スケジュールの立て方

はじめに

個人のタスクのスケジュールを立てるときの考え方、方法について記載していく。
 
※リーダーが案件全体のスケジュールを立てるときも基本的には同様の考え方と思われるが、案件全体のスケジュールの場合はもっと考慮すべき点があるため、基本的には個人のスケジュールの立て方に絞って以下に記載していく。 

[追記]一番重要なこと

※スケジュールを立てる上で一番大事なことを記載していなかったので、一番最初に加筆します。

スケジュールをパンパンになるまでタスクを入れないこと。
要求されたタスクは、得てして明確なものばかりではありません。

調査対応や検討事項などもあり、
結果次第では元々のスケジュールにハマらないということもよくあります。

リスケすれば良いでしょ、という考え方もありますが、
最初からバッファ込みでスケジューリングしましょう。
パンパンに詰め込んで、苦労するのは自分です🔥

タスクの明確化 

対応するタスクの目的、内容を明確化する。
開発であれば、作成する機能や難易度により開発期間は前後するため、要件や非機能要件などを明確化する必要がある。

この過程で、Input/Outputを明確にすべき 
　で、Inputの提供が遅れたその分だけスケジュールは遅れることを予め関係者とネゴっておく 

もしスケジュールを立てる段階で要件が明確化していない状態であれば、必ず要件が確定した段階で再度リスケジュールすることを前提とする。 

つまり、スケジュールを再度引くことをリーダーなどにあらかじめネゴっておこうね、ということ
まあ得てして最初の概算見積もりが一人歩きするんだけどね🔥

 

期日の明確化 

期日を明確化する。
その上で
・期日は必ず守る必要があるのか？
・それとも要件が明確化した段階でリスケジュールし、期日を後ろにずらしたり調整可能か？
も明確にする。 

また、逆算して、期日までにどういうサブタスクをこなし、どういう関係者と連携していく必要があるか考える。
 

タスクの前提条件と目的達成条件の明確化 

目的を達成するために、どんな前提条件が必要か検討する。 

また、目的達成条件として何をどの範囲まで、どの程度まで対応する必要があるのか明確にする、ということ。

この明確化は、自分一人で決めることが出来れば良いが、多くの場合はリーダーなど自分より上の人に確認が必要になると思う。

この判断が難しい場合は、とにかく周りに聞くこと。不明瞭な状態でタスクを進めると確実に失敗します😨

 

タスクの明確化 

目的を達成し、期日を守るためには何が必要かを逆算して考える。 

また、要件を満たすためにどんなサブタスクが必要なのか考える（タスクの粒度が細かくなれなるほど精度は高くなるはず）。 

そして、"クリティカルパス"　を把握し、開発中の進捗に影響の出るタスクに対して特に注視する必要がある。 
（クリティカルパス=プロジェクトを進めていく上でスケジュールに影響が出る作業経路） 
 

利害関係者の洗い出し 

登場する利害関係者が増えるほど、スケジュール調整が必要となりより長い期間が必要になってくるため、スケジュールを立てる際に洗い出す。 
 

連携する機能、システム 

他社、もしくは他担当者が開発する範囲で、自分（もしくは自社）が開発する機能にどう影響するかを把握する。 

システム内の機能の連携、他のシステムとの連携が発生する場合、各機能の担当者間で意思疎通のための打ち合わせが必要となる。また、連携先のシステムでも改修が発生する場合は足並みを揃えてリリースしなければならないため、その影響は大きい。 

例） 
　サーバ側のAPI修正が必要で、自分が担当するアプリ修正に影響が出るとする。 
　　→サーバ側のAPI修正のスケジュールも意識する必要がある。 
　　→関係するPhase（テスト担当者、デザイナーやディレクターによる受け入れ、
　　　総合試験、顧客のレビューなどなど）によっていつまでに実施する必要があるのかを理解し、
　　　逆算することで自分のタスクをいつまでに実施する必要があるのかが分かる。 
 
その上で、作業量と見合わせてスケジュール通りにこなせるのか？無理やりスケジュールに当てはめていないか考える。無理なスケジュールを立てても自分が苦しむだけだが、顧客に説明を求められたときにある程度説明できる程度の範囲で自分が苦しまないスケジュールを立てる。 
 
 

開発中のトラブル対応

最初に立てた理想通りのスケジュール通りに事が進めば良いが、自分のタスクの一部であるコーディング作業が思いのほか重かったり、他担当者の遅延の影響で自分の作業が止まる、他担当者のチェックが漏れており終盤でチェックしたら重大な仕様の考慮漏れがあった、とか、、 

こういう場合は、以下順序で検討していく
・まずは自分だけで対処可能なのか？
・自分だけで無理であればチーム内のメンバーを巻き込んで対処可能か？
・上記が無理そうであれば、スケジュールが調整可能か検討すべき 

スケジュールに入れたタスクを明確化しないと何が起きるのか、、、 
・スケジュールの精度が落ちる 
　→実際のブレが生じやすくなり、不測の事態がおきやすくなる 
・やるべきタスクの見落としが発生する可能性が高くなる 
　→特に他担当者が実施するタスクが、実は自分が実施する必要があるタスクだったりとか、、 

例） 
　ある機能の開発に3日かかるというスケジュールを立てたとする 
この期間内に対応完了して顧客に報告し、３日目に顧客側で受入試験を実施しクレームが入る。遅延が発生していると言われたがよくよく顧客にヒアリングしたところ、顧客側は顧客受入試験も完了しバグ0の状態が３日という想定だ、という。 
 
　上記例だと結果的に以下のような齟齬があったことになる 
　・開発側：開発側での実装・単体試験・結合試験 
　・顧客側：生産・製造リードタイム（実装から顧客受入試験を経てバグ0の状態とする） 
 
　これで顧客から怒鳴られることもあるため、立てたスケジュールがどういう前提でたてられているのかを明確化する。