令和トラベル流、事業成長を導くためのエンジニアリング

激動の3年間

この3年間は急激な変化の連続でした。

1年ごとに事業としても全く違う景色が見えるようになり、それに伴い開発チームとしても直面する課題の特性が急激に変わっていきました。

1年目：創業期。NEWTリリースに向けてゼロイチでプロダクトをつくり続けた1年

まだ開発チームも小さくリソースも限られているなかで、自分たちの信じるプロダクトをとにかく高速に実装していくことが何よりも重要でした。

2年目：プロダクトマーケットフィット（PMF）を最重要テーマに掲げ、プロダクトを検証しながら事業成長の土台づくりを模索した1年

初期リリース段階では不足しているアタリマエ価値を拡充させつつ、検索機能を中心にUXをブラッシュアップしていきました。また、旅行者が増えるごとにサービスレベルの向上もシビアに求められるようになっていき、インシデント対応やその未然防止のための開発なども求められるようになっていきました。

3年目：10Xをテーマにさらなる非連続な事業成長を追求してきた1年

世界中のありとあらゆる旅行プランを日本一の品揃えにすることが事業成長の大きなドライバーの1つであることが明確となっていました。

どれだけNEWTで販売できるツアー数を非連続に増やしていけるか、そのうえでホテルや航空券の最新の在庫・料金をリアルタイムに補足できるか、増え続ける予約をスピーディに手配して、滞りなくサービス提供できるオペレーション基盤を整えるかなど、事業全体のオペレーションエクセレンスを高めていくための開発の比重が一気に増えていきました。

ざっと振り返ってみても創業期、PMF期、グロース期と、状況の変化から次々に新しい課題が発生し、開発チームに求められることが大きく変わってきたなと感じています。

これが3年という短い期間で起きたわけですが、僕たちが事業成長のボトルネックになることなくむしろ成長ドライバーとしてプロダクト進化を実現し続けられたのは、目先の開発スピードを追求するだけでなく中長期的にスケールできる備えも先手先手で実施してこれたからだと考えています。

目先の開発スピードとスケールに耐えうる備えを両立する

もちろん失敗もありますし、意図せず結果としてそう解釈できるものだったね、というものもありますが、例えば以下のような取り組みを早期から行ってきたのはよかったなと感じています。

1. 最小単位スコープでの開発の徹底

スタートアップは基本的に、その時点での戦力やリソースの限界を超えて、多くのことにスピーディに取り組んでいく必要があります。QCDSでいうとDeliveryは超速を求められるのに、Cost（つまり開発人員ですね）は超極小という制約を課せられている状況です。となると、QualityかScopeで調整せざるをえないのですが、あれもこれも不足しているプロダクトをみると、あれもこれもやりたいとScopeが膨らみQualityが犠牲になるという力学が非常に働きやすい構造にあると思います。

令和トラベルでは品質を犠牲にすることはせず、目的を達成するための必要最小限の単位でプロダクトをまずはデリバリーしていく、という方針を掲げて、Scopeを最小化することで超速Deliveryを実現していく戦略を徹底してきました。

スコープを削るために、まずは王道のユースケースを押さえることを重視しました。検討しているとエッジケースやクリティカルではないパターンなども気になってしまいますし、エンジニアとしては一貫性や完全性を求めたくなり、細かなユースケースも作り込みたくなってしまいます。ですが、それらは拡張ポイントとしてその機能の1stバージョンには含めない、というポリシーでまずは価値をデリバリーしていくことに集中してきました。

そして、つくると決めたScopeについてはしっかりとシステム設計を行い、テストも実施して、品質を妥協せずつくりこんでいきました。

これにより短期での高速デリバリーを担保しつつ、中長期的にもメンテナンス性の高いシステムを実現することができたと思っています。（まあ、もちろんそれでも当然使われない機能も、いますぐにどうにかしたい技術的負債も発生してしまうわけですが。。）

2. 早期から厳しい品質目標を定め、品質向上プロセスを磨きこむ

