前例なきサービス領域、前例なきシステム形態　スマートラウンド・小山氏が語る、スタートアップ業務効率化への挑戦

スタートアップ業界の大きな非効率を解決する「smartround」

小山健太氏（以下、小山）：「前例なき課題に挑め、スマートラウンドの経営課題と挑戦」。

「日本にユニコーン100社、スタートアップ10万社を創出する」。先月政府が発表した内容です。今、スタートアップは注目され、大きな波が来ています。しかし、それを阻害する業界全体の大きな非効率が存在します。それは何か？　（スライドを示して）こちらです。

スタートアップは通常、投資家から投資を受けますが、その際、さまざまな書類の提出義務が発生します。しかし、その書類の形式も提出時期も経路も、すべてが各社でバラバラです。そのため、同じ書類なのに何度も別形式で共有する非効率が発生しています。「smartround」は、この課題を解決します。

経営者は、smartround上で簡単かつ正確にデータを作成でき、共有作業は1度しか必要ありません。その価値が認められ、創業4年でスタートアップ3,000社にご登録いただきました。そして先日無事、シリーズAを迎えることができました。

smartroundは、スタートアップ業界の基盤となるサービスを目指していきます。

前例がないサービス領域でゼロからUI/UXを作り上げてきた

そんなスマートラウンドもさまざまな経営課題に直面してきました。順に見ていきましょう。まずは、プロダクト。

smartroundは、株主総会、資本政策、経営管理などの便利なアプリケーションを1パッケージにまとめて提供するサービスです。

そのため、他社のスタートアップと比較して、システム規模は類を見ないレベルで巨大で、個々のアプリケーションのドメイン知識も複雑でした。さらに、前例がないサービス領域に挑戦しており、国内にも海外にも類似するサービスはありませんでした。そんな中、想像力を働かせ、ゼロからUI/UXを作り上げてきました。

システム形態も前例がありません。SaaSは、自社でデータが完結しますが、smartroundは、プラットフォームとして他社とデータをやり取りします。そのため、UXや設計の常識が通用しないこともありました。

スクラムを改変した独自開発スタイルとモジュラモノリス化で爆速開発を可能にした

そんなプロダクトの難しさにどのように対処してきたか？　一例を紹介します。

私たちは、スクラムを改変した独自開発スタイルを取っています。よく知られているスクラム開発は、誰がやっても一定の成果を出せる型ですが、スマートラウンドでは、開発者個人個人のパフォーマンスを「圧倒的に活かす型」を作り上げてきました。これにより、他社と比較した時に、ずっと少ない人数で遥かに巨大な規模のサービスを作り上げてきました。

また、技術的な課題解決も行いました。モジュラモノリス化により、各サービスをモジュール化することで、開発者が複雑さを気にすることなく安全に爆速開発が可能な環境を作り上げてきました。

また、「なぜ作るのか」という理解にも、会社全体として多くの時間を投資してきました。全社員が理解を深められるように、丁寧に機会を設計することで、前例がないサービスについて議論可能な土壌を作り上げてきました。

情報セキュリティ課題に対しCTO自ら手を動かしコミット

次に、事業について見ていきましょう。スマートラウンドは、プロダクトも会社も機密情報だらけです。セキュリティが重要な事業課題でした。

しかし、コロナ流行のタイミングで、固定オフィスを廃止し、全社員フルリモート勤務に移行するという決断をしました。そのため、前例がない状況でのセキュリティ対策を考える必要がありました。では、どのように対処してきたか？

ISMS（情報セキュリティマネジメントシステム）を、私が自ら手を動かして導入することで、自社にとって最適なセキュリティ体制を模索・構築してきました。それにより、全社を巻き込んでセキュリティが継続的に改善される体制を実現しました。また、プロダクトインフラも堅牢です。それが認められ、AWS認定ソフトウェアにもなりました。

エンジニアからの認知不足を「Server-Side Kotlin Meetup」の立ち上げで解消

最後に、組織について見ていきましょう。私の役割は、創業エンジニアとして最前線でプロダクトを作るという役割から、徐々にチームを作るという役割にシフトしてきましたが、その中でも採用において、前例がない方法で課題解決したので紹介します。

シリーズAが近くなった当時、私たちには採用力強化が必要でしたが、その時にあった課題は、「スマートラウンドが世間からあまり知られていない」ということでした。

みながよくやるアプローチは、自社コンテンツを発信するというものですが、今の時代は、超レッドオーシャンです。なので、私はまったく別のアプローチで課題を解決しました。

勉強会「Server-Side Kotlin Meetup」を立ち上げました。当社リードで、4社合同で運営しています。関わる人がみなハッピーになるようなスキームを組み上げ、Kotlinエコシステムにも大きく貢献してきました。

イベントは大成功し、日本最大のサーバーサイドKotlin勉強会になりました。参加者平均100名以上です。Kotlin開発元であるJetBrainsからもサポートを受けています。その結果、Kotlin好きの超優秀なエンジニア2名の採用につながりました。

以上、さまざま見てきましたが、共通して言えることは、私自身が経営者として前例なき課題に対して、自分自身の頭で考え問題解決してきたということです。

スマートラウンドは、今後も挑戦を続けていきます。ありがとうございました。

新機能開発のプライオリティ決めの判断軸は何か？

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

