『ダイニーの技術戦略の現在地』 技術選定とコミュニケーションについて
メリークリスマス。ダイニー VP of Technology の karszawa です。
本日は、本年のダイニーの技術組織の振り返りとして、エンジニアリング観点での重要な意思決定とその背景について紹介していきます。
『技術選定』に関して通底する思想についても触れます。技術選定に悩んでいる方はぜひご覧ください。
先日の Findy 社主催の Meetup でも類似のトピックに触れていますので、こちらも合わせてご参照いただけますと幸いです。
事業進捗
エンジニアリングに関する進捗を説明するために、まずは前提知識として事業上の進捗を紹介します。ダイニーでは今年もさまざまなことがありました。ここでは二つをピックアップします。
ES (Employee Satisfaction) 事業部の立ち上げと『ダイニー勤怠』の提供開始
Finance 事業部の立ち上げと『ダイニーキャッシュレス』の本格展開
ダイニー勤怠 — 2024年10月3日
ダイニーキャッシュレス — 2024年9月19日
それぞれの事業の詳細は省きます。重要なのは、既存の POS 以外の事業が複数並列で立ち上がっており、ついに！満を持して！飲食の Vertical SaaS として本格的な多面展開を開始した！ということです。
各プロダクトは事業部体制で運営されており、究極的にはそれぞれのプロダクトが独自に機能開発を進められる状態を目指しています。これは、技術的にはコードベースとリリースサイクルが独立して存在している状態を意味します。
一方で、完全に別個のプロダクトとして提供するのであれば、同じ会社が Vertical SaaS としてサービスを提供している意味がありません。分離と統合の按分が重要なのです。特に、アカウント管理とデータ分析の領域では、各システムが高度に統合されている必要があります。単一のアカウント（飲食店）を多面的な角度から分析できるということがダイニーの強みだからです。アカウントや利用状況が分断されていて単一のドメインからの分析しか出来ないのであれば、ダイニーが存在する意味がありません。
マイクロサービス化
複数の事業部のシステムを高度に連携させたい。つまり、マイクロサービスの基盤を構築したいということです。マイクロサービスにはデメリットも多いですが、ダイニーにおいては、そのデメリットを覆すほどのメリットがあると判断しています。事業進捗に伴い、それだけの規模になったということです。コンウェイの法則的にも、事業上の理想的な組織体制と一致するようなシステムアーキテクチャを目指すのは自然な発想です。
ダイニーの開発組織にどんなチームがあるのかを紹介します。
POS Team (2022/06~)
Platform Team (2022/06~)
Discovery Team (2023/09~)
Data Team (2023/11~)
Finance Team (2024/06~)
ES Team (2024/06~)
乱暴にまとめると、Platform Team が整えた基盤の上で各事業部の Feature Team がプロダクトを実装し、最終的に Data Team にデータを連携してデータプロダクトでデータを可視化するというアーキテクチャが見えてきます。
2024年は、上記のようなシステム・組織体制の理想と実現方法を模索する一年になりました。
技術的意思決定の手法
この記事では、上述の結論の根拠を説明するのではなく、それに至るまでの『フレームワーク』『思考方法』を紹介します。
結論としては、下記の3点を具体的なアクションとして実行しました。
実際に苦労した人に聞きまくる
課題と解決の方向性を示し、タイムラインに表す
技術の『標準』を定めて投資効率を最大化する
実際に苦労した人に聞きまくる
問題を解決するための第一歩は、実現しうるソリューションをすべて洗い出すことです。さまざまなアイデアをすべて並べて比較することで、初めて「良い」「悪い」の適切な評価が可能になります。
では、どのようにしてアイデアを絞り出すことができるのでしょうか？自分の頭で考えるには限界があるので、本を読んだり、実際にやったことがある人に聞いてみるのが一番の近道です。幸い、システム上の課題は異なる業界・産業においても共通する点が多く、他社事例を参考にしやすいです。システムは他社とどれだけ酷似していても何の問題も無いので躊躇なく模倣させてもらいます。
繰り返すと、「実際にやったことがある人が同じことをやる」のが当たり前に成功率が高いので、そういった人の話を聞くのが一番です（もちろん、その人を採用すれば成功確率を更に高められそうではありますが、それはハードルが高いので確実に実行可能な方法を紹介しています）。
相談相手がいない場合は、勉強会に参加してコネクションを作ったり、経営者同士のつながりからエンジニアを紹介してもらったりしましょう。注意点は、勉強会は「仲良くなる」ことに注力するということです。勉強会はたくさんの人と交流することが目的とされている場合が多いため、あまり深い話はできません。また、自分の利益のために根掘り葉掘り話を聞くことは勉強会の趣旨に反するでしょう。仲良くなったあに 1on1 で会食やオンライン MTG を行うのが最も効率が良いでしょう。
課題と解決の方向性を示し、タイムラインに表す
システムアーキテクチャの改善には長い時間がかかります。おおむね 1~3 年ぐらいで具体的な計画が立てられることが多いと思います。期間に関しても、システム上の課題であれば「実際にやったことがあるのでどれぐらいの時間がかかるか知っている」人がいるので、それなりに高い精度で予想ができるのではと思います。
移行の間は、逆に言えば「理想ではない状態」が長く続くことになります。現状を理想状態と誤解してしまうとそれに合わせて不適切な設計が拡大してしまいますし、現状に最適化するための無駄なコストが発生してしまいます。それよりは「今後はこうなるので現状はあえて何もしない」というような意思決定が出来たほうがリーズナブルな気がします。
ダイニーでは、そういった理想状態を定義するものとして「Engineering Vision」「Engineering Roadmap」というものを定義しています。Engineering Vision が課題と解決の方向性をまとめたもので、Engineering Roadmap はそれを実行アイテムとしてタイムラインに並べたものです。
このフレームワークを利用してエンジニア組織全体で最終的な理想状態に関して合意を取り、将来が不透明な状況を防止します。また、定期的に基盤および各事業部の技術面でのアップデートを共有する場を用意します。
技術の『標準』を定めて投資効率を最大化する
次に Technical Standard という取り組みを紹介します。Technical Standard は、ダイニーのプロダクト開発において標準的に採用すべき技術を定めた一覧です。具体的には、言語・フレームワークとしては TypeScript, React/Next.js を使うということから、インフラ管理には Terraform CDK を用いようということが記載されています。
プロダクトの特性に応じて重視すべき観点は異なり、それにより最適な技術も異なるはずではあります。しかし、あえて前提条件なく採用する技術の一覧として Technical Standard を定義しています。目的は、プロダクトを開発するたびにいちいち技術選定をしている時間が無駄であるということと、技術をある程度固定化することで、その環境に対する投資効率を最大化するというところにあります。
具体的には、言語を TypeScript/JavaScript で統一することでプライベートパッケージの公開を Google Cloud の Artifact Registry 上で簡単に行う仕組みを実現していたりします。これを言語ごとに実現するのはオーバーヘッドが大きいです。
都度最適な技術を検討するよりもある程度の標準を定めてしまうことのメリットには次のようなものもあります。
リンターやフォーマッターの一元化
エディタの設定の一元化
パッケージのキャッシュの有効利用
メンバーのスペシャリティの先鋭化
技術選定について
余談になりますが、技術選定に関する根本的な考え方についても触れておきます。
前項でも触れましたが、技術選定という営みにおいては、必ずしもプロダクト特性に即した技術を選び出すことがベストだとは限りません。それよりも重要なファクターとして、会社組織として投資を効率化できるかどうかや、コミュニティが成熟しているかという観点の方が重要だったりします。
また、そもそもユースケースに即した最適な技術が存在するとも限りません。むしろ、ある程度の妥協は避けられないと考えるべきです。デメリットのない最高の技術など存在しないという点も冷静に受け入れなければなりません。もし、ある技術がデメリットのない最高の技術に見えたとしたら、それはあまりにも新しい技術のため、実際のビジネスの中でヘビーに使いこなしているユーザーが存在しないだけという可能性が高いと思います。
個人的に最も重視している観点はコミュニティの成熟度です。ある程度の歴史があり、ユーザーが多く、それなりに問題が指摘されている技術の方が信頼感があります。その技術に対する批判は、それが長い時間の中でコーナーケース的な小さい問題を多く解消してきたということを示唆しています。
新しい技術に取り組む方法
技術選定に関する考え方としては、要はコミュニティが大きくて枯れている技術の方が得が多いということを話しましたが、もう一つ重要な観点もあります。それは、すべての技術はいずれレガシーになるということです。レガシー化によってコミュニティも小さくなってしまうので、「枯れた技術」を採用している理由も無くなります。
技術のレガシー化により、事業進捗に甚大な被害が発生する可能性もあります。レガシー化に備えることは技術に対する「嗅覚」を持つエンジニアにしか出来ないことです。つまり、新技術・代替技術の検証・研究はエンジニアにとっての責務であり義務であるということです。
ただ、既存のプロダクトにおいて基盤部分の検証を行うのは現実的に困難です。そこで、ダイニーでは新規プロダクトを立ち上げる際に新技術の検証も兼ねることが多いです。
実際に、これまで Cloudflare, Bun, Hono, Kysely, Prisma 等の技術について検証しており、それぞれ採用したりしなかったりしています。採用された技術を全プロダクトに適用していく作業は Developer Experience の改善の文脈で Platform Team の業務として実行しています。
ちなみに、ダイニーには新規プロダクトの機能検証を行っている Discovery Team というチームがあります。上述の機会で技術検証を行っている都合上、Discovery Team が新技術の検証も行うことが多いです。プロダクト上の検証も行いつつテクニカル面の検証もできる最強のケイパビリティを持った Discovery Team に尊敬と感謝！
まとめ
本記事では、スタートアップにおける技術選定のアプローチについて、以下のポイントを解説しました。
プロダクト特性だけでなく、コミュニティの成熟度や投資効率を重視
Engineering Vision と Engineering Roadmap を通じて、組織全体で技術の方向性を共有
Technical Standard を定めることで、技術選定の無駄を省き、投資効率を最大化
新技術の検証は小規模に行い、リスクを最小化しながら知見を蓄積
最後に、技術選定において最も重要なのは、選んだ技術に対して組織として投資していく覚悟です。完璧な技術など存在しない中で、選択した技術を育て、改善していく姿勢が、結果としてより良い技術基盤を作り上げることにつながります。
We're Hiring!
ダイニーでは、「“飲食”をもっと楽しく おもしろく」というミッションに共感し、一緒に飲食業界を変えていくエンジニアメンバーを募集しています。ダイニーのチームやプロダクト、技術などに興味がある方はぜひ一度カジュアルにお話しましょう！
