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

プロジェクトリーダー(以下、PL)は
プロジェクト全体を管理し、無事にゴールできるように
様々なタスクをこなさなくてはいけませんが、
その役割はプロジェクトを通して、一定のものではありません。
プロジェクトのフェーズごとにその役割を微妙に変えていかないといかないといけないのですが、そのお話を書こうと思います。

まず、そもそも何故そのようなことをしなくてはいけないのか？という理由ですが
それはプロジェクトには大きく分けて、

システムを導入する

という事を考えるフェーズと

導入したシステムの運用保守をどうやって行くか

を考えるフェーズが混ざるからです。

コンサルやSierであればシステム導入の事だけ考えればいいのですが
社内SEとなるとそれだけ考えればいいという訳にもいきません。
というか、むしろ導入よりも運用保守している期間の方が圧倒的に長いので
そちらの方が重要です。
そして、導入後のイメージを膨らませながらシステム実装する唯一の立場が社内SEであり、それをコントロールするのが社内SE側のプロジェクトリーダーになります。

プロジェクトリーダーを外部の人間に任せてはいけないという大きな理由の一つです。

さて、プロジェクトのフェーズをざっくり分けると以下のようになります。
要件定義フェーズ
開発フェーズ
テストフェーズ
移行フェーズ

各フェーズでのプロジェクトリーダーの役割の移り変わりを見ていきます。

 

【要件定義フェーズ】

導入するシステムで実現したいこと、それをどういう形で実現するか？という青写真を描くフェーズです。
システム導入というのは社内SEにしてもそんなに年中やっていることではなく、規模が大きくなるとそれはなおさらです。
ユーザーからすると、そこに輪をかけて稀な経験になり、「How要件定義？」どころか「What要件定義？」という感じになります。
一方、コンサルやSIerはそれを仕事として幾度となく繰り返してきていますので、発注側と受注側において、プロジェクトの「慣れ」具合に天地の差があります。

そこを社内SEは埋めないといけませんし、ちゃんと溝を埋められているのか？をプロジェクトリーダーは注視しなくてはいけません。
要件定義フェーズとして定められたスケジュールの中で、きちんと終わらせるためには
ある程度スピード感をもって臨まなくてはいけませんが、
かと言って、コンサルやSIerのスピード感にユーザーが置き去りにされてしまっていては、目的とかけ離れたものが出来てしまいますので
しっかりとユーザーとコミュニケーションを取りながらも、徐々に慣れさせて加速させていかなくてはいけません。
この最初のフェーズを失敗すると、全体のスピード感も見誤ってしまい
後々のスケジュールにも深刻な影響を及ぼすことがあるので、とても大事なフェーズです。
こういった
コミュニケーションの取り具合
全体スケジュールを見越してのプロジェクトのスピード感
を注視します。
実はプロジェクトにおいて、あまり運用の事を意識しないでいいのはここまでで
ここからは徐々に運用の事に頭を割いていかないといけません。

【開発フェーズ】

・要件定義フェーズで決まった「やるべきこと」を実際にシステムとして実装するフェーズです。
一言で開発フェーズといっても、このフェーズでやることは、かなり多岐にわたるのですが、プロジェクトリーダーとして考えないといけないことは「品質」です。
この「品質」もいろいろな意味を含んでいるのでもう少し噛み砕くと
・「要件定義したものに合致したものが作られているか？」
→言ったもの作ってる？見当違いなもの作ってない？
・「作られたプログラムの信頼性が高いか？」
→多少乱暴に扱っても壊れないか？
という二点になります。

信頼性とは、やすやすと障害を発生しないようになっているか？という意味になります。

さて、このあたりからもう運用の事を考えないといけなくなります。

要件定義が終わり、開発フェーズに入っていくと、まずは設計書というものに落とし込みを始めます。
この設計書を書く段階で、プログラムの動作の詳細部分が定められてくるので、
どうしても運用の事を考えなくてはいけなくなります。

例えば、要件定義で決まった事は
Aを使って、Bを生み出す。なおAはXシステムからもらえるので、それを使ってBは自動計算で出すようにします。
という事だとします。
設計書に落とし込んだ段階で
「ではAは、Xシステムからもらうということですので、Xシステムからデータをもらう仕組みと、もらったAからBを算出する仕組みを作りましょう。XシステムからAをもらうのは毎月第2営業日にして、そこまでにもらえなかった場合、Bが0で算出されるのは困るという事だったので算出処理でエラーが出るようにしましょう」
という風に落とし込んだとします。
ここで運用を意識した場合、気を付けないといけないのは、
Bの算出処理でエラーが出た場合のリカバリーってどうやるの？
です。

大体、「他のシステムからデータをもらって、自動算出します。」みたいな処理は、日中はユーザーがシステムを使っているので、
夜間に自動処理させることが多いのですが、エラーになったとして、そのリカバリーが翌日の日中でいいのか？それともその夜間中に対処しないといけないのか？
その場合、どうやったらリカバリーできるのか？考えないといけないことは山ほどあります。

例えばエラーになった場合はシステム担当の方で値を編集して再計算させなくてはいけなかったとします。
その場合、Aの値を手で修正する為の仕組みがシステムに用意されていないと、編集して再計算させることが出来ないわけです。
運用保守に慣れていないと、意外とこのあたりまで考えが回らず、
いざ運用保守に入った時に、これを考慮していなかったために事件が起きたりすることもあります。
こういった事まで考えてシステムを作らないといけないのが社内SEで、そこまでちゃんと目を配ってシステムが設計されているか？をプロジェクトリーダーは管理しなくてはいけません。

とくにコンサルは運用については素人であることが多いので、そこまでイメージできないことが多いので
そこまでちゃんと考えて、ベンダーを管理しないといけないプロジェクトリーダーはしっかり目くばせをする必要があります。

そして、プロジェクトリーダーは運用保守に必要以上にお金のかかるシステムにならないようにしないといけません。
上記の例で言うと、エラーが起こる度に社内SEが夜中に叩き起こされて対応しないといけないような作りになってしまうと
人件費もかかりすぎますし、従業員のエンゲージメントも下がってしまいます。
ですので、
毎月第2営業日は最後の砦だから、前月最終営業日、当月第1営業日まで3日間連続でデータをもらえるようにして、第2営業日の日中にデータがもらえないことが確認出来たら、Xシステム側にアラートを出すようにしよう
とか
Bが0で算出されても影響がないように後続処理を考えよう
という風に検討しないといけません。

さて、次はテストフェーズと移行フェーズになりますが、
ちょっと1記事にするには長くなってしまうので、2部に分けようと思います。