要件定義って何をすればいいの?
ヒアリングの進め方が分からない
何をヒアリングすればいいの?
直ぐに使えるヒアリングフォーマット教えて
と言った疑問に答えます。
この記事を読むことで、要件定義書を書く上で、必要なヒアリングをマスターする事が出来ます。
・記事前半:要件定義とヒアリングの関係性
要件定義の進め方
・記事後半:要件定義のヒアリングとは?進め方や項目等
ヒアリングシートサンプル紹介
といった流れで解説していきます。
✔記事の信ぴょう性
SIer SE→現、一部上場企業社内SE(IT歴15年以上)。基幹システム開発、及び、グローバル16拠点への導入やSCM・MDM等システム開発。社内SEの情報サイトIT Comp@ss運営者。「社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール」著者。
本記事は、以下の社内SE基礎講座の「要件定義ヒアリングのコツ」の記事です。
IT初心者・社内SE向け|システム開発の【基礎講座】関連記事一覧
起案・立上げフェーズ
システム開発とは?
システム開発の用語と選択肢
IT人材を取り巻く概況
システム開発の全体の流れ・工程
システム開発の体制図・役割分担
システム開発の成果物・ドキュメント
システム開発が学べる本22冊
システム開発の契約の種類
WBSの書き方とコツ
プロジェクトマネージメント
構築フェーズ
要件定義
システム要件定義の目的・進め方
要件定義の書き方・テンプレート
要件定義ヒアリングのコツ
要件をユーザー視点でヒアリング
業務フロー作成の書き方
要件定義の失敗を学び回避
要件FIX
PoC
PoCとは?進め方やコツ
PoC の読み方
PoC失敗事例
PoCの失敗回避するチェックリスト
システム開発ーテスト
システム開発のテスト全体像
機能一覧の書き方のコツ
システムテストで抑えるべき観点・項目
リリース・運用
システム移行計画のリスクと抑えておくべきポイント
要件定義とヒアリングの関係性
要件定義のヒアリングの関係性に関して以下の観点を解説していきます。
要件定義と要求定義の違い
ヒアリングを通しユーザーが本当に求める物を特定する
要件定義のヒアリングでよく発生する認識齟齬
ヒアリングで正しい情報を吸い上げる
ヒアリングの時に意識すべき事
要件定義と要求定義の違い
要件は要求を元に作ります。業務や事業側の何をしたいか、何をシステムに求めるのかをヒアリングしそのインプットを元に要件を形作っていきます。もし、業務や事業が全ての要求を完全に洗い出し文章化している場合、ヒアリングは必要なくすぐに要求から要件を確定していく作業に移ることができます。しかし、そんなことは私の経験上発生したことはありません。
ヒアリングを通しユーザーが本当に求める物を特定する
どんなプロジェクトでも、ユーザーの要求は得てして曖昧です。どちらかというと、ユーザーもヒアリングやディスカッションを通して何が本当にしたい事か発見していきます。その為、要件定義を進める為に、既にある文章からユーザー要望を理解する事に加え、ヒアリングで必要な情報を引き出す事が重要になってきます。
要件定義のヒアリングでよく発生する認識齟齬
要件定義で必要な正しい情報収集の大切さと難しさは、オレゴン大学で行われた実験結果【顧客が本当に必要だったもの】の風刺画で理解できます(以下図)。
社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール
顧客が要望した依頼の絵はには座る場所が3つあるブランコです(左上)。プロジェクトリーダー、アナリスト、プログラマー等同じ要件の解釈にもかかわらず描かれたイメージは大きくが異なります。結果、実装されたシステムは顧客の要望とはかけ離れています。要件定義を実施したことがある方であれば、これと似た光景に心当たりがあるのではないでしょうか?
ヒアリングで正しい情報を吸い上げる
このポイントは2つです。
①そもそも顧客が伝えた要望をそのまま実装していても、(おそらく)顧客が解決したい課題は解決できない=顧客の声をそのまま鵜呑みは危険
②引き出した要件を元に関係者と認識齟齬が発生しないように文章化・認識合わせが重要
このうち、本記事ではヒアリングを通してどうこの課題を解消していくか深堀します。②に関しては、要件定義の成果物をしり文章化し認識合わせをする作業が必要になりますが、それもこれも①が解決しない事には正しく情報を文章で表現することはできません。
>>何を要件定義書に書くべきかは、【要件定義の書き方・テンプレート】を参照ください。
ヒアリングの時に意識すべき事
意識すべきは誰が何を意識して話すべきか?もしくは、聞くべきか?です。業務や事業部は、業務・事業のスペシャリストであり、システムの専門家ではありません。彼らの知っている知識から背伸びしシステムに何を求めるかをと耐えてきます。ここに要件定義が上手くいかない問題があります。
業務や事業部は、業務・ビジネスの視点で何が課題かを社内SEやSierに伝えるべきです。それを元に、ITの専門家の社内SEやSier(もしくはコンサルタント)が、業務や事業の課題を理解し、その解決方法を提案すべきです。
このアプローチを間違うと、IT素人の業務・事業部がどうその課題をシステムの機能などで解決したいかまで踏み込んできて失敗します。そうなると、上の図のような3つ座る場所があるブランコが要望さえてしまいます。
上図の例で言えば、人間の子供ではなく、チンパンジーが楽しく捕まって遊べるブランコが欲しいという点をヒアリングすれば、認識齟齬が防げたのかもしれません。
このように、然るべき要件をヒアリングする為に、社内SE/Sier/ITはどうビジネス課題を引き出すのか?引き出しの質を上げる事が重要と理解出来ます。
要件定義のヒアリングの進め方
ヒアリング工程を含む要件定義の流れ
社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール
要件定義では、システム開発・構築で何を実現するかを検討し確定していきます。その為に、必要な情報を収集して文章化し最終的にユーザーと合意し次の工程に駒を進めます。
ハイレベルの流れは以下のイメージです。
①情報を取集する
②必要な観点を追加ヒアリングやディスカッションする
③纏める
④認識確認をする
⑤必要に応じ、②~④を繰り返す
⑥要件定義書を随時アップデート
⑦要件をFIXする
といった流れで進めます。大まかにイメージすると以下です。
要件定義書に何を書くべきか?は【要件定義の書き方・テンプレート】の記事を参照ください。
①情報を収集する
情報収集の手段は様々です。要件文章を読み込む、ヒアリングを実施する等々あります。いずれの場合も、何らかのインプットを元に、要件整理を実施します。要件定義フェーズでインプットなる成果物や依存関係に関しては【要件定義の書き方・テンプレート】の記事詳しく解説しています。
②必要な観点を追加ヒアリングやディスカッションする
要件定義以前のフェーズで準備された情報だけでは大抵情報が不足しています。その為①で収集した情報を元に追加でヒアリングやディスカッションを行い追加で必要な情報を収集をします。又、この時に意識したいのが、業務や事業が検討していない観点があれば、その部分の検討を実施させ必要な情報は集める事です。未検討部分に関しては適切な投げかけを実施し議論を促す必要もあります。
③纏める
情報は集めただけでは意味がありません。業務や事業部と合意できる文章にし、要件を握れるように形作る必要があります。この時に意識したい事は、要件定義文章は後々、これまで要件定義に携わっていなかった人々(例、プログラマー、テスター等)も読む場合を想定し、誰が読んでも分かる、解釈が異ならない点を意識し文章化する必要があります。
例えば、「暖かい飲み物」という言葉は、ある人はコーヒーを想像したり、ある人は出来立てのスープを想像するかもしれません。更に、温かいの定義も、人によっては40度かもしれませんし、人によっては60度かもしれません。このように曖昧な文章は求めている要件と異なるシステムを構築する原因になる為注意が必要です。
④認識確認をする
文章にした後に、その文章で認識確認をすることで更に深い議論や、文章の曖昧な部分を深堀することが出来ます。大抵の場合、文章化してもう一度ユーザーの意図を確認すると、何かしらのイメージのずれや新しい発見があります。社内SEやSier目線では、きちんと文章に目を通してもらう事で、要件文章を合意した事にもつながります。
⑤必要に応じ、②~④を繰り返す
上記のステップは、何度かぐるぐると繰り返す事により、引き出す情報の質、文章の質が向上していきます。1度のヒアリング・レビューで完成は難しいためあらかじめ2度・3度レビューをしても遅延が発生しない段取りが必要です。
⑥要件定義書を随時アップデート
もし、要件定義書外のPPT等でディスカッションや資料のレビューを実施している場合は、要件定義書も抜け漏れなくアップデートし更にレビューする必要があります。
⑦要件をFIXする
最終的に、現場レベルで合意した要件・要件定義書は然るべき場所・人によりオフィシャルに合意してもらう必要があります。これはものすごく重要です。折角、ここまでの工程を全て完璧に実施したとしてもこの要件をしかるべき人・場所でFIXする行為・工程が無いばかりに終わりのない要件定義になってしまう場合があります。
要件をFIXする行為を怠った場合、後から入ってきた人や、最初に巻き込まれていなかった人々が、あれもこれもと追加で要件を言える構図になります。こうなると、プロジェクトという特定の時間軸で活動としては、納期・予算を守るのが難しくなります。
要件定義のヒアリングを上手く進める為に必要な事
システム開発の要件定義のヒアリングを上手く進める為に必要な要素は以下です。
スキル
経験
周囲のサポート
ツール=ヒアリングシート
ヒアリングシートは、ツールです。ツールだけあっても、そのツールを使い上手くヒアリングをするスキルや経験が必要です。もし、あなたにスキルと経験が無くても、ヒアリング相手のサポートや周囲のサポートがあればスキルや経験の不足を補えます。至極一般的ですね。
とはいえ、現実的に社内SEにしろ、Sierにしろ上記で解説したようにITのプロとして要件定義での貢献を求められます。その為に、本記事では、経験と周囲のサポート以外の部分の情報を解説していきます。
要件定義のヒアリングに必要なスキルとその磨き方
要件定義のヒアリングに必要なスキルは以下の4つがあげられます。これらのスキルと経験が上がることでヒアリングシートというツールが無くても要件を上手く引き出せるようになります。以下の4つをフル活用しヒアリングを効果的に推進していく必要があります。
引き出し能力
文章化力
時間管理能力
対人能力
引き出し能力
要件を引き出す為には、高いコミニケーション能力が求められます。相手の真意をくみ取り、必要な質問を行う事で相手の本当に言いたい事を引き出す事が出来ます。高いコミニケーション力だけでは不十分です。どんなに会話が弾んで楽しい時間を過ごしても、要件を深堀し課題解決に繋がらないのであれば黙っていた方がましです。
>>関連記事:要件をユーザー視点でヒアリング
文章力
要件は、聞いても文章にしなかったのであれば無いと同じです。聞いた内容をあなたの言いたいことはこうですよね?と誰にでも伝わる形に表現する必要があります。
>>関連記事:要件FIX
時間管理能力
時間管理?あまり関係ないと思うかもしれませんが重要です。情報を相手に準備してもらう時間、文章化する時間、レビューする時間を管理する事でアウトプットの品質が異なります。時間が無ければ慌ただしく品質の低いアウトプットが出来上がります。時間をコントロールし質を上げます。
対人能力
要件定義のヒアリングも結局は、相手とのインタラクションが重要です。こいつ信用できない、怪しいと思われれば心を閉ざし本来聞けた情報も引き出す事が出来ません。メール、口頭どのような接点を持つ手段だとしても、相手の人を意識する必要があります。その為、相手の人によっては聞き方、話し方アプローチ、場の雰囲気づくり全て意識する必要があります。
上記に関連し【システム開発が学べる本22冊】で各スキルを伸ばすのにおすすめの書籍もご紹介しています。
要件定義のヒアリングフォーマットやサンプル
要件定義のヒアリングを上手く行う為に、ヒアリングシートの活用が有効です。ヒアリングシートとは、業務や事業の要求を吸い上げ要件を明確にするための質問やアンケートを実施する手段です。このシートを使う事で、ヒアリングする側も、される側も効率的且つ効果的に時間を活用する事が可能です。
但し、それは、ヒアリングシートで質問する内容が的をえていればの話です。要件を整理するのに全く的を得ていないような質問や、何も要件整理のインプットにならない情報、もしくは、本来ヒアリングしたい情報を質問できていなければ効率と集められる情報の品質は低下します。
そうならない為にも、ヒアリングの質を上げる必要があります。その為には、以下の点に注意する必要があります。要件定義でヒアリングすべき観点は大きく分けて3つです。
①検討済みの情報の有無の確認
②不足情報のヒアリング
③導入予定のソリューションに特化した質問
①検討済みの情報の有無の確認
要件定義では、基本要求定義の次の工程としてあります。その為、ヒアリング初期の質問は、ドキュメントや情報のありなしです。要求定義で検討された情報をスターティングポイントとし必要な追加情報の収集が効果的です。王道のやり方は、一旦、プロジェクト計画書等ハイレベルな業務・事業のやりたいことが詰まったPPTを説明していただきます。その上で追加で存在する情報(以下の様な資料あればいただけますか?)を収集します。
要求定義の成果物イメージ
社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール
②不足情報のヒアリング
既に存在する情報を頂いて、それに不足する情報を追加でヒアリングをする流れが一般的です。①で収集した情報から不足する情報を洗い出し、その内容をヒアリングシートにまとめます。ヒアリングシートを作成していく中であなたの頭の整理にもつながります。更に、ヒアリングシートを事前にユーザーに配布することで未検討の内容に関しては検討を促すことが出来ます。
③導入予定のソリューションに特化した質問
ヒアリングをする際は、もしあなたがSierの場合は、導入予定のパッケージに特化した質問をすべきです。おそらく自社の他案件で利用した質問集等を参考に、今回の案件用にカスタマイズし活用すべきです。
ヒアリングシート各種テンプレートやサンプル
ヒアリングに直ぐに使えそうなテンプレートをご紹介していきます。
マーキャリ編集部 Webサイト要件ヒアリングシートテンプレート
エムテック Webサイト要件ヒアリングシートテンプレート
WEBサイト作成ヒアリングシート テンプレート&QAシート含む
AWS構築 ヒアリング内容
SalesforceのMarketing Cloud Intelligence 要件整理のテンプレート
要件定義書の各種テンプレートを参考リンク集
要件定義書を参考にヒアリング必要観点を特定する参考資料
機能要件や非機能要件を参考にヒアリングする参考資料
マーキャリ編集部 Webサイト要件ヒアリングシートテンプレート
エムテック Webサイト要件ヒアリングシートテンプレート
営業用のヒアリングシート
WEBサイト作成ヒアリングシート テンプレート&QAシート含む
AWS構築 ヒアリング内容
以下はテンプレートではない無いですが、AWS構築時にヒアリングしたい内容がまとまっています。
以下はイメージです。
SalesforceのMarketing Cloud Intelligence 要件整理のテンプレート
SalesforceのMarketing Cloud Intelligenceという製品の要件ヒアリングのシートです。あなたの推進するシステムが全く同じでなくともこのテンプレートでカバーされている質問観点を参考にヒアリングシート作成に生かせるかもしれません。
要件定義書の各種テンプレートを参考リンク集
記事中断で以下の大量の参考になる要件定義書サンプルを紹介しています。
要件定義書を参考にヒアリング必要観点を特定する参考資料
機能要件や非機能要件を参考にヒアリングする参考資料
経済産業省の非機能要件案 非機能要求グレード本体(日本語版)DLはこちら
以下の様なエクセル入りですぐにテンプレートとして活用できます。
要件定義のヒアリングコツまとめ(フォーマット/シート、項目)まとめ
本記事で解説した内容を纏めていきます。
要件定義とヒアリングの関係性で押さえておきたいポイントは以下です。
要件定義と要求定義の違い
ヒアリングを通しユーザーが本当に求める物を特定する
要件定義のヒアリングでよく発生する認識齟齬
ヒアリングで正しい情報を吸い上げる
ヒアリングの時に意識すべき事を理解し進める
要件定義のヒアリングを含む進め方のおさらいです。
①情報を取集する
②必要な観点を追加ヒアリングやディスカッションする
③纏める
④認識確認をする
⑤必要に応じ、②~④を繰り返す
⑥要件定義書を随時アップデート
⑦要件をFIXする
ヒアリングに必要なスキル
引き出し能力
文章化力
時間管理能力
対人能力
そして最後に要件定義のヒアリングの方法と各種テンプレートに関して解説しました。
要件のヒアリング観点
①検討済みの情報の有無の確認
②不足情報のヒアリング
③導入予定のソリューションに特化した質問
要件定義のテンプレート
マーキャリ編集部 Webサイト要件ヒアリングシートテンプレート
エムテック Webサイト要件ヒアリングシートテンプレート
WEBサイト作成ヒアリングシート テンプレート&QAシート含む
AWS構築 ヒアリング内容
SalesforceのMarketing Cloud Intelligence 要件整理のテンプレート
要件定義書の各種テンプレートを参考リンク集
要件定義書を参考にヒアリング必要観点を特定する参考資料
機能要件や非機能要件を参考にヒアリングする参考資料
本記事の内容であなたの要件定義のヒアリング準備に貢献できれば幸いです。Please enjoy!