「順調なはず」なのに、胸のざわつきは消えない。

なぜ「順調なはず」なのに、胸のざわつきは消えないのか？

技術組織のリーダーとなり、技術組織のマネジメントを安定化させて、主要プロジェクトも問題なく進んでいた。

順調にもかかわらず、胸の奥のざわつきが数年消えなかった。

振り返ると、このざわつきは、事業の成長を“自分の手で動かしている実感”が薄かったことに由来していた。

この数年間で私は、

• 現象を構造として捉える
• 領域課題を設定する
• 事業解像度を上げる
• 不確実性に踏み込む

という順番で、自分の扱う世界が更新されていった。

この記事では、技術組織のリーダーとして変化を実体験に沿ってまとめていきたい。

現象を“構造”として読む

単体指標では見えない。複合的な“つながり”として読むことで構造が立ち上がる

最初の1年は、とにかく組織を多面的に見ることに集中した。

• プロジェクトの進行
• SLO
• 開発量
• 生産性
• 人材ポートフォリオ
• 定性アンケート
• メンバーの負荷
• 技術課題数

これらを単体だけではなく、価値や課題の流れを示す複数の信号として読むようになった。

読み方を養うことで、技術組織マネジメントの不確実性を、徐々に構造として捉えられるようになっていった。

構造として捉えられるようになると、マネジメントアクション（課題発見と打ち手のセット）が自分の中に増え、組織は定量と定性で以前より安定。

数字だけみれば順調なはず。

それでも、胸のざわつきは消えない。

課題を包括する “領域課題” の設定

無数の単一課題の中から、“関連性と密集度によって領域”の輪郭を作る。

現象を構造として読めるようになっても、「どこに踏み込むべきか」は自動では見えてこない。

単一の課題を一つずつ解くのではなく、“価値が集まる領域”としてまとめて扱う視点が必要だった。

• 価値や課題の源泉がどこにあるか
• 優先すべき領域はどこか
• 今触るべきではない領域はどこか

扱うテーマの選び方が大きく変わった。

ただこの時点で扱っていたのは、あくまで技術領域の課題に限られていた。

まだ、胸のざわつきは消えない。

事業計画を書いたことで“価値の流れ”と"事業解像度"が変化

事業計画を自分で組み立てた瞬間、点で理解していた要素が一本の価値の流れに

領域課題の先、事業課題を考えるタイミングで、自分で事業計画とプロダクト計画を書いてみた。

これは想像以上に大きな変化だった。

顧客獲得、コスト構造、投資と回収、収益レバー、プロダクトの優先度…。
こうした要素が、説明ではなく因果として自分の中につながり始めた。

技術の延長では説明しきれない、“事業としての動き” を感じ始めた。

その結果、 どの領域に手を入れるべきかの判断が、以前よりはるかにクリアになった。

前提が変わると、他領域の数字も同じ価値の流れとして読めるようになる

加えて、マーケや営業の数字が急に自分にとって意味を持ち始めた。

• 流入の質
• MQL（Marketing Qualified Lead） → SQL（Sales Qualified Lead） の変化
• 営業プロセスの歩留まり
• 成約率

これらが、事業全体の価値の動きとして読めるようになったからだ。

価値の流れを事業全体で捉えられるようになり、技術領域と事業領域の接続点が少しずつ掴めていった。

両者が別物ではなく、同じ線上にあるように見えてきたのだ。

胸のざわつきは薄まってくるが、しかしまだ消えない。

4. 事業の不確実性探索を実行することで“前提”が書き換わった

事業のダイナミズムに触れることで、判断の前提が更新される

技術組織のマネジメント基盤が整い、扱う前提も揃い始めた頃、時間の余白が生まれた。

その余白で自身の起案と PoC に踏み込んだ。

• 自分で正解にする
• 前提が揺れる
• 現場の声で仕様をドラスティックに変える
• 仮説と検証を最短で行き来する

事業の変動と手応えに触れた瞬間、 胸のざわつきが止まっていることに気づいた。

最後に

技術組織のマネジメントは、不確実性を構造に落とし込むことで少しずつ安定してきた。

しかし、“事業の不確実性”には、まだ自分の手が届いていなかった。それが、胸のざわつきの理由だった

事業に踏み込み、ダイナミズムに触れたことで、ようやく胸のざわつきは静まった。 自分が求めていたのは、事業の流れを自分の意思で作ることだったのだと思う。

所謂、技術と事業の接続を模索してきたのだと振り返る。

技術リーダーは、同様のざわつきを抱える人が少なくないのではないか。私の軌跡が手がかりになれば幸い。

