Open3

『一人一人が意識する開発生産性 - 組織の当たり前基準と顧客価値を上げるために』LTに参加してみた🌟

まさぴょん🐱まさぴょん🐱

LT①：『開発生産性可視化の意義とPR TIMESの事例』

  • PR TIMESの事例

  1. デプロイ頻度を上げる

    • 最初は、BackEnd に feature flag を導入 (現在は、FrontEnd にも導入済み)
    • デプロイ高速化のために、フルスクラッチでデプロイの仕組みを構築する
    • マルチステージング環境を構築
    • Apache

  2. Jira導入

    • チケット・Task管理
    • ガントチャートも活用

  3. CI導入

    • Unit Test導入
    • GitHub に push したら自動で実行する
    • テスト整備は、まだ途上の状態

BackEnd の開発方針

  1. バックエンドはPHPのバージョンアップ開始
  2. 使っていないCodeを削除するために、月に1度のリファクタリングデーを開始
  3. 学生インターン受け入れ
  4. テンプレートエンジンのSmarty+jQueryの構成から、JSON APIベースのシステムにreplace

FrontEnd の開発方針

  1. 既存の jQuery のコードを破棄して、TypeScirpt/Reactベースに機能毎に Replace
    • 現在では、Next.jsを導入しており、SSRも活用中
  2. OpenAPIでAPIのスキーマを定義、バックエンドとはOpenAPI経由で連携
    • OpenAPIで生成したコードを利用してAPIをフロントエンド上で扱う
  3. デプロイの仕組みは当初バックエンドのデプロイの仕組みに乗って初期導入コストを減らす
    • 現在ではフロントエンドのソースコードをS3にputしてFastly経由で配信するデプロイの仕組みが存在

あたりまえの基準を上げていく🌟

  1. 変更ができなくて当たり前→バグ修正できて当たり前→replaceできて当たり前→機能追加ができて当たり前→開発効率改善ができて当たり前、のように「当たり前」の基準を上げていく
  2. 「できない理由ではなく、解決する方法を探す」というマインドで解決策を考える
    • 例：PHPのバージョンが古すぎて新機能追加が行えない→PHPのバージョンアップ前でもLambdaなどのAWSのサービスやFastlyを活用することで、これまでできなかった機能追加を実現する方法はある
      • 事例：S3 を活用して工数を削減させた、ファイルアップロード機能の設計と実装
    • できない理由は誰でも分かるので、やりたいことから逆算して解決する方法を探す
  3. マインドばかりがクローズアップされがちだが、技術力が最も試される部分で、技術力が無ければ当たり前基準は上がっていかない
    • こうして解決した事例は開発者ブログで発信、カンファレンスでの登壇にも一部繋がっていくので社員のモチベーションアップにも繋がる
  4. 一度組織内で上がった「当たり前基準」は下がらない
    • 社員（開発以外も含む）は全員その「当たり前基準」を覚えている

開発生産性可視化前の課題

  • こういった取り組みで開発は進むようになってきていたが、開発速度の変化はエンジニア以外には伝わりづらい。
    • 特に最初の1年程度はプロダクトに大きな変化は起こらないので、プロダクトの変化から実感できない。
    • エンジニア以外の人はエンジニア側の「開発が進んでいる」という言葉を信じるしかない
  • エンジニア側は開発が進んでいる実感はあったものの、客観的に見てどうなのかが分かっていなかった。
    • この点を開発生産性の可視化で解決できないか模索

開発生産性と可視化について

  • 目的は開発速度を向上させることで、開発生産性を上げることではない。
  • しかし開発速度を向上させようとすると、開発生産性の数値は勝手に上がるはず。
    • そもそも開発生産性の数値が上がっていないなら、やり方を間違えている可能性が高い。
    • 自分たちのやっていることが正しいかどうかを知る上で可視化は重要
  • 開発生産性が高い組織はできることが増え、社員のやる気も増加する。
    • 単純にグラフが上がっているとモチベーションが上がるというのもあるので、その意味でも可視化はするとうれしい。
  • 開発生産性の可視化はエンジニア以外、特に経営層への説明を雰囲気ではなく、事実で説明しやすくできる。
    • 開発者ブログでも年末の振り返りで公開することで、社外の人からも開発チームの状況が分かるようにできる。
    • 2023年のグラフは既に公開済み

開発生産性の可視化事例

