SEのための聞く技術

SEに必要なスキル

スキル分類	主なスキル
技術	・プラットフォーム ・プログラミング言語 ・データベース ・セキュリティ ・ネットワーク
メソドロジ	・オブジェクト指向 ・コンサルティング手法 ・アーキテクチャデザイン ・モデリング手法 ・テスティング手法
ビジネス　#ここの話 ⇒	・聞く能力 ・交渉力 ・問題解決力 ・ドキュメンテーション力 ・プレゼンテーション力
業界・業務知識	・人事管理 ・販売管理 ・生産管理 ・財務管理 ・製造業、流通業、金融機関などの業界動向
プロジェクトマネジメント	・品質管理 ・進捗管理 ・コスト管理 ・リスク管理 ・コミュニケーション管理

提案時の失敗事例

失敗	原因	改善点
・提案内容が具体性に欠けている ・顧客の予算や期待に応えていない	業務機能について詳細に確認できなかった	・専門家や経験者を入れて、確認すべき事項を抽出する ・質問リストを作成する ・事前に顧客へ送付しておく
	顧客企業や業界の情報収集・分析をしていない	・顧客企業の情報を調べる ・業界の法規制や標準を調べる ・類似システム化の事例を調べる
	受注成功要因を探っていない	案件情報として、競合相手、予算規模、ベンダーへの期待感などを聞き出す
	顧客のニーズよりも、自社製品のアピールを優先した	・押し売りではなく、まずは顧客ニーズを聞くことに徹する ・顧客ニーズが起きた背景までも聞き出す

要件定義時の失敗事例

失敗	原因	改善点
・業務要件がシステムに反映されていない ・処理が遅く、操作性も悪い	ヒアリングの対象者に漏れがあり、ヒアリング手法も不足している	・マーケティング担当者だけではなく、受注担当にもインタビューする ・ブレインストーミングで、新システムの要件を検討する ・インタビューの結果を整理し、他のユーザー部門にも確認する
	性能要件を確認していない	信頼性や性能など、業務を円滑に遂行するために必要な非機能要件を把握する
	要件を目に見える形で検証していない	・データやプロセスはモデリングで視覚化して確認する ・ユーザビリティはプロトタイプで検証する

トラブル対応時の失敗事例

失敗	原因	改善点
・トラブルの影響が長引いた ・有効な復旧策を打ち出せなかった	本質的な問題を解決する前に、相手の心情を理解しようとしていない	・相手の置かれた状況や立場を理解しようと努める ・相手に、共感していることを示す言葉をかける
	トラブルを解決するにあたっての前提条件を確認していない	・どの範囲から復旧させる必要があるのか、いつまでに復旧させる必要があるのかを確認する ・条件を満足できそうになければ、妥協点を探る
	原因や解決策を見えるようにしていない	・原因の構造を可視化する ・複数の解決策を評価したうえで提示し、顧客に選んでもらう

傾聴の段階

1. 内的傾聴
2. 集中的傾聴
3. 積極的傾聴（アクティブリスニング）

アクティブリスニング

1. 相手の話に集中する
2. 聞いているサインを送る
3. リフレインで確認する
4. 反論してみる

質問する

1. オープンクエスチョン（5W1H）
2. クローズドクエスチョン
3. オープンとクローズドの組み合わせ

	オープン	クローズド
オープン	1. 発想を土台に新たな発想を得る（ブレインストーミング）	3. 複数の候補を抽出して、具体化すべきところを絞り込む
クローズド	2. 最初に範囲を特定したうえで、新たな発想を得る	4. より具体的に追及して、明確にする

明確化する

1. 内容を要約する
2. 客観的に聞く

議論の見える化

1. ロジックツリー　上位から下位へ展開。考え方：MECE（Mutually Exclusive Collectively Exhaustive）
2. マインドマップ　ロジックツリーの一種　5W1H　線の太さや色で関連性やカテゴリを表現
3. マトリックス　網羅的に複数の切り口で整理したいときに有効
4. ポジショニングマップ　 2つの評価軸で4象限を作成　代表例：PPM
5. ベン図　集合関係を視覚化したいとき

