開発生産性カンファレンス 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さんと、技術顧問業で外部から入る時にどう組織に影響を出しやすくするかを質問した
  • 自分で改善するというより知識を相手に伝達することをゴールとし、一緒に改善するチームを立ち上げて伴走していくようにしている、とのこと
  • 技術顧問はイネイブリング的働きと思っていたので知識を相手に伝達するのがゴールというのはイメージできていたが、そのために社内に一緒にやっていくチームを組成させる方が良いというのはなるほどと感じた

全体を通して

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

git grepの結果をfzfで絞り込んでエディターで開く

エディター側でなくCLI側でgit grepするのはいろんなオプションを渡せて便利だ。たとえば --and や --or でいろんな条件で絞り込んだり、-C オプションで周辺の行も一緒に見ることもできる。

一方でCLI側でのgit grepでは、エディター側をさっと開きにくいという問題がある。そこで、git grepの結果をfzfでさらに絞り込んだ上で選択するとすぐにエディターで開けると便利そうと感じ、git-grep-fzfというコマンドを作ってみた。

使ってみている様子はこんな感じ。grepした後にfzfで絞り込んで該当行をエディターで開いている。https://github.com/golang/go に対してgit-grep-fzf Sortedしている様子。

また、git grepに渡せるオプションはこのコマンドに渡すことができるので、複数条件で絞り込んで周辺行を見ながら開くことも可能だ。 git-grep-fzf -e slices --and -e Sorted -C 3 としている様子。

実装は以下のコードの通り。僕はCursorというエディターを使っているためcursorコマンドを呼び出しているが、VS Codeならcodeコマンドを使えば同じことができる。 https://github.com/shibayu36/config-file/blob/master/bin/git-grep-fzf

#!/usr/bin/env bash

file=$(
    git grep -n --recurse-submodule --color=always $@ |
    fzf --ansi |
    # replace - with : for line numbers
    sed -E 's/-([0-9]+)-/:\1:/' |
    # cut the file path and line number
    cut -d: -f1-2
)

if [ -n "$file" ]; then
    cursor --goto $file
fi

便利なのでご利用ください。

データ分析の基本の因果推論を学ぶため、「原因と結果の経済学」を読んだ

データ分析をやっていると、ある施策の効果検証をすることが多い。効果検証では、ある施策Aが仮説通りにある指標Bを変化させられたのかを検証したい。これはつまり「ある施策Aの実施」と「ある指標B」が因果関係にあるかを推論したいと言い換えられる。

このことからデータ分析をするには、因果推論の技術の習得が基本であると考え、「原因と結果」の経済学という本を読んだ。

「原因と結果」の経済学―――データから真実を見抜く思考法

この本は評価が非常に高かったのだけれど、その評価に違わず因果推論の技術の入門に最適だった。明示的にデータ分析担当にならなくてもエンジニアはデータを見る機会が多いので、その解釈を間違えないように読んでおくと良いと感じた。

たとえば印象に残った部分だと以下の話があった。

• 因果関係の存在を証明するためには、原因が起こったという「事実」における結果と、原因が起こらなかったという「反事実」における結果の二つの結果を比較する必要がある
  • しかし反事実の確認はタイムマシンがなければできないため、もっともらしい値で穴埋めする方法を考えなければならない
  • もっともらしい値を出すためには、因果推論したい「原因」以外の条件が揃ったもう一つの比較可能なグループを作る必要がある
  • すべての因果推論の技術は、この比較可能なグループを作ることを目的としている
• 因果関係を確認するためには、3つのチェックポイントを確認する必要がある
  • 全くの偶然ではないか、交絡因子が存在しないか、逆の因果関係ではないか
• ある実験をした前後での比較は因果関係を明らかにすることはできない
  • 時間とともに起こる自然な変化 = トレンドの影響を考慮できない
  • 平均への回帰(= 極端な値をとったあとは徐々にいつもの水準に近づいていく)に対処できない

このあたりの話をベースとして、比較可能なグループを作りだす因果推論の手法について1つずつ解説してくれる構成になっているため理解しやすかった。たとえば手法としてランダム化比較試験、差の差分析、マッチング法などを教えてくれる。

このように非常に短いページ数で、因果推論の基本を教えてくれるのでおすすめだ。データ分析担当になった人はもちろん、エンジニアやPMなどもさっと目を通すと参考になりそうだ。

読書ノート

