ホーム > ブログ > 工藤 武久の記事一覧 > 【第48回】プロジェクト工数管理の達人?コスト・マネージャー


【第48回】プロジェクト工数管理の達人?コスト・マネージャー

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回はシステム開発プロジェクトの「一括請負」と「準委任」契約について比べてみました。なんだかんだ言っても、システムの設計、開発、テストは、システム開発の専門家である開発ベンダーにおまかせする、一括請負契約が主流だと思います。

契約形態が請負だろうが、準委任だろうが、実際にシステム開発を行うのは人であり、発注側も受注側もシステム開発コストの大部分を占めるのが人件費であることに変わりはありません。

 

【 システム開発のコスト管理の中心は工数実績管理 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
当ブログの 【第46回】システム開発が楽しくなる生産性向上のポイント では、システム開発の生産性が低いと製造原価が増えて利益が少なくなるということを簡単な図で示しました。この製造原価がどんな構造となっているか、もう少し細かく表現してみました。

販管費や間接費については、各組織の事情に応じてなんらかの配賦ルールに基づいて、各プロジェクトにわりふられるので、各プロジェクトでコントロールしづらい部分です。とはいっても、プロジェクトの損益見通しを立てるためには、どのくらい配賦されるのかを押さえておく必要はあります。

ハードウエアやソフトウエアなどの材料費は、システム構成が決まれば費用は明確に算出できる部分です。開発にかかる交通費などの経費は、お客様との打ち合わせなどが増えて、遠隔地への出張が多くなった場合などは予算をオーバーする可能性もありますが、気を付けていればそんなに問題になるようなことはあまり無い部分でしょう。

この原価構造の中では、やはり労務費と外注費の部分がシステム開発プロジェクトのコスト管理としては最も大事な部分となってきます。たいていの企業では、給与の支給は毎月なので、毎月の作業時間がどれだけかかったかが、プロジェクトに投入したコスト計算の土台になります。外注費の方は協力会社との契約が請負か準委任かによっても変わりますが、請負の場合でも事実上の人月清算となることもあるので、その場合は開発工数管理が必要になってきます。

労務費の計算は、要員のランクによって基準となる単価が異なったり、複数のプロジェクトを兼務していたり、システム開発外の社内業務や研修などを受講した時間を除外したり、プロジェクトに費やした工数(作業時間)の集計がとても煩雑となり、結構たいへんな作業になることが多いですよね。毎月締めの時期は、どの組織でも結構ばたばたとするものです。

どのプロジェクトでも毎月同じように苦労するので、数字が得意な人を工数実績管理の専任者として割り当てることもあるようです。このような工数実績管理を含めたプロジェクトのコスト管理を専門に行う要員のことを、「コスト・マネージャー」とか「リソース・マネージャー」と呼んだりすることもあります。最近では、プロジェクト・コスト管理の役割はPMO(プロジェクト・マネジメント・オフィス)が担うことが多くなってきたのではないでしょうか?(※1)

 

【 工数実績管理は何がたいへんなのか? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
システム開発を行っている組織では、プロジェクトにかかる工数の予実管理は専用のシステムを導入して管理していることが多いと思います。システム開発プロジェクトのコスト管理の中心は工数実績管理なので、利益を確保して経営を安定させるためには、しっかりと管理する必要があるため、そのインフラとして工数管理システムを導入するのは当然のことです。しかし、専用のシステムを導入しているのにもかかわらず、工数管理がたいへんなのはなぜでしょうか?

また、当ブログの 【第45回】ありのままのプロジェクト実績データ収集 で触れたように、プロジェクトの成功率向上につなげるためにも、正確なプロジェクト実績データを収集することの意義は大きいはずです。システム開発の生産性を評価するために、プロジェクトごと、工程ごと、作業内容ごとに、どれだけの工数を使ったかをできるだけ正確に把握したいと考えるはずです。この目的のためにも、工数管理システムは十分利用可能なはずですが、なかなかそこまでしっかり活用できていないことが多いように感じています。

だいだいどのプロジェクトもなかなか計画通りに整然とは進められず、プロジェクトメンバーたちは工程遅延のキャッチアップや手戻り対応のために、いくつもの工程の作業を並行で進めざるをえないので、どの作業にどれぐらい時間がかかったかをきっちりとシステムに入力するのが難しいのかもしれません。それに、そもそも自転車操業の厳しい状況のなか、工数実績を日々システム入力することができず、ひどいときには一ヶ月分ためて締日の直前に一ヶ月分の実績入力をするなんてことも起きているかもしれません。

