プロジェクトのフェーズごとにおけるPLの立ち位置の変化（その2）
前回の記事に引き続き、 プロジェクトリーダーがシステム導入の際に 運用保守の事も考えて実装をしないといけない という話をしたいと思います。 当たり前といえば当たり前なのですが、 フェーズが進むにつれ、運用保守を意識するシーンは増えていきます。 【テストフェーズ】 テストフェーズの辺りから、頭の半分ぐらいは運用保守の方に使っていかないといけません。 一般的にテストフェーズでは 今迄に検討・作成したプログラムがちゃんと思惑通りに機能するように作られているか？ という点をテストを通して確認するのですが、 「ここまでの流れで、しっかり運用保守の事を考えてプロジェクトをコントロール出来てきているのであれば、運用保守の事を意識するというよりも、設計通りに動くかどうか？に力を集中した方がいいのでは？」 と思われるかもしれませんが、それは違います。 そもそも テストフェーズというのは、「想定通り動かない」という前提で行うもの です。 「想定通り動くはず」なんて意識でやっていると、拾えるはずのバグを見落としてしまう程度のテストケースしか考えないので、そもそもこのフェーズの意味を失ってしまいます。 これと同様に、今までしっかり運用保守を意識して設計を進めてきたけど、 テストフェーズではそれが裏切られると思ってテストを行わなくてはいけません。 どういう事かというと、 設計の段階では機能単体の動きを想定しながら作りこみますが それらを一連の機能としてテストシナリオを考える際に プロジェクトリーダーが想像もしないようなシナリオが生まれていたりするので それをチェックしないといけないという事です。 例えば機能の前後関係のあるOとPという機能があったとします。 要件定義の段階では 機能O→機能Pの順番で処理される という事がわかっています。 各機能を設計する際に 機能OではアウトプットとしてKとLを生み出します。 機能PはLを基にZを出力します。 と設計したとします。 そしてテストの際に 機能Oをまず実行し、Lを生み出します。その後、機能Pが実行され、LからZが出力されます。 というテストケースを考えたとします。 で、このシナリオは終わり。 すると、ここで「 あれ？機能Oで生み出されたKはどうなるの？ 」 という事に気が付きますが、周りの開発者に聞いても、機能Pの前提処理は機能Oしかなく、機能O...