あなたの作業で得られるプログラムが顧客要件をすべて満たしているのであれば設計書はいらなくなる

今日は所謂3.11の東日本大震災から3周年を迎える日で、それは子どもの頃の夏休みに泊りがけで遊びに行った親戚のお兄ちゃんが津波で亡くなった日でもあるんだ。亡くなったことを知ったのは少したってからでそれも人伝に教えてもらった。不幸中の幸いにもなくなった親戚は彼ひとりだと教えてもらったけれど、彼の夏に寝泊まりした家は基礎しか残っていないのも後からネットで知った。

今日は、3.11のことを書くつもりはなかったけれど、日経の私の履歴書を読んだり、ツイッターのTLなんか見ていたらなんとなくそんな気になった。でも、今朝起きて新聞を読む前までは別のキーワードが頭をよぎって「(あぁ、それで書こうか。)」なんて思っていたりしたけれど、今、なぜか“詳細設計書が熱い”のでそれについて書こうと思う気になった。

詳細設計書ってよくわからない

一行紹介を見ると、“オープンソースな世界にいたりするおじさん。”とあるので、タイトルは釣りなんだろう。それはそれでいいや。それに、今までならここで「詳細設計書とは……。」なんて表か文章で文字を書き連ねていただろなぁ。でも今日はそうしない。

作業品質と品質保証
ワタシはどちらかと言えば、今は、何が自分で必要だと思うことがあればネットや書籍でざっと概念を理解して、実際にやってみて自分の頭に入ったことと動かす手足が自分なりに一致するようになったときにそれがワタシにとって生きるモノか、そうでないか一旦評価している。その上で、さらに洗練しないとワタシ自身が想像するようなイメージで使い物にならないと思う場合、「まぁこのくらいでいいかな？」と言うレベルくらいにレベル上げすることが多い。
＃ケッコンカッコカリまで頑張ったり、やったりしないということ。

だから、プロジェクトマネージメントのスキルを学ぼうとしたとき、お作法を意識したし、経験の中でこれは良いパターンだと思えばそれを自分の腹の中にとりあえず飲み込んでおいて、いつでも引っ張り出せるようにはしておいた。その中に、作業標準と品質管理があった。

この2つの作業標準と品質管理の考えと実践方法は、ワタシにとってとても強力な思考の作用をしているのではないかと思う。それは、プロジェクトを計画どおりにキャリーするにはどちらも必要なことだと思っているし、物事を考えるときの体幹の一つになっていると感じるからだ。

詳細設計書なんてどうでもいい
実のところ、詳細設計書なんてどうでもいいと思っている。誤解を受けそうなのでその真意を述べると、顧客が実現したい要件をプログラムやパラメータに展開する実現仕様を表現できる表現方法があって、それをキャリーするプロジェクトチームとステークホルダーが共通理解できるのであればそれで十分だ、と言う意味だ。

顧客の要件は実に定性的である。一方、プログラムもパラメータも定量的である。その定性的な要件を定量的なプログラムやパラメータに変換しなければならない。その変換までの思考のプロセスを表現できればいいのである。それを最終的に表現しているのが詳細設計書なら必要だろうし、他の表現方法、例えばUMLで十分表現できるのであればそれでいい。ましてや、そうした変換することの必要のない要件なのであれば、それ自体不要としてよい。

詰まる所、後続するプログラミングやパラメータ設定に必要な情報を網羅しているのか、と言うことさえ確認できるオブジェクトがあればいいのだ、と思う。それを詳細設計書なんてどうでもよいと表現しているにすぎない。

作業品質
基本設計書なり詳細設計書なりクラス図なりで表現する対象は顧客から任された実現したいことの何を実装するかその仕様を示すものなのである。それは実装するまでの間必要なもので、実装する作業が必要な作業で正しいことであることを唯一示す拠り所なのである。

その作業が必要なことであり、その作業の結果が顧客が必要としている要件の実現のための作業であり、その作業のアウトプットは顧客が欲する要件を満たしているという証左でなければならない。それが担保されて初めて作業品質が確保されていると言えるのである。

その作業品質を満たす手段はそれを遂行するプロジェクトチームとステークホルダーが同じテーブルについて共有し、理解出来るモノであればなんであろうと問わないし問われる筋合いの無いものである。それを決めるのはプロジェクトチームとステークホルダーであり第三者がどうのこうの言う筋合いでない。

もし仮に第三者がつべこべ言うのであれば、その者が言うものの表現方法を読み替えさせればよい。大切なことは、そこで実施される作業が何によってトレースできるかどうかということである。

品質管理
品質管理というと、エンジニアが引くキーワードだと思う。これは、それを推進する側が警察でプログラムやパラメータを実装する側が追われる立場になってしまう関係性をイメージしてしまうからだと思う。でも、これは間違っていると思う。

品質管理とは、顧客の要件を実現仕様で決めたように実装されているかを確認する検証の場なのである。作業品質では顧客の要件どおりに実現仕様に則って実装するし、その実装したアウトプットが顧客の要件を満たしていることを保証するのである。

それをエンジニアは自分が設計した実現仕様のまま試験仕様書を書き、実装したプログラムやパラメータで追試するから間違うのである。本来、顧客の要件を満たしているか、で検証しなければならない。その上、実現仕様自体が顧客要件を満たしていないことからそれを充足していない個所を発見する活動になるため、品質管理はあらさがしに見えるのである。

先の作業品質で顧客の要件が実現仕様で充足されていることをトレースでき、そのとおりに実装されているとすることが作業品質として担保されているとするなら、試験工程では顧客の要件が設計した分だけ実装されていることを確認するだけで終わるのである。それこそ、顧客が欲する要件を満たしていることを証明することなのであり、これは最小限の作業工数で実現されるのである。

ところが、作業品質自体が担保されない実装であれば、本来100ないといけないところがそれに満たないまま試験工程に突入しているだけであり、試験工程での品質管理の名のもと不良探しをして、それを逐次補充する場当たり的な作業となるため警察に追われる心持ちになるのである。

だから、作業標準は必要なのであるし、品質管理をしなければならなくなるのである。エンジニアはそれをまだわかっていない。