「動けばいい」と「動かない場面まで想定する」　——新人プログラマーが知った、業務システムの掟

前回、銀行系SIのデータセンターで、怖さから始めた独学のマニュアル作りについて書きました。

あの経験の延長線上で、次にどんな決断をしたのか。今回はその話です。ITエンジニア・PMとして20年やってきた今の自分から見ても、この時期の経験は、仕事に対する向き合い方の原型になっています。

対象にしているのは、キャリアチェンジの成功パターンそのものよりも、「勢いだけで飛び込んだ人間が、その後どう困惑したか」に興味がある方です。スムーズな転身ストーリーを求めている方には、今回はあまり向いていません。

断った誘い、選んだ道

データセンターでの日々を送るうち、ある思いが強くなっていました。学生時代、卒業研究で地震解析システムを組んだときのあの夢中さを、もう一度仕事の中で味わいたい。プログラマーとして、腕そのもので勝負がしたい。そう思うようになっていました。

ちょうど同じ頃、学生時代の恩師が起業し、声をかけてくれました。当時メジャーになりつつあったJavaをメインに扱う会社とのことでした。ありがたい話でしたが、正直なところ、プログラミング経験自体がまだ乏しく、気が引ける気持ちもありました。何より、自分の中にはいつか起業するという漠然とした前提があり、まずは会社に属してプログラミングの腕を磨くことを優先したい気持ちが勝りました。恩師の誘いを断り、転職活動を始めました。

会社の規模も、給与も、正直あまり気にしていませんでした。とにかく「プログラミングができる場所」を探しました。

試験免除で入った理由

転職先が決まりました。とりあえずプログラミングができる、という基準で選んだ会社です。

後になって知ったのですが、この入社は異例の試験免除だったそうです。理由は、C言語が書けること、情報処理技術者試験の資格を持っていたこと、そこそこ名の知れた会社に前職として在籍していたこと。そして、新卒時代に新人研修を受け、社会人として一人前のあり方を一通り分かっているだろう、という判断もあったそうです。

今振り返ると、あの会社が見ていたのは、即戦力としての完成度ではなかったのだと思います。むしろ、独学で伸びていける土台と、社会人としての基礎的な振る舞いさえ揃っていれば、あとは現場で鍛えれば良い。そういう判断だったのではないか、と今は解釈しています。ただ当時は、そんな裏事情があるとは知らず、ただ運が良かったとしか思っていませんでした。「プログラミングができる場所に入れた」という手応えだけを感じていました。

その手応えが崩れるまで、そう時間はかかりませんでした。

趣味のプログラムと、業務システムの溝

自分がそれまで書いていたのは、正常に動く範囲だけをコード化したプログラムでした。想定通りに入力され、想定通りに動く。そこだけを見ていれば十分でした。

業務システムは、まったく違う前提で書かれていました。エラーが起きることを前提に設計されている。エラーを検知できること。そのエラーの内容によって、次にどう判断するかまで、コードの中に組み込まれていること。

「動けばいい」と「動かない場面まで想定する」の間には、想像していた以上の溝がありました。趣味で書いていた自分のコードは、いわば天気のいい日しか走らない車のようなものでした。業務システムは、嵐の日も、故障した日も、走り続けなければならない車です。同じ「プログラムを書く」という行為でも、見ている景色がまるで違いました。

具体的に困ったのは、エラーの「種類」でした。一口にエラーといっても、何種類もあります。それをどう検知させるか、どのエラーを拾うべきで、どれを拾わなくていいのか。この区別がつくようになるまで、しばらく時間がかかりました。

コーディングミスによるバグは、まだ分かりやすい方でした。見つければ、その場で直せばいい話です。厄介だったのは、それ以外のエラーでした。自分が携わっていたのは、装置に組み込むタイプのシステムです。エラーがソフト側で起きているのか、ハード側で起きているのか。その切り分けだけでも一苦労でした。

さらに、装置同士がやり取りする場面では、どこからどこまでを自分たちのシステムのエラーとして扱うのか、装置間のエラー判断領域という考え方そのものが、それまでの自分にはありませんでした。エラーを見落とせば、それがそのまま装置の誤作動や、お客さんへの実害につながる。分からないことをそのままにしておく怖さを、ここでも感じていました。

中でも厄介だったのは、再現できないエラーでした。一度きり起きて、同じ手順を踏んでも二度と出てこない。原因を特定できないまま、それだけで何日も時間を取られたこともありました。逆に、再現できたときは、なぜか嬉しくなりました。再現さえできれば、テストのしようがあるからです。エラー一つとっても、考えるべきことが山ほどある。それが、業務システムの世界でした。

たくさん聞いて、一から学び直す

この溝を埋める方法は、一つしかありませんでした。分からないことを、聞いて、調べて、書いて覚える。周りの先輩に、たくさん質問しました。必要になる言語は、その都度一から勉強しました。エラー時の対処法も、正解のパターンを覚えるというより、失敗しながら体に入れていきました。

学生時代、独学でC言語とフーリエ変換に苦労した頃と、やっていることの本質は変わっていませんでした。分からないことを、分かるまで理解する。その癖が、ここでも同じように動いていました。

常駐先のSEさんとの出会い

この時期、常駐先にいたSEさんに、たくさん質問をしました。技術的なことだけでなく、その人がプログラマーとどう接しているか、どう指示を出し、どう相談に乗っているか。そんなやり取りをそばで見ながら、少しずつ吸収していきました。今振り返れば、このときのSEさんの姿が、後年自分がSEとして、PGとどう向き合うか、どうコミュニケーションを取るべきかという像の、最初の軸になっていました。

社会人プログラマーとして、こうして一つ一つの溝を埋めていった時期。次は、この延長線上で訪れることになる、SEへの転換期について書きます。