• 大関 隆介 氏
  株式会社LEARNie CTO
• 中村 文明 氏
  株式会社Libry CTO
• 浅野 隆文 氏
  株式会社コードタクト VPoP

登壇者のご紹介

多様な形で教育の現場をサポートするEdtech企業

大関：
株式会社LEARNieのCTO、大関と申します。以前は株式会社ゆめみで40名ほどの開発チームの責任者を務めていました。私以外全員エンジニアで営業や売上管理、チーム作り、各エンジニアの評価などやっていて案件としては大手アパレルメーカーのグローバルアプリやファストフードのアプリ開発などを経て、2018年の4月からLEARNieのCTOとして参画しています。

当社は子供向けのオンライン英会話教室を運営していますが、実際には教育や人材・組織開発に特化したオンラインソリューションを開発しています。Zoomのようなオンラインのコミュニケーションツールを教育などに特化させたプロダクトをイメージしてください。具体的には、受講者の表情を読み取って感情を解析したり、参加者がどれくらい発言しているのかを可視化して講師にフィードバックするなどといった機能がありブラックボックスだったコミュニケーションを「見える化」しています。本日はどうぞよろしくお願いします。

【ファシリテーター】株式会社LEARNie CTO 大関 隆介さん

中村：
株式会社Libry（リブリー）のCTO兼TechLeadの中村と申します。大学在学中に現在の代表と出会い、学生ベンチャーとして起業して以来ずっとCTOを務めています。当時は教育現場にタブレットやPCが普及していなかったこともあり、事業を存続させるために、いたずらに組織拡大せずにほぼ一人でプロダクトを開発していました。その裏では日本マイクロソフトからの受託開発を請け負ったり、某大手企業の教育サービスのレコメンドエンジン開発にコンサルティングから入って携わったりと、さまざまな経験を経てフルスタックエンジニアになりました。現在はCTOとTechLeadを兼任しているということで、経営者と技術者両面の立場を担っています。

企業の目的は、日本の教育水準を高めること。学習履歴を分析することで、現在定性的に扱われている教育や学習をデータドリブンに進化させることを目指しています。そんな当社のリブリーというサービスは、学習者一人ひとりに個別最適化される学習特化型電子書籍プラットフォームです。教科書・問題集特化型のKindleを想像するとわかりやすいと思います。出版社に教材を提供してもらい、当社がデジタル化します。それを学校や中高生向けに販売を行い、出版社と売上を分配するビジネスモデルです。電子書籍を販売するだけでなく、問題を解いたら、「どの問題を、どれくらいの時間をかけて問いて、どうだったのか」という解いた結果が、学習履歴として保存されます。また、Libry for Teacherという先生用のツールでは、リブリー上で先生から生徒に宿題を出し、解いたものを生徒にアップロードしてもらうことで宿題の提出状況や正答率、その時のノートの写真を見ることができます。サービスは現在ほぼすべての都道府県で利用されていて、急成長中です。

浅野：
株式会社コードタクトの浅野と申します。CTOではなくVPoPという役職で、製品開発やプロダクト全般に関わる責任者を務めています。もともとはネットワークエンジニアとしてキャリアを積み、IPSでネットワーク構築をしたり受託開発案件を担当したり、専門学校の非常勤講師としてC言語を教えたり、フリーランスになったりと雑多な経験をしています。刺激を求めてベンチャー企業に転職し、2社目ではCTOも経験しました。その後は株式会社ZUUでエンジニアリングディレクターを務め、お誘いを受けて2年前に現職に入社。エンジニアが10名ほどの組織なのですが、全員フルリモートで仕事をしています。

当社のメインサービスはschoolTaktという授業支援システムで、学校の先生が授業を運営するための方策を立てるのに有意義なツールで、アクティブラーニングや協働学習を支援するものとなっています。具体的には、タブレットなどの端末でschoolTaktを使うことによって生徒が現在どういう課題にどのように取り組んでいるのかをリアルタイムで把握できるというものです。

