$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

開発生産性カンファレンス 2024を堪能してきました

dev-productivity-con.findy-code.io

自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。

興味深かったセッション

顧客価値向上による開発生産性向上

顧客価値を高めるという観点にフォーカスした発表でした。

  • 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい
    • 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作
    • 一元的品質は、高めれば高めるほど顧客価値が上がる = 車の燃費
    • 魅力品質は、当たれば顧客価値が高まる
    • リファクタリングすることで、顧客価値を高める可能性を増やせるかも、このモデルで判断できる
  • 開発生産性最大化に向き合うための問いが良かった。チェックリストとして毎回活用したい
    • 顧客価値や事業価値をチームで共有する場を設けているだろうか?
    • ユーザーを主語にして機能の議論をできているだろうか?
    • NSMやKPIツリーを可視化し、開発物がどこに貢献するか共有できているだろうか?
  • ジョブ型雇用はサッカーチーム。自分の範囲はここと決めつけるのではなく、オーバーラップしてカバーしていく
    • 越境の大切さに繋がると感じた

価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦

大企業で必須な粘り強いコミュニケーションを続けて課題解決をしていることに痺れました。自分はスタートアップ所属が多いからこそ、年月をかけて地道なコミュニケーションをする部分には弱みがあると思っていて、このように地道に根本問題の改善を進める発表に感銘を受けました。本当にいい発表だったのでぜひスライドを見て欲しいです。

  • エンジニアが企画側にも影響を及ぼすには他チームと強い繋がりを持つPdMとタッグを組むという話が良さそうだった。自分の隣接領域に影響を及ぼすときは基本タッグを組むという姿勢でやっていきたい
  • 簡素化や権限委譲のためにはステークホルダーからの信頼が必須なので、まず信頼してもらえるように改善を進めるというのがいい話だった

価値創造と開発生産性

www.ryuzee.com

  • 引用されている「重要でないものの正確な尺度よりも、価値あるもののあいまいな尺度の方がいい」「測定できないものは管理できない、と考えるのは誤りである」良かった
  • 自分としては、価値創造と開発生産性どちらが大事かという話題で、何よりもまず価値創造は反対の立場。その方向になると、結構なケースでエンジニアがPMなどへ他力本願になりがち。価値創造を意識すべきは賛同
    • ただしEMクラスが価値創造を意識しないのは正直ダメだと思う

実践チームトポロジー: プラットフォーム性とイネイブリング性の戦略

  • 外から自分のチームに入ってきたことを歓迎することも1つの越境というのが、良い知見だなと思った。オープンマインドだからこそ越境されやすくなり、結果的な全社の越境推進につながる
  • プラットフォーム/イネイブリングチームは最初はストリームアラインドチームにembedして入り込み、そこから徐々に離れていくのは良い戦略に思った。専任スクラムマスターとしてチームに入り込み、知見を伝授してから去っていく的な

また、質問タイムで突撃させてもらったのだけど、にている課題感を持っていて議論が盛り上がった。

  • ストリームアラインドチームをちゃんとしていくと、今度は複数のチームが関わる機能を避けるようになりがちじゃない?という質問をして、今まさに考え中という話だった
    • 越境自体をちゃんと文化とするため、横断的に行動したチームを表彰する、専門性で横断的取り組みをすることを奨励するなど工夫し始めているということだった
  • かなりプラットフォーム/イネイブリングチームの割合が多そうだが、他の経営メンバーとのすり合わせをどうおこなっていったかという質問をした
    • 結局全員が事業の価値を最大化したいという前提だよねという意識合わせをした上で、どの時間スパンで考えているかをすり合わせていったらしい
    • プラットフォームチームなどを作っていくことで、3ヶ月ほどの期間では価値の最大化は見込めないかもしれないが、1~2年のスパンでは確実に最大化する。そのような長いスパンで成長させていきたいと全員が思っているはずだよね、みたいな形ですり合わせていく
    • この「全員が同じ方向を向いているはず」から始めるすり合わせのやり方はPM/EMでの連携と同じだよねという話もした

フィーチャー開発からホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~

  • 実践チームトポロジーで質問させてもらった「複数チーム連携」の課題に挑戦していく話題で、自分の中でホットだった
  • 優先度決定のために、魂・骨・肉・皮を使うというのが、良いメタファーだなと感じた
  • Org TopologiesやFASTという概念を初めて知って、一度この辺りを深く調べてみたいと感じた

質問タイムでは、会社が小規模の時は優先度決定をCEOと一緒にやっていったと話していたが、現在はどうしているかということを質問させてもらった。 - 複数チームになった段階でCEOが優先度決めをする方式からは離れていった - その代わりプランニングやスプリントレビューの時にカスタマーサクセスの人に入ってもらうことで顧客視点を必ず入れるようにしている

ということらしい。カスタマーサクセスの人をレビューに含めるのは非常に良いやり方と感じる。

「開発生産性を上げる改善」って儲かるの?に答えられるようにする

  • レイヤーごとの開発生産性とは何かについて可視化している資料が非常に良かった
  • また施策のROIを開発生産性の観点で説明するときに、レイヤーを何段階も飛ばして変換しようとするとうまくいかないので、1レイヤーずつ変換するという話が勉強になった

仮説検証生産性とプロダクトグロースサイクル

https://gamma.app/docs/-necbojc9wcdk8yw?mode=docgamma.app

  • 付加価値労働生産性について、期待付加価値と実現付加価値に分解しているのは面白かった
  • 機能優先度では、探索と活用のジレンマ(確かで小さな改善と、不確かで大きな改善)、短期と長期のジレンマ、見える見えないのジレンマがあるという整理が良かった
    • プロダクトの時期によって、探索活用比率、短期長期比率、技術的投資比率を決める必要がある

開発生産性の観点から考える自動テスト

  • TestDoubleはテストサイズを下げるという発想が勉強になった。localstackはLargeをMediumにする
  • テストサイズのSmallを多くすべきかは、個人的には悩むなと思った。データベースを使った開発をしていると、Smallは正直小さすぎて自動テストとしてはあまり役立たないと感じているため

そのほか廊下での会話

  • LayerXのブースで話したやさしさチケットの話が良かった。細かい改善をどう回すか、微妙な空き時間でどう改善するかという点で参考になった
    • 手触りの改善とかはPdM・デザイナーと相談して、チケットとして先に作っておく
    • そのチケットは余裕があればスプリントに差し込んで実装して良い
    • さらに月に一度やさしさdayがありそこで一気に対応できる
  • t_wadaさんと、技術顧問業で外部から入る時にどう組織に影響を出しやすくするかを質問した
    • 自分で改善するというより知識を相手に伝達することをゴールとし、一緒に改善するチームを立ち上げて伴走していくようにしている、とのこと
    • 技術顧問はイネイブリング的働きと思っていたので知識を相手に伝達するのがゴールというのはイメージできていたが、そのために社内に一緒にやっていくチームを組成させる方が良いというのはなるほどと感じた

全体を通して

全体を通して今年は「開発をいかに速くするか」よりも「価値をいかに素早く大きく届けるか」の話題が多いように感じました。自分自身も、開発の高速化の知見は溜まってきたけど、その先の価値創造に紐づける部分が難しいなあと感じていたところだったので、このような話題が多くなるのは納得です。自分の課題感と似たようなセッションが多かったため、今回の話題を業務に活かしていきたいなと感じました。