エンジニア組織の年次計画とミッションツリー

CTO となり一年が経ちました、あっという間ですね。以前とは違うマネジメントの考え方が形になってきたので、筆を取ります。

1. 財務視点でのエンジニア組織年次計画の作り方
2. ミッションツリーとロールの関係

1. 財務視点でのエンジニア組織年次計画の作り方

バーンレートを正しく意識する

「自分たちが扱う事業モデルは、サービスで主要な売上を得ていますか？プロダクトで主要な売上を得ていますか？」

---

• SaaS のような月額課金モデルは、プロダクト売上構成比率: 高、サービス（導入時のコンサルティング等）売上構成比率: 低の関係性になりやすい
• 仲介業のような契約手数料モデルは、プロダクト売上構成比率: 低、サービス売上構成比率: 高の関係性になりやすい
• 主要な売上を担う領域に、主要な予算が割り当てられる

要は事業モデルよって、プロダクト開発（≒エンジニアリング）を営業キャッシュフロー（以下CF）扱いと見るか、投資 CF 扱いと見るかの基本方針を変えています。

基本方針を前提に、戦略を加味した意思決定を行うためにもう一つ観点を入れます。

---

• 創業期 / 発展期 / 成熟期 / 衰退期 等の事業成長フェーズによって CF が - になる意思決定もする
• 基本は CF が + になるように計画・管理したい

CF の扱いと戦略的意思決定を持って予算計画化。

エンジニア組織人数規模を、バーンレートの適切性観点で説明可能であるように心がけています。

---

粗利対人件費率を用いたエンジニア組織計画

「自分たちが扱う事業において、粗利対開発人件費率の指針を持っていますか？」

エンジニア組織としての予算計画は、ほぼほぼ人件費の計画と言っても差し支えないのではないでしょうか？

人件費に対する基準作りは、経営を行う際の共通言語として役に立ちます。

---

準備 1: 業界水準

自社事業における具体基準を作る際には、IR 等の公開情報から必ず同一業界他社をリサーチします。

業界水準を把握して目安とすることは、現実味のない基準値を生まないための予防ですね。

---

準備 2: 総人件費のセクション別構成比率の優先度を捉える

営業 CF と見るか？投資 CF と見るか？を定めることを最初に言葉にしました。

これを使って事業におけるセクション（営業部門・開発部門等）別構成比率の優先度を考えます。

営業 CF 扱いならば 開発人件費増 = 売上増 の単純な構図になりやすく、セクション（営業部門・開発部門等）別構成比で 50%~ 等に設定。投資 CF 扱いならば 開発人件費増 ≠ 売上増 の構図にもなりえるため、セクション別構成比で10%以下等に抑制。 ※ 50%や10%といった数字は説明のための一例です

というようなイメージで捉えます。

エンジニア組織が社内で一番大きくて良いか？いやはや営業組織のほうが大きい方が良いか？大枠の検算に利用します。

---

準備 3: 最小構成人数の年次設計

• エンジニア組織が向き合うプロダクトやシステム群をチーム単位に分解、ヘッドカウントをプロットする枠を整理
• 専門性毎にアサイン・主幹プロダクトにリソース冗長性・一人チームでOK等、プロダクト開発に必要な最小構成を設計
• システム改善・マネジメントリソース等、エンジニア組織運営に必要な最小構成を設計
• 事業戦略・サービス戦略・システム戦略等、新規プロダクト開発や SLO 維持向上に必要な最小構成を設計

---

アウトプット（サンプル）

• 準備 3 の最小構成での人数規模 x 平均人件費の総額の粗利比率を算出
• 準備 1 の業界水準から逸脱しすぎていないこと
• 準備 2 のセクション別構成比観点で投資不足 or 投資過多な数字となっていないこと

3 点を念頭におきながら、粗利対開発人件費率の妥当な基準範囲を設定。

これは CF が + になるように計画・管理するための素案扱い。

フェーズや状況によって意志をもって基準を上げる判断等をする（いわゆる成長投資をエンジニア組織に設定すること）。

---

アウトプットの利用用途

アウトプットをどのように計画に使うかというと、エンジニア組織人数の年次ギャップ = 採用計画 として扱える。

報酬設計見直し時の論拠として、平均年収上昇させても粗利対開発人件費率の基準に収まっているのだから、経営観点で実行判断可能だよね？という起案や交渉が行える。

短期計画の達成に開発力がスポットで必要、粗利対開発人件費率の基準に収まる前提ならば業務委託採用枠を増やす判断に利用する。

