The Rational Edge

チェスとソフト開発、その相関関係を探る

by Robert A. Maksimchuk
Senior Evangelist
Rational Software

2003/1/17

---

　IT技術専門雑誌の最新号を読んでいた私は思った。「まいったな、またか！ ソフトウェアの開発を建築工事に例えた記事など読み飽きたよ。ほかに例え話は浮かばないのかな」 。

　ソフトウェアを家に例える話が悪いというわけではない（告白すると、私自身も実際に使ったことがある）。ただ、あまりにも創意工夫に欠けるし、何といっても相当使い古されている。もの作りの例え話として、建物の設計とソフトウェアの設計を比較しているのだろうが、果たして、ソフトウェアの設計は「もの作り」という言葉で片づけられるものなのだろうか。決してそのようなことはできないと思う。つまり、建築の例え話は（ソフトウェアの開発を）単純化しすぎているのだ。

　そこで私は、ソフトウェア開発の特徴をもっと多く包含する何か新しい例え話を探すことにした。ソフトウェアは複雑で難しいものであり、場合によってはいら立たしさも伴う。本格的なソフトウェア開発にはそれぞれ特定の役割を担う多数の人がかかわり（各自がそれぞれ重要な任務を持っている）、全員が一丸となって作業を進める。さらに、実証済みのものもあれば、新しくエキサイティングなものもあるなど、開発にはさまざまなアプローチ方法がある。開発を成功させるためには確かな目的を持つ必要がある。常に変更が行われ、番狂わせも多い。開発を完全にマスターするには経験の積み重ねが必要なのだ。

　チェスだ！ そう、チェスに似ている。王侯のゲームだ！ チェスはこれらの特徴をすべて持っている。考えれば考えるほど、この古来のゲームにはソフトウェアの開発と共通の特徴が見えてくる。

---

作業に最適なツール

　ソフトウェア開発に多くの参加者がいるように、チェスにはさまざまな駒がある。それぞれの駒は異なる役割を持ち、それぞれがユニークな動きをするが、同じ盤上で協力して動く。駒や盤を使うゲームはほかにもあるが、駒や盤のほかにカードや銀行、点数表、サイコロなどを必要とすることもある。どれもゲームに必要な部品だと思われるかもしれないが、どれもが異なる使われ方をし、それぞれの（手続き上の）関連性は低い。チェスでは必要なものすべてが同じ盤上に置かれている。この盤が「チェスの環境」のすべてであり、プレーヤはそこでゲームに勝利するという戦略的目的を達成すべくルーク、ナイト、ビショップ、ポーンなど、各駒独自のユニークな機能を活用するのだ。

衝突のないデザインと開発

　ソフトウェア・デベロッパも、優れたコードの生成という戦略的な目的達成のためにツールのユニークな機能を活用する。そしてツールの機能を活用可能にする統合環境からも同じように恩恵を受けることができる。「Rational XDE Professional」はまさにそのような環境を提供する。「eXtended Development Experience」（XDE）は、好みのIDE（統合開発環境）と密接に統合できる。使用するデザイン／開発ツールを1つの「ボード」上にすべてまとめてくれるので、ツールを取り替えるたびにコンテキストを切り替える必要がない。すべてのツールが同じメニュー、ジェスチャ、利用パターンを使うため、設計とコーディングの間に「衝突」がなくなるのだ。これにより、学習時間が削減され、開発期間が短縮される。自分のIDEから離れる必要が全くないのだ。

戦略上の多数の選択肢

