「この機能、本当にリリースまでに間に合うのか…？」
「開発メンバーから上がる進捗報告、バラバラで全体像が掴めない…」

システム開発の現場では、こうした悩みはつきものです。

プロジェクトマネージャー （PM） やチームリーダーにとって、スケジュール管理はプロジェクトの成功を左右する重要な責務と言えます。顧客からの変更要求や技術的な問題発生など、予測不能な事態が起きることの方が多く、最初に立てたスケジュールの通りに進むことは、むしろ稀でしょう。多くのPMやリーダーがスケジュール管理に悩んでいます。

闇雲にタスクを詰め込み、間に合わせるために徹夜をするという時代もありましたが、今は、そんな時代ではありません。

スケジュール管理の技術は、ただ納期を守るためだけのものではありません。プロジェクト全体のリソースを最適化し、メンバーの生産性を最大限に引き出すことで、高品質なシステムを効率的に開発するための重要なプロセスなのです。

本記事では、システム開発の現場で活用できる「実践的なスケジュール管理術」を解説します。

精度の高いスケジュール作成の手法

システム開発プロジェクトにおけるスケジュールは、ただ闇雲に作成すれば良いというものではありません。開発に関わるメンバー全員が、スケジュールに記載されたタスクとその意味、そして全体像を正しく理解することで、初めてプロジェクトは円滑に進みます。

ここからは、精度の高いスケジュールを作成し、それをプロジェクトメンバーに浸透させるためのポイントを紹介します。

マスタスケジュール（ドラフト版）の作成

まずは、プロジェクト全体のゴールとなる「システムリリース日」を明確にする必要があります。顧客やユーザー部門との合意はもちろんのことですが、その期日を守るための開発期間の妥当性を検証しておくことが特に重要です。

PMが最初にするべきことは、マスタスケジュールのドラフト版を作成することです。このマスタスケジュールには、主に２つの目的があります。

  • プロジェクト全体の組み立てを考える
  • チームスケジュールの作成を指示する

マスタスケジュールは、１つのプロジェクトに対して、概ね１つか２つ作成されることが一般的です。

プロジェクト計画フェーズの中で最初のマスタスケジュール（ドラフト）を作成し、このプロジェクト計画フェーズ完了のタイミングで、ドラフト版に記述された内容を見直します。その後、プロジェクトの状況に応じて、要件定義完了時やテスト開始時に万全を期す目的で再作成されることもあるでしょう。

スケジュールの横軸は月単位の時系列とし、縦軸には主にチームの単位での大まかなタスクを配置しましょう。このマスタスケジュール（ドラフト）が完成したら、各チームのチームリーダーに「チームスケジュール」の作成を依頼することになります。

チームスケジュールの作成

プロジェクトの各チームリーダーが作成するのがチームスケジュールです。「マスタスケジュール（ドラフト版）」を元に各チームのスケジュールを作成することになりますので、１つのプロジェクトに対して、チーム数分のチームスケジュールができあがることになります。

このチームスケジュールは、実際にチームメンバーが参照し、チームの進捗管理にも用います。「マスタスケジュール（ドラフト版）」に記載された各フェーズの大まかなタスクをより小さく具体的な作業レベルにまでブレイクダウンしていくことで、作業漏れを防ぎ、正確な作業見積もりに繋げます。

段階的に階層構造に分解する形で、最終的には担当者が１人で１日～数日で完了できる程度の粒度まで細分化することが必要です。ここを怠り、タスクが大きな粒度のままとなると、進捗管理が難しくなり、問題が起きた時の検知が遅れてしまう可能性があります。

タスクを階層構造に詳細化していく際には、WBS（Work Breakdown Structure）を用いることがあり、ITPro ToolBoxでも、これを推奨しています。成果物を管理しやすい単位まで細分化することで、WBSの最小構成要素であるワークパッケージを定義します。WBSに含まれるすべての作業項目を説明するドキュメントとして、WBS辞書の形式でまとめます。（WBS辞書とは、そのワークパッケージにおいて、どの成果物を何をインプットにどのようなプロセスで作成するのか？を定義した文書のことです）

最終的にでき上ったスケジュールは、線表形式になっていることが望ましく、各タスクに必要な資源と所用時間を書き加え、開始予定日と終了予定日をバーや矢印で繋ぐ形で表現します。いわゆるガントチャート（Gantt Chart）と呼ばれる表現形式です。

ガントチャートは、タスクの開始日と終了日、タスク間の依存関係などを視覚的に表現できるため、これを用いることで、タスクの全体像の把握や進捗管理が容易になります。

これらのドキュメントは、ExcelやGoogleスプレッドシートで作成されることも多いですが、より効率的な管理を目指す場合には、プロジェクト管理ツールを導入することも検討しましょう。ひと昔前だと、Microsoft Projectが有名でしたが、最近ではサブスクリプション（Microsoft Plannerの一部となっています）でも提供されているようです。その他のツールでは、Atlassian社が提供しているJiraや株式会社ヌーラボのBacklogなどがあります。

マスタスケジュールの修正

