MEMBER INTERVIEW

エンペイでCTOをやっています。

僕はtoBが好きで、自分が経験したことがないお客様の業務に燃えるタイプですね。笑

自分が使うプロダクトを良くしたいという欲も無くはないんですが、それよりも知らない業界(人)の不の話を聞いて、「こういうものがあると便利なのかな？」と考え想像しながら作ったものを、実際に利用して満足してもらうことにとてもやりがいを感じます。業務効率化のアプリケーションってお客様の業務フローと課題があって、それをプロダクトの機能で解決しにいくので、プロセスが非常にロジカルなんですよね。

好奇心が満たされることに楽しさを感じているんだと思います。お客様が何をしているのかをオペレーションレベルで把握する必要があるので、自分がやったことのない業務を紐解いていくのは楽しいですね。

エンジニアとして手を動かす、動かさないについてはあまり好みはなく、お客様に対して良い物を提供できるんであれば、その時にチームとして足りないところを自分がやればいいと思っています。

共同創業者でCEOの森脇さんからエンペイの構想を聞き、チャレンジしてみたいと思ったからです。

元々、自分が知らない業界の不を解決するプロダクトを、一から創ることが好きだったこともあり保育業界に特化したエンペイはとても魅力的でした。

森脇さんから話を聞いてからというもの、しばらくはお互い本職の仕事をしながら、朝とかに集まってプロダクトの構想をディスカッションしたりしていましたね。

しばらくやっているうちに楽しくなり、本当にやりたいことだと心から思えてきたので、前職を退職し、エンペイにフルコミットすることになりました。

ワークスアプリケーションズにて、会計システムのエンジニアを担当していました。

その後、リクルートに入社し、キッズリー、スタディサプリでエンジニア、プロダクトマネージャーをしていました。

エンペイのCEOの森脇さんとはキッズリーで出会い、一緒に働いていました。前職でエンジニアをやってる中で印象的だったのは、中国と一緒にやるプロジェクトで中国人と近い距離で仕事をした時のことです。

コンピュータサイエンスを学んだ中国人のスキルは本当に凄くて、１ヶ月くらいかかるんじゃないか、、、というものを３時間で完成させたりするんですよ。

そんな凄いエンジニアが何十人もいたのですが、当時色々と厳しいこともあり、プロジェクトとしてはあまり良い結果となりませんでした。

いかに個として優れていても戦略、チームなどが複雑に絡み合ってアウトプットにつながるんだと、色々考えるきっかけになりました。

複雑な問題をシンプルに解決できた時が嬉しいですね。

お客様がおっしゃっていることの根本を突き詰めていくと本質が見えてきます。表面的な問題を対応していると、枝葉のような機能ばかり出来て辛くなりがちなんですが、そこからさらに掘っていって抽象度の高い共通的な課題を見つけていく。で、そこを解決すると一網打尽にできて、「ああ、気持ちいい」みたいになる。プロダクトも綺麗に保たれて、みんな嬉しい、ってなる。

深堀りのポイントは一つで、「対話」です。顧客のことを一番よくわかっているのは営業やCS（カスタマーサクセス）なので、システムのことを一番よく分かっているのはエンジニアなので、どっちかの知識だけになっても片手落ちになるんですよね。プロダクトデザインは目に見える使い勝手以外にも、将来的な機能拡張性、統一性、コードベースなど総合芸術的な側面があると思っています。

それぞれ、それなりに専門性が必要なので100％把握しきるのは難しく、そこら辺のところをオープンに対話して、「ああでもない、こうでもない」と言って機能が出来ていくのが良いかと思っています。

プロダクトって、エンジニアがコード書くことによって作られてるじゃないですか。

過去に経験してきたプロダクトと比較しても、エンペイって今の売り上げ、ユーザー数に対して、めっちゃコード量が少ないと感じています。

機能が少ないとも言えるんですが、コード１行当たりが生み出す価値が高いと言える状態なので、そこがとてもいいと思っています。プロダクトの立ち上げ時、あれも欲しい、これも欲しい、ってなりがちなんですが、これは今やるべきではないと判断し断り続けて、本当に必要な物だけに凝縮されたものになっています。機能不足だとそもそも売れないということもよくありますが、エンペイはお客様にとって必須な業務であり、お金を払ってでも解決したい課題を解像度高く捉えることができており、そこを一点突破で解決しています。

前職では、そこで失敗したものが多いです。リソースがあったり、組織が大きくて情報の分断が起きて必要のないものまで追加してしまったり。基本的に一回作ったら消せばいい、と考えがちだけど、お客様に一度お使い頂いた機能を消すのは難しいし、そのうちに新たな要望が来て追加で開発をして、エラーが起きたら全てのメンテナンスをすることになり、どんどん機動力が下がっていくので、元から不要な枝を生やさないよう、エンペイでは特に気を付けています。

細かい部分では失敗しているところもあるんですが、全体的には上手くいっているなと感じています。

情熱、パッション、、すごく大事ですね。

あとは、「こうしたい」を持っている人。面接ではそのあたりを探るための質問を必ずしています。

エンジニアってすごくハイテクなことをやっているように見えるかもしれなんですけど、実際は伝統工芸の職人の性質に近いものがあって、めっちゃ手作業なんですよ。手作業でコード書いて、手作業でレビューして、手作業でチェックするみたいな。高度な物を生み出している裏側でやってることって、すごくアナログなんです。ってなってくると、コードに書き手の魂がこもってきます。

あとなんやかんやシステムって、自分たちでこれ作ろうっていうより問題を解決するため、要件を満たすために作ることが圧倒的に多いということもありますね。要件は基本的に外からやってくるのですが、どうせやるなら自分事化して、ちゃんと情熱もって、まごころ込めて作った方が良いものができるし、やっていても楽しいと思っています。

降ってきた要件を満たせばいいんでしょうという人と、何のためにやるのかを自分事化して、自分の作品を作るように情熱を持ってコードを書く人だと、瞬間瞬間でも差が出ますし、それが10年20年となっていくと埋まらない差になってくると思います。