【ソフトウェア開発】設計書に混在する管理資料

従来、設計書や設計図というものは、「製品を作るため」と言う目的に則して作成されるものであるはずです。ですが、設計書の中に、なぜか「製品を作るため」と言う目的とは関係ないものがまぎれている場合があります。

設計書を大量に作成すると、よく目にするのが「〇〇一覧」と言う資料。

　• 画面一覧
　• 帳票一覧
　• テーブル一覧
　• 機能一覧
　• 業務一覧　etc...

これら一覧文書の大半において製品品質を保証するために求められる「目的」はというと、

　まったくありません（キッパリ）

むしろ、中途半端にドキュメント間のつながり（リレーション）を持っているだけに、ドキュメント間の結合度を上げてしまって作成負担のみならず、更新頻度や更新負担、更新の抜け漏れ発生率上昇などに起因しやすくなり、プロジェクトリスクを高める可能性が出てきます。

だからと言って、他の観点においても「まったくの無意味か？」と言うとそうでもありません。

少々規模が大きくなってくると、全体の管理が困難になってきます。そのための管理資料として一覧があるのは、いわば名簿のようなものでマネージャーや受入検査をするユーザー側としては大変重宝します（更新の抜け漏れが無ければ）。

けれども、開発を行うエンジニアにとっては、ほぼ恩恵がありません。

なぜなら、「製品を作るため」のドキュメントではないからです。つまり、deliverable な成果物では無いと言うことです。

だから、製品品質には何１つ影響を与えないくせに、新しい機能を作成したり、既存の機能を削除したりした際に、毎回毎回一覧の更新も必要になるのが、ひどく面倒になるのです。ついつい反映を忘れてしまったりすると、後々ＱＡ担当者にダメ出しされたり、受入検査で指摘されたり…と、直接製品の品質に関係の無いところで、無駄に工数を使うことになります。しかも、他の品質まで無用に疑われ、その調査や、他には問題が無いことの証明をするだけで一苦労です。

先にも書きましたが、「管理」を目的とした資料には、製品の品質には直接的な影響を与えることはほとんどありません。

なぜか？

一覧に記載されている名称、内容のほぼ全てが、個別の設計書にも記載されており、そちらの設計書に具体的な内容を書いているため、一覧側が参照されることは殆ど無いからです。

　• 画面一覧　　　　　→　画面設計書
　• 帳票一覧　　　　　→　帳票設計書
　• テーブル一覧　　　→　テーブル定義書
　• 機能一覧　　　　　→　機能定義書
　• 業務一覧　　　　　→　業務フロー図　etc...

ただ機能名や画面面を羅列しているだけの一覧であれば、各設計書と二重管理となってしまって変更が面倒なうえに、反映漏れ等があるとバグの温床としかならず、むしろそこにあるだけで問題の種にしかならないケースが多々見受けられます。

ちなみに、ＩＰＡ（独立行政法人 情報処理推進機構）で公開されている"発注者ビューガイドライン"では、次のように書かれています。

このパターン２のように、エンジニアそのものではなく、マネージャーやユーザーの管理情報およびその母体として利用されることが前提となっています。

ちなみに、パターン１を目的として作られるようなケースを私はほとんど見たことがありません。極稀に見かけはしますが、そういう資料はExcelで横長に作られていて、まず間違いなく画面内に収まらず、また印刷できるほどの幅に収まらず、大きく横スクロールさせる必要があります。

　「俯瞰してみることができなくなる」

これだけで、エンジニアの作業品質に大きく支障をきたす可能性が上昇します。ＱＡなどの確認者がいて、最終品質を高めることができても、ＱＡの指摘が増えるような事態を招くことは、手戻り工数を増大させるだけであり、スケジュールの破たん、あるいはエンジニアの稼働向上を意味します。

実際の場合、マネージャーが成果物単位でのＷＢＳをきちんと作っていれば、管理資料としての一覧など、ほとんど必要になるケースはありません。ですが、あえてこれら一覧文書にメリットがあるとしたら、納品前や確認時の員数チェックする際に利用できる…くらいでしょうか。

マネージャーにとっては自身の確認作業が楽になるための「管理資料」になるとは言え、無いと管理しづらいというのであれば「なくてもいい」とは言いませんが、これを開発成果物の中に加え、エンジニアたちに作成、更新等を丸投げするのはいかがなものかと思います。

エンジニアにとっての開発進行上のメリットが全く無い以上、その反面として次のようなデメリットが生じます。

• 限られた期間に意味のない作業工数が発生し、スケジュールを圧迫する
• スケジュールが圧迫されると、自ずと設計品質が低下する
• レビュー、修正対象とされると、手戻り工数が増大し、コストを圧迫する

こうしてデメリットを並べてみると、ホント「誰得！？」と言うドキュメントのようにしか見えません。

どうしても必要とする場合には、エンジニアたちにとって「あってよかった！」とその一覧文書に対して言えるような存在意義（意味）を与えるようにするべきだと思います。少なくとも、

• 以前はこれで問題なかった
• お客様がそう言ったから
• 一般的には必要らしいから

と言った「考えることを止めてしまった」ような理由で盲目的に作成する（させる）のは、スケジュール対効果やコスト対効果を一切検討していない時点で、プロジェクトマネジメントとしては悪手になるのではないでしょうか。