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

第6回　「落ちこぼれエンジニア」のスキルアップ戦術

萩本順三（豆蔵取締役）
2004/4/21

私は“落ちこぼれエンジニア”だった。これは事実だ。落ちこぼれだった人の記事など読みたくないと思わずに、どうかお付き合い願いたい。今回は、「落ちこぼれエンジニア」のスキルアップ戦術。つまり、落ちこぼれだった私の経験を振り返り、戦術としてまとめたものを紹介したい。

■お荷物エンジニアの私

　私はIT業界に遅れて入ったために、仕事ができない“お荷物エンジニア”だった。この業界に入る前に情報処理技術者試験などで勉強し、それなりの準備をしてきたつもりであるが、同レベルの若手エンジニアと比較すると仕事ができない方だった。実際に、私の上司は「中途採用の私は使えない奴だ」とほかの社員にグチを漏らしていたくらいだ。

　必然的に第一線の面白い仕事ではなく、某社に常駐してホスト系Debugger（デバッガ）のアセンブラコードを読みながら設計ドキュメントを起こすという“退屈な仕事”しか与えられなかった。隣で新しいデバッガの開発をやっているエンジニアや、UNIX、C言語など最先端の仕事をやっているエンジニアがとてもうらやましく思えた。

　何しろ、もともとCOBOLしか覚えていなかった私が、にわか仕立てで覚えたアセンブラの知識などを、仕事で使えるはずがない。第一線で仕事をしているエンジニアは上司から「セミナーに行ってこい」といわれていたが、私にはまったくお声が掛からなかった。自分の技術スキルに自信がないので、セミナーに行きたいのに、行きたいということすらいい出せなかった。

　技術者になる夢を持ってこの業界に入ってきた以上、やる気は人一倍あったのだが、いつの間にか、私には“落ちこぼれエンジニア”というレッテルが貼られているような気がしてならなかった。前職は経理マンであり、かなり頑張って、よいポジションを勝ち得たので、レッテルを貼られたことはとても屈辱だった。そのギャップに苦しみ、一時はノイローゼの一歩手前までいったこともあった。

　しかし、よく考えると私は常に「落ちこぼれ人生だった……」。学生時代はスポーツで腰を悪くし中途半端で終わった。前職ではそれまでの人生の巻き返しを図るため、ゼロからのスタートであったが、これもエンジニアを目指したことで中途半端に終わった。IT業界に入ったときは、いわばマイナスからのスタート。そういえば子どものころから兄弟の中で一番の落ちこぼれだった。自分はそもそもそういう存在だと思い始めたころから少々気楽になったものだ。

■落ちこぼれに与えられる小さなチャンス

　20代後半になると、かなり焦ってきた。何とかして上司に認められたいが、どうすれば仕事ができるようになるのかが分からない。しかし焦っていた割には、仕事のやり方はずいぶん遠回りをしていた。何か疑問に思うと、それを奥深く掘り下げてしまうのだ。例えば、アセンブラの命令1つ1つの意味が知りたくなったり、システムコールを呼んでいる個所を見るとOSの仕組みを学びたくなったりするのだ。

　当時アセンブラだけではなくシステムの記述言語を学ぶ必要があったのでコンパイラの仕組みにも興味を持った。スパゲッティコードを見ると、どのようにして構造化すべきかということに興味を持ち、構造化手法を学んだ。

　そのころから“優しい上司”をつかまえてはしつこく質問攻めをした。ほかの上司から、「萩本、それは仕事にあまり関係ないだろう。そこまで考える必要はないのに何でそんなことを調べるのだ」とよくいわれたものだ。確かに上司のいうことはもっともだが、それは何であるかが分からないと先に進めない、いや完全に理解するまで進みたくない性格だったのである。

　いま思えば、地道に納得いくまで繰り返してきたことで、基礎知識が身に付いたといえる。例えば、OSの仕組みを徹底的に身に付けたので、アセンブラのロジックの意味がよく分かるようになった。また、コンパイラの仕組みが分かるようになったので、プログラム言語がどのように機械語に展開されるのかも手に取るように理解できた。

　さらに構造化手法を学ぶことでオブジェクト指向への理解も深まり、次のステップアップのきっかけにもなった。この時期から、いままで遠くを走っているように思えた同僚エンジニアの存在がかなり近くに見えてきたのである。

