スケジュールは経営資源の配分である―大前研一氏が説いた“経営の中枢になるグループウェア”を、プロジェクト管理会計で実現する

結論：グループウェアが「経営の中枢」になる条件は、業務と会計をプロジェクトでつなぐことです

最初に結論を申し上げます。プロジェクト型ビジネスにとって、社内の情報共有システムが本当の意味で経営に役立つかどうかは、スケジュールや掲示板の使い勝手では決まりません。「社員の時間の使い方」と「お金の動き」が、プロジェクトという同じ単位で自動的につながっているかどうか。この一点で決まります。

多くの会社では、スケジュールはグループウェアに、工数は日報やExcelに、売上や外注費は会計ソフトに、商談は営業支援システムに、評価は人事の台帳に、とばらばらに記録されています。どれも一つ一つは真面目に入力されているのに、経営者が知りたい「この案件は儲かったのか」「この顧客との取引は割に合っているのか」「この人の働きは会社の利益にどれだけ貢献しているのか」という問いには、どのシステムも答えてくれません。

問題は、入力する社員の努力不足ではありません。記録の単位がそろっていないことにあります。スケジュールは「人」と「日時」で、会計は「勘定科目」と「取引先」で、営業支援は「商談」で、人事は「社員」で記録されている。それぞれの軸は正しくても、共通の軸がないために、つなぎ合わせる作業が毎月の手作業として管理部門にのしかかります。そしてその手作業が、数字の遅れと誤りの温床になっているのです。プロジェクト型ビジネスにおいて、その共通の軸になり得るのは、プロジェクト以外にありません。

本稿では、経営コンサルタントの大前研一氏がかつてグループウェアの将来像について語った提言を手がかりに、この「つながっていない問題」をどう解くかを考えます。そして、その提言を私たちが「eMplex PBM」というかたちでどう実現しようとしているのかを、プロジェクト管理会計の実務家の立場からお伝えします。

大前研一氏の提言を振り返る―「消極的なグループウェア」からの脱却

大前氏は、日経BP社のウェブサイトに掲載されたビジネスコラムの中で、国内グループウェアの代表的な企業であるサイボウズへの提言というかたちで、グループウェアのあるべき姿を論じていました。この文章は、私がかつて自分のブログでも紹介したものですが、読み返すたびに、プロジェクト管理会計の本質を言い当てていると感じます。

私なりに要旨をまとめると、次のようになります。まず、プロジェクト管理の機能を経理とつなげるべきだという指摘です。中小企業であっても、取引先や案件ごとにお金のかかり方は異なる。だから案件ごとにコードを分け、進行管理と経理を自動的に連動させる。そうすれば、顧客開拓にコストがかかっている取引先、技術やシステムにコストがかかっている取引先といった違いが見え、プロジェクト別の収益性をどんぶり勘定ではなく正確につかめるようになり、入札や見積の価格設定にも生かせる、という主張です。

さらに大前氏は、スケジュールや施設を管理するだけの「消極的な」グループウェアではなく、経営の中枢に位置づけられるものになるべきだと述べていました。大企業でも扱いに苦労する大がかりなERPに手を出さなくても、会計ソフトと連動させることで中小企業の経営の近代化に貢献できる。とりわけ受注型の企業やプロフェッショナル・ファームのような、活動そのものがグループ単位で成り立っている会社にとっては必須の観点だ、という指摘です。

提言は経理にとどまりません。グループ別の採算、固定費の回収、正しいレートの設定といった経理面に加え、アサインメント、チーム編成、評価、外部との協業といった人事面、さらには日本の企業で最大のグループである営業部門を支える仕組みにまで、連動の範囲を広げるべきだと論じていました。私はこの文章を、プロジェクト型企業のための経営管理システムの設計図として読んでいます。

この提言が書かれたのは2000年代後半のことで、文中にはM&Aの候補として当時の具体的な企業名も挙がっていました。個々の企業の動向についての見立ては時代とともに変わりますが、業務の中核に踏み込まないかぎりグループウェアの成長には限界がある、という骨格の主張は、今読んでもまったく古びていません。むしろ、クラウドの普及でシステム同士をつなぐ技術的なハードルが下がった今だからこそ、改めて向き合う価値があると私は考えています。

「スケジュールこそが資源配分である」という言葉の重み