etc...

色々な使い道があります。

---

開発量が増えていることの説明

「人数に比例して開発総量が増えていますか？」

人が増えているのに、プロダクト開発のスピードはなかなか上がらないのはなぜか？この問いを投げかけられた時の説明、これも共通言語を作っておきたいですね。

開発生産性の概念における代理指標群を用いて、開発量を説明可能な状態にします。

生産性指標で何が読み解けるのか？抽象的な部分を例示してから、年次計画に盛り込みます。

---

生産性指標のモニタリングによる考察の一例

• ハイパフォーマー 2 人（黄 + 水色）で構成されたチーム A は、個のパフォーマンスの高さ + レビューサイクルの早さによってハイアウトプット状態を長期実現
• 長期運営プロダクト、新規プロダクト、専門性別（Android / iOS / Backend / Frontend 等）、システム資産の特性によってパフォーマンスに有意差あり

※ presented by エンジニアリング組織のパフォーマンスを最大化 Findy Team+

自組織の開発アクティビティを考察することで、生産性に対するハイパフォーマー影響度の示唆や、システム資産の複雑度の違いによる影響度の示唆が得られる。

なぜシステム戦略を立ち上げ、システム資産の複雑度を解消するのか？それは、開発アクティビティの変化を通して生産性が向上し、最終的なアウトプット量の増加へと接続させたいからに他ならない。

生産性指標を用いると、このような説明ができると捉えています。

---

年次計画への盛り込み

• 開発アクティビティの代理指標から 一人当たり実装数（日） 、総実装数（年） を盛り込む
• 人数規模増・開発総量維持 → 生産性低下 = 開発人件費 ROI が悪化
• 人数規模維持・開発総量増 → 生産性向上 = 開発人件費 ROI が改善

生産量の代理指標を年次計画へ盛り込むことで、人数に比例した開発総量の変化を認識できるようになる。

最低限ここからモニタリングを始めておくと、システム戦略案件の ROI を開発アクティビティの改善率によって、成果判定や振り返りに繋げられるのも嬉しいですね。

※ Findy Team+ は DevOps 指標 / サイクルタイム / 個人アクティビティと他にも多くのモニタリングに有用です

2. ミッションツリーとロールの関係

年次計画が出来上がった次は、どのようにマネジメントを行うか？ですね。

ミッションツリーとしての分解や、各種ロールに託したいことの連続性や関係性を一枚絵にして概念整理を行います。

---

これらを前提に、個々人に何を期待かけるか？や、明確な目標管理がある組織においては目標設定に繋げるのが良いのではないかと考えています。

---

ビジネス要件を前提とした SLO

最小構成人数の設計の説明や、ミッションツリー内に SLO を記載しました。

財務視点のパートでは語りませんでしたが、エンジニア組織のマネジメントにおいて品質に対する考え方をなくすことはできません。

大枠としての考え方を方針として持ち、エンジニアメンバーと共に管理していきたいですね。

「ビジネス要件を前提とした 」というのは、これまた事業モデルを軸に基準値を決めようという流れです。

---

事業特性を考慮する一例

医療

生死の倫理観が求められる場合、システムが止まっている事が許容されにくい。

だから、システム稼働率が 99.999% 等、一定水準を保つ目標設定と予算を設定する。

ソーシャルゲーム

イベント時にどれだけアクセスを捌き切るかが売上に強く関連する。

だから、システムパフォーマンスとしてレイテンシー 100msec 以内等、一定水準を保つ目標設定と予算を設定する。

不動産（自分の扱う領域での考えも）

オフライン接客等のサービスによる売上が主流、必ずしも高頻度アクセスを捌くことが求められるわけではない。

しかし、高額商材な部類であるため一つの機会損失の影響度は大きい。

よって過剰投資こそしないが、安定稼働の担保・規模拡大や年数経過による性能劣化を抑制できるだけの予算を設定する。

---

事業モデルをキチンと読み解くと、そこには求められるシステム品質の輪郭があって、SLO の具体基準値への示唆がある。

SLO を維持向上することに対して、専任や予算をつける必要性が認識されてヘッドカウントを変える、だから人件費として財務指標が変わる。

うん、財務側にも繋がりましたね。

おわりに

また一年後には違った思考をしているしれませんが、今回はこの辺で。

次の一年は 、DevOps 指標・プロダクト生産量をブレイクダウンしてマネジメントに落とし込めるように精進します。

ではまた！

事業開発もシステム改善も諦めないために考えてきたこと

メリークリスマス！

