「基本設計を分担してはいけない」わけねーよという話

こういう話をするときに前提というか設定というかそういうのが雑なままで進めるとさっぱり話のフォーカスが合わない。という話になっている時点で「そりゃ分担したら上手く行かないよな」と思ってしまうわけで、つまりこの話は定量的・定性的な分析ではなくて個人の体験談なんだろうな、と思った次第。

私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。

基本設計を分担してはいけない: 設計者の発言

もういきなりわからないのが「何人もの」で、１人じゃないとダメなのか、何人までならいいのかとかそういうどうすべきかの話がわからず、DB設計がインフラの話なのかモデルの話なのかネーミングの話なのかもわからない。え、それ全部一人でやんの？んなわけないよね。出来るとしたら総工数どのくらいのシステムイメージしてんの？業務設計の基本設計とかってそもそも業務要件の落とし込みだよね分担出来んじゃねーの？

なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。

あーこれあれか、アーキテクチャ決めないまま基本設計突入すると死ぬってやつか。知ってるしやったことある（尻拭いを）。でもこれは基本設計を分担してはいけない理由ではなくてアーキテクチャを決めないまま基本設計に突入してはいけないって話でしょ。要はグランドデザインできてねーってことだよね。MECEってなんだよ基本設計かよそれとか。

また、DB構成と機能構成と業務構成は密接に関係しており、相互に矛盾のない形で構造化される必要がある。これらを別々の担当者が扱えばちぐはぐな形にまとまることが避けられない。ようするに手分けして基本設計などすれば、システムは「デッサン」のレベルでたちどころに狂ってしまう。

DB構成？構成って何？インスタンスが複数あるとかクラスタになっているかとかそういう奴？そういうのを基盤領域とか業務共通領域で抽象化して業務本丸には意識させない設計にするとかそういうのが基本設計でありかつ基本設計をする前に決めておくべき全体方針であってそれを決めているから役割分担しても齟齬が生じないとかそういう話じゃないんだっけ。
システムがデッサンのレベルで狂ってしまうとかってアレかデッサンもしないで基本設計してんのか。

とまあずっとこの調子で書いてあることは別にそんなに間違っているとは思わないんだけど、基本設計のレベルで大事なことが決まってないのに役割分担をしてかつ領域間の整合性をとらないという設定そのものが失敗プロジェクトの設定であるし、そうじゃない多くのプロジェクトは文字通り「基本設計を分担して」遂行しているものだ。