ヒアリングは単に自分の聞きたいことを直接的に言葉にして尋ねればいいものではない。自分が欲している回答を得るためにどうすればいいのか工夫して質問することが大切なのだ。最後に会議をクロージングするときにはこうやって得た見解をお互いが正しく認識しているか確認しよう。思考の整理にもなってよいだろう。
最後に本書購入の目的であった既存システム改善の５つのステップを簡単にまとめたい。
①要望の受付——フォーマットに要望を書かせる——これはどのようなシステムでも取り入れているのでは？ 開発候補一覧のようなかたちで私は取り入れている。開発の目的や背景が簡単に整理されていたり、優先度がわかりやすかったりするとその後が楽になるだろう。
②要望の目的をつかむ——。改善内容について書くのはもちろんのこと、その機能改善によって解決される課題や期待される効果をまとめよう。一体何をするための開発項目なのかを理解しないと改悪してしまう可能性だったあるからだ。また実施条件も確認しておくことで手戻りが発生しないようにしよう。本書ではそのためのフォーマットも用意していた。
③代替案や充足案を検討——。代替案は、依頼された改善要望よりも費用対効果の高い施策が他にないか検討するものである。開発側としては受注することが全てなのかもしれないが、ユーザ部としては利益になることが全てである。そのための提案をすることを躊躇ってはいけない。もちろん他の方法での機能改善があるのであればそれを提案しよう。そして、充足案とは要望の効果や実現性を高めるために依頼された要望と同時に実施すべき施策のことである。これらを与えられた実施条件の中で実現できるかを確認するのだ。
④実施可否や優先順位を判断——。最初の段階で簡単な優先順位づけができていると楽なのはこのためだ。限られた資金の中で開発を行うのでいくつかの案の中から費用対効果の高いと判断されたものを開発しなければならない。そのために「重要性」「緊急性」「実現性」「コスト」の四つの観点で点数化するのがよいだろう。
⑤修正する成果物で後続工程を決める——。ここからは後続工程への引継ぎだ。必要なドキュメント修正をもとに開発を行おう。
これらはとても基礎的なことなのだが、一方で忘れがちになってしまうことでもある。標準化された要件定義の方法をもとに自分たちのアレンジを加えながら効率的な要件定義が実現できるように健闘したい。
○読後のおすすめ