見出し画像

なぜアセンドにプロダクトエンジニアが必要なのか

Niwa Takeru｜アセンド株式会社CTO

みなさん、こんにちは！
アセンドでCTOを務めている丹羽（@niwa_takeru）です。
以前の note では「プロダクトエンジニアとは何者か」というタイトルで話題に上がり始めたプロダクトエンジニアという職種について解説しました。今回の note では、「物流の真価を開き、あらゆる産業を支える。」というミッションのもと、物流業界向けにSaaSを開発しているアセンドがなぜプロダクトエンジニアを必要としているのかを紹介します。

アセンドでは、在籍するエンジニア全員がプロダクトエンジニアとして、仕様策定からフロントエンド、バックエンド、デザインまで、プロダクト開発フローに全体にオーナーシップを持って開発に取り組んでいます。この特殊な開発体制をとった背景には、アセンドが向き合う物流業界やプロダクト特性への最適化があります。

この記事では、アセンドがなぜプロダクトエンジニアという役割を必要としたのか、その事業背景と共に組織環境作りを紹介します。みなさんにはこの記事を読みながら、自社にもプロダクトエンジニアが求められるのでは、プロダクトエンジニアが活躍する環境をどのように設計するのかといった問いを持っていただければ幸いです。


物流の産業変革に必要な２つの挑戦

このままでは2030年には35%のモノが需要通りに運べない社会になる。
アセンドは物流業界のデジタル化を基軸として産業変革を目的として事業を創っています。 この社会課題を抱える物流業界のDXを達成するためには、「どのような開発組織が必要か」ということから逆算した結果、プロダクトエンジニアという役割に至りました。

物流は日本で最もデジタル化の遅れた産業である

事実として令和３年の総務省統計データでは物流が所属する運輸業のクラウドサービスの利用状況は他産業に比べて最下位であり、物流は日本で最もデジタル化の遅れた産業になっています。（総務省：令和3年版情報通信白書）
日本の物流品質は高くそれ故に企業間での価格競争力は低くあります。それ故に低利益体質でシステム投資力を持てず、荷主優位なために荷主システム都合で運送会社側は柔軟なアナログ業務を強いられて来た、社会構造的な問題によりデジタル化は遅れているのです。
一方で私たちの身の回りのモノは物流があるが為に届いており、私たちの生活と経済を支えてくれる欠かせない存在です。私はこの不合理な状況を日本のエンジニアの誰かが解かなければならないと考えプロダクトエンジニア組織作りに取り組んでいます。

物流産業のクラウドサービス利用率は全産業で最下位

運送会社は長年のアナログ作業により業務は複雑化しておりデジタル化をするためには業務を紐解く必要がまずあります。これはエンジニア向かいに言えばドメインの複雑性とドメインモデル整理の醍醐味がある領域と言えます。エンジニアとしては「技術的にどう作るか」よりも「プロダクトとして何を作るか」の重要性があり、ドメインに張るプロダクトエンジニアの必要性が高まっています。一般的にもBtoBや、業務系のアプリケーションを開発する場合にもプロダクトエンジニアの必要性が高いのではないでしょうか？

スタートアップでマルチプロダクトを立ち上げる

私たちがデジタルによる物流の産業変革を目指すにあたってフェーズ１として選んだのが、運送会社向けのオールインワンな業務SaaSを開発することでした。DXの根本として業務データの生成と蓄積が重要なこともありますが、産業変革という挑戦をする為に胆力ある開発力を必須と考え、スタートアップ初期だからこそ難しいプロダクト開発に取り組みました。　

アセンドのプロダクト「ロジックス」の５領域。

アセンドのプロダクトは配車・請求・労務・車両・経営分析という異なる５つドメインを扱っています。初期のエンジニア４名で同時に立ち上げをするにはプロダクトの開発生産性を上げる必要がありました。フルスタックやフルサイクルでの開発によりFour Keys的な開発生産性を上げることベースとして欠かせません。その上で重要なのは実際の運送会社の現場業務が回せる装着性高いプロダクトを迅速に作る必要であり、１日に何度もデプロイを行い素早く仮説検証を繰り返すプロダクトエンジニアの動きは欠かせません。

昨今のプロダクトマネジャー不足への対応も１つの背景にあります。顧客に刺さり事業としてスケールするプロダクトを作るにはマネジャーとしての役割は広くあります。ドメインへの理解を積み重ねてきたプロダクトエンジニアは顧客に刺さる機能・ソリューションの策定する能力を持っています。エンジニアがプロダクトマネジャーの一部役割を代替することで、プロダクトマネジャーの役割を一段上げることができます。ひとりのPMが複数のプロダクトを担当でき、また企業として影響の大きい事業のスケール方面で責務を持つことができるようになります。

特に事業の初期フェーズでコンパウンドスタートアップ的に、新規プロダクトや新機能を作りたい場合には、プロダクトエンジニアは企業ミッションを叶える上で強力な助っ人になるのではないでしょうか？

複数プロダクトを管掌するプロダクトマネジャーの立ち位置

プロダクトエンジニアが活躍する環境

私がCTOとなった2021年当時に上記の事業環境と戦略から、プロダクトエンジニアが活躍する環境が必要と考え組織設計を進めました。エンジニアがPMの代わりに仕様策定を主体的に行うことや、プロダクト開発のライフサイクルの全体にオーナーシップを持つこと、加えてこの２つが有機的に繋がった組織作りは珍しくありました。
記事をここまでプロダクトエンジニアの重要性に共感いただいた方に向けて、環境作りで何を大切に何の施策をしてきたかをご紹介します。

