開発生産性カンファレンス

2023年7月15日

キーノート

シグナルとアクション

DORAは単純なシグナルなので、シグナルに対するアクションが必要。

アクション

Take the DORA DevOps Quick Check

SPACE

https://queue.acm.org/detail.cfm?id=3454124

生産性をどうやって計測するかのためのフレームワーク。SPACEとDORAはたがいに補完するがSPACEのなかにDORAがふくまれていると捉えることもできる。

DORAを使って何を改善するかを特定し、SPACEでどう改善するかを考える。

• S(Satisfaction and well-being): 環境に満足しているかどうか
• P(Performance): コードレビュー速度とか顧客満足度、
• A(Activity): コードレビューの数、コーディングの時間
• C(Communication): ナレッジの検索しやすさとか、1on1の頻度とか
• E(Efficiency):

コードレビューを高速化しようとしてとにかくアラートを増やそうとするとAはふえるけどEが減る。現状のバランスとトレードオフをどう組み立てるのかをチームで共有しながら考える。

• 何から始めるか？
  • どういうことをインタビュー、サーベイする必要があるのかを考える。
• これまではカルチャーが態度を整え、行動を決めていたけど、今は逆。行動がカルチャーをつくる。
• 中間層がいない企業だと下と上で文化が違う可能性がある。文化について考える必要がある。（⭐️）
• 何かを変えたい時に変える前と変えたあとの変化をはかる環境があるかどうか（⭐️）

フロー効率と「具体と抽象」

リソース効率は仕事A、B、Cが同時に進むので、仕事Aの経験を仕事Bに生かすことができない。

具体と抽象を行き来することで選択肢を増やし、課題解決の幅も質も向上する。

リソース効率による課題

• 全員が別の仕事をしているので、レビューコストの増加
  • 自分の理解度とコードを書いた人の理解度にギャップがある
• 他人のタスクに無関心になっていく
  • 感じている課題を言わない
  • 個人事業主の集まり
• 人によってスピードが違う
• PDMの認知負荷増加
  • 優先順位をつける暇がない

フロー効率を高めるとは何か

スクラムガイド

• バリューストリーム全体に全員が横断的に取り組む
  • 全員が全体に関わることで、いろいろな目線から各ポイントへの改善が見つかる
• 価値が高いものから先に終わらせていく
  • 仕事の価値を分割し、優先順位をつけて、1つずつ進めていける
• 透明性、検査、適応を高めてベロシティ
  • 個人のベロシティのばらつきをチームでならしていける

なぜ Four Keys を改善するのか？

なんで生産性上げるのが開発者なのか。カンファレンスも開発者むけのものがおおいし。

まずはwhyを共有する

なぜリードタイムを3日にするのか。その目的、理由を共有する。

• 推進し、人を動かすためにはwhyがききやすい
• 目的をみうしわないため

なにをチームにインストールするのか

• メトリクス計測の自動化
• 改善運用プロセス
  • チームのMTGに改善をねじこむとか
• 思想

サイバーエージェントの組織文化を活かした開発生産性への取り組み事例

Technology Map

• 各サービスがどういう技術要素で作られているのか、どういう評価がされているのか
  • チームごとに作っている
• Mission Statement

計測の単位を設計しよう

• 開発者の体感だけがよくなっても仕方ない（プロジェクトとしての改善の障害になる）
  • 競合他者より速くだせるとか、UIが使いやすくなったとか
• 顧客フィードバックを活用、MVPを定めよう
• Four Keysやってもいいけど、指標に囚われると定性的なところや文化が犠牲になることがある

大手企業の開発内製化事例

組織作りと生産性

立ち上げ期

• なぜ開発を内製化したのか
  • 顧客との接点が多く、サービスの品質をあげていくには、内製してサイクルを回したい
  • ITがメインではない事業会社で、開発者がどういう仕事ができるのか
• 気を使ったこと
  • 開発者に興味を持ってもらえるようなブランディング
  • なぜこのビジネスが内製じゃないとダメなのか

成長期

• マネージャーがいないフルフラットな組織（自立分散型組織）
  • 自主性をもってスピード感出せる
  • 人数が増えたらどうなるかは分からない
• 内製開発のプロセスやコミュニケーションを知らない人と内製やるのは大変
  • ビジネスサイドの人にもPMやプランなーとして最初から参加してもらったほうがいい

取り組みと課題

• ビジネスサイドとプロジェクト計画書を共通認識
  • 誰が何を何のために
• 標準化はしないけど、透明性を確保する
  • みたい人が勝手に見れるように
• いろいろなツールを使いたい人が使える環境、承認フロー

Four Keys をこえて

• 安定時のパフォーマンスをはかるのはどの指標なのか
  • どんだけリリースしてもユーザが満足しなければ価値がない
  • 可用性と信頼性

信頼性

• 求められた機能が求められた期間に動く確率
• ストリーム全体でSLOを優先事項として判断する
• SLIの種類、仕様、実装を明確にドキュメンテーションする
  • SLOもあわせてかく
