https://enlyt.co.jp/blog/spec-agile/
image title
2021-08-17
はじめまして。 株式会社Enlytのベトナム側開発拠点、SupremeTech Co.,Ltdの上木です。 SupremeTechの副社長として、Project Management Office（PMO）やResource Management Office（RMO）など、管理面から開発プロジェクトを支援しています。 このEnlytブログでは名無しのインタビュアーとしてこれまでに２件の記事を書きましたが、ご覧いただけましたでしょうか。
先日 プログラマーがドキュメントを書かない理由 という興味深い記事を読みまして、思うところがあり筆を執りました。以前、ディレクターの竹内がEnlytブログでドキュメント(画面設計書)の重要性について言及していますが、今回はその辺りを深掘っていければと思います。
私はベトナムに来る以前、日本のSI企業でシステムエンジニアとして働いていたのですが、ウォーターフォール型の開発がメインだったこともあり、自ら設計書を描き、レビューを貰い、それを元にコーディング、テストケース作成、テスト実施を通しで行っていたため、設計書が不要という発想はありませんでした。 ですので、後にWEB系企業に転職していくつかのプロジェクトで設計書が存在しない現場を目の当たりにしたときは衝撃を受けました。
これは前職のベトナムオフショア開発企業での話ですが、私があるプロジェクトにフェーズ２から参加したことがありまして、フェーズ１から担当しているプロジェクトマネージャ（PM）に設計書の共有を依頼したところ、プロダクトバックログの管理に使っていたRedmineというタスク管理ツールのURLが送られてきました。 PM曰く、仕様は全てRedmineのチケットに記載されているためこれが設計書とのこと。 では何か仕様変更が入った場合はそのチケットを修正するのかと聞けば、その場合は新しいチケットを作成するようで、１つの画面の仕様が複数のチケットに跨っていたり、逆に複数の画面の仕様が１つのチケットに混在していたりして、到底設計書とは呼べない代物でした。 結局その時はフェーズ１で作成した既存プロダクトの設計書をフェーズ２が始まる前に私がイチから作成し、フェーズ２以降は適切に運用されるようになりました。
このPMは全社のPMOチームにも所属しているぐらい経験のある人物だったので、このレベルの人でもこの認識なのかと大変驚いたものですが、アジャイル開発に慣れた人達からすると、積み上げたプロダクトバックログやクライアントから頂いた概要資料、ディスカッションに使ったホワイトボード等があれば、設計書がなくてもコーディングできてしまうため、設計書の必要性やプロダクトバックログとの違いが分からなくても無理はないのかもしれません。 その辺りのことを先述の記事でも「ドキュメントを書かなくても出荷は妨げられない」という表現で書かれていましたが、残念ながらこれは事実のようです。
引用文章：開発者がドキュメントを書かなくても、仕事は終了です。ドキュメントを書かなくても、出荷が妨げられることはありません（少なくとも、すぐには）
〜中略〜
コードはその機能を果たしている限り、（ある程度）は受け入れられます。そして、ほとんどの組織は製品を出荷することだけに集中しているので、出荷を妨げないものは無視されてしまうのです。
https://itnews.org/news_contents/why-programmers-dont-write-documentation
設計書が無くても開発できるのだとすれば、不要とみなされても仕方がないでしょう。 では本当にプロダクトバックログがあれば設計書は不要なのでしょうか？ 実は、プロダクトバックログと設計書は同じ「仕様」を取り扱うものでありながら、その役割が異なります。 つまりどちらの方が優れているということではなく、どちらもそれぞれ別の用途で必要なもの、と言えます。
弊社ではよくプロダクトバックログを Backlog, Github issue, Redmine等のチケット管理ツールを用いて管理しています。 １つのプロダクトバックログを１つのチケットに起票し、必要に応じてコメント欄でQ&Aやディスカッションを行い、決まったことをチケットの概要に反映していきます。 開始時点で仕様がカッチリ固まっていないことが多いアジャイル開発において、複数のステークホルダーがプロダクトの仕様策定に関与できるこの方法はとても効率的です。 開発が完了したプロダクトバックログはクローズされ、変更要件があれば新規に起票されるため、エンジニアは現在オープンになっているチケットにのみ集中することができます。 チケットの数が可視化されているため、見積もりに基づいたスケジュールが立てやすく、ゴールが見えることでエンジニアのモチベーションを高めることもできます。
一方、プロダクトバックログだけでは「いま、正となる仕様は何か」「何が正しいのか」が分かりにくいという課題があります。 例えばプロダクトバックログ上で以下のような経緯があったとします。
1. A-1, A-2, A-3という機能を含む画面Aを開発したい
2. チケット①で画面Aの要件を起票
3. エンジニアが開発→チケット①をクローズ
4. 画面Aの機能A-1と機能A-2に関わる部分を仕様変更したい
5. チケット②で機能A-1, A-2の変更要件を起票
6. エンジニアが開発→チケット②をクローズ
7. 画面Aの機能A-2に関わる部分を仕様変更したい
8. チケット③で機能A-2の変更要件を起票
9. エンジニアが開発→チケット③をクローズ
ここで改めて画面Aの正しい仕様は何かを確認しようとすると、クローズ済みのチケット①②③全てを見つけ出し、時系列に沿って組み立てる必要があります。（この例では画面Aがチケット②に記載された機能A-1とチケット③に記載された機能A-2とチケット①に記載された機能A-3で構成されているのが正） クローズ済みのチケットはチケット管理ツールで検索して見つけることになりますが、１つでも検索が漏れたり、組み合わせ方を間違えたりするだけで、間違った仕様を正しい仕様と誤認することになります。 その誤った前提で新しい仕様を検討しようものなら被害は大きくなるばかりです。
機能A-1, A-2, A-3ごとにチケットを切る案もありますが、ここではあくまで例えで機能としただけで、画像１つ、ボタン１つとっても仕様変更はあり得るので、全ての要素をチケットに分割するのは現実的ではありません。 また「コードに書かれているものが正だ」という考えもありますが、それは今そうであるというだけで、そうであるべきかはわかりません。 それが不具合でない保証はない以上、正しい仕様を認識していることにはならないのです。