顧客の価値を見出すには要件の詰め込み過ぎをしてはいけないのはなぜか

とある業務“も”担当していて、気づいたことがあります。これは、普通のシステム開発のプロジェクトであったこと。同じように組織内のプロジェクトでも同じようなことがありました。

顧客の要件は、“必ずやりたい(＝実現したい)要求”と“あったら良いなという要求”と“いらない”と3つに分別できるものです。その中で、“必ずやりたい要求”は、スポンサーの顧客がやりたいことなので「実現したい。」、「実現しましょう。」とバジェットの内輪である内は合意に至りやすいものです。あと、“いらない”は顧客もプロジェクトチームも簡単に合意しやすい要求です。

愚図愚図しやすいのは、“あったら良いなという要求”です。顧客に「やりたいですか？」と訊けばほとんどの顧客は「やりたいなー」って言うものです。基本的に要件は、実現する方から“何をやりたいか”聞いたら時間と予算の制約に負け(＝オーバーランするという意味で)てしまいます。

良いものにしたい気持ちとし過ぎた結果から得られるもの
プロジェクトチームもはやり人の子なので、顧客がやりたいと言うなら実現してあげたいと思うものです。端的に言えば、「時間と予算の限り何でも実現しますよ」、と言うもの。顧客のITリテラシが以前より向上したとしていたとしても、やはり、専門家ではないわけですからシステムのアーキテクチャやライフサイクルを俯瞰した目線での要求の折り合いはつけないものです。そこは、やはり専門家であるプロジェクトチームの役割になるわけです。

なぜなら、顧客は業務の視点でしか要求を出さないのだから。

そこがこれから実装するシステムを担うプロジェクトチームの所掌の範疇になるのに、顧客の要求を実現することが良いシステムを作ることだとしてしまうと、無理なシステムデザインになってしまうことも間々あるのも実際よく聞く話です。

顧客が要求することを専門家としての知見から助言をしなければならないことはわかっていながら、様々な言い訳を置いて。ここには、本当は必要でなかった機能を実装することも含まれるから、それは顧客が本来負う必要のない費用の負担をそのシステムをサンセットするまで負担させるということにほかなりません。

聴き方は顧客との関係があるのでそれぞれだと思いますが、顧客がそれを欲しいと言うならその要求がどの業務要求を由来とするか尋ね、その機能が何の業務の自働化の代替としてなすのかを丁寧に聞かなければならないでしょう。

顧客は早く手にしたい

顧客にとって、いつの時代でもシステム開発プロジェクトにかかる時間は、長すぎると感じるものです。形のない顧客の業務要求を形作りながらシステムとして実現するわけですから、不確かな曖昧さの中からステップを踏んで少しずつ確かなものに変えていくにはコンセンサスを儀式を介して形成しなければならず、それ自体仕方がないことです。

でもやはり少しでも早く見たい、手にしたい、業務として適用して効果を得たいという要求も、また、顧客は持ち合わせているものです。それならば、如何に早く顧客に届けるかという要望をプロジェクトチームは見捨てることはできないでしょう。

＃実際は、決まりきったやり方を変えないからその要望は見捨てられたままです。

実は、顧客の業務要件を実現したいという要望と早く手に入れたいという要望は、コンフリクトの関係にはありません。何を優先順位付けの判断基準とするのか、それさえ決めればよいことです。顧客が実現したい業務要件が出ていて、且つ、早く手に入れたいとするなら実現したい業務要件を早く手に入れたいとする期日までに実装できるところで諦めてもらえばいいことです。

やりたい、でも、いついつまでに、という要望があるなら実現する範囲を決める線引きの合意は至りやすいのです。

洗練の難しさ

顧客の業務要件は、業務としての要件ですから、システム化での考慮はされません。そこは先に述べたようにプロジェクトチームの範疇です。本当に実現したい業務要件があるなら、それはITの専門家として図面を引き、きちんとアーキテクチャを考えねばなりません。そこに、顧客の業務要件としての矛盾があるなら、それは「そうした事実がある」と客観的に伝え、どちらの業務要件が“優先順位”が高いかを問わなければなりません。

同じように早くという要望が存在するなら、同じように顧客の業務要件のリストを“今回の契約の中では”どこまで実現するかを線引きしなくてはなりません。そこには、先のシステムアーキテクチャとしての整合性の観点からの所見も必要になります。業務要件を線引きしたとき、システムで実現する機能のリストと自働化される業務が意味のある塊になるとは限りません。それこそ範囲にあるリストと、専門家として引いた図面にプロットした機能の重なりを見て、実現する機能のリストを洗練しなければ、使われない機能を実装する片棒を担いだことになるので注意が必要です。

そこにはエンジニアとしてのインテグリティが試されているのです。