そうなってしまうと、一ヶ月分の工数実績をアバウトに配分してシステム入力することになるので、正確な実績工数など把握できなくなってしまいます。「コスト・マネージャー」の立場としても、その月の途中段階での原価状況が把握できず、締日になってふたを開けてみてはじめて予定と実績に大きな違いがあることに気付き、あわてて現場に状況を確認して、必要に応じて工数入力の是正などを指示することになります。

かくして、月締めの工数実績計算とプロジェクト原価計算は、「コスト・マネージャー」の頭を悩まし続けてしまうことになります。逆にいうと、そういう面倒くさい業務に耐えられるような忍耐強い人が「コスト・マネージャー」に指名されるということかもしれません。

これを是正するために、タイムカードの導入や、各自のパソコンへのログイン時間、最終ログオフ時間などからある程度工数実績を自動的に把握する方法などを取り入れる取り組みも聞いたことはあります。しかし、やはりすべてのプロジェクトメンバーが、自発的に、できるだけタイムリーに正しく工数実績を入力するよう、システム開発の原価管理の仕組みを理解し、プロジェクト実績収集の重要性をしっかり認識するよう、粘り強く啓蒙活動をする必要があると思います。

その啓蒙活動の一環として、プロジェクト原価状況の変遷をわかりやすく「見える化」した資料やプロジェクト実績データ収集の結果得られた成果などを、定期的にプロジェクトメンバーにフィードバックする取り組みも必要です。

「プロジェクト工数実績管理をコスト・マネージャーだけに押し付けることはやめましょう!」

 

【 ありがちな工数実績管理の良くない運用 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
ここまで見てきたように、プロジェクト・コスト管理はなかなかたいへんで、特に月締め、期末締めのタイミングでは、なんとか予算と実算のつじつまが合うように数字を調整したくなってしまう「コスト・マネージャー」も出現します。と言っても、その調整は、「コスト・マネージャー」の上司であるプロジェクト・マネージャーの指示によることになりますが。。。

<ありがちな工数実績管理の良くない運用の例>(※2)

1.工程間の実績工数付け替え

たとえば、前回登場した「事実上の一括請負契約」において、外部設計と内部設計の契約が分かれていたケースです。外部設計が遅延して予定工数を全て使い果たしてしまった場合に、以降発生した外部設計工数を次契約である内部設計に対する原価として計上してしまうことです。

確かに「事実上の一括請負」なので、工程間の契約の切れ目は形式的だと割り切ってしまう考え方もあるかもしれませんが、これではせっかく契約を多段階にしている意味がありません。内部設計の工数を使い始める前に外部設計が遅延した原因を分析して、仮に要件が拡大していた場合には立ち止まって、再見積りをして全体計画を仕切りなおす必要があります。

2.プロジェクト間の実績工数付け替え

ある特定のプロジェクトがコスト超過に陥ったときに、そのプロジェクトにかかった工数の一部を他のプロジェクトの工数として実績計上してしまうことです。

これをやってしまうと、それぞれのプロジェクト・コストが正しく把握できず、生産性実績の評価もできなくなってしまうので、要注意です。

3.サービス残業の強要

デスマーチ化したプロジェクトにおいて、泥沼化した責任をプロジェクトメンバーに押し付け、サービス残業を強要し、実際はかかっている工数をもみ消してしまうことです。

デスマーチ化の責任は、プロジェクト・マネージャーや経営層にあるということを、しっかりと受け止める必要があります。

ここにあげた例は、一昔前には起きる可能性もあったかもしれませんが、コンプライアンスが強調される時代なので、今では間違っても起きないような仕組みを取り入れている組織がほとんどだと思います。ありのままのプロジェクト実績収集にもとづく継続的改善のためにも、健全で、属人化していない、効率的な工数実績管理の仕組みが必要ですよね!

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 PMO(プロジェクト・マネジメント・オフィス)については、関和美氏のブログ 「かずみ先生のPM、PMOあんなこと こんなこと」 をご覧ください!

※2 ここであげた例は、あくまでも「ありうる話」であり、フィクションです。

Pocket

| 目次

Profileプロフィール

工藤 武久
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事

PMI®公認教育プロバイダー(R.E.P:Registered Education Provider) 株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。
PMI Registered Education ProviderロゴおよびPMBOK®Guideは、PMI®(Project Management Institute, Inc.)の登録商標です。
IIBA®認定教育プロバイダー(E.E.P:Endorsed Education Provider) 株式会社アイ・ティ・イノベーションは、IIBA®(International Institute of Business Analysis)の認定教育プロバイダー(E.E.P:Endorsed Education Provider)です。
IIBA®BABOK®およびBusiness Analysis Body of Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。