前回、追加要素の予算を渋ったために「現場が動かなくなる」という事態に直面して慌てふためいた上層部が、結果的に人員追加を余儀なくされて人件費増大を引き起こしたうえ、やっぱりシステムの改修まで必要になってしまう・・という、どこかで実際に起きていそうな想像話を書いてみました。
増員など論外だとばかりに現メンバーを脅してこき使う、ドス黒いブラック企業でないぶんだけマシかも知れませんが、こういう「安物買いの銭失い」みたいなこともまた、それによって振り回される現場からすればやめていただきたいことではあります。
追い込まれるまではエリート然としてこれみよがしに余裕を見せつけ、でも切所に至ると盛大な狼狽ぶりを見せる、ドラマや映画でおなじみの振る舞いをする人は、システムの話に限ったことではないけれど結構見受けられました。
ちなみに私はネガティブな意見が少なすぎる要件定義の会議は、どこか嘘っぽく思えて仕方ないのですが、それはこんな見せかけのエリートが潜んでいるリスクを疑っているせいかもしれません。
”実務の強者” で構成された要件定義会議は・・
システム会社に対し、クライアント側が交渉材料として持っていると強いのは
「現場の動体をどう束ねて機能化すればよいか」
について、クライアント自身に充分な情報とイメージがあることです。
エンジニア側からは、本当の意味ではそこへ踏み込めない。
だからその領域に関しては、基本的にユーザーから教わってパッケージの組み立てやプログラムコードの参考にします。
「交渉の土台はそこにある」ということを共通認識にしてしまえば、システム会社に対しては常に「あなたの会社ではこれを実現できるか？」式に問いかけるスタイルに持っていける。
プロに諮問する手法
役人の世界では「諮問」という言葉がわりとよく登場します。
”大臣の諮問機関” みたいなフレーズです。
特定事案に関して専門機関に問うて答えを求めるもので、検討会などはそのための有識者を組織してお抱えの状態にするものですが、ようは「政策に必要な情報をまとめよ」といった感じのものです。
要件定義の段階では、この「諮問」をイメージしても良いかと思います。
専門者たちの意見を吸い上げて、業務全体を策定する。
つまりどこまでを機械化し、どの部分は諦めて人力に頼るかのトレードオフによって、現場の業務体制を固めていく感じでしょうか。
説明するクライアントは「値踏みされている」と思うべし
私の経験上、業務説明がＷＢＳ（ワークブレークダウンストラクチャー）式になっているとエンジニアには理解しやすいらしく、「概念」ー「段取り」ー「実作業（動作）」の順番に話を進めてゆき、段取りから実作業へ下がるにつれてボリュームが明示されていくように話すとスムーズにコミュニケーションできたように思います。
主題は「システム開発」なので、本来はクライアント（ユーザー）が踏み込みづらい技術畑の話が常にすぐ横を流れている状況なのですが、逆に、その中で主導的な立ち位置を保ちつつ会議を仕切っている「感」を演出できると、出席メンバーのモチベーションアップにも結構な効力を発するようです。
しかしこれは、意外にやれそうでやれないことだと思います。
技術者相手に「システムの話」をするゆえ、やはり気後れするのでしょうか？
二の太刀が出せるかどうかで「さらに値踏みされている」と思うべし
ちなみに、こちらがそんなスタイルで臨んだ場合、システム会社からの返しとして「こういうことは可能ですが、御社の業務はそのように統制可能ですか？」という反問が想定されます。
あちらはあちらで触れづらい「クライアントの実務」に、技術を突破口にして踏み込み、自分たちの言い分が通りやすくなる道を作っておく。
これは戦略的に重要なことですから、随所でその程度のことはしてくるでしょう。
先程私は ”諮問機関” なんて単語を使いましたが、システム会社からすればそれは失礼な話かもしれません。
「我々は諮問機関じゃない。ビジネス上の対等な関係だ！」という段階すら通り越し、ソリューションの提供者として客より上位の存在とした誇りを持っていてもおかしくはない。
そのプライドの前には、我々は ”指導を受ける側” ということになります。
そしてこの「誇り高き返し」への対応のときこそ、クライアント側の交渉材料たる ”実務への高い精通度” が最も効果を発揮するはずです。
ちなみにこのタイミングで「出がらし」しか会議に出席していないと致命的です。
「出がらし」についてはこちら⇩でふれています
逆に、このタイミングで実務系のしっかりしたメンバーが出席していれば、システム会社の返しに対してさらなる返しも可能で、それによって追及（問いかけ）を重ねられる。
宿題を「課す側」になるか「課される側」になるか？
もしもその場で形ある回答ができず「持ち帰ります」の数が嵩めば嵩むほど貸借の関係が如実になる。
意図的に「持ち帰る」戦術を採っているのでもない限り、スカッと答えられないまま押され続けた側は、その分宿題が増えてしまうということでもあるので、モチベーションは下がり、負けの心境に陥るかもしれませんが、駆け引きだと考えれば妥当でしょう。
当然両者ともYes／No式の問答を仕掛けるため、ここで国会答弁のようなことをすればすぐにお里が知れる。
真剣勝負で大変ですが、「だからお互いにプロなんだろ？」とも言えます。
しかし、実のある問答が展開されればその流れはエンジニアにはわかりやすいし、会議の場で一定の形ができてコンセンサスも得られやすい。
ということはやはり、「現場の動体をどう束ねて機能化すればよいかのイメージ」を詳しく持っていればいるほど、要件定義の会議でユーザーは ”強者” になりやすいのは間違いなさそうです。
＜雑談は続く＞