開発生産性の数値との付き合い方

  1. 数値の向上を組織目標にはしない
    • 組織の目標として持つとハックするincentiveが働いてしまうので組織目標にはしていない
      • 例：休日前にPRを作成しないなどPRを作成するタイミングを調整する、QAを適当にしてmergeを急ぐ、分けるべきでないPRを分割するなど
      • これらの行動は本質的ではないが、数値目標として持つとやりたくなってしまうし、実際簡単にできてしまう
    • チーム目標や個人目標で持つことは問題ないし、振り返りで使うことも推奨
    • 開発効率を上げるために活用することは推奨
  2. 数値を追うのではなく、振り返りで結果だけを見る
    • 例：結果として1 PRのサイズが大きいものが多かった、レビュー速度が遅かったなど
  3. 技術的に誤った方向で努力しても無駄なので、技術的に誤った方向に行っていないかの方が重要
    • 長期のプロジェクトはDesign Docを書いて方向性をそろえておく
    • 技術的に問題ないか全員でレビューを行う
  4. 会社の事情もあるので、必要以上に追いすぎない
    • 詳細は次で

可視化して実際に分かった実例

  1. PRのサイズが大きいプロジェクトチームが判明
    • 会話したところ1つのJiraのチケットに対して1つのPRを作るルールだと勘違いしているメンバーがいたことが分かった。
  2. 2月にPR作成数などが落ち込む
    • 旧正月のタイミングで帰国するベトナム国籍の社員が多いため
  3. レビューが特定の人に偏りがち
    • 気付いていたことが可視化された
    • 現時点では改善予定はないが、今後何かする可能性はある

最後に

  • 開発生産性の可視化で色々なことが分かったし、説明もしやすくなった。
    • モチベーション増加にも繋がっている。
  • ただ最も重要なのは「プロダクトを技術的に正しい方向でよりよくできたか」
    • それができていれば開発生産性は勝手に上がるはずだし、できていなければ開発生産性は上がらない
    • 開発生産性の数値だけは改善しているのに、プロダクトが良くなっていなければ意味は無いし、技術的に正しい方向でなければ必ず行き詰まる
    • 開発生産性との適切な付き合い方を各社考えるとよいと思います！

Q & A

  1. よりよくできているかの判断基準
    • 未来で、機能追加がスムーズにできるか？
    • 未来で、障害が発生しないか？

LT関連資料

https://developers.prtimes.jp/2024/01/26/developer-productivity-engineering-materials/

https://gihyo.jp/book/2022/978-4-297-12846-3

まさぴょん🐱まさぴょん🐱

LT②：『開発生産性と探索型組織のつくり方』〜 SmartHR の事例 〜

  • SmartHR の事例

今回の話のテーマは、

  1. 開発生産性を概観する
  2. 探索型組織とその作り方

開発生産性を概観する

  1. そもそもどのレイヤーの話をしているのか？
  2. 判断基準となる指標もレイヤー毎に違う状態。。。

DORAという概念・Model

経営側と開発側

経営層は、組織パフォーマンスを高めるために、開発生産性を高めたい。

Four Keys という指標に対する解釈

  • プロダクトの変更とは「仮説」に基づいた変更(実装・Update)
  • 仮説と検証の Cycle
  • 仮説検証スピードが速い組織

探索型組織とその作り方

  1. 探索型組織とは？

    • 顧客の価値を探索して、開発プロセスや、プロダクトの投資優先度などをセルフマネージメントできる組織のこと。
    • 顧客志向

  2. 探索型組織の特徴とは？

    • セルフマネージメントを行っている。
    • 経験主義的なアプローチを行っている。
    • 会社全体の情報の透明性が高い。

セルフマネジメントが実現していない状態とは？

  1. 開発プロセスが、開発チーム外から規定されている。
  2. プロダクトの投資優先度が、開発チーム外から規定されている。
  3. 開発プロセスの一部を開発チーム外の組織や個人に依存している。

経験主義的なアプローチとは？

会社全体の情報の透明性が高いとは？

  1. プロダクトビジネスからのフィードバック
    • ユーザーの声など

探索型組織を作りたい人が、考えるべきこと・質問事項

  1. セルフマネージメントを実現できるよう権限の付与と、適切な環境になるような組織設計がなされていますか？
  2. 経験主義的アプローチが採用され、チームは学習から適応していますか？
  3. 会社全体の情報の透明性が高く、チームは正しく学習できていますか？

探索型組織が会社にもたらすもの

Q & A

  • Q1. チームマネージャーをしながら、プレイヤーとしても生産性を高めるには？
    • A. チームとして、生産性があっがているのか？ を優先すべき。
    • 自分の生産性より、チームの生産性を上げるのがチーム・マネージャーの役割。

LT関連資料

https://speakerdeck.com/morizumi/developer-productivity-20240126

DORA

https://dora.dev/research/