【徹底解説】アジャイル開発に設計書は不要か？｜開発管理者が語る設計書の役割と運用・管理方法
はじめまして。
株式会社Enlytのベトナム側開発拠点、SupremeTech Co.,Ltdの上木です。
SupremeTechの副社長として、Project Management Office（PMO）やResource Management Office（RMO）など、管理面から開発プロジェクトを支援しています。
このEnlytブログでは名無しのインタビュアーとしてこれまでに２件の記事を書きましたが、ご覧いただけましたでしょうか。
先日「Why programmers don’t write documentation」という興味深い記事を読みまして、思うところがあり筆を執りました。以前、ディレクターの竹内がEnlytブログでドキュメント(画面設計書)の重要性について言及していますが、今回はその辺りを深掘っていければと思います。
目次
設計書が不要とされる背景
私はベトナムに来る以前、日本のSI企業でシステムエンジニアとして働いていたのですが、ウォーターフォール型の開発がメインだったこともあり、自ら設計書を描き、レビューを貰い、それを元にコーディング、テストケース作成、テスト実施を通しで行っていたため、設計書が不要という発想はありませんでした。
ですので、後にWEB系企業に転職していくつかのプロジェクトで設計書が存在しない現場を目の当たりにしたときは衝撃を受けました。
これは前職のベトナムオフショア開発企業での話ですが、私があるプロジェクトにフェーズ２から参加したことがありまして、フェーズ１から担当しているプロジェクトマネージャ（PM）に設計書の共有を依頼したところ、プロダクトバックログの管理に使っていたRedmineというタスク管理ツールのURLが送られてきました。
PM曰く、仕様は全てRedmineのチケットに記載されているためこれが設計書とのこと。
では何か仕様変更が入った場合はそのチケットを修正するのかと聞けば、その場合は新しいチケットを作成するようで、１つの画面の仕様が複数のチケットに跨っていたり、逆に複数の画面の仕様が１つのチケットに混在していたりして、到底設計書とは呼べない代物でした。
結局その時はフェーズ１で作成した既存プロダクトの設計書をフェーズ２が始まる前に私がイチから作成し、フェーズ２以降は適切に運用されるようになりました。
このPMは全社のPMOチームにも所属しているぐらい経験のある人物だったので、このレベルの人でもこの認識なのかと大変驚いたものですが、アジャイル開発に慣れた人達からすると、積み上げたプロダクトバックログやクライアントから頂いた概要資料、ディスカッションに使ったホワイトボード等があれば、設計書がなくてもコーディングできてしまうため、設計書の必要性やプロダクトバックログとの違いが分からなくても無理はないのかもしれません。
その辺りのことを先述の記事でも「Not documenting doesn’t block shipping」という表現で書かれていましたが、残念ながらこれは事実のようです。
引用文章：
If a developer doesn’t write documentation, their work still gets done. Not writing doesn’t block shipping (at least not right away).〜中略〜
Code will be accepted (to some extent) as long as it does its job. And since most organizations focus only on getting the product shipped, that which doesn’t block shipping gets ignored.
引用：https://kislayverma.com/programming/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ごとにチケットを切る案もありますが、ここではあくまで例えで機能としただけで、画像１つ、ボタン１つとっても仕様変更はあり得るので、全ての要素をチケットに分割するのは現実的ではありません。
また「コードに書かれているものが正だ」という考えもありますが、それは今そうであるというだけで、そうであるべきかはわかりません。
それが不具合でない保証はない以上、正しい仕様を認識していることにはならないのです。
設計書の役割
ではなぜ正しい仕様にこだわる必要があるのでしょうか？
確かにプロダクトバックログがあれば開発はできますが、それは短期的にしか成り立ちません。
アジャイル開発においては最小限の体制でプロジェクトをスモールスタートさせ、先ずはMVP（Minimum Viable Product：価値を提供できる最小限の機能）をリリースし、市場からのフィードバックを踏まえて長期的にカイゼンを重ねていくことが定石となります。
最初からプロジェクトに参加していて経緯から仕様まで全て頭に入っているメンバーだけで永遠に保守していくことができれば、或いはプロダクトバックログだけでも支障ないのかもしれませんが、新しいメンバーが参入してきたり、逆に既存メンバーが諸事情で外れたり、長く保守を行っていけばそういったイベントは避けられません。
その際、一子相伝の口頭伝授とならないよう、現時点で正しい仕様が記載された設計書が必要となります。
そもそも人間の記憶自体、完全性（情報が欠損・不整合なく維持されること）が100%保証されているものではない以上、記憶に頼るより記録として残すことが大切です。
設計書はクライアントとエンジニアの両方からレビューを通して合意を得た内容となるため、記載と異なる挙動がプロダクトで観測されれば不具合、または考慮漏れということになります。
まとめると、プロダクトバックログは短期的な開発ライフサイクルで有用な一方、設計書は長期的な保守に必要とされるツールと位置づけることができます。
| プロダクトバックログ | 設計書 | |
短期的な開発ライフサイクル | ⭕ 素早く要件を伝えられる点と、チケット管理ツールのコメント欄でのコミュニケーションを通した仕様策定が可能な点が便利 | 🔺 設計書があれば開発できるが、設計書作成には時間がかかるので、アジャイル開発ではボトルネックになる可能性がある |
長期的な保守 | ❌ 正しい仕様が分からないだけでなく、最悪誤認するリスクもある | ⭕ ステークホルダー間で合意済みの正となる仕様が明確 |
設計書が必要なのは分かった、でも面倒くさい問題
ここまででプロダクトバックログと設計書のそれぞれの役割について説明いたしました。
一方でエンジニアからは「設計書が大切なのは分かるが、作成する時間がない」とか「コードを書くのと違って面白くない（モチベーションがわかない）」といった声もしばしば聞かれます。
そういう人達は限られた時間の中でコーディングに集中したいためドキュメント作成を避けてしまい、避けている限りは上達もしないので益々忌避してしまうという悪循環に陥るものと思われます。
弊社SupremeTechでは、クライアントとエンジニアと共に仕様を練り上げプロダクトバックログや設計書に落とし込むビジネスアナリスト（BA）と、その仕様をコードに起こすソフトウェアエンジニア（SE）で、ドキュメンテーションとコーディングを分業できる体制をとっています。
設計書を描くにあたり最もマンパワーが必要なのはプロジェクトの初期に０→１で作成するフェーズであり、一度設計書を作り上げてしまえば、あとは保守で入った変更部分をアップデートしていくだけなので仮にSEが更新する場合でも心理的ハードルは大分下がります。
この最初の設計書を作成するのがBAの１つのミッションであり、この工程を通してプロダクト全体の仕様を把握、仕様ホルダーとしてプロジェクトに貢献できるようになります。
それでもMVPの規模が大きい場合や、他社が開発したプロダクトの保守で設計書が存在しないケースを取り扱う場合はBAの負荷が大きくなりがちですが、その場合は通訳/翻訳担当のジャパーニーズコミュニケータ（JC）と分担して設計書を作成することになります。
将来的にBAとなるキャリアパスをもつJCにとってもBA業務のトレーニングとなるので一石二鳥です。
いずれにしても、設計書の作成/保守はソフトウェア開発に必要な要素とみなし、SEのコーディング同様、PMによるタスク分割、計画、進捗管理が不可欠となります。
両方を運用する上でのTips３選
私は前職のベトナムオフショア開発企業でSenior BAとしてプロダクトバックログと設計書の両方を使ってプロジェクトを運営してきました。
その中で個人的にやりやすいと思っているTipsを３つ紹介したいと思います。
更新タイミング
プロダクトバックログは短期的な開発ライフサイクル内での仕様策定に用いられるため頻繁に更新が入ります。
一方で長期的な保守のために使う設計書はリアルタイムの更新まで求められないため、ある程度仕様が固まってから反映すればよいと思います。具体的にはプロダクトバックログを元にSEが実装を始めたタイミングや、実装後にクライアントが受け入れ確認したタイミングなどが挙げられます。
もちろん、設計書を元に開発するプロジェクトであればこの限りではありません。
使用ツール
プロダクトバックログの管理にはチケット管理ツールを使うことをおすすめします。Backlog, Github issue, Redmine等色々ありますが、担当者の割当、マイルストーンの設定、ステータスの変更、変更通知の機能があれば好みのものを選んでいいと思います。コードのバージョン管理でGithubを使うエンジニアにとってはGithub issueが都合良いかもしれません。
しばしば安易に導入できるスプレッドシートを使ってプロダクトバックログを管理するケースを見かけますが、これはアンチパターンだと思っています。短期的な開発ライフサイクルでは頻繁に更新が入りますが、スプレッドシートには更新を通知する機能がないため、いつの間にか誰かが追加、変更、削除していても気づかず見落としてしまうリスクがあります。
一方でプロダクトバックログと比べて更新頻度の低い設計書に関してはスプレッドシートを使っています。変更点については変更履歴用のシートに残します。スプレッドシートを表計算用途以外に使うなという過激な意見もありますが、実用に耐えれば何でもいいと思います。
クライアント向けと内部向けで分けるか否か
プロダクトバックログについてはクライアント向け（クライアントとBAが利用）と内部向け（BA, PM, SEを含むプロジェクトメンバーが利用）に分けた方が良いと考えています。
先ずは言語の問題があります。プロダクトバックログではプロダクトがどうあるべきかといった抽象的な会話も必要となるため、クライアントもなるべく母国語（日本語）を使って議論したいケースが多いのですが、ここに日本語が分からないベトナム人プロジェクトメンバーが入るとJCがベトナム語や英語に翻訳することになり、複数言語が入り乱れて可読性が落ちてしまいます。
次に情報の精度や粒度の問題です。議論をしていく中で仕様が二転三転することはよくありますが、まだ検討段階なのにエンジニアが早とちりして実装着手してしまい手戻りに繋がってしまうリスクが考えられます。また、複数の要件が１つのチケットで語られていたり、逆に複数のチケットで類似の要件が議論された場合は、必要に応じて分割/統合するなど一度整理した上でエンジニアに伝達することで認識齟齬の発生を抑えることができます。
以上の点から日本語でやりとりするクライアント向けプロダクトバックログと、英語またはベトナム語でコミュニケーションを行う内部向けプロダクトバックログにツールごと分けて管理する方法をとっていました。
一方、設計書については、作成後にクライアントとエンジニア双方から合意を得る必要があるため、共通のスプレッドシートに英語で記載して全員が同じものを見られるようにするのが好ましいです。日本語で描いたものをベトナム語に翻訳すると、日本語版とベトナム語版の二重管理になってしまい、保守時に一方を修正したものの他方に反映が漏れてクライアントとエンジニアの間で仕様の認識相違を引き起こす可能性があります。
英語で記載するとは言っても、設計書では長文での説明より短い文章で端的に要件を記載するため、よほどの英語アレルギーを持つ人でもない限りは許容いただけるのではないでしょうか。
この運用フローは私自身の経験から得たベストプラクティスでしかなく、全ての状況に適用できるものではありません。
基本的には各プロジェクトの特性、ステークホルダーの好みや経験、宗教観に基づいてワークフローやツールを選定して問題ないと思います。
現状ドキュメンテーションが上手く機能していない場合に、あくまで一例として参考にしていただければ幸いです。
おわりに
この記事は設計書がなぜ必要なのか分からない人や運用方法に課題を感じている人へ向けて、その役割や付き合い方をお伝えするために書きました。
弊社SupremeTech内においても、設計書の必要性と無い場合のリスクとを正しく認識し、必要なリソースを割けるよう、啓蒙（※）と体制面からサポートしていきたいと思います。
※この記事はベトナム語に翻訳したうえで全社に展開します。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、Enlytではこれまで50以上の開発プロジェクトを行ってきました。（ 株式会社Enlytの実績は開発実績ページから）ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
アジャイル開発をご検討の際は、株式会社Enlytまでご気軽にお問合せください！お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
下記ボタンより気軽にお問合せください！
