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

現在ＩＴプロジェクトの現場では、多様な技術要素マネジメントの手法が適用され、やや混乱をきたし気味です。ＩＴ投資に対するリターンがきちんと得られず、プロジェクトに関わる人たちの多くが、苦しいばかりで幸せになれていない。そのような現状を憂うアイ・ティ・イノベーション　代表取締役　林衛は、マイクロソフト社のアーキテクトエバンジェリストマネジャとして同社の技術を展開するミッションを持ち、精力的な情報発信を行っている成本正史氏と対談を行いました。
テーマは「次世代のメソドロジーやソリューションはどのようになっていくのか」。成本氏はどのような経歴を経て、どのような問題意識を持って現在の立場に就いたのか、また次世代のメソドロジーとソリューションに対し、マイクロソフト社の技術はどのように貢献しようとしているのかについて、林衛を聞き手として語っていただきました。その成果を6回にわたって掲載します。

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

実験を楽にしようと初めてのソフトを開発

林
本日は成本さんの問題意識と、それに対して マイクロソフト社の技術がどういうふうに役に立つのか、あるいは役に立つことを期待しているのかについてお伺いします。
それはもちろん成本さんひとり、あるいはマイクロソフト社だけで成り立つというものではありません。アイ・ティ・イノベーションもそのことについて考えている会社です。そして、今後いろいろなシナジーが生まれ得ると思っています。いま社会で活躍している会社に対してもそれを提供して、よりよい世界を作っていきたいのです。そういうことをちょっと議論したいなということです。
最初は、いきなり議論に入るより、まず成本さんご自身の自己紹介をいただきたいと思います。なぜこのような、時間がかかる、素晴らしいテーマを見つけて取り組まれることになったのか、その辺りをちょっとお聞かせいただけないですか。

成本
その点に関しては自分でも不思議なんですけども（笑）。
学生時代は、機械工学を専門にしておりまして、ちょっと変わっているんですけど、金属疲労実験の研究室に行きました。

林
金属疲労で飛行機事故が起きた頃ですか。

成本
そう、まさにあの時代なんですよ。

林
私自身、人間疲労実験をやっているようなところがありますが（笑）。

成本
こっちのほうはちょっとメタリックな感じなんですけども、確かに似た面もありますね（笑）。金属疲労の実験には、いろいろな強度で引っ張り実験をし、ヒビがどれくらいの時間で入っていくかで強度を測るという実験方法があるんですが、ものによっては１日で終わるものもあれば、３ヶ月かかるものもあります。それを当時は人間がメジャーで測っていたんですよ。人間が３ヶ月間、昼夜を問わず交代制でヒビを毎正時に測る。まさに「人間疲労実験」です。あまりにたいへんなので、それをCCDカメラで取り込みまして、そこにちょっと人工知能的な要素を取り入れて、ヒビの長さを自動測定するというようなソフトウェアを開発したのが、こういう道に入ったきっかけになっています。それまではソフトウェアは全然、作ってなかったのですが。

林
疲労一筋と（笑）。苦労の中から工夫が生まれた。そこにＩＴが介在してきたということですか。

成本
そうですね。その自動測定ソフトウェアは１年２年で完成するものではなくて、ある程度の精度までは達成したというところでしたが、卒業以降はいつの間にかメタル一筋からソフトウェア一筋に変わっていったんです。

ハードとソフトの発想の違いを実感

成本
卒業後、横河電機という会社に入りました。工場や石油プラントにハードウェア、ソフトウェアを納入しオートメーション化を行う会社でした。最初に私が配属になったのが、ビル事業部で、ビルのオートメーションをやっておりました。主に空調や電力の制御ですが、当時は自社製のマイコンを、アセンブラーで作るという時代でした。ＯＳも持ち前のやつで。

林
そうですか。成本さんは、学生時代からゴリゴリやるのがお好きだったのですね。

成本
そうです。ゴリゴリやってとことん突き詰めるタイプの性格ですね。

林
ゴリゴリやるってことは、その人の問題意識さえあれば、あとでいろいろな工夫を生み出す原動力になるんですよ。それが辛ければ辛いほど。

成本
そうなんです。一番末端の作業をやっているところからのボトムアップ的なアプローチは、日本人は得意ですから。私も「じゃあ、もうちょっとこうやった方が効率がいいな」というようなことは自然と学んできました。ハードウェアのエンジニアとしてデジタル回路設計などもやって、ソフトとハードの両方をやっていたので、その２つの違いについても非常に興味を持つようになりました。

林
違いと言いますと？

成本
ソフトとハードでは発想が違うんですよ。ハードウェアの世界ではバグなんてあり得ない。バグがあったら全部リコールなわけです。だからとにかく完璧に100％動く。しかも温度もマイナス何度からプラスの50度まで全部試験をして、連続稼動して当たり前の世界ですから。ハードウェアの設計を通じて、品質を上げるためにはどういう工夫をしていけばいいのか、自分のノウハウとして貯まっていきました。
ソフトウェアは何ステップあたりバグはいくつとかっていうような基準があって、それを超えなければ、品質はそこそこ確保されていることにする。まあ、ぬるいですよね。
当時の私は、理論的に解明できること以外はあまり興味がなかったんです。ハードウェアは、全て正しいか間違っているかです。こういうのが僕、好きなんです。ソフトウェアは、画面設計ひとつとっても何がよいのか答えなんてないじゃないですか。あまり好きじゃなかったんですけれども、ハードウェアを作ったあとで、それを上手く使うには今度はそのハードウェアを有効活用するソフトを作る必要がある。なので、ソフトウェアも同時期にずっとやってたわけです。

