さまざまな困難をどう乗り切ればいいのか
ITエンジニアとしての道を究めるには

第2回　エンジニアとして生き残るには

萩本順三（豆蔵取締役）
2003/11/26

　エンジニアは自分の道、ノートパソコンは侍の刀、だから私は侍。侍は刀さえあれば道を究めることができる。そして日々の仕事は武者修行。刀を抜くように、ノートパソコンをパカッと開き戦いに挑む。

　皆さんは、このようなことを考えたことがあるだろうか。私はパソコンを使うとき、大まじめにこんなことを想像してきたが、このことを人に話すと、必ず笑われる。そのとき、自分自身、自分のこっけいさがおかしくなって笑うのだが、それでも自分の生き方に誇りとこだわりを持っている自分が好きである。

　皆さんは、どのようなエンジニア人生を思い描いているのだろうか。私のように侍魂丸出しのエンジニアもたまに見掛けるが、最近は何かつまらなそうなエンジニアが増えているような気がしてならない。そもそもエンジニアという職種は、クリエイティブな仕事であったはずなのに、何かとてもつまらない仕事のように思っている人が多いようだ。

　私がエンジニアを辞めるとき、それは、夢をなくしたときである。そう決めて15年ほどたったが、まだまだ夢は蓄積するばかり。このような感覚を持ってエンジニアを務めている人はどのくらいいるのだろうか。

　今回は、SE（システムエンジニア）とは、どのような職種なのかを皆さんに再確認していただき、皆さんが選んだ道に間違いがなかったことをあらためて感じてほしい。また、そう思わない人は、できるだけ早く職種を変えた方がよいとアドバイスしておこう。

■プロのエンジニアとしての資格

　何も資格をたくさん取りなさいということではない。資格というより資質という方が正しいかもしれない。いまの時代に必要とされているプロのエンジニアとして重要な資質には、次の3つのものがあると思う。

（1）技術の本質を読む
（2）物事の本質をつかむ
（3）時代を読む

　それでは、それぞれについて詳しく解説しよう。

■技術の本質を読む

　なぜこの技術が必要とされているのかをしっかりと考えると、技術の本質が見えてくる。いまの時代、技術が技術だけの魅力で使われることはまれである。必ずビジネスでどのように利用できるか理解する必要がある。この技術が、どのように（ビジネスで）必要とされているのかを見抜くことができるよう、日々鍛錬していれば、技術の本質を読むことができ、伸びる技術と伸びない技術、本物の技術と偽物（または一時）の技術の見分けが付くようになる。

　この鍛錬は、日々「なぜ、何？」の繰り返しが必要とされるため頭を休める暇がない。一方、技術を技術だけの魅力で追求している人は、どんなに難しい仕事であっても、頭の使い方は単純に慣習化されてしまう。

　私は、技術を頭の中で整理する際に、次のような思考の棚を考え、利用している（図1）。この棚については、別途詳しく取り上げるため、今回は簡略化して説明しよう。

図1　思考の秩序棚。対象の問題について視点を切り替えながら考察する方法

　棚の下段には、モノやコトを示すクラスの入れ物がある。その上には、モノやコトを形成するための重要概念の入れ物が存在する。そして、その上には目的がある。この思考の棚を使って、これから習得する技術を整理する。

　プログラミング言語であれば、その言語機能がクラスとして登場し、その機能を使ってできているコンセプト用語が概念にくる。そして、そのコンセプトが目指すものが目的の棚に入るのである。このように、目的、コンセプト、クラスという層（つまりは視点）を行き来しながらつなげていくことで、1つの言語機能を概念と目的に結び付けて理解するのである。

■物事の本質をつかむ

　物事の本質をつかむ習慣は非常に重要である。私が以前、「Drop」というオブジェクト指向方法論を作成していたころ、エンジニアの知識やセンスとは何か、まったく分からなくなったことがある。それ以前、私が技術に対して自信を持ち始めたころ、それに有頂天になったときがあった。当時の私は、まるで技術という鎧（よろい）を身に着けて、戦車のような勢いで職場を暴れ回っていたように思う。技術は正しい、イエスかノーかのどちらかしかない。技術を持って正論で戦えば必ず勝てる。技術の鎧を身にまとっていれば怖いものはない。上司だろうが社長だろうが、まったくお構いなしだった。だからそのようなエンジニアに出くわすと昔の自分のように思えて親しみを覚えてしまう。

　そのころ、オブジェクト指向は創成期であったため、まだまだ使える方法論はなく、現在のように開発プロセスに着目した方法論が必要であった時代だ。そこで私は、再利用コンポーネント開発を標準とした開発プロセスと開発手法をひとまとめにしているオブジェクト指向方法論をつくろうと、3年ばかり頑張ったのである。オブジェクト指向方法論とは、オブジェクト指向技術を使ったソフトウェア開発のルールや知識を手法として伝授するようなものである。しかし、単にルールを決めても意味がない。確固たる技術と経験を基にして開発のルールを定めることが重要であった。

　オブジェクト指向方法論をつくろうと思い、勢いよく取り掛かって2年間。その間は悲惨なものであった。自分の頭の中で輝いて見えた知識やセンスを文章に書いてみると、どこかで聞いたことがあるような、つまらない文章になってしまうのである。誰かのマネならば方法論などつくらない方がよい。マネではない自分独自の知識やセンスが多少なりともあったはずだ。しかし、それを文章化して表すことができなかった。自分のものと思っていた知識は、いったい何だったのだろうか。センスと思っていたものの正体は何だったのか。

■知識には2種類ある

　このことを追求しなければ、自分の目指す方法論などつくることはできない。つまり、自分の言葉で技術を語れなければそれは自分の知識ではない。教えてもらっただけでは知識として身に付いていない。また、自分で学んだとしても自分の知識ではない。

