経緯と目的

（ややフェイクを入れています）

エンジニア見習いのチームで，学内のハッカソンへ出ることになりました．私自身，共同開発は，とくに初めてというわけではありませんでした．そのおかげでPMの立場を務めることになりました．なので，いかにストレスレスに作業を進められるかを考える必要がありました．

実務では様々な作業効率化があると思うのですが，今回は初心者なりに実運用できるレベルでの取り組みをまとめたいと思います．

なお，ここでいう初心者はプログラミング歴1~2年ほどを指すと思ってください．

大前提

これは以前の失敗談も含めての話ですが，共同開発が滞る主原因は「設計の甘さ」や付随する「見積もりの甘さ」によって発生するトラブルだと考えています．（私個人の意見ですので，ご意見・ご指摘歓迎します）

とくにハッカソンは短期間で行われることが多いので，事前に考えることは考えておくべきです．これは事前開発をしろ，というわけではなくて，事前にメンバーとの共通のビジョンを持つ，という至極当然の議論です．

例えば，
・どういう問題をサービスは解決できるのか？
・UI/UXはどうあるべきなのか
・他の類似サービスとの差別化はどうなっているのか？
などといった点です．

ビジョンを共有していないと，統一感を以って開発ができないので，「そこなんか違くない…？」という不満がそれぞれのメンバー同士で発生します．ツール云々は大事な話ですが，結局のところ開発を高速化するのは，このような人間間のトラブル（やその種）を取り除くことです．

とくに，プロダクトやサービスのユーザーの解像度を高く持つことは重要です．本当にユーザーが抱えている困難（ペイン）の解消に繋がっているのか，また（問題に対する）十分なソリューションになっているのか，を常に考え続けましょう．サービスにとって必要な物/不必要な物が分別できます．これは意識していないと，つい新しい技術であったり高度な技術を採用して，結局自己満的なプロダクト・サービスの開発に繋がります．当然，本人にとってすらいつか黒歴史になるので，誰にとっても嬉しくないものでしょう．もちろん，高度な技術を使わないといけないと解決できない問題もあります．ここは工数とのトレードオフになるので慎重に議論すべきです．

また，これはハッカソンのルールにもよるので一概には言えないのですが，ハッカソンに参加する前に少なくとも簡単なtodoアプリ程度でいいので作ってみましょう．とくにgit周りはトラブルが多いので，プラクティスを確立させるという意味でも重要です．

導入したもの

生成ＡＩ系

大前提として，ChatGPTまたはClaudeへの課金を強く推奨しました．これは疑問の解決にも使えるし，コードを書くのにも高速化できるからです．
また，全員学生なのでGithub Educationの恩恵としてGithub Copilotを導入しています．悔しい話ですが，メンバー全員がGPTよりも優れたコードを書けるかというと怪しかったので，GPT製のコードが乱立する場合もありました．その際は自分の学習できる範囲で学習して，きちんと理解してから次に進むように各々が心がけました．

Issue/PR Template Form

真っ先に用意したものです．IssueやPRには規約を設けましたが，それを徹底する責任をメンバーに持たせたくなかったので，Issue TemplateとPR Templateを用意しました．
とくに，TemplateよりもForm形式のほうになっているほうが開発体験はよかったと言われました．
詳しい記法は公式ドキュメントに譲るとして，簡単な紹介を．

Issueを作成しようとすると，次のようなForm形式が立ち上がります．これに従って入力するとMD形式でIssueが立ちます．
特にIssueとPRはメンバーが頻繁に触る部分だったので，導入ハードルとのコスパはとてもよかったです．10分ぐらいでできます．

Project機能

タスクなどを視覚的に見ることができます．これはメンバーというより，私自身が一番うれしかったものです．類似サービスはたくさんあると思うのですが，GitHub上で完結するのが嬉しかったです．

導入を悩んだ/悩んでるもの

PR agent

GPTなどの生成AIがコードレビューを自動でしてくれる，というものです．LayerXやメルカリで導入されているという記事を読んで，導入したいと思っているのですが検討段階に留まっています．
生成AIに任せることで，サポート的に使うのではなく，メンバー各々の意思決定がGPT任せになってしまうのが少し怖かったというのが本音です．（つまり，その指摘がどのぐらい妥当性を持っているのか正しく判断できないという問題です．）

似たような取り組みとして，純粋にChatGPTに自分のコードを10点満点で点数化してもらうということはしていました．ただし，自分たちでよく考えることを意識してしまいました．この部分は賛否両論あると思っていますが，結果的にある程度の可読性と保守性は意識されるべき＋初心者に詰め込み教育するのはよくない，という思いから検討に留まっている，という話です．

人的リソースによる部分

タスク割り振り

タスクの割り振りは基本的にGitHubのissue機能を利用しました．とくにラベル付けを行い，やるべきことが自然にわかることを常に心がけました．また，タスクの優先度や，タスクの順番（例えばAが終わらないとBに行けないなど）は，私が動的にPriorityのラベルを付け替えすることで対応しました．

しかし，基本的にはタスクは口頭で伝達することを心がけていました．AsIs-ToBe形式では伝えきれない細かいニュアンスの差異は，最初に述べたビジョンのズレに繋がります．きちんと伝えましょう．

レビューの工夫

実際にはほぼすべてのPRに対して，PMである私がコードレビューを行いました．とくに確認していたことは次の通りです．

Typescript側

仕様通りに動くか
型安全か，型の定義は自然か（created atにstringsなどはrejectしました）
デザインは自然か，とくに色味や必要に応じたアニメーションなどはいろいろ考えたりしました．

とくにフロントエンドはJestなどによる単体テストを実行するよりも，実際に動かしてみて入力やログを観察することを意識しました．

逆に私はバックエンド担当だったので，GPTにレビューを依頼することが多々ありました．これを自動化するという意味では，PR Agentを利用すべきだったかもしれません．ただ，とくにE2Eテストはもう少し機械的にやってもよかったと思っています．

反省

設計の不足

完全に私のミスですが，設計の見通しが甘く，機能要件追加や実装が間に合わない，という事案がありました．

これを防ぐために，先輩から頂いた言葉に，「技術的不確実性を想定すべき」というのがあります．この言葉に則れば，今回GCPやvectorDB周りが技術的なネックになってしまい，作業が硬直化したので気を付けるべきだと考えました．

とくにgo側のmodelやtypescript側のtypeの不足があり，ここはもう少し列挙して考えるべきだったと思います．

反省を踏まえると，設計レベルでの議論をもう少し挟むべきだったと思っています．サービス像についてのイメージはお互いにすり合わせていたのですが，相手方がバックエンドの知識がないことを理由にこのあたりを雑に流してしまいました．

また，アーテクチャ以外の部分，例えばデザイン面などは事前に協議をあまりせずに雰囲気で進めてしまっていました．もう少し正確なワイヤーフレームやデザインモックを見直すべきでした．

また，CD/CIプロセス，とくにCDをもう少し綿密に組み，デプロイ駆動で開発すべきだったと思います．

少し開発から話は逸れますが，発表の練習も十分時間を取るべきだと思います．

結び

ここまで読んで頂きありがとうございました．走り書きな分，粗雑なところもありますが，ぜひご意見コメントなどあればよろしくお願いします．