「フロンドエンドはWebアプリケーションの中心地」　3社の技術領域の役員が語る、開発の進め方・働き方

一休の開発の進め方

司会者：次のトピックに行きたいなと思います。このあたりは説明をいただいた部分が往々にしてあります。

「ざっくり、どう進んでいますか？」みたいなこと（です）。あとは、とはいえレギュラーパターンや障害対応やissueが出てとか、偉い人案件みたいな突発（的）なものも、もしかしたらあるかもしれないし。ざっくり、どう仕事が進んでいるのかとか、仕事はどこから生まれてくるのかみたいな話。

技術スタックは（すでに）説明をしてもらったり、情報を探せば落ちていると思うんですけれど。そもそもその技術スタックというか、新しい技術の技術選定がどう決められるのか。CTOの鶴の一声なのか、現場からのボトムアップなのか。そこの意思がどう介在しているのかみたいなことを流れでお話してもらえればと思うので。

一休の伊藤さんからいきましょうか。お願いできますか？

伊藤：どこから（話して）いけばいいですかね？

司会者：上と下は違う話だと思っていて。（まず）仕事はだいたいどう進みますか？

伊藤：語弊がないように伝えたいんですけれど、一休の場合、仕事の発生はややトップダウン気味です。それは偉い人から降ってくるという意味じゃなくて、半年なり3ヶ月なり「この領域にフォーカスしようね」というところだけは、きちんと経営陣とプロダクトの人たちで握ることをけっこう大事にしているという点ですね。その上で「双方で握った内容に関してどう進めるか、何を作るかはチームで好きにやってください」という感じです。

ひとたび開発が始まると要件定義からリリースまでのフローはチームごとにけっこう違っていて、チームが好きに決めて良いようになっています。独立自治みたいな感じです。ただ、そこでチームがやることの内容までボトムで好き勝手に決めちゃうと（よくありません）。

例えば、それこそまさに今がそうですが、来週から地方自治体が主導する「全国旅行支援」が始まります。いわゆる昔でいうところの「GO TOトラベル」。こういうビッグプロジェクトにフォーカスするのは会社としてとても大事ですよね。こういうタイミングで「いえ、我々はこれがやりたいんで」とチームが自分たちのやりたいことを優先してしまうと、商機を逃しちゃうので。そういうのフォーカスをきちんと握って、それをどう作るかは本人たちが決めるという感じですね。

司会者：それでいうと、要件定義の手前は上から降ってくるけれど、そこから先に何をどう進めるかみたいな（権利の）ところは、基本的には現場チームにある。

伊藤：そうですね。

司会者：なるほど。ちなみに突発案件みたいなものはもちろんあったり（しますか）。

伊藤：ありますね。GO TOトラベルがその最たるものです。

司会者：なるほど。

伊藤：突然やってきてメチャクチャ大変みたいな。

（一同笑）

司会者：確かにそうか。なるほど。ありがとうございます。

メルペイの開発の進め方

司会者：泉水さんはどうでしょう？　フローの話はけっこう説明してもらっている気がするんですけれど。

泉水：そうですね。同じように案件がどうやって決まるかという話をすると、弊社もビジネスの大まかなディレクションみたいなものは経営の中で決まっていて、「それをどうやって達成していきましょうか」というところからプロダクトマネージャーが入って進めている感じになっています。それぐらいかな。聞いていて、やはり似てるなと思っています。

司会者：なるほど。

LINEの開発の進め方

司会者：じゃあ福島さん、LINEはどうでしょう？

福島：LINEはやはり事業ごとにぜんぜん違うんですが、カンパニー制度を取っているので、そのカンパニーの中でのやるべきことみたいなものが決まって、そこからそれぞれの事業ごとにいろいろなサービスの機能追加などが事業側のプランナーから企画が上がってきます。

それに対して、もちろんフワッとしたタイミングでエンジニアに相談がきてそれを固めていくという場合もあるし、ある程度プランニングのほうで固まった状態で「こういった開発がしたいんだけど」という相談がきてブラッシュアップしていくものもあります。