　私は、知識には2種類あることをようやく理解できたのである。書籍や人から教わった知識と、教わった知識を自分の体験と照らし合わせて検証を繰り返すことで、自分の中で創造された新たな知識。この後者の知識こそが自分の知識であり、これがない限り方法論などつくりようもないことに気付いたのである。

　そして、私が身に着けていた技術の鎧は、自分の知識になっていない表面的な技術で固めていたのではなかろうかと思い至ったのである。それで技術の鎧を勇気をもって捨て去ろうと考えた。自分の頭で技術を構築し直すために。

　技術の鎧を捨て去ってみると、いままで見えなかった世界に気が付き始めたのである。「難しいことが技術だ」と考えていた愚かさに気が付いたのだ。なぜなら、技術の鎧を捨て去るということは、以前から使われていた難しい技術用語を捨て去り、自分で理解したやさしい言葉に置き換えて話すことが要求されたからである。

　その中で気が付いたのは、「難しいことをやさしくする」ことこそが難しい技術だということである。平凡な言葉で難しい技術を説明できてこそ、真に身に付けた技術といえるのである。

　そう考えると、ソフトウェア開発手法、オブジェクト指向、方法論などはまだまだ未熟なものである。これからいくらでも新たな考えを導入できるすき間がたくさんある。そのすき間を狙うヒントは、「難しいことをやさしくすること」に尽きると思う。

■時代を読む

　非常に流動的な時代であるため、将来どのようなエンジニアになるのかをしっかりとイメージしておく必要がある。そのためには、多少なりとも時代を読む力を養う必要がある。図2は、技術が発展する際に、何がしかのパラダイム転換が起こるというものである。

図2　パラダイム転換の瞬間を読む

　このパラダイム転換の瞬間を読むことがエンジニアとして重要なことである。パラダイム転換の時期には、下記のような現象が起こる。

• 技術的には後戻りする
• 新たな技術の発展は技術的妥協(点線矢印)から生まれる

　例えば、ダウンサイジングの波によって妥協されたものは信頼性である。つまり、この時代の業界は、ダウンサイジングの波によって、コストの低減や利便性の向上を目指す代償として、信頼性を追求しなかった時期なのである。また、DOSからGUIに移り変わったときには、GUI化の波に乗って使い慣れたDOSの利便性をあきらめた。

　次が私にとって、最も面白いパラダイム転換であった。ユーザーがオープン化の波に乗って便利なGUI環境を捨て去りWebの使いづらいユーザーインターフェイスで満足（我慢）したことだ。これには私も驚いた。というのも当時、WindowシステムにおけるGUIの開発にはかなりの開発コストが掛かり、ユーザーはそのGUIを使い慣れていたため、Webアプリケーションの貧弱なGUIに満足してくれないのでは、と思っていたからである。ところが、そのような私の常識は簡単に覆された。開発コストの低減とオープン化とインターネットの自由度の魅力の方がWindowシステムのGUIよりも数段魅力的にユーザーは感じたのである。その後、Webアプリケーションにも基幹系の高度な開発を行う必要が出てきた。そこに高度なオブジェクト指向言語Javaを使う理由が生じているのである。

　このように、パラダイム転換が起こるときに技術的には後戻りする。まず後戻りする個所としては、技術的妥協点部分（図中の赤色点線）がそうである。それに新しい技術・言語が登場すると、それに伴った環境を最初から構築するということでも、技術的には後戻りすることになる。

■パラダイムの転換を読む

　さて、このパラダイム転換の瞬間を読むとはどういうことだろうか。

　最初に重要なこととして、パラダイムが上りきったとき、新たなパラダイムがどのような原理で生まれているのかを見抜くことである。私は、最近のパラダイム転換の原理は、ビジネスにフォーカスしつつ技術がシンプル化する流れの中で生じていると確信している。おそらく、次のパラダイム転換もそうだろう。そのようなとき、エンジニアはどんな戦略を取るべきだろうか。

　この図にはもう1つ重要なことがある。それは、パラダイムが上りつめているときは、標準化志向・安定志向が強くなる。これは、インターフェイス安定時期といってもよいだろう。つまり、1つのパラダイムが文化として根付いている時期である。しかし、ビジネス環境は徐々に変化するため、この一見安定したかに見えるインターフェイスが徐々に合わなくなったり、インターフェイスが肥大化して中身の空洞化が始まるのである。そうなると、新たなパラダイムの登場を人々は待ち望むようになる。

　そこに登場する新パラダイムには、創造力・破壊力・構築力が必要とされる。これは、インターフェイス構築時期といえよう。残念ながらいまの日本におけるIT業界には、この創造力・破壊力・構築力が欠けているように思える。これはエンジニア個人の問題でもあるが、社会・企業の問題でもある。

　標準化志向・安定志向に強くて、創造力・破壊力・構築力が欠落していては、次なるパラダイム転換の時期に、現状の既存概念を崩し、再構築できる人はいない。エンジニアとして生きていくためにも、エンジニアという職種を楽しくするためにも、ぜひともこのNewパラダイムを呼び起こし盛り上げる能力を磨いてほしい。

　次回は、エンジニアの課題、将来のエンジニア像についてお話ししたい。

筆者プロフィール 萩本順三●豆蔵 取締役。20代後半でエンジニアに転身。その後、泥くさい開発の中からソフトウェアの構造をとらえることに関心を持つ。それをきっかけとしてオブジェクト指向技術に出合う。最初は同技術を疑い続けていたが、いつの間にかオブジェクト指向の虜（とりこ）となってしまい現在に至る。