大前氏の提言の中で、私が最も共感したのは、スケジュールこそがトップから末端まで全社員の資源配分であり、経費であり、企業活動そのものだ、という趣旨の一節です。この言葉は、プロジェクト型ビジネスの原価構造を一言で言い表しています。

建設、IT、コンサルティング、映像制作。業種は違っても、プロジェクト型ビジネスの原価の中心は人の時間です。ある社員が今週どの案件に何時間使ったか。それは、その案件に会社がいくらの労務費を投じたかと同じ意味を持ちます。スケジュール表に書かれた「A社打合せ」「B案件設計レビュー」という予定は、見方を変えれば、会社の経営資源をどこに配分するかという意思決定の記録なのです。

ところが、多くの会社でスケジュールは「予定の共有」にしか使われていません。予定どおりに時間を使ったのか、実際には何時間かかったのか、その時間はどの案件の原価になるのか。こうした情報は、スケジュールの外側で、別の手段で、しかも多くの場合は月末にまとめて記憶を頼りに記録されています。予定と実績と原価が切り離されているかぎり、資源配分の良し悪しを振り返ることはできません。

私はエンプレックス（現SCSK）でCFOを務めていた時代、システム開発のプロジェクト別損益を毎月締める責任を負っていました。そこで痛感したのは、会計上の数字がどれだけ正確でも、その源泉である工数が曖昧であれば、プロジェクト別の損益は「それらしく見える数字」にすぎないということです。スケジュールを資源配分として捉え、予定と実績の工数をプロジェクトコードで記録すること。ここがすべての出発点になります。

朋友建設にいた頃、現場の作業日報は紙で書かれ、事務所に集まってから集計されていました。日報には誰がどの現場で何をしたかが確かに書かれていたのですが、それが工事ごとの原価として経営に届くのは、ずっと後になってからでした。記録があることと、その記録が経営の判断に間に合うことは別の問題です。時間の記録は、発生した時点でプロジェクトにひもづき、原価として集計されてこそ意味を持ちます。

工数を記録するというと、「管理が厳しくなる」「監視されているようだ」と現場から反発が出ることがあります。しかし私は、工数の記録は社員を監視するためのものではなく、社員の時間という貴重な資源が、会社の中でどう使われ、どれだけの価値を生んだのかを明らかにするためのものだと説明しています。自分の時間の使い方が案件の採算にどう影響したかが見えるようになると、現場の社員自身が見積の精度や段取りの工夫に関心を持つようになります。資源配分としてのスケジュールは、経営者のためだけでなく、現場の社員のための情報でもあるのです。

業務と経理を連動させると、顧客ごと・案件ごとの「本当の違い」が見えてきます

業務と経理がプロジェクトコードでつながると、何が見えるようになるのか。大前氏が指摘したとおり、最も大きな変化は、顧客ごと、案件ごとの違いが数字で見えることです。

たとえば、売上規模が同じ二つの取引先があったとします。会計ソフトの上では、どちらも同じくらい大切なお客様に見えます。しかし工数と原価をプロジェクト単位で集計してみると、一方は仕様変更が多く、打合せや手戻りに想定の倍近い時間がかかっていた、ということがよくあります。もう一方は、受注までの提案活動に多くの時間を割いていたものの、受注後は順調に進み、粗利率も高かった。こうした違いは、売上の数字だけを見ていても決してわかりません。

私が支援してきた200社を超える企業でも、プロジェクト別の採算を初めて正確に出したとき、経営者が驚かれる場面を何度も見てきました。「一番の得意先だと思っていた会社との取引が、実は赤字続きだった」「小さな案件だと軽く見ていた顧客が、実は最も利益率が高かった」。こうした発見は、営業方針や価格交渉の姿勢を根本から変えます。

もう一つ重要なのが、受注前の活動にかかった時間の把握です。提案書の作成、見積の検討、プレゼンテーションといった営業活動の工数も、案件や見込み顧客に紐づけて記録しておけば、「この種類の案件を一件受注するのに、どれだけの提案コストがかかっているのか」がわかります。これは入札価格や見積価格を決めるうえで非常に強力な根拠になります。受注後の原価だけでなく、受注までのコストを含めて案件の採算を判断する。それが、どんぶり勘定から抜け出すための第一歩です。

ここで大切なのは、こうした分析を特別なプロジェクトとして年に一度行うのではなく、毎月の経営会議で当たり前に見られる状態にしておくことです。一度きりの分析は驚きを生みますが、行動を変えるのは継続的なモニタリングです。取引先別、案件種別別の粗利率が毎月同じ形式で並んでいれば、営業担当者は自然と「利益の出る仕事」を意識するようになり、見積の段階から採算を考える文化が育っていきます。

