これはシステム要件における顧客が求めているものと実際を揶揄した図ですが、現実に要件が求めているとおりに実装されることはまれだったりもします。
要件定義書に書かれたシステムイメージは非常にシンプルでも、仕様を詰めていく段階でどんどんと盛り込まれていく機能。
作り上げられたものは当初の要件からとはかけ離れたものになっていた、なんてものはシステム開発においてよくある話で、契約のもめごとや開発遅延の話は置いといて、なんでまたこんなに仕様が複雑化していくのでしょうか。
現行業務を頑なに変えようとしない
一つは現行業務への固執ではないでしょうか。
現行業務における課題を解決すための手段としてシステム開発を行うものの、その業務があるべき姿かどうかについてはあまり議論されないケースがあったりします。
つまり、現行業務に合わせてシステムが作り上げられるので、業務に内在する課題もそのままシステム仕様として実装されることになります。
現行業務を変えたくない理由は、それによる影響が大きく自分たちの変化を嫌い、システム化すれば何とかなるんじゃないかという幻想を抱いているからかもしれませんが、それによって出来上がるものは一部の業務フローが自動化されるといった具合のもので、業務全体として効率化がなされるわけではなかったりします。
業務は長い年月をかけて作り上げられたものにはなるので、システム仕様もその分さまざまな役割を担う必要性が出てきて、これはいらないんじゃないかという要件が顧客の強い要望で実装しなくてはならなかったりします。
マイクロマネジメントを実現するための機能群
せっかくシステムで自動化されるのにかなり細かいハンドリングを要件として組み入れたがるケースがあったりします。
当然それによって担当者の運用業務は膨れ上がることになるのですが、当人は「それはこちらできちんとやるから問題ない」とその要件で押し切ろうとしてきたりします。
これは、例えば通常ではなかなか使わないであろう特殊な権限設定を必要としてきたり、データを直接的に編集できる機能を求めてきたりといったことなんですが、せっかく自動化する仕組みを作ろうとしているのになぜ手動でのオペレーションが必要な要素を盛り込みたがるのだろうか、と思ったりするわけです。
こういうケースの場合、運用が始まってしまったらその業務が思いのほか大変であることがわかって泣きついたりしてきたりもするのですが、そうではないとしてもシステム化によって得られた効果がその仕様のために台無しになっているのではないか、と思うケースも見受けられたりします。
担当者のこだわり
プロジェクトの推進体制上、オーナーであったりPMであったり中心となる人物はいるもので、その人の思い入れの強さで思わぬ機能実装が盛り込まれたり、仕様変更を求められたりすることがあります。
これはその人だけのこだわりであったりして重箱の隅のようなところに時間を割かれたりするわけですが、構築側から見るとそれがその人だけの思い入れなのか、それとも実際に現場メンバーやユーザーが求めているものなのかわからないことがあったりして困ったり。
特に権限が強い人のこだわりとなると、その他の推進メンバーも意見するのをためらって押し切られたり、プロジェクトの後半になったレビュー会で放たれる言葉によって現場が凍り付いて大きくかじ取りを変えさせられるケースもあったりします。
その人の単なる思い付きであれこれ仕様が決まってしまうと、これまで業務フローや課題を整理したうえで組み立てた仕様が崩される形になって、最終的に歪な機能を作る羽目になったりもするわけです。
流行りものの全部入り
一昔前なら、システム仕様を検討するのは構築側にかなりの比重があったわけですが、それはシステムという理解をしている人材が一般的には多くなかったからなんですけど、今やインターネットを通じて日常的に様々なサービスを使ったり見たりしている人がほとんどなわけで、当然システムの仕様について目が肥えた人が多数体制上に存在したりします。
こうなってくると、普段使っているような流行りものを全部取り入れたがる意見が出てきたりして、スモールスタートで息を長くサービスを育てていきましょう、というような方針でも最初っから全部入りでお願いしたい、といった方向になってきたりもします。
フェーズを分けて徐々にやっていこうとしても、それぞれの立場で必要な機能が違ってきたりして、あれもこれも必須機能という要件が出来上がったりするわけです。
まぁ、たとえそれらを全て実装できたとしても使いこなせる人は少なく、結局ごく一部の基本機能しか使われないということはよくあることだったりもします。
余計なリップサービスが招く墓穴
顧客に対してサービスの説明やシステム要件を確認する場では、なかなか「できません」という表現をしたがらない傾向があって、拡張すればできるとかアドオンを入れればできるとか連携すればできるとか言ってごまかしたりするわけです。
それを導入するために基本料金に加えてかなり多額のカスタマイズ費用が発生したりもするわけですが、実際にはできないケースが多かったりして、打ち合わせの場での言った言わないに引きずられてかなり多くの労力をそのために強いられることはよく遭遇する場面であったりします。
また、顧客を喜ばせるためかより多くの機能提案をしてしまうケースもあって、先ほどの全部入りの話のようにあれこれと機能を盛り込ませようとしたりして要件が膨れ上がっていったりもします。
もちろん、これは費用が比例していくことにはなるので予算に合うかという問題はあるにしろ、「あれもできます。これもいかがですか」といえば顧客側からするとお願いしたい気持ちにもなってしまうわけです。
それを受け入れられるだけの構築側の体制が整っているのかという問題は度外視して。
まとめ
個人的には機能や仕様はできるだけシンプルなものであるべきだと考えています。
複雑な機能を求めてもそれを使う機会って年に何回あるの？って思ったり、その複雑な機能を使いこなすための労力って本当に必要なんだろうかと疑問に思ったり、それを作り上げるコストに見合うだけの効果が果たしてあるのだろうかと思うことがあるからです。
最初の図のように作りたいものや解決したい事象というのは実はとてもシンプルなものだというのに、実際に議論を積み重ねていくと要求が膨れ上がったり、捻じ曲げられたりして作り上げたものは誰が望んだものかわからず、そして本当に求めていたものさえ誰も気が付いていないというような事態になるのは互いが疲弊するだけなので避けたいところですね。
関連記事