価値ある設計書かどうかはIPOで決まる
昨日のエントリで、ドキュメント(設計書)の有用性について書きましたが、これはよくある話。
では、どうすれば価値のある設計書になるのかについて、もう一歩踏み込んで考えてみます。
まず、設計書とは、最終的にコードを作成するための成果物であり、価値のない設計書とは、コードを作成するのに役に立たないものだと言えるでしょう。
「顧客にレビューしてもらうため」とか「エンジニア間でコミュニケーションを取るため」といった意見もあると思いますが、それも最終的には、コードまで落とし込むための過程と考えられます。
その設計書を作成する上で、設計技法としては、以下のようなキーワードが必ずと言ってよいほど挙げられます。
- 構造化設計、DFD、ER
- オブジェクト指向設計、UML、デザインパターン
設計に関する書籍では、大抵このような設計技法を扱っているのですが、これらのものは、分析や表現に重きがあり、どうすれば良い設計になるのか、という部分には触れられないことが多いです。
私自身は、表記方法がどうであれ、設計とはソフトウェアエンジニアリングの分野であり、その原則は、この数十年変わっていないのではないかと思っています(とは言え、私自身は、ソフトウェアの開発に携わるようになってから10年にも満たないので、これまで見てきた設計書と先人の教えからの見解ですが)。
その原則とは、IPO(Input --> Process --> Output)」を決定すること。
IPOとは、システムやアプリケーションの入力データ(Input)は何で、出力データ(Output)は何かを定義し、それから、それを実現する処理(Process)を考えることです。
この内容がしっかり書かれている設計書は、見ていて分かりやすいし、上流から下流へ詳細化していきやすい。
各工程で、注目する点は以下のようなものです。
設計工程 | IPOで着目する点 |
---|---|
基本設計 | 画面の入出力 DBやファイルのデータ入出力 外部インタフェースの引数と戻り値 |
詳細設計 | コンポーネント単位の引数と戻り値 内部インタフェースの引数と戻り値 |
実装 | メソッドの引数と戻り値 |
冒頭で、「価値のない設計書とは、コードを作成するのに役に立たないもの」と書きましたが、上記の点を意識して詳細化していけば、「コードを作成するのに役に立つ設計」になると分かるのではないでしょうか。
さらに、Input/Outputがハッキリしていれば、テスト項目もあげやすいので、システム全体の品質向上に必ず繋がります。
TDD(テスト開発駆動)も、IPOをメソッドレベルで考え、それについて処理を記述するのが根本の考えにあります。
自分が設計するときも、他者が設計した内容をレビューするときも、まず、大きな視点でIPOを見るところから始めるのですが、それで、設計の良し悪しが左右されます。