なんとか仕事が立ちあがってきました

2025年1月から Engineering Office という組織が立ち上がります。自社における開発力の向上を目的とした各種の企画推進と、それらに付随する横断的な組織施策のプログラムマネジメントなどを一旦の業務管掌として定義しています。

先人の抽象度の高い命名にあやかった組織名ですが、社外の同名組織の事例によくある採用、育成、評価、広報などを直接担うことはなく、既存の専任チームとの連携を前提としています。

我々のスタンスとしては営利組織における攻めと守りの中庸を往くつもりで、組織の保守的な仕組み作り一辺倒ということはありません。ほか Engineering Office についてのもう少し具体的な取り組みの紹介は後日、社のテックブログに記事を掲載予定です。

ここでは6月入社以来、半年のふりかえりをば。

入社してから考えよう！

日本の既存産業、非 IT ビジネスで IT によるレバレッジをかける仕事への関心を近年あたためていたことが、会社選びにおける動機・きっかけになりました。

• ほんとうは開発系のポジションでお声がけがあった
• カジュアル面談後に判明する驚愕の事実「名古屋に開発系のポジションはない」
• 適したポジションが現状ないけど 入社してから考えよう 、で入社した

結構リスキーな転職だった気もしますが、現在のボス（副社長）や上司が、事業や組織について明け透けに話してくださったこともあって比較的心穏やかに決心することができました。

社内の観察と対話に時間をかけた

入社後は IT/IS 部というコーポレートITとセキュリティの部署の部付として、開発支援部 技術広報グループのお手伝いをするなどしながら社内のキャッチアップに励みました。社内ITに携わることはなく社内フリーランス状態です。

内製開発の会社として300名を超える規模の組織であり、既存の業務や体制も十分に確立しています。スタートアップで勢い良く突破と自己実現を図るのとは異なるものとして、社内の関係構築や観察に努めてきました。

並行して副社長との週次定例を入社直後から設定させてもらい、そこで事業や組織に対する考え方、求める人物像、既知の課題、未知の課題などについて会話を重ねさせてもらいました。そのうち3〜4ヶ月くらい経った頃から各種のリクエストをいただくようになって、あれよあれよと今に至ります。

引き続き走りながら考える

関わるビジネスの多様性もあり学ぶべきが尽きない状況であり、走りながら考えるという状況も脱するには至っていません。未だ社内フリーランスの延長線上にありますが、半年をかけて事業や組織に貢献するための取っかかりは得られた認識です。

実際のところ技術人事がどうとか、Web 開発がどうとかではない、アンラーンを求められる未経験領域の球も拾っているため悪戦苦闘しています。とはいえ自分のテーマとして根っこにあるのはダイナミック・ケイパビリティの実践と、そのためのチェンジマネジメントであることに変わりは無いので、引き続き励みたい所存です。

書けないタイプの剛速球も多くて、現実は上記文章のテンション以上に火がついています。ひぃ

KINTOテクノロジーズという会社について

ついでに KINTO テクノロジーズ（以下 KTC）について採用広告 (!) を兼ねて簡単に紹介しておきます。

トヨタのチャレンジに対する貢献

KTC は、トヨタグループ傘下にあるITサービスの内製開発子会社です。ソフトウェアやシステムの開発という点では、トヨタシステムズやトヨタコネクティッドなどの諸先輩方がいらっしゃいますが、我々は世間のIT事業会社が提供するような Web サービスやモバイルアプリの開発を主としています。

トヨタがモビリティ・カンパニーに変革していく中で、モビリティに関する多様な価値提供にチャレンジしていく動きをソフトウェア開発の面で支えています。

実は多様なサービスに関わっている

モビリティに関する多様な価値提供のチャレンジとして社名にも入っている KINTO を筆頭に、他にも多様なサービスに関わっています。会社のプロダクト紹介に多数掲載されていますが my route アプリや販売店のデジタルトランスフォーメーションのサポート（販売店DXプロジェクト）なども手がけています。

また KINTO も新車のサブスク（KINTO ONE）だけではなく、KINTO Unlimited や KINTO Factory、KINTO ONE 中古車など複数のサービスを展開しています。

Webサービス開発、IT事業会社の経験を活かせる

本稿執筆時点の会社紹介資料 によれば2024年11月1日時点で従業員数346人となっており、今後も採用を強化していく方針です。

求人の一覧をご覧いただくと分かる通り、Webサービス開発に求められる職能をほぼ全方位的に採用しています。私もそうですがIT事業会社の出身者にはとても入りやすい印象を持ってもらえると思います。

We're Hiring!

Engineering Office は表向きに求人をオープンしていませんが、自分のテーマや信念をもとに使命を開拓していくぞ！というフロンティアスピリッツ......もとい社内フリーランス耐性に自信のある奇特な方はウェルカムです。短期で体制が急拡大しているからこそ発展途上・過渡期における課題も多く、伸びしろしかありません。

• MUST
  • 自身のテーマや周囲の期待に従って使命/仕事を開拓できる
  • 世間のべき論から入らず、観察から方向性を導き出せる
  • 必要性さえあれば、何でもやりうる心意気がある
• WANT
  • 各々の立場や関係性を見極めて立ち回れる
  • 社内で未成熟な技術やナレッジのイネーブリングができる（専門家の場合）

もしご興味を持たれた方はオープンポジション求人や、個人的につながりのある方は各種 DM 等でお問い合わせください (・∋・)ﾉｼ

自己開示というか只の自己主張というか

ようはエクスキューズだとおもいます。(๑′ᴗ‵๑)

自認しているパーソナリティ

自認するに至っていない部分は都度ご対応ください。

自分の正しさに自信がないので口数が減ることがある

仕事がデキる人のように何とか振る舞いたいと願ってはいますが、自分の正当性にあまり自信があるタイプではありません。インポスター症候群のケがあることを自覚しており、逆に他者については過大評価しがちな傾向にもあります。過大評価というのも逆に失礼ですが。

他者の意見と異なる見解をもっている場合でも言葉にしなかったり、大きめのオブラートで包んだり、自分の中で保留にしたりします。他者の意見の背景には自分が知らない評価材料や視点があってそうしているものと深読みしがちで、限られた会話の時間でそれらを全て洗うことは困難なことが多いです。

困ったときは「沈黙は金」を装い始めるので「自分だったらどうするか」や「ここを具体的に指摘してほしい」みたいな会話上のディレクションがあるとちょっと喋りやすいので助かります。

アドリブで無理に喋るとコケるので、後から喋ることがある

前項を背景として会議や雑談におけるアドリブ力、瞬発力があまり高くありません。会話の後になってから思い返して見解が固まる（場合によっては変わる）傾向にある上、後から突然飛躍したように感じられることを言い出す可能性があります。

誤ったこと・変なことを言いたくない、恥を避ける感情も強めです。立食パーティーや初対面の雑談なども大変苦手です。これは初対面の人物と話したいことなんてそう滅多にない＆興味がない、という気質も大いにありますが...。そのわりに慣れた相手や、酒の入った2次会だとふつうに口が軽くなって、稀によく失言することもあります。偏った論説を楽しそうに語り始めたら殴ってください。

家を出るとき鍵をかけたか何度も確認することがある

このリスクを踏み抜くと大変に面倒くさいぞ、というポイントについては相当に慎重/臆病になります。諸々について心配しすぎないように努めてはいますが、要所についてはネガティブチェックが強めになる傾向にあります。心配事の9割は起こらないという研究もありますが、それはそれとしてリスクを見極めないと心配です。

一方で、コケてもあまり困らない物事（個人単位の失敗や停滞感などに気付いていても関心が低い）についてはチェックが甘くなりがちです。私の「どうぞどうぞ、お任せです」に不安を感じたときは懸念の表明や、レビュー/ネガティブチェックの要求を伝えてくれると助かります。

自称しているマネジメントの指向性

それっぽい用語に当てはめがちですが、どうかご寛恕ください。

羊飼い型リーダーシップ

一昔前はサーバント型リーダーシップに近いのかな？と思っていましたが、「そこまで個人に対する関心であったり、世話・支援だったりに興味は無いな？」とか「支援だけでなく一定のディレクションは必要だな？」と整理してからは放牧タイプとか優しい専制主義を自称していました。

羊飼い型リーダーシップとは、リーダーがメンバーの自主性を尊重しながら全体を見守り、必要に応じて方向性を示したり介入したりするスタイルを指します。羊飼いが群れを自由に草を食ませながらも危険から守り、目的地に導くように、このリーダーシップはメンバーが個々の能力を発揮する環境を整えつつ、組織全体が目標に向かって進むよう調整します。(written by GPT-4o)

ふとしたときに見かけた羊飼い型リーダーシップという放牧に近しい語彙を見てからは、このスタイルに近いのではないかと今は考えています。教科書的な羊飼いかは分からないものの今は羊飼いを自称しています。マイクロマネジメントはやれと言われてもやれない自信があります。

ダイナミック・ケイパビリティとチェンジマネジメント

近年は開発組織や人材領域における「変化と適応」を内心的なテーマにしています。これも後付け的にしっくりきた整理済みの考え方ですがダイナミック・ケイパビリティを参照するようになっています。