職能組織なので、僕らからスタートというよりかは、事業部からスタートして進めていくのが基本的なフローではあるし、その中で、事業やプロジェクトによって若干ウォーターフォール気味なものもあれば、アジャイルで進むものもあるという感じですね。

司会者：なるほど。ありがとうございます。

一休はどのように技術選定を行っているか？

司会者：ちょっと話を変えて、技術スタック。技術スタックの話はいいんですけれど、どうやってその技術をやろうとか。先ほどの話でも、いろいろなプロダクトがある中でもちろん違う技術を使っていて、それは誰が決めているとか。逆に言うと、現場というか、最前線で書いている方々が、どれぐらい意思決定に噛めるのかみたいなことを聞いていきたいんですけれど。伊藤さんはどうでしょう？

伊藤：やはり会社が小さいので、比較的個人技になっていますね。我々の場合は技術選定を決める明確なルールとか組織体があるわけではなくて、なんとなく新しいプロダクトが立ち上がる時にそういう話が好きな人がワイワイ集まってきて、「新しいことをやる？」「やらない？」とかを決めていったりとか。そこに僕がちょっと顔出して、「せっかくならこれでやってみなよ」で決まっちゃったりする感じですね。

司会者：じゃあヌルッとというか。決めたい人が声を出せばだいたいそういう方向に持って行けることも多いだろうし、伊藤さんみたいな感じの方が入っていって「せっかくだから」みたいな感じでもあると。

伊藤：そうですね。あとは日々会話しているとなんとなく「この人たちこういうことをやりたがっている」みたいなものが分かりますね。最近だとみんな「隙あらばRustを書いてやろう」みたいな雰囲気が出ているから、「じゃあ次に作り直す時にはRustでやってみようか」みたいな話はしていましたね。そういう日々の流れで決まっていきます。

司会者：プロダクトのためにみたいなところもあれば、先ほど言った社内組織やモチベーションのためにということも含めて、バランスを取りながら選定しているし、ヌルッと決まることが多い（と）。

伊藤：はい。

メルペイはどのように技術選定を行っているか？

司会者：泉水さんはどうでしょう？

泉水：これと言ってパキッと決まっているものはないんですけれど、やはり会社の規模が規模なので、ある程度のベースラインが前提としてあります。例えばバックエンドだったらGoとかDBでSpannerを使っていたりするし、メルペイのフロントエンドに関して言えば、Vue.jsとNuxtというスタックを使っていて。統一することで、会社内の流動性を確保するというのは一点あります。

さらに「他の技術にチャレンジしたい時はどうすんねん」という話があると思うんですけれど、それが先ほど言ったように「メルコイン側でこういう技術を使っている」というかたちで多様性を確保するといった工夫があったりします。

（新しい技術の導入については）「こういった技術で、こういうマイクロサービスを作りたい」ということはデザインドックを書いて、それを知見のある人がレビューをして、「じゃあそれでいこうか」という合意形成の仕方を取っていますね。

判断に迷った時、「エンジニアリング全体としてそれが中長期的に正しい選択かどうか」みたいなことで僕に意見を求められる時はありますが、僕をとおさないとだめということはぜんぜんなくて、普通にメンバー同士で決まっていることが多いと思います。

司会者：なるほど。ありがとうございます。

LINEはどのように技術選定を行っているか？

司会者：LINEの福島さんはどうですか？

福島：僕も同じで何もバキッと決まったことはなくて。

（一同笑）

福島：トップダウンで決まることは基本的に100パーセントないと思います。基本的には現場のメンバーが今の最適な技術を選択して、個人で勝手に決めるというよりかはチームの中で話し合って決まっていくものだと思っています。

司会者：それは、もちろんチームの中で序列があってマネージャーが決めているとかではなくて、新卒であろうが入ったばかりの方であろうが意見を出して、プロジェクトをリードするような立場の方で決めているような感じ。

