システム開発から運用・業務改善までを顧客と伴走して行うソフトウェアハウス「株式会社インターシステムズ」が、社員の力を引き出し、顧客により多くの価値を届けるために、アジャイル・スクラムを取り入れていく一連の事例。
第3話からは、いよいよ現場チームの話です。
社内で「そろそろ閉じてもいいのでは」と言われていたプロダクトを、「それでも事業として続ける価値がある」と結論付け、新たに立ち上げたスクラムチームで、顧客のニーズを聞きながら不要なものを大胆に削ぎ落とし、再構築していきます。
そんなチームが真っ先に取り組んだのは、プロダクトオーナーが投げかけた「3つの問い」を確認することでした。
プロジェクトの立ち上げに携わられた、プロダクトオーナーの橋本さんに語って頂きました。
はじめまして、インターシステムズでプロダクトオーナーを務めている橋本です。
インターシステムズ 橋本さん
自分の仕事の話がこういった記事になるのは、少し不思議な感じですが、私たちがスクラムを実践しながら、新しいプロダクトをリリースするまでの、直近1年間のお話しをさせていただきます。
私が携わっているのは、「SurveynoteX（サーベイノートクロス）」というプロダクトで、このプロダクトをスクラムチームで開発しているのですが、開発に着手するまでにはかなりの紆余曲折があったので、まずはその背景について簡単に触れさせてください。
インターシステムズでは、これまで、そして現在も「Surveynote（サーベイノート）」という建設現場向けの建物調査の業務を支援するプロダクトを提供しています。
マンションや団地、ビルなどの大規模修繕工事に先立って実施される建物調査の現場では、多くの分野の職人の方々がいて、バトンパスのように仕事をされています。
仮設足場の計画、外壁やタイルの劣化状況の調査、シーリングのひび割れ確認、塗膜の浮き・剥がれの確認、設備の点検…それぞれの担当者が自分たちの調査項目を確実に終わらせていくことで、後の大規模修繕工事の計画や費用算出に必要な情報が集約されていきます。
職人さんは、自分たちが行った調査内容について、元請けが定めたフォーマットに従い報告します。
今でこそ、建物調査の現場でもITツールの採用が広がってきていますが、私たちがこの課題に取り組み始めた当時は、紙ベースでのやりとりをしている現場が多くありました。
多くの職人の方々が、現場で劣化状況を手書きで記録し、デジタルカメラで撮影した現場写真を事務所に持ち帰り、PCで調査報告書を作成して印刷して提出するという作業を行っていました。
そのような中、弊社の前代表である田中が、交流のあった建築事務所から、「品川区営住宅の調査を予定しているが、大規模な案件で多くのマンパワーが必要になる。何か少しでも効率よく進められる方法はないか」と相談を受けました。
ITの力でこの課題を解決できないか？
現場で記録した内容を、そのまま報告書の作成につなげられないか？
そうした思いから開発したのが、「Surveynote」の前身となる「IEMORI」というサービスです。
その後、IEMORIで培った仕組みや現場で得た知見を受け継ぎ、2017年に月額制のクラウドサービス「Surveynote」としてリリースしました。
「Surveynote」はタブレットで利用可能なWebサービスです。
これまで事務所に戻らないとできなかった調査結果の整理や報告作成につながる作業を現場での記録段階から進められるツールとして、実際に建物調査に携わる下請け・孫請けの会社様を中心に、およそ70社様に採用いただいています。
Surveynoteについては、私をはじめとする開発メンバーも、より良いサービスにしようと懸命に取り組んできました。
しかし、思うように新規契約が伸びない時期が続き、建築業界の企業が開発した競合サービスも登場し始めていました。
長く使って頂いているお客様はいるものの、売上が十分に伸びているとは言えず、事業として今後どこまで成長させられるのか、見通しを持ちにくい状況でした。
技術面でも、課題を抱えていました。
システムを構成する基盤やミドルウェアが、いずれも古いバージョンのまま動いており、保守性やセキュリティ上の脆弱性が懸念される状態になっていました。
さらに、それまでサービスの方向性や搭載する機能を決めていた前社長の田中が不在となり、今後、誰がどのようにサービスを発展させていくのかについて、社内でも明確な方針を持てずにいました。
新規契約が伸び悩んでいること、競合サービスが増えてきたこと、技術環境が古くなっていること、そして、今後の方向性を決める意思決定者が不在となったこと。
こうした複数の不安が重なり、社内では次第に、「これ以上、開発や保守に手をかけるよりも、サービスを終了した方がよいのではないか」という意見が広がっていきました。
一方で、営業担当には、それらとは違った思いがありました。
既存のお客様からは、継続的に改善や機能追加の要望が寄せられている。
実際に必要としてくださるお客様がいる以上、その声を受け止めながら、少しでも良いサービスへ進化させ、今後も販売していきたい。
社内で議論を重ねた結果、営業担当を中心に、Surveynoteが置かれている状況や契約数、売上の推移を改めて整理していくことになりました。
「ServeynoteXのビジネスに関するディスカッションの様子
事前の用意はほどほどに、ホワイトボードの前で経営層とインタラクティブに議論する
「Surveynoteがお客様に提供している価値は何なのか」
「本当にニーズがないのであれば、なぜ約30社ものお客様が契約を続けているのか」
「どのような数字が見えればサービスを継続し、どこまで届かなければ廃止するのか」
「継続するために解決すべき課題は何なのか」
長谷川社長や営業担当が中心となって契約状況を確認していくと、新規契約数は急激には伸びていないものの、毎年およそ10社ずつ増えていることが分かりました。そして、直近では年間の新規契約数が15社を超えるまでに伸長しています。
また、サービスの内容をきちんと説明できれば成約につながる割合も比較的高く、解約するお客様も年々少なくなっていました。
新規獲得は伸び悩んでいても、いったん使い始めたお客様は長く使い続けていただける。しかもこのサービスは、売り切り型のビジネスではなく、月毎に収入が得られる月額のストック型サービスです。 経理担当も、これまで当社が主に手がけてきた受託型の事業とは異なる、SaaSの収益モデルについて調べてくれました。契約数を積み重ねることで収益がどのように変化し、どの時点で損益分岐点を超えるのかといった考え方も、社内で共有されました。
こうして事業を数字で捉え直していく中で、私自身も、「新規契約が大きく伸びていないから終了する」のではなく、「長く使い続けていただけるという強みを生かせば、まだ伸ばし方があるのではないか」と考えるようになりました。
ですが、Surveynoteを無条件に継続する、という訳にはいきません。
そこで、一つの判断指標として「3年間で年間売上1,000万円」という目標を設定しました。
その後、既存の環境を維持しながら比較的難易度の低い改修を進め、少しずつ営業範囲を広げていった結果、当初の予定よりも早く、年間売上1,000万円の達成が見込める状況になりました。
一度は終了も検討されていたSurveynoteに、事業としての可能性が見え始めたのです。
Surveynoteを必要としてくださるお客様がいることや、事業として成長する可能性があることは確認できました。
しかし、開発を担当する私としては、別の課題を感じていました。
営業担当には、これからもSurveynoteを販売し、お客様の要望に応えるための機能を加えていきたいという思いがあります。一方で、古い技術環境や複雑化したシステムに、販売のための改修をさらに積み重ねていくことが、本当に正しい選択なのかという疑問がありました。
サービスを今後も売り続けるのであれば、既存の環境を改修し続けるのではなく、一度土台から作り直すという選択肢が必要なのではないか。
事業としての可能性が見えてきたからこそ、私はそのように考えるようになりました。
そこで、サービスを作り直した場合の投資対効果をシミュレーションするとともに、継続する条件や、将来的に撤退を判断する条件について、社内で議論を重ねました。
その結果、次の方針で新しいサービスを開発することが決まりました。
古くなった技術環境は、保守性やセキュリティを考慮して全面的に刷新する。一方で、既存の機能をすべてそのまま引き継ぐのではなく、実際に使われていない機能は大胆に削減する。
そして、既存のお客様や新たなお客様が本当に必要としている機能を見極めながら開発するため、スクラムによって段階的に開発を進めていく。
こうして、新しいプロダクトの開発が正式に承認されました。
新しいプロダクト名は「SurveynoteX（サーベイノートクロス）」となり、これが現在、私たちのチームが取り組んでいるプロダクトになります。 一度は廃止も検討されたSurveynoteは、お客様に長く利用していただいているという事実と、数字に基づく検証を経て、新しいサービスとして再出発することになりました。
インターシステムズのマネジメント層がRSM研修を受けたのは2024年の年末、開発メンバーがRSTM研修を受けたのは、2025年2月のことでしたが、前述のような議論が長引き、実際にスクラムでプロジェクトを開始できたのは2025年5月に入ってからでした。
Surveynoteに対して懐疑的に思っているメンバーもいたため、まず最初に取り組んだのは、「なぜ作るのか？」をチームメンバーに正しく理解してもらうことでした。
5月12日、キックオフミーティングを開き、スクラムチームのメンバーと以下の話をしました。
ServeynoteX開発チームの現在のレトロスペクティブの様子
遠隔地でリモートで働くメンバーが多いため、teamsを使って行う
Surveynoteは建物調査の現場の課題をDXで解決している、すでに実績があるプロダクトです。
今までメンテナンスが十分ではなかったものの、現場で利用されている職人さんの声などを聞くと、普段はあまりそういったツールを使ってくれなさそうな人でも、「作業後に事務所に戻って報告書を作成したりする手間が減り、楽になったよ」と気さくに返してくれる人も少なくなく、これを良くしていくことで、もっとたくさんの人の仕事を役に立てるかもしれない。
そして、会社にとって安定した収益を提供してくれるストック型のビジネスであり、ある程度安定した形で保守・運営できれば、会社の経営にも資すると思う。
プロダクトオーナーとして、こんな話をしたかと思います。
一方、Surveynoteの失敗は、個別の要望が出るたびに機能追加する一方で、それが市場全体のニーズかニッチかを見極めないまま改修を重ねてしまったことでした。
結果として機能と実装が場当たり的に積み上がり、全体像が掴みにくく、保守しづらいコードになってしまいました。
個別のニーズを追求するのではなく、全てのお客様が同様に必要とする機能に絞り込み、作っていきたい。
既存のお客様の8割が満足し、新しい「SurveynoteX」に移行してくれることを目標とする。
そして、1年後までには必ずリリースしたい、というロードマップも示しました。
最後に、チーム構成について、このプロジェクトをスクラムで回していこう、と話をしました。
自分たちの作ったものを使ってくれるお客様に、ちょっと足を伸ばせば会うことができて、意見を聞ける。
ずっと使い続けてもらうサービスなので、その中でニーズに合わせて改良していく。
そんなことをスクラムでやっていこう、という話になりました。
その一方で、自分たちの「ルールブック」も整理しました。
そのルールブックの冒頭で、私が最初に書いたのが、次の一文です。
スクラムを実施すること自体が目的ではない。
スクラムを活用して、新しいサーベイノートクロスを作り上げていくことが目的である。
スクラムを始めると、どうしても「イベントをちゃんと回せているか」「ツールを使いこなせているか」といった「やり方」に意識が寄りがちです。でも私たちが本当に達成したかったのは、スクラムのイベントを消化することではなく、お客様に出せる新しいプロダクトをつくることでした。
これは、後になって非常に「効いてくるルール」だったのですが、それはまた後日お話ししたいと思います。
ということで、私たちスクラムチームのプロジェクトが始動しました。
コードのベースには、特定のお客様向けに派生開発された、比較的新しい実装を採用しました。
また、既存のお客様が本当に使っている機能は何かを洗い出すために、お客様にアンケートを取り、それを元に何を残すのか、何を捨てるのかを判断し、洗い出されたPBIを元に、チームは開発を開始しました。
ところが、始めのうちは、なかなか思い通りに行かないスプリントが続いたのです。
続く
