🚅

創業期のスタートアップに入社した5ヶ月をふりかえる

かわうそ

2025/03/31に公開

 はじめに去年の11月から創業期のスタートアップに入社して、あれもこれもやらなきゃという中で、メインのプロダクト開発以外で行ったことを振り返ろうと思い、この記事を書きました。
創業期のスタートアップを経験するのは初めてですが、想像以上に大変ですね...笑
プロダクトとしてやらないといけないこと・やりたいことが山ほどある中で取捨選択して実行する。期日はよりシビアに考えていかないといけない。その中でエンジニアリング環境をより良くしていかないといけない。そんな簡単なものではないですね。
正式創業を迎える前でステルスに事業を進めながらも、なんとか国内外含め100社以上のお客さんに受注していただき、プロダクト開発の楽しさも実感できました。
ということで、ここ5ヶ月の改善活動を振り返っていきます。

 前提1人でやったというわけではなく、今いるメンバーと一緒にやりながら、あくまで主導したこと
もちろん、プロダクトの機能開発がメインではあるが、その中で行った改善活動についてふりかえる

 改善活動ドメインモデリングの導入と浸透
報連相を元にコミュニケーションを促進
開発者体験を阻害している要因の吸い上げと改善タスクの棚卸し
アーキテクチャの見直し
2025年4月以降に向けた技術広報の下準備

 ドメインモデリングの導入と浸透
 背景プロダクトの性質上、ドメインとちゃんと向き合う必要があった
BtoB SaaSのプロダクトを開発しており、価値を生み出すためには業務の解像度を高くしていく必要がある
(全く関わったことのない業務とかはイメージが湧かないので、キャッチアップコストもなかなかに高い笑)

ドメインが曖昧なまま開発を進めてしまうと、結果的に求めているものではないものが出来上がってしまうこともある(あった)
プロダクト開発におけるアジリティを高める必要もあり、モデリングであったりテストなどに取り組んで、より業務や仕様の解像度を上げていく必要もあった

 何をしたのかこちらに関しては、以前、書いた記事があるので割愛させていただきます。

https://zenn.dev/syoryu89/articles/ab80a32ba48fe3
(イベントストーミングで大体の解像度を掴む、そこからテスト駆動開発で詳細の仕様を把握しながら解像度を上げる、みたいな流れが今はちょうどよいかなとか思っていますが、まだまだ試行錯誤中です)

 報連相を元にコミュニケーションを促進
 背景黙々と開発をしていることが多く、チームでコミュニケーションを取ることが少ない状態
コミュニケーションを取ることがあるといえば朝会ぐらい

他の人がどんなタスクを対応してて、どんなことに困っているかなど把握しづらい状態
朝会は昨日やったこと・今日やることの報告がメイン
相談したり発言する機会がほぼない状態

（でも雰囲気が悪いってわけではなく、全員が本気で開発に集中しているってイメージです笑）

 何をしたのかひとまず気軽に発言できる環境づくりということで、毎日、以下のようなスレッドを立ち上げて、どんなことでも気軽に発言して良いという前提のもと、わちゃわちゃ話せるような状態を作りました。
こういったコミュニケーションが活発になることで、いろんな知識の共有であったり、対人の理解が進むきっかけになったりするので、0から始めるならちょうど良いぐらいの仕組みなのかなと考えています。
（本当はチームビルディングをちゃんと行えたらいいなぁと思いつつ、得意じゃないとこういうのはなかなか気が進まないです笑）

 開発者体験を阻害している要因の吸い上げと改善タスクの棚卸し
 背景雑談ができるようになったが、具体的になにかしらの課題が明確になったり、チームで議論できるようになったわけではない
開発チームとして議論していかないといけないことは溜まるばかり（たまにぼやっとつぶやく程度）
「この機能ってなんでこういう仕様になっているの？」
「監視・アラートってどんなツールでどんな方針でやる？」
「単体・結合テストの方針ってどうする？」
「ドキュメントってどこにどうやってまとめていく？」
...