　チェスでは、ゲームを開始するに当たってこれが「正しい」という方法論はない。例えば、ポーンから動かそうと、ナイトから動かそうと、あなたの自由である。だがソフトウェア開発では、自分の立場（プロジェクトのデベロッパ、企業の設計者など）がソフトウェア開発に対する自分のアプローチに影響する場合が多い。Rational XDEを活用すれば、あなたがどのような立場にあろうとも、好きなようにデザインやコーディングの作業を進めることができる。コードに重点を置くことも、デザインに重点を置くこともできるのだ（図1）。自分のコーディング作業（C#、VB.NET、ASP.NET、Java）とデザインモデリングの作業を進めながら、これらの作業を自動的にシンクロナイズすることもできる。あるいは、終わるまで待ってからクリックするだけでシンクロナイズすることも可能である。

図1 Rational XDEはコード中心の開発もデザイン中心の開発もサポートしており、好きな方を選べる（クリックすると拡大します）

「白紙状態」症候群

　チェスで新しいゲームを開始するときは、同じ駒を同じように並べて毎回必ず同じ盤上で始める。また、ゲームの開始時（序盤）や終了時（終盤）には多数の定跡があり、中盤の局面でも「絶対手」「ナイト・フォーク」「ピン」「エックス・レイ」「トラップ」「キャスリング」など、多数の戦略が含まれた定跡がある。そして、定跡とは知名度が高く、成功率も高く、ユニークなものである。「Ruy Lopez」「Sicilian」「Budapest」「Caro Kann」「Alekhine」など、定跡を有名にしたプレーヤや生み出された場所にちなんだ名前が付いている強力な存在なのである。

　つい最近まで、デベロッパはこのような定跡の恩恵を受けることができなかった。プロジェクトはゼロから開始することが多かったのだ。一般的な問題に対する優れたソリューションがすでに構築されていると分かっていても、プロジェクトに効果的かつ効率的に再利用する方法は全くなかったのだ。

パターンの持てる力を解放する

　だが現在では、有名な「Gang-of Four（GoF）」（注）パターンなど、ソフトウェアデザインパターンの中で具体化された定跡をデベロッパが活用できるようになっている。Rational XDEは、各種のパターンをデザインに組み込める（図2）。しかも、自分独自の特殊なパターンを取り入れて、開発プロジェクト全体で再利用することも可能になっている（これに自分の名前を付けて有名人になった気分も味わえる）。

図2 生産性と品質の向上につながる実証済みパターンの利用

難問

　チェスというゲームはマスターするのが非常に難しい。取りあえず始めるにも勉強が必要で、そこにはさまざまな難問が待ち受けている。すべての駒の動きのほか、それぞれの駒を組み合わせたときの動きも学ばなくてはならない。それに加えて、さまざまな戦略やルールの例外なども学ぶ必要がある。チェスにはさらに、強力な駒を閉じこめるな、チェックからの脱出方法を3つ習得せよ、チェス盤上の各部分の相対的価値を理解せよなど、「事例」までも用意されている。何でも同じように、上達するには経験が必要だ。だが、まず始めてみないことにはしようがない。大抵の場合は本を読むことから取り掛かるが、その多くがチェスのプレーヤに理解できる標準の棋譜手法を使ってゲームと駒の動きを分かりやすく説明している。

　ソフトウェアの開発もこれと同じだ。複雑でマスターするのは難しく、専門知識の習得には時間がかかり、事例に従うことが勝利に役立つ。そして、多くのソフトウェア・デベロッパも標準の記述方法を使っている。それがUMLだ。チェスの標準的な動きを本を読むことで学ぶようにUMLも本を読んだり（時間があれば開発スケジュールと相談して）トレーニングに参加して習得できるが、デベロッパの多くはこのように悠長には構えていられないので、コーディングを進めながら学ぶといいだろう。

インスタントUML

　Rational XDEを使えばUMLを短時間で簡単に学ぶことができる。Rational XDEは、デザインの文書化や、利害関係者へのプロジェクト情報の伝達に利用可能なUMLモデルをコーディング作業中に即座に生成してくれる。さらに、Rational XDEは、「Rational Developer Network」（Webベースのトレーニングや技術ガイドなどの記事を公開しているオンラインリソース）のほか、学習のための無数の情報源にアクセスできる（図3）。従って、Rational Developer Networkからは、コーディングを進めながら学習するだけでなく、業界のリーダーたちの経験を生かすこともできるのだ。

