システムを作る場合に「あーだこーだ」と議論できる時間は長くありません。
たとえばシステム改編だったら、現行システムの保守期間満了が期限になっているのが大半のはず。
ゆえに要件定義会議のテーブルを囲む全員にとって、堂々巡りで時間が過ぎていくのが何よりもまずいという共通認識があります。
「麻酔が効いてる部位のケガ」に似たシステム会議
どうせ行き詰まるなら、もっと早く行き詰まっていれば・・
開発の期限が近づいてもなお行き詰まる話し合い。
会議参加メンバーの顔ぶれも当初とはずいぶん変わってしまった。
初期の頃に参加していたメンバーが残っていたら、もっと現実的で建設的な意見が得られたかもしれない。
「現場の痛みを感じない人」が現場に関することを決めるな
「動体（たとえば顧客接点）の動きの変革」が目的にも拘らず、現場とは無関係のメンバーで行われる「机上議論」
しかもそれが延々と続く会議はどうしても肝心なところの掘り下げが足りず、想像力も欠如しがちなため着地点がはっきりしなくなる。
決め手を欠くまま繰り返されるうち ”真の現場感” が強い人は実務に手を取られて出席が難しくなってくる。
つまりは、現場の痛みが理解できる人から順番に淘汰されてしまう。
そしてだんだん『単なる会議メンバー』になってくる傾向はあると思います。
いわゆる「スタッフ」と呼ばれる企画系の人たちが、会議を担っていくことになる。
口が悪い言い方をすれば「机上系の人たち」とでも言うのでしょうか。
だいたい予想がつきますよね
どんな「ドラマ」が展開されるか・・
おまけコラム
キリが良いので今回はここで終わりますが、ここでちょっとオマケをはさみます。
システム会議でキックオフが開かれることがあります。
関係各部署から参加メンバーが勢揃いし「今回の開発はこの顔ぶれでやっていくのだな」とはっきりします。
規模が大きいとシステム室も分野ごとに担当を分け、ユーザー側も「営業系」「経理系」「人事給与系」などに開発部位を分けての分科会形式になったりします。
システム室のチーフとクライアント側のチーフがプロジェクトマネージャー役を果たすのは良いのですが、こうなると一種の「経営」に近い。
当然ながら掌握の難易度は上がっていくことになります。
「プロジェクトチーム運営」という別のお仕事が発生している
分科会での話し合い結果を受けて機能同士をコネクトさせる部分では、チーム編成を変えて別会議が持たれたりします。
このやりくりが行われるプロジェクトがいかに難しいかということを考えると、逆に、末端の作業員の意見がいかに通りづらいものかということがうかがわれます。
システム開発では、特に規模が大きくなると自社での開発なんて到底無理な話で、システム室を窓口にして、分野（パッケージ）毎に別会社の協力を仰ぐことになるでしょう。
つまり、プロジェクトチームといってもユーザー側のそれとは桁違いに足並みが揃えづらくなる。
システム開発プロジェクトが、それだけで評価される理由
役員たちに監視されながら全ての関係者の意見をまとめ上げるのが、システム室の幹部と、ユーザー側の代表者だったりします。
かなりのコミュニケーションスキルが、それはそれはシビアに求められます。
たしかにこれを成し遂げたら、それ自体が手柄になるというのも理解できます。
それでも「使えないシステムで迷惑を被る現場」は、納得できるものではない。
ということを、改めてひとこと挟んでおきましょう。
＜雑談は続く＞
