この記事は、弊社noteで公開した内容をWantedly向けに再掲載したものです。
Domuzがどのような考えで事業や組織づくりを進めているのかを知っていただける内容になっています。ご興味のある方はぜひご覧ください。

Domuzの開発責任者の鈴木新芽（いぶき）です。受注管理システムや植物と花のオンラインストアECサイト「AND PLANTS（アンドプランツ）」「AND FLOWER（アンドフラワー）」花のECサイトのECシステム、イネイブラー関連の開発などを見ています。

今回の記事ではDomuzの成長をエンジニアの視点から正直に伝えようと思います。ここまでの成長を開発で牽引してきた一番の要因としては高度なアーキテクチャを組んだから、ではありません。むしろ逆で、作らないことを徹底してきたからだと思っています。

植物と花を扱っているスタートアップのエンジニアとして何が大事か。これから一緒に働いてくれるかもしれない人に、現場のリアルをそのまま届けられたらと思っています。

Domuzがどんなことをしている会社か知りたい人は、社長の高木のnote記事をぜひ読んでください。

なぜこのスタートアップに足を踏み入れたのか

Visual Basicから花のECへ、寄り道だらけのキャリア

小学生のころからプログラミングが好きでした。きっかけはゲームとWebページ制作で、大学教授だった父がVisual Basicを教えてくれたのが最初だったと思います。そのまま進路もエンジニアリング一択で、東京大学の電子情報工学科を経て、新卒でIT系の大企業に入りました。

ただ、大企業での開発はすぐに自分の肌には合わないと気づきました。まず動くものを試すのではなく、会議で方向性を決めるステップから入ります。しかも確実にできることを大手と組んで進めるので、なかなか前に進まない。ハッカソンなら一気に作れてしまいそうなことを、長いプロセスをかけてやっていく感覚でした。そうなるとメンバーもそのペースに合わせながら手順を正確にこなすことに最適化されていってしまい、自分の性格としては正直あまり面白く感じられませんでした。「もっと直接的に作って、直接的に影響を出したい」という気持ちが強くなっていきました。

その後、スタートアップ支援のベンチャーキャピタルであるREAPRA Venturesに移りました。そこでDomuzのCEOである高木さんと出会い、2020年7月にDomuzに入社しました。

決め手はいくつかありました。高木さん自身がCTOの経験を持っていて、エンジニアリングへの解像度が高い。現場スタッフとの距離が近い。そして毎月、事業指標という形で自分の仕事の影響が見える。大企業で感じていた「遠さ」がすべてない環境でした。

仕事のやりやすさで一番ありがたかったのは、ある程度動くものであれば、ちゃんと使ってくれるところです。依頼する側はつい細かいデザインや文言に気づいてしまい、文句が出て遅くなりがちです。高木さんにはそれによる律速がなく、あるものはそのまま使いますし、ちょっとした修正なら自分で直してしまうので、とても早かった覚えがあります。Domuzにいて、やり方が不透明で心配だなと思ったことは一度もありません。知らない部分はありますが、聞けば納得できます。

スタートアップの現場で何を思ったか

ゼロから200時間で、ECを立ち上げた

入社時点での既存の仕組みは何もなく、高木さんが詰めた受注管理システムの要件とストアのデザイン案だけがある状態でした。インフラ・管理画面・ストアを合わせて約200時間で立ち上げています。

アンドプランツは生花店を引き継いだわけでもなく、高木さんが観葉植物や植木鉢や資材などを新しく借りた空き事業所に仕入れるところからのスタートでした。

設計で難しかったのは、Shopifyをどう使えばいいかのノウハウがないところでした。Shopifyテーマというほぼ独自の言語があり、すでにあるテーマのHTMLをそこにどうはめていくか。あるいは、Shopifyの注文データをどうやって自社のバックエンドから管理していくのが適切か。自由度が高すぎて難しい、という感覚でした。ただ、ここが一番楽しいところでもあるので、辛かった覚えはありません。

少人数で全部やる、スタートアップエンジニアのリアル

現在のエンジニアチームは、20〜30代の少人数です。全員がインフラからフロントまで担当するジェネラリスト構成で、生成AIでスピードが上がっていることもあり、全員でどんどん書いてデプロイしていくスタイルです。

だからこそ、最初の設計が大事になります。標準的で、驚きのない堅牢な設計があると、各自が好き勝手に書いていってもしばらく持ってくれます。フレームワークから逸脱しない。ちゃんとDBに保存して、処理と処理が離れるようにしておく。これが効いてきます。

スタートアップの現場で難しいのは、要件が流動的な中で、作るべきものを正確に絞ることです。事業がどんどん変わる。昨日決めた仕様が今日覆る。その中で「これは本当に作るべきか」を問い続けないと、あっという間に手が回らなくなります。

スタートアップは新しいことを始めている分、打ち手はいくらでも考えられますし、伝統もないのですぐに改善できるところもたくさんあります。その中で「これは先回りしてやらないとだめ」というものを見つけ出さないといけない。そこが大変なところです。開発リソースは常に足りません。だからこそ、何に使うかの判断が、エンジニアとしての一番重要な仕事になると思っています。