福島：そうですね。チームの中でこれを採用しようと思っていて、他のチームですでに使っているのであればそこで意見を聞いてヒアリングして、プロコン（Pros/Cons）みたいなものをあらかじめ聞いた上で「どうしようか」と判断をしたりするかたちだと思います。

伊藤：先ほどの20年前との比較でいくと、細分化しちゃっていて、トップダウンとかでは決められないですよ。

司会者：プロジェクトの細かなところまで把握した上で、今後どういうことが起こりそうかも含めながら考えると、たぶん選択肢は無限にあって。それでいうと、本人たちのモチベーションや興味とかも汲み取ってあげると（なると）、「やはり本人たちに任せておいたほうがいいよね」というのが強い。

伊藤：あとは、やはり各技術、解像度が高く知っている人が決めたほうが当然良いわけですよ。トップダウンで決めると、どうしたってわからない領域があるじゃないですか。例えばクラウドサービスで何を使うとか、そういう大きな話はトップダウンで決めますけれど。フロントエンドの状態管理に何のライブラリを使うとか、新しいサービスのAPI設計はどうするかなどはある程度みんなに決めてもらう感じになってきています。

司会者：なるほど。ありがとうございます。

各社のデプロイ頻度

司会者：ちょっと1個前の質問というか進め方（の話）に戻るんですが、リードタイムやサービスのデプロイ頻度はどれぐらいでしょう？　これもたぶん「プロジェクトとかプロダクトのものによって違う」というのが答えだと思うんですけれど。

ベースのスパンというか、「早いものでこれぐらい、逆に言うと頻度があまり少ないものでいうとこれぐらい」みたいな、ちょっと幅を持って答えてもらってもいいかなと思うんですけれど。ざっくりどんな感じですか？

福島：2週間のスプリントを回してとか。

司会者：早いほうで？

福島：そうですね。

司会者：それくらい（のスパンですか）。泉水さんも頷かれていましたけど。

泉水：すでに出ている機能であれば、スプリントがだいたい2週間で、デリバリーはだいたい1週間単位でやっていたりすると思います。緊急でリリースしなければいけなかったら、そういうサイクルをある種無視してホットフィックスを切ったりすると思いますけれど。

司会者：なるほど。伊藤さんはどうですか？

伊藤：弊社はメインブランチにマージしたらほぼリリースしていいことになっているので、溜め込んで1週間に1回で出すようなことはむしろやっていないです。さっさとリリースして、もしバグが出たらすぐにまたリリースして直すという、わりとそういうやり方です。

司会者：取って出して取って出してみたいなことを繰り返す感じ？

伊藤：そうです。もちろん予約業務などお金に絡むところはもうちょっと慎重にやりますけれど、基本的には作ったらすぐその場で出して、1日10回デプロイみたいな。そんな感じです。

司会者：少ないということはない。むしろやはり頻繁で早い。

伊藤：早いと思います。ちょっと危なっかしいと思うこともあります。

（一同笑）

司会者：危なっかしいと思うか、楽しいと思うかですね。ありがとうございます。

LINEのリモートーワーク状況と、異動・副業の可否について

司会者：じゃあちょっと次に行こうか。質問もいろいろ溜まっているんですけれど、（話の）途中で触れるものもあるので。さっき質問にきていたやつ、いきますかね。

話がぜんぜん変わりますが、リモートワークは各社どうなっていますかというところで、エンジニアの方々がどのように働かれているかみたいなところ。

あと、（これは）先ほどの話と絡むのかな。社内異動とプロジェクトアサインはどうなっているか、あとは副業できるかみたいなものが来ていたので。

これは上から答えてもらおうかな。英児さんはどうですか？　LINEでのリモートワークはどうなっているか。制度としてどうなっているかと、フロントエンドの人がどう働いているか。

福島：はい。基本的にほぼリモートワークで、実際には（僕の部署は）数パーセントぐらいしか出社していないのかなと思っています。僕自身も、今年で2回ぐらいしか出社していない気がします。

