目次
■おすすめ企業
2019.06.18 2023.12.14 約4分
「沖縄 ホテル」で検索すると、オーガニック検索で未だに1位を守り続けているikyu.com（2019年5月時点）。運営母体の株式会社一休は、Web業界では老舗といえる会社です。
社長と直接ディスカッションができる環境がある一方、技術的負債、レガシーシステムに対する相応の「覚悟」が求められます。
株式会社一休の所澤氏にWebマーケティング・新規事業の立ち上げ・マネジメントを経てエンジニアに転向した理由や苦労した点。現在の環境を伺いました。
――まずは、一休さまについてご説明いただけますでしょうか。
所澤 株式会社一休は1998年7月30日に設立し、2019年で21年目に入る会社です。主な事業は高級ホテルに特化したインターネット宿泊予約サービス、高級レストラン予約サービスの二本柱です。宿泊のほうはおかげさまで日本国内トップクラスの施設をカバーさせていただいており、高い認知をいただいています。高級レストラン予約のほうはまだまだ、これから成長させていこうというフェーズですね。
――所澤さんはどういったお仕事をされているのでしょうか？
所澤 私はレストラン事業本部に所属し、「一休.comレストラン」を開発しています。いくつかチームに分かれていますが、私が担当するのはユーザーが触る画面を作るフロントエンドです。UI・UXチームと社内で呼ばれており、ユーザーがより使いやすくなる機能追加などを行っています。
――今の部署にどのくらい在籍しているのですか？
所澤 2018年7月に異動して、10カ月ぐらいです。入社は2018年1月で、最初の7カ月は宿泊事業本部、その後はレストラン事業本部に異動しました。レストランの開発リーダーが退職したため、スライドした形です。
――開発環境としてはどんな言語を使われているんですか?
所澤 古いシステムと新しいシステムが混在しており、新しいシステムではサーバーサイドでPythonを、フロントエンドではVue.jsを使用しています。
――創業21年とのことですが、Webサイトもその頃からあったのでしょうか？
所澤 最初はオークションサイトを運営していたので創業当時からではありません。それでも宿泊予約サイトは18年になります。レストラン予約サイトのほうは後発ではありますが、それでもリニューアルを重ねて10年以上経過しています。
――長く運用しているサービスになると、技術的負債が気になりますね。
所澤 そうですね、いわゆるレガシーコードがある事で開発スピードが上がらない部分があるので、現在リプレイスを進めています。
――レストラン事業部に異動されてから、大変だったことはありますか？
所澤 レストラン事業部に関しては、開発よりはリーダーとしての文脈で苦労があったかもしれません。
開発リーダーとしてはエンジニアリングの能力だけでなく、ビジネス的にチームへ貢献できているかが求められます。われわれのKPIはCVRの改善、予約率を上げることです。集客は別にデジタルマーケティングチームがあり、SEOや広告を使って集客しているので。多くの人が訪れる中、どのぐらいの割合の方が予約をしてくれているかを意識しています。
ディレクターも別にいるのですが、各種数値の改善は私自身も考える必要があります。経営陣と定期的にディスカッションし、プレゼンをしたり、実際に結果に繋げる必要があります。プレッシャーもありますね。自分たちに何が足りないかビジネス的な観点から考えることができておらず、苦しかった経験があります。
社長からは「エンジニア的発想だね」と叱られることもあります。自分が開発した機能に発想が引きずられて視野が狭くなってしまったり、技術ありきで機能の提案をしてしまったり。もちろん機能追加は便利ですが、ビジネス構造やユーザー心理等を考慮したうえで課題にフォーカスする必要があります。そういうところで「もう少し頑張れ」と言われますね。
――ビジネスパーソンとして成長できる環境ですね。社長とフェイス・トゥ・フェイスでフィードバックを貰える環境は、そう多くないと思います。
所澤 社長と直接話すときは緊張しますが、ミーティングでは対等に扱ってもらえますし、経営戦略もオープンに話してもらえます。事業の数字についてはエンジニアに限らず全社に共有されており、風通しのよい環境だと思います。
――エンジニアである前にいちビジネスパーソンであり、売上にどう貢献するか常に求められる環境なのですね。
所澤 そうですね。ビジネスサイドなどもっと数字に追われている人は当然いますが、エンジニアでも「ビジネスに対して敏感になれ」というメッセージは常に受け取っています。
――続いて、所澤さんのキャリアを伺います。証券会社でリテール営業に従事された後、クラウドソーシング・メディア事業を営むMUGENUPさんに入社。Webマーケティング、新規事業立ち上げ、マネジメントを経験された後にエンジニアに転向されたと伺っています。
所澤 そうです、紆余曲折を経てエンジニアになりました。エンジニアに転向したのは、2016年ぐらいのことです。
理由は、自分自身の専門性のなさに焦りを覚えたからです。前職はスタートアップだったので、雑務でも何でもやらなければならない環境でした。また、創業間もない頃からのメンバーなので、「単に社歴が長くて色々なことを知っているから成果が出せただけなのでは？」という不安がありました。
キャリアを見つめ直した時、それまで趣味であったプログラミングを研ぎ澄まし専門的な知識を身に着けたいと思うようになりました。そこで、思い切ってエンジニアに転向しました。
もともとベンチャーに入ったのも、自分でWebサービスを作りたいと思っていたからです。自分で企画し、手を動かしてフットワーク軽く開発したい。何度も挑戦して止めてを繰り返しているうちに、「そろそろエンジニアになっても大丈夫そうだ」という感覚がありました。
――周囲はどんな反応でしたか?
所澤 歓迎してくれました。前職は専門職の人がたくさんいました。そういう人たちに「みんなを見ていて、自分も専門性を持って仕事したくなったんだ」と伝えたら共感してもらえました。
――エンジニアになって、最も苦労したところはどのようなことですか？
所澤 なにもかも初めてなので全体的に苦労しましたけど、技術的に困るということはありませんでした。勉強したらどうにかなりましたし、比較的新しいサービスを作っていたのでレガシーコードがあるわけでもなく、開発しやすかったです。
ただ、担当していた新サービスが軌道に乗らず、リリース3カ月くらいでクローズすることになってしまいました。「技術的に頑張っても、ビジネスがうまくいかないと無駄になる」と痛感し、「次はビジネスモデルがある程度できあがっている会社に」と思いました。それが今に繋がっています。
――今後、一休さんでどんな変化を起こそうと思っておられますか？
所澤 古いコードを新しくキレイにすることと、売り上げが上がる機能を作ることですね。自分が作った機能で、今まで以上にユーザーがサービスを使うようになった、アクセスするようになった、コンバージョンが上がった……そうなったら良いと思います。
――一休さんに入社されてから、一番印象に残っている事柄はどんなことですか？
所澤 レガシーコードの話なんですが、入社して間もないころに、ちょっとした機能の開発なのに3万行くらいのdiff（差分）が出る開発をしたことです。
diffが千行くらいになるとコードレビューが大変なのですが、それが3万行もあるんです。RailsみたいなWebフレームワークを使っていれば数百行で終わるような内容なのですが、レガシーというか少々作りが悪くて、「作り方次第でこんなに大変になるんだ」と思いました。
色々なインタビューでも話していることですが、面接では「ウチはレガシーだけど大丈夫？」って聞いているんです。改善が進んだとはいえ、覚悟を持たないと最初はつらいと思うので。
――状況を包み隠さずにお話いただけるのは一休さんでの就業を考える方にとって誠実だと思います。「どれくらいつらいですか？」と積極的に聞く方のほうが相性が良いかもしれませんね。
所澤 一方でカルチャーとして技術的負債を返していく、綺麗なコードを書くことが良しとされている点は、誇っていきたいところです。
余談になりますが、カルチャー以前に企業体力がないと技術的負債の返却はできないと思うんです。平たく言うと、儲かってないとできない。われわれの会社はきちんと利益を上げて、その利益をシステムの品質向上や優秀なエンジニアの採用に投資できている、投資をする余裕がある、それが非常に良いところだと思います。
――所澤さんが働くうえで大事にしていることは何ですか？
所澤 妥協しないことです。「愛せよ、さもなくば捨てよ」という言葉が好きで、これは「情熱プログラマー ソフトウェア開発者の幸せな生き方」（チャド・ファウラー著）という書籍に書いてあるフレーズです。やると決めたら、ちゃんとやる。仕事にちゃんと愛を持つということですね。
プログラミングを仕事、生きるための手段だと割り切ることもできますが、私の場合は好きになりたいので、休日を使って技術の情報を追いかけています。
――やるからには100％でやる、やらないなら0％やらない、ということですね。
所澤 なかなか難しいですが、そちらの方が良いと思います。「愛せよ、さもなくば捨てよ」なので、「やらない」と決めたらきちんと断れということでもありますね。
あとはドラッカーの本に書いてあった「神々が見ていると思って仕事をせよ」ということですね。誰も見ていないし適当でいいや、ではなく見えない部分も手を抜かない。プロフェッショナリズムを表しているな、と思っています。
普段の開発では必ずコードレビューを受けるので、誰も見ていないということはありませんが、本当に細かい場所までは見られていないので、ちょっとした妥協は見落とされる可能性があります。けれど、可能な限り自分が100％だと思えるものを出したい、10年後に誰かが見直したときに「ちゃんとしたコードだな」と言われたいですね。
書いたコードはgitで管理されているのでblameすると誰がコードを書いたのかわかります。つまり「このコードは読みづらいな」「キレイなコードだな」と思った時に誰が書いたのかわかってしまうのです。
――すべて残るんですね。
所澤 少なくとも社内ではそうですね。
――今のお話とも共通するところだと思いますが、ご自身の成長の為に日々行っている事はありますか?
所澤 「ひとり朝活」をやっています。早起きして7時に赤坂のスタバに行き、9時くらいまで勉強してから出社することを心掛けています。
――どんな勉強をしているのですか？
所澤 いまはGo言語を勉強しています。会社で新しくGo言語を使おうとしているので、有志が集まって、週一で社内勉強会をしています。練習問題をやらなければならないので、早起きしています。結局、自分のパフォーマンスが一番出る時間に勉強するのが一番だと思います。
――ありがとうございます。「エンジニアとして良い仕事をしたな」と思う瞬間はどういう時ですか？
所澤 自分の作った機能の拡張が、すぐに終わった時です。機能拡張は拡張した人より、ベースを作った人が優秀かどうかが大事なんですね。優秀な人は最初から拡張しやすいように作ります。なので誰かが自分がベースを書いたコードを拡張して、すぐに終わった時は「しめしめ」と思います。
――最後に「こんな人と一緒に働きたい」という思いはありますか？
所澤 プロフェッショナルな方と一緒に働きたいと思っています。繰り返しになってしまいますが、ビジネスでは、結果を出す事が大事だと思います。
一つは専門性を持っている人、もう一つはその専門性をビジネス的に使える人です。私自身も出来ていないので頑張らないといけないのですが、同じように考えられる人と一緒に働きたいです。技術バカでもダメですし、技術をないがしろにしている人でもダメ。ということですね。
――本日はありがとうございました。
ライター：澤山大輔
