AIで仕事のやり方を変える

Transcript

1. AIで仕事のやり方を変える 〜 新しい当たり前を浸透させる、estie の3つの事例 〜 matsu7874 2026年9月9日 AI活用 LT祭り
2. 自己紹介 matsu7874 SWE（EM / Customer Reliability Engineer）@ estie Ops（営業・CS）の業務効率を上げるための仕組み作りを している 技術広報も担当 0歳児と暮らしている © 2026 estie, Inc. 1
3. 「AI で仕事のやり方が変わった」と 言えるのは、いつからか？ © 2026 estie, Inc.
4. 作った仕組みが、 当たり前に使われるようになったとき © 2026 estie, Inc.
5. 3つの事例 事例 1. タッグ開発Night 2. 発信物レビュー 3. Skill 配布 何が当たり前になったか 非エンジニアが Pull Request を出す レビューは Slack に本文を貼るだけで受ける 共通のスキルの最新版を使う 仕組みを作っても、使われなければ意味がない。 3つとも「どう使われるようにしたか」を中心に話します。 © 2026 estie, Inc. 2
6. 事例1: タッグ開発Night VoC（顧客の声）に最も近い人が自らプロダクトに手を入れられるようになれば、仮説検証のサイクルは何 倍も速くなるのではないか。 BizDev・PM・UI デザイナーなどの非エンジニアが AI を活用してコーディングし、エンジニアがタッグを 組んで支援する社内イベント。2026年2月、デザインエンジニアの kkaru が企画・運営した。 狙い Discovery と Delivery の機会を10倍にする 非エンジニアとエンジニアがペアを組む。題材を事前に決め、開発55分、各ペア3 形式 分で成果発表、その後ふり返り 初回の結果 13ペアが参加。後日 10件以上の PR がマージ、社内向け Chrome 拡張2つ © 2026 estie, Inc. 3
7. なぜ「タッグ」なのか エンジニアが代わりに作るのでも、Opsメンバーが1人で挑むのでもなく、ペアで取り組む理由。 1. Opsメンバーが VoC を起点に、自らプロダクトを改善できるようになる 顧客の声を聞いた人が、その日のうちに手を動かせる 2. その視点を Pull Request として受け取れるようになる 口頭の「お願い」が diff になり、プロダクト改善の方向がいっそう鮮明で多角的になる 3. Opsメンバーが実装上の制約を肌で感じ、仕様策定の質が上がる 「なぜすぐできないのか」を体験として理解できる © 2026 estie, Inc. 4
8. ルールが肝 ルール 狙い 題材は依存が少なく、失敗しても影響 既存機能の軽い改善。1ファイル・1画面・1API が限定的なもの アウトプットは PR 1つ以上 ＋ 動作確認 「動くもの」と「説明」までを1セットにする 用 URL ＋ 口頭紹介3分 開発時間は55分 短いが、スコープを小さく切る強制力として機能した エンジニアはコード・プロンプトを書 手を動かすのは非エンジニア＋AI。質問対応と安全面の助言だけ かない イベント中の PR マージは禁止 後日レビューを通してから判断する 機密情報をプロンプトに入れない 安全側に倒す Devin（AI コーディングエージェント）で開発し、Preview 環境で動作 GitHub アカウントは不要 確認 © 2026 estie, Inc. 5
9. 2回目・3回目を私が運営 育休から戻ってきたら、すごい社内イベントが開催されていた。ただ、参加できなかった人もたくさんい る。Devin を使うことを浸透させたい。そう思って再開催した。 回 日時 規模 第2回 2026年7月21日 夜 10ペア 第3回 2026年8月4日 昼 11ペア 初回のふり返りから変えたこと 「プロダクト・リポジトリ・データ」対応表を配り、「どこに指示する？」で詰まらないようにした Preview 環境を早めに立ち上げておく。Build 待ちが最大のボトルネックだった © 2026 estie, Inc. 6
10. 参加者の声 Ops「コードが読み書きできなくても作れて、要件を満たすことを自分で検証できると分か った」 Ops「優先度が低くて後回しになる改善を、自分でステージングに作ってチェックしてもら う流れを試したい」 Dev「Ops にどんなニーズがあるか知ることができた」 © 2026 estie, Inc. 7
11. さらに開催 2026年8月14日、別のメンバーがさらに参加出来なかったメンバーを集めて「タッグ開発 Afternoon Tea」 を開催した。私は関わっていない。 その後も、BizDev のメンバーが Devin を使い続けている。 顧客向け機能の改善を Preview 環境で作り、顧客にデモ 新機能を試作し、顧客の要望をヒアリング 事業本部 本部長から「細かい改善は BizDev で PR を出すのを文化にする」宣言 © 2026 estie, Inc. 8
12. 事例2: 技術ブログ・登壇資料のレビュー 技術ブログや登壇資料は、公開前に技術広報チームがレビューしていた。 観点が人の頭の中にあるので、レビュー待ちが発生する。指摘の中身は毎回似ている。 例 "esite" → "estie" 未公開のプロダクト情報が載っている 古い数値が使われている © 2026 estie, Inc. 9
13. 人力 → ツール → Skill → Slack で発火 段階 人力 ツール Skill Slack で発火 何があったか 時期 技術広報と広報が公開前にレビューする運用。観点は担当者の中で整理 従前から されていた textlint（校正ツール）で表記チェックを自動化。ただしレビュー担当者 従前から が手元で動かす形だった 「この資料をレビューして」の一言で Claude Code がチェックリストと textlint でレビューし、Canvas で共有。誰でも手元の AI で走らせられ 2026年3月 る Claude Tag（Slack 上の Claude）に同じリポジトリを参照させ、チャン 2026年7月 ネルに本文を貼るだけでレビューが返る。広報も同スレッドで確認 Skillまでは既存業務の自動化。Claude Tag導入で依頼の仕方が変わった。 © 2026 estie, Inc. 10
14. レビューのたびにルールが育つ 資料を配置 → Claude が レビュー → Canvas で共有 → 修正・ コメント → 学びを抽出 → rules/ を更新 取り入れなかった指摘も、理由ごと rules/ に戻す。次のレビューはその分だけ賢くなる。 やり取りが Slack チャンネルに移り、誰がどんな指摘を受けてどう直したかが全員に見える。レビューの観 点が、人間にも浸透する。 © 2026 estie, Inc. 11
15. 事例3: Skill をどう配るか estie は全社で Claude を使っている。エンジニアがどんどん追加する場と、Ops 標準として組織的に運用する場は、 リポジトリから分けた。 観点 共有plugin Ops標準plugin 対象 主にエンジニア？Ops向けもあり Ops（営業・CS） Claude Code の marketplace から各自が入 管理者が claude.ai 管理画面からプラグイ 配布経路 れる ン配信（GitHub 連携で自動更新） Ops のタスクフォースが精査し、承認制で 運用 誰でも PR を出せる 更新。標準を絞る 始まり 2025年12月 2026年8月、17件の棚卸しから © 2026 estie, Inc. 12
16. 共有pluginは自由に育てる 2025年12月「社内用の marketplace 作りました」。 いろいろな人がコミットするリポジトリになっている。 項目 2026年9月時点 13。コードレビュー規約、技術ガイドライン、フロントエンド規 プラグイン 約など 貢献者 / PR 15人 / 160超 plugin.json から marketplace.json を自動生成し、version 更新 CI 漏れを検知 © 2026 estie, Inc. 13
17. Ops標準plugin: 属人配布からの脱却 Ops メンバーは GitHub アカウントを持っていない。スキルは各個人が共有する形だった。 どれを使えばいいのか分からない、更新にも追従されないという課題があった。 配布方法（2026年8月の棚卸し・17件） 件数 claude.ai の個人リンク共有 7 .skill ファイルの添付 6 プロンプトのSlack投稿 4 組織配布 0 © 2026 estie, Inc. 14
18. Ops標準plugin: 決めたこと Ops 業務の標準スキル群を定義して配布する。 機微情報はスキル本文に書かない。 機微データは権限管理された参照先に置き、スキルには「どこをど う見るか」だけ書く 配布は claude.ai の管理画面からのプラグイン配信に一本化。 GitHub 連携で、リポジトリを更新すれば 全員に自動反映 最新版はGitHubでCREが管理する © 2026 estie, Inc. 15
19. Ops のスキルは Ops が作る Ops メンバーのタスクフォースでスキルを精査し、承認制で更新するルールにした。承認後に SWE が配布 処理をする。 業務の場面 スキルがすること 商談の前 公開情報から企業の概要と課題の仮説を整理する 商談の後 書き起こしから議事録の下書きを作る 顧客向け資料 社内フォーマットに沿って資料の下書きを作る 担当の引継ぎ 顧客とのやり取りから引継ぎ資料をまとめる © 2026 estie, Inc. 16
20. CREとして考えていること： 新しい当たり前を浸透させる 仕組みを作っても、使われなければ意味がない。 当たり前に使われるまでが、仕組み作りの仕事。
21. ご清聴ありがとうございました 質問・議論、歓迎です。X: @matsu7874 estie は商業用不動産の DX を推進する仲間を募集中です。 採用情報: https://hrmos.co/pages/estie/jobs?jobType=FULL&category=1756293647827165184