enPiTに1年間参加してました
どうもみなさんこんにちは。寝る時の姿勢と環境は想像以上に大事、えふじです。
タイトルにもある通り、去年（2022年）の4月から今まで、約1年ほど「enPiT」なるプログラムに参加していました。大学の必修科目の1つとして受講し、最終レポートをブログでまとめてねとのことだったのでここにまとめております。「そもそもenPiTって何だよ」「1年間も何やってたんだよ」といった疑問に答えつつ、1年間受講生として参加していたenPiTを振り返っていきます。
つまり、今回趣味の話は一切出てこないということです。
そもそもenPiTって？
education network for Practical Information Technologies の略*1で、ざっくり言うと「実践的なIT教育」らしいです。「社会で通用するイノベーション人材を育成しよう！」って触れ込みで文科省予算で日本各地の大学が実施してるっぽいです。
enPiTの中にも4分野あり、私はそのうちの1つ「BizSysD（ビジネスシステムデザイン分野）」に参加してました。所謂PBL（Project Based Learning）形式の授業で、「身近な困りごとを解決するプロダクトをチームで開発する」といった内容でございます。
ちなみに学部生向けである以上私もBizSysD連携校のどこかにいることになりますが、あえてここでは伏せておきます。*2
何を作ったの？
「青い栞」というWebアプリケーションをチームで作ってました。プロダクトとしては未完成です。
URL（PC推奨）：https://aoi-shiori.netlify.app/
GitHub：https://github.com/enpitut2022/aoi-shiori
何これ？
青い栞のエレベーターピッチ（プロダクトの超ざっくりとした説明）を掲載します。
[青い栞] は
[旅行計画をイチから考えるのがめんどくさい]を解決したい
[旅行に行きたいがツアーで縛られたくない、でも自分であちこち調べるのは嫌だというわがままさん]向けの
[旅の栞提案アプリ] です。
これは [旅の骨組みを提案しそれをカスタマイズすること] によって、
[旅行会社のツアーや比較サイト、Visit A City] とは違って
[イチから計画を考える負担を減らしつつ、自由度の高い旅行計画の作成]
を実現できます。
旅行に行きたいけど計画立てるのにあちこち調べるのは面倒、ツアーのプランを見てもなんかぱっとしない。そんなこと、あると思います。自分で計画立てられる方や計画なんざいらねぇって方はそのまま旅行してください。計画立てられない（面倒くさい）方向けのプロダクトです。
何がすごい？
旅行会社のツアーや個人サイトのサンプルプランのように旅行計画を「提案」してくれる、それを踏まえて行きたくない場所を除外したり代わりの場所を追加したりと「カスタマイズ」できる。この「提案 × カスタマイズ」を1サイトで完結させ、旅行計画のたたき台を作れる点が青い栞の強みです。*3
どうやって使うの？
※現在は京都市にしか対応していません。京都旅行の体で説明します。
まずアクセスすると以下のような画面になると思います。
画面左上の列が現在のプラン（横スクロール可）、左下の列がスポットの追加候補（横スクロール可）、画面右側が現在のプラン内のスポットの場所となっています。
画面を拡大して動いている様子をば。カードをドラッグ&ドロップで場所の入れ替え、追加、削除が行えます。また、現在のプランにあるスポットは画面右側の地図上にも表示されます。現在のプランのスポット間には、距離と徒歩移動時間が表示されます。
余談ですが、先日青い栞のみを使って計画を立て、実際に京都へ1人旅に行ってきました。なかなか有意義な時間を過ごせました。
どんなチームだったの？
私のいたチーム「判断が遅い！ズ（仮）」*4は、1年間のうち前半5人、その後2人out・1人inで4人のメンバーがいました。授業全体としてアジャイル開発、とりわけスクラムを導入した開発を行う方針だったため、判断が遅い！ズ（仮）もスクラムを導入してアジャイル開発*5をしていました。
最終的なメンバーと役回りは以下のような感じです。
- えびちゃん（開発者）
- えふじ（ScM）
- ぬたひろば（開発者）
- 発言量こそ他メンバーと比べて少ないものの、きわめて正確に的を得た意見を刺す猛者。えびちゃんとものけがアイデアを出し議論しつつ、私が適宜内容をまとめ上げ、ぬたひろばのクリティカルな発言で方向性が定まることもしばしば。終盤は積極的に発表役も引き受けてくれました。
- ものけ（PO）
- 開発力の塊にして、困りごとへの解像度がものすごく高いPO。メンバー内で最も開発経験があり、環境整備はじめ多大なお世話になりました。POとして積極的にアイデアを出したり、最終的な意思決定をしたり、チームの文化を作り上げたり。総じて多才。
なお、一応POとかScMとか書いていますが、プログラミングには全員関わってます。あくまで開発者兼PO・開発者兼ScMといった具合です。
タイムラインで1年間を振り返る
スクラムでは「スプリント」と呼ばれる単位で開発を行っていきます。そこで、スプリントベースで1年間を振り返っていきます。
前半（基礎知識学習 ~ 夏合宿）
1年間の前半は、その大半を基礎知識学習（夏合宿以降で開発に必要な技術要素の自習）に費やしました。といっても私は授業でプログラミングをした程度の経験しかなかったため何をやったらいいか分からず、たまたまその時期勉強していたUE（Unreal Engine）の勉強をやってました*6。
そして迎えた夏合宿*7。5日間（プロダクトの開発は4日間）にわたり開発を行いました。メンバーは5人で、作ったプロダクトも今とは違うもの（メシレコ）*8でした。
チーム開発経験がゼロな中手探りで始まった開発。1日でできるタスク量の見積もり等に苦戦はしたものの、大きなアクシデントやトラブルはなくプロダクトを形にできました。メシレコで提供したい価値は全て実現できたため、大成功といっていいでしょう。
ここからの学びとして「共通認識の領域は大きければ大きいほど開発がスムーズに行える」というものがあります。困りごとへの解像度やプロダクトの方向性等、開発に関わる部分の認識がメンバー間で揃っていたことや、作業中こまめに情報共有を行っていたからこそ、分業してもメンバー全員が同じ方向を向いて（同じ場所に向かって）作業できたのではないかと考えています。
後半・スプリント1 ~ 4（/15）
メンバーの変更を経て後半戦が始まりました。メシレコがある種完成状態であったこともあり、困りごとを考え直して新しいプロダクトを作ることに決定。プロダクトの方向性を1日で定めて*9、メシレコの資産を最大限活用しつつ開発開始。滑り出しそのものは順調でした。
後半・スプリント5 ~ 8 (/15)
スプリント4後のレビューを受けて、チームの中でどのような機能が欲しいか、より正確にはどのような価値を実現したいかが曖昧であることに気づきます。チーム内で原因を探った結果、そもそも掲げていた困りごとにメンバーのほとんどが共感できていなかったことが判明しました。共感できていないか、あるいは共感できるけどそこまで深刻に困ってないといった状態で方向性も曖昧なまま開発を続けるのは危険だというチーム内判断により、一旦開発を中断。2スプリントほど時間を使って困りごとを根本から見直し、プロダクトを新しく作ることになりました。この大幅なピボットを経て、ようやく青い栞の開発が始まります。
なぜ大幅に方向性を変えることになったのか。ここで夏合宿の学びが効いてきます。ずばり理由は「共通認識領域が少なかったから」。夏合宿の場合は方向性の決定に1か月ほど*10時間をかけることができましたが、後半で方向性の決定にかけられた時間はわずか3時間程度*11。困りごとやプロダクトの共通認識、つまりチーム開発をする上での土台となる部分が脆弱であったがゆえに開発計画が崩壊したと言えます。過去4スプリント分の蓄積と2スプリント分の話し合いで土台を盤石にした上で開発に着手する。この期間は判断が遅い！ズ（仮）にとっての挫折、そして再起動のタイミングだったなと、今振り返って感じています。
後半・スプリント9 ~ 12 (/15)
そんな経緯でついに始まった青い栞の開発。既に後半の開発期間も折り返したタイミング、他チームと比べてプロダクトの開発状況が遅れていることや、過去にサンプルコードをコピーして書いた、ロジックが分かっていない箇所でのバグ（通称「動く負債」）の解消に奔走し、毎スプリント進捗を生むのに必死でした。
見通しが立たない状況の中でタスク分けが洗練されていき、さらにチーム内でenPiTの本質に触れるような名言が次々と生まれたこともありました。総じてこの期間でメンバー全員のチームオペレーション能力やアジャイル開発への理解がかなり深まったと思っています。
後半・スプリント13 ~ 15 (/15)
ようやく判断が遅い！ズ（仮）がスクラムチームらしく動けるようになってきました。共通認識を盤石に整えたおかげで洗練された分業を行えたり、レビューでもらった意見のうちプロダクトに反映させるものを選定したり。動く負債の解消もできて、今の青い栞の形に辿り着きました。紆余曲折経てチームが落ち着く場所に着地した、といった感想です。
1年間を通して学んだこと
だいたい3つほどあります。えふじセレクションです。
対象ユーザーは誰なのか
万人に刺さるプロダクトは難しいって話です。開発途中のプロダクトを先生やメンター、他受講生に触ってもらう機会が結構あります。そう言った様々なユーザから意見をもらえること自体は嬉しいのですが、当然意見の内容はバラバラです。そもそも困りごとに共感してない人、困りごとに共感はしてるけど解決法に納得してない人、解決法にも納得してるんだけど使う状況がこっちの想定と違う人……。まぁいろいろです。そういった多種多様な意見を全て受け入れるのではなく、「お前はこっちが想定してるユーザじゃない」と意見を切り捨てる勇気が大事だという学びです。他受講生はともかく先生やメンターの意見を切り捨てるのにはかなりの勇気が必要ですが、プロダクトが迷走するよりはよっぽどマシです。
心理的安全性の早期確保
発言が活発でないと話が進まないよねって話です。開発にしろチームビルディングにしろ、意見の交換が起こらないと何も始まりません。作業に関する話から雑談まで、とにかく何でも言い合えるような雰囲気が大事だという学びです*12。これは「緊張が原因で本来のパフォーマンスが発揮できないなんてもったいない」という私個人の考えでもあります。ScM関係なく開発早期からなんでも言い合えるような雰囲気づくりに尽力しましたし、それが功を奏したとも思ってます。
余談ですが、個人的に「心理的安全性」って言葉が嫌いです。あまりにもふわふわしてて実体がない。言葉の持つイメージが強すぎて具体的な内容が伴ってない気がするんです。パワーワードってやつです。心理的安全性はあくまで結果であって、それが先にくるような言葉じゃないと思ってます。お気持ち表明です。
共通認識領域の最大化
もう何度も触れましたね。土台は盤石にしておきましょうって話です。意見を切り捨てるためには、チーム内でプロダクトに対する明確なビジョンが必要です。そのためにもチームメンバー全員の、困りごとやプロダクトへの理解水準は一定に保っておくべきだなという学びです。意見交流を活発にして、共通認識による土台を盤石に固めて、その上で開発するなり発表するなり意見をぶった斬るなりする。たぶんこの順番なんじゃないかって思ってます。
あとがき
ここまで長々と書いてしまいました。最後まで見てくださった貴方、本当にお疲れ様です。正直チーム独自の取り組みについても触れようかと思いましたが、挙げてるとキリがないのでやめました*13。
PBLだの、アジャイルだの、スクラムだの、横文字がいっぱい出てきて困惑されている方もいるかと思います。大丈夫。私もそうでした。先に述べましたが、私の開発経験は授業でやっただけです。もちろん中には趣味でバリバリモノ作ってる人やハッカソン出まくってる人とかもいます。ですが私みたいに開発経験皆無で「でぷろいってなぁに？」って状態の人でも1年間やっていけます。
これを読んでいる中に、もしかしたら来年度（2023年度）enPiTを受講しようか悩んでいる方がいるかもしれません。開発経験皆無のコミュ障な私でも1年間走り切れました。あなたなら大丈夫。メンターとして*14、あなたの受講を待ってます。
以上。2022年度 enPiT 琉球大学・筑波大学 PBL 成果発表会最優秀賞「判断が遅い！ズ（仮）」スクラムマスター、えふじでした。
*1:なんで略すと I が小文字になるんでしょうか。ちなみにテキスト表記はenPiT、ロゴはenpitとなぜか揺れてます。
*2:割とすぐわかるんじゃないでしょうか。IMAGINE THE FUTURE.
*3:未完成だけど
*4:（仮）まで含めて正式名称です
*6:そして夏合宿以降UEは全く使わないという
*7:合宿と言ってますが泊りではありません。1 ~ 6限ぶっ通しの集中授業です。
*8:スマホ推奨。位置情報を基に付近の飲食店を1つずつ提案します。カードを上にスワイプして別の飲食店に切り替えられます。
*9:夏合宿の場合は事前に1か月ほど決める時間がありました。この差が後に効いてきます。
*10:正確には授業の関係で10コマちょっと
*11:授業2コマ分
*12:相手を不快にさせるような発言はご法度ですよ？
*13:この独自の取り組みが結構高評価をもらっている。
*14:あくまで予定