品質を妥協しないという意味では1と同じなのですが、別のアプローチとしてこれも本当によかったといま振り返って思う取り組みです。リリース当初から、以下のような取り組みを行ってきました。

機能開発におけるシステム品質目標を設定する

具体的には、QAフェーズでの重大不具合の検知率と、結果指標としての重大インシデントの発生件数の2つの指標を、メガベンチャーなどでも十分通用する水準で定めました。

QAフェーズでの重大不具合の検知率を定めることより、仕様をすり合わせて設計をはじめる段階から開発チーム一丸となってどう品質を向上させていくか？という問いにフォーカスすることができ、KPTでも建設的な議論からシフトレフトな改善策がたくさん生まれました。

品質状況を可視化し、改善のための開発プロセスの改善を積み重ねる

毎回の振り返りで、直近のスプリントでの実績値を定量数字として明確にして、それをもとに原因や対策を議論することで、地に足のついた改善施策を積み重ねることができました。

インシデントレベル定義と対応フローを定義、障害分析と振り返りをやりきる

これも当たり前ですね。サービス運営にクリティカルな影響を与えるインシデントから順にレベル定義を行い、レベルごとの対応ポリシーも定めて運用装着も徹底して行ってきました。

これらにより、NEWTはリリース後のこの2年間において、十分高いシステム品質をキープすることができていますし、品質がいいからこそ手戻りや混乱、場当たり的なツギハギ実装などもうまれず、スピーディな開発も両立することができています。

文字として書くと当たり前のことではあるのですが、勢いと感覚で突き進みがちなスタートアップの初期フェーズにおいて、これを徹底するのは意外と難しいと思います。

が、スケールしたあとから品質水準をあげることは非常に難しいですし、相当なコストがかかります。

スケールを想定するのであれば、これは初期段階から絶対に愚直に妥協せず、徹底すべきポイントだと思います。

3. 早すぎる最適化はしない

これは実装の話も機能の話もあるかなと思いますが、令和トラベルでは機能の観点で特に効果があったなと思っています。

令和トラベルでは、旅行会社として必要な一連の業務を全てソフトウェアで自動化していく構想が創業当初からありました。利益率の低いマーケットにおいて、独自の高収益ビジネスモデルを実現するために、人海戦術に頼らないためのDX基盤の構築が重大テーマの1つでした。

しかし、僕たちは創業初期からいきなりDX基盤をスクラッチで実装することはしませんでした。

NEWTでツアー商品を販売するための必要最小限のツアー入稿機能のみをシステム実装し、ホテル、フライトの在庫、料金管理や、料金計算、予約管理機能、手配管理機能などほとんど全ての業務についてはシステム実装せずにスプレッドシートをフル活用して業務を管理することにしました。

これは初期のプロダクトチームに旅行業のドメイン知識が全くなく、システム化を適切に検討できなかったのと、令和トラベルにおける理想の業務プロセスが明確に定まっていなかったからです。

スプレッドシートをフル活用することで、短期的にはスピーディに業務に必要なツールを提供することができました。また、進める中で発生するビジネスロジックや業務パターンなどに臨機応変に対応することもできました（僕が夜な夜な泣きながらGoogle App Scriptを書いてたことは内緒です）。

スプレッドシートで大量に試行錯誤を繰り返す中でドメイン理解が深まり、真につくるべき自動化システムの要件を明確化することができ、のちのちシステム化する際に、シンプルなシステムをスピーディに組み上げることに繋がりました。

システムを一度作ると大幅な拡張開発に非常にコストがかかります。特に業務システムは複雑な業務を取り扱うために、複雑なデータモデリングと大量のデータを扱うことになるので、業務モデルが大幅にアップデートされるとデータマイグレーションを伴う大きな開発が必要になりがちでスピード感のある開発が難しいのが事実です。

スプレッドシートなど柔軟な簡易ツールから始めることで、短期のスピードと柔軟性を担保することができ、またドメイン理解を深めたあとにシステム化することで、最初からシンプルで大きなデータモデルの変更がそこまで必要のないシステムをつくことができるので、中長期的な観点でも非常に生産性が高いと考えています。