本日は 12 月 25 日ですね、皆様いかがお過ごしだったでしょうか？

はてさてかなり久しぶりに筆をとるわけですが、今回は「事業開発とシステム改善の両立」にいかに向き合ってきたか？そんな話をしようと思います。

主として手を動かしている時とマネージャーとしてチームを動かしている時と、両面で思考してきた末の内容となります、共感や何か発見があれば幸いです。

システム改善との向きあい方

システム改善と一口にいっても、色々な粒度感があると思います。

僕はユーザー体験変化と投入リソース規模感という観点を用いて、事業開発とシステム改善の両立に向き合う方法に行き着きました。

イメージが沸かせやすいように、最初にざっくりと分類を作ります。

---

---

どうでしょうか？リファクタリングがユーザー体験変化が高い分類にいるのは、なんだか違和感ある感じがしますね。

考え方を深ぼっていきたいと思います。

投入リソースをどう確保するか？問題

基本的にはシステム改善というものは、それ単体で考えた場合にユーザー体験としては変化が起こらないものであると捉えています。

事業目線で考えていくと、投入リソースを大きくする力学が働かないと言うことを意味しています。（ユーザー体験の変化が起こらない行為にリソース投入するインセンティブが薄い）

これが 投入リソースをどう確保するか？問題。

システム開発の生産性の低下を防ぐ、システムパフォーマンス向上に比例したユーザー体験向上、いかに事業価値へと翻訳するのか？色々なエンジニア組織で翻訳家がいて、腕の見せ所であろうと想像します。

僕も長年この問題と翻訳に向き合ってきました。その中でやはりこう、事業成長や業績を後ろ盾にされると、どうしても説得には時間もスキルも必要だなと痛感します。（翻訳活動を諦めはしない）

システム改善への投入リソースを安定確保できないと、サービス品質が低下していくことを専門家として定性的に理解しています。だからこそ、これはエンジニア組織が解かなければいけない普遍的なコア課題だなと考えます。

そこで僕は、事業と交渉する回数減らしたり難易度を下げるにはどうしたら？ こんな問いに対して試行錯誤してきました。

事業と交渉する回数や難易度をできる限りコントロールする

取り組みは以下の 3 つ

1. 運用リソースとして固定費扱いで確保する
2. 機能開発要求に合わせてシステム改善をプランニングする
3. 事業規模に合わせてシステム改善をプランニングする

1. 運用リソースとして固定費扱いで確保する

書いた文字の通りで、開発工数の 10% 程度は固定でシステム改善に確保させてくれと言うものです。

ライブラリ更新や開発環境の更新系等、ルーティンで行いたい改善アクションや、システム改善活動を行いたい箇所の課題マップをため込んでいくアクションに使っています。

エンジニアリングマネージャーが組織へ説明して獲得するケースが多く、固定で確保してしまうことで都度交渉をなくします。

2. 機能開発要求に合わせてシステム改善をプランニングする

細かい単位でのリファクタリングに始まり、データ構造の改修や、1 の活動でため込んだシステム改善課題マップの解消に至るまで、多様なユースケースがあります。

キモは、機能開発要求が発生した際に触る事になるコードをスコープとして実施すること。

これによりシステム改善単独の投入リソース交渉ではなく、事業成長や業績貢献とセットでシステム改善を行う目的で投入リソース交渉ができる構図となる。

※ リファクタリングがユーザー体験変化が高い分類にいた理由

この目線を取り入れることで、プランニングとしてのスケジューリング時には、自分のスキルが高まるほどにシステム改善ができるとも言えます。（変数が自分のみになるのがいい）

エンジニア自身で PO や事業企画へ説明して獲得するケースが多く、交渉難易度を低くします。

3. 事業規模に合わせてシステム改善をプランニングする

1 と 2 による活動は、あくまで予防や改善活動の細分化になります。

これだけではリアーキテクチャのような、投入リソースが大きいシステム改善を行うことには至らないなぁというのが本音です。

ここで初めて、システム改善活動のみによる事業価値への翻訳が必要になります。事業規模によるバックキャスト思考を用いて、大規模な改修リソースを確保しに動きましょう。

事業計画上 xx 年後にxx 倍になるユーザー数に対応するシステムパフォーマンスを得るため、xx 年後のシステムクライアント数に対応するアーキテクチャを得るため、色々な観点が成長戦略上から逆算して描ける。

技術トップが経営へ説明して獲得するケースが多く、地道に交渉する領域ですね。

終わりに

システム改善活動を安定的に行うというのは、事業価値へと繋がっているものであると信じています。

