現場との人間関係が苦手なリーダーが、やや逃げ腰で要件定義に取り組んだ末のシステム改修
掘り下げが不充分で、使用者たちが本当に必要としているディティールが伝わらないまま、額面どおりの改修が進む。
そのまま現場に投下したら反発が起こるのは必定です。
ただし・・
主としてその実務に携わるのが「外注さん」ならば・・
外注できない人間関係
もしも外注先の動きがギクシャクしていて、そこから上がってくる声（要望）の中に「システムの仕様が適切でない」というものがあっても、それは要因の一つにすぎません。
外注側が業務開始早々だと、明らかに不慣れなことをしているわけですから、ギクシャクする原因はほかにもたくさんある。
それらを指摘して、逆にこちらから外注先に改善を求めれば、少なくともシステムへの口出しはブロック・・というか手を付けないまま時がすぎるに任せて状況変化を待つという方法も採れます。
しかし前回記事に書いたように、私は早々に現場へ溶け込んでしまった。
しかも、準備段階から基幹システムにフォーカスし、データベース内のカラムを指定して格納データを貰って分析するなど、その会社の人ですらしないアプローチを経ていた私はその点を踏まえて、扱いづらい点を現場の人に伝える。
すると、現場からリーダーさんへの要望という、リーダーさんが苦手とする関係が生まれてしまう。
それどころか、これでは私たちが使いづらいだろうと、こちらで気づいていない点まで見つけ出してはリーダーさんへ改善要望を出してくれたりしました。
さすがは「実務重視の現場」です。
私にとってはありがたいけれど、リーダーさんから見れば外注先は ”●●に蓋” という働きを示さず、”クッション” にすらならない。むしろ現場の声の拡張機能として、思わぬ影響を及ぼしてしまったことになる。
状況によって ”要件定義のスタイル” は変化する
「実務に強いこと」が人間関係におけるキーサクセスファクター（KSF）なのが明らかな現場なので、主としてそこの業務の補強を目的とするシステム改修は、そのKSFを直截に指向するのが、どう考えても最も効率が良い。
机上の要件定義をあれこれ考えているよりも、私が現場に溶け込んで ”そこの会社の人” みたいな立ち位置を占めてしまったように、KSFを活かして操作時の手の動き、目の動き、心理の傾向をリストアップするのが得策で、それこそがユーザー側の ”おしごと” だと思う。
人との接触（ハイタッチな事柄）の得手不得手はシステム（ハイテクな事柄）が解決してくれるものではないし、そんな都合の良いシステムはどんなに優秀なエンジニアでも実装できません。
その問題を持ち越したまま改修の要件を話し合っても、ユーザーとエンジニアが分かり合うことは難しそうだし、どちらかといえば対立を生む確率のほうが高いと思います。
やはり、要件定義前にユーザーがしておかなくてはならないことが存在する。
・・というか「どこまでの効果をシステムに求めるか？」によって、ユーザーが越えなければならないハードルの高さが決まると言ったほうがよいでしょう。
組織は、その身の丈にあったシステムしか使いこなすことはできない。
なんでもかんでもハイスペックを目指すと扱いを持て余し、システムによって組織内に自家中毒が起こる。
やはり、そのように思うのです。
＜雑談は続く＞