• エラーバジェットに余裕があるかどうかで何を優先すべきなのかを判断できる

フィーチャーチームか

• 以前はプロジェクト体制（各部署から人集めて、終わったら解散）だった
  • プロジェクトごとに人集めたり、都度チームビルディングが必要
  • リリース後の改善、運用主管が不明確になりやすい
• 新たなチーム体制
  • フィーチャーチーム
    • 事業価値創出、戦略を実行するチーム
    • ジェネラリスト、T型がむいている
  • プラットフォームチーム
    • 認知負荷を下げる職能別のチーム
    • 技術的な支援をするがあくまで支援
  • ピープルマネジメントチーム
    • 横串のチーム、横軸にちかいけど、マネジメント専門
    • フィーチャーチーム内にEMを入れるのは難しいので、外からマネジメントする
      • リソース効率がいい
      • 冗長化が可能
      • チームの自立性をたもつ
    • 業務範囲 - https://creators-note.chatwork.com/entry/2022/10/04/110957
  • チーム横断コミュニケーション
    • EATは全共有、参加も自由
• 課題間
  • 担当者不在 *
  • スキルがチームに閉じない
    • 足りない職能は外部から引っ張ってくる必要があるので、チームにスキルが根付かない
• いいチーム
  • コミュニケーションがチームで閉じている
  • スキルもチームで閉じている

グロービス

経営サイドの巻き込み方

• 世の中的にこういう流れになっている、という話は入り口でその会社で通じる言語に翻訳した上で会話をする必要がある
• 実際に自分の会社にフィットする指標なのかを小さく試す
• 合意形成のコツ
  • 気になっているけど、実はよくわかっていないそうなところを後押しする感じ
    • ビジネスとか経営理念、経営層の人が考えていることに沿ったところからせめてみる
  • 理屈からせめてもうまくいかない時はけっこうある

PdM、ビジネスサイドの巻き込み方

• もともと20%は負債の解消の時間に割当てる予定だったけど、スプリントゴールを優先しがちだったので、専任チームを作ってる
• PdMやビジネスサイドが求めているデータは何かを聞くところからはじめてみる
  • 開発生産性の指標自体は開発の中で分析できていればいい
  • 巻き込む時に指標をビジネスサイドが求めている指標に変換する
• 会社の外からの評判はインパクトがでかいし、信頼の積み重ねも大事

AI時代の開発生産性

開発生産性は難しい

• そもそも生産性はアウトプット/インプット。ソフトウェア開発において、アウトプット、インプットって何か。
  • 何をアウトプットにするかによってどういう生産性を測るのかがかわる。
• ソフトウェアの複雑性はあがっているが、複雑なことを簡単に実現できるようになっていて、適応領域は広がっている
• 個数で評価できない
• 状況によって簡単な機能追加が難しくなる
• 効率化しても売り上げが上がらなければ生産性が上がったと言えない時もある

3つのレベルに分けて評価しよう

• 仕事量生産性: 開発チームで見る
• 期待付加価値の生産性: プロダクトチームで見る
  • どのくらいの価値が期待される仕事ができたか
• 実現付加価値の生産性: 事業部で見る
  • どのくらいの価値を実現できたか

将来価値をたかめる生産性向上

• 将来価値を高める取り組みが数値になるには時間がかかる
• 逆に2,3年前の取り組みが今価値になっていることもある
• 新しい当たり前となる習慣の価値は使う前には分からない

生産性という言葉のもとをたどる

• 速さの話をするのであれば、スループットの話（リソース効率）をしよう
• 早さの話をしているのであれば、リードタイムの話（フロー効率）をしよう
  • どこのリードタイムなのかもはっきりしていない
• リソース/フローの考え方
  • 価値が全てまとめて届くトラックがいいのか、価値が分割されて定期的に届くベルトコンベアがいいのか
  • フロー効率を高めてからリソース効率を高める方がやりやすい
    • リソース効率がいい状態でフロー効率を高めると不安になる

デプロイ頻度

• ソフトウェアは不可視なので、嘘の進捗はかならず起こる
• 関係者や市場に晒されることで進捗は少しずつ見えてくる
• 晒すことはデプロイ、頻度が上がれば質に転化する

目標

• 定性的な目標（達成したい状態）
• 状態を数値化するための定量的目標
• 質的なバランスが崩れないような維持するための健全か指標

共有すること

• 依頼がきてからデザイン着手、開発着手できるまでにかかってる時間長くない？
• 納品、公開日をこっちの裁量で決められないのか？
  • 早く終わっても待ってないといけない
  • スケジュールが決まっていると、早く終わっても遅くなっても引っ張られる
• 誰が何を決めるべきなのか、決めていいのかの共通認識をもとう
• 文化は人だけではない
• コミュニケーションは疏である方あるほうがいいのか
• Gorilla in the room