「書くのです。とにかく書くのです。」
株式会社光通信 EパークFP事業本部 サービス開発・運用部
執行役員 和田俊弘

Pocket

Q:和田さんがプログラミングを始められたきっかけは?

 まだファミコンが出ていなかった小学校中学年くらいの頃に、自分でプログラムを組んでゲームを作って遊んでいたのです。それがプログラミングを始めたきっかけですね。 実は父が自動車関係のエンジニアで、仕事だけではなく趣味としてもコンピュータを使っていたので、物心ついた頃からコンピュータが身近な存在だったのです。まだマイコンが主流の時代でしたから、父は半導体を1,000個くらい買って、自分で一生懸命マイコンを組み立てていましたね。そんな環境ですから、私も小学校に入った頃から16進数を読まされていました(笑)小学校5~6年になってパソコンが出てきてからも、私はマイコンのほうが好きで、雑誌に投稿されているゲームのプログラムを打ったりして遊んでいました。そんなことをしていたので、コンピュータは誰よりも強い、超オタクだったのですね。ただ、コンピュータには強くなったものの勉学には身が入らず、大学受験は失敗してしまい、コンピュータの専門学校に入って本格的にエンジニアの道をめざすようになりました。

Q:その後はどのようなご経歴を辿られたのでしょうか。

 まず、専門学生時代に日立造船コンピュータ株式会社(現:日立造船情報システム株式会社)でアルバイトを始めて、卒業と同時にそちらに就職しました。コンピュータに関しては誰にも負けないという自負がありましたし、営業が受注してきた人事システムや勤怠管理システムなど、あらゆるシステムを率先して開発していました。プログラミングは好きなので、寝ずにプログラミングばかりやっていて、無理がたたって死にそうになったりもしながら(笑)残業代が基本給を上回るくらい働いていました。そしてちょうど当時は、海外のInteropや展示会などでは「時代はインターネットだ」「.comが流行っている」と騒ぎ始めていて、アメリカでYahooが出てきた頃でした。その流れに乗りたいと、社内でもインターネットを利用したサービスを始めようという話が出て1996年に作ったのが、ホテルの予約サービスである『ホテルの窓口』です。後の『旅の窓口』の原型になったサービスです。

 『旅の窓口』に携わったことは私にとって人生の転機の一つでした。それまで私はコンピュータ一筋で、電話も取らないし、営業なんて自分には関係ないと思っていました。でも、営業マンが出払っているときは私が対応することも出てきたのです。ホテル予約サービスの打ち合わせには、ホテルの支配人の方も多くいらっしゃるのですが、彼らは当然コミュニケーションにも非常に長けていますし、営業のノウハウをたくさん持っているのですね。その方々と色々な話をしていると、「なるほど、こういう風な振る舞いで、こういう喋り方をするといいのだ」と、マナーや話し方など多くのことを吸収できました。これはその後の人生においてとてもプラスになりました。
 もう一つの転機が、楽天トラベルとの合併です。1,000名体制での大規模開発をめざす中で、マネージメントというものを学びました。そこで、コンピュータが好きで、モノづくりに愛着を持って携わることができる人材の育成や、フレームワーク作りという目標ができたのです。

hikari_1

Q:その目標を光通信で実現しようとお考えなのですね。

 そうですね。今まさに光通信で1,000名体制を作ろうとしているところです。アイディアを実現するためには人手が必要ですし、多くの人間の意見を集約しながらモノづくりをしていきたいのですね。一人ひとりが考えて、自分たちで愛着を持てるプロダクトを作って、その商品が売れることがエンジニアにとってのステータスだと思うのです。今、SGS株式会社で「EPARK」というサービスを運営しているのですが、エンジニア全員が同じ方向を向いて「EPARKらしさ」というものを作り上げていけたらと考えています。そのためには優秀なエンジニアが大勢必要ですから、今はたくさん種を蒔いて、芽が出るのを待っているところですね。

 

Q:エンジニアの育成のために、具体的にはどのような取り組みを行っていますか?

 まずは採用ですね。「この人は3年後にどうなるか」という視点で採用しています。これは楽天トラベルでの経験則なのですが、例えば新卒を10名採用すると、そのうち1~2名は本当にセンスがある人なのです。そういう人が身近にいると、今は芽が出ていない人であっても1~2年かけて着実に成長します。今はハイリスクでも、3年後にはハイリターンが返ってくるのですね。ですから、即戦力になる人材を採用するのではなく、「育てる」ということを第一に考えた採用を行っています。

hikari_2