ヒアリングのPDCAサイクル

1. P…ヒアリングの準備
2. D…ヒアリングの実行
3. C…アウトプットの作成・検証
4. A…ヒアリングの見直し

ヒアリングのアプローチ

提案と要件定義では、ヒアリングの性格が異なる。

【提案】

• 対象業務の詳細を深めるよりも、提案範囲の明確化を優先する。
• 事前の情報収集を十分におこない、仮説を持って臨む。
• 他社との競争に勝って受注するための成功要因を探る。

【要件定義】

• 個別の業務について、詳細な要件を正確に把握する。
• 業務の実地調査などにより、ヒアリング結果の裏付けをとる。
• ヒアリング結果を共有して、関係者間で共有する。

【提案と要件定義の負荷バランスの違い】

ヒアリングのポイント

提案と要件定義では、アプローチが異なるため、ヒアリングのポイントも異なる。

【提案】

提案時のヒアリングは、アウトプットである提案書の構成を意識してポイントをおさえる。

（１）提案書の構成

5W1H3Cの視点で構成をおさえる。

構成	内容	留意点
WHY （目的）	顧客要件の背景	経営戦略や経営課題など、要件の背景をおさえる
WHAT （提案内容）	提案する内容	システムの新規構築やパッケージの適用などを明確にする
WHERE （範囲）	提案の対象とする範囲	業務範囲や既存システムとの関係などを明確にする
WHEN （スケジュール）	システムの開発スケジュール	要件定義、基本設計、テストなどの工程を区別する
WHO （体制・役割分担）	顧客側・自社の体制と役割	体制図により、責任関係を明らかにする
HOW （作業）	開発内容をWBSで詳細化	作業のインプットとアウトプットの関係を明確化する
COST （費用）	開発作業費や機器費を提示	保守費の目安も含める
COMPETITOR （競争相手）	自社が優位に立つポイント	競争相手との差別化を明確にし、顧客の期待に応える
COMPANY （自社）	自社の開発実績をアピール	類似のシステム事例を整理する

（２）システム化要件

　1️⃣　システム化の背景

• 顧客が属する業界の動向
• 会社概要や事業内容、組織構成
• 経営戦略や経営課題
• 現状の業務が抱える問題
• システム化の中長期計画

　2️⃣　システム化の内容

• システム化の対象業務
• システム化の方針（開発方式、システム構成など）
• システムの機能（画面、帳票、処理）
• システムの運用条件（稼働時間帯、信頼性、性能など）
• システムの保守方針
• 既存システムとの関係

（３）受注要件

　1️⃣　提案の評価基準

　2️⃣　システムの予算規模

　3️⃣　顧客の期待

【要件定義】

システム構築フェーズの最初の工程、正確にユーザー要求を拾い上げて把握していく。

（１）機能要件

• 機能が必要な背景、目的
• 機能の概要、前提となる条件
• だれがいつどのように機能を使うのか

（２）非機能要件

対象とするシステムの特徴を確認し、重要な品質特性を見極めていく必要がある。

品質特性（JIS X0129）

機能性	合目的性	使用される目的に合っている
	正確性	正確、または合意できる処理結果を返す
	相互運用性	他のシステムと相互接続、運用ができる
	標準適合性	機能が規格に適合している
	セキュリティ	不当なアクセスを排除できる
信頼性	成熟性	潜在する欠陥の度合い
	障害許容性	障害発生時にある程度のレベルを維持できる
	回復性	障害発生時にデータや処理の回復を図る
使用性	理解性	利用者が労力をかけずとも操作できる
	習得性	利用者の習得のしやすさ
	運用性	利用者がおこなう業務運用の容易さ
効率性	時間効率性	応答時間や処理時間
	資源効率性	計算機資源の使用量、使用時間
保守性	解析性	設計書やプログラムの解析が容易
	変更性	システムの拡張・変更のしやすさ
	安定性	システムの修正が他へ影響しない
	試験性	修正後のテストの容易性
移植性	環境適応性	異なる環境への適応
	移植作業性	環境設置のための必要作業
	規格準拠性	移植のための規格に準拠している
	置換性	他のソフトウェアへ置き換えしやすい

