概要

日程: 2023年7月13日 (木) 10:15 ~ 19:00
会場: KABUTO ONE（東京） ＋ オンライン配信

ハッシュタグ: [#開発生産性con_findy]

申し込みだけで1,500名 ※64%以上がエンジニアリーダー
34名のスピーカー
13社のスポンサー

開催概要説明

[開催背景]

1. 開発生産性/Four Keysへの注目の高まり

2. エンジニア組織への投資額の増加

• 組織の大規模化

• エンジニアの年収増加

3. エンジニア採用に開発生産性が求められる時代へ

• 8割弱のエンジニアが求人応募時に開発生産性を重視している

タイムテーブル

Keynote

10:30 ~ 11:30

[DORA - quick review]

DORA 4 metrics measure speed and stability

• Lead time for changes

• Number of deploys

• Mean time to recover

• Change fail rate

SIGNAL: 現状評価

ACTION: SIGNALに対する改善アクション

SPACE: DORAに対するメトリクスを選ぶフレームワーク？(ちょっと理解できなかった)

SPACE Frameworkについて書いているサイトを探してみたので後で読む

1on1を増やすとコーディングの効率が良くなる？(みたいな発言があった)

[Good Day Project]

個人開発者に対して質問を取った(メモ取れなかった)

[心理的安全性]

心理的安全性がある環境では優れたパフォーマンスを出すことができる

誰の意見であろうと優れた意見を取り入れ、検証してみるべき

[GitHub Copilotの事例]

AI支援プログラミングを使用する開発者は仕事のやり方が根本的に変わる

コードを書くとそれなりにレビューの時間も発生する
→これ以降ちょっと聞き取れなかった

[リモート・ハイブリットワークの課題]

ミーティングが多過ぎる

非効率なやり方を昔からの習慣で続けている

[Q&A]

英語でのやり取りでほとんど分からなかった・・・

QAセッションはSlidoというサービスを使用してリアルタイムに投票し、多い順で質問をしていた

Q: これから開発生産性について取り組むなら何からすべきか？
A: 一番最初はソースを見ること。データを集めて課題を発見する

Q: 経営者(エンジニアに対する知見が低い人)にどうやって可視化の重要性を伝えるか？
A: なぜ重要なのかを伝えたいなら、彼らの知っているもので例える。グラフなどで可視化する

Q: 1on1の回数を増やすとコーディングについて良くなるとの研究結果があるとの話がありましたが、一度の1on1の時間はどれくらいのものをたくさん行うイメージなのでしょうか。
A: バランスが重要。多過ぎても良くない。1,2週間に1回が良い。マネージャー、メンバー同士でもやると良い

Q: リモートワーク、ハイブリッドワークの廃止はスタートアップ企業やそこまで大きくない企業で進んでるのでしょうか？(Googleなどの大企業で廃止しているため)
A: データがあるわけじゃないが、一定数リモートワーク、ハイブリッドワークをしているらしい

生産性向上に自ら取り組むチームカルチャーが生み出す顧客価値

12:10 ~ 12:40
ホールB

ログラスさんは日本CTO協会主催のイベントで「開発者体験ブランド力」評価の高い会社として表彰

なぜ取り組もうと思ったのか？

現在は開発3チーム + プラットフォームチーム

[開発チームの概要]

• PdM/デザイナー/エンジニア/QAで構成

• スクラム

課題が上がってきた

• 開発着手からリリースまでデリバリーに時間がかかった

  • リードタイム、デプロイ頻度

• ビッグバンリリースになってしまった

  • リードタイム

• 変更失敗が複数回起きてしまった

  • 変更失敗率

  • 品質を上げるために数週間新規開発を止めていた時期がある

お客様に価値を届けるために品質を担保しながらチームで開発生産性の改善を進めることにした

改善実施

•  開発スピードの向上

  • エピックから小さなストーリーに分割する

    • 「良いケーキの切り方」

    •  チーム内に知見がない時は他のチームの知見を借りてストーリーの分割の仕方を練習

  • ペアプロの導入

    • 新規メンバー参加時に知見を伝達できる

    • 相互レビューで実装方針や設計標準の知見共有ができる

  • Find Team+を活用してサイクルタイムをトラッキング

    • 社内勉強会でFour Keysを指標にするとよさそうとの示唆

    • チームのOKRとして設定、週次で改善アクションを試す

  • フィーチャートグル、ユーザーロールを活用する

  • プルリクを小さくする

• 品質の向上

  • チームで品質のシフトレイトに取り組む

  • スプリントプランニング時に「テスト設計」を実施する

  • 「ソフトウェアテスト技法ドリル」を解く

どのような変化が起きたか？

• サイクルタイムが改善

  • Findy Team+で可視化

  • 約260時間→約32時間に改善

• 「お客様への価値提供向上」に目を向けられるようになった

  • お客様からも改善された機能についての喜びの声をいただいた

  • CSの皆様からも喜びの声

チーム力を上げるために取り組みを実施

• 関係性システムコーチング

  • DTA (Designing Team Alliance)

  • ハイドリーム・ロードリーム

• ドラッカー風エクササイズ

  • 自分の得意なこと、大切に思う価値などの共有

チームのカルチャーが形成されていく中で開発生産性の向上、お客様への価値提供の向上が行われていった

まとめ

• チームカルチャーは重要

  • 自律的に開発生産性向上、改善活動の原動力となる

  • 褒める文化は心理的安全性が高まる

  • 価値観が形成されるとオーナーシップを持って進めやすい

• 開発生産性の向上には指標をトラッキングし続けることが重要

  • オーナーシップを持って継続することが重要

• 他チームとの協力は不可欠

  • 知見のある方を巻き込むことでチームが強くなる(QAエンジニア、CS、EM、SRE、etc…)

なぜ Four Keys を改善するのか？〜How ではなく Why を重視したメトリクス改善活動〜

12:45 ~ 13:15
ホールA

チーム構成

• 3つのプロダクトからなる複数のチーム

• 改善活動はSREチームが推進してきた

  • SER = インフラが強いメンバー

まず先にコンテナ化などのインフラを中心に改善しがちに。
→改善は一人でやることじゃないのでみんなでやりたい！

中央集権的な改善
→各チームの要望をSREが吸い上げて改善を行う

課題

お互いの主体性の偏り

• 生産性改善したいけどリソースがない

• SREチームは全てのコードを把握しているわけではない

どうすれば全員が改善活動をできるか？

改善

[Whyから始めよう]

NG例

• リードタイムを縮めることが目的になっている→なぜ縮める必要があるのか？

Whyから始めると

• みんなが能動的に活動できる

  • 人は「何」ではなく、「なぜ」に動かされる

• 目的を見失わないために

チームの目標に「デプロイ頻度 = High」が入る
→一日一回デプロイ = 週で5回

実際に週3,4回になったが・・・

• リリース作業に3時間くらいかかっていた

• リリースする人に偏りがある

なんでこんなに大変な作業をしてまでデプロイ頻度を上げたのか？
→逆に生産性下がっていないか？

結局は2回に落ち着いた

デプロイ頻度、リードタイムを改善すると何が嬉しいのか？

• デプロイ回数が多い = 生産性が多い？

  • 少ないと一度のデプロイに複数のfeatureが入る

  • マイグレ等の巻き戻しに時間が掛かる

  • feature = デプロイになると理想？

  • デプロイ回数が多い→安全な切り戻し→切り戻しの時間が減る

• リードタイム

  • マージまでの時間がみじか→単に分割してマージしただけかも・・・

  • リードタイムの定義はFirst Commit→マージされるまでのタイム

  • リードタイムは機能単位ではなく、PRの単位

  • PRが小さいとレビュー&テスト品質が上がる

  • コードの1行までレビューができる

  • 変更に対して最小のテストを実施(テスト工数が減る&品質が上がる)

  • コンフリクトしない

• リードタイム短縮の目的

  • 障害を減らしたい

  • (他数個あったけどメモ取れなかった)

チームの壁を越えて一丸となって解決する

各チームから横断的に生産性向上をやりたい人を募った: 改善チームの結成
→個人目標として入れたりする

片手間だと進まないため、「仕事」として役割を明確にする

改善のオーナーシップをチームに

中央集権での改善は組織が大きくなると限界がくる
→理想は各チームでオーナーシップを持ってやること

チームごとに計測&改善のプロセスをインストールする

• メトリクス計測の自動化

• 改善運用/プロセス

• Whyから始める思想

最後に

• 開発生産性の活動に銀の弾丸は無い

• メトリクスが低い原因は一つではない

• メトリクス値から生産性課題を見つける

Four Keys改善だけはない。ZOZOTOWN/WEARの開発生産性向上の取り組み

13:20 ~ 13:50
ルーム1

背景

案件の渋滞→経営層を交えてディスカッション→ユーザーへの価値提供を増やしたい

ZOZO TOWN

可視化に向けた取り組み

リリース案件数→リードタイム

今はリードタイムを減らすことで以下に捌ける量を増やせるか？を改善中

可視化をする上で難しかったことは？
→レベル1、レベル2の生産性可視化を行いたい

何を可視化するのかの選定が難しい

うまくいかなかった施策は？
→Findy Team+を導入したが、組織として浸透しなかった

個別でチームごとにフォローすることで対応した

WEAR

[フェーズ1:  開発生産性向上に向けた計測の土台作り]

開発生産性3倍→プルリククローズ24h→計測しよう！

一般的にデプロイ頻度が高い = 生産性が高い

[フェーズ2: 向上の取り組み]

まずは現状把握

プルリククローズ24h→沢山・地道にトライ→レビュアーに優しいプルリク作り

レビューがボトルネックであるとの結論

生産性向上において、銀の弾丸はあるのか？
→無いのではないか。複数の施策で複合的に上がっていくイメージ

地道にコツコツとトライしていくことが大切。

[レビュアーに優しいプルリク作りとは？]

• プルリクを出してレビューする意味とは？

  • 品質を上げることが目的

  • それなのにレビュアーに雑に渡しては意味が無い

• 粒度を細かくすることが重要

  • チケットの粒度では開発者目線を入れることは厳しい

  • JIRAの場合はサブタスクがあるため、そこで細分化する

  • ex.) フォームを作るなら入力ボックスを作るサブタスクを作る

