こんにちは、阿久梨絵です。
「このシステム、なんでこんな作りになってるの？」
「もっといい設計があったはずなのに…」
そんな疑問を抱いたことはありませんか？
実はその裏には、技術的な制約ではなく“ 人間関係の力学 ”が潜んでいることが少なくありません。
今回は、システムの品質と“関与者の力関係”について掘り下げてみます。
技術的に“正しい”設計が通らない理由
理想的なアーキテクチャや設計方針があっても、それが採用されるとは限りません。
なぜなら、システムは“人間の合意”で成り立っているからです。
・「この仕様、営業部長が強く推してるから変えられない」
・「インフラチームの意向で、クラウドはNGになった」
・「ベンダー側の都合で、古いミドルウェアを使い続けることに…」
こうした“非技術的な力”が、設計や実装に大きな影響を与えるのです。
システムに潜む“見えない構造”＝組織構造
これは「コンウェイの法則」にも通じます。
組織が設計するシステムは、その組織のコミュニケーション構造を反映する。
つまり、組織の縦割り・権限構造・発言力の強弱が、そのままシステム構造に現れるのです。
・サービスごとにAPI仕様がバラバラ → チーム間の連携が弱い
・データベースが分断されている → 部門ごとにデータを囲い込んでいる
・UIが一貫していない → デザインチームがプロジェクトに関与していない
“誰が決めるか”が“どう作るか”を決める
プロジェクトにおいて、「誰が意思決定権を持っているか」は極めて重要です。
・技術リーダーが強い → 技術的に洗練された設計になりやすい
・営業部門が強い → 要件がビジネス寄りに偏る
・発注者が非技術系 → UIや運用性が軽視されがち
つまり、システムの良しあしは“設計思想”ではなく“力関係”で決まることがあるのです。
“良いシステム”を実現するために必要なこと
1. 技術者が“交渉力”を持つこと
・技術的な正しさを、ビジネス言語で説明できる力が必要です。
2. 意思決定構造を可視化する
・誰が何を決めているのか、権限構造を明文化することで、責任の所在が明確になります。
3. “全体最適”を語れる人をプロジェクトに入れる
・各部門の利害を調整し、システム全体の整合性を守る役割が不可欠です。
まとめ
システムの品質は、コードや設計図だけでは語れません。
その背後には、組織の構造・文化・力関係といった“見えない設計図（ 人間関係の力学 ）”が存在します。
だからこそ、エンジニアに求められるのは技術力だけでなく、構造を読み解く力。
「なぜこの設計になったのか？」を問い直すことで、
より良いシステム、より良いチーム、そしてより良い未来が見えてくるはずです。
阿久梨絵でした！
