(第1回)開発生産性Conference参加記
SET/SREとして先月6月よりウイングアークにジョインした斎藤です。近年ホットな話題として“開発生産性”が注目されていますが、ついに今月「 開発生産性Conference 」が初めて開催されました。参加できた9コンテンツの中から、会場限定だったKeynote、そして自分が良かったと思うコンテンツの感想をまとめました。私の認識違いもあると思いますので、マサカリお待ちしております！
(会場限定Keynote) From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework
要約
- DORAがやってきた研究によってFour Keysが見出され、最新研究としては”SPACE”というフレームワークが有効とわかったよ
- 「リードタイム・デプロイの頻度・平均修復時間・変更失敗率」のFour Keysは、それぞれに相関がある
- 自分たちがどの位置にあるかは、 このサイト を使うと簡易的にわかる
- 生産性の要素を包括的に捉えるためのフレームワークとして”SPACE”を発見した
・ 満足と幸福(satisfaction and well being): どの程度、満たされ、幸福で、健康的か
・ パフォーマンス(performance): 一連の仕事量
・ 活動量(activity): 行動や仕事の回数
・ コミュニケーションとコラボレーション(communication and collaboration): どれくらい人と話して一緒に仕事をしたか
・ 効率性とフロー状態(efficiency and flow): 邪魔や介入が最小となる仕事をすること - Four KeysはSPACEの一部
・ リードタイムは、”効率性とフロー状態”と関連
・ デプロイ頻度は、”活動量”と関連
・ 平均修復時間は、”効率性とフロー”と関連
・ 変更失敗率は、”パフォーマンス”と関連
・ (可用性は、”パフォーマンス”と関連)
2. 文化を変えることで行動を変容出来るというのが先行研究だったけど、行動を変えることで文化も変わるよ
- これまでは、文化を変えることで一人ひとりの行動が変化すると考えられてきた
- 一人一人のやり方を変えることで、その人の価値観が変わり文化が変わっていくという、逆方向の変化が見出された
3. 直近気になるトピックスは、AI使うと開発体験めっちゃいいことと、リモートワークが一番生産性高い件だよ
- AI利用すると、開発体験が良いらしい
- リモートワークが一番生産性高いらしい
感想
“開発生産性”をバズらせたベストセラー『 LeanとDevOpsの科学 』の筆頭著者Forsgren, N.による基調講演。残念ながら自分には字幕の切り替えが早すぎて、講演の内容がちゃんと理解できませんでした。自分の英語力の駄目さに目を背けて海外の登壇者の講演が理解できないというのを、一体何度繰り返すのか…orz 。英語勉強ｼﾖ…。
SPACEについては初耳でした。日本語の記事でもそこまで多くはヒットしませんね。この2つの記事くらいでしょうか。
- 開発者の生産性を測るためのフレームワークSPACEについて | r-kaga’s log
- PR数から「SPACEフレームワーク」へ、技術組織の成長と共に進化した開発生産性の計測手法 | Developers Summit 2023 セッションレポート CodeZine
やり方を変えることで価値観が変化し、文化が変わっていくという話は、自分にとってはとても励みになりました。開発部の人たちと一緒にこれまでのやり方を刷新して開発体験を高めていくことで、高品質の製品を早くユーザーに届ける文化を作り上げていきたいですね！
参考資料
(会場限定) Four Keysを超えて〜信頼性はいかに開発生産性を高めるのか〜
要約
- 計測指標が4つというのは2017年までの話で、最新2022年バージョンでは「信頼性」が追加されて“Five” Keysになってるよ
- 『 LeanとDevOpsの科学 』によって4つの計測指標(リードタイム・デプロイの頻度・平均修復時間・変更失敗率)が有名になった
- この本は2017年出版で、2018年以降もGoogle主導で研究は進んでいる
- 2018年には既に「可用性」が5番目の指標に追加、2022年に「信頼性」に名称変更
- この追加指標によって、“デプロイ後の運用期間”を計測・評価することが出来るようになる
2. 信頼性の計測指標としてはサービスレベル指標とサービスレベル目標を基準にすれば良くて、その計測式を例示するよ
- 信頼性を測る指標は多種多様(レイテンシー、スループット等)
- O’Connor and Kleyner(2012)の信頼性の定義から、サービスレベル指標(SLI)とサービスレベル目標(SLO)に着目
- SLIを下記式で表すことでSLOも定まる(例えば”4週間で99%以上”など)
SLI = ( (良いイベント数) / (全イベント数) ) * 100%
ただし、良いイベントとは、2xx, 3xx, 4xx(429 Too many requestを除く)のレスポンス数。
全イベントとは、全レスポンス数。3. 信頼性が計測できると「エラー予算(Error Budget)」という考えが生まれて、実験的なリリースをする判断材料になるよ
- SLOが決まると、「その範囲内なら悪いイベントを返しても良い”予算”(Error Budget; エラー予算)」として扱うことが出来る
- エラー予算の消費速度を見ることで、チームが「速度」と「安全性」のどちらを取ればよいかの判断材料になる
- 詳しくは登壇者が和訳した今月出版の『 SLO サービスレベル目標 』を見て
感想
参加したコンテンツ全ての中で一番良かったコンテンツ。お前らの知識は古いぞとマサカリを投げられて、「ウッ！」とやられてしまいましたw明日からでも計測できるようなわかりやすい計測式も提示した上で、他の指標にどう影響するかという話まで扱うパーフェクトな発表でした。ファイル同期がうまくいってなかったようで、最初5分ほどスライドが動かなかったのはご愛嬌。
参考資料
The Metrics Key: Connecting Product, System, Team
要約
- 実は全て計画通りに終わる開発って3%くらいしかなく、「不確実性が高い」ことを理由にみんな計画・計測・学習を怠っていると思うよ
- 100人月未満・100～500人月・500人月以上のPJ規模毎に、工期・予算・品質の3指標について遵守度や満足度を測った調査がある
- その調査では、工数遵守PJは全体の34.4%、予算遵守PJは全体の37.0%、品質満足PJは全体の23.0%となり、確率で考えると全て予定通りなPJは全体の3％となっている
- 計画通りに行かなかった理由の結果を考察すると、計測・学習が足りてないように見受けられる
- 言い訳せずちゃんと計測し、予測モデルを作ろう
2. DMMでは開発部内に留まらない計測をしていて、4階層で計測してるよ
- 事業の価値: 売上、競争優位性(シェア率)
- プロダクトの魅力: UI/UXの良さ、機能の優位性、ユーザーからのフィードバック
- システムの装置: 稼働率・レイテンシー、crash free rate
- チーム生産性: リードタイム、有効稼働率、仮勘定レポート
・ リードタイム: コードを書くところからマージするまでの時間
・ 有効稼働率: 新規開発・保守運用・非開発を比率に表し、開発比率目標を社員60~70%委託80%に設置
・ 仮勘定レポート: 工数・工期・費用のレポート。どういった成果物をどのくらいの金額感で出したかを計測
3. 誰のための計測を考えることも大切だよ
- 開発生産性と言っても、見る人によって指標は変わる
・ 開発チームから見た開発生産性は、どれだけ早くリリースするか
・ 経営層から見た開発生産性は、コストマネジメント - リードタイムは現場向け、
有効稼働率は現場・マネージャー向け、
仮勘定レポートは管理監督者向けに計測
感想
見積もり不得意な自分には、言い訳せずに毎度測って見積もり精度上げろやという主張はぐさっと刺さりました。ﾃﾞｽﾖﾈｰ。
開発生産性といえばFour Keysみたいな脊髄反射的回答をしがちですが、ちゃんとビジネス面から見た開発生産性の指標を取るという姿勢は見習わないとなと思いました。そもそも新しいことを取り入れる理由としては「開発生産性が上がるという口コミがあったから」でも良いわけで、何故数値をわざわざ取るのかというと他部署とバトルするためなわけですよね。ビジネスを大事にするDMMらしさが垣間見えた瞬間でした。
仮勘定レポートの計測機構を開発が作ってるのか～というのがちょっと意外でした。そういうのって経営層が自分たちで作ってるのかなーと思ってたけど。まさか世の中の経営層はこれを計測してないなんてことは…ないよね…？
参考資料
なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜
要約
- SREだけじゃなく開発にも生産性向上に参画してもらいたかったけど、SREと開発で取り組みへの姿勢に差があったよ。
- 2018年からSRE発足したが、最初の改善はインフラ側に寄りがち
- 開発側に近いE2Eテスト、アプリコード、テストコードに対しては改善活動が出来なかった
- 開発者と一緒に全員で改善活動を行いたかったが、開発者からの反応は冷ややか
- どうすれば全員が主体性を持って改善活動に取り組めるかが課題
2. WHYの言語化を行うことで、改善活動がより意味のあるものになっていったよ。
- 改善になってない活動として事例2件を紹介
・ 事例1: プルリク作成後1ヶ月放置、レビュー時にプルリクを作り直してリードタイム改善(？)
・ 事例2: リリース作業に工数割かれて辛いけど、デプロイ頻度を5回/週に改善(？) - 数値を達成することが目的になっている
- 数値は変更しても良い、あるべき姿を見つける事が必要
3. 他には、改善のための明確な責務を決めること、一時的でも改善したいチームに加わること、改善のオーナーシップをチームに移譲することが大切だよ
- 改善活動に興味ある開発者をピックアップし、個人目標・評価に組み込むのが良い(ボランティアではダメ)
- 外からヒアリングしてもわからないことが、一時的にチームに異動することでわかることもある
- 可視化したものをミーティング内で必ず見るようにすると、オーナーシップを持ちやすい
感想
エンジニアが数値目標をハックしてしまい、改善活動が改善に繋がらないという事例を知れたのは良かったです。開発生産性の計測は日々行うことだからこそ、一時的にストレスかけて無理やり目標達成しても駄目で、高い生産性が自然と続くような仕組みを作らないとな～と改めて思いました。
あとはちゃんと評価に組み込むというのが良いですね。評価される側としてはちゃんと評価してくれないとやる気失うし、評価する側にとっても約束してないことを押し売りされても困る。活動の前にちゃんと互いに約束する姿勢は本当に大切。
参考資料
(会場限定) 大手企業の開発内製化事例 〜東急×KINTOが語る内製化の3ステップ〜
要約
- 両者とも内製を選んでPJを立ち上げたが、立ち上げ期では大企業(東急・トヨタ)ならではの問題があったよ
- 両者とも内製を選んだ理由は、ユーザーへの価値提供を迅速に行いたいから
- 中小企業よりも説明をしっかり問われるため、KINTOでは内製の必要性を上司に訴え続けて洗脳した
2. 成長期では、両者とも上手く組織化してアウトプットを最速で出せるようにしてるよ
- 東急では、マネージャー不在でシニアエンジニアが自律分散型でアウトプットし続けてる
- KINTOでは、事業側とエンジニア側と双方に付き合い方を教えるところから始めた
- 事業側にはとにかく話を早く持ってくるようにさせ、エンジニア側はMVPを早く出させた
- MVPを出していくと、事業側の欲しい物がどんどん変わる
3. 将来の成熟期では、これまで通りの組織拡大はできないと両社とも感じているよ
- 東急では、「エンジニアにとって楽しい組織であること」は変えたくない
- 一方で、ジュニア・第二新卒層が入ってきたら今まで通りでは上手くいかなそう
- KINTOでは、中途採用者のためにノウハウを言語化中、新技術も積極的に取り入れている
- 将来的にはPMOを作って、各PJの見える化と事前の対処できるようにしたい
感想
生産性の向上というとエンジニアはとかく技術でなんとかしようとしがちですが、適切な組織作りやPJのマネジメントでも生産性は向上できるという、エンジニアにとっては盲点の話だったと思います。事前に上司を味方に取り込んで、昔の話を蒸し返す系の”戦い”を略したというエピソードは、とても面白く感じました。ある意味で、スタートアップは説明責任を犠牲にしてプロトタイプ作成の速度を上げているのだなぁと、改めて思いました。
MVPを出すと欲しい物がどんどん変わるというのは、とてもうまく開発サイクルが回っているなぁと感心しました。MVPかくあるべし。
参考資料
(会場限定) AI・クラウドの発展がもたらす生産性の向上と開発者体験の未来
要約
- Developer eXperience Day 2023の講演 と7割方一緒だったので、こちらをご覧ください。
- AI開発に関しては、3つの層が今後考えられるよ
・ App側
・ AIオーケストレーション
・ 基盤モデル - 専用のプラグインを汎用AIに繋ぐことで、より専門的な支援が得られるようになるよ
感想
MicrosoftのCopilotシリーズのデモ動画を存分に生かした講演だったと思います。スケッチ絵をAIに読み込ませるだけでウェブアプリが作れてしまう未来を描いた動画は、なかなか熱くなるものでした。AIのオーケストレーションはなかなか面白そう。
余談だけど、人数が減ったせいで会場の空調がめっちゃ寒かった。長袖パーカー着てた自分でも寒いくらいで、半袖の人はみんな腕さすってた。夏のオンサイトは空調が鬼門ですよね。
参考資料
まとめ
開発生産性に関する各社の取り組み、大変勉強になりました。本気で取り組んでこそ効果も期待できる施策だと思うので、しっかりと向き合っていきたいですね！