• PRのタイトルを見れば何をレビューすれば良いかが分かるのが理想

取り組み結果

プルリククローズ時間の変化: 237h→30hまで改善

QAセッション

Q: 各チームに価値を説明しその時は利用してくれても、時間が経つにつれて形骸化したりしないのかな？一時的なものではなく文化にしていくためにやったこととかあるのかな
A: 1on1、振り返りのタイミングで伝えるようにする

Q: PRを小さくし過ぎると関連性が分かりにくくなったりしないか？
A: PRテンプレートを使うことで必ず親タスクを関連付けるようにする

Q: タスクの細分化（サブタスク化）をしていくのは、開発者の力に依存するところもあるのかなと思います。この点についてはどのように解決しましたか？
A: ペアプロをするなりして切る粒度を伝えたり相談したりする。そうすることでメンバーが細分化する力が付く

Q: サブタスクとしてチケットを細かく作ると言うお話ですが、だんだん沢山作るのが面倒になってくるなどの問題は起きていないのでしょうか
A: バランスが重要。意味のある単位で。コミットと同じイメージ。細分化するコストは発生するが、それ以上にレビューする側が楽になるメリットがある

Q: ペアプロ、モブプロで開発した場合、レビューもかねることができて、レビューまでのクローズ時間は短くなると思いますが、ペアプロ、モブプロについてはどう思いますか？
A: どんどんやるべき。但し、強制するべきでは無いという考え。

