”アジャイルCoE”とは何をするチームなのか？ - techtekt（テックテクト）

こんにちは！カスタマープロダクト本部 dodaサイト開発アジャイルCoEグループの川又です。
今回は「dodaサイトで活動しているアジャイルCoEは結局何をするチームなのか？」というテーマでチームの取り組みの背景・実務を紹介いたします。

アジャイルCoEとは
チームポリシー
これまでの活動
来期のテーマ

アジャイルCoEとは

まずアジャイルCoEというワードですが、
「アジャイル」はソフトウェア開発手法の名称から来ています。いわゆるPJT型と言われるウォーターフォールとの対比でイメージを掴んでもらえればと思いますが、要約すると「小さく、早くリリース」というアジリティの高い開発手法です。

そして「CoE」は
Center of Excellence（センターオブエクセレンス）の略語となります。
一般的な説明としては以下になります。

組織横断的な取り組みを進めるために、優秀な人材やノウハウを1つの拠点に集約して組織化することを指します。文脈により、CoEは人材が集約された中核的な研究拠点そのものを指すこともありますが、ビジネスでは一般的に専門知識を持つ優秀な人材が集まる部門横断組織という意味で用いられています。

つまり、アジャイルCoEは
「アジャイルな開発手法を取るチーム・組織」に対して「知識とソリューションをもって課題を解決する組織」
と定義することができます。

チームポリシー

次はチームとして定義している憲章を紹介します。

私たちはコアバリューとして「変化に強い組織／文化を作る」を掲げています。
近年VUCAの時代と呼ばれるなか、変化に強くその環境に適応していくことが求められます。dodaサイト開発も例外ではなく、積み上げたチームナレッジや関係性、独自のルール等がチーム・体制の再編によりまた1から整理し直し…という課題によく直面します。
しかしこれは変化が悪いわけではなく、変化があったとしてもそれに耐え得るチーム・体制作りのフレームワークが脆弱であり、判断基準や運用知が人に依存していることが課題と言えます。
私たちは全チームを横断して俯瞰することで課題(※)を第三者的に整理し、ソリューション提案や選択肢を与え、記載の行動指針を基に自律的かつ自己組織化されたチームを育む支援を行っています。
直近では、dodaサイト開発の継続開発チームの支援によりある程度進め方のフレームワークや自律的なアクションが増えてきたため、周辺領域に展開することで再現性の確認と組織としての「振る舞い方の統一化」を狙い活動の幅を広げています。

※開発プロセス改善、課題の真因分析、開発手法・フレームワークの型化など

これまでの活動

続いて、私たちが25年度下期に実施してきた具体的な活動を紹介します。
課題、打ち手、そして定量／定性評価をセットで整理していきます。

①インプロセスなアジャイルコーチング

■課題

事業貢献に直結する施策以外の技術負債や開発プロセスにおける課題に対して適切にリソースが割けていない。
スクラムマスター、デベロッパーが指針とするガイドライン・開発標準が存在せず、組織としての基準が人に依存している。

■打ち手

認定スクラムマスターの資格を持ったCoEメンバーによるレトロスペクティブのファシリテーション。課題の真因分析や優先度整理、ステークホルダーとのコミュニケーション手法等をレクチャー
アジャイル開発としてのスクラムマスター（SM）／デベロッパー（Dev）ガイドラインを策定し、これまで曖昧だったロール、レベルに応じた求められるスキルを具体性を持たせて可視化。実務をイメージしやすく今すべきことの迷いを削減することで個人・チームの成長に繋げた。

■定量／定性評価

Four Keysの指標良化
改善施策のリリース数増加

②開発プロセス変革

■課題

各チームごとにテスト設計・管理が異なり、再利用されず情報の透明性が低い
コンプラ・セキュリティチェックを開発の後工程で実施し、かつ専門部署へ依頼となるためリードタイムが非常にかかる

■打ち手

