案件の種類や規模にかかわらず、スケジュールを設計することはとても重要です。
特に事前に要件やスケジュールを綿密に計画する「ウォーターフォール型」であれば、スケジュール設計が甘いとタスクごとの遅延が発生し、全体の納期に大きな影響を与えます。
小規模の実装とテストを繰り返して開発を進める「アジャイル型」の場合でも、全体の要件に対する見込み工数や期間から予算を出すために、スケジュールを設計することが大切です。
今回はスケジュール設計でよく使われる「WBS（Work Breakdown Structure）」について書いてみます。
スケジュールを調整するタイミング
スケジュールを調整するのは要件定義後から見積を提出するまでの間、もしくは見積と同時に行うことが多いかと思います。クライアントからの要求として希望納期を言われていたとしても、要件定義後、工数を出し、現実的なスケジュールを伝えて納得して頂けるよう調整させて頂くことが重要です。
スケジュール提出を後回しにして、「クライアントから事前に納期を聞いているし、押し込めばなんとかなるかな」といった感覚で進めることは非常に危険です。あくまでクライアントからの機能要件に対して現実的なスケジュールを設計し、見積前に調整させて頂くようにしましょう。
特にプロジェクトの初期フェーズでは、以下のタイミングでスケジュール調整を行うべきです。
要件定義の完了後
大まかな機能一覧が出揃ったタイミング
チーム体制と担当者が固まったタイミング
クライアントと納期の期待値をすり合わせた直後
この初期調整が甘いと、後工程で無理なスケジュールになりがちです。「調整」ではなく「設計」の視点でWBSを扱うことが成功の鍵です。
また、プロジェクトが進むにつれて、要件定義の抜け漏れや、チーム体制の変更など、スケジュールを変更しなければいけない場合もよくあります。そのような場合は、「一度決めたスケジュールも必要に応じて柔軟に変更する」という意識が重要です。この意識は、クライアントや制作／開発チームを含め、プロジェクト全員に共通で意識して頂くよう周知する必要があります。
ここで最も重要なことは、プロジェクトチーム一丸となって、プロジェクトを完成し、エンドユーザーのためにリリースする、というゴール設定です。このゴールに対して、「プレスリリース等の計画もあり、納期は絶対に変更できない」場合は、「一部機能を後追いとさせて頂くことで、納期通りリリースが可能です」といった交渉を実施することで、プロジェクトを推進するために、スケジュール設計が重要になってきます。
機能一覧と対として作成する
WBSは単なる作業の羅列ではなく、機能要件をもとにブレイクダウンした構造的な工程表です。この段階での整理が甘いと、作業抜け・工数見積もりミス・スケジュール遅延に直結します。
機能間の関係性を考慮する
各タスクは単独で動くわけではなく、他のタスクに依存していることがほとんどです。例えば下記のように、タスク間に依存関係があります。
APIが完成しないとフロントエンドの結合テストができない
管理画面ができるまではクライアントにデータを渡せない
このように、依存関係（前後関係）を意識したWBS構成が必要です。
プロジェクト管理ツール（BacklogやRedmine、Jiraなど）を活用すれば、ガントチャート形式で視覚的に把握できるため、おすすめです。
見積工数に1.2〜1.5倍程度のバッファを持たせて調整する
見積を人日で出す場合、基本的には1人日＝8時間という認識で算出することが多いかと思います（休憩を考慮して7時間という考えもあります）ので、例えば1人日という見積は、「付きっきりで対応した場合」という意味合いになります。
但し、あくまで見積時点の工数算出ですので、人日をそのままスケジュールに反映すると、ゆとりがまったくなくなってしまいます。他の案件も並走している場合は尚更、付きっ切りで対応は出来ない前提であることもあります。また、クライアントによるレビュー、レビューに対する修正など、想定する実作業以上に時間がかかってしまうことも想定できます。
そのため、WBS（スケジュール）を設計する時は、見積工数に1.2〜1.5倍程度のバッファを持たせて調整するのが安全です。
特にフリーランスの場合、体調不良や急な家庭の用事にも自分自身で対応する必要があるため、余裕を持った計画を立てましょう。
カレンダーに反映されないお休みを忘れないようにする
お正月含めた年末年始やお盆、GWやシルバーウィーク内に含む平日は、お休みとさせて頂きたいこともあります。自分自身の都合もありますが、クライアント側も同様にお休みを取得される場合もあります。そのような場合、休暇期間中にクライアントに報告しても、確認が進みません。
そのため、このような休暇時期を挟む場合は、事前に稼働日数から外してスケジュールを設計しておいた方が、健全な進行に繋がります。開発側としては、スケジュールに遅延が発生しそうな場合、これらのお休みの時期に巻き取れる、という保険としても活用できます。
クライアント側に必要な対応も考慮する
WBSを作成する際、自分たちの作業だけをもとに設計してしまうのはNGです。プロジェクトには必ずクライアントの確認作業や対応タスクが存在し、それらが遅れるとプロジェクト全体の遅延に繋がってしまうこともあります。
クライアントによる確認対応
仕様確認、デザインレビュー、成果物の検収など、プロジェクトの進行においてクライアントに判断を仰ぐ場面が必ず存在します。
このタイミングで想定以上に時間がかかるケースが多いため、「ここで3日遅れると、後ろの工程も3日ずれる」ということを事前にWBSに盛り込み、余裕を見ておくことが重要です。
実装完了後の受入テスト
開発が完了しても、それを受け入れるかどうかはクライアント次第です。受入テストでは、実装の意図が正しく伝わっていない場合や、仕様認識のずれが明らかになることもあります。この対応フェーズをWBSの一つの工程として見積もっておかないと、納品が「想定より1週間以上遅れる」ことも珍しくありません。
また、受入テストの体制（誰が、どの観点で確認するのか）を事前にクライアントと擦り合わせておくことも、スケジュール管理上のポイントです。
WBSは「更新」し続けるもの
WBSは一度作ったら終わりではありません。むしろ、「プロジェクトの進行に合わせて都度更新する“生きたドキュメント“」として扱うべきです。
進捗や課題、仕様変更などを反映させることで、スケジュールの現実性を保つことができます。
定例ミーティングのタイミングでWBSを最新化し、次回までの作業範囲を明確にする運用を習慣づけると、関係者の認識ずれを防げます。
「WBSを見れば、今どこにいて、次に何をすべきかが一目でわかる」という状態が理想です。
まとめ
フリーランスとしてIT業界で活躍するためには、WBSを使った進行スケジュールの整理は必須スキルです。
以下のポイントを意識してWBSを作成・運用することで、スケジュール遅延やタスク漏れのリスクを大幅に軽減できます。
スケジュール調整は初期段階で行う
WBSは機能一覧とセットで構築する
依存関係・バッファ・休暇日程を盛り込む
クライアント側の確認・受入工程もWBSに反映
WBSは常に最新化する
クライアントにとって「この人に任せれば安心」と思ってもらえるスケジュール管理を行い、信頼を積み上げていきましょう。
