プロジェクトのフェーズごとにおけるPLの立ち位置の変化（その2）

前回の記事に引き続き、
プロジェクトリーダーがシステム導入の際に
運用保守の事も考えて実装をしないといけない
という話をしたいと思います。

当たり前といえば当たり前なのですが、
フェーズが進むにつれ、運用保守を意識するシーンは増えていきます。

【テストフェーズ】

テストフェーズの辺りから、頭の半分ぐらいは運用保守の方に使っていかないといけません。
一般的にテストフェーズでは
今迄に検討・作成したプログラムがちゃんと思惑通りに機能するように作られているか？
という点をテストを通して確認するのですが、
「ここまでの流れで、しっかり運用保守の事を考えてプロジェクトをコントロール出来てきているのであれば、運用保守の事を意識するというよりも、設計通りに動くかどうか？に力を集中した方がいいのでは？」
と思われるかもしれませんが、それは違います。

そもそもテストフェーズというのは、「想定通り動かない」という前提で行うものです。
「想定通り動くはず」なんて意識でやっていると、拾えるはずのバグを見落としてしまう程度のテストケースしか考えないので、そもそもこのフェーズの意味を失ってしまいます。
これと同様に、今までしっかり運用保守を意識して設計を進めてきたけど、
テストフェーズではそれが裏切られると思ってテストを行わなくてはいけません。

どういう事かというと、
設計の段階では機能単体の動きを想定しながら作りこみますが
それらを一連の機能としてテストシナリオを考える際に
プロジェクトリーダーが想像もしないようなシナリオが生まれていたりするので
それをチェックしないといけないという事です。

例えば機能の前後関係のあるOとPという機能があったとします。
要件定義の段階では
機能O→機能Pの順番で処理される
という事がわかっています。

各機能を設計する際に
機能OではアウトプットとしてKとLを生み出します。
機能PはLを基にZを出力します。
と設計したとします。

そしてテストの際に
機能Oをまず実行し、Lを生み出します。その後、機能Pが実行され、LからZが出力されます。
というテストケースを考えたとします。
で、このシナリオは終わり。

すると、ここで「あれ？機能Oで生み出されたKはどうなるの？」
という事に気が付きますが、周りの開発者に聞いても、機能Pの前提処理は機能Oしかなく、機能Oの後続処理は機能Pしかないとのことなので、Kの出番はないように見えます。
結果、シナリオを作る人間は「きっと開発途中でなくなったものなのだろう」と判断し、Kを見なかったことにしました。

しかし、実はKは人の手によって処理され
別のシステムに連携されなくてはいけないもので、
きちんと従来通りの形でKが出力され、別のシステムに滞りなく投入されることをテストしなくてはいけなかったのです。
これを怠った為に、実際の本稼働の時にKは別システムに連携されず障害が発生し、システムに重大な影響を及ぼしてしまった・・・

というようなことが、実際に起こります。（極端には書いていますが。）
プロジェクトに関与する以下の人達
・社内SE
・コンサルティングファーム
・SIer
彼らはどちらかというとプロジェクトのミクロな課題に取り組むことが多く、
それぞれが自分の業務を誠実に勤めていても、こういった全体の運用を見通した視点は見落としがちです。
それにそもそも、実際に稼働した後の事などはコンサルティングファームとSIerは考えてくれないので、気にするのも社内SEしかいません。
勿論、社内SEもこういった全体的な問題を全く意識しないわけではありませんが、
プロジェクトの終盤であるテストフェーズともなると、目の前のミクロな課題に力を奪われがちで、このようなマクロな課題について、同時並行で考える余裕はないというのが実態です。

ですので、代わりにプロジェクトリーダーは常にマクロな視線を保ち、
システム稼働後の運用を見据えたテストにきちんとなっているか？
そこに目を光らせなくてはいけません。

【移行フェーズ】

そして、最後のフェーズです。
移行はプロジェクトの中にいくつもあるタスクの中で1，2を争う難易度の高いタスクです。
どんなプロジェクトでも、みんな頭から煙を吹きながら対処しています。
そんな移行フェーズで運用を意識するのはどういう時か？

そもそも、移行フェーズというのは
今まで使っていたシステムのデータを、新しいシステムに移すことを言います。

ここで運用保守を意識することはあまりないように思えますが
実はちゃんとあります。

移行するデータの中には
新システムでも利用するデータ
移しはするものの、中身が見れればよくて、新システムでは使用しないもの
と別れます。
前者に関しては、移行フェーズというよりも、その前のテストフェーズで検証することになりますので、移行フェーズで強く意識しなくてもいいのですが、
後者については、新システムに移すだけではなく、「移したデータを見れる状態になっていなくてはならない」という条件があります。
これが意外と重要で「移行したデータを見れるようになっているか？」というテストをするのはここでしかなかったりします。

新システムを導入する場合、
問題の一つとして必ず上がるものとして
今まで旧システムで貯めてきたデータはどういう風に見れるようになるのか？
というものがあります。
これは
松パターン
新システムの新仕様に合わせた形で、新システムのデータとあわせて見れる
竹パターン
新システムには移すけれども、新システムのデータと合わせてみることはできないので、旧システムのデータ、新システムのデータと二回に分けてみないといけない
梅パターン
新システムにはもっていくが、新仕様でも見れないし、旧仕様でも見れない。どうやって見るかは後日考える
そういう事もあるパターン
新システムに持っていきもしない。捨てる。
などの色んな対処があります。
往々にして、システムの制約によるものなので、あまり選択の余地はなかったりするのですがいずれにせよ、ユーザーの主張としては
「旧データも見れないと仕事にならん！」
です。
その為、旧システムのデータもある程度ユーザーの納得感のある見せ方をしないといけないですし、実際、見れないと仕事にならないというケースも稀にあります。

しかし、システムの開発側というのは
往々にして、新システムの使い方に注力し、旧システムの移行データの取り扱い方までは意識しない人が多く、
こういった旧システムの移行データについては、考慮から漏れてしまう事が多いので、この点についてもプロジェクトマネージャは意識をして
きちんと着地するべきところに着地するように移行が行われているか？
移行テストもしっかり行えているか？をチェックしないといけません。

でないと、これもシステム稼働後に新システムは健全に動いているが
旧システムのデータが満足に移行されていなかったり、
見え方が想定と変わってたりで、運用保守において甚大な影響を与えたりするので
注意が必要です。

さて、これまでに書いたように
プロジェクトリーダーというのは
導入システムが進むにつれ、「この新システムをどうやって運用保守していくか？」を考えざるを得ません。
プロジェクトリーダー以外はプロジェクト内に次々と発生するミクロな問題に目を奪われ
こういったマクロな問題の優先度を下げてしまう事が多く、プロジェクトリーダーがこれを考えないと、だれも運用保守の事を考えていないという事になり

設計書通りだが、運用に耐えられないシステム

という珍妙なものが出来上がってしまいます。

逆に言うと、今自社にそういうシステムがあるとするならば
プロジェクトリーダーが運用保守を考えていなかったという事に他ならないと思います。

ですので、社内SEはもちろん、プロジェクトを束ねるプロジェクトリーダーも必ず自社の人間がしなくてはいけないですし、その人間にはここまでに書いたような視点もしっかり持ち合わせてもらう必要があります。