テスト仕様書再利用プロセスの策定
専門部署に頼らず自組織でコンプラ、セキュリティ観点プロセスを策定

■定量／定性評価

テスト仕様書再利用率100%
IT／STにおけるすり抜け故障ゼロ

③テスト自動化推進

■課題

dodaサイト開発におけるリグレッション観点のテストが不足しており、網羅的なテスト設計・実施ができていない
テスト自動化を導入するための開発プロセスが整っていない

■打ち手

②で整備された開発プロセスをもとにE2Eテストを導入し、品質・開発生産性の向上を目指す

■定量／定性評価

エラー率1%未満／実行速度2h以内
クオリティゲートとしてE2Eの実施を義務化
リリース数増加、本番障害0件

④各種研修の開催

■課題

内製エンジニアのQAスキル、ファシリテーションスキル不足

■打ち手

外部のアジャイルコーチによるファシリテーション研修実施
QAスキル（テスト計画／戦略、シナリオテスト、機能テスト）研修実施

■定量／定性評価

テスト計画／戦略を開発プロセスに盛り込んだ施策を1件リリース
テスト設計におけるバグを20%削減

上記のとおり、「コーチング」「プロセス醸成」「テスト自動化」「メンバー育成」など支援と言いつつも幅広い活動を行っています。
チームメンバーに「どう納得感を持って実行力高く自走してもらうか」がポイントのため、どの取り組みの推進においても①インプロセスなアジャイルコーチングが要となります。
イベント参加、定期的な1on1、Four Keysやリードタイムを用いた定量的な分析など、常にチームや組織の現在地を把握しながら今最も効く取り組みは何なのか？を考え抜いて活動を行っています。

また、各取り組みにおいても定量／定性の評価軸を設け、週次のスプリントレビューにおいてPO・マネジメント層に対して経過報告を行い、改善点や優先度再調整を行うことで次スプリントでの取り組みに活かしています。
より詳細の活動を知りたい方はぜひご連絡いただければと思います！

来期のテーマ

最後に、来期のテーマを語って締めようと思います。
私は「AIとの共生」「外部への発信」の2つが来期のアジャイルCoEのテーマだと考えています。

まず「AIとの共生」について
私自身、上記の活動だけではプロセス醸成という文脈ではまだまだ道半ばだと感じています。そのなかで、無闇にAI導入するのではなくAIが効くポイントと人間が価値発揮できるポイントを整理し、適切にリソースを割く必要があります。
25年下期ではAI導入の基礎として、まずは”ありものの開発プロセスをよくする”に注力していきました。基盤となる開発プロセスが整備されていないと、いざAI駆動開発を導入となった場合、プロセス変更が多くなり開発者の負荷が非常に高くなります。
この半年でチーム・組織のプロセス整備も一定推進できましたし、アジャイルCoEが伴走しなくても自律した課題設定・解決のサイクルも回りつつあると感じています。来期からは整った開発プロセスにおいて、どのプロセスがAIに置換できるか、また人間がリソースを割くべきプロセスはどこか？について以下のポイントを整理しながら推進していきたいと考えています。

開発プロセスにおけるAI置換ポイントの洗い出し
KPI／ROIの精緻化
開発プロセスのToBe像作成
品質向上施策の試行
全体展開用のガイドライン作成

続いて「外部への発信」について
こちらは、この半期で着実に進められたからこそ来期も継続して実施していきたいテーマです。
まさにこのtechtektへの寄稿もそうですし、サイト開発を飛び出して周辺領域へインプロセスで改善活動を促進することができたため、組織という意味では外向きな取り組みを実現できました。来期はアジャイルCoEの取り組みを社外へ発信し、同じ分野に携わる方々からの示唆を得ることで組織の成長と精度向上に繋げていきたいと考えています。

引き続き、開発チームの品質・開発生産性向上に繋がる活動を行うアジャイルCoEにご期待ください！
ここまで読んでいただきありがとうございました！