【ご登壇者】株式会社コードタクト VPoP 浅野 隆文さん

技術紹介と技術選択理由

教材の電子書籍化にはブラウザ版の開発が必須だった

大関：
では早速パネルディスカッションに入りたいと思います。まずは各社の技術紹介と技術選定の理由についてお話いただければと思います。中村さんいかがでしょうか。

中村：
フロントの特徴は独自ストレージで開発していることと、ガワネイティブで実装していることです。リブリーというサービスを提供するにあたってはハードルが3つありました。1つはブラウザ版でなければならなかったこと。正確に言えば、アプリ版のみでは事業が破綻する恐れがあったことです。2つ目は、書籍の代替物ということでオフライン機能が無いと学校現場で使えないこと。3つ目は大容量のデータを扱わなければならない製品だということです。

特に前者２つについてご説明すると、1つ目は単純に言えば手数料の問題です。アプリ内で課金をすると、プラットフォームの利用料が発生します。最初に説明したとおり、当社のサービスは教材を提供してくれている出版社にも利益分配を行うため、アプリ版のみではほとんど利益が手元に残らなくなってしまう状況でした。そのため、ブラウザ版を前提としたサービス開発をして、アプリ版をビュアーアプリとして提供する必要がありました。

2つ目は、学校のITインフラが十分に整備されていなかったことです。学校現場も、クラス全員が授業の中で同時にサービスが使おうとすると障害が発生してしまう現場がありました。また、普段の学習で利用する教科書などをデジタル化しているため、Wifiがない家庭や帰りの喫茶店など様々な場所で利用できる必要があります。ですから、オフラインでも利用できるようにすることが必要だという判断になりました。

【ご登壇者】株式会社Libry CTO 中村 文明さん

新技術も採り入れながら、モノリシックなシステムの分離を進行

浅野：
当社のメインプロダクトであるschoolTaktは、Webブラウザがあれば利用できることを売りにしています。Webアプリケーションとしては一般的な技術スタックで開発しているのではないでしょうか。

ただ、もともとschoolTakt自体は、大学のIT未踏プロジェクトに採用されたリアルタイムなラーニングマネジメントシステムがもとになっています。当初からWebで開発されていて、かなりモノリシックな作りになっていました。そのため、モダンなアーキテクチャの採用やユーザーの要求にできるだけ早く対応しようとすると、古いコードを逐一紐解いて直さなければなりません。近代的なフレームワークとの整合性も良くないというデメリットが生まれているので、現在はフロントとバックエンドの分離を進めている最中ですね。

大関：
分離は一部が進んでいて移行中という状況ですか？

浅野：
いまはRailsのAsset管理の枠組みを使ってビルドされている部分もありつつ、それとは完全に独立してReactで作られている部分ももありつつという形です。裏側は徐々にAPI化していく中で、良さそうな新技術は適宜採り入れています。GraphQLも一度検討はしたのですが、結局Boilerplateが多くなりすぎるなどの理由で導入を断念。最終的に当社のCTO自ら、Railsのモデルの更新をリアルタイムにフロントへ伝搬できるGemを作りました。

大関：
自前で作るんですね！

浅野：
当社の場合はCTOの技術力が圧倒的で、週末プロジェクトで課題解決してしまうようなことがままあります。

大関：
ちなみにサーバーサイドの言語はなんですか？

浅野：
サーバーサイドはずっとRubyですね。今のところは問題ありませんが、パフォーマンスなどはあまり良くないので将来的には変更を検討することがあるかもしれません。インフラははAWSがメインです。他社と協業で進めているプロジェクトの場合はAzureなどを使うこともあります。

大関：
AWSとAzureを使うとエンジニアがお互い連携できない、ノウハウが共有できないといった影響が出てくることもありますが、その点は大丈夫でしたか？？

浅野：
その部分に関してはもともと私がインフラ得意だったということもあるので、早い段階からInfrastructures as Codeを実現しようと取り組んでいますね。

