エンジニア組織のデザインと管理会計
何回か組織デザインについて書いた。
ここで思い出した。お金の話を全くしていない。経営はヒト・モノ・カネらしいがこれまでにしてきたのは主にヒトとモノだった。お金の話をして見よう。
組織デザインと権限
組織デザインはコミュニケーションのアーキテクチャと捉えるのが良いと書いたが、一般にはミッションの体系化あるいは権限委譲のアーキテクチャと捉える方が自然である。
事業に関する権限
人事に関する権限
予算に関する権限
株式会社はそもそもとして、株主総会から取締役会へ、取締役会から各組織へ、そして組織から各メンバーへと権限を委譲することによってスケールアウトする集団である。組織デザインはこれを表現する。
グループあるいはマネージャーには達成すべきミッションとそれを行なうための権限と責任が必ずある（ないなら何かがおかしい）。人が100人いれば100通りの能力と経験と知識があり、100通りの異なる意思決定が生まれる。似たような能力と経験と知識なら似たような意思決定になるだろう。意思決定は何かを選び何かを捨てることだから、これは物事に優先度をつけることと同じである。すなわち、誰かに権限を与えるということは組織に優先度をつけることである。
ビジネス職をリーダーにするか事業部制の組織にすれば短期的な売上が優先されるだろうし、技術職をリーダーにするか機能別の組織にすれば長期的な事業成長が優先されるだろう。
予算についても同じことが起きるが、ヒト・モノ・カネは分離できないというのは覚えておく必要がある。組織デザインは一通りしか採用できない。
2つのプロダクトといくつかの会計
簡単な例を上げて、少し具体的な話をしてみる。
プロダクトが2つ（プロジェクトA、プロジェクトB）がある
メンバーは営業か開発のどちらかである
プロジェクトにはそれぞれ売上がある
プロジェクトにはそれぞれ費用があり費用、内訳として人件費とサーバ費用がある
以前は主にpeople management的な観点で組織デザインを考えたがfinance的な観点だとどうなるだろうか。
事業＞プラットフォーム
グループを事業でわける。
プロジェクトA
営業
開発
プロジェクトB
営業
開発
この分け方のメリットは明白で、プロジェクトAとプロジェクトBのそれぞれの単体の会計を計算できる。しかも簡単かつ完全に。全体としてはプロジェクトAの人件費とサーバ費用、プロジェクトBの人件費とサーバ費用をそれぞれ計算すれば良いし、それぞれのプロジェクトのリーダーは余計なことを考えずに自分のプロジェクトのP/Lを最適化すれば良い。人員がどれくらい必要かも、サーバ費をどれくらい許容できるのかも簡単に計算できそうだ。事業計画や人員計画を立てやすそうだし、実際に実行しやすいだろう、PDCAも回しやすそうだ。
デメリットは全体最適化ができないことである。人件費が高くなりそうなエンジニアの採用は最適化されないだろうし、これまた高くなりそうなサーバ費用に関してもインフラは最適化されなさそうだ。例えばエンジニア採用の面接官はかなり偏るだろう、そのたびに事業リーダーが採用担当に文句を言うか、採用担当が事業リーダーに相談しにいく状況が想像できる。プロダクト開発技術に比べてインフラ分野は相対的に貧弱になり、プロジェクトリーダーは特にインフラに詳しくないだろうエンジニアの適当な見積もりを聞く以外に予算を考える手段がない。
プラットフォーム＞事業
グループを逆にプラットフォームでわける。
プロジェクトA
営業
プロジェクトB
営業
開発
少し変則的に営業はプロジェクトに直接置くことにした（これは本稿の本筋ではないのでどちらでも良い）。この場合のメリットとデメリットは先の逆になる。メリットはわかりやすい、エンジニア全体の人事とインフラを最適化できる。
デメリットは？事業リーダーからするとエンジニアの人件費とサーバ費用が見えないコストあるいは制御不能なコストになる。P/Lを最適化するという目的だとかなり厄介だ。一方でプロジェクト側の事情がわからないと、エンジニア全体で必要な人件費とサーバ費用がよくわからない、というか全くわからない。わからないということはナイーブに考えると最適化するモチベーションが出てこない。なんてこった＼(^o^)／機能的には最適化しやすいが最適化する優先度が上がりにくいのだ。
実際にはサーバ費用のうちXX%をプロジェクトA、YY%をプロジェクトB、ZZ%を全社横断機能とか割り当てると思う（あるいはプロジェクトAからxx円、プロジェクトBからyy円、その他としてzz円）。ただ匙加減ひとつで各プロジェクトのP/Lがかなり変わりそうだ（そしてこの匙加減はプロジェクトリーダーからコントロールできない）。さらにこのZZ%はいわゆるコストセンターだから匙加減だけで限りなくゼロにできる。
事業＋プラットフォーム
いいとこ取りを目指してみる。
プロジェクトA
営業
開発
プロジェクトB
営業
開発
開発横断
横断部門だけ独立させたらどうか。これは問題を解決しない、というか悪化する可能性もある。プロジェクトリーダーからすると自プロジェクトの費用は見えるが横断組織の費用は全く見えなくなる。横断組織からするとインフラを使っているのは各プロジェクトだ。各プロジェクトのサーバ費用は誰が見るのだろうか？横断組織の「小さなインフラ」よりプロダクション環境のサーバ費用の方が規模が大きいだろう。かくして元の目論見とは異なりプロジェクトリーダーは売上を追い、横断部門は自部門のコストを追い、最も費用がかかりそうなものが放置されるのだった。
back to basics
組織デザインとはなんだったか。
組織デザインで第一に覚えておくべきルールは、すべての組織デザインは悪いということだ。あらゆる組織デザインは、会社のある部分のコミュニケーションを犠牲にすることによって、他部分を改善する。
financeの観点では、組織デザインはある部分の会計を犠牲にして別のある部分の会計を改善する。
コミュニケーションにはキャパシティがあるという話をした（だいたい3〜8人くらいが適正）。では、1人のマネージャーが同時に追えるKPIの数は？OKRでkey resultを何個置くべきかとも言い換えても良い。これには答えがある。
まあこれは正しいがちょっと現実的ではないと思う、ただ3つぐらいが限度なのは本当だ。
自社の会計をできるだけ上手く説明できるKPIツリーの中でインパクトが大きくレバレッジのかかる部分に責任者を置き、その責任者が十分に業務にフォーカスできるように組織をつくれば良い（このKPIツリーは一般に管理会計と呼ばれるだろう）。こういうと当たり前のことしか言っていない気もするがこれは組織図を「ただ綺麗にする」ことよりもずっと大事なことだ。
この観点で考えると、事業部長ではないCxOの中でCFO、CMO、CTOが比較的多くの企業に存在する理由がわかる。一般的に、これらのポジションはその機能自体が会計に大きな影響を与える。例えば、CTOはトップラインへの影響では事業（特に開発計画）と採用人数、ボトムラインへの影響では人件費とサーバ費にフォーカスすることが多いだろう（今言ったことを合わせると4つになる、一人でこれを全部やるのは難しいということになる、だからVPoEやVPoPを置く）。
自社のKPIを分解して、フリーハンドで作り直した時に、最もレバレッジが効く、betすべきはどこだろうか。それが組織デザインのヒントになる。
この記事が気に入ったらサポートをしてみませんか？