Rationalとの出会い（前編）
1. はじめに
初めまして、本コラムを担当させていただきます日本IBMの太田健一郎と申します。
本コラムではIBM Rationalが提唱し、お客様に提供している開発プロセスやツールの有用性を実際の開発現場のSEが実体験に基づき建前ではなく、本音で語ってみたいと思います。
わたしたち開発者にとって、Rationalの開発プロセスやツールはIBMがお客様に販売しているほかの製品と大きく異なることが1つあります。それは、Rationalの製品がお客様のターゲットとして、主に（注1）開発者を対象にした開発者のための製品であり、自社の現場のSEたちも使用する製品であり、その意味SEとしてはもっともお客様に近い視点で接することのできる製品だということです。つまり、わたしたち自身がプロジェクトで活用し、その有用性を実証することができれば、営業やプリセールスSEのメンバーだけでなく、我々自身も自信を持ってお客様に製品をお勧めすることができるということです（注2）。
（注1） IBM Rational Portfolio Managerを始めとして、経営者や組織を横断したManagerを対象にした製品も存在します。
（注2） WebSphereブランドやLotusブランド、Tivoliブランドの製品開発には実際に各種のRational製品を利用しており、社内でも有用性が実証されている製品群です。
と、何か、いきなり宣伝っぽくなってしまいました。わたしはもちろんお客様にはRationalブランドの製品を買っていただき、ソフトフェア開発の効率化、高品質化を目指していただきたいと本気で願っている人間ですが、Rationalブランドの人間ではありませんし、決して営業トークでこのようなことを書いているわけではありません（注3）。
（注3） 別に営業の方がお客様のニーズを発掘していなかったり、実体験に基づいていなかったりなどと言うつもりは毛頭ありません。
わたしはRationalがIBMに買収される前からのRationalユーザーであり、Rationalの開発プロセスやツール群、特にRUP（Rational Unified Process）、正確にはその前身であるOOSE（Object-Oriented Software Engineering）によってこの世界に踏み込んだ人間といってもよいので、わたし自身の実体験からRational製品の有用性をお話したいのです。
前置きが長くなりましたが、今回はそのRationalとの出会いを書いてみたいと思います。長くなりますので、前編と後編に分けてお話したいと思います。
2. プログラムってどう書くの？
わたしが本格的にコンピュータに興味を持ったのは、高校時代でRPG（Role Playing Game）が好きだったのと、家に父親が持っていたPC-8801やPC-9801 noteがあったので不遜にもRPGを自分で作ってみたくなったというのが理由です。
といってもいきなりゲームを作ったりするのは無理だということがコンピュータを触り始めてすぐに分かりました。しばらくはN88-BASICのリファレンス・マニュアルをROM版のN88-BASIC（86）にひたすら打ち込んではちょっと変更ということをして遊んでいました。
BASICの入門本を買ってみると、アルゴリズムなるものが世の中にはあって、どうやら数学の解法のようなものらしい、問題に応じてこれを使い分けて、プログラムを作っていくのだということがなんとなくわかってきました。
そして、高校3年生の時に2年間アルバイトをして貯めたお金で、PC-9821XsというNECのPCを購入し、ようやくカラー環境（これまではお下がりのPC-9801NSとPC-8801mkIIを使い分けていました）で、今度は無謀にもBorland Turbo C++を購入し、C言語に挑戦して、これまたC言語の入門本とにらめっこしながら学んでいきました。
大学の学科も実に不純な動機でゲームを作りまくれる学科があるなど全く間違った思い込みの元、情報学科というものに入学しました。
まあ、待っていたのは思っていたのとは全く違った世界でしんどい情報数学の世界だったのですが、それはさておき、一応、学科でもプログラミングの演習はありました。自習と大学の演習の両方で、それなりにプログラムが書けるようになってきたと思ったので、冬至愛読していたマイコンBASICマガジンの投稿プログラムのソースコード（注4）を打ち込んでみようと決意しました。
（注4） 当時はソースコードが投稿プログラムとして掲載されていました。このころともう少し前の時代のパソコン雑誌では普通だったと思います
3. どうやったら要求から実装につなげられるの？
そこでつまずいてしまったのです。ソースコードが載っているページには同時にゲームの概要が載っていて、そのゲームがどの様なものなのかということが書かれているのですが、その概要とソースコードがどの様に結びついているのか、はたまた作者がどの様な思考過程を経てこのソースコードにたどり着いたのか全くわからなかったのです。どうも、投稿雑誌だったということもありますが、演習のようなものではない本格的なプログラムというのは一部の特殊な才能を持った人たちしか書けないのではないか、やっぱり自分が感動したようなRPGを作るゲーム・クリエーターになる（注5）のは無理のようだと挫折感にさいなまれました。
（注5） 無謀にもまだ思っていました
その時は、ソースコード自体は何とか打ち込むことができたのですが、ソースコードの意図がよく分からなかったので、間違えたときにデバッグするのが非常に大変でした。そのため、ソースコードを見て打ち込むと言うのは何度かやってみたもののしんどくなってきてしまってやめてしまいました。
そこで思ったのはどうも、ゲームの概要とソースコードの間には何か大きなギャップがあって、それが一人でゲームを作ろうと思ってもできない原因ではないか（注6）と思うようになりました。
（注6） 実は才能がないというのも大きかったのですが
演習やプログラミングの入門書に出てくるような簡単な例題だったらアルゴリズムさえ知っていれば思いつきで何とかできるのですが、どうも作ろうとするものがある程度の大きさになるとそのような思いつき駆動ではプログラムを書くことができないということが分かりました。
4. 古典的な方法を知る
そんなこんなでどうもゲーム作りには程遠いと言う状態だったある日、ソフトウェア工学なる授業があって、そこでフローチャートとPAD（注7）というものに出会いました。
なるほど、いきなり問題（注8）をプログラムにするのではなく、このようなダイアグラムを使って整理すればプログラムを書けるようになるのか、これがソフトウェア工学なのか！ゲームは天才だけが作れるものじゃなくて凡人でも作れる方法があったのか！ソフトウェア工学素晴らしいとか一部間違った認識を持ちながら、ダイアグラムとソフトウェア工学というものを知りました。
（注7） 日立の標準として使われていた構造化設計用のダイアグラム
（注8） そのころは要求や要件なる言葉も知りませんでした
それで、一時、goto文を許してしまうフローチャートはどうも好きになれなかったので、基本的にgoto文を許さないPADにはまってなんでもかんでもPADにしてプログラムを書くと言うことをしていました。
そのころのメインに使っていたプログラミング言語はCだったのですが、コンパイラはTurbo C++だったので、どうもC++というのはCよりすごいらしいとTurbo C++のマニュアルを見ながら思ったので、これまた無謀にもC++に挑戦してみました。
5. オブジェクト指向でプログラムが書けない
ところが、PADにはまりすぎたのでしょうか、BASICの期間が長すぎたのでしょうか、どうもオブジェクト指向なるものが理解できません。Turbo C++のマニュアルにはC++のライブラリの説明は載っていても、オブジェクト指向でのプログラムの作り方は載っていませんでした。これまたどうやって、問題をオブジェクト指向のクラスに落としていくのか、そして動くプログラムにしていくのかさっぱりわからず、結局関数とメインでできた構造化設計で問題を片付けていたのです。
6. OOSE（Object-oriented software engineering）と出会う
そのころは大学の情報数学の授業についていくのが厳しい状況で、予習と復習のために自習室にこもって勉強していました。自習室の隣には図書館があって自習がしんどくなってくると、そこでPC関係とプログラミング関係の雑誌を読んでいました。同時にプログラミングや設計の本も探しては借りて読むということをしていました。学生でしたのでそう何冊も高い専門書は買えなかったのです。
その中で、ようやくたどり着いたのが、オブジェクト指向方法論なるカテゴリでした。どうも、Booch法とOMT法なるものがすごいらしいということが分かり、無謀にもチャレンジしてみるのですが、どうも最初の問題（要求）からフローチャートでいうところの設計に落とすところにギャップがあって、わたしにはどうもこれらだけではやはりうまく現実の問題をプログラムまで落とすことができませんでした（注9）。
（注9） ただし、Booch法もOMT法もそれぞれRUPの前身であり、RUPに取り入れられた有用な部分はたくさんあります。当時のわたしが最も求めていた部分に対する解決策が弱かったというだけです。
そこで、最後にようやく見つけたのが、OOSE（Object-oriented software engineering）こと「オブジェクト指向ソフトウェア工学」です。OOSEでは現在のRUPやUMLでも採用しているユースケースとユースケース図によって機能要求を表します。ようやく、要求を表す方法が分かりました。そして、ユースケースごとにクラスをBoundary、Control、Entityのステレオタイプごとに抽出して、最後に各ユースケースを実現するクラスを合成していき、分析段階のクラスを完成させるという現在のRUPでも採用している要求と分析のプロセス（注10）が例題を交えて分かりやすく解説してありました。それまで読んだオブジェクト指向方法論では、自分の読解不足からでしょうか、どうも、クラスやデータモデルがインスピレーションをもって天から降ってくるような書き方がされていて、例によって、「天才でない自分にはやはり無理なのか」というマイナス思考にさいなまれていました。読んでも凹むばかりでした。しかし、OOSEは、これなら、自分でもできる。やってみよう。オブジェクト指向はやはり素晴らしい！ と自信を与える何かがありました。
注10) RUPでは作業分野と呼びます。
特に素晴らしかったのが、一見オブジェクト指向ではなさそうですが、実は取り掛かりとしては書きやすいユースケースと、クラスのステレオタイプですね。オブジェクト指向を勉強し始めて難しかったのが、どの様なクラスをどの様な基準で作ったらよいのかが、構造化技法の知識と経験からは全く分からなかったことです。
しかし、OOSEではユーザーとのインタフェースを受け持つのがBoundary、永続的な実体を表すのがEntity、そして、Entityを調停し、BoundaryとつなぐのがControlと非常に分かりやすい役割分担でしたので、これらとユースケースを合わせれば自分でも作成できそうだと自信がもてました。
同時に、構造化技法ではあまり言及されていなかった繰り返し開発と言うのも新鮮でした。ああ、なんだ、一度に完成させようとしなくていいのか、これなら何とかなりそうとこれまた自信がもてました。
これからこのコラムでも書いていきたいと思いますが、RationalとくにRUPにおいて最も重要だと個人的に思っていることは開発方法論とは天才のためのものではなく、お客様と開発者の両方を含めて、凡人がよりよくシステムを開発するためのものであるということです。ゲームの例でも分かるようにごく少人数の天才がソフトウェアやシステムを作るときには別に開発方法論のようなものはなくても何とかなってしまうと思います。天才には独自の本人だけの方法論があるので、一般化された方法論は不要なのです。
しかし、我々凡人は本人独自の方法論、もっとざっくりいえば本人やチーム独自のやり方などいきなり生み出すこともできません。そのような凡人が凡人のままでもなんとかよりよくシステムを開発するためには、まずは偉大なる先人が作り上げたやり方、方法論を学ぶ方が効率的なのです。自分独自の方法論を作り上げるのはその後でも遅くはありません。
ツールにしても同じで凡人こそ、自分たちを適切にサポートしてくれるツールが必要なのです。
と、方法論、そしてソフトウェア工学素晴らしい！ とOOSEの真似事をしながら、やはり実用性皆無（結局こうなってしまいました）のプログラムを作っている間に、オブジェクト指向の世界ではBooch法のBooch、OMT法のRumbaugh、OOSEのJacobsonの3人が集まり、表記法の統合（UML）と開発方法論の統合（RUP）の検討を始めていたのです。
後編に続く