プライベートでのチーム開発をやってみたので振り返ってみる
こちらの記事はTCU-CTRL場外乱闘AdventCalenderの12月23日の記事です。
前回の記事はベイリーフさんの「TCU-CTRL場外乱闘 Advent Calendar 2023 総集編」でした。
missile-launcher.hatenablog.jp
流石の文章力で圧巻の感想記事でした。毎年（アドカレがある年は）楽しみにさせてもらってます。
TRPGに関する記事も書かれているようなのですが、時間が取れなかったので、後でじっくり読ませていただきますね。
はじめに
この記事を読んでいる方の中でプライベートでのチーム開発をやってみたいけど中々手を出せないと考えている人はいますか？
既に何かしらの技術コミュニティに属している方であればそういった経験がある人もいらっしゃるかもしれません。ただ、仕事でのチーム開発経験はあるもののプライベートとなるとやったことがないという人はぼちぼちいるのではないでしょうか。
かくいう私も、これまでは仕事以外でのチーム開発の経験がほぼありませんでした。そんな私でもふとした機会を得られまして、現在進行形でチームでの開発を進めています（何とか進められています）。
中間報告というほど進んではいないのですが、そのチーム開発におけるこれまでの過程を文字に残すことで、プライベートでチーム開発をやってみたいが尻込みしている人の後押しができるのではと考えました。
仕事と同じでは？と思う人もいらっしゃるかもしれませんが、仕事とはまた違う気の使い所があったりするので、そういった点についても本記事内で触れていきます。
私たちはSNSを作っています
まず作っているものの紹介をさせてください。
私たちは今ActivityPubという分散SNS規格に対応したSNSの開発を進めています。
ActivityPubという規格に則ることで他SNS（misskeyやmastodonなど）との連携も可能にする予定です。
Githubでのrepositoryはこちら
少し前の某SNSのAPI制限騒動は記憶に新しいと思いますが、その時に自分たちでSNS作っちゃえば何かと融通効くし面白そうじゃね！？とノリで思いついたのが発端となり、今に至ります。
---
具体的な言及はこれくらいにしておきます。本記事はあくまでも経験、開発プロセスに焦点を当てた内容となりますので、もう少し詳しく聞きたいという方がいらっしゃいましたら直接ご連絡くださいませ。
プロジェクトメンバーを紹介するぜ！
次にこのSNS開発に携わっているメンバーの構成を紹介します。
現状稼働の少ないメンバーも合わせて8人という数値で見ると中々の大所帯で開発を進めています。
人数比でいうとフロントエンド3人、バックエンドが5人。学生と社会人が半々といった具合になっており（多分このアドカレでは説明不要かもだが）、某大学のサークルOBで集まっています。
担当箇所の技術に触れたことのない人、はたまた既に会社でリードしていらっしゃる人など改めて文字に起こしてみると意外と多様性に富んでいるようですね。
使用ツール
メインで使っているツール類についても紹介します。今プライベートでチーム開発をやろうとしたらおそらく同じような構成になり得ると思いますが、一応紹介しておきます。
Discord
メインの連絡ツールです。Slackと違い、（今のところは）チャット履歴が消えることはないため採用しました。
Scrapbox
カジュアルなドキュメントの保管場所として利用しています。（fixした設計資料についてはgithubの方に移していく予定）
Markdownに似た文法で編集でき、複数人の同時編集に対応していてとても便利に使わせていただいています。
商用利用でなければ、人数無制限無料で使えるのもいい点ですね。
Github
これがないと何も始まらないですね、本プロジェクトでもコード管理に使用しています。
当初はprivate repositoryにして開発を進めようと考えていましたが、無料プランだと制約が多すぎたためすぐにpublic repositoryへ変更しました。
コード管理だけでなく、Task管理でgithub projectを使用しています。そこまで機能は多くないのですが、軽くカンバン的な運用をするのであればこれで十分だと思います。
Figma
ワイヤーフレームを作成するために使用しました。 私はほとんど触っていないので、今でも使いこなせていません。
Miro
ホワイトボードツールです。図に起こして情報共有したい場合に利用しています。エンジニア御用達のdraw.ioなども考えたのですが、複数人での共有時に難があったため不採用としました。
VSCode
一応推奨エディタとして指定しています。
設定ファイルをgitで管理でき、個人間で環境差が生じにくいため、一応推奨エディタとしています。（と言いながら自分はjetBrains系のエディタを使ってる）
具体的にどう進めてきたのか
前述したツールを駆使して、私たちがどのように開発を進めて来たのかということをここでは紹介します。
1. メンバー集め
たまたまサークルOBが集まるイベントがありまして、その場でこういうの作りたいよね〜という話をしたら意外とやりたいという人が多かったので、ノリで始まりました。
あとは某SNSでメンバー募集している旨をボソッと呟いたところ、数人が反応を見せたので、直接連絡してその人達にも参画してもらいました。
この時思ったのですが（前から思ってたかも）、みんな声に出さないだけで、チーム開発をやりたいと思っている人は多いです。最初の旗振りだけでもやれば、意外とスムーズに事が進む気がします。
2. 作るものを決める
これは最初に決めるべきかも？というのが自分の考えではあります。
詳細は後から考えればいいのですが、これを作りたい！というものは用意してから人を集めた方がいい気はします。（個人の意見です）
なぜなら、作るものに対してモチベがないと作り切るのが難しいからです。実際、自分も人を集めてから作るものを考える事があったのですが、作るものに対するモチベがあまりにも沸かずそのままプロジェクト自体蒸発したこともありました。
ただ、場合によってはこういう技術を使って何かを作りたい！という技術ベースのモチベがあることもあり、一概には言えないかもしれません。
3. 設計
最初は要件定義から始めましたが、プライベートだからこそどう進めるか悩みました。
要件などきっちり決めなくとも、プライベートだと自分たちの塩梅で自由に進められます。ただ、そうしてしまうと軸がなく、エンジニアの俺が考えた最強のSNS（機能モリモリ、今の某SNS）となり、本来作りたかったものが作れなくなるというリスクもあります。
結局、要求整理の段階では、SNS上でアンケートなども行い、以下のような形でキャッチコピーをまとめるところをゴールとして進めました。
Stlaticaは、既存のコミュニティにおける活動をさらに活発にすることを目的とした分散型SNSです。アナウンスやイベント管理などの機能を提供し、コミュニティ内での情報共有や活動への参加をより手軽にします。またActivityPubを採用しているため、複数のコミュニティ間での柔軟な連携も実現できます。仲間との絆を深め、効率的なコミュニケーションを追求しましょう！
この要求を元にした機能整理などについてはScrapbox上で行いました。
正直いうとここはもう少し簡略化しても良かったかも？とは思いました。メンバーの中でも飽きがきている事が伝わってきましたし、ただここを疎かにするとそれはそれで瓦解するリスクもあり、難しいですね。
要件定義のあとは設計ですが、フロントエンドについてはFigma上、バックエンドについてはAPI定義についてはopenapi、それ以外はScrapbox上にまとめる形で進めています。（まだ終わってない）
実装
taskについては基本的にgithubのissueに切っているので、各々にissueを割り振り、黙々と進めていただいています。
レビューフローについてもドキュメントに明記して、それにしたがってレビューを回す形にしています。（ここだけでも1記事くらいにはなりそうなので、後から別記事で出してもいいかも）
ここまでしか進んでいないので、これまでの過程は以上となります。
もう少し実装が進んできた段階でテスト環境の整備だったり、リリースに向けた準備などもしていきたいですね。
プライベート独特な気の使い所/取り組み
全てが実践できているとはとても言えませんが、気にはかけながら進めていきたいと考えていること、やってきた取り組みについて解説します。
とにかく気長に進める
これが一番大事かもしれないです。フルタイム感覚で見積もるとあまりの進捗の進まなさでモチベが一瞬で消え去ります。
特に社会人の平日稼働はほぼ難しいと思った方がいいです。休日に稼働するとしても土日まるまる確保するのは難しいので、1週間合計で5時間稼働が取れたらいい方、0でもおかしくないくらいの気持ちでいた方がいいです。
5時間 × 4週 = 20時間
と考えると、1ヶ月あたり安定して稼働できるのはmaxでも20時間くらいとなってしまい、かなり少ないです。
やることは小さなissue単位で明確にして渡す
場合によるかもしれませんが、学生がメンバーにいるとマイルストーン単位でタスクを渡すとスムーズに進めてもらうのはなかなか難しいです。どう進めればいいのかが分からず呆然としてしまうかもしれません。後半の方ではマイルストーンでいいとしても最初の方はissueをちゃんと切って渡しましょう。（書いてて思いましたが、別に学生に限った話ではないですね）
社会人は前述したようにそもそも稼働時間が確保しずらいです。少しでも隙間時間で進めやすくするために小さなissue単位で渡すことで負担を減らすことができます。
また、繁忙期などで稼働できなくなることもあるかもしれません。そういった場合にその人がマイルストーンでタスクを持っていた場合、他の人の作業のブロッカーになりかねません。そういった稼働不可になる事態だったり、メンバーが蒸発する事態に対処するため、プライベートだからこそ小さなissue単位で渡すというのが大事になってくると思っています。
講習会をやる
仕事と違って技術スタックが大きく異なることがあります。少しでもその差を減らせるよういくつかの講習などを行いました。
前提の技術スタックが揃っていないところから始めないといけないというのもプライベートならではの難しさですよね（違うか）
定期的に話す機会を設ける
不要なmtgは減らすべきだ！と声を高らかにして言いたいですが、プライベートだとそうもいきません。サボりたいだけサボれるので、最低限、進捗を確認する機会がないとズルズルと先延ばしになってしまいます。
Let's 定例駆動開発！
最後に
最後まで読んでいただきありがとうございました。
これまでの経験を淡々と語りましたが、これはあくまでも自分の経験であり、ベストプラクティスなどではないことをご理解ください。それでもプライベートでのチーム開発に尻込みしている方の背中を少しでも押せたら幸いです。
突貫で書いたこともあり、言葉足らずな箇所が多々あるかと思われます。加筆修正版をどこかでまた出すかもしれません。少なくともSNSが完成した暁には再度記事として残す予定です。
それでは ﾉｼ
---
次の記事では、クロメガさんがSEを辞める（辞めた？）ことについて話してくれるようです。転職話は他人事ではないのでどのような内容なのか楽しみです。
