工数管理を始めよう（３）工数計画の落とし穴　品質及び生産性の向上を図るには

工数計画とは、製品の加工などにかかる仕事量を計り、工程別に「人・作業時間・納期」などを決めて割り当てていく作業です。

製造業であれば、生産計画に必要な人員と機械の稼動時間を調整して、計画を立てていきます。

システム開発であれば、プロジェクトや案件を完了するのに必要な人員、工程ごとの作業時間を調整する必要があります。

すべての人や機械が空いているような状況であれば、単純に作業を割り当てていけばいいだけですが、現実はすでに他の作業に割り当てられていることがほとんどでしょう。その中で、誰がどのタイミングでどのくらい作業できるかを考え、製品加工やプロジェクトを完了させる計画を立てていきます。

工数計画を行うにあたり気をつけたいこと

工数計画を行うことで、工数実績と比較することで原価を細かく分析できたり、その分析結果を活用して業務効率アップにつなげられるなど、メリットは多くあるでしょう。

ですが、業務効率を意識しすぎて実作業や品質に影響がでてしまっては意味がありません。

徹底的に無駄を排除することを優先するあまり、品質を上げるうえで必要となる検証・テスト作業の回数を減らすこととなり、その結果、品質が落ちてしまうことのないように注意する必要があります。

また、品質管理を行う上で作業途中でも無理のない工数計画になるよう見直しを行うことも重要です。

例えば、当初予定していた工数計画に対し、作業メンバーの長期離脱など想定外のことが起きてしまいリソースが不足してしまったときに、その不足分を補うため、1人の1日あたりの作業量を大幅に増やし（つまり残業を増やし）、なんとか納期に間に合わせるような工数計画の再立案だと作業に対する集中力の低下により、品質の低下を招くことにもつながります。ですから、残業を定常的に増やすことで対処するのではなく、当初予定していた納期を伸ばすか、外部への発注を含めたリソースを追加する工数計画を立てるのが望ましいです。

システム開発の工程と役割

ここで、システム開発における作業工程と必要な人員及びその役割について見ていきます。

一般的にシステム開発を行う工程を大きく分けると

・要件定義

・基本設計

・詳細設計

・プログラミング

・テスト

・運用／保守

となります。

システム開発を行う構成としては、以下のような役割に分けられます。

・PM（プロジェクトマネージャー）

プロジェクトの取りまとめを行います。システム構築よりもプロジェクト全体を見たり、メンバーをマネジメントすることが中心で、エンドユーザーとのやり取りなども行います。

・PL（プロジェクトリーダー）

比較的中規模以上のプロジェクトにおいて、PM補佐のような立場でプロジェクトを管理します。SEやPGの作業進捗に問題はないか、品質は落ちていないかなど細かいところのチェックも行います。プロジェクトメンバー間のコミュニケーションがうまくいっているかなどにも目を向ける立場となります。

・SE（システムエンジニア）

開発メンバーとして、PMの指示の元、自分の課せられた作業をこなしていきます。要件や仕様を確認するなどの上流工程を担当します。

・PG（プログラマー）

主に、SEの作成した仕様書に従い、プログラミングや単体テストを実施します。SE兼PGといった場合も多くあります。

こうしたメンバーがそれぞれの役割をこなすことで、ひとつのプロジェクトが進んでいきます。

工数計画の失敗例

ここで、プロジェクトにおけるいくつかの失敗例を見てみましょう。

PMの失敗例

大型プロジェクトが始まり、PMは非常に精度の高い計画・見積りを作成した。自信をもって見積もった計画だったこともあり、その計画に固執しすぎてしまい、想定外のトラブルに対して柔軟な対応ができなかった。

→これは変更管理の重要性を欠いてしまった事例になります。計画は変わるものという意識を持ち、問題が起きた場合の解決スキルを高めることが求められます。

また、リスク戦略をあらかじめ考えておくことも重要です。できるだけ多くのリスク事象を洗い出し、リスクを緩和する計画を策定するとよいでしょう。

アサインされた次期プロジェクトの概要を見ると、過去に経験したプロジェクトと同じような内容で、しかも小規模プロジェクトだったため、当時の資料を探し、同じように計画を策定したが、計画通りに進まないことが多く発生して計画を見直すことになった。

→似たようなプロジェクトであっても、同じように進むとは限らないという事例です。たとえ小規模なプロジェクトであっても想定外のことは多く発生します。予期せぬ事態やリスクを想定し対応できるように準備をしましょう。

その他にも、たまたま廊下ですれ違った経営者にプロジェクトの予算を尋ねられ、あまり深く考えずに概算金額を言った結果、その数値が一人歩きしてしまい、予算が決まってしまった、というような単純な失敗例もありますので、このようなケースでも回答は一旦保留するなどして正しい数値を伝えるほうがよいでしょう。

PLの失敗例

新規プロジェクトが始まるにあたり、PMがPLに要件定義に必要な工数見積もりを依頼した。PLからスケジュール通りに終わるプランが提出されたので、PMは問題ないと思い、それをそのまま受け入れ予算を立てた。要件定義が始まり数週間経ち、作業進捗状況は予定通りに進んでいるように見えていたので安心していたが、いざ原価を見てみると、大幅に超過していた。原因調査のために作業工数を確認すると、かなりの残業をしていることが判明した。

→少し極端な例ですが、これは、日数的にはスケジュール通り進んでいるように見えているが、原価はオーバーしている事例です。工数を計算したPLが、一日の労働時間を考えず、今いるメンバーで納期に間に合わせるためには一日何時間作業（残業）すればいいから、何日あればできる、と日単位で計算してしまったことに由来している例になります。

それでなくとも、担当者はゆとりのない時間を見積もりがちと言われています。過小申告をしてしまいがちなのです。

PMはPLの報告を鵜呑みにせず、本当にそれでできるのかを確認したうえで計画を立てるのがよいと思います。

開発フェーズに向けて、早急にメンバーが必要になり、とりあえず時間が空いているメンバーを集め、必要とされている人数を確保した。しかし、実際は集めたメンバーのスキルが必要な水準に到達していなかったため、計画通りに進捗できなかった。

→とりあえず人数を集めて後はなんとかするというのは、現実的ではありません。アサインする時にメンバーのスキルは適正かどうかを判断しましょう。ただ一方で、スキルを妥協しなかったゆえにメンバーが集まらず、プロジェクトの開始が遅れてしまってはいけません。最初から完璧なプロジェクトチームができればそれにこしたことはありませんが、そうならない場合にはそのリソースでできる現実的な計画を立てましょう。また必要に応じてスキル不足のメンバーには学習の時間を含めることも考えましょう。

プロジェクトに必要なスキルを持ったメンバーが集まったので、メンバーの1日の労働時間を8時間と設定し、工数計画を策定した。だいたいスケジュール通りに進捗していたが、少しずつ遅れが出始め、気づいたら残業時間が大きく膨らんでいた。

→1日の労働時間を考慮して最適な計画を立てたるもりが、別の要因により遅れが生じてしまうケースです。メンバーは1日8時間フルにプロジェクトに当てることができるのかを検討する必要があります。プロジェクト以外の委員に抜擢されたり、全社会議や打ち合わせ、電話対応に時間を割かれることもあります。他にも日報や週報の作成、成果物の検討に当てる時間なども発生するので、担当メンバーの状況を確認して1日あたりのアサイン時間を決めるとよいでしょう。