一般的に、システム開発はユーザーが要望を出し、エンジニアがそれを形にします。
いわば二人三脚で作り上げていくものですが、それぞれが担当すべき独自の事柄があります。
この「独自の事柄」の切り分けがうまくいけば、希望にかなり近いシステムが出来上がるはずです。
つまり、出来上がったシステムが期待通りのものでなかったとすれば、、それはユーザーとエンジニアの役割の切り分けに失敗しているということです。
そして私の感触からすればこの場合、切り分けに失敗しているのは圧倒的にユーザー側が多い印象です。
要件定義～失敗の入口
エンジニアは、ユーザーがエンジニアに伝わる言葉で表現できた部分を具現化します。
そういう役割だからです。
ユーザーの言葉が伝わらないとすれば、それはユーザー自身が自分たちの動体部分である末端の作業に関する掘り下げが甘いから・・というのが理由の大部分を占めます。
動体部分の動きを理解しないまま ”システムの働き” を考えるから、要件定義が会議上は成立しても「思ってたのと違うシステム」が出来上がる。
しかしなぜかユーザー側は、自分たちのこの現実を認めない。
それどころかエンジニアに対し「あの連中は言われた通りにしか動かない」と、あたかもエンジニアに問題があるかのように言い繕い、本当の問題点に対する自覚を持たないケースが多い気がします。
概ねこのような前提があると思ってください。
それでは続けます
要件定義の会議で「手段」が「目的」になる瞬間
要件定義の際に要望がうまく伝えられず、エンジニアが様子見程度に出した追加機能の案を鵜呑みにし
「その機能を追加すればうまくいきそうだね！」
という甘い見込みで成功を夢想するクライアント（ユーザー）たち。
オイオイ、機能追加によって影響を受ける他の動きの検証は？
これはエンジニアにとっては手慣れたもの・・
・・というか「その検証は必須」の認識がある。
それに対し、追加機能の提案にご執心のユーザーはどうか？
追加を受け入れた現場の ”実務的検証” のほうは、誰も考えないと言っても過言ではない。
なぜなら、検証要素や検証項目を具体的に考えられる実務担当者がその場に居ない。
締まらない会議が回数を重ねると、バリバリの実務者は現場の業務に追われて会議メンバーから外れていくためです。
そしてこのような追加機能の話は、堂々巡りを繰り返す会議を進捗させるために、シーズを持っているエンジニアからの提案として出されることが多くなる。
当初こそコスト増を警戒して追加の話は退けるユーザーたちですが、ここまでどっぷり浸かりこむと俯瞰する能力も発揮できなくなる。
そこに時間的制約が追い打ちをかけます。
＜雑談は続く＞