Q:優秀なエンジニアを採るのではなく、一から育てていくのですね。

 そうですね。正直なところ、優秀なエンジニアはITではなく自動車業界などに流れているのが現状です。なぜかと言うと、ITはまだまだ発展途上な業界だと思われているのですね。自動車業界にもリコールはありますが、技術力が高いので、そういうことへの対応も徹底しているのです。「日本のITは強い」「ITはかっこいい」と認めてもらわないと、優秀な人材がITに流れてきません。そのためにも、いいものを作れるようなフレームワークを築いていきたいですね。

 

Q:もの作りをする上で、どのようなことが大切だとお考えですか?

 やはり、自分が自慢できるようなものを作るということですね。商品を使ってくれたお客さんから「ありがとう」と喜んでいただけるようなものを作って、社会に、さらには世界に認められるというのはエンジニアにとって非常に嬉しいことだと思うのです。
 実は、私の最初のお客さんは父なのです。私が中学校に上がった頃に父が株に熱を上げ始めまして、株価のデータをすべて抽出してチャートにするというシステムを作ったのです。使っていくうちに要望が出てくるわけですが、それを反映させていくのが楽しかったですし、たくさん使ってくれたことがとても嬉しかったのですよね。その喜びは社会人も一緒だと思うので、より多くの人が喜んでくれるような商品を開発するために、しっかりと考えて、愛情を込めてもの作りに携わることができるエンジニアをたくさん育てていきたいと考えています。

hikari_3
Q:難しいとされるエンジニアの評価についてはどのようにお考えでしょうか。

 まずはコードをどれだけ書くかだと私は考えています。コーディングの量がエンジニアの基礎だと思うので、最初のキャリアステップとしてエンジニアに求められるのは質より量かもしれませんね。リファクタリングも含めて、書いたコードの量を実力とするのもエンジニアの評価としては「あり」ではないでしょうか。たくさんコーディングをして実力を身につけた後は、アーキテクトの提案やコラボレーションなどにシフトして、どれだけコードを書かないか、何行減らせるかということが求められるようになります。そこでどういうタイミングをもって評価するか、というのがエンジニアの評価制度としては面白いかもしれませんね。
 最終的には、エンジニアはマネージメントに進むか、技術のスペシャリストとしてアーキテクトに進むかという局面に立たされます。エンジニア一人ひとりが目指すキャリアプランを立ててステップアップしていけるように、現場寄りの情報システムの試験制度や、実力主義の開発のマニュアルなども取り入れていきたいですね。自分が進むべき道を示すためにも評価制度は必要ですから、これからも模索していきたいです。

 

Q:和田さんがマネージメントを選ばれた背景には、やはり事業の成功があるのでしょうか。

 そうですね。たまたま「旅の窓口」が成功したということもありますし、楽天トラベルでの大規模開発など、マネージメントに進むための境遇に恵まれていたということもあります。あとは、自分より才能があるエンジニアに出会ったことですね。もともとは技術のアーキテクトを志していましたが、『旅の窓口」をやっていた頃に「この人には敵わない」というエンジニアが現れたのです。本当にセンスがあるエンジニアは、アーティストのようにコードを書くのですね。音楽を聞きながら一気にコードを書き上げていて、そのコードを見たときは衝撃を受けました。私は学生時代から長く書くことが身についてしまっていて、簡潔に書くことができないのです。これはとても真似できないと思い、アーキテクトになるべきはこういう人なのだと痛感しました。

hikari_4
Q:今後の展望についてはどのようにお考えですか?

 エンジニアのための環境作りに取り組んでいきたいと考えています。今年は社内に開発のフロアを作りました。今後は人事制度をよりよいものに変更します。あとは、当社なりのスタイルの構築です。フルフラットにしてオープンにしてもいいですし、ボックスに囲まれて集中してもいいですし、皆の意見を取り入れながらより良い職場環境を整えていきたいです。技術を知らない人でもさまざまなことにチャレンジしてみて、自分が極めたい分野を見つけられるような環境を作るのが理想ですね。「こういうエンジニアをめざしたい」という目標ができると、本当に大きなことをやってくれるのですよ。

 

Q:最後に、エンジニアとしての活躍をめざす若者に向けてアドバイスをお願いします。

 若者はとにかくコードを書いてください。ひたすら書きまくるという経験が、将来必ず役に立ちます。あとは、人のコードをたくさん見ることです。人のコードから学んで書き続けていくうちに自分のスタイルが確立されていきますし、コードに対する「目」も養われます。「この人が書くコードはかっこいい」というのが、見ただけでわかるようになれば一人前ですね。それを自分でも書けるようになるかどうかが、アーキテクトとマネージメントの分岐点です。
 あとは、オブジェクト指向を意識することです。この考え方を徹底できるエンジニアは、1つのクラスにつき3行くらいでコードが書けるのでパーツそれぞれが本当にきれいなのです。それができる人はなかなかいないですから、これからエンジニアとして活躍したいという方は、ぜひオブジェクト指向を身につけていただきたいですね。

Pocket