変幻する実行可能知識 13X, Y, Zソフトウェア開発における「生産性」とは何かを定義するのは難しい. 生産性とは基本的には「あるアウトプットを得るのにどれだけのコストを掛けたか」という尺度だ. さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが, じゃあ代わりに何を使えばいいのかは今だはっきりしない. ユースケースやストーリで測る考え方もある. そんなものは存在しないという意見すらある. そういう場合には視点を一レベル上げて考えてみよう. つまり, ソフトウェア開発だけ考えているから分からないんで, そもそもこのソフトウェアを作ることになった原因から考えてみようということだ. このソフトウェアを作ることによっていくら得できるのか? ユーザあるいは顧客にとっては, X円で発注したソフトウェアによってY円売上が上がれば (あるいはコストを下げられれば), Y/XがROI (投資に対する収益) と言われる. もちろんこの場合にはソフトウェアだけが素晴らしくても駄目で, それをどう使うかが問われる. 一方開発者にとっては, X円で受注したソフトウェアをZ円で作れれば, X/Zが開発効率あるいは収益率ということになる. 現状では顧客側はXをいかに低くするかに腐心し, 開発側はXをいかに高くするかにしのぎを削っている. このゲームはどちらかが勝てばどちらかが負けるゲームだ. そして多くの場合, 開発者は不利な戦いを強いられている. しかし別の考え方もある. Yを高くし, Zを低くしてもよいのである. 開発者にとっては使い方次第でYを高くできるような可能性を持ったソフトウェアをできるだけ低いZで作れるようにすればよいということになる. このゲームではどちらもが勝者になれる可能性がある.  Zを低くするにはどうすればいいだろうか? 開発ツール? ちゃんとしたプロセス? CMMI? それもいいけど, Zを10%や20%下げるだけではしようがないのだ. 半分か1/3, できれば1/10にすることはできないだろうか? Yはどうだろうか? Yを高くするためにはいろいろな要素があるが, そのうちのひとつにスピードがある. 顧客にとって「今すぐ」(例えば1ヶ月後に) このシステムができればそれはとてつもなく大きなビジネスにつながるけれど, 半年後にできてきたのでは何の意味もない, というような事例はますます増えているような気がする. つまりスピードに関してはある閾値を境にして連続的ではなく断続的な価値のカーブを描いている場合が多いのである. 開発者にとっては開発スピードを10倍にできるか? ということだ (ただ単に開発メンバの数を10倍にしても開発スピードが10倍にならないことはすでにはっきりしている). 僕はこれらへの解答のひとつがモデル駆動開発であると考えていたし, もちろん今もそう考えている. ただし, Mark Soley流のMDAではZを1/10にもYを10倍にもできそうにない (そもそもMDAはそんなことを目指しているわけではないのだろう, きっと). Steve Mellor流のxUML (「Executable UML - MDAモデル駆動型アーキテクチャの基礎」スティーブ J. メラー, マーク J. バルサー, 2003, 翔泳社) ならできるかもしれない. でもxUMLはこの業界では単に好事家の趣味か暇つぶしとしか見なされていない:-) どうやらxUMLだけでは駄目なようだ. なぜだ. 「インクス流! - 驚異のプロセス・テクノロジーのすべて」(山田眞次郎, 2003, ダイアモンド社) はそういう僕らの視点からすると, 謂わば金型作りにおけるモデル駆動開発のように見える. 金型とはたい焼きの型のようなものだ. 何かモノを量産しようとしたら必ず金型が必要になる. 日本は世界の金型の42%を作っており, それが日本のモノ作りの底力を支えているのだという. しかもその金型を作っているのは蒲田や川崎にある, 平均年齢50代の職人30人ほどを抱える7000の中小企業なのだ (ここにはソフトウェア開発との共通点と相違点が見て取れるが, それはちょっと後回しにしよう). その金型を作るのには通常は40日以上かかるらしい. まず設計現場では二次元CADで二次元の図面を書いてそれを紙に印刷し, 試作屋さんに渡す. 試作屋さんはそれを読んで三次元化し, NC (数値加工) データを起こす. NCマシンがNCデータを読んで粗型を起こし, それを加工していく. 何段階もの変換過程があるから, その間には何回もの問い合わせや試行錯誤がある. また各段階には職人の長年の経験知によるノウハウが活かされている (逆に言えば職人の経験値がなければ作れない). 本書はその40日以上の工程を10日から数日までに短縮するテクノロジ - プロセス・テクノロジをいかにして作り上げていったかという物語である. そのテクノロジの肝は次のような点にある.
(1)ではプロセスを分析して, ガント・チャートを作り, クリティカル・パスを抽出する. この考え方は例えばトヨタ生産方式 (リーン) やクリティカル・チェーン (制約理論) の考え方と通底している. そして工程をできるだけ細分化する. それによって並列化と非同期化を最大にすることができる. これはXPと同じ考え方だ. XPではプロジェクト全体を分析/設計/実装/テストという大きな逐次的な工程に分けるのではなく (この場合各工程の長さは1~数ヶ月で, かつ工程は並列化できない), テスト/コーディング/リファクタリング/統合という数時間~数日の並列的な工程に分解する. (2)ではできる限り変換過程を短縮する. つまり最初から三次元ソリッド (パラメトリック) CADを用いて三次元ソリッド・モデルを描き, この三次元ソリッド・モデルから光造型装置によって直接モノ (プロトタイプ) を作り出す. これによって二次元から三次元, ワイヤ・フレーム・モデルからサーフェイスあるいはソリッド・モデル, 設計データからモノといったような変換過程を極力減らす. もちろん図面を紙に出すことはしない. 変換にかかる余計な時間/工数を省略するのと同時に, 最初に設計者が持っていたはずの「設計の意思」が損なわれてしまわないようにするためである. 「Executable UML」の帯のキャッチ・コピーに倣って言えば「形にならないCADデータは, 単なるスケッチにすぎない」のだ. (3)では細分化された工程のうち, 人の判断が必要な工程とある規準に従えば人の判断が不要になる工程を峻別し,判断が必要な工程をできるだけ減らし, 判断が不要な工程は自働化する. 昨今「暗黙知」が大流行ではあるけれど, 暗黙知が暗黙知のままでは大した役には立たないのである. これを人の仕事を機械が奪っていくと考えればつまらないけれど, 人はより創造的な (?!) 仕事に時間を費やせると考えることもできる. 実際, 我々はそのような暗黙知をコンパイラやツール, フレームワークの形で形式化してきたのだ. もちろんこのやり方がそのままソフトウェア開発に使えるかどうかは分からない. ソフトウェアと金型にはいくつかの共通点もある. 例えばそれが実際の製品そのものではなく, 製品 (あるいはサービス) を産み出すための母型となるモノである点, またそれ自身は量産されるものではなく一点ものである点, 現状では職人 (しかも本当の職人の多くは下請けの下請けの下請けだ) の暗黙知に多くを依存している点など. 一方で多くの相違点もある. 金型のマーケットや競合相手は世界であるけれど, (特にIT系) ソフトウェアのマーケットや競合相手はほぼ国内でしかない. だから切迫感も金型業界や製造業界ほどはないように思える. また業界自身も職人 (プログラマ) もまだ若く, 蓄積された経験知/暗黙知はまだまだ少ない. |