岩田真一氏（以下、岩田）：VCなのでいつも利用させていただいています。小山：ありがとうございます。

岩田：けっこうアメリカには、同じようなサービスがあって、以前私が勤めていたヨーロッパのファンドでも、違う管理ソフトを使っていました。やはりスタートアップ側も、情報を入力してもらうだけではなく、その場でコミュニケーションが取れたりすることが大事かなと思います。

僕らはシードファンドですが、だんだん投資家が増えてきた時に、あまりバックオフィスに彼らの時間を使ってほしくないなという思いがあります。そういう意味では、一度入力しておくとリンクをピュッと送るだけで済むので、私たちもすごく推薦しているプロダクトです。

質問したいのは、どういうプライオリティで新しい機能を決めているかということです。これは砂川（砂川大氏）さんと相談されて決めていくと思うのですが、けっこう僕らは、海外に出資していて、いろいろリクエストをする中で、英語のUI作ってもらったり、多言語対応してもらったり、その他通貨も対応してもらったりいろいろしてもらっているのですが、外国ではなかなか使ってもらうところまでいかなかったりするんですね。

ユースケースとしてはけっこう弱いので、（機能が）入るのはけっこう後になるんじゃないかなと思っているんですよね。そういったような機能の取捨選択、それから、スタートアップも法令も変わってきたりもしますよね。税制も変わってきたりしますが、そういうところのウォッチと、その反映の部分と、リクエストの吸い上げのところをどうされているのかを教えてください。

小山：私たちの全社でのKGI（Key Goal Indicator）は、プラットフォームとしての成功という部分で、実はそのプラットフォームの上に例えば株主総会とか資本政策とかのSaaSが乗っかっているという建て付けなんですね。

なので、国内にせよ海外にせよ、データを入力してくれるのであれば、極論SaaSは要らないという考え方もできます。

その中で、海外投資家の方がデータを入力してくれないというのであれば、それを無理のないようなかたちで入力できるよう現地の法律に則って作る必要があるよねという話をしていたりします。

各国によって法律が違ったりするのでデータ入力をしてくれない国を優先するのかどうかとか、そういった判断軸での優先度判断になると思います。

岩田：それは、砂川さんとみんなで決めているんですか？

小山：そうですね、その方針は合意しています。

岩田：ありがとうございます。

セキュリティとUXのバランスはどう考えているか

司会者：ありがとうございます。そのほか、いかがでしょう？

竹内真氏（以下、竹内）：：僕も投資家側で使わせてもらうことがあって、すごくsmartroundが好きなんですよ。すべてが1クリックでできるから。逆に1クリックでできるからすごく心配にもなるんですけど（笑）、「この情報けっこう重要だよな」と思うものも、メールからのリンクでそのままいけちゃうところがあって。

先ほどセキュリティの話が重要という社内の話がありましたが、そのあたりのセキュリティとUXって、なんとも言えない反比例をするところもあるじゃないですか。

小山：はい。

竹内：そのUXのあたりは、たぶん意志を持ってああしていると思うのですが、今のスマートラウンド社、そしてこれからのスマートラウンド社として、どのように考えているか教えてもらえますか？

小山：基本的にはやはりプロダクトオーナーである、創業者の砂川、あるいはCPOの加納（加納拓也氏）から、「こういう理想のUXを実現したい」というのが来て、それについて、私やテックリードが、「いや、セキュリティ的にこういう懸念があるから、ここまでは攻められるけど、これ以降は無理だ」とロジカルに反論するかたちなんですね。

そういったかたちで、今まではUXを追求してきているのですが、やはりユーザーの懸念として、例えばパスワードを入力できるようにしたいなどの要望もいろいろあるので、そういったものを吸い上げて、機能追加として実現していくかたちになるかなと思っています。

竹内：オプショナルにしていくみたいな。

小山：はい、おっしゃるとおりですね。

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

司会者：あと30秒です。

セキュリティにおける優先度の付け方やコストのかけ方は？

山本正喜氏（以下、山本）：セキュリティのところを少し聞きたいです。ISMSは基本だと思いますが、セキュリティって……ロードマップと機能開発とセキュリティをどう配分するかがすごく難しいと思っています。セキュリティっていくらでもできちゃうじゃないですか。

そこの優先度の付け方やコストのかけ方に考えがあれば教えていただけますか。

小山：はい、わかりました。プロダクトのセキュリティと全社のセキュリティを分けて考えています。プロダクトのセキュリティに関していうと、なるべくベーシックでベストプラクティスに則った構成にしようという考え方で、SREと合意しています。

背景ですが、プロダクトのインフラで攻めても、うちの会社にとって特に非機能要件として重要なのは、セキュリティぐらいなんですよね。同時アクセスユーザー数が少なかったりするので、パフォーマンスはあまり重要ではありません。

なので、とにかくベーシックな構成にすることで穴をなくそうという方針を合意していて、じゃあ、そのロードマップ上に何があるかという点で、AWS認定ソフトウェアというのを取ることでAWSベストプラクティスに沿えるんじゃないかという目標があったので取ったというのが、スライドの中でも紹介した内容になります。

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

司会者：ありがとうございました。ここまでは小山さんでした、ありがとうございました。拍手でお送りください。

（会場拍手）