ビジネス書にしろ仕事術の本にしろ、多くの本は勝者バイアスにかかっているように感じる。ようは俺はこのようにしたからうまく言った、この一流企業が実践してるからこれはよい手法である、というように。「HARD FACTS」で批判されているように、それらのことはあるコンテキストでは正しいこともあるが、幅広く適用できるようなものではない。
どの本が勝者バイアスに打ち勝っているか判断するのは難しいが、著者の姿勢が分析的であるか、というのはひとつの基準だろう。今日、紹介する「はじめよう! 要件定義 ~ビギナーからベテランまで」の著者、羽生章洋さんはIT系ではその豊富な知識でシステム開発を分析的に換骨奪胎して本質を語れる稀有な人物である。
システム開発業界は昔から「アジャイル」やら「ドメイン駆動設計」やら「ユースケース」やら「自動生成」やら舶来のバズワードで盛り上がり、それができればシステム開発はうまくいく、かのような幻想がしばしば振りまかれる。実際にプロジェクトを行っている側から見れば、そんなものは革新でも本質でもなく、ただでさえ混沌とした現場にさらなる混乱を追加するだけ、と感じることも多い（設計を楽にするための「ドメイン駆動設計」が理解が難しいと言うなら、本末転倒ではないだろうか）。
それに対し、「はじめよう! 要件定義 ~ビギナーからベテランまで」は、私のいままでの経験にも合致する「本質」と思われることがコンパクトにつまった本だ。一見すると、まるで当たり前のことがたくさん書かれていると思うかもしれないし、UMLやドメイン分析といった新しめの概念もまったくでてこない、しかし本質とはむしろそういうものだ。
例えば、この本では、要件として何を決めればいいのか、として
要件として何を定めればよいのか。これを考えるときに重要なのは「ゴールから逆算する」ということです。
と述べる。そして、ソフトウェアを完成させるためのゴールとは何か、それはUI、機能、データだという結論をくだす。ここで重要なのは、UI、機能、データを決めることが結論ではなく、「ゴールから逆算する」という本質が書かれていることだ。
いくつかのプロジェクトに実際に関わってみて、この「ゴールから逆算する」がいかに重要か本当に実感する。企画をした人、要件を出した人、設計する人、開発する人、しばしば誰もゴールを想定していないことがいかに多いか。企画するにしろ設計するにしろ悩まなければならないことはたくさんあるけれども、ゴールが決まっていれば、無駄な思考や作業は最小限に抑えられるし、関係者全員が楽になる。もし偉い人がそれを決められなくとも、これをやればプロジェクトは終了できるはずだ、という落とし所を各担当者がもっていれば、そうそう変なことにはならない。どう考えても、これはプロジェクトへのアジャイル導入よりも重要なことだと思いませんか？
コラムであるものの企画の良し悪しについて書かれた部分も秀逸だ。
企画の良し悪しの差はどこに起因するのか。それは「利用者便益（ベネフィット）の観点から精査されているかどうか」です。
システム開発を受注する開発会社にとっては、お金さえ貰えれば企画なんてどうでもいいではないかと思うかもしれないが、それは違う。変な企画はしばしばプロジェクトを迷走させるし、リリース後に大トラブルを招くこともある。お客の立場でも、あのシステムが成功したから次も発注しようと思うのであって、あのシステム誰も使ってないけど不具合は少なかったのであの会社に発注しよう、ということにはならない。
たいてい実務には役にたたない経済学ではあるものの、需要がなければ供給できない、という考えは仕事にも役に立つ。この場合、利用者便益というのはまさに需要に他ならない。しばしば「ニーズからシーズへ」というキーワード先行で需要を生み出せばいいのだ、と意味不明なことを語る人がいるのだが、おおむね潜在的な需要があったことが解決策の開発で明らかになっただけで、そもそも需要がなければ意味がない。それ以上に、シーズが見つかる状況というのはほとんど偶然だ。ベンチャー企業でもない限り、そんなあやふやな根拠でシステム開発などしてはならない。
一方で経験を踏まえたアドバイスにも余念がないのが本書の素晴らしいところ。
上流工程と実装とは別物であるから、実装技術を決めなくても要件を定義することはできるという意見もありますが、ではそこでいう要件とは具体的にはいったい何なのか、それを決めることで後工程に何を送るのか、ということを曖昧にしたままもっともらしい言葉で誤魔化すのは、プロジェクトに火種を持ち込むだけです。
拍手喝采。実際、コンサル主導のプロジェクトはこういうことになりがちだし、先日の新国立競技場問題にも繋がる話であるように思う。しばしば、それを実現したらいったいいくらかかるのかよく考えずに夢のようなプロジェクト企画書を作り上げ、実装のことはよくわからないのでとシステム会社に丸投げして大失敗というのが十数年前によく見られた光景である（なお、さすがに客もシステム会社も懲りたのか、コンサル会社に最後まで責任持たせるなどして、そのようなひどい事例は減っているらしいとは聞いている）。
今の時代、開発内容に対し費用と期間が妥当ならば、システム開発自体が失敗することはほぼない。しかし、実装技術が決まらなければ、開発内容は決まらず、妥当な費用、期間が決まらないことになる。これではプロジェクトがトラブるのも必然だろう。
個人的には、「全体像を描こう」を章がツボだった。画面遷移図を書かずに開発を始めるプロジェクトがいかに多いことか。全体像をつかむことはゴールを思い描くことでもある。
逆にちょっと違和感を覚えるのは、業務フロー（＝利用者の行動シナリオ）が助走工程に位置づけられていることだ。要求一覧を決める以上、新旧業務フローは平行して作るようなものなのではないだろうか。要求があるのは前提と言いながら、なかなか白紙から出てくるものではない気もする。業務フローを確認しながら要求を書き出していく方が自然ではないだろうか。
また、導入すべきか躊躇するのが画面項目ベースのラフスケッチだ。作れればそれに越したことはないとは思うものの、この手の図は作るとやたらと大きくなってしまい管理に困る気がする。私の場合は、PowerPointなどで本物のUIに近い画面モックと吹き出しによる動作記述が書かれた画面概要図みたいな資料を作ることが多い。たしかに、この本に書かれているような項目とその遷移がわかる方が処理が明確になりやすいとは思うものの、客との打ち合わせで使うには記述的すぎる気がする。
後半、ちょっと不満も書いてしまったが、要件定義の「本質」とノウハウがコンパクトにまとめられた優れた本である。細かいことばかり書かれていて読んだ後、何も残らないプロジェクト管理本にあきあきしている人に是非進めたい一冊だ。
