冒頭で要件定義に参加するのはこれが始めて——と申し上げたが、それ以前にある簡易ヒアリングには参加したことがある。これは見積のために行うもので、要件定義ほど細かい粒度ではないにせよユーザ部の要望を伺う機会であった。この中で当たり前だけど大切にしたいことがあったので、本書の学びと併せて記述しておきたいと思う。
要件を合意させるには、当たり前のことだが相手と自分たちの目指しているものが一致していることを確認する必要がある。このために会議を開催するのが一般的かと思うが、そこで提示する資料はどのタイミングでユーザ部に見せているだろうか。SIerは多忙であることが多い。そのため資料作成に時間がかかってしまい、説明資料をその場で提示することも多々あるだろう。しかし、これはいけない。目指しているものを一致させたいのであれば、意識のズレを明確にして誤差を埋める時間が必要だ。そのためには資料を事前送付して相手に納得いかない部分を掘ってもらう時間を設けるべきだと思う。その事前送付の際にこちらから明確にしておきたいことをQAリストのような形で提示できればそれも合意形成の手助けになるに違いない。
次にヒアリング方法について以下二点の違いを理解しておく必要がある。①縦型反復質問、②横型反復質問である。①は、相手の言っていることや事象に対して原因や目的などを深く質問していくものだ。②は、他にも同様のことが当てはまるものはないか検討するための質問方法だ。ロジカルシンキングの考え方の応用で過去にも考える機会はあった。
bookyomukoto.hatenablog.com
ヒアリングは単に自分の聞きたいことを直接的に言葉にして尋ねればいいものではない。自分が欲している回答を得るためにどうすればいいのか工夫して質問することが大切なのだ。最後に会議をクロージングするときにはこうやって得た見解をお互いが正しく認識しているか確認しよう。思考の整理にもなってよいだろう。
最後に本書購入の目的であった既存システム改善の5つのステップを簡単にまとめたい。
①要望の受付——フォーマットに要望を書かせる——これはどのようなシステムでも取り入れているのでは? 開発候補一覧のようなかたちで私は取り入れている。開発の目的や背景が簡単に整理されていたり、優先度がわかりやすかったりするとその後が楽になるだろう。
②要望の目的をつかむ——。改善内容について書くのはもちろんのこと、その機能改善によって解決される課題や期待される効果をまとめよう。一体何をするための開発項目なのかを理解しないと改悪してしまう可能性だったあるからだ。また実施条件も確認しておくことで手戻りが発生しないようにしよう。本書ではそのためのフォーマットも用意していた。
③代替案や充足案を検討——。代替案は、依頼された改善要望よりも費用対効果の高い施策が他にないか検討するものである。開発側としては受注することが全てなのかもしれないが、ユーザ部としては利益になることが全てである。そのための提案をすることを躊躇ってはいけない。もちろん他の方法での機能改善があるのであればそれを提案しよう。そして、充足案とは要望の効果や実現性を高めるために依頼された要望と同時に実施すべき施策のことである。これらを与えられた実施条件の中で実現できるかを確認するのだ。
④実施可否や優先順位を判断——。最初の段階で簡単な優先順位づけができていると楽なのはこのためだ。限られた資金の中で開発を行うのでいくつかの案の中から費用対効果の高いと判断されたものを開発しなければならない。そのために「重要性」「緊急性」「実現性」「コスト」の四つの観点で点数化するのがよいだろう。
⑤修正する成果物で後続工程を決める——。ここからは後続工程への引継ぎだ。必要なドキュメント修正をもとに開発を行おう。
これらはとても基礎的なことなのだが、一方で忘れがちになってしまうことでもある。標準化された要件定義の方法をもとに自分たちのアレンジを加えながら効率的な要件定義が実現できるように健闘したい。
○読後のおすすめ
bookyomukoto.hatenablog.com