システム開発において、「上流工程」が重要であることは、言うまでもないことでしょう。
要件定義が間違っていたり、いい加減であれば、その後の基本設計がスムーズに進むことはありえないからです。
だからといって、基本設計、詳細設計、プログラミング工程等のあらゆる工程において「重要でないもの」は、ありません。
今回は、プログラム詳細設計に焦点をおいて、基本設計との違いを軸に考えてみたいと思います。
SEは基本設計書を基に詳細設計書を作るわけですが、この2つのドキュメントの目的は明らかに異なります。
それは、基本設計書はお客様に確認してもらう為の設計書であり、詳細設計書は、プログラマに説明する為の設計書である、という点です。
ですから、基本設計書は、お客様が理解できる言葉で表現される、業務内容に沿って説明されたものであるべきです。
一方、詳細設計書は、SEがプログラマに指示を出す為のドキュメントとなるわけですから、むしろ業務内容の説明ではなく、そのプログラムの構成や、細かなプログラミング工程となるものです。
しかし、プログラミングをするのが人間である限り、そのプログラムが、どの画面で、どんな役割をもって使われ、誰が、いつ、どのように使うのか？といった、意味をつけて引き継ぐことが、プログラマにとって、大きな理解に繋がることは間違いありません。
プログラムがどのように使われるかもわからず、ただ、詳細設計書から読み取って、さまざまな想像をすることは、理解する為に余分な工数を使わせることだけでなく、勘違いを引き起こしたり、考えなくて良いような余分な作業を重要とみなして、コーディングしてしまったり、といったことを引き起こします。
もちろん、プログラマがそれなりのキャリアを積んでいる場合は、プログラマからSEに質問があがることでしょう。
だからといって、あがってきた質問に答えればよいという仕事の引継ぎ方法は、間違いの元となります。
詳細設計をSE同士で確認レビューを行うように、プログラマへの引継ぎも、できれば1対1ではなくて、1対2以上の関係で、引継ぎをする者と、引継ぎチェックを行う者がいることが望ましいでしょう。
詳細設計書に書いてあることを、一字一句守ってプログラミングすることは、プログラマにとっては当たり前のことです。
しかし、その詳細設計書が間違っていない、と誰が保障できるでしょうか。
人間が作っている以上、コピーしてきたものの未修正や、思い違い、うっかり、といったミスはつきものなのです。
頭ではわかっていたことが、ドキュメントとなると正確に表現できていない、というのは、ドキュメント作成者のミスだけでなく、人と人との「伝言ゲーム」的なコミュニケーション能力に起因することもあるわけです。
ありとあらゆるリスクを廃して無駄なことを省く。
その為には、一見無駄なように思われる「複数人数でのレビュー」や「ドキュメントチェック」を確実に行うことが、後々の工数の何倍もの節約になるのです。
「急がば回れ」といった諺を思い出すのは、こういうときなのです。
Vol.00129