見積の精度についても同じことが言えます。過去の類似案件で、どの工程に何時間かかったのか、当初の見積と実績はどれだけずれたのか。こうした実績が案件の種類ごとに蓄積されていれば、次の見積は担当者の勘ではなく、根拠のある数字に基づいて作れるようになります。業務と経理をつなぐことは、過去を正確に知るためだけでなく、未来の価格を正しく決めるためでもあるのです。

経理のその先へ―グループ別採算、固定費の回収、正しいレートの設定

大前氏は、次世代のシステムに求める経理面の機能として、グループ別の採算、固定費の回収、正しいレートの設定を挙げていました。この三つは、まさにプロジェクト管理会計の中核テーマです。

グループ別の採算とは、部門やチームを一つの事業体とみなし、それぞれが稼いだ粗利と、使った費用を対応させて評価することです。プロジェクトの数字を部門やプロジェクトマネージャー単位で集計できれば、どのチームが会社の利益に貢献し、どのチームが支援を必要としているのかが見えてきます。

固定費の回収は、プロジェクト型ビジネスで特に見落とされがちな視点です。オフィスの賃料、管理部門の人件費、システム費用といった固定費は、個々のプロジェクトの原価には直接現れません。しかし会社全体としては、すべてのプロジェクトの粗利の合計でこれらを回収しなければなりません。案件ごとの粗利が黒字でも、全体の粗利が固定費に届かなければ会社は赤字です。月次で「粗利の積み上げが固定費のどこまで届いたか」を確認する習慣は、経営の安定に直結します。

そして、正しいレートの設定です。社員一人ひとりの時間単価、つまり原価レートは、給与だけでなく、法定福利費や賞与、さらには間接費の負担分も考慮して設定する必要があります。この原価レートが実態より低く設定されていると、見積も採算管理もすべて甘くなります。逆に、顧客に請求する単価（チャージレート）は、原価レートに固定費の回収分と適正な利益を上乗せして決めなければなりません。原価レートと工数、チャージレートと売上が一本の線でつながったとき、初めて「この案件をこの価格で受けてよいのか」という判断が数字でできるようになるのです。

私がホリプロで経営企画を担当していた頃も、作品や公演ごとの損益に、制作部門や管理部門の固定費をどう負担させるかは、常に議論の的でした。配賦の基準一つで、ある作品が黒字にも赤字にも見えてしまうからです。大切なのは、どの基準が絶対に正しいかを追い求めることではなく、合理的で説明可能な基準を決め、それを継続して使い、プロジェクトの粗利と固定費の回収状況を分けて見ることです。そうすれば、個々の案件の良し悪しと、会社全体の稼ぐ力の過不足を、混同せずに議論できるようになります。

この三つは、どれも一度設定すれば終わりというものではありません。給与改定や採用による人員構成の変化、オフィスの移転や新しいシステムの導入があれば、原価レートも固定費の水準も変わります。私は支援先に、少なくとも年に一度、期初の予算策定のタイミングで原価レートとチャージレートを見直すことをお勧めしています。業務と経理が日常的につながっていれば、この見直しも実績データに基づいて短期間で行えます。

人事と営業への連動―アサイン、評価、そして日本型の営業

提言の中で大前氏は、人事の領域として、アサインメント、ベストチームの編成、評価、外部とのコラボレーションまで連動させたいと述べていました。これもプロジェクト型ビジネスの実務にそのまま当てはまります。

誰をどのプロジェクトにアサインするかは、プロジェクトの採算を最も大きく左右する意思決定です。社員ごとの稼働状況、スキル、過去に担当した案件の実績が一つの画面で見られれば、特定の人への負荷の集中を避けながら、案件に最適なチームを組むことができます。また、担当したプロジェクトの収支や稼働率といった客観的なデータが人事評価と結びつけば、「声の大きい人が評価される」という不満を減らし、評価への納得感を高めることにもつながります。

営業についても、大前氏は興味深い指摘をしていました。日本企業で最大のグループは営業部門であり、支店や課の単位で使うグループウェアとは、つまるところ営業支援システムのことだ、という見方です。そのうえで、海外製の営業支援サービスは日本の営業に必ずしもフィットしない部分があり、顧客の個別事情や長年の関係性、過去の経緯といった情報を扱うことこそ、グループウェアの本領だと述べていました。

