工数管理を始めよう（３）工数計画の落とし穴 品質及び生産性の向上を図るには
工数計画とは、製品の加工などにかかる仕事量を計り、工程別に「人・作業時間・納期」などを決めて割り当てていく作業です。
製造業であれば、生産計画に必要な人員と機械の稼動時間を調整して、計画を立てていきます。
システム開発であれば、プロジェクトや案件を完了するのに必要な人員、工程ごとの作業時間を調整する必要があります。
すべての人や機械が空いているような状況であれば、単純に作業を割り当てていけばいいだけですが、現実はすでに他の作業に割り当てられていることがほとんどでしょう。その中で、誰がどのタイミングでどのくらい作業できるかを考え、製品加工やプロジェクトを完了させる計画を立てていきます。
目次
工数計画を行うにあたり気をつけたいこと
工数計画を行うことで、工数実績と比較することで原価を細かく分析できたり、その分析結果を活用して業務効率アップにつなげられるなど、メリットは多くあるでしょう。
ですが、業務効率を意識しすぎて実作業や品質に影響がでてしまっては意味がありません。
徹底的に無駄を排除することを優先するあまり、品質を上げるうえで必要となる検証・テスト作業の回数を減らすこととなり、その結果、品質が落ちてしまうことのないように注意する必要があります。
また、品質管理を行う上で作業途中でも無理のない工数計画になるよう見直しを行うことも重要です。
例えば、当初予定していた工数計画に対し、作業メンバーの長期離脱など想定外のことが起きてしまいリソースが不足してしまったときに、その不足分を補うため、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日あたりのアサイン時間を決めるとよいでしょう。
SE・PGの失敗例
- 開発フェーズも終わりに差し掛かり、テストフェーズを向かえ、テストを担当するPGやSEが不具合を見つける。想定していたよりも多くの不具合が見つかり、すべての不具合が解消するまでテストを繰り返していくうちに費用が膨大になっていた。
→これはSE・PGの失敗というよりは、品質目標が明確ではないことに由来する失敗と言えるでしょう。
上図に示したとおり、最初のうちは費用をかければかけるほど品質は向上しますが、ある一定の基準に達すると、そこからの品質向上は難しくなってきます。
もちろん、高い品質目標を設定することは非常に大事なことで、意識はするべきなのですが、不具合ゼロというのは必ずしも現実的ではないので、成果物が最低限満たすべき品質を見極め、その目標を達成するようにテストを行うのがよいでしょう。
プロジェクト全体に言えることですが、何をもってプロジェクトが成功したと言えるかの判断基準を明確にしておくことはとても重要です。
その他にも
・自分だけでは判断できないことや上司の判断が必要なことがあり、確認したいが、上司が不在のことが多くてなかなか次に進めない、
・長期プロジェクトの場合、ゴールが見えずに途中でモチベーションが低下してしまい作業スピードが遅くなる
といったことも考えられるでしょう。
プロジェクトを失敗しないためのポイント
・計画書を作ったあとも更新、変更を躊躇しない。
・現実的なスケジュールにする。PMとはいえ、勝手にスケジュールを変更すると信用を落としかねない。
・計画書や仕様書にあること以上のことを無理にしようとしない。
・想定外の出来事でリソース不足が発生したとき、正式な支援を取り付ける。
・現状起こっていることをプロジェクトメンバーに周知する。
・報告書を複雑にしすぎて時間を割かれてしまわないようにする。
・プロジェクトメンバーのコミュニケーションツールを適切なものに統一する。
・メンバー間で対立が起こった場合、しっかりとその原因を究明する。
プロジェクトが失敗する場合、普通であればその原因は特定できるとされています。過去の失敗の経験を活かして、プロジェクトをすすめていきましょう。
工数計画の視点
工数計画は、立場によって視点が変わってきます。
それぞれを見てみましょう。
- 経営層の視点
計画ベースでの原価はどれくらいかかるのか
実績ベースでの原価はどれくらいかかったのか
実績と計画の差異はなにか
リソース状況の可視化
- PM及びPLの視点
プロジェクトのスケジュール管理
プロジェクトのコスト管理
成果物の品質は落ちていないか
メンバーごとの作業量にばらつきはないか
メンバーの評価
メンバーの労働時間の分析
メンバーの労働生産性の向上
作業の改善点はないか
- SE及びPGの視点
自身の作業時間管理
プロジェクト計画通りに遂行できているか
報告のための工数の入力
進行状況やゴールの見える化によるモチベーションのアップ
工数計画を活用する際の注意点
上記に述べたように、立場が変われば求めることも変わります。
経営者や管理者はより詳細な情報を求めるべく厳密な管理を求めますが、現場メンバーは作業の負担が増大してしまわないようなより入力しやすいものを求めます。
その双方のニーズをバランスよく満たせる仕組みを構築しないと、せっかく工数を入力したのに使えるデータが出せなかったり、逆に分析に必要なデータの入力が滞ったりしてしまう可能性があります。
工数計画の落とし穴 品質及び生産性の向上を図るには のまとめ
工数計画を行うことは重要ですが、生産性を追い求めすぎて品質が落ちてしまったのでは意味がありません。また、想定外のことが起きた際に、今いるメンバーが長時間労働をしてなんとか納期に間に合わせるような計画を立てていては、働き方改革が注目を浴びている昨今において、やがては問題になっていくことでしょう。
プロジェクトを進めるうえで、それぞれに与えられた役割があります。
工数計画を立てる人は、現状を的確に見極め、実現可能なスケジュールを立て、またメンバーはコミュニケーションを取りながら、それぞれの立場で求められている作業を遂行していけるようにするとよいでしょう。
筆者プロフィール
- ビーブレイクシステムズ
- 家電量販店でウィンドウショッピングするのが好きです。
