🔧 阿川の電商水電行
概要
地方的公立高中在籍的筆者，總結了他在開發文化祭整理券系統時的經歷。這是我第一次製作供大眾使用的服務，包含失敗在內的這一過程，對我來說都是一個良好的體驗。
我相信有許多可以改進的地方，如果您有任何指教，歡迎在評論中告訴我。
作出的產品
在高中文化祭上，我製作了一個Web系統（以下稱為整理券系統），讓參加各班活動的同學能通過裝置獲取和管理整理券。這個系統的概念接近於醫院等地的預約系統。
功能
- 整理券的取得與管理
選擇想參加的活動後，可以通過手機的瀏覽器取得整理券。獲得的整理券會由各活動的工作人員來管理，等到順番時便能參加該活動。此外，當自己的整理券被叫到時，會收到通知。 - 了解活動信息
可以查看各活動的等待時間、等待人數、舉辦地點等資訊。 - 確認活動資訊等
可以查看冊子中所發放的宣傳手冊內，部分活動的時間表等資訊。
使用語言
採用了Next.js（應用路由）+ TypeScript + Tailwind CSS。
資料庫使用了Supabase（但後面會提到一些問題）。
因為是使用Next.js，所以所有的託管服務都是在Vercel上進行的。
開發過程
1）開發的經過
・在疫情過後的去年文化祭上，候補的人實在太多，導致銷售額下降，並且等待隊伍妨礙通行等問題發生。
・為了解決上述問題，我想製作一個整理券系統，來解決活動的等待問題。
・但是外包開發的預算實在無法負擔…
・那麼就讓學生和老師一起來做吧！（由學生會提出）
雖然學生會和實行委員會的高年級生想到這件事，但因為是普通科，能夠實現的人才本來就不多...
2）開發成員
・負責程式設計：1名（筆者）
・負責設計：2名（來自美術部的學生等）
・其他負責（測試等）：4名
・顧問：1名（數學科教師）
最終，學生會在文化祭前的三個月招募了有志的學生，組成了上述成員。
因為募集條件是「希望能透過程式設計製作文化祭系統的人！」，所以當時一年級的我也報名了，但如我所料，聚集的都是不太能夠實現系統的同學。
我之前已經體會過如果完全依賴沒有程式設計經驗的人進行開發會出現什麼情況（以下的文章），所以在首次會議上我就感覺這樣可能不妙。
不過，參與開發的數學科老師因為是個對程式設計有興趣的人，因此給予了不少幫助，讓我們都覺得或許還是能做到的，於是開發工作開始了。
3）開發時間等
成員齊聚是在3月下旬，而文化祭是在6月底，所以開發期間大約為3個月。不過，由於我還在參加社團，所以是孤軍奮戰地撰寫程式，要在6月上旬前完成，因此從需求定義到結合測試實際上的開發期間大約只有兩個多月。
4）需求等
開發前，學生會要求的系統需求包括：
- 能夠在瀏覽器中取得和管理整理券
- 能承受約3,000人的同時存取
- 資料不會因為刪除瀏覽歷史而消失
- 預算控制在三天的運營內不超過10,000日圓
而考慮到開發者是外行人，學校還要求：
- 不需要進行帳號註冊
- 不使用電子郵件地址等個人資訊
基於此，決定繼續朝著Web應用的方向展開開發。
結果來說...
雖然有各種問題存在，但簡而言之，在兩天的文化祭中，沒有發生重大的糾紛。學生們和一般來賓們都能利用這個系統享受班級活動。
透過系統的開發，銷售額的增長和活動等待隊伍的消失等，原先導入目的的班級活動等待問題獲得了解決。此外，在來賓的問卷中也收到了許多正面的意見，還促進參與的班級活動數量的增加等副作用。
許多問題點
儘管最終系統成功了，但這一成功的背後卻隱藏著許多重大問題。
在之前類似的情況下開發時，
・功能過於繁雜導致系統未能完成
・難以獲得周圍人（特別是教師）的理解，系統無法運行
・其他成員的工作漸漸消失
基於這些經驗，總結了這次開發中我所做的事情，及其後出現的問題。
1）人力資源方面
如之前所述，程式設計完全依賴我一個人，而我在開發供大眾使用的服務方面並無經驗。系統規模並不是特別大，但是因為要參加社團，所以我也清楚無法投入太多時間進行開發。
所做的工作
・最小限的設計
當成員在一起時，我感到危機感，基於之前只用外行製作大型系統而失敗的經驗，我力求系統以最低限度的功能運行。利用生成AI等工具，編碼上特別沒有遇到困難。
・明確任務
針對運行的最低限度功能和其他成員能做的事情進行明確，提前考慮好時間表以推進開發。特別意識到可以分配不需要程式設計知識的任務，如畫面配置和操作測試等。
面臨的問題
・其他成員的參與度低於預期
我認為我自己的任務管理方面也存在問題，但在向他們提出「時間不夠」或「不理解」時，他們多數拒絕了不需要程式設計的任務。例如，即使我說「希望在一週內製作這個圖示，並思考這個按鈕的設計」，期限往往被不遵守，甚至根本沒有被做。
・周邊的任務預估過於寬鬆
因為周圍的同學和老師都沒有程式設計經驗，他們對於實現工數的估算相當鬆鬆。對於實現而言，經常會被問「能更快完成嗎？」或「這個功能為何不能實現？」即使解釋原因，有時也難以獲得理解，這讓我相當痛苦。
2）開發方面
因為之前沒有制作過大型公眾服務，所以我試圖以自己獨特的方式進行開發。
所做的工作
・模仿著試著去做
參考公司裡的系統開發文章，試著模仿以發展出開發的形式。例如，首次實施的git版本控制，還有考慮到程式碼的可讀性來進行實現。
・進行細化的需求定義
學生會的要求總體較為笼统，因此我進行了詳細的需求定義。將功能需求與非功能需求區分，並繪製了畫面流轉圖與DB設計圖等。
面臨的問題
・需求定義後的爭執
即使稱之為開發團隊，實際上也是由實行委員會招募的有志學生組成，對於系統功能的發言權並不多。其他役員傳來的需求通常都是較為模糊的，而其中多為技術上難以實現的，因此很難向他們傳達這樣的現實，最終決定功能的仍是開發團隊之外的其他役員，因此造成了意見分歧與不滿，讓我在實現代碼方面面臨了相當大的壓力。這樣的情況持續到比賽前兩周，因此在正式比賽前一天仍在進行單元測試。
・解釋無法實現原因困難
周圍沒有具備相應知識的人，即使解釋為何無法實現某功能，對方也難以理解。由於缺乏與役員進行會談的機會，無法詳細解釋也是造成困難的一個原因。
・謎樣的約束
針對實現功能的約束中，有幾個無法理解的內容。例如，關於使用者區別的問題：「因為不能使用Cookie，也不會通過NextAuth或Supabase Auth進行認證，所以這不可以，但使用localstorage卻沒有問題」這樣的情況。
3）運營方面
如第二部分所述，實際上開發並未如想象進行，因此在運營各方面也遭遇許多困難。特別是開發延遲，造成其他學生和一般來賓的資訊已無法及時傳遞。
所做的工作
・減輕學生的負擔
每一班級都有負責運營班級活動的學生，而這些人也需要進行整理券的管理。因此，我製作了學生用的管理界面，讓對IT不熟悉的學生也能輕鬆操作。
・金錢面管理則交由老師負責
由於涉及商業用途，Vercel和Supabase都必須使用付費計劃。這會需要信用卡，未成年人無法自行管理，因此Payments和預算的獲得交給了負責的老師處理。
面臨的問題
・缺乏資訊共享
需求在確保學生的操作方法及向老師的請託中，但我在實現系統時，其他成員和役員卻幾乎未進行此類工作，結果於當日資訊共享不充分，造成當日的混亂。有來賓因為不知系統的存在而無法參加班級活動的情況，實際上也發生過。
・學生和來賓上圍操作系統的能力低於預期
儘管我希望以普通應用程序的操作感來進行設計，但實際上UI/UX方面有些不便之處。我認為這是我設計得不夠好。這次我將其設計為PWA可以安裝，但因為不清楚安裝方法而無法使用通知功能的人也不少，這讓我感到有些可惜。
總結
總的來說，普通科的高中中缺乏能進行程式設計的人，因此要在這種情況下製作出一定程度的系統，很重要的一點是如何將除編碼以外的部分交給其他學生負責。這次在任務分配上雖然做得不錯，但在隨後未考慮整體的情況下，僅僅在功能實現上加快進度是比較大的原因。我再次感受到，向掌握知識的人進行解釋的確是相當困難的。
不過，在學校這一特殊環境中進行開發，似乎有著與個人開發不同的有趣之處，因此我也想利用今年的反思，在明年進行更多的開發。
原文出處：https://qiita.com/OtakuMoyashi/items/1c1ae9507dcc75b057d2
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
