1
/
5

ポイントモールを0から開発したCTO加藤に、これからのEDOCODEに必要なエンジニア像について聞きました。

EDOCODE創立のきっかけとなったポイントモール事業は、2009年にグループ親会社であるWano株式会社の一事業として始まり、今では国内クレジットカード会社を中心に、10数社のクライアントにご利用いただく、大きな事業に成長しました。

今回は、現在のポイントモールシステムを0から開発したCTOの加藤に、システムの成り立ちをインタビューしながら、現在エンジニアチームが抱えてる課題と、それを解決するために会社として求めるエンジニア像を聞きました。

(聞き手:人事担当 山田響、文章:ツヅキ)

Perl人間が趣味で作っていたフレームワークがポイントモールのベースに

山田:
まずは加藤さんの経歴をもう一度振り返るところからでも良いですか?

加藤:
はい(笑)。経歴としては、前職の会社に大学卒業前に入社し、エンジニアとして当時はアフィリエイトシステム開発などを行っていました。

山田:
大学卒業前に就職ってできるんですね(笑)。

加藤:
なぜか卒業前の3月からがっつり働いていましたね。入社当時からPerlを使っていました。入社してから覚えたわけではなくて大学時代(1998年くらい)からPerlを書きはじめて。なのでPerlでの開発歴は20年以上になりますね。

山田:
ポイントモールのシステムは0からつくったんですか?

加藤:
そうですね。実は前職時代、趣味でWebアプリケーションフレームワークを作っていて、それをベースにシステム開発しました。

山田:
趣味で作るものなんですか、それ(笑)。仕事で使うため、とかではなく?

加藤:
そもそもプログラミングが趣味なんですよ。昔は24時に仕事が終わってから2~3時まで趣味のプログラミングをするという生活をしていました。平日だけでなく、土日もずっとやっていましたね。

当時、仕事でも趣味でもPerlを書きすぎて、考えたことをPerlのコードに落とすのに、思考する必要がなかったので、そのフレームワークもPerlで作りました。

山田:
もうそれPerl人間やん...。

Perl人間になるよりもっと前って、どんな感じだったんですか?最初はそんな熟練してるわけではなかったと思うんですが、そこからどうやってPerl人間ほどのスキルを持つに至ったのか、興味があります。今だったらYAPCとかそういうイベントもありますし、Perlのコミュニティもネットで存在がすぐに確認できますよね。

加藤:
大学生の頃、CGI MLというPerlのメーリングリストがあってそこにPerlに関する質問がバンバンきてて、それに答え続けたり、他の人の回答を見て調べたりしているうちにどんどん詳しくなったんですよね。分からないことでも調べて答えたりしていました。

他にもいろいろなPerlのコミュニティに所属していて、その一つのコミュニティがきっかけで前職の会社の副社長と知り合ったりしました。

山田:
Perlで人脈も築いていたんですね。

大きくなるビジネスを支えるのに必死だった成長期

山田:
ポイントモールを作り始めた頃の話をもう少し詳しく聞かせてほしいです。その時の開発メンバーは何人くらいだったんですか?

加藤:
僕一人です(笑)。初めは一つのクライアントのためだけのモールだったのですが、当初から一応他の会社にも展開できるようにすることを視野にいれて、汎用性があるプラットフォームとして作りました。その後、割とすぐにモールを導入したいという会社が出てきて、3社に増えましたね。

山田:
それを一人でこなしたとは…すごいですね。

加藤:
その時の課題はまさにエンジニアが一人しかいないこと。今だから言えますが、ポイントモールのリリースが2、3日ずれ込んだ経験もあります。そんな大事件もあって、複数人で取り組まなければならないと危機感を持ち、新たなエンジニアを採用してチーム化を目指しました。

しかし、その当時はmixiやDeNAなどの大手もPerlを使っていたためか、創業したばかりのWanoにジョインしてくれるエンジニアがなかなか集まらなくて。業務上、Perlの言語が使えることが必須条件だったのですが、テストをしても一行も書けないなんて人も多く、採用に疲弊していたことを覚えています。

山田:
エンジニア採用って大変ですよね...。加えて一人でシステム開発から運用まで対応していたのか...。それはしんどい(笑)。

で、それからポイントモール事業が軌道にのって収益も安定してきて、ポイントモール事業をWanoからスピンオフした会社としてEDOCODEができたわけですね。EDOCODEができた2016年頃は、エンジニアチームは何人くらいになっていたんですか?

加藤:
その頃には、Perlを扱えるエンジニアが6人くらいいました。分社化前後はまさに事業の成長・拡大期で、どんどんクライアントが増えてビジネスが大きくなり、それに追いつくためにエンジニアチームも大きくなっていきました。多い時は1年間に4クライアント増えた年もありましたね。人も増えましたが、それ以上に業務量も増えたので開発が大変でした。

山田:
業務が増えて人が増えると新たに課題が出てきそうですね。

加藤:
そうなんですよ。この成長・拡大期があったからさらに事業が成長しましたが、とにかくシステムを開発することに注力していたので、作ったのはいいけれど、開発したものがユーザーにとって効果的だったのか、ちゃんと使ってくれているものなのか、そういった検証ができていない時期でした。膨大な業務に追われていて、目先のことしか考えられず、長期的な目線を持ててなかったですね。