外部とのコラボレーションという視点も見逃せません。プロジェクト型ビジネスでは、協力会社やフリーランスとの協業が当たり前になっています。社内の社員だけでなく、外部のパートナーがどの案件にどれだけ関わり、どれだけの費用がかかっているのかを同じ仕組みで把握できれば、内製と外注のバランスを数字に基づいて判断できるようになります。

私も同感です。日本のBtoB取引、とりわけプロジェクト型ビジネスでは、受注は一度きりの商談で決まるものではありません。名刺交換から始まる人間関係、過去の案件での実績、紹介の連鎖。そうした関係性の履歴が、次の受注の確度を決めます。営業活動の記録が、その後のプロジェクトの収支と同じ顧客コードでつながっていれば、「どの顧客との関係に時間を投資すべきか」を、感覚ではなく実績で判断できるようになります。

評価の話に付け加えると、プロジェクトの数字を人事評価に使う際には注意も必要です。粗利率だけで人を評価すると、難しい案件や新規顧客の開拓を誰も引き受けなくなります。案件の難易度や、組織への貢献、後進の育成といった数字に表れにくい要素も合わせて見ることが大切です。データは評価を決めるためのものではなく、評価の対話を具体的にするための材料として使う。そうした運用の設計まで含めて、人事との連動を考える必要があります。

なぜ、この構想はなかなか実現しなかったのか

大前氏の提言が書かれてから、かなりの年月が経ちました。この間、クラウドサービスは急速に普及し、業務アプリケーションを手軽に作れる仕組みも広がりました。それでも、プロジェクト管理、経理、人事、営業が一つの仕組みの上で自然につながっている中堅・中小企業は、今も決して多くありません。私はその理由を二つに見ています。

一つは、大前氏自身が指摘していた人材の問題です。業務の中核に踏み込むシステムを作るには、業務の流れ、会計の仕組み、営業やマーケティングの実情、そしてITのすべてを理解している人材が必要になります。どれか一つの専門家は多くいても、これらを横断して設計できる人は、どの会社にもなかなかいません。大前氏は、グローバルなIT大手ですら業務を本当に理解している人がどれだけいるか疑問だ、という趣旨のことまで述べていました。

もう一つは、システムを「部門ごとの道具」として選んできた歴史です。経理は経理で使いやすい会計ソフトを、営業は営業で評判の営業支援サービスを、人事は人事で勤怠や評価のシステムを、と部門ごとに最適な道具を選ぶと、全体としてはつながらない仕組みが出来上がります。プロジェクトという横串が通っていないのです。

加えて、使う側の意識の問題もあります。システムを入れること自体が目的になり、「何を判断するためにこのデータを集めるのか」という問いが置き去りにされると、入力の負担だけが増えて、誰も数字を見なくなります。業務と会計をつなぐ仕組みは、経営者が毎月の経営会議でその数字を使い、現場に問いを投げかけ続けて初めて生きたものになります。

振り返ってみると、私自身のキャリアは、この横断的な視点を身につけるための偶然の連続だったように思います。朋友建設では、新卒で入った会社が和議に至る過程を内側から経験し、現場が忙しく働いていても案件ごとの採算が経営に見えていない怖さを知りました。エンプレックスではCFOとして会計と業務システムの両方に責任を持ち、ホリプロでは経営企画として、作品や公演という性格の異なるプロジェクトを横並びで評価する難しさに向き合いました。独立後は200社を超える企業の現場で、業務、会計、営業、人事がつながらない現実を見続けてきました。こうした経験を一つの仕組みにまとめようと考えたのが、eMplex PBMの出発点です。

eMplex PBMで実現する「プロジェクト型企業のためのグループウェア」

eMplex PBMは、大前氏が描いた「経営の中枢に位置づけられるグループウェア」を、プロジェクト型企業のために具体的なかたちにしたものです。CRM、営業支援、請求・売上、支払・原価、タイムシート、経費精算、フォーキャストレポート、財務会計連携、給与、社員情報、生産性分析、プロジェクト予算実績など、16の業務モジュールを一つのプラットフォームに統合しています。

その設計の中心にあるのが、プロジェクトという横串です。見積から取り込んだ予算、社員が日々入力するタイムシートの工数、外注先への発注と支払、立替経費、請求と入金。これらがすべて同じプロジェクトに紐づき、工数は社員ごとの原価レートを通じて案件別の労務費原価に自動的に反映されます。取引先や案件ごとにコードを分け、経理と自動的に連動させるという大前氏の構想を、日々の業務の入力がそのまま管理会計の数字になる仕組みとして実装しました。

