SaaSを大企業向けに開発しようと奮闘した振り返り
こんにちは、株式会社オプティマインドの戸ヶ里と申します。
株式会社オプティマインドでは、Loogiaという物流の配車を自動化するSaaSを開発・販売しております。
私自身は、開発部組織に所属して対顧客のプロジェクトマネジメントを担当しております。
本記事では、今年1年の大企業向けのSaaS開発の状況やアクション、その結果を振り返ってみようと思います。
※ ぼかしている部分があるので、より具体的な内容が気になる方はオフレコな場で話をしましょう。
大企業向けSaaS開発にはジレンマがある
株式会社オプティマインドでは、主に中〜大企業のお客様にサービスをご利用いただいております。ここで難しいのが、中規模の企業と大規模の企業で異なる対応が必要になることです。
中規模の企業ではSaaSに合わせた業務を構築することができる一方で、大規模の企業では業務に合わせたソフトウェアを構築することが重要です。これは大企業が柔軟性がないというわけでは全くなく、この現象はごく当たり前に発生します。
例えば、勤怠システムを導入したいと考えたときに、大きくない企業の場合はソフトウェアを変えるより業務フローを変える方にインセンティブがあります。なぜなら、ソフトウェアの開発費＞業務フロー変更のコストとなるからです。
反対に大きな企業では、業務フローを変更するときのオペレーションが非常に大変になるため、ソフトウェアの開発費＜業務フロー変更のコストとなります。そのため業務に合わせたソフトウェアを構築するインセンティブがあるということです。
ここで改めてSaaSについて整理します。
「SaaS」とは「Software as a Service」の略で、「サービスとしてのソフトウェア」を意味します。クラウドサーバーにあるソフトウェアを、インターネットを経由して利用できるサービスで、パソコンにソフトウェアをインストールする必要はありません。インターネット上へのデータ保存、マルチデバイスに対応、複数人のユーザーで利用が可能といった点がSaaSの特徴として挙げられます。
定義は包括的な表現になっており理解しづらいので、本記事では、複数のユーザーが利用することを前提とする利用料が発生するソフトウェアサービスとします。（厳密ではないですがご了承ください。）
代表的な例だと、SlackやZoomがあります。
どんなジレンマがあるのか
複数のユーザーが利用することを前提としているため、個別の企業の要望には必ずしも答えることができるわけではないです。
例えば、Slackに「偉い人はアイコンが大きくなる機能」や「他の人に送金できる機能」が必要な会社があったとしても、その機能を開発してもらうことはできないでしょう。（Slack側が開発を決定する可能性はゼロではないですが、ユーザー側からは基本的にコントロールできません。）
反対にサービス提供会社の視点で見ると、全ての顧客の要望に応えることは現実的に不可能であるということです。
ここでジレンマが発生します。大企業では業務フローを変更するのではなくソフトウェアを変更したい一方で、サービス提供企業では全ての要望に応えることはできないので必ずしもソフトウェアを変更できるとは限りません。
ジレンマ対応のために顧客対応のチームを組成した
前述したように全ての要望に応えることはできないですが、当然顧客へ価値提供をしたい気持ちは強く持っております。そのため、大企業対応専門のプロジェクトチームの組成しました。大企業を担当するチームで、私もそのチームに所属しました。
チームメンバーは主に営業の方と私の2名、加えて役員が責任者として携わっておりました。加えて一定の予算（キャッシュ）が割り当てられておりました。
私は大企業のお客様からいただいた要望と全ての顧客から頂いた要望をアラインして開発ロードマップを作成する、そしてリリースするまでを担当しておりました。
苦戦した
結果としては、プロジェクトを良い方向に進めることに苦戦しました。
なぜ苦戦したのか
体系的な振り返りをすると、プロジェクトマネジメントは10のマネジメント領域がありますが、その中で資源のマネジメントに失敗しました。
最も重要なリソースである開発リソースを確保することが難しかったことが最大の要因であると思います。
6. Project Human Resource Management
The project team is your most important resource, so it’s crucial to assemble the best team and to make sure they’re happy. But also you need to track their performance to ensure that the project is progressing as planned. A human resource management plan will identify their roles and their requirements for those positions, as well as how they fit in the overall project structure.
なぜ開発リソースを確保することが難しかったのか
もう少し深掘りしてなぜ開発リソースを確保することが難しかったのか、確保できなかったのかを考えてみます。
予算を開発リソースに変換できなかった
前述の通り、開発を発注するためにプロジェクトチームに一定の予算が割り当てられていましたが、この予算を適切に使うことができませんでした。
SaaSを開発している方は共感していただけると思いますが、プロダクトの一部機能を外部で開発することは簡単ではありません。加えて、Loogiaを開発するには一般的に必要なサービス開発に関する知識に加えて、GPSデータや地図データ、グラフ理論、組合せ最適化アルゴリズムなどニッチなスキルが必要でした。そのような開発を外部に依頼することが難しかったため、予算を効果的に使うことができませんでした。
謝辞
私の1年の振り返り、主に反省の振り返りをご覧いただきましてありがとうございました。この記事が少しでも皆さんのメリットになれば嬉しいです。
本記事では書ききれなかった部分もたくさんあるので、同じような境遇にある方やもう少し詳しく聞きたいよって方はコメントかTwitterから連絡ください！
https://twitter.com/KenseiTogari
この記事が気に入ったらサポートをしてみませんか？