楽々精算のRAKUSさんが自社のAI活用ナレッジを共有。開発利用にとどまらず、組織浸透における課題や施策であったり、プロダクトへの組み込みであったりと幅広いテーマでとても聞き応えあった。特に組織内のAI活用を活性化するための試行錯誤は、巷では中々聞けない内容で、今後取り組んでいきたい課題のひとつでもあったので知れてよかった。
イベントページ：https://rakus.connpass.com/event/378121/
全エンジニアのAI活用状況を可視化する～LookerStudioを用いたアンケート分析と今後の推進策～
- AIネイティブ開発化の促進ミッション
- データの持ち方〜意思決定プロセスまでAIを全面活用する
- 当初戦略：理想定義と現状とのギャップを埋める
- 挫折要因：技術進歩が早すぎ、数日で陳腐化
- 合意形成の難しさ：メンバー間で目指すべきレベル感が異なる
- アプローチを変更：理想の定義から、現在地の定義へ
- 次の一手を打つために、意思決定に役立つ情報を届けること
- 300人開発組織の見える化、誰でも使える分析基盤
- サーベイ設計は3つの観点に着目
- ヒト（ユーザー属性）
- コト（開発工程）
- キモチ（自己評価、環境整備度合い、成果物への貢献割合）
- Google Forms でサーベイ実施
- サーベイ設計は3つの観点に着目
- 分析基盤の作成：Google Looker Studio
- 無償範囲でも使える
- 開発部だけでなく役員の利用も想定
- メンテしやすさ
- 閲覧者のドリルダウンしやすさ
- 可視化重視ポイント
- 分析対象の傾向を見える化：若手が多いとか、バックエンドが多いとか
- 対象者を絞って不可ぼれるように（もっと知りたくなる仕掛け）
- プロダクト横串で比較しやすく
- 自分のプロダクト・チームが他所と比べてどうか？を知りやすく
- どのチームが何に長けているか見やすく、ナレッジ共有の促進に繋げる
- プロダクトごと俯瞰して見える化
- リーダー陣が自担で把握できるよう
- 分析対象の傾向を見える化：若手が多いとか、バックエンドが多いとか
- 定性的評価の曖昧さ
- 定量に比べて入力者の感覚でばらつきあり
- 自己評価の低さから、実態より不当に低く入力されたり
- 定性的値は、時系列でウォッチして軌道修正にりようすべし
- 経過観察を前提にしたサーベイ設計、分析基盤を準備するべし
- 施策の成功度合いの計測に利用、など
- 強みと弱みから、どこから手をつけるべきか？打ち手の優先順位をつける
- 現場との対話に重きを置いた
- 立ち止まっている人に、障壁をヒアリングし特定
- 使い倒している人に課題と改善案を共有し、クリティカルな課題を選ぶ
- 解消していくことで、協力的になるスパイラルを産む
- 具体的な一手の例
- Quick Wins (即効性重視)
- 市街ツールの利用申請フロー短縮
- 開発作業動画の共有
- Systematic (組織的整備)
- AI特化ポータルを公開
- プロダクト組み込み時のセキュリティルールの策定
- Quick Wins (即効性重視)
- 現場との対話に重きを置いた
- Q&A
- 現状を可視化して想定外だった気付き
- 特定部署のとある人の全社への共有が多い一方、意外とチームの利用状況が連動していない：周囲への実践レベルの共有に至っていない？という仮説
- 可視化が入ったことでマネジメントの意思決定への変化
- アンケート可視化＋ヒアリングがエビデンスになり、踏み切れなかった決断の後押しになった
- 現状を可視化して想定外だった気付き
仕様駆動開発の組織的定着に向けた取り組み～『楽楽電子保存』開発チームの事例～
- 開発プロセスの試行錯誤について
- プロダクトと開発体制
- 品質課題：業務判断がサービス層に分散する傾向
- 日本・ベトナムのグローバル開発体制
- 開発へのAI活用
- 25年度から活用始動、上期とりあえずやってみるトライアルを試行
- 3Qから生花の刈り取りができた（生産性向上）
- 今後仕様書駆動開発への適用と組織定着
- 要件定義・ドラフトの生成、レビュー
- アウトプットをプロンプト化してAIに精度高く自己レビューさせている
- 設計リードタイムを30%短縮
- 実装フェーズ
- 作成レイヤー単位でカスタム指示を整備している（Controller / Domain / Repository）
- e.g. Controller にビジネスロジックを書かない
- instructions に対象の関する構造、責務、テスト方法、実装の禁止事項などルールを明文化
- AIに対して何をしてほしいかだけでなく、何をして欲しくないか、どこまでやるかを明言化し、実装品質を安定化
- オフショア特有の課題解決にも：ベトナム側のPR日本語説明文のAI生成で、日本側のレビュー負荷を軽減（なぜ、なにを、どうやって、アーキ図を Mermeid で自動生成）
- 作成レイヤー単位でカスタム指示を整備している（Controller / Domain / Repository）
- オフショア開発との親和性、成果
- オフショア開発への最適化に向けて情報の構造化を進めていた
- 設計の見直し、PR単位の最適化、サブシステムの責務分離
- 人間向けの施策が、AI活用にも同様に効果があった
- 入力トークンを抑制し推論精度向上
- AIが迷わない
- 開発サイクルが改善した：マージ頻度が6倍に、開発量も増加
- オフショア開発への最適化に向けて情報の構造化を進めていた
- より洗練した活用に向けた取り組みの展望
- 現在：要件、設計、実装のフェーズがばらばら
- 理想：仕様があれば、AIが形にし仕様とコードが同期されている状態
- 苦悩中
- ドキュメントが GitHub 外にあったり、形式にばらつき、MCP参照だが手動運用も多い
- Copilot / Claude 使い、カスタム指示やスキルを最適化、整備、AIに任せる範囲を明確化していく
- Q&A
- アーキ情報は製品リポジトリに含めているか
- 製品コードには含めていない（Issueに記載）
- リポジトリにドキュメントを入れることは検討中
- レビュー時の大量の手戻り、開発者の成長阻害などで生産性落ちる課題はあったか
- 書き方、変数名のレベル感は指摘しなくなった：AIの精度が高い、開発者として頑張るところではない
- ものとして考えるのに使う時間は増えたイメージ
- 開発者成長：対話できるとより成長につながり、人による
- この実装どういうこと？をAIと対話できること
- 何ができるようになることを何をゴールにしているか
- エンジニアに対し複数エージェントが並列に作業できるか、非稼働時間も作業できるか
- 人間側のコンテクストスイッチが課題
- アーキ情報は製品リポジトリに含めているか
出してみてわかったAIエージェントプロダクトの舞台裏〜楽々AIエージェント for 楽々精算〜
- AIプロダクトのあるある課題をどのように乗り越えたか？
- プロダクト概要
- ゼロから半年でリリース
- 精算書の帳票の紐付け、従来経費内容をひとつひとつ手入力していた作業をAIエージェントで代行
- 開発中に立ちはだかった3つの壁
- LLMコスト問題
- 試算：1申請あたり1,000円（コスパ悪い）
- 全項目に対し丁寧に推論、1申請ごとのリクエストが多かった、1項目ごとにコンテクスト量も多かった
- 過去の経費精算書から機械学習により類似伝票を探索することで、推論量を大幅に削減した
- LLMコスト問題
- 精度問題
- AI生成のデータ品質が不安定、経費精算ルールも多種多様
- 既存の規定違反チェック機能で、顧客ごとに設定可能なルールベースチェックをAIエージェントのワークフローに組み込むことで解決
- 応答速度問題
- 当初1回2-5分以上、アクセス集中やデータの詳細さによる課題
- 帳票紐付けと作成を分離し並列処理化
- 作成指示のうらで残りのタスクを進行し、表では同時に複数の経費精算ができるように
- ユーザーからの反響
- ポジティブ：早く終わった、備考記載も自動化された
- ネガティブ：自分でやった方が早い、非同期処理に慣れない
- 展望
- 3つの観点で評価、実現可能性、事業継続性、有用性
- コスト削減は継続的に取り組み、ユーザー体験は当初想定から妥協あり（非同期化：実現可能性とのトレードオフ）
- Q&A
- 非同期仕様への気づきを得るまでのPoCサイクルの回数
- 5回、Miro、プロトツールでの紙芝居モック含む
- AI Agent というより ワークフローへの AI 組み込み
- Aegntic なワークフローは、経費精算においてはユーザーにとって分かりにくかった、ユーザーが求めているのは安定性
- 非同期仕様への気づきを得るまでのPoCサイクルの回数