開発コストと工数を下げるためのアイデア：ソフトウェア開発をちゃんと考える（1）

　本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部）

生産性向上のメカニズム

　ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。

　そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分からないのであって、そもそもこのソフトウェアを作ることになった原因から考えてみようということだ。このソフトウェアを作ることによっていくら得できるのか？ ユーザーあるいは顧客にとっては、X円で発注したソフトウェアでY円売り上げが上がれば（あるいはコストを下げられれば）、Y/XがROI（投資に対する収益）といえる。もちろんこの場合にはソフトウェアだけが素晴らしくても駄目で、それをどう使うかが問われる。一方開発者にとっては、X円で受注したソフトウェアをZ円で作れれば、X/Zが開発効率あるいは収益率ということになる。

　現状では顧客側はX（発注額）をいかに低くするかに腐心し、開発側はX（受注額）をいかに高くするかにしのぎを削っている。このゲームはどちらかが勝てばどちらかが負けるゲームだ。そして多くの場合、開発者は不利な戦いを強いられている。しかし別の考え方もある。Y（発注側の売上高とか）を高くし、Z（開発者の開発コスト）を低くしてもよいのである。開発者にとっては使い方次第でYを高くできるような可能性を持ったソフトウェアをできるだけ低いZで作れるようにすればよいということになる。このゲームではどちらもが勝者になれる可能性がある。

　Zを低くするにはどうすればいいだろうか？ 開発ツールの導入による効率化？ ちゃんとした開発プロセス？ CMMI？ それもいいけど、Zを10％や20％下げるだけではしようがないのだ。半分か1/3、できれば1/10にすることはできないだろうか？

Xにこだわるとゼロサムゲームに陥る

　Yはどうだろうか？ Yを高くするためにはいろいろな要素があるが、そのうちの1つにスピードがある。顧客にとって「いますぐ」（例えば1カ月後に）このシステムができればそれはとてつもなく大きなビジネスにつながるけれど、半年後にできてきたのでは何の意味もない、というような事例はますます増えているような気がする。つまりスピードに関してはある閾値を境にして連続的ではなく、断続的な価値のカーブを描いている場合が多いのである。開発者にとっては、開発スピードを10倍にすることが課題となる（しかし、単に開発メンバーの数を10倍にしても開発スピードが10倍にならないことはすでにはっきりしている）。

工程日数短縮のプロセス

　僕はこれらへの解答の1つがモデル駆動開発であると考えていたし、もちろんいまもそう考えている。ただし、（米OMG会長である）マーク・ソーリー流のMDA（Model Driven Architecture）ではZを1/10にもYを10倍にもできそうにない （そもそもMDAはそんなことを目指しているわけではないのだろう、きっと）。スティーブ J.メラー流のxUMLならできるかもしれない。でもxUMLはこの業界では単に好事家の趣味か暇つぶしとしか見なされていない）。どうやらxUMLだけでは駄目なようだ。なぜだ。

　「インクス流！ - 驚異のプロセス・テクノロジーのすべて」（山田眞次郎、2003年8月、ダイヤモンド社）はそういう僕らの視点からすると、いわば金型作りにおけるモデル駆動開発のように見える。金型とはたい焼きの型のようなものだ。何かモノを量産しようとしたら金型が必要になる。日本は世界の金型の42％を作っており、それが日本のモノ作りの底力を支えているのだという。しかも、その金型を作っているのは大田区蒲田や川崎市にある、平均年齢50代の職人（社員）が30人ほどの中小企業群（約7000社）なのだ（ここにはソフトウェア開発との共通点と相違点が見て取れるが、それはちょっと後回しにしよう）。

　金型を作るのには通常は40日以上かかるらしい。設計現場では2次元CADで2次元の図面を書き、それを紙に印刷し、試作屋さんに渡す。試作屋さんはそれを読んで3次元化し、NC（数値加工）データを起こす。NCマシンがNCデータを読んで粗型を起こし、それを加工していく。何段階もの変換過程があるから、その間には何回もの問い合わせや試行錯誤がある。また各段階には職人の長年の経験知によるノウハウが生かされている（逆にいえば職人の経験値がなければ作れない）。

　本書はその40日以上の工程を10日から数日までに短縮する技術（＝プロセス・テクノロジ）をいかにして作り上げていったかという物語である。その技術の肝は次のような点にある。

1. 工程（プロセス）を徹底的に分析する
2. 一気通貫の意思伝達過程を作る
3. 本質的に人間の判断が不要なところは徹底的に自働化する

　（1）ではプロセスを分析して、ガント・チャートを作り、 クリティカル・パスを抽出する。この考え方は、例えばトヨタ生産方式（リーン）やクリティカル・チェーン（制約理論）の考え方の基本と通底している。そして、工程をできるだけ細分化する。それによって並列化と非同期化を最大化することができる。これはXPと同じ考え方だ。XPではプロジェクト全体を分析／設計／実装／テストという大きな逐次的工程に分けるのではなく（この場合各工程の長さは1〜数カ月で、かつ工程は並列化できない）、テスト／コーディング／リファクタリング／統合という数時間〜数日の並列的な工程に分解する。

　（2）では、できる限り変換過程を短縮する。つまり最初から3次元ソリッド（パラメトリック）CADを用いて3次元ソリッド・モデルを描き、この3次元ソリッド・モデルから光造型装置によって直接モノ（プロトタイプ）を作り出す。これによって2次元から3次元、ワイヤ・フレーム・モデルからサーフェイスあるいはソリッド・モデル、設計データからモノといったような変換過程を極力減らす。もちろん図面を紙に出すことはしない。変換にかかる余計な時間／工数を省略するのと同時に、最初に設計者が持っていたはずの「設計の意思」が損なわれてしまわないようにするためである。「Executable UML」の帯のキャッチ・コピーにならっていえば「形にならないCADデータは、単なるスケッチにすぎない」のだ。

　（3）では、細分化された工程のうち、人の判断が必要な工程とある規準に従えば人の判断が不要になる工程を峻別し、判断が必要な工程をできるだけ減らし、判断が不要な工程は自働化する。昨今「暗黙知」が大流行ではあるけれど、暗黙知が暗黙知のままでは大した役には立たないのである。これを人の仕事を機械が奪っていくと考えればつまらないけれど、人はより創造的な（?!）仕事に時間を費やせると考えることもできる。実際、われわれはそのような暗黙知をコンパイラやツール、フレームワークの形で形式化してきたのだ。

　もちろんこのやり方がそのままソフトウェア開発に使えるかどうかは分からない。ソフトウェアと金型にはいくつかの共通点もある。例えばそれが実際の製品そのものではなく、製品（あるいはサービス）を生み出すための母型となるモノである点、またそれ自身は量産されるものではなく1点ものである点、現状では職人（しかも本当の職人の多くは下請けの下請けの下請けだ）の暗黙知に多くを依存している点など。一方で多くの相違点もある。金型のマーケットや競合相手は世界であるけれど、（特にIT系）ソフトウェアのマー ケットや競合相手はほぼ国内でしかない。だから切迫感も金型業界や製造業界ほどはないように思える。また業界自身も職人（プログラマ）もまだ若く、蓄積された経験知／暗黙知はまだまだ少ない。

　とはいえ、ここには興味深い並行性があるのも確かだ。メラーの会社の名前は（いまはメンター・グラフィクス社に買収されてしまったが）Project Technologyといった。片やこちらは「プロセス・テクノロジー」。われわれの対象はモノそのものではなく、モノを作り、モノを使う過程であるということなのだ。そしてそのツールとして、3次元CADや光造型装置に相当する何かをわれわれは手にできるだろうか。