AIで疲弊せずに⽣産性を上げるまで

Transcript

1. AIで疲弊せずに⽣産性を上げるまで
2. ⾃⼰紹介 ・名前 がーしら ・職業 プロジェクトマネージャー 部内事業推進リーダー ・経歴 ⾃社プロダクトを中⼼に、Webアプリ開発 や、リテール系のアプリ開発を経験したり品 質やAIについて推進したり
3. プロダクト紹介 ・会社名 ピープルソフトウェア株式会社 ・代表 横道彰 ・事業概要 地⽅の受託開発や⾃社サービスや ⾃社プロダクトの開発・運⽤、アプ リ開発やDX推進やコンサルティング など
4. 「変⾰期を⽣き延びるためのエンジニアリング⼒を⼿に⼊れる」 そんな事業計画からAIで⽣産性を向上しようと⾔う取り組みが始まりました 「AIに使われるのではなく使いこなす」 という命題を元に去年1年間AIを推進していったメンバーの1⼈として取組実績を報告します
5. 2025年8⽉のその時、世の中はAI開発⼿法が急速に進んでいた プロンプト バイブ コンテキスト 仕様駆動 ハーネス ループ グラフ Prompt Vibe Context SDD Harness Loop Graph 指⽰を与えて書い てもらう 感覚で対話しなが ら書いてもらう ⽂脈を渡して精度 を上げる 対話から仕様を策 定し、書いてもら う モデルが安全に動 作するための環境 を整えて⾛らせる ⾃律的に実⾏、検 証、修正のサイク ルを回す ノードとエッジで フローを回す 2023年〜 2025年2⽉〜 2025年前半 2025年11⽉前後 2026年2⽉前後 2026年6⽉〜 2026年7⽉〜 →⼀⽅、社内は「バイブコーディング」の経験をチラホラ聞きはじめた段階 ？？？
6. まずはAIを「知る」ところから フェーズ 1 ・ 知る • Gemini・Codex・Cursor・Claude を実際に契約して体験 • 使⽤⾯・管理⾯をいろいろ試して⽐較 （諸事情もあり全てを同時に⽐較することももできず紆余曲折） • Claude の Team プランに当時 Claude Code が無いなどの壁も →新しいAIが次々に出て性能もすぐに変わる。「最適なAIを判断する」のは諦めた →開発メンバーにVSCode利⽤者が多かったため、VSCodeライクな「Cursor」をメンバーへ
7. AIを「浸透」させ全員使えるようにしていく フェーズ 2 ・ 浸透 • AI をうまく使える⼈、使えない⼈の差が出はじめる • AI に任せきりで、⾃分で考えなくなる「認知的降伏」に陥るメンバーも • 認知的降伏…⼈間が⽣成AIの出⼒を検証することなく、⾃⾝の判断や答えとして無批判に受け⼊れてしまう⼼理的傾向 • 若⼿からシニアまで、レベル差のある教育をどうするかが課題に → AIそのものより「⼈とAIの付き合い⽅」を育てる難しさを痛感
8. 開発をAIで改善する フェーズ 3 ・ 改善 • プロジェクトによってAIを効かせる場所はまちまち（設計、製造、レビュー、テスト） • 成功も失敗もまちまち。プロジェクト、⼈、⼯夫によって結果が変わる • 「適⽤できる範囲」に限界はなく、⼯夫次第でバリューチェーンのどんな場⾯にでも適⽤できる • 採⽤、営業、製造、テスト、リリース、保守運⽤などなど → 改善に限界はなく「どの業務をAIで改善するか」の⾒極めが重要になった
9. 実装が速くなった分、レビューが追いつかなくなった 短縮分を打ち消す 実装完了後、レビュー完了までの待ち 時間が伸びた 実装で縮めた期間が、レビューで相殺 されてしまう ? 💦 レビュー待ちが滞留 💦 →これではAIで開発している意味がないのでは、と疑問に思い始めた
10. そうだ、レビューもAIに任せたれ 各々のAIレビュー メンバーが個別にエージェント へ依頼。抜け漏れがあり、レ ビュー観点のレベル感もそろわ なかった Copilotは使えず Bugbotから試す 当時の有⼒候補はCopilot。リポ ジトリオーナーの都合で導⼊で きなかった すでにメンバーが使っていた CursorのBugbotを、まず使って みることにした →レビュー品質を⼈に依存させないため、共通のレビューエージェントを置くことにした
11. Bugbot⾼い、、、 料⾦が⾼い 当時はCursor 1ライセンスと同じ ⾦額。負担が⼤きかった ⼈数課⾦ デフォルト英語 プルリクエスト作成者1名ごとに 課⾦。使う⼈が増えるほど費⽤が 膨らむ 指摘が英語で返ってくるため、メ ンバーの指摘内容解釈違いがしば しば →別のレビューAIを探し、評判のいいCodeRabbitを試すことにした
12. CodeRabbitを試しに導⼊すると、、、 ポエム アスキーアート ウォークスルー プルリクの内容を詩で要約して くれる。遊びのある演出 変更の流れを図で表現。少し崩 れているときもあるが、雰囲気 は伝わる 変更点をファイル単位で解説。 全体像の把握が早い →指摘は修正箇所だけで完結せず、処理全体の流れやコードの統⼀まで⾒てくれる
13. しばらくは良かったが、、、、 AIコードレビューを導⼊してしばらくすると、メンバーから不満の声が… 指摘が細かい 何度も⾔われる ストレス 重箱の隅まで指摘され、修正時 間がかかる 指摘→修正をなん度も繰り返し する 淡々と指摘を繰り返されて、フ ラストレーションが溜まる →品質は下げたくないので、指摘はしてほしい反⾯ストレスは取り除いてあげたい →同じような悩みを抱えたエンジニアがいないか調べた
14. 「CodeRabbit うざい」で検索してみた 同じ悩みを持つ⼈の声を、こんなキーワードで探しました 「CodeRabbit うざい」 「CodeRabbit 指摘うるさい」 「ウサギ うるさい」 「CodeRabbitを黙らせる⽅法」 「CodeRabbit イラっとする」 「CodeRabbit 指摘 鎮まれ」 →なかなかこれといった解決策がない中で、外国の記事で有⼒な内容を発⾒
15. トーン設定で指摘トーンを設定 海外記事で⾒つけた「disappointed mom＝失望したお⺟さん」にトーン設定を、⾃分の環境で試しました ① 設定してみた トーン設定を「失望したお⺟さ ん」に変更 ② 動かしてみた 指摘のトーンが想像以上に⾟辣 で、ハートにくるものがあった ③ 効きすぎた 怒りはなく指摘を重く受け⽌め るが、別の理由でメンタルが削 られる →求めているのは「重い正しさ」ではなく、もっとフランクで芯を喰った指摘
16. 失望した関⻄弁のお⺟さん
17. Before 指摘が冷たい印象 何度も重なると疲弊する
18. After 関⻄弁により不思議と親しみが 加わり、かつ例えも交じってニ コニコしながら修正できる
19. 関⻄弁の失望したお⺟さんにしたら、チームに余裕が⽣まれた 指摘粒度などの中⾝は変えず、しゃべり⽅だけを変えた結果 トーンを変えたら、好評だった 関⻄弁のお⺟さん⼝調にしたことで、メンバー が指摘を読むのを楽しんでくれるようになった。 「ありがとう」まで⾔ってくれる ⼈間味が出るまで微調整。指摘者を「1⼈の ⼈」として受け⽌められるようになった。 → 指摘の量は同じでも、受け取る側の気持ちに余裕ができた
20. まとめ 1 2 3 4 AIの進化スピードが⽬まぐるしいため、AIが変わっても影響がないような仕組みづくりが⼤事 使える⼈と使えない⼈に差がでたり、ベテランでも認知的降伏に陥る⼈がいる。⼈とAIの付き 合い⽅の教育が⼤事 どの業務を改善するかの⾒極めが鍵となり、⼯程や業務にどう適⽤するかは⼯夫次第でどこに でも適⽤可能。 中⾝は変えずトーンだけ関⻄弁に変更。受け取る側に余裕が⽣まれた。つまり⾔い⽅が重要。 結局は「⾔い⽅」で受け取り側の気持ちは変わるということ。 AIという物理（物のコトワリ）を通して⼼理（⼼のコトワリ）に触れた瞬間でした。