【仕事】区切りとタイミングが大事

月次、四半期、半期という区切りで仕事をしなくても良いのですが…

仕事の「まとまり」の区切り

仕事のまとまった区切りは、だいたいが週次、隔週、月次、四半期、半期、年次…という区切り方が多いと思います。

本当に必要なときまでにタスクが終わる、成果が出ているべきと考えると本来は週や月などの区切りのよいところに納期や期限を設定する必要はないはずですが、人間は仕事だけでなく普段の生活も交えると、キリの良い区切りやまとまりで動いているので、週や月といった区切りの方が、わかりやすいというところもあります。

アジャイルでのスクラムでも、タイムボックスという考え方でスプリントの区切りを設けますが、これは仕事にリズムをつけることで、スクラムのプラクティスを習慣化することができます。変化に対応するために、むしろ短い区切りで回していくことで、これまでも仕事の仕方でよく言われるPDCAの動きを素早く回せるイメージです。

そういう意味でも区切りで計画し、区切りで動くことは特に疑問を感じることは少ないかと思います。

多くが区切りで動いている

この区切りの持ち方は、仕事の大きさや内容によって変わってきます。
開発の委託や受託の案件だと、人の確保や環境構築などリソースと整備する時間などを考えると、それなりの区切り、短くても1ヶ月、通常は3ヶ月か半年という大きさで契約をして実施することが多いでしょう。

そして、その区切りの節目にあたるところは、会計年度でいえば4月から四半期や半期という切り方で言えば、1Q（第一四半期）が6月末まで、2Q（第二四半期）や1H（上半期）が9月末まで、という契約になってくることが多くなります。

この区切りの動き方でプロジェクトを考えておかないと苦労する場面があります。
それは私も実施あったのですが、諸々予定が狂って、1Qの途中から開発をスタートさせたかったのですが、社内でも社外でも、節目ではない期間の途中から開発人員を確保することはかなり難航しました。
仮に確保できたとしても、他の案件にメインで入っている人の一部の工数（たとえば、10％や20％）を持ってくる程度で、開発スピードは上がりません。

必要なときに人を確保するというプロジェクトにとって、この区切りや節目の影響を考えておかないと、机上の企画や構想はできても、実働できる人員が確保できないという問題に直面します。

予めリスクとして見ておく

前の年度からきっちり計画されて進められるプロジェクト、つまり何か仮説検証したりするわけではなく、発売やリリースが確約されているプロジェクトは、よくある区切りで予算と人員確保すればよいですが、このような確度が高いプロジェクトは今の時代、そこまで多くはないでしょう。（国家プロジェクトでやることが既定路線であれば別ですが）

不確実で正解のわかりにくい時代に、仮説を立てて検証しつつ、プロダクトを小さく早く改善したり、時にはピボットすることが必要なプロジェクトでは、スタートも終わりも、わかりやすい区切りや節目で動かない場合も多いでしょう。

とはいえ、世の中の動き方、リソースや予算の動き方が自分たちの動きにフィットして動くとは限りません。確保出来なかった場合のリスクをマネジメントし、その対処やプランBなどを持っておく必要があることを頭に入れておくとよいでしょう。