Employee interview

I&L QUALITYをつくる人03

TOP  >  I&L QUALITYをつくる人  >  I&L QUALITYをつくる人03

ソフトウェア開発部 ITエンジニア K.K

保守開発には「終わり」がない。
技術を掘り下げ、顧客に寄り添う。

ソフトウェア開発がやりたい。
不退転の決意で大学中退

ソフトウェア開発がやりたい。 不退転の決意で大学中退

 単位不足のまま大学生活4年目の終わりに差し掛かって――。

 岐路に立ったK.K.は「……学校をやめさせてほしい」と両親に告げた。卒業するためには留年しなければならないが、専攻を選び間違えたと思っていた。転科して軌道修正すると、3年生で取るべき単位から履修する必要があった。留年は1年ではおさまらない。半導体だの集積回路だのの授業には身が入らず、学業成績は惨憺たるありさまだったから、転科が認められるかさえ覚束なかった。

 どうしてもソフトウェア開発の仕事に就きたい。

 この4年間、授業そっちのけで、ゲームパーツやらSNSの専用ブラウザやらをつくることに熱中してきたが、その仲間の中にはソフト専攻の連中もいて、水をあけられたと感じていた。やりなおしに2年も3年も費やしている場合じゃない。ソフトウェア分野には、大卒ではない成功者もいる。学校はここまでにして、とっとと実践の場に飛び込むべきだ。

「だったら秋田の実家に戻れと親には言われたんですが、東京以外ではITの就職先なんてないでしょ?」

 アルバイトしていた飲食店の店長にも「学校はやめなくてもいいんじゃないのか?」と諭されたが、不退転の決意を述べたら、就活しながらのバイト継続を認めてくれた。この応援はありがたかった。今も感謝している。

ガシガシとプログラムを
書く仕事……じゃなかった!!

ガシガシとプログラムを書く仕事……じゃなかった!!

 それから半年後。K.K.は、I&Lソフトウェアに入社した。採ってくれそうな会社は他にもあったが、「3ヶ月の技術研修」に強く惹かれて、この会社しかないと思った。プログラミングにはそこそこ自信を持ってはいたけれど、所詮は自己流にすぎないという認識も持っていた。

 C言語の基礎から学び直し、ひたすらコードを書き続けて、徹底的なレビューの反復で鍛えられる研修。それを通じて、K.K.は、配属後の仕事に思いを馳せた。新たなシステム開発に挑んで、ガシガシとプログラムを書く仕事。学生時代に満喫したものづくりの楽しさを、これからもプロとして味わっていける……。

 だが、研修明けに配属された先で待っていた仕事は、イメージしていたのと少し違っていた。配属先は、保守開発チーム。

 人がいない深夜のうちに自動動作するバッチ処理プログラムが前夜に正しく動いたかをチェックしたり、サーバーの奥に溜まった不要なデータを定期的に削除したり、セキュリティパッチが配布されるたびに起きる軽度の不具合を解消したり、開発当時は見逃されていて最近顕在化したバグを取り除いたり……。

「……正直、開発をやりたかったですよね。保守がいやだというのではありませんが、プログラムを書いているほうがエンジニアっぽくないですか?」

 だが……と、K.K.も、頭ではよく理解している。

 コンピュータシステムがこれだけ普及した今日では、新規開発よりも、すでに稼働しているシステムの保守・改修のほうが、はるかに需要が高い。システム保守の卓越した技術は、社会的にも経済的にも、重要な価値を持っている。

他人が書いた古いコードを
スラスラ読み解く圧倒的な技術

「お客様の現場で動いているシステムの中には、他社が開発したものもあるわけです。何か起きたときには、それも診なきゃいけない場合があります。

 他人が書いたソードコードはただでさえわかりづらいものなのに、自分が不慣れなプログラミング言語で記述されていることも少なくありません。でも、先輩たちは、そんなものをスラスラ読み解いて、記号の羅列の中に隠れていたバグを苦もなく見つけてしまう。この芸当は、まさに圧倒的な技術力で、とても真似ができないと思ったものです。配属当時は」

 保守“開発”という言葉のとおり、この任に当たるK.K.たちの業務は、「壊れたものを直す」というのとは少し違っている。ハードウェアには故障もあれば経年劣化もあるが、物理実体がないソフトウェアは、ハードウェアのようには壊れない。問題なく動いていたソフトウェアに突然不具合が発生するのは、元々の想定から外れた何かが起きたせいだ。コードを読み解いていって、その何かに対応する“小さな開発”を加える。修理ではなく、つくり替え。あくまで“開発”なのだ。

「たとえば、Windowsベースのシステムなら、マイクロソフトから新たに配布されたパッチをあてたときに、それまで機能していたプルダウンメニューが使えなくなるといった障害が起こったりします。でも、コマンドを手入力して動くのであれば、そのまま放っておいて手入力での運用に切り替えるのも選択肢ではあります。しかし、パッチがあたって新しくなったOSに対応するプルダウンメニューを“開発”して追加する方法もありますよ、と尋ねれば、たいていの場合は、直してほしいと求められます」

 こういう“小さな開発”を、現場でどんどんこなす。

 もちろん、これがチームの売上になり、業績評価になっていく。

地道な作業と“小さな開発”の
積み重ねが大きな信頼につながる

「客先常駐していると、われわれが日常的に接するのはシステム部の方々ですが、その後ろには、営業部とか経理部といった“エンドユーザー”がいるわけですよね。全社的なシステムとは別に、各部門が自分の部署だけで使うシステムを自主運用することもあって、それをEUC(エンドユーザーコンピューティング)といいますが、システム部を通してEUCへの協力を求められることもあります。

 お話を伺って、Excelのマクロを書いてあげたりすると、おーっ!!と大絶賛されたりもします。1日か2日でできる“小さな小さな開発”ですけど、こういうことの積み重ねが信頼につながっていきます」

 他の部門も同じような課題を抱えていたとわかり、「それなら全社的な見直しを検討してみよう」という気運が生まれて、“大きな開発”の需要を掘り起こしたこともあった。

「保守開発は地道な作業の連続です。でも、システムが稼働している限り、終わりのないプロジェクトであり、ユーザーとのつながりも切れません。中身の濃い仕事なんですよ。……配属されたときは、地味な仕事だとも思ったけれど」

 大学卒業を諦めてまで貫徹した志に、やはり誤りはなかった。

 おそらく、きっと。

K.K

電気通信大学情報理工学部先進理工学科中退。
大学での専攻分野はハードウェア寄りだったが、課外で熱中したソフトウェアを仕事にしたいと方向転換。大学卒業を断念し、半年間の模索の後、2015年10月にI&Lソフトウェアに入社。
大口顧客のシステム保守開発プロジェクトに配属され、日常的なシステム運用、障害時の保守・改修、機能拡張のための開発……と幅広い業務をこなしている。

地道な作業と“小さな開発”の積み重ねが大きな信頼につながる

pagetop