あなたがもし、ビル・ゲイツさんやトーマス・エジソンさん、本田宗一郎さんの技術者としてのこれまでの体験について興味が湧けば、WEBで検索すればすぐにその情報が手に入るでしょう。しかし、そのような知名度のあるエンジニア以外にも、世の中には果てしない努力をしてきたエンジニアがたくさんいるはずです。また、そのエンジニア一人一人に唯一無二の貴重な体験があるはずです。
もしあなたがそのようなエンジニアのこれまでの体験について知りたくなったとき、どのような手段を取ればそれらの情報が得られるでしょうか。私がその答えを考えたときに、容易にその情報が得られる方法は出てきませんでした。想像してみてください。
もしあなたがこれからエンジニアとして社会に出ていく新人の立場だとして、様々なキャリアを積んだエンジニアの一番の成功体験や一番の失敗体験などについて事前に聞いておくことができたら、その後の自分のキャリアに大きく活用できると思いませんか。
もしあなたが成長途中の若手エンジニアだとしたら、さらなるスキルアップのため、今だからこそ先人から学び、より今後の仕事を加速していきたいと思いませんか。
もしあなたがベテランエンジニアであれば、ご自身のこれまでの経験と照らし合わせて、ご自身のされてきた努力、他のエンジニアのされてきた果てしない努力を互いに間接的にでも労う、そんな時間を少しとってみたくありませんか。
私は検索をしてもなかなか出てこない”無名の”エンジニアの方の1番の成功体験・1番の失敗体験について、知りたい気持ちが強かったです。
そこで本書ではあらゆる技術職における、新人からベテランまでの成功体験・失敗体験についてヒアリングを行い(エンジニアの方の了承を得た上で)、有益な情報のまとまりとして皆さんに共有ができるものに仕立て上げました。
また、エンジニアの方々の体験や労力にはきちんとした対価を支払うべきで、身銭を切ってヒアリングを行いました。また、単なるエンジニアさんへの報酬だけでなく、魂のこもった体験をぞんざいに扱うことにはならないように敬意を払う意味でも、デザイナーさんにもお仕事として発注させていただき、装丁やデザインに関してご協力いただきました。
どうか少しでも皆さんのキャリアの一助になれば幸いです。
かさた
本書では、一人一人実在するエンジニアの方々からの声を直接集めているため、文章自体もそれぞれの方の想いやスタイルを表すものになっています。
このため、誤字や脱字などの改善は行っておりますが、極力ご本人のありのままのスタイルをお伝えしたく、各体験の口調(文調)の違いや、必ずしも文法的には正しくないスタイルもできる限り残したものとなっております。
男性、 会社員、 流通業(卸売業)、 SE、 30年
流通業界の企業内システムでシステム開発を行っています。昨年、システム全体をオンプレミス型からクラウド型に移行しました。
システム開発業務内容は、インターネット(プライベート)を通じたオンライン受発注システムの開発、保守を行っています。開発内容はLinuxサーバー上で、Web系アプリケーション開発をJSP(JavaServerPage)で行います。
業務アプリケーション開発にpowercobol、データベースシステムはSymfowareを使い、プログラム開発を行っています。運用業務としては、日々の監視業務(夜間は当番制)を行い、システム異常時の復旧対応を行っています。また、業務スケジュールに合わせた自動運転処理のツール開発も行っています。
経歴が長いので、汎用機時代から現在のクラウド型システムに至るまで、数多くの失敗を経験しています。
現在は、システムのハード費用が汎用機時代と比べると格段に安いので、開発環境、検証環境、本番環境と3つの環境を構築できるため、安全な開発ができるようになりました。汎用機時代は、費用面の制限により開発環境と本番環境が同居している状態でした。
最大の失敗は、在庫管理システムの改修をシステムメンバーで行っているとき、本番で動いている在庫をテスト用にコピーを取ろうとして、JCL(プログラムを動かすツール)の入力の定義と出力の定義を間違えて逆にして動かしてしまったことです。在庫が一括管理のため、社内の各倉庫の全商品の在庫数がゼロになってしまい、泣くに泣けない状態に陥りました。流通業で出庫ができないことは、致命的でした。
さらに悪いことに前日、業務終了時のバックアップ(保存)をクリアーして、現在の状態をコピーする予定だったため、クリアー後に本番の在庫にリストア(戻し)してしまいました。たまたま、2日前の業務終了後の在庫のバックアップを別名でコピーを取っていたため、2日分のトランザクション(仕入、売上、返品などの出納)を使い、急遽、アプリケーションを作り復旧しました。ただ、復旧するまでその日の深夜までかかりましたので、出庫業務が停止になりました。
失敗の原因は、在庫のバックアップ、リストア処理を一人のメンバーに任せきりにしたことです。その後は、データベース(重要なファイル)のバックアップ、リストアの管理を手作業で行うときは必ず複数で行うことを義務とし、申請、報告の書類管理の徹底を行いました。
システム関係の仕事に限らず、長く仕事をしていると、指示する側、される側になったりすることでしょう。指示する側もされる側も同じことがいえると思います。
システム関係の仕事の範囲は、とても広いです。会社の規模にもよりますが、社内のシステム部門であれば、雑用的な仕事も引き受けることもあります。そんなときも、何でもやってみるのが大切だと思います。私自身、何でもやって見てから考えるようにしてきました。当然、自分の思うようには、なかなかうまくいきません。失敗も数多くします。しかし、常に新しいことへの挑戦は忘れずにしてきたと思っています。
もうひとつ忘れてはいけないことは、システム技術のスキルアップも必要ですが、業務に関することも、必ずスキルアップしてください。業務知識がないと、いずれやっていけなくなります。業務知識のスキルアップも心がけながら、汎用機時代(日立、富士通、NEC)からクラウド型システムの構築まで、手掛けてきました。自分が率先して会社に提案するよりも、時代の流れに左右されることの方が多いと思いますが、何でもやってみるという姿勢がよかったと思います。
若い人たちには、一度や二度の失敗に挫けることなく、新しい時代への挑戦を継続して行っていただきたいと思います。
男性、 会社員、 研究開発、 38年
開発業務、入社直後はエンジンの性能開発に携わりました。いかにエンジンの馬力を上げるか、吸気、排気ポート形、バルブの開閉のタイミングなどトライ&エラーを繰り返し、狙いの性能を引き出していました。まさに勘と経験が物をいう時代でした。
その後デジタル化が進み、シミュレーションで物を作らず性能を予測し、修正、改善し、最後に物を作って狙いの性能が出ていることを確認するといった、モデルベースの性能開発に進化しています。
現在はトランスミッションのシフトクオリティ(変速時のショックを少なくスムーズにギヤチェンジを行わせるのが狙い)開発を行っています。それを車両にマッチングさせ、ドライバが要求する通りに駆動力をマネージメントするシステムの開発を行っています。
入社して、OJTも進み、エンジンテストベンチで性能評価を任されるようになったころのことです。エンジン出力性能はギヤを直結(減速比が1.0で入力回転と出力回転が同じになる状態)で低回転のアクセル開度全閉状態から動力計の負荷を入れつつ、アクセル開度を開きつつ、最終的にはアクセル開度は全開にして、エンジン回転を500rpmごとに上げて、回転数ごとにエンジントルクを測定する評価ですが、一通り、1000rpmから6500rpmまで測定し終えてました。あとはアクセル開度を緩めつつ、回転を落とし最終的には、アイドリング回転、ギヤをニュートラルにしてエンジンのIGキーオフでテスト終了するのですが、どこで間違えたのか、アクセルが全閉になっていない状態。つまり、ダイナモ側からトルクがかかった状態で回転が下がっていたのをアイドルと勘違いし、ギヤをニュートラルにしてしまいました。
結果は明白で、エンジンはオーバーランし、緊急停止が作動し、となったのですが、当時はキャブレター方式の燃料供給システムで、フロート室にあったガソリンが停止するまでに吸い込まれ、燃焼室で燃えない状態で排気系に流れ込み、キャタリスト(排気ガスを浄化するシステム)が真っ赤に燃えて解けてしまい、火災になる寸前まで至りました。その後、次の行動に移る前は十分状態を確認してから行うようになりました。
何事も挑戦してみる、行動してみる、ということです。当時は、キャブレター方式の燃料供給システムから、EGI、EFIなどの名称で呼ばれた、電子制御による燃料供給システムに移行する時期でした。電子制御(プログラムにより、デバイスを電子制御する)を理解できている人材は、エンジン開発を行っているメンバーにはいませんでした。
社内留学システムという制度があり、他グループに仮配属してもらい、そのグループの仕事を学ぶ制度がありました。私は、これからはプログラムがわからないと、狙った性能を引き出すためのデバイスコントロールができない。社外メーカーさん任せになり、マツダの独自技術が育たないと考え、この留学システムを活用し、当時、時代の最先端を行っていたエンジン電装開発グループに留学し、プログラムを基礎から学びました。その成果が現れ、電子制御デバイスをエンジンの要求に応じて、最適に制御できるようプログラムを作成できるようになりました。このことで、グループの業務がスムーズに効率よく行えるようになりました。
従来であれば、社外メーカーさんに要求を出してプログラムを作成していただき、それでエンジン性能を評価して問題が明らかになり、再修正していたところが、まず、自グループでプログラムを組み、評価し、問題なければメーカーさんに発注するというように、無駄な工程を排除できるようになりました。
男性、 フリーランス、 情報通信業・SE、 17年
現在、不動産会社の情報サイトのレコメンド物件の表示に関する処理を作成しています。サーバーサイドの処理を担当しています。言語はPythonです。その前は、某広告代理店の宣伝対象商品の顧客の購買情報の分析を行っていました。言語はPythonです。更にその前は証券会社の債権の収益計算システムの開発を行っていました。言語はJavaです。
上記のように挙げるとキリがないですが、ほぼサーバーサイドに特化しています。しかし、技術者として駆け出しの若いころはC言語で組み込み系の開発をしていました。ルータや携帯電話の基地局などを開発していました。私の経歴を振り返ると、非常に幅広くやっていたことが改めてわかりました。関わった業種も様々です(上記に挙げた以外ではEC、メーカー、旅行会社など)。
いずれは機械学習の案件に携わってみたいと考えています。
結論からいうと、本番障害対応の解析のチャンスを逃したことです。どういうことかというと、某通信系のシステムにて、原因不明の障害が発生した。対策として、次に発生した場合に解析できるような情報を記録するような機能を盛り込み、再現待ちとしました。そしてその後、障害が再発しました。これは原因特定のチャンスなわけですが、解析機能を盛り込んだことをすっかり忘れていた私は、あろうことかシステムの再起動を依頼しました(この解析機能で記録した情報は再起動すると消えてしまう仕様)。
後に、お客様からなぜ解析機能の情報を吸い出して解析しなかったのかと咎められました。そこから長い闘いが始まりました。開発環境で再現試験を何度も繰り返し、障害報告書を何度も書いて何度もお客様と打ち合わせをしました。これには膨大な時間を費やしました。
結局バグの原因は不明なまま、そのプロジェクトを去ることとなりました。この失敗を教訓にし、本番に限らず障害の際は可能な限りその状態を維持して、情報を吸い上げることに注力することとなりました。どういう操作をしたら発生したのかをまずヒアリングする。そしてログとデータベース・ファイルを収集し、画面キャプチャも取ります。そしてできれば一次解析も行って、原因がわかるまで現状維持します。一次解析をする時間的余裕がないのであれば、上記の証跡を収集した後に再起動します。以上が私の失敗談にまつわる話です。皆様の参考になることを願います。
結論からいうと、ある特定の分野で秀でたスキルを身につけるよりも、レベルはそこそこでいいのでたくさんの種類のスキルを身につけたことです。その理由は、世の中の動向がどうなろうとも仕事にあぶれなくなるからです。
まず、私の経歴を振り返って説明してみます。私のキャリアは2003年から始まり、C言語で組込系でした。ルータやら携帯電話の基地局やら世の中のインフラに関わる地味なシステムを作っていました。SQLすら使っていませんでした。それが7年くらい続きましたが、その仕事も収束し、次の仕事が決まるまで社内で3か月も空き要員として待機することとなりました。これは2010年頃の話ですが、つまり時代の流れが私のスキルを必要としなくなったということです。
その後、私は運よく次の業務が決まりました。当時としてはモダンな、Javaで業務系アプリの開発を行う業務でした。SQLもここで初めて使うこととなりました。これまでとは大きく違った業務内容であったため、キャリア8年目にして全てが戸惑いの連続でした。しかし、これを機に私は大きく成長しました。以降次々と仕事が舞い込んでくるようになり、ついにはフリーランスとして独立して大きく年収が上がりました。
しかし、ここで大きな転機が訪れることとなります。2017年頃から始まったAIブーム、時代はPythonで機械学習なのです。その頃、私はJavaでキャリアを積んでいていい気になっていましたが、危機感を覚えました。技術の流行り廃れは激しい。このままでは仕事にあぶれる。2010年頃の記憶がよみがえります。そこで、私は現状で手堅く稼げるJavaの業務系アプリ開発の案件を捨て、年収を大幅に下げてでも全く畑違いのPythonのデータ分析の案件を強引に獲得しました。そして今はPythonで修行を積み、機械学習の知識も付いてきて、大きく羽ばたける一歩手前まできました。以上の経験から、ある特定の分野を極めるよりも次々にその都度新しい技術にチャレンジするほうが、技術者としての寿命は長くなると確信しました。