こんな構想を持ちつつ最初はスプレッドシートで。すぐ限界を迎えたけどスタートとしては最適な判断だったなと。

4. マネジメントを早期に組織に装着する

創業初期はチームは数人しかいないので、毎日ミーティングをしていれば自然と同じ方向に向きますし、情報の伝達も適切かつ阿吽の呼吸でチームプレーができると思います。

しかし10人を超え20人、30人となってくると、どうやら同じやり方では徐々に組織が機能しなくなっていき、気づいたら組織全体の生産性が低下し、、、、という話はよく30人の壁、50人の壁、などで話に聞いたりします。これは事業と組織がスケールしたあとには必ず直面する問題なのです。

先回りするためには人数が少なく「マネジメントなんて不要なのにな…」と多くのメンバーが感じている段階から組織マネジメントを強化するしかありません。

ベストなのは、マネジメント経験のある人が初期から大勢いることだと考えていますが、昨今エンジニアリングマネージャーの採用は非常に困難なものになっているので、体力のない初期フェーズにどれだけEMを採用できるかは組織としては大きな分岐点になると考えています。

いずれにしても、ピープルマネジメントもそうですし、課題設定力、KPIなど目標設定、プロセス改善、プロジェクトマネジメントなど、最初から基礎的なマネジメントを組織に装着することで、人が短期に増えていっても傷まずに組織成長していくことができると思います。

プロダクト開発は個人戦ではなくチーム戦です。プロダクトドリブンなビジネスモデルの会社ほど、エンジニア組織が会社の中で一番最初に人数が増えていくのではないかと思います。そういった意味でも、特にエンジニアリングマネジメントの装着は早期から取り組むべき重大テーマなのではないでしょうか。

事業成長を導くためのエンジニアリング

サービスの成長に伴う状況の変化に開発スタイルを適応させていくことは非常に重要です。しかし、スタートアップにおいてはもろもろのカオスや問題発生を前提に、急激な事業成長を志向していますので、とある問題が発生しそれに対処したときにはまた別の問題が発生しているはずで、問題が発生してから対処していくのでは到底対処しきれず、開発チームがボトルネックになり事業成長を毀損してしまう可能性すらあります。

スタートアップにおける開発チームとしては、急激な事業成長にともなう問題の発生や開発チームの役割の変化を予見し、先手先手で対策していくことが重要です。

目先の開発スピードは当然重要ですが、それと同時に事業スケールを見据えた中長期の備えも並行して取り組んでいくことで、事業成長を牽引する開発チームが実現できると考えています。

令和トラベルでは、事業開始から5年で1,000億円の流通総額をつくるという非常に高い事業計画を立てています。

複数事業展開、グロース展開、IPOなど、これまでは全く意識も考慮もしてなかったようなビッグイベントも想定されますし、単純にプロダクトチームのみで50〜100人の組織になる、ということも割と規定路線として存在しています。

いま、それらの備えができているか？と問われると間違いなく「No！」ですが、これからも「1年ごとに全く違う状況になる＝1年ごとに全く新しい会社になる」んだ、と捉えて、必要な変化を先んじて起こしていきたいと考えています。

ちなみに、次の半年で特に取り組みたいと考えていることの1つは、プロダクト開発チームのスケールアウトです。

人数が増えてきている、かつ益々採用を強化していくなかで、4〜8人程度の小人数プロダクトチームが、独立して機動力高くプロダクト開発をそれぞれ進めていくチーム構成への進化が今後は必要になります。

そのためには潤沢な開発環境、安全安心にデプロイし続けられるテストセットやデプロイパイプライン、チーム間横断での連携など、開発基盤や組織基盤の構築に投資が必要になります。今のタイミングだけを見ると若干オーバーヘッドがあるかもしれませんが、間違いなく1年後には必要不可欠な取り組みになりますので、短期的な混乱やリスクは覚悟を決めて取り組んでいきます。

このあたりの具体的な取り組みについては別途記事を公開予定ですのでお楽しみに。