システム構築の失敗はFMで防ぐ、あるいはなぜ僕らは要求定義でこのツールを愛用し続けるのか？

システム構築プロジェクトの成功率は低い。
失敗する原因の多くが、
・関係者が「あれもやりたい、これもやりたい」と主張し、収拾がつかなくなる
・必要性が薄い機能まで作ってしまい、コストオーバー
・いったん作る機能を決めたにもかかわらず、後のフェーズで変更が頻発する
といった、要求定義にまつわるものだ。要求定義がシステム構築プロジェクトで最難関、最重要だと言われるのはこのためだ。

この問題に対処するため、僕らの会社ではFM（ファンクショナリティ・マトリクス）と呼ぶツールを使っている。

ご覧のように機能がずらずらと並んでいるので、紹介すると「こういう機能一覧なら、プロジェクトでよく作りますよ」という反応が返ってくる。
確かに本質的には機能一覧でしかないのだが、実はこの何気ない表が、システム構築で最大の難所と言われる要求定義（要件定義）を劇的にスムーズにする力を持っている。ひいてはプロジェクト全体の成功の秘訣でもある。
だからこそ、「システムを作らせる技術」では1/4にあたる90ページも使って、FMの作り方を詳細に説明した。


このブログでは、「システムを作らせる技術」のL章を転載して、なぜFMがシステム構築の失敗を防ぐのか、丁寧に説明してみよう。

★FMの効果①Scopeが明確になる
物事をハッキリさせることを慣用表現で「白黒つける」と言うが、FMでは文字通り「最初に作るものは白、それ以外はグレーや黒」と機能一つ一つを白黒で塗り分ける。作るのか。作らないのか。１回目の稼動でこの範囲、２回目はこの範囲・・。そこに曖昧さは一切ない。

Scopeフェーズ以降、プロジェクト計画はいつもFMを見ながら立てる。最初の稼動に向けて集中すべき時期に、グレーや黒の機能に脇見していないかチェックするのも、プロジェクトマネージャーの仕事になる。

★FMの効果②やらないことが書いてある
実は効果①の一部なのだが、あまりに重要なので分けて説明したい。例えば、予算の都合で機能Aと機能Bのどちらかしか作れない状況を想像して欲しい。この時ユーザーに確認する方法は2種類ある。
「Aを作ります。いいですね？」
「Aを作りますが、Bは諦めてください。いいですね？」
ユーザーがどちらに対してもYesと答えたとして、後から揉めにくいのは後者だ。前者の場合、結構な確率で後からユーザーが「え？Bないの？なんで？仕事回んないけど、どうしてくれんの？」と言い出す。
わたしは前者を「脆弱なコンセンサス」と呼んでいる。一応Yesとは言ったものの、堅くないのだ。

だがほとんどのITエンジニア、ITベンダーは、「Bは諦めてください」の一言を言えない。言ったら嫌な顔をされたり、反論されるのがわかり切っているから。誰だって会議は早く終わらせたいし、言い争いを避けたい。たとえ後で揉めることになっても。

実はFMで機能をグレーに塗る行為は、「Bは後回しになります。いいですよね？」と言うの同じ効果がある。同様に黒に塗ると、「Bは作りませんよ。いいですよね？」と言うのと同じ。

不思議なことだが「諦めてください」と口で言うより、FMを黒く塗る方がずっと心理的負荷が低い。全体最適やコストカットの観点から、ユーザー自身が塗ってくれることもある。FMはコミュニケーション下手なエンジニアを助けるツールでもあるのだ。

もし機能Bが黒く塗られているのを見たユーザーが「え？Bが黒なの？仕事回んないんだけど」と言い始めたら、レーティングが妥当ではないのか、ユーザーが大げさなだけのどちらかだ。改めて諦めてもらうか、予算を増やすのか、冷静に議論すれば良い。後から発覚して大騒ぎになるよりはずっとマシだ。

★FMの効果③一覧性
FMは機能の一覧表だが、縦横に並んでいるので大抵のシステムはA3一枚に印刷できる。全社基幹系のような、機能が多いシステムの場合でも3,4枚がせいぜいだ。だからひと目で全体が把握できる。
・どのくらいボリュームがあるシステムか？
・システムのこの領域はパッケージA、こちらはパッケージBで実装できそう
・メンバーAさんが担当する領域はここからここまで。随分広いな・・
などなど、ひと目で見られることで、考えたり把握できるようになる。