■落ちこぼれにできることは、次に使えるエンジニアを目指すこと

　なぜ、このような“立場の逆転”ができたかといえば、私には時間があったからだ。そもそも期待されていない落ちこぼれエンジニア。やることさえやっていれば、それ以上の知識を求められる仕事は回ってこなかった。浮いた時間を自分の勉強の時間に利用したのだ。しかも、当時の私には焦りと悔しさがあったので、技術バカといわれようが、何といわれようが、がむしゃらに突き進むという意志だけは人一倍備わっていた。

　私のような落ちこぼれに与えられた小さなチャンスとは、以下の3つである。

（1）学ぶ時間があり、それを有効に使ったこと
（2）がけっぷちに立たされた自分の心理状態をうまく利用したこと
（3）「基礎知識」を大切に身に付けてきたこと

　そして、上記の「基礎知識」を現在の技術でたとえると、次のようになる。

（1）Javaを学ぶのに手続き型言語を基礎知識として学び、さらにオブジェクト指向技術とその価値まで学ぶ
（2）オブジェクト指向を学ぶ前に構造化手法を学び、オブジェクト指向の必要性を理解する
（3）EJBを使うために分散オブジェクト、データベース、ORマッピング技術、トランザクション技術といった基礎技術を学ぶ

　なかなか、このようなことを基礎から学ぼうとする人はいないかもしれない。しかし、急がば回れ、ダマされたと思って自分の時間を最大限活用して学んでみてほしい。きっといままで考えられなかったような実力がついてくるだろう。

　優秀なエンジニアほど、日々の仕事に追われやすい。「どうせ自分は落ちこぼれ……」と落胆せず、次の仕事で役立とうと思うべきだ。自分はダメだと考える余裕があったら、その分明日のために勉強しよう。

■嫌いな仕事をこなすことこそ、逆転できるチャンス

　「嫌な仕事だなあ」というものほど、いまになって考えると非常に貴重な経験だったように思う。例えば、ドキュメンテーションばかりやらされたころ、もっと開発の仕事をやりたかった。そうしなければ、若手エンジニアにますます差をつけられると思っていたからだ。

　しかし、ドキュメンテーションをまとめてきた経験は、プログラムを書く前の設計をする際にとても役立った。プログラムを書く前に、プログラムの仕様を書く習慣が身に付いたのだ。また、プログラムを書きたくても書けないという悔しさによって、自分の中でプログラムを書きたいという欲望が強まった。そのため、自宅でコツコツとプログラミング作業に専念する気持ちがわいてきたのである。

　当時は派遣社員だったので、ユーザーといつも一緒に行動していた。最初は雑用係だった。このとき、営業的な仕事も経験した。上司には、「お前は営業をやっていればいい」といわれた。しかし、同時に開発の仕事にも携わっていたので、一生懸命こなすうちにユーザーに信頼してもらえるようになった。

　そうなると、ユーザーと仕事のやり方、開発の進め方などでいろいろ話し合う機会が増えてきた。ただ、ユーザーのために譲れないことは決して譲らなかったので、ものすごい論争になったことが何度もある。最初は嫌われていたが、私の信念がユーザーに伝わり、本当の意味での信頼関係が出来上がったように思う。これは私にとって何よりも代えがたい大きな財産となった。ユーザーのためと思って信念を持って発言することは、最初はぶつかっても、最終的にはユーザーとの信頼関係につながるということを体感したのである。

　このような経験を通じて、開発マネージャとしてのマネジメント能力や交渉能力の基礎が身に付いたのである。

　そうこうするうち、私はそのユーザー（部長さん）から気に入られ、ユーザー教育を任された。このときに、ひっそりと学んできた基礎知識や自宅で実践してきた先端技術を最大限に発揮し、自分の目指す分野の仕事を勝ち取ったのである。オブジェクト指向もその中の1技術だった。

■ユーザーとの出会い

　このようなユーザーとの出会いは大切だ。（ここで名前は明かせないが）あるエンジニアと一緒に仕事をする中で、さまざまなことを学んだ。一番学んだのは技術者魂だ。彼は、徹夜が好きで何かにつけてマシン室で徹夜していた。体にはよくないことであるが、徹夜仕事に付き合ううちに“マシン語”を体で覚えたように思う。

