Man page of CHIKU_WAIT(2)

システムソフトウェアとポエムの差が激しいので,高山病に注意

学生だってちゃんと開発したい!大学の授業でスクラムを導入しようと思った話

前提

僕が居る公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業ではサービスの開発や心理学研究、楕円曲線暗号アルゴリズムの高速化やアルゴリズムの改良といった様々なテーマで最大15人程度のチームを組んで1年間取り組みます。実社会に根ざした問題群を解決していく方法を探求する取り組みらしいです。また、教員はあくまでもアドバイザーで、どんなことをするのか、何で開発するのか、どう開発していくのか、スケジュールはどうするのかすべて学生が主体となって決めていきます。そのため、チームによってですが、授業の時間以外も時間を費やすことが多く、3年生はプロジェクト学習に全力を注ぐと言っても過言ではないと思います。詳細はこちらを参照。www.fun.ac.jp

僕が所属しているプロジェクトは「ビーコンIoTで函館のまちをハックする – BEACON FUN Reloaded」というテーマでビーコンと呼ばれるBluetoothの電波を発信する小さな機器を用いて世の中にはまだないような新しいサービスで函館のまちをハックすることを目的としています。

前期の話

そしてなんの間違いか5月のプロジェクト学習初回でリーダ決めの際にリーダになってしまいまして、いきなり15人を仕切ることになってしまいました。そもそもリーダーということが大の苦手な僕ですが、なんとか周りに助けてもらいながら計画を立てたり物事を進めていくことができました。具体的に前期の間は5〜7月にかけて4箇所でのフィールドワークやアイデアソンを行い256個のアイデアを出し、開発する4つのサービスを決定して、中間発表会用のサービスポスターを作り、そこまでのプロセスをすべて中間報告書というものにまとめました。これだけみると割と平和そうなんですが、実際は炎上してました(ほんとすみません)。最終的に作るサービスが決まったのが中間発表会の1週間前で、そこから5枚のポスター作成と発表準備で毎日11時近くまで大学にみんなで残った状態になりました。(ほんとごめん)

ところで、後期大丈夫なの…?

さて、前期で勢いで作るサービスを決めたんですが、後期は9月末から1月までです。この中でも12月の第1週に成果発表会、1月に報告書提出というスケジュールになっているので開発期間は9月末から11月末までの2ヶ月です。さあこの短い期間で動くプロダクトを4つ僕たちは作らないといけません。大変!前期で炎上が鎮火し終わったと思ったら、既にもう後期は炎上しているのです。ここで、2ヶ月で動かすための壁となりそうなものをいくつかリストアップしていきましょう。

2ヶ月で動くプロダクトを用意するための頭が痛いリスト

1. 毎日開発できるわけではない

いくらプロジェクト学習に1年間全力で取り組むと行っても、あくまでも授業です。みんなで集まれるのは毎週水曜日と金曜日各2コマずつの合計4コマ、6時間です。なので授業だけの時間でいうと120時間ちょっと。いや短いでしょ。また授業の時間は大抵別の決めないといけないことがあったりするので実質100時間くらいでしょうか?100時間で動かすプロダクト×4という状況なので、望む望まないは別にして絶対に授業外でもガッツリやらないと間に合わないと思います。イヤイヤやるかみんなでワイワイやれるかはチームビルディング次第です。うちのプロジェクトは幸いにも全員がそれなりにやる気をもっていて、前期の段階からかなりみんな頑張ってくれました。報告書ガーポスターガーって言ってる中既にプロダクトを作る奴が居るくらいなので恵まれて居ると思います。まあプロジェクトによっては消息不明になったりというのを聞いていてして大変そうですが…。もちろん授業外でやったところで、2ヶ月という期間が短いことには変わりないです。

2. メンバー全員の開発スキルの差が激しい

情報系大学生といっても、スキルは千差万別。授業以外でもストイックに書き続ける人、授業以外であまり書かない人、コード書くよりデザインが好きな人、iOSが好きな人、サーバサイドが好きな人というように15人全員違います。当たり前。この中で一番考えないといけないのが授業ぐらいでしかコードを書いてこなかった人たちへのフォローが重要になってくるんじゃないかなって思っています。別に授業以外でやらないということを否定しているわけではなく、純粋に何を使ってどのように実装するといったことや、どういう手法を使っていくのかといった所がどうしても普段書いてる人とそうでない人に出てきてしまいがちというところです。

3. メンバー間のプロダクトへの認識の違い(理想像が違う)

これは別に大学に限った話では無いと思いますが、一人一人プロダクトに対する認識はどうしても少しづつ違うものです。 言い出しっぺが思ってプロダクトのビジョン、後から入った人のプロダクトのビジョン、そして先生が想像するもの、客が想像するもの(なんとプロジェクトによっては客・共同でやる企業がついてしまうのです大変)。どこかで認識を合わせていかないときっと作りながら大崩壊を起こしそうです。「俺達が本当に作りたいのはこんなんだっけ…?」となってしまうのは絶対に防がないといけません。

4. チーム開発をほとんどの人が未経験

大学生の殆どはチーム開発の経験がありません。インターネッツを見てるとみんなバリバリ開発してインターン行きまくって圧倒的チーム開発しているように見えますがそんなことはない。7〜8割は経験がないですし、チーム開発の経験がある人でも後述するオレオレチーム開発だったりします。そのため、大抵の人が複数人で開発することの難しさがあまりわからないことが多く、まずはチーム開発とはって話や、チーム開発のために使う技術とか、ツールとか色々皆で学ぶ必要があります。