システムは住宅と違って目に見えないから、考えにくい。他人とコミュニケーションするのはもっと難しい。このことがシステム構築プロジェクトの難易度を上げている。だから、ひと目でおおよそ把握できることの価値はとても高いのだ。

★FMの効果④作成過程が後から見える
FMは誰がいつ何を決めたか、ガラス張りの状態で作っていく。
さらに、完成したFMを後から見返しても、作成プロセスがおおよそ把握できるようになっている。FMには機能ごとにレーティング結果が小さく書いてある。ビジネスベネフィット（機能の価値）がHighであれば、恐らく業務が効率的になることを評価されたんだろうな・・。だから最終的に真っ先に作ることにして白く塗られているのだな・・。という具合に、想像できるのだ。

プロジェクトで機能の優先順位付けの議論は1,2週間で終わってしまうが、システムは5年10年と使っていくものだ。だから後から見返しても経緯が想像でき、納得しながら使ってもらえることが重要になってくる。


★FMは要求定義以降も使い倒す
完成したFMの最大の用途は、システムを作る人（IT部門やITベンダーなど）に開発を依頼することだ。「プロジェクトチームの総意として、今回作って欲しい機能はこれです！」と明確に伝えられる。
だがFMの用途はそれだけにとどまらない。

FMによってシステム構築の対象範囲は明確になった。だが、プロジェクトの進展とともに、その範囲は残念ながら変わっていく。例えばアテにしていたパッケージ機能が、いざ設定してみたら使い物にならないことが、しばしば判明する。
想定が間違っていたのだから、優先順位付けをやり直す。すると当初白く塗られていた機能が、グレーになるかもしれない。その場合は必ずFMのレーティングとステージ分けを更新しておく。常に最新に保っておくことで、いつでも「僕らが作っているのはここ！」と説明できる。とかく方針がブレがちなプロジェクトでは、これが大切なのだ。

■設計、開発
当初は思ってもみなかった機能について、「新たな機能を足したいんだけど」「○○の機能がFMに載ってすらいないのはおかしいのでは？」と横やりがはいる場合もある。そういった場合も、逐一FMに載せ、レーティングし、開発するかしないかを明確にしていく。こうして、要望を野放図に開発するのではなく、一旦受け止めてから、常にFMに照らして合理的に判断する。こうすることで、要求の肥大化を防げるはずだ。


■説明会にて
システムが完成したら、ユーザーにたいして説明会などを開くが、この時にもFMをざっと説明する。
要求定義で出た意見や疑問を、説明会で現場のユーザーからも言われることは多い。「○○の機能が欲しい」「××の機能はなぜないのか？」と。こうした質問には丁寧に回答し、納得してもらう必要がある。それには、結局のところFMをどう作ったのかを説明するのが手っ取り早い。現行FMと新しいシステムのFMを比較しながら説明するときもある。


■稼働後
最初の稼動が落ち着いたら、先送りにしてあったグレーの機能に着手しよう。これをやらないと、嘘つきになってしまう。プロジェクトメンバーが現場から恨まれるだけならまだ良いが、「先送りにする≒作らない」と関係者が思い込んでしまうと、もう二度とシステムを段階的に作るプロジェクトをやれなくなってしまう（そういう会社は結構多い）。
ただし1回システム開発を経験したことで、採用したパッケージや業務への理解は以前よりも深くなっているはずだ。だからレーティングや優先順位に変更があるケースは珍しくない。改めて関係者を集め、短時間で検討し直したほうが良いだろう。


以上のように、ただの機能一覧にみえるFMはシステム構築のトラブルの芽を的確に潰せるように作られているし、要求定義だけでなく、その後のプロジェクトを通じて使い倒していく。

このブログでは「FMの何が優れているか」を紹介した。
だがFMがどんなものなのか（例えば優先順位基準の1つである"組織受入態勢"とは何か？）についてはほとんど説明していない。
そして、FMを作る手順やコツについても、1回のブログに載せるには手に余る。何しろ本では90ページに渡って解説しているのだから。
なので「ふーん、FMというツールもいいかもね」と思ってくださった方は、ぜひ「システムを作らせる技術」を手にとってほしい。