各チームリーダーが作成したチームスケジュールについては、必ずPMがレビューします。PMは全チームのスケジュールをレビューし、その内容をマスタスケジュールに転記しながら、整合性のチェックを行います。

整合性チェックについては、以下の観点で、最初に作成したマスタスケジュール（ドラフト）と比較するのが良いでしょう。

  • 各タスクの完了納期や予定日が合っているか？
  • タスクの漏れがないか？
  • チームを跨ぐ各タスク間での前後関係が守られているか？

各チームが作成したスケジュールの辻褄が合っているのかをチェックし、そのスケジュールの実行可能性を確認するのは、このタイミングでないとできません。

チームリーダーの視野は他チームには及ばないことも多く、チームの作業計画を立てる際に、プロジェクト全体の都合や他チームのタスクとの依存関係などを考えられていないことがあります。そのような場合には、このレビューの場で指摘することになります。

マスタスケジュールや他チームの作業スケジュールとの整合を守ることができない何らかの事情がある場合も、このレビューの場で、チームリーダーからのエスカレーションを受けることになります。例えば、リソース起因の問題であれば、追加メンバーのアサインを手配することになります。また、タスクの依存関係の都合でマスタスケジュール通りにならない場合は、マスタスケジュールの方を修正し、各チームのチームスケジュールにもその修正内容をフィードバックすることとなります。

作業明細スケジュールの作成

チームスケジュールを作成する際に、同一かつ大量の作業明細があるタスクについては、必要に応じて、作業明細スケジュールを作成することになります。例えば、システムの画面を定義するドキュメント（画面設計書）について、画面の数だけ作成する必要がある場合などが、これにあたります。

この場合、前述のチームスケジュール上に、各画面の画面設計書タスクを並べるのではなく、別の作業明細スケジュール上で、各画面単位の「ドラフト作成」「リーダーレビュー」「顧客レビュー」「修正版作成」などの予実を管理するのが適切です。

スケジュール作成における重要なポイント

スケジュールは、PMやチームリーダーだけが利用するものではありません。プロジェクトに参画しているメンバー全員で共有するコミュニケーション文書だと認識するのが肝要です。

ここに記載された内容について、作業者とPMやチームリーダーの間で認識齟齬があった場合には、プロジェクト全体の遅延や品質低下に繋がります。どの成果物をどのようなプロセスで作成するのかを文書化しておくことが大事ですし、各タスクの進捗状況が可視化されている必要があります。前者のためのWBS辞書であり、後者のためのガントチャートなのです。

スムーズな開発のための進捗管理テクニック

スケジュールを作成したら終わりではありません。むしろ、そこからが本番であると言えます。

システム開発に限らず、プロジェクトが当初の想定通りに進むことの方が稀であり、様々な要因で遅延が発生する可能性もあるでしょう。

PMやチームリーダーには、進捗状況を常に把握した上で、問題が発生した場合には、迅速に対応していくことが求められます。

問題を早期に発見することの重要性

スケジュール通りに進んでいるかを定期的に確認し、プロジェクトに何か問題が起きている場合には、これを早期に発見することが重要です。そのためには、各メンバーや各チームリーダーが「悪い報告」をエスカレーションしやすいような雰囲気を醸成していく必要があります。

例えば、進捗遅延や課題発生の報告を受けた時に、あからさまに不機嫌になってしまうのは、PMとしては論外です。また、遅延回復や課題解決を報告元のチームだけに押し付けるようなことが続くことも、「悪い報告」を上げにくくなるため、回避するべき状況と言えます。どのような厳しい状況であっても、まずは、問題が早期に発見されたことを歓迎する姿勢が大事です。

問題の検知が遅れると、最悪の場合は、リリース延期や開発コスト増大に繋がる可能性もありますし、更にチーム内だけで自力で問題の解決を図り、うまく行かなかったことを隠ぺいするようになると、システムに重大な欠陥を抱えたまま、テストフェーズや本番リリース後に問題が発覚するという事態にもなり兼ねません。

進捗報告のサイクル

プロジェクト規模や報告先によって、適切な進捗報告の頻度というものがあります。ここでは、一例を示しましょう。

チーム内：日次での朝会・夕会を実施するほか、チャットツールなどで随時情報を共有するなど、密なコミュニケーションを心掛ける必要があります。

プロジェクト内：プロジェクトでの進捗報告会議は、週次で開催し、進捗状況や課題を共有するのが良いでしょう。何か問題があった場合には、必要に応じて、他チームと協力の上で解決にあたることが必要です。

上位マネジメント向け：フェーズ終了時や月次での報告を行なうケースが多く、プロジェクトの全体像を簡潔に把握できるような報告資料が必要となります。

進捗遅延への対応方法

進捗遅延が発生した際には、まず、原因を分析することが重要です。

一般的によくある原因の分類としては、あくまで一部の例となりますが、以下のようなものがあるでしょう。

  • 技術的な問題
  • 前工程の甘さ
  • メンバーのスキル不足
  • コミュニケーション不足
  • 計画時の過少見積もり

こうした原因を明らかにした上で、実際の遅延回復策においては、スケジュールかリソースを調整するのが一般的な対応となります。

  • スケジュールの調整
  • 作業担当者の変更
  • 追加サポート要員のアサイン

