« ER図レビューの3つのポイント | トップページ | アジャイルではなく「プロトタイピング」を »

2016.07.19

開発案件の「適正サイズ」を考える

 「4000億円がパー」とも噂される某銀行のシステム刷新プロジェクトのデスマーチぶりが話題になっている。当事者ではないのでよくわからないが、議論の余地がないのが「開発対象がとにかくデカい」という点だ。どう考えてもひとまとまりで「設計・施工・引っ越し」が可能な大きさを超えている。種々雑多な問題が生じることは、デカすぎる開発対象を切り出した企画段階ですでに運命づけられていたのではないか。

 銀行のシステムに限らない。製造業向けの生産管理システムや卸売業向けの販売管理システムといった基幹業務支援システム(業務システム)の開発案件には、共通の「適正サイズ」があると私は考えている。そのサイズを超えるようなものがあれば、「大型案件」と言うよりは「不適切案件」とみなすべきではないか。

 「システムのサイズ」ではなく、「1回あたりの開発範囲」の話であることに注意してほしい。業務システムの大きさは、当然ながら個々の事情で違っている。しかし、その全体サイズに関係なく、開発対象を切り出す際には「案件としての適正サイズ」というものがあるのではないか。いかに小さ目の開発対象を切り出し、既存部分との連係を確保しつつ全体性を維持してゆくか。それが企画担当の腕の見せどころだ。データHUBマイクロサービス等、参考になる知見は今や豊富にある。

 ではじっさいのところ、「開発案件の適正なサイズ」はどれくらいなのか。「テーブル数が100本を超えない」というのがひとつの目安になるかもしれない。私の経験からも、上手くいった開発案件は大きくてもテーブル数100本を超えることはなかった。

 ただしこれには「上手くDB設計すれば」という前提がある。上手く設計すればテーブル数100本となるデータ処理要件に対して、下手に設計すれば本数が倍以上だったり半数以下だったりということが起こり得る。DB設計が拙ければ、テーブル数に関係なくデスマーチが約束されていることは言うまでもない。それゆえに「上手くDB設計して、かつテーブル数100本以内」なのである。

 この主張を支える現代的な根拠がある。「上手くDB設計して、かつテーブル数100本以内」であれば、現在の実装技術を活用すればひとりで設計・実装できてしまう。私の経験では、業務システムが有するデータ処理機能の数は、テーブル数に3.5~4.0を掛けた値になる(次表参照。いずれも拙作CONCEPTWAREでの例)。上手く設計されたDBが100本のテーブルを含むとすれば、そのDBを処理するデータ処理機能は多くて400本。それくらいなら、現実的な工期で実装までをひとりで賄える(ただしシステムテストの要員は多ければ多いほど良い)。しかし、機能数400を超えたら、さすがにいろいろと手分けせざるを得ないだろう。

                 テーブル数 機能数 比率
受注生産型生産管理システム   58   205  3.5
専門卸売業販売管理システム   65   261  4.0
組立加工型生産管理システム   99   377  3.8

 つまり、サイズが適切であれば設計と実装の分業が要らない、ようするにぜんぶ自分で設計してぜんぶ自分で実装できるゆえに、桁違いの効率で開発できるということだ。契約単価が高くても、クライアントにとっては安価で済むので、準委任契約も結びやすい。そうなれば仕様の妥当性を高めるためのプロトタイピング手法もとれる。これが、ひとりかごく少数の精鋭による開発――「おひとりさま開発」の効果である。なお、この手法に対して「大型案件には通用しない」という批判があるが、そもそもデカすぎる案件は企画段階で失敗している可能性を疑ったほうがいい。

 では、実装技術の発展ゆえにコンパクトな開発体制で済む時代であるにも関わらず、いまだに人海戦術を基調とする不適切案件(大型案件)が跋扈するのはなぜか。現場感覚や実装技術の発展とは関係なく、多くのベンダーが大型案件を欲しがるからだ。彼らにとっては「小さ目に切り出して、おひとりさま開発」など言語道断で、より多い人員を投入しなければ売上も稼働率も稼げない。そのような事業特性を持つベンダーが関われば、案件は無駄に大型化する。

 そのような不合理を認める意見もある。膨大な数の技術者に食い扶持がまわるゆえに大型案件は是認される、というものだ。理屈としてはわかるが有効な議論とは言い難い。所属組織が違っていれば、また他の業界であれば、もっと良い形で社会貢献できたかもしれない若者たちが、多重下請構造の底辺で心身をすり減らしてゆく。ただでさえ生産年齢人口が減っているというのに、あまりに大きな社会的損失だ。

 そもそも、「膨大な数の他人の就労のために、ある種の非効率を認めるべき」といった主張は、高尚かつ観念的すぎて受け入れがたい。実装技術の発展が止まらないという冷徹な事実を前にして、我々は他人のことなどにかまわずに「自分自身」やせいぜい「自分の会社」を処することで精いっぱいなのが現実だ。その結果として業界全体の合理化も、ゆっくりではあっても着実に進んでゆく。このことに早めに気づいた技術者やベンダーはさいわいである。

 1案件に妥当なサイズがあることに気づくことも、合理化にともなってあらたに求められる知恵のひとつなのだろう。「テーブル数100本以内」の正しさはさておき、あなたが関わっている案件はやたらとデカくないだろうか。やたらと要員がいないだろうか。そうだとしたらそれを誇るのではなく、危うさを感じたほうがいい。


このブログでの関連記事:
もう「チーム開発」には戻れない
基本設計を分担してはいけない

|

« ER図レビューの3つのポイント | トップページ | アジャイルではなく「プロトタイピング」を »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 開発案件の「適正サイズ」を考える:

« ER図レビューの3つのポイント | トップページ | アジャイルではなく「プロトタイピング」を »