Stories 12話：制御不能の案件達
さて、前回までの話で
減ることなく増え続ける会議に対しての出席を強要され
その回避策として、私にすべての会議を集約する
という手段を取ったわけですが、その結果
私の時間はすべて会議に埋め尽くされることになりました。
これは誇張でも何でもなく、本当に朝から晩までずっと会議という状況です。
かろうじて空く30分とかは、各種設計書やテストのレビューで埋められ
本当に一切の誇張なく、私は定時内（もしくは定時後も）ただただ人の話を聞く、
もしくは人に報告をするだけの人になっていました。
これにより何が起きるかというと
自チームのタスク管理ができず、チームの負荷コントロールが出来ない
業務知識をキャッチアップする時間が取れないので、いつまで経っても知識が追い付かない
感覚的にチーム全体が過負荷になっていることはわかるが、案件の発生を止めることができない
というようなことが起き始めます。
発生する案件の処理自体は導入から入っているコンサルティングファームに任せていたのですが
彼らも運用保守が素人という事もあり、ユーザーが言ってくるものを
すべてそのまま受け入れようとするためリソースと案件のバランスが取れなくなっていました。
コンサルのリソースはコンサルのリーダーに任せている為に、
受け入れているという事は大丈夫なのだろう
と思っていましたが、単に断る術を持っていないだけでした・・・
この為、
リソースに限りはあるが、Inputはどんどん増え続け
私もキャッチアップの時間が取れない為、戦力にならず
リソースの拡充もできないから、メンバーの首がどんどん締まっていく・・・
となり、状況の悪化に歯止めがかからなくなっていきました。
本当は私的にはまず、
という思いがありましたが、
なにしろ、会議に出ているだけで、業務知識が一切つかないので
ユーザーの出してくる案件の優先度をつけることが出来ません。
そもそもユーザーというものは出してくる要求はすべて最優先
というような口ぶりで振り出してくるのですが
ちゃんと話を聞いたらそこまで急ぎではないものや
整理をしたら後回しにできるものがごちゃ混ぜになっていることが多く、
そういったものを取捨選択したり、ユーザーと折衝して後回しにして
メンバーの稼働率をコントロールするのがリーダーの役割なのですが
これが私にはできないというか、出来るようになる見込みすら立たない
更には、システムの事がわかっているコンサルのリーダーにもそれを期待できない
という事でしたので、本当はやりたいこのアプローチを諦めざるを得ませんでした。
そうなるとどうしたらこの状況を快方に向かわせることが出来るか・・・
考えたのは永遠に案件が発生し続けることはないはずなので
一時的に無理やりリソースを拡充する
という方法でした。
といっても、
他所から人を持ってきても、
事情も分からぬまま、いきなり戦力になることはありません。
それは私の状況を見ても明らかです。
しかし追加した人たちが戦力になるまで待つ
というほど、時間的ゆとりもありません。
そこでとった手段は
でした。
どうしたかというと、まず
協力会社として参画してもらっていた開発メンバーに上流工程になる要件定義や設計などを手掛けてもらいます。
それにより穴が開いた開発のリソースは別途調達する
という方法でした。
開発自体は設計がしっかりしていれば
比較的走り出しやすいので、ここは新しく追加したメンバーに担ってもらいます。
そして今まで開発をしていたメンバーは
プロジェクトに長く居るメンバーが多く、機能の詳細を理解している人が多いので
彼らに設計や要件定義を担ってもらうという事です。
幸いなことに、開発に入ってもらっていた協力会社のメンバーも
上流工程に携わること自体はウェルカムだったので、この案はすんなり受け入れられ、
開発メンバーの追加自体も会社に認められたので
この体制案は受け入れられました。
これにより、状況が劇的に改善すると考えるほど
楽観主義ではありませんが、手も足も縛られている状況の中で
唯一といっていい、打てる策だったと思います。
結果的に、この案自体はよかったのですが、
別の要因によって、状況はさらに悪化していきます。
次回、このStoriesとしては最終回になると思います。
コメント
コメントを投稿