Stories 3話:プロジェクトマネジメント

さて、チーム内で発生していたコミュニケーション不全は改善の糸口を見つけることが出来ました。
相変わらずリーダーに聞くのは憚られるようですが、
私を仲介して聞いたり、別の人に聞いてみたり、自分で資料を漁ってみたり
という事は自分たちで出来るようになったので、プロジェクトの現状を考えれば上出来だと思います。

私が次に直面したのはプロジェクト全体の問題でした。
それは、

4月にカットオーバーを控えているにもかかわらず
1月の段階で新たなテスト環境を用意しようとしている

ことでした。
新たなテスト環境を用意するという事は、新たにテストを行おうとしているわけですが(当たり前ですが)、問題は今は1月という事です。
4月カットオーバーを見込んでいるプロジェクトの。。。

正直、狂気の沙汰だと思いました(笑)
今まで、火消ししてきたどの炎上プロジェクトでも聞いたことがありません。

そもそもプロジェクトの全体スケジュールとして、
1月にテストをするという事が決まっていたのであれば
テスト環境の準備は11月には着手しているはずです。
それを1月からテストするからその環境を用意しないといけない
という話を12月の終わりにし始めている時点で、
完全に思いつき、もしくはプロジェクトリーディングできていない。という事がわかります。
私が他の記事でも書いた
プロジェクトリーダーがやるべき2つのタスクができていないことが露骨にわかる事例です。【あわせて読みたい】
プロジェクトを管理するって要はどういうこと?

テスト環境を用意するというのも大変ですが、現時点で既にAチームの作業は逼迫しているので
これは自殺行為に近いと考え、入社して一か月にもかかわらず、決裁者に提案をしました。
あまりそういう、変に目立った動きは取りたくない人なのですが、そうもいっていられない事態だと判断しました。
・そもそも今からテストをねじ込む時間的猶予がない
・テスト環境を準備する時間もない
・テスト環境を用意するとそれに伴う、予定にない作業が大量に発生し、それを受け入れるチームもない
という点と
上記のデメリットを考慮した上で、どうしてもテストをやりたければ、現行の環境を代替して、理論値で計測した方が現実的だ
という話です。
つまりテストをやりたいのであれば、現行の環境を利用して理論値でやるべきという提案です。

結論はというと・・・・・
私の意見は通りませんでした。
どうしても別の環境を用意して、そこでテストをしたいというステークホルダーの意志
というのが答えでした。
その結果、カットオーバーできずともやむなし!
という事です。

何が衝撃だったかというと
今まで、何とかしてカットオーバーに間に合わせようと、様々なことに調整をかけるのが常でしたが、テストができないのであれば納期延長もやむなし
つまり、万全なテストが行えないのであれば、カットオーバーしない
という思い切ったことを言い放つプロジェクトは初めてでした。

勿論、万全なテストが出来なければカットオーバーしない
という所だけ聞くとごもっとな意見なのですが(コストの話はさておき)
そもそも万全なテストがカットオーバーの絶対条件なのであれば、
スケジュールに最初から組み込まれているべきです。
それが組み込まれていないという事は「万全なテスト」というものがそもそも定義されていなかった
という事になります。
となると、「おっしゃっている万全って何ですか?」
という「万全」の定義の話になってしまいます。

しかし、一つ救いがあるとすれば
テストを終えることが出来ないのであれば
カットオーバーしないという意思表示をしてくれたことですね。

ここで
・万全なテストをする
・カットオーバーは死んでもする
という相反する目標を掲げられると、完全に×となります。
デスマーチ確定といえるでしょう。

なので、次に私がやることは
テスト環境準備とデータ移行を滞りなくすることです。
ここでも相変わらずAチームリーダーは共有という行為をせず
口伝で進めようとしていたので、私の方で
作業リストを作り、どこに問題があって、どこがボトルネックになっているか?
それを解消するにはどうしたらよいか?
をメンバーと共有しました。

メンバーの様々な協力のおかげで、
新しい環境準備自体は滞りなく進みましたが
当初予定になかった作業がメンバーに降りかかることになり
当たり前ではありますが、更なる工数増大は避けられませんでした。
しかし、この増大した工数を何とかするというのは私にどうにかできる問題ではないので、
メンバーに頑張ってもらうという事しかできませんでしたが
やはり作業自体を、無目的に意味も分からずやるという状況は脱して、
作業の目的、やり方を整理して、メンバーに落とし込んだ後に作業を進めてもらう
というやり方になっていたので、メンバーとしてはだいぶやりやすくなったようで
最終的にはこれを乗り切ることが出来ました。

これは
やはりプロジェクトマネジメントにおける肝は
タスクの洗い出しと、正しいスケジュールだ
と心底思った事件でした。

と同時に今後も発生してくるであろうプロジェクトに対する恐怖心を養うに十分な事件でした・・・。

コメント

このブログの人気の投稿

Stories 5話:今までの経緯を知らないまま、運用設計をする

社内のコミュニケーションを活性化!グループウェア導入のススメ

ITにどう向き合う?どう向き合ってもらう?