 |
[2004 年 2 月号] |
|
[2004 年 2 月号] |
今回のゲストは結城浩さんです。 結城さんは、読みやすくて分かりやすいことで有名な『Java 言語で学ぶデザインパターン入門』の著者であり、 また、Web サイトや、 デザインパターン・メーリングリストの管理など、 精力的な活動をなさっています。 今回は、著作活動を中心に幅広くお話をおうかがいしました。
|
|
|
| 結城さんの「Java本」 |
|---|
-- 現在はどのようなお仕事をなさっていますか？
基本的には文章とプログラムを書いています。 いちばんメインとなっているのは本を書く仕事ですが、 コンピュータ雑誌にも記事を書いています。
-- プログラミングの観点から書かれているご著書が多いですよね。
ええ、そうですね。プログラミングは大好きです。 言語というものが好きなので、 プログラミング言語の話を自然言語で書くということに、すごく喜びを感じます。 プログラミングもそれに近いものがありますが。 インフォーマルにコメントを書いて、フォーマルにコードを書く。 言葉と言葉がからみあうようなところが好きです。
-- 好きとはいえ、あれだけのものを書き続けるというのは、かなりの体力や気力が必要になると思うのですが。
体力は必要です。 でも、まあ、楽しみつつやっていますね。 マイペースで書いているので、編集者さんにはしょっちゅうご迷惑をかけていますけれど（笑）。
-- 特にお気に入りのプログラミング言語は何でしょうか。
プログラミング言語を使うときには、そのときどきの「気持ち」があります。 たとえば「かっちり」書きたいときと、「さくっと」書きたいときという具合に。 かっちり書きたいときは Java で、さくっと書きたいときは Perl が気持ちいいですね。
Java の場合「これとこれを、こういう風に組み合わせよう」とか「ポリモルフィックにはこの方がきれいでしょ」と書きたくなるのですが、 Perl の場合「これでどうだ。たったこれだけで十分だ」という感じに書きたくなります。 私の中では"Java と Perl"は、ちょうどお互いを補っている感じがして、 現在のお気に入りの言語ですね。
|
| Stroustrup の C++ 本 |
|---|
-- 結城さんとオブジェクト指向との最初の接点というのは、やはり言語なのでしょうか？
そうですね。 最初に触れたオブジェクト指向プログラミング言語は、Smalltalk です。 大学時代に友人と Adele Goldberg さんの青い本(”Smalltalk-80: The Language and Its Implementation”) を一緒に読んだりしてました。 そのときは「あまりピンとは来ないけれど、でも何だか面白い」みたいな感想を持っていました。
それから、C++ ですね。Stroustrup さんの本*1を、 毎朝喫茶店で読むのを習慣にしていました。 今日、このインタビューを受ける前に久々に読んでみて、懐しかったですね。 これ、1986年の版なんですが、たった 300ページくらいしかないんです。 本に書き込みしながら何度も何度も読みましたよ。 この本で初めて virtual 関数を知って「なるほど、これはすごい」と驚きました。 この本を読んで、AT&T かどこかが出していたプリプロセッサ型の C++ コンパイラ*2をフロッピーディスクで動かして、 勉強していました。
*1Bjarne Stroustrup 著『The C++ Programming Language』
*2プリプロセッサ型の C++ コンパイラ：初期の C++ コンパイラはまず C 言語に変換してから、マシン語に変換をしていたそうです。ここで出ているコンパイラは、AT&T ベル研究所の Bjarne Stroustrup によって開発されたものです。
-- そのころのハードウェアとは何だったのでしょうか？
PC-9801 VX でしたかね。そんなに速いものではなかったと思います。 もう遠い昔なんで忘れちゃいましたけど。 ハードディスクも 10MB とか 40MB の容量しかなくて。
Stroustrup さんの本を読み終えたころ、 知り合いの編集者の方から「本を書かないか」という話をちらっと聞きました。 連載原稿は毎月出していましたけど、本を書くということを、自分と関係あるとはぜんぜん思っていませんでした。 その編集者さんがおっしゃった「本を書かないか」という言葉が心にひっかかって、 そうだ、書いてみよう、と思いました。
で、C++ とオブジェクト指向に関する本を書き始めたんですよ。 まじめに書いたんですが、残りは最後の章、というところで、何ていうか…行き詰まっちゃって、とうとう完成できませんでした。 当時は独身で、独身だと自由な時間が多いはずなのに、結局のところ独身時代には一冊も本を書き上げられなかったんですよ。 結婚してから初めて本をまとめることができて。それは C の入門書でした。 独身時代に書き上げられなかった原稿は今でもきれいに取ってあるんですけど、 それを見るたびに、いつも「時間が足りないから書けないわけじゃない」って思うんです。 自由に使える時間がたくさんあった時代には一冊も書き上げられなかった。 忙しくて時間がないような時代になって、書き上げることができたってことは、 自分の心に留めておきたいなって。
|
| Strategy パターン |
|---|
-- なるほど。話は変わりますけど、オブジェクト指向の有用性についてはどうお考えですか？
いや、私も良くわかっていないんですけど。 オブジェクト指向プログラミングに限定して話をしますが、 私がまず感じることは「名前空間が分かれている」ってところですね。 例えば、大きなクラスライブラリに相当するものを C で書こうと思ったら、 関数にいろいろプレフィックスをつけたりして、ながーい名前になっちゃったりしますね。 ogis_database_open とかね。 パッケージやクラスのような単位で名前空間がパタパタっと分かれているなら、 個々のメソッドは短い名前でもいい。 例えば open と書くだけでいい。これは良いね、と思うことは多いです。
それだけならいいんだけど、ソースを見ていて open とあったときに、何だかよくわからない。 特にポリモルフィズムが使われていて、 引数で渡されてきたオブジェクトが本当にはどのクラスのものかがわからないと、 メソッドの実体はどこなのか、わかりにくいですよね。 Cで普通に書いていれば grep をかければ関数が見つかるのに、 動的に追わないと本当は何なのか、本当はどうなるのかがよく見えない。 そういう意味では、良い面と悪い面を両方持っているような気がしますね。
それから、膨大なクラスライブラリがあったとします。 すると、プログラミングをしている時間よりは、ライブラリのリファレンスを調べている時間が長い。 何かを実現したいとき、 自分の手で作るべきなのか、似たようなものがどこかにないか探して再利用するべきなのか、 これを考えなくちゃいけない。 つまりは、プログラミングとちょっと違う次元の活動が必要になる。 だから、クラスライブラリを利用すれば、自分の手でコーディングする分量が減ってうれしい代わりに、 調べ物のために使わなきゃいけない時間が長くなるんじゃないかって気がします。 もし、コーディングの分量だけに注目すれば、オブジェクト指向は素晴らしい、ハッピーという感じだけど、 そう一概に言えない部分もあるのではないかと思います。
-- 結城さんのように、プログラミングがすごく好きな方にとっては、例えば UML などはとっつきにくいものなのでしょうか？
いやいや、そんなことはないですよ。UML は好きですね。 なぜかというと、私の「デザパタ本」でも UML を使いましたけど、UML はコミュニケーションのツールなんですね。 UML を使って表現することで、うまく誰かと意思疎通ができる、そこが大事だと思うんです。
私はコーディングは好きなんですけども、なぜ好きかというと、それが最終的に動くプログラムに直結しているからなんですね。 コードは、コンピュータとうまくコミュニケーションする手段なんです。 でも、人間に説明するときには、いきなりコード詳細を見せても相手が困ってしまう場合がありますよね。 そんなときには、やっぱりダイアグラムを描いて説明する方がはるかに良い。 要するに、UML を使うと効果があるときには使えばよい。 でも必要がないときまで UML を使うのは愚かなこと。 使い方を間違わなければ UML は良いと思いますよ。
|
|
| 結城さんの「デザパタ本」 |
|---|
-- デザパタの本の話題が出ましたが、結城さんが『Java 言語で学ぶデザインパターン入門』を書こうと思ったきっかけはどのようなものだったのでしょうか？
本屋さんで、GoF 本*3が平積みになっていたんですよ。 当時、私はデザインパターンなんてぜんぜん知らなくて。 これは何だろう、と思ってぱらぱらっと見たんですが、さっぱりわからない。 さっぱりわからないけど、何かすごいことを言っていると思ったんですね。 この題材は、もっとわかりやすく説明するべきだって感じました。 それでそのとき「よし、この本を Java で書こう。わかりやすい本にしよう」と考えたんです。 それがきっかけ。
私は「この本がわかりにくいのはきっと、コードが「…（てんてん）」で省略されているからだ」と思い、 「動くコード」を載せた本にしようと考えたんです。 「動くコード」というのはプログラマにとって一番具体的でわかりやすいものだ。 それを通して説明するのが、プログラマには最もよいと思ったんです。
*3Erich Gamma 他著『Design Patterns: Elements of Reusable Object-Oriented Software』 （邦訳『オブジェクト指向における再利用のためのデザインパターン』）
-- デザインパターン・メーリングリストのきっかけもこの本にあるのでしょうか？
ええ、そうですね。 最初は、デザパタ本の販促のつもりだったんです。 自分の Web ページで デザインパターンのメーリングリストを立ち上げて宣伝すれば、 私の本を買ってくれる人も出るかも、って思ったんです。 パターンに興味のある人とか、オブジェクト指向の興味のある人とか、たくさんいると思うので。 ところが、思ったよりも反響が大きかったんです。 メーリングリストを立ち上げてあっという間に何百人という数になってしまったんですね。 それを見ていて「これはまずいな」と思いました。 まずいというのは、それだけ多くの人がパターンというものに興味を持って集まってきてくれたのだから、 私物化するのはよくないという意味ですね。 私の本のためと限定するのをやめて、 パターンやオブジェクト指向の情報交換に広く利用できるようにメーリングリストの紹介文を変更しました。 今は 3000 〜 4000 人にも達しています。 ときどき話題が盛り上がったりして、私のお気に入りのメーリングリストなんですよ。
-- 結城さんの著作や Web サイトを拝見していると、読み手がわかりやすいように、という心がけのようなものを感じるのですが。
うーん、読者にわかりやすい本を書く心がけ、文章を書く心がけはたった一つしかないんです。 それは「相手のことを考える」というものです。 相手のことを考えないと、読みにくい文章になってしまうんですね。
これは文章に限ったことでもありません。 基本的に「相手のことを考える」と、世の中の多くのことがうまく回ります。 どんなお仕事でもそうですね。相手のことをほんのちょっと考えてみるだけで、ずいぶん変わるんですよ。
-- 確かに、仕事のことだけじゃないかもしれないですね。結城さんの著作は、中国や韓国などでも出版されていますが、これは出版社の方から話が来るのでしょうか？
海外での出版は、ソフトバンクパブリッシングさんがとてもがんばってらっしゃるんだと思います。 台湾や中国の出版社からオファーがあって、現在 Perl、デザパタ、マルチスレッドの本が翻訳されています。
中国語に翻訳されていたデザパタ本をぱらぱらめくっていたときのことですが、 はじめの方に「結城浩先生に感謝します」と日本語で印刷してあったのを見つけたんです。 この翻訳者が書いた「結城浩先生に感謝します」という言葉は、 著者である私ひとりに向かって書かれたものなんですね。 出版された書籍を使って、たった一人にメッセージを送ってくれたことになります。 それを見たときすごく感動しまして、 翻訳と出版に関わった方に ありがとうと伝えて欲しい、とソフトバンクパブリッシングさんにお願いしました。
|
| Facade パターン |
|---|
-- 翻訳ってなかなか不思議ですよね。結城さんの書かれた本を、そのままどなたか訳すわけですよね。
ええ、章立てなども同じですし、イラストなんかもそのまま使っています。
ちなみに、デザインパターン本のイラストの原案を描いたのは私なんですよ。 たとえば、Facade ってこういうものですよって。 Facade は、ごちゃごちゃとややこしそうなものを中に入れて、こんな感じに。 （*編集部注 右図『Java 言語で学ぶデザインパターン入門』より Facade パターン）
それから、各章の副題として Facade は「シンプルな窓口」とか、 Mediator なら「相手は相談役1人だけ」のように、柔らかい日本語で表現しているんです。 アカデミックな硬い感じにしたくなかった。 ぱっと読んで、すっと分かるようにしたかった。 楽しみながら仕事していたのを覚えています。
-- アカデミックな硬い響きを好まれる方もいますけど、わかりやすい方がやはり良いですね。
入門書って、いわゆる学術論文の参考文献に挙がらないですよね。 資料的な意味では、それでよいのだと思いますけど、 最近だったら、論文を書く人の中には、 私のデザパタ本ではじめてパターンに出会った人もいるんだろうなって（笑）。 建前として名前が挙げられる本ではなく、 本当の意味で役に立つ本、読者の理解の助けになる本を書きたいですね。
先日、IT の業界から他の業界へ転職するという方からメールを頂きました。 で、その方は買ったたくさんの本を、全部捨てちゃったり人にあげたりしたんですって。 でも、結城が書いた本だけは記念に持っていくって。 そのメールが来たとき、すごく、こう、じーんと来ちゃってですね。 きちんと読まれる本、本当の意味で役に立つ本をこれからも書いていきたいなと。
-- なになに学会のなんとか論文なんてぜんぜん興味ないのでしょうか？（笑）
（笑） いや、そんなことはないですよ。 これは誤解がないようにきちんと言っておかなくちゃいけませんけれど、 私は学者先生をないがしろにしたいわけではないんです。 まったく逆です。 私の本も、ベースはきちんとしたアカデミックな本を元にしているわけですし。 私は、自分の書く本はアカデミックな領域と読者との橋渡しだと思っているんですよ。
研究者の論文は、 一般人の感覚からすると細かすぎるところまできっちり示さなきゃいけないじゃないですか。 普通の読者にとっては、それを読むのは非常に大変だと思うんですよ。 それに、偉い先生が一般書を書くと、 わかりにくいものになっちゃうことが不思議に多い…。 もちろん、例外もありますけど。 そのあたりのギャップを埋めるものとして、 仲介者あるいは注解者の存在が重要だと思っています。
-- そういう意味で結城さんの書かれる著作というのは、同じコンセプトで筋が通っていますね。
そうですね。 実は、入門書は書くのがとても難しいんです。 相手がまだよく知らないことを伝えるって、難しいじゃないですか。 基礎になる知識が足りなくて説明がなかなか進まないこともあります。 でも、手っ取り早く説明するために「誤解を与える説明」になってはいけない。 説明を単純にするために細かい部分を無視することはありますが、 全体像を見誤るような説明はよくないんですよね。
先日、暗号技術の入門書を出版しましたが、 暗号学者から読まれても恥ずかしくない内容にしないといけないと思ってがんばりました。 もちろんそれでいて、一般の人にも読みやすいように工夫するわけですが。 よい入門書は、説明のさじ加減が難しくて、執筆にとても時間がかかるんですよ。
|
| 結城さんの「暗号本」 |
|---|
-- 結城さんは、本を書く過程でオンラインレビューをしていらっしゃいますが、どういったきっかけで始められたのでしょうか？
最初は、CGI の本*4を書くときに、 オンラインで Perl スクリプトのレビューをやってもらいました。 スクリプトを読んでもらって気になるところがないか、見てもらおうと思ったんですね。 それが、わりと良い結果を生んだんですよ。 例えば、私のクッキールーチンよりも良いクッキールーチンをレビューアに送ってもらったりしましたね。
自分が書いたものを他の人の視点でコメントしてもらうのは面白いなって思ったので、 次の Perl の入門書*5の時には、原稿そのものをレビューしてもらおうと。 でも、レビューアさんがいると分量が多くなってしまう傾向があります。 どうも、私が調子に乗って書きすぎてしまうようです。（笑）
同じようにデザパタ本の時も、
スレッド本*6の時も、最近出た暗号本*7の時も、レビューアを公募して読んでもらっています。
*4『Perl で作る CGI 入門 応用編』
*5『Perl 言語プログラミングレッスン 入門編』
*6『Java 言語で学ぶデザインパターン入門 マルチスレッド編』
*7『暗号技術入門 ―― 秘密の国のアリス』
-- オンラインレビューというのは、やはり良い方法なのでしょうか？
自分の書いた文章が他の人からどんなふうに読まれるかがわかる、 という意味では非常に良いですね。 ただ、かなり手間がかかるのは確かですね。 少なくとも、全ての著者におすすめできる方法ではないです。 神経の太さもかなり必要です（笑）。
-- やっぱりあの、かなり鋭い指摘とか…攻撃的なレビューメールを受け取ることもあるのでしょうか？
うーん。攻撃的なメールというのは少ないですけれど、 他の人から内容を批判されて怒り出す著者には向かない方法だと思います。 私は、自分の書いた文章に関してなら、どんな意見であっても Welcome ですけれど。 あと、物理的に大変なんですよ。トータルで何千通にもなるので。
-- たとえばデザパタ本の作業ログを拝見しますと、すごいペースで書いていらっしゃいます。そのたびにたくさんの人からメールが返ってくるとなると、相当な量になりますよね。それを全部読んで、返信されているのでしょうか？
こういうやり方になっています。 本を一章書く。一章書いたらレビューアの方にメールで送ります。 レビューアの方には〆切は何もないので、それぞれがばらばらに返してくるんです。 で、私のほうはそれをすぐ全部原稿に反映させるんじゃなくて、ストックしているんです。 それを後でバッチ処理的に原稿に反映します。 もっとも、返信が来たときに一応目は通しておきますが。
だから、やり取りといっても、送っていただいたメールにすぐ返してしまうわけではないですね。 もちろん、すぐに返した方が良いと私が判断するものについてはすぐに返します。 だから平均すると、十通に一通くらい返しているかな…。
|
| Reader-Writer パターン |
|---|
-- 結城さんの Web サイトはメーリングリストと同時に立ち上げられたのでしょうか？
Web サイトの方がずっと先ですね。 1995年くらいだと思います。 はじめは1ページだけで「C の本を書きました」みたいなことをページに載せていました。 でも、誰からも何にも反応がありませんでしたね。 アクセスカウンタも全く増えず、たまに 1 増えたと思ったら、それは自分だったみたいな（笑）。
-- （笑） 結城さんのサイトといえば、プログラマの心の健康に関するコンテンツも面白いですよね。
あれは非常に人気のあるページですね。 ほかにも、何でも書いて良いですよというページ「王様の耳はロバの耳」や、 「あなたのために、祈ります」というページもあります。 毎日けっこうな量が来ますね。
-- やはり、話すだけでも、気持ちが楽になるものなのでしょうか？
そうですね。 「ロバ耳」は私の好きなコーナーです。 あれって言うなれば入力フォームがぽつんとあるだけなんですよ。 送信メッセージは私に送られるんですが、私は返事や反応をしないってことがルールになっています。 ということは、フォームに書いて送信したときに、どこにも送られないとしても、現象論的には同じなわけですよね。 でも、送り手が「向こう側に、自分の話を聞いてくれる人がいる」としっかり感じてもらうことが重要な意味を持っているんです。 たとえ返事がもらえなくても、「きちんと自分の言葉を聞いてくれる人がいる」と意識するだけで、 とても気持ちが楽になるものなのですね。
-- あの「ロバ耳」のアイディアは、どのようにして思いついたのでしょうか？
あの、「ロバ耳」が生まれた経緯のところにも書きましたが、 人にメールを書くと気分が楽になることってありますよね。 面白いことに、相手からの返事が来なくても、送信しただけで気分が楽になっちゃった、という経験は誰にでもあると思うんです。 そこからアイディアが来ていますね。 そういうフォームを作ったら面白いんじゃないかなと。 そういう企画に対してどういう名前がいいでしょうかねえと、 自分の Web 日記で聞いてみたところ、 多くの人から「王様の耳はロバの耳」という意見をもらって、 ロバ耳ができあがったんです。
-- Web サイトを運営することは、物を書く喜びとつながるのでしょうか？
もちろんそうですよ。Web サイトは最もダイレクトに読者の反応をもらえますから。 思ったほどは反応って来ないものですけど（笑）。 今、私の Web サイトには全部で 1000 ページくらいありますが、 あのぐらいあると、いろんな人が読んでときどき反応が来ますね。
-- プライバシーを公開することに関する抵抗はありませんか？
読んでいただければわかると思いますが、そんなに公開はしていません。 家族を持っていますので、セキュリティ上、写真や住所は書かないとか、そういう点では神経を使っています。 個人的な情報は公開していませんが、 私のことを理解していただくのに十分な情報は公開しているようには思います。 たくさんの文章を公開していますので。 私の Web サイトは文章が重要な役割を持っていますね。 私は自分のサイトが非常に好きだし、大事にしています。
-- 結城さんが講演などされているという話もあまり聞いたことがないですね。
ええ。 さっきのセキュリティの話もありますけど、基本的には人にあまり会わないことにしているんですよ。 2003 年は人に会い過ぎたかもしれません。インタビューを受けたりして（笑）。 ときどき、サイトを見たり、著書を読んだりした方から、 講演していただけませんかというありがたい申し出もあるのですが、お断りしていますね。
|
| Template Method パターン |
|---|
-- 結城さんのご趣味といいますと、どういったものになりますか？
趣味…。 うーん、仕事は、文章書いたり・プログラム書いたり。 趣味は、文章書いたり・プログラム書いたりって感じなので…。 あ、ときどきリコーダーを吹きますね。
-- なるほど。お仕事は、自宅でされているのでしょうか？
えーとですね、メインに書いているのは、マクドナルドですね。（笑） マクドナルドが一番いい。 それから、デニーズ。ファミリーレストランならデニーズが一番です。
-- （笑） いや、仕事やプライベート、趣味の切り替えはどうされているのかな、と。
あ、そういうことですか（笑）。 いや、あんまり切り替えていないですね。 家にいるときは、ちょこちょこプログラムを書いたり、ちょっと子供と遊んだりとか。 子供が「レゴブロックいっしょにやろう」とかいうと、 いっしょにやりますので。ちょっとわからないです。
-- すると今日は何時から何時まで仕事、といったふうには、特には決めてないんですか？
ないわけではありません。 例えば、基本的に午前中は本を書いています。 午前中は一番頭が回る良い時間なんですね。私は「黄金の時間」と呼んでいます。 その時間帯は一番頭を使わなくてはいけない仕事をしています。
-- なるほど。著作をされている方は時間が逆転されているというイメージがあるので、午前に著作活動をされているというのは驚きですね。
でも、良く寝て起きた朝が一番頭が働きますよ。 最近はちょっと崩れてきているけど、本当にまじめに本を書いているときは午前を中心にしてますよ。 夜には、図を描きます。図を描くときって、手を動かしている時間が長いからかもしれませんね。 あと、わかりやすい図を書くためには、少し頭が眠いほうがよい。 頭が回りすぎると、複雑な図になっちゃう傾向があります。
|
| Immutable パターン |
|---|
-- 好きな言葉についてですが。
「天の下では、何事にも定まった時期があり、すべての営みには時がある」という言葉ですが、 私はもう少し単純化して「ものみなすべてに時がある」と覚えています。
この言葉は「いろんなタイミング」ととらえても良いです。 自分がなにかをやらないといけない「時」、あることにふさわしい「時」というのがあるんです。 ちょっと言い換えれば「自分が全部を支配できるなどと思いあがってはいけない」ということでもあります。
人って、将来の計画を立てますよね。 何歳までにこうなって、何歳で結婚して、何歳でこんな仕事をして、年収いくらになって、 あそこに家を買ってのんびり過ごすみたいな。 でも、それってちょっと傲慢なんですよね。 自分の力を過信しているというか、作戦どおりに物事がいくと思うな、という心根がわりと好きなんです。
-- 尊敬する人は？
尊敬する人というのはなかなか難しいですね。 私は、イエス・キリストという答えを準備してきたんですけど、イエスさまの場合、尊敬する人というのともちょっと違いますね。
あ、クヌース先生はいいですね。 私の本を書くお手本でもあるし、あの人もクリスチャンですし。 最近『コンピュータ科学者がめったに語らないこと』という本で、神さまについて話したという本がベストセラーになっていたんですよ。 原題は『Things a Computer Scientist Rarely Talks About』*8 だったかな。
*8Donald Ervin Knuth 著『Things a Computer Scientist Rarely Talks About』（邦訳『コンピュータ科学者がめったに語らないこと』）
-- アインシュタインもクリスチャンだったそうですが、科学者には多い気がしますね。
それはとても納得がいきます。
科学って、いわば「世界をリバースエンジニアリング」しているんですね。 世界を構成しているものを調べたり、物理法則を調べているじゃないですか。 あれって、誰かが作ったプログラムをプログラマが解析しているのと同じようなものですね。 このクラスとこのクラスがこういう関係にあるとか、 テストケースを与えて、振る舞いを調べたりとか。 乱暴な言い方をすれば、科学は世界をリバースエンジニアリングしているみたいだな、と。
それでですね、ここから大事な話なんですが。 リバースエンジニアリングが意味を持つのは、そのシステムを作った設計者が存在するときだけなんです。 だから、もしもデザインした設計者がいないもの、 そもそもデザインなどされていないものはシステムとは呼べないし、 調べてもつまらない。
この世そのものを探っているサイエンティストが、その向こう側にいる本当のデザイナー、 世界をクリエイトしたクリエイターの存在を意識するのは、当然だと私は思います。 だから、科学者が世界の創造主としての神さまを信じるというのは、とても自然なことだと思います。
|
| Mediator パターン |
|---|
-- 最後に、先輩として、若手のエンジニアにアドバイスなどいただけますでしょうか？
二つあります。 一つ目は「弱い人」へのアドバイスです。 この業界のお仕事は、夜遅くまで大変ですよね。 まじめな人は特に心が煮詰まって、体も壊してしまう場合が多いと思います。 「内緒だけど、適当にさぼろうよ」とアドバイスしたいです。
-- 適当ってところが難しいですよね。
そう。その適当なポイントというのは「相手のことを考える」ことで見つかるんです。 つまり、たとえば、自分が作るプログラムは、誰が必要としているのか、どんな風にいつ使うのか、 ということを考えていくと、よいポイントが見つかるのではないでしょうか。
それからもう一つは「強い人」へのアドバイス。 世の中には「正しければ良い」って思う人がいるんですよね。 特にプログラマに多いかもしれません。 正しければ相手に何を言っても良い。相手の本当の姿なんだから、相手に突きつけても良い。 正しいことがすべてだ、と。 でも、たとえ正しいことであっても、相手への示し方によっては、愛がない行為になることもあります。 逆に、相手に良かれと思っていても、嘘いつわりや幻想だけを示すのももちろん良くない。
それで、これは聖書の言葉*9なのですが「愛をもって真理を語る」ことが大事だと私は思っています。 正しいことを、相手に適切に伝えることが大事だと。 内容だけではなく示し方も大事だと。 さもないと、せっかくの正しいことも本当の意味では正しくなくなってしまいますよね。 そもそも、相手に受け入れられなかったら、正しい意見も無駄になる。
*9新約聖書 エペソ人への手紙４章１５節より「愛をもって真理を語り」
正論を振り回して、周りの人の気持ちを傷つけてばかりいるという人はたくさんいますよね。 IT 関係に限らないかもしれないですが…。 そういうのはよろしくないんじゃないかな、と思います。 まあ、自分を棚に上げて偉そうにいっているわけですが。
-- そういえば、この業界は心を病んだり参っちゃったりする人が多い気がしますね。
原因は、スピードじゃないですかね。 プログラムは、素早い計算をしてくれるので、すぐに応答を返すことが期待される。 それと同じことを人にも期待しちゃうんです。 人を、いつのまにか機械のように扱っちゃっているんですよね。 でも、相手は人間なんだから、問いを送ってもすぐには返事がこないかもしれない。 ずっと後になってはじめて、意味のある返事がくるかもしれない。 そういうゆとりを忘れがちなんだと思います。
-- 大切なことですよね。これからも結城さんのサイトや著作にはいろいろお世話になると思いますが、よろしくお願いします。
いえいえ、こちらこそ。
-- お忙しい中、ありがとうございました。
本記事で使用した挿絵について
本記事で使用させていただいた画像の一覧です。
| ©2004 OGIS-RI Co., Ltd. |
|