ダイナミック・ケイパビリティ（Dynamic Capability）とは、企業が変化する環境や市場の中で競争優位を維持するために、組織の資源や能力を継続的に再構築、適応、革新する力を指します。単なる既存の能力の活用ではなく、新たな状況に対応するための柔軟性や創造性が重要であり、これには外部環境を敏感に察知する力（感知）、適切な意思決定を行う力（捕捉）、そして組織の資産やプロセスを再構成する力（変革）が含まれます。(written by GPT-4o)

そして自らの職務の大部分は、これを組織全体の大きな動きとして実現するための緩やかなチェンジマネジメントに収束するものと考えています。とはいえ現実はそんな収まりの良い仕事ばかりではないので、目の前の問題解消、課題解決に一生懸命なつもりです。

過去の関連アウトプット

マネージャーとしてのプレイスタイルや過去のキャリアについては、下記の記事でもまとめています。

• マネージャーとしてのプレイスタイル
• 2022-2024年ごろのキャリアの振り返り
• 2012-2021年ごろのキャリアのふりかえり

個人的なモチベーション

大変にエゴイスティックなもので、自分が望ましいと思う方向にどれだけ寄せられたか、仕事の結果に自分が満足できたか（満足できたことは無い）という主観が全てです。社会的意義、事業貢献、お客様の笑顔、金銭報酬 etc ... といったものは当然スパイスにはなりえますが、それ自体が主になることはありません。

単に自分自身の理解、自己分析が未成熟なだけの可能性もありますが、少なくとも今のところそのようなスタンスです。金銭についてはあればあるほど困らないので大歓迎で、宝くじで数億円あたったら会社辞めそうなタイプです。宝くじ買わないけど。

16personalities

2025年1月時点では論理学者 (INTP-T)でした。過去、人事っぽいことをしている時期は擁護者、ソフトウェアエンジニアっぽいことをしている時期は巨匠に振れることもありました。16personalitiesに何らか納得できる方向けの参考程度に。

【緊急情報】16Persontalities性格診断テストを「MBTI®」だと思って受けられた方へ https://t.co/jyf5Crr5Uc

これはこれで商売大変そう & 16 personalities もそこまで真に受けて信じてる人いないでしョ、って言いたいけどこういうのは信じたい人が信じるから難しいわね

— あほむ@KINTOテクノロジーズ (@ahomu) June 14, 2023

間違いなく言えるのは、根っこの部分で斜に構えているタイプの人間であるということです。

この文章は適宜、加筆修正されることがあります

ます。

この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。

前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。

人的効率主義に対するアンチテーゼの補足編

安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する

開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そうでないときに効率だけでも良くしたいときだってある。

小手先の開発アクティビティ指標（人的行動量）をこねくり回しても意味がないという立場には些かの変化もないが、今回は「成果のためには効率も良くしたい、とはいえ数字だけ眺めても"頑張る"以外にどうしてよいか分からん」という気持ちを踏まえた記事としている。

※ 以下で可視化サービスと呼称するが少なくとも国内サービスは成果までトレースできる段階にない為、あくまで開発アクティビティ指標を可視化しているものという前提で記述する。

システムよりも個人に目がいくバイアスを自覚する

引き続き人的効率主義に警鐘を鳴らす話ではあるが、多くの可視化サービスが GitHub 由来の行動量や時間を中心に計測しているため、特にチームメンバー同士で画面を眺めていると「個人がどのように行動すれば短縮できるのか」という思考に引っ張られやすい。

• 開発アクティビティ指標の多くは人に起因する
• しかし、人のアクティビティには事情も余念も言い訳もある
• 個別の工程を雑に短縮することは無意味どころか有害たりえる
• 末端の数字だけ追っても有効打に繋がらず、可視化と行動の想起が噛み合わない

人の効率化は容易でない(※)が、システムやプロセスは効率化できる ので、個人の努力に閉じずチームや組織として効率的なシステムやフローを整備することによる効率向上は期待できる。もちろん個人・チームの単位でパッチサイズを小さくして影響範囲を限定し、早くレビューを回していこうといった基本的なプラクティスは当然に押さえているものとする。

※ 作業単位に分解されてシステムに組み込まれた業務体制であれば話は異なり作業や工程の標準化による恩恵が順当に考えられる。しかし今「開発生産性」に関心を持つソフトウェアエンジニア諸氏に係る本来の期待はそういう仕事ぶりではないと仮定している。科学的管理法が適用可能ならば、ソフトウェア文脈の開発生産性以前に「時間と金」で説明できる。

システムやプロセスを軸とした効率改善の選択肢4つ

「正面から成果に向き合えるタイミングばかりではないので、そうでないときに効率だけでも良くしたいことはある」を念頭に、チームや組織の立場で講じうる効率化の打ち手の類型を試みる。これらは必ずしも既製の可視化サービスが観測可能な情報とは限らない。

1. 段取りプロセスの改善

典型的に開発工程への影響が大きい段取りの関心としては、所謂「手戻り」を減らすためのプロセス改善が効果的と考えられる。意思決定や開発仕様の過度な曖昧さが忌避されがちだが、ユーザーや事業背景の理解が乏しいまま着手してしまう悪い意味でのフットワークの軽さも忌避されるべきだろう。

2. 習慣プロセスの改善

人起因の開発効率に近しいが「開発イシューの細分化 → パッチサイズ、プルリクエストの小型化 → レビュー負荷の低減、デリバリーサイクルの向上、影響範囲の限定・明瞭化」のようなプロセスと機序は期待しても良いと考えている。経験則もあるが、比較的副作用が出づらく汎用的なプラクティスと言える。個別具体においては他にも良い習慣はあるのだろう。
個人の努力ではなく習慣、プロセスに落とし込んでこそということは留意したい。

3. 足回りシステムの改善

ビルド、テスト、デプロイ等のフローをシステム的に改善、効率化することはソフトウェアエンジニアリングとしては優先的にアプローチしたい関心事であり、実際そのようにしているチームや組織は多いだろう。CI/CD をただ座して待つ開発者はいないにせよ、テンポの良さは確実に開発効率に影響を及ぼす。

いたずらに工程の処理時間が長いのは論外だが、例えばパッと出してパッと直すが許容されているフェーズにも関わらずリリースに1時間かかってしまうとすれば改善を講じるべきだ。一過性の開発者体験を言い訳にアジリティを犠牲にすることの正当性は (ほぼ) 無い。速い方が正義だ。

4. 作業システムの改善

日常的な割り込みや、定常的に発生する手作業（トイル）の自動化、システム化も優先的に取り組みたい。下手に都度の手間、時間が許容できてしまうと後回しになりやすいが、その積み重ねが奪っている時間は大きい。不具合調査や問い合わせ対応が頻発するのであれば、その原因をプロセスから摘み取る改善も視野にいれることになる。

総じて、段取り・習慣の改善はおおよそチームに託されやすいが、足回り・作業の改善は組織横軸でもアプローチできる。組織の規模が許すならば、頼れるはずの横軸を上手に使う発想も必要だ。目の前にある数字だけでなく、バリューチェーン全体をフラットに見渡す姿勢が重要だろう。

可視化サービスには行動変容の仕掛けを期待したい

システムやプロセスを作るソフトウェアエンジニアであればこそ、自分たちの開発活動も同様に改善できるはずである。指標の上下は今そこにあるシステムやプロセスの結果でしかない。数字を見て小手先の操作をするのではなく、大元の開発活動のシステムやプロセスに対して行動変容を起こさなければならない。

可視化サービスの立場としても、変動を眺めているだけでは開発生産性が改善しないのは百も承知であり「録れるログを全て録って、出せるログを全て出す」が取っかかりに必要だとしても本命は行動変容につながるインサイトの示唆ではないか。

現状の生産性可視化サービスに直接的な事業インパクトを求めるのは酷かもしれないが、もしインサイトの示唆によって導入チームの行動変容を正しく加速できるならば、それは事業インパクトへの先行指標として十分に有意義と思われる。

追記

本稿では（タイトルの割に）既存のシステムやプロセスをどう観察して現実的にアプローチするかまで掘り下げていない。少し思い返すと技術・プラクティスを起点にすると本来的なマトを見失うという話があり、考え方の取っ掛かりとして過去の同僚氏の資料を思い出すに至った。

自分は事情・背景をよく知っているという補正もあるが、今も通用する示唆があると思ったので参考までにご紹介させていただく次第。

この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。

効果・成果よりも効率を優先することは生産性か？

開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。

• 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する
• 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する
• 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする

それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。

などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論は次の段階に進んでしまったかもしれない。供養。

結論

安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。

チームの開発効率の向上を目的として開発アクティビティ指標の観察によって効率改善を試みることは生産工程の歯車に限り正しいが、チームに求められていることが価値創出であるにも関わらず開発効率を目的にしてしまうと変な方向にいってしまう
効率だけをいくら追っても効果や成果にアラインできない

— あほむ@KINTOテクノロジーズ (@ahomu) June 24, 2024

効率と効果と成果は異なる

