Ubie における、小さく泥臭くはじめる開発生産性改善

本記事では Ubie における最近の「開発生産性」というテーマで向き合っている事柄と実際のアクションについて紹介します。まだまだ発展途上ではあるのですが、何かの参考になれば嬉しいです。

背景

「開発生産性」とは一見シンプルな概念に見えますが、世のテック企業、取り組んでいる人々のアクティビティを見ていると複雑で深いものにも感じます。例えば SpeakerDeck で「開発生産性」と検索することで多様な情報発信を見ることができます。有名な書籍として「 Lean と DevOps の科学」も、初学者が内容を頭に叩き込むのも難しいのではないでしょうか。
これらの先行者の知見は素晴らしいものの、具体的に我々の現場の開発組織、事業状況などなど現実に近しい環境と密接に接続して、すぐに手応えが感じられる成果が得られるかというとそうでもないとも思います。 Ubie でも過去に開発生産性課題を感じて様々なアプローチを試してきましたが、イマイチ軌道に乗ることろまで到達できていないでいました。（このあたりの試行錯誤は技術書典16でUbieが出した書籍 でも紹介しているので、ご興味があればぜひ！）
この苦い経験がありつつも、2024年春に再度開発生産性への疑念がプロダクト開発組織で幅広く訴えかけられました。既に一定は強い開発組織ではあるが、それで満足なのか。事業成長をプロダクトパワーでもっと牽引できなくて良いのか。最強に成るのを諦めてよいのか。

この記事では、この問題提起に対して再度「開発生産性」というテーマに Ubie らしく立ち向かうべく 2024 04 - 06 月の間に取り組んだことについて紹介します。

ゴールを見据える

今回の取り組みでブレない目的として「プロダクト開発において ROI を最大化させたい」と置きました。生産の量を増やしたいなら採用を強化するのも手ですが、人数に対してアウトカムが悪ければ会社の収益性が悪く見えますし、採用活動は少なくないコストを支払うことにもなります。今いるメンバーの生産性を改善することも諦める訳にはいきません。
開発生産性周辺のツールセットのプロダクト開発現場での活かし方は、以下のイメージを持ちました。数値を追って管理されるような体制というより、個人・チーム・組織を繋いでより高みを目指すための対話のフレームワークにしたかったイメージです。

• 各チーム内
  • チーム内で開発生産性最適化の活動を実施する
  • チーム内で頑張るべきでない課題を的確にチーム外に出す
• チーム外
  • 人員計画等の組織開発へのインプット
  • 横断・基盤的活動への投資判断へのインプット

計測と分析

アンケート調査

2024 04 頃、社内エンジニアを中心に定性データ収集のためアンケートを取得しました。軽量に Google Forms で作成・展開したものです。設問としては

• 開発における時間の使い方
• 開発における感覚の、前職との比較
• その他開発生産性を阻害していそうな要因

などを聴取するものでした。

結果の一例を挙げると、以下のようなデータが得られました。メンバーの回答の性質はざっくり二分する形になったと言えそうです。

また開発生産性阻害要因としては、

• ミーティング過多や兼務の発生などアンチパターンにハマっている
• チームを横断するレビューや調整系に時間を取られる
• インフラ・データ基盤などに関するハードスキル不足

といった回答を挙げるメンバーが多いのも特徴的でした。

総合して、開発生産性の伸び代をまだまだ感じているメンバーがいることは伺え、すぐに取れるアクションもあるものの、今回のアンケートで明瞭になった課題はそう多くもないとも解釈しました。

GitHub の開発アクティビティデータの収集・可視化

TROCCO を活用したローコードデータ連携

GitHub から取得できるデータを分析することで、いわゆる Four Keys の「デプロイの頻度」「変更のリードタイム」に近しい指標を評価することにしました。「平均修復時間」「変更失敗率」は Ubie のプロダクト開発スタイルではやや取得するのが難しく、かつあまりこの領域に顕著な課題感が無いので敢えて除外しています。

Ubie では、様々なデータソースとデータ分析基盤を連携するのに SaaS の TROCCO を利用しています。 TROCCO では幸いなことに GitHub GraphQL コネクタがサポートされており、これでローコードでできる範囲のデータを取得しています。

連携するデータとしては

