DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

成本正史さん
マイクロソフト株式会社　デベロッパーマーケティング本部　マネージャ
1988年　大阪大学基礎工学部卒業。同年横河電機株式会社に入社。主にファクトリーオートメーションの分野でソフト・ハードの開発を担当。99年マイクロソフトに入社。COMや.NETに関する開発コンサルティングに従事した後、現在はアーキテクチャに関する技術啓蒙、中央省庁関連の各種団体活動への参加、アーキテクトを対象とした講演や各種メディアへの寄稿を担当

効率的な開発を目指しコンポーネント指向に
林
成本さんがメソドロジーを意識したのはいつ頃ですか。

成本
CASEツールを作った次のプロジェクトの頃からです。ファクトリーオートメーションを監視するソフトウェアをまたWindows上で作った時ですね。CASEツールもとにかく大変なプロジェクトだったんですが、そのときはメソドロジーを考える余裕がなかったんです。
苦労してそのプロジェクトが終わって、仕切り直して次のプロジェクトをやろうとした時に、今度は今までと同じやり方ではなくて「やり方をまず考えて、それに従ってやってみたらもっと効率がいいんじゃないのかな」と最初に思いつきました。
そのひとつが、今で言われる「テスト・ドリブン・デベロップメント」というものです。当時はもうＣ++は主流ですから、オブジェクト指向の考え方も当然取り入れたりしました。さらに言うと、コンポーネント指向ということで、ActiveXコントロールというのが当時あったんですけれども、そのActiveXコントロールをコンポーネントとして作って、それを組み合わせていくことで、スパイラルに業務的でより大きなビジネスコンポーネントみたいなものを作れるんではないかとも考えて、そういうアイディアを全部、その製品には盛り込んだんです。31歳の頃だから、７、８年前ですね。

林
まだ90年代末ですね。コンポーネント指向のはしりのころですか。

成本
そうですね。でも私の場合、本を見て勉強したわけではなくて、まったくのボトムアップだったんです。自分で考えた結果としてそうなった。
オブジェクト指向はもう流行っていたんですけれども、コンポーネントのほうはまだあまりなかったんです。せっかくこういう機能があるんだからと、ActiveXを調べていって「じゃあ、こういう使い方をしたらもっとスパイラルに、どんどん粒度を大きくしていって、作業性が高まるんじゃないの」というようなことを自然と思いついたわけなんですよ。

VBA＋ActiveXをFAに応用

成本
ちょっと自慢ぽくなりますけど、VBAというスクリプト言語を日本で始めて実装したのは、実は私なんです（笑）。VBAはライセンスを受けて自分の製品に組み込むことができるんですけども、私はそれを横河電機時代にやったんです。
それにプラス、ActiveXコントロールの組み合わせで、FAの分野で使ってみようと思いつきまして。

林
それは生産性が上がりますね。今までと全く違う世界になります。

成本
ええ、今まではプロプライエタリーな言語でやっていたものが、「VBAができる人であればFAのちょっとした制御は書ける」ということになりますからね。
VBAは非常によくできていて、これはあまり知られてないんですけども、VBAで書いたコードそのものをコンポーネントのように扱える機能もあるんですよ。工夫次第でそういうことができるんです。そこで僕が思いついたのは、監視対象をひとつのコンポーネントと見て、それを全部ActiveXコントロールで表現することでした。

林
全部を抽象化して最小値をとるということですね。

成本
そうです。ActiveXコントロールに対してVBAでそういう表現をすることによって、オン・オフや温度の制御などを全部できるようにした製品を開発したんです。それくらいからですね、メソドロジーを意識するようになったのは。

デザインパターンを調べてわかったこと

成本
次に、コンポーネントを使うにはデザインパターンみたいなものがあるということで、デザインパターンについて調べてみました。いまＭＳの社員だから言うわけじゃないんですけど、当時、COMと言われていたテクノロジーはそれ自体がデザインパターンをもとからインプリしているんです。だから「あっ、これってデザインパターンに従って作られているんだな」ということがその時にわかったわけですね。

林
やっぱりいいものっていうのは、そういうものなんですよ。あとから、「実は、すごいじゃないか」とわかってくる。

成本
僕は当時、「デザインパターンって新しいものだ」という認識だったので、それを適用してみようと思っていろいろ調べていたんですけど、実は、既にもう適用していたということだった（笑）。そのときは、「あれっ？」と思ったんですが、いま思えばそれも当たり前の話で、パターンというのはデザインパターンに限らず、成功例を集めてきて、それを「はい、これがパターンです」っていうものですから。何もないところから生まれるものではなくて、みんながやって上手くいったものをパターンとして取り上げているんです。新しいものじゃないんですよね。
だから、現場で非常に苦労している人から見れば、デザインパターンは当たり前のことなんですよ。