　私の技術者としての基礎は、その方と一緒に働いているころに出来上がったのではないだろうか。社内でヌクヌクと育つのではつまらない。エンジニアとしても成長できない。会社の外で戦いながら成長することによって、自分のスキルをアップさせるべきなのである。

■失敗プロジェクトは自分を磨けるチャンスと思え！

　私が落ちこぼれエンジニアの道を歩んでいる最中に、とんでもないプロジェクトのメンバーに入れられたことがあった。ほとんど毎日徹夜で、プロジェクトマネージャはいたが、「何をどう作るべきか」という方針はほとんどない。単に訳の分からない関数仕様をポンと渡され、それに合わせてプログラムを組んでほしいといわれた。

　そうして作られたプログラムを組み合わせても、システムがうまく動くように思えない。私はそうした不安のために仕事が手に付かなかった。「自分がおかしいのか？ それともプロジェクトがおかしいのか？」と、随分悩んだものだ。

　後日そのプロジェクトは途中でストップし、もう一度システムを作り直すことになった。プロマネが管理しないプロジェクトほどタチが悪いものはない。このとき、プロジェクトマネジメントの必要性を実感した。私が、異常なほど方法論や開発プロセスにこだわり続けるのは、このような“苦い開発経験”からくるものである。

■ホストエンジニアにも十分チャンスがある

　前職はソフトウェアエンジニアではなかった。非常に遠回りをしてこの業界に入った。しかし、前職の経理マン時代に行ったことは決して無駄な経験ではない。その会社がシステムを導入したとき、社内SEとして日々出力された仕訳の数字合わせや、間違った仕様（つまりバグ）を見つける作業をこなしてきた。

　経理マンというよりも“何でも屋”だったのだ。レストランのウエイターや、婚礼宴会のボーイもやったが、これらの経験が非常にプラスになっている。それはさまざまな視点で物事を考えることができるようになったからだ。

　私の専門であるオブジェクト指向技術でいえば、（開発者だけではなく）ソフトウェアの利用者の視点を持っていることが最大の強みと考えている。最近のソフトウェア技術において利用者の視点は欠かせない。Javaベースの「分散オブジェクト技術HORB ver2.x」の開発リーダーをやっていたころも、HORBがどのように使われるかという利用法を最重視しながらプログラミングインターフェイスを産業総合研究所の平野博士と二人三脚で設計し、内部の設計に落とすようにしていた。

　「作る視点と、使う視点を併せ持つこと」こそ、ソフトウェア開発に重要なことなのである。もちろん、それ以外の視点を持つことも必要だ。以前、私が開発したコンポーネントベースの開発方法論「Drop」も、ある人から、この方法論は「視点の方法論ですね」といわれたくらい、さまざまな視点を持ってソフトウェアの開発方法を書いたのである。このような視点をたくさん持てたことが、エンジニアとしての器を大きくしてくれたのではないかと思う。

　最近COBOLなどをやってきたホストエンジニアが、オープン系の開発に移行するケースが増えている。その流れについていけないエンジニアを見ると、昔の自分を思い出す。じっくり学びさえすれば、きっと明日が見えてくるのだ（学び方の戦略については、連載第2回参照）。

　ホストで培った技能をオープン系の開発で生かす方法を自分で考えることができれば、いつの間にか優秀なオープン系エンジニアになれるだろう。急がば回れということと地道な日々の努力、そして落ちこぼれに与えられる時間を有効に使っていこうではないか。

■一流へのステップに必要な体験、それが落ちこぼれ時代

　落ちこぼれ時代の経験は、一流へのステップアップに貢献することもあるような気がする。私も一流を目指す人間として、落ちこぼれ時代を振り返り、どのようにして苦難を乗り越えてきたのかを考えた。

　その答えは「失敗を恐れないこと」「敗者になってもあえてそこから無理して抜け出そうと思わないこと」、そして、「それらの苦い経験を（一流になるまでの）プロセスとして味わうこと」などではないだろうか。そうすることでエンジニアとしての器は大きくなると思うのだ。

　しかし、落ちこぼれた状態から這い上がろうとするには努力が不可欠だ。それが伴わなければ何も生まれない。常にあきらめず、やる気を維持することが重要なのである。

■回り道と思っていることこそ近道になる