• 各リポジトリの Pull Request 一覧
• 各リポジトリの Release 一覧
• 各リポジトリの Issues 一覧
• チームとそのメンバー一覧

を対象としています。

GitHub GraphQL API を使う上で、アウトプットデータをパースするのが複雑という課題が出てきます。基本的に指定する GraphQL クエリによってスキーマが変わる上、中身はオブジェクトの配列、しかもそのオブジェクトに更にオブジェクトを持っている、など多段にネストして入り組んでいたりもします（今回実装したクエリ例を下記に示します） GitHub GraphQL コネクタでは柔軟性を持たせるため JSON 形式の 1 カラムで結果を出力することを想定とされていますが、このままだと分析時の効率やメタデータ管理の問題も発生します。

query($__trocco__githubEndCursor__:String){
  repository(owner: "$org$", name: "$repository$") {
    pullRequests(first: 100, states: [OPEN, MERGED], after: $__trocco__githubEndCursor__) {
      nodes {
        title
        url
        baseRefName
        headRefName
        repository {
          name
        }
        author {
          login
        }
        createdAt
        merged
        mergedAt
        commits(first: 1) {
          edges {
            node {
              commit {
                committedDate
              }
            }
          }
        }
        ...
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

そこで今回、 TROCCO のデータマート機能を使って、一度 JSON 型で転送はするものの、その後に BigQuery 上で具体的な型を付ける工程を挟みました。 BigQuery のクエリにさえ落とし込んで仕舞えば、 JSON_EXTRACT_*() 関数や UNNEST() などで柔軟な加工ができます。

この転送 -> 加工のプロセスはリポジトリごとに行いたいものです。これを最終的には TROCCO のワークフロー設定に落とし込んで、必要なプロセスを、対象リポジトリを変数に落とし込んでループできるように仕上げました。

GitHub のデータの分析と考察

無事 BigQuery に分析しやすい形式で転送できたら、dbt で加工して開発生産性分析用データマートを構築した上で、 Looker Studio で可視化を行いました。可視化したダッシュボードは下記のイメージです。可視化対象に則って、PRマージまでのリードタイムやリリース件数を可視化するとともに、各人が自分自身や自分が所属するチームの開発生産性を振り返られるように柔軟なフィルタを組めるようにもしています（余談ですが、僕のような慣れない初学者でも、こういうカスタムフィルタを非常に簡単に組めるのは Looker Studio の良いところですね！）

さて、可視化自体はゴールではありません。可視化して表面をなぞっただけで満足するのはありがちな罠であり、過去に Ubie でも踏んでいたとも思っています。ここでは僕自身がまず踏み込み、コンサル的？なマインドで「何らかここから示唆を出せないか、伸び代を必死に探れないか」を模索することにしました。

ここでは現在エンジニア達が暗に気にしていそう・気を引けそうなポイントを、前Q・今Qとの対比を含めて行いつつ、ややコミカルなトーンで Notion でまとめ上げました。これにより一定の関心を引きつつも、メトリクスに出てこないリアクションを引き出したり、突出してメトリクスが良いメンバーがどのような特性を持つかを引き出すことができました。元々ゴールにも据えていた「対話のフレームワークとする」の実現も少し見えたのでは無いかとも思っています。

Ubie ではレガシーなバックエンドサービスをリアーキテクチャしている のですが、その効果の速報も評価してみました。こういった活動の成果は感覚頼りになりがちですが、実際に定量でも改善効果が見られると今後の活動指針へのインプット強化やモチベーション維持にもなりそうです。

このGitHub 開発アクティビティの可視化・分析から得られた課題感としては以下が挙げられます。

• 特定のケイパビリティが満たせている「良いチーム」はメトリクスも良い
  • 特にチーミングは効く。チームとして良い体制を組めることで初速も出る
  • 期中にチーミングに向き合うことでトレンドが一気に好転した例もある
• 基盤系、特にデータ基盤がリバレッジポイント
  • 2024 04-06Q のファクトとしてデータ基盤のレビューが遅く、アプリケーション実装のレビューと同程度に待たされるケースがあった
  • 蓋を開けて見るとリソース不足や基盤チームのケイパビリティの偏りがありそうだった

開発組織メンバーの巻き込み

個別チームへの deep dive

定量・定性データに基づく分析も良いですが、 Ubie の開発生産性活動ではまだ知見が不足しています。プロダクト開発チームでの現場で抱える課題感や悩みは、そのチームの外側からガヤガヤ言っているだけではキャッチし難い。生の声を得るべく、個別のチームに一時的に embedded してチームの活動を観察することにしました。具体的には、症状検索エンジン「ユビー」のメイン機能を担うチームの週次のレトロスペクティブにゲスト参加しました。
この活動を通して、チームで生じる課題感、チームを構成するメンバーのケイパビリティの重要性、チームの構成要素を変える前後の開発生産性への影響などリアルな情報を収集することができました。

ところで、今回の事例ではもう少し踏み込んで課題仮説を提示しつつ議論するような活動も行ったのですが、これは常に行うべきか難しい。チーム外からチームの事情をよく把握しないまま口出しするのは歓迎されないケースもあるでしょう。一方で事情をよく知らないからこそ言いやすいこともあるかも知れません。この辺りは口出しする役割の人間のキャラクターや信頼関係、課題解像度、チームの雰囲気に依るかも知れません。

継続的に関心を引くための定期施策

分析・考察結果を発信することにより一時的にみんなの関心を引くことはできたわけですが、こうした活動は関心を割き続けていないと廃れてしまいます。これに対処するため、 Ubie のエンジニアが定期的に集まる社内の Tech MTG という催しの中で「勝手に開発生産性アワード」みたいな企画をクイックに回してみるようにしてみました。時間の経過や基盤の改善等により生産性は変化したのかは常に気になるトピックであることは想定され、一定ワークするのでは無いかと考えています。

余談ですが、ここに名前が上がった @tonkotsuboy_com は入社後目覚ましい立ち上がりを見せて爆速で開発を牽引して、猛スピードでプロダクトの不確実性を減らして行ったということで全社表彰されたりもしました。このレポートが直接貢献した訳では無いですが、全社的に好ましい行動と連動している傾向が見える・明瞭化できているのは嬉しいポイントです。

Ubie らしい開発生産性への向き合い方

ここまで紹介してきた取り組みですが、決して賢いアプローチでは無いと考えています。今回主に分析対象とした「アンケート」と「GitHub のアクティビティデータ」では開発プロセス全体の課題を炙り出すことはできません。例えば開発着手前にチームで本当に開発をすべきかの議論に時間をかけている場合もありますが、このデータ・分析・可視化だけだとそのチームは「ただ開発が遅いだけのチーム」になりえます。また、定量データを可視化して堂々と公開することによる弊害、いわゆるグッドハートの法則も出てくるやもしれません。チームが本来追うべきアウトカムに繋がる指標より、開発生産性に関連する指標を追いかけてしまい、無駄なリリースを多発するなどです。

これらの問題は起こる可能性はあるものの、 Ubie の組織では

• 役職なし。エンジニアに対して権限の強い偉い上司はいない
• 給与査定の絡む人事評価なし
• 各人が自らの人材開発を行う姿勢
• 目的意識の強いマインドセット
• ホラクラシーをバックグラウンドに添えた、理想と現実のギャップをひずみとして上げることが推奨される
• …

と言った特殊な環境が揃っており、開発生産性において今持っている手札でも道に迷うことなく良い効果を産めると信じることにしました。完璧ではないアプローチでも、会社のカルチャーに乗っかって価値が出せるなら、近道を行って初速を稼ぐこともできます。他社でも通じる賢いアプローチを目指したくなりますが、最も目指したいのは自社の成長なわけで、自分たちに最も適した、「Ubie らしい」アプローチで登ろうと考えています。

同時にみんなを巻き込み開発生産性を牽引する立場にも覚悟が求められるとは思いますが、これはもうやるだけ、覚悟するだけかと考えています。

今後の展望

本記事では開発生産性に改めて向き合い始めることについて記述しました。しかし望ましいのは、この開発生産性をプロダクト開発組織において最適な形にコントロールすることです。今回の活動で見えてきた課題感、ベストプラクティスに対処するのは、すでに一部着手していますがこれから強化していきます。いずれは具体的な改善活動に関しても筆を取りたいと思います。