システムをカットオーバーさせて「作りました」とアピールすることが終着点。
そんな人たちが目指すシステム開発（改編）のことを前回少し書きました。
この場合の恩恵を受ける ”システムユーザー” は、現場で物理的にそのシステムを使う作業者たちではないのが悲しいところです。
会社に行きたくなくなるシステム
鳴り物入りで開始されることの多いシステム改編。
しかし、「完成しても現場にだけは投入しないでくれ！」と言いたいような代物もあります。
変えること自体は目的に沿っているのだけれど、空論の土台に立ったようなプロセスで組まれているため、投入されたことによって現場が「対現実」と「対システム」の両面作戦を強いられるような、それ自体がハラスメントでは？と突っ込みたくなるようなシステム改編です。
ご自慢のそのシステム、観賞用にでもしといてくれませんか？
もちろん我々の目に触れない場所に置いて（アップして）くださいね🙏
なんて・・そんな出来栄えのものも、かなりの数が存在するのではないでしょうか。
予定調和会議（要件定義）は現場から浮いている存在
現場で扱いづらい
使うべき人たちからの評判が悪い
そんなシステムが生まれてしまう原因はむしろ「要件定義」という言葉とその扱い方ではないかというのが私の持論です。
「末端ユーザーの意見聴取を丁寧にやっていたら、いくら時間があっても足りやしない」
そんな事情があることは、充分理解できます。
実際に、末端でシステムを扱っている直接のユーザーが要件定義の会議に呼ばれず、責任者だけが代表して出てくるなんてケースは普通に有るし、私もそんな場に居合わせたことが有る。
でっかい会議室に、システム会社のメンバーも含めて4〜50人が一堂に介するような仰々しいキックオフの後に行われた会議では、毎回2〜30名程度の人間が集められて打ち合わせを続けました。
しかし「現場代表の責任者」は、毎日リアルに操作しているわけではないだけに、その発言にはあまり迫力が感じられない。
要件定義の会議では「ドブさらい」は論じられない
具体的に言えば、操作当事者の
「手の動き」
「目の動き」
「操作時の資料の置き場所」
「利用が集中した際のフリーズ発生数と時間」
「フリーズでシステムが動かない時、仕方なくしている別の行動」など、動体である末端作業員がシステムのスペックに影響される瞬間の行動や思考についての掘り下げが甘い。
そもそもそんなことは議題には上がらないのだから、あらかじめ充分にまとめて短いフレーズで表現し、「どういった機能でそれらがカバーされるか？」というワンコンセプトにしないとお話にならない。
なぜなら要件定義の会議であまり各論を言おうとすると「細かな点については個別に確認しつつ進めましょう」というセリフで強制終了されがちで、ありていに言えば「なかったこと」にされてしまいます。
ゆえに、ここでの掘り下げの甘さはその何倍ものインパクトを以て現場業務を圧迫することになります。
そこまで想像する人は、少なくともその会議の出席者の中には居ないのがフツーですが、現場にはフツーにその負担がのしかかります。
主張が強くても「それは力にならない」要件定義会議の特徴
いくら要件定義の会議で現場の問題点を主張したくても、とにかく長広舌は禁物・・
「そんなこと言われても、現場の諸事情をコンパクトにまとめて会議で発言なんてできない。オレは力技で道を切り開くぞ！」
そんな熱血で人情派の責任者が居たとしましょう。
末端の作業者から見れば、頼りになる上司です。
そして会議の場に出ても、ある程度は他人の口出しを封じつつ、熱弁を振るう度胸とパワーも持ち合わせていたとします。
ならばそうやって「強制終了」をさせなければよいのか？
そうではない。
そんな人は、私でも強制終了させるでしょう。
会議を上手く取り回すにはそのほうが良いに決まっています。
なにせ会議の時間は限られているし、各論を深堀りしすぎると無関係なメンバーにとっては無駄な手待ち時間が生まれてしまうので、この場合の強制終了には妥当性があります。
そして強制終了とともに、せっかくの熱弁は『なかったこと』になる
力学的に見て、そうなるのは当然と言えます。冷たいですが・・
＜雑談は続く＞
