前回は設計書に何を書いたらいいのかについて書いた。
今回は設計に関して少し補足をしたい。
アジャイル開発と設計の話
ここまででかなりじっくりと要件定義と設計の話をしてきているので、これはウォーターフォール開発向けの話だと思っている人も多そう。 あるいは「うちはアジャイル開発してるから設計なんてしないんだよね」なんていう人も。
まず、「アジャイル開発では設計をしない」というのはアジャイル開発に対する典型的な誤解。
次の図は『アジャイルサムライ』に出てくる図。
見ての通り、アジャイル開発でも分析（≒要件定義）や設計という工程は含んでいる。 なので、アジャイル開発だからといって要件定義や設計をしないというわけではない。
違うのは、前の工程が全部終わってから次の工程に行くというのではなく、段階的に何度も繰り返すというところ。 これはソフト開発における「設計」とは何なのか。（その4） - いものやま。で書いた図にも近い。 粒度の違いはあるかもしれないけど、繰り返し開発していき、その中で要件定義や設計していくというのは、ソフトウェア開発の基本的な考え方となっている。
ただし、設計はするけど、設計書を書くとは限らないというのは少し注意が必要。 これはソフト開発における「設計」とは何なのか。（その5） - いものやま。にも書いたけど、設計書はあくまでコミュニケーションのためのツールなので、別の手段でコミュニケーションが取れるなら、書かなくてもいいというのがあるから。
具体的には、アジャイル開発で使われることのあるプラクティスとして、ペアプロやモブプロというのがある。 これは担当者が一人で設計、実装していくのではなく、複数人でやっていくというもの。 みんなでワイワイと議論しながら作業を進めていくので、紙の上で方向性のコミュニケーションをする必要性が下がる。
あるいは、アジャイル開発だと同じ場所に集まって開発を進めた方がいいというプラクティスもあって、これも気軽にその場で相談や議論ができるので、方向性の確認が必要なら逐次その場でやっていけばいいというのがある。
あとは、とりあえず実装ができたら方向性がちょっと違っていてもOKとしてしまって、方向性の修正は次のイテレーションで行うという手もある。 繰り返しが短い期間で行われるので、ちょっと方向性が違った実装が出てきてしまっても、そこで学んだことを次の繰り返しで反映するのがやりやすい。 もちろん、開発に必要な工数自体は増えてしまうんだけど、間違った方向に進んだままリリースしてしまうというリスクをかなり抑えられる。
実際、ウォーターフォール開発で設計をしっかりと考えてみたけどコードを書き進めてみたら思ったよりも感触が悪いというのもよくある話。 そのときは、よく練られた設計を考えるよりもとりあえずの設計で動く実装を用意してみて、そこからのフィードバックを踏まえていい設計を考えて実装を直す方がよかったりする。
実現可能性との付き合い方
上記のアジャイル開発の方法と関連して、実現可能性の問題というのは常にある。
何かというと、設計を考えてみたけど、実際にやってみたらうまいこと動かなかったみたいな問題。 設計をするときはこれとどう付き合っていくかというのを考えておかないといけない。
一つの対策は、上記の通りアジャイル開発的な方法を使うというもの。 つまり、まずは動くものを作っておいて、繰り返しの中で必要に応じて改善していく。 こうしておけばとりあえず動くものがあるので企画倒れで終わることはないし、最悪そのままリリースもできる。
他の対策は、アジャイル開発の方法に近いんだけど、実際に手元で仮の実装を作って実現可能性を確認しておくという方法。 手元で試行錯誤した結果を踏まえて「この方法だとこういうメリットがある」「この方法だと問題があるからやらない」というのを書けると、設計書に説得力を持たせられる。
ただ、気をつけないといけないのは、手元で試した実装をそのまま「できました」と出しちゃうのはダメということ。 あくまで実現可能性を確認するためのコードなので品質に問題があるし、方向性が違って「なんじゃこりゃ」となったり、あるいは「じゃあそれで」と仮の実装なのにそのまま使われてあとで苦労することになりがち。 なので、方向性の確認は設計書でちゃんとやった方がいい。
一応これで設計のプロセスに関する話は終わり。
あとは実際にソフトウェアの設計をどう考えて作るといいかについて少し書きたい。
今日はここまで！