エンジニア、EM、技術責任者等、それぞれの領域でのアクションの積み重ねによって、事業開発もシステム改善も両立していきたいですね。

おしまい。

LADR を組織で運用プロセスにするまでの話 part 1

What is LADR?

Lightweight Architecture Decision Records の頭文字をとって LADR

アーキテクチャの決定事項を、背景や協議内容と共に記録する手法です 最近は、色んな組織で取り入れられるようになってきましたね

現代におけるシステムは、コミットヒストリー、アプリケーションコード、テストコード等の管理状態によって、実態そのものをドキュメンテーションとして捉えることも可能になったと考えています

しかし、それはあくまで今この瞬間の実態について、自己ドキュメンテーション化されているだけであり、なぜこのアプローチを選択するに至ったのか？については多くを語ってはくれません

この課題に対して、実態の前提条件となる技術的な意思決定情報を残すことで、システム資産の過去と現在を繋げて理解するための手引き の役割を果たす、それが LADR の運用する意義だと僕は解釈しています

今回は、 LADR を自組織にフィットさせるためにどんなアクションしてきたのかを、言葉にしようと思います

LADR 自体のメリデメや、How の話は多いなぁと思っているのですが、どのようにプロセスを作っていったのか？の話はまだ少ないなと思い、誰かの役にたてばと筆をとります

Why LADR?

まずは LADR を調べ始めたきっかけについて

生産性向上をエンジニア組織としての１つの目標と置いている中で、「良いシステム資産を構成するものとは何だろうか？」と言う問いがあり、発散していく中で以下のような意見が出てきました

長く運用する前提を考えると
システム資産には積み重なってきた理由が存在している（はず）
なぜそれが、そう存在しているのか？
not only システム的な理由 but 事業上の制約もあるだろう
それを理解できる状態にあることが、良いシステム資産に繋がるのではないか

ここから、長く運用する（事業拡大を目指す）前提でのエンジニア組織の生産性向上には、自組織のシステム資産特性を説明可能にすることが良い影響を持つと仮説を作りました

仮説を設定したはいいものの、はてさてそれを実現するためにはどんな工夫をすれば良いのか？うまくイメージを固めきれない中で、一人のエンジニアが LADR という概念を紹介してくれました

一定のフォーマットに則って技術的意思決定を記録するプロセスを確立することで、自組織のシステム資産特性を説明可能に近づけることができる

この期待値を持てたことが決め手で、 LADR やろう！エンジニア組織の文化にしよう！本格的なアクションをする判断となりました

LADR を組織として運用するぞ！合意形成はできたわけですが、それだけでは前に進みません さぁ、一歩ずつ歩んでいきましょう

作る過程の話（フェーズ 1 ）

僕の現職であるツクルバには TechBoard というリードエンジニアによる組織体が存在しています、まずこのメンバーにて LADR というものを自組織で運用するために何をするべきか？トライアルを始めます

今までない文化を作っていくためには、着実に前進させることが何よりも大事だと考えていたため、コミュニケーションを進めるために、プロジェクトメンバーの役割と議論プロセスを最初にイメージしました

1. オーナー役とフィードバック役という形に分ける
2. オーナー役がプロジェクト進行とファシリテートを行う
3. オーナー役はベースとなる思考や論点や指針を持論ベースでドキュメント化して事前共有
4. フィードバック役は MTG までに読み込み事前コメントをいれる
5. MTG ではコメントされた内容について議論を加えて合意形成と NextAction を作る場とする

これを前提に TechBoard での LADR トライアルがスタートしました

続いてはアクションしていった順に少しだらっとなりますが、思考過程を理解してもらう意味で文章を作って行きます

LADR 運用トライアルの全体像整理

何はともあれ、ゴール設定とそこへのチェックポイントがなくてはプロジェクトは始められません

1. LADR 運用の合意形成
2. LADR 作成フローの整備
3. LADR 作成（一定数こなす）
4. LADR 評価
5. LADR プロセス振り返り

ざっくりでもやりたいことと順序イメージを共有するところから始めます、アクションしていく中でブラッシュアップしていくことで全体像を合意、LADR 自体はやろうと合意形成済みなので早速上記ステップにおける 2 の議論へと進んでいきます

LADR 作成フローの整備

ベースとなる思考や論点や指針の持ち込み

1. 意思決定をしたい技術を GitHub issue として作成する / by all engineer
2. TechBoard メンバーと起案者にて issue を協議 => 判断 / by tech board and issue author
3. 採用・不採用に関わらず、協議内容を持って LADR を作成し issue を close / by issue author