バイナリデータを多用するため、ネイティブアプリでの開発を選択

大関：
当社はメインプロダクトとしてMac及びWindowsのデスクトップアプリケーションを開発しています。サーバーサイドはGoとNode、frontendはVueで開発している所です。当初はElectronを使って開発することも視野にいれていたのでNodeも使っている形となります。

デスクトップアプリケーションを開発することになった経緯としては、まず代表から、「オンラインアプリケーションとしてZoomと同じ品質のものを作って欲しい」と言われたことから始まります。当時、エンジニアは私含めて3名しかいなかったので、かなり厳しくなりそうという話を代表ともして出来ることをやろうということにはなりました。

そこでまずは効率化を考えElectronでの開発を検討したのですが、代表のこだわりとしてグループレッスンをすることや表情・発言量の解析をするといった要素があり、バイナリデータを使う部分が多かったんです。サンプルアプリを作って検証していたのですが、複数人数を扱い且つ解析用の映像や音声データを送ったり画面共有をしたりということで負荷が高かったためElectronを断念してパフォーマンス・チューニングが行いやすいネイティブで開発する形になりました。MacOSはバージョンが上がるとカメラのアクセスに失敗する、Windowsは未だに7のシェアが高いことあとは開発できるエンジニアが少ないなど結構辛い部分もありますね。

スピード優先のスタートアップ企業が持つジレンマ

大関：
技術に関しての失敗経験はありますか？

中村：
アーキテクチャですね。一人で膨大な量をスピード重視で開発しなければいけなかったので、設計している暇がなかったんです。できた部分から組み上げていった形になっています。コード量が多くないのですべて見ればわかるようにはなっていますが、そもそもどのアーキテクチャが良くて…と吟味した開発はできていません。

大関：
スピード重視というのはスタートアップではよくあるパターンですね。ただ、それを続けると結果的に事業のスピードが落ちる事態にもなってしまいがちです。

中村：
まさにその通りで、なかなか乗り越えられていない部分です。

大関：
浅野さんはいかがでしょうか。

浅野：
具体的なテクノロジーやアーキテクチャによる失敗はありませんね。ただ、これもスタートアップによくある話ですが、トラフィック特性や需要を無視して組んだ結果としてシステムが立ち行かなくなるものの、メトリクスが無いからどこが問題なのかがわからないという状況はあります。一つひとつ手作業で紐解いていかなければなりません。そういったことをしなくてもいいように、現在はメトリクスを取れるようにしたり、アーキテクチャを一定にしたりしています。

リファクタリングの判断基準は事業メリットの有無

大関：
リファクタリングするときに何を更新するのかなどは人によって違うこともありますが、どのように決定していますか？

中村：
何を優先して進むかは提示しますが、基本的にエンジニアに任せますね。

浅野：
僕も完全に任せていますが、意図しないリファクタリングによって問題が起きると困るので、品質保証の方針をどうするかは最近話し合うようにしています。必要ならリファクタリングの観点などを聞きます。

大関：
なるほど。僕はエンジニアがやりたいリファクタリングと、事業スピードを速めるためのリファクタリングがあると感じているので、リファクタリングする時はそれが事業にとって良いかどうかも含めて判断しています。単純に新しいことをやりたいからという理由で実施してしまうと、今やらなくてよいリファクタリングという可能性もあるので、事業にメリットがあるかどうかも実施するための判断基準としています。もちろん、エンジニアが開発しやすいためのリファクタリングは事業にとっても良いことなのでそこは積極的にやっていきたいなとも思っていますが、バランスをみないといけないなと思っています。

費用対効果が高く、デファクトであることが採用技術の基準

大関：
ちなみに、今後使っていきたい技術はありますか？

中村：
GCPを使ってみたいですね。今はそんなにデータ容量が多くないのですべてMySQLですが、BigQueryでログデータを解析できたらと思っています。

