kg-icon
コアドメイン模索中のプロダクト開発に関する備忘録
2025-01-27

はじめに

これはただのポエムであり備忘録です。未来の自分がこれを振り返って色々試行錯誤できたらいいなと思い書いたという意図があります。

スタートアップで業務委託

スタートアップで働くのは初です。

初めはサーバーサイドエンジニアとしてスタートアップ企業に業務委託として参画しました。今は設計、サーバーサイド、フロントサイド、その他諸々(CI/CDとかドキュメント書いたり等)と横断的になんでもやっています。

この記事を書いてる段階でほぼ1年経過しました。最初は業務委託として参画しましたが、参画して3ヶ月ほどで正社員としてお誘いを頂き、業務領域にすごく関心があり、またいい人ばかりだったのでそこまで悩まずに転職を決めました。

エンジニアの人数に関してはめちゃくちゃ少なかったですがそこは自分にとって懸念にはなりませんでした。

本格的にプロダクト開発スタート

自分はこれまで設計、アーキテクチャに強い興味関心があり、プライベートでも結構な時間をそれらに費やしてきました。

なので、実務でこれまで得てきた成功、失敗の知見や、色々試行錯誤して得た知識を元に堅牢でセキュアなシステムを構築していこうと超やる気でした。

ドメインエキスパート(ビジネス領域に関しては詳しい人)と密接にコミュニケーションをし、曖昧な仕様や業務内容を炙り出し、ユビキタス言語を作り、それらをもとにコンテキストマップを用意し、境界づけられたコンテキストで境界を整え、できるだけコンポーネントを疎結合にし、関数型プログラミングでドメインイベントを徹底的に管理してI/Oとビジネスロジックを切り分けて、アーキテクチャ特性の中から何が大事かを選定して….と、いわゆる「堅牢で保守しやすく、ビジネス仕様も漏れなくコードに反映している」という状態をせっせと目指して業務にのめり込んでいました。

もちろんこれらの設計やプログラミングパラダイム自体を目的としていたわけではなく手段として捉え、この領域ならこの設計でいい感じに開発、運用していけるんじゃないかと色々分析してはいました。

しかし、案の定スッとうまくいくわけもなく問題は往々にして発生しました。

  • ビジネス要件がコロコロ変わる
  • 現在のビジネス状況だと着手しても微妙だから中止。代替案出したけどそれも中止。
  • 仮説検証段階だから開発コストはできるだけ抑えたい
  • なるべく自社で開発するんじゃなくて外部依存のソフトウェアやAPIを活用して運用コストを減らしたい
  • そもそもコアドメイン探してる最中

1番印象的だったのが圧倒的に最後の「そもそもコアドメイン探してる最中」でした。

スタートアップすぎてコアドメインがない状態

開発を始める前に、今どういうビジネスをしていて、どういう方向を目指していきたくて、どういう問題を解決していきたいのかということの詳細は聞いていましたし、そこの納得感も凄くありました。

ただ、それらを解決するビジネスアイデアがまだまだ未熟であり、それをコアとしてこれからやっていくかどうかはこれからの仮説検証とその結果で方向が180度変わっていくということでした。

自分はこれまで、ある程度完成されたシステムの新機能開発、保守、リプレイスの経験が多く、どういうビジネスが継続的に利益をもたらしていて、それが「どういう背景でコアなビジネスになっているのか」ということに関してはあまり意識していませんでした。というかできていませんでした。

なるほど、今はコアドメインを模索してる段階なのか…と腹落ちした瞬間からはなるべく以下を意識するようになりました

  • 作って捨ててを繰り返せるような設計にする(スクラップ&ビルド)
  • 経営側の意見と今何をしようとしてるのかをめちゃくちゃ聞く
  • アウトプットだけではなくアウトカムを重視する
  • 目的だけ考えるんじゃなくて問題をよく捉える

今まで技術的なことばかりに頭を使ってきたエンジニア人生だったので、最初は脳の使い方がわからず一瞬でメモリが埋まってパンク状態でした。

作って捨ててを繰り返せるような設計にする(スクラップ&ビルド)

もちろん変更容易性がめちゃくちゃ悪いと開発がしにくすぎるので最低限の品質は意識していましたが、ガチガチに設計したりコードを書くのはやめました。

コードや設計は捨てることを前提に、早く市場に出して仮説検証することを最重要視しました。これを意識し出してから副産物としてリリースサイクルも早くなりました。

経営側の意見と今何をしようとしてるのかをめちゃくちゃ聞く

最初は経営側のMTGは任意参加でしたが自分がドメインエキスパートになるぞという気概で経営MTGなどにはできるだけ参加するようにしました。

これのおかげでやるべきこととやらなくていいことを切り分けて課題解決の精度を上げることができました。無駄なことに開発の時間を使わずにも済みました。

アウトプットだけではなくアウトカムを重視する

これは今までも意識しながら開発していましたが、会社のビジネスが今までよりも段違いに自分ごとになりその意識レベルも上がりました。

機能Aが必要になった際は、機能Aがリリースされユーザーに使われた時に

  • どういう状態になっていて
  • どういう結果になっていれば良いか
  • またそれは定量的に測ることができているか?

ということを考える習慣がつきました。

(データ基盤とデータ分析の経験、知見がもっとあればなぁ…と何度思ったかわかりません)

目的だけ考えるんじゃなくて問題をよく捉える

自分は割と目的から考えるタイプでそれなりに得意な方かなと思うのですが、問題に関してはあまり詰めて考えられていなかったです。

目的は合っていても解決しようとしている問題がブレていればほとんど意味がないです。

これはアーキテクチャにも当てはまることで、DDD自体が目的になって解決しようとしている問題に目を向けなかったら本末転倒で意味ないよね…?みたいなことは昔よくありました。

解決しようとしている問題を注視すれば今までやろうとしていたことは本質的では決してなく、他の方法がより最適ではないか?という結論に至り舵を切ることなんて何度もありました。

しかもその代替策の方がよりスマートで早く仮説検証できる可能性が高いことが多いんですよね(これは感覚値)。

まとめ

スタートアップでの開発はスピード感が早すぎて色々と難しい。でも楽しくもあるので引き続き壁にぶち当たりながらも乗り越えていきたい。