プロジェクトのスケジュールを管理する

イントロダクション

ユーザー側でのシステム導入にあたって、プロジェクト計画書をベースにシステム導入の勘所とRFPに記載すべき要件をお話ししていく「システム導入のエッセンス」、第６回目です。

一般的なプロジェクト管理手法であるPMBOKやPM7Keysを元に、ユーザー側でチェックすべき以下の７つのポイントを紹介しました。

１．ゴール
２．スコープ
３．スケジュール
４．チーム
５．コミュニケーション
６．コスト
７．リスク

前回はプロジェクトのスコープの設定についてお話してきました。
今回からは「スケジュール」の話になります。

どんな仕事にも基本的にはスケジュールがあります。
いつまでに何をしなければいけないか、誰がしなければいけないのか。
そもそもシステム開発において、何をしなければいけないのかがわからなくてはスケジュールは作れません。

ウォーターフォール型開発の大きなマイルストーン

今回説明するのは所謂「ウォーターフォール型」開発の標準的な作業の流れです。
最近話題のDevOpsだとかアジャイルという手法もありますが、まずは基本となる形で説明したいと思います。
ウォーターフォール型とは、水のように上流から下流へ流れていくような形で作業が進むプロジェクト形式です。
「前作業があって次の作業に進む」と言えば当たり前と言えば当たり前ですが、もっと言ってしまえば「基本的に逆行不可」ということです。

ある程度工程が進んでから新たな要望が出たり、前フェーズの内容が覆されると流れが滞る＝プロジェクトが予定通りに流れなくなるのです。
「臨機応変に」などという言葉はシステムの世界では基本的に使えません。

とはいえそういう事態が全く発生しないわけではありません。
そういう場合は本来の流れとは分けて別の流れとして管理することがあります。

各工程の内容と色分けの意味を説明していきます。

要件定義

システム開発といっても、いきなり画面やプログラムの話から入るわけではありません。
そのシステムを使ってどのように業務を行っていくかを決める必要があります。
システムは決められた動きを行うことには長けていますが、想定していない動作を行うことはできません。
そのため「何を想定しなければいけないか」を業務の流れとして定義していかなくてはいけません。

このフェーズで主に登場するのは業務フローです。
どの業務を、どのタイミングで、誰が行うのか。
各業務のインプットとなる情報は何で、次にどの業務にどのようなアウトプットを渡さなければいけないのか。
そういったことを決定していきます。

多くの場合ベンダーが提示する想定業務フローがあります。
これはベンダーが提供しようとしているシステムの標準フローであり、このフローで業務を行えばシステムを最も有効に使うことができるという業務の流れです。

システム導入は業務フローの最適化の意味合いもあります。
システム導入によって業務効率化を図るには、本来はシステムが想定する業務の流れに合わせることが最も有効になります。
しかし全ての企業の業務が既製品通りとは限らない（という前提）に、要件定義では現行業務とシステムが想定するフローの差を把握し、その差をどのように埋めていくかを検討していくのです。
所謂「Fit&Gap」というやつです。

Fit&Gapで出てきた差異の吸収方法は、極端に言えば「運用方法をシステムの想定運用に変更する」のか、「現行運用方法を踏襲するためにシステムをカスタマイズする」のかの二択になります。
前者は単純に合わせるだけでなく、現状の運用の意味合いを損ねず、且つカスタマイズを回避するような運用事例の提案なども含まれます。
ここの引き出しがSIerの腕の見せ所と言っても過言ではありません。

最終的にシステム導入後の業務フローの確定と、カスタマイズ範囲の確定と合意をもって要件定義フェーズは終了します。
カスタマイズは基本的に費用が係りますから、その費用も含めた合意ということになります。
この合意を持って次フェーズ以降の開発に移ることができるようになります。

多くの場合要件定義フェーズと開発フェーズは契約方法が異なります。
前者は準委任契約、後者は請負契約となることが多いです。
両者の違いは簡単に言えば契約として成果物の納品を含むかどうかです。

要件定義には成果物はなく、業務フローの整理という作業を依頼しているという形になります。
開発は成果物としてのプログラムの納品を求めることになります。

基本設計、詳細設計

要件が固まれば、確定したカスタマイズ範囲に従って設計作業がはじまります。
基本設計（外部設計とも言う）は「ユーザーに見える部分の設計」、詳細設計は「基本設計を具現化するためのユーザーに見えない部分の設計」と思ってよいでしょう。
基本設計では画面レイアウトや入出力のファイルレイアウトなどの変更点を主に確認します。
ユーザー確認を行う作業は主にここまでです。
詳細設計は基本設計で決まった内容をプログラムにどのように反映させるかという設計です。
プログラムの内部構造の話になるので、ユーザーレビューを必要としない場合が大半です。