例えばワークショップをやるとかの時はもちろん出社しますが、それ以外は基本的にはリモートでやっている人がほぼ（全員）だと思っています。

司会者：それはチームでの取り決めとかもあるとは思うんですけれど、個人の意思が大きいですか？

福島：そうですね。もちろん「チームとして出社して集まって何かやるぞ」という時は出社してもらうことが前提ではあります。

司会者：あとは社内異動やプロジェクトアサインみたいなところも、先ほどから聞いていると、やはり個人の自由というか個人の意思が尊重されている？

福島：はい。社内異動となるとまたちょっと違う制度が弊社ではあったりはしますが、それを話し出すと話が長くなる。

司会者：ちょっとならたぶん大丈夫です。

福島：社内公募制度というものがあって。これは純粋に、今いる組織からポジションをオープンにしている別の組織に異動したいと誰かが思った時には、上司や自分の組織にはまったく知られずに応募ができるんですね。

通常の選考フローと同じようなフローを通して、もし通ったら問答無用で異動ができるし、もしNGだったとしても誰にも知られずに、サラッとそのまま自組織で働き続けられる。そういった社内公募制度は別途あったりします。

それとは別に、チームの中での異動とか、組織内での異動は先ほどお話したとおり、その状況に合わせて柔軟にできる感じではあります。

司会者：先ほどからちょいちょい出ていますが、別にマネジメントをする方々も「俺のチームから絶対に出さないぞ！」というわけではなくて、「相談さえしてくれれば良いところ紹介するよ」みたいな。

福島：そうです。正直それで転職しちゃうんだったら、社内の違うところでバリューを発揮してもらえるのが一番良いというのはあります。

司会者：最後にスパッと、副業の可否。

福島：OKです。よほどバチバチやっているとかじゃなければ大丈夫だと思います（笑）。

司会者：（副業を）メルペイさんでやるとかだと止めるとは思うんですけれど。

（一同笑）

司会者：（LINEは）基本は上司や会社がOKすればみたいなことになっているかなと思います。

メルペイのリモートーワーク状況と、異動・副業の可否について

司会者：さて、メルペイさんはどうでしょう？　上からリモート（について）。

泉水：そうですね。リモートワークについては「YOUR CHOICE」という制度がメルカリグループには存在していて、これが「日本のどこからでも働けますよ」という制度になっています。「場所的な話だけじゃなくて、時間も自由にやってください。ただ、月の所定時間は働いてくださいね」という制度になっています。それを使って北海道から働いている人もいたり、週4日勤務でやっている人もいたりします。

その中で、個々やチームがどのようにパフォーマンスを担保するのか、例えばチームとの協調がちゃんとできているのかは当然各自に委ねられています。会社の中のプロジェクトの動きを無視することは当然止めてほしいんですけれど、基本的には個人の裁量に委ねられた働き方をしています。出社も強制的に求めることは今はしていません。

司会者：なるほど。社内異動だったり、プロジェクトの採用はだいたいお話してもらっていると思いますが、異動とかはどうなっているんですか？

泉水：異動は福島さんがお話されていたことと近いですね。異動したい意向を何でもかんでもすべて汲めるわけではありませんが、異動してもらったほうがその人のパフォーマンスが出るとか、組織にとって良いという判断がなされれば（異動できます）。

例えば、マネージャー同士が話をして担当VP同士が「これでいけるよね」という合意さえ取れれば。基本的にはそこに対してオープンな会社だと思います。

司会者：ありがとうございます。最後に副業は？

泉水：OKです！

司会者：それは多少は会社として見るし上司として見るところはあるけど、原則はOKみたいな感じですかね？

泉水：そうですね。そんなに厳しく見ていることはないと思います。

司会者：ありがとうございます。

一休のリモートーワーク状況と、異動・副業の可否について

司会者：一休の伊藤さんはどうでしょう？

