トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

しっかりと整備されたドキュメントはなんぼあってもいいですからね、という話

この記事は、トレタのアドベントカレンダー2021の14日目の記事です。

。。。いや、なんぼはあると管理的な意味で困っちゃいますね。

f:id:FukuromiQA:20211220223604p:plain

みなさん、ドキュメント作ってますか?こんにちは。トレタでQAをしている福富です。
普段は(こないだプレスリリースも出た)デジタル塚田農場プロジェクトのO/Xの方でQAをしています。
(プレスリリースはこちら、O/Xについてはこちらをご参照ください!)

こちらのプロジェクト、自分はキックオフから関わってきまして、たくさんのドキュメントをまとめてきました。
スピードが重要視されるプロジェクトにおいてドキュメントをいっぱい作るのは大変ですし、管理も辛いです。
でも、作ってきたドキュメントに助けられることも多々ありました。
今回は、自分がドキュメントをまとめる目的ならびに気をつけていること、実際にどんなドキュメントを作っているのかを紹介してみたいと思います。

なぜドキュメントをまとめるのか

ドキュメントをまとめる理由って、そのドキュメントの内容にもよると思うんですけど。。。
個人的に一番大事なのは未来のチームの生産性を担保することだと思っています。

時間が経つと、チームメンバーは移り変わっていくものです。
最初のころは阿吽の呼吸で物事を進められても、メンバーが変わればそううまくはいきません。
ドキュメント化されていない部分の疑問が出てきて、調査、回答にかかる時間が増えていきます。
そうなると必然的に「自分がやりたかったこと」を対応する時間が減っていくので、生産性が下がっちゃいますよね。
そんなとき、しっかりとドキュメントがまとまっていれば「基本的にはそこ読めば解決!」となり、調査にかかる時間も削減されます。
質問される回数もきっと減るので、差し込み対応の数も少なくなって集中できますね!
もちろん、ドキュメントが最新化されているということが前提になりますが、
弊チームでは、カンバンボードに「DOC UPDATING(仕様更新)」を追加し、ドキュメントの更新漏れを防ぐようにしています。

f:id:FukuromiQA:20211221123711j:plain
QA後、DOC UPDATINGを経由してDONEにする感じ。

まとめるにあたり意識していること

そのドキュメントは誰のため? を意識する

今から作成するドキュメントは誰のためのものなのか、ターゲットをしっかりと定めましょう。
例えばの話ですけど、仕様ドキュメントを作るとして、それが開発者向けなのか、QA向けなのか、それとも営業さん向けなのかによって書き方って変わると思うんですよね。
だから、できる限り作成する前にターゲットは定めておきましょう。

書き始める前にフォーマットを考える

ちゃんとしたドキュメントを作るとなると、フォーマットの統一は必要不可欠です。
フォーマットなしのメモ書きでは、後から見直したときや他の人が見たときに解読に時間がかかってしまいます。
そうなると、時間短縮のために開発者に質問をすることも増えるので、あんまりドキュメントとしての意味をなさなくなっちゃいますね。
上記のターゲットとあわせて(というか、ターゲット次第で書く内容も変わるのでフォーマットも変わると思います)、しっかりと決めておきましょう。
もちろん、書いていく中で必要な項目が増えてフォーマットが変わることもあります。要は読みやすく整理されていればいいのです。

溜め込まない すぐに更新する(強い気持ちで)

大事なのことなので2度言います。
溜め込まない すぐに更新する。
更新を怠るとドキュメントの鮮度が落ちるっていうのは当然として、
溜め込んでしまうと更新量が多くなって、更新するために必要な時間が増えて、でもそんな時間はなくて。。。みたいな状況になって更新が難しくなります。
そうならないよう、ドキュメントはこまめに更新しましょうね。

過去に作成したドキュメント

ここからは実際に自分が作成してきたドキュメントについて簡単に紹介します。
まとめておいてよかった点や、これからの課題についてもまとめるので、なんかの参考になればいいなと思います。

テストログ、テスト仕様書

f:id:FukuromiQA:20211220223021j:plain

これはなに?

QAエンジニアが改修に対してどんなテストをするか(したか)を残しておくドキュメント。

誰のため?
  • QAエンジニア、開発者
まとめておいてよかったなと思うシーン
  • 開発者とのテスト設計レビューが非常にやりやすい(画面共有で一緒に見ながらできるため)
  • ドキュメントとして残しておくと、その後の改修プロジェクトにケースを流用できる
  • リグレッションテストは既存のテスト仕様書をコピーして書き足していくだけでいいので準備がラク