「勢いよく書いて、早く出す」

最大のリスクは、「コードを書くこと」だった

一番のリスクは「作りすぎること」だ、というのが根本にある考え方です。

僕のやり方を要約すると、こうなります。とにかく動くコードまで持っていき、頑張れば使える形にしてリリースしてしまう。最悪、使えなくてもいい。ハッピーパスで使えれば良い、という捉え方です。こうすると、すぐにフィードバックがもらえます。これを言葉にすると、「勢いよく書いて、早く出す」になります。

過設計・過実装、いわゆる作り過ぎのムダこそが最大のリスクで、コードを書いたり複雑な設計をするのは最終手段であるべきだ、と考えています。

コードを書き始める前に、次の2点を必ずやります。

• 作らなくていいかもしれないものを、なるべく削る
• 約束したことは、期限通りに作る

この2つができていれば、数回ミーティングのあとには難しい点がほぼなくなり、あとは手を動かすだけになります。設計の方針も同じで、なるべく実装しない。実装するとしても、決まりきった大枠だけを作り、変な設計をしない。 こうすると「間違えずに十分なシステムが出来上がる」。これが変わらない考え方です。

必要になってから作る

注文データも当初は実装や責務を減らすために、自前のDBには持たず、Shopifyにすべて持たせていました。1年ほど経って、検索性能や統計でどうしても負荷がかかるようになり、そこで初めてDBに持たせる構成へ変えました。必要になってから作るを地で行った形です。

最初からDBに持つ設計にしておくこともできました。でも、それは「いつか効くかもしれない」という想像に対してコードを増やす行為です。もし負荷が来なければ丸ごとムダになる。何を作らずに先送りするかを決められること自体が、エンジニアの判断力だと思っています。

もちろん、この方法には問題もあります。当然、設計が甘い部分は出てきて、その扱いには苦しむ部分も出てきています。ただ、それはあとから時間を使えば解決する問題なので、致命的ではない。それよりも、測定できない遅さのほうが致命的だと考えています。

この方針でいると、エンジニアが業務過多になりにくい。分かりにくいところやブラックボックスが減るので、現場が素直に業務を回せます。コードが少なく素直であることは、運用する全員にとっての利益になります。

そしてこれは、生成AI時代とも自然にかみ合います。設計に意外性があったり、名前から読み取れない要素があると、AIも誤解する。逆に言えば、人間にとってリーダブルなコードは、生成AIにとってもリーダブルで、バグも生まれにくい。 昔からの「作りすぎない」という方針が、そのままAI時代の前提になっています。

弊社でも大部分がAIコーディングになってきています。いまは、完全自律で実装する場合はDevin、手元で半自律でやるときはClaude Codeを使っています。既存のコードをもともとフラットでリーダブルな構成にしているのが効いているのか、それほど時間もかかりませんし、あまり変なコードが出てくることもありません。

おわりに

AI時代の開発体制へ

今後ますますAIコーディングの領域が増えていくことは確実です。人が判断するよりも早くコードが出力され、大部分問題がないコードが出来上がります。これによってこれまではなかった速度・少ない人数で大量の機能やデザインをリリースしていけます。

しかし、大規模なデータ量がくることや、非連続的な機能拡張に関してなどAIが自然に生成したコードでは耐えられないことがあります。人間がまだ果たさないといけない役割はここに残っています。AIは今だけ動かすためや、ほぼおきないエラーのためにコードを複雑化しがちです。しかし、今動けば良いだけではなく、将来の拡張が必要です。人間がガードレールとなり、シンプルに保つことで、人間にしか見えていなかった、新しい拡張に耐えられる余地を残すことができるのです。

Domuzが今後も成長を続けていくため、今の時点では予想できない新しいビジネスへの拡張に耐えられるようにする必要があります。そのためには現状の最適化にとどまらず、拡張がしやすいシンプルで柔軟な構成を保ち、開発がボトルネックにならず、強みであり続けるようにしていきます。

「作りこまない判断」ができる人と、一緒に働きたい

「何を作らないか」を一緒に判断できる人と働きたいと思っています。

機能を増やすことより、削ること。複雑にすることより、シンプルに保つこと。スタートアップのエンジニアに求められる判断は、大企業でのそれとは少し違います。コードを書く力より、作りこまない判断をできる力の方が、ここでは活きます。

求めているのは、自律性が高い人です。話を聞いて、すぐにやってみました、次はどうしましょう、と自然に動ける人と働きたいと思っています。率直に話ができる環境があり、要点を絞って短期間でリリースできるので、とにかく早く動くコードを出せます。入社したらすぐに、すべてのコードもデータも見て触っていい。好きに会社を良くできます。

事業の成長を数字で見ながら、現場と近い距離で開発を回せる環境です。興味があれば、ぜひ話を聞きに来てください。