伊藤：弊社もリモートでやっています。ただ、近頃は「週1回チームでタイミングを合わせてなるべく出社したら？」という話をしています。そこまで強制しているわけじゃないんですけれど。

というのは、コロナを一番よくわかっていなかった時期は完全にフルリモートだったんですが、やはり調子を崩しちゃう人が少し出てきちゃってですね。

調子があまり良くないことが、リモートなのでこちらからまったく見えなかった問題があって。「お互い健康ですよ」ということを確認することも含めて「週に1回ぐらいは会社に来てもいいかもね」という話をしています。エンジニアの人に聞いても「週1ぐらいは行ったほうがいいんじゃないですか？」という人が多いようで、そういう感じになっています。

（ただ）遠方からの仕事もできたほうがいいので、今は交通費は月15万円ぐらいまで支給するような感じです。要するに、例えば福岡に住んでいて（も）週1回会社に行きたいと思えば行けるようにしています。

司会者：（交通費の）15万円は確か法律か何かの支給できる上限で、LINEもメルカリグループさんもたぶんそれが上限になっているという話ですよね。

伊藤：そうなんですかね？あまりよくわかってないです（笑）。あとは社内異動やプロジェクトアサインも同じような感じですかね。弊社も社内公募制度があって、手を挙げれば異動の検討はできます。ただ、エンジニアで手を挙げた人は見たことがないです。ソフトウェアエンジニアに関してはそうではないもので決まっている気がします。

司会者：コミュニケーションの中で異動を決めていたりとか。

伊藤：1on1の機会なんかに「じゃあ違うチームに行ってみようか」という感じですね。副業は弊社もOKで、やっている人もけっこう多いですね。

司会者：ありがとうございます。そうですね。出社も、LINEも先ほど言った「何パーセント」みたいなことは、けっこうな頻度で来ている人とまったくきない人で、けっこうな頻度で来ている人がその数パーセントを作っているようなことが多かったりするので。わりと個人の意向に沿った働き方が3社ともできる。し。

福島：そうですね。人によっては出社したほうがパフォーマンスを出せる人が出社している感じだと思います。

司会者：そうですよね。僕は週5で会社に出社しているのでなんとも言えない立場なんですけれど。

（一同笑）

司会者：自分の意思でここにいます。

“フロントエンド”というキャリアにデメリットはあるのか？

司会者：さて、フロントエンドのイベントではありますが、どういう方向で知識やスキルを得ていったらいいかとか、幅を広げたほうがいいか、もしくは深めたほうがいいのかみたいな質問がチラホラきていたので、答え方は難しい部分がありつつ、良いトピックだなと思ったのでその3つを持ってきちゃいました。

フロントエンドに特化したキャリアを取ることのデメリットはあるのか。メリットに触れてもらうのもOKだし、あとは逆にフロントエンドを軸にもうプラスワンとか外の領域を求めるんだったら何が良いかみたいな話。

あと、フロントエンド自体で先ほどからお話してもらっているようにやはり移り変わりが激しいんですけれど、組織としてというか、個人的に「このあたりが大事なのは変わらないんじゃないの？」みたいなこととか、「このあたりがどんどん変わってくるから、これを追っておいたほうがいいんじゃないの？」みたいなことが知りたいよと。

下のは1個目と近いですね。領域が広くなる中で、特定のポジションやフロントエンドエンジニアによってさらに特化した募集であったり、スキルのロールを明文化することが進んでいるのかみたいなことは、細分化している・していないに関わらず、キャリアの考え方、振る舞いの考え方みたいなものをそれぞれお話してもらえればと思います。

もうちょっと時間もあるので1個ずついきましょう。まずはフロントエンドに特化したキャリアについて、みなさんどう思われますか。誰から振るのがいいんだろう。いけるよという方いますか？　じゃあ笑っていた伊藤さんからお願いします。

伊藤：（笑）。別にデメリットはないんじゃないかとシンプルに思いました。

司会者：むしろメリットというのも（説明するのは）難しいですか。

