これはドラフトである。まだまとまっていないが、書きながら整理していきたい。
状況
- 0.5人日~3人日程度の規模の小さなタスクが多い。
- 定例作業があり、0.5H~4H程度かかる。
- 納品日や作業期日は厳しくなく、ずらす事ができる。ただし、時々、外部システム連携などで期日がずらせないタスクがある。
- 開発人員は2人~3人と少数体制。
管理の目標
- 期日のあるタスクの場合、期日にタスクが終わっていること。
- 生産性を上げること。
管理方法
タスク一覧表で管理する。
■ 説明
まず、割り込み案件が多いため、スケジュールを引いてもあまり意味がない。しかし、期日があるタスクはあるし、タスクに前後関係があるケースもある。そのため、クリティカルパスを見る必要はある。また、人の数よりタスクの数の方が多いが、タスクを処理しきれるだけの人員リソースが割り当てられる事はない。人の手が空くと人件費が無駄になるためである。そのため、タスクが待ち行列のように作業員の前に溜まっていくことになる。
人を増やす事はできないので、コントロールできるのは以下である。
- タスクの着手順
- リリース分割などの作業分割
作業が期日に間に合うかを判定するには、作業の工数を見積もる必要があるので、各タスクの最小工数と最大工数を計上する。工数が見えないタスクは要注意タスクなので、早めに着手し、見通しが立つところまで作業を進める。これはそもそも要件が出たばかりで、必要な工数の見積もりが出せない案件も同様である。案件が浮かんできた状態で放っておいてはいけない。
見積もりを出すと目標としているリリース日に間に合うかどうか大体見通しが立つが、どこまで他の案件をシャットアウトして良いかが次の問題として出てくる。割り込み案件を無視してはいけないが、既に上がっている案件が期日に間に合わなくてもいけない。基本的には期日のあるタスクを優先しながら、割り込み案件にも適宜応えていく事になる。当然の事ではあるが、全てそのタスクに時間を割けるつもりでスケジュールを組んではいけない。日の半分の時間は、定例作業や問い合わせ対応に当てられる事を見込む必要がある。具体的には、7.5Hのタスクがあったら、スケジュール時間で2~4日程度で完了するということである。2日は特別に作業がなかった場合で、4日は障害対応などが発生して普段より割り込み案件が多く、ほとんど作業に手が出せなかったケースである。もちろん、これより遅れる事も考えられる。7.5Hのタスクが1日で終わる事はない。
■ リカバリ
タスクが処理しきれず、期日を超過しそうになったらどうするか？ これといったアイデアが今のところない。今のところ、残業したり、休日に出勤したりしている。障害対応で追われるとこれになる。
■ ボトルネック
自分がある程度進めて、新しく入った開発者Aに仕事を渡すようにしていたら、自分がボトルネックになっていたことがあった。それで、要求のヒアリング、調査、障害対応など、非定型案件を自分が中心に処理し、定型的な案件をAに渡す事にした。
定型的な案件が本当に定型的であれば、システム化できるはずなので、効果の大きいところを見極めて、順次システム化したい。これも効率化になる。古典的な機械化による効率化であるといって良いだろう。
