私がエンジニアとして挫折した時の話
はじめに
「コンピューターとの衝撃的な出会い」によって、中学生のときにはソフトウェアエンジニアになるという自分の将来の進路を決めていました。これから進むべき道になんの迷いもありませんでした。
やがて、社会人となった私は、晴れて独立系のソフトウェア開発会社へと就職します。
その頃の日本は経済バブル期であり、日本全体が活気に溢れていました。その中にあってIT業界は産声を上げてから年月も浅く、特に異様な活気に溢れていました。
幸運にも、入社後は信頼できる上司にも恵まれ、職場の雰囲気も自由闊達で、皆が生き生きと仕事をしていました。
好きな事を仕事にして、夢中になっているうちに、あっと言う間に10年ほどの歳月が流れていきました。
今回は、そんな頃に私に訪れた困難と、そして大きな挫折を経験した事について、お話してみたいと思います。
長文になると思いますが、気楽にお読み頂けたら嬉しいです。
求められる役割の変化
中堅どころとなった私は、数名からなるチームのリーダーとしてプロジェクトを任されるようになっていました。必然的に求められる役割はマネジメントとなります。
顧客との打ち合わせ、仕様調整、見積もり、そういった仕事に多くの時間を割くようになると、自然とプログラムコードを書く、という仕事から遠ざかるようになっていました。
めまぐるしい勢いで日進月歩で進化していくITの世界で、最新の技術から遠ざかるという事は、１人の技術者として致命的でしたが、日々の仕事の忙しさに追われているうちに、次第に技術の勉強が疎かになっていたのです。
時代はサーバーサイドのアプリケーションへ
さて、本題に入る前に、この時代の背景を説明させて下さい。成長期にあった当時のIT業界は、現在の成熟期を迎えた状況とはまったく異なり、一年単位でガラリと技術が進化していく激動の時代でした。
背景色を変えておきますので、面倒な方は読み飛ばしてください。
黎明期から始まったIT産業は、大型コンピュータを主体とするメインフレームの時代から始まりました。やがてコンピューターの性能が劇的に向上し、かつ値段も安価になったことで、ダウンサイジングの波が起こり、メインフレームからオープン系と呼ばれる開発へとパラダイムシフトしていきます。
今では当たり前となったネットワークインフラは、その当時ようやく形になり始めた頃であり、その後インターネットブームが起こり、ブラウザーが登場してきます。
それまでのアプリケーションは、クライアントPCから直接データベースサーバーと通信していましたが、ブラウザーの普及と共に、徐々にwebアプリケーションの波が近づきつつありました。
今の時代から考えると、ちょっと理解が難しいかもしれませんが、バックエンドの領域は、今のように枯れた技術ではなく、まさにこれから進化していく過程にありました。
Java言語を知る者も、まだ殆ど居なかった時代です。インターネットの普及に後押しされるように、サーバーサイドでのアプリケーション構築という新しいシステム、新しいソフトウェア開発の波が来ていました。
アプリケーションサーバーの登場
サーバーサイドでのアプリケーション構築が始まると、それまでのクライアント層とデータベース層という二層からなるシステムに新しいビジネスレイヤー層が生まれました。
アプリケーションサーバーの誕生です。しかし最初はとてもシンプルで貧弱なものでした。
やがてJavaを開発したSunマイクロシステムは大手のベンダー各社を巻き込んで、アプリケーションサーバーのリファレンスを策定します。これはJCPと呼ばれる活動によって、広く世界中の技術者を巻き込んで行われました。IBMや日立、富士通などの大手からは、この新しい規格にそったアプリケーションサーバーが開発されるようになります。
世の中のアプリケーションがwebベースに徐々に移行していく中、いよいよ企業のミッションクリティカルな基幹系と呼ばれる大規模システムをアプリケーションサーバー上で構築するという、新しいシステム開発の時代に入ろうとしていました。
技術の話題の中心は、バックエンドのサーバーサイドを中心に大変な盛り上がりを見せていました。
本格的なミッションクリティカルなアプリケーションサーバーの中核をなす技術として当時熱い注目度を集めていたのがEJBでした。
Oracle vs アプリケーションベンダー
既に業界のバックエンドのシェアをDBサーバーという形でガッチリと押さえていたのがOracleです。
そして、後発ながらSunがアプリケーションサーバーという新しいバックエンドレイヤーを開拓して、各社大手ベンダーを巻き込んでEJB規格を策定、Oracle vs Sunという新しい構図が生まれました。
なぜ、EJBがOracleと対立する構図になるのかといえば、EJBは思想としてOracleのみならず、他のDBサーバーを含めたRDBに依存しない技術だったからです。
ここにOracle vs アプリベンダーという新しい勢力構図が生まれました。
このような背景のなか、EJBは新しい機能として期待と注目を集めながらも、業界は微妙な綱引きに揺れていました。
エンジニアとしての挫折
ここから本題に入ります。
私にとって、上流設計である要件定義からプロジェクトに参画することは始めての経験でした。
システム化されていない現場に、ITを導入するためには、その業界のビジネスを理解し、現場の業務を分析し、最適なソリューションを提案する必要があります。
それまで何年か関わってきた業界であったので、ある程度の業務理解はありました。しかし、未経験の領域であるため、「何から始めたらよいものか」と途方にくれました。
このようなソフトウェア開発手法は、ソフトウェア工学に基づいた理論建てされた設計手法が確立されていますが、たとえ知識だけを学んでいても、簡単には行きません。知識に加えて経験が必要なのです。
また、いかに顧客に魅力的に感じてもらえるか、お金を払ってでも欲しい、と思ってもらえるソリューションを提案する必要があります。
その当時の私は、まだまだ技術者としての視点が強く、顧客のビジネスに寄り添うような提案は出来ませんでした。
その結果、数ヶ月に及ぶ、業務分析と要件定義は難航し、いつしか顧客の信頼を失いかけていました。
そんなある日の打ち合わせの場で、顧客から言われました。
「たぁぼまるさん。あなたが頑張っている事は理解しています。しかし私も上に状況を報告しなければなりません。いつまで要件分析を続けるんですか？」
「はい。今も全力で対応していますが、なかなか難しいですね・・・」
と力なく答えると、顧客から厳しい叱責を頂きました。
「たぁぼまるさん。別に難しくはないんですよ。ただ、あなたの力量が足りないだけです。経験不足なだけですよ。もっと、上手に私たちを導いてくれないと困ります。」
これには、返す言葉もありませんでした。
10名ほどが参加していた会議の場がシーンと静まりかえった、あの時の状況は今も鮮明に覚えています。
私にとって、それまで順調に歩んでいたエンジニア人生として、始めての挫折でした。
顧客の信頼を失い、わたしは今のポジションを降ろされる覚悟をしていました。
そんな状況の中、私の上司である広川（仮）さん（私が尊敬する上司の話）が私に言いました。
「厳しい状況かもしれないが、こういう経験がお前のためになるんだ。辛いかもしれないが、最後までお前に任せるから、しっかりやれ」
この言葉に、私は勇気づけられました。
自分のためではなく、人の信頼に応えたい、と心から思いました。
また、顧客からは確かに厳しい叱責を受けましたが、その一方で私に対して「こいつを育ててやろう」という雰囲気を感じていました。長く一緒に仕事をしていく、そういう古き良き風土が残っていた時代でした。
厳しいけれども、だからこそ、信頼に応えなければならない、と思いました。
精神的にも肉体的にも苦しい状況でしたが、私の心は静かに落ち着きを取り戻しつつありました。
頼もしき応援者たち
こうして厳しかった要件分析のフェーズを乗り越え、いよいよ具体的にシステム化のイメージを作り込む設計フェーズに移りました。
このフェーズでは、ユーザの業務を改善する具体的なフローを整理し、イメージできるUIの設計を行う必要があります。
また、技術面で重要なテーマであるアーキテクチャを決定しなければなりません。
この時、非常に問題になったのはまさに技術面でした。私たちは、サーバーサイドの新しい技術であるEJBを採用することを提案していました。
この選択は賛否両論であり、当時の上司である広川さんは「リスクが大きすぎる」として反対していました。
ベンダーにとっても、その時点ではEJBの導入事例はたったの一件しかない、という状況で、アプリケーションサーバーの技術部隊とも相談させて頂きながら、この新しい技術の採用を検討していましたが、その技術部隊からも「スケジュール期間に学習コストが盛り込めないなら、やめたほうが良い」と言われていました。
誰もがEJBの採用に二の足を踏む中、なぜかチームの開発者の士気は高く「やってやろうぜ！」と盛り上がっていました。
しかし、直属の上司が反対しており、EJB採用が見送られる寸前でした。
そんなとき、上司の広川さんが急病になり二週間ほど病院に入院することになりました。
私たち開発チームは、ここぞとばかりに顧客とベンダーの説得を開始しました。
このとき、ベンダーのプロジェクト統括リーダーであった森上さん（仮名）の雄志は今も忘れません。
森上さんはベンダーの事業部の部長と直接交渉して説得に当たってくれ、EJB採用を反対するステークホルダーを説得してくれました。
森上さんが、ものすごい剣幕で
「開発チームが新技術でやりたいって言っているんだ！彼らを信用して任せてやりなさいよ！」
と机をドン！と叩きながら交渉してくれた姿は、本当に頼もしかったです。
そうして、当時の最先端であったEJBの採用が最終的に決定したのでした。
私たちの上司が退院してきて、この事実を知ったとき、「きっと叱られるだろうなぁ」と思っていましたが、広川さんは呆れながら「しょうがねえなぁ、そんなにやりたいなら、やらせてやるよ。その代わり失敗したら、ただじゃおかねえぞ」と釘を指しながらも、私たちを応援してくれたのでした。
天才的なエンジニア
私のチームメンバーの１人に堀田（仮）という天才的なエンジニアがいました。彼は新人のときから私の後輩として配属され、何年も一緒に仕事をしていましたが、成長力が凄まじく、メキメキと頭角を表していました。
社内では既に有名な存在で、他の部署からも何か困ったことがあると「堀田君、助けて」と相談に来るほどでした。当時の社内では随一の技術者になっており、私も彼にはとても及びませんでした。
私たちは馬が合ったのでしょう。職場ではいつも一緒にいました。新人の頃から私を慕ってくれており大切な仲間でした。
チームメンバーからの信頼を失う
プロジェクトの開発が進むにつれ、EJBは当時は非常に難解で開発に必要なライブラリも不足していました。いざ始めてみるとメンバーは技術の難易度に苦戦し、結果として堀田が技術面を全面的にリードすることになりました。
彼の負担は相当に高かったと思います。私も彼を助けたいと思っていました。しかし、数年開発を離れていた事もあり、まったく技術体系の異なる今回のプロジェクトは、私自身も勉強不足でした。
いつも仲の良かった私たちでしたが、デスマーチが続くうちに、いつの間にか口論が絶えないようになっていました。
仕事は深夜まで続き、汚い話ですが、社内のトイレでは何度も吐きながら仕事を続けていました。
これまでに経験した事が無いほどに、辛いプロジェクトとなりました。
力強くリーダーシップを発揮しなければならない時でしたが、私はメンバーの期待に応えることが出来ず、特に堀田は私に対してとても失望していました。私は信頼を失っていました。
私は要件分析での不手際から技術面での勉強不足に至るまで、すべての領域でレベルアップが必要であると痛感していました。
これまでにも、辛いプロジェクトは多々ありましたが、自分自身の能力不足を感じた事はありませんでした。しかし今回は違いました。
私は屈辱感を感じていました。子供の頃から憧れ、そして大好きな仕事をしてきたはずなのに、この体たらくは一体なんだと。自分に腹が立って仕方がありませんでした。
プロジェクトの敗北
結論からいうと、プロジェクトは一応の成功を納めました。私たちはボロボロになりながらもEJB開発を乗り切り、納期にも間に合いました。
しかし、ただ一点、大きな問題がありました。
それはパフォーマンスです。
EJBには構造的にパフォーマンスに関する欠陥がありました。私たちがアプリケーションをリリースする頃、業界全体でも様々に同様の問題が世界的に起きており、技術情報誌には「EJBは失敗だった」と堂々と記事になっていました。
そりゃないよ・・・と思いながらも、なんとか性能向上に四苦八苦する日々が続くことになります。
私にとって、このプロジェクトは敗北でした。
（ちなみにEJBのその後）
EJBはアプリケーションサーバーの規格の一つであり、新しい仕様の策定もコミュニティープロセス（JCP）を通して行われているため、この当時の目まぐるしい技術進化のスピードに明らかに遅れをとっていました。
もはやJCPのスピードでは対応できないのは明らかであり、世界中の有志が個別にフレームワークをオープンソース（OSS）として開発するようになります。
フレームワーク文化が一気に花開いていく始まりでした。
狂ったように努力する
このプロジェクトが無事にフライトしてからの数年間は、私にとってソフトウェアエンジニアとしてのキャリアハイとなっていきます。
このときの挫折と屈辱は、私にとって、もう後に引けないほどの強いモチベーションとなりました。
「もう一度、技術を洗い直す」
という強い決意でエンジニアとして再スタートを切る覚悟が出来ていました。
私は、この頃から私生活の全てをなげうち、全ての時間をソフトウェアエンジニアとして費やすようになっていました。職場では毎日終電まで仕事し、家に帰ってからは、夜が開けるまで技術の勉強を必死に続けるようになりました。
それは果てしない道を進むようでした。ゴールも決めていませんでした。ただ、すべてを仕事に捧げた数年間でした。
まわりの私をみる変化
そのような生活が二年ほど過ぎた頃、ある変化が起きていました。
以前ならあれほど苦労していた上流設計も顧客から認められるようになり、よくやっているとほめてもらえるようになっていました。
また、会社の同僚達も私をリスペクトしてくれるようになり、信頼を再び取り戻していました。
能力が向上することで時間にも余裕が生まれ、普段の仕事は１日3時間ほど集中すれば、充分な結果をだせるようになり、残った時間は後輩の育成や指導に多くの時間を使うようになっていました。
もっとも困難なプロジェクトを乗り越えた事で精神的にもタフになっていました。
それまでと変わった世界
その後、仕事を続ける間に不可能とも思えるプロジェクトに度々出くわしましたが、私にとっては、それが不可能だとは思えなくなっており、「何とかなるだろう」と思うようになっていました。
私は、常にベストを尽くすことを心掛け、そのことにのみ集中するようになっていました。やれるだけの事を精一杯やっていれば、力量が足りなくても恐れることはない。出来なくても良い。挑み続ければいつか乗り越えられる。いつも成長する気持ちを持ちながらベストを尽くす。その繰り返しなのだと悟ったのです。
このときの開発経験は、私のその後の人生に大きな影響を与えました。
エピローグ
仲の良かった後輩の堀田とは、このときのプロジェクトで大喧嘩して以来、仲違いして数年間は口も聞きませんでした。
機会があり、久しぶりに再会して二人で話す事になったとき、私は堀田に当時の素直な気持ちを伝えました。
色々あったけれど、堀田には本当に感謝していました。そして、彼の当時の辛さを理解出来なかった事、先輩として力に成れなかった事を素直に謝りました。
彼は私の話を静かに聞いていました。
少しの沈黙の後、彼は言いました。
「なんでそんな事を言うんですか・・・」
彼の目には、うっすらと涙が浮かんでいました。
私はハッとしました。彼が涙ぐむ姿をみたのは初めてでした。
二人の間のわだかまりは、いつの間にか綺麗に消えていました。
その後、私が会社を退職したとき、堀田から連絡がありました。彼はベンチャー企業に転職し、そこで活躍していました。
「先輩、もう一度、僕と一緒に仕事をしませんか？先輩の力を貸して欲しいんです。」
私は、この申し出を二つ返事で引き受けていました。
仕事は１人でも出来るけれど、信頼できる仲間達と一緒にやるから楽しい。
この記事が気に入ったらサポートをしてみませんか？