[ベテランCIOが語る「私がやってきたこと、そこから学んだこと」]

2016年7月6日(水)寺嶋 一郎（TERRANET代表／IIBA日本支部代表理事）

　2016年初め、まだ10年はかかると思われていた囲碁で、コンピュータがプロ棋士に勝利したというニュースがあった。これに象徴されるように、人工知能（AI）は現在、3回目のブームを迎えている。第1次は米ソ冷戦時代のニーズでもあった自然言語処理による機械翻訳などの研究。10年ほど続いたが、急速にブームは去った。当時のコンピュータではCPU性能もメモリーも追いつかず、文脈を読むなど言語の理解は無理だったからだ。

　前回も書いたが、筆者がMITにいた時はExpert Systemが脚光を浴びた第2次のブーム。日本でも一部の研究機関のみならず、通産省（当時、現在は経産省）が「第五世代コンピュータ・プロジェクト」を立ち上げるなどしたので、多くの企業が注目する一大ブームになった。余談になるが第五世代とは、機械語を第1世代とし、アセンブラ、汎用言語、4GL(第四世代言語、今日のプログラムジェネレータに相当）の先にある知的なシステムという意味で名付けられたものだ。

　だが結論を見れば、Expert Systemも第五世代コンピュータも期待外れに終わった。限定された数の形式知を処理するようにはできても、人間が意識しないで使う常識や暗黙知をわきまえさせることは、知識のメンテナンスも含めて非常に困難だったからだ。CPU性能やメモリー容量も第1次に比べれば良くなっていたとはいえ、当時のスーパーコンピュータは今日のスマートフォンに劣る性能だったから、自ずと限界があった。

　第2次ブームにおいて、脳に似た仕組みを作れば脳と同じことができるのではと、「ニューラルネットワーク」の研究も本格化した。しかし当時のコンピュータの能力では、脳の神経回路の階層構造は3層程度、ニューロン数も数10を再現するのがせいぜいで、実用化はクレジットカードの利用チェックくらいだった。今日、コンピュータの性能が向上し、この階層を深くすることができ、精度の高い機械学習の実現に成功した。これが「ディープ・ラーニング」（深層学習）と呼ばれ、第3次ブームの原動力の1つとなっている。

　第2次の頃の苦労を知る筆者にすれば、Siriなどに代表される音声認識や言語解析技術の進歩はびっくりものだ。格段に高くなったコンピュータ・パワーと、圧倒的多量のビッグデータが可能にした技術の破壊力はすさまじいものがある。とはいえ、ディープ・ラーニングのチューニングには試行錯誤的な取り組みが必須だし、適用分野もまだまだ限られているのも事実。期待しすぎる反動でブームが急に去るのは避けたい。

　じっくりと腰を据えた研究を望みたいし、人工知能はディープ・ラーニングだけではなく、非常に幅が広い。ぜひ日本企業も、長期的視野を持って人工知能への取り組みに力を注いでほしい。それはIT企業だけではなく、一般の製造業や流通サービス業、金融業などへの期待でもある。

全体最適が追求できるのはIT部門だけ

　前回はユニット住宅の部品展開システムを開発した経緯を書いた。この時にいつも考えていたこと、その後、CIOとして全社ITを見る立場になってからも有益だったことについて記しておこう。それは特定の部門や業務のことだけでなく、常に関連する部門やプロセスの前後の工程を考えて臨むことだ。

　アイザックで住宅のシステムを考える際にも、住宅の開発部門と生産部門と営業部門を連携させることを明確に意識した。実際には、生産部門を支援する部品展開システムからスタートし、次に開発部門の商品開発支援システム、最後に営業部門のCADシステムを再構築したのだが、この際、三部門のシステムが共通のデータ構造を持ち、互いに連動するように考えたのだ。

　営業部門は、お客様の間取りをコンピュータで作成し、外観や内観をプレゼンテーションし、見積もりを行う。OKとなれば、作成された邸（住宅）のデータを工場に送り、それをもとに部品展開する。部品展開で使用する部品表のデータは開発部門で作成済み、といった流れである。受託しうる邸で使用する可能性のある部品をすべて事前に設計しておけば、お客様の間取りが決定した時点でほぼすべての仕様の詳細が決まる。つまりユニット住宅のメリットを最大限に引き出すことができるのである。

　もちろん頭の中で考えただけではない。「開発」を頂点にして底辺の両端に「営業」「生産」と三角形を描き、三部門のシステムを統合するビジョンを可視化した。不思議なもので、こういったビジョンを常に自らにも言い聞かせ、周りのメンバーや事業部に対しても言い続けると、ちゃんと実現するものだ。「石の上にも3年」と言われるが、少なくとも3年、できれば5年、10年と思い続ければ、夢は必ず実現すると筆者は固く信じている。

　よくIT部門は全社の業務を俯瞰して仕事ができると言われるが、まさにそうだと思う。開発、生産、営業の各部門はそれぞれ自らの部門のことを最優先で考える。それを真正面から受け取り、追求していくと部分最適のシステムになってしまう。矛盾し合う互いのニーズを調整して全体最適に昇華させ、効率や利益の最大化を追求できるのは、全社に横串がさせるIT部門が適任だ。目の前の案件に専念するあまり、ともすれば部分最適に陥りがちなのは言わずもがななので、肝に銘じたい点である。

プログラマーを大事にする

　1990年を過ぎた頃から商品開発支援システムの検討を開始した。膨大な部品表のデータを設計図書とともに管理しながら、商品開発の生産性と設計品質を向上させるためのシステムだ。今から考えれば「PDM（製品データ管理）」の仕組みだが、当時はそのコンセプトはまだ普及していなかった。

　コンペをして選定したベンダーの研修所に開発部門とシステム関係のメンバーが寝泊まり、難航はしたものの、仕様を固め、設計もなんとか終了。のべ何百人という下請けも含めたプログラマーが関わる、かなりの大型のシステム開発投資になった。

　ところが悩ましい事態が起きる。完成した後も仕様変更や機能拡張の必要性に迫られ、結構な費用がかかったのである。そうこうするうちに、UNIXワークステーション上でしか動かなかった仕組みをWindows上で動かす必要が生じ、ベンダーに再構築を依頼すると想定を超える莫大な見積もりが提示された。ベンダー・ロックインかどうかは別にして、ベンダー依存のままでは引き続き膨大なコストがかかる──。

　いろいろ考えた結果、アイザックで再構築を行うことにした。大手べンダーが莫大な費用をかけて構築したシステムの再構築である。アイザックのような小さなソフトハウスで本当にやりきれるのか、不安がなかったと言えばウソになる。だが「時には冒険をしなければ未来は開かれない。うまく行かなかった際は、辞表を書けばいい」と腹を括った。

　逃げ道をなくし、自分や仲間を信じて前進すれば、一見無理そうなことも、必ず乗り越えられる。無茶な根性論に聞こえるかも知れないが、筆者自身もプログラマーの端くれである。アイザックには、選りすぐりのプログラマーたちもいたので、やれる見通しはあった。彼／彼女らとオブジェクト指向に基づきしっかりとソフトウェアのアーキテクチャを設計した上で、プログラム開発を少数精鋭で行った。

　結果として、メンテナンスも含めシステム開発の生産性は一桁以上良いものができた。優秀なプログラマーが少数精鋭でシステム開発を行えば、ここまで生産性が違うのかという驚きがあったほどである。プログラマーを大切にしなければならないという筆者の信念は、この鮮烈な経験による。