昨今の開発生産性の指標と言われる多くは人間起因の行動量、時間を示す開発アクティビティ指標であることが少なくない。組織が求めている成果が売上やプロダクトKPIの達成などであれば、プロダクトに変更を加えてリリースするだけで「生産した」とは言えない。

「開発工程の効率」と「開発によって生じた効果」と「組織が得られた成果」は厳密に区別される。指標やスコアを上げたら何となく良いことだ、という認識で開発アクティビティ指標だけに執着するようでは効率の局所最適が行われるだけで本質的な生産には何ら影響を与えない可能性がある。

それどころか人間に起因する効率に過度な期待を寄せたコミュニケーションは、チームやメンバーを燃えつき症候群を誘引してしまいかねない。健全に効率を上げたいなら CI/CD の処理短縮や定型業務の自動化などに向き合って時間を増やす方が真っ当だろう。

効果と成果の確認を優先するべき

請け負い仕事を除いてソフトウェア開発の多くが、常に価値があると決まったものを生産できるわけではないため、時間あたりのアウトプットの多寡がアウトカムを保証しない。メソッドとパフォーマンスの側面からアウトプットをいくらか効率化しても、アウトカムに繋がらない生産が続けばそもそもの前提が誤っていることになる。

前向きには試行回数を増やすことを念頭にイテレーションの高速化を志向するのが現代のソフトウェア開発におけるユーティライゼーションだが、例えば「無駄なものを作らない」という意思決定の有無というユーティライゼーションがアウトカムの生産性に最も響くという可能性も大きい。 開発生産性の可視化サービスから何を見いだして何ができるのか

おにぎりを作ったら無限に売れるのであれば効率と成果の関連は強いと言えるが、おにぎりを作りすぎたら普通は売れ残るので効率以前の計画が必要である。過去のブログでも述べたが、いくら開発工程の回転数だけを上げたとしてもユーティライゼーション（計画や活用のうまさ加減）が及ばなければ意味がない。

多くの事業においても効率化の追求やリソースの投入は、それが成長のレバーになっていると確信できてから行うものだろう(※)。不確実性が高い中では開発工程が効果や成果につながっているかどうかと向き合うことが必要であり、効率はそれらと比べれば優先度が下がる。

※このフェーズであればソフトウェアによる自動化や定型化を経たアウトソースのほうが社内リソースを温存して効率的である可能性も観点として必要である

それでも開発効率を求めるべき状況はあるのか

価値探索フェーズにある事業やチームにおいて仮説検証の打席数を増やすために回転効率を高めることは一見すると正しそうでもある。一方でそのようなフェーズの開発者にかかっている期待の優先事項は開発効率だろうか？

開発チームとして未成熟（個々人の成熟度というよりもチームワークとしての成熟度）で人間起因の効率を最適化したい場合でも、やはり第一義としては効果・成果に目線を向けた上で取り組むべきだと考えられる。

未成熟なチームが手元の効率から追うことはあるかもしれない

習熟が進んでいない主体（チーム、メンバー）は「アウトプット」に多くの関心を払い、成熟した主体では「アウトカム」に多くの関心が自然と払われるようになる 開発生産性の可視化サービスから何を見いだして何ができるのか

以前の記事でも言及したとおり、そもそも開発を著しくスムーズに回せていないのであれば自分たちの開発が本当にスムーズになったと言えるのかを可視化するために開発アクティビティ指標で必要最低限の効率を見ることは有効な可能性がある。

その場合は Pull Request (ないしパッチサイズ) の単位を小さくする等の汎用的なプラクティスと、それらの実践に必要なチームインフラへの投資が考えられる。誤解を恐れずに言えば、ある程度の習熟をしたチームであれば汎用的なプラクティスで向上する程度の効率は一定満たしているので開発効率に強くフォーカスする必要はない。

※チームとして効率性の習熟にどれくらいの目線を持つかという要素もある。チーム内でいくら満足していても相対的に程度が低いことは常にありうることから当事者の意識にも左右される。順序を間違えない限り究極的には効果/成果のために効率は必要であり、どちらもやればい良い。

Four Keys は効率というよりパフォーマンスのヘルスチェック指標

DORA (DevOps Research and Assessment) の研究によって見出された Four Keys と呼ばれる（いた？）指標は State of DevOps Report 2023 においてソフトウェアデリバリーパフォーマンスを示す指標として次のように整理されている。

• 変更のリードタイム - コードの変更を commit してからデプロイするまでの時間
• デプロイの頻度 - 変更を本番環境に push する頻度
• 変更時の障害率 - デプロイにより障害が発生しすぐに対処する必要が生じる頻度
• デプロイ失敗時の復旧までの時間 - デプロイの失敗時に復旧にかかる時間

同様に組織パフォーマンス（利益等の実利）やチームパフォーマンス（コンディション）などが評価対象の尺度として並んでいる。年度によっては fifth metric として信頼性が入っていることもあったが直近は運用パフォーマンスとして扱われている。

これら Four Keys 相当の指標群は攻守のバランスがとれており、これまでの調査研究において組織パフォーマンスとのポジティブな関連性が示されている(※)。デリバリーパフォーマンス指標を運用パフォーマンス指標とあわせてトラッキングすること自体は開発活動のヘルスチェックとして意義があると考えられる。その場合も各指標を目標として扱うのは慎重であるべきだ。

※一方で「本当にそうなのか？」という話もある。LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report という記事では興味深い視点で Four Keys への疑義を論じていたので紹介したい。

コトに向き合う姿勢や環境を作るほうが大事では

近年の State of DevOps Report では組織パフォーマンスを高めるために、健全な組織文化やユーザー中心の開発を成すことの有効性が言及されており、それらはソフトウェアデリバリーパフォーマンスとも関連性が示されている。

• Culture in the 2022 State of DevOps report | Google Cloud Blog
• 2023 State of DevOps Report: Culture is everything | Google Cloud Blog

7 章「組織文化への投資なしには何事もうまくいかない」のモデル（2023 State of DevOps Reportより）

広範な組織文化はチーム単位においてアクショナブルではないかもしれないが、ユーザー中心の開発推進はチーム単位でも取り組める関心事だ。ユーザーにより早く、より良い品質でプロダクトや事業の価値を提供するために結果としてデリバリパフォーマンスも高まるという機序は感覚的にも理解できる。

Four Keys 相当の指標が芳しく無いとき下手に開発効率だけにフォーカスしてしまうよりは、まずはチームがコトに向かえる姿勢や環境整備、チームワークの獲得を志向することから入るほうが望ましいのではないだろうか。

効率から上げようとするな、効果・成果を上げろ

普段から全体の効率を高めることは至極あたりまえの取り組みだが、開発生産性を可視化する中で特に人間の行動に起因した効率性を過度に突き詰めることは危険という立場である。本当に効率がボトルネックならば局所最適を考えざるをえない可能性を否定しきれないが、基本的には効果・成果を念頭に向き合うべきだろう。

個人的には、生産性可視化サービスはシンプルに Four Keys とビルドやテストの所要時間が見えているくらいで良い。人間起因の些末なアクティビティ指標のほとんどがノイズであり、スコアで抽象化して曖昧に高低を示してしまうことも余念がすぎると感じている。純粋なアウトプット量や速度だけを観測したいベンダーコントロール用途等は別文脈・別製品として考えたい。

限られた開発リソースが意図した方向に向かえているか (意図した投資が成されているか) のほうが関心事としては真っ当に感じられるため、雑多な指標を出すよりは How to balance engineering investments — and not just keep the lights on? | Swarmia にあるような可視化を今後期待したい。

変化を起こす人

自分が勤めている間にかぎっては身の回りの変化を特に焦らなくても安定した生活が送れる...、などという特異な状況下を除けば、あらゆる組織、チーム、個人にとって「変化」することは前提と言ってもよい基本動作である。

変化の必要性は言うまでもなく高い

周囲の環境や状況が変化していく中で生き残るためには、自分たちも新しいかたちに変化することでしか適応できない。地球環境や地政学まで話を大きくしなくても、ユーザーの嗜好変化や新技術の勃興など多少の予測はできても基本的にはアンコトローラブルものばかりである。

文明社会の成熟に伴って組織のトップに求められる資質が変革者ではなく統治者としての側面が強くなる中で、チームや個人の側に変化の期待が寄っているという風潮（ボトムアップの重用）はあるのかもしれない。

自分を起点とした変化があるか

人材に対して期待する変化の起こりは、状況に流された結果の変化や、衆愚的な合意形成による変化ではない。他責思考や自分でケツを持とうとしない消極的態度は、努めて抑え込まなければならない。

期待されているのは、自分や自分たちを主語として意思と目的をもって変化を起こす行動だ。中身を評価するためには課題定義の精度や効果の大小も考慮しなければならないが、変化を起こせるだけでも、起こせない人材と比べれば圧倒的に価値がある。

変化の納得を広く持てるか

現実的には全員が常に変革者である必要はない。自分が変化の前面に立つこともあれば、変化を周囲から支えることもあるだろう。リーダーシップとフォロワーシップを柔軟に切り替え、あらゆる変化に対する納得を自律的に獲得できることも期待される。

そのようなスタンスで活動を通じて周囲との協力や見返りの交換を続けていると、必然的に影響力を獲得するようになる。リーダーシップとフォロワーシップの言い換えとして「変化を起こす主体性」+「納得を広く持つ柔軟性」は重用される素養のひとつだろう。