それだけで解決できないような大きな問題が発生している場合には、顧客を巻き込んだスコープの調整などを行う必要もあるかもしれません。

原因分析と対策のススメ

どれだけ緻密な計画を立てても、予期せぬ事態は発生するもの。もう少しだけ、遅延が発生した場合の原因分析と対策を深掘りしてみましょう。

遅延理由の分析：問題の根本原因の特定

問題が起きた場合には、まずは、冷静に状況を分析し、遅延の根本原因を突き止める必要があります。以下は、現場で発生しやすい遅延理由を例として挙げてみたものです。

  • タスクの難易度や作業量の見積もりミス:
    • 新技術の導入や、複雑な要件定義が絡むタスクの場合、当初の見積もりが甘かった…というケースは少なくありません。
  • メンバーのスキル不足:
    • 特定の技術に精通したメンバーが不足しており、開発が滞ってしまうケースがあります。
  • 突発的な業務の発生:
    • 緊急度の高いバグ対応や、顧客からの急な要望変更などにより、開発リソースが圧迫されてしまうことがあります。

差異と傾向の分析：客観的な指標による現状把握

スケジュール遅延やコスト超過が起きている場合には、立案した計画に対する実績を確認し、何が差分となっているのかを分析することが必要です。

プロジェクトの現時点の状況を把握することができたら、その傾向を踏まえて、今後の状況を予測することになります。

こうした分析のヒントとなるナレッジのひとつに、Earned Value Management (EVM) の考え方があります。EVMを用いることで、プロジェクトの進捗状況を客観的な指標で把握することができます。EVMを用いた進捗管理には手間もかかり、これを適切に運用できているプロジェクトを見かけることも少なくなりましたが、それでも有用な考え方ですので、簡単にご紹介しておくことにします。

EVMを用いた管理では、主に、以下の数値を把握します。

  • AC (Actual Cost): 実際にかかった費用
  • PV (Planned Value): 計画時点での予定費用
  • EV (Earned Value): 完了した作業に対応する費用

これらの指標を比較することで、プロジェクトが予定通りに進んでいるのか、当初予定通りのコストでタスクが進められているのか、といったことが可視化できます。例えば、「AC > PV」かつ「EV < PV」の場合は、予定よりも費用がかかっているにも関わらず、進捗が遅れている状態であることが分かります。

コスト効率が悪いという状況が分かった場合、当初の見積もりが甘く、今後も投入コストに合った成果物が生産されない状況になることが示唆されています。一方で、コスト効率上の問題がないにも関わらず、遅延が発生している場合には、それは予定通りのリソースが投入できていないことが分かります。（一般的に、後者のような状況になる場合には、要員の病欠による離脱や突発的な計画外作業などが発生していることが多いです）

遅延への対策立案：状況に合わせた柔軟な対応

遅延の原因が明らかになったら、状況に合わせた適切な対策を検討・実行します。例えば、以下のような対応が考えられるでしょう。

  • タスクの再計画:
    • スケジュールを見直し、優先度の低いタスクを延期したり、タスクの担当者を変更したりする
  • 人員の追加:
    • 開発体制を見直し、人員を追加することで開発速度を向上させる
  • 作業の効率化:
    • 開発プロセスを見直し、無駄な作業を減らすことで効率化を図る
  • 顧客との交渉:
    • 納期の延長や、要件の変更を交渉する

実際にどのような対応を採るかについては、そのプロジェクトの目的や目標に照らして、どのような制約があるのかを確認し、それを踏まえた判断と調整をする必要があります。

リスクヘッジ：事前対策による問題の極小化

ここまで遅延発生時の対応について、述べてきましたが、起こってしまってから対応するのではなく、事前に予防策を講じておくということも重要です。

  • リスクの洗い出し:
    • プロジェクト開始時に、発生しうるリスクを洗い出し、対応策を検討しておく
  • バッファ時間の確保:
    • 見積もり段階で各タスクにバッファ時間を設けておくことで、不測の事態に備える

前者は、スケジュール管理というよりは、リスク管理の範疇に入る話題だと思いますので、ここでは後者について、簡単に述べます。

バッファ時間を見積もることは、有効なリスクヘッジにはなり得ますが、各チームが作業を見積もる際に、チームリーダーが各自の裁量でバッファを乗せてしまうと、どうしても過剰な見積もりとなる傾向があります。バッファ時間の確保とその管理については、チームリーダーには共有されるべきものですが、基本的には、PMの責任範囲であることを理解しておく必要があります。

おわりに

システム開発におけるスケジュール管理は、プロジェクトの成功を左右する重要な要素です。本記事で紹介したスケジュール作成、進捗管理、遅延への対応策は、いずれもプロジェクトを円滑に進めるための重要なポイントとなります。

完璧なスケジュール管理は難しいかもしれませんが、計画段階での入念な準備と進捗状況に応じた柔軟な対応ができれば、プロジェクト成功に大きく近づくでしょう。

本記事を参考に、あなたもプロジェクトを成功に導くためのスケジュール管理術を実践してみてください。