ヒアリングの準備

ヒアリングの成否は計画時点で決まる。

【ヒアリング準備の流れ】

　

【関連情報の収集・分析】

（１）顧客企業の情報

　1️⃣　顧客の現状分析

顧客企業の情報

企業情報		内容
企業概要	企業の沿革	創業、上場、会社合併などの変化
	代表者	同族経営か否か
	資本金	資本金の大きさ、自己資本比率
業績	売上	単体、連結での売上状況
	純利益	単体、連結での収益状況、売上高利益率
	傾向	近年の傾向は増加か減少か
事業	商品	主力商品の傾向と割合
	サービス	提供しているサービス内容と割合
組織	組織構成	営業や製造などの組織構造
	事業拠点	営業拠点や製造拠点
	従業員数	従業員の数、平均年齢
取引先	仕入先	原料や部品を仕入れている企業
	得意先	製品やサービスを提供している企業
	金融機関	メインバンクや幹事証券会社

　2️⃣　情報収集方法

　　ホームページの会社案内やIR向けの事業報告書。会社四季報、帝国データバンク。

（２）顧客の業界情報

　「顧客の問題がなぜ問題たりうるか」を理解するためには、その背景となる業界動向を把握しておく必要がある。

　1️⃣　業界の動向

業界情報	内容
市場動向	市場全体は拡大しているのか、縮小傾向にあるのか。業界の課題は何か？
競合状況	業界構造はどうなっているのか。競合企業との大きな違いは何か？
政府の法規制	政府による法規制にはどのようなものがあるのか？
業界団体の自主ルール	業界団体には何があるか。またどのような自主ルールが定められているのか？
業界の専門用語	業界一般によく使われている専門用語には何があるのか？
ITソリューションの動向	業界で流行しているITには何があるのか。それは何を狙って導入されているのか？
類似事例	今回の案件と類似した先行他社の事例はあるのか。失敗事例はあるのか？

　2️⃣　IT投資規模の分析

　顧客のIT投資規模に見合った提案にすることが重要。

　売上高に対するIT予算比率。（金融業が突出）

　3️⃣　情報収集方法

金融業界の情報源の例

分類	例
白書	・「金融情報システム白書」 ・「金融庁の１年」
業界紙	・日本金融新聞 ・日本金融新聞
行政機関	金融庁
シンクタンク	・野村総合研究所 ・日本総研
業界団体	・全国銀行協会 ・日本証券業協会 ・日本クレジット産業協会 ・日本消費者金融協会 ・日本損害保険協会 ・生命保険協会
書籍	・「SEのための金融の基礎知識」 ・「日本の金融業界」 ・「銀行の法律知識」 ・「ロイター最新金融用語辞典」

（３）顧客の顧客

顧客が業務をシステム化し改善する背景には、顧客の顧客からの要請に基づくことが多くある。

（４）対象業務の情報

顧客企業が、すべての業務を見直してシステム化するケースは稀で、たいていは特定の業務を対象にしていることが多い。業務を絞り込んで対応したほうが効率的。

　1️⃣　業務システム事例

　日経コンピュータ等の業界紙やウェブサイト等。

• ITmediaエンタープライズ
• 日経BPビズボード
• CIOオンライン

　2️⃣　標準業務プロセス

　標準プロセスのリファレンスとしては、米国生産性品質センター（APQC）によるPCFがある。ベンチマーキングの基準となるベストプラクティスを定めておくといい。

（５）顧客からの提供情報

　1️⃣　提案

　顧客から受け取るRFPの典型的な構成

RFPの構成例

分類	項目
システムの概要	システム化の目的と効果
	システム化の範囲と現状の課題
	既存システムとの関連
	システム構成の前提、制約
	利用する部署とユーザー側の体制
発注前提	納期と立ち上げタイミング
	必要な成果物
	ユーザー教育の方針
	業務移行、データ移行の方針
	瑕疵担保期間
