なぜ要件定義の結果はぱっとしないのか？〜情シス目線のプロジェクトマネージメントTips#09　

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

現状維持＋αくらいの要件

古くなった情報システムを刷新するとか、新しいビジネスに対応していくためにシステムの再構築や開発がされる場合には必ずと行っていいほど「要件定義」の作業があったりします。

その業務に直接関わる人や管理する人、そして経理や営業など関係する業務に関わる人が集められプロジェクトチームが結成されてたいていは情シス部門や企画部門のファシリテーション、お金がある場合はSIerの常駐工程担当やコンサルが入って要件定義が実施されます。

沢山の人が動員され、お金と時間をかけて要件定義は行われるわけですが、なぜかその結果はなんだかしょぼいものが溢れています。

要件定義では膨大な業務フローやチャートなどの資料が生産されるわけですが、要件定義の価値は情報量の多さでも無ければその緻密さでもありません。大事なことは全く別のところにあります。

要件定義の価値は「その結果としてどれだけビジネス価値を生むか？」なのです。資料の多さでも調査の緻密さでもなく、ましてや「後戻りが発生しないこと」でもありません。

ビジネス価値を産まない要件定義は全くの無価値なのです。

それなのに何故か出てくる要件定義の結果は「現状維持＋α」なのです。

集まった人が無能だからなのか？

「社運を賭けたプロジェクト」というほどでなくても、そういうプロジェクトはお金がとてもかかります。要件定義のために集められるメンバーだって組織の中では優秀な人たちが集められます。SIerやコンサルからの人たちも大抵は単価の高い優秀な人達があつまります。

もちろん組織長の無関心で「要らない奴」がプロジェクトに参加させられること（これはとっても困りますが）もありますが、大多数は各組織を代表する「優秀な人達」の集まりなのです。

でも、何故か出てくる結果はビジネス価値のたいしてない「現状維持＋α」になってしまうことがほとんどなのです。

集まった人が優秀なのになんで優秀な結果が出ないのでしょうか？

馬車から自動車への発想転換

If I had asked people what they wanted, they would have said faster horces.

「もし、人々に”移動手段として何が欲しいのか？”と聞いていたら、彼らはもっと速い馬が欲しいと答えただろう」

こういう話をするとよく出てくる「馬車から自動車への発想転換」の話です。２０世紀のはじめに自家用自動車の市場を切り開いたフォード社の話で、馬車を利用している人の意見を聞いても早い馬とか乗り心地の改善みたいな馬車の改善の話しか出てこない・・・・・それでは革新的なことは生まれない・・・という話です。

まさに「現状維持＋α」にしかならないというわけです。

この話はフォードという「売る側」だから、商品開発やマーケティングでもない我々には関係ないし、我々に与えられたテーマは特定の業務の話であって、そんなにダイナミックには変わらない・・・・と思うかもしれません。しかし、少し立場を変えてみて「馬を使う事業」の人でも全く同じことが言えます。「どうやら自動車ってのを使ったほうが輸送が効率化するみたいだぞ」・・・・という観点は必要なのです。

では何が足りない？

では「現状維持＋α」にしかならない要件定義のプロセスには何が達無いのでしょうか？奇策を考えても仕方がないので基本的なところに立ち返ってみましょう。

プロジェクトの対象の業務を分析するには各プロセスの要素をちゃんと分解して整理する事が重要です。一般的には各プロセスは「インプット」「機能」「アウトプット」に分類されます。

インプット　　⇒　　機能　　⇒　　アウトプット

これを「要件定義」というプロセスに当てはめてみます。

たとえば「機能」であれば「ファシリテーション」とか「業務フロー作成」などが当てはまり、「アウトプット」なら「ビジネス勝ちがあるアイデア」や「アイデアのフィジビリティ」や「組織のコンセンサス」になるわけです。

要件定義を強化しようと言う場合にはたいてい「機能」の強化が行われます。コンサルを雇ったり、ファシリテーションを工夫したり、ヒアリングにツールを使ったり、プロセスマイニングを導入したり・・・・そして価値のある「アウトプット」を求めようという作戦です。

しかし「インプット」はなかなか注目されません。

このインプット考えてみると現場や管理部門の人をいくら集めても、全力でがんばったとしても、用意されるのは

・現状の業務に関する知識
・現状の業務を行う上での課題、問題点

だけなのです。馬車の例に例えると

・馬車の乗り方、馬の制御方法、馬の管理方法、良い馬の選び方
・良くない馬に当たる問題、馬車が古くなること、道が悪い

いくら考えても「自動車に乗り換えよう」にはならないのです。

ついでに更にたとえると

サバと米では大トロの寿司は作れないのです。作れるのはせいぜい「美味しい鯖寿司」だけなのです。

インプットを変えるには？

つまりはこのインプットを変えないとビジネス価値を生む要件定義にはならないのです。

手っ取り早いのは「外から人を連れてくる」です。社員を入れ替えてしまうのもいいかのしれません・・・
しかし特定の人に頼るのは非常にリスキーで持続性はないですし、社員を入れ替えるなんて日本では無理ですし、そんな事をしたくはないはずです。

そうなれば出来ることはただひとつです。
要件定義をするメンバーに充分な情報を与えることです。改善に繋がりそうな様々な道具（クラウドサービスとかAIとかIoTなどなど）の知識とか、同業他社の事例や動向、似ている業種の事例、マーケットの状況などなどたくさんのインプットを与えることです。そしてそういう新しいものに対するオープンな姿勢を作っていくととしかありません。

「なんだか自動車ってやつを使うと輸送コストが下がるらいいぞ」

要件定義の場でこういう話し合いがされるようにする準備が必要です。

しかしながら、いざプロジェクトとなったときに、そんな時間はなかなか確保できません。短期間で結果を出していこうというのであれば、こういった事は日常の中で行っておくことが必要になります。

よくＤＸをはじめるには組織風土から・・・・

という話をよく聞きますが、やはりこういった「目は外を見る」という風土を作っていかないと「現状維持＋α」な要件定義にしかならないのでしょう。