浅野：
基本的に新しい技術は各エンジニアが個人で好きに触っていて、プロダクトに導入したいと声を上げる人が多い文化風土があります。なので、費用対効果を見ながら今をより良くしていくという部分にフォーカスして取捨選択していますね。個人的に重視しているのはインフラストラクチャーの抽象化や自動化によって、開発に注ぐリソースを高めることです。

大関：
僕はデファクトかどうかも確認しますね。言語を選ぶときもPHPを検討しましたが、PHPをやりたいエンジニアが減っている状況だった且つエンジニアからもやりたくないということだったので選ばなかったです。そのあたりをきちんと見ないと、すぐに技術が枯れてしまったりしますから。逆にデファクトだとわかれば、あとはエンジニアに任せる部分が大きいですね。ちなみに私自身はサクッとかけるのでPHPは好きです。

開発における課題とは

現在の開発手法が組織にマッチしているかの見極めが必要

大関：
第二部は開発手法に関してディスカッションしていきたいと思います。まずは浅野さん、開発における課題はどのようなものでしょうか。

浅野：
うちの組織は今スクラム開発を行なっていますが、スクラムはきちんと行おうとするとコストの高いフレームワークです。毎回のスプリント計画でこれくらいの粒度で進めていこうという話をするものの、優先順位をつけてきちんと整理できているかというと、なかなか難しい面があります。

重要な意思決定はプロダクトオーナーが対処しているので開発自体は進められますが、そもそもスクラムが我々に合っているのかどうかというところは再考しているところです。

大関：
浅野さんの組織はほとんどの方がフルリモートで開発を進めていますが、スタートアップのフルリモートも難しいイメージがあります。そのあたりは何か工夫をされているんですか？

浅野：
確かにフルリモートは難しいのですが、会社の初期からフルリモートを実施しているので、リモートに慣れている、リモートに自分を最適化することにモチベーションを持つメンバーしか所属していないというのは大きいと思います。リモート特有の孤独感があったり、雑談の中でアイディアが生まれるといった要素が無いのはデメリットですが、リモートを実施した企業にありがちな「リモートだからサボっているかも」といった懸念は特に無いですね。

大関：
しっかり仕事をしているかどうかはやはりコードを見て判断するのでしょうか？

浅野：
そうですね、基本的にアウトプットを見ます。アウトプットがない場合は働いていないのか、あるいは何か問題があるのかのどちらかですから、個別にケアします。あとはデイリースタンドアップに相当するものは毎日やるようにもしています。コミュニケーションは基本的にすべてslackですが、発言が無い日は何かあったのかと気にかけますね。

属人化・無人化によって生まれた負債を3年の長期計画で返済する

大関：
中村さんはいかがしょうか。

中村：
属人化と無人化が課題でしょうか。過去に社内向けの一部サービスの開発を委託したことがあったのですが、そうしたせいで内製しているサービスとは設計思想や技術が異なってしまいました。その結果、そのサービスを担当しているメンバーへ属人化してしまい、そのメンバーが辞めてしまったところ、サービス全体の見通しが悪く、補修が大変になってしまったんです。それでも機能の改善ははいるので、なんとかやりくりしながら、リファクタリングを進めていきたいと思っています。ただ、どうしても着手のしづらさから優先順位が下がってしまうのが問題点ですね。

大関：
どうしても変えていきたい部分に関してはどう進めていく予定ですか？

中村：
短期的な事業成長のための「新機能開発」と、長期的な事業成長のための「リファクタリング」を両立しながら進めていく予定です。リファクタリングについては、1年単位でどれくらい負債を返済できるかを綿密に考えていきました。来年までに何をしたいか、何ができるかを整理しているのですが、どうやら3年ほどのスパンで見る必要があるかもしれない、という話になってきています。今後、事業成長させながら積極的に採用も行なうことでリファクタリングをどんどん進められればと思っています。

【ご登壇者】株式会社Libry CTO 中村 文明さん

優秀な人材の確保を望めるリファラルへの期待

大関：
そうなると採用がキーワードになるのかもしれませんね。

