Stories 8話：進むにせよ退くにせよ・・・・
さて、色々なことに巻き込まれつつ
運用設計も終え、山積したチーム内の問題にも対処しつつ、
このプロジェクトもカットオーバーに近づいていきました。
正直、この時点で
というのが私の中の結論でしたが、プロジェクト全体としては
何が何でもカットオーバーするという流れで進んでいました。
あるあるではありますが
プロジェクトの目的が「カットオーバー」になり、
システム品質の話が二の次になっている時点で
炎上プロジェクトかつ、失敗プロジェクトなのですが
入社したばかりの立場でこれを止めることもできません。
そしてそれは、プロジェクトをカットオーバーさせるかどうかを決める
リリース判定基準がいまいちあやふやな所にも表れていました。
本来、リリース判定基準とは
明確に数値化されたもの
誰が見ても誤解のしようのないもの
プロジェクトとして必達となっているもの
等が掲げられているものなのですが、やはりプロジェクトの目的が
「カットオーバーすること」
になっていた為、関係者もそのあたりを考慮したのか・・・・
必達の目標を明文化してしまうと
もしかするともしかする可能性があったのでしょう。
というような、非常にあいまいな判定基準が掲げられていました。
ただ、この「もう何が何でもカットオーバーする！！」という方向性が
私個人にとって全くメリットがないか？というと、そういう訳でもありませんでした。
本来であれば、こういった不完全なシステムがカットオーバーされると
それを保守していかなくてはいけない立場からすると
「そんな中途半端なもの、リリースしてくれるな」
という事になるのですが、
そもそもこのプロジェクトはここに至るまでにもう何年も経過していて
しかも前の記事で述べた通り、チームリーダーが独断専行しなくては前に進むこともできない。
そんな状況です。
Stories 2話：コミュニケーション不全
よって、このプロジェクトには、何年もの間に蓄積された
このチームリーダーしか知りえないことが数多く潜んでいます。
なんでこんな機能があるのか？
なんでこんな回りくどい仕様になっているのか？
など、本人に直接聞かなくてはわからないような話がてんこ盛りになっている上、
問題のチームリーダー自身も、このプロジェクトに嫌気がさしていて
カットオーバーの１か月後に別の部署に異動するという事が決まっていました。
ので、もしカットオーバーしないとなった場合、
リスケした次のカットオーバーに向けて、
残された課題を今までの歴史を踏まえた上で、ブラッシュアップして品質向上をしていかないといけないという事になります。
それはつまり
彼が今までため込んできた、このプロジェクトの何年分もの歴史を引き継がないといけない
という、面倒なことこの上ない、そして私にとって、有益でもないタスクが発生するという事です。
これは相当厄介な仕事ですし、私にとって勉強にもキャリアにもならないのでモチベーションも大変下がります。
一方、無理やりでもカットオーバーしてしまえば、
一旦、過去の話は過去の話という事で
そういった歴史問題を置き去りにして、これから先の事だけを考えることが出来ます。
ですので、私個人で言えば
前に進む方がまだ幾分マシです。
そういった事情もあり、私としてもこの流れ自体を止めるつもりはなかったのですが
依然としてプロジェクトの品質は低く・・・・
カットオーバーの前月時点でも課題がしばしば発見され、
緊急度を加味して、カットオーバー後の課題として後回しにする
という事を繰り返しつつ、このプロジェクトはなんとかかんとかカットオーバーを迎えることができました。
ただ、意外なことにカットオーバー直後は
システムが止まるといったような深刻な問題は発生せず
無事に動き出すことはできました。
勿論、引き続き品質問題は付きまとい、
想定通り、何か数字がおかしいぞ？というような課題は頻発
修理しながら走り続けるという状況になってしまいましたが
そんな状況でもやはり、カットオーバーを延期にはしなくてよかったと今でも思います。
想定通り、運用保守をやっていく中で
不可思議な動きをしている機能が散見され、頭を悩まされるのですが
それでも、
この謎の動きがどうして謎になっているのか？の歴史を紐解くよりも、
「それはそれとして、本来はどう動いたらいいのか？」
を考える方がよほど建設的で有意義な時間の使い方だと思います。
そういう意味で、無理やりでもカットオーバーしたほうがいい
というシーンも極めて稀に存在するという例でした。
コメント
コメントを投稿