Hello Ecomott!
おはようございます、こんにちは、あるいはこんばんは。そして何よりお久しぶりです。お忘れでしょうか、
そんな中、以前の記事で、私はこんなことを書いてしまいました。
「なぜヒアリングは難しいのか」を深掘りし、その上で「実践」の考え方やテクニックについて、紹介していければと考えています！
――その場の勢いでなんてことを！！！！！
盛大に大風呂敷を広げてしまった以上、若輩者といえどあまり無責任な記事は書けないぞ、と構想を練っているうちに慌ただしくなり、そしてうっかり忘れ去られるいつもの流れだったわけですね。
春に書くつもりだったこの記事も、気づけばリリースは夏の終わりになってしまったわけで。
おかげで記事内容にも、なにかしらの季節感の演出が必要となってしまいますね。
夏……そう、夏といえば、怪談、
というわけで、今回は要件定義入門シリーズ、「ヒアリング」編の後編です。
我々ITエンジニアにとっての怪奇譚、怖～い怖～い「ヒアリングの失敗」のお話が、暑い夏の夜のお供となりますように
この記事を読むのにかかる時間は 約10分 くらいです！
この記事でわかること
前回のおさらい：ヒアリングは難しい
前回の記事の結論として、以下の点が「ヒアリング」工程において重要であり、故に難しいと締めくくらせていただきました。
- ヒアリングは「聞く」だけではない：
情報のインプットに加え、「構造化（パース）」し、「本質を抽出」するまでが一連のプロセスである。 - ヒアリングの本質は「深掘り」力：
顧客の要望から細かく深掘りしていき、要件化する論理思考力が必要である。 - 営業とエンジニアのヒアリングは別：
営業がビジネス的な「Wants(希望)・Needs(必要性)」を取り、エンジニアが技術的な「What(合意)・How(実現)」を担保する。
いわば車の両輪、どちらが欠けてもプロジェクトは走り出せない。 - 「ヒアリング」でのエンジニアの役割：
顧客の「要望」に対し、技術的な実現可否を批評する。
でも心配はご無用。 👻――本当の”恐怖”はここからだ。💀
ヒアリングに潜む”恐怖”の法則！？
ホラーには法則がある
さて、ここからが怖ーい話。と、その前に。 ホラー映画や怪談には、”恐怖”について、ある鉄則が存在するのをご存じでしょうか。 人が心底「怖い！」と感じる現象には、ある共通する条件が存在します。色々あるのですが、ここでは特に、 4つの法則 について挙げてみましょう。
- 法則①：『正体がわからない（未知の存在である）こと』
確かにそこにいる”何か”。王道のホラー。
姿も、目的も、思考すら理解できず、意思疎通もできないが故の底知れぬ不気味さこそ”恐怖”の根源——。 - 法則②：『後戻りできない（不可逆である）こと』
気づいた時にはもう遅い。あなたの逃げ場は失われた。その選択は取り返しがつかない事態を生む——。要はヒステリックな金髪美女とか偉そうなおじさんが勝手な行動の結果ひどい目に遭う定番のアレのこと - 法則③：『制御不能であること』
その”恐怖”の前に、あなたが出来ることは何もない。為す術もなく、ただ無力であるというシンプルな絶望――。 - 法則④：『理不尽であること』
その”恐怖”の前に、あなたの「常識」も「ロジック」も無意味でしかない。「こんな目に遭う程のことはしていない」のに――。
私が大好きなホラー映画の『ミスト(2007)』などは、まさにこの法則によって、登場人物たちを追い詰め、視聴者の心を削っている作品ですね。
そして同時に、「しかし、何故に要件定義の解説記事でホラー映画論を語り出したんだ……？」と、ブラウザバックのアイコンないし指を動かした方もいらっしゃるかもしれません。
もちろん、意味も関係もあるからこそ、話題に挙げたまで。
実はですね、この”恐怖”の4つの条件は――
そのまま
「ヒアリングの失敗」の原因
として語ることができるのです……！
あるいは、正体不明の要望（未知）。
あるいは、後戻りできない工程（不可逆）。
あるいは、膨れ上がる追加仕様（制御不能）。
そして噛み合わない対話（理不尽な人/状況）。
――ね？ なんだか途端に身に覚えがある気がしてきませんか？
というわけで、ここからはこれらの法則により引き起こされた、なんだか聞いたことがあるようなIT業界の怪談から、「何故ヒアリングは失敗するのか」という恐怖の根源と向き合っていきましょう……！👻
本当にあったかもしれない！？ IT業界に伝わる怖～い話
ここからがお楽しみの怪談タイムです。この業界で働いていれば、どこかしらで聞いたことがあるはずの、ある「惨劇」のエピソード――。
といっても、あまり赤裸々に語りすぎると
せっかくなので、00年代のアングラな雰囲気でお送りします。
Case：『誰がためのシステム統合だったのか
〜要件と要望の混在が生み出した”怪物”〜』
日本では古来、「ぬえ」という、色々混ざりすぎてなんとも形容しがたい姿で伝えられる有名な妖怪が語られています。
この妖怪は、夜闇にどこからともなく聞こえてくるトラツグミという鳥の鳴き声の不気味さから想像が膨らまされた結果、やがて顔は猿、胴はタヌキ、手足はトラ、尾はヘビという異形の怪異として語り継がれるようになりました(姿についても諸説有？)。
初出(諸説有)の古事記の時点では「声」や「気配」としか語られていなかった「ぬえ」が、平家物語で突然、前述のような盛りすぎな姿で語られたのは、あるいは様々な口伝の習合によるものかもしれませんし、あるいは源氏武者の強さを引き立てるために、とにかく盛れ！盛れ！と時の権力者から圧力が掛かっていたのかもしれません。
勘が鋭い方、あるいは実体験として身に覚えのある方はお気づきのことかもしれませんね？
実はこのような流れで「奇妙な怪物」のような要件となってしまうのが、ヒアリング失敗の典型例なのです。
今回はそんな、「ぬえ」のように盛りすぎな怪物になり果ててしまった、ある大規模開発での事例として、公的に報道・出版されている情報を元にしたケーススタディ（フィクション表現を含む）を紐解いてみましょう。
なお、本ケーススタディは業界一般でよく知られる事例を参考にしたものであり、特定の企業を批判するものではありません。
【事例：巨大システム統合】
※推奨BGM：♪某・何とかの世紀的なメインテーマとナレーション
それは、メガバンクや巨大インフラ企業の誕生に象徴される、まさに「巨艦誕生」の時代であった。
そんな時代の中、ある複数の同業他社が、経営統合という形でひとつになろうとしていた。
それに伴い、彼らは基幹システムの一本化を必要とし、史上類を見ない規模の基幹システム統合プロジェクトが、幕を開けた――。
現代であれば、共通の基盤へ一本化する前提で統合が行われたのかもしれない。
しかし、当時、この規模のシステム統合・刷新におけるノウハウを持つITベンダーは、ほぼ皆無と言えた。
そして何より、当時の彼らには、それぞれに歴史があり、思惑があり、プライドがあった。
システム要件検討の最中、旧組織それぞれの思惑とプライド、そして『現在の運用や機能を一切変えたくない』という主張が、激しく対立した。
元を辿ればライバル同士、そんな彼らによる主導権争いが繰り広げられる中でも、システムは開発の手を止めるわけにはいかなかった。
背景には、時代が空前のITバブルの渦中にあったことが大きかった。
『IT化の遅れは企業の死を意味する』そんな焦燥感が、経営陣にはあったのかもしれない。
惜しげもなく、膨大な資金が市場へと投じられていた。
経営統合とリリース期限が迫る中、やがて指導者たちが出した決断は――言うならば『全員の言い分を聞き入れ、異なるシステムを無理やり繋ぎ合わせる』というものであった。
彼らには、『最新の技術なら、どんな複雑な要望も解決できる』という過信があった。
彼らが本来目的としていたであろう、『業務の削ぎ落とし＝要件の精査』という工程が、機能しなかった。
どういうシステムを創るか、その明確なビジョンを見失ったことで、開発は難航した。
当初想定されていた開発スケジュールは、度重なる調整や政治的対立により大幅に圧迫され、現場に残された実質的な開発期間は1年にも満たない、ごく僅かなものだったとも言われている。
その歪みは、すべて開発現場へと押し寄せることとなった。
「炎上案件」の象徴的事例として語り継がれるほど過酷な開発環境となり、IT業界全体に対して「過酷で厳しすぎる現場」というネガティブなパブリックイメージを植え付ける一因になったとすら言われている。
国内の有力ITベンダー複数社を巻き込んで迷走した超巨大プロジェクトは、やがて十分な検証期間を確保できないまま、『開業日』という動かせないタイムリミットに向けてリリースへ踏み切らざるを得なかった。
書籍や当時の報道によると、運用開始早々に、「全国の利用者への直接的な不利益」という形で、プロジェクトの歪みは噴出した。連日、当時の各メディアの紙面を独占し、国会や行政機関すら巻き込む社会的事件にまで発展した。
その事態の収拾、そして運用開始後にも続けられた改修と運用保守により、費やされた資金は最終的に小国の国家予算並みにすら達したとされており、本件に起因する問題の完全なる決着を見るまでに、膨大な人員の投入と莫大なコード量、そして実に十数年に渡る膨大な歳月を費やすこととなった――。
「破綻したプロジェクト」に潜む”怪物”の正体を暴け
以上、エンジニア的には、トラウマ必至の、こうはなりたくないというこわーい話。
が！ただ怖い話で終わらせてしまっては、技術ブログである意味がありません。
全ての失敗事例は、これからの成功事例に繋げてこそ成仏できるというもの。
本事例の初期、要件定義・ヒアリングの工程で何があり、どこに不備があったことで、プロジェクトが破綻してしまったのかを分析することで、
「何故、要件定義/ヒアリングが失敗してしまうのか」
という掘り下げを行なっていきましょう。
まずは今回の事例の概要と、どこに根本的な問題があったのかを簡単に振り返っていきましょう。
(ケース整理)
| 要約観点 | 内容 |
|---|---|
| 本来の目的（あるべき姿） | 経営統合に伴い、各社の業務システムを集約して基幹システムを一本化・最適化すること。 |
| 引き起こされた被害 | 運用開始直後から全国的なシステム障害が発生。解決・改修に莫大な資金と人員、長年の歳月を費やす社会的事件となった。 |
| 根本的な問題点 | 「現状を最善とする」各社の要求（Wants）を整理できず、真の目的（Needs）抽出のための「業務の削ぎ落とし」ができなかったこと。 全員の要望を足し算して精査できなかった結果、正体不明の「ぬえ」のような歪んだ要件が爆誕してしまった。 |
| 副次的な問題 | 歪んだ要件と多重ブラックボックスと化した設計、そして相次ぐ障害対応によって違法建築じみたシステムとなってしまい、現場の運用コストと修正リスクが増大し続ける構造を生み出してしまった。 |
まさに「ぬえ」よろしく、人間たちの混乱と権力闘争に起因して、正体不明、カタチさえつかめない”怪物”と言えるシステムが生み出されてしまったことがわかりますね。
というわけで、ようやく再登場の「ホラーの4つの法則」を用いて、この怪物の正体を暴いていきましょう！
解呪！「ホラーの4つの法則」から、問題構造を紐解こう
先ほど挙げた「ホラーの4つの法則」は、以下の通りですね。- 法則①：『正体がわからない（未知の存在である）こと』
- 法則②：『後戻りできない（不可逆である）こと』
- 法則③：『制御不能であること』
- 法則④：『理不尽であること』
- 法則①：『正体がわからない（未知の存在である）こと』
■ この事例で起きていたこと
「現行を変えたくない」「現行が正解像」という各社の要望・要求をそのまま鵜呑みにした結果、誰も全体像を把握できない(=正解像/ゴールが定まらない)正体不明の「（ぬえさながらの）要件」が生まれてしまった。■ エンジニア/PMの対策観点：「要望・要求と要件を正しく切り分ける」
記事1作目で掘り下げた通り、要件定義とは「ユーザーの”要望”を”要件”に変える工程」であり、ヒアリングはそのためにユーザーの”要望”から”要件”を抽出するための工程です。
顧客の「こうしてほしい」「今のままがいい」はあくまで手段・要望（Wants）であり、「正解」であるとは限りません。むしろ、「正解を創る」のが要件定義という工程の目的なのです。
顧客と、これから作りたいシステムに「なぜそれが必要なのか？」「どんな課題をどう解決したいのか？」を粘り強く深掘り（ヒアリング）し、その本質を言語化・可視化して正体を暴いていくことこそが、この”怪物”への最大の対抗策です。【解呪ポイント】正体が分かった時点で、”怪物”は”怪物”ではなくただの”課題”となる。
- 法則②：『後戻りできない（不可逆である）こと』
■ この事例で起きていたこと
本ケースでは、経営判断により動かせないリリース日が半ば確定していたにも関わらず、要件がまとまらないことで開発期間が圧迫され、十分な検証や評価が行われないままリリースされたことで、大規模障害とその後20年近くに渡る極大規模の改修作業という致命的な破綻を招いてしまった。
一度走り出した巨大プロジェクトは基本的に不可逆であると理解せず、まだリカバリーできる初期の要件定義で「削ぎ落とし（捨てる決断）」が出来なかった結果、要望のすべてがシステム設計に組み込まれてしまい、多重ブラックボックス化・違法建築化が進行してしまった。■ エンジニア/PMの対策観点：「引き算（業務の削ぎ落とし）の合意形成を行う」
記事2作目で解説した「要件の整理」において最も重要であり、最も勇気が要る(あるいは腕の見せ所)のがこの「引き算」です。
顧客の要望をすべてそのまま「全部盛り」で聞くのは、一見して親身に見えて、実のところ最も顧客に寄り添わない、自分本位なエンジニアの仕事であると言ってよいでしょう。
要件定義という「最も後戻りが効く初期フェーズ」だからこそ、プロジェクトの真の目的と照らし合わせ、「何をやらないか（スコープ外か）」「何を捨てるか」の基準を提示し、顧客とバッサリ捨てる合意形成を結ぶことで、必要な開発を確実に遂行するための「答え」を創ることができます。【解呪ポイント】「引き算」こそエンジニアに求められるプロの視点！”怪物”の弱点を見極めよう。
- 法則③：『制御不能であること』
■ この事例で起きていたこと
経営層の思惑や組織間の政治的対立、現場エンドユーザーの要望に振り回され、プロジェクトの舵取りが完全に不能（＝制御不能）となった。
※複数のベンダーが並立していたことも大きい
エンジニアやPMの力だけではどうにもできない上位レイヤーのパワーゲームに対し、システムで実現すべき判断基準（グランドデザイン）を持たないまま対峙してしまったことで、プロジェクト全体が「どういうシステムを作ればよいのか」という明確なゴールを見失い、迷走してしまった。■ エンジニア/PMの対策観点：「絶対的な評価軸を定義し、意思決定の場（経営層）を巻き込む提案を行なう」
記事3作目で深掘りした「真意（ニーズ）の抽出」は、何も現場担当者だけに向けたものではありません。
制御不能に見える政治的対立の渦中だからこそ、エンジニアは「このシステムで達成すべき本来の経営目的（例：コスト〇%削減、業務標準化）」という客観的な評価軸を言語化・可視化し、意思決定権を持つ各ステークホルダーに提示する必要があります。
現場同士のエゴのぶつかり合いに現場レベルで付き合うのではなく、「この目的を達成するために、どちらの要件を優先すべきか」という判断材料を提示し、トップに決めさせる（＝制御可能な土俵に引き戻す）アプローチこそが、プロとして求められる技術です。【解呪ポイント】「制御不能な政治」に振り回されない「客観的な評価軸」を定め、示せ！
- 法則④：『理不尽であること』
■ この事例で起きていたこと
上流工程での妥協と「要望の丸呑み」の結果、歪んだ要件と多重ブラックボックスからなる「違法建築システム」が誕生。
「言われた通り作った（繋いだ）はず」なのに運用開始直後から全国規模の障害が多発し、その尻ぬぐいとして膨大な資金と歳月を費やして、夥しい数の人員が不眠不休の障害対応に追われるという、あまりにも理不尽な地獄絵図が生み出されてしまった。ここには技術力の問題や予算都合といった現場の責任比重はあまりにも少なく、経営判断とシステム要件定義の失策という、現場のエンジニアにとってはあまりにも「理不尽」な災難だったと言える。■ エンジニア/PMの対策観点：「プロとして技術的実現性を評価・批評し、リスクを提言する」
連載を通じてお伝えしてきた通り、ヒアリングにおけるエンジニアの真の役割は、単に「顧客の御用聞き」ではありません。
顧客から提示された要望に対し、「その構造は技術的に破綻するリスクがある」「その実装は将来の運用を殺す」というプロとしての評価・批評を行い、リスクを明確に提言することです。
「言われたものをそのまま作る」ことは一見誠実に見えて、リスクから目を背けるリスクヘッジの放棄でしかありません。
技術的な実現性とリスクを評価し、不可能なことには「NO」を突きつけ、現実的な代替案（リスクの少ない構成）を提示することこそが、巡り巡って現場と顧客の双方を理不尽な惨劇から守ることに繋がるのです。【解呪ポイント】「良薬は口に苦く、忠言は耳に逆らう」リスクを正しく伝えることを恐れるな！
それもそのはず、このケーススタディは20年も前の事例が元ネタです。
実際の失敗例、被害例を教訓として改善を積み重ねた結果こそが、現代の我々が学んでいる「要件定義の原理原則」であり、「ヒアリングの技術」なのです。
まとめ：一番怖いのは”人間”なのかもしれない
ホラー映画の法則4件に沿って、要件定義/ヒアリングの失敗事例を紐解いてまいりましたが、いかがでしたでしょうか？あらためて、今回の怪談もといケーススタディから得られた、”怪物”の弱点をまとめてみましょう。
- 正体を暴く：現場の「言い分」ではなく、システムで達成すべき「課題の本質」に向き合う
- 引き算をする：プロジェクトを守るため、「やらないこと（スコープ外）」を真っ先に合意する
- 評価・批評する：相手に流されず、プロとして技術的リスクを明確に提言する
こうしてみると、ヒアリングの失策は、こうした対応が出来なかったが故の、まさしく「人災」であり、要件定義において向き合うべき相手は「システム」の向こう側に存在する「人間」であるということがわかりますね。
と、ある意味ホラーの王道オチ、「一番怖いのは”人間”」に綺麗に着地できましたね(?)
次回記事が、いよいよ「ヒアリング」解説シリーズの完結編となります。
ここまで紐解いてきた「怪物の正体=なぜヒアリングは難しいのか」と「対抗策=必要な考え方」を踏まえ、いよいよ具体的・実践的なアプローチ・テクニックとして解説させていただこうと思います。
ぜひ最後までお付き合いいただけますと幸いです👻✨
採用情報
エコモットでは、共に「未来の常識を創る」スタッフを随時募集しています。弊社に興味がある方はぜひ下記の採用ページをご覧ください！