5. 別の開発演習やどっかで身についた謎の秘伝のオレオレチーム開発

なんか別の演習とかでやっているなんちゃってスクラムやオレオレチーム開発というBadパターンの塊みたいな知見を持っている人も一定数います。正直、経験が無いほうがマシな説がある。あとまだ授業だけなら良いんだけど時々インターンでBadパターン持ち帰ってくる人もいる。「企業〜〜〜〜〜!!!!!!!お前〜〜〜〜〜〜!!!インターンで行き当たりばったり開発を学生にさせるんじゃねええええええええええええ!」と思っている。兎に角、このオレオレ開発手法やなんちゃってスクラムというものは結構厄介で、ちゃんと開発しようにも逆に上手く行かなくなったり生産性下がりそうで怖い。

6. 結局は†強い奴†が全部実装する

これ、学生の複数人の開発で顕著に出てくると思います。というか、毎年プロジェクト学習こういう事が多いという話を聞きます。個人的な気持ちとしては、技量の差はあっても、できるだけ皆に動くものを作って欲しいと思っていて、「誰かが作った」ではなくて「チームで作った」と胸を張って言えるようにしていたい、そう思います。また、誰か強い人が一気に実装していしまうと他の人があまり成長できないのではないか?と思っています。もちろん実装を見るだけでも学べることがあるかもしれませんが、できれば手を動かして、動くものを作って成功体験をみんなで重ねていきたいです。普段から書いてる人も他の人を教えている中で成長してほしいです。できるだけ皆で成長する環境でありたい。

Aさん「わからん…」

ツヨツヨマン「俺が全部直した^^」

Aさん「俺なにしたんだっけ…」

みたいなことは絶対に避けたい。

2ヶ月で最高のプロダクトを開発して、全員が成長できる方法を考える

さて、ここまで頭痛いリスト書いてみてもうね、胃が痛いし頭が重い。だけど真面目に2ヶ月で最高のプロダクトを開発して、全員が成長するにはオレオレ開発や大学生複数人開発にありがちなノーマネジメントをやめてちゃんとした方法を考える必要がありそうですね。 二ヶ月という期間でプロダクトを作っていくには、継続的に動くものを出し続けていく、何が必要不可欠で何が本質ではなくて後回しできるものなのか…などを明確にする必要があるかなと個人的に考えています。また、この短い期間でプロダクトを完成させるには、大きな失敗は死に直結します。ウォーターフォール的なことをして大きな後戻りが発生したら2ヶ月だとどう考えてもほぼ死亡です。我々15人の単位は虚空の彼方に消えて留年してしまいます。そこで失敗は一度にドカンとくるものではなくて小さく早く失敗し続けるような仕組みを取り入れる必要がありそうです。また、全員が成長できるということを真面目に考えると、誰が何を困って上手く行ってないといったことや今日やることなどを定期的にちゃんと共有する仕組みが無いとそもそも始まらないかなと考えています。また、できれば僕が仕切ってあーだーこーだ言うのは前時代的な組織ぽくて好きではないので、全員で成長するためにも全員が当事者意識のようなものをもって全員で考えていけるようなチーム、自己組織化されたチームを目指していきたいです。もちろん今すぐじゃなくて最終的にって感じですけどね。

さて、このお気持ちを達成するチーム開発の手法を考えてみましたが、自分の知識があまり無いのも有るとは思いますが、スクラムが最適なのではないかな…?というような気持ちになりました。あとはMiho🍺Nagase (@miholovesq) | Twitterさんのアジャイル開発ワークショップに参加した時の事や、スライドを見たりしながらいっちょ真面目にスクラム導入頑張ってみるかという気持ちになりました。

口うるさくスクラム導入したいと喚いて議論のきっかけを作ろうとする

とはいっても、ほとんどの学生にスクラム経験があるわけでもないので、まずはスクラム導入のために布教活動と俺はちゃんとチーム開発をしたいんだという激しい自己主張が必要がでした。大炎上するくらいなら喚くほうがマシという精神で。とりあえず、夏休みにプロジェクトで毎週技術勉強の進捗報告みたいなものをDiscordでやっていたので毎度毎度「ね〜ね〜アジャイル開発授業でやったよね!!!スクラムってしってる?やってみない??」と毎週毎週懲りずに話します。それどころか夏休み会う機会毎回行ってた気がする。完全にうざい人である。でもそうすると何人か乗ってくれるようになるのでその人達と話しながらスクラム導入の議論を進めていきます。また、enPiT(成長分野を支える情報技術人材の育成拠点の形成)の予算で用意されていたSCRUM BOOT CAMP THE BOOK amzn.asia をメンバーにポイポイ渡して読ませてみながら皆で「自分たちがどうやって開発すればいいのか…?」ということを考えていくようにしました。それもあってか、とりあえず各サービスでスクラムを導入してみようか という流れになりました。何も考えない開発スタイルは無事回避できそうだ。

おわりに

正直成功するかわからないですが、できるだけなんちゃってスクラムにならないようにやっていきたいお気持ちです。本当にここからは色々やってみるしかない。というわけで、実際にスクラムを導入していってやっていった話はまた次回以降。これからもちょくちょくまとめて行きます。ヤバイことしていたら指摘ください。失敗は小さくしていきたい…。というわけで今回はここまで。