
The Rational Edge
ルネサンスの巨匠たちに学ぶエンジニアリングの技
ワーチェスター工芸研究所業務学教授
Gary Pollice
2005/9/23
The Rational Edgeより:このコラムでは、ルネサンスの偉大な芸術家たちの作品に対するアプローチと、偉大なソフトウェア開発者たちのアプローチをGary Polliceが比較する。
歴史とは、実例を用いた哲学教育である--ディオニュシオス
筆者は、妻と一緒にイタリアを巡る18日間の小旅行から戻ったばかりだ。今回の旅は研究に追われる日常の良い息抜きになったし、うるさく呼び掛けるコンピュータの前に座らずに考える時間を持つこともできた。
![]() |
絵画、彫刻、建築の壮大な傑作を夫婦で見ていくうちに、筆者は何かいつも見慣れたものを見ている感じを抱くようになった。筆者は、約2000年前のベスビオ火山の噴火によって地中に埋没した古代の街の残骸の中をさまよいながら、構築物の高度な設計や実用性に畏敬の念を抱いた。そして、これらの過去の業績と今日の優れたソフトウェアシステム、すなわち複雑な問題に対するソリューションのスタイル、構造、そして簡潔な表現を尊敬せずにはいられない「傑作」との間に強力なつながりがあることを悟った。このようなシステムは誰でも目にしたことがある。中には、その開発に運良く何度か携わった方もいるだろう。
これらの作品と過去の巨匠を比較したのは筆者が最初ではない。ピート・マクブリーンはその優れた著書である「ソフトウェア職人気質」(ピアソンエデュケーション)の中で、物作りに対して異なる役割を持つ名匠、熟練労働者、あるいは見習いに分類して開発者と中世のギルドの職人を比較している。この例えは、それなりに優れたものだが、過去と現在の熟練工の間には、もっと深いつながりがあると思う。今月は、そのことについて述べる。
◆ 多次元知識
- - PR -
これらのルネサンスの巨匠たちにとって、1つの技能を修得するということはその基本原理を学習し、それをたゆまず応用し続けることを意味した。そうすることで、そこから最終的な発展および改善が可能になった。生来の才能も重要だが、努力がなければそれも光らないのだ。トーマス・エジソンは、「天才は1%のひらめきと99%の努力のたまものである」という言葉を残している。
現代では、Knuth、Booch、Thompson、Ritchie、Jacobson、Parnas、Beck、Fowler、Rumbaugh、Wirth、そしてMartinといった偉大なソフトウェアエンジニアやコンピュータ科学者の名前が頭に浮かぶ。彼らもまず基本原則から学習し、そこから最適な動きを理解できるまで、詳細に十分注意しながらこれらを応用していった。彼らの多くは、ソフトウェアだけでなくハードウェアアーキテクチャ(オリジナルのRational Adaコンピュータシステムはご記憶か?)、各種科学や数学(Knuthの著書をご覧いただければ分かる)、そして心理学といった社会行動科学も学んでいる。彼らにとっては、この異種学問の交流が、ユニークで素晴らしく、往々にしてウソのようにシンプルなアイデアの着想につながった。
XPやRational Unified Process(RUP)などの方法論は一見直感的に見える。だが、これらの生みの親たちは、最も簡単に思える部分でさえも、さまざまな経験に基づいて慎重に引き出しており、特定の目的をそれぞれに持たせている。
偉大な芸術作品同様、各パーツは巧妙に影響し合って見事な全体像(先の例の場合は、効率的なソフトウェア開発の優れた描写)を作り出している。
◆ 目的のための創作
はるか以前から、ミケランジェロをはじめとする多くの偉大な芸術家たちは、委託されて作品を制作してきた。彼らが対価を得て仕事を続けるためには、顧客(パトロン)を満足させなくてはならなかった。大抵はうまくいったが、顕著な例外もあった。例えば、ミケランジェロが家族の思い出にと制作した彫像を見せると、ロレンツォ・メディチはこれが故人に全く似ていない、と文句を付けた。作品に自信のあったミケランジェロは、その千年後に結果を示して見せた。いまとなっては誰にも顔の違いは分からない。
ミケランジェロが目的を持って芸術作品を生み出したのと同じように、われわれも目的を持って(大抵はお金を払ってくれる顧客のために)ソフトウェアを開発している。作業の内容が確定し、金額で合意して初めて本格的な設計が始まることになる。一方、ルネサンスの巨匠たちは、まず自分の作品の下絵を描くか、巨大な彫刻や建物の場合は模型を作成する。彼らは「製品版」の作成に取り掛かる前に、予期せぬ事態が起こらないよう確実を期していた。肩が重さに耐えられず、彫像の腕が落ちてしまったら一大事である。筆者は、多くの彫像で美観を損なう支持物(supports)が見えていることに驚いた。だが、ミケランジェロのダビデ像にはそれがなかった。この傑作には支持物が一切ない。余分なものは1つもない。すべてが目的を持って存在しているのだ。
一部の優れたソフトウェアシステムにも同じことがいえる。筆者は光栄にも、権威と呼ばれる多くの開発者と一緒に仕事をする機会があった。彼らは、プロジェクトの最初から最終的なシステムをイメージすることができる。モデルが着ている衣服のひだを確実に再現したルネサンスの彫刻家と同じように、これらの開発者も、洗練されたデザインの効率的なシステムにつながるクリーンで正確なモデルを作ることに対して細心の注意を払っていた。このようなシステムでは、どの機能にも明確な目的があり、適切なサポートが施されている。
◆ 人とプロセスとツールのバランス
過去の記事を読んだり、講演を聞いたことのある方なら、筆者が人、プロセス、ツールの3つの軸を用いてソフトウェア開発を考えていることはご存じだろう。人が(定義が正式なものであろうとなかろうと)プロセスに従って作業を進め、ツールがプロセスと人の両方をサポートする。これら3つの軸は、中世、古代、そしてそれ以前から作業を定義してきた。
・人
お分かりだと思うが、世界の偉大な絵画の多くはチーム作業の成果だ。師匠がデザインを描き、重要な部分を塗る。そして、熟練労働者や見習いが残りの作業を分担した。
これらのプロジェクトでは、効率的な管理が非常に重要だった。師匠たちは職人を雇わなければ多くの作品を生み出せないことを理解していたが、請求する「有名料」に見合った価値をパトロンが作品から見いだせるよう、その品質を監視する必要があった。
ソフトウェアの開発も「団体競技」だ。1人がビジョンを描き、設計を引き受けても、システムを生み出すためには大勢の力が必要だ。デザイン全体を台無しにしてしまうのではないかと恐れるあまり、優秀な開発者がチームの一員としてはうまく機能しなかった例は多い。ティツィアーノやカラヴァッジオなどの芸術作品を見れば、有能なチームと一緒に作業することの価値を理解するのに役立つかもしれない。
・プロセス
美術工芸の世界で素材に命を吹き込むためには、それぞれ異なる技術が要求される。絵を描くにも、水彩画と油彩画では異なるのと同じ理屈だ。しかも、その制作プロセスまでが異なってくる。われわれが訪れたフィレンツェのあるギャラリーでは、金箔の葉が付いた木片に描かれた中世期後半の絵を展示していた。その展示には、メッキの詳しい工程が書かれており、わずかでもズレが生じると作品が破綻してしまうとの説明があった。もちろん、芸術作品すべてがここまでの精度を要求するわけではない。時には制作工程がかなりいいかげんな場合もある。ソフトウェア開発にもこれと同じようなことが当てはまる。工程の精度は、開発している製品の種類によって異なってくるのだ。
・ツール
ことツールに関しては、彫刻とソフトウェアの例えは分かりやすい。巨大な白大理石を前にして、そこら辺に落ちている古ぼけたノミでそれを削り始めることは絶対にない。傑作を作り出すためには、適切なツールが必要だ。それは、高価なカスタムアプリケーションも同じだ。複雑になればなるほど、望ましい結果を出すためにはツールの品質も上げる必要がある。
人材、プロセス、そしてツールを一致団結させて完ぺきに機能させたいなら、ミラノからほど近いクレモナを訪れてみると良いだろう。この町は、偉大なバイオリンメーカーであるストラディバリウスとアマティ家のお膝元で、ここには現在も100社以上のメーカーが存在している。ある工房では、職人たちが木材を切ったり、ヤスリやワックスをかけたり、接着やチューニングを行う作業を見ることができた。熟練工が見せた配慮や専門知識には驚かされるものがあり、これらの工房の作業環境は数百年の間ほとんど変わっていないように思える。ツールは同じで、工場には製造ラインもない。この訪問は、時間をかけてソフトウェアを手作りするという、筆者がほとんど経験したことのないことを思い出させてくれた。筆者がソフトウェアの仕事を続けられている最も大きな理由の1つは、このような作業をしていたころを思い出してコードを修正するときに感じるプライドだ。
◆ 細部への気配り
偉大なルネサンスの芸術家たちは、原材料にうるさかった。ダビデ像の制作に必要な完璧な白大理石を見つけるため、ミケランジェロはカッラーラにまで出掛けていった。妻と一緒に地中海へ抜ける途中ここに立ち寄った筆者は、彼と同じ道を歩いて畏怖の念を抱いた。そして、偉大な作品を作り出すには常に細部に気を配る必要があることを考えさせられた。最高の材料を選ぶだけではなく、適切なツールを選択し、適切な人材を集めてチームを編成し、作業のあらゆる面に配慮する必要がある。細部の重要性を理解し、そこに愛情を込め、時間をかけて対処するのが、本当に偉大な芸術家、科学者、ソフトウェア開発者、そして(あらゆる分野の)巨匠と呼ばれる人々だ。
◆ 歴史から学ぶ
日々の仕事の手を休め、筆者のように世界有数の過去の傑作を見て回ることをぜひお勧めする。それが古代のものであろうと現代のものであろうと、そこから何か学び、反映させる価値のあるものが見つかるだろう。時間を作って、われわれより前の時代に作られた作品の中を歩き回り、その歴史がささやいてくれる教訓に耳を傾けてみるのはいかがだろう。市場のプレッシャーや、複雑化し続ける技術など、われわれが名作ソフトウェアを生み出すのに必要な時間を作るチャンスは少なくなった。われわれは必要に迫られて、間に合わせ的なソフトウェアを開発している。しかし、絶望することはない。芸術と呼ぶにふさわしい作品を生み出す絶好のチャンスは来る。筆者は読者がそのチャンスを認識し、それを最大限に活用できることを願っている。
|
本記事は「The Rational Edge」に掲載された「Great art and the craft of software development」をアットマーク・アイティが翻訳したものです。 |
| IT Architect 連載記事一覧 |
The Rational Edge
米ラショナルソフトウェアがWeb上で毎月更新するオブジェクト指向開発のための論文集「The Rational Edge」を@ITが厳選して翻訳
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|


