要件定義で失敗すると、プロジェクトはあっという間に炎上する。
上記の記事でも述べているが、その原因は修正コストの大きさだ。システムが市場に出た後で要件レベルの不具合を直そうとした場合、要件修正時に比べて200倍のコストがかかる。具体的な金額で考えると、要件定義時に1万円で済んだ変更が、200万円かかるようになるのだ。機能を新規追加する場合は、大した問題にならない。やっかいなのは、変更や削除だ。すでに動いているシステムをデグレードさせるわけにはいかないため、変更箇所や削除箇所の影響範囲を丁寧に調査する必要がある。改修完了後も、本当にデグレードしていないかを確認する必要がある。やることがいっぱいあるのだ。
このような変更は、関係者全員が不幸になる。顧客側は追加費用に頭を悩ますし、受注側は金銭面で負担はないものの、納期に追われる。納期は「なるはや」だ。しかも、絶対に失敗できない。確実、かつ、なるはやで対処するために、残業は増え、開発者は疲弊する。
筆者は、このような不幸な現場が少しでもなくなれば良いと思っている。そのためにこのようなブログを立ち上げて、自分なりに得てきた知見を伝えるようにしている。今回は、要件定義者に求められる能力を整理したい。
要件定義者に求められる能力
そもそも、要件定義者に求められる能力とは何であろうか。筆者は下記3点が必要と考える。
- 課題定義力
- 文章作成力
- 対人コミュニケーション力
課題定義力について
システムとは、顧客の課題を解決するために存在する。課題がないなら、システムを作る必要はない。課題があるから、システムを作るのだ。課題を解決するために、システムに対する要件を定義する。ゆえに、要件を定義するためには、課題の定義が最優先なのである。課題を定義するためには、、、話が長くなるので、別の機会で説明することとする。課題を定義しなければシステム開発は前に進まないし、この課題定義力というのは、非常に重要な能力である。
文章作成力について
システム開発というのは、共同作業だ。人が集まって作業が行われる。口頭で説明して、みんながそれを記憶し、解釈の相違なく仕事を進められれば、問題は起きない。
実際はそんなうまくいかない。口で説明されてもすぐに理解できないし、一度言われたことなんて、みんなしょっちゅう忘れる。だからこそ、ドキュメントが必要なのだ。そのドキュメントの中でも、最も参照されるのが要件定義書だ。
要件定義書を起点として、色々な議論が行われる。要件定義書の内容があいまいだと、まず、要件定義書を解釈する作業から始まる。設計者は苦労して内容を解釈し、要件定義書を書いた者にＱＡ表を投げる。そのQA表は後生大事に保管される。また別の者も個別に質問する。その回答も、後生大事に保管される。
誰しもが理解容易な要件定義書を書けば、こんな無駄プロセスは必要ない。だからこそ、文章作成能力は必要なのだ。
対人コミュニケーション力について
そもそも、システムを開発したいと思っているユーザーの大半は素人だ。そして、なんとなくシステムを開発したいと思っている。要は、課題すら明確でない場合が多いのである。そんなところに乗り込んで、課題を明確化しましょうなんて言いだしたら、なんかめんどくさいやつだなと思われるし、基本対面での会話ベースになるので、相手を怒らせてしまったら、重要な課題発見ができなくなってしまう。相手を怒らせない程度のコミュニケーション力は必要なのである。
もちろん、上記3点以外に必要な能力はたくさんあると思う。この3点を取り上げた理由は、この3点を使うと、筆者がこれまで出会った人たちをうまいこと分類できるためである。
要件定義者として欲しい人材
要件定義者に求められる能力として、3点の能力をベン図で表現した。ベン図上には、①から⑧までの番号を振った。3点の能力のあるなしにより、①～⑧に分類される。
- ①：課題定義力あり、文章作成力あり、対人コミュニケーション力あり
- ②：課題定義力あり、文章作成力あり、対人コミュニケーション力なし
- ③：課題定義力あり、文章作成力なし、対人コミュニケーション力あり
- ④：課題定義力あり、文章作成力なし、対人コミュニケーション力なし
- ⑤：課題定義力なし、文章作成力あり、対人コミュニケーション力あり
- ⑥：課題定義力なし、文章作成力あり、対人コミュニケーション力なし
- ⑦：課題定義力なし、文章作成力なし、対人コミュニケーション力あり
- ⑧：課題定義力なし、文章作成力なし、対人コミュニケーション力なし
①について
この中で欲しい人材といえば、もちろん①だ。要件定義書の骨子を手渡し、「要件定義やっといて」と言うだけで、自発的に情報を収集し、立派な要件定義書を作成してくれる。いわゆる戦略系コンサルの人たちは、こんな人たちなのかもしれない。
②について
次に欲しい人材は、②だ。課題を明確化し、それを文章に落とし込めるということで、まっとうな仕事ができている。ただ、コミュニケーション力の程度によっては、顧客を怒らせるかもしれないので、コミュニケーションのできる者をバディに据えておくべきだ。
③について
その次に欲しい人材は、③だ。コミュニケーション力を武器にして、顧客と共に課題を明確化できるところまでは良い。が、その後に作成した要件定義書がグダグダだと、後工程が割を食う。QAは多発する。こういう人が担当の場合は、要件定義書のレビュー体制を強化し、当人をサポートしていくべきだ。
④⑤⑥⑦⑧について
その次に欲しい人材は、、、いない。要件定義担当としてやっていくのは難しいのではないかと思われる。
タイプ別に説明する。
④について
いわゆる社内評論家だ。理想論を論ずる(課題を定義する)能力はあるが、文章も作成できないし、コミュニケーション力もない。自ら動かず、遠巻きから理想論を言うだけである。要件定義担当としては向いていないと思う。
⑤について
一見このタイプは約に立ちそうだが、要件定義という観点で見れば、失格である。コミュニケーション力と文章作成力を武器に、読ませる文章を書くのだが、いかんせん、顧客が思ってることを伝えるだけのメッセンジャーになってしまう。真の課題が何かを突き詰めることができないので、終盤になって要件が覆る可能性がある。このタイプは、ある意味で一番厄介な存在かもしれない。
⑥について
課題定義力がないので要件が覆る可能性がある。
文章作成力はあるので、ポエムを披露してもらうとよい。
⑦について
課題定義力がないので要件が覆る可能性がある。
面白い人なら、ムードメーカーとしていてくれるとよい。
⑧について
要件定義書の担当をさせてはいけない。
この記事を通して伝えたいこと
３つの能力について説明したが、技術に関する項目が入っていないことに注目していただきたい。要件定義が難しいと言われる所以は、要件を定義する前段階においては、システムに関する技術が必要ないためだ。システムに詳しいエンジニアが、のこのこと出向いても、システムが解決すべき課題をしっかり定義できず、要件定義をしっかりできないという事態がありうるのだ。
システムを作るために必要な能力は、まずは課題定義力なのである。そして、課題定義は、難しい。あるべき姿と現状が、顧客によってばらばらなためだ。過去知見があまり役に立たず、プロジェクトのたびに、地道な現状把握作業を強いられる。
それでも、システム開発を成功させるためには、課題定義力を磨かないといけない。課題定義力については、思考訓練を続けることで習得できるはずだ。文章作成力についても、適切な日本語を書く訓練をすることで習得できるはずだ。この2つは、論文を作成する際に必要な能力であるため、ある程度の偏差値の大学を出た理系の院生ならば、この2つの能力を最初から備えているはずである。コミュニケーション力については、何も、明るい楽しい人になれと言っているわけではない。なるべく相手に敬意を持つようにして、相手がどう思うか考え、最低限の失礼のない会話ができれば良い。
