こんにちは、CX開発グループでテックリードを担当している德廣です！
CX開発はリネットの顧客向け機能、コアシス開発は基幹システムを担当するチームです。
今回は、2026年上期からCX開発・コアシス開発を跨いで立ち上げた「AI活用ラボ」という取り組みについてお話しします。
なぜこのタイミングで立ち上げたのか、背景から書いていきます。
これまでやってきたこと
DDD認識共有会から始まった
2022年末、私がホワイトプラスに入社して最初に取り組んだのが「DDD認識共有会」の立ち上げでした。
当時は弊チームではPRでの指摘・手戻りが多く、望む生産量に達していませんでした。ValueObjectやRepositoryといったDDDの概念についてメンバー間で解釈がばらついていて、コードレビューで都度指摘が入る状況です。
原因は、組織として採用しているDDDの設計方針と、チームの設計習熟度に乖離があったことでした。この乖離を埋めるために、以下の取り組みを段階的に進めてきました。
- DDD認識共有会: メンバー間のDDDの解釈を揃える
- DDD勉強会: 継続的な学習の場として定着
- DDD実装ガイドライン作成: チームの合意をドキュメント化
守りが実を結んだ
これらは言ってしまえば「守り」の取り組みです。直接ベロシティを上げにいくものではなく、設計方針とチームの実力の乖離を埋めることで手戻りを減らし、結果として生産性が上がる土台を作るためのものでした。
この守りが、前期（2025年下期）になって目に見える形で実を結びました。
- PRでの設計に関する指摘が明らかに少なくなった
- メンバーから「これはこのパターンを使うのが良いと思います」「これは注文モデルで表現すべきですよね？」といった発言が自然に出るようになった
設計の議論がゼロになったわけではありませんが、「指摘→手戻り」から「提案→議論」に変わり、会話の質が変わったと感じています。
チームの転換点
3名から5名へ
今期（2026年上期）、私を含めて3名だった開発メンバーにベテランエンジニアが2名加わり、5名体制になりました。
これは単なる人数の増加ではなく、チームの性質が変わるきっかけになりました。3名体制のときは限られたリソースで安定して回すことが最優先で、設計力の底上げもその文脈でした。
正直なところ「守り」の取り組みがいつまで続くのかという思いもあったのですが、ベテランが揃ったことで「生産量の安定」を守るフェーズから「ベロシティの向上」を狙えるフェーズに移行できると感じました。
目的に立ち返る
ここで改めて立ち返ったのが、「ユーザーに早く価値を届ける」というチームの本来の目的です。
前期はd/d/d（deploys per day per developer）を0.46から1.01へと約2.2倍に向上させることができ、PRの手戻りも減りました。守りが一定固まった今、攻めに転じるタイミングだと思いました。
AI活用ラボの立ち上げ
攻めの一手として、前期から構想していた「AI活用を推進する場」を立ち上げました。
なぜ必要だったのか
前期の時点で、弊チームではすでにAIツール（Cursor、Devin、Claude Codeなど）を活用していました。 ただ、期末の振り返りで以下の課題が見えていました。
- AI活用が個人レベルに留まってしまっていて、ナレッジが可視化・再現されていない
- メンバーのAI活用は「作業のブースト」で止まってしまっている
- 「使い方がわからない」のではなく「うまく使う感触がない」という声があった
個人の生産性は上がったけれど、それを組織の力に変える仕組みがなかった。
せっかくツールを導入しても、ナレッジが個人に閉じてしまっては勿体ない。
これがAI活用ラボを始めた理由です。
場づくりで心がけたこと
CX開発・コアシステム開発のチームを横断してエンジニアが参加する形にしています。心がけたのは以下です。
- 成功事例の発表会にしない
- 「これ試したけど微妙だった」も歓迎
- 完璧を求めると何も出てこないので、未完成なアイデアや失敗談もOKとしました
- 正解を決めない
- AIの活用はまだベストプラクティスが確立されていない領域なので、「どの業務で使えそうか」の仮説を議論する
- 「面白いけど実用性がわからない」で終わらせない
- 議論が詰まったときは「エンドユーザー価値」「業務・ビジネス価値」「エンジニアリング価値」の3つの観点で、「そこに繋がることはないか？」と整理するようにしています
起きている変化
①Skills（スキル）の共有が始まった
最初に取り上げたのはClaude CodeのSkills（再利用可能なプロンプトテンプレート）についてです。 ある程度みんなAIツールを使えてはいたものの、「うまく作る・使う感触がない」という声があったので、手元にあるSkillsを共有し合うところから始めました。
新しいメンバーのナレッジや活躍もあり、チーム内で「スキルを育てたい」という意識が向くようになってきました。
②ラボから生まれた具体的な動き
ラボをきっかけに、具体的な動きが出てきています。
例えば、あるメンバーがラボでの議論に着想を得て、変更のあったファイルのみ を対象にPHPUnit・PHPStan・PHPCSを実行するSkillを作成しました。
「自分で確認するのは手間だと思ってたのでAIにやらせてみます」とのことで、まさにラボで話した「AIに任せられることを見極める」の実践です。
また、「ローカルDBに繋いでAIにデータ確認させたい、誰かもうやってる？」という投稿に対して、別のメンバーがすでに作っていたローカルDB操作のSkillを共有。
「接続先情報を環境変数から読ませるようにすれば、Skill化してチーム横断で展開できそう」とアイデアが出て、翌日には動的取得版が検証済みでシェアされていました。
個人が自分用に作ったものが、チームの資産になっていく流れが自然に生まれ始めています。
③Slackチャンネルの開設
ラボの中で、AI活用に関する話題が各自のtimesチャンネルで呟かれて終わっていることがわかりました。 そこで、気軽に投稿できるAI活用ラボ専用のSlackチャンネルを作ってみました。
まだ作って1週間程度ですが、早速こんなやりとりが生まれています。
- 「こんなスキル作ろうと思うけど、誰か手元で似たのあったりする？」
- draw.ioのMCPを試した感想を共有したら、「コアシステム開発Gでは大きなクラス図を試してみました。これがその時の結果です」と共有してくれた
- 他社のSkillやAgent、MCPの活用事例の共有
- 今まで個人のtimesチャンネルで呟かれていましたが、ここに集約されていくのでは、という期待をしています
ラボの時間だけでなく、普段のコミュニケーションの中でもAI活用の話題が気軽に出てくる場になっていけるといいなと思っています。
これから
ナレッジ化しやすい環境が整った
AI開発ツールはClaude（Claude Code）に標準化する方針が決まりました。
前期は各自が好きなツールを使っていましたが、バラバラだとナレッジが横展開しにくい状況でした。ツールが揃ったことで、RulesやSkillsといった形でチームのナレッジを蓄積・共有しやすい環境になっています。
この変化も、これからの取り組みの後押しになると考えています。
AI活用の成熟度を4段階で捉える
MIT CISRの研究を参考にしつつ、チームの文脈に合わせて私は以下の4段階で捉えています。
| Stage | 名称 | 状態 |
|---|---|---|
| 1 | 個人の実験 | AIツールを使い始め、プロンプトで試行錯誤する |
| 2 | 個人の実践 | 得意・不得意を掴み、日常業務に組み込む |
| 3 | チームの共有 | ナレッジを可視化し、SkillsやRulesとして体系化する |
| 4 | チームの標準 | AIを前提とした開発プロセスが定着している |
今のチームの位置
今のチームは Stage 2からStage 3 の間です。個人での活用は始まり、Skillsの共有も進んできましたが、ナレッジを体系化して「どんどん作って、育てる」というフェーズにはまだ来ていません。
今期中にStage 3への転換点に立ちたいと思っています。具体的にはClaude CodeのRulesやSkillsとしてナレッジを蓄積し、個人の中にあるノウハウをチームの資産にしていきたいです。
DDD認識共有会のときと同じで、個人の中にあった設計の解釈をチームで揃えてガイドラインとして体系化したことで、チーム全体の設計力が底上げされました。AI活用でも同じことをやりたいと思っています。
そしてその先には、蓄積されたナレッジをもとにAIがプロセスや設計の改善を提案し、開発のやり方自体が進化し続けるような状態があるのではないかと思い描いています。 まだ具体像は見えていませんが、Stage 3→4を着実に進めた先で考えていきたいテーマです。
おわりに
振り返ると、DDD認識共有会からAI活用ラボまで、やっていることの本質は同じでした。 チームの中にある知見を可視化して、共有して、全体の力に変える。その対象が設計からAI活用に移りました。
チームは守りの時期を経て、攻めのフェーズに入りました。
「個人の知見を組織の力に変え、ユーザーに早く価値を届ける」という取り組みを続けていきたいと考えています。
ホワイトプラスでは一緒に働いてくれるエンジニアを募集しています。興味を持っていただけたら、ぜひ採用ページやエントランスブックをご覧ください。