林
それは面白い出会い方をしましたね。

「デザインパターン」至上主義への疑問

成本
だからかもしれませんが、僕がいま懸念しているのは、今の風潮として、デザインパターンみたいなものが非常に祭り上げられているということなんです。「これからはデザインパターンだぞ」みたいにね。

林
それは極めて表層的な理解ですよね。

成本
そうなんです。いま「パターンを知っているのが賢い人」とかいうような風潮もあるんですけども、僕から言わせると、それはちょっと頭でっかちというか、「現場でやってきた人からみれば、別に普通のことですよ」と、ちょっと冷めた感じで見ちゃいますね。

林
「そんなこと、もともとやってますよ」と（笑）。でも、最近、概念先行で頭でっかちなソフトウェア開発者が増えているでしょ。

成本
増えています。だから、議論をしてもやっぱりそういう方向に行ってしまうんですよね。

林
まあ、言葉の部品というか、概念の部品だけが、そのもとを知らずに飛び交う会話になりますよね。でも概念の部品を使っている人は本当には理解していないので議論がかみ合わない。本当に理解するには時間がかかるんですよ。
だから「疲労試験」が必要なんです。成本さんのように現場でゴリゴリやって疲労してみて、本当の理解に行き着くわけですよ。

成本
ゴリゴリ加減が足りないんだと思います。

林
でも、ゴリゴリさえやればいいという話でもない。

成本
ええ、ずっとそれだけでは、やはりダメですね。

林
ゴリゴリの中から、創意工夫が生まれるというところが大事なわけです。苦労しているうちに「こんなことをやっていちゃだめだよな」というように、普通は考えますから。

成本
もっと楽な方法、いい方法はないかと思いますよね。

「ショートカット」と「手段の目的化」に惑わされるな

林
私はもちろん、成本さんもそう思うわけですが、今の人たちが本当に「ゴリゴリの中から創意工夫が生まれるんだ」と思うかどうか。

成本
それは、ちょっとわかりませんね。

林
今の人たちは「ショートカット世代」ですからね。ゴリゴリというのはどうも時間とエネルギーを無駄にするように見えるんでしょう。「そのゴリゴリ部分を簡単に学ぶ方法を教えてよ」みたいなことを言いそうです。それはその言葉自体、概念が矛盾しているぞと言いたくなる。

成本
全くそのとおりです。英語を勉強するときにも、「これを耳に当てて聞くだけで英語がしゃべれるようになる」というのに殺到する。あるわけがないじゃないですか、そんなものは（笑）。エンジニアとしては、地道にやっていく喜びの部分がすごく大事だと思います。

林
僕はエンジニアというのは、非常にスポーツの学習に近いものを持っていると思うんですよ。

成本
ああ、通じますね。

林
スポーツの世界では「３日間で100切れるゴルフ」とか「このビデオを見るだけであなたもウェーデルンで滑れます」とか言われたら、すごく怪しいじゃないですか。

成本
はははは(笑）。

林
ね、誰でも笑うでしょ。ところが「３日間、独習プログラミング」とかがあると、そっちにつられていくわけですよ。その結果、３日間では、かなりわからなかったということがわかるわけです。

成本
それはまだいい方ですよ。それでわかった気になってしまうと、本当に困ってしまうんです。要は、抽象的でも本質から外れていなければいいんですけど。本質的な部分がどこかということを知らずにしゃべっていて、どんどんずれていく人をよく見かけます。パターンを溺愛している。パターンに限らずそうなんですけど、手法を取り入れること自体が目的化しているんですね。

林
残念ながら、メソドロジー全般に言えることですね。手段が目的化しがちなのは。

成本
よくあるのは、MVCモデル教の信者みたいな人がいて「MVCじゃないともうダメだ」と言う。「じゃあ、何のためにMVCをやっているんですか」と目的を尋ねてみると「いやー、それはだってオブジェクト指向だから」とか「JAVAはMVCなんだよ」とか(笑)、それこそもう「MVCじゃないとダメ」という世界から出られない。その瞬間に「この人はちょっと危ないな」と思うわけですよ。

林
危ないですか(笑)。

成本
本質から全くずれてしまっている。要は、依存関係をきちんと整理するためにいろんなパターンがあるわけであって、それが別にMVCである必然性はないんですよね。それなのに方法やツールが目的化しているんです。

林
でもね、そういうのは多分なくならないですよ。「これさえあれば勝てる」みたいなのは永遠に人間を魅了し、そっちに走る人は絶えないんじゃないかな。

成本
それをまたベンダーが商売道具にしていくわけです（笑）。

＜第３回へつづく＞