プロダクトエンジニアが活躍するための３軸

顧客課題を中心に広い領域に越境するオーナーシップを育てる

顧客課題を深く解く機能を作る為には課題に執着する人間が必要と、いきなり精神的な話になり恐縮ですが私はそう考えています。その上で、顧客課題に対して深く共感し、課題解決に関するプロダクト開発全体に対して一気通貫でオーナーシップを持てる環境作りを目指しました。

  • 入社オンボーディングにて各地域の運送会社に現場訪問を実施。課題だけでなく業務の周りにいる"人"を知り、課題解決の重要性を体感して火をつけること。

  • 仕様策定にエンジニア自身が主体的に関わること。上から降ってきた仕様ではなく自身が良いと意思決定した仕様を作ることで、失敗に対する適切な恐れと成功までやり続ける姿勢を作る。

  • フルスタックかつフルサイクルエンジニアとして開発に取り組む。自身の主幹でない領域を作らないことで、オーナーシップを途切れさせない。

顧客・ドメインへの理解を深め、イシューの本質を突く改善サイクル

装着性の高い機能仕様を策定する為には、顧客や業務を解像度高く理解していることが基礎となります。また SaaS を作る上では１顧客だけでなく、広範に業界としての抽象化された業務や性質の理解が必要となります。そのため１エンジニアが同じ機能領域を継続して担当し、改善サイクルの中で学習が生まれる環境が必要となります。

  • 顧客への課題ヒアリングをエンジニアも同席し実施。現地やオンラインで顧客の課題を幅広く聴き、詳細さを持って顧客課題を抽象化する。

  • １つの領域・機能に対しての継続して同じ担当者をアサインする。知識の属人化を過度に恐れず、属人的であれど深い理解を優先してドメインへの継続的な学習を進める。

検証スピードを早めるアーキテクチャと仕組み化

検証スピードを上げることでプロダクトを素早く提供できることもありますが、重要なことは短期間にフィードバックと学びの密度を高めることにあります。検証スピードを上げるための要点は、実装を早める開発力や即座に顧客に提供できるデプロイ機構があります。また迅速さを求めると当然のように失敗は増えやすいため、失敗の影響範囲を狭める機構があることも心理的安全性を作り、迅速さというカルチャーを作る上で重要です。

  • Full Stack TypeScriptでプログラミング言語を統一する。１エンジニアがフルスタック開発しやすくし、コミュニケーションコストと言語のスイッチコストを無くす。

  • トランクベース開発で小さく１日６回以上デプロイし顧客に価値提供をする。ChatOpsとGitOpsでのデプロイ機構を開発初期に投資して作り、気軽かつ迅速に顧客に提供する文化を作る。

  • Feature Flagでデプロイとリリースを分けて顧客への影響範囲をコントロールする。時には検証機能を一部の顧客のみに限定公開してユーザ体験ができあがっていない機能も先行検証をしています。

余談：組織作りはシステムで考える

上記のように組織作りのためにコンセプトとなる３軸を決め各種施策を実行しています。読んでいただいて気がつかれたと思いますが、各種施策が軸を超えて有機的に機能していることや、ルールといった意識的に守るアプローチではなく仕組みや構造を作って自然と意識が向くシステムを組織に組み込んでいます。
これは下記の「学習する組織」のシステム思考での考え方を組織作りにおいて重要視しています。ドラッカーのMBOのように固定的な目標を作ることが難しく、不確実性の高いプロダクト開発が必要な組織においてはイノベーションが生まれやすい「学習する組織」的なアプローチが有効だと丹羽は考えています。

プロダクトエンジニア組織へ昇華させる

以上のように、事業環境と戦略を捉えて１プレイヤーであるプロダクトエンジニアが少数精鋭で活躍する環境を作り、私たちのプロダクト・ロジックスはこのデジタル化の最も遅れた産業においてARR 1億円を超え、まさしく Product Market Fit を果たすことができました。

しかしながら、私たちが目指す「物流産業のデジタルによる産業変革」にはまだまだ足掛かりを作れた程度でしかありません。この大きな挑戦を実現するためにはより多くの人・仲間が必要であり、組織としての開発強度も高く保ち続けなければなりません。
この社会課題解決に共感し、共にプロダクト開発に挑む仲間を募集しています！

特にエンジニアリングマネジャーの方も積極的に募集しています。これまでのプロダクトエンジニアが活躍する環境作りから、より数段とレベルを上げてプロダクトエンジニア組織を作るフェーズにあります。技術的な挑戦を内包してプロダクト開発というスコープでエンジニア組織を作ることは日本でも類い稀であり、今後の日本のソフトウェア産業の生産性を上げるためには欠かせない知見がアセンドで気づかれると考えています。
CTO丹羽は組織作りに多分な思いはあれど、やらねばならなぬ経営的イシューは他に多くあります。このプロダクトエンジニア組織作りに共に挑戦するエンジニアリングマネジャーを募集しています！

■ エンジニアリングマネジャーの求人はこちら。

■ カジュアル面談はこちら。
　CTO丹羽がお話ししますのでどうぞお気軽にお申し込みください！

■ CTO 丹羽のSNSはこちら。


この記事が気に入ったらサポートをしてみませんか？