« 設計情報のバージョン管理を合理化する | トップページ | DBの複雑さとアプリの複雑さ »

2015.10.17

基本設計を分担してはいけない

 プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。

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

 なぜか。業務システムにはアーキテクチャ(意図された構造)が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と機能構成と業務構成は密接に関係しており、相互に矛盾のない形で構造化される必要がある。これらを別々の担当者が扱えばちぐはぐな形にまとまることが避けられない。ようするに手分けして基本設計などすれば、システムの全体像(デッサン)はたちどころに歪んでしまう。

 にもかかわらず基本設計が安易に分業されがちなのはなぜか。そうするためのいくつかの根拠がありそうだ。まず、「スキル上のリスク分散」のためだったりする。何人かで分担すれば、設計スキルが劣悪な要員が含まれていたとしても、助け合い精神や文殊の知恵といった効果ゆえに、成果物はまともになるだろう。そんな期待があるのではないか。

 残念ながら、その期待は大ハズレに終わる。ある映画プロデューサーが、腕のいい脚本家を確保できなかった。そこで、素人の脚本家を10人集めて、物語の始まりから10分毎に区切って分担させた。多少心配はあったが、助け合い精神や文殊の知恵によってすぐれた脚本が生み出されると考えたからだ。あなたはそんな映画をお金を払って観たいと思うだろうか。まあ、複数の脚本家が協働するケースはある。しかしそれはあくまでも「有能な人物によるコラボ」なのであって、人数だのみの素人集団とはわけが違う。けっきょく、この種の課題を何人かで手分けすれば、その中でもっとも低いスキルレベルに合わせた成果として完成する(または完成さえしない)と覚悟したほうがいい。

 私は長年の経験から、業務システムの設計には映画制作や建築設計などと同様にクリエイター的な素質が良くも悪くも求められることを実感している。ひとまとまりの手がかりが与えられていて、それらを手順に沿って分析すれば唯一の正答にたどりつける――そのように機械的・事務的な過程ではない。設計者は設計上の価値を生み出すために、専門家として身につけたイディオムやパターンを駆使しながらも、さまざまな局面で創意や工夫を凝らさねば仕事をまっとうできない。

 それを遂行できる要員を見つけ出し起用することが、システム企画における初期の最重要課題である。これに失敗したときに人数でカバーするようなことをすれば、事態はさらに悪化する。有能な主任設計者を確保できないのであれば、映画だろうが業務システムだろうが国立競技場だろうが、プロジェクトそのものをあきらめたほうがいい。

 「スキル上のリスク分散」と似たような根拠として「欠員リスクの緩和」というのもありそうだ。一見合理的に思えるが空論である。なぜなら、基本設計をふつうにこなせるような人材はただでさえ少ないからだ。それはまるでマイケル・ジャクソンのコンサートで本人の欠員リスクを考慮して、歌手を余分に確保しておくようなものだ。マイケルが急きょステージに立てなくなったときに、集まったファンが納得するにはジェームス・ブラウンくらいを登場させる必要があるだろう。そんな大物を「余分」に確保しておくなどどう考えても無理な話だ。ようするに「欠員リスクの緩和」は、低スキルの要員を混ぜ込んで工数を水増しするための下手な言い訳でしかない。

 「育成のため」という言い訳もありそうだ。じっさい私が「ひとりか少人数で設計・開発すべきだ」と主張すると、「育成のことを考えていない」と批判されたりする。しかし私は工学の話をしているのであって育成の話をしているのではない。当然ながら技術組織の運営にあたって育成のことは考えるべきだが、それは工学とは異なる課題であって、これらをごっちゃにしてはわかることもわからなくなる。だいたいOJTはプロジェクトのパフォーマンスを確実に落とすもので、コスト計画上それが許されるのであればやればいいだけの話だ。なおその余分なコストは投資であって、客先への見積りに上乗せされるべきでないことは言うまでもない。

 基本設計が安易に分担されるもうひとつの理由。それは、ExcelやWordやパワポで設計しているからではないか。その種の汎用ツールを使って設計する限り、作業効率がものすごく悪い。それで設計の見積工数が膨れ上がって、多人数で分担させようと発想されてしまうのではないか。しかも汎用ツールを使って設計すれば、設計の妥当性が見えにくい。それゆえに求められる提出物が増える。それらの余計な資料を作るためにも、多人数を投入しようと計画されそうだ。かくして設計はエンジニアリング的要素の希薄な「人海戦術による資料作成祭り」と化す。

 もちろん基本設計は少ない工数で済む仕事ではないが、その様相はむしろ、多様な要素をどう構成すべきかについて「専門家が徹底的に考える」ことで特徴づけられる。X-TEA ModelerXupperといった専用のCADツールを使ってみればわかることだが、システムの「デッサン」を構想して描き出すために(専門性は要るが)時間はたいして要らない。ただしそのデッサンを何度も修正しながら、より良い落としどころを探り続ける必要がある。それがエンジニアリングというもので、何人かで手分けしても楽になるわけではない。この特性を理解するためにも、大勢で寄ってたかってExcelやWordやパワポで設計するやり方はもうやめたほうがいい。

 まとめ。基本設計はひとり(またはごく少数)の精鋭によって実施可能だし、効率や品質を確保するためにそうすべきだ。そのために必要なものは、訓練された専門家と、プロ用のCADツールである。そのうえで、設計成果に対するピアレビューを徹底しよう。複雑で巨大なシステムのあり方をツールが端的に示してくれるため、第三者が設計の妥当性を評価しやすくなるからだ。そしてなによりもレビューされることで、この仕事につきまとう孤独感と不安が和らぐからだ。

|

« 設計情報のバージョン管理を合理化する | トップページ | DBの複雑さとアプリの複雑さ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 基本設計を分担してはいけない:

« 設計情報のバージョン管理を合理化する | トップページ | DBの複雑さとアプリの複雑さ »