これからの課題
  • 今までずっと設計書ドキュメントをコピペしながらやってきたので、ケースをマスタ化したい
  • リグレッションテストの準備がラクなのでなかなか自動化に踏み出せないでいる(言い訳!)

簡易な画面仕様、機能仕様

f:id:FukuromiQA:20211220221528j:plain

これはなに?

画面仕様はこの画面にどんな情報が表示されているか、画面遷移や入力時のバリデーションなどを記載するもの。
機能仕様は画面を横断する機能について、事前準備や利用の流れ、注意事項等をまとめておくもの。

誰のため?
  • プロジェクトに関わる開発者、QA、デザイナー、ビジネスサイドのメンバーなど全員
  • 途中から参画するメンバー
まとめておいてよかったなと思うシーン
  • みんな欲しいと思っていたのか、めっちゃお礼を言われる
  • 改修前に開発者さんも仕様をまとめてくれるようになり、開発前にみんなでレビューできるようになった
これからの課題
  • 現在は強い気持ちで継続的に更新しているが、その気持ちが途絶えた途端に負債化しかねないところ(どんな仕様書にも言えることだが。。。)

セットアップマニュアル類

f:id:FukuromiQA:20211220223316j:plain

これはなに?

O/Xは導入時に店舗にてプリンタ機器を設置する必要があり、そのセットアップ手順をまとめたもの。

誰のため?
  • 導入サポートで店舗にてセットアップを実施するメンバー
まとめておいてよかったなと思うシーン
  • 初期段階では導入サポート的なメンバーがおらず、色んな人が店舗にてセットアップを行ったが、このドキュメントがあることでみんなすんなりと作業を進められたと思う
  • 店舗側でセットアップを行う場合の手順書をこのドキュメントをもとに作成したのでスムーズにできた
これからの課題
  • 特になさそう

毎日のスタンドアップの議事メモ

f:id:FukuromiQA:20211220222837j:plain

これはなに?

チームで毎日行っているスタンドアップにて議論した内容をメモし、Slackにて共有しているもの。

誰のため?
  • スタンドアップ参加者、参加していないがプロジェクトに関わっているメンバー
まとめておいてよかったなと思うシーン
  • スタンドアップに参加していないメンバーが、議事メモを見て回答などのアクションを起こしてくれることが多い
  • 過去のスタンドアップで決めたことを簡単に思い出せる

おわりに

と、まあこんな感じです。
スタンドアップの議事メモは毎日更新ということもありますが、この1年でだいたい400くらいのドキュメントを作成してきました。
1日1ドキュメント以上と考えると、なんだか達成感が湧きますね。
冒頭でも言ったとおり、ドキュメントの管理はすごく大変です。でもやっぱりドキュメントに助けられる場面も多いんですね。
とはいえ負担も大きいので、ドキュメントの整備をするなら自分ができる範囲でやるのが一番よいと思います。
自分はこれからもドキュメント残し魔として、大量のドキュメントとともに生きていこうと思います。
それではまた!

トレタでは一緒に働くメンバーを募集しています!

トレタはいろんな職種で一緒に働くメンバーを募集しています!
QAとしては上流からすべての工程に関わることになります。
非常にスピードがはやい環境の中でQAとしてのスキルを磨くことができます!

少しでも興味があれば、カジュアル面談などお気軽にご応募ください!

www.wantedly.com

corp.toreta.in

優秀なデザイナーが上流工程に加わると開発が捗る話

こんにちは、何がなんでもアドベントカレンダーを埋めようとしている鄧(でん)です。

Data is a precious thing and will last longer than the systems themselves.

-- Tim Berners-Lee

今日はトレタのエンジニアとデザイナーの連携についてお話させてください。

ちょっと前までのトレタでは主にデザイナーが顧客にヒアリングした上でユースケースを整理し、ワイヤーフレームを作ります。そこからよくも悪くもワイヤフレームが仕様書となり、そこからフロントエンドエンジニアに渡され、フロントエンジニアはワイヤーフレームと API の間に板挟みになって、どう API につなげるか、API が足りない場合は DB のどの項目をどう API に反映させるかのすり合わせが始まりますが、お世辞でも効率がいいとは言えません。

そこで新しいサービスとして O/X を設計した際には流れを逆転させ、まずはデザイナーとエンジニア(~= サーバーサイドエンジニア)が長期的な運用を意識しつつ、お客さんの課題を理解し、ソリューションと共通の言語(~= ユビキタス言語を意識している何か)を定義してすり合わせてからフロントエンジニアに渡すやり方をチャレンジしております。

ここ際にユースケースを達成するために保存する、あるいは表示する情報を整理しますが、デザイナーは情報アーキテクチャ(Information Architecture )、エンジニアは ER モデル使います。細かい表現や制約は若干違ったりしますが、本質的には 情報を整理する と言う同じルーツを持っているので、場合によってはペアリングして設計を進めることも可能です。

