みなさん、こんにちは。ネクストビートの堤です。

今回は、開発組織とリードエンジニアについて、複数回に分けて記事を配信する企画の第二弾となります。第二弾として、「KIDSNAブランドのプロダクトにおけるリードエンジニアの働き方」について、CTO衣笠と2名のリードエンジニアにインタビューした内容をご紹介いたします。

第一弾：開発組織の体制紹介
CTOとVPoEの2頭体制で開発を推進。事業やプロダクトの状況に応じた柔軟なマネジメント体制を

CTO 衣笠 嘉展
ヤフー株式会社、グリー株式会社、スタートアップのCTO経験を経て、2015年株式会社ネクストビート執行役員CTOに就任。創業間もない時期に入社し、エンジニア0名の状態から開発部の立ち上げ、「創りだす」を開発部のビジョンに据え、多くの新規事業の創出を推進。0→1の新規事業の事業責任者を歴任、KIDSNAブランドの立ち上げには特に注力してきた。

KIDSNAコネクト リードエンジニア 宇都宮英幸
大阪大学大学院卒業後、グリー株式会社に入社。ゲームのプラットフォーム事業に携わった後、スタートアップやアプリのトラッキングツールを作成している会社で経験を積む。社会的意義が高い事業に惹かれ、株式会社ネクストビートへ入社。

KIDSNAシッター リードエンジニア 川井淳矢
徳島大学大学院卒業後、徳島にあるシステム開発会社に入社。飲食店の顧客情報の統計分析や工場の稼働状況を監視するシステムの開発を行う中で、サービスを作りながら社会に対する自分の影響を実感したいと思い、上京と共に株式会社ネクストビートへ入社。2020年6月に開催された全社総会にて、上半期ベストクリエイター賞を受賞。

KIDSNAブランドのプロダクトにおけるリードエンジニアとは？

Q.今の業務内容やビジネスサイドとの関わりについて教えてください！

川井：僕はKIDSNAシッターの開発リードをメインで担当しています。KIDSNAシッターは、事業方向性が明確になり、それに耐えうるシステムへの刷新過程にあるプロダクトです。開発はもちろん、デザイナーやディレクターとの調整、CTO含めて技術負債に対して向き合い、最速で改善している段階です。

これまでの開発、運用の過程で明らかになった技術的な課題やオペレーションの問題を踏まえて、プロダクトの作り直しを行うための要件定義や設計に時間を使っています。デザイナーやディレクターと一緒に「どういうサービスにしていくか」「どういう使い勝手にしていくか」といった最上流の部分から携わってるので、自分が「こうしたい」という部分がプロダクトに反映されている実感があります。

宇都宮：僕はKIDSNAコネクトの開発リードを担当していますが、KIDSNAコネクトの場合も、ビジネスサイドから「これをやってください」という形で降りてくるのではなく、上流の部分から関わっています。

運用部分では、営業やCS（=カスタマーサクセス）のメンバーから上がってくる要望に対して、優先度をつけていくディレクションがメインですが、新機能の開発では、開発主導で調査、要件定義を行い、デザインまで落とし込みます。ただ、現場のニーズを最も把握しているのは営業やCSなので、部署間での連携が非常に重要です。

衣笠：KIDSNAコネクトの開発方針は定まっているので、市場のニーズに合わせて変化する開発のプライオリティを定期的にチェックすることが重要ですね。直近ですと、新型コロナウイルス感染症の拡大により、連絡系の機能需要が一気に上がりました。

プライオリティのチェックは、市場の動向等含め、経営企画側と一緒にシミュレーションを週次で行っています。もちろん開発側の責任者である宇都宮さんや、ビジネス側の責任者も参加しているので、自分たちが取り組む開発に納得感が持てる環境だと思います。

Q.各プロダクト開発における技術選定はどのように行われていますか？

川井：技術選定に関しては、衣笠さんに方向性を確認したら、リリースまでは責任を持ってやっています。特にJavaScriptなどのフロント系の技術や、アプリのライブラリで影響範囲が限られているものは、ライセンスや更新頻度、認知度を調査した上で、信頼感があるものであれば導入しています。

衣笠：そうですね。ただ、インフラ関連の新しい技術の導入に関しては慎重派です。AWSから出ているサービスをポップに使ってしまうことは、AWS提供サービス間の複雑性が増すことに繋がりかねません。ですので、可能な限り今の技術スタックの延長上で対応するようにしています。これは新卒や未経験が多い組織で、基本となる技術力のベースを上げていきたいという意図もあります。

また、開発効率化と社内のプロダクト・ローテションのために、プロダクト開発の基礎としてScalaとAngularを採用しています。基幹部分をできるだけ共通化することにより、プロダクト感のシナジーや車輪の再生産にならないように技術共有を大切にしてます。

