(前編): ソリューションプロジェクトのPoCをやってきた人の立場から見る、SaaSプロダクト開発の面白さ
こんにちは＆はじめまして。
テクノロジーの力で日本の製造業の経営改革を支援するスタートアップSaaSカンパニー、スカイディスクのAIエンジンチームで働いています、matsunoです。
今回は「スカイディスクというSaaSカンパニーで、AIエンジニアとして働くことの面白さ」(前後編)の前編という位置付けの記事になります。
「ソリューション(※)プロジェクトのPoCをやってきた人の立場から見る、SaaSプロダクト開発の面白さ」について語っていきたいと思います。
記事の構成・論理展開としては、まず論拠となる事実や一般論の紹介としてソリューション・SaaSそれぞれの特徴や共通点・差異について述べた上で、最後に「結論:」部分でそれぞれの面白さを語る、という方式を採用しています。
それなりに長文の記事(前後編合わせて一万字弱)になってしまったのですが、根気強く読んでいただけると幸いです。
※: この記事におけるソリューションとは「特定の企業やプロジェクトのニーズに応じて設計された、オーダーメイドの技術的解決策」のことを指します。汎用性というよりはカスタマイズ性、堅牢性というよりはプロトタイピングを重視して、フルスクラッチに近い方法で開発されるものを想定しています。
自己紹介:
私は、2018年春に大学院を卒業して、そこから現在である2024年夏に至るまで、スカイディスクのお世話になってきました。
大学院では物性分野で理論物理をやっていたため、入社当時はあまりAI ! 即戦力というかんじの人材ポートフォリオではなかった私ですが、自分なりに少しづつ学び・実践しながら、AI研究開発 リサーチャー (1年くらい)→ DXソリューション開発 AIエンジニア (4年くらい)→ 生産計画SaaS AIエンジニア(現在: 1年くらい)というキャリアを歩ませてもらってきています。
個人的には、停留しすぎず、背伸びしすぎず、無理なくいい感じのステップで知見を溜めつつスキルを伸ばしていけていると思っているのですが、それはまた別の機会にでもする話として、今回は「両方の職務を実体験してきた立場から見て、ソリューションのAIエンジニアとSaaSのAIエンジニアって、結局何が違うの？どう面白いの？」という話をさせてください。
ビジネスのありかた:
ソリューションとSaaSにおいて、まず違うのは、ビジネスのありかたです。
これに伴って、働き方や事業に適した組織の形態もそれなりに変わります。
ソリューションの場合は(絶対に、ではないにしろ)フルスクラッチの完全カスタマイズ開発になることが多く、プロジェクトが持つ大きな不確実性を反映して、人月で計算される準委任の契約形態をとることがほとんどです。
納期と大まかな予算ありきで、ではまずいつまでにどのくらいの工数を使ってこんなことを検証してみましょう(PoC1回目)、ここまでで見つかった新たな課題に対してこのくらいの時間とお金を使って対応策を作り上げましょう(PoC2回目)、最小構成で仮のシステムを組んでみましょう(MVP)、etcというような進め方に、毎回ヒアリングや要件定義や調整や説明・説得・提案が乗ってくる形式の進行パターンが採用されがちです。
経験上、プロジェクトチームは小さめ(５人以下くらい)で、期間としては2〜3ヶ月を3〜4回かけて分割して実施するような規模感を持ちます。
ソリューションのプロジェクトで実施する内容は、お客さまのやりたいことと、我々から提供できることのバランスで決まります。できうる限り、顧客要求はそのままその通り実現する、という意思決定が多くなるでしょう。
一方のSaaSはお客さまとの契約形態がサブスクリプションであり、開発は終わりなき改善サイクルを回すプロダクト方式で進みます。(締め切りが厳格に定められたプロジェクト方式ではありません)
今この瞬間にもプロダクトを使ったり利用を検討してくださっているお客さまが多数存在するため、息継ぎしている暇が一切ありません。
プロダクトという生き物を少人数で支えていくことは不可能であるため、必然的に大きめのチーム構成となり、上手に分業しつつ互いの失敗・学びを生かしながら開発・運営を回していくことになります。
業界特化型SaaSはパッケージソフトウェア(※)としての性格上、業界標準の知見・技術の粋を集約したツールとして君臨する可能性があり、いいものを・安く・誰もが使える世界をもたらす爆発的なポテンシャルを秘めています。
プロダクト開発においては、より多くの人に最高の価値・体験を届ける、という大義名分があるため、お客さまからのFBを下敷きにしつつも、お客さまが本質的にやりたいことってなんだろう、とか、より良いサービス体験のありようやその実現手段について、日々頭を悩ませることになります。顧客要求は必ず一旦咀嚼・昇華され、より多くの人に価値を届けられる様式に変更された上でプロダクトに組み込まれてゆきます。
※: ここでいう「パッケージ」とは「多数のお客さまが同様に利用できるように共通化・標準化されたもの」という意味であり「ROM媒体を購入してオンプレミス環境に導入するもの」という購買方法・配布方法に言及するものではありません。
協力体制:
ビジネスのありかたに伴って、チームの組成やメンバーに求められるスキルセットも変わります。
ソリューションプロジェクトチームはコンパクトさが肝要であるため、各メンバーには広く柔軟なスキルセットが求められます。
特に、開発を担当するエンジニアの目線から言うと「直接、顧客がわかる言葉で、どんな結果が得られ、今後どう改善の見込みがあるか、いつ頃できそうか、そしてそれはなぜか、を説得力をもって説明する能力」の重要性がとても高いです。
一方のSaaSプロダクト開発チームは、より専門性の高いメンバーからなる集団です。
大規模なユーザーベースを想定することが求められるため、サービスのスケーラビリティや信頼性を確保するためのインフラストラクチャ設計や運用が重要になったり、高頻度のリリースサイクルに合わせて、設計、開発、テスト、デプロイの手順が整備される必要があるからです。
開発チーム内においても、専門性によって細分化された小規模チームを複数編成して組み合わせられることがよくあるでしょう。
両者ともに共通の要素として、チーム外メンバーとのコミュニケーションが重要、という部分はありつつ、主として誰とやり取りするか、には大きな変化があると言えます。(ソリューションでは社外のお客様とのやりとり、SaaSでは社内の別チームとのやりとりが増えてきます)
実務エピソードのコーナー:
スカイディスクのSaaS事業部では、メンバー誰もが起票権を持つインサイトボードという仕組みを採用しています。
これは、お客様から直接発せられる要望の声 [Voice of Customer: VoC] とは別に、プロダクトを進化させるために必要な why・what をまとめるものです。(※)
インサイトボードにてまとめられた情報から、プロダクトチームが開発の優先順位づけを行い、実装が決まったものについては how・who・when などを管理するバックログに「要求仕様」として受け渡され、エンジニアたちの手によって具体化されてゆく、という流れになっています。
先日、ある biz メンバーのかたと共同で、ひとつのインサイトを執筆する機会がありました。
お客様の業務内容や引っ掛かり易いポイントに詳しい biz メンバーと、現行プロダクトの仕様や技術的実現可能性に詳しいエンジニアが、綱引きをしつつ対等な関係をもってプロダクトの一歩先の理想像について語り合える場があることの重要性を、改めて感じることができました。
みなさんには内容についてはまだ秘密(！)なのですが、この知見を盛り込んだ機能が公開され、お客様から「まさにこんなのが欲しかった、すごく便利！」の声が聞こえてくることを確信していますし、その時が来ることを今か今かと心待ちにしています。
※: VoCがアンケートやインタビューなどによってお客様から直接得られる意見や感想である一方で、インサイトは市場やフィードバックに対するデータ分析、顧客業務理解や行動観察から得られる一段階深い洞察を指します。インサイトには「お客様が直接的には言及しないがプロダクト使用中に感じる不便さ」であったり「お客様が持つプロダクトの未来への期待を予測するような潜在的なニーズ」が含まれている必要があります。
結論:
ソリューションプロジェクトの面白さ
厳格に決まった納期に向けて、効率よく高い成果を出すにはどうするか、攻略を考え着実に実行するゲーム的快感がある。
目標を合意したり進め方の提案をしたり、目の前にいる N=1 の顧客満足を、自らの力量によって作り出している実感が得られること、その実践によって総合力が鍛えられること。
SaaSプロダクト開発の面白さ
いかに「たくさんの人」に「すばやく」多くの「価値」を届けるか、「持続的に」価値を届けられる仕組み・プロダクトとは、という、根源的な問いに集中できる。
役割分担もありつつ、チーム一丸となって達成する文化や安心感が強い。
結びに替えて:
特にSaaSプロダクト開発では、
それぞれの専門を高度に生かしつつ、チームとうまく協働できる人
顧客要求の奥に潜む根源的な価値を嗅ぎ分け、かつ、誰もが納得できるように説明づけられる人
が活躍できるでしょう。
スカイディスクでは、一緒に働いてくれる仲間を募集中です。
カジュアル面談を通じて気軽に繋がりましょう！
https://recruit.skydisc.jp/
次回は後編として「機械学習モデル活用プロジェクトをやってきた人の立場から見る、数理最適化・スケジューリング問題の面白さ」について語る予定です。
次回の記事も楽しく読んでいただけたら幸いです。