コンサルタントの秘伝帖　「業務変革の王道メソッド」　第15回
「必要な機能は全部作りたい、だがしかし予算はない！！」

コンサルタントの秘伝帖
「業務変革の王道メソッド」
第15回
　
必要な機能は全部作りたい、
だがしかし予算はない！！
　
　
「システム導入に失敗しないための勘所」第4回です。
これまで「要求定義」フェーズの進め方について、
・まずユーザーと将来の業務を定義し、そこから将来の機能要求を決めること
・それをFM（機能一覧）、Function Spec（機能詳細）という形で見える化すること
・機能は「ユーザーとコミュニケーションできる粒度」「あくまで業務目線」「やらないことを含めて」書くこと
が大切、とお伝えしてきました。
　
今回は、機能の優先順位の決め方についてです。
　
以前お伝えしたように「欲しいものは全部作ればいい」というほど潤沢な予算と時間があれば話は別ですが、通常はそうはいきません。それに、機能の優先順位を決め、重要な機能から作り始めたほうが早く新システムを使い始められるし、コストとリスクを抑えられるし、いいことづくめです。逆に緩い優先度付けをして、なんでもかんでも「優先度高」にしてしまうと、社内の意見調整に時間が掛かり構築フェーズの立ち上げに時間がかかってしまうリスクにもなります。
しかし、将来のことについてじっくり議論をしたユーザーに「全部は作れないので、優先順位を決め、作る機能を絞ります」とお話しすると、「全部必要に決まってる」「うちの部署で使う機能が一番大事だ」などの意見が飛んでくることはよくあります。どうすれば、全員が納得いくように優先順位を決められるのでしょうか。
　

1. 優先順位を決めるための基準を作る

　
「機能の優先順位を決める」とは、具体的には「やること、そのうちやること、やらないことに仕分ける」ことを指します。ケンブリッジでは、仕分けの論理的（説明可能な）基準として、以下の3つを推奨しています。
　
(1)ビジネス・ベネフィット
その機能を実現することが、会社全体のビジネスの中でどれくらいインパクトがあるか。あるいはプロジェクト・ゴールの達成にどれくらい寄与するか。
　
(2)技術的容易性
その機能をどの程度簡単に作れるか。枯れた（昔からあり、安定性・信頼性のある技術やロジックで構成された）機能であれば容易性は高くなります。作られた前例がない、または作ることは可能だが高度に複雑である、といった機能であれば容易性は低くなります。
　
(3)組織受入態勢
ユーザーにその機能を使う準備ができているか。例えば、その機能を導入するにはビジネスルールの変更や大規模なユーザー教育が必要なら、受入態勢が低い、ということになります。
　

2. 各基準に対してレイティングを定義し、機能を評価する

　
これらの基準に対してHigh/Middle/Lowの3つのレイティングを定義します。レイティングの内容はプロジェクトによって変わりますが、レイティングを実施する人（主にユーザー）が、客観的に判断可能な切り口を採用します。
例えば、ビジネス・ベネフィットなら、以下のようにレイティングを定義します。
　
High：以下のいずれか一つ以上に当てはまるもの
・その機能がないと業務が成立しない
・トータル20時間以上の工数削減を見込める
・内部統制、またはコンプライアンス上不可欠
　
Middle：Highにあてはまらず、かつ以下のいずれか一つ以上に当てはまるもの
・その機能がなくても業務が成立しないわけではないが、非効率である
・トータル5時間以上の工数削減を見込める
・ミスの削減に寄与する
　
Low：High、Middleのいずれにもあてはまらないもの（あると便利なもの）
　
　
次に「H/H/H」と「L/L/L」の間にあるさまざまな組み合わせのどのパターンを「やること」「そのうちやること」「やらないこと」に仕分けするか、を決めます。プロジェクトの規模や予算に応じて、判断の基準は変わってきます。
　
　
並行して、決めたレイティングに基づき各機能を評価します。すると、FMは次のようになります。
　
　
これらの作業から、機能の優先順位の全体像を明らかにします。
　
　
3つの視点の組み合わせにより、優先度が高い機能と低い機能が明らかになったのがお分かりでしょうか。
　
　
このプロセスに正解はありません。
機能要求定義に関わったメンバーがひざを突き合わせ、優先順位を決めるための基準とレイティングをきちんと定義し、粛々と仕分けを実施していきましょう。仕分けを実施した結果、あまりにも「やること」が増えてしまい、もう一度レイティングを見直す、といったケースもあります。だから正解がないのです。
　
議論のプロセスを丁寧に記録し、納得感の醸成と振り返りを繰り返しながら進めることが極めて重要です。
「なぜそう仕分けたのか」を記録に残していないと、そのプロジェクトに新しいステークホルダーが参加したときに納得のいく説明ができませんし、プロジェクト終了後に機能を拡張（「そのうちやること」に該当）していく際、その妥当性を証明することができません。
また、プロジェクトにはイレギュラーケースがつきものです。例えば評価の結果、機能Aは「M/L/H」で「そのうちやること」になってしまったとします。しかしメンバーの一人が「他の機能はよいが、機能Aだけは『やること』にすべき。なぜならば・・・」と説明し、他のメンバーがそれに納得したならば、機能Aを例外的に「やること」にすることもあります。こういうケースは必ず起こりますし、その検討のプロセスを記録しておかないと、後から「なぜ機能Aだけが例外的に採用されたのか」といった質問に即座に答えられずクレームにも発展しかねません（もちろん、例外が増えるのであれば、そもそもレーティングを見直すべきです）。
　
　
　
企業のシステムはこの先何年にもわたって使うものです。
今は作らないけれども来期以降に作るものも、機能要求を決めるのに必要なメンバーが揃っているこのタイミングに議論し尽くしたほうが効率的に決まっていますし、予算取得の際の強力なエビデンスになります。ぜひ丁寧に機能をリストアップし、それらの優先順位を決め、「そのうちやること」についても、プロジェクト後に丁寧にメンテナンスしていくことをお勧めします。