影響力の行使

変化を起こすためには周囲に影響力を発揮する必要がある。特に上手に立ち回っている人は、同じく変化を起こせる他の人と持ちつ持たれつの関係を築くことで持続的に影響力を高め続けている。

広く周りの行動を変える

変化を起こす影響力というのは、とどのつまり周りの人々の行動を変える力である。上司部下のようにわかりやすい関係性がない相手を動かす力でもある。変化を起こすためには必要があれば上司だろうと、他部門だろうと、経営だろうと、同僚だろうとアプローチしなくてはならない。

何もしなくても皆が何となく従ってくれる、付いて来てくれるというものだけではない。個別具体を持って相手の立場やコンテキストを考慮し、対応していくことが求められる。

貸し借りによって増幅する

これまで関わってきた人々や自身の体験を鑑みても、自明な話ではあるが最も単純な関係に協力の貸し借りがある。誰かが変化を起こしたいときに協力を貸し付けて、自分が変化を起こしたいときに借りを返してもらう。互いに貸し借りが滞りなく成立するようであれば信用が出来て、そういう関係が増えれば自分の影響力の総量が増える。

貸し借りというと生臭くはあるが、同じ志によって支えられた共同体だけでは外側に変化を起こすことは難しい。貸し借りや交換関係を前提に物事や人との関係性を捉えておいたほうが汎用的だろう。

特別なものではないが、意図しなければ育たない

おそらく「変化のための影響力」について、会社によってはコンピテンシーや職能の評価基準に組み込んでいることもあるだろう。個人的によく使うダイナミックケイパビリティの文脈においても変化、変革の類は常に大きい関心事である。誰かを評価したり期待したりするときにも、変化を求める姿勢や影響力につながる振る舞いはよく見てきた。

一方でこのような振る舞いを各位が実現するためには、抑圧的でなく、効力感があり、適度に余裕のある環境とマインドセットを必要とする。組織が変革を志向するためには、人材が変革を志向できるような組織に変革するという卵鶏のような話がある。

この記事に書いた内容の続きとして、硬直化の傾向があるIT系の開発組織を念頭にどのような観点を持って環境を整備していくことが、変革を志向できる人材の奮起に重要かを続く記事（他の記事を挟む可能性は非常に高い）でまとめてみたい。

※ なんだかビジネス系の自己啓発書みたいなタイトルと内容になっちゃったゾ

心機一転がんばります

車のサブスクを提供する KINTO やトヨタのモビリティビジネスのITを支える内製開発部隊である KINTOテクノロジーズ株式会社に6月1日付で入社しました。

通算4社目

ついに転職回数も3回を迎えて通算4社目に至りました。これまで経験した会社いずれとも異なった環境で、良い意味でギャップと新鮮さを味わいながら社内をキャッチアップしているところです。:)

KINTOテクノロジーズという名前とは裏腹に組織全体としては KINTO 以外にもさまざまなモビリティビジネスに関わっており、さらに独自のチャレンジの機会もあってやれることが盛りだくさんの気配です。

KINTOテクノロジーズ株式会社に興味がある/よくわからないけど話を聞いてみたい等があれば @ahomu か任意の連絡手段でお気軽にコンタクトください。

入社したてですので語りはそこそこに取り急ぎのご報告でした。

みなさま、今後ともよろしくお願いいたします。

目次

これまでに培われたスタイルの棚卸し

先日の記事 では直近2年間に携わってきたアクションを延々と書き連ねましたが、今回は直近2年とそれ以前の経験によって培われた自分自身のプレイスタイルを書き綴ります。

経験してきた技術組織のマネジメント

おおよそ次のような環境でマネジメントや、それに類する業務に携わってきました。

• メディア事業全体を横断するWeb フロントエンド人材、技術に関する取り組み
• 50人規模のエンジニアリングチームのマネージャ
• 400人規模のエンジニア組織の技術人事 w/人事、各エンジニアリングマネージャ
• 40〜50人規模のスタートアップのボードメンバー VPoE

さかのぼると入社からしばらくして30人弱の評価者を突如ぶん投げられた記憶もありますが、マネジメントというよりお役目だったので割愛･･･。

マネージャーとしてのスタイル

根底にあるのは凝り性でありつつ、飽き性であるということ。

進むということは変化するということ

特定の目的に向けて進むためには、大なり小なり変化が必要です。誰かが変えたい、変えるべきと思ったら何でも変えて良いというスタンスであり、変化を恐れずっと同じ場所に留まっていてはその先にある本当に重要な変化に触れることすら難しくなります。

ダイナミック・ケイパビリティは私の考え方と相性が良く、周りの環境変化に適応し続けるため自らをも変革し続けられるケイパビリティを備えた組織開発、チームづくりがマネージャーとしての重要なテーマです。

牧羊型リーダーシップ

変化が生み出される土壌を作るというスタンスを前提として、その土壌から生み出される変化を育て上げ、結実させるための支援やフォロワーシップの発揮を手段的に好みます。自ら放牧と揶揄することすらありますが、各所から自発的に生み出される変化による効果の最大化を念頭に置きます。

一方、ボトムアップ的なアプローチだけでは経営や組織の大局観において大きな的（まと）を定めたり、狙ったりすることは難しい傾向にあります。ボトムアップに頼り切らないためのディレクションとして、中長期における技術組織としての統率や戦略、方針の言語化は欠かさず行うようにしており、牧羊型リーダーシップを自称することがあります。

マネージャーとして実現すべき抽象

優しい専制主義を構成する自身のコミットメント。

透明性を高く保ち変化を実感できるようにすること

自律的な変化を演出するためには、変化の必要性や内容を検討するために十分な情報が組織内に流通していることが不可欠です。曰く、情報の透明性を高く保つことが該当します。

情報の透明性は、階層の上下間における情報の非対称性に対する是正だけを指すものではありません。横の組織間や横のチーム間における透明性も必要です。マネジメント一般において時には「余計な情報を入れずに専念させたい」という要請もありえますが、私自身はあまり選ばない選択肢であり、そのようにすべき時はその旨をフェアに宣言します。

チャレンジや成長の機会をつくり続けること

エンゲージメント観点において組織の硬直化は、個人の成長実感の鈍化に直結します。組織における有形無形の変化によって結果的にもたらされる副次効果とも言えますが、組織の中に常に新しいチャレンジや成長の機会があるように努めます。

変化を担うのは常に人です。その人にとって「ある変化」がどのようなものであるのかを考え、「ある変化」においてどのような人を結び付けることができるのかを重要視します。そのような変化の中における個人のチャレンジを発見することが成長機会の創出に結びつきます。

注力すべきを指し示すこと

大局観を担うマネージャーの責任とも言えますが、組織として実現すべき的（まと）を示し、期待される変化の方向性を指し示すことはハンズオンで取り組むべき重要な関心事です。注力すべきに十全なリソースを投下できているかどうかは物事の成否を左右します。

方向性を示し変化を統率するということは、マネージャーとしての責任分界を自認し影響力を行使するということです。影響力を発揮するためにはメンバーの納得とフォロワーシップを引き出す必要があり、その用途においても前述の透明性と成長機会が効果的に作用すると期待しています。

マネージャーとしてよく使う手法

個人的なお気持ちを支えるやや人事っぽいメソドロジー。

土着のカルチャーを最大化するための仕組み

ここまで述べたような自分の中の基本戦型はありますが、環境や目標に応じて最適な仕組みや制度の具体は異なります。最適な仕組みや制度を導き出すための土着の優れたカルチャーを発見することが重要です。

カルチャーは創る物であると同時に発見するものでもあります。0 -> 1 を除けば、それまで組織成果の再現性を担ってきていた文化が必ず存在します。優れたカルチャーを発見してすくい取り、それを最大化できる仕組みや制度を勘案しようとします。

8:2の法則、縁の下の力持ちと推進力

パレートの法則は組織にも一見して適用されます。どれだけ優秀な人材が揃っていても活躍していると特筆できる人材は2割程度に収まる傾向にあります。

よく言われる2割の「活躍」の多くは組織における推進力です。私は残りの8割が活躍していないのではなく縁の下の力持ちとして「活躍」していると捉えています。8割がベースラインを支えているからこそ2割の推進力が物事を実現できます。個々人レベルでみると、長い期間を推進力として駆け続けられる人材は稀です。前衛と後衛は常に入れ替わる可能性があることを念頭に、個々の成長とプロフェッショナリズムを求めます。

ピープルマネジメントはストーリーが大事

経営や組織における必要性、合理性で先に結論がでているとしても、そこにどれだけのストーリーを見いだせるかによってマネジメントの質と価値が変わります。

個々人にとっての必然性を整え、「本人の成長」「周りへの好影響」といった期待を丁寧に見つけ出して言語化し、周知していくことでアクションの意味や効果が大きく変わります。特に人材の適材適所施策において顕著ですが、ストーリー構築の成否は当事者はもちろん意思決定者にとってもひとつの基準たり得ます。

インクルーシブとボトムアップの重用

