みなさんスケジュール管理はできていますか？これは多くの人にとって悩ましい問題ではないでしょうか。プロジェクトリーダーであればシステム全体の納期や機能別の納期、工程ごとの締め切りなど多くのデッドラインを抱えながら業務を進めます。また設計担当者やプログラマは与えられた業務ごとに締め切りが設定され、それに合わせて業務を進めていくことになります。
どんな立場や職種であれ締め切りは必ず存在し、その締め切りを守るためにはスケジュール管理は必須のスキルです。
この記事では、スケジュール管理に必要な考え方やスケジューリングの基本についてご案内します。
参照：フリーランスのスケジュール管理について解説した記事はこちら
スケジュール管理の基本は成果物を明確に
スケジュールを管理するための基本は「業務を細かく区切る」ことです。業務を細かく区切り、ひとつひとつに締め切りを設定してこれを守っていくことで最終ラインまでスムーズに業務が進むという算段です。
しかしながらこれがなかなか難しいと感じる読者の方もいらっしゃるのではないでしょうか？
エンジニアが業務を細分化する際に最も基本とするべき考え方は「成果物で区切る」ことです。
「成果物をひとつのマイルストーンととらえ、最終ラインまでにいくつのマイルストーンがあり、ひとつ先のマイルストーンにいつまでにたどり着けば良いかを明確にする」ことが大切です。
これはシステムエンジニアであれ、プログラマであれものづくりに携わる人なら全員何らかの「成果物」を提出する必要があります。
まずは自分がどんな成果物を作る必要があるのかを明確にしましょう。
成果物を利用したスケジュール管理の基本
成果物をスケジュール管理に使うために、さらに「最終成果物」と「中間成果物」に分けて考えてみましょう。
あなたがプログラマや設計担当者であれば、必ず自分が作成する「最終成果物」を明確にして、これを仕上げるために必要な「中間成果物」にはどのようなものが必要かをさらに細かく考えていきます。
例えばあなたが帳票を出力する機能を担当しているエンジニアだとします。その場合、最終成果物は「帳票出力機能があるプログラム」です。中間成果物としては「帳票設計書」「テスト仕様書」「ソースコード」が挙げられます。もし「帳票設計書」を作るために必要な機能設計書や詳細設計書がまだ準備できていないのなら、これらはいつまでに必要か、いつごろ完成する見込みかといった内容をプロジェクトリーダーなどと相談する必要があります。
まず基本は「成果物」で、さらに「最終成果物」と「中間成果物」を積み上げていくことでスケジュール管理に必要なマイルストーンが見えてくるでしょう。
初心者は精度より業務イメージを具体化してスケジューリング
担当する業務がはじめての場合や新規顧客の場合は成果物がわかっても所要時間やスケジューリングが難しい場合があります。この場合はどのように対応すればよいでしょうか。
はじめての業務ですから、当然ながらスケジューリングは非常に困難なため、はじめての業務で精度の高いスケジューリングを行うことは最初の段階では無謀です。
ただしあくまでも「最初の段階だけ」であることを忘れないでください。最初の段階では精度の高い見積もりではなく、できるだけおおまかで業務全体が見渡せるようなスケジューリングをすることが肝心です。
そしておおまかなスケジューリングをしながら「ステークホルダーへの相談」を行いましょう。
顧客や上司に対して、いつごろまでにその業務を終わらせたいのか、自分に求められる成果物は何かといったことをヒアリングしながらその業務への概要を掴み、業務イメージを膨らませていきます。
プログラマや設計担当者であれば、似たような業務に携わったことがある人が周りにいるかもしれませんから、そのような人たちの話を聞くこともとても大切です。
さらに使えるものは、他の業務のスケジュールです。他の業務のスケジュールを参照して、自分が取り掛かろうとしている業務とどのような違いがあるのか、似ている部分はないかを探していきます。はじめての業務はいわば「雲をつかむような感覚」で考えてしまいますが、他の業務のスケジュールを参照することで「取り掛かろうとしている業務の輪郭を浮き彫りにする」ことが大切です。
はじめての業務はとにかく取っ掛かりが少ないものです。そのような状態でスケジューリングをするのは手戻りやスケジュール変更といった事態になりかねませんから慌てないようにします。
もし仮に、はじめての業務や不明点が多いにもかかわらず急いでスケジューリングをする必要がある場合は、無理に予定を立てずにステークホルダーに相談しましょう。スケジューリングのミスは関係者全体に影響が及ぶこともあります。予想されるリスクの管理や共有はエンジニアとして重要な仕事の一つです。
参照：厚生労働省「フリーランスとして安心して働ける環境を整備するためのガイドライン」
似た業務経験がある場合はスケジュールをそのまま使う手もあり
以前に似たような業務を経験している場合、スケジューリングの難易度はかなり下がります。担当したことがある業務の資料や記憶をたどりつつ、どのような成果物を作ったのか、それにはどのくらいの所要時間がかかったかなどできるだけ洗い出しましょう。
あくまでも基本となるのは「成果物」です。以前の業務で作成した成果物を基本にして、今回はどのようなものを作るのかを洗い出します。そして出てきた結果を時間軸に当てはめ、マイルストーンとして利用していきましょう。
規模や内容が似ている業務であれば、ざっくりとその業務のスケジュールを仮のスケジュールとして利用する荒技もあります。スケジュールが最初にしっかりと固定されることは少なく、必ずどこかで変更や前倒しなどが発生するものです。この場合はある程度スケジュールや業務内容が固定されるまでは似た業務のスケジュールに従い、できる範囲の業務から取り掛かるほうが効率的です。そして進んでいる業務と止まっている業務、必要な成果物と出来上がりに近い成果物を明確にしておいた上で全体のスケジュールの策定にフィードバックさせていくといったや方法が考えられます。
スケジュールの見直しは業務記録がポイント
スケジュール管理の上で最も重要なことは見直しが発生したときの対応です。あくまでも「管理」ですから、見直しや変更には柔軟に対応できるように普段から準備しておきましょう。
では見直しが発生した場合はどのような対応が必要でしょうか。当然ながら、スケジュールの見直しによって影響を受ける関係者への相談や説明が必要となります。しかし関係者がすんなりと見直しを受け入れてくれるとは限りません。そこで必要となるのが「説明の材料」です。
説明の材料は見直しの内容や業務によってさまざまですが、どんな場面であれ業務記録が活躍します。プログラマであれば1日〜数日でコーディング出来る量の記録、プロジェクトマネージャであれば会議の議事録やメールなど、必要となる記録はさまざまです。
いずれにしても「他者に説明できる材料」を用意して、「なぜその見直しが必要なのか」「なぜ見直しを受け入れられないのか」「どうすれば見直しを受け入れられるようになるのか」といった交渉の根拠を必ず作りましょう。
スケジュール管理能力はエンジニアスキルに比例します
エンジニアのスケジュール管理について書きましたがいかがでしたか？
スケジュール管理といっても、職種や立場、業務内容によってさまざまですがこの記事では「成果物」を中心としたマイルストーン作りを起点として、さまざまな考え方を書きました。
求められる成果物はどのようなものか、どのくらいの大きさか、何がいつまでに必要かといった「見通す力」はエンジニアスキルと深い関係にあると言えるでしょう。見通す力には技術スキルだけではなく、関係者とスケジュール調整をする交渉力やヒアリング力といった技術以外の力も含まれます。
スケジュール管理に優れたエンジニアは時間や予算の管理も優れているものです。
スケジューリングを通じて、エンジニアに必要なさまざまな能力を磨いてくださいね。