福島：フロントエンドやっている人は、基本ユーザーが実際に触るところや目に見えるところは作れるとか、作ったものがすごいわかりやすいとか、フロントエンドがやりたいからフロントエンドに行っている人が多いかなと。そこに対してのデメリットがどうかというと、それはどうなんだろうな。

伊藤：あまりない。というのは、もはや今はフロントエンドの領域がどんどん広くなってきていて、フロントエンドこそがWebアプリケーションの中心地だから。そこに特化するというのはむしろ中心地をやっているという感覚なのでそれで幅が狭いとか、そういう印象はないですね。

司会者：1個目の質問と3個目の質問のハイブリッドというか、そこがコアだから広がっていて。バックエンドとかデザインとか周辺知識はもちろんあったほうがいいし、何をかけ合わせてもたぶんキャリア的に間違いはないみたいなところはありそうですよね。

伊藤：そうですね。

司会者：泉水さんは？

泉水：そうですね。今直也さんが言っていたことに尽きるかなと思います。フロントエンドに寿命が来るとしたらWebの終わりな気がするので、それは少なくともないのかなと思いますね。

「広がり続けるフロントエンドで近接領域のどこに配分を置くか」みたいなところは確かにちょっと難しいというか。ベースラインとしては、Webスタンダードな技術、例えばHTML、CSS、JavaScriptで作ってブラウザの動きを理解して、Webアプリケーションを要件に応じて作れるところを中心に求めつつ、専門性の比重をどちらの方向に置くかですよね。

（スライドを示して）ここにあがっているデザインエンジニアリングみたいなところは、僕は実は解像度がそんなに高くなかったりするんですけれど。

弊社のソフトウェアエンジニアだと、ソフトウェアエンジニアというロールの中でデザインに近い領域のことをやっている人もいれば、バックエンド寄りのことをやっているという人もいる状況ではあります。

登壇者が最近関心を持っていること

司会者：ちなみに、みなさんの中で「個人的にこのあたりに興味を持っている」「メチャクチャやっている」とか、個人的に興味津々なところはあったりするんです？　そういう立場だと意外となかったり（しますか）。

伊藤：ありますよ？

司会者：お、例えば？

伊藤：私は関数型言語の厨二病みたいになっていますね。

司会者：それは何かきっかけがあったんですか？

伊藤：先ほどスライドでちょっと触れましたが、フロントエンドとバックエンドの技術的なパラダイムが離れ過ぎちゃって。それこそReactとかを書いたあとに「バックエンドを書くか」と言って書くとすごく書き味が違っていて、簡単に言うとストレスなんですよ。

「じゃあフロントエンドの世界は何がそれまでと違うんですか」というと、関数型言語の考え方が多少なりとも入ってきていて。それはフロントエンドやTypeScriptの世界だけでなくて、RustもそうだしSwiftもそうだし、最近の新しい言語は基本的に関数型言語から影響を受けていろいろな機能が入っているから、大きく見るとそういうトレンドに動いているんですよね。

恐らくバックエンドの世界がトレンドに乗っかってくるのが遅れていて、結果フロントエンドからトレンドが逆流してきているみたいな状態になっているんだろうなあと。そういうのを見定めるためにも自分はけっこうそっちに時間を使っている感じです。

司会者：なるほど。英児さんは何かあります？

福島：プレゼンの中でも話しましたが、組織として今はアクセシビリティみたいなところは僕ら全体として強く意識しているし、やはりLINE自体が広く使われているサービスだからこそ、いろいろな人が等しく情報にアクセスしてほしいし、されるべきだと思っています。そういった意味では一番そこに注力して、今やれていないからこそ、やっていかなきゃいけないところだとは思っています。

司会者：なるほど。ありがとうございます。泉水さんはいかがですか？

泉水：二人と違うことを言おうとして考えたんですが…、僕個人で言うとWeb標準技術、つまりWebそのもののケーパビリティが今はどんどん拡張されているかなと思っていて、それをうちの事業にどうやって活かすかみたいなところは個人的なテーマとしてやっていますね。

