2014-03-09

■[on]設計書が死に体 なのは、関わるエンジニアが誰ひとりそのドキュメントを作る目的を理解せずにしくみを設計し利用しているからである 09:08

詳細設計書も問題だけど、それ以上に成果物定義が問題

詳細設計書という名のゴミ

まとめ

どんなシステム開発方法を採用しても、どんな工程やスプリントにしても、顧客に届けるためのアウトプットにつなげるための文書が必要ならその文書は何をインプットにして、どんな情報を付加して、どんな形にして使うのかを決めて、プロジェクトの中で目的を理解すればいいだけ、なんだよ。

その工程は何のために作業するか誰も理解していない

ウォーターフォールが嫌いとか、アジャイルなんてとかは食わず嫌いもいいところでそんな物言いをする人には「その嫌いな手法を学んで一人で出来る程度には習得しているんだよね？」と問いたいものだ。同じように、工程に相対するアウトプットに嫌悪感を持つエンジニアには、その工程であなた自身が介在し加工して付加価値を付けた上で次工程に送っているのかどうかを訊きたい。

とても単純なことで、情報を取り入れて、加工しないと顧客が使用するシステムにたどり着けないのだからそういう段取を踏んでいるだけなのだ。極端なことを言えば、顧客の業務要件という“お金を払ってまでやりたいこと”を聴いただけで「あぁ、これですね。」と使えるシステムがデリバリ出来るならそれはシステムインテグレートするようなものではなくパッケージでもWebサービスの類だ。カタログから顧客が自分で選んで買って使えばいい。そうじゃないんだろう。顧客は自分好みで実現したいからわざわざ高いお金を払って実現しようとするんだから。

アジャイルだってドキュメントをアウトプットするのだ

アジャイルは使えるシステムを届けることを「はじめに考えるんだ。」と言う件のアジャイルマニフェストを誤解して「ドキュメントを作らなくていいんだ。」というのは「勘違いだ。」とその界隈の先駆者達が言っているのをよく聞くようになったのは2013年くらいだ。彼らは言っていた。「アジャイル開発だって顧客がスポンサーなんだよ。顧客が望めばドキュメントを作る。」と。嫌々ではない。それがビジネスにとって必要だからと理解しているからそこまで言えるんだ、と思う。本当に不要なものならそれは個別で相談しているさ。使われないものまで「お金を払って作りますか。」と。「その分、実装する機能を増やしませんか。」と。アジャイルはもう10年を超えたがまだ新興なのだ。実績が必要なんだ。その観点を分かっている人から見れば、必要のないアウトプットを作るくらいなら機能を実装して彼ら流の言い方をすれば“ベロシティ”を上げたいんだ。それがウォーターフォールに勝つためであり、実際実装したシステムの機能を見せるのが顧客にとって認めやすいからだ。

ドキュメントを必要としているのは誰か

アジャイルに限らず、ウォーターフォールであっても同じなんだとそろそろ気づいて欲しい。顧客からみたらシステムを実現するエンジニアが顧客である自分の要件を実装するまでのドキュメントなんてない方が良いのだ。その分、早く、安く使えるのだから。多段階の工程を経てアウトプットを産出するということはエンジニアサイドがそうしないとシステム化できないからなんだよ。

多分、システムエンジニアとプログラマとコーダの仕事を職種という肩書き上、システムエンジニアを名乗らされている技術者が全部やっているから話がおかしくなるんじゃないか、と思う。同じシステムエンジニアであるのに、担当する工程が違うだけで仕事の内容が正にプログラム仕様書からコードに変換するというコーダの仕事になるし、単機能工とみなされるから単価も安いのだ。

システム開発というしくみの設計と利用者でしかないエンジニア

システムの開発を助けるツールを揃え、そのプロジェクトで使えるように調整し、使って生産できるならそれはエンジニアリングなのである。設備を整え、その設備を回す人的リソースを供給し、そして生産する。そこには単機能しかない。

以前、エンジニアにはマルチロールを担える多機能工とこれしかできませんという単機能工の2種類のエンジニアがいると書き記した。単機能工のエンジニアはその分野しか見ようとしないし理解しようとしない。大体、それしかできないので視点が単視点しか持ち合わせていないし“なぜ、そのようなしくみ”になっているか多面的に思考ができないのだ。

話を逸らすが、ここでは用意されているアナタのプロジェクトでのシステム開発手法や工程やその工程で制作されるアウトプットがその顧客が望むシステムに最善なのかどうかまでは判別しないし言及しない。ただ、多くのプロジェクトの中間生産物であるドキュメントを見てきた経験から言えば、なんとなくこれまで作ってきたから「今回も作るよ！」であって、そのドキュメントがなぜ必要か、そのドキュメントの様式はなぜその項目なのか、他の設計ツールで出力できるアウトプットで代用できないのか、など、検討なんてしていない。残念ながら。

結局、設計工程や試験工程ごとにドキュメントを作成するということは、システム開発をエンジニアリングに見立てているからであり、その実現のためのしくみ作りの具現化されたものなのである。

それが、その実装されたシステム開発のしくみが、実際に現場で使うエンジニアから「意味が解らん。」とか「何のために作っているの？」とか「使いにくい。」とかクレームが上がってくるとしたら、そのしくみを設計したエンジニアから利用するエンジニアへの説明不足かしくみを設計する力量不足なんだ。説明が足らないなら、いや、設計したしくみで補足が必要な時点で設計不良なのだが、足らないなら足らないで実施要領なり利用ガイドを用意しなければならない。それがしくみを作る側の責務なのだから。それもせず、現場から文句を言われ「アイツら使えねー。」と言っているようなら使えないのはそのしくみを設計したエンジニア自身だ。これもこういった状況になっているならそのしくみを設計したエンジニアが気づくことはないのだ。

ただ、それも仕方がない。設計したエンジニアを擁護するつもりは微塵もないが、そうしたしくみを設計する経験をする場が限られるから。実際のプロジェクトの中で、その工程で必要なアウトプットとしくみはその工程に入ってからあわてて建てつけることばかりだから。本当も糞もないけれど、使う工程の前にしくみを設計して先行して試さないといけないのだ。現実はそうはいかなくて、必要なときを過ぎてから、しくみを設計もしたことがないエンジニアがしくみを作っているのだから上手くできるはずがない。