開発合宿でプロダクトを完成させるための5つの準備
こんにちは。オールアバウトの@naga1460です。
先日は1泊2日の開発合宿に参加してきました。
allabout-tech.hatenablog.com (合宿全体の様子は↑こちらの記事をご覧ください!)
合宿ではチームに分かれて開発を行ったのですが、私のチームでは最終的に2つのプロダクトを作り上げることができました。
2日間という短い時間でプロダクトをきちんと完成させるために必要な5つの準備を、今回は紹介したいと思います。
時系列に沿って説明していきます。
その1. 事前ブレストでアイディア収集〜合宿1ヶ月前〜
合宿の1ヶ月程前から、参加メンバー各個人が開発したいもの・アイディアを共有シートに書き出し始めました。
この時点ではチーム分けは行っておらず、完全に個人個人で自由なアイディアを書きました。 オールアバウトの既存プロダクトを改善する案から全く新規の案まで、50個以上の案が集まりました。
◎ここで沢山案を出すことで、その後のチーム分け・開発がスムーズに!
その2. キックオフでモチベーションを高める〜合宿2週間前〜
今回、開発合宿全体のキックオフを実施したことにより、参加メンバーのモチベーションが良い感じに高まりました。
ちなみにキックオフは合宿2週間前に行ったのですが、2週間というのは準備期間としても十分で、 かつ、ダレることなくモチベーションを維持できるようなちょうど良い長さでした。
キックオフでは、まずチーム分けの発表を行い、その後は早速各チームでの作業を行いました。
チーム分け発表
このチーム分けは、その1の事前ブレストを元に同じジャンルの希望者が同じチームになるよう、合宿運営側で決めたものです。 私はBOT系の開発希望で出していたので、同じくBOT希望者との2人チームとなりました。
◎ここでの盛り上がりがその後のモチベーションを左右!
チーム作業開始
チーム分け発表の後は、そのまま各チームでの作業を始めました。
私のチームはまずブレストを行い、作りたいBOTの案を出していきました。 事前ブレストの時点である程度案が出ていたので、チームでのブレストはとてもスムーズに進みました。
20分程度の話し合いの結果、最終的に下記の3つの案に固まりました。
◎チーム分け発表直後にすぐチーム作業を開始することでモチベーションを維持!
その3. 調査期間を設ける〜合宿2週間前〜
※ここからは私のチーム独自の動きとなります。
私のチームでは、キックオフ後〜合宿2週間前の期間には、キックオフで出した案それぞれの実現方法、実現可能性を分担して調査しました。
その結果、実際に開発するプロダクトは下記の2つに決定しました。
- CafeSnap LINE BOT
採用理由: - 自動勤怠通知Slack BOT
採用理由:- IOTと絡めた開発に挑戦したい。
- 席にいるかどうかは、イスに圧力センサーを置けば検出可能。
- 圧力センサーとサーバー間のやりとりにRaspberry Piを使えないかと勉強会に飛び込み参加してみたところ、割と簡単そう。
- サーバーでRaspberry Piから受信した情報を元に、席に座っていない人を特定し、Slackに通知すれば実現可能。
残りの案は、下記の通り没となりました。
- All About LINE BOT
没理由:
採用した2つのプロダクトはどちらも小規模な開発となるため、チームの1人が1つを別々に開発することにしました。
◎調査期間を設けることで、納得のいく取捨選択を!
その4. プロダクトに必須なものを揃える〜合宿1週間前〜
合宿1週間前には、それぞれのプロダクト固有で必要となるものを準備しました。 全て「これがないとプロダクト開発は不可能」というものなので、プロダクト採用が決まってからすぐに準備に取り掛かりました。
圧力センサー+Raspberry Pi(自動勤怠通知Slack BOT)
- イスに圧力センサーを仕込んで在席確認を行うため、圧力センサーの用意とRaspberry Pi連携テスト。
- ※ここで「圧力センサーは壊れやすい」ということも判明。
- イスに圧力センサーを仕込んで在席確認を行うため、圧力センサーの用意とRaspberry Pi連携テスト。
◎プロダクト開発に必須なものは早めに揃えておく!
その5. 開発環境を整える(プロダクト共通)〜合宿1週間前〜
こちらもその4と同じく合宿1週間前ですが、開発環境の構築を行いました。 作るものによって用意するものは変わると思いますが、事前に準備することで合宿当日は開発に集中することができます。 私のチームでは次の環境を準備しました。
Webサーバーの用意・疎通確認
- どちらのプロダクトも外部から通信可能なWebサーバーが必要なため、GCE上にチーム共有のインスタンスを立ててWebサーバとした。
リポジトリ作成・疎通確認
- GCP→Bitbucketのpushテストも含む。
これらは普段やらない作業なので、やり方を思い出しながらやると思いの外時間がかかりました。。
◎念入りに準備し、開発の障壁を減らしておく!
そして、開発合宿当日。。
準備万端で開発合宿当日を迎えたため、当日の開発はとてもスムーズに進みました。
- 1日目
- メイン機能をほぼ完成させる。
- 2日目
- 仕上げの調整に徹する。
このようなスケジュールで、最終的にCafeSnap LINE BOT、自動勤怠通知Slack BOTどちらも完成させることができました。
開発を振り返ってみて
今回の開発を振り返り、良かったこと、悪かったことをまとめました。
良かったこと
キックオフでモチベーションが上がった
キックオフでモチベーションが上がったおかげで、最後まで開発をやりきることができました。
キックオフは実施して本当に良かったです。
事前準備のおかげで開発に集中できた
事前に環境構築や疎通確認等の準備を念入りすぎるほど行っておいたおかげで、 合宿当日はメインの開発にじっくり取り組むことができました。
これなくしては2日間でプロダクト完成まで漕ぎ着けられませんでした。
1人でプロダクトを1から作って完成させた達成感
普段の業務は既存プロダクトの改修案件が多いですし、新規プロダクトの開発だとしても複数人で開発することがほとんどなので、 1人でプロダクトを完成させる経験のできる機会は多くありません。
ですが今回の私のチームでは1人1プロダクトを開発したため、 自分の力で1つのプロダクトを完成させられた、という大きな達成感が得られました。
悪かったこと
チームでサーバーを共有することによる弊害
チームで同じサーバーを使用していると、他メンバーによるライブラリインストール等の影響を受けてしまい、思わぬところで時間を取られてしまうこともあります。
よくよく考えれば、プロダクトによって必要な環境、ライブラリも違うため、サーバーはチームごとではなく、プロダクトごとに構築しておくべきだったと思いました。
サーバーへのライブラリインストールに手こずる
CafeSnap LINE BOTの開発の途中で、画像に文字入れをする際の文字サイズ指定等のために、特定のライブラリをサーバーにインストールする必要があることが発覚しました。
色々試したのですが、上手くインストールできず、、、最終的には時間の関係で諦めました。
無駄な時間を使うことになってしまったため、サーバーにインストールする系のライブラリ辺りは事前に準備しておけば良かったです。
GCP設定周りがインフラ担当者任せ
インフラ担当者の方が慣れている、会社のアカウントで合宿用のサーバーを管理する、 等の理由から、GCPの設定周りはインフラ担当者任せとなってしまっていました。
これにより、サーバートラブル時に毎回インフラ担当者に聞く、 という手間が発生してしまったため、その辺りも含めて自分のチームで準備しておいた方が、 開発がよりスムーズになっていたと思います。
最後に
このようにして、私のチームでは無事2つのプロダクトを完成させることができました。
せっかくのチームなのにバラバラに開発するのはもったいないのでは?という意見もあるかもしれませんが、 仕様を一緒に考えたり、実装で詰まった部分の相談、息抜きの雑談等、チームを組む事によるメリットは大いにあったと思います。
ただ、また開発合宿をするとしたら、次はチームで1つのプロダクトを協力して開発したいです。
※今回LINE BOT開発でリッチメッセージ送信について知見を得られたので、サンプルコードと合わせてQiitaに投稿しました。 是非参考にしてください! qiita.com