1. 今回の投稿について
こんにちは、サイオステクノロジーの安藤 浩です。SIOS Tech Labアドベントカレンダー10日目の投稿です。
技術よりというよりマネジメントよりの内容で投稿します。私は開発も行いますが、プロジェクト管理を担当することがあり、プロジェクト管理で気を付けたいポイントを記載してみます。
ソフトウェア開発のプロジェクトでは、適切なプロジェクト管理が欠かせません。スケジュール、コスト、リスク、コミュニケーション、スコープ管理など様々な考慮をする必要があります。
特にWBS（Work Breakdown Structure）の作成はプロジェクト全体像の工数、タスクを把握するために重要な基盤です。
今回は、WBSの作成方法、スケジュール作成、JiraやNotionの比較をご紹介します。
2. WBS（Work Breakdown Structure）とは
WBSはプロジェクトのタスクを階層的に分解し、管理可能な単位に整理する手法です。プロジェクトの成果物やタスクを「見える化」することで、以下のメリットが得られます：
- タスクの漏れ防止：全体を分解することで、見落としがちなタスクを発見
- 正確な工数見積もり：小さな単位に分解することで精度向上
- 進捗管理の容易化：各タスクの完了状況を明確に把握
- 責任の明確化：誰が何を担当するかを明示(出来る限りタスクに対して1名のみを推奨)
3. WBS作成の基本ステップ
3.1. 成果物の洗い出し
プロジェクトで作成すべき成果物を最初に洗い出します。
成果物の例：
- 要件定義書
- 基本設計書
- 詳細設計書
- ソースコード
- 単体テスト仕様書兼成績書
- 結合テスト仕様書兼成績書
- リリース手順書
- マニュアル・ドキュメント
3.2. タスクの分解
成果物の洗い出しと並行して、進めてもよいですが、成果物に対して必要なタスクを詳細に分解します。
分解の原則：
- 1タスクは1～5人日程度の粒度にする → タスクが大きすぎると漏れや管理が困難になります。
- 具体的なタスクの完了条件を明確にする。→ タスクによっては完了条件を決めることが難しい場合がありますが、タスクの完了条件を決めることで対応内容を明確にします。
- 「○○の作成」「○○のレビュー」など動詞で終わる形にする。 → タスク名から何をするタスクか判別できるようにします。
- 担当者を1名で対応できるタスクに分割します。 → 複数担当者にわたる場合は、タスク分割が必要です。
WBS構造の例：
担当やプロジェクト、会社によって異なると思いますが、3階層くらいまでにすることがWBS構造の把握をするためのポイントかと思います。
あまりに階層が深すぎたり、階層が浅すぎると工程やタスクがわかりにくくなります。
1. 要件定義フェーズ
1.1 要件ヒアリング
1.1.1 ヒアリングシート作成
1.1.2 ユーザーヒアリング実施
1.1.3 要件整理
1.2 要件定義書作成
1.2.1 機能要件定義
1.2.2 非機能要件定義
1.2.3 レビュー・承認
2. 設計フェーズ
2.1 基本設計
2.1.1 システム構成設計
2.1.2 画面設計
2.1.3 DB設計
2.2 詳細設計
...
3.3. タスクの前後関係（依存関係）の定義
タスク間の依存関係を明確にすることで、どのタスクが完了していなければ着手できないのかの明確化や正確なスケジュール作成を行うことができます。
依存関係の種類：
プロジェクト管理 依存関係 を見ると 「PMBOKでは依存関係という用語は定義されていない」とあり、PMBOKでは依存関係という定義がないことを知りましたが、タスクの依存関係を意識するとスケジュールが立てやすいです。
| 種類 | 説明 | 例 |
|---|---|---|
| FS（Finish to Start） | 先行タスク完了後に後続タスク開始 | 設計完了後に実装開始 |
| SS（Start to Start） | 先行タスク開始と同時に後続タスク開始 | 設計書作成とレビュー準備を同時開始 |
| FF（Finish to Finish） | 先行タスク完了と同時に後続タスク完了 | テスト実施とテスト報告書作成が同時完了 |
| SF（Start to Finish） | 先行タスク開始時に後続タスク完了 | 新システム稼働開始時に旧システム停止 |
依存関係の定義例：
以下タスクがざっくりしていますが、こんな感じです。
タスクA（要件定義）→ タスクB（基本設計）[FS]
タスクB（基本設計）→ タスクC（詳細設計）[FS]
タスクC（詳細設計）→ タスクD（実装）[FS]
タスクD（実装）→ タスクE（単体テスト）[FS]
3.4. タスクのバッファ設定
技術的に不確実性を抱えることは通常ですが、リスクに備えて各タスクにバッファ（余裕時間）を設定したり、各タスクではバッファを考慮せずに、全体の工数に対してバッファを積むことがあります。
ここでのタスクのバッファは工数見積もり時に考慮するもので、スケジュール上のバッファとは区別します。
タスクバッファの指針：
- 各タスクに例: 5～20%の余裕を持たせる(プロジェクトによってどのくらいかも異なります。バッファを積まずに楽観的な工数とする場合もあります)
- 不確実性が高いタスクほど多めにバッファを確保
- 経験の浅いメンバーが担当するタスクは余裕を持たせる
例：実装タスクの工数見積もり
├── 機能A実装: 2人日 + バッファ0.5人日 = 2.5人日
├── 機能B実装: 3人日 + バッファ0.5人日 = 3.5人日
└── 機能C実装: 4人日 + バッファ1人日 = 5人日
4. スケジュールの作成
WBSで洗い出したタスクをもとに、具体的なスケジュールを作成します。
月から金まであって「よし、5日だから5人日のタスクができるな！」となって失敗するケースがありますが、考慮すべき要素はいくつかあります。
スケジュール作成で考慮すべき要素
- 営業日(土日祝日、長期休暇など)
- スキル・経験
- タスク優先度
- バッファ
- 前工程、後工程の状況
- 稼働率
など
4.1. 稼働日を考慮したスケジュール作成
少なくとも営業日（稼働日）はどの会社にもあると思うので、スケジュールに織り込むことは必須です。
また、有休や稼働率の考慮なども必要なので、考慮すべき要素は以下かと思います。
考慮すべき要素：
| 項目 | 内容 |
|---|---|
| 土日祝日 | カレンダー上の休日を除外 |
| 年末年始・お盆 | 会社の休業期間 |
| 有給取得予定 | メンバーの休暇予定 |
| 他プロジェクトとの兼務 | 稼働率の考慮（50%稼働など） |
| 会議・定例 | 開発タスク以外の時間 |
スケジュール作成の際に毎回営業日いつだったか確認してSpreadsheet で営業日外(休日・祝日)一覧を書き出すのが面倒なので、直近やった方法を紹介しておきます。
前提
前提として、WBSには各工程のタスクの分割が行われ、タスクに対して工数が振られているとします。
| No | 工程 | タスク | 工数（人日） |
|---|---|---|---|
| 1 | 設計 | 基本設計書作成 | 3 |
| 2 | 設計 | 詳細設計書作成 | 5 |
| 3 | 実装 | 機能A実装 | 2.5 |
| 4 | 実装 | 機能B実装 | 3.5 |
| 5 | 実装 | 機能C実装 | 5 |
| 6 | テスト | 単体テスト | 3 |
| 7 | テスト | 結合テスト | 4 |
手順
- 営業日の情報を入手する。YYYY-MM-dd の形式で一覧でスプレッドシート上で扱いやすければよいですが、カレンダー形式になっていたり、画像やPDFの場合があるので、
- 1の画像やPDFをGemini 3 Proに読み込ませて「祝日と休日すべてをYYYY-MM-dd の形式で一覧に出力して」とプロンプトを入力します。※弊社には有休奨励日が設定されている(休日と休日の間の営業日が多い)ので念のためその日は休む人がいそうなので考慮に入れておきます。
- 以下のような感じで出力してくれました。
**12月 (11日間)**
2025-12-06
2025-12-07
2025-12-13
2025-12-14
2025-12-20
2025-12-21
2025-12-27
2025-12-28
2025-12-29
2025-12-30
2025-12-31
- ざっとあっていそうか確認してスプレッドシートに「休日」のシートを作成します。
- 3の結果を張り付けます。WBSの工数や納期によっていつまでの期間の情報が必要か異なります。
- 例えば2025/12/01がプロジェクト開始だとして、以下のようにC2のセルの開始日を「
=WORKDAY(WBS!F1 - 1, 1, '休日'!$B$4:$B$140)」のようにすると休日でを避けて開始日を設定することができます。
- 7. D2セルの終了日は「
=WORKDAY(C2-1,E2+F2,'休日'!$B$4:$B$140)」のようにして開始日からE2: 対応工数＋F2: スケジュールバッファの期間での休日を除いた終了日が設定されます。
※スケジュールバッファは以下で検討。 - 8. プロジェクトメンバーが複数いて並列対応が可能であれば、「並列対応」の列を用意してタスクを並列で進める考慮も行います。
- 9. 2026年1月中旬に終わりそうだとなります。
細かい作業ですが、休日一覧文字認識やフォーマットを変更したりするなども手間なので生成AIを活用して楽になりました。
4.2. スケジュールバッファの設定
プロジェクト全体やフェーズ単位で、期間的なバッファを設定します。タスクのバッファとは異なり、スケジュール上の調整日として確保します。結合テストの期間やリスクが見込まれるマイルストーンでは期間的なバッファを持たせることで例えばリリースに間に合わないということがないようにします。
スケジュールバッファの指針(例)：
- プロジェクトバッファ：全体期間の10～15%をプロジェクト終盤に確保(プロジェクトによってどのくらいかも異なります)
- マイルストーンバッファ：フェーズ終了時に調整日を設定
例：実装フェーズのスケジュール
├── 機能A実装: 1/6 ～ 1/14（6営業日）
├── 機能B実装: 1/15 ～ 1/18（4営業日）
├── 機能C実装: 1/19 ～ 1/25（5営業日）
└── フェーズバッファ: 1/26 ～ 1/28（2営業日）
-----------------------------------
合計: 17営業日
4.3. ガントチャートによる可視化
ガントチャートは、作成したスケジュールを視覚的に表現するツールですが、Excel やスプレッドシートで書くと色づけするなど変更に耐えられないので、Backlog, Jira, Notion などのツールを使った方が良いと思います。
ガントチャートに含める情報：
- タスク名
- 担当者
- 開始日・終了日
- 進捗率
- 見積工数(人日)
- 依存関係（矢印で表示）
- マイルストーン
など
ガントチャート作成ツールの例：
- Microsoft Project
- Jira（タイムラインビュー）
- Notion（タイムラインビュー）
- Backlog
プロジェクトメンバー全員で共通認識が容易にできることが重要だと思うので、Microsoft Projectはライセンスが高かったり、プロジェクトメンバー全員がMicrosoft Projectをもっていないとファイルが開けなかったりと導入には注意が必要です。
5. Jira と Notion の比較
直近だとJira(無料版) と Notionを利用しましたが、小～中規模ではNotionのほうが操作性が良く学習コストが低いと思いました。
Notionはやや操作が重くなることがありましたが、ステータスの変更によって進捗率の算出など数式を利用したいときはJiraの無料枠ではAutomation の月の上限がすぐに達してしまうのでうまくいきませんでした。
今回でだいぶJiraになれたので、次回機会があれば有料版も利用したいところです。
| 観点 | Jira | Notion |
|---|---|---|
| 価格 | 有料（無料枠あり） | 無料プランあり |
| 得意な領域 | アジャイル開発 | ドキュメント管理、柔軟な運用 |
| 学習コスト | やや高い | 比較的低い |
| カスタマイズ性 | 設定項目が豊富 | 自由度が非常に高い |
| 開発ツール連携 | GitHub, Bitbucket等と連携 | API経由 |
| チーム規模 | 中～大規模 | 小～中規模 |
WBSやガントチャートをJiraやNotionに落とし込む方法も記載しようと思いましたが、時間がないので次回にしたいと思います。
6. まとめ
本記事では、プロジェクト管理の基本であるWBS作成からスケジュール作成のポイント、Jira・Notionの比較についてご紹介しました。
1. WBS作成について：
- 成果物を洗い出し、タスクを適切な粒度（1〜5人日）に分解する
- タスクの依存関係を明確にする
- 不確実性に備えてタスクバッファを設定する
2. スケジュール作成について：
- 営業日（土日祝日、有給、稼働率）を正確に考慮する
- プロジェクト全体やフェーズ単位でスケジュールバッファを確保する
- ガントチャートで可視化し、進捗管理を容易にする
3. ツール選定について：
- Jiraはソフトウェア開発・アジャイルに強く、大規模チーム向け
- Notionは柔軟性が高く、ドキュメント管理も一元化したい小〜中規模チーム向け
