

JISAの研修で目指せヒアリング力向上!
こんにちは。ソリューション開発部の矢和多です。
先日、JISAのITエンジニア育成研修コースのひとつ、「ビジネスとITをつなぐ要求分析とヒアリング~BABOKの活用~」を受講してきました。
非常に歯応えのある演習に打ちのめされつつ、ヒアリングのポイントを自分なりに掴めてたいへん有意義な1日となりました。
なぜヒアリング力?~受講のきっかけ~
アークシステムでは、社員育成・スキルアップ支援の一環として、外部研修・講習会の活用を年度計画に盛り込んでいます。2016年度ソリューション開発部では、メンバーがそれぞれ自分自身で伸ばしたいと感じている分野について希望を出し、受講計画を立てました。
会社全体の教育計画で対象になっているのは主にビジネススキルが中心です。
技術系スキルの習得については、各部門主体で必要なときに必要な研修・セミナーへの参加を申請する形になっています。
そこで、私が日々の業務の中で、いま自分にもっと力があれば…と感じる瞬間について考えたところ、ヒアリング力というキーワードに思い当たりました。
私は、あるお客様のシステム部門を支援しているスクラムチームの一員として、アークシステムが新規開発から携わってきたWebアプリシステムの保守運用開発を行ってきました。
※ 以前こちらの記事でも紹介したスクラム開発チームです。冒頭の写真「1」のカードを出しているのが私の手です。
特に2年前にスクラムチームがお客様のオフィスに常駐するようになってから、お客様の業界全体の在りようや業態の変化を目の当たりにし、この激しい流れの中でお客様のビジネスに最適なシステムの形を保ち続けるためには、お客様に寄り添って日々次の形を考え続ける必要があると痛感しました。
そこで重要になるのが、聞き出す力、ヒアリング力です。
小さな新機能開発ひとつを取ってみても、それを必要としている人の話を聞けば聞くほど気付きが重なるという体験もしましたし、あのときもっと突っ込んで聞き出しておけば、もっとより良い形にできたのに、という反省もあります。
ヒアリング力を高めて、もっとお客様の役に立つシステムを作りたい!そんな意気込みでこの研修コースを受講しました。
いきなり超上流?!
さて、今回のコースは丸1日の講習会で、講義と演習が半々という形態でした。
コースタイトルに「ビジネスとITをつなぐ」とあるように、経営層、業務の現場、システム部門の3つを橋渡しするビジネスアナリストを目指す内容で、演習内容も、経営者から経営目標・経営戦略を聴き取り、現場部門の担当からは現場の課題を聴き取って分析、施策を検討する、という壮大なもの。
講師を相手にヒアリングを実践するロールプレイ形式のグループ演習を特に楽しみにしていたのですが、これがなかなかに高難度!我々のチームは見事に撃沈しました。
まず馴染みの薄い業界の事例企業の現状分析に四苦八苦するところから始まり、システム屋の癖でついついまずシステムありきで進めると迷子になって最適解を導き出す前に時間切れになる罠に嵌ったり。
想像力を駆使していろいろな切り口を考えるという作業に頭が疲れました。
講義パート~プロジェクトの成功にはヒアリングが不可欠!
講義パートでは、ビジネスアナリシスの知識体系のまとまりであるBABOK(Business Analysis Body of Knowledge)をベースとしたヒアリングに関する知識や観点を学びました。
ビジネスアナリシスとは、
とBABOKで定義されており、システム開発工程における超上流工程に対応すると考えることができます。


講義で学んだ内容で特に印象深かった内容を記載しておきます。
開発プロジェクトを成功させるためには
多くのシステム開発プロジェクトが失敗する原因は、要件定義が十分でなく、要求が曖昧なまま進めてしまうことにある、と言われています。
- 発注者が適切に要求を提示できているとは限らない。曖昧な要求からは使えるシステムは作れない
では、システム開発を成功させるためには、どうすればよいのでしょうか。
- 機能や実現方法を考える前に、そのシステムを必要とする背景や業務上の課題、さらにそれらの根本となる経営上の目標を明確にし、ステークホルダー間で共通認識にした上でプロジェクトを進めることが重要となる
- そもそもの問題は何か、何故それが問題なのか、隠れている問題や真のニーズを引き出すために、「聴くこと(ヒアリング)」が大切!
ヒアリングで意識するポイント
要求は「ビジネス要求 → ステークホルダー要求 → ソリューション要求(機能要求、非機能要求) → 移行要求」のように階層構造に分類できます(下図参照)。上位(目的)を実現するために下位(手段)は十分に検討されているか、を意識してヒアリングすると、問題点が浮かび上がりやすくなります。
- 誰に何を聴くか、的確な相手を選ぶ
- ドメイン(業務領域)とそれに対するソリューション(解決策)というセットで考える


