リソースヒストグラムとは
徐々に仕事を任されるようになり、上司に「そろそろリソース（人）の管理もしていこうか。」といわれた時、人を管理するほど偉くなったと錯覚しドキドキしたことは今でも覚えています。その時はリソース管理とは、人に必要な工数を割り当てるだけのものと思っていました。
どの会社でも要員計画をたて、部／チームにどういった人材が必要かを検討していると思います。同じように、プロジェクト管理においてもプロジェクトの適切な時期に適切な人材を配置すべく計画をたてる必要があります。会社が利益を生み出さなければ存続できないのと同様、プロジェクトも利益をもたらす必要がありますので、空き工数が発生しないような無駄のない計画が求められます。
人というリソースをどのようにプロジェクトに投入するかという計画を立てるのに用いられるのが「リソースヒストグラム」です。
Ｘ軸に時間、Ｙ軸に必要なリソースの量を示すことにより、プロジェクトの時間推移に伴ってどのくらいのリソース（要員、資源等）が必要なのかを直感的に把握できます。リソースを山積みする意味で山積み表ともいわれます。
図１：リソースヒストグラム（山積み表）
実際のプロジェクト現場では、この図のような大雑把なリソースヒストグラム（山積み表）は使っていません。同じリソースという言葉ですが、モノ（資源）と違ってヒト（要員）は生産性、能力、コスト、負荷状況が一人ひとり違いますので、もっと具体的に工程と個人の対比に着目してリソースを考えることのほうが多くなります。
例えば図２のような考え方をします。はじめに「①工程別に必要なリソース」といった具合に各工程に対する作業量を見積もります。各工程のスケジュールをひき、作業を実施する時期、必要な作業量を洗い出します。ここでは作業量の単位として工数を用い、1人1ヵ月労働力を1.0人月として考えます。
次にこの月別リソースをもとに「②実際の担当者別リソースへの落とし込み」を行います。各工程に実際の要員に当てはめて、どの時期にリソースの投入が見込めるかの計画を立てます。図２の例ですと4月に要件定義、設計を行える要員1.7人月分を確保する必要があります。もちろん、誰でも頭数さえ合っていればいいというわけではなく、その工程にふさわしい能力を持つ人で作業を行うことになりますので、リーダーのＡさん、ＳＥのＢさんのリソースを合計1.7人月分計画するといった具合で進めます。
図２：リソースの計画と割り当て
プロジェクト管理においてリソースの計画をたてるとは、どの時期にどのような人員が必要かの計画をたて、その人員アサインの段取りをすることをいいます。
リソースヒストグラムをツールで作成
OBPMではこの人員計画の機能を「リソースヒストグラム」と呼び、図３のようにスケジュールに基づいたリソースの計画をたてます。見積で工程ごとの工数を計画し、ガントチャートで工程ごとのスケジュールをひくことにより、どの期間にどれだけのリソースが必要かわかります。その計画をもとに今後のリソース計画を入力していきます。各リソースは、ランク別の単価テーブル（協力会社の場合は契約単価）を持っていますので、工数計画を入力するとプロジェクト全体における労務費の原価が求まる仕組みです。
図３ではアジャイル開発におけるサンプルを作成しています。図２のようなウォーターフォール型の開発に限らず、アジャイル開発においてもどういった時期にどのようなリソースでプロジェクトを遂行しどれだけのプロジェクト原価を必要しているのかを計画する流れは変わりません。
図３：OBPMのリソースヒストグラム
プロジェクトの原価計算方法
では、要員一人当たりに支払われる単価と工数をかけ合わせれば、プロジェクト予算が計算できるでしょうか。プロジェクトのリソースから算出する標準原価計算の考え方を紹介します。
１．プロジェクト運営にかかるコストとは
会社ではプロジェクトに直接かかわっていないような間接的なコストが発生します。例えば、フロアの賃貸料や電気代、開発プロジェクトの人員を支えるための管理部・管理職、事務職の労務費、案件を取得するための営業費等です。そういった費用はプロジェクトの売上を支えるためにかかっている費用ですから、各プロジェクトはその費用を加味して利益を上げる必要があります。どのくらい加味すればいいか一目でわかるようにするため、費用はある基準でプロジェクトに按分し配賦する必要があります。
サンプルとして社員５名からなるシステム会社Ｓのプロジェクトコストについて考えてみます。このシステム会社Ｓでは図４のように今月プロジェクトＸ、Ｙが稼働しているとします。
・ＡさんはプロジェクトＸを担当します。
・Ｂさん、ＣさんはプロジェクトＹを担当します。
・ＣさんはプロジェクトＹの傍ら、開発共有サーバーのメンテナンスも行います。
・開発は行いませんが、Ｄさんは会社、プロジェクト全体の事務処理を行います。
・賃貸料、電気代等の諸経費が発生します。
・次期開発案件を獲得する営業Ｅさんの労務費も発生します。
図４：プロジェクトのコストを会社全体で考えてみる
・Ａさん、Ｂさん、Ｃさんの労務費はプロジェクトＸ、Ｙの原価になります。
・Ｃさんの労務費の一部はプロジェクトＸ、Ｙのために行った共通費と考えます。
・賃貸料、電気代等の諸経費も共通費として考え、プロジェクトＸ、Ｙにかかった工数分で按分します。
・事務Ｄさん、営業Ｅさんの労務費は販売管理費として一旦纏め、プロジェクトＸ、Ｙにかかった工数分で按分します。
会計上は、共通費はプロジェクトの原価に含めますが、販売管理費はプロジェクトの原価には含めません。つまりプロジェクトＸの原価は82万円、プロジェクトＹは98万円となり、これが粗利を計算する場合の原価です。
一方、きちんと利益管理するためには販管費をいくら負担するかをプロジェクトごとに把握する必要があります。その場合、プロジェクトＸは122万円（直接費50万円＋共通費割掛け32万円＋販管費割掛け40万円）、プロジェクトＹは188万円（直接費50万円＋共通費割掛け48万円＋販管費割掛け60万円）が採算ぎりぎりのラインとなります。このラインが営業利益を計算する場合の原価となるのです。
プロジェクトの実行予算の立て方
上記は原価実績の計算方法です。共通費や販管費は月次を締めてみないと金額が確定しませんので、しかし、プロジェクトの実行予算を立てるためには、毎月どのくらい共通費や販管費の割かけを負担するかを見積もらなければなりません。
そこでリソースヒストグラムを活用します。見積を行うために取られているのが、１人当たりの原価（直接費）に共通費（予定）と販管費（予定）も加味して標準原価を設定する方法です。
共通費と販管費の設定額は、過去の実績をベースに求めます。例えば、１か月の部門共通費が300万円で、開発要員（事務や部長など以外）が10人でしたら、１人当たりの共通費負担は30万円です。同様に、１か月の販管費が1000万円で、開発要員（社長や営業、管理部門など以外）が40人でしたら、１人当たりの販管費負担は25万円です。
社員ランクＡの人の直接費が50万円とすると、リソースヒストグラムでこの人を１人月アサインすると、（直接費50万円＋共通費負担30万円＋販管費負担25万円）が標準原価となります。共通費、販管費は毎月ぶれますので、このような計算を過去半年もしくは1年の平均で求めて標準原価を定めるような運用になります。
共通費や販管費の洗い替え（標準原価と実際原価）
共通費と販管費は、月次処理により実績値が求まります。例えば、図４ではプロジェクトに直接かけた工数が合計で2.5人月です。共通費80万円、販売管理費100万円だった場合、工数2.5人月分で共通費、販売管理費を工数按分すると次のような実績が割掛け負担となります。
・共通費＝80万円／2.5人月=32万円/1人月
・販売管理費＝100万円／2.5人月=40万円/1人月
図５：標準原価からプロジェクト原価を求める
こうして求めた実績値（実際原価）を予定原価に対して洗い替える場合があります。洗い替えの対象は、直接費と共通費、販管費です。毎月、実際原価で洗い替えを行うかどうかは会社の方針です。例えばSI社の場合は、共通費は原価なので洗い替えますが、販管費は“もはや部門やプロジェクトの責任ではないので”洗い替えを行っていません。また、直接費も社員ランクごとに設定していて、実際の給与との差が大きくないので標準原価のままにしています。もちろん予定と実際の原価差異は会計処理しています。あくまでも、プロジェクト単位の採算管理にフィードバックするかどうかという方針になります。
また、洗い替えの実施可否だけでなく、標準原価の粒度や共通費、販売管理費の按分方法も会社のルールによって決められています。
現在の会社ではありませんが、新人時代にコピー機の印刷物に新人の名前がずらりと並びその横に単価が書かれたものが印刷されているのを発見しました。なんと自分がもらっている給料の3倍以上の単価が書かれていたのに驚いた次第です。その単価に共通費、販売管理費が入っていたかは覚えていませんが、労務費の中には、退職給付費用や福利厚生費等いわゆる給料とは別のお金が含まれています。まじめな私は標準原価を見るたびにコスト意識が高まり「単価に見合った仕事をしなければならない」という社会人初心を思い出します。
OBPMの仕事を行っている中で、リソースは工数だけしか管理していませんといった牧歌的な会社に遭遇することも少なくありません。でも、OBPMを導入して実行予算管理を徹底した結果、社内のコスト意識が高まったというような声を聞いてうれしく感じることも多いです。プロジェクトはきちんと利益をあげてこそ成功といえますので、どんぶりでなくリソースをもとにした精度の高いコスト管理は欠かせないと思います。
最終的には部や会社の利益を考える
えらそうなことを書ける立場にはおりませんが、個々のプロジェクトのリソースが問題なかったとしても、会社全体の利益につながるとは限りません。すごく忙しい人がいたかと思うと、放置されている暇な人がいたり、難しいプロジェクトばかりだからと新人がプロジェクトにはいれなかったりといった状況はシステム業界でよく聞く話です。
様々な理由があると思いますが、そのひとつに全社員のリソースを一度に把握できないということがあります。プロジェクト内だけでなく、部門内で見たとき、全社で見たとき、今あるリソースがどのように配置されているかが把握できます。PMOや部門長は、このような状況を常に監視することが大切になります。
監視を容易に行うためには、各プロジェクトで登録したリソースヒストグラムをもとに会社全体のリソース状況を表示する仕組みが必要です。プロジェクト単位ではなく、リソース（人）別に負荷状況を一元管理すれば、リソースを有効に配置することも可能になります。
SI社では、OBPMにより図６の画面のようにリソース（人）別に負荷実績と今後の予測がパッと見えます。メンバーは自分たちの負荷状況を管理されていると知っていますので、暇そうだと思われないためにも決まった仕事はさっさとリソース計画をたてる好循環でまわっているような気がします。
図６：開発メンバアサイン状況により部や会社全体のリソース状況を把握
OBPMとリソースヒストグラム
OBPMは、リソースヒストグラムを要員管理とコスト管理の要として重要視しています。統合型システムの利点を活かして、ガントチャート、工数入力、メンバー管理、実行予算、原価計算など各機能がリソースヒストグラムを中心に連携していますので、効率的かつ矛盾のないリソースヒストグラムを作成・管理できます。
また、各プロジェクトのリソースヒストグラム情報を部門や会社で集計して、社員のリソース状況を把握できる機能も用意しています。「これまでExcelでやっていたのでメンテが大変でだった」「誰が来月どれくらい稼働する予定なのか見る手段がなかった」というような声をいただいており、各社でかなり重宝されている機能です。
システム開発におけるリソース管理は人がメインです。それだけにリソースヒストグラムはコスト管理の要といえます。
とはいっても単純な金額計算では収まらないと感じることもあります。「技術力の高いＡさんと仕事をしたい」「新人のＢさんを一人前にしたい」といった、人との関わりによって生産性は違ってくると感じます。一緒に仕事をできるメンバーへの感謝の気持ちをもつことでリソース計画以上の成果が出ることも忘れてはいけないと思いながらリソースヒストグラム重視のコスト管理に励んでおります。
（株式会社システムインテグレータ 羽佐田奈津美）
