エンジニア組織のマネージメントを思考する

前置き

今回は、エンジニア組織のマネージメントを自分がどのように考えてきたのか？の備忘録です

思考した結果、チームのアウトプットを最大化することを目指し、構造化・モニタリング・レバレッジ期待値の3つでマネージメントを捉えています という話をします

何をモニタリングする？何を基準にレバレッジ期待値を判断する？考えるベースとなるものが構造化

以下の3項目で整理していきます

1. 事業と価値とエンジニアの関係性
2. 損益と資産と要求と生産の関係性
3. モニタリングとレバレッジ期待値

1. 事業と価値とエンジニアの関係性

最初に考えるのは、会社に所属するエンジニアは何を作っているのか？について

プログラム？システム？サービス？ いえ、事業 を作っていると考えています

そのため、スタートは事業のことから理解していきます

労働とお金の話

皆さんは、お金をどのように手にしていますか？

大抵の人は労働の報酬として、お金を手にするんじゃないでしょうか

自分の頭にある労働とお金の構造を表現してみます

時間や技術を使って	作りだした資産価値が	お金に変換される
👷	💎	💰

人とお金の間に価値が存在しています

極端に言うとガムシャラに働いたとしても、無価値なものを作り出してしまうと、お金には変換されないのですね

次は価値について考えていきましょう

価値とお金の話

自分が価値があると考えて作り出した資産が、他者から見たら無価値である状況は、どう理解するとよいでしょうか？

ちょっと別の視点をいれます、価値観という言葉がありますね

価値観（かちかん、英:sense of values[1]）とは、何に価値があると認めるかに関する考え方[2]。
価値(善・悪、好ましいこと・好ましくないこと、といった価値)を判断するときの根底となる ものの見方[2]。
ものごとを評価・判断するときに基準とする、何にどういう価値がある(何には価値がない)、という判断[3]。

引用: wikipedia

人は価値を各々の基準によって判断している、他者が価値を認める資産を作り出せれば、お金を獲得できることがわかってきました

であれば、多くの人が価値だと認める資産を作り出せれば、多くのお金が獲得できそうです

事業とは 多くの人が価値だと認める資産を仮定し、作り上げ、収益をあげる ことだと捉えられました

また 多くの人が価値だと認める ≒ 社会的価値 とも考えられるので、多くのお金を稼げる事業を作ろう！とする行為は、社会的価値のある事業を作ろう！と同義なのかもしれません

事業とシステム価値とエンジニアの構図

ここまでの情報を使ってまとめ直します

エンジニア	システム価値	経済的価値	社会的価値	事業価値
🏃‍	💎	💰	🌏	⛳️

※ 以降の説明の図で登場するアイコンの解釈です

構図	説明
💎 ⬅︎ 🏃‍	エンジニアは システム価値を生産する
🌏 ⬅︎ 💎	システム価値は 社会的価値を生産する
💰 ⬅︎ 💎	システム価値は 経済的価値を生産する
🌏 ⬆︎ 💰 ⬅︎ 💎 ⬅︎ 🏃‍	上3つを重ねると エンジニアはシステム価値通して 社会的価値と経済的価値を生産する
	大きな経済的価値は 社会的価値になりえる 逆もまた然り
	事業価値というものは 社会的価値からくる要求と 経済的価値からくる要求が 引っ張り合い生産された システム価値から繋がる物

最後の図が、自分の中で構造化した事業と価値とエンジニアの関係性です

2. 損益と資産と要求と生産の関係性

事業と価値とエンジニアの関係性の章では、最も根底となる概念のような話になったので

次は、事業運営の要素を使ってもう少し具体性をつけていきます

note.com note.com

※ 上記2つの記事が自分の考え方の骨子というか元ネタです、とても有益な記事を公開して下さって感謝致します 🙏 これに自分の解釈を加えるような形で表現していきます

※ G/P（総生産力）につきましては「CTOの頭の中：技術を財務で表現する」を参照されると深く理解できます

損益と資産と生産の話

💰 P/L（損益計算書） / 💎 B/S（貸借対照表） / 🏃‍ G/P（総生産力）という登場人物がいます

エンジニア組織という生産力によって、システム価値である資産と負債が生産され、それを運用することで損益が発生する構図を表現してみました

この図にもう少し付け足したいものがあるなと考えました、それは要求の出所です