宇都宮：僕もフロント系の技術に関してはポップに導入するものの、基幹部分は他のプロダクトにも横展開しているので、影響がでないかは慎重に考えています。

衣笠：一時期、SEOの関係でAngularよりも容量の軽いVue.jsを、Angularと平行して試験導入したことがありましたが、Vue.jsを長期的に扱うプロダクトが途絶えてしまい、ごく一部のサービスだけ使っている状態になり、最終的にはライブラリー自体のアップデートなど運用面で誰がやるのかなど人的な問題になってくるようになりました。

Angularもバージョンアップが頻繁 (3ヵ月使わないだけで...知らない仕様が出てくる) なのですが、幸いAngularに常に携わっているメンバーがいるため、キャッチアップなどが引き続きできている状態です。

そういった意味でも、技術の採用に関して、長期目線で考えた技術運用戦略を目線に置いて、導入を考えていくのが望ましいと思っています。

川井：技術の共通化が前提なので、自分の担当しているプロダクト以外のプロダクトコードをよく見ますね。8プロダクト全部見たかもしれません。下手なことをすると後々大きな技術負債になって返ってくるので、他プロダクトの良い部分は積極的に真似しています。

開発、CS、営業といった機能が全てインハウスだからこそできる、顧客ファーストの思考

Q.開発において大切にしていることを教えてください！

衣笠：KIDSNAブランドのプロダクト開発では、エンジニアとしての技術スキルやマネジメントスキルだけでは開発をリードするのが難しく、異なる職種の知識やメンバーとの関係性がとても重要です。

また、KIDSNAコネクトのようなSaaSビジネスだと、営業は代理店に任せたりCSをアウトソースする戦略もあると思いますが、ネクストビートの場合は事業運営に必要な機能がインハウス化されています。そのため、利用頂いているお客様との距離が近いのは、開発の方針決定や、創ることへのやり甲斐があり非常に嬉しいことです。私自身も機能開発に際して、機能の壁打ちをするために保育園に出向いてヒアリングを行ったこともありました。

宇都宮：ありましたね。また、CSや営業経由で実際の利用者にヒアリングの依頼ができるので、新しい機能の要件を考えるときに利用者の声を反映しやすいことも良いですね。

ネクストビートは、KIDSNAコネクト以外にSaaSビジネスのプロダクトがないので、様々な場面において、CSや営業と一緒に考えていく必要があります。何気ない会話の中でも、エンジニアだけの知識だと難しいと感じているので、営業に同行したり、他社のCSに関する事例を調べたりすることで、ビジネスサイド側の業務のキャッチアップを行っています。

また、自分は「週休3日制」なので、自分がいない日はメンバーがビジネスサイドからの問い合わせに答えています。メンバーであってもCSや営業のメンバーと直接話す必要があるので、自発性が身に付く環境だと思います。

川井：KIDSNAシッターもインハウス化されているので、同意ですね。KIDSNAシッターの場合は、社内に子供がいる社員が多いので、ユーザーの声が特に集めやすいです。最近だと、ベビーシッターを探す・選ぶ条件について社内アンケートを実施しました。

インハウスなので、納得できるまでコアコンセプトを詰めることもできますし、ある程度完成に近づいたタイミングでも、違和感があれば再度深く検討することができます。プロダクト全体の品質を考えたときに、細部まで妥協せずにこだわれるのは良いと感じています。

衣笠：インハウスにしている理由とも繋がりますが、開発において大切にしていることは、顧客ファーストな思考です。日常的に繰り返している業務だけど効率が悪い部分に対して、どうやったらエンジニアの力で改善できるかということを突き詰めながら開発に取り組んでいます。

顧客ファーストを第一に考えてはいますが、 BtoB,CtoCモデルビジネスに置いては、開発速度を最重要KGIにする考えは敢えてしたく無いと思っています。プロダクトを作ってリリースして終わりではなく、その後の運用こそが、非常に大切なビジネス構造だと考えています。

これまでの経験を踏まえると、新規機能を開発し、その後、技術負債になってしまった場合、改修時間にかかる概ねのコストを機能開発時間 × 2.5 と意識しています。技術負債を最小限に留めるため、各々の開発者が運用・保守などの振り返り時間に業務全体の何%を充てられるかを考えながら事業を進めることを意識しています。

そうしないと、BtoB,CtoCのプロダクトは新機能の開発が、技術負債により開発がストップする未来が容易に想像できます。技術自体を目的化することや、開発スピードの追及ではなく（効率化は必要と考えます）、長期的に安定して価値を提供できる顧客ファーストの思考をネクストビートのエンジニア文化として、今後も根付かせていきたいと思っています。