スキルを作る、その前に！複数人で使われるスキルを 作るためのプロセス

「自分が使いやすい ≠ 他人が使える・チームで使える」
プロダクト作りと一緒で、人と一緒に使うものを作るって難しいですよね。
このイベントでは、どのようなスキルを作ったか？という結果の話ではなく、どのようにスキルを使ってもらえるよう準備していったか？というプロセスの話をしました！

Transcript

1. 2026/10/01 スキルを作る、その前に！ 複数⼈で使われるスキルを 作るためのプロセス プラットフォーム開発本部 第3開発部 Developer Productivity Group / AXグループ ふるじゅん
2. ⾃⼰紹介 ふるじゅん •前職：Webディレクション・デザイン・実装・解析など幅広く経験 •2023年4⽉ DMM ⼊社。 • Developer Productivity Group の デザインシステム開発チームにて、 チームリーダー / プロダクトオーナー / デザイナーを担当 •2025年度〜さらに広範囲の取り組みに注⼒ ◦ 開発組織内でユーザー中⼼なアプローチの導⼊提案とプロジェクト ⽀援（イネイブリング） ◦ • 本部全体の AX 戦略推進（プロジェクト企画・遂⾏） X: @design_oldriver
3. 私たちの組織 •DMM.com： ◦ 60種以上の多様な事業・サービスを展開 •プラットフォーム開発本部： ◦ 各事業に共通基盤・共通機能を提供 ◦ 決済、ログイン、レビュー、ポイント、クーポン... •AXグループ： ◦ プラットフォーム開発本部のAX導⼊を推進する ◦ 成果の可視化 ◦ AI関連の基盤提供 ◦ etc…
4. 組織図... プラットフォーム開発本部 第1開発部 第2開発部 第3開発部 横断的な活動をする部 AXグループ 開発周りの AI推進をしていく 200名くらい？ 第4開発部 プラットフォー ム戦略企画部
5. 前置き •本当にまだまだ「現在地」です！ •私個⼈は、今チーム活動より個⼈活動が多く、実際に本当に多様なチームで使わ れる再現性があるかは保証できない！（なので⽂脈しっかり⽬に共有を⼼がけま す） •この先うまくいくかもしれないし、失敗するかもしれない！ •似た悩みを持つ⼈にちょっとでもインスピレーションになれば幸いです！ なんとかつたわれ〜
6. スキルを作るとよく起こること •組織でAI活⽤を進め、スキルも作った •でも、チームでは使われない •複数⼈で改善する体制も作れていない Issue ⾃分が使いやすい ≠ 他⼈が使える・チームで使える
7. 最近作ったスキルの話をします 指標ロジックレビュー スキル 背景：本部全体で「AI コストを成果として説明 できるようにしましょう」の流れ到来 •「AIへの投資」を「成果」として視覚的にわかりや すくしロジック整理をサポート ◦ AI 投資 → パフォーマンスや品質 → アウ トカム → ビジネスインパクト ◦ 関⼼や役割が異なる19グループマネー ジャーの利⽤を想定 •
8. どうやって取り組んだか 中⾝ではなく、“プロセスの話”をします！
9. 使ってもらえない3つのリスク このリスクを乗り越えないといけない 壁 アプローチ 必要性を感じない ... ① イシューから始める これが欲しいんじゃない ... ② 「標準化ライン vs 入力で担保を見極める 使いにくい... ③ 恐れず改善できる仕組み
10. ① イシューからはじめる - AX戦略は⽴てた。戦術も⽰した。 - しかし、各グループが⽬標やアクションに適切に落とし込めているか、成果を出 ⽂脈 せる環境が整っているのか不明だった - AXグループとして何を⽀援すべきかもわからない...！
11. ① イシューからはじめる - AX戦略は⽴てた。戦術も⽰した。 - しかし、各グループが⽬標やアクションに適切に落とし込めているか、成果を出 ⽂脈 課題の特定 せる環境が整っているのか不明だった - AXグループとして何を⽀援すべきかもわからない...！ - マネージャーの⽯垣さんと、プロダクト状況、戦略、温度感をグループヒアリング - わかったこと - 各グループで期待される成果や、ステークホルダー、判断基準が結構バラバラ - 売上に直結しないプロダクトは特に、成果貢献を説明するには翻訳が必要 - だがしかし、その整理ができる余裕があるグループも少ない
12. 課題の徹底理解 ・技術⾰新によって起こりうるリスクを共有 し、全体で「確かにそうかも...！」の納得感を醸 成 ・納得してくれた⽅が結果的に早い ・マネージャーにはコストの話が最も響く。相 ⼿に伝わる⾔葉を使うことを意識
13. 全体像の徹底理解 ・納得感２。「なんのためにやるか」を全体像 や⽬指す状態と共に⽰す。 ・忙しくても「確かに必要だな...ごもっともだ な...」状態になることで、アクションを⼀押しで きる。
14. 明確な依頼 ・AXグループのマネージャー経由で依頼を出す ことで、各マネージャーへの課題が⽣まれる。 ・⽬的と課題、明確なタスク、スケジュール⽬ 標、成果物、また補助ツールや⼿順があること ・結果的に、⾏動しない理由がない状態にする （あとはやる気だけ ｳｵ-）
15. ②標準化ライン vs ⼊⼒で担保を⾒極める • 各グループで重視する⽅向やコンテキストは様々 • 売上 • 事業部 • 不正アクセス • CS... • 無理にまとめるのは現実的じゃない • マネージャーの負担、すり合わせラリーするコスト...減らせるものは減らしたい
16. ⼊⼒ 標準化ライン vs ⼊⼒で担保を⾒極める ・指標ロジック、ソフトウェア品質の順守、 チームトポロジーのチーム分類とそこに求められ る期待値は、どのプロダクトチームでも不変であ る。 ・それを握ることで多様な複数グループのプロダ クトマネジメントを包括的に⼀部サポートできる のでは 既存戦略・重要指標・チーム概要 処理 指標整理・不⾜や⽭盾の特定・既存指標の 収集 出⼒ 指標改善から事業成果までを⼀枚で説明する
17. ③ 恐れず改善できる仕組み • スキルの修正の品質は⼀定ラインまで⾏くと⾼⽌まり、もしくは劣化する • モデルの変化によっても品質の劣化に晒されるリスクが常にある • これに対抗しながら推論の品質を落とさず、改善活動を続けるには？
18. 成果物を定量評価する 以下の観点を、YES/NO で判断できる基準まで 落とし込み。 ・最低限⼀つ以上、アウトカムとパフォーマンス指標が 接続されたロジックが存在するか ・チームトポロジーのチーム分類からみて、この指標は 妥当性があるか ・重視するソフトウェア品質を担保する指標がロジック に含まれているか ・指標の因果関係が成り⽴っているか → 成果物スコア =（100満点-減点）を出す💯
19. スキルを複製するスキル v2, v3 …と既存スキルにバージョンをつけて複 製できる仕組みを⽤意。 ・全てのスキルには⼊⼒要件・出⼒要件・⼿順が含まれ ている ・修正前後を同じ出⼒要件で⽐較する時に便利 ・⼤きな変更では現⾏版を残し、新しい版を変更するこ とで劣化を恐れなくて済む ・精度低下への不安を減らし、安⼼して試せる状態 → これは複数⼈で使う時にも役⽴ちそう👀
20. 現在地 •先⽇各グループへ展開し、活⽤してもらっている段階 •オンボーディング資料と⼀緒にマネージャーへ配布 •10⽉中には各グループと状況確認・すり合わせを⼀回ずつ⾏っていく
21. ① イシューからはじめる まとめ 複数⼈で使われるスキルを 作るためのプロセス ② 合意できる評価軸から始める ③ 改善が怖くない仕組みを作る
22. ご清聴ありがとうございました 皆さんのチームで、メンテのために⼯夫していることも教えてください！