「開発が遅い」と嘆くのは簡単です。でも本当に遅いのは“人”ではなく、“見えない仕組み”かもしれません。
ラクスの開発組織が大切にしているのは、「顧客志向」です。
そして私たちはお客様に価値を速く・確実に届けるための基盤づくりとして開発生産性の向上に重きを置いています。
そのため各チームは、プロダクトの性質やお客様のニーズに合わせて、プロダクトごとに合理的な開発スタイルを選択しています。
そして、開発生産性に関わるデータを活用し、スタイルに合った施策を日々検証することで、価値提供のスピードと確実性を高めています。
今回は、そうした多様な背景を持つ開発チームが行っているリアルな「生産性向上のための取り組み」をチラっとご紹介します。
多様な技術スタックを持つチームが、それぞれの現場でどんな工夫をしているのか。
そこには 「開発生産性を科学する文化」 があります。
目次
データが語る、チームの「今」
ラクスでは開発の現在地を見える化するために、
(1) チームごとの客観データ収集
(2) Findy Team+や社内ツールで可視化
(3) リーダーによる改善
というサイクルを継続しています。
可視化結果はメンバー層まで共有され、チーム全体でボトルネックを発見・議論できるようになっています。
(※Findy Team+については先行記事参照)
可視化されている値の例として、
全チームのPR（Pull Request）データをFindy Team+で分析し、
「オープンからレビューまでの平均時間」や「レビューコメント数」
といった指標を毎週～毎月追跡しています。
開発に要した時間だけではなく、レビュー待ち時間やレビュアーの偏りなど、
開発サイクルの“詰まりポイント”を見つけ出し、改善の余地をチーム単位で議論しています。
あるチームでは、オフショア開発体制ゆえにレビュー周りの時間が長引く課題がありました。
そこでAIを活用した一次コードレビューを併用し、ヒトの負荷を減らしつつ質とスピードの両立を実現しました。
レビュアーの偏りがボトルネックになっていたチームでは、
1PRあたりの変更量を下げてレビュー負荷を分散しやすくしました。
同様の他チームでは、レビュアーを育てる仕組みに意図的にシフトすることで、負荷分散を目指しています。
単体テスト工数が規模に対して大きく、コストが課題になっていたチームでは、
AIを使ったテストの自動化を進め、テスト工数の半減を実現しました。
ラクスの開発チームでは、顧客ニーズの解決に直結するPR数の増加とその消化スピードを上げるため、
開発現場をよく知る開発リーダーが直接GitHub統計や各種社内ツールを組み合わせて分析、
原因を深堀、改善施策を打つことで高速な改善サイクルを実現しています。
チームによって違う、“スピードの壁”への取組
開発スタイルは、前述した通りチームによってさまざまです。
WFで設計精度を高めるチーム、Agileで小さく早く試すチーム、両者を織り交ぜるハイブリッドがあり、
いずれも担当サービスのお客様に最短で価値を届けるために戦略的に選択しています。
全チームの共通事項として、
「4Keys指標（Googleが提唱するDevOps成功の4つの指標）」を意識しつつ
より自律的に改善できる指標として自チームのスタイルに合った指標を置いています。
前項でも挙げたように、"管理される側"というよりも、自発的に“改善を設計する側”として指標を定めて動くことで、
ラクスのユニークネス「ゴールオリエンテッド」、「着実な継続」、「不確実性の排除」(※)を地についた形で実現しています。
※ラクスのユニークネスについては別記事参照
開発スタイルに即した開発生産性向上の施策として興味深いものでは、オフショア開発の事例があります。
ベトナム開発課では、現地メンバーが主導して工程ごとの指摘数や本番バグ発生率を分析しています。
レビューコメント数の集計、内容確認を振り返り会に組み込み、テスト工程へのフィードバックに活かすなど、
開発拠点間の距離を“データ”で埋めることでスピードUPに繋げています。
オフショア開発という開発スタイルならではの取組と思います。
“本社の指示を待つ”のではなく、“自分たちで課題を見つけ、仕組みを考える”思想が根付いています
（もちろんコミュニケーションも密に行っています）。
そこにFindyなどの数値で見られる各種ツールや、翻訳が容易になるAIが加わることで、私たちは言語的、地理的な壁を越えた認識の共有をしています。
「数字」ではなく学びの共有に注目する文化
開発本部では、結果として起きた数字の変化に対して、
「数字」を共有して優劣を競わせるのではなく、
変化させるために行った施策で得た「ナレッジの共有」を促進しています。
これは、手探りになりがちな施策の検討にあたり、リーダー陣が闇雲に施策を試すのではなく、
数値をベースに過去事例の根拠を以て小さく試し、大きく育てることにより、
高効率で生産性の向上をするためです。
この分析サイクルとナレッジ共有が習慣化すれば、結果としてスピードも品質も向上します。
各施策の進行途上で得たナレッジは、3か月ごとに開発本部全体で共有され、次の一歩のヒントになります。
あるチームの課題が、別のチームのアイデアで解決される、
「学びの連鎖」が生まれる仕組みとなっています。
この仕組みの中で、チームリーダーたちは“数値を見る目”を磨いていきます。
単なるチームマネジメントではなく、「開発者として顧客へどうスピーディに価値を届けるか」を
リーダークラスのメンバーが主体的に考え、実践しています。
ラクスの開発現場は、
コードを書く「だけじゃない」、言われたことをやる「だけじゃない」
データをもとに開発文化を進化させる、「だけじゃない」高次のスキルを磨ける環境です。
この環境で働くエンジニアは自然と、今後更に進化するAI駆動開発にも柔軟に対応していくものと思います。
さいごに
生産性向上の目的は、「顧客に価値を速く・確実に届ける」ための基盤づくりです。
今回は、顧客へ価値を届けるために、データを使って生産性向上に挑む私たちの取組を紹介させていただきました。
開発をもっと速く、もっと楽しく！
ラクスは、開発の未来を作りたい仲間をお待ちしています！
