失敗の背後にあるもの　/　要件定義でつまづいた３つのシステム開発を振り返る

「言いましたよね!?」
できあがったシステムを前に、「これは、私たちの要求とは違います」とクライアントから言われてしまった時。
思わず口にした、「言いましたよね!?」という悲鳴にも似た言葉を、私は何度も聞いてきた。私自身が口にしたこともあった。
要件定義の時に、ちゃんと確認したじゃないか…
心の中で、そうつぶやきながらも、事がここまで至った時点で、既にプロジェクトが大きな課題に直面したことも、同時に分かっている。
 
システム開発において、前提となるはずの要件定義に疑義を指摘されるということは、開発会社にとっては悪夢であろう。
修正や変更による工数の増加は、プロジェクトの赤字につながりかねないし、最悪、プロジェクトそのものが頓挫することだってあり得るのだから。
でもそれは、クライアントにおいても同様だ。
システム開発の遅れは、ビジネスの遅れにもつながる。だからといって、求めるものとは異なるシステムを許すわけにはいかない。
私が経験した、３つの「要件定義が原因でつまづいたプロジェクト」を例に、教訓を探っていきたい。
 

真の決裁者は誰なのか？

BtoCサービスを展開する、ある大手企業のWebサイトリニューアルプロジェクトでのことだ。
同社では、リニューアルに合わせてVIの刷新も予定していた。その一環として、往年の大女優をメインに据えた広告戦略を目論んでいたのだ。
件の大女優が活躍したのは、まだ映画がモノクロの時代である。モノクロのイメージカットに合わせるため、Webサイトの基本カラーは、上品な淡いブルーで統一される予定であった。
全サービスのカットオーバーまで、一ヶ月を切ろうかというタイミングだった。
クライアント側のPMが、同社会長に、完成間際のWebサイトをレビューした時に、大問題が発生した。
「きれいなブルーだけど…、うちのコーポレートカラーと違うよね」
同社のコーポレートカラーは、くっきりと強い原色カラーだった。
同社PMも慌てた。
会長にも、淡いブルーに統一することで了承を取っていたからだ。
だが、そう言い募っても、会長の言葉は変わらなかった。
「でも、うちのコーポレートカラーとは合わないよ」
 
ステークホルダー・マネジメントという言葉がある。
システム開発等のプロジェクトを進行する上で、真の決裁者が誰であるのかを把握し、適切にプロジェクトを進行させるための手法である。
企業によっては、本ケースのように、「鶴の声」を発するだけの権限と実力を持つ存在がいる。こういうタイプは、カリスマ的な経営手腕を奮ってきた経営者に多い。
厄介なのは、この手の「鶴の一声」には、説得力が伴っていることである。
「コーポレートカラーと異なる…、というか、まるでそぐわない色を、メインビジュアルの基本色に据えてて良いの？」
おっしゃるとおりである。
 
本ケースでは、クライアント側PMも、システム開発側PMも、会長の存在を、どこかおざなりにしてきた。プロジェクトの進行を止めるような、爆発力のある意見は言わないであろうという、楽観があったのだろう。
だから、プロジェクト進行における報告やらレビューのタイミング、回数、内容についても、どこか気が抜けていたのかもしれない。
真の決裁者を見誤った顛末である。
 
私の勤めていた会社は、デザインと実制作を担当していた。会長の指摘を受けて、たった一ヶ月あまりの間に、二万数千個のボタン、見出し、ページ等の作り直しを強いられた。
私の会社も大変であったが、同プロジェクトにはカットオーバー間近になって、同時に進行していた業務系システム開発にもさまざまな横やりが入ったと聞いている。
余談だが、システム開発側PMは、心を患い、プロジェクトを途中離脱、会社も辞めたと聞いている。
※VI
ビジュアルアイデンティティの略。ロゴ、シンボルマーク、ブランドカラー、デザインポリシーなど、企業やブランドが備える視覚要素全体を指す。
※PM
プロジェクトマネージャーの略。プロジェクト全体の進行管理や調整、クライアントとの折衝などに従事する、リーダーとしての役割を果たす。
 

要求と要件が違う

「クライアントから、『要求と違うものが作られている』とクレームが入り、プロジェクトを中断せざるを得なくなってしまいました」
あるシステム開発会社から、このような相談を受けた。
同社では、ある企業の基幹システム再構築を請け負っていた。
プロジェクト進行は順調に思えたが、システムレビューの段階で、クライアントから「要求仕様を満たしていない」とクレームが入ったのだ。
困ったシステム開発会社は、同社、そしてクライアントの双方と付き合いがあった私の会社に仲裁を求めて相談してきたのだ。
 
システム開発会社が作成していた要求仕様書、要件定義書を確認したが、内容、品質とも、十分な内容であった。むしろ、及第点を超え、褒められて良いレベルのものであった。
なのになぜ、クライアントは不満を抱えているのか？
課題は、クライアントとのヒアリングを重ねることで診えてきた。
 
