この記事は全enPiT Advent Calendar 2020!!用の記事です。

筑波大学のenPiTで、昨年度と今年度、講師をさせていただきました伊藤です。
良い機会ですので、この2年のenPiTを通して、私自身が学んだこと、気づいたことについてまとめようと思います。自分メモと学生（メンター）さん向けの内容を含んでいます。

なぜ講師に？

大学の恩師がビジネスシステムデザイン分野の事業推進責任者をされていまして、私に実務での開発経験があるということでお誘いいただきました。私は筑波大初のベンチャー企業であるソフトイーサ社で10年以上、開発業務に携わってきました。小さな会社ですが、自社プロダクトの開発がほとんどで、私自身も20代のうちに量販店に並ぶようなパッケージソフトウェア/ハードウェアを手掛けました。自分で考えたものを開発し、製品にまでもっていった経験はこの歳では多い方かなと思います。また、未踏事業の合宿にお誘いいただくことも多いため、開発過程を拝見させていただく機会も多いです。そのため、プロダクト開発のメンタリングにはお役に立てるかと思い、ご協力させていただくことにしました。

その一方で、チーム開発についてはほとんど経験がありません。もちろん、協業という形で（各専門家が）手分けして製品までもっていった経験はありますが、複数人で同じプログラムを書くという経験はほとんどありません。そのため、チーム開発については学生さんと一緒に学ぶ気持ちで参加させていただきました。

お話が決まったのが、すでに学期が始まってからでしたので、私はいきなり6日間の夏合宿から参加することになりました。（ですので、今年のメンターさんよりも経験が浅いのです）

チーム開発の考え方が変わった

参加前の私のチーム開発のイメージは、各部の専門家が集まり、分業して効率的に開発していくというものでした。ビジネスっぽく言うと、アウトソーシングでコアな部分だけをおさえるとか、ファブレスでハードをやるとか、経営で流行った（今も主流？）考え方です。その感じで合宿に参加したのですが、そこで私のチーム開発に対する考え方は大きく変わりました。

私がチーム開発を積極的に取り入れていない理由は、開発を数名で分担してもあまり効率が上がらなかったからです。また、コミュニケーションが好きではないため、自分でできないところをアウトソースしてやってもらう以外では、自分で全部やってしまったほうが、効率がよく、ストレスも少なかったという理由もあります。そうやってチーム開発を避けていると、どんどんと個人でできることが増えてくるため、よりチームが必要なくなるというスパイラルで過ごしてきました。そのため、少人数チームのグループワークって、実際どうなの？という疑念を持ちながら、合宿に参加しました。

しかし、合宿1日目にスクラムの研修を（講師の顔をしながら必死に）受け、疑念は払拭されました。スクラムは、専門化・分業ではなく、チーム全体のベース能力と堅牢さの向上に主眼が置かれており、長期的に見て継続的に成果を出していける仕組みだと理解しました。また、3人いることで3倍効率…ではなく、3人いることで3倍堅牢、3倍品質になることを目指しているのだなと思いました（もちろん効率も上がるのですが）。つまり、チーム開発で得られると思っていたものがそもそも違ったわけです。これは私にとって衝撃でした（スクラムの専門化ではないため、あくまでも、私の解釈です）。合宿では、初日には環境構築でいっぱいいっぱいだったチームが、最終日には並列モブでバリバリ開発していた姿を目の当たりにし、なるほどこういうことか！と腑に落ちました。あの感動は今でも忘れられません。

そのほか、カンバンを用いたタスク？の管理方法や、エレベーターピッチ・ユーザーフローなど、なんとなくやっていたことに名前をつけられたことで、自分の開発にも活かせそうな知識を多数学ぶことができました。

enPiTは縮図

ここからは、ちょっと学生さん向けの内容です。

enPiTは、スクラムによるアジャイル開発を取り扱っていますが、私としては、学生さんが自ら考えたものを実際に開発するという点がとても大事ではないかと思っています。この経験があるのとないのとでは、その先に見えるものが全く違います。私自身でいうと、幸いにも学部3年のときに未踏ソフトに採択いただいたことで、そういった自分開発の経験あり、そのおかげで、大学で習う授業の内容がとても身になったことを覚えています。おそらく、enPiT受講者も、今後の大学の授業の内容が身にしみると思います。実際につまずいた点を解消する技術に出会えたり、講義で教わる基礎技術の活かし方がなんとなく想像がついたりと、授業内容が一歩二歩、身近に感じられるようになるはずです。

また、enPiTにはプロダクト開発の楽しさ・辛さがしっかりと詰まっています。たとえば、こんな喜びがあったと思います。

