AIに狂うスタートアップが、あえて「人との協働」に全振りした新卒エンジニア研修 / New Graduate Engineer Training at a Startup Accelerating AI Adoption

Transcript

1. PBL Pub 2026 登壇資料 AIに狂うスタートアップが、 あえて「⼈との協働」に全振りした 新卒エンジニア研修 2026年8⽉19⽇ 株式会社ログラス ⼤野 英（おーのA）@ohnoeight 1
2. 2025年9⽉末のこと
3. 新⼈エンジニアをいきなり各チームに⼊れるのは難しい。 ⼀定の戦⼒化を図った上で 各チームに配属できるよう全社的なエンジニア向けの 新⼈オンボーディング設計をお願いします。
4. 50⼈強のエンジニア組織（デザイナー‧PdM除く）に 数カ⽉後、8名の新卒エンジニアが⼊社するという状況 • Cursorが出始めた頃から、採⽤要件を絞るなど、かなり採⽤枠を縮⼩していた • 新卒採⽤は2年スパンで⾏うが、組織の全体規模の2年前の⾒込みから⼤きく乖離していた • それらの要因から、結果的に全体のエンジニア数に対する新卒の割合が多くなってしまっていた • ゆえに、メンター負担が⼤きい状態でのチーム受け⼊れは難しい ※参考情報：25卒（昨年）は3名の新卒エンジニア入社・基本チーム配属で OJTオンボーディング 4
5. 新⼈エンジニアをいきなり各チームに⼊れるのは難しい。 ⼀定の戦⼒化を図った上で 各チームに配属できるよう全社的なエンジニア向けの 新⼈オンボーディング設計をお願いします。
6. 「⼀定の戦⼒化」 ＝ 「チーム配属時のメンター負担を軽減せよ」 かなり⾼いレベルの底上げを 要求されている!!!
7. 「‧‧‧‧‧‧‧わかりました。」 （いやいや、分からん！）
8. PBL Pub 2026 登壇資料 AIに狂うスタートアップが、 あえて「⼈との協働」に全振りした 新卒エンジニア研修 2026年8⽉19⽇ 株式会社ログラス ⼤野 英（@ohnoeight/おーのA） 8
9. ⾃⼰紹介
10. ⾃⼰紹介 ⼤野 英（おーのA） Akira Ohno 株式会社ログラス CTO室 新卒入社のキヤノンでスクラムに出会ってから、 自律的な組織での開発に魅了され、一念発起しスタートアップへ転職。 スタートアップ複数社ののち、前職のスタートアップではスクラムマスターとしてス クラムの導入を推進、その後、同社でEMを経てVPoE就任。 2024年10月に株式会社ログラス入社。 現在は新卒育成に従事。 CRR Global認定システムコーチ（ORSCC）/ 8月1日に青山学院大学のワークショップデザイナー育成プログラム修了。 趣味 ：筋トレ・サウナ 10
11. PBL（Project Based Learning）と スクラムを 導⼊しようと考えた経緯 11
12. PBLとスクラムを導⼊しようと考えた経緯 私を成⻑させてくれた過去―― スクラムが⼈の成⻑につながるという強烈な原体験 • 私⾃⾝がスクラムチームの開発者だった時期の経験が エンジニアとしてのスキルを最も成⻑させてくれたと感じている • 前職でのエンジニア組織へスクラムを導⼊し、 新卒、中途⼊社のメンバーが未経験な知識領域の学習も含めて急成⻑する姿を⾒てきた • アジャイル/スクラムコミュニティに参加するようになってから たくさんの⼈と関わることで様々なことを学び、⼈として成⻑してきた実感がある 12
13. PBLとスクラムを導⼊しようと考えた経緯 私を成⻑させてくれた過去―― スクラムが⼈の成⻑につながるという強烈な原体験 • 私⾃⾝がスクラムチームの開発者だった時期の経験が エンジニアとしてのスキルを最も成⻑させてくれたと感じている • 前職でのエンジニア組織へスクラムを導⼊し、 新卒、中途⼊社のメンバーが未経験な知識領域の学習も含めて急成⻑する姿を⾒てきた • アジャイル/スクラムコミュニティに参加するようになってから たくさんの⼈と関わることで様々なことを学び、⼈として成⻑してきた実感がある 私の成⻑はいつもスクラムと共にあった 13
14. PBLとスクラムを導⼊しようと考えた経緯 Project Based Learningという選択肢―― むしろそれ以外の選択肢で「⼈の成⻑」に寄与する⼿段が分からなかった • 「アジャイルPBL祭 2025」私⾃⾝も参加したり、 楽天がPBLで研修をやってたことを知っていたり、 PBLが「なんか良い」ことだけは知っていた 参考：楽天の新卒研修についての資料 2025年10月31日 早い段階でPBLの方向性には行き着いた • 検討開始当初〜年末頃まで、外部研修を検討したが ログラスが求める⽔準の学びを標準で提供できる会社を探せなかった • 結局、時間的制約から内製を軸に検討することになり、 私にできるのは、これまでのスクラムの経験から研修を提供することだけだった 14
15. PBLとスクラムを導⼊しようと考えた経緯 スクラムで研修を実施する必然性が無く、 スクラム好きの「スクラムやりたい」という主張以上のものが無かった • 現状、ログラスでは全てのチームがスクラムで開発しているわけではない • プロジェクトによっては、技術を学ぶ機会は新卒依存になってしまう • AIによって、開発のあり⽅が様変わりする中で、 研修でチームのコラボレーションを学ぶことにどれだけの価値があるのか分からない どうしたものか・・・ 15
16. ログラスの社内状況＝AI狂気 16
17. ログラスの社内状況＝AI狂気 AI狂気―― 積極的なAI活⽤を組織的に推進する状況 17
18. ログラスの社内状況＝AI狂気 全社的にAIの活⽤を⼀気に加速 2025年前半 エンジニアは 全員 Claude活用 Claude Code 勃興 参考：生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜 18
19. ログラスの社内状況＝AI狂気 基礎⼒を⾼めて欲しいという要求に対し、AIエージェントを活⽤する前提では‧‧‧ • 技術を知らないとAIをうまく使えない今は、まだソフトウェア開発の基本的知識は求め られている。半年後、新卒が⼊社する頃には‧‧‧？ • 必要な技術基礎⼒は変わっている？ • AI使ったら研修課題なら簡単にできちゃうし、AI使わない研修で基礎⼒を磨くべきか？ • むしろ、AIを上⼿く使うための研修が重要か？ 19
20. ログラスの社内状況＝AI狂気 変化が⼤きすぎて数ヶ⽉先の状況が全く分からない。答えが無いから決めるしかない • 社会の変化とログラスの状況、 AI狂気を掲げるログラスのプロダクト組織はほぼ世の中の状況をトレースしていた • 研修を検討していた当時も、 1ヶ⽉も経てば状況が変わるような⼤きな変化の中にいた • 新卒研修を開始する時期のことなんて、もはや想像しても想像しきれない AIのことは⼀旦脇に置いて研修設計を開始 20
21. プログラム修了時のアウトカムを定義 22
22. 新⼈エンジニアをいきなり各チームに⼊れるのは難しい。 ⼀定の戦⼒化を図った上で 各チームに配属できるよう全社的なエンジニア向けの 新⼈オンボーディング設計をお願いします。 アウトカムが抽象的でイメージしにくい
23. プログラム修了時のアウトカム定義 AI勃興前後でチームの「基本的な構造」は変わっていない 少なくとも1年以内は変化しないと想定 • 最初の配属においては必ず「チーム体制」の中に属するということ • 新卒への業務アサインについては、 ⼒量に合わせて上司‧メンターが依頼するということ • チームの中で活躍できているかどうかを評価するのは⼈であるということ 24
24. プログラム修了時のアウトカム定義 AI勃興前後で変わらない構造の中で チーム体制の中で求められる「⼀定の戦⼒である」状態は？ • 極⼒⼿助け無く仕事をできる • 他のチームメンバーが⼿助けしなければならない状況に 気づけるよう状況を共有できる • ⼿助けして欲しい時に、助けて欲しい状況にあることを発信できる 25
25. プログラム修了時のアウトカム定義 全体⽬標「1週間未満で完了できる開発業務を独⼒で完遂できる状態を⽬指す」こととし そのために必要な3つの⼒を定義 ⾃律的遂⾏⼒ 1週間未満で完了できるチケットを⽇単位のタスクに分解し、メンターの常時伴⾛なしに、 当該チケットごとに定められた完了基準を満たして遂⾏できる 情報共有⼒ 関係者と定めた共有⼿段を⽤い、⾃⾝の進捗状況と課題‧⾒通しを、⽇次で最新の状態に 保つことで、関係者が作業状況を確認できる状態を維持し、作業をホワイトボックス化できる リスクの早期検知⼒‧対応⼒ 業務の遂⾏やシステムにトラブルが発⽣する可能性があると判断した場合、それを⾃分だけで抱え込まず、 必要な情報を添えて、適切なタイミングを⾒定め、⾃らの判断で関係者にアラートを上げることができる 26
26. チーム活動で学ぶか、個⼈活動で学ぶか 27
27. チーム活動で学ぶか、個⼈活動で学ぶか 『スクラム好きの「スクラムやりたい」という主張』ではない アウトカムに向かう⼿段としてチーム活動を捉え直す ※当時の検討資料から抜粋 28
28. チーム活動で学ぶか、個⼈活動で学ぶか ⾃らのアウトプットやAIのアウトプットに対して批判的思考で取り組めるか否か 個⼈の素養‧これまでの経験に依存する AI アウトプット アウトプット 新卒 新卒 個⼈開発では批判的思考ができているか確認が難しい 29
29. チーム活動で学ぶか、個⼈活動で学ぶか 個⼈で作業する限り、誰かが壁になり、「本⼈が気づいていない状態」に指摘が必要 AIを使わなくても、AIを使っても、構造は変わらない AI アウトプット メンター アウトプット メンター フィードバック フィードバック 新卒 ここの考え方は このように考えます 新卒 ログラスでは このように考えます メンターを⽤意する必要性 30
30. チーム活動で学ぶか、個⼈活動で学ぶか チーム開発で他者の視点を交えることで 「相⼿が気づいていないこと」への気づきを与え、「批判的思考」を相互に育む 新卒 新卒 アウトプット アウトプット 新卒 新卒 AI 31
31. チーム活動で学ぶか、個⼈活動で学ぶか メンバー同⼠が互いの「思考の壁」になることで、 1⼈では到達できないレベルまで批判的思考を深めるための仕組みとしてのチーム開発 • ⾔語化の強制： ⾃分の考え（またはAIの提案）をチームに説明する際、論理的根拠の必要性 • 視点の拡張： ⾃分が⾒落としていた懸念点を、異なるバックグラウンドを持つ同期から指摘 • 無知の⾃覚： 教え合う過程で、⾃分が深く理解していなかった知識、もしくは、 批判的思考が及んでいなかった個所への気づき 32
32. チーム活動で学ぶか、個⼈活動で学ぶか AIや先輩を頼りがちになる配属後よりも今。新卒同⼠、研修だからこそできること。 • 配属後は「⾃分より経験がある⼈たち」や 「知識を持っているAI」と仕事することになる • 先輩やAIが教えてくれることに対して、 配属直後から批判的であり続けることは難しい • ⽐較的⼼理的安全な同期同⼠だからこそ、遠慮すること無くぶつかり合える 33
33. チーム活動で学ぶか、個⼈活動で学ぶか AIや先輩を頼りがちになる配属後よりも今。新卒同⼠、研修だからこそできること。 そもそも AI時代に本当に 批判的思考が必要か？ • 配属後は「⾃分より経験がある⼈たち」や 「知識を持っているAI」と仕事することになる • 先輩やAIが教えてくれることに対して、 配属直後から批判的であり続けることは難しい • ⽐較的⼼理的安全な同期同⼠だからこそ、遠慮すること無くぶつかり合える 34
34. 批判的思考とAI ⽣成AIの利⽤によって⼈間の「批判的思考」が低下、認知的努⼒を怠るようになる傾向が マイクロソフトとカーネギーメロン⼤学の研究で⽰されていた "We find that GenAI tools reduce the perceived effort of critical thinking while also encouraging over-reliance on AI, with confidence in the tool often diminishing independent problem-solving." ”我々は、 生成 AIツールが批判的思考の認知的努力を減らす と同時に、 AIへの過剰依存を助長し、 ツールへの信頼がしばしば独立した 問題解決能力を低下させることを発見した ” 参考：The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers AI時代だからこそ批判的思考を育む重要性は⾼まっている 35
35. 批判的思考とAI AI時代だからこそ、新卒研修を「⼈との協働」に全振りすることに価値がある Project Based Learningの採⽤へ 1週間未満で完了できる開発業務を 独⼒で完遂することができる ⾃律的 遂⾏⼒ 情報 共有⼒ リスク 検知対応⼒ AI勃興前後で変わらない 基本的な業務遂⾏スキル 批判的思考を育むための チーム活動 36
36. 新卒エンジニア研修内容の紹介 38
37. 株式会社ログラスの紹介 唐突ですが、研修テーマに関わるため、ここで紹介 39
39. 企業価値向上のプラットフォーム構築を⽬指す 41
40. 「Loglass Series」プロダクトラインナップ 42
41. 新卒エンジニア研修内容の紹介 前提：本発表で説明するProject Based Learning（PBL）は以下の特徴です。 • 課題設定については、研修運営が実在するログラスの顧客のニーズを基に、 フィクション課題をあらかじめ設定した • 新卒開発チームは上記の担当者の声から顧客の課題を特定し、 その課題を解決するソフトウェアプロダクトを作成する • スクラムを⽤いて開発を進める • ユーザーヒアリング‧スプリントレビューでは、ログラス社員が仮想顧客を演じる • 技術的に分からないことは、社内のエンジニアに問い合わせる 43
42. 新卒エンジニア研修内容の紹介 Phase1：10⽇間 / 開発基礎 インプット + チーム活動練習 ‧スクラム研修 ‧AI 研修 ‧クラウド研修（AWS Jump Start） ‧Git 研修 ‧アジャイル研修 ‧ClaudeCode研修 ‧DDD研修 ‧ソフトウェア設計研修 ‧マインドセット（具体‧抽象） ‧QA‧ソフトウェアテスト研修 ‧データベース研修 DB基礎 ‧リレーショナルモデリング研修 ‧コンテナ研修 ‧WEB フロントエンド研修 ‧kubernetes研修 ‧observability研修 Phase2：25⽇間 / 開発実践 ログラスの⼀部機能 + α の開発 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 ＋ 各⽇ チームでの ⼩スプリント チームでの仮説設定 研修に対する アウトプット Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 44
43. 新卒エンジニア研修内容の紹介 Phase1：10⽇間 / 開発基礎 インプット + チーム活動練習 ‧スクラム研修 ‧AI 研修 ‧クラウド研修（AWS Jump Start） ‧Git 研修 ‧アジャイル研修 ‧ClaudeCode研修 ‧DDD研修 ‧ソフトウェア設計研修 ‧マインドセット（具体‧抽象） ‧QA‧ソフトウェアテスト研修 ‧データベース研修 DB基礎 ‧リレーショナルモデリング研修 ‧コンテナ研修 ‧WEB フロントエンド研修 ‧kubernetes研修 ‧observability研修 Phase2：25⽇間 / 開発実践 ログラスの⼀部機能 + α の開発 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 ＋ 各⽇ チームでの ⼩スプリント チームでの仮説設定 研修に対する アウトプット Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 45
44. 新卒エンジニア研修内容の紹介 基礎技術⼒は、AIがあるからこそ「できなくても知っていれば良い」 「意識的有能」の状態まで引き上げない 学習の5段階 無意識的有能に 意識的有能 • 問いをAIに⽴てるために「知っている」 • AIに与えるコンテキストとして ログラスの「技術的観点」の抜け漏れに 気づくために「知っている」 • AIの回答を鵜呑みにしないために「知っている」 無意識的有能 意識的有能 意識的無能 ここを ⽬指す 無意識的無能 引⽤：NLP学び⽅ガイド 46
45. 新卒エンジニア研修内容の紹介 Phase1：10⽇間 / 開発基礎 インプット + チーム活動練習 ‧スクラム研修 ‧AI 研修 ‧クラウド研修（AWS Jump Start） ‧Git 研修 ‧アジャイル研修 ‧ClaudeCode研修 ‧DDD研修 ‧ソフトウェア設計研修 ‧マインドセット（具体‧抽象） ‧QA‧ソフトウェアテスト研修 ‧データベース研修 DB基礎 ‧リレーショナルモデリング研修 ‧コンテナ研修 ‧WEB フロントエンド研修 ‧kubernetes研修 ‧observability研修 Phase2：25⽇間 / 開発実践 ログラスの⼀部機能 + α の開発 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 ＋ 各⽇ チームでの ⼩スプリント チームでの仮説設定 研修に対する アウトプット Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 47
46. 新卒エンジニア研修内容の紹介 Phase1の基礎研修中もチーム活動をすることで Phase2の開発実践でのチーム活動に備え、⾜がかりにする • エンジニア基礎研修の1⽇は 座学＋チームによる⾃主学習 で構成、1⽇で完結 • 10:30研修開始、社内エンジニア講師による説明（座学）で進め、15:00前後に講師パート終了 • 15:00以降 、スプリントを2.5〜3時間で回す。学んだことをチームで消化‧昇華 インプットは座学中⼼ アウトプットはチーム活動 48
47. 新卒エンジニア研修内容の紹介 新卒がチーム⾃主学習で迷わないように 基礎研修で⽬指すべき状態と⽬指さない状態を明⽰ • ⽬指すべき状態 ◦ ◦ ◦ ⾃分で調べる⼿段を知っている AIなどで情報を検索するためのトリガーとなる情報を知っている ⾃⾝が磨くべき、他者から学ぶべきことを知っている • ⽬指さない状態 ◦ ◦ ⽤語の完全理解‧知識の⾎⾁化 ⼿を動かすスキルの習得 49
48. 新卒エンジニア研修内容の紹介 Phase1：10⽇間 / 開発基礎 インプット + チーム活動練習 ‧スクラム研修 ‧AI 研修 ‧クラウド研修（AWS Jump Start） ‧Git 研修 ‧アジャイル研修 ‧ClaudeCode研修 ‧DDD研修 ‧ソフトウェア設計研修 ‧マインドセット（具体‧抽象） ‧QA‧ソフトウェアテスト研修 ‧データベース研修 DB基礎 ‧リレーショナルモデリング研修 ‧コンテナ研修 ‧WEB フロントエンド研修 ‧kubernetes研修 ‧observability研修 Phase2：25⽇間 / 開発実践 ログラスの⼀部機能 + α の開発 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 ＋ 各⽇ チームでの ⼩スプリント チームでの仮説設定 研修に対する アウトプット Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 50
49. 新卒エンジニア研修内容の紹介 仮想課題の提⽰ 仮想顧客 要望 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 経営企画 部⻑ 鯨 太郎 さん チームでの仮説設定 仮想アカウント マネージャー A社 顧客要望 の⽂書 Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 実証実験の 企画提案 契約中 新卒チームA 新卒チームB ログラス 51
50. 新卒エンジニア研修内容の紹介 課題ヒアリングの実施 弊社社員が演じる 仮想顧客 ヒアリング 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 新卒チームA 経営企画 部⻑ 鯨 太郎 さん チームでの仮説設定 A社 Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 契約中 新卒チームB ログラス 52
51. 新卒エンジニア研修内容の紹介 チームごとに課題特定‧MVP設計 顧客課題特定 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 MVP設計 新卒チームA 顧客課題特定 チームでの仮説設定 MVP設計 新卒チームB リーン キャンバス ユーザー ストーリー マッピング Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 ※ここで合わせて インセプションデッキ‧ワーキングアグリーメントも作成 53
52. 新卒エンジニア研修内容の紹介 MVP開発 1週間x4サイクル 開発 仮想課題の提⽰： 仮想顧客からの実証実験（PoC）の提案 レビューで 社員が演じる 新卒チームA 仮想顧客 チームでの仮説設定 Minimum Viable Product開発 顧客価値を提供できる最⼩限開発 レビューで 社員が演じる 新卒チームB 仮想顧客 54
53. 新卒エンジニア研修内容の紹介 研修設計の肝：⾃分⾃⾝の能⼒や当たり前に気づき、 「批判的思考を磨く学び」を実現するための3段構えの体制を構築 デイリースクラム/ プランニングだけ 参加する チームサポーター スプリントを通して 新卒同⼠で 気づいてないことに 気づきを与える プロセス チームが気づいてない 観点への気づきを与え るプロセス 計画 ふりかえり プロとしての 「判断基準」「技術視点」を 教える社内技術エキスパート 実⾏/議論 レビュー 社内のエンジニアの知⾒を 得て知識に磨きをかける プロセス 55
54. 「AIを使わせない」のではなく 「プロジェクト全体を最⼤限難しくする 56
55. 「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」 AI活⽤は禁⽌しない。だからこそ、プロジェクトを最⼤限難しくする • AIが当たり前の世の中への変化する中で「技術を学ぶことが必要だ」と 「⾃⼒コーディング」を強要することもできる • AIを活⽤するという、「配属後に必要な⼒」を封じることはナンセンス • だからこそ、プロジェクトは最⼤限難しさを追求 57
56. 「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」 AI活⽤は禁⽌しない。だからこそ、プロジェクトを最⼤限難しくする • AIが当たり前の世の中への変化する中で「技術を学ぶことが必要だ」と 「⾃⼒コーディング」を強要することもできる • AIを活⽤するという、「配属後に必要な⼒」を封じることはナンセンス • だからこそ、プロジェクトは最⼤限難しさを追求 研修設計中に最も意識したことは「迷ったら難しい⽅を選択」 難しい かんたん 58
57. 「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」 あえて関わる⼈を多くする、 しかし、⾃ら上⼿に頼らないと扱いにくい設計にする 59
58. 「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」 実際に意識して設けていた罠の例： 顧客からの情報をアカウントマネージャーが整理した「難解な⽂書」 直接的な要望ではない内容 実際に解きたい課題を曖昧に 直接的な要件で提⽰ Slackより 60
59. ~「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」~ 実際に意識して設けていた罠の例： GitHubやAWS環境を整備しておかない Slackより 61
60. ~「AIを使わせない」のではなく「プロジェクト全体を最⼤限難しくする」~ 実際に意識して設けていた罠の例： 「技術学習を主⽬的」‧「MVPを探索してください」のトレードオフを要求 Notionより（Sprint1修了後に種明かし） 62
61. 研修中に起こったこと 64
62. 研修中に起こったこと ２つのチームは全く別の雰囲気で進んでいた 衝突チーム：早い段階で緊張が表に出ているチーム 配慮チーム：穏やかそうなチーム あまり気にしてない⼈ ２⼈を⾒て慌てる⼈ 話通じなくてイライラする⼈ 淡々と仕事する⼈ 65
63. 研修中に起こったこと 〜事例1：早い段階で対⽴が起きたチーム〜 66
64. 〜事例1：早い段階で対⽴が起きたチーム〜 Phase1修了後、開発実践研修の前の早い段階で、チーム内の緊張が表⾯化した 〜当時運営から⾒えている景⾊〜 • ⼀⾒進んでいるが、合意されたリードではない ◦ 推進役が先に進めているだけで、プロセスとしてチーム合意に⾒えなかった • アウトプットのための⾏動になっていた ◦ 他メンバーが置き去りで、チーム学習には⾒えなかった • 苛⽴ちは⾒えるが、健全な衝突にはなっていない ◦ ⼼にあるものを出せず抱えている⸺創造的な衝突ではないように⾒えた 67
65. 〜事例1：早い段階で対⽴が起きたチーム〜 関係性の課題そのものには介⼊せず、成⻑期待を率直に返した • 運営として待ったこと ◦ チーム内の不和には気づきながらもじっと我慢、 直接介⼊せず、⾃⼰解決に委ねた あまり気にしてない⼈ ２⼈を⾒て慌てる⼈ • イライラメンバー‧慌てメンバーから相談 ◦ ◦ ◦ • 話を聞かない‧遮る ⼈として合わないから限界 なぜこのチーム編成なのか、という前提に対する疑問 運営が伝えたこと ◦ ◦ ◦ 合わない⼈とやり切る能⼒こそ、本配属以降で必要になる 変えるのは相⼿ではなく、⾃分の振る舞い 研修という有限の期間だからこそ、 殴り合いでなければ、⾔い合ってよい 話通じなくてイライラする⼈ 淡々と仕事する⼈ 68
66. 〜事例1：早い段階で対⽴が起きたチーム〜 チームの変容のためにワーキングアグリーメントを作成 合意形成やコミュニケーションを⾃らの⼿で変えていった 実際のワーキングアグリーメントから抜粋 69
67. 研修中に起こったこと 〜事例２：⽐較的良好な関係に⾒えたチーム〜 70
68. 〜事例２：⽐較的良好な関係に⾒えたチーム〜 仲は良い。なのに、議論が終わらない 2スプリント経ったが‧‧‧ほとんど顧客の価値は無い状態 • スタンスを取れていない ◦ • 議論が収束せず、元の論点すら消える ◦ • 抽象→具体のあと別の具体へ⾶び、議論⾃体が⾏⽅不明 顧客価値‧バックログの前提から直す必要がある ◦ • 配慮はできるが、⾃分の思いを強く出せない 2スプリント後も顧客価値になるものがほぼ無い 認識を揃えずに進もうとしたり、納得してなくてもとりあえず合わせる ◦ 「作りたい∕Fail Fast」と⾔いつつ認識を揃えずに進もうとしているように⾒えた 71
69. 〜事例２：⽐較的良好な関係に⾒えたチーム〜 関係性の課題そのものには介⼊せず、成⻑期待を直接的に伝えた • 運営として待ったこと ◦ • チーム全体の場で伝えたこと ◦ ◦ ◦ • 約2週間の停滞‧議論の紛糾は⾒守った 議論を放棄することと、Disagreeのまま進むことの違い ⾃分の意⾒を⽰さなければ、その場にいないことと同じ 無駄な意⾒なんて無く、正解はない、だから遠慮せずに出すことが⼤事 価値のあるプロダクトバックログの作り⽅を改めて伝える 個別1on1で伝えたこと（⾊々な⼈にそれぞれ ◦ ◦ ◦ 役割が無い中でのリーダーシップこそ本物のリーダーシップ 他者が議論についてこれないのは、⼈の思考プロセスが違うから 話している議論が異なる⽅向に⾏くなら、⾃分が戻せばよい 72
70. 〜事例２：⽐較的良好な関係に⾒えたチーム〜 3スプリント⽬で顧客レビューで⾒せるものに劇的な変化 議論の停滞に時間を割く状態から、顧客価値に向き合う時間が増えた • 議論の⽬的が明確になり、意思決定のスピードが⾒違えるほどに変化 • ⾃席で作業をしながら必要なタイミングでチーム相談するようになった ◦ ――以前は、スプリントイベント以外の時間もほとんど集まって議論をしていた • スプリントレビューでは「動くソフトウェア」を⾒せられるようになった 73
71. 〜事例２：⽐較的良好な関係に⾒えたチーム〜 結果として、顧客価値やFail Fast、Disagree and Commitの精神など―― 開発者として⼤切なマインドセットを学ぶ経験となった チームの最終成果報告会から抜粋 74
72. 個々の新卒メンバーが発表した 「学び」の紹介 75
73. 個々の新卒メンバーが発表した「学び」の紹介 頭の中に抱え込んでいるだけだから、衝突やズレが起きる • 研修初期 ◦ ◦ • 学⽣の頃の学びの分野が違う経験から、 他メンバーとの視点の違いを感じていた ⾃分の思考の整理 & 解決策が思いついてから、 考えていることや思っていることを 話すようにしていた 研修中 ◦ ◦ ⾃分の違和感を頭の中に抱えているから 衝突が起こるという気づきを得た ⾃分の考えを場に出すという経験を 積み上げた 個⼈報告資料から抜粋 76
74. 個々の新卒メンバーが発表した「学び」の紹介 完璧主義からの脱却、議論に必要な材料を⾃分から提供することの⼤切さを学ぶ • 研修初期 ◦ ◦ • 完璧主義で⾃分の意⾒がまとまらないと 意⾒を共有できない 議論の場では「確かに‧‧‧」と 流れに乗りがち 研修中 ◦ ファシリテータを買って出ることで 議論中にスタンスを取る練習をした 個⼈報告資料から抜粋 77
75. 個々の新卒メンバーが発表した「学び」の紹介 他メンバーのリーダーシップに圧倒されながら、⾃らのリーダーシップを⾒出した • 研修初期 ◦ ◦ • ⾃分がチームの役に⽴てていないと 感じて焦っている状態 貢献感を感じることができず リーダーシップについて思い悩む 研修中 ◦ ⽬⽴つ仕事ではなくても チームへの貢献があることへの気づき 個⼈報告資料から抜粋 78
76. 個々の新卒メンバーが発表した「学び」の紹介 8⼈が語ったのは、技術だけではなく「⼈との協働」の中で 「⼈との摩擦が、どのように⾃分を変えたか」だった • およそ2ヶ⽉間、研修をやり切った研修の成果報告会 • 本⼈たちが語ったのは、⾝についた技術だけではなく ◦ ◦ チームでうまくいかなかった経験と、そこから掴んだ学び 「⾔えなかった」「決められなかった」「疑えなかった」⸺そのきっかけになった出来事 79
77. 個々の新卒メンバーが発表した「学び」の紹介 8⼈が語ったのは、技術だけではなく「⼈との協働」の中で 「⼈との摩擦が、どのように⾃分を変えたか」だった • およそ2ヶ⽉間、研修をやり切った研修の成果報告会 • 本⼈たちが語ったのは、⾝についた技術だけではなく ◦ ◦ チームでうまくいかなかった経験と、そこから掴んだ学び 「⾔えなかった」「決められなかった」「疑えなかった」⸺そのきっかけになった出来事 配属してからより研修の⽅が⾟かった 80
78. AI時代に「⼈との協働」に 価値をもたらす運営のマインド ~チームを⽀援する運営の関わり⽅~ 82
79. チームを⽀援する運営の関わり⽅ AI時代だからこそ「⾃ら⼈を頼る判断」も磨いて欲しい だからこそ、運営は「育成する役割として気になる」を堪える • 要するに必要なタイミングを⾒定めて関わるコーチ/スクラムマスター的な関わり⽅ ◦ システムコーチング®やワークショップを実施することで新卒全体に対する働きかけで 「本気」にさせる ◦ 開発の進め⽅を教える⼈として関わり、 プロダクトバックログの作成⽅法、スプリントバックログへのタスク分割⽅法などを教える ◦ 各チームの状況を遠⽬から俯瞰、ある程度はチームに任せつつ、 介⼊が必要な場合を⾒極めて介⼊する ◦ 各⼈を観測し、必要なタイミングで1on1で個⼈へ働きかけ 83
80. チームを⽀援する運営の関わり⽅ 待つことは放置ではない―― その時間は、トラブルが「本⼈の⾔葉」になり、当事者に変わるまでの時間である • 限られた時間の中で「進まない状態」「対⽴やいらだち」に焦らない • 意図的に待つことが結果的に成⻑につながる • 待って待って、限界を迎えた時の対話こそが彼らの成⻑機会となる 起こっている事実を 観察する 本⼈が乗り越える 準備を検知する 成⻑期待を伝える 変化した/しないを 気にせず観察する 84
81. チームを⽀援する運営の関わり⽅ 待つことは放置ではない―― その時間は、トラブルが「本⼈の⾔葉」になり、当事者に変わるまでの時間である • 限られた時間の中で「進まない状態」「対⽴やいらだち」に焦らない • 意図的に待つことが結果的に成⻑につながる • 待って待って、限界を迎えた時の対話こそが彼らの成⻑機会となる 起こっている事実を 観察する 本⼈が乗り越える 準備を検知する 変化が起きているだけであり、 その事実を運営は評価判断しない 成⻑期待を伝える 変化した/しないを 気にせず観察する 変化途中かも知れない、 評価判断しない ※マネージャーやスクラムマスターも⼀緒ですね 85
82. チームを⽀援する運営の関わり⽅ 議論紛糾は歓迎するが、放棄は歓迎しない―― 本物の「Disagree and Commitした納得解」は議論の先にしかない • ⾔葉が無いことには始まらない。「⼼の中にあることを表現する」「スタンスを取る」ことを促す • 基本的に仕事は「完全合意」であるわけではないことを伝える ◦ • ワークショップを実施してこの難しさを体感してもらった（本⽇割愛） それぞれの考えが表現され、議論されるようになって初めて 「Disagree and Commitした納得解」を⾒つけることが難しいことに気づける 表現できない 表現させる 議論紛糾 Disagree and Commitの納得解 議論を放棄 86
83. チームを⽀援する運営の関わり⽅ 議論紛糾は歓迎するが、放棄は歓迎しない―― 本物の「Disagree and Commitした納得解」は議論の先にしかない • ⾔葉が無いことには始まらない。「⼼の中にあることを表現する」「スタンスを取る」ことを促す • 基本的に仕事は「完全合意」であるわけではないことを伝える ◦ • ワークショップを実施してこの難しさを体感してもらった（本⽇割愛） それぞれの考えが表現され、議論されるようになって初めて 「Disagree and Commitした納得解」を⾒つけることが難しいことに気づける 表現できない 表現させる 議論紛糾 Disagree and Commitの納得解 議論を放棄 放棄している状態のときこそ 「成⻑のチャンス」 87
84. 新卒研修を終えた今、AI時代に思うこと 88
85. 新卒研修を終えた今、AI時代に思うこと チームの学び、個⼈の学び―― 彼らが学んだ全ては「AIとの協働」ではなく「⼈との協働」からだった • 成果報告会で「AIからxxを学びました」という⾔葉は1つとしてなかった • ⼈との摩擦が⽣じる時に成⻑の芽が⽣まれた • AIは仕事を代替するものであり、成⻑を⽀援するものではない、と感じた （※個⼈の感想） 89
86. 新卒研修を終えた今、AI時代に思うこと ⾃分の思考‧⾃分の当たり前の輪郭は、 異なる当たり前を持つ他者との摩擦の中で明確になる 「こう思っているんだな」 「こういう前提で考えているんだな」 という⾃分の思考がはっきりする 他者 ⾃分の思考 ‧ ⾃分の 当たり前 他者 ⾃分 他者 ⾃分の思考 ‧ ⾃分の 当たり前 90
87. 新卒研修を終えた今、AI時代に思うこと ⾃分の思考‧⾃分の当たり前の輪郭は、 異なる当たり前を持つ他者との摩擦の中で明確になる 「こう思っているんだな」 「こういう前提で考えているんだな」 という⾃分の思考がはっきりする 他者 ⾃分の思考 ‧ ⾃分の 当たり前 他者 ⾃分 他者 ⾃分の思考 ‧ ⾃分の 当たり前 ⾃分⾃⾝をアンラーンするプロセス 91
88. 新卒研修を終えた今、AI時代に思うこと ⾃分の思考‧⾃分の当たり前の輪郭を疑える状態になる―― 「⼈との協働」が批判的思考を育てる理由ではなかろうか 「こう思っているんだな」 「こういう前提で考えているんだな」を 批判的に捉える ⾃分の思考 ‧ ⾃分の 当たり前 92
89. 新卒研修を終えた今、AI時代に思うこと チーム少数化が進むAI時代における、研修での協働学習の重要性 • 他者との関係が希薄になるAI時代だからこそ、 研修として意図的に協働学習を含めることに意義がある • 研修で学んだ新卒メンバーが ⾃らの研鑽のために「⼈との協働」を活⽤できるようになる • 学んだ彼らが「⼈との協働」の価値を次の世代へつないでくれる 93
90. おわりに 94
91. 謝辞的なやつ 研修は参加者の真摯に向き合う⼼が無ければ成り⽴たないものです。 研修に向き合ってくれた新卒エンジニアの皆様に感謝を申し上げます。 未来を担う⼤切な新卒の2ヶ⽉間という⼤切な時間を私に任せ、 ⼤きなチャレンジに向かわせてくれた株式会社ログラスにも感謝を申し上げます そして最後に、PBLという素晴らしい学びを、⻑きにわたりソフトウェア業界に伝え、 実践し、育て続けてこられた皆様に、⼼より敬意を表します。 95
93. 採⽤情報 ロ グ ラ ス で は 新 卒 採 ⽤ を ⾏ っ て お り ま す。 新卒採⽤サイト https://loglass.co.jp/recruit/newgraduate-all 97
94. 採⽤情報 98
95. 使⽤しない資料 99