自律的な変化を重んじるという個人的なスタイルもあって、インクルーシブやボトムアップ的なアポローチを重用します。インクルーシブに意思決定や運営にメンバーを巻き込むことでより良い結果を求めたり、ボトムアップにあがってきたアイディアへのエンパワーを優先したりします。

これらによってもたらされるのは組織の「自分ごと化」であり「組織のお客様」を減らすための方策でもあります。これまで述べた内容のそれぞれと相互に作用することで、自律性や主体性の発露、エンゲージメントと業務パフォーマンスの向上に結びつきます。

これまでとこれから

本稿の内容からもお察しのとおり、これまでマネージャーとしての私にとっての主戦場は技術組織開発とピープルマネジメントです。過去の経験的に HRBP 色が強めなことに加え、開発者として横軸の技術マネジメントに携わってきた為そういう施策も立案や支援も得意とするところです。

一方あまり経験として強くないのはプロダクトマネジメントやプロジェクトマネジメントと言った地上戦の領域です。世間的なエンジニアリングマネージャーにしばしば求められる要素でもあります。ただ自分で言うのも非常に業腹ですが、ハンズオンでは「突撃」「停まれ」しか命令コマンドをもたない思考回路を自覚するところであり、これらはもっと理性的な各位に委ねて自身は統率や戦略に寄った役をしてきたように思います。

このような役回りが求められるフェーズは限られますし、場合によっては贅沢を言ってられないことも多々あります。今もたまの特攻役ならやぶさかでなく従事することもありますが、マネジメント系で証明済みの強みは組織開発寄りかなと。

これからの話としては、プレイヤーとしての特攻スタンスからは逃れられる気がしないので引き続き理性的な各位に託しつつ、私自身は経営と一緒に組織や技術を育てていくような仕事を引き続きやっていけるとバリューを発揮できるのではないかと思うところでございます。

目次

開発生産性を掘り下げるサービスたち

開発に関わるインテリジェンスを提供する SaaS には国内では私が勤める overflow 社の Offers MGR（オファーズマネージャー）や Findy 社の Findy Team+ 、海外では Jellyfish、Swarmia などのプレイヤーが存在している。

国内では特に「開発生産性」という業界キャンペーンの文脈で持ち出されることが多く、チーム内のアクティビティを何らか可視化するサービスカテゴリーである。また国外勢は数歩踏み込んでリソース配分や費用効果に迫ろうとする機能も提供している。大まかには同じカテゴリーだが細部ではプレイヤーごとの考え方に差異が見られて興味深い。

以下、当時の社内勉強会資料から一部抜粋しつつ話を進める。

生産性 = 産出量 / 投入量

開発生産性について論じる既存の記事の多くでソフトウェア開発においても物的生産性と付加価値生産性を分ける考え方が紹介されている。案外日本語のほうが耳に慣れないので、アウトプット（出力）およびアウトカム（成果）と捉えても良いだろう。

• 生産性（労働生産性） | 用語集 | 株式会社 日本能率協会コンサルティング
• エンジニアの生産性を高めるために必要な4つの指標

生産性が投下量に対する産出量であるという前提に付け加えると、習熟が進んでいない主体（チーム、メンバー）は「アウトプット」に多くの関心を払い、成熟した主体では「アウトカム」に多くの関心が自然と払われるようになるということだ。

生産性を向上させる3側面による整理

基本的な考え方の出発点として、おそらく従来的な製造業を念頭に置いて書かれたと思われる生産性向上の3側面という Web ページから分類を拝借して整理を試みる。

①メソッド（生産方式や業務処理方法）

①メソッド面（M面）とは、現在の標準作業方法を改善し、より良い方法を追及していく取り組みである。たとえば、現在5人で生産している作業を、作業方法の工夫や治具の工夫などによって、3人で作業できるようになるというものである 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング

ソフトウェアエンジニアリングにおいてはチームレベルの業務プロセスや技術利用に当てはめることができそうであり、アウトプットの向上に係る側面と考えられる。

チームワークを見直したり、作業効率が高くなる技術を導入したりなど、開発者がいわゆる開発生産性にアプローチするときはこの部分に伸び代を見いだすことが多いのではないだろうか。

②パフォーマンス（能率や業務実施効率）

②パフォーマンス面（P面）とは、標準作業方法を時間に置き換えた標準時間の達成度を改善し、高いレベルで維持していく取り組みである。たとえば、微小な作業中断の改善や標準作業方法の訓練によって、標準時間の達成度100％を超える上手い作業者に近づける取組で、現場監督者の力量が問われる項目である。また、達成度を常にモニターできる測定システムも重要である。 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング

ソフトウェアエンジニアリングにおいては個人レベルの作業効率に当てはめることができそうであり、アウトプットの向上に係る側面と考えられる。

チームとして生産方式や業務の標準化、環境の整備を前提としつつもソフトウェア開発は依然として工業化されていない領域であり個人レベルの作業効率を高める手段は限られる。寄り道せず最短でコーディングをする装置たれという文脈では今後 AI への置き換えのほうが積極的に進むだろう。

古典的な大規模開発であれば、それ自体の効率性の是非はさておきモジュールごとに定められた仕様書を元に決められた手順で生産するという形が成り立つこともあるだろうが適用範囲は限られそうだ。

③ユーティライゼーション（計画や活用のうまさ加減）

③ユーティライゼーション面（U面）とは、就業時間中に作業ができない状態を改善していく取り組みである。たとえば、仕事の負荷が少ない日は別の職場の応援に行かせる、取り付ける部品の不具合で作業がストップすることを事前に防ぐ、品種切り替えや段取り替えの時間をできるだけ短くするなどの取り組みが必要となる。 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング

ソフトウェアエンジニアリングにおいては組織または上流工程レベルの計画、意思決定に当てはめることができそうだ。

請け負い仕事を除いてソフトウェア開発の多くが、常に価値があると決まったものを生産できるわけではないため、時間あたりのアウトプットの多寡がアウトカムを保証しない。メソッドとパフォーマンスの側面からアウトプットをいくらか効率化しても、アウトカムに繋がらない生産が続けばそもそもの前提が誤っていることになる。

※ アウトプットの多寡がアウトカムを保証しない時点で「お前らが言っている生産性とは一体何なんだ」という声もある。ごもっともだがアウトプットなしにアウトカムも無いので幾ばくかの相関は期待したい。

前向きには試行回数を増やすことを念頭にイテレーションの高速化を志向するのが現代のソフトウェア開発におけるユーティライゼーションだが、例えば「無駄なものを作らない」という意思決定の有無というユーティライゼーションがアウトカムの生産性に最も響くという可能性も大きい。

(余談) SPACE フレームワークについて

The SPACE of Developer Productivity - ACM Queue で示された SPACE フレームワークというものがあって、生産性の観測にはより多角的な視点が必要という話がある。これには「生産性に関わる開発アクティビティの観測」だけでなく「生産性の高い環境を持続させるための観測」が含まれる。

後者は定性的にならざるをえない部分が大きく、定性アンケートや組織・チームのコンディションダッシュボードの観点としては優れているかもしれないが直接的な生産性の議論に営みの持続可能性を混ぜると話が拡がりすぎるため今回は割愛する。

生産性関連データの可視化で何を見いだせるのか

ここまでアウトプットとアウトカムの生産性視点と、メソッドとパフォーマンス、ユーティライゼーションの側面を整理してきた。そもそも我々は生産性の可視化に何を期待しているのだろうか。

アウトカムの厳密な可視化は難しい

生産性の可視化においてアウトプットに連なるアクティビティの可視化は容易だが、アウトプットの結果がアウトカムに繋がったかを解像度高く測定するのはサービスとしても容易ではない。評価のリアルタイム性を鑑みると実際的なアウトカムの代用として、何らかの期待値スコアを用いることになるだろう。開発部門内の責任の分解点によるが評価指標としてもそれほどズレないはずだ。

あるプロジェクトに投下されたリソースとプロジェクトが結果的に生み出した成果を紐付けることは可能だが、その程度であれば人月換算で大まかな勘定はどこでもしている。Jellyfish や Swarima は何らか費用効果として見せる機能を提供しているようだが、個人的にはそれらも魔法のような機能ではなく現実的な枠組みによって意義を示すコンセプチュアルなものと認識している。

機能としてはアウトプットの可視化に比重が寄る

サービスの機能の多くは単純なアウトプットやアクティビティの収集にかなりの比重が寄っているし、サービス提供側としてもそのような機能のほうが提供難度、確実性において現実的である。各社のマーケティングにおいて大きい前提にありそうな「開発部門の説明責任を果たすため」というニーズとは別に「チームの自己組織化とパフォーマンス改善」が巧妙に使い分けられる背景の一端でもあるだろう。

狙える的としてはアウトプット → アウトカムへの変換効率・変換後総量に係るユーティライゼーションが根本的かつ影響度が大きいと思われるが、それでも開発のアウトプットに係る細かいアクティビティから可視化せずにはいられないのがソフトウェア開発の新しい潮流かもしれない。

生産性の可視化を必要としないこともある

盲目的に可視化をすることを推奨することは本意でない。生産性において課題感がない（向上させる必要性を感じていない）、開発部門の生産性について特段の説明責任を求められない、に当てはまるならば可視化サービスは必要ないだろう。