依頼事項	システムで実現する機能
	開発体制と役割分担
	開発スケジュール
	開発手法と開発言語
	ハードウェア／ソフトウェア構成
	開発と保守の契約条件
	開発の費用

• 提案の前提は明確化、不明確な部分はないか？
• RFPから透けて見えるリスクは何があるか、確認の必要はあるか？
• 依頼事項の中に、とくに確認を要するものはないか？

　2️⃣　要件定義

分類	資料	内容
業務関連	運用マニュアル	業務の運用条件や業務フロー
	操作マニュアル	画面の項目説明や操作方法
	業務用語集	業務で必要な専門用語の解説
既存システム関連	システム構成図	既存システムのハード／ソフト構成
	システム機能階層図	既存システムの機能構成と関係
	データベース一覧	既存システムのデータベース構成

【ヒアリング目的の明確化】

ヒアリングに際しては、その目的を明確にする必要がある。明確な目的をもつことによって、ヒアリングの質問項目を絞り込むことができ、ヒアリングの場で話が発散するのを防ぐことができる。

【ヒアリングシートの作成】

短い時間で効率的にヒアリングをするためには、事前に質問をまとめて、ヒアリングシートを作成しなければならない。事前に対象者に送ることによって、準備を進めてもらうこともできる。オープンとクローズドを使い分ける。

• 「なぜその質問が必要なのか」をよく吟味し、質問を絞り込む。
• 全般的な質問から詳細な質問へ、少しずつブレイクダウンしていく。
• 答えやすい質問から始め、回答に時間がかかる質問は後回しにする。
• 何が知りたいのかを明確にし、答え方がわかりにくい質問はしない。
• 仮説は立ててもよいが、回答を一定の方向に誘導しないようにする。

質問リストを作成したら、第三者のレビューを受けるのが適切。

• 質問内容は、今回のヒアリングの目的に合っているか？
• わかりにくい冗長な質問はないか、質問は多すぎないか？
• 質問の順序は、質問を受ける相手の立場に立っているか？

【ヒアリング手法の選定】

ヒアリングを効果的に進めるためには、適切な手法をとらなくてはならない。

（１）ヒアリング手法の種類

　ヒアリングには5つの手法がある。それぞれに長所・短所があり、状況によって使い分けたり組み合わせたりする。

手法	長所	短所
インタビュー	・対面のため、じっくりと深く聞ける ・場の共有で、お互いの信頼感を高められる	・一部のユーザーを対象に聞かざるをえない ・聞く場を設定するために時間を要する
ブレインストーミング	・課題解決策などの発想が得られやすい ・参加意欲を高めることができる	・うまく進行させるためには、ファシリテーションスキルが要求される ・話が発散しやすい
アンケート	・幅広いユーザーを対象にできる ・手間をかけずに多くの情報を収集できる	・一方通行で、臨機応変な判断ができない ・準備や集計に時間がかかる
現場観察法	・現場で客観的な情報を収集できる ・実務を見て、業務内容の理解が促進される	・現場で観察するため、手間がかかる ・SEに高いスキルが要求される
弟子入り法 （インターンシップ）	・通常だけでなく例外的な業務ケースも拾いやすい ・ユーザーが気づかない視点からアイデアを得られる	・ユーザーの負担が大きい ・時間がかかりやすい

　1️⃣　インタビュー

　回答内容の優先付けや分類などを整理するためには、その場でホワイトボードに書いて

整理していくのが良い。ファシリテーションしていくことが大切。議論を「見える化」していく。

　2️⃣　ブレインストーミング

　ブレストの基本的な進め方には、次の4つのルールがある。

• 他人の発言を批判しない。
• 制約なしに自由奔放に発想する。
• アイデアの質よりも量を追及する。
• 他人のアイデアに便乗する。

　集中力をあげるために30分程度に時間を制限すること、また議論のテーマを具体的にして発散しすぎないようにするのが秘訣。

　3️⃣　アンケート

　定式化した内容に大きく依存するため、質問文の作成にあたっては誘導しすぎないよう注意が必要。提案では、あまり時間が与えられないため、使うことがほとんどない。要件定義では、インタビューの結果を踏まえて全体のニーズを検証したいときに活用できる。