製造、単体テスト、結合テスト、総合テスト

設計が決まればモノ作りがはじまります。
作ったものは正常に動作するかテストする必要がありますが、これも大きく３つのフェーズに分かれます。
まずは修正した箇所単独で設計通りの動作を行うかを確認する単体テスト。
次に修正箇所と関連する他の機能との連動を確認する結合テスト。
最後に業務の流れ全体で正しく動作するかを確認する総合テスト。
少しずつ確認する範囲を広げていくのは、後フェーズで小さな箇所の問題が発生した場合に再テストを行うための手間を最小限に抑えるための工夫です。

この辺りも多くはベンダー側での作業となります。

受入テスト

ベンダー側で作成したものが要件定義で決まった内容の通り動作しているか、ユーザー側が検品するのが受入テストです。
受入テストが完了したら成果物を受領したこととなり、開発フェーズは終了します。

開発フェーズの作業の図の色は、黄色がユーザーが関与する作業、青色がベンダー主体の作業を指します。

並行稼働、研修、データ移行

プログラムが納品されればシステムが稼働できるかと言えばそういうわけではありません。
実際に要件定義で決めたフロー通りに業務を回してみて、現行業務と同じ結果が得られるかを確認する並行稼働。
新システムの操作習熟のための研修。
現行業務データを新システムに投入するデータ移行などの作業があります。

これらは「導入支援フェーズ」として開発フェーズと分離され、準委任契約となることが多いです。
作業そのものは開発フェーズ完了後にはじまりますが、実施計画はそれ以前、開発フェーズの間に行われることが多いです。

放っておけばスケジュールは遅れる

そしてシステム開発プロジェクトの特定として、引いたスケジュールが次々に遅れていくことが挙げられます。

例えば要件定義フェーズは、ユーザー側の要望と費用の折り合いがなかなかつかず、当初予定していた期間までに落としどころが見つからず、後続スケジュールが遅れます。
開発やテストは確認していた仕様に漏れがあったり、製造物の品質問題によりテストにおけるバグ対応に時間がかかることがあります。
並行稼働や研修、データ移行などの場合、ユーザーマターのスケジュール調整が難航したり、既存業務を優先されて新システム関連の作業の進捗が遅れることがあります。

プロジェクトは一人でやる作業ではありません。
どこかのタイミング（主にフェーズのマイルストーン）に合わせられればそれでいいとも言えますが、全体の進捗度合いのバラつきはプロジェクトの安定運営にとってリスクになります。

ユーザーマターの部分だけではなく、ベンダーの作業遅れに対しても目を光らせておく必要があるでしょう。

ユーザー側とベンダー側で事情は違うが

とはいえユーザー側の管理者にとって重要なのはやはり自社側のスケジュールの管理です。
ベンダー側は多くの場合そのシステムの導入の経験があるので、言い方は悪いですが帳尻の合わせ方もある程度心得ています。
何より「システムを導入する」ことがベンダーの仕事なので、そのことだけに注力することができるのです。

一方ユーザー側はシステム導入選任の担当者というのはよほどのことがないと難しいです。
通常業務を行いながら、システム導入に係る作業も進めなければいけません。
どちらのスケジュールも守らなければいけないのですが、どうしたって今の業務を止めないほうの優先度が高くなります。

システム導入は決してベンダーだけで行うものではありません。
「ユーザーの協力義務」とはシステム開発契約においてユーザー側を果たさなければいけない義務として定義されています。

義務を確実に全うしようとするには、そもそもユーザー側でどのような作業をしなければいけないのか、その作業にいつ誰をアサインする予定なのか、その結果生じる作業負荷に対して対策を講じる必要があるかまで考えておく必要があります。
体制的に準備が整っていないのに無理やりスケジュール内に作業を終わらせようとして計画が破たんするのは、ベンダー側もユーザー側も同じです。

ベンダー側だった経験からも、業務負荷が高いユーザー側担当者が無理やり期日に合わせてきたり、付け焼刃的に増員されたメンバーが入ってきた場合などは、ベンダー側だけでなくユーザー側もシステム稼働後まで苦労していたように思います。

システム導入に必要な期間とそこで発生する作業、そこから導き出せる体制とスケジュールを考慮したプロジェクト計画の作成が必要です。
またユーザー側、ベンダー側ともにどのようなスケジュール管理を行っていくかという取り決めも事前に定義しておくべきでしょう。