ERPを導入しなくても会計ソフトと連動できる、という点も大切にしています。eMplex PBMは月次の会計仕訳データを生成し、既にお使いの会計システムにつなぐことができます。会計ソフトを入れ替える必要はなく、その手前にある業務と管理会計の層を整える、という考え方です。

経理の先の領域にも踏み込んでいます。フォーキャストレポートでは、プロジェクトごとの予算・実績・着地見込みを月次で更新し、粗利率が悪化した案件をアラートで早期に知らせます。事業別やプロジェクトマネージャー別に数字をまとめれば、グループ別の採算も一目でわかります。人事の面では、稼働率や案件別工数の分析、アサイン状況の一元化に加え、タレントマネジメントの仕組みと生産性データを連動させる追加ソリューションも用意しています。営業の面では、名刺情報を起点に取引先やプロジェクトの履歴、セミナーへの参加状況までを一元管理し、商談から受注、そしてその後の収支までを同じ顧客の文脈で追いかけられます。チャットツールとの連携により、承認依頼やアラートも日常のコミュニケーションの流れの中で届きます。

大前氏は、若い会社には業務系に詳しいベテランの人材が必要だとも述べていました。eMplex PBMの機能の一つ一つには、私が企業の現場で目にしてきた失敗と工夫が反映されています。予算から大きく乖離した案件を再承認に回す仕組みや、契約書の段階的な承認フロー、取引先の与信や反社チェックの一元管理などは、上場準備や内部統制の支援を通じて「本当に必要だった」と実感した機能です。業務を理解した実務家が設計に関わること。それが、大前氏が指摘したグループウェアの枠を超えるための条件だと考えています。

また、会議運営についても大前氏は、スケジュール管理で決めた時間に関係者が一斉にオンライン会議に入るような、ダイナミックな運営を歓迎すべきだと述べていました。当時は先進的に聞こえたこの姿も、今では多くの会社で当たり前になりました。eMplex PBMでは、NotionやChatworkなどのツールと連携し、承認やアラートを日々のやり取りの中に組み込むことで、数字の変化にチームがすぐ反応できる環境づくりを目指しています。

まとめ：情報共有の道具から、経営の中枢へ

eMplex PBMのようなシステムを導入するときに、私が必ずお伝えしていることがあります。それは、すべてを一度に始めようとしないことです。まずはプロジェクトコードの体系を決め、タイムシートによる工数入力と、プロジェクト別の予算・実績の管理から始める。これが定着して月次でプロジェクト別の粗利が見えるようになったら、フォーキャストによる着地見込みの管理、営業活動との連動、人事評価への活用へと、段階的に範囲を広げていく。大前氏がスケジュール管理を核として周辺業務を統合していけばよいと述べたのと同じように、工数という核から始めて、つながりを一つずつ増やしていくのが成功への近道です。

導入の成否を分けるのは、システムの機能の多さではなく、経営者がその数字を使うかどうかです。月次の経営会議で、プロジェクト別の粗利と着地見込みを必ず確認し、アラートが出た案件について担当者に説明を求める。この習慣が根づけば、入力する側の意識も変わり、データの精度は自然と上がっていきます。逆に、経営者が数字を見なければ、どれほど優れた仕組みも、やがて形だけのものになってしまいます。

グループウェアは、社員同士が予定や情報を共有するための道具として広まりました。その役割は今も大切です。しかしプロジェクト型ビジネスにとって、社員の時間は会社の最大の経営資源であり、その使い方の記録は、そのまま経営の記録です。スケジュールと工数、原価と売上、営業と人事が、プロジェクトという単位でつながったとき、グループウェアは初めて「経営の中枢」になります。

大前氏が十数年以上前に描いた構想は、決して色あせていません。むしろ、人材不足で一人ひとりの時間の価値がかつてなく高まっている今こそ、実現する意味が大きくなっていると私は考えています。業務と会計のあいだに立ち続けてきた実務家として、その構想を現場で使える仕組みに落とし込むこと。それが、eMplex PBMを通じて私たちが果たしたい役割です。自社の情報共有の仕組みが、経営の意思決定にどこまで役立っているか。一度、立ち止まって見直してみてはいかがでしょうか。