プログラマーSEが『納期前の忙しさ』を軽減する方法。平準化の威力
忙しさってプロジェクトによって様々で、すごく忙しいプロジェクトもあれば、暇なプロジェクトもあります。
私の経験上、毎日定時で帰れるプロジェクトもありました。
そうは言っても納期前はどのプロジェクトも大体忙しくなります。
これを解決できればいいんです。
納期前もそうじゃない時も大体同じぐらいで安定した仕事量になったら最高です。
私がこれまでの仕事の中でうまく機能した方法を紹介します。
仕事量を平準化できればいいのにな
『平準化』という言葉はもともと製造業で生まれた言葉で、
数値にバラつきが多いものをある一定の基準に近づける、平均値に近づける
という意味です。
なので、仕事量を平準化するということは、
まだまだ余裕な納期３ヶ月前と納期直前の一週間を同じ仕事量にする
ということです。
プロジェクトの始めの1日も納期前日の1日も同じ24時間です。
それなのに納期前日の24時間のほうがめっちゃ仕事しますよね。
これを平準化できればいいんです。
つまりは1日に行う作業料をプロジェクト初日から納期前まで同じにすることを目指します。
では、どうやるかです。
最初暇で最後くそ忙しくなる理由
私が以前参加したスマホゲーム開発の仕事は新規開発ではなく、機能追加のフェーズで2ヶ月かけて新しい機能を開発してリリースするというのを繰り返していました。
リリースサイクルには問題がないのですが、リリースする際の作業スケジュールに問題があったんです。
- 企画チームが最初の3週間で追加機能を考える
- 追加機能が決まったら開発チームが開発する
というやり方で、3週間を過ぎても企画がまとまらず最後の一週間でようやく決まって、「この機能作ってください」と言われて大急ぎで作るみたいなことになっていたんです。
逆に最初の一週間とかはまだ企画が決まってるものが少ないから開発チームはひましてる、みたいな状況で、
最初の一週間超暇 → 最後の一週間くそ忙しい
みたいな従業員にとっても会社にとってもよろしくない状況でした。
そこで私はこんな提案をしました。
仕様策定・変更の締切(デッドライン)を設けよう
「最初の3週間で企画を練るんじゃんなくて、それより前に練った企画を次のリリースで開発した方が良くないですか？
じゃないと最初の一週間二週間は企画が決まってないから開発は暇、最後の二週間になって急にこれもこれも作ってくれと言われても間に合いませんよ。
いざん私が参加した他社のゲーム開発では、事前に企画したものを次のサイクルで作るっていうスケジュールになっていて、とてもうまく機能してましたよ」
こんな内容のことをプロジェクトの全体会議で言いました。
「たしかにそうできればいいけれど、急には難しいのでひとまず企画をフィックスする締切を設けることにします」
ということになりました。
その締切も完璧には守られなかったのですが、以前よりも企画が早く決まるようになり、早く開発に着手できるようになったので、作業量が平準化したんです。
最初の二週間の暇さが減って早めに開発が始まり、その分最後の二週間の忙しさも軽減されました。
つまり、毎日同じくらいの作業量、労働時間に近づいたんです。
このようなケースはゲーム開発のような自社サービス系の仕事だけでなく、SIerの受託開発やSESみたいな仕事でもよくあります。
その場合、ちょっと違ったアプローチが必要になります。
受託開発の上流工程が遅れるケースへの対応策
お客さんとの打ち合わせがうまく進まなくてなかなか仕様がフィックスできない、そんなことはよくあります。
要件定義をやる期間が1ヶ月だったはずが2か月かかり、基本設計をやるのがその次の1ヶ月だったはずがさらに半月のびた、だけど、最終的な納期は延ばせない、すると前工程で浪費した期間を開発期間で吸収して間に合わせなければならない、そんなことになります。
この場合、それぞれのフェーズの締切(デッドライン)はちゃんと決めてられているわけで先程のゲーム開発のプロジェクトとは異なります。
「ではどうするか？」です。
時間を貯金する方法
要件定義が伸びてる間に別の進められることを進めておくんです。
例えば、開発フェーズに入った時にやらなければいけない定形作業とかを先にやっておきます。
- ソースコード置くプロジェクトのテンプレートを用意しておく
- サンプルプログラム、開発ガイドラインの作成
- 使ったことのない技術の疎通確認
- 定形ソースコードを生成するツールの作成
ちょっと考えただけでもけっこう浮かぶはずです。
後でやるはずのことを先にやっておくことで貯金を作っておくイメージです。
こうすることで、後工程の日程が圧縮されても、ある程度、作業量を平準化することができます。