経験依存から脱却しよう！～経験の少ないメンターが教える側として向き合うために～

AgilePBL祭り2025 筑波大学 ギルド 経験依存から脱却しよう！ ～経験の少ないメンターが教える側として向き合うために～

自己紹介 1 [紹介] • enPiTに何故か3年くらいいる人です • スクラム何もわかってないので専門用語は少なめです [経歴] • 2022: 豊田高専 卒業 • 2022: 筑波大学 編入 • 2024: 筑波大学大学院 編入 筑波大学 大学院 ギルド（ :@Gild_prog） [経歴(enPiT)] • enPiT2022 受講生 • 優秀賞 • BizSysD Workshop プレゼン賞 • enPiT2023, 2024メンター • 多分２０２５もメンター

どんな発表？ • 筑波大学enPiTでは修了者がメンターになって受講生をサポートします しかし、(特になりたての)メンターはつい口を出しすぎてしまいます。 • こういうのはやったほうが/やらないほうがいいよね！ • やるかどうかはともかく、こういうことを意識しておきたいよね！ ということを議論出来たらと思っています 2

メンターになったA君 4 enPiT一年修了できた！ メンバーはもちろんメンターさんのおかげで 何とかプロダクトが作れた！ 今度は自分がメンターになって受講生をサポートするぞ！

授業では親切にサポートしてあげたいよね！ 5 あ、まってまって、それじゃだめだよ スクラムとうはこうでああで、 価値を提供できないと意味がないから・・・ 僕たちがうまくったから君たちもやってみて！！ ここまでで １５分経過

受講生側を見てみよう プロダクトの価値になる機能を先に作れって言われたけど、 それを実現するために必要な機能があるんだけど。。。 ハードコーディング？あとから置き換えるコストの方が 僕らのチームだと高いんだけど メンターの話が長すぎて開発の時間が消えたんだけど！ １５分あればこの機能実装できたのに・・・ 6

7 じゃあどうすればいいの？ 7

ご法度 9 • 経験を一方的に押し付けるのはアンチパターンです • このセッションでは経験の押し付けを「経験依存」と呼ぶことにします 俺たちのチームはこれでうまくいったんだ！！ みんなもこうするべき！！

アドバイスするチームを理解する あなたがアドバイスするチームはどんなチームですか？ プロダクトはもちろん、 • 誰が何が得意で • どんな技術を使っていて • どんなことで悩んでいるか / この先悩みそうか 10

自分たちとの共通点を考える • あ、技術が一緒だ！ 技術のサポートは出来るかも！ • プロダクトが似ている レビューでこの辺指摘してみようかな • あの子と自分は考え方が似ているなぁ 何か愚痴ないか聞いてみようかな 11

自分が経験不足と自覚する • 誰が何が得意で • どんな技術を使っていて • どんなことで悩んでいるか / この先悩みそうか 単純に考えればチーム開発経験が多いほど 共通点は見つかるはず。。。 でも自分のチーム経験はenPiTくらい。。。 12

自分たちとの違いを考える ＜(過去の)自分たちのチーム＞ 全員開発経験少ないから全 員で協力しながら開発した！ 13 ＜自分が見ているチーム＞ 開発ﾂﾖﾂﾖがいるから その人が中心！ ついつい。。。 属人化してない？その人だけが開発してる間 他の人は何をしてるの？ とか言いたくなる

そのチームにとって課題の可能性もあるし、そうじゃないかも。。。 開発ﾂﾖﾂﾖがいるからその人が中心！ • その人が頻繁に欠席するとかじゃなければ課題にならないかも • 授業なので突然異動！とかも基本はない • いないときもChatGPTに頼ればなんとかなる機能開発とかもある • コーディングだけなら特に 課題になりえるパターン 「実はチームでその方針が合意が取れていなかった」 開発経験積みたいからenPiTに来たのにあの人に任せきり。。。 14

逆にメンターが口を出すべきところ これ （他にもあるが後程） 課題になりえるパターン 「実はチームでその方針が合意が取れていなかった」 開発経験積みたいからenPiTに来たのにあの人に任せきり。。。 15

口を出すよりも。。。 16 • チームメンバーじゃないメンターがこれに気づくには • 「観察する」 • メンターが口を出しすぎて本当に思っていることを伝えないということも割とあった • 「話を聞く」 するしか基本はない 課題になりえるパターン 「実はチームでその方針が合意が取れていなかった」 開発経験積みたいからenPiTに来たのにあの人に任せきり。。。

17 見守る勇気を持つ

経験主義の基本に立ち返る 18 それを続ける、 続けるための方法を考える 自分たちなり に進める 検証する 改善するための方法を 考えてトライする

失敗を見ることを恐れない • 自分のチームを振り返る（赤が改善したいこと） • 自分たちも色々失敗して改善してきたはず 19

あれ、これって経験する過程を邪魔してるんじゃ。。。 20 (再掲)悪い言い方をすればこんな考え方もできる そのチームならあなたが失敗した方法でも成功していた かもしれない 失敗したとしても失敗する原因が違い、改善するプロセスも 違っていたかもしれない 受講生が経験する ための時間を 奪っていたかもしれ ない

そもそもenPiTって失敗していい場では？ • 授業一回の時間が短い(開発時間は１００分)ので、受講生だけじゃなくメンターも 「失敗したら時間がない、まずい！」となる気持ちはある・・・ • ただ、納期が遅れたらまずい！みたいな環境でもありません • 開発時間の方がプロセスを考える時間の方が短い(人が多い) • とりあえずこれに気づく関係作りをしたい 課題になりえるパターン 「実はチームでその方針が合意が取れていなかった」 開発経験積みたいからenPiTに来たのにあの人に任せきり。。。 21

逆にメンターが口を出すべきタイミングは？ • チームが八方塞がりだと感じたとき • 要はやったことがうまくいかなかったが、改善する方法がうまく見つけられていないとき • 失敗しないようにサポートするのではなく、失敗した後の立ち直りがスムーズになるようにサ ポートする • あくまで自分が語るのではなく話してもらうことに気を付ける • アドバイスを求められたとき • もちろん自分が頼られたときはOK • 非本質的なことで躓いているとき • 技術面とかmiroが重いときのサポート…etc • 透明性が皆無な時 • 状況が分からないチームにアドバイスをすることは不可能なので。。。 • カンバン管理してないとかゴールが分からないとか 22

まとめ：メンターの心構え 23 「自分の経験を押し付けるな！！」 • アドバイスするチームのことを知る • そのチームと自分の過去との違いを認識する • 失敗を見ることを恐れない スライド