浅野：
採用が一番の課題という点は当社もそうなのですが、非常に難しいです。僕自身も過去に何社かで採用に関わっているのですが、成功体験がありません。いい人が来ることはもちろんあるのですが、要因を考えるとどうも偶然だったりする。リファラルに力を入れていきたいとは思っているのですが、具体的な方策はよくわかっていないのが現状です。

大関：
うちのエンジニアはプロパーが2名に副業が9名ですが、ほぼリファラル採用です。僕自身がスポットメイトという会社のCTOとしても入っているので、その会社のエンジニアに紹介してもらうこともあります。一緒に働くと信頼関係を築きやすいので、あえて違うところで働いて紹介してもらうのは良い手法かもしれません。ただ、自分の労働時間を割くことになるのでそこはメリハリをつける必要があります。

リファラルは優秀な人が入ってきてくれるのですが、うちの場合はスタートアップだから社員としての採用ができないという別の課題がありますね。映像や音声データを扱うことに長けた人が少ないといったスキルの問題もあり、その点はアプローチが難しいところです。

【ファシリテーター】株式会社LEARNie CTO 大関 隆介さん

プロダクト導入のハードルとなる、学校側のITインフラ＆リテラシー問題

大関：
サービスを実際に学校に導入する際、クレームなどは頻繁に来るのでしょうか？

中村：
頻繁かどうかはわかりませんが、もちろんインシデントは発生します。ただ、クライアント側の状況がわからないことが多いので、ある程度あたりをつけて症状を再現して解決にあたることになります。これもなかなか対応しきれていない部分です。

浅野：
確かに学校サイドは全体的にITリテラシーがあまり高くないので、問題を報告されても必要な情報が含まれていないケースが多いです。「職員室では使えるのに教室だと上手く動かない」などとと言われても、「端末は同じなのか、ネットワーク経路はどうなのか、前提条件がわからないのでなんとも言えない」という返答になることはあります。現地に行けば「それは当社の問題ではないですね」という話で終わることも多いのですが。

大関：
うちも教育の事業者にツールを提供したら「全然動かない」と言われたのですが、確認したらデータ速度が1Mbps以下だったということがありますね。

浅野：
ブラウザ系だとプロキシも厄介ですね。通信がプロキシによって遮断されることがあります。特にそういう製品はWebSocketの挙動を正しく解釈しないので、普通に使えているのに同期機能だけが動かないといったこともあります。その場合はセキュリティ設定を見直してもらわないといけないので、保守業者に連絡してもらってホワイトリストに追加してもらうといった対応になりますね。

当社のメインクライアントは公立・私立の小中校なのですが、基本的に代理店が絡むんです。ですから今はあらかじめ代理店にお願いして、可能であれば動作確認を行い、さらにフィルタリングソフトウェアの導入状態も見てもらうようにしています。

大関：
そういった手間を考えると、日本の学校にiPadを普及させようとしても「流行しなさそうだな」と思ってしまいますよね。僕が聞いた話でも、iPadを導入しようとしても人数分の機器を充電する電源が足りないとか、ネットワークが弱くて良いツールがあっても使えないといった話は往々にしてあります。

質疑応答

教育業界へのテクノロジー導入で苦労した点は？

中村：
一番苦労したのは、まず学校現場におけるタブレット端末の普及を待つしかなかったことですね。それから、学校ごとにさまざまな端末が導入されているので、そこに対応しなければならないこと。私立はiPadが多いですし、国公立だとWindowsタブレットやSurfaceだったりと多種多様です。

浅野：
我々が授業のあり方を変えるために公立小中校をクライアントにして製品を導入してもらおうとすると、地方自治体による教育委員会の入札案件になります。そうなると、不思議な技術要件のRFPが出てくるんです。例えばブラウザを使った児童支援なのに、生徒がアクセスしているWebページの履歴をすべて先生が収集できるようにしてくださいといった内容です。

大関：
アプリケーションとは全く違う話になってしまうんですね。