大手企業の開発内製化事例 〜東急×KINTOが語る内製化の3ステップ〜

14:00 ~ 14:45
ホールA

東急株式会社

どんなことをしているのか？

• 都市開発: 不動産

• 交通: 鉄道

• 生活サービス: 百貨店

• ホテル・リゾート

[目指す世界]

デジタルをどう取り組んで事業を発展させるか？が今の課題

人々のライフスタイルを支えるデジタルプラットフィームを組み合わせたまちづくり
→リアルとデジタルが連動する

東急グループの資産をハックして、より豊かな暮らしをつくる

130社の子会社全てをデジタルで繋ぐ

サービスに必要なデリバリーを回せる体制を全て内部で賄うように改革中

KINTOテクノロジーズ株式会社

トヨタの子会社

社内にグローバル開発部隊がある→ドキュメント、コミュニケーション全て英語

[プロダクト]

• グローバルKINTOアプリの提供

• グローバルIDプラットフォームの提供

• KINTOシステム(ex. カーシェアシステム)のグローバル横展開

トヨタとしては珍しく、内製化を行なった

開発内製化組織づくりと開発生産性

[立ち上げ期]

• 東急

  • 内製化は一つの手段

  • ユーザーサービスを改善することが成長に必要

  • 内製化してやり続けていく覚悟が必要だった

  • まずは小さく初めて、見えてくる課題を解決しながら大きく成長を目指す

