BATONリリースで得たサイドプロジェクト開発における勘所
先日BATONというサービスをリリースしました。
piconは普段はiOSアプリの開発をメインでやっています。
そのためWeb経験が少ない2人での開発でした。
そんな中で、 なんとか1ヶ月弱でのリリースを実現出来ました。
今回の記事では、BATONのプロジェクトでの学びをKPT形式で共有したいと思います。
BATONは週末ハッカソン発の サイトプロジェクトとして開発 をしていました。
社内で新規事業を考えている、非エンジニアの人も参考になる内容 になってると思うので、ぜひ読んでみてください。
【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介 | SELECK [セレック]
Keep
新技術を導入する際に経験者に手伝ってもらうのがよかった
新技術を軌道にのせる部分を初学者がやると、設計的にもスピード的にも悲惨なことになりがちだと思います。
今回はJavaScriptすら本格的に開発したことない中で、Reactを採用しました。
そのためReactでの開発経験のあるkotaroさんに、週末開発的な感じで立ち上げに入ってもらい、基本的な作法や技術選定などをリードしていってもらいました。
学習効率を最大化するためにも、長期的な開発速度を維持するためにも、経験者の方に立ち上げを手伝ってもらうのは、本当によかった と思っています。
新技術と使い慣れた技術の選定のバランスがよかった
今回の開発では、スピードは保ちつつも、開発力をアップするための学習も出来ました。
Webクライアントでは、Reactという新技術を使いつつ、そのほかの部分（API / インフラなど）では、徹底して既に経験のある技術を採用しました。
学習と開発スピードのトレードオフの中で、どういうバランスをとっていくのか大事な課題だと思うので、今後も向き合っていきたいと思います。
Problem
開発期間の見積もりが甘かった
当初は１週間程度でのリリースを予定していましたが、実際３週間ほどかかりました。
メイン事業へのリソースを投下できなくなってしまう
BATONはあくまでサイドプロジェクトでした。
なので メイン事業への開発リソースが最優先であるべき なので、リリースが想定よりも伸びたときにメイン事業の進捗に影響が出てしまうケースも考えられました。
リリースが伸びた時の対応を考えておくべきでした。
フロントエンジニアとのコラボレーションが改善の余地がありそう
PMでデザイナーのしょせまるに、デザインとフロントエンド(HTML/CSS)開発をしてもらいました。
HTML/CSSを書いてもらって、それをReactに移行するという形をとっていてたのですが、移行コストが無駄にかかっている感じがありました。
バグをリリース前に発見できなかった
リリース直後、Twitter認証が一部端末でうまく行かないバグが発生しました。
Try
新技術を利用した開発の見積もりは少し多めにとる
爆速開発は、バグとかよくあるミスとか、落とし穴に落ちて這いつくばりながら上がってきて、の繰り返しの土台の上で初めて実現するのであって、簡単に新技術で実現出来るわけじゃないことを痛感した。
— 渋谷幸人 | picon inc. (@yukitoto__) 2018年6月8日
このツイートの通り、どの技術にも落とし穴がたくさんあることを実感しました...
そしてその落とし穴に見事にハマっていきました。（この経験が自分を強くすると信じてます...）
今後は、特に 新技術を採用する際はバッファーを多めにとった見積もり をしたいと思います。
リリースが遅れたときは投下するリソースを制限するようにする
今回は、BATON開発中のタイミングでは、メイン事業での開発タスクが多くなかったので実際には問題はありませんでした。
ただ、サイドプロジェクトに追われてメイン事業の進捗が遅れてしまったら元も子もないです。
もし期限が伸びてしまった場合は、週にx日しかサイドプロジェクトの開発に割かない、というような規約を決めておくといいかなと思いました。
もしくは場合によっては、開発を保留にしておいて手が空いたらやる、ぐらいの判断でもいいかもしれません。
周辺領域の知識を身につけた上で開発をする
今回のケースだとフロントエンジニアにReactについて少し学習してもらえれば、直接Reactでフロントを開発できるようになっていたと思います。
そうしていれば移行作業がなくなるだけではなく、CSSをコンポーネントごとに書くこともできました。
以後は領域をまたぐ際の連携が発生する際には、学習コストを掛けてでも全体の開発効率化を図る選択肢を持っておこうと思います。
QAタイムを導入する
今回はしょせまるがサービスのチェックをする片手間で一人QAを担当していました。
それだと頻度の低いバグや分かりづらいバグを発見できない可能性がありますし、実際に認証という致命的なところで一部端末でバグが発生してしまいました。（遭遇された方、本当に申し訳ないです...）
以後は、 リリース前にQAタイム を導入したいと思います。
社員全員のみならず、バイトなどで人数を補填して、一気にバグをハントする時間を取ることでバグを事前に発見したいと思います。
まとめ
今回のBATONプロジェクトはエンジニアの開発力アップという面でも、piconとしての打ち手の選択肢を増やすことが出来たという面でも、いい挑戦だったと思っています。
この学びをメインの事業にも反映しつつ、これからも開発を進めていきます。
piconでは、一緒にプロダクトを作っていく エンジニア（特にiOS, Android）を 全力で募集しています。
少しでも興味ある方は、ぜひ気軽にDMください！
まずは週末コミットやハッカソンのみの参加でも歓迎です。
↓ 連絡はこちら