これを何もない状態で議論すると空中戦になってしまう可能性もある
まずはちゃんと言語化してそれから議論するという流れが必要


 何をしたのかまずは以下のようなドキュメントをNotion上に作成して、タスクまでしっかり設定できる場（仕組み）を構築しました。ただ、内容によってはタスクまで設定しきるのが難しいこともあれば、タスクを設定できてもなかなか実施できないこともあります。
まずは以下のようなドキュメントをNotion上に作成して、困っていることや解決したい問題を吸い上げるところから始めました。内容は開発に関わることであればなんでもOKとして、とにかく問題を吸い上げることを優先しました。
実際に以下のような問題も挙がったりします。

そこから全員で議論する場を設けて、決めた時間内で対応方針を考えたり、その場で解決できるものは解決してしまうということを行いました。これをやってみて気づいたのが、こういう場からもドメイン知識やアーキテクチャの設計思想などが得られたりするんだなと感じました。
例えば、「XXXの運用が難しい」の相談から「そもそもその機能はなぜそういう機能になっているんだっけ？」「当時はどういう意図があってそういう設計になったの？」みたいな議論ができるので、後から参画した人たちにとっても貴重な場になっているなと感じました。
でも本当はこういった情報を一元化してADRなどに残していくべきであり、ここからADRをちゃんとやっていこうという流れも作ることができました。生成AIが普及してきたこの時代に、ドキュメントを適切な形で残すことはとても重要なことなので、ADRだけでなくプロダクトに関わることはちゃんとドキュメンテーションをしていきたいですね。

 アーキテクチャの見直し
 背景フロントエンドやバックエンドにそれぞれ明確なポリシーが存在しない
エンジニアによって出来上がる成果物が異なってしまう状態

何を理想系としているのかがわからないので、ポリシーも決めづらい
なぜ、このポリシーになるべきかと言えるものがない状態

プロダクト・組織のスケールに耐えられるような状態ではない
いつまで、モノリスな状態で開発を続けるのか
毎度、developブランチに大量の機能がマージされ、リリースの負荷がどんどん上がる

プロダクトの機能が増えるたびに、全ての変更を把握し続けるのか
流石に、人間の認知負荷限界はあるので、ある程度、領域ごとに分割しないと厳しい(システムを分ける分けないは別として)



 何をしたのかまずは現状把握と理想系を決めることを優先して行いました。エンタープライズアーキテクチャを定めていくみたいなイメージに近い活動です。
アーキテクチャはプロダクトが成長するとともに理想形も変わる可能性があります。だけど、「今はどこを目指しているのか」を明確にすることは、意思決定の速度であったり、開発者体験や開発生産性にも関わってくることだと思っています。
現状把握に関しては”開発者体験を阻害している要因の吸い上げ”で進めつつ、理想系を決めるために、プロダクトに関わるメンバーと「ビジネス特性を踏まえた上で、どんなエンジニアリング的な強みを伸ばしていくか、大事にしていくか」などを議論したり、ヒアリングする場を設けました。
実際に出た論点だと以下のようなものがあります。
そこから、フロントエンド、バックエンド、インフラ、データベース、セキュリティ、ローカライゼーション…という感じに、システムをコンポーネントごとに「中長期的にはこうしていきたいね、だから短期的にはこうしよう」みたいな指針を定めていきました。
まだまだ定めていかないといけないことは盛りだくさんですが、創業期からちゃんと理想形を設計できて、理想形から引き算で進めていけることはすごくありがたいことだと思っています。
僕の経験と個人的な私情もありますが、ソフトウェアアーキテクチャのポリシーを決めておくことはとても開発が進めやすくなります。ドメインとしてのモジュールの切り方、モジュール間を跨ぐ参照、レイヤードアーキテクチャをベースにした技術的な責務の分離なとなど、あるかないかで開発者体験は大きく変わるなぁと改めて思いました。
(共通言語で話せるようになるのもまた良いところですね)
あとはやっぱり中長期のアーキテクチャ像が少しでも見えてくると、今やるべきことが見えてきて、このフェーズだからモノレポやモジュラーモノリスが良いよねみたいな議論も進めやすく、現状のアーキテクチャも納得感が得られやすくなりますね。
(モノリスでどこまで戦えるのか、ビックバンなシングルDBとどこまで向き合えるのか、理想形を定めたものに対して移行戦略はどうやって計画していくのかなど、戦わないといけないことはたくさんありますが笑)

 2025年4月以降に向けた技術広報の下準備
 背景このご時世、エンジニアを採用するため、内部のエンジニアのモチベーションを高く保つため、”技術広報”はとても重要なものだと思っている
