「疎結合だけが正義？」あえての密結合でスピードと品質を両立するスタートアップの開発ガイドライン
MedicalShift代表、開発責任者の堀です。
当社ではプロダクトの成長につれて、コードの非一貫性やコミュニケーションのズレが目立つようになってきました。
その中でも特に「将来をどこまで考えるか？」は頻繁に議題に。
疎結合を推奨する声は多いけど、スタートアップに本当に当てはまるのか？ 負債を溜めるのも怖いし…。
その問題を解決するべく、疎結合と密結合、スピードと品質のバランスを意識した開発ガイドラインを作りました。
同じ悩みを抱えるスタートアップの方にも、ヒントになれば嬉しいです！
あと全ポジション絶賛採用中ですので、気になった方は気軽にご連絡ください！
※ 本ガイドラインは、以下の外部の方々のご協力を得て策定しました。
・五十嵐さん (@igaiga555) 「パーフェクトRuby on Rails」共著者。特にRails関連でサポートいただきました。
・その他に、複数の友人エンジニアに色々と相談に乗ってもらいました
以下『開発チームの基本姿勢ガイドライン 』の短縮・抜粋版です。
本ガイドラインに通底する考え
以下の式をヒントに、短期と長期のバランスを見ています。
直近1ヶ月の生産性 + Σ (Nヶ月後の生産性の期待値 ÷ (α ^ N))
α: 将来生産性の割引率（プロダクトやフェーズに応じて変化。大きいほど、未来の生産性の現在の価値が下がる）
厳密に数値化は難しいですが、式からこんな示唆を得られます。
短期成果と長期的価値の両立
目先のスピードを失わない程度に、将来の負債も溜め込みすぎないラインを探る事業ステージ等に応じた割引率(α)調整
成長期や実験フェーズなら短期重視、長期視点が欠かせない事業なら将来投資を多めに確率 × インパクトで投資配分を決定
確率が低いシナリオに過度に備えすぎない。一方、確度が高くインパクト大なテーマにはしっかり準備して高いリターンを狙う
策定の狙い/背景
各示唆はいずれも当たり前に言われることですが、あえて数式化することで全体観を明確にしてコミュニケーション齟齬を減らす目的で導入しました
仕事の進め方
1. Comply or Explain（まず従い、例外時には説明する）
整合性を保ちつつ、現実の例外や特殊ケースに以下方針で対応します。
原則的な流れ：
Comply（準拠）：まずはガイドラインに従い、整合性を確保
Explain（説明）：もし妥当でないと感じる場合は、なぜ従わないのか、その背景・理由・意図を明確に共有する。
2. 驚き最小の法則
「利用中の言語/FWに精通していて理解力も高いが、プロジェクト固有の詳細には慣れていないエンジニア」を想定し、その人が混乱しないコード・ドキュメント・PRを目指します
※ 運用を間違えると経験則に振り回される可能性も高いので注意
(参考: MatzのQouraでの回答)
3. ビジネス理解と成果の重視、その上での技術チャレンジ
事業理解がプロダクト品質を高める
成果を起点とした技術チャレンジ
まずは事業の成果を出し、そこから将来投資として新技術を試す
その他の指針（項目だけ紹介）
4. 困ったときは（社内外の）専門家に相談する
5. 教条主義ではなく実用主義
6. 相手視点を重視したコミュニケーション
7. 論点と仮説を明確にして合意をスムーズに
策定の狙い/背景
以下に注意して策定しました
・杓子定規になりすぎず、ルーズにもならない適度な強制力
・ビジネス指向、発信者責任のコミュニケーション、実用主義を主軸に
共通のコーディング指針
具体的なコーディングルールや規約は、基本的に各フレームワークや言語の一般的なルールに従います。
変更の先取りをしすぎない：
将来を過度に見据えて抽象化し、可読性や柔軟性を損なわないようにします。具体的には、過剰なDI、特定シナリオの決め打ちに注意します。密結合を過度に恐れない：
「どのシナリオでどう困るのか」「その発生確率はどのくらいか」を冷静に判断し、時にはあえて密結合を採用しますテストはカバレッジより「ドメインの重要ロジック」を大事に：
テストを書くのは当然として、「ビジネスやドメインに直結する重要ロジック」を厚く検証することを網羅性より重視します。テストが難しい箇所は、設計や依存関係を見直すきっかけと捉え、継続的に品質を高めます。
その他の指針（項目だけ紹介）
宣言的で明快なコード (実行速度よりもまずは可読性)
呼び出し側で読みやすいコード
策定の狙い/背景
現在のスピードと将来の拡張性のバランスを意識しています。
そのうえで「密結合を過度に恐れない」というスタンスが、当社の現状では重要だと判断しました。
Railsにおける設計方針 (要点)
Railsにはさまざまな流儀が存在し、社内でもしばしば議論や混乱を生んできため、Rails固有の指針を設定しました。
Rails Wayを最大限活用する：
Railsは密結合アーキテクチャを意図しているため、その狙いである初期フェーズの高い生産性を活かすFat Modelの許容と分割のタイミング：
モデル上にドメインロジックを集約し、Rails慣習に沿ったファイル構造を維持します。
Modelが複雑化し、validationロジックなどで分岐が増えそうなときにはComply or Explainに沿って切り出しを検討しますServiceクラスを極力利用しない：
役割が曖昧になるため、設計を明確化する方向へRESTfulな設計への準拠：
リソースへのCRUD操作を通じてのみ、ビジネスロジックを実装します。
なお、リソースはDBのテーブルと1:1対応している必要はありません
Rails以外の技術への展開
当社がRails以外のフレームワークや技術を採用する場合も、各技術のベストプラクティスをまずは尊重します
そのうえで、事業目標やチーム構成に合わせ、実用的な判断を下します
継続的な改善とアップデート
このガイドは硬直的な「教科書」ではありません。
プロダクトやビジネス、チーム構成が変われば、そのたびに振りかえりを行い、「今でもこの方針でいける？」と問い続けながらアップデートしていきます。
最終的なゴールは、ビジネス価値を最大化しつつ、エンジニアが気持ちよく働ける環境をつくること。
このガイドが社内の迷いを減らすと同時に、「ここで働いてみたいな」と思ってもらえる魅力の一端になれば嬉しいです。
最後に
当社は代表の私を除くと、社内エンジニア2名、社外エンジニア3名という体制で各プロダクトを運営しています。
これからどんどん開発チームを拡大していくフェーズです。バックエンド/フロントエンド、メンバー/VPoE/テックリード/CTO 全ポジション募集中です。
事業的にも開発組織的にも、ここからが一番おもしろいタイミングですので心惹かれた方がいらっしゃれば、ぜひ採用情報ページをご覧ください。
新たな仲間と出会えることを楽しみにしています！