• アンケートの目的を絞り込み、集計結果の使い方を決めておく。
• アンケートのサンプリング対象とする母集団を適切に選ぶ。
• 質問での言葉づかいは、わかりやすく具体的にする。
• 回答は、自由文ではなく、選択肢から選ばせる。
• アンケート結果を定量的に集計できるようにしておく。

　4️⃣　現場観察法

　人間の業務知識には、言葉で表現しやすい形式知と、表現しにくい暗黙知があり、インタビューでは形式知は得られても、暗黙知を得るのは至難の業。

　5️⃣　弟子入り法

　一般的にインタビューでは、業務の通常ケースについて語られることが多い。弟子入り法は、現場にいるため、例外的な業務ケースについても聞きことができる。提案では使うことはないが、要件定義ではインタビューの結果で業務全体をふるいにかけた後、詳細を確認したい特定の業務に絞って使うのが効果的。

（２）提案は効率的に実行する

　提案では、時間があまりとれず深める必要もないため、システムの調達を主管しRFPを発行するIT部門の担当者を対象にインタビューするのが効率的。

（３）要件定義では現場を見る

　要件定義では、業務要件を具体化し確定させるため、時間をかけてでも多くの関係者からヒアリングしなければならない。インタビューだけではなく、問題解決法を探るブレインストーミングやアンケートのほか、業務理解を進めるために、現場観察法や弟子入り法も活用する必要が出てくる。

【ヒアリング対象者の選定】

ヒアリングする際には、目的に合わせて、適切な対象者を選び出席を要請しなければならない。

【ヒアリングスケジュールの作成】

提案では、1，2回のヒアリングで終わることもあるが、要件定義では、ヒアリングを計画的に実施する必要がある。

（１）参加者の都合を調整する

（２）日程レベルで計画を立てる

【ヒアリング依頼書の作成】

ヒアリングの日程が確定したら、開催日の少なくとも1週間くらい前までに、関係者に対してヒアリング依頼書を発行する。ヒアリング依頼書には、ヒアリングの目的や参加必須メンバー、会議のアジェンダなどを記述しておく。アジェンダを送付するときに前回の議事録を送付すると効果的。アジェンダの内容は、キーパーソンに事前承認を求めておく。

ヒアリングの実行

【オープニング】

（１）会議の開始前

（２）目的と議題の確認

（３）自己紹介

（４）配布資料の確認

【質疑応答】

アクティブリスニングに徹し、オープンクエスチョンやクローズドクエスチョンによって相手に問いかける。相手の回答を要約したりして、明確にしていく。ヒアリングは二人以上で臨み、一人は質問役、もう一人は回答結果の書記役という形で役割分担をするのが適切。

【クロージング】

議題が終わって、単に「それでは、終わりましょう」ではなく、次の方法で締めくくる。

• 議論や回答結果のサマリーをおこない、最終的な確認をとる。
• ペンディングや宿題事項があれば、納期を設定して確認する。
• 議論の過程を振り返り、合意にいたったプロセスの理解を得る。
• 特定の業務を詳細化する必要があれば、詳しい人を紹介してもらう。
• 次回の会議日程と議題、参加者について確認する。

アウトプットの作成・検証

把握した情報が間違っていないかを検証するために、アウトプットを作成し確認する。

【議事録】

（１）議事結果のまとめ

議事録の構成

項目	内容
①開催日時	会議開催した開始時間、終了時間
②出席者	会議に出席した人数とメンバー
③議題	会議の議題と消化状況
④議事内容	会議のアジェンダ
⑤決定事項	会議で決定したこと
⑥未決事項	決定できず、次回へ持ち越しになったこと
⑦発言の要旨	出席者の発言要旨、議題ごとに主張点をまとめる

（２）出席者によるレビューと配布

完成した議事録をドラフト版として関係者へ送付し、内容の確認を依頼する。チェックおよ反映が完了すれば、議事録を正式に配布する。記憶は薄れるので次の日までには送付したほうが良い。

【モデリング】

