念願だった「会社外での個人開発チーム」を立ち上げ、第一弾のサービスを世の中に解き放つことができました！！
自分で作ったサービスを公開して、誰かの手助けになる、世の中に貢献するって、エンジニアが誰しも持つ夢ですよね？！
僕もそういった夢を持つ、エンジニアです。
今回その夢を実現しました！自分でチームメンバーを集め、組織を作って、サービスをみんなで作ってリリースしました！！本当に最高でした！
今後もこのチームで継続してサービスをリリースして、みんなで事業を作っていこうと思っています。
その話をつらつら書いていこうと思います！！
作ったサービス
こんなアプリを作りました！！
PDFをセットすると、スライド形式で発表ができて、スライドに聴講者からのコメントをリアルタイムで流し、LTがより双方向になる楽しいサービスです！！
開発メンバーの関連記事
最初にメンバーが書いてくれた記事を貼っておきます！！
開発を持続可能にするには
さて、まずは開発の持続可能性について書いていきます。
最初は、ItsukiN32さんと二人で始めた感じで、ItsukiN32さんの記事でも触れているように、開発序盤は、開発速度の減少傾向が見られました。
有名な記事かもしれませんが、↓この記事にも挫折の大きな要因として「モチベーションが続かない」ことについて触れています。
これはいざ実践してみるとその難しさをコッテリと実感させられました。
しかし、結果的にはこれは新しいメンバーtakusan64さんの参加によって回避することができたのです！
ではtakusan64さんはどうやってスムーズに開発メンバーに加わることができたのか？
それを可能にしたのが立ち上げ期の土台作りだったと思います。
ここでは、立ち上げ期に考えたことについて、プロダクト開発チームを作りたい皆様にお役に立てる情報があるかもしれないので、少し自分の考えたことを書いていきます。
種々のツール選定やチームづくり
チームを立ち上げるときに自分が一番懸念していたことが以下でした。
- あまり何も決めずに進めてグダって何も作れずチーム内の雰囲気が悪くなって仲違いしてせっかく仲がよかったのに気まずくなる
これを一番恐れていたし、嫌だなーと思っていことでした。
じゃーどうすりゃいいのか、と考えて出した結論が以下でした。
- ハッタリでも形だけでもいいから完成したアプリケーションを作り上げる
- 業務外であっても、開発組織づくりにはこだわって本気度合いを演出し、メンバーのモチベーションを高める
ハッタリでも形だけでもいいからすごくちゃんとしてそうな開発組織づくりをしてチームとしての真っ当感を出そう！！
これまでの自分の生き方そのものを現すような感じなので、僕のことを知っている人は笑ってしまうと思うのですが、業務外とはいえ、大真面目にビジネスを作るつもりで本気でチームの土台を整えることをまずやりました。
そのおかげで、今後も事業継続していこうというモチベーションが維持できています！！
途中加入してくれたtakusan64さんもこれが大きかったと言ってくれました！！
以下は利用したツールを記載していきます。
チャットツール
......
まあ、現状ならslackの無料版一択やな！！
Slackで確定しました。
コード管理
GitHub！！！
SlackにGitHub用のチャンネルを作り、GitHubと連携して、そこにコミットやGitHub上のメンションなどが流れてくるように設定して、全員がやり取りを見やすいように工夫しました。
タスク管理
チーム開発なので、まずはタスク管理をどうするか決めいないといけませんでした。
現代において、プロジェクトのタスク管理ツールなんて山ほどある中で何がベスプラやねん。。。いきなり悩みます。
notion、asana、バックログなどなど。
「何がいいと思います？？」
「お金かからない方がいいすよね」
「ガントで管理するほど人数もいないっすよね」
「ツールはあんまり分散したくないっすよね。一つのところである程度管理したいっす」
.......
「GitHubのプロジェクト機能」を使いました！！
POがタスク起票して上から順番にタスクを拾っていくシンプルなスタイルで運用してうまくいきました。
無料だし、カンバン管理で優先順位も上から順に並んでいて明確だし、ステータスの管理も見やすいし、 GitHubで一元管理できるし。非常によかったです。
Wiki管理どうする？？
知見も貯めたいし、できる限りコミミュニケーションロスをなくすために、ドキュメントの管理はちゃんとしたいなと思っていました。
esa,kibera,notionなどなど。
「何がいいと思います？？」
「お金かからない方がいいすよね」
....
以下同文
GitHubのwikiでいいんじゃないですか？？
「あ、俺GitHubのプロアカウントだからwiki使えるわー」
GitHubのWikiで確定しました。
インフラ
- できるだけお金かけない方が長続きするだろうなー
- サーバーの管理はできるだけしたくないなー
- 費用もできるだけ抑えたいなー
そういったことはぼんやり頭にありました。
サーバレス構成(AmplifyとかFirebase)で行こうと決めました！
最初のサービスはAmplify (ストレージは S3 と DBは DynamoDB) で作りました。
チームの開発方針やマインドマップやMVVもどきのようなものも作りました
ちゃんとしてる感を出すために、ドキュメントにチームの開発方針や、マインドマップ的なものやMVVみたいなものを整備しました。
最初誘ったチームメンバーも若干ガチすぎて引いてたと思いますが、結束的なものは固まった？？かなと思います！！
一部はこんな感じです。
そんなこんなで、ちゃんとしたことにより、新しく誘ったメンバーも信頼感を持ちやすかったりするのかなーと思いました！！
継続してサービスを作っていくためのAWSの運用
AWS organizationsを使って、組織を作成しました！
- 最初のプロジェクト(slide_commenter)は管理アカウントで作成。
- それ以降で新たにサービスを作るときは「AWSアカウントの追加」からプロジェクトを作っていく
- budgetは管理アカウント内に各プロジェクトのものを作成していき各プロジェクトごとに予算管理もできる
- 予算の全体額は管理アカウント内で一括請求ができる
この運用により、AWSでサービスを継続して開発していく際に非常にやりやすい環境になったと思います。
デザインできる人の必要性
いやー、本当にデザインできるtakusan64さんの加入はデカかった。
ありがちなのが、エンジニアでチームづくりをするときに、デザインとか見た目が壊滅になるという。。。最初は、バーっと適当に作り始めていて、「このままVuetifyのデフォルトのやつでリリースしたろか！！」みたいなやばい発想になってました。。笑
「優秀なエンジニアでありながら、優秀なデザイナーである。」
これがデザインエンジニアってやつなんですね。
SRE的な、システムの設計/運用やソースコードの設計などを担保してくれるフルスタックな強い人の必要性
技術的に信頼度の高い、本業でご一緒している経験年数の長いエンジニアの方の加入により、開発していく上での安心感も非常にデカかったです。
開発経験の浅いエンジニアのチームだったので、壁打ち相手がいるのは非常に大きいですね。ありがとうございます。
開発した時に意識したこと
自分は主に、以下のことをやりました。
- AWS Organizationsを設定してAWSアカウントの一元管理や請求一括化などを設定して今後も継続して新たなサービスを継続リリースできる体制づくり
- AWS破産しないように予算アラートなどの設定
- AmplifyのGraphQL設定周りやCI/CD周りとかドメイン管理とかのインフラ周り
- Nuxt.jsでプロジェクト作成する際の初期構築
- デザインを見てhtmlやcssを当てていくマークアップ的な作業
- PDFのスライドセット周りや主要コンポーネントの作成・繋ぎ込みまわりをNuxt.jsで書く
開発は普通にしつつも、自分が始めようと号令をかけて仲間も集めたこともあって、お見合いになりそうな、溢れタスクを拾うことを意識しました。
ItsukiN32さんの記事にもあるのですが、みんな本業が忙しい中やっているので、コミットの時間が空いたときに、タスクのキャッチアップコストが上がったり、入っていきずらくなったりすると思うので、そこをできるだけ、フォローできればなーとマインド面をケアできるように動いていました！
今思えば、そうした立ち振る舞いがチームのモチベーションの維持に大きな影響を与えたのかもしれません。
技術的な詳しい内容は、別記事で個別に書けそうであれば書きたいと思いますが、ここではこれ以上書きません！
今回は以上です！！！