• KINTO

  • トヨタにいるとちょっとしたシステムでも1年~半年くらいかかってしまう

    • それではダメだとなって内製化がスタートした

  • キーマンになるような方々に3ヶ月くらいインプットした

    • 理解を得て貰う活動をした

[成長期]

• 東急

  • まさに今成長期の段階

  • 組織としては上手くいっている

  • マネージャーの居ないフルフラットな組織(あまりお勧めしない)

    • 最初からミドルクラス以上を集めたらしい(50人程度)

    • 結果としてスピード感は持てた

    • しかし、100名以上になった時にどうなるのか？

• KINTO

  • ビジネスサイドとの関係性が問題になってきた

  • ビジネスサイドは「発注者」の意識

  • 内政開発部隊との付き合い方を教えていくことが必要

[成熟期 or 未来構想]

• 東急

  • 「エンジニアの理想郷を作る」を明言している

  • エンジニアが楽しく仕事ができている状態が生産性が上がる

  • チームを信頼し、メンバーを信頼し、やりたいことができている状態

  • 新卒採用、ジュニア採用をしながら理想を作る挑戦が必要になってくる

• KENTO

  • 「内製開発スタイル」の働き方を言語化して浸透させている段階

    • 外注と内製はどう違うのか？を理解する

  • いかに新しい技術で勝負できるか？

    • 勉強会を頻繁に行なっている

開発生産性に対しての取り組みと組織づくりの課題

• KENTO

  • ビジネスサイドとの共有が大切

  • やりたいことに対しての実現方法、必要な工数などを共有

  • 一緒に要件定義をすることで何が必要かを理解してもらう

  • 勝手に見て、勝手に理解してもらう仕組みづくり(JIRA、GitHubに公開)

  • 1チームでFind Team+を導入して改善してきたところ、他チームも興味を持つようになった

• 東急

  • 色々な新しいツールをボトムアップで入れられる環境づくりが重要

  • 色々なツールを試して取捨選択していく

メルカリ×DeNAの考える開発生産性とは？〜専門チームが推進する可視化の取り組み〜

15:00 ~ 15:45
ホールB

メルカリ、DeNAの考える開発生産性の本質的な目的

• メルカリ

  • 一言で言うと、ビジネスの成功のため

• DeNA

  • ちゃんと見える化することで課題に対する本質的なアクションを取れるようにする

可視化の取り組みにおいて陥りやすい課題

開発生産性が高い状態とは？

• DeNA

  • dev-vitalチーム(横断的な取り組み): 課題の予防、早期発見、改善ができている状態

  • Pococha: 変化に対して柔軟に対応できる状態

  • Pocochaは何でこの取り組みをするのか？を動画で共有したりしている→文化の醸成

  • Four Keysを取っているか？→取っている

    • JIRAがデータソース

• メルカリ

  • 継続的かつ高速に、プロダクトの価値提供ができている状態

  • KPIを設定しているか？→Four Keysに沿って検討中

    • まずはデプロイ頻度

可視化するまでの準備にどのくらいの工数が必要か？

• メルカリ

  • DevStats Product(内製した計測ツール)を使用している

    • GitHub

    • Deployment Tool

    • Incident Management Tool

  • 1Q(3ヶ月)くらいの工数が掛かった

• DeNA

  • 内製ツール

    • スプリント内で消化したポイント(ベロシティ)

    • チケットのステータス遷移時間

    • リリース頻度

    • 変更障害率と復元時間

  • 3ヶ月程度掛かった

    • 項目の定義に時間が掛かった

「可視化した(だけ)」で終わらせないためにはどうしたら良いか？

• メルカリ

  • なぜ可視化するのか？改善することが目的であることを意識する

    • 可視化することが目的ではない

    • 事業を達成するためにはどの数値をどうすべきか？を考える