ヒアリングで洗い出した要件は、可視化しなければ、ユーザーと共有し確認することができない。オブジェクト指向設計に向いているUML、プロセス分析のためのDFD、データ分析のためのERDなどがある。

（１）UML

• クラス図やユースケース図など、13種類の図が定義されている。
• 構造図のうち、パッケージ図と配置図は物理的な構造、それ以外は論理的な構造をあらわしている。
• シーケンス図やタイミング図などによって、時間的な遷移もあらわせる。

　要件定義では、静的な情報の構造をあらわすクラス図やシステムの使い方をあらわすユースケース図がよく使われる。

（２）DFD

　DFDは、データに着目して業務の流れを整理する技法。業務のデータがどこで発生するのか、また、どのように処理されるのか、どこで保管されるのかを、入出力の媒体や組織にとらわれずに図式で表現する。

（３）ERD

　ERDは、データ間の関連をエンティティ（実体）とリレーションシップ（関連）を用いて表現する技法。業務全体の概念的な把握ができる。

【シミュレーション】

人間がヒアリングする以上、すべての要件を完璧に把握するのは容易ではない。シミュレーションで、ユーザーの目に見える形で具体的な画面などを提示し、要件の再確認や新たな要件の引き出しを図る。

（１）プロトタイプ

　とくに画面や帳票に関して開発するのが有効。アプローチによって、使い捨て型と継続発展型の2つがある。

　1️⃣　使い捨て型

　目的を要件の確認に絞り、具体的な画面イメージを作成する方法。ユーザーが直感的に確認する機能性や使用性に絞って確認し、品質全般、高い性能や信頼性は追及しない。

　短期間に作成するため、一般的に内部のアーキテクチャは重視しない。

　プロトタイプはPCのソフトウェアで作成したものに限らない。会議の場でホワイトボードに画面イメージを描き、その場で確認していくことさえ可能。

　2️⃣　継続発展型

　作ったプロトタイプを捨てずに、これをベースとして本開発へと継続的に展開していく方法。プロトタイプであるにもかかわらず、最初から凝って作成されることが多い。オーバースペックになりがちで、ユーザーに見せるまでの期間もその分かかってしまう。

　しかしながら、「インクリメンタルプロセス」によって、ユーザーの要件の実現度を引き上げやすいメリットもある。

　継続発展型を採用する場合は、基盤となるアーキテクチャを最初に固めておく必要がある。

　いずれにしても、プロトタイプ作成には時間も負荷もかかる。安易に取り組まずに、次の判断基準を用いる。

• プロトタイプを作成する目的が明確である。
• 要件が不明確な部分があり、目で見なければ確認が難しい。
• 参考にできるような、対象システムに似たシステムが身近にない。
• 要件の実現性に疑問があり、具体的な確認が必要である。
• プロトタイプに時間と費用をかけられる。

（２）シナリオ

　通常ケースから例外ケースにいたる複数のケースを整理する必要がある。シナリオを整理することで、ユーザーは実際にシステムの動きを理解しやすくなり、妥当性を評価できる。

【用語集の整備】

「自分の常識は相手の常識と同じではない」

「在庫」は、出荷部門では完成した製品在庫、製造部門では各工程間に滞留する中間製品の在庫を含む、経営の立場から見れば仕掛品も含む等。

　ステークホルダー間で起こる意見の不一致は用語の定義の違いから生まれがち。共通認識を図ってコミュニケーションを円滑にする。

ヒアリングの見直し

【失敗の原因】

• 質問の不足
• 対象者の選定
• 不適切なヒアリング手法
• 質問リストの内容が不適切

【見直し方法】

　ヒアリングの振り返りシートを作成。

悪かった点（対策が必要）	対策
・質問量が多く消化できなかった ・質問の内容が抽象的すぎた ・分担した結果、属人的になった	・目的に合った質問に絞り込む ・質問に優先度をつける ・質問文をクローズドに変更する ・顧客へ事前に送付し、回答準備を依頼する ・知見者にレビューしてもらい、質問リストの品質を上げる
良かった点（今後も継続）
・話しやすい雰囲気をつくることができた ・業務に詳しい人が出席した ・議事録を迅速に作成し送付した