糞システムにしないため、私ができること『はじめよう！ 要件定義』

　「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。

　詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。

　では、どうすればよいか？

　「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“決める”ことこそがおまえらの仕事だろうに。呪ったところで仕方ない、現場でできることを粛々とやろう―――だが、具体的に何を？

　それをコンパクトにまとめたのが、本書になる。もちろんマネジメントや政治といった力学はあるけれど、いち担当としてできることが、これ以上噛み砕けないほど噛み砕いて書いてある。要件定義とは何かから始まって、基本的な流れ、定義すべき内訳、ゴールからの逆算の仕方など、助走から離陸まで、「やるべきこと」と「なぜそれをするのか（しないとどうなるのか）」に絞ってまとめられている。

　たとえば、「企画を確認せよ」という。ゴールを確認するための企画書なのだが、企画書なんて見せてもらったことがないのが現実だ（あるいは、誰も読まない稟議のための分厚い束が渡されるかだ）。無いなら作れという。関係する人たちがゴールを確認するための企画書だ。何をどのように作るのか、利用する人の便益、期限と体制などが記されたペーパーでいい。これは、ソフトウェア開発だけでなく、あらゆる仕事に通用する（仕事は一人で完結しないから）。

　そして、あちこちのコラム欄で、要件定義の周辺を説明する。企画の話、マネジメントの話、と飛び火するのを堪えているのが分かる。この飛び火した先の話のほうがめっぽう面白く、机に刻んでおくべきなのだが、もし全部語ったなら、どんどん膨らんでしまうだろう。この分量におさえて、「要件定義だけ」に絞るため、泣く泣く切り上げたのだと推察する。

　いちばん刺さった（というかトラウマを呼び起こした）のは、「要件定義と業務設計を分割せよ」の件。「せっかくだからソフトウェアを活かした業務にしたい。そのためにソフトウェア側の要件がハッキリしないと行動シナリオ（業務設計）が書けない」と言ってくる客だ。

　その結果、「ソフトウェアの要件定義」という作業と、「行動シナリオの検討と設計（＝業務設計）」という作業が入り混じってしまい、作業が異様に複雑になる。「要件定義には業務知識が不可欠だ」とか本質からズレた議論が白熱し、白熱するわりに不毛な展開になる。

　これは、発注元がよく使う逃げ口上だ。自分がやってこなかった（やるとは思っていなかった）宿題の理由を、受注側に押し付ける常套句だ。受ける側は、自分の仕事のインプットとなる「一つ前の仕事」なのにね。著者は、この土俵に乗ってはいけないと警告する。ではどうするか？　分割統治せよと答える。すなわち、要件定義「の前」に行動シナリオを書くことを推奨する。

　ここは極めて重要なり。わたしの場合、「打ち合わせの時間を変える」で対処した。同じメンバ、同じ会議室なのだけど、何時から何時を第一部「行動シナリオを検討する」時間と、その後に第二部「要件定義を詰める」時間に分けるのだ。間に休憩を入れて役を変えるだけで、「今のゴールは何か」という共通認識が生まれる（お試しあれ）。

　他にも、「データベースとはシステムを越えて共有する、超グローバル変数だ」とか、「終わったはずの要件定義をやりなおしているのなら、それやった人は要らない子」など、刺さる箴言がさらりと埋め込まれている。要件定義で泣いた人なら、思い出し泣きするかもしれない。

　要件定義で泣かない子になるために、「自分が」できる全てがある。