はじめに
この記事を書くきっかけ
今回、enpitという授業の最終レポートとしてこの記事を書いています。enpitというのは文部科学省が推進するプログラムで以下のように述べられています。
本プログラムは、情報技術を高度に活用して社会の具体的な課題を解決できる人材の育成機能を強化するため、産学協働の実践教育ネットワークを形成し、課題解決型学習（PBL）等の実践的な教育を推進し広く全国に普及させることを目的としています。
色々書いてありますが、まぁIT人材を育てるための取り組みのようなものだと考えてもらって構わないです。
余談ですが、ブログ形式で文章を書くというのが今まで生きてきて今回が初めてなので新鮮な気持ちです。見にくかったら申し訳ない...
アジャイル開発について
enpitでは開発手法としてアジャイル開発を採用していました。アジャイル開発ってよく聞くけど、最初は「なんかカッコいい名前の開発手法らしい」くらいの認識でした。
ざっくり言うと 「ちょっとずつ作って、試しながら改善していく」 スタイルの開発手法です。普通の開発（ウォーターフォール型）は、最初にガチガチに仕様を決めて、その通りに作っていくけど、アジャイルは「とりあえず動くものを作って、フィードバックを受けながらブラッシュアップしていく」**という感じ。
例えば、カレーを作るときにウォーターフォール型だと…
- 材料を全部そろえる
- レシピ通りに全部調理する
- 完成！でも味見するのは最後
アジャイル型だと…
- まずはカレーのベースを作る
- 味見して「ちょっとスパイス足りないな？」って思ったら追加
- 途中で「やっぱりシーフードカレーにしよう」と方向転換
みたいな感じ。やってみて「これ違うな」と思ったらすぐ修正できるのが強みですね。
enpitでも、最初に「これを作ろう！」と決めたものの、途中で「やっぱりこうしたほうがいいよね？」と仕様変更が入ることは当たり前に起きていました。最初は戸惑いましたが「作りながら考える」っていうのが意外と性に合ってたなと思います。
私について
こんな感じのプロジェクトに参加しましたが私自身は全然大したことがないです。
enpitに参加した当初は、Gitは初めてまともに使ったし、個人で開発とかしたことないし、開発する言語も何を使うのか全然わかってないしみたいな状態でした。とはいえ、漠然と「みんながやってる開発ってものをしてみたいなぁ」と思ってはいました。
そこにちょうどenpitの話が舞い込んできました。自分で頑張るのが苦手で環境に左右されやすい性格なのは自分も理解していたのでちょうどいい環境だと思い申し込んで受けることになりました。気持ち的には紀貫之ですね。
「皆もすなる開発といふものを、私もしてみむとてするなり。」
開発したアプリ SuStudy,
開発したアプリは「Sustudy,」というアプリです。
これはコミュニティ型勉強習慣化アプリとして作成しました。このアプリでできることは
- アプリ内で問題が解ける
- アプリ内で目標（1日5分やTOEIC500点）が設定できる
- 投稿やランキングで友人の進捗がわかり競える
- 通知や継続日数の表示で継続しやすい取り組みが行える
開くとログイン画面があるので新規登録から登録してください。進めていくと勉強したい項目について出てくるので「TOEIC500点」を選択して進めてください。その後進めていくとチュートリアルが出てくるのでそれに従って機能を体験してみてください。（もしチュートリアルが進まなくなった場合、再リロードしてください。）
資格勉強や受験など長期的な勉強を継続できるような体験を意識しました。以下のURLから使用することができます。（未完成な部分もあるよ）（しっかり体験したい人はTOEIC500点を目標に選択してね）
https://sustudy.netlify.app/
チームについて
メンバーについて
チームのメンバーは6人でスタートし、諸事情によって最終的には5人になりました。
フロントエンドやバックエンドなどの役割は明確には決めず、2人組と3人組で作業をしてローテーションするという仕組みをとりました。個人的にこの仕組みは非常に感触がよく、学びながら開発をすることができたと思っています。
私のチームではプロダクトオーナーとその日の進捗管理をするスクラムマスターは決めていました。
プロダクトオーナーのやりたい方針が明確だったので、開発段階では方針をしっかり持って迷いなく取り組むことができたと感じています。スクラムマスターはその日のスプリント（目標のようなもの）を逐一管理してくれて、また、振り返りやチームとしての取り組み方などをまとめてくれました。彼らには頭が上がりません。
他のふたりはデータベース設計などのバックエンドの開発が多く、私自身がデータベースなんのこっちゃだったので色々教えてもらい助かりました。
私の役割
明確な役割を決めてはないですが、フロントエンド側の作業を主に担当していたと思います。データの表示の仕方や全体のデザインの考案などです。発表資料のスライド作成もしました。スライド作成は好きなので楽しく作業できましたね。
チームの軌跡
夏合宿
今回のレポートでは夏合宿のことについてレポートには必須ではないですが、私たちのチームにとって重要だと感じたので書きます。
私のチームは良くも悪くも皆がしっかり意見を言って話し合いをするチームでした。特に課題の設定やアプローチの方法は話し合いに時間がかかりましたが夏合宿では2日ほどかけて方針をまとめることができました。
基本的に夏合宿のプロダクトを継続して秋も開発するという形なのですが、私たちが夏合宿に作っていたものは「とどくくん」という配達の注文忘れなどを防ぐことを目的としたプロダクトでした。アジャイル開発では最初に解決したい課題を見つけ、その課題を皆が課題と感じているかを検証し、それにアプローチしていくという形をとります。
しかし、夏合宿を終えて秋に進む際、このプロダクトでは課題を解決できないとなってしまいました。
秋前半
さて、夏合宿で作ったプロダクトは諦めて秋になりました。
選択肢は2つありました。
- 課題はそのままで、新しいプロダクトを考える。（新しいアプローチ方法を模索する必要がある）
- 課題も変更し、新しいプロダクトを考える。（課題の検証からやり直す必要がある）
私たちは話し合った結果、後者の「課題も変更する」という選択をとりました。そこで二日間かけて話し合いと検証を行い、その結果「勉強の先延ばし癖を直す」ためのアプリを開発することが決まりました。
次に言語の選定です。プロダクトはアプリが理想でしたが、メンバーは誰もアプリに関してはノータッチだったためアプリ開発をどうするかの学習から始まりました。結果としてReactnativeかFlutterの二択で悩むこととなりました。
FLutterの言語は皆が触れたことのない言語でしたが、最終的にはweb, ios, androidのすべてに対応しておりユーザーが日常的に使いやすいプロダクトを制作することができる点やチームメンバーの挑戦意欲を反映してFlutterを選択しました。
また、開発に関して強みである通知機能とデータベース設計に取り組みました。ここでは明確な役割を分けず全員で開発に取り組みました。このおかげでデータベースの構成について全員が理解できた一方、より開発のスピードを上げる必要があるとも感じました。
秋中盤
まず、前半で起きた開発のスピードを上げる必要があるという課題に対して、その日の作業を細分化し、班を作って分担することに決めました。
そして方針とレビューについて新たな課題が生まれました。
- 方針：習慣化アプリについて通知に加えて何を強みにして習慣化を促すかが決まっていない。
- レビュー：毎授業後にプロダクトに対してもらうレビューの目的があやふやなことに加え、シンプルにレビューに対して時間を作れていないこと。
方針について、これはチーム内での話し合いを徹底することでSNS型を強みにすることとしました。理由は、SNSは定期的に開きやすいなどのメリットがあ理、習慣化に良い効果をもたらすと話し合い、評価を貰えたからです。
また、レビューについては毎授業ごとに何をレビューしてもらいたいかを決めることと１5分前からレビューに関して動き出すということを決めました。
ここで、開発したことは全体のUI、ログイン画面の実装とそのデータ設計、問題を解く画面など大まかな枠組みと肝となる学習の部分を実装することができました。開発の中で、全体のUIの見やすさ、ログインおやり方に関してレビューをもらい、修正を加えながら実装することができたのは非常に良かったと感じています。
秋後半
後半では開発も進み、プロダクトの全体像も形となり、チームの中の方針もほとんど一致するようになりました。その一方で、データベースやコードなどが複雑となり、自分が担当していなかった部分の内容がわからなくなってきたという問題に直面しました。チームとしてこれはマズイと思い、解決策としてローテーションで班を回すということでした。
このやり方は班の中の一人は次の授業では別の班、もう一方は残るという方法です。このやり方の優れているところはまず開発を進めつつ、学習も行えるということです。残されたメンバーは班の担当の開発を進めているため教えることが容易にでき、もう一方は質問をしながら学習しつつ開発を進めることができます。
また、チーム全体を見てもローテーションを繰り返すことでチーム全体の知識、進捗状況の把握を同じレベルに持っていくことができました。個人的にこのやり方は非常に開発が捗ったと感じています。
後半では今までで学んだことをmiroに乗っけることで毎授業の動き方を同じように進めることができ、良いリズムが作れたなと感じています。
開発に関してはここではモチベーションを上げるための機能について実装しました。SNSの投稿、友人とのランキング機能、その日のミッション達成度などを実装することができました。
最終発表に向けて
最終発表に向けてスライド資料の作成とプロダクトの完成をどうするかについて話し合うことになりました。
プロダクトに関して、当初はアプリでの実装を理想としていましたが審査や時間の問題から今回は断念し、Webアプリとして発表することに決めました。スライド資料の作成は主に私が担当させていただき、全体のデザインと発表の流れを決めました。細かい文章や内容はチーム全体で話し合い、擦り合わせながら完成まで持って行きました。
チームの最終的なAMFは以下のようになりました。
自分のチームでは問題点を赤、良かった点を緑の付箋で表しています。
赤が多い部分にはそれを解決するための方法を黄色の付箋で貼り、改善できるように作成しました。
enpitを通じて
この期間で私が学んだことは、計り知れないほど多くありました。
全く知らなかった開発の流れや、問題提起からプロダクトを決めるまでの過程。チームで意見を出し合いながら課題を深掘りし、それが本当に解決すべき課題なのかを検証することの大切さを実感しました。
技術面でも多くのことを学びました。Gitの基本的な使い方から始まり、チーム開発におけるブランチ運用、コードレビューの重要性など、個人開発では経験できなかったことばかりです。また、開発環境のセットアップや技術選定といった、普段あまり意識しなかった部分にも目を向けるようになりました。
もちろん、アジャイル開発についても学ぶことができました。最初に作ったものが必ずしも正解ではなく、ユーザーのフィードバックを受けながら改善していくプロセスは、とても実践的で学びの多いものでした。特に、途中でプロダクトを大きく方向転換する経験をしたことで、「作ること」が目的ではなく、「課題を解決すること」が目的であるという意識を持つようになりました。
しかし、私が一番大きな学びになったなと感じたのはチーム開発です。
enpitを通じて学んだこと
この期間で学んだことは、計り知れないほど多くありました。
全く知らなかった開発の流れや、問題提起からプロダクトを決めるまでの過程。チームで意見を出し合いながら課題を深掘りし、それが本当に解決すべき課題なのかを検証することの大切さを実感しました。
技術面でも多くのことを学びました。Gitの基本的な使い方から始まり、チーム開発におけるブランチ運用、コードレビューの重要性など、個人開発では経験できなかったことばかりです。また、開発環境のセットアップや技術選定といった、普段あまり意識しなかった部分にも目を向けるようになりました。
加えて、アジャイル開発の考え方にも触れることができました。最初に作ったものが必ずしも正解ではなく、ユーザーのフィードバックを受けながら改善していくプロセスは、とても実践的で学びの多いものでした。特に、途中でプロダクトを大きく方向転換する経験をしたことで、「作ること」が目的ではなく、「課題を解決すること」が目的であるという意識を持つようになりました。
しかし、チーム開発をできたのが最も大きな収穫だったと思います。チームでは意見がぶつかることもありましたが、それを乗り越えて一つのものを作り上げる過程はとても刺激的で、自分一人では得られなかった学びや成長があったと感じています。その中で特にコミュニケーションの重要性は非常に感じました。対面の話し合いはもちろん、オンラインのチャットやタスク管理ツールを活用して、進捗状況をこまめに共有することで、メンバー間の認識のズレを減らすように動くことは今回でいかに重要かを学ぶことができました。
このような経験は開発に関わらず、複数人で行う作業全てに通ずることがあると思います。サークル活動や勉学にはもちろん、将来的に仕事などにも活かせるかもしれません。この経験を通じて、技術力だけでなく、課題解決の視点やチームでの協働の大切さを学ぶことができました。これからもこの学びを活かして、さらに成長していきたらと思います。
おわりに
ここまで読んでいただき、ありがとうございました。最初はブログっぽく書こうと意識していましたが、後半はすっかりそのことを忘れて、気づけばいつもの書き方になっていました。でも、こうして振り返って文章にすることで、自分が学んだことや感じたことを改めて整理できたのは良かったなと思います。
これをもって最終レポートとさせて頂きます。