フィードバック

• 大きな違和感はないことメンバーから言葉をもらう（参加メンバーが違和感ないという事実をすり合わせたのが大事）

合意形成

• GitHub に LADR 専用 repo を作成する
• issue 管理と record 管理を兼ねる
• 起案 ➡︎ 協議 ➡︎ 記録 のフェーズと担当者

LADR 自体を各々事前調査していた ので、全員のイメージが一定近しいものだったから、スムーズだったと振り返ります

LADR 作成

ベースとなる思考や論点や指針の持ち込み

GraphQL をテーマに issue を実際に事前作成してみた結果、手を動かしたことで人によってメリデメの書き方は多様になりそうだと実感（以下のようなのを書いていった中で筆が止まった）

1. ユーザーエクスペリエンスへの影響
    - 処理速度（表示/インストール etc）
    - UI/UX（アニメーション/レイアウト要件 etc）
2. デベロッパーエスクペリエンスへの影響
     - デリバリー
     - 開発効率（デリバリーと同義か？）

具体的には一定の基準となる情報や判断材料となる情報を決めないと、LADR の協議に持っていく情報精度が自己満足の範囲を超えていない、この時点で issue 作成の深掘りをやめ TechBoard に持ち込む

フィードバック

• メリデメの書き方は決まっていたほうが書きやすいが、初期に決められるんだろうか？とは感じている
• メリデメという括りというか、意思決定者が意思決定できるための材料となる情報が盛り込まれていればOKでは？
• もし過不足あれば issue 上でやりとりもできるはず、まずは具体で進んでいこう
• タイムスパンのグラデーションがある気がしている
  • 未来に対する技術的意思決定に対して、最低限検討したい項目
  • 直近に対する技術的意思決定に対して、最低限検討したい項目
  • LADR 導入に対する想いとして、未来に対する意思決定も含まれているのでそこを意識できるような運用にしたい

合意形成

• 意思決定に必要な情報を LADR issue に盛り込むこと
• ガチガチに決めずに、走りながら深掘りする

意思決定に必要な情報を LADR issue に盛り込む 、これが結果的に採用不採用の判断基準に繋がって行きました

運用上の懸念点を認識合わせ

次に、自分が運用するとしたら懸念に思うことは？というテーマで発散させ、それぞれに回答を作りながら前に進むことを決め、まずは問いをひたすら出していきました

• 皆にやってもらうにあたって意思決定をしたい技術の基準がないよね、どんな基準で issue にする？
• LADR があることによって、新規技術導入までタイムラグが生まれるのでは？（issue 化してすぐ協議できるとは限らない）
• 評価するタイミングはどうする？
• どの範囲、どのタイミングでLADRを書く？
  • 1 プロダクト導入するごとにLADRを書く？
  • 開発チームとして広く採用しようとしたタイミングで書く？
• Apple 等プラットフォーマーが推奨する技術は採用しない選択肢が生まれにくいが、意思決定として残す？

これは 実際に運用するタイミングで自分たちが迷わなくなること、よくある疑問点への Q&A にもなること、二つの効果を発揮してくれます

洗い出した懸念点と、意思決定に必要な情報に答えを出すことで、LADR issue 作成が可能な状態になるとし、以降はそれを議論していきます

技術的な意思決定をするための情報を議論

Q1. 意思決定できるための材料となる情報にどんなことを求める？

• 客観性と妥当性を判断したい、それをできるだけの情報を求める
• 採用することで何を解決することを期待しているのか？
• 課題に対する妥当性の観点での情報
• 保守容易性の観点での情報

Q2. フォーマットで情報をある程度引き出せるようにする？やりとりで情報を引き出せるようにする？

• 大きい観点でのフォーマット（保守容易性を判断できる情報だしてねとか）と、リファレンスとしてサンプルの何かがあれば、それを模倣してもらえるのではないか
• 大きめのアンケートフォームみたいになるのは嫌だ

合意形成

• 妥当性と客観性を判断基準とする
  • 妥当性を判断できるのは、起案者と同一専門職である
  • 客観性を判断するのは、起案者と異なる専門職とする
• LADR issue テンプレートを作成する
  • 判断に必要な土台となる情報を引き出すため、指針となる項目を最低限記載する

フェーズ 1 の決定項

それなりの必要要素が集まってきたので、一度情報を収束させます

LADR 運用フロー α 版

