皆様の会社では、以下のような課題を抱えていませんか？
・プロジェクト単位での案件情報（契約内容や請求、入金予定など）や損益・収支情報がわからない
・社内リソースのアサイン状況や稼働率をタイムリーに把握できていない
・コスト意識が低い
このような課題を抱えている会社の多くは、共通点があります。
・プロジェクトが複数、同時に進行しており、契約形態も様々である
・プロジェクトの単位に関する社内ルールが曖昧（プロジェクト・コードの採番ルールが決まっていない）
・１つの請求書の中に複数種類の請求項目があり、社内の複数部署が関与している請求がある 等
このように管理の仕方が複雑で、明確な社内のルールが決まっていない会社の多くが、プロジェクト毎の業績管理が実施できておらず、いわゆる｢どんぶり勘定｣となってしまっているのです。
そこで、今回はプロジェクト毎の個別の業績管理を成功させるための７つのステップについて解説します。業種によって多少、状況が異なる場合もありますが、ここではシステムの受託開発会社のように、プロジェクト毎に仕様が異なり、数ヶ月にまたがって進行するプロジェクトが複数ある会社を例にして説明します。
ＳＴＥＰ１．プロジェクト・タイプの整理
ＩＴベンチャー企業を例にとると、採算管理で困っている会社の多くは、複数の形態（プロジェクト・タイプ）の業務を行っています。例えば、受託開発といっても、初期開発費用と保守・運用費用という別々の形で請求が行われることもありますし、受注前の提案フェーズでエンジニアが要件定義と基本設計の一部を進めてしまうこともあります。また、Ｒ＆Ｄとしての開発などのプロジェクトが進行している会社もあります。精度の高い採算管理を行う上では、このような複数のフェーズ・種類のプロジェクトを整理して、それぞれのプロジェクトとして認識することが重要となります。
企業会計上も受注前のプリセールスに係る費用は販売管理費と認識すべきですし、受託開発業務において検収後に発生した費用はアフターフォロー（瑕疵担保義務の履行）として売上原価又は販売管理費として認識すべきですが、いずれも発生原因となる元のプロジェクトに紐付けてプロジェクトのスタートから終了までを（例えば親プロジェクト・子プロジェクトとして）一元管理することが有益です。
ＳＴＥＰ２．セグメントの決定
第４回のブログで事業別損益の把握方法について解説しましたが、プロジェクト別損益は、社内の事業区分など経営者が採算管理したい単位をセグメント化し、各セグメントについて誰が採算の責任を負うかを決定する必要があります。ここでの｢セグメント｣という表現の意味は、必ずしも社内での組織としの事業部とは一致せず、採算管理を行う上でのプロジェクトの集計単位としての意味で用いることにします。
ポイントは、当該セグメントの事業に関する予算と実績に関する権限・責任を明確にしておくことです。例えば、月次の経営会議等のミーティングにおいて、それぞれの事業やグループのリーダーが活動報告等を行う際、それぞれのセグメント毎の業績に関する報告も合わせて行うようになり、いずれは当該関与している事業に関する一定の予算権限・裁量を持たせるようになると、現場にもコスト意識が芽生え、権限委譲が進み、結果として強い組織へと成長していきます。
ＳＴＥＰ３．プロジェクト単位（採算管理の最小単位）の決定
社内にあるプロジェクトタイプの整理と、プロジェクトの集計単位としてのセグメントの方針がなされた後、それらを勘案して採算管理すべき最小単位、すなわちプロジェクト単位に関する社内ルールを決定する必要があります。
ここでのポイントは、プロジェクトタイプ（有償か無償か、検収前か後か、請負契約に基づくものか毎月請求できるものか等）が異なればプロジェクトは分けて管理すべきであること、そして、業績管理をする上で分離して採算を把握したいものがあれば、請求単位にかかわらずプロジェクトを分けて管理すべきという点です。
ＳＴＥＰ４．プロジェクト・コード採番ルールの策定
プロジェクト単位が決まったら、それぞれのプロジェクトに管理ナンバー（プロジェクト・コード、案件番号、受注コード等）を採番するルールを策定しましょう。会計ソフトや基幹システム側で自動採番の機能があれば、それを使うのも良いと思います。しかし、手動で管理する場合には、セグメント別やプロジェクトタイプ別に付す記号や番号に意味を持たせ、採番する方法をお勧めします。こうしておけば、その後、業績管理をする際にExcel(表計算ソフト)等を使って集計するのが便利になります。
このプロジェクト・コードの採番にあたっては、既に採番済みの案件に関して継続的に状況確認を続け、すでに失注した案件などを放っておかないことが最大のポイントです。
ＳＴＥＰ５．プロジェクト・ステータス区分の決定
プロジェクト・コードの採番ルールが決まれば、プロジェクト毎の採算管理をスタートすることはできますが、よりタイムリーにプロジェクト毎の案件情報を知るためには、各プロジェクトのステータスを常に最新の情報として共有する仕組みが必要となります。
すなわち、受注前の案件であれば受注確度がどの程度の案件なのかをランクA、B、Cなどを使って共有し、受注後であればプロジェクトの進捗を、検収後であれば請求・入金の状況等について、ステータスを各プロジェクトに紐付けて管理していくと、業績管理をより有意義なものとすることができます。
ＳＴＥＰ６．共有が必要なドキュメント種類の決定
プロジェクトの数が多くなった場合、案件毎の情報、例えば契約条件や仕様、アサインメントの状況やプロジェクトリーダーに関する情報等をプロジェクトに紐付けて共有しておくと便利です。
もちろん、営業担当者、エンジニア・開発者、管理部門の担当者は、それぞれ必要とする情報が異なります。しかし、プロジェクトという単位で上記のドキュメントを整理し共有する仕組みを創り、少なくともリーダーの方はいつでもこれらを確認できる状態にしておくことが、プロジェクト管理でトラブルを回避するために有効な手段となります。
ＳＴＥＰ７．プロジェクト承認ルールの決定
このようにプロジェクト単位毎にコードを採番し、プロジェクト毎のステータスや案件情報を共有する仕組みができたら、それらを承認するワークフローの仕組みを決めておきましょう。受注に関する承認は勿論ですが、それ以外にも、例えば無償で瑕疵対応する場合や受注前の提案フェーズでの作業など、何となく｢見切り発車｣して想定以上のロスが発生しないよう、社内の承認ルールを決定し、それを徹底することが重要なポイントです。これらの承認プロセスは、株式公開準備会社や上場会社では、内部統制上も重要なプロセスと評価されておりますので、留意が必要です。
このようなステップを経て、プロジェクト毎の業績管理は上手く機能するようになります。
上記の説明で分かるとおり、プロジェクト別損益管理を適切に行うためには、経理部門（管理部門）だけでなく、全社を巻き込んだ取り組みが必要となります。そして、いくら高価なシステム投資をしたとしても、決めるべき社内ルールが適切な手順（社内の合意形成のプロセス）を踏んで策定されない限り、プロジェクト別損益は正しく把握できません。