「うつになったことはありますか？」

この質問に対して，大多数の人が経験無いと答えると思います。では次の問はどうでしょう。

「⁠一ヶ月の残業時間が８０時間以上の月が２～６ヶ月続いたことはありますか？⁠」⁠

これには多くの人が経験あると答えるでしょう。私は後者の状態が大きなファクターとなってうつをこじらせました。

今でもよく覚えているのですが，掛かりつけの医者に上記のような残業時間の話をしたら，とたんに表情を変え，そういう状況では２人に１人は身体的・精神的な問題が出ることと，すぐに仕事を休みなさいという事を言われました。長い時間の労働は体や心に多大な負担をもたらすということです。

つまりそのような状況では，誰だってうつを発症する可能性があるということです。

これを防ぐには，早く帰るのが一番簡単な問題回避方法と考えています。そして仕事を続けていく上では，健康を保ちつつも，きちんと作業のアウトプットを出す事ももちろん必要です。

そのためには，進捗を計測して正しく作業が進んでいるかをチェックすることが欠かせません。

進捗を計測するとはどういうことか

進捗の計測は簡単です。

全体の作業量に対して，どれだけ進んだかを数値として計ること。

これが進捗の計測です。例えば，「⁠夏休みの宿題のドリル100ページあるけど，まだ20ページしか解いてないよ」という状態では，100ページ分の20ページ完了という進捗になります。たったこれだけです。

ですが，実際には以下のような事が問題となり，なかなか上手くいきません。

1. 全体の作業量の把握が難しい
2. 計画工数と実作業工数の乖離
3. 進捗が上がったとみなす基準

これから，上記の問題を解決するコツを解説していきます。

全体の作業量の把握が難しい

例えば，製品の利用マニュアルを作る作業を請け負ったとした場合，全体の作業量はいくらになるでしょうか。

業量として設定できる要件は，⁠”数値として計算できること⁠”です。そして全体の作業量を求めるには，あらかじめ計画段階で，適切に作業を分割し，分割した作業ごとに工数を割り出す必要があります。

作業を分割する

作業を分割するにはいくつかの方法があります。作業のサイズ，難易度，作業の進め方のカルチャーによっていくつかを組み合わせてつかうことになります。

工程で分ける

ウォーターフォール型開発でおなじみのやり方です。いくつかの工程に分けて，その工程にそって線形に進めていきます。
前の方にある工程を失敗すると後の工程のインパクトが大きいことで悪名高いやり方ですが，各工程の工数が少ない場合はとても使いやすいやり方です。
バッチ処理が好きな人はこのやり方が得意なのではないでしょうか。

階層で分ける

MVCモデルのように，成果物がいくつかの層で成り立っていると捉えます。
前述のマニュアルの作成では，マニュアルの見た目と，内容と，見た目と内容の紐付けの３つに分けて捉えることができます。
画面系のアプリケーションが好きな人はこのやり方はすぐに飲み込めると思います。

部分で分ける

アプリケーションならばクラス単位，マニュアルならば章や節単位に完成させていくという方法です。
完成した単位はそれだけでリリースに耐えうる品質になるので，確実に作業を進めることができます。
完成した単位はそれだけでリリースに耐えうる品質になるので，確実に作業を進めることができます。その代わり，全体的な整合性に気を付けないと，単位ごとにちぐはぐになってしまうので注意が必要です。
eXtreme Programmingが好きな人はこのやり方に慣れていると思います。

分割した作業ごと工数を割り出す

上記で分けた部分ごとに，時間で工数を求めます。

何故時間かというと，最終的に聞かれるのは「いつ完了する？」という問いだからです。また，労務管理上も原価計算上も時間が重要な要素となり，働き過ぎで倒れたりしたときも勤務時間が大変重要ですので，工数の見積もり以外でも，時間を基準にする習慣を持つことをお勧めします。

さて，作業の分割はどこまでやればいいのでしょうか。

大まか過ぎては大雑把すぎ，細か過ぎては計測自体のオーバーヘッドが無視できなくなりますので，時間単位になるまで分割することをお勧めします。

自分の作業として日はあまりに大きすぎ，かといって分刻みで計画するのはあまりに大変になるため，時間単位を利用するのが落としどころでしょう。