ソフトウェア専業となり「人間CASEツール」と言われた頃

林
それが何で、ぬるくてやわらかい世界に来てしまったんですか。

成本
そうなんですよね（笑）。ソフトウェア専門になったのは、正直に言うと部署が替わったからです。ファクトリーオートメーションの方に移りまして、そこはもうハードはパソコンだったんです。センタムという横河のプロプライタリーなものか、もしくはUNIX。私はパソコン用の安いやつを担当していまして。当時はWindows3.1でした。苦労しました（笑）。勝ち負けで言うと負けたかもしれないですね。

林
まあ、そういうところで、ゴリゴリ底辺でやるというノウハウというか、「やり切れば何か出てくるぞ」みたいな気持ちが出てくる。

成本
まあ、喧嘩根性みたいなものです。開発環境もビジュアルベーシックの2.0という時代ですから、本当に手作業で試行錯誤という世界ですね。作ってみたけどメモリの範囲を超えてしまって動かないということもしょっちゅうあった時代です。そのへんから徐々にソフトウェア専門になっていったんです。
当時、CASEツールというのを作っていまして…。

林
何年くらいのことですか？

成本
30歳くらいの時だから、10年くらい前です。ファクトリーオートメーションの末端の機器のコントロールは、シーケンサーと言われるディバイスでやってるんです。そのシーケンサーのプログラムにラダー言語というのがあるんですけど、これがあまり生産性がよろしくない（笑）。これを何とかしようということで、Windows上でグラフィカルに定義をしたものが、そのラダー言語に落ちて、シーケンサーの制御ができるツールを当時のＶＢ上で作っていたというわけですね。

林
ジェネレーターですか。

成本
ジェネレーターですね。なおかつ、プロセス制御とか工場の制御の工程管理みたいなものをグラフィカルで定義して、チャート的に開始処理、終了処理、異常処理というようなことを前提にしておけば、「この時にはこのバルブを閉める」というようなことを全部、グラフィカルにできるので、最終的にはラダー言語としてそれが実行されるというのを作っていたんです。
ですから、あとでちょっと話が出てくるモデルドリブンの話をすると、「じゃあ、過去のCASEツールと何が違うんだ？」というふうにおっしゃる方が多いんですよ。「昔、失敗していたじゃないか。」とか「結局、上手くいかなかったのに、なぜ今モデルドリブンで上手くいくんですか」と（笑）。これは割と著名なアーキテクトの方もおっしゃいますね。

林
私も80年代中盤から、ビジネス系データベース中心の複雑な業務システムを、どうモデルからシステムのほうに出していくか、ディライトしていくかというテーマでやってきました。多少時期はずれていますけど、成本さんはＦＡの世界、私は業務、ビジネスの世界で同じようなテーマでやってきたことになります。末端から、金属疲労じゃなくてヒューマンのほうの疲労試験をしながら。

成本
ええ、疲労を軽減させるべく。

林
軽減させるつもりが、よけい疲労しちゃった人もいる。まあ、いろんな面白いことが起こるわけです。

成本
そうですね、私も「人間CASE」と呼ばれたりしていましたからね（笑）。結局、パソコンが止まっちゃって、自分でバルブをもらって来たり。

林
それが一番よくできたりしたんでしょ（笑い）。

成本
ええ、それはもう確実ですからね。そういうことをやっていました。

ソフトウエアにつきものの不確定性

林
一般的な理工系の理想的な考えというのは、完全なものがあるという前提なんですよ。それをいかに組み立てるかという発想です。でも大学に入って、だんだん「測ろうにも測れない」とか、物理なんて「不確定性原理でどこにあるかわからない。そういうものなんだ」と教わったりして「ああ、そうか、人生みたいなもんだ」と思うわけです。最初から何も決まってない。「じゃあ、それなりにその理屈から組み立ててやっていこう」と柔軟な方向に行く人はだいたいソフトウェアに来るわけです。

成本
そうかもしれないですね。

林
割と理想についての考え方、哲学ができているんで、そういうことが繰り返されても耐えられる。でも、固めの理想追求型の人は打ちひしがれちゃう。もろいんですよ。
「どうしても完成しない。なぜゼロにならないんだ」と。そんなの高校で微分の時に、「ゼロに近いんだけどゼロというのがあるかどうかわからない」と習ったじゃないですか。最初は考え込んでしまうかもしれないけど、「言われてみれば世の中って、そうだな」と納得できる。

成本
そうですね。やっぱりねという感じで（笑）。人間のタイプとして、公式を全部覚えてからでないと取り掛かれないような人もいれば、「いや、それはもうやりながら覚える」という割と柔軟な人もいて、どっちの方がいいとかっていうのは一概には言えないんですけども、適応能力の高さでいうと後者の人の方が高いですよね。仕事の進め方とかに、それが当てはまるんじゃないかと思います。

林
まあ、バランスでしょうね。最初の理想がひとつあって、それを追求していくのに向く対象もあるんですが、柔軟さを持たないといい仕事はできないような、あるいは最初から答えが決まっていないようなソフトウェアはたくさんあります。Ｗebやブログ系のシステムがたくさん出てくると、作ってみなきゃわからない。作って使ってみて初めて次のフェーズがわかる。そういうことは教わってないわけですから、仕事をやりながらわかってくる。
だとしても、大雑把な原理はあるんですよね。最初はこうやって、ここはやりながら考えようというような。そういうバランスをとるのがメソドロジーなわけですよ。

＜第２回へつづく＞