Findy主催、表題のカンファレンスにオンライン参加してきたのでその感想・忘備録です。
参加したトーク・セッションは下記になります。
CTOが語る、ビジネスグロースに向けた開発生産性向上への道筋
組織拡大フェーズにおけるペインと開発生産性向上の推進
開発生産性を測る新たなフレームワーク「SPACE」の定義と実践
それぞれについて軽く要約して、感想を書いていきます。
CTOが語る、ビジネスグロースに向けた開発生産性向上への道筋
「株式会社はてな」さんと「株式会社ユーザベース NewsPicks」さんのセッションですね。
要点としては、エンジニアだけでなく、ビジネス側とも仲良くなろうといった開発チームだけでなく、もっと広義の価値に着目しなければならないをお話されていました。(開発生産性だけでは、必ずしもビジネス貢献できている訳では無い)
Four Keysとかで個人・チームの開発生産性が分かってもそもそもビジネスそのものがだめだとどうしようもないよねって話でした。現職でそういう局面にちょうどいるため、終始共感していました。
お話の流れとしては
各社の開発組織の紹介
両社、100名前後の組織で部門が各種しっかりある感じ
NewsPicksさんはミッション型組織ではてなさんはマトリックス組織でした
NewsPicksさんは技術負債の返却アウトカムの最大化、はてなさんは事業のコスト低減・技術リソースの提供・変革促進など両社とも現状を変えたい意識の強さを感じました
開発生産性への取り組み
NewsPicksさん : DX Criteriaを活用し、組織全体の再編も含めて推進
はてなさん : Findy Team+の活用、開発パフォーマンスダッシュボードで可視化・改善を推進
今後のトライ
NewsPicksさん : 11年目でも去年作ったシステムを目指す(標語があるとトライすることが明確になる) / プロダクトエクセレンスの向上
はてなさん : 事業全体としての生産性の定義(開発→全社への横断的な指標設定を目指す) / 最速のための技術支援 / 運用コスト低減
といった感じでした。事業全体と開発組織の関わり方を両社とも模索しているような印象でした。信頼貯金だったり、関係性にかなり気を使うといった話はよく分かるなと思いました。そして、関係構築をする上で「最高の開発組織がビジネスを支えますよ」って状況を目指しているのかなと思いました。
組織拡大フェーズにおけるペインと開発生産性向上の推進
「株式会社BuySell Technologies」さんと「Chatwork株式会社」さんのセッションでした。
要点としては、組織を拡大をするとアウトカムが不透明になったり評価面に課題が生じる。それを開発生産性の取り組みで可視化するようなお話でした。現職がこれまた拡大フェーズ(グループ再編)でアウトカムが不透明になったり、評価が上手く統合されていなかったりと同じようなペインを感じているのでよく分かるなといった感じです。これらが上手く行かないと拡大フェーズにコアメンバーがごっそり辞めるみたいなことが発生します…。
お話の流れとしては
エンジニア組織のペイン
BuySellさん : エンジニアのアウトカムが組織拡大によって見えにくくなる。
Chatwork さん : 100名以降になると顔が分からなくなる。定性・定量評価が課題になる。
開発生産性の優先度と取り組み
BuySellさん : CTO室と各EMで施策を推進する体制作り(テックイシュー制度)を行っている。採用・評価のテコ入れを最初に行い、育成・マインド・QCD等をテコ入れされていました。
Chatwork さん : 開発生産性≠企業の付加価値だがアウトプット量の占める重要性を認識。Findy Team+やGitHub Copilot, ChatGPTを活用し、可視化・効率化に取り組んでいました。
開発生産性を可視化するメリット
両社とも、同じ物差しがあることは共通の言語になりうる(特にエンジニアとビジネスの共通語が難しい)だったり、同じ指標を追いかけられる(数字を使わないとコミュニケーションが難しいため)といったユビキタスな指標の重要性を説いてました。
今後の開発生産性のトライ
BuySellさん : 限りあるリソースでどういうリターンを得るのかが主題だと認識。組織横断で開発生産性に繋がる指標の可視化や投資側の指標やアウトカムの指標も可視化をできるようにしたい。
Chatwork さん : 可視化や生産性の向上にトライしているが、定量データの扱いの難しさ(独り歩きしやすい)が開発生産性を評価利用する際にネックになる点が悩みだそうです。個人的にもチーム毎に抱えるペインは違うわけでそれらが同一の指標で評価されるのは本当に公平なのかなど考えることがあります。
といった感じでした。ちなみにQ&Aで可視化のデメリットについても言及していましたが、
BuySellさん : 生産性がチーム間で比較されることによる弊害。最終のアウトカムに向いてくれない。実際のアウトカムに直結しないため。
Chatworkさん : 扱いが難しい。チーム間で必ずしも比較できない。その中で評価をするのは納得感がない。(ハックされてしまうとディスコミュニケーションになってしまう)
といった感じで、みんな同じようなことで苦戦しているんだなと思いました。アジャイルプラクティスにも似たようなお話がありますよね。組織共通の仕組みがほしい一方で、チーム単位でカスタムしなければならない現状をどうするかが、今後のエンジニアリング組織論で重要になってくるのかもしれないですね。
開発生産性を測る新たなフレームワーク「SPACE」の定義と実践
株式会社ワンキャリアさんのセッションでした。(このセッションはFindyさんがSPACEフレームワークについて解説もされています)
現職でSPACEフレームワークを利用しているので、一番楽しみにしていたトーク・セッションでした。
要点としては、SPACEフレームワークについてとSPACEの運用する上で難しい点の解説といった感じでした。私自身も原文を読んでいたり、マネジメントの師匠に当たる方から勉強会等でかなり詰め込まれているため、SPACEフレームワークそのものについては特に目新しいことはなかったですが、運用している会社さんの事例や生の声が聞けたのは良かったなと思いました。
お話の流れとしては
SPACEフレームワークの解説
基本的に原文の解説になるため割愛(5つの次元の指標例はいいなと思いました)
海外事例について(こことても良かった)
Spotifyの事例 : 開発生産性向上に向けた、Flakyテストやビルドタイムに対する開発者の満足度を前提。定量的な指標だけでなく、アンケート等、定性的な意見を聞いてみることを推奨している
Airbnbの事例 : SPACEをBeyond DORA(Four Keys)として位置づけ。高い開発者満足度を実現するために仕事の環境に関する観点を持ち、技術負債の返却やドキュメントの整備、開発への集中時間を設定している
SPACEを利用している背景は？
元々、開発生産性を測っていたが、実装以外のアクションを促すことができていなかった
エンジニアの生産性を多角的に評価し、適切なアクションをエンジニアに促す
具体的なメトリクスの集計方法と運用とは？
Satisfaction and wll being では開発メンバー向けアンケートを実施
Performance, Activity, Efficiency and flow は Findy Team+を活用し、取得できる指標を使用
SPACE運用について
Four Keysで見えない開発生産性の課題を把握できる
企業や開発体制によって最適な指標が異なる点や絶対的な基準を設けることができない点が難しいところ
といった感じでした。
SPACEフレームワークの原文は下記参照です。
現職で私がEMとしてやっていることの妥当性や異なる点がいくつか分かって面白かったです。アンケートの運用については、私のチームでも実施しており、現在執筆中のQiita記事で解説しようかと思います。
P,A,Eの次元については私のチームでは、Swarmiaを利用しています。
Findyさん主催のトーク・セッションで触れるのはちょっとタブーな感じではありますが、Four KeysをGitHubと連携して測れたりします。(全部英語です)
企業や開発体制によって最適な指標が異なる点や絶対的な基準を設けることができない点が難しい
というのは、とても良くわかります。最適な指標を定めるようなサイクルがあったら面白いですよね。
あとちょっとこのセッションで気になったのはQ&Aの際に、
SPACEフレームワークを評価に用いているとありましたが、具体的にどのように評価しているか教えてください
といった質問に対して、「それぞれに評価指標を設定して、評価している」といった回答をされている点です。絶対的な基準を設けることができないとお話されていたのでここってどう解決しているんだろうかと思いました(チームレベルで見直し前提で用意している？)。あと個人的にSとかCを評価に入れることはよろしくないのではと思っています。このあたりどのように評価に落とし込んでいるんでしょうね？
総まとめ
どの企業もペインは似ているんだなと思いました。そして、そのペインを組織レベルでアグレッシブに向き合っていることが素晴らしいなと思いました。僕も組織レベルでこういったことをやりたいな。
後、私のマネジメントの師匠が書いているDPEのスクラップ宣伝しときますね。おすすめです。