開発というのは要求の出所がなければ始まりません、次はその観点を盛り込んでみます

二つの要求と生産力の話

開発における要求とは、どのようなシステム資産をつくりたいのか？どうやって事業成長をさせたいのか？というものと捉えられます

Growth Request (G/R) とでも名付けて図にしましょう

この図を言葉に変えるのであれば

1. 社会的価値を Vision として描き
2. 事業戦略（プロダクト戦略）に変え
3. エンジニアの生産力を使って
4. システム資産を作る
5. システム資産を運用して収益にする

とったような形でしょうか？すこし普段現場で考えていることに近くなってきました

この中で、エンジニアが密接に関わる項目はどこでしょうか？色付けしてみます

B/S と G/P ですね、個別に言葉を補足していきます

分類	項目	補足
B/S	Asset/資産	プロダクト戦略に基づくシステム開発 事業成長にダイレクトに効く 最も生産力が使われる
B/S	Debt/負債	資産と対になって生まれるシステム負債 開発効率やスケーラビリティに悪影響 エンジニアが最も正しく認知できる
G/P	Reducer/減速要因	システム資産以外に使われる生産力 育成や会議といったもの
G/P	Accelerator/加速要因	開発プロセスの最適化やDevOps 生産力のエンハンスメント
G/P	Power/生産力	エンジニア組織そのもの

Asset/資産 はプロダクト戦略という要求の出所が見えてきましたが、他の要求はないでしょうか？

Debt/負債 はエンジニアが最も正しく認知できるため、この負債を返済したい！といった要求が生まれます

開発効率やスケーラビリティに影響するので、事業運営上も無視はできないものです

プロダクト戦略と対となる、システム戦略と便宜上呼びます

システム負債を返済する要求なので、Repayment Request (R/R) とでも名付けて再度図にしましょう

事業運営の要素に要求と重ねて考えてみると G/P の投資先が、プロダクト戦略とシステム戦略の二つとなる構図となりました

この構図が、自分の中で構造化した損益と資産と要求と生産の関係性です

システム戦略とプロダクト戦略を実行するためには、それぞれのタスクを比較した時の有用性が判断できないと、生産力を行使することができない のです

やっと、事業運営におけるエンジニア組織を構造化できました

次は、どこから情報を集めるのか？レバレッジをどう判断するのか？についてです

3. モニタリングとレバレッジ期待値

今回話してきた構造におけるエンジニアが密接に関わる対象の中で、お金を産む可能性があるのはシステム資産だけです

そのため、事業におけるシステム開発というものを考えた時には、システム資産に効率的に変化を与え続けられてるかどうか？

このように集約されていくのが、今の自分に見える世界です

変化量を基準に打ち手を作り、再度変化量を観測する、エンジニア組織のマネージメント全体像になりました

打ち手をいかにして考えるのか？をもう少しみていきます

モニタリング対象の話

エンジニアが密接に関わる B/S に関連する部分を、構図で色分けしてみましょう

• プロダクト戦略として表現される、事業要求の変化
• システム戦略として表現される、開発要求の変化
• 事業収益として表現される、各種事業数値の変化
• 総生産力として表現される、エンジニア組織の変化

4つのモニタリング対象が存在することが理解できました、これらの変化に伴って生まれるのが課題感です

その課題感に対して解決する打ち手を考えていくのがベターそうですね

レバレッジ期待値の話

複数の課題感が生まれてくることが想像できます、何を基準に打ち手に優先順位をつけるのでしょうか？

システム資産に変化を与え続けたい前提に立った時に、打ち手がどのくらい影響を与えるのかと必要となる生産力

それがレバレッジ期待値なのだと解釈しました

まとめ

1. 事業価値というものは社会的価値からくる要求と、経済的価値からくる要求が引っ張り合い生産されたシステム価値から繋がる物

2. 事業運営の要素に要求と重ねて考えてみると生産力の主な投資先が、プロダクト戦略とシステム戦略の二つとなる

3. 4つのモニタリング対象の変化を観測し、変化に伴って生まれる課題感を解決する打ち手を考えていく

4. システム資産に変化を与え続けたい前提に立った時に、打ち手の影響度と必要となる生産力によってレバレッジ期待値を判断する

大変長くなりました、最後までお読みいただいた方はお付き合い頂きありがとうございます

おしまい