SmarESGプロダクト開発のこれまでとこれから
序文
みなさん、こんにちは。シェルパ・アンド・カンパニーVPoEの小川です。
2024年のアドベントカレンダー最終バッターを務めるわけではありますが、特に最終バッターということに関係なく書き物をしたいと思います。
(最終バッターだからあれこれみたいな適度なオチが見つかりませんでしたw)
大変ありがたいことに今年も多くのお客様にSmartESGをご導入頂きました。
ビジネスの成長と共にプロダクトとしてのラインナップも順調に増えており組織・製品としてのフェーズも刻一刻と変化してきていると肌身で感じています。
現在のラインナップ
SmartESG
コアプロダクト
ESG情報開示をトータルサポート
SmartESG KPIコンソリデーション
連結データの収集と集計を効率化し、人的資本経営をサポート
SmartESG Answer Ease
取引先へのESG評価アンケートの回答作成を自動化
今回の記事では、主に開発視点でのこれまでのフェーズの振り返りと今後の向かってゆく大きな方向性を書きたいと思います。
これまで
これまでの成長を簡単に振り返り
SmartESGは開発をスタート（2021年12月から）してから約3年経過したという状態です。
プロダクト立ち上げ
SmartESGはDay1からエンタープライズ、中でも東証のプライム市場上位に位置するようなスーパーエンタープライズ向けのプロダクトしてスタートしました。
立ち上げ期のミッションは「短期間でスーパーエンタープライズ企業に導入できる製品を開発する」ことでした。
当時の重要な意思決定は、「PMFするための開発を少人数・短期間で実現するために圧倒的に選択と集中をすること」です。お金と時間がないですからね💸💸
その結果の成果としてスーパーエンタープライズ向けの業務システムSaaSを開発開始5ヶ月でローンチ、開発開始1年弱で10社以上に導入、次の資金調達成功を達成できました。
弊社の場合アーキテクチャの特徴としてサーバサイドの開発・インフラの管理がほぼなく、すべての開発リソースをフロントエンドに集中しています。
ここでいう選択と集中とは、作らない部分・気にしなくていい部分を大胆に決めたことです。
このような意思決定をした背景には3点理由があります。
1点目は市場特性、2点目はSeedフェーズ、3点目は開発経験です。
1点目の市場特性
弊社が事業展開しているESG情報開示領域の特徴として顧客がスーパーエンタープライズ企業ということが挙げられます。例として公開している導入事例（https://smartesg.jp/case）にもありますが、DNP様等に導入頂いています。
SaaSは有料ユーザーからフィードバックをもらいながらプロダクトを改善し続けることが王道ですが、事業立ち上げ時に顧客がエンタープライズ企業の場合、改善サイクルを早く回すことがかなり難しいです。有料で導入して頂くためには、業務を回すための機能の充足はもちろん、セキュリティ要件や予算時期の関係など様々なハードルがあり、導入のリードタイムが長くなります。また、実績を重要視する顧客も多いため、鶏卵状態になり導入実績もない製品はさらに導入のハードルが上がります。そのため一部機能しかない中途半端なものは導入されません。
このハードルを超えるためにも一気に一定の機能と非機能を満たすように開発する必要がありました。
2点目のSeedフェーズ
ヒト・モノ・カネ全てが充足していないということです。
そのような中にプラスして市場特性もあり、より一層短期間で多くの機能を開発しないと次のフェーズに進めないという強力な制約がありました。
このハードルをクリアするために選択と集中をするのに加えてより精度の高い製品とするためにエンジニアであっても「ユーザーと対話する」ことを重要視し、「ドメインを深く理解」し、「技術にこだわらない」ことを重要視してきました。
また、市場投入前であってもより精度の高い一次情報にあたることができるように弊社代表の杉本がサステナブル・コミュニティの立ち上げに参画し、現場で業務をしているサステナビリティ担当者の方にヒアリングできる仕組みを構築しました。
（現在サステナブル・コミュニティは社団法人化し、500名規模に拡大しています。）
3点目の開発経験
現在採用しているアーキテクチャは弊社内では採用実績が豊富にありました。そのため最速でエンタープライズ向けのシステムでもPMFまで走りきれるという自信がありました。
弊社は創業から順調に今のフェーズに到達したわけではなく、現在のSmartESGの事業を開始するまで2度のピボットを経験しています。SmartESGの開発を始める前はエクイティでの調達はしておらず、事業機会を探して短期で開発し、試し、撤退し、次の事業までは受託開発をするということをやっておりました。
そのような中で、自社サービスしかり、受託開発の中でもMVP開発をしてきた経験が糧になっています。暗闇の中でも前に進んできたチームとしての経験が活かされています。
シード調達してから次の調達までの1.5年は、エンジニア3名、デザイナー1名というミニマム体制でした。この体制でスーパーエンタープライズ向けの業務システムSaaSを開発開始5ヶ月でローンチ、開発開始1年弱で10社以上に導入頂いています。
現在はMeet The Teamにもあるように業務委託の方も含めて20名前後まで拡大していますが、ここ数ヶ月前までは小川が開発チームの全てのリソースをコントロールして各種プロダクト開発を進めていました。
※イメージ図
※人数は適当です
Meet The Team
これから
プロダクトの売り方の変化
この記事の冒頭でも紹介させて頂いておりますが、直近プロダクトのラインナップが増え、プロダクトの売り方が変化してきていると感じます。
2022年の正式版リリース時は単一のコアプロダクトだけであったが、2023年から2024年はコアプロダクトからアップセル、クロスセルしていくオプションプロダクトが増えました。
また、来年2025年は更にプロダクトが増えていき、コアプロダクト以外のオプションプロダクトを単体のプロダクトとして販売できるようにしていくという方向性も考えられます。
コンウェイの法則と逆コンウェイ戦略
プロダクトの売り方の変化からシステム基盤の見直しや組織体制の最適化といった変更を直近進めています。
コンウェイの法則、逆コンウェイ戦略に基づきアーキテクチャの進化と人間組織の再編成を同時に進行している最中です。
コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。 逆コンウェイ戦略は開発チームの組織構造を変更して、望ましいソフトウェアアーキテクチャを目指すというものです。 コンウェイの法則で覚えておきべきことは、システムのモジュール分解と開発組織の分割は同時に行わなければならない、ということです。 これは最初だけではありません。 アーキテクチャの進化と人間組織の再編成は、企業が存続する限り密接に連携させなければなりません。
組織体制の更新と求める開発職の人材像
組織体制に関しては立ち上げ期に最適であったリソースをワンプールで管理する方式から、Team Topologiesをベースにした体制に変更を実施しています。
また、我々は開発手法としてアジャイルを採用していますが、スクラムはしていません。
もっとより柔軟に自律性を持って、ストリームチームごとの多様性を許容し開発を推進しています。
このような考え方は、Fluid Scaling Technology (for Agile) Fast と呼ばれる考え方と似ていると考えていますが、Fastに準拠しているわけではなく、あくまで自社にとって最適と思われる仕組みを構築するように意識しています。
上記の組織変更に合わせて、チーム、個人としての動き方も変わってくる部分がありますので、求める人材像のディスカッションも社内で行っており、来年議論に基づいた内容で採用職種なども更新していく想定です。
この記事では「これから」について触りの部分に多く触れ、詳細を書きたいところは山々なのですが、この記事で書くとボリュームが出すぎてしまうので書きませんが、来年開発チームとしての情報発信は積極的に行って行きたいと考えておりますのでそちらで触れる予定です。
最後は来年の自分に向けての送りバント（来年の記事の前フリ）のような形となってしまいましたが、会社としては、来年も着実なヒットを重ねて塁を進めつつ、ホームランも狙っていきたいと思います！⚾
というわけで、メリークリスマス🎄🎅🏻
みなさま、よいお年をお迎えください🎍
Cierpa Advent Calendar 2024、全17記事無事完走することができました。
読んでくださった皆さま、ありがとうございました⛰️🧗