リリースから半年、技術負債で落ちてしまった開発スピード　その時CTOが“サービス大部分の作り替え”を決断できたワケ

現場の73パーセントがSaaSを使いこなせていない

日比野淳氏（以下、日比野）：はじめまして。テックタッチの日比野と申します。本日、僕からは、「プロダクトを堅実に伸ばす大きな意思決定」というテーマでお話しします。

突然ですが、みなさん、日本のデジタル競争力はランキング何位かご存じの方はいらっしゃいますか？　（スライドを示して）実は、2022年日本のデジタル競争力は29位という結果になっています。日本のDXは、待ったなしという状況なのかなと思います。

一方で、企業のIT投資は積極的に進んでいて、特にSaaSの導入に関しては、年々増加傾向にあると思います。ただ、SaaSは導入したらそれで価値が出てくるかというと、そうではなく、やはりユーザーに定着して使いこなしてもらうことで、価値が出てくると思っています。しかし、現場では73パーセントの方がシステムをあまりうまく使いこなせていないというレポートも出てきています。

企業のシステム利活用を支援する「テックタッチ」

ここで僕たちのサービスの紹介です。私たちはWebシステムの画面の上に操作方法、業務フロー等をナビゲーションとして直接表示するソリューションを提供しています。これによって各企業のシステムの利活用を促していくサービスです。

少し変わったところとして、ブラウザの拡張機能として提供しているので、対象システム自体を一切改修せずに、こういったナビゲーションを展開できます。（スライドを示して）ナビゲーションについて、もう少し解説すると、エンドユーザーの画面の操作を補足することで、うまく案内を展開することが可能です。

例えば、入力フォームにフォーカスが入った時に、「ここのIDはメールアドレスですよ」とか「（株）という表記は入力しないでくださいね」というバリデーションをかけたり、システムの導線を案内する場合は、クリックに応じて、順次吹き出しを展開していくことが可能です。

複雑化によりリリースから半年で開発スピードが落ちてしまった

ここから少しエンジニアっぽい話になります。やはり私たちは、対象システムとうまく共存させていく必要があります。まれに、クリックイベントを止めるとか、IDが2つあるとか、関数がカスタマイズされているとか、対象システムに少し特殊な実装がされているケースがあります。ちょっと僕たちでは認知できないカスタマイズがされているケースがあります。

その時、僕たちが「対象システムの開発者に調整してください」と言うことは、どうしてもできないので、テックタッチ側の実装を改修していく必要があります。

このような度重なる種環境要因の適用と、スピード感のある開発・機能追加により、コードがかなり複雑化し、開発スピードが落ちてきました。

「サービスの大部分をゼロベースで作り替える」という意思決定をした

このリリースから半年後がどういう時期だったかと言うと、展示会に出展して、すごく大きな反響をいただきました。これから売っていくぞ、これからやっていくぞという熱狂が社内の中にすごくあったかなと思います。

これは賛否両論あると思いますが、ここで僕たちは拡張機能をゼロベースで作り替える意思決定をしました。

大胆な意思決定ができた理由とは

（スライドを示して）なぜ、この作り替えの意思決定ができたのか。いくつか理由があります。

まず、PMFにすごく手応えを感じていたので、もう少し長い目で考えられるようになってきました。開発のスタートの時には、ノウハウがゼロの状態で始めているので、この1年半でノウハウがすごくたまってきました。

僕たちには「今後、より多くのシステムに適用する」というビジョンがあります。いろいろ考えた結果、やはり、私たちの一番の強みは、Webシステムへの適合能力だと思いました。機能を積み重ねるのではなく、このWebシステムの適合能力が、私たちの競争力の厳泉だと考えました。

（スライドを示して）これまでノウハウをためてきて、これを正しく実装することで大きなアドバンテージを得られると考えました。なので、「早めに開発の2周目に突入する」という意思決定をしました。

「サービスの大部分をゼロベースで作り替える」ためにやったこと

これをどうやったのかというと、既存開発はPMFを確かなものにするために継続開発をして、再設計チームは今までのノウハウをもとに技術選定から開始しました。結果、フレームワークの変更を意思決定しています。

環境要因による適合ミスは、やはり進んでいくことで見つけられるので、既存のチームが見つけた場合は、再設計チームのメンバーと一緒にバグ修正をして、それぞれの開発チームに持って帰るという体制を1年間取ってやっていきました。1年後に無事、再設計への移行を完了しています。