生産性の向上は可視化サービスを用いずとも従来的なチームワーク、チームコミュニケーションによるアプローチが可能だ。その場合もサービスによって定量的な評価・議論ができるメリットはあるが、定量化の副作用に懸念があるならば絶対に必要なパーツというわけでもない。

とはいえ自信をもって可視化による改善を要しない、社内的にどこからも突っ込まれない、という環境は稀なのではないだろうか。

可視化された情報から何ができるのか

現行の生産性可視化サービスの多くはアウトプットに係るデータの可視化、各種の指標提供を主たる機能として備える。

アクティビティ傾向の変化や異常の発見

結論から述べると各種の一次指標（直接のアクティビティデータ）・二次指標（一次を元に見せ方を工夫したデータ）を観測しても即座に具体的な問題や課題を発見することは難しい。ましてや絶対値として意味のある数字が得られるわけでもない。

上下する数字に一喜一憂するのではなく、継続的な観測による傾向の変化や異常の発見を前提として運用するべきだ。これは世間一般のコンディションサーベイサービスでも同様であり、複数要因が絡み合った結果の擬似的な定量に絶対値を見いだすことは難しい。

意思決定における再現性の担保

チームの自己組織化とパフォーマンス改善を念頭に置いたとき、可視化サービスだけで何かしらの意思決定が完結することはない。サービスのデータから得られた洞察を現実世界で検証し、また現実における違和感や得られた仮説のためにサービスのデータを検証するというサイクルが前提にある。個人的には Google Analytics を想起するところだ。

意思決定者の主観とデータによる客観を相互に運用することで、個人やチームという当事者が意思決定の再現性を高められる。あくまで仮説検証における補助的な観測装置であることを念頭に置いておくと健全な運用が期待できる。

説明責任における透明性の担保

時間あたりのアウトプットの多寡がアウトカムを保証しない、と断じてしまったので開発部門の説明責任という話もいよいよ難易度が高いのだが、可視化サービスは少なくともアクティビティのブラックボックス化を解消する。説明責任について特定のサービスだけでそれを果たすことは難しいが、開示すべきを開示して開発部門のコンテキストを理解している人物がそれを説明する上では有用だ。

公開範囲を定義して数字の読み取り方や根底にある生産性の考え方などこ手の可視化サービスを取り扱う上でのコツや前提となる部分を共有しておかないと無用な誤解を生む恐れがあることは注意すべきだろう。

総じて、すべきでは無いこと

可視化サービス自体が一歩間違えれば開発者に対して「お前の ×× が低いから生産性を上げろ」というコミュニケーションを生じさせるセンシティブな特性をもつ。導入の文脈や運用の方法次第では容易にダークサイドに墜ちてアンチパターンを踏み抜いてしまう。

賢明な諸氏であればこそ導入の文脈を整理した上でサービスの導入を検討するはずだが、特に言及しておきたいアンチパターンだけ触れておく。

Common Pitfalls When Designing Metrics | The LinkedIn DPH Framework では指標運用におけるさまざまな落とし穴を紹介されているので、まじめに可視化サービスの導入を検討している場合は一読すると良い。

速度と量の回し車にしない

ネズミを回し車に載せるが如く高回転にしたところでアウトカムは保証されない。開発部門の倫理・誠意においてアウトプットの最大化は善処すべき関心だが、全体としてはアウトカムの最大化が優先されるべきだ。一定のアウトプットで十分なアウトカムが得られているのであれば持続可能な開発体制として肯定できる。

アウトカムが出ていないから開発組織という回し車を速くしようという話が挙がってしまうようなら、それはかなり危険な兆候だろう。（人をすり潰せばお金に変換できる類のビジネスは除く）

意味を見いだせない指標を運用しない

サービスでは色々な数字がとれてしまうからこそ、それぞれの指標に対してどれくらいの意味を見いだせるか、利用者側のリテラシーに大きく依存する。あまり意味のない指標だってあるし、何にでも意味を見い出して使い込もうとしても混迷が極まる。

• その指標の変化に意味を見いだして説明できるか
• 指標の変化に対して明確なアクションが可能なのか
• その指標に誰が対応することになっているのか

このようなことをよくよく考えれば現実的に運用可能で有意義な指標は限定されるので、闇雲にすべての指標を運用しようとは思わないはずだ。SPACE の S (satisfaction and well being) もこのように考えると開発側からはアプローチしづらく、組織マネージャーや人事に委ねたほうが賢明だろう。

どうぞご健康で！

このようなデータの可視化を伴うサービスは自分が欲しい結論のためのデータを拾ってしまうこと（バイアスの作用）が往々にして起こるため仮説検証におけるデータリテラシーが基礎として求められることも覚えておきたい。

人は休むと止まる。対戦よろしくお願いします。

心身の健康以上の開発生産性要素はないので、体力測定とストレスチェックを定期実施しましょう

— あほむ｜副業転職 Offers の overflow (@ahomu) November 1, 2023

目次

入社2年経って個人的な振り返り

株式会社 overflow に VPoE として入社して2年が経ちました。( 入社当時の記事 ) ふりかえり具体の前に弊社について簡単にご紹介をば。

弊社の Offers 事業は「転職」と「副業」をテーマにデジタル人材が社会において同時多発的に活躍し、その時々で然るべき場所に然るべき人材が流動する人材循環型社会を志向したプラットフォームです。

転職 + 副業という切り口で本邦のデジタルを加速させる

デジタル人材において労働人口の圧倒的な不足が予想される中「副業」を通して優れた人材の優れた知見が社会的にシェアされることの意義はもちろん、個人の立場としても副業はキャリアのリスクヘッジとして有効に働きます。

当職 VPoE は組織開発が主な職務

overflow は CTO が技術経営を担うのに対して、VPoE が組織開発を担うかたちで管掌の分担が行われています。レポートライン上は CTO が VPoE の上長にあたるので組織開発も技術経営の最大化を念頭に執行しています。

ピープル、テクノロジー、開発進行 (事業アライン) のマネジメントスコープ3つがそれぞれ円滑に執り行われるための組織開発と、ピープルマネジメントを主務とします。その他の業務は雑多すぎるので割愛。

ちなみに CTO や VPoE がしばしば兼務しがちなプロダクトマネジメントは CPO の管掌になっています。

「変化」と「成長」と「注力」

成果としてどこを目指すかは状況に依るものとして、組織開発の普遍的な要点としては変化、成長、注力（推進）の最大化を念頭に置いて取り組んでいます。

• 然るべき変化が実感できること
• チャレンジや成長の機会をつくり続けること
• 注力すべきに注力すること

過去にダイナミック・ケイパビリティの考え方に感化されたことから内発的な変化と適応に比重を置いています。徹底的なフラットやボトムアップ偏重で統制がとれるとは思っていないため実態としては懐が深くて優しい専制主義に寄りがちと自認するところです。

マネージャーとしての世界観

ソフトウェアデザインパターンのごとく、どこかの本に書いてあるような紋切り型のマネジメントスキームを片端から導入して整地するのが組織をエンジニアリングする...ってコト!?

— あほむ｜副業転職 Offers の overflow (@ahomu) August 23, 2023

これはちょっと煽りすぎですが（ごめんて）、マネージャーの世界観が反映されたメッセージこそがマネジメントをマネジメントたらしめると考えており、課題に対する処方箋としてのフレームワークやプラクティスの安直な適用には慎重な立場です。

処方箋に期待される結果が本当に目の前の状況に対して有効なのか、世間の「良かった探し」を再生産しているだけではないのか、本当にマネージャーの世界観に適合しているのか自問を要します。また会社の文化の現状を見極め、状況に応じて変化させていく過程においてスキーム先行ではうまくいきません。土着の文化ありきで、それに応じたスキームを選別していくべきです。

① 2022.04 〜 スケールアウトの基盤づくり

ここから回顧録です。

入社当初は採用、技術広報、ガバナンス整備を粛々と行いました。組織や事業のインプットも十分ではなかったので、まずは、どうあっても必要になるであろう基盤を整えておこうという保守的な方針です。

｢副業｣ を強みにする組織方針の策定と注力

Offers にとって「副業」が重要なテーマであることから、overflow 社内において副業人材の活躍が一過性でなく持続的な企業価値に寄与するスキームの構築が開発組織で自社の企業価値を高めるアプローチであると定めました。

1. 副業人材の活躍が overflow のコアな価値 (※) に成果を残す
2. 成果をもって人材の副業体験、従業員満足度を最大化する
3. 社員メンバーだけでなく副業メンバーからのポジティブな発信を引き出す
4. 社外の潜在顧客、潜在候補者 etc に発信を届ける
5. Offers の新規利用や副業転職、新たな人材との出会いに結びつく → 以降ループ

書いてしまえば単純かつドッグフーディング観点で当たり前ですが、徹底的に「副業」を擦り倒すサイクルの実現が唯一絶対の方針です。

※ コアな価値 = 技術資産、プロダクト、社員・副業メンバーの経験値

入り口として採用、選考プロセスの整備

