会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。

この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。

財務諸表と同じように見える化する

会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じないってことではなくて、プライオリティの話です。数字で負けると潰れちゃうので、まず数字を見て戦略を立てなきゃ本末転倒だよね、という話。

そして社長やCXOも基本的には財務三表くらいは読めるはずです。読めないと話にならないし、有効な戦略も導き出せません。であるならば、技術の話をするために財務諸表の流れの中に、技術の話を出そうじゃないかというアプローチを考えました。

この図はいつも僕の頭の中にあるものです。一番左にPL（損益計算書）、真ん中にBS（貸借対照表）、そして右にGP（総生産力）。GPってのは僕が勝手に名付けた名前で「Gross Productivity」の略にしています。要するにエンジニアチームの総生産力を表しています。

僕の視点からすると、現代のIT企業の内製エンジニアチームって凄く特殊で、バランスシートにやってくる「システム」資産を作る力のことと言っても過言でない。もう少し言葉遊びすると「作る」というより「作り続ける」力。流量のようなイメージでしょうか。

元々、資産を作るという意味で言えば、工場や建築といったようなものがあったと思いますが、販売と工場の関係性で言えば受発注のような関係性で、建築も建築会社にお金を払って建築物を買うわけです。事業会社が建設技術者を抱えて絶えず工事し続ける、なんていう状況はいままで見たことが無いのですが、IT事業会社ってずっとこれやってる感じなんですよね。まず、この新しいモデルを財務として表現しようとすると、どうしてもバランスシートの上位に「単位時間あたりの総生産力」のような概念を作らないと説明ができない。だからこの「G/P」という概念を絵にすることにしました。

このG/Pの構成要素は当然ながら「ピンのエンジニアのアウトプット力」みたいなもの（Velocity）から、チーム開発プロセス、カルチャー、外部要因による摩擦（μ）、自己組織化における改善係数（k）など、まあ、色々あります。解像度を粗くして例を出すと「エンジニアにリモートワークを許可した方が良いか？」という議論は、結果としてG/Pが上がるかどうか？というゴールに対して見ていけば良いというような話になります。G/Pが下がったらリモートワークやっぱやめるとか、例えばそういうトライができると良いですよね。制度やカルチャーへの投資はμ、kという係数に引っかかってくる可能性があるので、対係数へのROIに着目していけば、自ずとボードでのコミュニケーションもやりやすくなるのではないかと思います。

次に「一番注目したいところが」Product ManagerとCTOの役割の違いでしょうか。全部できる人がいても良いですが、全部ひっくるめればひっくるめるほどアーティストになってしまうので、できる限り責任は大きくひとつにした方が良いでしょう。その方が採用難易度も下がり、再現性も高まります。結果、仕組みとして成立しやすくなります。

ここではそれぞれの責任を
・Product Manager：プロダクト資産を有効に活用し、利益を生み出す
・CTO：G/Pを最大化し、アウトプットを最大化する
という風に置いています。

よく、この一気通貫の人材を探している経営者がいますが、まずは落ち着いて欲しくて。その人は多分「CTO」ではないです。もちろんCTOにもできる人はいますが、良いProduct Managerを見つけて開発を外注する方が、まだ探している人材に近い働きをしてくれると思います。

作ることと稼ぐことは元来違うフィロソフィーがあるので、個人的にはこのように役割分担すると、経験上も一番バランス感が良いように思います。

Product Managerはつまり、Revenue / Profitに責任を持つ代わりに、開発組織に対して要求をしたり、優先順位を変えたりする権限を持ちます。そのためにCTO以下、開発に責任を持つチームは要求に対する結果＝アウトプットに責任は持ちますが、直接的にRevenueやProfitに責任を持つことは出来ません。なぜなら、P/Lへ直接影響させられる権限を有しないからです。（少なくともこの絵に書いてある組織構造では）

CTOや開発チームが優先順位をコントロールできる、要求に対してアウトプットの責任がゆるやか（期限を守らなくても良さげ、バグが沢山混入してても仕方がなさげ）、Product ManagerがP/Lに準ずる指標に責任を持っていないなど、そういう場合は責任と権限のバランスが破綻している可能性があるので、ちゃんとバランスが取れているかチェックが必要です。

G/Pのメトリクスは？

CTOおよび開発チーム側に話を戻しましょう。G/Pという仮の財務諸表がありましたが、絵を見る限り、G/Pからは資産を生み出しているようです（厳密には負債になりうるものも同時に生み出しているはず）。

G/Pを計測するメトリクスが単純な「アウトプット量」だとどうでしょう？その開発チームはどの程度の人数で、どのくらいの時間軸で、どのくらいコストをかけて生み出しているのでしょう？そしてアウトプットとは何？コード量？機能数？それともデプロイ数？ちょっと曖昧ですね。

最初の方に書きましたがG/Pとは「流量」のようなもの、どれだけでっかい「水道管」なのか？みたいなイメージです。つまり、単位時間あたりにどれだけの量をアウトプットできるか？なので、上の絵で見ると右側、機敏さや生産性というものも関係していていないといけないイメージです。莫大なお金と時間をかければ、さすがに大抵のものはできると思いますが、それでビジネスが成功する訳ではないですから。やはりコスト対効果は大切です。

例えば「d/d/d」というメトリクスがあります。それぞれの「d」は、Deploy / Developer / Dayです。1Deployという結果に対して、何人のエンジニアで何日を要したかの逆数が出る指標です。10回のDeployを5人のエンジニアで20日要していたとしたら、d/d/d = 0.1 となります。この数が多くなれば多くなるほど、1要求あたりのアウトプット（Deployまで）の生産性は高いということになります。生産量は課題解決数でもDeploy数そのものでも良いかと思いますし、Velocity（チームあたりの生産可能量）の総和（異なるチームのVelocityの総和は微妙だけど）みたいなものでもありだと思います。