- 因果関係を確認する3つのチェックポイント 29
    - まったくの偶然ではないか
        - 例: 地球の温暖化が進むと海賊の数が減る
    - 第3の変数(=交絡因子)は存在していないか
    - 逆の因果関係は存在していないか
- 因果関係の存在を証明するためには、以下二つの結果を比較する必要がある 41
    - 原因が起こったという「事実」における結果
    - 原因が起こらなかったという「反事実」における結果
        - 反事実 = 仮に〜しなかったらどうなっていたか
    - 反事実はタイムマシンがないと確認できないため、もっともらしい値で穴埋めする方法を考えなければならない
- 穴埋めをするには、比較可能なグループを見つける必要がある 50
    - 例: 売り上げに影響しそうなすべての特徴が似通っていて、2つのグループの唯一の違いは「広告を出したかどうか」だけなら、比較可能
- 因果関係を明らかにするための方法は、全て「比較可能なグループを作り出し、反事実をもっともらしい値で置き換える」ことをしている 53 ⭐️
- 因果関係を証明する方法: ランダム化比較試験 80
    - 対象となる人々を、乱数表などで介入群（事実）と対照群（反事実）にランダムに割り付ける
- 因果関係を証明する方法: 自然実験 96
    - 対象となる人々が、制度の変更、自然災害などの「外生的なショック」によって、介入群と対照群に自然に分かれてしまったという状況を利用する
    - 観察データから「あたかも人為的な実験が行われたかのような」状況を見出す
- ある実験をした前後での比較は因果関係を明らかにすることはできない 106
    - 時間とともに起こる自然な変化 = トレンドの影響を考慮できない
    - 平均への回帰(= 極端な値をとったあとは徐々にいつもの水準に近づいていく)に対処できない
- 因果関係を証明する方法: 差の差分析 102
    - 介入群と対照群において、介入前後の結果の差の、さらに差を見て因果効果を判定する方法。ただし元々のトレンドが同じ、介入のタイミングで別の変化が起きていないという2つの前提条件あり
    - 使える前提条件
        - イベントの前のトレンドが平行である 114
        - 指標に影響を与える「別の変化」が起きていない 117
            - 例: Aにだけ指標に影響を与えるドラマが放映されていた
- 因果関係を証明する方法: 操作変数法 138
    - 「原因に影響を与えることを通じてしか結果に影響を与えない」という操作変数を用いて、介入群と対照群を比較可能にする。前提条件は2つで、操作変数が原因には影響を与えるが結果には直接影響しない、操作変数と結果の両方に影響する第4の変数が存在しないこと
- 因果関係を証明する方法: 回帰不連続デザイン 155
    - 恣意的に決定されたカットオフ値の両サイドで、介入群と対照群が分かれる状況を利用する。前提条件は、カットオフ値の周辺で結果に影響を与える他のイベントが起きていないこと
    - 例: 従業員が50人を超えた店舗でだけ広告を出せるケース
- 因果関係を証明する方法: マッチング法 175
    - 結果に影響を与えるような共変量を用いて、対照群の中から、介入群によく似たサンプルをマッチさせて比較する。複数の共変量があるなら、それらをまとめたスコア（=プロペンシティ・スコア・マッチング）を使うこともある。マッチングが成り立つ条件は、結果に影響を与えるような共変量が全て観察可能であること
- 因果関係を証明する方法: 回帰分析 182
    - 原因と結果に最適な線を引くことで、因果効果を推定する。ただし交絡因子が存在していないことが条件
    - 交絡因子が似ている人の中で、回帰分析を行うと影響を取り除ける = 重回帰分析
        - 飲酒と肺がんの因果関係を見つけたい -> 喫煙量が同じ人の中で飲酒量が多い人と少ない人を比較し、肺がんのリスクが異なるかどうかを調べる
        - ただし中間変数を取り除くと本来の影響を過小評価してしまうので注意 191
- 因果推論のステップ 196 ⭐️
    - 1. 原因と結果を明確に定義する
        - 原因として広告をとっても、広告料なのか、掲載面積なのか、もしくは単に出したかどうかなのか
        - 結果として売上でも、売上高なのか営業利益なのか
    - 2. 3つのチェックポイントの確認
        - 全くの偶然ではないか、交絡因子が存在しないか、逆の因果関係ではないか
    - 3. もっともらしい値を使い、反事実を作り出す
        - 広告を出した時と比較するため、広告を出さなかった時という反事実を、もっともらしい値を使って作りだす
        - 手法は書籍で紹介されたもの