まずは自己紹介
この記事をお読みの皆様こんにちは！orikouです。2022年度の筑波大学のenPiTという授業の個人レポートとして提出するためこの記事を書くことになりました。
私の大きな特徴として
- プログラムに自信がない
- 周りにプログラムがバリバリかける人に対しててちょっと劣等感みたいな感情を抱えてしまう
というような特徴があります。プログラマーとして駆け出しの方や編入生にも同じような悩みを抱えてしまう方はいらっしゃるのではないでしょうか？
この記事はそのような方、特にプログラムに苦手意識はあるけどenpitに参加しようか迷っているという方に向けて書いていこうと思っております。プログラムに関する難しい話などはしない（できない）ので最後まで読んでいただけると幸いです。
今回参加した「enpit」って何？
enPiTビジネスシステムデザイン分野(通称:BizSysD)は、社会やビジネスニーズに対する実用的なソリューションとしてのビジネスアプリケーションやシステムデザインを自ら提案、開発し、顧客の潜在的要求を満たすことのできる人材育成を目指します。
公式サイトからの引用ですが、少しわかりづらい内容ですね。ざっくりいうと実践的な問題解決を自発的に行える人材を育成のための授業となっています。かつては文部科学省から予算が下りていたプロジェクトですが、今は筑波大学とその連携校が予算などを出し合ってこのプロジェクトを継続しています。
この授業のテーマとしては「アジャイルな開発」とそれを行える人材の育成に主眼が置かれており、プロダクトの質が絶対的な評価にはならないという点で私のようにプログラムが苦手な生徒も幾分参加しやすく感じていたでしょう。実際、この授業ではプログラムを書くのが苦手という生徒も一定数いらっしゃいました。
アジャイルな開発とは
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を
上記はアジャイルソフトウェア開発宣言から引用した内容です。つまるところ、
- プロダクトにもチーム運営にも正解はないという前提のもと、皆で話し合って最善を尽くす
- 綿密な計画を立てても簡単に破綻する。ならとにかく素早く「動く」ものを作ってユーザーに見せる
- 実際にユーザーに意見をもらい、その都度軌道修正する
といった内容になっています。
この考え方は私にとってかなり新鮮なものでした。実際に多くのプロダクトがそもそも社会に必要とされていなかったという理由で失敗に終わっているということを知ることもできたので、このアジャイルな開発のチーム管理とアプリの方向性の制御という観点では私はみんなの役に立つことが出来ると思うことが出来ました。
enpitの授業の流れ
enpitの授業はこのように3つのタームに分かれています。まず基礎知識学習期間では、基本的に個人ワーク(自習)を行い次のPBL基礎期間でプロダクトを作ることが出来る力を蓄えます。
次にPBL基礎の期間では、enpit受講生の中で共通の「困りごと」を持つメンバーで集まり、5人ぐらいのチームを組みます。そしてそのチーム内でプロダクトの方針を固め、5日間の集中授業によってプロダクトを作り上げます。
秋以降の発展学習では、enpitの講義を半年しか受けられない生徒がいるため、チームが解散になったり追加メンバーを募集して、夏までのプロダクトを引き続き発展させたり、また新たなプロダクト開発をしたりします。この秋の期間は週2回集まって授業するため定期的な仕事に近いような形でプロダクト開発を行います。
今年度は上記の画像より基礎知識機関が一か月短く、その後のすべての予定が一か月前倒しになっています。
各期間での具体的な取り組み
基礎知識期間
私はこの期間progateで初めてのrubyの学習に取り組んでいました。(結局使わなかった)enpitの受講生は、ドットインストールに取り組まれる方やUE(Unreal Engine)の学習をされる方、htmlの基礎を学習される方など、多様な取り組みがありました。
この期間中は2週間に一回成果報告会があったのですが、ランダムなグループに分類されてヒーローインタビューのような形式で成果報告を行うのはとても楽しかったです。参加したメンバーはどんなに些細な進捗でも「えらい！えらい！」とほめてくれるので、自信のない自分でも堂々と発表できたと思います。
またこの期間中には、ゲスト講義やgit演習など、PBL基礎や発展学習期間を有意義に過ごすことが出来るような講義も実施されています。
PBL基礎期間
この期間で私はほかの5人のメンバーとチームを組みプロダクトの作成を行いました。一か月ほどチームの方針を話し合う時期があり、その後5日間の集中授業によってプロダクトを作り上げます。
私は「インペリアルスカラー」という5人組のチームに参加し「ココロミエル」というプロダクトを作りました。このプロダクトはオンライン授業でのコミュニケーションの難しさを軽減するための匿名の感情表現ツールです。デプロイされていないので、イメージで伝えると、Discordのリアクションがツムツムみたいに降ってくる感じです。このチームではデプロイにかなり苦戦しました。デプロイという作業は顧客からのフィードバックをもらう上で必要なので、顧客からのレビューをもらう時間を有効活用できなかったのは少し後悔しています。
ココロミエルのエレベータピッチ
発展学習期間
この期間は、今までチームに参加していたメンバーが継続して授業を受ける人と、やめてしまう人に分かれるのでチームが消滅したり、新たなメンバーが追加されて作業を継続するチームが生まれたりします。私の参加していた「インペリアルスカラー」はメンバーが3人抜けてしまったのでチームは解散となり、「注文の多い料理店」というチームと合流することになりました。この「注文の多い料理店」では「Cookりさん」というプロダクトを作成しました。
このプロダクトはタグを用いた絞り込み機能によって楽にレシピを決定できるプロダクトです。以下にリンクを張っておくのでぜひ使ってみてください。（スマホの使用推奨）この課題内容は継続ですが、新たなメンバーが参加したので、顧客のニーズの調査の段階からやり直してプロダクトを作成しました。開発の初期は何が本当に顧客にとって必要なのかという話し合いやそれを知るためのレビューを繰り返したので進捗は遅れ気味でしたが、顧客にとって価値あるプロダクトを作るという点ではとても良い進め方が出来ていたと思います。
授業としては、週に2コマ分の授業が2回あり、それぞれの時間で授業の時間で開発をすすめていきました。実際にプログラムを書く授業時間は100分程度でそのあとにレビューの時間があるので、その授業時間内でレビューの効果を最大化するような取り組み方をしました。ほかの班は授業時間後も残業することもあったそうですが、私たちの班は残業を全くしなかったので、決められた時間で効率的なプログラムを書けていたと思います。
enpitで得ることのできた知見
顧客からのレビューが第一
ネットで顧客が本当に求めていたものみたいな画像を目にしたことがあるでしょうか？
この画像は、ビジネスの複雑な工程によって、結果が顧客が本当に求めていたものから大きくかけ離れていく様子を滑稽に描いたものですが、これは非常によく起こりえる状況です。実際に、問題の定義、設計、開発を順番に行っていく従来の開発手法（ウォーターフォール）でのプロジェクトは29%が失敗し、成功するのはたったの11%であとは課題が残るとされています。その失敗の原因として大部分を占めているのが「顧客が必要としていなかった」という点です。
アジャイルな開発では、このような失敗を減らすため顧客との対話に基づく、もしくは顧客を巻き込みプロジェクトを進めていくことでそのプロジェクトが失敗する確率を大きく減らすことが出来ました。この話は就活をした際も必ず使える話なので、経験しておくのはとてもいいことだと思います。
| 手法 | 成功 | 課題有 | 失敗 |
|---|---|---|---|
| アジャイル開発 | 39% | 52% | 9% |
| ウォーターフォール | 11% | 60% | 29% |
この授業では、こまめにお互いにレビューをしあう機会を設定してくださっていたのでそれに向けて各授業で準備し、レビューをもらうことで顧客にとって本当に必要なプロダクトを作成することが出来ていたと思います。
心理的安全性について
この概念は私がこの授業を通じてかなりクリティカルに刺さった概念です。これはチーム内で自分がわからないところがあったら気兼ねせずに聞けたり、失敗したら自分で何とかしようとしたりせず、すぐにチームに報告できるような環境が整っているのがという観点です。
私は、すごく気兼ねしてしまうし、自分で何とかしようとしてしまうので、この授業内では心理的安全性を確保しようと心がけました。チーム内のメンバーも心理的安全性の確保が出来ているか気を配っていたので少し専門的な話をしすぎた際は、コードの説明を行ったり、「何かわからないところあった？」と聞いてくれました。
ここで重要なのは、心理的安全性を確保するときにメインとなるプレーヤーは一番コードを書くのが苦手な人であるということです。この人が積極的に「これってどういうコードなの？」と質問をすることで、ほかのメンバーも自分にわからないコードがあった際に質問がしやすくなります。
心理的安全性の確保にはお互いのリスペクトが必要ですが、プログラムができる人ができない人を見下すようなことは自分は経験したことがない（プログラマーは初心者にやさしい）ので、「馬鹿にされるかも...」なんて思わずにどんどん質問するとよいチームの雰囲気につながります。
属人化を避けよう
属人化とは、特定の作業についてその人しか扱うことが出来なくなっている状態のことです。チームでプログラムを書いている人なら何度か経験したことがあるのではないでしょうか？特に優秀なプログラマーがいる場合は、「なんかよくわからないけど、○○さんの邪魔しちゃいけないし、この機能の実装は全部○○さんに任せちゃおう！」という気持ちになりやすいと思います。
しかし、そのような取り組みをした結果、その人がチームをやめてしまったり、何らかの事情で欠席してしまった場合に仕事が全く進まないなどの大きな不利益が生じる場合があります。秋以降の開発では、このような不利益をなくすための取り組みに力をいれて開発を行いました。その手法として用いられたのが「モブプログラミング」通称「モブプロ」です。これは、一人の人がドライバーとしてプログラムを書き、ほかのメンバーが「VScode Liveahare」などの機能を使ってその様子を見たりしながらプログラムをすすめていく手法です。作業効率は分業に比べて劣るかもしれませんが、プログラムに対する理解をチーム内全員で同じ水準まで高めることが出来るので、もし優秀なプログラマーが休んでしまってもチームでプロダクトを続行することが出来ます。
また自分がモブプロに参加して感じたのが、優秀なプログラマーがコードを書いている様子を実際に見ることが出来たので、かなり良い学習になりました。Fast APIとかVootstrapの存在を知らなかったので、このモブプロを通じて知ることが出来て非常に役立ちました。また大人数で一緒にプログラムを書くと文法ミスにすぐに気が付いたりやより良いアイディアが出やすかったりと、特有のメリットも生まれていたように感じました。
最後に
ここまで読んでいただきありがとうございました！
プログラムに自信のない方でも、チームの運営やプロダクトの方向性の決定、心理的安全性の確保といった点でチームにおおいに貢献できるという点は覚えていってもらえると嬉しいです。
またenpitを受講するか悩んでいる方がいらしゃればぜひ！enpit受講しましょう！