図3 開発の重要な情報源となるRational Developer Network（クリックすると拡大します）

コミュニケーションの必要性：重要な差

　もちろん、チェスとソフトウェアの開発はすべての面で同じではない。普通にチェスをする場合、正式な試合を除き、一般的には重要な役割を担う2人の人間、つまりプレーヤしかゲームには参加しない。どの駒をいつどのように動かすかは彼らが考える。駒の動かし方の誤りを指摘したり、確実に優れた手を打てるよう助けてくれる人間はいない。自分たちの試合が会場の反対側で行われている他人の試合に影響するなどと不満を漏らす者もいない。その試合で起きていることを理解しなくてはならないのは対戦する2人だけだ。

　ソフトウェアの開発でも以前から同じことがいえたのかもしれないが、今日のソフトウェアはチーム競技となっている。デベロッパが全くコードを書いたことのない人に自分のデザインを説明しなくてはならないこともしばしばある。すべての利害関係者（カスタマ、マネージャ、チームリーダー、デベロッパ、テスター、マーケティング、営業など）が作業を理解する必要があるというのももっともな話だ。では、コードを熟知していない人にはどのように説明したらよいのだろうか。

モデルのさらなる活用

　Rational XDEならばパワフルかつ柔軟なデザインモデルを作成できる。UMLが持つ表現力と、自由形式のダイヤグラム機能、表現力のあるシェイプやアイコンを使う機能とを組み合わせれば、自分のアイデアを適度に複雑かつ概念的な形でだれにでも伝えられるようになる（図4）。

　もっと技術寄りの仲間向けには、多数の技術分野にまたがる機能をRational XDEが提供してくれる。実証済みのRationalのUMLベースデータモデリング技術を使うことで、技術者以外でもデータベースの概念、論理、および物理デザインが理解できるようになる。さらに、XDEの新しいWebステレオタイプを利用すれば、WebのチームメンバーはWebアプリケーションやWebサービス用コードをデザインおよび生成することができる。メンバーはさらに、Webデザインのやりとりや複雑な部分の理解に役立てるべく既存のWebアプリケーションやWebサービスのリバースエンジニアリングさえも可能だ。

　最後に、Rational XDEのマルチモデル機能を使えば、プロジェクトを整理して使いやすさを念頭に置いたデザインを行うことができる。デザインソリューションが複数のモデル（要求モデル、アーキテクチャモデル、デザインモデルなど、デザインを明確、スケーラブル、そして管理しやすくするために必要なものすべて）を同時にオープンにしておけるのだ。

図4 複数の利害関係者とのコミュニケーションを明確にしてくれる自由形式モデリング（クリックすると拡大します）

終盤の局面

　チェスとソフトウェア開発との間には重要な共通点が少なくとももう1つある。どちらも、いつまでも「簡単なもの」になることはないのだ。チェスをすれば勝つときもあれば負けるときもある。ソフトウェア開発現場の人間にとっては非常に重大な結果を招くこともある。プロジェクトの失敗はビジネスにとっての膨大な損失につながる可能性がある。しかしチェスと同じように、自分のスキル、定跡や事例、そしてRational XDEのようなツールを使って精進すれば勝利することができる可能性は大きい。過小評価されることの多いポーンのように、敵陣深くに攻め込めば「成る」ことができるのだ。

【謝辞】

　編集に当たって力添えをいただいたLisa Dornell、Carolyn Hakansson-Johnston、David Hauckに感謝の意を表する。

---

【注釈】
（注）Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides共著、『Design Patterns: Elements of Reusable Object-Oriented Software』（1995年Addison-Wesley刊）。

本記事は「The Rational Edge」に掲載された「You Build Software -- Not Houses」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