 |
[2003 年 12 月号] |
|
[2003 年 12 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、株式会社サイバー・ラボの加藤康之さんです。加藤さんは、エンドユーザー・コンピューティングを実現するためのフレームワーク、Cyber Framework の開発者であると同時に、NTT 社内ベンチャー制度を利用して起業した、株式会社サイバー・ラボの代表取締役社長も務められています。 また、その功績が認められ、1996 年にはコンピューターワールド・スミソニアンアワードを受賞されています。 今回は、Cyber Framework の目指すエンドユーザー・コンピューティングの話題を中心にお話を伺いました。
 |
|
-- Cyber Framework はエンドユーザー・コンピューティングを推進するために開発されたそうですが、エンドユーザー・コンピューティングを実現しようと考えた経緯を教えていただけますか？
私は、ソフトウェアの世界に入る前は、NTT の研究所で FTTH（Fiber-to-the-Home） という世界を夢見て、光通信の伝送理論をやっていました。 ところが、実際にインフラが整い、光ファイバーで通信ができるようになっても、 何に使ったらいいのか分からないため、 なかなか各家庭に入ってこないんですね。 毎日、映画を見ているわけにもいかないですから（笑）。 結局、「サービス」や「生活を豊かにする新しいコンセプト」を誰かが作ってあげないと、 通信といえども単なるインフラでしかないわけです。
そういったサービスを実現する大元はコンピューターであって、
その中でもソフトウェアを国民全体が知恵を出して作っていかないことには、
生活は豊かにならないと思うんですよ。
しかし、ソフトウェアというのは、
非常に限られた人達、
例えば、OS であればマイクロソフトさんとかアップルさんとか、
そういう限られた人達だけが作っていて、一般の大衆には解放されていません。
しかし、実際のニーズや次代を継ぐ発想は、
そういう一部の限られた人達が持っているのではなく、
我々の生活の中にあるんです。
その生活を豊かにするような発想を、
民衆が、大衆が、国民が、全世界の人々が、
色々な思いで結集できるような仕組みがないと、
ハードウェアやインフラだけ作られても、
生活は一向に豊かにならない。
ちょうど光通信を始めて 10 年くらいたったときから、
そういったことをひしひしと感じるようになりまして、
残る半生をこういったサービスを作ってゆくようなところに
かけていかなければならないのかな、と考えたんです。
そういう話をしていたら、仲間が集まってきた。
それと時を同じくして、
NTT の現場も色々なサービスを要求されるようになったんですね。
そういった要求に対してきちんと対応していくためには、
NTT グループもシステムをどんどん作っていかなければならない。
ところが、
今までの作り方でやっていたんでは、
お金も時間も足りないので、
現場で誰でも作れるようにしなければいけない、という要望があがってきた。
会社の中の切実なる問題と、 自分たちが疑問に思ってきた世界というのは、どうも同じものだということで、 エンドユーザー・コンピューティングの実現に向けて動き出したわけです。 国民が知恵を出して作っていくことが エンドユーザー・コンピューティングの最終ゴールでもあるわけですが、 それをまずは目先の会社の中で実現させていこう、ということで始めたんです。
-- 現場の開発者達は、誰でも簡単にソフトウェアを作れる世界を 受け入れることができたんでしょうか？
そうですね。 NTT グループの中でも、最初はやっぱり物議を醸しだしました。 レガシーな開発環境の中に身を投じてきた人達にとっては、 ドラッグ & ドロップで 1 、2 秒で作られたんでは、 たまったものではないですからね。 全員が新しいパラダイムに乗り換えようとするわけではなく、 乗り換えられない人たちも出てくるわけです。 写真が登場してきた当初、フランスでは、 「街角から画家がいなくなってしまう」と思って、 写真を使わないというデモがおこなわれたそうですが、 これと同じような構造が出てきました（笑）。 これは人間の極めて素直な反応だと思うんですけどね。
-- エンドユーザー・コンピューティングを実現する、すなわち、ソフトウェアの生産性を上げるために最も重要なことは何ですか？
一言でいえば、「再利用」だと思うんですよ。 ただ、再利用できる形であれば何でも良いかというと、そうではなくて、 「複雑さを回避するシステム」がポイントになります。 皆、システムが複雑なのは業務が複雑なのだから仕方ない、と思ってしまっている。 ところが実は、世の中にも、自然界にも、 複雑さを回避する考え方が沢山あるんです。
その一番の代表例は、 コンピューターの心臓部の CPU です。 複雑な CPU の世界を作っていくのに、 いちいち、コンデンサーや抵抗、トランジスタという レベルで考えていたんでは、複雑さに対応できなくなりますよね。 今では、トランジスタの数は 1 億を超えるくらいになっていますから。 そこで、その複雑さを解決するために何をやっているかというと、 ロジックの基本形を作っているんです。 ロジックの基本形の NAND ゲートによって、 フリップフロップを作ったり、 バッファーを作ったり、色々なことをやる。 トランジスタというような部分まで落としていくと、 CPU は非常に複雑なシステムですが、 その上の階層で見ると、NAND ゲートを何度も再利用した構造を持っている。 またその 1 つ上の階層では、フリップフロップ等を組み合わせた、 汎用的なレジスタ構造を基本形として持っています。 自然界で言えば、 DNAの構造が 4 つの塩基配列の基本形から何千万種もの生態系を作っているのと同じですね。
今までは、ソフトウェアもコードを 1 行 1 行書いてきました。 しかし、たとえ Java であろうが Objective-C であろうが、どんな高級な言語でも、 1 行 1 行書いていたのでは、複雑さを回避することはできません。 先ほどの CPU の例のように、もっと上のレイヤーのコンテキストで複雑さをカバーしていかないことには、 生産性は上がらない。 いわゆる構造化や部品化というのは、 再利用の考え方がほとんどを占めていて、 次に重要な複雑さを回避する考え方が実は抜けていたんです。 これに対し、Cyber Framework は再利用の実現だけではなく、複雑さも回避できる枠組みも持っています。
-- Cyber Framework では、「再利用」そして「複雑さの回避」を どのように実現しているのでしょうか？
Cyber Framework では、 あたかも LEGO の積み木細工のように、 コンポーネントを組み合わせてソフトウェアを作っていきます。 ただし、単に部品を用意しておくだけでは、 一般の人には複雑な構造を持つ部品を組み立てられません。 そこで、部品をより賢くしてやって、 部品 1 つ 1 つが正しく組み合さるような仕組みを、 フレームワークの概念を導入することで実現しています。 部品が足りないときは、必要とする部品を自分でローディングしてくるので、 ユーザーが適当に部品を選択しても、 その部品を構成するのに必要な部品は全て自動的についてきます。
また、LEGO の積み木細工を使いやすくしている最大の特徴は、
「どんな部品を持ってきても必ずくっつく」という点です。
インターフェースが 1 つしかないので、部品をくっつける時に悩む必要がないわけです。
これに対して、今までのソフトウェアは、
「関数名をどういうふうに書いたらいいか」、
「引き数は何個あるか」、
「引き数の型は何か？」
といったところまで全部一致させてコールしないと、クラッシュしてしまう。
しかし、「関数名をどうつける」とか「引き数をどうするか」といったことは、
人によって任意性があるわけですから、
あらゆるところにクラッシュの危険性をはらんでいます。
ですから、100 のプロジェクトで作ると、
100 の階乗の何倍ものインターフェースが生じ、
誰かが 1 つミスをするだけで、
クラッシュを起こして動かなくなってしまう。
たとえ結合試験をして動いても、
ユーザーに見せて、「あっ、これは違うよっ。」と言われると、
引き数を増やしたり減らしたりすることで、その場を凌いでしまう。
そのような事が至る所で起こって、
システムが動き出すまでに当初の計画よりも 2 年遅れた、といった話が頻繁に出てきます。
Cyber Framework で作る世界は、
LEGO と同様、インターフェースが 1 つしかないので
クラッシュは起こりません。
LEGO の積み木細工のように、何を持ってきてもくっつきます。
ダイナミックに結合を固定することができる仕組みを持っているんです。
ただし、メッセージセンディグの度に毎回それをやっていたのでは
非常に効率が悪いので、1 回確立された結合はそのまま再利用していく。
これにより、メッセージセンディングの非効率性を回避しています。
-- GUI の部品化は容易に実現できると思うのですが、ビジネスロジックはどのように部品化するのでしょうか？
例えば、与信率というものは、 「年間の総収入」と「月々に使っている支出」などから計算できますよね。 ただし、その計算方法（ロジック）は、 銀行によって千差万別なので、 あらかじめ部品として作っておくわけにはいきません。 だからといって、 弊社が毎回毎回出て行って部品を作るわけにもいかない。 そういうときには、このようにロジックを追加します。
データーベースからデーターを複数取得して、計算 & 表示する
アプリケーション作成のデモを見せてもらう。その間わずか 5 分足らず。
作業の大半がマウスによるドラッグ & ドロップで、
キーボードを利用するのは計算式（ロジック）の入力時のみ、という簡便さに一同感激する。
このように、Cyber Framework では ドラッグ & ドロップで一瞬で作れてしまいます。 これに対し、ほとんどの開発環境では、コードをガリガリ書いていくしかない。 しかも、せっかく作って顧客のところに持っていっても、 「あっ、ごめん。ここの数値は 5 じゃなくって、7 に変わったんだよ。」 というふうに要求がコロコロ変わっていく（笑）。 必死に顧客の要望に応えようとするんですが、結局、 「とても赤字だわ、あのシステムは。」ということになってしまう。 ところが、Cyber Framework なら顧客の所でも直せるくらい簡単です。 ロジックが必要なときには、 ダイナミックに一瞬にしてそのためのクラスを設計して、 また、それを表示する部品も一瞬にして組み込めるんです。
-- エンドユーザーが自分たちで開発をしていくことで、何か大きな変化は出てきたのでしょうか？
今までのように、 ベンダーに開発を全部委託していると、 ベンダー側にノウハウが蓄積されてしまって、 ユーザーの方には何も残らないんですね。 ところが、 Cyber Framework を使って エンドユーザーが自分自身でシステムを作っていくと、 お客様との色々なやり取りのノウハウが部品としてできあがって、 手元に蓄積されていきます。 その蓄積された部品、ノウハウを使って、 より戦略的なお客様へのアプローチができるようになってくる。 ユーザー自身が、 自分たちの業務はどうあるべきか、 ノウハウを次の世代に伝えるためにどのようなナレッジマネジメントが必要になるのか、 ということを考えるようになるんです。 もともとはユーザーがシステムを作るところから始めたのですが、 会社全体の業務そのものを変えていくことが分かってきました。 エンドユーザー・コンピューティングという考え方が、 世界を変えていくのではないか、という感触を掴んでいます。
-- 業務ノウハウ、言い方を変えると、ナレッジをソフトウェアとして蓄積できるということですね。
そういったものをドキュメント、仕様書として残してきた従来のやり方とは大きく異なるものなんでしょうか？
実は従来は、残していなかったのかもしれません。 確かに従来も、業務ノウハウを仕様書としてベンダーに渡してきました。 しかし、そういった仕様書はぶ厚い紙媒体の資料として、 ユーザーの手元ではなくベンダーの書庫等に仕舞われてしまうだけです。 しかも、利用者の立場の人が読んでも分かるものではないですよね。 ですから、 今までは、 ノウハウを文字ではなく口伝えに伝えていく、 マヤ文明のような世界だったんです（笑）。 それでもよかった時代はいいのですが、 現在のようにお客様のニーズにタイムリーに対応しなければ生き残れない時代では、 より戦略的に優位に業務を展開していくために、 自分達の手元にノウハウを集積し、外部に出さないことが重要になります。 また、現場で人が転勤して代わったとすると、 従来のやり方では、転勤していく人にノウハウがついていってしまったわけですが、 Cyber Framewok の場合、部品としてそのまま組織の中に残ります。 次の担当者は、その残された部品、すなわちノウハウを利用することができる。 アプリケーションの中に、ノウハウを見える形できっちり入れていくことができるようになった、 というのは非常に重要な変化ですね。
-- デモを拝見させて頂いて思ったんですが、 Cyber Framework で作成したアプリケーションは、 もう、これ自体がドキュメントなんですね。
ええ、そうです。
Cyber Framework では部品を組み合わせながら、
トライ & エラーで作っていきますので、
設計図なしにアプリケーションが出来上がってしまうことがよくあります。
そうすると、他人にそのアプリケーションの構造や目的を伝えるのが難しくなってしまう。
そういう時のために、
開発環境上でアプリケーションそのものが設計図になるようになっています。
例えば、NTT の現場ですと、複雑なアプリケーションが山のようにあるわけですが、
その開発者たちは 2 年くらいで転勤してしまって、
次の担当者が来ても何をしたらいいか分からない（笑）。
「何かこれで良さそうなんだけど、ホントにこれで大丈夫かな？」とか、
「ここのところはちょっと変更したいんだけど・・・。」と思っても、
設計図がないことには恐ろしくて変更もできないんです。
Cyber Framework はアプリケーションを構成する各部品を全部知っていて、
何をしようとしているかも分かります。
例えば、データーベースそのものが変更されてしまい対応できなくなったときに、
その原因を調べることもできます。
これに対して、ドキュメント中心の開発、
例えば、UML を用いて開発をおこなっても、
最終的にはコーディングに入っていきますよね。
その際、UML ツールを使えば、確かにスケルトンは作れるかもしれませんが、
残りの部分のコードは自分で書かなければいけない。
Cyber Framework では
そんな二段構えではなく、
アプリケーションを作ると、
そのアプリケーションそのものがドキュメントになるんです。
-- Cyber Framework はどういった環境で開発されたのでしょうか？
最初はいきなり PC-98 を買ってきて始めたんです。 で、PC-98 でもがいていた（笑）ところに、 周囲の UNIX 文化の人から「PC-98 で努力するくらいだったら、 SUN の SPARCstation でやった方が、 十倍くらい効率よくソフトウェアが作れるよ。」 と言われて、UNIX を始めた。 それでコンセプトの 4 割くらいまではいったんですが、 エンドユーザー・コンピューティング実現のために 超えなければならない 1 つの垣根をどうしても越えられなかった。 そんな時、たまたま秋葉原に寄ったら黒いマシンでデモをしている人たちがいて、 それが NeXTSTEP だったんですね。 見てみると、超えられなかった領域が、まさにそこにあったんですよ。 「おおおー、こんなのがあるんだ！！ これだね！」 と、すぐに NeXT の世界に移ったんです。
-- その NeXT のデモはどういったものだったんですか？
アプリケーションを外部から見ることができる Application Inspector というシステムのデモで、
作ったアプリケーションがどう動いているかをリアルタイムで確認する、というものでした。
ソフトウェアの一番難しいところは、
例えば、 1K ステップくらいだったら
頭の中で構造が全部見えるんですが、
数十〜百 K ステップくらいの実用的なシステムになると、
自分のコントロールの範囲、見える範囲を超えてしまう、という点なんですよ。
システムの規模が大きくなると、
自分が今作っている箇所が、全体のシステムの中で整合性がきちんと取れているのか
分からなくなってしまい、結果、バグの温床になってしまいます。
そうすると今度は、
幾つかのプロジェクトに分けて、
例えば、100 のプロジェクトに分けてみんなで分担しながらやりましょう、ということになる。
しかし、分割したプロジェクト間のインタラクティブが
100 の階乗分だけ出てくるわけですから、
ほとんど打ち合わせだけで終わってしまいます。
この矛盾を解決するためには、
自分が作っている複雑な世界を、
見えるようにしなければなりません。
つまり、
作成中のアプリケーションを動作させながら、
不具合や整合性をリアルタイムで見ることができる仕組みが必要だったわけです。
そのコンセプトが NeXTSTEP にはあったんですね。
どんなふうにアプリケーションを作っても、
どのオブジェクトが ON で、
どのオブジェクトとどのオブジェクトがどういうメッセージングをやっているか、
というのが全部見えるんですよ。
結局、
NeXTSTEP に出会ってから半年くらいで、
エンドユーザー・コンピューティングの核になるようなところは
出来上がったんです。
-- Cyber Framewok は Objective-C で開発された、と伺いましたが、 他のオブジェクト指向言語ではなく、 Objective-C を用いなければならない必要性とは何だったのでしょうか？
C++ や他の言語では、オブジェクトをクラスとして設計しないと使えない。
実はこれは、メリットでもありながら凄いデメリットでもあるんです。
人間が物事を発想していったり、新しいモノを作っていくときには、
最初からゴールが見えているわけではなく、
どんなオブジェクトがあるのか分からずに、
色々な試行錯誤のもとにゴールにたどり着くのが現実です。
最初から全ての工程が見えているようなシステムなら、
時間さえかければ誰でも作れますが、
人間の世界はそんなに単純ではなく、
ユーザーすら自分が最終的に使いたいものが何であるか分かりません。
実際にシステムを作って、試して、業務として使う中で、
「あっ、これはやっぱりこうだね。」 となるわけです。
つまり、
ソフトウェアを作る段階でも、
使う段階でも、最終ゴールにおいても、
半固定的で、絶えず変化しうる形を持っていないといけない。
ところが、それは C++ のシンタックスの体系の中では許されないんですね。
しかし、これを打破しないことには、
フレキシブルに考える人間に開発環境は追従することができません。
これを実現するための仕組みをだいぶ探していて、Objective-C に出会ったんです。
Objective-C の言語体系の中には、
クラスをダイナミックにローディングする機構と、
クラスのメソッドをダイナミックに追加できる機構の両方があります。
また、クラスの名前をそのままに、
中身だけダイナミックに入れ替えられるという極めて柔軟な機構を有しています。
これによって、
アプリケーションを走らせた状態でダイナミックに機能を追加する、
といった事が可能になりました。
人間は初めから完成された存在ではなく、いい加減な発想をします。
しかし、そのいい加減な発想が、結局はフレキシブルな新しい発想に発展する。
ソフトウェアの厳密な世界の中に、
そのいい加減さ、人間の不完全さを如何にして取り入れていくか、
ということが課題でした。
悩んで悩んで、
結局、NeXTSTEP と Objective-C に出会って完成したんです。
-- 実際に Cyber Framework という製品を世の中に送り出して、当初思い描いていたエンドユーザー・コンピューティングの目的は実現されたのでしょうか？
エンドユーザー・コンピューティング、これが究極だと思ってやってきました。 でも、実はそうじゃなかった（笑）。 これが、この5年間、サイバー・ラボをやりながら学んできたことです。 ユーザー開放型の究極的なツールを作って売ったわけですが、 その中で自分だけで作れる人は 100 人中 5 人しかおらず、 残りの 95 人は何らかのサポートが必要でした。
現実の世界でも、例えば建築の世界で 自分の家をオーダーメイドで建てようとすると、結構大変ですよね。 建築業者さんがやってきて、 「週末までに、壁や天井、床の色を決めて下さい。 そうしないと施工は始まりません。」と、分厚いファイルをトラックに積んで 10 冊くらい持ってきます。 見ると、ほんの少しずつ色が変わっている 5cm 四方くらいのサンプルがいっぱい貼ってあって、 悩んでも悩んでもきりがないんです。 しょうがないから、 例えば、私の好きなグリーン系ばかりを選ぶと、 結果、緑色だらけの息苦しい感じがする空間になってしまう（笑）。 このように、 ユーザーは 「自分が好む世界」と「本当に実用的な世界」とのバランスが分からないんですね。 私も分からなくて、結局インテリアコーディネーターに頼みました。 すると、窓のカーテンにグリーンのストライプをほんの少し入れるだけで、 後はほとんど白にする。 そうすることで、全体としてはグリーンっぽい居心地の良い空間になるんです。 こういうバランス感覚は相当のノウハウで、 ユーザーが何回か失敗して痛い目にでもあわない限り、 そういう境地には行けません。 何度も何度も色々な設計をして、 作って、その空間に実際に入って、 というふうに肌で感じている人だけが分かる世界なんです。
エンドユーザー・コンピューティングの世界も同じで、 例えば、病院のシステムはエンドユーザーだけでは作れません。 お医者さんは、 「よぉし、そんな便利なものがあるなら、俺は何でも作るぞ！」と言うんですが、 彼はある病気に対してどの薬を使えばいいか、ということは知っていても、 病院の中でどんな仕事が行われているかは知らない。 つまり、 エンドユーザーは自分の仕事のことはよく知っているけれど、 他の方々がどんな仕事をしてるかは分からないんです。 したがって、 ある程度決まったデザインパターンを利用しない限り、 エンドユーザー・コンピューティングは完成しない、 ということが分かってきました。 ですから、エンドユーザーだけではなく、 コンサルの方にアドバイスをしてもらいながら一緒になって作る世界も必要なんですね。
それから、 実際に生活を豊かにしていくには、 ユーザーがシステムを作れるようになる、 ということだけではなく、 人間に優しいシステムも必要です。 例えば、 医療サービスとか、 介護サービスとか、 年金サービスなどのシステムを、 子供でもお年寄りでも誰もが簡単に使えるように、 垣根を低くしないといけない。 そこで、より利用者に優しいシステムを構築できるよう、 オントロジー辞書を持ちながら、 世の中にある色々なサービスの統合をしていく エージェントの利用を Cyber Framework の次のターゲットにしています。 個別の部品を組み合わせて、アプリケーション。 アプリケーションを集めてきて、シミュレーター。 シミュレーターからコンポーネントウェアに。 コンポーネントウェアをエージェントに。 というふうに、より賢くしていくことによって、 システム全体を統合化しようとしているところです。
-- 研究所で光ファイバーの研究をおこなっていた、とのことですが、もともとはコンピューターの開発者ではなく、ユーザーの立場だったんですね
そうです。 しかも、36 歳、「ソフトウェアをやるには適さない」と言われている年齢で始めたんです。
-- 昔は「SE 35 歳定年説」という言葉がありましたよね？
今でも定年されている方、多いんじゃないですか（笑）。 35 歳くらいで管理職になって、上流設計で適当にごまかして、 現場でのデバッグとか結合試験は若者に任せる。 そして、若い人達が徹夜続きで納期を迎える、という習慣がまだまだ続いてますよね。 血気盛んな若い人たちが現場で苦しんでいるのを アゴで使うのが SE の醍醐味みたいな感じで（笑）。 そうすると、 若者は現場で必死に働くうちに、 本来好きであったはずのソフトウェアが嫌いになってしまう。 これは、 楽しいはずである学問が受験勉強のせいで嫌いになってしまう、 という日本の教育にも似てますよね。 結果、若い頃から「出来るだけ早くコーディングの世界から逃げたい」 と考えるようになってしまう。 我々サイバー・ラボのやっていることは、結果的にではあるのですが、 この体制に対して、 「ソフトウェアをずっと死ぬまでエンジョイしていこうよ」 ということを提案している一面も持っています。
-- ソフトウェアの先輩として、若手エンジニアへのアドバイスを一言お願いできますか？
あえて若い人達に言うとすれば、「仕事を楽しくしなきゃ」ということですね。
一過性の仕事ではなく、 歴史に残るような仕事をするためには、 一生続ける必要があります。 若い頃から早めに逃げようと考えながらやっていては、 歴史に残るような仕事にはなりません。 先ほど言いましたように、 最初は好きでソフトウェアの世界に入ってきたのに、 他人の為の頼まれ仕事をただ単にこなしていくだけでは、 自分が何のためにソフトウェアを書いてるのか分からなくなってしまい、 辛いことから出来るだけ早く逃げ出すことばかり考えるようになってしまいます。 そうではなく、 他人の為に書く一方で、 ソフトウェアの中の自分のコンセプトをずっと大事にする。 あの世に行ってからも「こんなソフトを書いてるよ」と、 メールを出すくらいの気持ちでやれば（笑）、 ソフトウェアから得られるものは沢山あるはずなので、 楽しい仕事になると思うんですよ。
これは若い人達に言っているんではなくて、自分にも絶えず言っていることなんです。 会社を成り立たせていくためには、日々の仕事をやらなければならない。 嫌な仕事もやらなければいけないこともあります。 そういう中で自分を見失わないためには、 やっぱり「仕事を楽しくしなきゃ」、ということですね。
-- 最後に、読者の皆様に伝えたいことはありますか？
ひたちなか（サイバー・ラボ社）は良いトコロですので、是非遊びにきてください（笑）。
-- （笑）
-- 本日は大変貴重なお話、ありがとうございました。
| ©2003 OGIS-RI Co., Ltd. |
|