採用を急ぎたいフェーズだったこともあって、CTO や生え抜きのエンジニアメンバーを巻き込んで下記の整備と実行を粛々と進めました。CTO と私以外の社内の物差しを育てるためにもスクラム採用スタイルです。

• 評価基準の言語化（社員、副業それぞれ）
• 構造化面接ライクな整理
• エンジニア向けピッチの作成（カジュアル面談用）
• 選考中の候補者向けアンケートや面接録画スキームなどの整備
• 全体的なドキュメント化

採用人事が本格的に参画するまで手弁当で Offers を含む採用媒体を漁りスカウトを打って、面談、面接、アトラクトを重ねた結果ほぼエンジニア工数だけで半年のうちに元 CTO の古強者を含む5名の内定承諾が決まりました。

うちの事業が事業だけに多くの採用媒体からはお断りされるため、使わせてくれた一部媒体の各社には感謝しております :)

成果を残してもらうためのオンボーディング整備

副業、社員問わず成果を残して貰うために3ヶ月間を目安としたオンボーディングの整備にも着手しました。具体的なオンボーディングプログラムの作り込みは走りながらですが、分散した必須情報の集約、非同期なコミュニケーションの明文化などのドキュメンテーションを中心に社内で部分的に横展開などもされています。

副業メンバーのマネジメントスキーム整備

オンボーディングとは別に特に副業メンバーを対象としたマネジメントスキームの整備もしています。これらを前提としつつ副業メンバーの活躍を共有する会議体を設定し、副業のマネジメントが特定個人の負荷にならない工夫もしています。

• プロに業務を委託するという線引きのメンバーレベルでの徹底
• エンゲージメントを高めるコミュニケーションの例示
• タスクアサインの判断基準（期日感 × ドメイン知識の要否）
• アウトプットの可視化と振り返りスキーム
• 継続判断や報酬見直しのロジ整備
• 副業転職（社員化）に向けた方針と戦術
• 時間単価契約の報酬計算式（だいたい外れない秘伝のタレ）

事業的にも重要な要素だったため当時のフェーズには少々過分なほどの作文をした結果、カスタマーサクセス経由でお客さまの手元にもノウハウ資料に化けて旅立っており多少なりとも貢献できたかなと。

広報資産を積み上げるテックブログの建立

参照先: テックブログの運営ノウハウと FY2022 前期の完走報告 | Offers Tech Blog

過去に zenn で記事化してあるのでそちらを参照いただきつつ、ポイントとしては「善意ではなく業務として取り組む」「まずは質より量をとる」が重要なプラクティスと考えています。

採用の場でも「あの記事を見て興味をもった」「この記事についてもっと話を訊きたい」といったポジティブな反応も得られ、実はそこそこな PV もコンスタントに獲得しており "Offers" の認知拡大に寄与したと思われます。

※ SEO 狙いでめっちゃロングテールな記事を書ける元ライターなエンジニアメンバーがおりましてテックブログにしては玄人の仕事が入っていました :)

エンジニアのロールと期待役割の言語化

参照先: エンジニア組織でありがちなリーダー・マネージャー問題と、フレキシブルで可逆なキャリア開発のアプローチ｜Offers Tech Blog

こちらも過去に zenn で記事化していますが、若年メンバーも在籍していることを鑑みてキャリアに繋がるイメージと期待役割の明文化も早期に行いました。開発における役割の棚卸しを経て、職位や等級からは独立した「役割」の定義になっています。

全社の組織戦略や評価制度の策定

主に HR と連携した取り組みとして、組織戦略や評価制度の策定にも携わっています。

当時の全社組織戦略には前述の ｢副業｣ を強みにする組織方針 が部分的に取り込まれした。評価制度については前職の終盤で人事に片足を突っ込んでそれなりに達者になったおかげで、社内外の HR 責任者に混ざって色々議論させてもらいました。

じつはデザイン領域も担当

ボードメンバー内での分担としてデザイン領域も預かっています。デザインに対して経営としてどのような期待があるかを伝えるのが主であり、デザインチームやデザインワークの具体はお任せしています。

一方で経営会議で社内の現状におけるコミュニケーションデザイン領域の必要性を説いてポジションを作るなどの形では携わっています。

② 2023.04 〜 開発組織とチェンジマネジメント

2022年10月ごろから注力事業の開発を CTO 直下の指揮に変更するなど変化の端緒は開かれていましたが、全社方針の変化に呼応する形で開発組織のマネジメントにもいよいよ変更を加え始めました。

戦力化、筋肉質化への注力

この頃、過去半年の採用によってオンボーディング途上のメンバー率が増加しており傍目には「人数増に対してアウトプットが振るっていない」という状況がありました。

コンテキストをもった当事者からすればもどかしい状況であり、即効性のあるプラクティスや型の適用にも限度があります。そんな中「他人の世話を見るよりも、自分の成長・成果にとことん向き合おう（超意訳）」という方針を打ち出して筋肉質化の文脈を強めました。

手堅いツリー型からフラット寄り｢脱・世話焼きマネジメント｣への変化

ミドルマネジメント候補の育成を含めイザとなったら堅めにも振れるようにしていましたが、当時の状況で堅めのスキームを突き詰めることはプロダクト成長の枷になることが想定されました。半年前は判断が付かなかった中でようやっと見えてきたので変化に踏み切った次第です。

フラット極振りではないもののミドルマネジメント育成を中断しつつ、CTO と VPoE とデザインマネージャーにレポートライン（評価ライン）を集約しました。同時に少数のマネジメントをスケールアップさせるため「脱・世話焼きマネジメント」が始まります。これは今名付けた。

筋肉質化と矛盾する部分もありますが世話を焼ける側も自分の成果に向き合う姿勢を見せることを優先しました。（そして色々言いつつも焼くべきは焼いています）

目標設定と評価に絡めた全員参加型マネジメントの導入

自分のことは自分で面倒を見れることの必要性を示す施策として「VALUE チェックイン MTG」という月イチで開発メンバー全員で集まり、目標の自己設定と自己評価を共有しフィードバックをもらう会を始めました。

• セルフリーダーシップ（またはセルフマネジメント）の促進
  • 自分で決めた目標をやり切って、自分で振り返られる裁量
• コミットメントとフィードバックのオープン化
  • ポジネガ問わないフィードバックによる順当なプレッシャー

細部に議論の余地がある施策ではあり、メンバーからも当時は懸念や不安そうな声が挙がりましたが直近はアンケートを見てもポジティブな取り組みに育っています。

半期ごとの昇格の自薦と審議のスキーム整備

半期毎の昇格判断シーズンにおいて自分が等級に見合う実績があると思ったら、自ら手を挙げて推薦できるようにしました。マネージャーの昇格させる責任を完全に放棄するものではありませんが、社内における成長目線と現在地を自分で意識してもらう機会です。

1. 等級表を念頭に昇格にふさわしい事由を当人がまとめて提出
2. マネージャー + 当人より等級の高い者で昇格の是非を審議
3. マネージャーから結果をフィードバック

瞬間的に関係者全員の負荷が高くなる行事ではありますが、明文化されていても解釈に齟齬が産まれがちな等級・グレードについてフィードバックを通して更なる言語化と共通認識を醸成できるメリットがあります。

ご多分に漏れず LLM による機能開発

ここまでの流れでプレイヤー比率を高めるのは CTO と VPoE も例外ではなく、当時は自分のプレイヤー比率を高める一環で LLM を利用した機能開発の検証にもチームメンバーと共に取り組んでいました。

当時の成果としていくつかの機能をプロダクトに反映することはできましたが、社内利用を活性化する方面は振るわずやや反省が残るところではあります。

③ 2023.10 〜 挑戦と成長によるスケールアップの模索

ピザ4枚弱の人数感だったこともあり半年過ぎる頃には「脱・世話焼きマネジメント」環境下が日常に溶け込みました。一方で各位にに挑戦と成長を促す差配は続けていたので、脱・世話焼きの副産物として裁量の獲得とプレッシャーがポジティブに作用したメンバーもいます。

自発的に大事な関心事と向き合える土壌づくり

脱・世話焼きのセカンドステップとして組織機能、厳密には組織の意思決定に対するオーナーシップの健全な分散を企図しました。マネージャーだけが組織機能を担うことによってメンバーが組織のお客さまになるのは避けたい未来であるからです。

そこでティール組織的な委員会の亜種として、将来的には各自が必要と思うコトを自発的に取り組める環境づくりと土壌となる組織内の了解を醸成する仕込みを行っています。まずは事業直結ではないが重大な課題（セキュリティ保守や重度の負債）への取り組みを試金石としてワーキングループ制度を実験的に開始しました。

個人単位からチーム単位に至る成長目線の拡張

年明けにスポットのワークショップを実施したのみですが、チームにおける半年後の理想と成長目標に向き合ってもらう機会を設けました。

• チームの今後の成長について解像度を上げて共通認識をつくる
  • チームとして何ができていたらより良いか
  • 誰がどうなっていたら、より成果を出せるか
• チームの事業貢献と、個人の自己実現のすり合わせを行う
• チームの理想に対して、個々人がどのように貢献するのかを宣言してもらう