• DeNA

  • 可視化したその先にやりたいことがあるはず

  • 数値を取った上でそこから改善を回す

(組織が大きい・技術負債が多い等の理由で)可視化するのも難しい場合、何から取り組むべきか？

• メルカリ

  • まずは大まかなデータを取る(サーベイ)

  • 1つのデプロイがどれくらい掛かっているか？は取れるはず

  • 人力で測定するとかでも

  • 兎に角取れるところから取ってみる

• DeNA

  • 開発プロセスそのものを可視化する所から始める

  • PFD(プロセス・フロー・ダイアグラム)を取ってみる(計測を始める準備)

  • どの作業が並列化できるかが分かる

  • 新しい人が入った時にどんなことをしているかが分かりやすいです

可視化している指標を評価に紐づける場合のデメリットは？

• メルカリ

  • 評価では使っていないし、使わない方が良い

  • 数値が目的になると障害を隠したりもできてしまう

• DeNA

  • 数値が良くなることは良いことだが、良くするためにチームでどう取り組んだかが重要

QAセッション

Q: JIRAベースで管理するに当たって、ちゃんとステータス変更してもらうために工夫していることはありますか？
A: 朝会でJIRAの看板を見ながら行えばステータス変更漏れは無くなる。可能な部分ではオートメーションを入れる(PRマージのタイミングとか)

Q: 生産性指標の変化に意味があるか判断するのに見る方の経験値に依存する気がするのですが、その経験値を上げる施策などは何かやられていますか？A: チーム単位で改善を行なっている。

Q: メルカリさんのリードタイムの測定単位がPRの作成からマージまでとなっていました。本来のfour keysで定義されているコミットからマージまでではないのは、社内的な目標からの逆算で決めるなどした結果なのでしょうか？A: 現状はそうなっているが、取れていないタイミングも含めて本当は取りたいと思っている。

Q: チーム単位で見た方がいいと思いつつ、どうしても個人のやる気的な問題もありそう、個人に問題がありそうな場合はありましたか？もし、あった場合どうされましたか？
A: やる気が無いという問題に当たったことは無いが、モチベが上がらない要因が組織または個人にあるとしたら1on1で解決すべき。個人じゃなくてチームの責任。

これからのソフトウェア開発　"GitHub x AI" による生産性革命

16:15 ~ 17:00
ホールA

テーマ

• テクノロジー

• 文化

• プロセス

• トランスフォーム

  • 生産性の高い成果物

ある会社の事例

• 開発者が最初にコミットするまでの時間

• インナーソース貢献

• 漏洩したシークレットとコードの脆弱性

  • 全部終わってからどこかにアウトソースしている

※メモ取り切れませんでした

開発者のワークフローへのセキュリティの取り組み

• Security Overview

  • 公開してはいけない環境変数を入れていないか？

  • 間違えて漏洩していないか？などを検知できる

ソフトウェア開発者の集中力を高める。ゾーンに入りやすくなる

集中力: 10,45,90の法則
→GitHubは集中できるようにすることを重視している

AIの登場

constant flow == happiness

• オンボーディングにかかる時間を最小限に

• コンテキストイッチを最小限に

• 優れたソフトウェアを作るためには集中力が必要

Inner dev loop

• Code Search: コードの検索が優秀

• Codespaces: クラウド側で環境構築が完結

• Copilot: AIによる補完

GitHub Copilot

あくまでもドライバーは開発者自身で、Copilotが副操縦士
Copilotの提案を見て受け入れるか否かを判断するのは開発者というコンセプト

Copilotの何が一番良いか？
→何よりも楽しい。AIの導きによって生産性が上がる

ZOZOさんのCopilot全社導入のお話

[機能紹介]

• GitHub側でCopilotの登録をしていればVSCodeの拡張機能として入れるだけ

• コメントでガイドをするだけでCopilotが提案してくれる

• 標準関数やHTMLのタグを提案してくれるからドキュメントを見に行かなくても良くなる

• CSSにコメントで要件を書くだけで提案してくれる

[新機能]

Copilot X

Chat

• 既存コードの把握・改善

• プロトタイピング

• コラボレーション(レビュー)