1つはFIDO（Fast Identity Online）。ヤフーさんとかが先進的に取り組んでいたりしますが、それをうちにどうやって導入できるかみたいなところ。もちろん事業上のシナジーもあるし、Web Paymentsみたいなところも、どうやって事業のメリットがある中で戦略に組み込んでいけるかを個人的なテーマとしてやっていたりします。

司会者：ありがとうございます。さて、予定の時間を迎えたのと、答えられていない質問もありますが、関連の質問は答えられた、お話できたかなと思います。

3社それぞれのアピールポイント

司会者：（スライドを示して）最後に、一番上にずっとある「3社それぞれのアピールポイントはありますか？」と。他の人の話を聞いて「俺もここを言っておかなきゃな」とかあるかもしれないんですけれど。

「こういうことをやりたい人はぜひうちに」みたいに、最後はしっかりアピールしてもらえたらと思うんですけれど。「自分からしゃべりたいよ」という方はいらっしゃいます？　準備ができたよという方はいますか？

福島：例えば面接とかこういった採用説明会みたいな機会でけっこうアピールするポイントとしては、LINEは本当にコンシューマ向けもあるし、法人向けのサービスもあるし、それこそデベロッパー向けのプラットフォームとかもやっているので、対象となるユーザーのバリエーションの多さみたいなものはアピールポイントなのかなと思っています。

司会者：そうですよね。プレゼンでも言っていましたが「LINEはモバイル（アプリ）じゃないの？」みたいなところが。

福島：そこがあって「Webでやっていることを知ってもらおう」という活動をこの3年から5年ぐらいすごく力を入れてやってきているんですけれど、まだまだ知られていないところがあるので。

よく見てもらうとWebも（やっていることは）いっぱいあるので、いろんなことをやりたい方とか、興味の幅が広い方にはおすすめかなと思います。

司会者：はい。メルペイの泉水さんはどうでしょうか？

泉水：はい。ちょっとしゃべったことの拾い直しにはなってしまいますが、事業的には「メルカリ」を土台にしつつ、決済とか与信などのシナジーをどうやって生んでいくかということに取り組んでいるので、そのあたりで事業的に興味がある人は一緒に働けるとおもしろいのかなと。

組織としては先ほど言ったように、ハードスキルとソフトスキルがある人が活躍できる。「ちゃんとエンジニアリングをやっていきます」というアピールはしたいなと思います。

司会者：なるほど。

泉水：あとはフロントエンドに関して言えば、福島さんも言っていましたが、品質の部分ですね。パフォーマンスやアクセシビリティ、セキュリティあたりのエンジニアリングの普遍的な部分だとは思うんですけれど、そこもちゃんと評価してやっていきたい。取り組んでいきたい。評価もします。ただ、今は人がいない感じです。

司会者：なるほど。ありがとうございます。そうですね。やはり作るだけじゃないというか、Webの品質を上げていくみたいなところは、規模が大きいサービスだから（こそ）貢献（できる）であったり「先にやらなきゃいけないよね」みたいなことは（あると思います）。

LINEもメルペイさんも一休さんも、社会からの要求も高まっている中で、どう先人に学んで作っていくかとか。事例の基準ができていないからこそ、やりがいがある気がします。そういったところは、メルペイさん然り、たぶんいろいろな会社であるのかなと（思います）。最後に一休の伊藤さんお願いできますか？

伊藤：一休の事業で特徴的な点としてエンジニアが事業に貢献しやすいというのがありますね。ビジネスモデルがとてもシンプルで、予約した人が増えれば会社が儲かる。ただそれだけなので、きちんとシステムを改善して予約に躓かない人が増えると、数字が伸びるんです。そこがおもしろいと思えると思います。

司会者：なるほど。要は自分がやったことが事業貢献とかに直結しているのがわかりやすくて、会社の成長・事業の成長が自分の喜びになるみたいな話ですよね。