2026/10/01 スキルを作る、その前に！ 複数⼈で使われるスキルを 作るためのプロセス プラットフォーム開発本部 第3開発部 Developer Productivity Group / AXグループ ふるじゅん 

⾃⼰紹介 ふるじゅん ●前職：Webディレクション・デザイン・実装・解析など幅広く経験 ●2023年4⽉ DMM ⼊社。 ● Developer Productivity Group の デザインシステム開発チームにて、 チームリーダー / プロダクトオーナー / デザイナーを担当 ●2025年度〜さらに広範囲の取り組みに注⼒ ○ 開発組織内でユーザー中⼼なアプローチの導⼊提案とプロジェクト ⽀援（イネイブリング） ○ ● 本部全体の AX 戦略推進（プロジェクト企画・遂⾏） X: @design_oldriver 

私たちの組織 ●DMM.com： ○ 60種以上の多様な事業・サービスを展開 ●プラットフォーム開発本部： ○ 各事業に共通基盤・共通機能を提供 ○ 決済、ログイン、レビュー、ポイント、クーポン... ●AXグループ： ○ プラットフォーム開発本部のAX導⼊を推進する ○ 成果の可視化 ○ AI関連の基盤提供 ○ etc… 

組織図... プラットフォーム開発本部 第1開発部 第2開発部 第3開発部 横断的な活動をする部 AXグループ 開発周りの AI推進をしていく 200名くらい？ 第4開発部 プラットフォー ム戦略企画部 

前置き ●本当にまだまだ「現在地」です！ ●私個⼈は、今チーム活動より個⼈活動が多く、実際に本当に多様なチームで使わ れる再現性があるかは保証できない！（なので⽂脈しっかり⽬に共有を⼼がけま す） ●この先うまくいくかもしれないし、失敗するかもしれない！ ●似た悩みを持つ⼈にちょっとでもインスピレーションになれば幸いです！ なんとかつたわれ〜 

スキルを作るとよく起こること ●組織でAI活⽤を進め、スキルも作った ●でも、チームでは使われない ●複数⼈で改善する体制も作れていない Issue ⾃分が使いやすい ≠ 他⼈が使える・チームで使える 

最近作ったスキルの話をします 指標ロジックレビュー スキル 背景：本部全体で「AI コストを成果として説明 できるようにしましょう」の流れ到来 ●「AIへの投資」を「成果」として視覚的にわかりや すくしロジック整理をサポート ○ AI 投資 → パフォーマンスや品質 → アウ トカム → ビジネスインパクト ○ 関⼼や役割が異なる19グループマネー ジャーの利⽤を想定 ● 

どうやって取り組んだか 中⾝ではなく、“プロセスの話”をします！ 

使ってもらえない3つのリスク このリスクを乗り越えないといけない 壁 アプローチ 必要性を感じない ... ① イシューから始める これが欲しいんじゃない ... ② 「標準化ライン vs 入力で担保を見極める 使いにくい... ③ 恐れず改善できる仕組み 

① イシューからはじめる - AX戦略は⽴てた。戦術も⽰した。 - しかし、各グループが⽬標やアクションに適切に落とし込めているか、成果を出 ⽂脈 せる環境が整っているのか不明だった - AXグループとして何を⽀援すべきかもわからない...！ 

① イシューからはじめる - AX戦略は⽴てた。戦術も⽰した。 - しかし、各グループが⽬標やアクションに適切に落とし込めているか、成果を出 ⽂脈 課題の特定 せる環境が整っているのか不明だった - AXグループとして何を⽀援すべきかもわからない...！ - マネージャーの⽯垣さんと、プロダクト状況、戦略、温度感をグループヒアリング - わかったこと - 各グループで期待される成果や、ステークホルダー、判断基準が結構バラバラ - 売上に直結しないプロダクトは特に、成果貢献を説明するには翻訳が必要 - だがしかし、その整理ができる余裕があるグループも少ない 

課題の徹底理解 ・技術⾰新によって起こりうるリスクを共有 し、全体で「確かにそうかも...！」の納得感を醸 成 ・納得してくれた⽅が結果的に早い ・マネージャーにはコストの話が最も響く。相 ⼿に伝わる⾔葉を使うことを意識 

全体像の徹底理解 ・納得感２。「なんのためにやるか」を全体像 や⽬指す状態と共に⽰す。 ・忙しくても「確かに必要だな...ごもっともだ な...」状態になることで、アクションを⼀押しで きる。 

明確な依頼 ・AXグループのマネージャー経由で依頼を出す ことで、各マネージャーへの課題が⽣まれる。 ・⽬的と課題、明確なタスク、スケジュール⽬ 標、成果物、また補助ツールや⼿順があること ・結果的に、⾏動しない理由がない状態にする （あとはやる気だけ ｳｵ-） 

②標準化ライン vs ⼊⼒で担保を⾒極める • 各グループで重視する⽅向やコンテキストは様々 • 売上 • 事業部 • 不正アクセス • CS... • 無理にまとめるのは現実的じゃない • マネージャーの負担、すり合わせラリーするコスト...減らせるものは減らしたい 

⼊⼒ 標準化ライン vs ⼊⼒で担保を⾒極める ・指標ロジック、ソフトウェア品質の順守、 チームトポロジーのチーム分類とそこに求められ る期待値は、どのプロダクトチームでも不変であ る。 ・それを握ることで多様な複数グループのプロダ クトマネジメントを包括的に⼀部サポートできる のでは 既存戦略・重要指標・チーム概要 処理 指標整理・不⾜や⽭盾の特定・既存指標の 収集 出⼒ 指標改善から事業成果までを⼀枚で説明する 

③ 恐れず改善できる仕組み • スキルの修正の品質は⼀定ラインまで⾏くと⾼⽌まり、もしくは劣化する • モデルの変化によっても品質の劣化に晒されるリスクが常にある • これに対抗しながら推論の品質を落とさず、改善活動を続けるには？ 

成果物を定量評価する 以下の観点を、YES/NO で判断できる基準まで 落とし込み。 ・最低限⼀つ以上、アウトカムとパフォーマンス指標が 接続されたロジックが存在するか ・チームトポロジーのチーム分類からみて、この指標は 妥当性があるか ・重視するソフトウェア品質を担保する指標がロジック に含まれているか ・指標の因果関係が成り⽴っているか → 成果物スコア =（100満点-減点）を出す💯 

スキルを複製するスキル v2, v3 …と既存スキルにバージョンをつけて複 製できる仕組みを⽤意。 ・全てのスキルには⼊⼒要件・出⼒要件・⼿順が含まれ ている ・修正前後を同じ出⼒要件で⽐較する時に便利 ・⼤きな変更では現⾏版を残し、新しい版を変更するこ とで劣化を恐れなくて済む ・精度低下への不安を減らし、安⼼して試せる状態 → これは複数⼈で使う時にも役⽴ちそう👀 

現在地 ●先⽇各グループへ展開し、活⽤してもらっている段階 ●オンボーディング資料と⼀緒にマネージャーへ配布 ●10⽉中には各グループと状況確認・すり合わせを⼀回ずつ⾏っていく 

① イシューからはじめる まとめ 複数⼈で使われるスキルを 作るためのプロセス ② 合意できる評価軸から始める ③ 改善が怖くない仕組みを作る 

ご清聴ありがとうございました 皆さんのチームで、メンテのために⼯夫していることも教えてください！