|
武蔵流プログラマ
山崎 敏
YAMAZAKI Satoshi |
|
|
●皆既日食（かいきにっしょく） |
|
|
皆既日食（ダイヤモンドリング 注1）には，個人的に忘れることのできない思い出があります．それは，ダイヤモンドリングをヨーロッパで観ることができるという情報を聞いた筆者が，死ぬ前にぜひ一度観てみたいと思ったことから始まったのです．長期の休暇を取り，旅行会社の観測ツアーに申し込み，ドイツを経由してはるばるオーストリアまで出かけました．そして皆既日食の当日，観測ツアーに参加した人たちは2 つのチームに分かれて観測することになりました．
1つのチームはホテルの近くの市街地から，もう1 つのチームは遮蔽物の少ない丘の上からです．筆者はもともと人ごみが嫌いですし，市街地の観光は済ませていたので，のんびりとした丘の上の観測点を選択していました．出発のとき，一瞬「市街地のほうが良さそうだ」という何か直感のようなモノを感じたのですが，最初に決めたとおり丘に向かいました．
天候は晴れ，8 月の丘の上は風も涼しく，最高のコンディションでした．あとは時間が来るのを待つばかり，はやる気持ちを抑えながら，その瞬間を待っていました．ところが事態は急変します．日食が始まり気温が下がったためなのか，急に雲が出てきて，なんと雨が降り出したのです．「マジかよー！」心の中で絶叫する筆者．当然，太陽は見えません．月に隠れたのではなく，雲に隠れて見えないのです．雲の上では皆既日食が始まっています．あたりは真っ暗になり，そして雨…，ひたすら雨…，心の中も雨．現地の人たちを含み，そこにいた全員がくらーい気持ちになりました．誰も一言も話しません．その後，日食が終わると雲は晴れ，再び快晴に戻りました．
何と表現したら良いのでしょうか．言葉が見つかりません．世の中に「不運」という言葉がありますが，そんな言葉では表しきれない複雑な気持ちです．誰が悪いわけでもないのですが，はるばる日本から飛行機を乗り継ぎ，長期間会社を休み，お金をかけて，あと一歩，あと数分のところまで来ていながら，目的を達成できなかった…，「いったい何をにし来たのだろうか…」といった虚無感でしょうか．
その後ホテルに帰ると，なんと！市街地のほうは晴れていたそうで…「とってもキレイだったよ」と言う市街地チームの言葉が皆の心にグサグサ刺さり，と同時に湧き上がる敵意を筆者も感じました．あー，あの出発のとき，自分の直感を信じるべきだった…，このとき筆者は一生忘れないであろう教訓を得たのでした．
「自分の直感を信じろ！」
そして「ダイヤモンドリングが観たいのなら，なるべく水気のない所を選べ」と…．
注1 ）皆既日食の終わりに太陽から光が漏れ始める瞬間，ダイヤの指輪の形に見えることからそう呼ばれているようです．
|
|
|
●直感 |
|
|
『失敗学のすすめ』（畑村洋太郎著／講談社／ISBN ：406210346X ）という本の中に直感について考えさせられる事例が載っています．
それは，この本の著者が学校の教師をしているときに「危うく生徒を殺してしまうところだった」という失敗の体験談です．ある材料の破壊実験をしているときに，通常，引張（ひっぱり）で行う実験を，あえて圧縮で行ったのだそうです．学生6人が実験機械を取り囲むように観察していました．実験開始後，1 人の学生が危険を感じ，観察を中断して避難します．その直後，材料が崩壊，爆発し，材料の破片が避難した学生のいた方向に激しく飛び出し，後ろの壁に激突したのです．そのときの教師であったこの本の著者も怪我をし，あまりの出来事に腰が抜けてしばらく動けなかったそうです．
この失敗は幸いにも，軽い怪我ですみましたが，もしその学生が「危ない」という直感を信じなかったら，その学生は大怪我をしていたか，最悪の場合死んでいたかもしれません．
●直感のなせるワザ
こういった状況の判断は，理論的に後付けすることは可能ですが，はじめてその場に遭遇した場合には，その人の直感だけが頼りなわけです．怪我で済めば「あのときはこうすればよかった」とあとから考えることもできるでしょうが，もし死んでしまったらあとで考えることはできないのです．
その場で圧縮された材料を見て，その軋（きし）む音を聞き，空気を読み，想像力を働かせ，瞬時に判断し行動するのです．いや，意識して思考するのではなく，ほぼ無意識に反応するわけです．それができた学生は怪我をせずに助かるわけです．頭で覚えた知識ではなく，体で覚えた体感のなせる技なのです．
直感は理論を飛び越えて答えを出します．それゆえに正確さに問題もありますが，瞬時に判断できるため時間を節約できます．必ずしも時間をかけて考えられる場合ばかりではないので，直感が有効になるケースもたくさんあるわけです．
●速度のメリット
筆者は「時間をかけて導き出された正解よりも，時間をかけずに除外した不正解」に価値を感じます．なぜなら，正解か不正解かの正確さよりも，判断にかかった時間にメリットを感じるからです．
簡単な話でたとえるなら，1 リットル98 円のガソリンを29 リットル買うとおよそいくらでしょうか？
このとき，細かくかけ算をするのではなく，単純に「100 円の物が30個」と考えて「3,000 円くらい」と思考をショートカットするわけです．3,000 円ちょうどではありませんが，2,000 円でもなく5,000 円でもないわけです．2,000 円や5,000円という不正解を素早く除外できるのです．
ほかにも，待ち合わせの時間に遅れそうになったとき，時計を見るとデジタル表示であったとします．このとき筆者は残り時間を瞬時に計算できません．待ち合わせ時間が18時で，今の時間が17 時43 分55 秒だったとすると…，えーと…．頭の中が軽く混乱してきます．これがアナログの時計であれば針の位置から「あと15 分くらい」と一瞬にして答えが出ます．正確な数値ではありませんが，この精度で十分なのです．10 分でも20 分でもないわけです．
筆者は，こうした時間をかけずに除外した不正解に価値を感じるのです．
|
|
| ●バグに効くのは？ | |
|
システム開発（ソフトウェア開発）においても，不正解を瞬時に嗅ぎ分ける嗅覚は大切です．とくにシステムとは複数の正解が存在するモノです．こういったモノを作るには，時間をかけて正解を探し続けるよりも不正解を除外したほうが容易に目的を達成することができると思うのです．
改めてシステム開発の作業を考えてみると，開発中には「バグ」という不正解を取り除く作業に終始しているように思います．しかし，直感のみを頼ってバグを取るのは問題です．やはりバグは理論的に出るわけであって「何だかよくわからないけど，怪しいところを適当にいじっていたらバグが消えたのでこれで良しとしよう」では，根本的な解決になっていないわけです．こんな状態ではバグは減るどころか増えつづけることでしょう．
では，効率良くバグ（不正解）を取るには何が効くのでしょうか？直感ではダメですね？では方法論や理論でしょうか？人でしょうか？それとも最新の技術でしょうか？いえいえ，そんなことはありません．
筆者の意見は，
それは「オブジェクト指向」や「デザインパターン」ではない！
と今は述べておきましょう．皆さんも一緒に考えてみてください．
| |
|
●道具 |
|
|
誰にでも「こだわり」はあると思います．とくに毎日使うものであればこだわらないほうがおかしいと思います．毎日車に乗る人は車にこだわるだろうし，毎日料理をする人は料理の道具にこだわるでしょう．まして，その道具が仕事や商売に直結するとなると，その道具の使い勝手がそのまま利益に影響することにもなります．
とくにPC で仕事をしている人にはPC の性能が大きな問題になるわけです．たかが道具，されど道具なわけです．
●万能薬はない
しかし，まずはじめに「道具（ツール）がすべてではない」ということを頭に入れてほしいのです．
知識があれば作れるのか？というとそれは違いますし，センスがあれば作れるのか？というとこれも違います．道具があれば作れるのか？というとそれも違うわけです．プログラミング言語に詳しくなっても，どんなに知識が増えても，才能があっても，最速のPC をそろえても，モノ（プログラム）を作るの作業は「まず頭の中で行われる」ということなのです．
道具が勝手にモノを作りだすわけではないのです．道具は支援してくれるモノであって思考や生産そのものをしてくれるモノではないということなのです．これらの大前提を忘れてはいけないのです．
「これがあればすべてがうまく行く」とか「この理論であれば間違いはない」とか「このマニュアルに従っていれば大丈夫」とか，そういった藁にもすがりたい気持ちは理解できますが，どんな問題に対しても十分条件となる万能薬は存在しないのです．偏った1 つの道具や方法論に頼らないでほしいのです．
●人が作る
デバッガがバグを取ってくれるわけではないわけです．デバッガを使いバグを特定するのは，あくまでもデバッガを使う「人である」ということを忘れてはいけないのです．
「ソフトウェアは人が作る」
ということです．
たかが人とあなどってはいけません．最先端の技術を支えるのは，何を隠そう人なのです．つまり人が最先端を支えているわけです．優れた人がいれば優れた道具や環境がなくてもモノは作れますが，優れた道具や環境があっても人がいなければモノは完成しないわけです．ナポレオンの言う「1 頭の羊に率いられた100 頭の狼群は，1 頭の狼に率いられた羊群に敗れる」という言葉がこのことを的確に表していると思います．
道具は手段であって，道具を使うことが目的ではないはずです．目的はあくまでもモノを完成させることです．目的と手段を履き違えてはいけません．戦略と戦術を履き違えてはいけないのです．
|
|
|
●オブジェクト指向？ |
|
|
あるWeb ページに，オセロゲームを作る（コーディングする）ことで，オブジェクト指向プログラミングを勉強するという話がありました．ある程度プログラミングの経験のある人ならオセロゲームをコーディングすることはそれほど難しいことではないと思います．しかし，オブジェクト指向でコーディングをするとなると「ある点」でつまずくのだそうです．
その点とは，オセロの「石」をオブジェクトとして理解しコーディングすることはできるのですが，オセロの「ゲーム板」が見えないのだそうです．「石」のコーディングをしたところで，そこから先に何をコーディングすれば良いのか迷ってしまうというのです．目に見えるモノはオブジェクトとして理解できるのですが，目に見えない「ゲームのルール」はどのオブジェクトとしてコーディングするのか？という点でつまずくようなのです．
その見えないモノは「ゲーム板」であったり「人」であったり「ゲームそのもの」であったりするわけですが，オブジェクト指向の初心者は「目に見えないモノであってもオブジェクトとしても良い」という考え方が見つからずに迷ってしまうようなのです．
このことは，ちょっとした視点の移動だと思います．筆者はそれを「マクロな視点」と言っていますが，その視点の変化によってパラダイムが変わり，考え方が変わり，問題に対するアプローチが楽になるのです．
|
|
|
●包丁 |
|
|
料理に必要な道具として，筆者がまず最初に思い浮かべるのは包丁です．包丁の使い勝手や切れ味は，生産性や精神的な負担はもとより，何よりも安全に関係してくると思っています．
では，良い包丁とはなんでしょうか？良く切れることでしょうか？刃こぼれしにくいことでしょうか？それとも持ちやすさでしょうか？
ここでも，オセロの話と同じように見えていないモノがあります．それは「まな板」であったり「砥石」であったりするわけです．まな板や砥石は包丁を使うには欠かせないモノなのですが，ついつい意識は包丁のみに行ってしまいがちになります．
1 つの道具に意識を集中するのではなく，包丁やまな板，砥石，さらには料理をする空間（厨房）までを，マクロな視点からまるごと1つで捉えるべきなのです．
道具の使い方を覚えるため，必死に勉強をしている自分に酔ってしまってはいけないということです．
言葉では表し難いのですが「物」や「技」ではなく「場」であり「道」であると言いたいのです．どうでしょう？筆者が「オブジェクト指向やデザインパターンという物や技のみがバグに効くわけではない」と言いたいのが少しは見えてきたでしょうか？
|
|
|
●デジタルで行こう |
|
|
インターネット社会に突入した今，あらゆる場所でデジタル化の波が押し寄せています．単純にデジタル化するだけで企業の利益が上がるという神話がまことであるかのように言われ，われ先にとデジタル化を進める企業もあるようです．
デジタル化をすることで利益を上げることは可能であり，そのすべての言葉が神話であるとは筆者も思っていません．やり方によっては企業の利益になり，そして社会の利益になるでしょう．ただ「どんな形であれデジタル化さえすれば良い」というモノではなく，正しいデジタル化の適用が必要なのです．
やみくもに前進してもゴールには着かないわけです．周りを見て，的確に判断する必要があります．その判断に必要なモノ，中でもとくに大事なモノはなんでしょうか？「オブジェクト指向」や「デザインパターン」でしょうか？
では，何が効くのでしょう？
|
|
|
●UML は？ |
|
|
では，UML のような設計時の共通の言語はどうでしょうか？
たとえば，同じ機能で同じ価値を実現しているシステムであっても，保守が不可能なほど酷いコードで書かれている場合もあるし，誰が読んでも理解できるようにきれいなコードで書かれていることもあるわけです．同じようにUMLであっても，酷いUML もあればキレイなUML もあります．やはり「UML を使えば良い」という単純な図式ではないわけです．
|
|
|
●カッコイイか？楽しいか？ |
|
|
ここで皆さんに同意していただきたいことがあります．それは，システム開発やソフトウェア開発において「何を求めるのか？」というところです．楽な仕事ができればそれでいいのでしょうか？お金さえもらえればそれでいいのでしょうか？社会の利益につながればそれだけでいいのでしょうか？
やはり，仕事には個人の充実感や達成感が必要だと思います．何のために働くのか？と聞かれたら，堂々と「カッコイイ人生を送るためです」とか「人生を楽しむためです」と言えるようになりたいですよね．そう思いませんか？筆者はついついそういうことを考えてしまうのです．たしかに，社会の利益になることも大切です．しかしそれ以前に，個人が働きつづける意味や動機が大切だと思うのです．
●武蔵流のすすめ
唐突ですが，宮本武蔵の戦い方の特徴は
・武器や流派にこだわるな
・実践し定期的に観察せよ
・勝て！
だそうです．まさに今のプログラマに必要なことを言っていると思うのです．現代のプログラマの立場として言い方を変えるならば，
・ツールや方法論にこだわるな
・実際にコードを動かしテストせよ
・完成させろ！
となるでしょう．どれも大切なことであり，多くのプログラマが忘れていることのように思えるのです．
|
|
|
●情熱 |
|
|
理論的でない直感は，時として理論を超越したモノを作り上げます．たとえば，映画『七人の侍』は理論的に創られたとは思えないのです．「ディズニーランド」も計算しつくされて創られたとは思えないのです．完成したモノを見て「これは，こういう理論で作られている」とあとから言うことはできると思います．しかしそれは「コロンブスの卵」です．やはり，今までにないモノを最初に作るということは，未開の地を行くことであり，そこに既存の理論はないのです．
黒澤明やウォルトディズニーやコロンブスという人の「こうしたい！」という強い情熱が理論を超えて現実のモノになったと思うのです．
さて，そろそろ筆者の言いたいことが見えてきたでしょうか？
|
|
|
●大切なこと |
|
|
筆者がシステム開発において大切であると思っていることは，オブジェクト指向やデザインパターンではなく
システム開発について「つねに考えつづけること」
なのです．「それって，答えになっていないじゃないか」と思われる方もいられるでしょう．ある意味ではその意見も当たっているでしょう．しかし筆者は，このこのシステム開発の弱点に関しては1 つの答えに到達することはないと考えています．
地球上の生物が日々進化を繰り返しているように，モノづくりの仕方も日々変化し，進化し続けているわけです．ある時点で正解であった答えも，時代が変わってしまうことで正解ではなくなってしまうのです．過去の正解にいつまでもしがみついていてはいけないのです．1 つの点にとどまるのではなく，つねに模索しつづけること，立ち止まらないことが大切なのです．
「答えがあるかないか」ではなく「答えを探そうとするかどうか」
です．それにしても「自分で考えろって，ちょっとズルくない？…」そう思ってしまった方に今回は特別にもう少しだけお話ししましょう．
|
|
|
●ズバリ弱点は？ |
|
|
筆者が考える今現在のシステム開発における弱点は，ズバリ
「品質とメンテナンス性」
です．この部分が大きなボトルネックになっているのです．とくに，最近では銀行などのシステム統合や，航空に関するシステムのメンテナンスなどで，その品質の低さが露呈し，日々のニュースを賑わしていたります．
品質を確保するには「テスト」が大切です．そして，メンテナンスを容易にするには「コードの可読性」が大切なのです．このテストやコードの可読性についての意識や優先度が低いために，今のシステム開発は多くの問題を抱えているのではないでしょうか．
的確なテストをしていれば，バグは抑えられます．品質が確保できるのです．おそらくプログラマの誰もがこのことを知っているでしょう．知っているはずなのに，なぜ品質が保てないのでしょうか．それは，単純にテストの優先度が低いからなのです．
プログラマの誰もがテストをしたほうが良いと，頭ではは理解していても，それが実行できないのです．それはテストよりも設計や機能の追加などの顧客や一部の開発者が重要だと思っているところに時間を奪われてしまっているからなのです．
メンテナンスについても同じ理由で優先度が低いのです．そのため，コードを書いた本人ですらメンテナンスができないようなシステムが出来上がります．これは冗談ではなく，本当に書いた本人にも理解できないコードが世の中には多く氾濫しているのです．
|
|
|
●XP では |
|
|
現在のシステム開発において，品質やメンテナンス性が低いことに多くの人が気が付いていると思います．XP （エクストリームプログラミング 注2）などの方法論の中には，テストファーストやユニットテスト，リファクタリングやシンプルデザインという，品質やメンテナンスに関する優先度を上げるようなプラクティスが多く入っています．
筆者もこの方針に賛同します．テストファーストにより，テスト項目を洗い出し実装コードよりも先にテストコードを書くのです．リファクタリングにより，コードの可読性を確保するのです．シンプルデザインにより，高速で省メモリではあるが複雑なコードより，一般的で理解しやすく簡単なコードを選択するのです．そして，ユニットテストにより，テスト範囲が大きくなりデバッグが困難になる前にテストを行うのです．
これらのプラクティスが品質やメンテナンス性に大きな貢献をするのです．
注2 ）多くの解説本が出版されているので詳しくはそちらの本を参照ください．
|
|
|
●コードの変更はタブー？ |
|
|
「さわらぬ神にたたりなし」「動いているコードを触るな！」などといわれたものですが，どうやらこれは昔の話になりつつあります．筆者はことあるごとに「変化に追従しろ」と言ってきました．それはスタイルの話なのですが，具体的にはコードの話も含まれているわけです．
なぜ，動いているコードを変更してはいけなかったのでしょうか？
それは，そのコードが何をしているのか理解できなかったことが原因と思われます．何をしているのかわからないコードを修正するのはとても危険なことです．どういう影響が起こるのかわからないからです．
たとえば，あるコードのグローバルな領域にg_flg というint 型の変数があったとします．この変数に0 や1 を設定していたのですが，あるところで2 を設定していました．はたして，この2 はいったい何を意味するのでしょうか？まったく不明です．この状態で，2 が1 の誤りであるのか，それとも2 は0 でも1 でもない別の意味を持つのか判断できません．これをハッキリさせるために仕様書を見ても，仕様書に書いてあることはまずありません．書いてあったとしても，その記述が正しいと言いきれないところもあります．
となるとすべてのコードから変数g_flg を参照（代入）している個所を抜き出し，どういう意味で使っているのか？コメントに書かれていないか？広範囲にわたり調べることになります．こうした大きな手間（時間と労力）がかかるのです．
この大きな手間をかけてまで2 の意味を調べ，正しいと思われる修正を加えるのか？このリスクを受けてまで修正を加えるべきなのか？その修正をしてバグを作り込んでしまったとしたらどうするのか？これらの障害が「動いているコードを触るな！」という法則を生み出したのです．これは，ある意味正しい判断だったのです．
しかし，時代は変わり，顧客のニーズや価値観が変わり，システムも変化しなければ時代から取り残されます．危険だからと言ってコードの修正を避けつづけてはいられません．
では，このg_flg がグローバルな領域ではなく，ファイルローカルな変数だったらどうでしょうか？もしくはクラス内のプライベートなメンバ変数だったらどうでしょうか？さらには，関数内でしか有効でないローカルな変数だったらどうでしょうか？よりローカルであればその変数が何をしているのか把握しやすくなります．
●干し草の山
これはシステムが大規模であるほど「干し草の山から針を探す」作業になり，干し草の山の中に手を入れることすら危なくなるというわけです．そうではなく「数本の干し草のから針をより分ける作業をしましょう」と言いたいのです．一目見ただけで把握できる状態にするのです．内容が把握できてしまえばコードを修正することになにも危険はないわけです．裏を返せば，把握できないことが危険だといえます．
XP のプラクティスの1 つでもあるリファクタリングのおもな目的は，可読性を上げることだと思います．可読性が上がればバグも減りメンテナンス性も上がるのです．危険やリスクは少なくなります．リファクタリングは，何も大規模な構造の変化を求めているわけではないのです．g_flg の例のように
「変数の宣言領域をローカルに移す」という比較的に軽い手間でも効果を発揮する
のです．
この事実を知ってしまっても，なおリファクタリングをしないと決断する人はいないのではないでしょうか．
|
|
|
●リファクタリング |
|
|
リファクタリングが行われないおもな理由は，メリットが見えにくいという点にあると思います．リファクタリングのメリットは可読性が良くなり，コードの内容が容易に把握できるようになり，バグが減り，メンテナンスが容易になります．
しかし，システム開発においてリファクタリングが行われる時期はコーディングからそのあとになります．とくにウォーターフォールモデルを採用している場合，コーディングから後ろというのはテストと納品が主であり，一般に非常に忙しい時期になります．バグも出るし，納期も迫っています．猫の手も借りたいほどの忙しさです．リファクタリングに時間をかけるくらいならバグを1 つでも減らしたいと思っているはずです．
そのような1 分1 秒が惜しいときに，リファクタリングという（とくに目の前のバグを取るわけでもない）作業ができるでしょうか？
筆者はここでもマクロな視点が大切だと思います．品質を上げるために目の前のバグを減らすことを考えるか？それとも根本的にバグの少ない品質の良いシステムを完成させることを考えるか？です．視野を広く持つことが大切なのです．
●表裏一体
リファクタリングはテストと表裏一体です．とくにユニットテストと密接な関係にあります．テストコードがあるからリファクタリングの作業ができると思っていただいて良いでしょう．
なぜ，ユニットテストにこだわるのかと言えば，テストの対象を干し草の山にするのか？数本の干草にするのか？の違いです．対象の範囲が狭いほどテストは楽になり，バグも発見しやすく，入り込み難くなるのです．3 本の矢をまとめて折ろうとするから折れないのです．1 本ずつ折れば容易に折ることができるわけです．そして，ユニットテストのコードはそのままリファクタリング時のテストコードに使えるのです．
テストコードを書かない場合，これらのすべてを失うことになります．その損失は，デスマーチになるかならないかの分水嶺になるほど大きいものであると思います．
|
|
|
●フィードバックサイクル |
|
|
開発するシステムの規模が大規模になればなるほど，ユニットテストやリファクタリングなどのプラクティスは重要になります．テストコードを書き，実装し，テストをし，リファクタリングをする．このループを円滑に循環させ素早く回すのです．その流れを保つことがシステム開発にふさわしい「場」になるのです．
Java やC++といった個別のプログラミング言語に左右されるような考え方ではないのです．「物」や「技」ではなく「場」や「道」を重視するのです．その「場」や「道」は，マクロな視点から考え，立ち止まらずに考えつづけることで保つことができるのです．
|
|
|
●Eclipse |
|
|
幸いなことに，この本の読者の皆さんは，筆者が弱点であると思う「品質やメンテナンス性」について最先端と言っても良いほど，良く効く道具を手にしたことになります．Eclipse という開発環境は，ユニットテストの機能やリファクタリングの機能をサポートしています．これらの機能が滞りなく円滑に操作できる「場」はおそらくほかにはないと思います．
筆者の経験から言えば，この
ユニットテストやリファクタリングは，システムの品質やメンテナンス性にとても良く効きます．
これを使わない手はありません．さらにEclipse はとても大切なモノを持っています．それは「進化することができる」ことです．時代の変化に追従できる能力を持っているということです．皆さんの手で使いやすい道具に変化させることができると同時に，時代の変化に追従し生き残る能力も持っていることになります．
しかし，何度も言うようにEclipseは道具であることを忘れてはいけません．道具は考えてはくれません．考えるのは皆さんです．そのことをくれぐれも忘れないでください．そして誰にも負けない情熱を持ちつづけてください．情熱を持ちつづければ『七人の侍』や「ディズニーランド」を超える作品を現実のモノにできることを知ってください．
ここでもう一度，筆者が大切だと考える言葉を書いておきます．
・物や技ではなく場や道である
・人が作るということ
・つねに考えつづけること
・誰にも負けない情熱を持つこと
|
|
|
●墨壺（すみつぼ）の話 |
|
|
皆さんは墨壺という道具を知っていますか？プログラマであれば，モノづくりの好きな人が多いでしょうから，知っている人も多いと思います．
墨壺は大工道具の1 つです．おもに木材に直線を描くために使います．少し考えると，鉛筆と定規で描けそうに思えますが，木材には木目がありデコボコしていて鉛筆では上手く描けないのです．また，長い距離をまっすぐに引くのは定規では至難のわざです．そこで糸に墨をつけて，まっすぐに張り，糸を弾くことで墨を木材に付けるという道具，墨壺が考えだされたとのことです．
最近では，工場などで機械によって組み立てられたパーツを，現場で組み立てるだけの仕事が増えてしまったようで，墨壺の出番も少なくなっているようです．
その昔，墨壺は市販されておらず，棟梁が自分の手で工天しながら作っていたそうです．現在のプログラマが，自分で工夫しながら開発環境を作りこむのに近い感覚と言えるでしょう．
●忘れ物の墨壺
ある博物館に「忘れものの墨壺」と呼ばれている墨壺があります．その墨壺は奈良の東大寺にある南大門を修理したときに，梁（はり）の上から発見されたそうです．当時の人たちは単純に「忘れていったのだろう」と思ったのでその名前がついたのだそうです．しかし墨壺は大工道具の中でも大切なモノです．何年も使い込み，使い込むほど使いやすくなる道具です．その墨壺を忘れるでしょうか？しかも梁の上に．
おそらく，その墨壺の持ち主である棟梁は，南大門を最後の仕事と決めたのでしょう．持てる力を出し切り，悔いのない仕事をして引退する．そんな気持ちをこの墨壺にたくして，置いていったのだと思います．
もしかしたら，再び発見されるかもしれない…，いや，自分の建てたこの門は絶対に壊れることはない，そう確信していたのかもしれません．その確信があったからこそ梁の上に置いたのではないでしょうか．
たとえ，南大門の仕事を完璧に仕上げたとしても棟梁の名前は残りません．しかし，棟梁には自信があったのでしょう．名前は残らなくても，墨壺は残り，この仕事の優秀さを証明してくれるだろう…と．
筆者はこの話を聞いたとき，何か心に響くものを感じました．なんとも表現しにくいのですが，もし，自分がその棟梁の立場だったら，最後の仕事に全力を出して，キッパリと辞められるのだろうか？そんなことを考えたのです．また，大事に使っていた道具（たとえばPC ）から離れられるでしょうか？そんな粋な大人になれるのでしょうか？今の筆者には自信がありません．でも，そんな大人になって，格好よく引退したいという気持ちはいつまでも持ちつづけたいと思っています．
| |
「Eclipse パーフェクトマニュアル vol.1」 は書店やAmazonで購入できます。