tags
Engineering Management
author
category
em
mainImage
.png?table=block&id=6eb9f3a7-d401-4475-9400-f8c6c2892104&spaceId=06681db4-d0ea-4e78-9164-a9d5fb58f475&userId=&cache=v2)
publishedAt
Oct 24, 2022
published
published
slug
transition-of-product-development-2022
authorDisplayName
Shotaro Magara
.png?table=block&id=ef000416-569f-4ea6-b984-df27498a0ad2&spaceId=06681db4-d0ea-4e78-9164-a9d5fb58f475&userId=&cache=v2)
はじめに
こんにちは、令和トラベルのEngineering Manager 兼 Product Managerの@magarashotarです。
早いものでわたしが令和トラベルにPP（※令和トラベルでは副業で携わってくれている方をPP=プロ・パートナーと呼んでいます。以下、PPが何度もでてきますので覚えてね。）としてジョインしてから1年半、フルタイムとしてジョインしてから1年が経ちました。
創業期のこの1年半は本当にカオスの中で、濃密な経験ができてとても楽しい1年半でした。
次から次へと難解な課題が降り注いでくるので常になにかに没頭している状態で、本当にあっという間に月日が流れていった感覚があります。（これはわたしの加齢が進んでいるのが原因ではないはず。令和トラベルのせい。）
フルタイムジョインして10月でちょうど1年たったのもあり、このタイミングで立ち止まってこの1年を振り返ってみようと思ったのですが、濃密すぎるがゆえに1つ1つの記憶がもはや曖昧になりつつあることに気が付きました。（これもわたしの加齢が進んでいるせいではないはず。令和トラベルのせい。絶対そう。）
それなりに面白い課題に直面してよい取り組みもできたはずではあるので忘れてしまうのは勿体無いなと思うので、このブログではEM目線で主に組織や開発の進め方といった観点でスタートアップのリアルなカオスをアウトプットして残しておきたいと思います。
プロトタイプ開発期
創業初期の2021年4月頃はコロナ禍の真っ只中であり海外旅行マーケットがどの時間軸で回復するかが全くわからない時期でした。1つのシナリオとして2021年夏頃に回復し始めるシナリオを想定し、スマートに海外旅行が予約できる最低限のプロダクトを夏までに立ち上げるということで開発がスタートしました。
（初期のプロダクト開発スケジュール。な、懐かしい…）
初期に集まったメンバーで技術選定を行い、NEWTの原型となるUXやコア機能は代表の篠塚とPMでラフデザインと仕様のアウトラインを一気につくり、骨子が見えてきた機能から順次開発に着手しました。
当初の開発チームはフルタイムエンジニアが1,2名しかおらず、ほぼ大半がPPさんで構成されたチームでした。限られた時間かつ稼働時間が異なるメンバー同士ということで、ミーティングは各チームごとに週1時間程度しか設定できなかったので、基本的に非同期コミュニケーションを前提とした開発スタイルを考える必要がありました。
基本的な進め方としては、週1時間の定例でデザインの60%段階の機能について仕様とデザインの読み合わせをおこない、主要論点を潰して大枠が見えたら、各メンバーが実装を進めていきました。その上で、細かな仕様やデザインは実装しながらslackで調整しながら仕上げていく、というフローで進めていきました。
また、途中からジョインするメンバーが多数いること、週次定例に参加できない人も多いことなどから、立ち上げ当初からドキュメントをしっかり残すことを徹底して行いました。機能要件は決定経緯含めてNotionにまとめ、デザインはFigmaを必ず最新状態にメンテナンスし、ミーティング議事録は手厚く残していく。さらにSlackは基本パブリックなチャンネルしかつくらない、など、情報の伝達ロスや情報の非対称性を極力発生させないように工夫しました。
NEWTで販売するためのツアーを入稿して在庫・料金・予約を管理していくためのバックヤードシステムの開発は、そもそもほとんどのメンバーがホテルやフライトの料金構造や在庫管理の仕組みがわからない状態からのスタートし、かつ、バックエンドエンジニアは全員PPさんだったため、最小工数で実現するために、データモデル駆動開発とも言える開発方針で進めました。初期段階でドメイン理解を一気に深めコアとなるデータモデルだけ先に確定させ、管理画面のUIやビジネスロジックはデータモデルに制約させる、というスタイルです。テーブル構造と同じ構造の画面構造になるため管理画面としては使いにくく、システム都合のユースケースを考慮したビジネスロジックの検討も必要となったりデメリットもありますが、システムの根幹であるコアデータモデルがシンプルになること、変更が入りにくいこと、API開発の工数が最小化されることなどのメリットがあり、この方針は初期のスピーディな立ち上げにマッチしていてよかったのではと思います。
このような工夫があったとは言え、やはりPM含めPPさん多数で進めていたので、仕様検討が追いつかない、アプリエンジニアとバックエンドエンジニアでAPIのインターフェイスのすり合わせが全くできない、そもそもプロジェクト計画が曖昧、スケジュール管理ができていない、など相当に混沌とした状況でした。
今振り返ると、当時の開発は個々人の力量と判断に多分に依存した野性味あふれる開発だったなあと思いますが、情熱的でスキルフルなチームの圧倒的な突破力で夏の終わり頃にはプロトタイプをほぼ完成させることができました。
（初期メンバーのオフィスでの1枚。）
リリースバージョン開発期
コロナ禍の状況を鑑みてリリースは先送りとなり、2021年秋頃からしばらくはリリースの機会をうかがいつつ、プロトタイプにしっかりと肉付けをしていく期間が続きました。複数エリア展開対応やカレンダーの料金色分け、価格ソートなどの機能拡張から、コンシェルジュ相談フォームの埋め込み、ツアー詳細画面の情報リッチ化などクオリティの磨き込みやツアー入稿機能の拡張など、大小様々な対応をプロトタイプに積み重ねていきました。
この時期に3人ほどフルタイムのバックエンドエンジニアがジョインしてエンジニア5名体制（PPさん含めると10〜12人程度）となったので、プロトタイプ期の課題を解消すべく徐々にフルタイムメンバーを中心としたチーム開発を強化していきました。
まずは、スケジュール計画や進捗管理がチーム全体で可視化されておらず多くの案件を同時並行で着手しているもののそれぞれの完了見通しがわからないという状況を解消するために、スクラムをベースとした2週間スプリントでのイテレーション開発を導入しました。
PPさんについては日中時間帯のスクラムイベントに参加してもらうのは厳しかったので、フルタイムメンバーでスクラムイベントを行い同期を取りつつ、iOS、Android、Frontend、Backendと技術軸ごとに週次定例を設けて各領域のフルタイムメンバー（リードエンジニア）から具体タスクを依頼していく、という二層構造的なチーム体制で開発を進めていきました。
（完全に余談ですが、元から全社でNotionが広く使われており仕様もNotionに書いていたのもあり、バックログ、PRD、スプリントごとのタスクかんばんにはNotionをフル活用しました。通知や依存関係の管理など細かなことはできませんがNotionの表現力の高さは本当にすごいですよね。Notion大好きです。）
スクラム化することで開発にリズムがうまれ、プロセス改善も積み重なり徐々に開発が安定化していきました。しかし、チームが大きくなるにつれて、PPさんの稼働の波が激しくベロシティが安定しきらない（＝開発完了見通しがたたない、ずれる）、リードエンジニアがボトルネックになる、という問題が大きくなってきました。
PPさんは当たり前ですが本業の忙しさの波や土日の予定などで波発生しますので、2週間スプリントの中で1週間稼働できないことが多々あるとタイムラインが合わず難しかったです。試行錯誤を繰り返しましたが、ここには明確な解を見いだせませんでした。さすがにスクラムベースでスピーディに開発をすすめるとなると、チーム構成比率的にもフルタイムメンバーの採用が必要不可欠という大前提に立ち戻り、採用活動を強化することにしました。
ちなみに現在ではPPさんには納期制約が緩いが重要なものをまるっとアサインするのが一番バリューを発揮してもらえるのではないかと考えていて、目先の開発タスクだけでなく、現在は少し先の未来に必要になる機能のPoC開発をお願いしたりするケースも増えてきています。
（エンジニアメンバー全員集合しての交流会＠オフィス）
プロダクトリリース期
2022年4月にNEWTをリリースしたタイミングを期に、私たちのプロダクト開発は大きく変わりました。
それまではPRを無条件でmainブランチにマージし、問題が発生した場合は都度修正、QAプロセスも整備せず人海戦術でのモンキーテストを定期的に繰り返すというスタイルで開発スピードだけを追い求めていました。当たり前ですがリリース後はこのような進め方で安定的にサービスを提供できるわけもありません。開発環境、QAプロセス、CI/CD、リリースマネジメント、障害対応フローなどを整えて、サービスの安定提供とスピーディなプロダクト進化を両立していく必要がありました。
実はリリースに向けて奔走していたためこのあたりの整備が全くできていないまま4/5のリリースを迎えてしまったのですが、これらリリース後に必要なオペレーションやプロセス設計は4月にジョインした EMの @oura と @miisan が入社直後にすぐ状況を察知してクイックに整えてくれました。神かよ。
プロセス的な面でいうと、2週間スプリントを継続しつつ、毎週後半をQA期間、翌週月曜をNEWTアプリのリリースポイントとして定めました。スプリントの中で開発がすぐ終わるものは1週目のQAラインに、開発が1週間以上かかるものは2週目のQAラインに乗せる、といったイメージです。本当は1週間スプリントがシンプルで理想的だったのですが、この時期はまだアプリエンジニアはPPさんが多く土日に稼働してもらうことなどを考えると1週間ではスプリントとして成立しないため2週間スプリント×毎週リリースというサイクルでバランスを取るという判断となりました。
障害対応については、障害レベルの定義、発生時のトリアージプロセス、障害対応中のコミュニケーションルールや情報フォーマットを定めました。slackに全社員が入っている #incidentチャンネル をつくり、不具合かと疑わしきものは全て @channelメンション でエスカレ、それをPM or EMが障害レベルを即時判断してレベルが高いものはプロダクト開発を止めて障害対応、低ければバックログに起票だけしておきプロダクト開発を優先する、というメリハリをつけた対応をリリース時から徹底したことで、リリース直後もチーム全体で混乱することなく効率よく対応できたのではないかと思っています。
現在
2022年夏頃には開発サイクルが定着しチームの生産性もプロダクト品質も大幅に改善していきました。PPさんも増え、フルタイム7人、PPさん15人とチームサイズも大きくなりましたが、非同期コミュニケーション前提でも齟齬を極力発生させない工夫を積み重ねてチームをスケールしていきました。
特によかったのがデザインのバージョン管理です。細かな仕様やデザインは開発中にもアップデートされ続けるためその変更を関係するメンバー全員で共通認識を持ち続けないといけませんが、PPさんも多い中非同期コミュニケーション前提でコストをかけずにどのように実現するか、という点がずっと課題となっていました。
- Figmaに仕様やデザインを一元化する
- Figma上でデザインや仕様の更新があるたびに元のデザインを残したまま隣に変更したデザインを作る
- そしてバージョンを書いて最新のデザインバージョンがどれかを明確にする
- 全員が常にその最新バージョンを見て開発 & QAをする
- デザインに表現できない仕様はメモ欄に書き、開発着手後は変更履歴も残す
という少し力技な運用ではありますが、これにより仕様変更する際の議論に参加していない人でも変更点に気づけるようになり、仕様の実装漏れ、バックエンドとクライアントサイドの不整合などの不具合が大きく減り、開発スピードも向上することができました。
（Figmaの例。ver10くらいまでアップデートされるものも。）
また、バックログやスプリントでのタスク管理はNotionからJIRAに移行しました。スクラムをやるうえでの機能が充実しているのはもちろんですが、不具合分析や生産性分析などのためのメトリックスをきちんと計測できるのが大きいです。わたしたちは2022年上半期に100件のリリースを目標に定めていたので、その達成のためにいくつかメトリックスをしてそれをもとにKPTを行い改善を積み重ねていきました。
特にQAプロセスを定義してからのこの半年間は、QAフェーズででた不具合原因の分析の成果が大きく出たと感じています。
- そもそも開発規模に対して不具合数が多い
- 特に、実装漏れや仕様の考慮漏れが多い
ということが数値的にも明確になったことで、上記にあげたFigma上でのデザイン最新化の取り組みにもつながったり、実装時の品質を上げることが結果として開発スピード向上に寄与することがチーム全員のコンセンサスにもなり、KPTであがる改善案の質もよりよいものになっていきました。
結果としても上半期で目標としていた100件を超える106件のリリースを達成することができました。
アーリーフェーズでカオス真っ只中のスタートアップとはいえ、10人程度の規模となってきているので事実をしっかり計測し、数値をもとにボトルネックを特定して改善していき、効果を振り返る、というこれも当たり前ですが取り組みとして重要だなと感じています。
（KPTは毎回Miroでスタンプつけながらワイワイやってます。）
振り返りとこれからについて
この1年半をザーッと思い出してみましたが、振り返ってみると事業やプロダクトの進化に合わせてわたしたちの開発チームも大きく進化してこれたのではないかなと思っています。個々人の力量のみに依存した野性的な開発スタイルからチームで成果を最大化できるスタイルになり持続的に成長し続けられる開発チームになってきたと感じています。
この進化を自画自賛したい部分もありつつ、とはいえ冷静に見るとまだまだ事業自体がスタートラインに立ったくらいの段階であり、これからどう非連続に成長していけるかが重要だと考えています。
篠塚のnote（【長文】NEWTスタートから半年、PMFを達成するために意識している5つのこと。）にあるとおり、わたしたちは今PMFを目指して試行錯誤しています。NEWTでの最高の旅行体験の構築はもちろんのこと、多様な旅行ニーズにこたえる新規サービスの開発や、旅行代理店としてのオペレーションのオートメーションを目指したバックヤードシステムの構築など、明らかに1年前、半年前よりもやるべきことが広がっている状況です。デジタルトラベルエージェンシーとしてテクノロジーの力で新しい旅行体験を生み出したいわたしたちとしてはエンジニアリングで事業の進化を牽引していきたく、そのためにもプロダクトリリースを今まで以上のペースで生み出しつづけていく必要があります。
そのためにはもちろん組織のスケールも至上命題の1つであり、採用を強化する（絶賛募集中です！ちょっとでも興味もっていただけた方、エントリー or Meetyで連絡いただけると嬉しいです！）とともに、人数倍増した際に適切にスケールするための組織づくりも進めていく必要があります。1つの取り組みとして組織のSquad化に着手し始めておりミッション（課題）単位の少人数チームへの移行を進めていますが、まだ取り組み始めたばかりではあるのでこれについてはまた少し先にブログに書きたいと思います。
とりとめもなくわたし個人の目線で1年半の振り返りを書きなぐってしまいました。スタートアップの立ち上げフェーズのプロダクト開発と一言に言っても対峙する事業領域やチームその他前提事項により求められるものは異なってくるかとは思いますが、1つの事例として、これをご覧いただいている方のお役に立てる部分あればうれしく思います。
最後に宣伝
令和トラベルでは今後もエンジニアリングブログで定期的に取り組みを共有していきたいと考えています。ぜひまた気軽に見に来ていただけると嬉しいです！フィードバックなどもお待ちしております！
また、令和トラベルでは一緒に働く仲間を募集しています。ぜひこの記事を読んで興味を持ってくれた方はご連絡お待ちしています
さらに定期的にイベントも開催予定です。connpass にてメンバー登録して最新情報をお見逃しなく！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますのでお気軽にお声がけください〜！
それでは次回もお楽しみに！
