「アジャイル開発では設計書は必要ない」「設計書がないとプロジェクトに途中から入っても何が何だかわからない」
こんな相反する話を聞いたことはないだろうか。
実際、この意見は個別に捉えると両方とも的を射ているように聞こえる。
アジャイル開発では設計書は必須資料ではない。
確かに、設計書を作ることによってそれ自体の工数や内容をメンテナンスする工数が必要になってくる。そのため、アジャイル開発で求められるようなスピード感が出しにくくなる。
設計書がないとプロジェクトに途中から入っても何が何だかわからない
だからと言って、設計書がないプロジェクトだとどういうことが起きるか。途中からプロジェクトに参加した人にとっては、どういう構造でシステムが組まれているのか理解するまでにかなりの時間を要することになる。
しかし、この一見矛盾している二つの意見をより詳細に考えると、筆者は以下のような要素が設計書を作るか否かを決める際に必要ではないかと考えるようになった。
その結果、自分の中では以下の結論に至った。
まず、以下が必ず必要になる「２つの設計書」だ。
「２つの設計書」
・システム構成図
・ER図
それ以外にも、「その他の設計書が必要になる２つの場合」がある。
「その他の設計書が必要になる２つの場合」
・複数のシステムを跨ぐような処理を行う機能の設計図
・自分以外の誰かが開発をする時で、なおかつ開発者と自分の間にスキルのギャップがある時
本文でそれぞれ、それぞれを詳しくみていこう。
アジャイル開発で必須の設計書２つ
アジャイル開発においても設計書は作成するべきだ。
ここでは、冒頭で挙げた４つの観点のうち、最初の２つに焦点を当てていく。
結論としては、メンテナンスコストが少なくて、その設計書があると該当の機能やシステムに対するキャッチアップがしやすくなるような設計書は必ず作るべきだ。
新しい人がプロジェクトに入る時というのは、切羽詰まってる時が多い。その時に、説明資料を毎回作るのではなく、資料だけ渡してキャッチアップしてもらえるととても助かる。
既存のプロジェクトメンバーにとっては、新規の人に説明する時間を省くことができるのでプロジェクトを前に進めることに集中できる。
また、新規参入者としても忙しい既存のプロジェクトメンバーに質問して、彼らの作業をとめるという心理的に負荷のかかることをしなくて済む。それに、一度の説明で全てを把握するのは難しいため、何度も見返せる資料が準備されているとプロジェクトの内容を理解するのが早くなる。
こういった設計書は、具体的にはシステム構成図やER図が挙げられる。
システム構成図
システム構成図はアジャイル開発においても必要だ。これがあるだけで、システムの作りの大枠を理解しやすくなる。
例えばこのような図があるだけで良い。
ER図
ER図もアジャイル開発においても絶対に必要だ。データ構造というシステムの根幹を理解することができれば、そこから業務を想像することもできる。
例えばこのような図だ。
アジャイル開発でも設計書を作ったほうが良い２つのケース
ここでは、冒頭で挙げた４つの観点のうち、残りの２つに焦点を当てていく。
結論としては、以下の２つの場合には設計書を作るべきだ。
・複数のシステムを跨いで処理をする機能の開発時
・自分以外の誰かが開発をする時で、なおかつ開発者と自分の間にスキルのギャップがある時
それぞれ詳しくみていこう。
複数のシステムを跨いで処理をする機能の開発時
これはいわば、複雑な処理を必要とする機能をわかりやすい基準を使って言い換えた場合だ。こういった場合は、是非とも設計書を作成するべきだ。
作成するメリットとしては以下の２つが挙げられる。
・設計レビューを受ける時に、チーム内で議論の認識を合わせやすい
・開発をする前から、開発時に課題になりそうな点を早めに把握できる
前者についてはこういうことだ。こういった複雑な案件については、実際にコーディングを始める前にチーム内で設計レビューを受けることが想定される。その際に、口頭で説明するだけよりも資料としてテキストや図を使って説明するほうが認識を揃えやすい。
後者については、開発をする前に開発の模擬体験をすることで課題を早期発見できるということだ。精度はもちろん１００％ではないが、大きな課題については見つけられる。
例えば、登山では実際に山に登る前に「机上登山」というシミュレーションをするらしい。これによって、当日のルートや起こりうるリスクを想像することができるということだ。もちろん実際に登山をしたらよりリアルで想像していなかったような課題が見つかるだろう。しかし、机上登山でも十分な対策ができるということらしい。
これと同じことが設計についても言える。実際にコーディングしてみたら課題は出てくるであろうが、設計する段階でも大きな課題は見つけることができる。
例えば筆者の過去のプロジェクトでこんなことがあった。そのプロジェクトではセキュリティ診断ツールを作成していた。そこで過去１ヶ月で行ったセキュリティ診断の結果をまとめたレポートをPDFで作るという案件を任された。
その時、シーケンス図を書きながら処理の設計をしていたら、単純に既存のインフラの構成では実現できないことがわかった。（既存のインフラ構成は単純にDBとWebアプリケーションサーバがあるのみだった）
例えば以下のような問題があった。
・ユーザがセキュリティ診断レポートを作成依頼した時に、作成処理が5秒以上かかる可能性がある。
・PDFデータの容量が大き過ぎてネットワーク上でデータのやり取りができない可能性がある。
そこで以下のように設計を変更し、PDFデータを保存しておくためのインフラ構成を取る必要があることがわかった。（赤背景の登場人物が追加されたインフラの構成要素だ）
もちろん、これができたからといってその後の開発に全く問題がなかったわけではない。しかし、少なくとも開発が始まる前の段階で、開発ボリュームが最初に考えていたよりも圧倒的に多いこと、さらに自分だけではなくインフラ担当者とも連携をとる必要があることがわかった。
自分以外の誰かが開発をする時で、なおかつ開発者と自分の間にスキルのギャップがある時
これはチームメンバー間にスキルのギャップがある場合だ。
できる人が設計書を書き、開発自体はまだ経験が浅いメンバーに任せられる状況であれば是非ともそうするべきだ。
これをするメリットとしては以下の２つが挙げられる。
・短期的にメンバー全体のスループットが挙げられる可能性がある
・長期的にチーム全体の開発スキルが上がり、スループットも上がる
そもそもスループットとは、一定期間内での処理能力のことを指している。アジャイルの開発プロジェクトにおいては、１回のイテレーションで完了できるストーリーポイントのことだと読み替えることもできるだろう。
短期的にメンバー全体のスループットが挙げられる可能性がある
メリットの一つ目は、設計担当者が設計に力を割くことでチーム全体としては消費できるストーリーポイント数が増加する可能性があるということだ。
ただし、以下の二つのストーリーポイントの後者が前者を上回っている必要がある。
・設計担当者が設計に力を集中させることで失われる本来消費できたはずのストーリーポイント数
・設計担当者以外の開発者が設計をしなくて済むようになったことで増加した消費できるストーリーポイント数
例えば３人チームで、それぞれスプリントあたりの消化できるストーリーポイントが以下の状態だった場合を考える。
・Aさん：５
・Bさん：３
・Cさん：３
・Dさん：２
この場合、１回のイテレーションで完了できるストーリーポイントは単純に合計すると13ptだ。しかし、この時Aさんが工数の半分を使って設計に時間を使ったとする。その結果他の３人のストーリーポイントが1ptずつ上がったら、そのイテレーションでのストーリーポイント消化量は13.5pt だ。
このように、Aさんが設計に力を割くことで失われるストーリーポイントの消化量（2.5pt）が、その分のチーム全体としてのストーリーポイント消化の増加量（3pt）を下回ればメリットになる。
長期的にチーム全体の開発スキルが上がり、スループットも上がる
メリットの二つ目は、設計と開発を切り離すことができるので、特に経験が浅いメンバーが担当できる開発領域が広がり、開発の知見が溜まりやすくなることで、全体としての開発スキルが上がり、結果としてチーム全体のスループットも上昇するということだ。
例えば設計と開発がセットになっているとこんなことが起きる。DBに変更を加えたことがない人はDBの設計も勘所がなく行いづらいため、結局実務でDBの変更に関する案件に挑戦する機会を得づらい。
しかし、設計と開発が別れていれば、設計されたものをもとに開発を行うことができる。開発をしていく中で実践的な疑問として「このときどうするんだろう」「なんでこうしたんだろう」という考えが出てくる。これによって、さらなる学習のとっかかりにもなるし、その後の学習も実際の状況にひきつけて考えることができるため効率よく進めることができる。
まとめ
アジャイル開発においてどのような設計書が必要なのかについて述べてきた。
ここで述べてきたような観点でぜひ一度、読者の方の実際の業務においても「その設計書は必要なのか」、「ここでは本当に設計書を残さなくても良いのか」ということを考えてもらえたら嬉しい。