　私の場合、常にこれが当てはまった。では、「なぜ回り道と思っていることこそ近道になるのか」をここでよく考えてみたい。人間、慣れてしまった仕事はどんなに難しいことでも頭を使う努力を怠ってしまう。慣れない仕事ならば単純なことでも頭を最大限に使う。「ひょっとしたらこれは間違っているのではないだろうか？」と……。

　いつも似たようなソフトウェア開発の仕事ばかりしていると、どんなに難しいものでも頭を使わなくなっていく。また新しい視点で見ることができなくなるので、（素晴らしいものはもちろんのこと）これといったアイデアさえも出なくなる。だから、伸び悩むのである。いまこそエンジニアは、さまざまなことにチャンレンジしてみよう。例えば、営業マンに頼んで、一緒に顧客のところに出向いて話をするとか、自分の会社の経営者と経営について議論するとか。

　自分の殻を打ち破ることは、つらくきついものだと思う。ただ、そのつらさは、自分の頭の使い方を変えることが生じるつらさであり、新たな視点を持つには必須のものなのである。決してそこから逃げてはいけないのだ。

■知識とは何か

　本連載の第2回で知識について下記のように書いた。

私は、知識には2種類あることをようやく理解できた。書籍や人から教わった知識と、教わった知識を自分の体験と照らし合わせて検証を繰り返すことで、自分の中で創造された新たな知識である。

　このことをもう少し詳しく説明すると、知識を身に付ける方法として次のような“魔法”を知っておくこともスキルアップにとって非常に有効だと思う。

●経験だけを当てにするな！

　「何事も経験、経験」と、とにかく経験を大切にする人も多い。しかし何度経験しても同じ失敗を繰り返したり、まったく進歩がない人もいる。本当に経験を積み重ねることで優秀なエンジニアになれるのだろうか。私はそうは思わない。経験も重要とは思う。しかし、経験と対にして同じ程度重要なのだが、なかなか実践されていないことがあると思っている。それは、経験をした後の「思考の整理」と「シミュレーション」である。

　つまり経験したことをしっかりと頭に整理するために、「誰と何をいつどのように経験してどうなったか」ということを頭の中でやや抽象化して蓄えておき、ほかの経験と比較するのである。頭の中で経験を抽象化すると、異なる経験でも共通の概念が見つかるものだ。このような抽象的な概念は、経験の中から「どうやったのか？」という方法に着目して抽出すればいい。

　そして、そのような方法とは異なる方法を使って“新たな経験を想像する”。これがシミュレーションである。または同じ方法で異なる結果が出ることを想像するのである。こうして結果を想像するのがシミュレーションである。これを連載第2回と第5回で紹介した「思考の秩序棚」を使って説明したものを図1に示す。

図1　思考の秩序棚（経験の例）

　このような思考法により、ほかの業界での経験も、自分の経験と照らし合わせることができる。経験の内容や領域（例えば業界）が異なっても、概念レベル、目的レベルでは共通することが多い。つまり、人の成功体験と自分の失敗体験とを比較できる。これはあくまで私のやり方であるが、いずれにせよ、経験とともに、思考の整理をしなければ、経験を生かすことはできないのである。少ない経験で多くの知識を得て、多くの擬似経験を行うテクニックを身に付けることも重要なのである。

●本を読むことだけが勉強ではない

　本連載で以前にも取り上げたが、本を読まずに物事を考える時間を長く持つことは重要である。勉強熱心な人ほどたくさん本を読んだかどうかで、勉強したかどうかを判断してしまうものだ。本を読むだけでは無意味である。本を読んだ後、自分の頭でそしゃくすることが重要なのだ。この作業は慣れないうちは結構つらいかもしれない。

　もし、つらいと感じるのならば、その作業は自分の頭で真剣に考えず、単に本に目線を流しているにすぎない。本を読みながら、著者の意見に自分の考えをぶつけてみることが重要だ。そうすることで、本に書かれていない本質が見えてくることがある。本を読み、自分の考えと戦わせることで、自分のナレッジとして確実に蓄積することができるのだ。

　以上、「自分は落ちこぼれエンジニアではないだろうか？」という不安を持っている方々に贈る、“元落ちこぼれ”だった私からのささやかな知識のプレゼント。しっかりと受け継いでいただけただろうか。

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