浅野：
あとは、どうしても先生側にITを使うことに積極的ではない方というのはいて、そうなるとせっかく教育委員会に導入を決めてもらってもあまり活用してもらえません。どうすればよいか解決するのに苦労している最中ですね。

大関：
当社はまだ学校関係にしっかり参入してはいませんが、新規事業を立ち上げてから大変だったのは資金調達ですね。まだ日本においてEdtechをメジャーだと思っている人が少ないからです。そもそもEdtechはどこまで成長する分野なのかということから説明しなければなりませんでした。日本においてEdtechでユニコーン企業がいないというのもあります。Edtechで面白いことが出来ると認知されないと優秀な人もこないなというのも感じています。

【ご登壇者】株式会社コードタクト VPoP 浅野 隆文さん

リファラルでエンジニアを採用するメリットは？

大関：
一番のメリットは、あらかじめ能力のわかっているメンバーが入ってくるので、コミュニケーションコストがかからないことです。また、これは完全に経験則ですが、信頼している人が紹介してくれる人は大体優秀です。

中村：
リファラルだと、能力がわかっているだけでなく、カルチャーにフィットする人を紹介してもらいやすいですね。また、当社はエンジニアではないのですが、プロジェクトマネージャーや広報などでリファラル採用をしています。通常の採用だと役職の枠にとらわれず全社的に手広くカバーできるような人材を見つけ出すのは難しいのですが、最初から履歴書からはわからない能力や姿勢がわかっている人を採用できるのは、やはりリファラルのメリットですね。

浅野：
エンジニアの能力は面接のような短時間で評価できるものではないと思っているので、一緒に働いたことのある人の経験に基づく紹介だというのは大きいですよね。少なくとも、ツールや媒体から応募してきて、数時間話しただけの人よりはやはり信頼感が高くなります。

BIツールの導入によって生徒の成績が上がったというデータはある？

浅野：
そもそも生徒の成績や能力の向上をどのような観点で見ていくのかはなかなか答えが出せない世界です。実際、当社の代表取締役の後藤は、そういった部分での仮説を立てるためにも、いま現在大学院に再び入り教育心理学を学んでいます。

ですから現在は具体的なメトリクスはありません。我々が提供しているデータと先生の定性的な感想を付け合わせた上で、環境の変化を判断している状態ですね。

大関：
うちの場合、ツールの導入前はNPSが低かったものが、導入後は30％アップするといったことはあります。あとは発言量が少ない人に対してもっと喋った方がいい、あるいは喋るのが早すぎるといった指摘が入ることで改善されて、生徒側のNPSが上がるといったことも起きています。

というのも、これまでは先生がもっと喋ったほうがいい、あるいは喋らない方がいいといった指導をしていたと思うのですが、人の感覚なので明確な根拠が無いことも多いんですよね。そこをデータによって可視化できるようになったという点があります。今後もそれは当たり前のことになっていくのではないでしょうか。

浅野：
同じような文脈で言うと、我々の場合は生徒がお互いの課題にいいねを押したとか、コメントをしたなどのデータを収集しています。そういったデータをネットワーク分析し、孤立傾向にある生徒がいないかどうか。といったことを分析可能にしていきたいですね。

Edtech業界全体の課題とは？どのように改善していく？

中村：
学校や先生に余裕がないことが課題ですね。授業はもちろん、部活動や校務もあり、非常に忙しい中でICT化の対応をしなくてはならない。当然、先進的な先生も多い一方、やはり変えたがらない先生も一定数いるので、学校内のコンセンサスを得るのも難しい。ICT、Edtechを広めるためには、まずリブリーを普及させながら良い事例を広め、Edtechの導入ハードルを下げていくということだと思います。

浅野：
Edtechによって教育そのものや社会課題が解決された、あるいは解決される見込みがあるという大々的な話が現在はあまり無いんですよね。教育の現場で結果が出るにはまだまだ長い時間が必要になると考えています。一方で、先程の資金調達の話のように、今後Edtechがどれくらい大きなマーケットになるのか、何を改善してどうなっていくのかという見通しは必要になっていきます。その点はジレンマですね。