創業期だからといってやらなくて良いということはなく、むしろ、創業期だからこそ”技術広報”への仕組みやナレッジを創りあげていくべき
(社内のエンジニアもみな同じ温度感を持っていたのでありがたいw)

 何をしたのか手段ベースなお話が多くなるので、ここだけ箇条書きにまとめます。
テックブログの開設、運用に載せる
テックブログの必要性や価値を普及する
テックブログを書くことのハードルを下げていく(いいね数 ≠ 良い記事)

会社としての技術ブランディングにおける方向性の策定
上記で挙げたエンタープライズアーキテクチャを定めていく部分と近しい話
どんな技術的な要素を伸ばして広げていくか

勉強会・コミュニティへの参加に向けた準備
OSSなどのスポンサードも検討
コミュニティにも積極的に参加

テックカンファレンスにおけるスポンサードに向けた準備
創業期からどんなカンファレンスに参加していくべきか


 全体を振り返って
 開発者体験に関わる意思決定はそんな簡単ではない開発者体験に関わる意思決定は改めて難しいなと思いました。
技術的負債にも今までたくさん向き合ってきましたが、「プロダクトを前に進めること」と「プロダクトを前に進めやすくする」の間には多くのトレードオフがあるなと改めて感じました。特にスタートアップは短期的にめちゃくちゃ前に進めないといけないタイミングもあるので、「ここまで整備しきりたいけど今は後回し」みたいなことは結構ありました。
ぱっと思い付くものだと、「このコンポーネントがいろんなところで使われているから、デザインシステムと合わせて共通コンポーネント化したい、だけど今やると影響範囲が大きくなり、リリースにも影響するから後回しにする」とか「まだまだドメインが見え切ってないけど、今の段階でわかる範囲でモデリングして、最悪別のタイミングでスクラップ&ビルドしてもいいから、リリースを優先する」とかなどです。
ビジネスはインプットとアウトプットのバランスが求められることが多いので、エンジニアが時間をかけてこだわり抜いて綺麗に基盤を整えたとて、アウトプットまでのスピード・アウトプットの価値が低ければ、ビジネスとしてのインパクトが小さくなってしまうものです。
創業期だからかもしれないですが、エンジニアは「技術者でもありビジネスマンでもある」 ということを改めて感じています。
エンジニアとしてビジネスマンとして「今、何を選択して、何を捨てるのか」、この意思決定は一生向き合っていかなければならない事象ですね。

 ファシリテーションってやっぱ難しい新しい環境に変わって、自分がファシリテーションをするとなった時に、やっぱりファシリテーションって難しいなと改めて感じました。
その難しさの正体は「高速な意思決定を目的としたMTGのファシリテーション」です。
「ファシリテーションは準備が9割」と言われますが、とはいえ、いざMTGで意思決定まで持っていくにはいろんな情報や理解、合わせて整理が必要であって、その中でスピード感を持って意思決定していくのは難しいことだと思っています。
限られた時間とリソースの中で開発を行っているので、できる限り最速で物事を進めていきたいけれども、決めないといけないことがたくさんあリます。”開発者体験を阻害している要因の吸い上げと改善タスクの棚卸し”もそのうちの1つです。
こんな状況の中で、状況を見極めて、意図を定めて、関係者を集めて、安全な場を作って、対話を始めて、衝突を受け入れて、可能性を探って、合意を築いて、行動に移していく。
やっぱり、ファシリテーションってめっちゃ難しい笑

 さいごに4月からいよいよ正式創業になるので、よりプロダクトに向き合っていかないといけない。

そして、プロダクト・組織のスケーラビリティ獲得に向けてやらないといけないことも盛りだくさん。
次はアーキテクチャの記事を書こうと思います。