ポイントとしては、生産した結果だけにコミットする開発チームは「外部ベンダー」とあまり変わらないということ。取引コストだけ社内の方がコストカット出来ますが、コストセンターになります。機能提供チームと割り切ればそれもひとつの戦略ですが、コアとなるシステムを開発し続けているチームには生産性の指標も入れて、事業全体のROIに効果をもたらすようなゴール設定をしていくことが強い技術組織を作る要素となるでしょう。

Deployを大切にする

ざっくりなプロセスで言えば、開発とは要求を受けて要件定義をし、多段階に及ぶ設計をして、開発、QA（テスト）、本番反映（Deploy）となります。QAの前まではVE（Value Engineering）を行うタイミングをいつでも取ることが出来ます。要求に応えることが出来るならば「このOSS使ったら一瞬でできますよ」というのも設計か開発工程（担当のエンジニア）からしか生まれない発想だったりするので、VEを適宜行いながら生産性を上げていきます。もちろん不要なVE検討はただ時間が過ぎていくだけなので、みんなで考えるよりも起案ありきでVEを行うようなやり方がベターだと思います。

大きな開発組織になると、意外とDeployがされないブランチ（新機能など）が出現したりします。外部要因の変化などでちょこちょこ発生することがあります。生産性という観点で考えれば、本番適用されないものは、究極生産されていないことと等しく、またDeploy権限と執行がProduct Managerの意思とリソースのみで行うことができない場合、やはり開発チームがDeployまで責任を持つことが大切です。これによって、DevOpsチームが組成されたり、Blue Green Deployが可能になったり、生産性の観点からすると素晴らしい機能開発がなされる可能性を秘めています。

つきつめていくと、仮説としてProduct Managerの仮説が一定確率で当たりを引くとしたら、出来る限り多くのアウトプット（Deploy）をスピーディに行う開発チームがより強いと考えられます。一括でタイミングを合わせてDeployするパターン（上の絵の上段）と、五月雨でいつでもDeployできるシステム（上の絵の下段）で見比べても、検証スピードまで含めるとスピードアップが出来そうです。

上の絵は一括Deployのイメージですが、一括QAなど、Requirement単位（ISSUE単位）で待ちが発生するプロセスであればあるほど、思った以上にアウトプットの生産性は高まりません。開発力そのものだけでは、本当に事業貢献できているかわからないわけです。

技術負債との戦い

もう一つ、切っても切り離せないのは「技術負債との戦い」です。上の絵はめでたくビジネスが成功しているITサービスの「ある検索スピード」の対データ量グラフになります。

概ね、検索速度はデータ量が増えれば増えるほど遅くなりやすいものです。複雑な検索になればなるほどこの現象は顕著です。嬉しいかな、サービスが上手くいってユーザー数が増えれば増えるほどサービスが遅くなるというのは、こういう基本的な現象によってもたらされます。しかし、この速度が「体感として遅い」というところまで放置された場合、わかりやすく技術負債として認定されます。

この技術負債はあくまでも「B/S」に存在します。負債ですから。負債を返済するべきか、いやいや負債をさらに増やしても突っ込むべきか、こいつは経営判断レベルに難しい話です。少なくともProduct Manager（PLとBSにまたがって責任を持つ）と、CTO（BSとGPにまたがって責任を持つ）が議論してProduct Managerの権限のもと、優先順位を変更するようなプロセスが理想的な状況です。さらに言えば、上の絵の青い線のグラフのように、事前事前に対策できれば、一度の対応コストも大きくならずに事業全体のスピード感も大きく落とさないで対応できるのではないかと思います。

他にも上の絵のように、分岐処理が時を経て負債化していくことはママあります。使っていないコードを断捨離するタイミングがあれば良いのですが、断捨離自体もユニットテストコードがしっかり存在していたり、ある程度コード改変による影響範囲を小さくするためにマイクロサービス化されていたり、アーキテクチャと初動の開発プロセスに安全性をどう組み込んでいるのかということが技術負債との戦いの難易度を決定づけます。コンテナ化、Infrastructure as Codeのような概念も、断捨離、リファクタリング時に威力を発揮するでしょう。自動E2Eテストなんかもありがたいですね。

その他にも

そもそもの総生産力を高めるためにエンジニア人数、それぞれのエンジニアのスキルの高さ、チームとしての出力、リテンションなど、わかりやすく言えば採用、研修、文化形成、開発プロセス改善など、G/Pを向上するために必要なロールは数多くあります。

今回は財務諸表のイメージから、トップダウンの視点で解像度粗くプロダクト、テックチーム、CTOの責任範囲などを大雑把に見てみました。また、そこに紐づくコンフリクトする要素（Deploy数/生産性の追求と、技術負債の返済など）についても触ってみました。

視点を変えながら、今後もちょこちょこ頭の中を出力していこうと思っていますが「じゃあ何をどうすれば良いんだよ？」と結果へのコミット力が高い方のために、こちらのDX Criteriaをご活用ください。説明資料のスライドをご覧いただければ各要素に対して細かく指針を明記しています。DX Criteriaは現場レベルから対策ができる内容となっていますが、こちらのnoteはそこへ着地するための経営レベルから考えた時のアプローチ、DX Criteriaとの整合性を説明するようなものでもあるので、両サイドからアプローチいただくことで、行間が埋まるところもあるんじゃないかな？と思っています。

それではまた、僕が暇な時に。