今考えると当たり前なのですが、システムを作れば作るほどメンテナンス工数もかかるので、業務がどんどん増えていくんです。また当時は、各々がシステムを動かすためにとにかく頑張って書く、書き方は問わないからとにかくシステムを開発して運用していくというギリギリの感じだったので、今見るとちょっとこれはよくないなというコードも残っています。あとそうやって限界のなかで作ったのに、全然ユーザーに使われずにメンテナンスコストだけ残ったものとかもありますね。

山田:
箱物行政みたいですね(笑)作ることが目的になってしまっていたのかな。でもサービスの成長期ってそんなものなのかもしれないですね。勢いだけで作ってはみたものの、活用できないものがたくさん残ってしまって。あとマンパワーだけでどうにかしていた時代って感じがすごいですね。いまのEDOCODEの社員からはほとんど想像できない光景かもしれません。

予定されるシステムのモダン化と、必要なエンジニア像

山田:
僕はだいぶ事業が大きくなった2018年に入社していますが、その時は採用を専任でやっている担当者がいなかったですよね。僕は事業側をやりたくて、というかやる気で入社したんですが、あの頃の採用はちょっと自分としても見過ごせないぐらいヒドかった(笑)そこでとりあえず応急処置だけでも、と勝手に採用について手直しを始めて、求人の内容から選考プロセスまで色々変えて、そうやっているうちに会社も採用に手をかけられるようになった、そんな時期でしたね。

あと会社のVisionやValueを決めたり、外国人採用を本格化したのもこの辺りですよね。それまで明文化されていなかった会社のカルチャーや方向性を経営メンバーで考えていったなと。

昔と今のエンジニアチームを比べて、何か変わったことはありますか?

加藤:
一番の変化は開発フローを明確化したことです。以前は同じメンバーで開発を行っていたのでフローをわざわざ明確にしなくても仕事を前に進められていましたが、ある時期にメンバーが一気にやめてしまって知識の断絶があったんですよね。

山田:
あぁ〜。僕がEDOCODOのカルチャーをドラスティックに変えすぎたんですよね(笑)。ほんとすみません...。でも、こういった危機が業務整理をするきっかけになって、チームとしては良い方向に進んでいると思っています。言い訳っぽいかもですが(笑)

今後予定している大きなトピックとしては、システムリプレースですよね?

加藤:
そうですね。ポイントモールシステムを作ってから十年以上経過していて、さすがにレガシーになってきているので、モダンなシステムに移行していく予定です。難易度が高いプロジェクトになると思っています。

具体的には、「フロントエンドとバックエンドを分ける」、「サーバー側でページをレンダリングせず、APIを呼んで表示する」とかですね。最近のフロントエンドはReactやVue.jsが主流ですが、Perlのテンプレートを使っている今のシステムとは相性が悪いんですよ。今はフロントエンドとバックエンドを分けたときに、どんなAPIが必要なのかをリストアップしたりしています。

山田:
これからジョインしていただくエンジニアの方には、そういったシステムリプレースのプロジェクトに関わっていただくと思うんですが、どういったスキルや経験が歓迎されますか?

加藤:
サーバーサイドでシステムリプレースを担当したことがある方、モダンなAPIについて知識がある方、さらにAPIを設計して実装できる方だと嬉しいですね。また、リプレースするシステムはPerlがベースなので、最低でもPerlを読めるようになってもらう必要があるかなと思っています。

あとは、まだ検討中ではあるのですが、移行先の言語にRust, Go, Pythonなどが候補にあがっているので、このあたりの言語の経験がある方だとうれしいです。さっきも言ったように、いまリプレースに必要な要素をリストアップしている段階なので、タイミングによっては、どういう仕様で実装するか、というところに関与していただけるかもしれないですね。

山田:
今のエンジニアチームって、技術的にはそんなに問題ないじゃないですか、事業をやっていく上で。なんですが、個人的にはもうちょっとリーダーシップをとれるタイプのメンバーがいてくれると助かるなと...。加藤さんは完全にスペシャリスト肌ですから。テックリード的な動きとか、できないでしょ?(笑)

加藤:
そうですね(笑)確かにテックリードがいると技術的なディスカッションがさらに進むし、プログラムについて勉強できる場面も多くなりそうですよね。

山田:
あと別に役割を増やしたいわけではないんですが、エンジニアリングマネジャー的なところに強みがある人が入ってくれると、これもバランスが良くなりそうです。加藤さんのようなスペシャリストに意見を求めつつ、ちゃんと実際的なところに落とし込んだり、技術的なトピックを調整できる方ですね。スペシャリスト、リーダー、マネジャーがいて、そこにジュニアな人が入ってくる。そういうバランスの良いチームを作っていきたいですね。まあ、これは僕の理想というか希望って感じですが...。

加藤:
そうですね。それと、スキルや経験はもちろん大事ですが、一番はエンジニアチームにもっと開発を楽しんでほしいなと思っています。

山田:
おお、なるほど。加藤さんはやっぱそこなんだ。そういう思いもあって、最近勉強会をやっているんですか?

加藤:
はい、システム開発はチームで行っていくものなので、プログラミングを楽しんでいる人たちが集まれば、スキルは後からついてくると思っています。エンジニアという仕事を楽しめる、そんなチームにしていきたいです。

EDOCODE株式会社's job postings

Weekly ranking

Show other rankings
Like EDOCODE 採用担当's Story
Let EDOCODE 採用担当's company know you're interested in their content