• 動いた！たのしい！
• 便利と言われた！うれしい！
• 思ったとおり、問題解決！天才！

一方でこんな辛さがあった（進行形で味わっている）と思います。

• 身近な問題って何だろう？
• 解決のアイディアがない…
• 実装できない…
• 時間が無い
• ユーザーの反応が悪い
• ユーザーさん、反応するのそこ？！
• 自分も使わない
• いいと思って作ったけど、実際できるとそうでもない
• 面白いんだけどなんか使わない
• 困っていると思っていたけど、そうでもなかった
• バグが取れない
• バグで1日飛んだ
• 議論が噛み合わない
• プロダクトに迷いが生じる
• ねぇ、昨日は動いたのに動かなくなったんだけど…

ちょっと、辛さが多くなりましたが… まぁ、どれかは思い当たるところがあると思います。
これらは、授業あるあるではなく（辛いところが多い点も含めて）プロダクト開発あるあるです。本当のプロダクト開発も、（収支に頭を悩ませる以外に）大きく違うことはありません。そのため、程度の問題はあれど、プロダクト開発のひととおりの経験ができたと思っても差し支えないと思います。

enPiTで遭遇率の低かったであろう経験は「あれ？この作り方、偶然知ってるわ！」という機会でしょうか。授業を通して、事前にすべての必要な技術を学習しておくのは、ほぼ不可能ということは分かったと思います。実際にプロダクトを開発していても、多かれ少なかれ学習が必要になることはあります。ですが、ときどき「そのプロダクト、偶然にも全部の実現方法がわかるわ！」という機会に出会います。狙って勉強したわけではなく、たまたま趣味で触っていたものが、5年越しに役立ったりすることがあるのです。そのため、面白そうだと思ったものを触ってみるのは、とても大事だと思います。enPiTを進めていると、役に立つものを…という考えになりますが、個人で楽しむ分には別に誰の役にも立たなくても構わないはずです。enPiTを通して、開発の基礎力はついたと思いますので、今度は、ただただ自分のためだけに開発を楽しむというのも良いでしょう。将来役に立たないかもしれませんので、あくまで、楽しむというのがポイントです。

少し話はそれましたが、結論、私が思うに、enPiTはプロダクト開発の縮図です。
enPiTが楽しかった人は、おめでとうございます。今後もずっとこんなことができます。
enPiTがつらかった人は、残念ながら、今後もずっとこんなことをやります。

個人開発でも生きるノウハウ

ここからは、enPiTで学んだことを今後の自分の開発にどのように生かしていきたいかをまとめます。

チーム開発についてですが、機会があればスクラムを取り入れてみても良いかなという気がしています。ただ、その機会が少ないことと、結局のところコミュニケーションがあまり好きではないので、新規プロダクト開発には取り入れなさそうです。運用系で考え方を導入したいですね。

一方で、アジャイル開発とカンバンなどのタスク管理は、すでに開発に導入しました。昨年から進めているプロダクトに、カンバンでの管理を導入しており、今も継続しています。また、スプリントの考え方を取り入れ、アップデートを定期的に行えるようになったため、ユーザーさんにも喜んでもらえています。カンバンは、ユーザー目線で作られたPBIと作業用のタスクの二段構造がとても気に入っており、導入してから効率と品質がアップしたように思います。最近は、別の仕事やプライベートの用事も増え、20代のときとは違って常に作っているもののことだけを考えていれば良いというわけにもいかなくなってきました。そのため、プロダクトの開発コンテキストをカンバンに保存できるようになったことで、プロダクトの開発だけではなく、生活全体が楽になったように感じます。enPiTで学んだテクニックは、何もチーム開発だけではなく、個人の開発にも十分に応用が効くものだと感じています。

さいごに

enPiTを通して学んだこととともに、学生さんへのメッセージもまとめさせていただきました。
2年と短い期間ですが、enPiT講師の経験は、多数の開発ノウハウを学ぶことができました。また、教員としてのノウハウも学べることが多く、非常に貴重で身になる経験をさせていただきました。機会をいただきました先生方には心より感謝申し上げます。

私が学生だった頃からすると、enPiTの授業は特殊な形態のようにも思いますが、改めて考えますと、自分で考えたソフトウェアを開発するという授業は、ソフトウェアに関わるすべての人が受けるべき授業なのではないかと思います。なぜなら、そのあとに受ける授業の効果が変わると考えられるからです。週2回、4人の教員がつきっきり…という豪華仕様は難しいと思いますが、このような自らのソフトウェア開発体験の機会が今後どんどんと増えてくることを期待しています。