やはり、なんでも2周目は強いと思っています。僕たちが当初目標にしていたシステムカバレッジはだいたい30システムぐらいで、けっこう大変だとなっていましたが、今だと100システムを超えるシステムの上で、安定稼働をしています。

（持ち時間終了のブザー音）

司会者：時間になってしまいました。

日比野：以上になります。

主要な部分を作り直す中で大事にしていたこと

司会者：質疑応答に移ります。それでは審査員のみなさま、いかがでしょうか。お願いいたします。

竹内真氏（以下、竹内）：ありがとうございます。すごくわかりやすかったですし、お客さまに対する言葉遣いにもすごく気を遣われているところも、すばらしいなと思って聞いていました。

作り直しを並行で行なったということで、中身のすべてを理解できていないので質問させてください。全部のシステムの中から、主要な部分を作り直していくということで、いろいろなことを考えて、ここまで行くか、ここまで行くかと考えられたと思うのですが、そこの瀬戸際でがんばったところがあれば教えてもらっていいですか。

日比野：ありがとうございます。まず一番に考えたのは、どういったリスクが僕たちのプロダクトにあるかというところです。私たちは、管理画面をコンソールみたいなもので提供していますが、やはり、お客さまのブラウザ上で動作する、この拡張機能の部分のリスクがすごく高いと思いました。

なので、そこの部分でまず簡単に切り分けて、このお客さまに提供するブラウザの拡張部分を、今回再設計の対象としてやることに決定しています。

竹内：ありがとうございます。

サービスの主要部分を作り直すためにビジネスサイドをどう説得したか？

司会者：そのほか、いかがですか？

山本正喜氏（以下、山本）：技術的負債がたまって、システムのスクラッチで書き直すことは今もあるのですが、これをやると、既存システムの一部の機能開発をいったん止めなければいけないじゃないですか。システムを作りながら既存側の開発をしていくと、両方作らないといけなくなるので、ロードマップに対する影響のインパクトが強くて、ビジネスサイドからすると、「え、なんで？」みたいな感じになります。

アーリーフェーズだと、特にどんどん機能を作っていかなくてはいけない場面だと思いますが、お客さんからの要望もたくさんあって、機能が足りないところに、「1年ぐらいパラでもう1ライン走らせてくれ」と言った時に、「なんでそんなことすんの？」と社内で意思がぶれることがあったと思いますが、その中で、どんなプロセスで説得していったんですか？

日比野：ありがとうございます。まず、結論から言うと、ビジネスサイドから反対という声は挙がってきていません。理由はいくつかあるかなと思っています。井無田（井無田 仲氏）という者が代表をやっているのですが、彼とはテックタッチを創業する前から長くやってきていて、手前味噌ではありますが、信頼を勝ち得ていたかなというところはもちろんあります。

あとやはり、先ほどお伝えしたように、どのようなシステムでも動作させるということを1丁目1番地と考えていたので、先ほどの回答になってしまいますが、機能追加よりは、そこの技術ノウハウを正しく実装するということが、僕たちの開発においては正しい道だったと、あとからかっこつけて言うと、そうなります。

山本：ありがとうございます。

デグレードしないためにテストカバレッジを設定

司会者：残り1分少しですが、いかがでしょうか。

藤本真樹氏（以下、藤本）：では、すみません1個だけ。この手のやつは、教科書で言えば、テストを書けというのが鉄板だと思うのですが、デグレうんぬんの、そのへんで新旧を動作担保する時に、テスト、その他、工夫したところを教えてください。

日比野：もうおっしゃるとおりで、テストを徹底的に書くというところです。それとも、再設計前の移行の時のプロセスの注意点ですかね？

藤本：そうですね。もう人力でめちゃくちゃテストを書いたとかもそうかもしれないし、このへんをがんばったとかありましたら。

日比野：コードとしてテストコードをたくさん書くのを目標として、テストカバレッジを設定して、やり尽くしました。あとは再設計の軸としては、リスク分散がテーマとしてあったかなと思っています。

ノウハウってなんぞやみたいなところでいくと、どうしても適合は未知というか、そのシステムの上に載って初めて出てくるというところがあります。これを僕たちは認識して、それが起きた時にどれぐらいリスクを局所化できるんだみたいなところを、再設計の軸にしています。

だから、例えばバージョンをコントロールする、その粒度を小さくしたり、なにかしらが適合されるタイミングを調整したりして、デグレに備えました。

藤本：ありがとうございます。

司会者：ありがとうございます。ちょうどお時間になりました。ここまでは日比野さんでした。ありがとうございました。拍手でお送りください。

日比野：ありがとうございます。

（会場拍手）