チャットの入力欄は拡張機能のタブはもちろん、コードにインラインで入力も可能

• リファクタリングもやってくれる

• 選択したコードに対して単体テストを生成することが可能！

• まずはミニマムに作って、提案しながら肉付けをするイメージ

レビューコメントに対してCopilotで「提案をする」という事ができる
→AIでレビューコメントの内容を自動生成できる

Chat以外にもVoice、Pull Requests、Docsなどがある

一番の推しはPull Requestが楽になること

エンジニア1人から始めた開発生産性改善が、組織100名、経営をも巻き込んだ話

17:10 ~ 17:55
ホールB

過去のイベント

開発生産性の取り組み初期・現在取り組んでいること

[2022年の取り組み]

• デプロイ頻度を計測、改善

  • 元々週1→30回

• リードタイムの計測、改善

  • 127h→32hに短縮

[現在]

• 障害対応フローの整備・障害訓練

  • 誰でもフロー通りに行えば対応できるようにする

• SLOプロジェクトの発足

• MTTR、変更失敗率の計測開始

経営とのコミュニケーションの課題

• 開発が遅い

• 小さく作って欲しくない

• デプロイ頻度の意味が分からない

  • デプロイ頻度を高めたからどうなの？

[取り組んだこと]

• 経営チームのアジャイルマインド強化

  • 経営チーム全員をPO研修に派遣

  • 輪読会

  • 全体OKRにもフロー効率向上を標榜

• 横にナレッジが伝播する仕組み

  • プロダクトを超えたナレッジ伝播の取り組みを継続

• アワードの受賞

  • 雰囲気としての盛り上がり

経営サイドを巻き込んだ開発生産性の可視化と合意形成

共通認識として言えるようになって来ている

具体例としてGoogleが提唱しているものを提示してみたり

ただ、それが組織にマッチするのか？は小さく試していくことが大切

Q: 合意形成をする上で苦戦したことは？
A: アジャイルという言葉自体は認知してくれているため、学んで貰いやすかった。一人だと難しいけど、仲間を作ることでスムーズに進む

PdM・ビジネスサイドを巻き込む開発生産性の可視化と合意形成

開発生産性自体は開発者が管理、理解していれば良いこと

開発生産性を高めて自分達が良いチームになっているぞ！と言う事が伝えられる事が理想

(もっとお話があったのですがメモ取れませんでした)

QAセッション

Q: d/d/d(deploys / a day / a developer)を取るツールとして何かおすすめはありますか？
A: デプロイ回数を追いかけてエンジニア数で割れば良い(Findy Team+にも機能がある)

Q: 経営側からすると売上達成するために、いつリリースできるの？ってくらいの粒度感だと思います。そこでエンジニア組織の開発生産性の数字ってどう響きますか。
A: 組織が100名超えてくるといつリリースできるの？は語られなくなってくる。それよりはその人数必要なのか？が強まってくる
開発生産性が向上することによって相関して他も上がって来やすくなる

Q: 1人から始めた開発生産性改善というところで、一番最初に着手したのはどんな事だったのでしょうか
A: デプロイ頻度が一番取りやすい。GitHubのログから取得してスプシにまとめる所から始めた

Q: SREチーム起点でSLO設定を進めていらっしゃるとありましたが、ビジネスサイドの巻き込み方に工夫や苦労された点はありますでしょうか。
A: SLOはエンジニアが意識することではなく、組織全体が追うべきこと。
組織全体が追うべきということを理解してくれればスムーズに進む。

Q: ROIについてと、開発生産性のあいだにあるギャップをどう思いますか？
A: 何人採用すべきか？が問われる部分。
現在Copilotを導入して生産性が上がったかのアンケートを取っている。

(他の発言はメモ取れませんでした)

大規模言語モデル時代の開発生産性

18:05 ~ 18:50
ホールB

まずは宣伝

そもそも生産性とはなんなのか？
ソフトウェアにおける開発生産性とは？

エンジニアのアイデンティティに届く問題
→定義が曖昧なままの議論は不信感を抱く

経営学的な生産性

• 物理的労働生産性

• 価値労働生産性

• 付加価値労働生産性

ソフトウェア開発のアウトプットとは？

• ソースコードの行数

• PR数

• 完了したストーリーポイント

