価値ある設計書かどうかはIPOで決まる

PM

昨日のエントリで、ドキュメント（設計書）の有用性について書きましたが、これはよくある話。
では、どうすれば価値のある設計書になるのかについて、もう一歩踏み込んで考えてみます。


まず、設計書とは、最終的にコードを作成するための成果物であり、価値のない設計書とは、コードを作成するのに役に立たないものだと言えるでしょう。

「顧客にレビューしてもらうため」とか「エンジニア間でコミュニケーションを取るため」といった意見もあると思いますが、それも最終的には、コードまで落とし込むための過程と考えられます。


その設計書を作成する上で、設計技法としては、以下のようなキーワードが必ずと言ってよいほど挙げられます。

設計に関する書籍では、大抵このような設計技法を扱っているのですが、これらのものは、分析や表現に重きがあり、どうすれば良い設計になるのか、という部分には触れられないことが多いです。


私自身は、表記方法がどうであれ、設計とはソフトウェアエンジニアリングの分野であり、その原則は、この数十年変わっていないのではないかと思っています（とは言え、私自身は、ソフトウェアの開発に携わるようになってから10年にも満たないので、これまで見てきた設計書と先人の教えからの見解ですが）。


その原則とは、IPO（Input --> Process --> Output）」を決定すること。


IPOとは、システムやアプリケーションの入力データ（Input）は何で、出力データ（Output）は何かを定義し、それから、それを実現する処理（Process）を考えることです。

この内容がしっかり書かれている設計書は、見ていて分かりやすいし、上流から下流へ詳細化していきやすい。
各工程で、注目する点は以下のようなものです。

設計工程 IPOで着目する点
基本設計 画面の入出力
DBやファイルのデータ入出力
外部インタフェースの引数と戻り値
詳細設計 コンポーネント単位の引数と戻り値
内部インタフェースの引数と戻り値
実装 メソッドの引数と戻り値


冒頭で、「価値のない設計書とは、コードを作成するのに役に立たないもの」と書きましたが、上記の点を意識して詳細化していけば、「コードを作成するのに役に立つ設計」になると分かるのではないでしょうか。

さらに、Input／Outputがハッキリしていれば、テスト項目もあげやすいので、システム全体の品質向上に必ず繋がります。
TDD（テスト開発駆動）も、IPOをメソッドレベルで考え、それについて処理を記述するのが根本の考えにあります。


自分が設計するときも、他者が設計した内容をレビューするときも、まず、大きな視点でIPOを見るところから始めるのですが、それで、設計の良し悪しが左右されます。