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

さて、
チーム内のコミュニケーション不全
と
チームの外とのコミュニケーション不全
について、対策を打ちながら、なんとか情報共有が円滑に進むように
整理整頓をしてきましたが、ここまではチームとしての課題でした。
次に立ちふさがったのは私個人のタスクでした。
（実際は順番に問題が起きているわけではなく、コミュニケーションの問題と同時に発生していたのですが。）

その問題というのは、4月にカットオーバーを迎えるにあたり、
システムの運用設計を行うというタスクを与えられたという事です。

ここでいう運用設計は具体的には
サービスの提供体制であったり
サーバーの稼働時間であったり
といったものです。

問題は入社したばかりで1か月も経っていないにもかかわらず、
これを任されたという事です。
普通、
・自社ではどのレベルのSLA（サービスレベル）を定めているのか？
・他のシステムはどういう基準でサーバーを動かしているのか？
・体制としてどういった人員体制を組まなくてはいけないのか？
・カットオーバーするにあたり、どういったドキュメント類をどこまで用意しなくてはいけないのか？

などといった事を事前に知識として持っている人がやるような仕事なのですが
何故か、前提知識のない中で私がアサインされ、これらを決めていかなくてはいけなくなりました。

勿論、今までにもこういったことをやってきた経験はあるので
やろうとしていること自体は特に違和感もないのですが
何しろ、転職した直後ですので、この会社における常識というものがありません。
基本的にこういったものはべき論というよりも、既存システムと足並みをそろえないとおかしなことになるので、周辺システムがどうやっているか？
を把握している人間が設計しないと、
このシステムだけ、とびきり厳しい稼働条件になっていたり、
ゆるゆるのサービスレベルになっているというようなことが起こりかねません。

どちらかというと、このプロジェクトに古くから参画している人間が総仕上げとしてやるようなタスクなのですが・・・・
これをひょっと入ってきた人間に任せるという時点で
このプロジェクトの異様さというのを感じ始めたのはこのあたりかもしれません。
私がプロジェクトリーダーなら決してこのようなアサインはしませんが、
この運用設計に着手し始めて、その理由というか、何故私がすることになったのかは
徐々にわかっていく事になりました。

ともあれ、任された以上やるしかないのですが
さすがに何もないところから書き上げるのはハードルが高すぎるので
同様に他のシステムの運用設計をやっているメンバーにサンプルとなるようなものを求めると
稼働済みのシステムのドキュメントを手に入れることが出来ましたので
それをベースにブラッシュアップしていく事にしました。

しかし、そのドキュメントの問題点として
1.1年以上前のドキュメントである
2.格納されているフォルダが明らかに正式なフォルダ名ではない。つまり最新版ではない可能性がある。
という2点がありました。特に2.についてはここがはっきりしないと
サンプルとしてもらったドキュメントの内容をどこまで信じていいのかわからないという
そもそも論的な問題につながってしまいます。
しかもこの点を突き詰めていくと、そもそもドキュメント管理がちゃんとなされておらず、
1年前にカットオーバーしたシステムの各種ドキュメント類自体が集約もされておらず、色んなフォルダに分散している上に、「ドラフト」みたいな名前のフォルダに格納されたままであるという実態までわかってきました・・・・。

こうなると、もはやドキュメントの記載内容については信用ができないので
ドキュメントのレイアウトや記載項目についてだけ、参考にすることにし、
中身は0から書いていく事にしました。

そして、またまた次の問題
じゃあ、各項目に書くべき内容を誰にヒアリングすればよいか
これを運用設計チームのメンバーに投げかけたところ、
それもわからない
という事がわかってしまいました・・・・・
つまり、各項目を本来誰が定義すべきなのか？誰の知見を正とすればいいのか？
という事も私が調査、定義しないといけなくなったという事です。

正直、「は？」と思わなくもなかったですがｗ
アサインされた当初は
「かなりミスマッチなアサインするなぁ・・・」
ぐらいに思っていたころが、ふたを開けてみれば、おそらく誰がアサインされても
困惑するようなタスクという事がわかったので、不承不承
「まぁ、しょうがないか・・・・」
という気持ちにはなりました。

とはいっても、タスクが楽になったわけではありませんので
ここから、知ってそうな人を捕まえて、聞きこむという作業を
手当たり次第に続けるという事になるのですが
これはかなり面倒でした。

なにしろ、普通プロジェクトに古くからいる人が手掛けるようなタスクなのに
誰も手を挙げなかったという所からして、「我関せず」というスタンスの人が多いので
100%こちらからのアクション待ちです。
誰かが助けてくれるという事は期待できませんでした。
私が聞いたことには答えてくれますが、プラスアルファの情報が出てくることはありません。
よくある
「あ～、それは俺はわからないけどTさんなら知ってるかもよ。」
という情報が出てくることすらないので、誰かに聞いて、目的の情報が得られなかった場合、次のTさん自体を探すことすら自分でやらなくてはいけませんでした。

勿論、大前提として入社して2か月程度しかたっていないので
なんとなくの当たりもつかないので、もう本当に手当たり次第に聞いて回っていくしかありません。
これは相当に面倒な仕事でした。
しかし、ここから更に面倒な事態になっていきます・・・・

上記のような状況なので、一つのドキュメントを仕上げるにも相当に時間がかかります。
その理由も運用設計チーム内に共有しているのですが
何故か、それを踏まえた上でも、全くスピード感（締め切り）をあわせてくれないという事も追い打ちをかけてきます。

私の目から見て、運用設計の整理については
現時点でそこまで急ぐ必要はなく、他にも現在進行形のタスクはいくつもあり、
優先度はそちらの方がはるかに高い
というか、そのタスクが終わらないと
運用設計ドキュメントに反映できない項目もあるのですが
何故か、妙に早い締め切りを設定し、それに対して執拗に催促を繰り返してくるという状況になっていきました。

私もページの冒頭に書いたように、これだけの仕事をしているわけではなく
より、優先度の高いタスクもあるのですが
何故か待ったなしで催促を繰り返し、最終的にはインシデントだという話にまで発展しましたが
こういう、前にも後ろにも行けなくなっている場合、どうしたらいいか？というと

運用設計のタスクの締め切りが妥当な場合
→何かのタスクをあきらめる。（誰かに委託する）

運用設計のタスクの締め切りに余裕がある場合
→催促を無視する

のどちらかの対応をとったりするのですが、今回で言うと後者を選択しました。
結構力技ですが、このような状況になった場合はこういう図太さも必要です。
あきらかに締め切り自体がおかしい場合、その締め切りを守るために無理をするのも下策ですし、締め切り自体を調整するのにも時間がかかる場合は、そこに貴重な時間を使ってしまうのも下策です。
こういう場合は、最低話を通しておかないといけない人にだけ、事情を説明してあとは無視する
っていうのが一番時間を大事にできたりします。

私もめったに使わない力技ですが、
余分なリソースがない状況下では、結構有効な手段でもあります。

結果、私の想定通り、
締め切りに妥当性はなく、ズルズル伸ばしても実態として問題は起きず
本当のデッドラインまでには各種ドキュメントを間に合わせることが出来ました。

従来、運用設計というのはここまで手こずることはないのですが
プロジェクトマネジメントがしっかりしていない
普段の運用自体（運用設計）疎かにしている（ドキュメント管理が疎か等）
と、この運用設計すら、難易度の高い作業になってしまうという事がわかる事例でした。

そして、このプロジェクトが何故にこんなにドタバタして、
うまく回っていかないのか？という事の片鱗を見た事件でもありました。