デザイナーは最終的にワイヤーフレーム、エンジニアはデータモデル(例:ER 図)を作りますが、フロントエンジニアに渡す前にワイヤーフレームとデータモデルをすり合わせて抜け漏れがないかを確認します。(O/X の API は基本データモデルの CRUD が多いのでほぼそのまま適応することが可能です)

f:id:toreta-dev:20211208192455p:plain
デザインに対してのアノテーション例

具体的にはワイヤーフレームに対してデータモデルを被せてレイヤーを分かりやすくしているのですが、トレタでは figma を使うことが多いのでこのように色を使ってデータモデルの境界線を表示した上で、文字でデータモデルの項目とのマッピングを表現しております。

この際にデザイナーと同じく QA もディスカッションに入るので客さんの課題やスースケース、ワイヤーフレーム、設計意図、データモデル、API 仕様など全てを俯瞰的に把握することが可能です。

ここで優秀なデザイナーと優秀なエンジニアの共通点としてはお客さんのペインややりたいことを理解することができ、情報を整理する能力が優れており、それを言語化する能力も優れていると認識しており、そのようなメンバーが集まっているプロジェクトは居心地がいいと感じております。

さて、トレタのデザインプロセスについてエンジニア視点でお話しさせていただきましたがいかがでしょうか?もしご意見、ご指摘などがございましたらぜひお聞かせいただければと思います。

最後に宣伝

トレタでは一緒に飲食店の未来を作るデザイナーを積極募集中です!まずはカジュアルに話を聞きたい方もこちらからご応募いただけます!

corp.toreta.in

優秀な QA メンバーが上流工程に加わると開発が捗る話

こんにちは、なんとか今年のアドベントカレンダーを埋めようとしている鄧(でん)です。

今日は社内での QA メンバーの活動についてお話させてください。

今までのトレタでは 要件定義(ふんわり)→ 設計(ふんわり)→ 実装 → QA の流れでどちらかというとウォーターフォール型の開発が多かったと記憶しております。リリースはできていたのである意味ワークしていたと言えますが、QA の視点からすると

  • この画面や API はどんな課題を解決するためのものか
  • なぜその設計に至ったのか
  • 今の挙動やレスポンスは果たして当初意図した正しものなのか

など、QA メンバーのフィードバックから、コンテキストが正しくバトンタッチされていないことが多いと感じました。

改善内容

サービスの品質や保守容易性(maintainability)を担保するために QA のメンバーにお願いして以下の施策に協力していただきました。

ドキュメント整備

まずは、QA メンバーの協力を得て API シーケンスからエラーコードの整備など、暗黙知だった部分を仕様とドキュメントとして言語化しました。まだまだ、改善の余地は多い(というか伸び代しかない)のですが、API 利用者目線でも全貌が把握しやすくなりましたし、設計意図、動作確認など、テストケースを設計する際にも便利になったと認識しております。

API シーケンス図

f:id:toreta-dev:20211204101829p:plain
API シーケンス図

エラーコード一覧

f:id:toreta-dev:20211204101933p:plain
エラーコード一覧

テスト駆動

一部のサービスではコードを書く前に QA メンバーの協力を得て、テスト内容をコードより先に書く所謂テスト駆動の手法を検証してます。トレタは TypeScript、Ruby on Rails、Golang、Clojure などさまざまな言語やフレームワークを扱っております、それを QA が全て把握するのは現実的ではないと思いますが、仕様を把握した上で日本語として言語化することなら実行可能ですので、それを実際にコードを書く前に仕様書ベースですり合わせ、実装と共に担当エンジニアがテストコードとして翻訳して CI を通してことによって、毎回 QA の手を借りずとも継続的品質を担保しやすくなりました。

情報を俯瞰できる環境づくり

最後に、QA メンバーには要件定義段階から会話に参加頂き、開題と設計意図などの情報をキャッチしやすくしました。これによって QA メンバーは基本的に事後出来上がったものを渡されて「テスト作業」する作業員ではなく、課題を理解し、方針や設計などにも参加しやすくなったと考えております。

たまにはライオンの威を借りて品質の重要性、テスト容易性などに注目するように意識喚起することもあります。

f:id:toreta-dev:20211204102657p:plain
品質の重要性

最後に宣伝

トレタでは一緒に飲食店の未来を作る QA エンジニアを積極募集中です!まずはカジュアルに話を聞きたい方もこちらからご応募いただけます!

corp.toreta.in

参考資料

© Toreta, Inc.

Powered by Hatena Blog