 |
[2005 年 8 月号] |
|
[2005 年 8 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、豆蔵の 萩本 順三 さんです。萩本さんは、開発方法論 Drop*1を作ったことで有名なオブジェクト指向エンジニアです。また、Java 用分散オブジェクト技術 HORB の開発にも携わっておられました。今回のインタビューでは、現在、取り組んでおられる要求開発を中心に語っていただきながら、オブジェクト指向との関係性についても教えていただきました。萩本さんのオブジェクト指向に関する深い洞察は必読です。
*12005 年 8 月にクリエイティブ・コモンズ・ライセンスで再リリースされました。 |
| ||||||||
-- まず、現在のお仕事についてお話していただけないでしょうか？
豆蔵を立ち上げた頃から、私自身の課題として持ってたんですけども、要求開発っていうものを開拓しようということで、それに取り組んでいます。
要求開発っていうのは、要求を獲得する前に、ビジネスを可視化して、それに改善を加えて、相手に伝えていくっていうようなものです。それはオブジェクト指向と非常に関係してくる話なんですけども。その活動のための方法論づくりとそれを実践するっていうことをコンサルティングの中でやってます。
まぁ、たまに教育をやったり。たまに経営をやったり・・・。
（一同笑）
-- 要求開発って言葉を使われていますが、普通は要求を開発するって言わないと思うんですよね。なぜ、そういうふうに要求を開発するって言葉を使われるのでしょうか？
やっぱり、要求っていうのは一方通行じゃない、非常に不可思議なものだと私は捉えているんですよ。
基本的にビジネスとか業務の本質っていうものは、江戸時代から変わらないかもしれない。でも、変わらないからといって、それを自然と要求として出せばいいっていう考え方は間違っていると思うんですね。なぜかというと、そこに IT が絡むことによって付加価値が出たり、やり方が変わったりするんで。そうすると、要求の構造の半分は IT が担っているわけです。IT を含めて IT でどういうふうに業務をやるかっていうところに要求が存在してる。だから、IT の姿をお客さんに見せないと分からない。
ところが、基本的に要求っていうのは、お客さんから獲得するっていう感覚がありますでしょ？
-- そうですね。
お客さんは、その要求っていうことのやるべき仕事は分かるけども、システムに対する 要求なんて分かんないわけですよ。だから、そこを IT のメンバも含めて、獲得してい くための場を提供することを方法論とともに作っていこうとしているところです。
-- 多分、今言われたことって、ずいぶん前から言われてることだと思うんですが、でも、なかなか実現できてないですよね。
そうですね。
-- 今回やられてることの特色というか、今まで何が駄目だったから IT の技術を含めた要求をきちんと汲みとれなかったと考えられているのですか？
1 つはシステム開発における要求っていうのは、視野が狭すぎる。 システム開発プロジェクトの中で、ビジネスモデリングとかをやって、要求を獲得するっていうのは方法論としてあまりにも安直すぎるんですね。だけど、要求獲得という中で、ビジネスモデリングとか、ビジネスを可視化するっていうのは必要だから、方法論提唱者はシステム開発方法論の中にビジネスモデリングを入れたがるんですけども。
でも、それはそもそも間違っていて、ビジネスの中にシステムっていうのが部分的に存在してるわけですから、 もっと広い視野で、ビジネスの視点で、そこのデザインを考えるべきで。 そのビジネスのデザインを考える前に、何をしたいのかっていうビジネス全体の要求を捉えていくことが重要ですよね。
そこを捉えるための方法として、ビジネスモデリングっていうのがあるかもしれませんけども。 ビジネスモデリングだけでは問題がある。例えば、ビジネスモデリングをやったときに、 その価値って何なのかっていうのをモデラーも説明できません。そもそもその局面においてモデリングの効果とは何かを明確にする必要がある。単純に可視化ですよと言って納得されるような甘い世界じゃなく、システム開発に対する投資対効果も含めて結果を出していかなければいけない。
そこで、ビジネスモデリング活動を行うためのプロセスと、そのプロセスを実践するための組織っていうのがセットになった方法論が必要とされているのです。 そういうものをセットにした方法論が今まではあまりなかった。 そこをセットにして方法論として考えるっていうことがすごく重要だと思ってるんですね。
そうすると、これからの我々エンジニアも、そういう領域を改革していかなければいけないですし、 例えば、アーキテクトであっても、ビジネスとの接点を見つけていかなければいけない。 そうすると、どうやったらビジネスと接点があるのかなっていう、そういう構造の枠組みも、 例えば、UML を使って説明するなり、人が分かるようにちゃんと説明していかなければならない。
今は、そういうところがある意味で可視化できていないわけです。だから、そこを少しでも可視化できたり、なんかちょっとでもヒントになるような仕組みっていうのを作っていく。 そういうことが私の使命なのかなって思っていて。まぁ、あんまり豆蔵だけにこだわってなくて、 これから開拓していかなきゃいけないんで、みんなでやっていきましょう、という気持ちでやってますね。
-- やっぱりそういう方法論をまず考えて何かやっていくというやり方を好まれてるんですか？
そうですね。
-- Drop のような独自の方法論を打ち出される方は、あの時期の日本にはあまりおられませんでしたよね。
まぁ、方法論っていうのは、カタチ無いですから。定義自体は、自分で考えるべきだと思うんですね。 だから、プロセスが方法論って言われたり、モデリングが方法論って言われたり、時代とともに変わってくると 思うんですよ。 やっぱり、実践するときに何かガイドラインみたいなものがないとなかなか実践しづらいっていうのと、 私は今後ビジネスにしても IT にしても、すごく可視化が重要だと思ってるんです。
可視化っていうのは、UML でいうところのあるシーンのスナップショットっていう考えだけじゃなくて。 例えば、分析工程とか、設計工程とか、それを繋げるための活動の可視化。シナリオっていったらいいんですかね。シーンをイメージできるっていう、自分たちがやるべき活動の流れを可視化する。 それがうまくいってないから、自分が次にどういう流れで仕事をやればいいのかっていうことが分からないことが大きいかなと。
ビジネス要求と IT の要求を繋げるっていうこともそうですし、 分析と設計を繋げるっていうことだってそうですし。要は、分業するために工程を分けたり、ロールを分けたりしますが、分けたら今度は繋ぐことを考えなきゃいけ ないわけです。例えば、アーキテクチャのレイヤーを分けるっていっても、 サービスはそこを通貫していきますよね。 ソフトウェアだって結局は、分析、設計っていうのを通貫しない限り、分析の価値なんていうのは無いわけですよ。
IT 化においては、ビジネスの課題がまずあり、それからビジネスオペレーションを、 ビジネスオペレーションから要求を、要求からシステム要求を、 システム要求からアーキテクチャを、アーキテクチャから設計を、設計から実装を、っていうような 通貫しているものがあるんです。で、それぞれの後ろの工程には前に必ず根拠があるはずで、 それを繋げていくっていう話です。ややこしいのは、それは上流から下流へと流れていくわけ ではなくて、むしろ、並行して進むっていう特性もあるということです。
そこを本当に見えるような形で、「こうなってますよね」っていうようなことを、一つ一つ根拠づけていって、みんなで合意していくっていう活動がやっぱり重要だと思います。それができれば、繋がっていく部分が増えていくと思うんですよ。 綺麗に繋がるわけじゃないけれども、少なくともどういう形とか、どういう考え方の構造になっているかっていうことをみんなで理解していけば、見えてないものが見えてくると思うんですね。
-- 並行して進むというのはどういう意味なんでしょうか?
そういう特性もあるということです。 要求っていうのは、ビジネスから出るものもあれば、ビジネス課題を IT でどういうふうに見せるかによって付加価値が生まれるものもあるから両方向から創出される。よってビジネスの姿とITの姿を並行して模索する活動っていうのが必要になってくる。
-- 今お話してくださったことは、開発者側の活動を可視化するということでしたが、お客さんの仕事を可視化するっていうことも、当然、考えられてるんですよね？
そうですね。
-- むしろそっちの方がメインなのかなって気はしてたんですけども。
きっかけは、やっぱり私も開発者ですから、あくまで開発者としてどうあるべきかっていうところから始まって。例えば、オブジェクト指向技術をとってみて、どうこの技術を活かすべきかとか、本当に使えるとしたらどういうところで使えるのかとか、そういうことを考えていったら、結果的にそうなっちゃったっていうことなんですけども（笑）。
これ、ちょっと見ていただけますか（右図）？
要は、トップと開発者と業務担当者に壁があって、3 者がぜんぜん違うことを言ってかみ合わないことが多い。 業務担当者は、自分たちのやり方がベストだと、トップはこうあるべきだって言う。で、開発者はここはフレームワークを使えばいいよと。
で、うまくいってそうでうまくいっていないケースとしては、業務管理者とシステム開発者がある意味でコミュニケーションが非常によいケースです。トップダウンで開発した場合ですね。この場合は、実は業務担当者は、業務管理者が何も分かってないとか。分かってるか分かってないか分からないのに分かってないって言ってるわけです。その場合、システムがリリースされても業務担当者は使おうともしない。
で、これが一番多いと思うんですけども、確実に要求を聞き出してるんだけれども、その要求は、１業務担当者から聞き出したもの。それが理由で、レアケースのシステム化になっちゃってて。レアケースを扱うからいろんな機能が出てくるんですね。で、いっぱいシステムの要求を獲得しちゃうんです。で、60 %くらい使われなくなっちゃう。また、レアケースをシステム化してるから、業務を標準化しようとしても、システムに足を引っ張られる。
そういう問題を抱えるユーザ企業で、要求開発って必要だよっていう話をしてますね。そのときに組織づくりっていうのを考えていて、技術者っていうのはメンタリング能力だけに力を入れがちなんですけれども、少なくともプロセス推進力とかファシリテーション力とか、そういったものも持ってないといけないと言っています。
もう一つ、お見せしたい資料があるんですけれども（右図）。
システム開発における V 字モデルっていう、よく使われるやつなんですけども。要求開発はその前段階として存在していて、変形 V 字モデルって名づけてるんですけども。要は、ビジネスの要求を可視化することによって、システムはこうなるよっていうのを予測するわけですよね。ここをできるだけ早く見せるっていうことをちゃんとやっていきたい。そのときにモデルとか使っていくわけですね。
で、今何が問題になってるかっていうと、システム開発の前段階あたりで、業務やってる人達が蚊帳の外だったりするわけですよ。で、できたものを見てはじめて、「それならものすごく作業コストかかるよね」とか、「それやるんだったら、こういうふうに業務を変えなきゃいけないよね」ということを気づき、抵抗するんですね。 そもそも業務のシステムを作るっていうことは、業務を変えるっていうことに繋がるのに、そこの意識付けができていないのです。
で、要求開発の段階から、ユーザを要求開発チームに入れることで、意識作りをしていくわけですね。 その中でできるだけ自分たちが使える要求っていうのを抽出してもらうための活動をやっていこうとしているわけです。
-- そこで（右図）評価されるものっていうのは、モデルなんですかね？それとも実際に動くものなんでしょうか？
モデルとそのプロトタイプとか、そういったものを駆使してやっていくわけです。現状がどうなっていますかとか、ゴールに対するギャップはどうなのかとか、ゴールは一体なんなのかとか、そういったものをチームの中で作りこんでいく。そういう活動の場を提供するっていうことが、すごく重要かなっていうふうに思いますね。
-- 最初に要求開発とオブジェクト指向が関係しているといわれていましたが、それはそのモデルが関係しているということなんでしょうか？
そうですね。
2000 年くらいに豆蔵を立ち上げる前の段階から常に思ってたんですけども、例えばみなさんは分析モデルを作って、それがどのくらいの価値があるかっていうのは疑問視されたことはありませんかね。
分析モデルの作成をあくまであのフェーズでやるから、やっただけの投資対効果って本当にあるのかなっていうふうに疑問視することってあるでしょう。要は、モデリングっていう活動をソフトウェアプロダクトの一環として考えたときに、どの程度の価値があるのかって考えると色々と疑問があるわけですよ。 分析モデルのほかにも、オブジェクト指向でよく強調される、再利用性や拡張性の確保っていうのは、一つのプロダクトの中で収支が取れるわけではないので。
以前作成した Dropという方法論では、アプリケーションチームとコンポーネントチームに分けることで、アプリ開発と再利用という 2 つの課題をクリアしようとしていた。 でも、あれはちょっと行き過ぎたところがあってですね（笑）。 行き過ぎたっていうか、そういう組織っていうことに関しても触れてたんですが、それがまだ実践できるような IT 環境や業界の意識はなかった。
要は、オブジェクト指向の価値っていうのは、一個のプロジェクトの中では採算が取れるようなものでもない。そうすると、プロジェクトとは違うライフサイクルで、オブジェクト指向で可視化するとか、設計をやるとか、そういったものの価値をちゃんと考えていかないといけない。そうなると、プロジェクトから離れたところ、具体的にはシステム開発よりももっと前工程からやっていくべきだって思うようになったわけです。 その結果、要求開発方法論という方向へ自然と導かれたのです。
分析をやるといったときの可視化というのは、ビジネス領域に関わってくるようなところで、ビジネスの本質面での抽象化をして、そこの概念関係の構造を捉えていくわけですよね。 そうすると、どうしてもビジネスってところを理解しておかなければならないんです。システム開発の前段階でもう少しじっくりとビジネスの概念構造っていうのを捉えておいて、あとはユースケースでスコープをかけて、そこにシステム開発に関係するものだけを分析モデルとして抜粋してくというやり方がベストと思ってるわけです。
要は、オブジェクト指向の再利用性や拡張性、分析モデル、こういったものは、システム開発のプロジェクトの中では採算が取りにくいし、ちょっと無駄な部分が多いかなというふうに昔から思いがあり、しかし価値ややるべき根拠は非常にあるので捨てられない。 だから、そこを要求開発としてシステム開発の前に出していこうと。要はそこが私の課題だったわけですよ。
もう一つ、現代の開発においては、どうしても要求開発が必要だったのです。
最近、反復開発ということが注目されています。私は、ウォータフォールから反復開発に移行する根拠は、設計・実装のリスクヘッジと、曖昧な要求のリスクヘッジがあると考えています。 つまり早いうちにこの２つのリスクヘッジをするために分析・設計・実装を小刻みに繰り返す。石橋を叩きながら渡る的なプロセスですね。
しかし、両リスクは、反復開発においても解決できない問題が含まれているのです。
-- どういう問題でしょうか。
まずは、設計・実装におけるリスクヘッジについて話しましょう。オープン系の開発っていうのは、いろんなコンポーネントを寄せ集めて作っていくモデルですよね。そうすると、アーキテクチャのベースラインを、例えば RUPでいうところの推敲フェーズで作ることで、アーキテクチャの事前検証を行うことで、早期にリスクヘッジしようとするわけです。しかし、ここに問題がある。 アーキテクチャのベースラインっていうのは薄く広く作っていきますから。そのアーキテクチャを薄く広く作るっていうのは、どれだけ難しいことかっていうのは、多分やられたことがあると思いますから分かると思うんですけども。
-- はい。そうですね。
で、未知の問題領域に関しては大抵失敗するわけですよ。失敗したら次の反復でやります。で、どんどん後ろになっていくわけです。 それに対する回避策は、部分アーキテクチャのプロトタイプをまず最初に作って、 それを組み合わせるというのがあるかもしれませんけども、いずれにしても、リスクは高い。で、そのリスクを回避するためには、それをもっともっと開発の前段階、もしくは、方向付けよりももっと前でやらざるを得ないんです。
で、もう一点、仮にアーキテクチャベースラインを確立できたとしても、個々のシステム開発のプロジェクトで異なったアーキテクチャベースラインができたら、企業レベルでソフトウェアをメンテナンスする際、分かりやすさの観点から見たら問題が多い。また、開発コストの面での無駄も生じます。企業レベルでアーキテクチャというのを確立したいとか、そういう意図もあるわけですから。
そうしたら、システム開発のプロジェクトとは違うフェーズで、システム開発の前段階で、企業レベルのビジネス標準アーキテクチャを早く作る必要性がでてくるでしょう。この点がDropにつながるところです。
次は、曖昧な要求というリスクを早期に解消するという話に移ります。
旧来のホスト系開発の場合は、ある意味で制約された世界の中で要求っていうのを出していってるわけですから、要求っていうのがあんまり曖昧ではなかったんですね。 ところが、昨今は IT によりイノベーションを創出していこうとしているわけですから、 そういう高度な開発における要求は、形が分かり辛く曖昧だったりするのです。だから、要求を明確にするために、要求を検証するっていうことを、プロトタイピングなどを使って、方向付けフェーズでやったりするわけですよね。でも、それではあまりにも視野が狭いと思いませんか。 一つのシステム開発の中で、ビジネスを理解するとか、要求を獲得するっていうのは、 要求の根拠としては全然足りないんですよね。
そもそもビジネス課題があって、そのビジネス課題をどういうビジネスオペレーションで実現していて、そのビジネスオペレーションの一部をコンピュータシステムが担っていますので、システム要求の根拠は、ビジネスオペレーションにあるわけです。つまりシステムの切り出しを行う前に、ビジネスという観点で、要求の具現化が必要とされているのです。その中で、ビジネスを可視化し、改善を加えて、IT に繋げるわけです。
つまり、システム開発の中で曖昧な要求を具現化するという前に、要求開発の段階で、ビジネスのデザインの延長で要求を考える必要がある。その要求の中にシステムに対する要求があるのです。
なぜ、そのような当たり前の事が今まで疎かにされたり、話題に上がらなかったのかというと、システム主導でビジネスを考えることができていたからです。 経済的にドンドン発展している時代だったので、それが IT のナレッジとして蓄積されていたり、パッケージとして構築され、それを利用し、ビジネスをカスタマイズすることができてきた。 つまり、「ビジネスを IT に合わせてください。それだけで価値が出ます。」 というような売り方が通用してきたのです。 だから、システム寄りでビジネスを考えたり、要求を出したりできていたのだと思っています。
ところが、ビジネスがすごく急速に変化していって昨日の価値が今日の価値では無くなってきたっていう今の状況においては、ベースとなる IT の枠組みは使えなくなってきてるんですよ。
そうなると、ビジネス主導で IT をもう一度再構築しなければいけない。もしくは、既にあるコンポーネントやパッケージの利用方法を、ビジネス主導でマッピングしなきゃいけない、という状況に世の中がこれから気づくのです。 そのようなことに気がつけば、初めてもう一度ビジネスの姿を可視化して、改善・ IT 化ということを、ビジネス主導で、ちゃんとデザインしていこうということになるでしょう。
このような活動は、過去にホスト系ではあったんですが、昔みたいに制約された中で、システム開発をやってるわけじゃないから、更にいろんな課題がいっぱい出てきてるわけです。それを、一つ方法論としてまとめていく必要性があるのかなっていうところを今は感じてますね。
-- 2 点お聞きしたいことがあります。最初の質問ですが、アーキテクチャのベースラインを、もっと今より前の段階で確立したいとか、そういうことではないんでしょうか？
ウォータフォールの場合には、考えたものが机上で設計したらだいたい動いていたんです。ところが、オープン系になったらそれが動かない。だから、できるだけリスクヘッジするために、推敲フェーズとかの前フェーズでやろうとしてますよね。それじゃ遅いっていうことが、よく見かけられたっていうのが、1 つの理由です。
で、もう 1 つは、もしもそれで間に合ったとしても、各プロジェクト毎にベースラインができるっていうのは、メンテナンスビリティっていう観点からすると問題がある。 そしたら、ビジネスから IT に繋げるためのビジネスフレームワークっていうのは、たいてい同じようなものなんで、そこのベースはプロジェクトが始まる前に作っておくべきだという話です。
そのビジネスフレームワークのベースラインを作るプロジェクトと、開発するプロジェクトを分けて、ベースラインを作るプロジェクトはビジネス主導で考えていく。ビジネスフレームワークって、やっぱりビジネスを動かすためのフレームワークだから、IT の観点だけでやっちゃうとどうしてもビジネスフレームワークは使えなかったりするわけですよ。
-- ビジネスフレームワークというのは、ちょっと想像がつかないんですが。
ビジネスフレームワークというのは、サーブレットとか、Struts とか、そういうレイヤーではなくて、ビジネスレイヤーのフレームワークなんですよ。 ビジネスに特化したところの、ある意味で Struts にちょっと皮をかぶせたようなものです。 ものを作る必要性があれば、そういうのはプロジェクトの中で作るとコスト面で問題となるし再利用できないですよね。そのようなものを作る必要性を決断したら、企業のコンポーネントとして作っていきましょうというわけです。これは非常に高度な企業レベルのソフトウェア価値向上を目指すためにも必要となります。
-- それは、いろんなプロジェクトに共通で使えるような非機能要件みたいなものを実現して、残りのものはプロジェクト毎に実現していこうっていう感じですか？今言われたアーキテクチャのベースラインっていうのは、その共通の非機能要件っていうのを実現するものっていうことなんですよね？
いろんなプロジェクトに使えるビジネス共通機能や非機能は、共通のプロダクトでやろうということです。ユーザの人たちから、システムに対する要望っていうのを聞くと、たいてい個々の機能っていうのは、要求として出てくるんですけども。 それ以外の基本要求みたいなものを聞いていくと、システムってこういうところで使いづらかったとか、ユーザビリティも含めて色々出てくるわけですよ。 で、そこがその企業に特化したところの要求なんですよね。
そういう意味では、非機能要求が結構多かったりするわけですけども。そういったものは共通で作ったほうが、あるプロジェクトの A システム、B システムで違った見せ方をするとかそういうことにならない。 だから、アーキテクチャベースラインっていうのはいろんなタイプがあるから、プロジェクトの中で解決すべきことと、標準化すべきこととに分けましょうということです。
-- もう一つの質問ですが、さきほど、ビジネス主導でもう 1 回システムを考え直すといわれてましたよね。しかし、実際には技術とビジネス的な要件がていうのが両方絡み合っているっていう気がするんですよね。
絡み合ってますね。
-- 例えば、ビジネス的にはなんだかよく分からないんだけれど、ちょっと技術的に面白いからやってみたっていうことが、次のビジネスに繋がるっていうようなことがすごく起こってて。そういうものもビジネス主導というように捉えられているということなんですか？
まさにそのとおりです。IT っていうのは人間系を含むシステム全体の部分を補ってるっていうもので、 IT 側が大きいケースもあれば、少ないケースもある。 IT 系ベンチャー企業や組み込みシステムでは、IT 側の課題がむちゃくちゃ大きいですよね。 IT 側から出てきたものは要求と認めないなんていっても、話になんないわけですから。 そうすると、ビジネス要件と IT 化要件を抽出するための活動を同時並行的に進めるのが自然なのです。ビジネス主導という考えは、ビジネス主導で、ビジネスと IT のデザインを考えるということなのです。
-- なるほど。
「IT を考えずに、要求を出してください」なんて、ユーザさんに言ってること自体ナンセンスなんですよね（笑）。 だから、そこの枠組みが難しい問題になってくるわけですよ。常識的に考えたら今まで、我々がソフトウェア開発者として習ってきたのは、まずは業務要件を切ってから、IT を考える。 だけど、ビジネスと IT が組み合わさったところに、具現化できた要求っていうのが存在していて、その中には暗黙知があるわけですが、それがとても厄介なものなのです。
-- 厄介なものになっている暗黙知とはどのようなものなんでしょうか。
例えば、開発者の暗黙知っていうのはフレームワークの知識とかです。これって業務の人たちは全然分かんないですよ。でも、フレームワークが実際は、業務をIT化へ導きパターンを実現していくわけです。でも、ここの仕組みっていうのを、敢えて要求として出す人いないですよね。つまり、要求っていう文書の中に出てるものは、暗黙知以外のものが出てきてるはずなんですよ。だけど、そこが業務担当者には見えない分からない。
また、業務の人たちからすると、慣習化された業務っていうのは暗黙知になっているんですね。 で、これが開発者は分からない。ところが、この暗黙知になってる部分に、実は IT としてはすごく重要な非機能要件が入ってることって多いんですよ。それで、後になってこれが大きな問題をもたらすことになります。
こういう暗黙知をどのようにシステム要件として具現化すべきかということが、要求開発の課題と考えています。もし具現化できたとしたら、今まで百個で済んでいた要求が千個になるかもしれない。 千個になったときにそれをどうやって管理可能な個数に狭めていくのか、それとも千個の要件など出すべきではないのかというのが、要求開発プロジェクトの問題なんですよね。
結局、具体化すればするほどどうでもいいものも増えていくわけですよ。 それをどうやってコントロールするかっていうことがある意味で課題ですね。 この問題は、要求開発ツールの方で解決できる可能性もあるように思っています。
-- お話を聞いていて感じたんですが、そういう方法論を作るっていうこと自体、可視化するっていうことにすごい近いのかなって思いました。
ええ。
-- 多分、同じようなことは、いろんな人が考えてて、みんなぼんやりとは何か思うところはあると思うんですよね。だけど、そういうふうに方法論としてまとめられることによって、もっとそれがはっきりと見えてくるっていうこともあるのかなと。
私は、可視化っていうことは非常に柔軟に考えています。例えば、UML のモデリングっていうのは、ある状況におけるスナップショットみたいなものだと思ってるわけですよ。たまにスケッチモデルとか言われたりもしますけど。それは、今の状況をスケッチするとか、将来の To-Be モデルをスケッチするとか、そのギャップがどう違ってるかっていうのをみんなで合意するためのものですよね。分析、設計もそうですよね。ソフトウェアのあり方、構造をスナップショットしたものですよね。これを、スナップショットモデルというふうに呼びましょう。
-- ええ。
で、次に、As-Is から To-Be にどう変えたのか、変えていく過程でどういう判断や意思決定がなされたり、どういう寄り道しながら変えてきたのかっていうのがある。その As-Is から To-Be に変えていくような発見する過程を記録する。これをディスカバリーモデルとしましょう。
で、次は、このスケッチされる局面と局面の関係や、その中でモデルがどのような価値があるのかという、局面の定義と局面間の流れを定義することで、どういうストーリで作業を進めるかという時系列を伴うモデル。これがプロセスモデル。
で、最後に、この中で、プロジェクトに参加している人たちがどういう心理状況で、そこの中でどういうふうな葛藤がおこなわれていて、プロジェクトを遂行するためには、どういうタイミングで何を話したら、うまくプロジェクトがいい方向に遂行できるのか。これを、ヒューマンプロセスモデル。
このようにモデルとして可視化すると人はイメージを持ちやすいんですね。 私のアプローチは、人の活動をすべてイメージにするとか、ストーリにするとか、紙芝居を作るとか、実はそういう単純な発想なんですね。
ただ、方法論として可視化できる領域っていうのは、そんなにないからとりあえず、スナップショットモデル、ディスカバリーモデル、プロセスモデルを要求開発方法論として今テーマに挙げようと提案しています。
特に、時系列を含む可視化であるプロセスモデルは、ビジネスモデリングにおいて非常に重要で、時系列を含んでいるからこそ紙芝居的にどういうふうに進めていくのかの手順が分かり易く、モデリングの価値も局面ごとに定義され、その局面をどのように繋げていくかも定義するので、ビジネスモデリングの道しるべとなる。それができて初めて個々の局面で写真を撮るスナップショットである UMLによるビジネスモデリングの有効性が理解できるようになるし、価値が説明できるのだと思います。ですから要求開発では、プロセスモデルをもっとも重視しています。
Dropを作ったときも同じような思いがあって。昔の方法論って、非常に平面的に見えたんですね。平面的に見えてたっていうのは、分析と設計の違いがよく分からなかったんです。で、そこにプロセスを導入しようっていうふうに考えてみて。結局、今やっていることが、Dropと何が違うのかなっていうことをちょっと思ったりするんですけども（笑）。
Drop の場合にも、Rational Unified Process と同じように、ビジネスモデリングやらなきゃいけないなと思っていたんですけど、実はビジネスモデリングをどこに入れるのかっていうことで、すごく悩んだんですよ。 RUP は、プロジェクトの中に入れちゃったんですけども。やっぱりあれは切り離すべきだっていうふうに思ったり、切り離すとしたらもう一つ別の方法論作らなきゃいけないからどうしようとか。
運良くっていうか、今のシステム開発のプロセスはある程度形になってるんで、ようやくそっちの方に要求開発という姿で取り組めるようになって、私の中で少し罪意識が消えました。
-- オブジェクト指向と出会われたっていうのは、いつぐらいからなんですか？萩本さんって確かソフトウェアとは全然関係ない仕事をされてて 20 代の後半にソフトウェア業界に入られたんですよね？
ええ。 ユーザ企業にいたときに経理をやってまして、そこで COBOL とか、簡易言語を使って、公認会計士が太鼓判押すようなシステムを作り上げたんですよ。自分が作ったわけじゃなくて、私はユーザ側として数字合わせばっかりやってたんですけど。
で、その後 COBOL をちょっと覚えたから、この業界でやってみようかなって思ったら、２０歳前後の若い人が C 言語をバリバリやっててまして。もう愕然としましたねー（笑）。「俺は甘かったかな」っていう感じだったんです（笑）。
それから半年で生活難という理由で、新しい会社に転職しまして、今度はアセンブラでホスト向けのデバッガ開発をやったんです。もうガラっと変わっちゃったわけです（笑）。それからもう訳分かんない世界になって、自分はもうダメかなっていうふうにぐらいに追い詰められました。
そして、段々分かってきた頃に、ソフトウェアの構造っていうのがすごく気になり始めたんです。 そういう頃から、ソフトウェア工学とかを読み始めたり、学び始めたりしたんですけども、構造化手法はどうも感覚的にイマイチだなっていう、言っちゃ悪いけどオモチャっぽいなっていう思いがあって。つまり、設計は綺麗に作るけども、その綺麗に作ったものと自分が作ったプログラムとが全然似てない。だから、実際やってみても価値が感じられないっていう。
そういう中で、オブジェクト指向っていう訳の分かんないものが、世の中に出てきて。Smalltalk とか、これは何なんだろうなっていうふうに思いながら、少しずつ関心を持ち始めたんです。でも、自分がやってることと、オブジェクト指向が言ってることと何が違うのかよく分からないところがあって。
私は、データ中心で、データを関数でカプセル化して作るっていうのを、オブジェクト指向をやる前からやってたんですよ。それは何でやってたかっていうと、当時はプロセス間通信とかをやってて、共有メモリを管理するっていうことがすごく重要だったんですね。共有メモリを管理するのは、排他管理が必要なんで、データに対して関数をくっつけるっていうのが定石だったわけですよ。 だから、リスト構造とかのデータ構造のカプセル化をすっごく大切にしてた。
そういうことやってたんで、オブジェクト指向とどう違うのかなっていうふうに思って、オブジェクト指向に関心を持ち始めていったんです。結果的に分かったことは、オブジェクト指向っていうのは、自分が分かればいい世界じゃないっていう話ですよ。自分が分かって、それを人に説明するためにオブジェクト指向技術があるわけだから。
そういう意味では、分かりやすく作ることっていうことがオブジェクト指向の最優先で。要は、分かりやすさがオブジェクト指向の良さの 80% くらいで、再利用とか拡張性っていうのは残りの 20% で考えればよいって話なんですよね。この事を初心者のみなさんには是非とも頭に入れておいてほしい。どうしてもオブジェクト指向をやると難しく考えてしまい、再利用とか拡張性を追求し、分かりやすさを疎かにする傾向がありますからね。
その辺りが分かるまで結構時間がかかっちゃって、いろんな投資をしてオブジェクト指向の環境に慣れました。で、次にオブジェクト指向の開発しかしないプロジェクトチームを作って、その中でプロジェクト開発をやりながら、方法論っていうのを考えたんですね。そのとき、今の方法論っていうのがあまりにも平面的に見えたんで、プロセス込みの方法論っていうのを作ろうっていうことで Drop を作り始めたんです。実は、HORBを手がけさせてもらったのもDrop方法論をミドルウエア開発に適用してみたくてチャレンジしたのです。そのあと、そこで培ったノウハウをオープンな世界に広めていこうっていうことで、研究室みたいな形にしていったって感じですね。
-- Dropはアプリケーション開発の方法論だというイメージがあるんですが、HORB のようなミドルウェアへの適用はうまくいったんでしょうか？
あまりうまくいきませんでした。すべてプランありきで進められないので、仮説検証的なサイクルが必要となりました。そこでDropの最終バージョンで開発サイクルに「発想主導型開発サイクル」を導入しましたが、このサイクルの実践はまだできていません。発想主導型とは、言ってみれば仮説検証を繰り返しながら進める方法です。要求開発プロセスは、製品開発のような先の見えにくい活動という特性があり、清水建設の安井さんと共同で、仮説検証PDCAサイクルという姿を作り出し、新しいバージョンのプロセスとして提案しているところです。
-- オブジェクト指向の良さが分かるまでに時間がかかって、投資もされたということですけれども、なぜ投資をする価値があると思われたんですか？何か確信があったんでしょうか?
プログラミングテクニック的には絶対的にオブジェクト指向は有効である、 っていうことは分かりきってたし、5 年後にはもっとブレークするっていうふうに思ってました。だから、分かる過程の中で投資をしていったってことですね。
私のポリシーは基本的に 5 年後の仕事を自分の趣味でやる。そうすることによって、仕事に追われないっていうんですか、常に仕事が追っかけてくるようにしたいって思ってるわけですよ。で、そうなって来てるわけですよ。好きなものがどんどん自分の仕事になってるっていう。
-- その頃、オブジェクト指向が主流の技術になるっていうことをおっしゃっていましたが、今はどう思われますか？ オブジェクト指向の技術自体は、多分いろんなところで使われてると思うんですが、ソフトウェア開発に関わる人たち全体で言えば、きちんと理解されてないし、使いこなせてる人っていうのは、そんなにいないんじゃないかなと思うんですが。
そのへんはやっぱり、我々にも責任があると思うんですよね。正しく伝え切れてないっていうのと、やっぱり分かりづらいところがありますよね。もっとダイレクトに分かりやすい形で、見せていく必要性があるかなっていう。
あとは投資効果ですよね。 これだけ作業をやったのに、これだけのものっていうことが、疑いの目で見られるっていうところがありますよね。だから、ビジネス的にもまだ洗練されてないかなって。そこをもっと洗練させて、ビジネスの中でどうしても無くてはならない思考法なんだっていうように。オブジェクト指向って分かりやすく言うと思考法ですよ。 そういうふうになれば、価値が出てくるかなと思いますね。
でも人の思考法や認知技術という観点まで達してしまうと、半世紀程度のサイクルで成長と衰退を繰り返しているのでは。最近の問題は、IT だけでは解決できず、人の活動や思いをどう制御するかという点が重要なのですから、ここにチャレンジするしかないのです。そうなると自分の一生をかけても終わらないというのは目に見えています。オブジェクト指向も一部、そういう領域が入りこんでいるので、なかなか定着しているように見えてこないのではないでしょうか。でもきっと、いつの間にか、ウイルスのように人の活動に定着していくのではないかと。
それに、ソフトウェアテクニック面では、うまく使われてるようになってるし、当たり前のように使っていってると思うんですよ。私も最初はそれだけを認めてました。 あとは、ちょっと訳の分かんない世界っていうか、嘘っぽい世界だなって思ってたんですね。 段々やってるうちに、結局何が価値なのかっていうことを追求していけばいくほど、 その自分が嘘っぽく思ってた領域に踏み込まざるをえないんですね。
昔、私は、そういう上流のオブジェクト指向技術を提唱している人たちをすっごくバカにしてたんですけどね（一同笑）。
-- プログラマだとありがちですよね。
ええ。それなりに根拠はあったんですよ。要は、オブジェクト指向で言うところの理想と現実が繋いでないじゃないかっていう。
で、繋ぐために、私は努力して上の方までいってやろうとしてる。だけど、おそらく今若い人が私をみると嘘っぽく見えると思うんですよ。それって、どういうことかっていうと、結局、人間がどうやって物事を判断して、みんなでその合意してるかっていうところに、どれだけ関心を持ってるかっていうことですね。私は若い頃、それがあんまり分かんなかったわけですね。自分がわかればいいっていう。オブジェクト指向を使うことで、プログラミングテクニックは数倍上がった。オブジェクト指向すごくいいなという、まずはその価値が分かったんですね。 でも、もっと上のところは分からなかった。ちょっと疑いを持ってました。
現実世界のオブジェクトと、コンピュータ世界のオブジェクトって違うじゃないですか。
-- ええ。
現実世界のオブジェクトっていうのは、なんの理由もなく存在しているわけですよ。人間の人工物は理由があるわけで、人工物はオブジェクトに似てるんですね。少なくとも、システム開発のオブジェクトっていうのは、何らかの根拠があるわけです。それは、要求にあったりするわけですよ。だから、理由もなく存在している現実世界のオブジェクトをそのまんま、コンピュータ世界に写像するっていうのは嘘っぽいわけです。
だけど、ソフトウェアを理解したり、認知したりするっていう行為の側面では、現実世界を認知するっていう行為とほぼ同じでしょう。人は、目を瞑って考えている時は、現実世界の「もの」も、ソフトウェア世界の「もの」も同じようなイメージとして処理しているのではないでしょうか。オブジェクトに対して、現実世界から名前を借用して付けてあげるだけで、嘘っぽい世界だけれども、みんなが認知できるっていうのは事実なんですよ。 それをソフトウェア世界にどうやってうまく使うかっていうところが説明しきれてない。それが説明できればソフトウェア世界っていうのも、今よりも少しだけ分かりやすくなると思うんですよね。
そういうことにやっぱり挑戦していかざるをえない。そこを嘘の世界だっていうふうに言った途端に、ある意味でもうお手上げしているっていうことで。だったら、オブジェクト指向いらないじゃんっていう話になっちゃうかもしれない。
-- 結局、その可視化するっていうところに繋がってるっていうことですよね。
そうですね。 私は無いものを作り出すわけですから、創造していくってことだと思うんですよ。 つまり、現実世界のものに例えて名前を付けてあげて、そこにあたかもあったかのように見せる。
例えば、デザインパターンなんかも、あれはみんな思ってたことだけども、パターンを作ることによって、今まで無かったものがあったかのように見えるわけですよ。 そこまで広げて考えていくと、どうしても分からない曖昧な世界に突入せざるをえなくて、そこを扱い始めると、私自身も混乱の渦に巻き込まれます。だけど、今のビジネスの世界にしても、IT の世界にしても、そこがすごく課題になっている。 だから、人間の活動自体を可視化する。ビジネスストーリーを明確にすると、ビジネスが分かりやすくなったりしますよね。ユースケースだってユースケース記述を書くことによってイメージが湧くわけですよ。そういう可視化をこれからちゃんとやっていかなければいけないと思っていますね。
-- 現在、興味を持って取り組まれている技術っていうのは、要求開発以外に何かあるんでしょうか？
結構いろいろ幅広く見てますけども、これといって注目してるものはあんまり無いですね。まぁ、興味持っているのは、ファシリテーションとか、そういう領域ですよね。 どうやって人間の活動の中で合意を取っていくかっていう。でも、あんまり見たくないっていうこともありますけども。見た途端になんか、自分の中でアイデアが全く無くなってしまうんで。言葉は参考にさせてもらうっていうところですよね。
結局自分で納得しない限り、人に説明できないですからね。それはすごいワガママだと思います。エンジニアとしてっていうか、企業人としてはね。 すごくワガママで、おそらくみんなに無茶苦茶迷惑かけてると、思ったりはしますけども（笑）。それは自分の生き方だから仕方ないな、というふうに思ったりもしますね。でも、ある意味でそういうことを認めていただいて、一緒にやっていただける方が結構多いんで、この業界には感謝してます。拾ってもらったと思ってますよ（笑）。会計士にはなれなかったと思うんで（笑）。
-- そうなんですか？
この性格。あまりにも大雑把すぎて（笑）。
-- 興味の方向が変わられてますよね。昔はもうちょっとプログラミング寄りのとこだったと思います。先ほどの話だと、今はもう少し人間系というか、ビジネスとかに興味をもっておられると思うんですが。そういうきっかけっていうのは何かあったんですか？
いやぁ、あんまり無いですね。変わってないですよ。
-- そうなんですか？
もともと、理想と現実を繋ぐのが私の永遠のテーマなんですよ。理想っていうと、上流ですね。現実は実装ね。そこの境目が埋まってない。最近では、ちょっと広く捉えるようになり、切ったものを繋げる作業と捉えています。
そもそも文明っていうのは、いろんなものを作業単位に切るっていう。アーキテクチャだってレイヤーを切るとか。プロセスだって工程を切るとかあるじゃないですか？それに加えて、人の活動をロールに分ける。
-- ええ。
だけど、そこを繋げない限り、サービスが提供されたり、ソフトウェアって動くわけないですよね。で、切ることばかり進みすぎて、それぞれの担当者がロールという帽子をかぶって牢屋に入っているような感覚なんですよね。
だから、繋げるっていうのがむしろ重要。切ってから繋げる方法を考えるっていうんですかね。さっき言った昔からの私のテーマである現実世界のオブジェクトモデルとシステム開発のオブジェクトモデルって根本的に違っていて、そこをいったん切った上でそれをどう繋げるかっていうことが随分前の課題だったわけです。
-- シームレスに繋がるっていうよりも、1 回切ってるんだけど、もう少し緩く繋がり直すようなイメージなんでしょうか？
切った個々の領域の価値と活動を定義した上で、活動の中で繋げるところを繋げるっていう感じです。分けたものはそれぞれに価値がある。だから、切ってそこで作ることは重要だと分かってるんだけども、それを繋げることにも価値があって、繋げない限り、それぞれの切ったものの価値が意味がないっていうことにもなっちゃうんで。 だからといって、切らないで最初からグシャグシャにしていいかっていうと、そうでもないですよね。
だから、そういう観点で考えたら、最初っからあんまり変わってない。ただ、仕事の中で私はプログラミングっていう領域をずっとやってきてたので、そっちからのアプローチが多かったってだけですよね。
でも、そもそも私って、ユーザ企業にいたわけですから、ソフトウェア開発に関しては、すごい冷めた目で自分を見ていて。もう一人の自分がいるような感じで、「お前そんなことやってていいの？」っていうような、そういうことを常に思っているわけですよ。 「それって、何の意味があるの？」って。「オブジェクト指向って、そんなにいいの？」っていうふうに、いつももう一人の自分から責められるわけですよ（笑）。
「すいません。説明できません。」って、いつも言ってますね。
（一同笑）
でも、今は、そういう葛藤の中から説明できる部分が増えてきてる感じですね。
-- では、プライベートなお話をうかがいたいと思います。例えば、趣味だとか、休日の過ごし方について話していただけませんか？
子供とドライブするのが大好きですね。
一卵性親子って言われてるくらい似てて、いい加減なところとかね。 全部、真似するんですよね、私がやることを。中学 2 年生なんですけど、ちょっと幼いかな（笑）。
-- 中学校 2 年生で、まだ休日に一緒に遊んだりとかするんですか？
結構一緒に遊んだり、行動したりしてますね。部活とかそういう以外では。父親としてというよりむしろ、なんか色んな意味で一緒に語り合ってますね（笑）。
後は、音楽を聴くことが大好きですよね。
-- どういう音楽を聞かれるんですか？
基本的にクラシックとか、オペラが大好きだったんですけど。最近は変わったところで、50 セントが好きです(笑)。
-- (笑）。全然違う世界じゃないですか。
これはいいなって思って。それから病みつきになりまして。うちの子供も好きなんですよ。まあ一卵性親子なので、趣味や好きな食べ物や幼稚なところまで似ているんですね（笑）。うちの奥さんは、クラシックとか、オペラが大好きで。で、車の雰囲気がガラッと変わる。
（一同笑）
奥さんが乗ってるときは、奥さんモードにしろっていって。一度 50 セントなんかかけてたら「うるさいね」って言われて。それで、息子との時は、50 セントかけ始めると、窓全部開けて。冬でも僕は開けっ放しでドライブしてる、子供と一緒に。
で、奥さんきたら、窓全部閉めて、クラシックを聞くようにしてる（笑）。
そうやって結構休日とか楽しんだりしてますね。
あと、私は結構考え事をしますね。海辺で 1 人で考え事するのが好きですね。みんなが寝静まった夜中の 2 時ごろコッソリと抜け出して。
（一同笑）
横浜マリーナとか。
あと最近よく行くのはね、赤レンガとかね。別に覗きにいくわけじゃないですけども。
（一同笑）
私は、机に座って時間をかけて考えるのがダメなんですよね。なんかぼーっと歩きながら考えるとか、クルマに乗って考えるとか、海を見ながら考えるっていうと、なんか調子がすごくいいんですよね。
だから、電車はもう、ほぼ毎日間違ったりしますよ（笑）。地下鉄乗るときとか、ほとんど考えてないですよ。
熊本出身なんで、電車は上りか下りしかなかったわけですよ。その感覚がどうしても抜けなくてね。電車に乗ったら、どこに行くかあんまり見てないんですよ（笑）。だから、萩本さんに道を案内してもらうつもりは、全くないですからって社員から言われる（笑）。
-- その気持ちはすごくよく分かります。山口県出身なので、ほんとに上りと下りしか無くって。
でしょ？
だから、とんでもない間違いしますからね。新横浜で待ち合わせするのに、横浜で降りて探してたりね（笑）。 駅名が突然分かんなくなってね。打ち合わせ行くときに迷っちゃって。 だから、そういう自分を知ってるから、30 分前に着くようにしてるんですよ。 30 分前に着くようにしてても、たいていギリギリで着きますから（笑）。 ちゃんとリスク管理はできてるんですけどね（笑）。
いつも無駄な人生送ってるなと思ってるんですけども。だからといって生き方を修正しようっていうところは無いですからね。
-- 考え事をされるときは集中してされますか？それとも、いろんなテーマで考えられますか？
最近分かってきたんですけども、すごい短い時間、短いっていっても 5 分くらいを定期的に繰り返し考えることで少しずつイメージを軌道修正しながら頭の中に定着させているような気がしますね。
-- それは同じテーマに対してですか？
同じこともあれば、複数の断片的なテーマもあるかな。ちょっと視点を変えたり。ずっと考えるっていうことはできなくて、なんとなくいつも考える。なんとなくが習慣的に、あれってどうだったっけ、これってどうだったっけ、これはどうするんだっけなとか、そういうのが突然湧いてきて、段々イメージの世界に入っていって、自分がある意味でお芝居をしているような、自分が考えてる自分を見ているような、そういうモードに入っていくとすごく調子がいいんですよ。 そこで考えたり強烈なイメージとなったものは体験とすり合わせることで、コンサルティングのネタにもなるし、豆蔵としてのビジネスにも繋がっていくし、とりあえず価値があるかなっていうものは出せるんですね。
だから、机に座って、さぁ仕事やろうっていうとバッテン（笑）。むしろ現場に行ってお客さんのところでなんか色々やってる方がいいですよね。打ち合わせをしてたり、人と話をしてたりして。
それは、プログラミングをやってるとこからそうだったですね。バグとか発見するのはたいてい帰りの電車の中とかね。ぼーっと考えてるときに、突然、ハッと違うやり方でやったら、うまくいくんじゃないかなって思って、ワクワクしながら家に帰って（笑）。 「おー、うまくいっちゃったよ」とね。
（一同笑）
-- それでは、若手エンジニアへのメッセージをお願いします。
今の若い人たちが興味を持っている Struts とか新しい技術に関してはちょっと不安がありますね。プログラムの外出しを XML でやろうとしてるじゃないですか。 リソース管理がむちゃくちゃ大変になって。
-- ええ、大変だと思いますね。
システムの変更点・拡張点について柔軟性をもたらす代わりに、リソースの管理に問題がおこってますよね。その問題を解決するためには、プログラムの接合点を管理可能なビジュアルツールありきで考えるべきなのに、現在のところそのような動きが見られないように思うのです。その背景には、ツール開発のコスト的側面や、標準化、開発スピードなどがあると思っています。
すごく行き当たりばったりっていいますか、土方みたいな開発になってきつつあるなっていう。本来進むべき方向性とは違う方向に進んでるっていう気がするのが、 オブジェクト指向技術っていうか、今のオープン系の技術には不安があって。それがオブジェクト指向のある意味で洗練された形であるというように若い人達がもしも思ってるとしたら、それは大きな間違いであって。これはすごく技術の進み方としては、変な方向に進んでるなってちょっと見えてしまうんです。
一時は過渡期だと思ってたんですが、今は過渡期じゃないような気がするんですね。
-- 過渡期じゃないんですかね？多分、その十分なツールが出てないっていうのが。
前はそう思ってた。でも、十分なツールが出てないことがこれだけ続くと、それがある意味で当たり前の世界になってしまうような気がする。
ツールを出さない理由は、やっぱりビジネスとして価値が無いからだと思うんです。つまり、技術自体がどんどん進歩してる中で、 ツールが出せないっていう状況に追い込まれていく。 コンセプト的には、ツールで補おうとしてるにも関わらず、ツールを作る価値が無いってなった途端に、それは誰が負担をしなきゃいけないかというと、エンジニア達ですよね。
オブジェクト指向の特徴っていうのは暗記の世界から、意味論の世界に移ったんだと私は思ってたんですけども。意味の世界を追求しようとしてたのに、また暗記の世界に逆戻りしてる。そこのデータは XML で、そこはそっちでっていうふうにバラバラになってきている。
-- J2EE に関しては多分そういう方向にどんどん進んでるじゃないですか。みんな設定ファイルで外に出して動的にオブジェクトを関係付けようとしてますよね。それはそれで意味があってやってるんですが、大規模開発だとつらいだろうなっていうのは、すごく思うんですよ。
そうですね。そういうような技術は、フレームワークを作るための技術だと私は思ってるんですけども。 そういうところに、みんなが着目しては駄目だと。それは小さなアイデアで、パターン化すれば済むことなので。やっぱり若い人達には、自分でそういうようなアイデアを出すとかしてほしいですね。DI コンテナっていうのは話題よりも、やってることがちゃっちいわけですよ。そこに対して、大きな技術だと思って欲しくないなっていうふうに思うわけです。
もっと、エンドユーザよりの問題を解決するっていうところに対して、技術力を使うように思うとか、製品のコアのユニットを作るとか、ツールを作るとか、そういったところで自分の技術力を試そうとか、自分なりのフレームワークを作って世界に出そうとか、そういうことをやってほしいなって思いますけどね。
なんか、説教じみた話になっちゃいましたけど、ちょっと気になるところです。
-- そうですね。Struts にしろ、 DI コンテナにしろ、メディアでは素晴らしい技術として取り上げられてるんだけど、そういう暗黒面は、エンジニアがちょっと話してるくらいで、大きく取り上げられてないっていうのは不安に思うんですよね。
うん。うん。
-- 実際、アプリケーションが管理しにくいじゃないですか。
うん。もう少し、そこをちゃんと説明しなきゃいけないんじゃないかなと思いますけどね。 その技術は、ある意味、どういう領域で使えるものであって、そこに対して足りないものがなんであって、今後どういうふうになっていくのかっていうのをやっぱりちゃんと解説しなきゃいけないかなというふうに思いますけどね。
だから、私が伝えたいことは、そういうものだけではなくて、そこはわりと標準化されたもので、非常にシンプルに作ってあるから、そこに技術の難しい領域っていうか、そういったものはないですよっていうことです。そこは、見ればそれで済む話で、もっと違うもっと難しい問題にチャレンジしてほしいですね。
で、IT のどんなにコアな部分のテクニカル上の仕事をしたとしても、その価値を人に説明できない限り、エンジニアとしての価値がないと思った方がいいと思ってて。そこは考えてほしい。私がそういうことをいろんなメディアで言っちゃうと、どうしても勘違いされる人がいるんですよね。「我々もビジネスを理解しないといけないのか。私はエンジニアだ。」と。 そういうことじゃなくて、ビジネスを理解するっていうことは、自分の価値を人に説明するっていうことですよね。
それが、ビジネスっていうところに繋がってくるんで、それをやってる限り、何れはビジネスっていうのを理解するっていうところになってくると思って。エンジニアとして、技術をどんどん追求するとしたら、その追求している技術がどういう価値があるかっていうのを人に説明できない限り、多分、自己満足で終わってしまう。
昔はそれでよかったかもしれませんけどね。追求してる人と、それを世の中に出していく人と役割分担がなされてても、それでいいっていう世界だったと思う。今は、もうダイレクトにその価値って何ぞやっていうことが問われるような状況なんで。そういう観点は、是非若いうちから養って欲しいなと。 だから、自分が追求してる技術に対して、ちゃんと人に説明できることが課題かなと思いますけど。
-- それは自分が追求してるものだったり、自分が生み出したものっていうのがどういうもので、周りの人達にどういう価値があるかっていうことをきちんと伝える能力がないと駄目だっていう話ですよね。
そうそう。自分流のやり方でいいんで。 だから、例えば、自分はアーキテクトを目指したいといって、アプリケーション開発の中で自分が考えてるアーキテクチャはこうだとか、自分が考えてる設計はこうだとかを勝手にやっちゃうとそれは間違ってるかもしれない。お客さんの求めてるものと違うかもしれないですよね。
お客さんが実現したいことに対して、お客さんに「ここの設計っていうのは、こういうところでは強くて、ここは柔軟な構造になってます。その反面、こっちの方は弱いんですよ。」っていうことを言えるかどうかですよね。
例えば、こういう拡張に関しては耐えられないけれども、こういう拡張に関しては耐えられるっていうのは、オブジェクト指向では当たり前のように存在してるわけです。そういうことの拡張点をもし誤ったり、勝手に考えてお客さんを無視してやってたりすると、後でお客さんからビジネスが変わったからこういうふうに変更したいって言われたときに、「それはできません」となる。「えっ？あなたは拡張性のあるソフトウェア開発をやってたんですよね？そういうアーキテクチャを作ったんじゃないの？」っていうように、言われるのがオチじゃないですか。
だから、自分の作ってるものの価値っていうのを、ちゃんと人に説明するっていうことに対して訓練をすることによって、自分の価値っていうのが初めて人に理解してもらえると思うんですけどね。
-- 今伺ったようなお話って、多分リクルート系の雑誌だったり、Web サイトとかでたくさん話されたと思うんですけど。そういうことを敢えて言われるというのは、やっぱり、自分で何かそうすればよかったなっていうような想いがあるんですか？
結構苦労しましたからね。例えば、HORB とか。 今は、こういうこと言ってるけれども、自分自身もやっぱり HORB の分散オブジェクト技術の価値っていうのを人に説明するっていうのは、本当に難しかったですよ。 だけど、それをある意味でやったからこそ、そういうことが見えるようになったんで。自分が見えるようになって、今こう威張っていってるかもしれないけども、それは本当に大事なことだというのは分かってます。
だから、私も見えない時期もありましたよ。人に説明しなくてもいいっていうよりも、説明するところを自分でうまくやれてなかったところはあったかもしれませんけどね。 だけど、運がよかったのは、方法論を作ろうって思ったことかもしれませんね。方法論作るっていうことは、結局、人が「読んで」、「理解して」、「使える」ようになって、初めて方法論なんですよね。
だから、人がどうやったら理解するかっていうことを常に考えてたんですね。そうすることで、人に説明する力に繋がったり、エンジニアが抱えている問題っていうところがある意味で見えてきたりしたんですね。方法論を作ろうって考えたのは、そのきっかけになったんじゃないかなと思います。
| ©2005 OGIS-RI Co., Ltd. |
|