1. 意思決定をしたい技術を GitHub issue として作成する / by all engineer
2. TechBoard メンバーと起案者にて issue を協議 => 判断 / by tech board and issue author
3. 採用・不採用に関わらず、協議内容を持って LADR を作成し issue を close / by issue author
4. 定期（Q毎、半期毎）で LADR 棚卸し（評価）する / by tech board and issue author

判断基準

1. 取り扱う対象と専門性が同じメンバーによる妥当性判断をする
2. 取り扱う対象と専門性の異なるメンバーによる客観性判断をする

上記2点の基準を持って、技術的意思決定をするものとする

LADR 管理

• GitHub に LADR 専用 repo を作成、issue 管理と record 管理を兼ねて運用する

LADR issue テンプレートの詳細度

• 判断に必要な土台となる情報を引き出すため、指針となる項目を記載する

Next Action

1. 議論しきれていない運用上の懸念点について認識合わせ
2. 1を完了させて、LADR issue 作成と issue 協議を実行フェーズに移行させる

終わりに

フェーズ 1 だけでも盛りだくさんで、全く書ききれませんでした！続きのコンテンツは以下のようなものです

• 運用上の懸念点を潰していく話
• OKR に LADR 関連指標を設定し、実行 = 評価にすることで初期の文化形成を動かした話
• 個別 LADR の評価フェーズの話
• LADR プロセス全体の振り返りの話

うぅ、part 3 くらいまでいきそうだが...、と一抹の不安を覚えますが今回はこの辺で

次回は、LADR の具体例もご紹介しつつ続きを話せればと思います

chao!!👋

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

前置き

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

思考した結果、チームのアウトプットを最大化することを目指し、構造化・モニタリング・レバレッジ期待値の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. システム資産に変化を与え続けたい前提に立った時に、打ち手の影響度と必要となる生産力によってレバレッジ期待値を判断する

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

おしまい

エンジニア組織の認知拡大をリードするために考えたこと

前置き

エンジニア向け自社イベントを企画したことはありますか？

一般的なイベント企画の動機として浮かぶのは、次のようなものでしょうか。

• 知見の共有
• 発表機会の提供
• コミュニテイ発展への貢献

自分が自社イベントを企画する際にも、上述したことを考えていました。

しかし時間をかけて考えていくと、それらは建前だと気付きます。

自分がエンジニアとして自社イベントを企画する本心は、採用と探究心を満たすことの2つでした。

加えて純粋な知識探究のためなら、会社の名前をつけたイベントにしなくても良いです。

以上のことから、結局は自分が自社イベントをする目的は採用。 すごくシンプルになった。

というところで本題へ。

今回は、認知拡大に対するアクションと採用をどのように線にして考えるのか？を整理した話です。

認知拡大ワークフローの考え方

大目的

エンジニア組織の採用へ繋げる認知拡大を目的とする

3つの重点項目

1. 採用をフェーズで理解する
2. 対象スコープでのアクションを定義する
3. アクションの評価方法を設計する

個人で闇雲に外部向けアクションを行っても、継続性が生まれにくいです。
組織的に動けるフレームにどう落とし込むか？誰をどれくらい巻き込むか？そんな観点を大事にして考えていきます。

1. 採用をフェーズで理解する

図1. 採用のステップ / リクルートメント・マーケティング入門：あたらしい採用の常識 / Recruitment Marketing 101 より引用

採用フローは、引用させて頂いた図1のような4つのブロック、8つフェーズで捉えることができます。

これをベースに、 自分たちがするアクションの前後関係を意識し、対象とするスコープはどこまでなのか？ の考え方を共通認識にしていきます。

具体的には、自分たちは図1における Lead Generation のブロックをスコープ とし、前後関係として後ろに Lead Nurturing のアクションが続いていくと理解しました。

2. 対象スコープでのアクションを定義する

自分たちは1で言葉にした、図1における Lead Generation のブロックをスコープとしました。

具体的なアクションとしては、以下を設定します（よく言われているようなものに落ち着いた）

• イベント登壇
• イベント会場提供
• イベントスポンサード
• イベント開催
• ブログ運用
• SNS活動
• OSS貢献
• 書籍類の執筆

個人だけでできること、チームや会社を巻き込んでできること、社外も巻き込んでできること、様々な粒度のアクションリストですね。

3. アクションの評価方法を設計する

1で前後関係を意識することを言葉にしました、これを評価を考える時の観点に利用します。

Lead Generation と Lead Nurthuring の境目にあるアクションを目標に置き、そこに繋がる中間点や、出発点となる2であげたアクションリストを繋いでいくことで、図2ができあがります。

図2. アクションと目標を繋ぐ

