[エンプラ×Vertical SaaS開発]エンジニアとしてA1Aで5年以上挑戦し続けるわけ
初めまして、A1Aでソフトウェアエンジニアをしている住奥(すみおく)と申します。A1Aで展開しているブログリレーのバトンを受け取り記事を書きます。他のメンバーの記事も面白いので、お時間がある時に見ていただけると幸いです。
まず、簡単に経歴を紹介いたします。2015年4月より新卒で大手企業向け人事パッケージアプリケーション開発に携わり、2018年1月からはITスタートアップで領域特化のCtoCフリマアプリ開発を経験しました。その後、2019年7月から現職のA1Aでソフトウェアエンジニアとしてアプリケーション開発を担当しており、現在はUPCYCLE開発のリードエンジニアをしております。
本記事では、A1Aで5年以上働くエンジニアの視点から、
エンプラ×Vertical SaaS開発の難しさ
プロダクト組織が大切にしていること
A1Aにおけるプロダクト開発の面白さ
をお伝えできればと思います。
エンプラ×Vertical SaaS開発の難しさ
A1AのプロダクトであるUPCYCLEは製造業の大手企業かつ調達購買部門のお客様にターゲットを絞り、そのお客様の本質的な課題を解決していきます。
なぜA1Aが上記の方針をとるのかについては、代表の松原の記事を参照いただければと思います。
いわゆるエンプラ×Vertical SaaSのプロダクト開発にあたるのですが、この領域におけるプロダクト開発には次の3つの難しさがあると考えます。
より深い課題を定義・解決することが求められる
UPCYCLEがターゲットとする製造業の大手企業様では各社異なる形で高度な分業や複雑な業務が行われています。そのため、汎用的なサービスでは一定の効率化しか出来ず、本質的な課題解決が難しくなります。
その状況下で、UPCYCLEは特化したVertical SaaSとして汎用的なサービスではなし得ない課題解決を実現しようとしています。そのために、高度な分業や複雑な業務をより深く理解し、各社共通の本質的な課題を定義・解決することが求められます。
推進者・決裁者と利用するユーザーで求める価値が異なる
UPCYCLEがターゲットとする大手企業様では、実際にプロダクトを利用するユーザーと、推進者・決裁者が異なることが多いです。
実際にプロダクトを利用するユーザーは自身の日常業務が効率化されることを求め、推進者・決裁者は調達購買部門がより成果を出すことを求めます。そのため、フィードバックを分析する際には「誰」が「何のために」を履き違えないように気を付ける必要があります。
また、フィードバックは推進者経由でいただくことが多くなります。この場合、ユーザーの意見として記載されていても推進者の考えが入る場合があることも分析を難しくします。
施策の結果が出るまでのリードタイムが長い
先述した、実際にプロダクトを利用するユーザーと、推進者・決裁者が異なる影響として、リードタイムが長くなるという難しさがあります。
商談においては、情報システム部門やDX部門の構想との兼ね合いもあるなかで、ステークホルダーが多く、導入検討プロセスが複雑になるため、リードタイムが長くなる傾向にあります。
また、プロダクトにおいては、機能追加があっても実際にユーザーがすぐに使えない場合があります。部門で運用ルールが定めされている場合、部門のルール変更が必要になるケースがあります。
このように、施策の結果が出るまでのリードタイムが長い傾向があるため、施策の評価が難しくなります。
プロダクト組織が大切にしていること
ここまでで、UPCYCLEの開発における難しさを挙げてきました。これに対応するためにプロダクト組織が大切にしていることを紹介します。
成功すると思ってやりに行く
「検証自体を目的としない」、「検証の質を高める」と言い換えても良いかもしれません。
検証の目的に対してミニマムに実装し、検証のサイクルを多く回すことが基本になります。しかし、細かく検証することにこだわり、検証自体が目的になってしまうと、検証後に次のアクションどう繋げるかわからなくなってしまいます。
また、UPCYCLEのターゲット特性に起因して、施策の結果が出るまでのリードタイムが長くなる場合、検証の回数が限られます。
そのため、次のアクションに繋がるよう「成功の定義」を明確にすることが重要になります。成功の定義を明確にし、成功すると思ってやりに行くことで、検証の成否が判断できます。また失敗の場合にどうやったら成功になるかを検討しやすくなります。
実際に動くものを早い段階で作る
UPCYCLEのプロダクト開発では、世の中にまだ解決策がない課題に直面することがざらにあります。この場合は他のプロダクトは要素ごとに参考にするしかなく、全体の要件が十分か不安になることがあります。
この場合、画面デザインを利用してユーザーインタビューをするなど、検証の手段はいくつかありますが、実際に動作するプロトタイプを早い段階で作ることが多いです。
世の中にまだ解決策がない課題の場合、検討中の解決策によって本当に解決されるかのイメージが難しくなります。このため、具体性の低いデザインを利用したインタビューでは、ユーザーが実際の業務で利用するイメージを持てず、検証しても結局わからないとなってしまう場合があります。
そこで、より具体的なプロトタイプが有効となります。チーム内においても、ドックフーディングを通して要件を具体化できます。ユーザーへの検証に対してもプロトタイプ利用することで、ユーザーも業務利用のイメージを持つことができ、より具体的なフィードバックが得られます。
プロトタイプであっても実装の時間はかかります。そこに対しては次の「ユーザー価値を早く提供する」の考え方が重要になります。
ユーザー価値を早く提供する
エンジニア観点でユーザー価値を早く提供するには、課題を解決する要件を最速で実装する必要があります。このためには、要件を早く実装するのみでは不十分と考えています。PdMやデザイナーが要件を決める上で、現状のシステムを考慮した要件を作成することは難しいためです。
エンジニアはそれを補完するために、要件の背景を理解し、システムの制約を踏まえ「課題を解決できる、かつ最速で実装できる要件」を提案することが重要になります。
対話を大事にする
前述したプロダクト組織が大切にしていることの土台として、「対話を大事にする」というA1Aの文化があります。明文化していないですが、メンバーが大切にしているものです。
この文化の元となった出来事をCTO佐々木が記事にしています。贔屓目なしに面白い記事だと思うので、ぜひご覧ください。
A1Aにおけるプロダクト開発の面白さ
ここまでで、A1Aにおけるプロダクト開発の難しさと大切にしていることを紹介しました。これを踏まえ、A1Aで5年以上働くエンジニアの私見として何が面白いかを紹介します。
よいものづくりが事業貢献に繋がる
A1Aの事業領域はよいものづくりが事業貢献に繋がりやすいと考えています。エンプラ×Vertical SaaSの特性として「ターゲット顧客が多くない」があります。この特性により、お金とスピードのビジネス面のみで勝負が決まりにくいと考えています。
例えば、資金が多い企業においては人海戦術を取ることができます。しかし、ターゲット顧客が多くないため人海戦術をとってもすぐに顧客数は頭打ちになります。そもそもエンプラ営業は難しいので、質を伴わない人海戦術では顧客数が増えないかもしれません。
また、ターゲット顧客が少ないため1社あたりの単価を増やすことが重要となります。そのために、プロダクトは本質的な課題を定義・解決し、顧客に大きな価値を提供することが重要になります。
このようにA1Aはエンプラ×Vertical SaaS事業であるからこそ、よいものづくりが事業貢献に繋がります。また、A1Aとしても業界の課題を正しく解決することを掲げており、よいものづくりができる環境であると感じています。
最後に
ここまで読んでいただきありがとうございました。エンプラ×Vertical SaaS開発の難しさや、プロダクト組織が大切にしていることはもっと具体的に書ける余地があるので、また別の機会に記事にできたらと思います。
A1Aのプロダクト開発は、エンプラ×Vertical SaaS開発がゆえに複雑で難しいですが、だからこそ面白いし、5年以上も飽きずに挑戦しづつけることができていると感じます。
製造業の大手企業かつ調達購買部門に絞っているがゆえに、業界知識が重要と思われるかもしれません。もちろん、業界知識は助けになるのですが、それ以上に重要なのは興味を持てること・学んでいけることだと考えています。今のA1Aメンバーも業界経験がない状態から製造業・調達購買部門をキャッチアップしながらやっています。
面白そうと思えるということが一番重要なので、もし興味を持っていただけたのであれば、気軽にお話しの機会をいただけたら嬉しいです！
以上です、ありがとうございました！