• FPの量

• サービスの売り上げ

に対するエンジニア数
→どれも一長一短

なぜソフトウェアの生産性評価が難しいのか？
ソフトウェアはもっとも複雑な構造物

• ソフトウェアは本質的には2度同じものを持たない

• 抽象的な概念同士の関連性が物理的制約を持たない

• 複雑な構造物を抽象化によって隠蔽され、更なる複雑性を生む

開発生産効率は実際には恐ろしいスピードで高まっているが、複雑性がそれを上回る

• ソフトウェアの複雑性

• 複雑性あたりのコスト

• 社会の適用領域

開発生産性が難しい理由

• 二度と同じものを作らないので個数で評価できない

• 複雑性が増大していくと類似の機能であっても追加の難易度が上がる

• 時代ごとに同じものは簡単になっていくが、水準が高くなっていく

開発生産性の3つのレベル

• 仕事量生産性

  • PRやコード数などの作業量を評価

• 期待付加価値の生産性

  • プロダクトとしてその機能にどれだけの価値が見込まれるか

• 実現付加価値の生産性

当たり前の話だが、開発部門だけで売り上げを作るわけではない。
→みんなで作るもの、みんなで上げるもの

生産性を上げる生産をどう評価するか？

機能開発が効率的にできる→十分に価値ある機能が開発できる→それが伝わり顧客に伝播する→(メモ取れなかった)

早い vs 速い

“生産性”って言いたいだけちゃうんか
→ビジネス現場で人は「よく知りもしない概念」を持ち出して、それっぽいことを言う。

ちゃんとマネジメントできてる？生産量を増やしたい？ある機能を早くリリースしたい？
→信頼関係があれば具体的に議論できる

スループットとリードタイム

→スループットは単位時間あたりに生産できたアウトプットの量。生産性という言葉で注目されるのはここ。速さ

→リードタイムは開発を開始してから市場に投入されるまでの時間。ビジネスにとっての重要性が高い

リソース効率とフロー効率

• リソース効率: 稼働率やスループットを重視する

• フロー効率: リードタイムを重視する

ソフトウェア開発における「嘘の進捗」
→ほぼ完了です、多分いけます、あと実装だけです、20%完了です

アジャイルソフトウェア宣言
→これまでの「嘘の進捗」を生み出すものから現物による「動く進捗と品質」への転換

ソフトウェア開発の本質的な難しさ(人月の神話より)

1. 複雑性

2. 同調性

3. 可変性

4. 不可視性

本質的なソフトウェアの生産性とは

• 関係者への曝露: 通信不確実性

  • 別システムとの統合

  • 受け入れテスト

  • 関係者レビュー

• 市場への曝露: 環境不確実性

  • マーケットイン

  • ユーザーインタビュー

不確実性に対してどれだけ曝露するか
→不確実性のある環境への曝露(Exposure)によって、不確実性が削除されたとき

頻度は質に転換していく

フロー効率を高める技術的投資
→頻度は「質」に転化する

大規模言語モデルで何が変わるのか？

全ての人がAIをマネジメントするマネージャーになる

AIに仕事を奪われるのではなく、AIを使いこなす人との格差が広がる。
不確実性に向き合い、本質的な問題の試行錯誤をしよう。

クロージングセッション

来年も開催したい！のお声が多かったのでまた来年もよろしくお願いします！

「Findy Team+ Award」を開催するらしい

→開発者体験が良い会社にはエンジニアが集まる、採用強化に繋がる

感想

今回初開催・初参戦でしたがかなりの参加人数で圧倒されました。
ブースもユニークでとても楽しいイベントでした！

今までは目の前の開発のことや技術について考えることが多かったのですが、転職してから人数も増えてポジションも変わったのでチームとして、組織として開発生産性を上げることを意識して仕事しようと思いました。
(もう自分のことだけ考えるフェーズは終わりだぞ！との戒めも込めて)

また、何をするにしてもなんのためにするのか？それをすることで何を解決できるのか？を日々意識することの重要さを改めて認識する機会にもなりました。

最後に、誘ったり誘われたりしたわけでも無く、エンジニアの友人やRubyKaigiで知り合った方とお会いできて嬉しかったです！

来年も参加しますのでみなさんお会いしましょう！