大関：
この業界で食べていけるかどうかは重要ですよね。もちろんやりたいからやっているという人もいると思うのですが、経営者は基本的にその市場にどれくらい価値があるのか、利益を生むサービスを作れるかどうかで見ているはずです。その選択肢の中になかなかEdtechは入ってこない。だからオファーもあまり無いという状況です。

浅野：
業界が活性化できないと、そもそも結果が出るに至るまでビジネスを継続できなくなってしまう。卵が先かニワトリが先かというような話です。

中村：
当社から出せる成功例をお伝えすると、全教科の教材をすべてタブレット一台に入れられるので、生徒にとって通学カバンが重いという問題は解決できます。そこは目に見えて「いいな」と思ってもらえるポイントだと思うんですよね。「学習成果がどうだ」という成果はどうしても出るまでに時間がかかりますが、こういう結果は、とてもわかりやすい結果だと考えています。学習という話とは全く違いますが。与えるインパクトは大きいはずです。

浅野：
日本の課題を一つ解決するという意味ですね。

大関：
去年、東京で開催したEdtechのサミットに訪れたのですが、エンジニアがいないことが衝撃的でした。つまり興味を持っている人の絶対数が少ない。まずはEdtechに興味を持ってもらって、この業界ならお金を稼げるという認識をしてもらわないと、なかなか参入してくれる人数も増えないのかなと思います。

そこをどうやって改善していくのかは、まさしく僕たちが今挑戦している部分です。今まで定量的に見えていなかった部分を可視化して、僕たちのツールがあるから授業ができるし、先生の質も良くなっていくという世界にしていきたいですね。

ただ、学校のネットワークが弱いという話にもあったように、業界自体がレガシーだという現実もあります。学校を変えていくのは、やはりすごく大変ですね。

【ファシリテーター】株式会社LEARNie CTO 大関 隆介さん

他のエンジニアメンバーに技術で負けないための情報収集・調査方法は？

中村：
負けてもいいんじゃないかなと思いますけどね。

大関：
僕もそう思います。うちの場合、僕よりコーディングが出来ないエンジニアは今は採用していません。僕は仕事の比重でいうとマネジメントの方が高くなっているので、コーディングだけでみると他のメンバーよりもスキルは低いと思っています。ですから負けないためというよりは、自分より優秀なエンジニアときちんとディスカッションするための勉強はしていますね。それに技術が多様化してして全てを一人でみるのは限界があるので出来ない部分は優秀な人に任せてしまった方が効率がよいとは思います。

あとは、役割的にもコーディングだけが仕事ではないのでプロダクトにとって何がベストかを考えて意思決定をしています。プロダクトや事業を前に進めることがゴールであってコーディングすることではないのでここは意識してやっていますね。もちろん、自分でコードを書いたりインフラ作ったりしないといけない場面もまだまだ多いのでそうゆう場合は自分でもやっています。

浅野：
僕も勝ち負けでは考えていません。エンジニアそれぞれにバックグラウンドや得意分野がある程度あるので、自分のスペシャリティを生かして仕事ができればいいと思っています。

大関：
情報収集の方法という意味では、優秀なエンジニアの話はよく聞くようにしています。食事にもよく行きますし、なぜこのアーキテクチャを作ったのか、どうしてこの設計にしたのかなど、とにかく質問します。前職のときは負荷試験やDB周りに詳しい人がいたのでたくさん質問してました。

そこは今も変わらなくてなんでこう作ったかや他の選択肢はなかったかなどたくさん質問しています。

浅野：
仲の良いエンジニアに新しいもの好きが多いので、新しいトピックが出てきたら日常生活の中で自然と話題に上ります。そこで情報収集している感じですね。

最後にflexyポーズで写真撮影をしていただきました。貴重なお話を有難うございました！

企画/編集：FLEXY編集部