前述のVALUE チェックイン MTG が個人にフォーカスしていた中、チーム個別の経験学習の推進と合わせてチームとしてのゴールを明確にする必要がありました。普段からスプリントごとの振り返りをしていても、改まって「自分たちの理想状態は？」と向き合うことは少ないので良い機会になったようです。

企画する割に私がワークショップ的な催しに不慣れな部分はデザイナー各位の miro ぢからに助けられました。

開発フルコミットへの一時復帰

10-11月頃は ｢控えめな App Router と持続可能な開発｣ というタイトルで久々に外部発表した :: ハブろぐ に至る開発にほぼフルコミットで取り組んでいました。完全にリハビリ案件。

そんなところで今に至ります。あー、長かった。

経営ボードとしての役割

いわゆる経営会議に出席するボードメンバーでもあります。もちろん会社法上の役員ではありませんし、執行役員制度も無いので実質スゴイ平社員です。

現時点の自己評価としてビジネス的な意思決定への貢献に課題は残るものの「会社ごっこをしていないか？」という自問可能性の獲得は重要な発見でした。結果論として反省、後悔も多くありますが入社当時と比べれば何とかやっています。

※ 会社ごっこのくだりは自分自身の内省にのみ適用している話です、念のため :)

｢変化｣ しよう

組織寄りのマネジメント業としては社内や事業の変化をいち早く嗅ぎ取って備え、管掌が変化に遅れをとらないよう方針を示し続け、地上戦で実感を伴って浸透させていくチェンジマネジメントの重要性を学べた2年でした。

キャリアの弾力性においてイチ開発者として復帰しようと思えばできると自負はするものの、当面は組織開発を主軸とした経営コミットのほうが意義を感じるので暫くはマネージャー路線で生きていく所存。

マネジメントや組織開発の文脈で語る機会に乏しく、たまに Web フロントエンド開発に戻って言いたいことを散らかすとそれなりに世間の反応が得られてしまうことに内心複雑な今日この頃 :|

｢なぜこんなに必要？｣ にうまく答えられなかった当時

当時の役員から組織の頭数に対して、そんな旨の問いを投げかけられたことがありました。ポジションの内訳や開発規模に対する"必要性"を中心に話したはずですが、わざわざ内製で安くない人件費を投じている文脈で期待される +α の成果に対して十分な説明を行うことはできなかったように思います。

技術畑でない役員と話すにあたっては当たり前ですが自社の経営目標とビジネス一般の理屈にチャネルを合わせて話をする必要があり、当時は自身にそれが求められていたことを改めて意識するタイミングでした。

相応の学習や技術の乗換をしていれば Tier 2 ソフトウェアエンジニアの価値が直ちに崩壊する可能性は今のところなさそうですが、作れます！使えます！以外で説明可能な「自身のバリューのテーマ性とキャリア」の獲得が市場価値の持続的な向上に不可欠であることの確信が深まります。 ソフトウェアエンジニアの市場価値または報酬傾向の変化と覚え書き

これも結局は同じ話に繋がっている認識で、経営も各種の意思決定の中で膨れあがったソフトウェアエンジニアの人件費に対する納得を欲している部分もあるのではないでしょうか。

ソフトウェアエンジニアとビジネスの距離感

近年（本稿の原型は2022年頃のテキストであることから時差が大きくなっている）、ソフトウェアエンジニア界隈での「事業貢献」や「ビジネス視点」が度々論じられ「技術は手段に過ぎない（ｷﾘｯ」がますます幅を利かせているように感じます。

手段と誹られようが無邪気に技術を論じた Twitter もとい X はどこにいったのか。

それは ｢全員に経営者目線を持て｣ と何が違うというのか

ソフトウェアエンジニアの事業目線・ビジネス寄り添い論を見かけるたび「全員経営者目線」ほどの風当たりの強さは感じないのを不思議に思うことがあります。

これまでの時代がエンジニアファーストだのと牧歌的すぎたと自覚できる層、最初からビジネスに携わる手段としてソフトウェアエンジニアリングに参入した層、さまざまな背景から一定の合意形成はされているのでしょうか。

｢事業が分かる自分と分からないお前ら｣ に耳を貸す必要はない

斜に構えて見るとマウンティングの一環としてこの話題を持ち出している手合いも少なからず存在しますが、分かる/分からないを単純化してその是非を論じたがっているようにあなたが感じるならば耳を貸す必要はありません。そのように単純な二元論であるはずが無いからです。

作ることが本分であることから目を背けてはいけない

ソフトウェアエンジニアリングのアウトプットは何にせよ作るという行為を要します。もしビジネス判断とうそぶいて稚拙なものづくりに甘んじているようであれば確たる成長は望めないでしょう。

どこかに物理的な限界はあることは理解しますが、様々な制約がある中で最善を尽くし続けることでしか自分が正しく拙速を成しているのか、単なる稚拙に甘んじているだけなのかを判断するに耐える地力を養うことはできません。

終わりつつある市場価値の青天井

ビジネスの場において他セクションと対等に振る舞えるスキルを持ったソフトウェアエンジニアの台頭そのものは歓迎すべきだと考えます。野趣溢れる SNS ですらビジネスとの距離感が論じられるのは真っ当な成熟の過程にあると認識しています。

お前の価値と、お前が生み出す価値の説明責任

ソフトウェアエンジニアの市場価値の青天井に歯止めがかかりつつある中で「ビジネスと近い距離感でこのように貢献できます」とあなたが語れるのであれば自らの価値を説明する上で強い武器でしょう。

経営者や事業責任者は技術の立場から事業について会話チャネルを共有できる意気軒昂な人材を常に欲していますし、何らかマネージャーの役割であれば求められても当然の素養でもあります。

※ 中間管理職的な技術マネージャーの素養と事業運営の相棒たりえるマネージャー/リーダーの素養が厳密には異なりそうなのが難しいのですがさておき。

自分の仕事をアウトカムに繋げるストーリーテリング

営利に携わるならば誰しも行き着く果ては「ビジネス成果」になるはずですが、アウトプット（ものづくり）はできてもアウトカム（具体成果）との距離が生まれやすいソフトウェアエンジニアの身の上ではビジネスとの距離感だけで勝負できるとは限りません。また技術を通した価値創出がメインストリームであって欲しい願いもあります。

専門性を求められない Web アプリケーション開発であっても、そこにパフォーマンスやユーザビリティの面で卓越した技術があるとか、精通した知識によって組織の技術水準を底上げできるだとか、アウトカムに繋がるストーリー（理由付け）が自他共に明らかであれば説明責任の筋が見えてきます。

これまでも技術による価値創出と真摯に向き合ってきた諸氏はもちろんのこと、多少の安全圏にいた当事者ですら自らが関わることによる付加価値を説明することの責任からは逃れられなくなっています。

手段と目的を賢しく論じるようになってしまうのか

個人的には技術が目的たらんとすることはありえる派ですが、手段でしかない技術しか触れてこなかったのならば、そういうこともあるのでしょう。なんにせよ手段と目的の云々では言葉遊びの範疇を出ないので少々飛躍します。

アウトプットへの責任とアウトカムへの責任には濃淡がある

どちらに責任の重心を持っているかは立場によって異なりますが、スタートアップのような環境では末端に至るまで両方のスタンスを求められることもあるでしょう。マネジメントでない一部の上級エンジニアもアウトカムへの責任を語れなければならないことがあるでしょう。

アウトカムに対するスタンスが求められる状況を想像すること自体は容易いですが、それがソフトウェアエンジニア全員に対して普遍的に求められるかと問えばどうでしょう。そこには違和感があるのではないでしょうか。

技術行使の説明責任

結果論として価値たりえるアウトプットを売上等のアウトカムに変換する行為は個人の中で完結することはほとんどなく、通常は組織の営みひいては経営の責任です。

ソフトウェアエンジニア一般が果たすべきは技術を行使した結果のアウトプットに対する説明責任が第一義です。Why - What - How のどこに責任分界点を持ってくるかにもよりますが、曖昧にアウトカムへのコミットを期待して責任の転嫁を図るようなことがあればあまりにも都合が良すぎるでしょう。

全員が賢しい必要はない

できないよりは、できたほうが良い。それはそうです。

ソフトウェアエンジニアも説明責任とニアリーイコールな位置付けでどれくらいのインパクト（影響力）を産み出せるかは常に意識しながら動いたほうが良いとは思いますが、全員が事業が分かる、事業と話せる、みたいな像を厳に求める必要も目指す必要もないのではと思います。

メモ書きの供養ポエムでした

自分たちになりの "良いエンジニアリング" と向き合っていた頃と比べるとあらゆる場面で "自分たちが作る" ことによってどのような価値がアドオンされるのかを示さなければならないことが増えていると実感します。本当に繰り返しですが。

一方でビジネス云々を引き合いにして「技術観点でしかモノを申さない」「事業都合を考慮しない」 のような個別具体の社内政治かマネジメントの話をこじらせて、悪い意味での "職人気質" をソフトウェアエンジニア一般に適用して公に揶揄するのはフェアではないなぁという気持ちが溢れた頃のテキストの供養でした。

こんな長々書かなくても140文字以内でまとめている方がいらっしゃいました。持ち場を離れるなって良い言葉。