かんたんに言うと、クライアントは要件定義を軽んじており、システム開発会社は要求仕様を軽んじていたことが原因であった。
要求と要件は違う。
例えば、「お腹が空いた」という要求に対し、要件は、どう答えるべきなのか？
「カレーライスを提供する」「ラーメンを提供する」といった直接的な解決手段を提供するのか、もしくは、「キッチンを用意する」といった仕組み的な解決手段を提供するのか。
クライアントの要求に対し、実現可能な実効手段を示すのが要件である。
ヒアリングの際、クライアント側は、「私たちは、ただ、私たちの要求を実現してくれれば良いだけなのです」と発言した。
一見、正当な言葉に聞こえるが、だがクライアント側の課題は、システム開発会社が提示した要件について、「それが私たち（クライアント）の要求を満たし、実現する実効手段なのかどうか？」という、クライアントが果たすべき義務に対し、真摯に向き合わなかったことにある。
一方、システム開発会社側は、クライアントが理解できるように、丁寧に要件定義を進めなかったという課題がある。
確かに、本ケースにおけるクライアントの姿勢には、課題がある。だが、システム開発会社は、仕事を請け負った立場にある。
「お客様が私ども（システム開発会社）の仕事に満足していただけないのは、お客様の責任です」とは、言えないのだ。
 

そもそも、ゴールが違う

そのプロジェクトは、国からの助成を受け、ある大学で行われたプロジェクトであった。
大学が保有する、巨大なデータベースに対する検索システムを構築するプロジェクトである。
プロジェクトチームは、教授をはじめとする研究スタッフと、システム開発会社側のPM、システムエンジニアたちで構成されていた。
プロジェクトは、要求仕様の確認から始まったが、要求仕様がなかなかまとまらない。これはある意味当たり前のことで、これまでにない検索システムを創り上げるわけだから、誰も、どんなスペックが必要なのか、どういう機能が必要なのか分からないのだ。
議論の結果、要求仕様らしきものはまとまった。しかし、次ステップである要件定義に進んでも、やはり話がまとまらない。要件定義の議論をしているはずが、いつのまにか要求仕様の再定義をしている始末である。
「このままでは、納期までにシステムが完成しません！」
意を決し、ついに、システム開発会社PMが言った。が、議論に参加していたある教授が、このように反論したのだ。
「何を言っているのだ。私たちにとっては、システムの完成よりも、この議論の方が有益なのだ！」
 
本プロジェクトのお金を出したのは、国である。だから、最終目的がシステムの完成であることは、あらかじめ国が指定したことであって揺るがない。
もっと言えば、大学側も、システム開発会社と協力して、システムを完成させる責任を持つ立場である。
その意味で、先の大学教授の発言は、明らかに不適切である。
 
だが、システム開発会社側にも課題がある。
本プロジェクトを、研究機関である大学に委ねたということは、「じっくりと検討と研究を重ね、国内の他大学にも水平展開できる（少なくとも、その礎となるような）検索システムを創り上げてくださいよ」というビジョンであり、期待を含んでいるのだ。
これは、明らかに通常のシステム開発と違う。
システムの完成は、確かにプロジェクトのゴールであるが、要件定義の重要性は、通常のシステム開発とは比にならないほど、重要なのだ。
そのことを理解していないシステム開発会社に対し、教授たちも不満を感じたのだろう。
 

要件定義の齟齬を防ぐために

ここに挙げた３つのエピソードは、すべて世に広く名を知られた大手システム開発会社のものである。
いずれのエピソードにおいても、プロジェクト進行に関するマネジメントについては、しっかりと行っていた。
では、しっかりとしたプロジェクト・マネジメントを行っていたにもかかわらず、なぜ問題が発生したのか？
むしろ教科書的でしっかりとしたマネジメントが仇となり、「人を診る目線」が欠けていたことが原因だったのではないかと、私は思う。
システム開発は、依頼する側（クライアント）と作り手（システム開発会社等）双方の努力があって、はじめて完成するものだ。
だからこそ、教科書的マネジメント管理とは別に、すべての関係者が協力し、努力できる体制の実現に向け、「人を診る目線」を欠くことはできない。お互いのエゴや都合だけをぶつけ合うような関係の中で、優れたシステムなど出来上がるはずもない。
だからこそ、システム開発における要件定義というのは大切なのだと思う。
良い要件定義書は、クライアントとシステム開発会社が、お互いに深い理解と尊重がなければ完成しないものだからだ。
 
私はここに挙げた３つのエピソードに、間接的ではあるが関わっていた。
ここまで大上段から、その原因と考えられる要素を検証してきた。だが仮に、私がそれぞれのプロジェクトにおけるPMだったら、問題は回避できたのだろうか？
率直に言えば、難しいと思う。私も、自信はない。
この３つのエピソードに登場する課題は、どれも一筋縄ではいかない。各エピソードの課題を一発で解決する、カンフル剤は存在しないからだ。
 
この記事を読んでくださった皆さまが、これらの失敗例から、要件定義と「人を診る目線」の大切さを再認識し、自らが関わるシステム開発を成功させる、ヒントを掴んでいただければ幸いである。