目標の「SMART」が明確になるように聴き出すことが大切です。
- Sprcific(具体的): 何らかの観測可能な方法を示している
- Measurable(測定可能性): 結果をトラッキングして測定している
- Achievable(達成可能性): 工数に対するフィジビリティを調べている
- Relevant(関連性): 組織の主要なビジョン、ミッション、目的と合致している
- Time-bounded(有限時間): ビジネスニーズに合うように定義された時間枠がある
例えば、「売上の向上」という目標に対して、(S)具体的な方法、(M)いくらまで売上を伸ばす、(A)具体的に実現できるか、(R)会社の経営方針に則っているか、(T)いつまでに達成するのか、を明確にすると実現策を立てやすくなります
正確な文章表現は要求管理の生命線
要求は、ステークホルダー間の共通認識でなければ意味がありません。そのため、要求を文章化する際には、ステークホルダー間で認識が異ならないよう、文章表現に細心の注意を払う必要があります。
具体的に気を付けるべきなのは、下記のようなポイントです。
- 読み手にドメインの知識があると思い込まない
- 要求の表現には、要求を使用するステークホルダーにとってなじみのある用語を一貫性を持って使用する
- 一度に一つの要求のみ表現する
- 複雑な条件記述は避ける
これらは、要件定義に際して口を酸っぱくして言う内容ですが、実際に開発の現場では思い込みや読み違いによる認識の齟齬を抱えたまま進めてしまった結果、手戻りが発生することなどはよくあります。
ヒアリング時から用語の統一と正確な表現を意識するとよいでしょう。
演習パート~やってみよう!ビジネスアナリスト
演習は3人1組のグループワークで、事例企業の情報システム企画部門に所属するビジネスアナリストの立場となり、業務施策・情報施策を検討する、という内容でした。
内容は2部に分かれており、前半は企画フェーズを想定した経営者へのヒアリングによってトップダウンの目標・施策の体系化を行い、後半は要件定義フェーズを想定した業務部門へのヒアリングによってボトムアップの目標・施策の追加を行いました。
下図は成果物のイメージです。


演習の流れ
演習の具体的な進め方は下記の通りです。
- 各々で事例企業の成り立ちや経営環境などについての資料と経営者や部門トップのインタビュー内容を読み込んで経営目標や戦略を把握し、全員で話し合いながら目標体系図の整理を始める
- 体系化を行う中で出てくる疑問をもとに、確認項目を洗い出す。これらの確認項目がヒアリング項目の候補となる
- 目標と施策は必ずセットで提示されるべきだが、資料から読み取った内容を体系図に整理していくと、施策を持たない目標、目標と紐づかない施策が浮かび上がるため、そこを明確にするためにヒアリングを行う
- 確認項目をもとにヒアリング項目を整理する。重要なポイントは下記の3点
- 聴くべき相手=ステークホルダーはだれかをはっきりさせる
- 回答についてあらかじめ仮説を立てておく
- ヒアリング項目に聴く順番(優先順位)をつけておく
- 経営者役の講師に対してヒアリングを行い、回答を基に体系図を更新する
- 業務の問題やそれを解決する業務上の目的・目標と施策について検討するため、今度は、業務の現場から提示された問題や目標についての資料から、目標を達成するための施策を検討する
- 可能な範囲で一般的に考えられるアイデアを自由に出す
- 自由に出したアイデア(施策)を効果・費用・実現可能性の観点で評価し、重要なものを選択する
- 目標体系図に選択した施策を追加し、目標と施策の体系化を行う
- 施策の検討・体系化の中で出てきた疑問をもとに、確認項目を洗い出す
- 確認項目をもとに業務部門へのヒアリング項目を整理する
- 様々な業務部門の担当者に扮した講師に対してヒアリングを行い、回答を基に体系図を完成させる
最終的な成果物のイメージは前述の図の通りですが、今回の演習の「2年後の売上高30億円増」「業務運用コスト2億円削減」という2つの経営目標に対しては上の図ほど単純なものにはならず、解答例を見ると、経営戦略が3項目、CSFが4項目、業務目標が8項目、業務施策が10項目、情報施策が10項目、システム数4つを導き出すという複雑なものでした。
講義では解った気になってもいざやってみると、必ずしもシステム化が最適解ではないというような目標も存在していたり、気を付けないといつのまにか施策自体が目的と化してしまっていたりと、グループで知恵を出し合っているにもかかわらず解を導き出すのが非常に難しかったです。
半日間頭がぐるぐるしっぱなしでした。
やってみて実感したこと
この演習のなかで、特に実感したのは次のようなことです。
- 質問について予め回答の仮説を立てておくとスムーズに進められる
- 「これはどういうことですか?」と質問するよりも、「これはこういうことだと考えるのですが、どうでしょうか」という持っていき方をした方が相手も答えやすい
- 「いえ、そうではなくこうなのです」「はい、そこはその通りです。ところが、こちらでは実はこうでして・・」
- 良い質問は問題点を露わにする
- 質問者と回答者で回答内容を吟味するなかで、問題の本質が明らかになっていくような、キーになる質問を出せればしめたもの(演習では出せませんでした。。)
- 「何をどれだけいつまでに実現するために」という目標がはっきりしていると、より有効な施策を立てられる
- 具体的な目標数値が見えないままでは、オーバースペックな施策案を進めてしまうこともある。「SMART」の5つのポイントを明確にすることを常に意識するとよい
本当に「使えるシステム」を目指して
今回の研修では、BABOKをベースとした要求分析について学び、お客様の真のニーズを引き出して経営に貢献するシステムを実現するための要求ヒアリングを体験しました。
保守開発を行うなかでお客様から出てくる「こんなことしたいんだけど」という要望が、そのままシステムに反映できるような内容であることは稀で、「何のために」「いつまでに」「何を実現したいのか」を辛抱強く聴き出していくと、当初の要望からは違った形になっていくことはよくあります。
表面的な要望には表れていない真のニーズを聴き出して、本当にお客様の役に立つ「使えるシステム」を作るため、今後の業務のなかでも今回の講義と演習で学んだことを意識してヒアリングに当たりたいと思います。