この図より、以下の2点が全アクションに対する到達点の指標であるとイメージできました。

1. エンジニア募集への反響
2. エンジニアのリファラル紹介数

会社としてブログをするのも、イベントを開催するのも、外部登壇するのも、認知拡大を目的とした場合にはこの2つにいかに影響を与えられたか？なんですね。

また、到達点だけでなく中間点や出発点のアクションも定点観測することで、改善サイクルを細かく回せるでしょう。

まとめ

エンジニア組織の認知拡大アクションには、多くのアプローチがあります。

闇雲にやっても継続せずに、アクションをしなくちゃ！という気持ちすら生まれてしまうのをよく見てきました。

そこで改めて採用構造理解と評価手法を考えることで、個々のアクションを線として捉え、目的につながる形が見えるようにしました。

認知拡大には継続と改善サイクルが必要だから、しっかりと考えていきたいですね。

これはあくまで自分の状況による一例ですが、戦略を練るための道筋をつくれたことが成果だなと考えています。

そんなところで、今回はおしまいです。

お知らせ

自分がメイン担当として企画したイベントが来月開催されます。

テックリードに興味のある人、このブログ内容のようなエンジニア採用へのアクションを語りたい人👇のイベントでお話しましょう！

tkrb-studios.connpass.com

意識的に成長実感を得るために必要なこと

前置き

皆さんは、どんな時に成長を感じるでしょうか？

近くで見ていた人のできることが増えたタイミングで

「成長しましたね」と伝えたことがあります

その時に次の様な言葉が返ってきました

A さん		まだまだ、あの人と比べると自分は何もできていないんです、成長なんてしたなんて言えないですよ...
B さん		昨日の自分よりまた１つできることが増えた、毎日のように成長している気分ですよ！

何故こんなにも解釈は違うのでしょうか？

今回は言葉の裏にある事実を考察する過程から、意識的に成長実感を得るために必要なことを探っていきたいと思います

言葉の裏にある事実を考えると

前置きの具体例から、事実を拾いましょう

対象者	事実
A さん ＆ B さん	経験を積み、できることが増えた
A さん	自分と他者を比較している
B さん	自分の過去と比較している

整理してみたところ A さんと B さんでは、成長を判断するための事実が異なることに気づきました

異なる点である比較する対象とは、自分の変化量をどう見るかの現れであり

つまりはその人の重要視している評価視点なのではないか？

次は評価視点という観点で、もう少し深掘りしていきましょう

評価視点について

今回は、変化量と達成時の実感値を軸にして考えていきます

自分の過去と比較した評価視点の場合

• 変化量を累積値で評価している
• 変化量にかかる変数が自分だけなのでコントロールしやすい
• 変化量は停滞か増加になる

なんだかポジティブな実感を長く得られそうに見えます

なんだ最高じゃないか！これでいいじゃん！...と上手くはいかず

得てして、達成時の実感値が低くなります

なぜか？

僕はこれを、メタ認知能力が実感値に影響しているからと考えています

自分自身の蓄積した事実を詳細に認識し、正当に評価することは能力に依存していて

変化量を認識できる能力を育てていないと、この評価視点とは上手く付き合えないのです

自分と他者を比較した評価視点の場合

• 変化量を他者との差分で評価している
• 変化量にかかる変数に相手も含まれるので、コントロールしにくい
• 変化量が減少する（差が大きくなる）ことがある

アンコントローラブルで、減少する可能性も含んでおり、ポジティブな実感を長く得られはしなそうです

ではなぜこの評価を重要視する人がいるのか？

こちらは、達成時の実感値がある程度高くなります

なぜか？

僕はこれを、適度な競争心や闘争心が実感値に影響しているからと考えています

優劣という認識しやすい尺度があることで、評価時に判断がしやすく実感値が高まりやすい

しかし多面的に比較できる能力を育てていないと、総合比較をして劣っていると判断しがちになり

この評価視点とは上手く付き合えないのです

まとめ

2つの事例から考えてきて、以下のことが考察できました

1. 人にはそれぞれ重要視している評価視点というものがある
2. 評価視点には、それぞれ上手く付き合うための能力が存在する

ここから、意識的に成長実感を得るためには

専門的な経験を積み重ねていくだけでは足りず、自分の重要視している評価視点を理解し、上手く付き合うための能力も合わせて育てる必要がある

終わりに

重要視している評価視点というのは、自分の欲求からくる素直なもの

評価するための能力は、自分自身だけでなく誰かへのフィードバックのためにも大事なもの

上手く付き合っていきたいですね

といったところで、今回はおしまい