開発会社が出すWBSとスケジュールで発注側が確認すること
システム開発を依頼すると、契約の前後に開発会社からWBSやスケジュール表が提出されます。細かい作業名と横に伸びる線が並んだ資料を前に、発注側の担当者は「専門的なことは分からないので、このままで大丈夫です」と答えてしまいがちです。
しかし、WBSとスケジュールは、システム開発がどこで遅れそうかを発注側が事前に見つけられる数少ない資料です。作業の分け方、順番、期間の置き方、発注側の作業がどう組み込まれているかを見れば、技術に詳しくなくても遅延のリスクはある程度読み取れます。
また、開発が遅れる原因は開発会社の作業だけとは限りません。発注側の確認や回答が予定より遅れ、それが後工程に連鎖して全体が遅れることもよくあります。WBSとスケジュールを読むことは、自社が何をいつまでにしなければならないかを把握することでもあります。
この記事では、WBSとスケジュール表の関係を整理したうえで、開発会社から出されたWBSとスケジュールのどこを見れば遅延のリスクが分かるか、発注側の作業の確かめ方、開発が始まってからの進捗管理の見方を解説します。
WBSとスケジュール表はどう違うか
WBSはWork Breakdown Structureの略で、プロジェクトで行う作業を、管理できる大きさまで段階的に分解したものです。システム開発では、「要件定義」「設計」「開発」「テスト」「移行」といった大きな工程を、さらに「画面一覧の作成」「受注画面の設計」「受注画面のレビュー」のような具体的な作業へと分けていきます。
WBSが「何をするか」を表すのに対し、スケジュール表は「いつするか」を表します。WBSで分けた作業に、開始日、終了日、担当者、作業同士の順番を割り当てたものがスケジュール表です。横棒で期間を表すガントチャートの形で示されることが多く、WBSとガントチャートが一つの表にまとめられていることもあります。
| 用語 | 意味 | 発注側が見るポイント |
|---|---|---|
| WBS | 作業を階層的に分解した一覧 | 必要な作業が抜けていないか、作業の大きさは適切か |
| ガントチャート | 作業ごとの期間を横棒で示した表 | 作業の順番と重なり、期間の偏り |
| マイルストーン | 工程の区切りや重要な節目となる時点 | 発注側の承認や判断が必要な時点がどこか |
| クリティカルパス | 遅れると全体の完了日が遅れる作業のつながり | どの作業が遅れると致命的か |
システム開発の期間は、機能の数や外部との連携、データ移行の有無などによって大きく変わるため、一般的な目安を当てはめても自社の案件の妥当性は判断できません。期間が妥当かどうかは、WBSの作業が漏れなく並んでいるか、作業の順番と重なりに無理がないか、という中身で確かめるほうが確実です。
最初に確認しておきたいのは、提出されたWBSがどの粒度で作られているかです。契約前の提案段階では工程単位の大まかなもの、契約後には作業単位の詳細なものが出てくるのが一般的です。提案段階の大まかなWBSしかない場合は、詳細なWBSをいつ出してもらえるかを確認しておきます。
作業の分け方から読み取れること
WBSで最初に見るのは、作業の分け方です。作業の名前と大きさを見るだけでも、計画がどの程度具体的に考えられているかが分かります。
作業が成果物で終わっているか
よいWBSの作業は、終わったかどうかを第三者が判断できる形になっています。「画面設計」という作業名だけでは、どこまで進めば終わりなのか分かりません。「受注関連画面の設計書作成」「設計書のレビューと修正」のように、何ができあがれば完了かが読み取れる名前になっているかを確認します。成果物で終わらない作業が多いWBSは、進捗を「なんとなく8割」としか報告できない計画になりがちです。
作業の大きさが偏っていないか
一つの作業の期間が長すぎると、その作業の途中で遅れていても気づけません。たとえば「開発」が2か月の一本の横棒で表されているだけなら、遅れが分かるのは2か月後です。長い作業は、画面や機能の単位で分けてもらうよう依頼します。目安として、定例会の間隔より短い単位で区切られていれば、毎回の定例会で完了したかどうかを確認できます。
抜けやすい作業が入っているか
プログラムを書く作業はどのWBSにも入っていますが、その周辺の作業は抜けやすい傾向があります。次の作業がWBSに含まれているかを確かめてください。
- 開発環境、テスト環境、本番環境の準備
- 設計書や画面のレビューと、指摘を受けた後の修正
- テスト計画とテストデータの準備
- 不具合の修正と再テスト
- 既存データの移行と、移行結果の確認
- 操作マニュアルの作成と、利用者への説明
- 本番切り替えの手順の確認とリハーサル
とくに、レビュー後の修正と不具合の修正は、計画上は時間を見込んでいないことがよくあります。レビューをすれば指摘が出て、テストをすれば不具合が見つかるのが普通です。その時間がWBSにない場合は、どこで吸収する想定なのかを確認しておきましょう。
順番と重なりから遅延のリスクを見る
作業の分け方を確認したら、次はスケジュール表で作業の順番と重なりを見ます。遅延のリスクが高い計画には、いくつかの共通した形があります。
| 見る場所 | 危ないサイン | 開発会社に聞くこと |
|---|---|---|
| 工程のつなぎ目 | 設計が終わる前に開発が始まっている | 設計が変わった場合、開発済みの部分をどう扱うか |
| 並行している作業 | 同じ担当者に複数の作業が同時期に集中している | 担当者ごとの作業量と、交代できる人がいるか |
| 終盤の期間 | テストや移行の期間が、開発の期間に比べて極端に短い | テストで不具合が多かった場合の予備の期間 |
| 余裕の置き方 | 全体のどこにも予備の期間がない | 遅れた場合にどこで調整する想定か |
| 外部に依存する作業 | 外部サービスや他社の仕様提供を前提にした作業がある | その情報がいつ届く前提で、届かないとどうなるか |
| 発注側の作業 | 確認や承認の期間が数日しか取られていない | 確認が遅れた場合、どの作業に影響するか |
なかでも注意したいのが終盤の期間です。開発が遅れたとき、最終的な完了日を守るために削られやすいのはテストの期間です。最初からテストの期間が短く組まれている計画は、開発が少し遅れただけでテストがほとんどできなくなる危険があります。テストの期間が短く見えたら、どの程度の不具合を想定しているのか、テストで不具合が多かったときにどこで調整するのかを聞いておきます。
余裕の置き方も確認のポイントです。予備の期間がどこにもない計画は、すべての作業が予定どおりに進むことを前提にしています。逆に、各作業に少しずつ余裕を持たせていると、その余裕は作業者の手元で使われてしまい、全体の余裕として機能しにくくなります。工程の区切りや終盤にまとめて予備の期間を置き、それを使う判断を定例会で行う形のほうが、遅れを管理しやすくなります。
クリティカルパスがどこかも聞いておきましょう。遅れると全体の完了日に響く作業がどれか分かっていれば、発注側も、その作業に関わる確認や回答を優先できます。
発注側の作業がスケジュールに入っているか
WBSとスケジュールで発注側が最も注意して見るべきなのは、自社の作業です。開発会社が作るWBSには、開発会社の作業は細かく書かれていても、発注側の作業は「お客様確認」の一行だけ、ということが少なくありません。
発注側の作業として、次のようなものがスケジュールに入っているかを確認します。
- 現行の業務や帳票、データに関する資料の提供
- 開発会社からの質問への回答
- 要件定義書や設計書の確認と承認
- 開発途中の画面の確認
- テストデータの準備と、受入テストの実施
- 利用者への周知と、操作説明への参加
- 社内の決裁や、取引先など関係者との調整
それぞれの作業について、期間が自社の実情に合っているかを見ます。たとえば、設計書の確認に3日しか取られていなくても、現場の担当者が繁忙期で時間を割けないなら、実際には2週間かかるかもしれません。社内の決裁に役員会を通す必要があるなら、その開催日に合わせなければなりません。発注側の作業の期間は、開発会社には分からない情報です。自社で見直して、実現できる期間に修正してもらってください。
受入テストの時期も重要です。受入テストには、実際にシステムを使う現場の担当者が参加する必要があります。受入テストの時期が月末の締め処理や年度末と重なっていないか、担当者の休暇の時期と重なっていないかを、スケジュールが決まる段階で確認しておきます。
開発会社からの質問への回答も、期限を決めてスケジュールに入れておきたい作業です。質問は開発の途中で随時届くため、一つずつの回答は小さな作業に見えますが、回答が数日遅れるだけで、その質問に関わる設計や開発が止まります。「質問は原則として3営業日以内に回答する」「社内で決められない質問は、定例会で決裁者に上げる」のように、回答の期限と、決められないときの扱いを最初に取り決めておくと、回答待ちによる遅れを防げます。期限の日数は、自社の決裁の流れに合わせて無理のない値にしてください。
発注側の作業がスケジュールに明記されると、遅れたときの責任の所在もはっきりします。開発会社の作業の遅れなのか、自社の確認の遅れなのかが分かれば、対策も正しく打てます。
開発が始まってからの進捗の見方
WBSとスケジュールは、契約前に確認して終わりではありません。開発が始まってからは、計画と実績を比べる基準として使います。
IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」では、開発会社が定期的な連絡協議会で進捗管理報告を提出し、遅延の有無や、遅延があるときはその理由と対応策を協議する形が示されています。同契約書の参考文書では、進捗管理報告に添付するプロジェクト進捗計画表の例として、WBS、担当者、成果物、着手予定日、進捗率、完了日、予定線表、実績線表などを表示することが挙げられています。自社の案件でも、少なくとも作業ごとの予定と実績が並んだ表を毎回の定例会で受け取るよう依頼しておくとよいでしょう。
進捗率の数字を見るときは、その数字の数え方を確認します。作業の途中を担当者の感覚で「60%」と報告する方法では、終盤になって残りが思ったより多いことが判明しがちです。終わった作業だけを数える、あるいは着手で半分、完了で残り半分とする、といった決まった数え方にしておくと、報告の数字が実態に近づきます。
次のような兆候が見えたら、早めに理由を確認します。
- 同じ作業の進捗率が、何回かの定例会にわたって変わらない
- 完了予定日を過ぎた作業が、完了扱いにならないまま次の作業が始まっている
- 報告の中で、作業の名前や区切り方が計画から変わっている
- 発注側の確認待ちの項目が増え続けている
- テストの段階で、見つかる不具合の数が減らない
遅れが見つかったときに判断すべきなのは、遅れをどこで取り戻すかです。予備の期間を使う、作業の順番を入れ替える、人員を増やす、範囲を絞る、完了日を延ばす、といった選択肢があり、どれを選ぶかは発注側の判断が必要になります。人員を増やす方法は、新しく入った人が慣れるまでに時間がかかるため、終盤ほど効果が出にくい点に注意してください。範囲を絞る場合は、稼働開始に必須の機能と、後から追加してよい機能の区別が、判断の拠り所になります。
計画を大きく見直す場合は、WBSとスケジュール自体を更新してもらいます。元の計画のまま遅れを報告し続けると、どこが本当の基準なのか分からなくなります。見直した計画は、変更の理由とあわせて議事録に残しておきましょう。
参考：情報システム・モデル取引・契約書〈第二版〉ソフトウェア開発委託基本モデル契約書（ひな型）／IPA（情報処理推進機構）
参考：情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉／IPA（情報処理推進機構）
まとめ
WBSは作業を分解した一覧、スケジュール表はその作業に時期と順番を割り当てたものです。システム開発の期間が妥当かどうかは、一般的な目安ではなく、WBSとスケジュールの中身で判断します。
開発会社から出されたWBSとスケジュールでは、作業が成果物で終わっているか、作業の大きさが偏っていないか、レビュー後の修正やデータ移行など抜けやすい作業が入っているかを見ます。スケジュール表では、工程の重なり、担当者への集中、終盤のテスト期間、予備の期間の置き方、外部に依存する作業を確認すると、遅延のリスクが読み取れます。
最も大切なのは、発注側の作業がスケジュールに入っていて、その期間が自社の実情に合っているかです。WBSを受け取ったら、まず自社が担う作業と期間を抜き出し、現場の担当者の予定や社内の決裁の日程と照らし合わせてください。合わない部分を開発会社に伝えて計画に反映してもらうことが、遅延を防ぐ最初の一歩になります。