受託開発文化にCIのプラクティスを広める

課題と仮説

- システム開発をまるっと委託する、昔ながらの文化
- 部署によってオフショア、オンサイトが混在
- フェーズゲートの所々に組織/部署/チームの溝が生まれている
- 溝の中で品質を担保しようとする部分最適化が蔓延している

大企業でよく見かけるこのような状況で、実装・UTフェーズでの傾向はこのようなものでした。

- 数十名のメンバーを抱える大規模チーム
- 集まる開発者のスキルはバラバラ
- レビュアーに負荷が集中し、ボトルネックになっている

レビュアーの声を聞いてみると

レビュー以前に、このコードじゃ読めないよ、、、

コーディング規約ってね、、、
可読性ってね、、、
この書き方はバグになりやすくてね、、、
このアルゴリズムだとパフォーマンスが悪くてね、、、

時間がないから、仕様の認識齟齬だけ解消して通そう
メンテナンスつらそうだな、、、

全社に広がるこれらの状況から、ボトルネックを解消する仮説検証を進めています。

仮説
全社にCIのプラクティスを適用したら
より楽で安全に、より早く多く
実装・UTフェーズを回せるのでは？

提供価値
- 誰でもすぐに利用できるCI pipeline
- CIのプラクティスを学ぶ機会
- 適用状況、開発プロセスを分析したフィードバック

ソリューション
- 誰でもすぐに利用できる全社標準のCI pipeline
- CIイネーブルメントチーム

誰でもすぐに利用できる全社標準のCI pipeline

昔ながらの開発文化なこともあり、ほとんどのシステムはVM上で動く、モノリスや分散モノリスです。packagingとdeploy、e2eテストには独自の考慮が必要なことが多いのでスコープから外し、別プロダクトで支援することにしました。

提供する機能は、どんなモジュール構成でも必要になる、UTと静的解析にしぼりました。Multi-Stage CIの前半（Dev-CIとTeam-CI）をシンプルに提供しています。

Multi-Stage CI with Jenkins in an Embedded World

アーキテクチャ
- GitLab
- Concourse
- SonarQube

誰でもすぐに利用できる社内標準
機能を限定することで、利用できるプロジェクトの幅を広げています。導入作業と設定も定型化できるので、GitLabプロジェクトのurlやブランチ戦略などの最低限の情報をヒアリングするだけで、すぐに導入できるようにしています。

これからCIを始めるならこれを選べば楽ですし、すでに自前で用意していれば、使わなくても大丈夫です。最低限の機能を別環境で実行するので、自前と併用することもできます。

Dev-CI
- 開発者が実装/UTを終えたらMergeRequestを出す
- 機械的なチェックが通らなかったら、すぐに開発者にフィードバック
- 機械的なチェックが通ったあとで、レビューを実施
- レビューのやり取りはMergeRequestを利用

Team-CI
- trunkのブランチにpushしたら、Dev-CIと同等の処理を実施
- 静的解析の履歴を保存して、内部品質の推移を追跡できる環境を提供

Nightly Build
- CIでの回帰テストで実施できない分のパターン網羅テスト
- CIとセットで必要なことが多いので、あらかじめ提供

CIイネーブルメントチーム

しくみだけではプラクティスは浸透しないので、利用者ごとのコンテキストや状況に合わせて、段階的で継続的な学びが必要です。利用者に伴走し、情報提供や提案をするチームを、CIのプラクティスを経験したことがあるメンバーで構成しました。

イネーブルメント
成果につながる継続的な成長を促すアプローチで利用者に伴走しています。

簡易版の利用者コミュニティ
プロダクトを利用していく上で生まれる疑問やつまづき、新機能や障害の対応状況を共有するために、チャットグループを利用して簡易版の利用者コミュニティをつくっています。ある利用者がうまく行った方法などもチャットグループ内での会話から、部署を越えて知見を共有できるようになっています。

開発プロセスのデータ分析基盤

適切なタイミングで、適切な内容を学ぶきっかけを提供するには、利用者の行動と結果を分析し、データドリブンなフィードバックが必要です。

レビュー前後の行動は、MergeRequestのnoteで確認できます。行動の結果は、静的解析で計測した内部品質と、mergeまでに掛かる時間として確認できます。これらのデータを収集、可視化し、分析する環境を構築しました。

アーキテクチャ
- Gitlab, SonarQube
- Airflow
- Postgres
- Grafana

行動の結果に影響する施策
- 静的解析で計測した内部品質
  - Dev-CIでのしきい値チェックで、悪化を防止
  - Dev-CIでの自動フィードバックで、内部品質に意識が向くように
  - 定量データが、既存コードをリファクタリングするきっかけに
- mergeまでに掛かる時間
  - DevCI通過後のレビューで、機械的に判断できる観点のやり取りを廃止
  - 人が確認するべき観点に集中してもらうきっかけに

計測対象
- プロダクトのオンボーディング進捗
- 静的解析の結果
- GitLabのMergeRequest履歴

KPIツリー
CIイネーブルメントチームが追う数字は、カスタマーサクセスの考え方を取り入れて、利用者がプロダクトを上手く活用できているかを示すヘルススコアを算出しています。各利用者が注力するKPIは、利用者の状況に合わせてKPIツリーから選びます。

- ヘルススコア
  - オンボーディング進捗
    - 完了ステージ数
  - 内部品質
    - 脆弱性の指摘数
    - バグの指摘数
    - コードスメルの指摘数
  - レビューコスト
    - 月間マージ頻度
    - 月間マージLT 中央値

日次でこれらのデータを収集・加工・集計し、ヘルススコア・KPIツリーを可視化します。値の変化をCIイネーブルメントチームに通知し、行動の結果が変化したタイミングで、行動とその結果を分析、利用者にフィードバックします。つまり、利用者が行動を変えたタイミングで、データドリブンに、努力を讃え、改善を提案することができるようになりました。

データを軸に利用者とのコミュニケーションを取ることで、当たり前のこととして埋もれていた上手いやり方を発見し、その知見を部署を越えて広めることもできるようになってきています。

まとめ

しくみとフィードバックループで行動を変え
行動を変えることで新しい文化を醸成していく

という流れを生むために

- 従業員の行動を成果につながるように変えるしくみ
- 継続的な学びに伴走するチームとアプローチ方法
- 適切なタイミングと内容でフィードバックするためのデータ分析

これらを段階的に整えていくと、スムーズにプラクティスを広めていけることが見えてきました。組織の状況に応じて優先するポイントや、実現方法は異なりますが、どこでも同じ観点で進めることができそうです。