Qiita全国学生対抗戦 Advent Calendar 2023の19日目の記事です。
はじめに
こんにちは。ご覧いただきありがとうございます。
前振りもなく突然ですが，今回は友人と行っているプロジェクトについてご紹介したいと思います。
有益な技術的要素は含まれませんが，最後までご覧いただけますと幸いです。
プロジェクトの概要
昨今，学校現場はブラックと言われています。
日々の業務が多忙を極め，定時出勤・退勤が難しいのが現状です。
しかしながら，昔に比べ業務の効率化は進んだものの，依然としてIT化はほとんど進んでいないと言っても過言ではありません。（コロナ禍でスクールGIGAは進みましたが）
現状の問題点
例えば，日々の業務の1つである時間割作成はおそらく多くの学校がExcelを用いて作成しています。
時数の計算はさすがに電卓ではなく，Excel関数を用いていると考えられますが，年間1000時間を超える授業をクラス別に集計するのにExcelは適さないでしょう。
確実に計算が重たくなりますし，管理するのがかなり難しいでしょう。
そこで友人とそのような業務改善に繋がるWEBアプリを作成するプロジェクトを考えました。
実際にはチーム開発をしたい，プロジェクト運営を経験したいという下心があります。笑
ビジョン
本プロジェクトでは「教師の子どもと向き合う時間が増え，よりよい教育ができる様に環境づくりをする」をビジョンに掲げ，アプリ開発を行っています。
本来，教師のあるべき姿は児童生徒としっかりと向き合い，人格形成に寄与することであるにも関わらず，現状は多忙を極めており，それが難しいということがあります。
そのため，業務改善をWEBアプリという手段を用いて行い，よりよい学校教育の環境づくりを行うことが必要だと考えられます。
これらの理由からビジョンを設定しました。
また，このビジョンを達成するために
- 教育現場の業務効率化を促進
- 悩みの解決や今後の教育を考える場づくり
という2つのミッションを設定しています。
プロジェクトの内容
プロジェクトは立ち上げたものの，実際には研究が忙しく，進捗は全く芳しくありません。
（二人とも院生で特に秋は学会発表等もあったため，忙しかったです）
現状，本プロジェクトは最低限の機能で以下のサービスが公開されています。
- ユーザー認証
- 教師相談：知恵袋のように教師らが悩みの共有や相談ができるサービス
- 指導案共有：作成した指導案を共有するサービス
- データ共有：作成した授業に関するデータを共有するサービス
これらを実現するための技術スタックや工程等をご紹介します。
技術スタック
サーバ
本プロジェクトはお金儲けというよりも経験を積むことが目的であるため，第一にお金を極力かけないようにすることが念頭にあります。
そのため，WEBサーバは筆者がHP等で利用しているレンタルサーバとしています。
こうすることで本プロジェクトのために余計なお金が発生していません。
（今後，ユーザーが増えたらクラウドに移行するかもしれませんが，その際はマネタイズを考える必要が生じます）
バックエンド
筆者がプログラミングできるPHPのフレームワーク，Laravelを採用しました。
採用と言っても他にバックエンドでできる言語を持たないため，他の選択肢はありませんでした。笑
加えて，Laravelは利用ユーザーが多く，情報が充実しており，向こう数年は安定して運用できることも採用できた理由にもなります。
フロントエンド
フロントエンドはLaravelのbladeではなく，React.js(TS)＋Viteとしました。
HTMLやCSS，JavaScriptはそれなりにコーディングできるのですが，モダンなUIにするためにはReactが良いと考え，採用しました。
Laravelと同様，Reactもユーザーが多く，情報が充実していることも理由の1つです。
また，プロジェクトの人数が少なく，開発工数を極力削減するため，React Bootstrapを用いています。
そのため，動的なページの作成も低工数で可能です。
APIドキュメント
フロントエンドのReactとバックエンドを繋ぐためにAPIを用いています。
そのドキュメントはOpenAPIを用い，HTML生成にはRedoclyを用いています。
画面がSwaggerに比べて見やすく，それなりの利用ユーザーがいることから採用しました。
上流工程
基本的にはプロジェクトメンバーでミーティングを行い，様々な定義を行っています。
第1回のミーティングでは「何を実現したいのか」，「そのためにはどのような機能が必要か」ということを中心に話し合います。
終了後に内容を整理し，担当者が要件定義を行います。
第2回のミーティングでは，要件定義の確認を行います。
前回のミーティングの内容やお互いの認識に齟齬がないかの確認も行いながら，要件定義の粒度を上げていきます。
終了後に要件定義を元に，設計を行っていきます。
設計においてはDBの設計や画面の設計（必要な画面等）を中心に行います。
第3回のミーティングでは，設計内容の確認を行います。
DBは設計指針に従ったものになっているか，要件定義の内容を満たすことができる設計になっているか等の確認を行います。
画面設計は実際に利用する場面をシミュレーションし，使いやすいものになっているか確認を行います。
ただし，画面設計は基本的にUIやUXの設計ではなく，画面の遷移等が中心です。
終了後，バックエンドとフロントエンドを繋ぐAPIの設計を行います。
第4回ミーティングでは，APIの確認を行います。
APIの設計指針に従ったものになっているか，DBと内容の齟齬がないか等の確認を行います。
また，基本的にはドメイン駆動ではなく，DBのテーブルに沿ったAPIとしています。
そのため，一部フロントの工夫が必要になることがあります。
以上のように複数のミーティングを重ねてから実際の開発フェーズに入ります。
なお，ミーティングの合間にもチャットやドキュメントベースで摺合せは行っています。
下流工程
基本的に設計を元に開発を行います。
開発においてはブランチルールに従ってブランチを作成し，プルリクでマージを行っています。
プルリクではプログラミングしていないメンバーがレビューを行っています。
実際の現場とは異なるかもしれませんが，人数や時間の制約上，このような流れで行っています。
ウォーターフォールとアジャイルを参考にしています。
プロジェクトを運営しながらの感想
「時間や人と言ったリソースが足りない！！」の一言に尽きます。
友人は設計をもっと丁寧にしたがっていましたが（例えばクラス図の作成等），時間が少ないため細かな設計はしないことにしています。
（友人も実際に設計をしてみて，時間的に細かいのは無理だと言っていました）
もちろん，設計が根幹となり重要であるため，手は抜きませんが，詳細な設計は極力省き，どのような実装をするのか等具体的なことはプログラミング時に考える，という風になっています。
これはある意味，人数が少ないからこそできることな気はします。
また，元からあった下心（笑）のチーム開発やプロジェクト運営の経験としてはやっている甲斐があるかなとは思っています。
まず，楽しいのは確実です。
友人と色々言いながらアイディアを出してそれを実現させていくというのはこれまでに経験してきていないため，新鮮でとても楽しいです。
加えて，これまでは個人プレーでしていたため，正直なところ設計指針等をわざわざドキュメント化しなかったですし，設計も適当な部分が多かったです。
しかし，複数人でするためには共通の認識がなければスムーズな運営は難しく，ドキュメント化することはとても重要です。
これまで頭にボヤっとあった指針を確実に伝わるような言語化する作業はなかなか難しかったです。
プロジェクトメンバーの募集
まだまだ小さなプロジェクトで今後もどうなるわからないようなプロジェクトですが，メンバーも募集しています！
- チームで開発してみたい
- 勉強だけでなく，実際にサービスを提供してみたい
等々どのような理由でもよいです。
もし本プロジェクトに興味を持って，参加していただける方がいらっしゃいましたら是非ともご連絡を頂けますと幸いです！
本プロジェクトは営利目的ではないため，趣味の延長上です。
お金を得ることはできませんが，なかなか経験できないことが経験できるように今後も活動をしたいと思っています。