「プライベートで開発しようよ！」
会社の同僚やエンジニア仲間で話をしていると、「今度、誰々とアプリを作ろうと思っている」、「今ある計画が動いている」 なんて話をよく耳にします。
しかし、半年後ぐらいに今どうなっているの？と聞いてみると、ホスティングされている開発途中の成果物がみることができれば良い方で、大体頓挫しているような気がします。
どんなクオリティのものであれ、とりあえずリリースまで漕ぎ着けるというのはかなり珍しいケースでしょう。
なので、プライベート開発で形にしている人というのはそれだけで素晴らしいのだと。
偉いのだと。
というわけで、↓ こういうものを作りました
こちらは、スライドについてコメントが飛ばせるというアプリです！
今回は、チーム開発でアプリを作ったけど、それをどうやって形にしたかと、それをやり切るための難しさみたいなものを振り返りたいと思います。
はじまり
ある日、メンターであるDさんと雑談をしている中で、こんな話をしていました。
me
「全然関係ないんですけど、何かプライベートで作ってみたいサービスとかってあります？」
Dさん
「ありますあります。〇〇なサービスが作ってみたいです。絶対需要あると思うんですよね」
me
「いいですねー、私も××なサービスを作ってみたいって構想があったりします」
Dさん
「いいですねー」
me
「いいですねー」
Dさん
「...」
me
「...」
Dさん
「なんかこう、勉強がてら一緒に作ってみたりします？」
me
「やっちゃいますか」
そんな流れで、とりあえず作るかも？という雰囲気が発生し、ふわっとするのかなと思いきや、
Dさんの抜群のブルドーザのような突進力であれよあれよと進んでいきました。
DさんはAWSのIAMや、Githubのレポジトリ、プロジェクトの管理方法の準備、ドキュメントの整備などを進め、
プライベート開発に興味がありそうな人に声をかけ、気がついたら5人で構成されたチームができあがっていました。
まるでキューピー3分クッキングをみているような感覚でした。
何を作るの？
チームができたものの、何を作るかまでは決まっていませんでした。
そこで、ひとまずは簡単そうでチーム開発の練習になりそうだということで、メンバーの Hさん が温めていた、 『スライド形式で発表する際に、聴講者からのコメントをリアルタイムで流せるサービス』 を作ってみることにしました。
それが冒頭にある SlideCommenter です。
私が触ってみたいという要求から、 技術スタックとして AmplifyCLI が採用されました。
動き出し
案は決まったのですが、最初の create nuxt-app から誰も手をつけない、残った最後のケーキの一切れをみんなでにらめっこしているような状態が少し続きました。
私は、 Amplify を触ってみたいという意欲がかなり強かったので、とりあえず下地でもつくるかということで、Amplify Backend の基礎となる部分を作りました。
その頃はデザインもなにも決まっていなかったのですが、今回のアプリはそんなに複雑なことはしていないので、必要そうな最低限のバックエンドとフロント部分を作りました。
（多分使い慣れている人だったら一瞬でできる内容です笑 知識がほぼ0からやると結構時間がかかるんですよね...笑)
全然関係ないですが、 Amplify CLI のこれさえあればなんでも作れる感に感動して、Amplify のドキュメントをずっと眺めていました。
最新のドキュメントと古いドキュメントがあって、古いドキュメントの方にしか書かれていない使い方があったり、Amplifyのバージョンが違うと挙動がかなり変わったりするのでハマりました笑
減速
そんな流れで最初の方はガシガシ作ることができていました。
しかし、 Amplify が関係する部分を一通り終えて、基本的な仕組みを作った後から 開発にエネルギーがいるかも... と感じ始めていました。
元々は一人で全部作り切っちゃおうぐらいの気持ちでした。
ただ、開発をしてみてわかったのですが、Amplify には強い興味があっても、Nuxt.js にはあまり興味を持てなかったのでした。
元々 Next.js は触っていたので、同じようなことをするだけだと思っていたのですが、
私にとっては、同じようなことをもう一度調べ直すような感覚に陥り、心理的な学習コストが高く感じてしまっていました。
また、ちょうどその頃から仕事が忙しくなり、心理的な余裕がなくなってきたのも大きな原因の一つでした。
こうして、プロジェクトの開発速度が減速しはじめたのでした。
どうなってしまうのか！?
開発がぬるっとはじまって、そのままぬるっと進んでいくかのように見えたのですが、実際に開発してみて継続させるのは難しい思いました。
なんなら、この頃はアプリ完成しないかもなぁ...と、うっすら不安に思っていました。
「どうなってしまうのか?!」と書いてはいますが、結果的にアプリは形になってます笑
端的に言えば、メンバーの Dさんが 色々調整していただいたおかげで、新しいメンバーYさんを誘い、開発速度の維持を回復してくださりました。
この辺りのチームビルドについて 何を意識していたのか については Dさん の記事にて記載されています！
Yさんはプライベート開発には興味があるけど、個人開発ではモチベーションが続かないが、チーム開発だとモチベーションを維持できるというフロントエンドの方でした。
なので、 Yさんによって、私の食指が伸びなかった箇所を補ってくださったのでした！
自分に対する考察
興味があることに関しては、 やってみよう！ となりますが、そうでないことに関しては、とてもハードルが上がるのだなと思いました。
業務が終わって疲れている状態で、任意開発となるとなかなか取り組むのにもハードルが高いように思います。
また、これは私個人の感覚ですが、途中までコミットしていたのにコミット速度が遅くなるとどこか後ろめたい気がしてきて、それがモチベーションが下がって...のスパイラルを産むような気がします。
そういう意味で言うと、チーム開発より、個人開発の方がモチベーションは保ちやすいような気がします。
興味という点で言うと、元々私がバックエンドというのもあり、AWSと親和性が高い Amplify は馴染みがあったのですが、元々強い興味がない方にとっては Firebase の方が馴染みがあるようで、そういう面では他の人が触りにくい技術スタックを選んでしまったことも、チームとしての開発速度を遠回しに下げてしまったのかなと思います。
というわけで、今回の自分自身の開発速度の推移から、開発速度を下げないためには以下が必要なのではないかと思いました。
開発速度を下げないコツ
- 最小公倍数のみんなにとってハードルの低い技術スタックを選定する
- 各個人の興味の対象や有無を明確にする
- とにかくモチベーションに焦点を当てる
- メンバーを追加できる体制をつくる
まとめ
以上です！
このあたりはなんとなく事前に想像ができる点ではありますが、いざ経験してみるとその重要さが身に染みました。笑
この辺りの知見が誰かの役に立てば幸いです。
開発メンバー関連リンク
この経験について開発に携わったメンバーの記事へのリンクも貼っておきます！
それぞれの感じ方が異なっててなかなか面白いです笑
チームビルドをしたDさんの記事
https://qiita.com/Dai_Kentaro/items/2accfa8cc7d6bb4cda16
開発後半、主となって色々対応してくださった Yさんの記事
https://qiita.com/takusan64/items/1035ae5f0ac57cdf64bd