CBcloud Advent Calendar 2020 の 6 日目を担当します。
今年は個人的に 「PickGo 買い物」に携わった一年だったので、いろいろなこと振り返っていこうと思います。
ちなみに「PickGo 買い物」とは、今年の 4 月にローンチした プロのドライバーさんが買い物を代行してくれるサービス です。
只今（12月6日現在）キャンペーン中で、 3km 圏内の店舗での買い物が配送料 0 円になるので良かったら使ってみてください！
キャンペーン LP
https://pickgo.town/shopping/cp/freeshipping-202009/
開発フローの改善は早めにやったほうがよい
プロダクトとしてもチームとしても立ち上げたばかりだったため、当時は実装できたら誰かが確認してリリースみたいな流れで開発していました。
ただ不思議なものでシステムが複雑化していくと、ある時期を境に不具合が多発してしまうようになりました。
また、企画段階の施策が開発側に見えていないという問題もあり、急な変更や施策の意図、技術的な調査の先回りができないみたいなことも起きていました。
これらの問題を解決すべく現在は PBL の作成と開発タスクの見える化、開発フローの見直し、それらの定期的な振り返りに取り組んでいます。
使っているツールは Asana で PBL 用のリストと開発タスク用のボードをそれぞれ作って運用しています。以下の記事がすごくイメージに近いです。
https://qiita.com/xoyo24/items/246fa5e9ad5d01273b56
また必ず実機でテストするようにしているのですが PdM やデザイナーの方々もテストに参加してもらっています。
toC アプリなので操作性や UI/UX にはこだわってて、エンジニアが気づけない FB などが上がってきたときに非常にありがたさを感じています。
技術選定や設計の自由度高めだが影響範囲が広い
立ち上げ当初だと人数も少なく自動的に裁量権が大きくなり、技術選定や設計などはチームの少人数で決めることが多いです。
ここらへんを魅力に感じる人も多いと思いますが、当然ですが技術選定や設計ミスると技術負債として溜まっていきます。
実際にミスったなという選定はいくつかあって、施策が続くとなかなか改修できず放置状態が続きます。
技術負債を生み出さないためにやってることとしては他プロダクトでの設計や選定をパクるようにしています。
PickGo 買い物は社内でも一番若いプロダクトでありがたいことに他のプロダクトが踏んだ負債や成功と言えるような設計を参考にすることができます。
真似をすることで 去年のアドベントカレンダー（マイクロサービス化に踏み出せない人々の代わりに踏み出してみた）にも記されていますが、プロダクト間で同じような機能を持ってしまうというデメリットを認識しつつも、
設計や機能を拝借しながら開発が進められるのはスピードが求められる場面においてメリットに成り得ます。
真似ばかりじゃなく、社内で運用経験のない Elasticsearch や Flutter の導入など攻めた選定もやってきました。
来年は逆に他プロダクトへここらへんのノウハウを還元できる機会があればと思っています。
特に Flutter を採用することでモバイルエンジニアが 1 人という状況でも Android と iOS ユーザーに差分なく機能を提供できています。
この選定がなければ今のスピードを維持できていなかったと思います。
一方でエンジニア市場に Flutter エンジニアはまだまだ少なく、採用に困ってしまうことに後々気付かされました。
だからといって Flutter をやめることはないと思いますが、エンジニア採用にも影響を及ぼしてしまうので技術選定はやっぱり大切です。
アライアンスはチャンスだが運用保守に気をつける
※ 最初に言っておきますがアライアンスが悪いと言っているわけではなく、僕にとってアライアンスとは、他企業の他アプリと連携してお互いの課題解決になり得るチャンスと捉えています。
サービスを立ち上げるとありがたいことにいろいろな引き合いが存在し、中にはそれ専用の機能を開発するみたいなことも有りました。
そういった開発を行っていく上で既存ドメインを汚さないようにと意識はしつつも、修正しづらいコードになってしまうみたいなケースが多少生じてきました。
先輩エンジニアに教えてもらった DDD の腐敗防止層の考え方が直接の解決策となりえそうなので改めて勉強してみようと思います。
また連携における運用にも注意が必要です。
機能拡充やデータ連携のやり方はどちらがどの部分を担当するかなど手順や仕組み化を見越したルールを作っておかないと、こちらの作業工数を大幅に使ってしまう羽目になります。
ここらへんの取り決めは営業さんと通して行うことが多いと思うので相談して進められる関係性を構築するのも大切です。
ドラスティックな変更を恐れない
個人的に今までにプロダクトの立ち上げをやったことがなく、またスタートアップという環境もあってか急な方針変更やドラスティックな改善をこれまでに経験したことがありませんでした。
正直言うと疲れますし、大きな変更加えたらテストがかさむし、不具合が起きたらどうしようみたいにネガティブに捉えがちでした。
これは今でも思いますしまだ克服できていないのですが、最終的には立ち上げ当初でユーザーも少ないしそれよりも PMF 達成のためにチームで頑張ろうという気持ちに切り替えるようにしています。
またドラスティックな変更を可能にするという面でモバイル開発において API のバージョン管理が大切なことにも気付かされました。
あるバージョンのアプリでは v1 を叩いているが、新バージョンだと v2 にしないと互換性が保てないなんて場面が結構あります。
Web の開発を行っていると API のバージョンをあまり意識していなかったのですが、ここらへんアプリ開発やらないとわからないノウハウなのかなと思います。
まとめ
思いつくことをまとめてみましたが、
結論、立ち上げ当初は過激な改善や新規機能の開発がつきもので、先を見越した技術選定や設計だったりが問われます。
これは成熟したプロダクトでのそれと比べて、影響範囲が大きいので非常にリスキーだし責任ある仕事です。
やっているうちに現場の変更に対して柔軟に対応していくエンジニアとしての問題解決力がついてきます。
また 0→1 のプロダクトを開発していくということは同時にチームも立ち上げ期であることが多いです。
チーム開発する上での決まり事や運用方法も模索しながら作っていけるのでチームビルディングなどに興味がある人におすすめの環境だと思います。
チームもプロダクトもまだまだ改善の途中で完璧とは言い難いですが、0→1 やスタートアップがよくわからないという人の参考になると幸いです 