初めまして、株式会社スマートラウンドCTOの小山（@doyaaaaaken）です。
昨年末、Startup CTO of the year 2022というイベントに出場させていただき、嬉しいことに優勝しました。
スマートラウンドの開発体制・組織に対して評価いただけた結果の優勝だと思っていますが、短時間のピッチでは詳細まで伝えきれない部分も数多くありました。
各スライドごとに掘り下げて語れる内容が色々あり、これまで行ってきた取り組みの裏に込められた思想や背景について紹介したいという思いがありました。
会社のフェーズが大きく変わりつつある今、これまでの取り組みの自分なりの振り返りも兼ねて、ピッチ資料について解説する一連の記事を書くことにしました。
なお🔗ピッチ資料はこちらでも公開しているので、よければぜひご覧ください。
（ピッチで実際に話した内容の全文はログミーさんが書き起こし記事にしてくださっていますので、お時間ある方はぜひそちらもご覧ください。）
【追記】
優勝ピッチ解説シリーズの他の記事はこちらで公開しています。👇
- 🔗【優勝ピッチ解説(2)】スマートラウンドでISMS認証を取得した背景および得た知見
- 🔗【優勝ピッチ解説(3)】Server-Side Kotlin Meetupが日本最大のサーバサイドKotlin勉強会になるまで
前提：スマートラウンドとはなにか
スマートラウンドは スタートアップと投資家の日々の実務を効率化するコミュニケーションプラットフォーム『smartround』 を開発・運営しているスタートアップです。
現在（2023年2月）時点で、3,500社ものスタートアップからご利用いただいております。
「スタートアップ・投資家の多対多の関係で生じる大きな非効率」を解消し、スタートアップ業界全体の生産性の底上げに貢献しようとしています！
スタートアップに対しては、株・ストックオプション・株主総会関連書類・財務情報など株式会社の根幹に関わる書類の管理・作成にまつわる業務を効率化し、投資家の方々とコミュニケーションを円滑に行うためのサービス群を提供しています。
これらの業務はスタートアップ成功の要でもある経営層がやることが多く、大きな負担となっています。
smartroundはこうした負担を軽減しスタートアップが事業に集中できる環境を作り出すことを目指し、会社として 『スタートアップが可能性を最大限に発揮できる世界を作る』 というミッションを掲げています。
また投資家に対しては、投資検討中・投資実行後のスタートアップの情報を効率的に管理するサービス群を提供し、スタートアップへの投資や支援により集中できる環境を作り出すことを目指しています。
スマートラウンドはこういった スタートアップと投資家のための業務効率化・データ管理のためのサービス群を1つにまとめて提供するプラットフォーム です。
ピッチ内でもこのスライドで、スマートラウンドが様々な業務効率化アプリケーションを包含したプラットフォームであることについて紹介しました
会社としては創業してまだ5年未満の若い会社です。
先日シリーズA資金調達を行ったばかりで、これからアクセルを踏み事業・組織拡大していき始めたばかりのフェーズの会社です。
テーマ：『スクラムを改変した独自開発スタイル』
ピッチ内で 「スマートラウンドはスクラムを改変した独自開発スタイルを行っている」 という紹介をしました。
そしてその結果として 「少人数で複雑かつ大規模なサービスを作ることができた」 と説明しました。
以下2画像がそのスライドです。
この「スクラムを改変した独自開発スタイル」に関しては何名かから興味を持っていただき、ピッチ後に質問をいただくこともありました。
この記事ではその取り組みについて紹介させていただきます。
以下の順で解説していきます。
- 少人数組織を志向した背景
- スクラムをどのように捉えているのか
- 具体的にどのような改変を行ったのか
- 今後も同じ体制を続けるのか
少人数組織を志向した背景
スマートラウンドは2018年5月創業で、できてまだ5年未満のスタートアップです。
ピッチ内でも紹介しましたが、直接的な競合がおりすでにマーケットができている領域ではなく、 ユーザニーズがあるかどうかわからない領域に対し模索しながら サービス開発を行ってきました。
そういった状況下においては 「新機能の高速な開発」 と 「頻繁かつドラスティックな仕様変更」 の両立が求められます。
特に仕様変更については、多くのユーザが定着した後にはリスクが高くてできないような、サービスの根幹レベルのドラスティックな変更もよくありました。
そういった状況下においては 開発スピードの速さだけではなく、機動力の高さも求められます。
そして 両者を両立するには少人数組織でなければ実現できない という理由で、スマートラウンドは少人数組織を志向していました。
「機動力の高さ」を実現するには少人数組織のほうがいいというのは、恐らく誰もが賛成するかと思います。
一方で直感に反するかもしれませんが「開発スピードの速さ」を実現する上でも、大人数組織より少人数組織のほうが優れているケースはよくあります。
昔からの名著『人月の神話』で語られているように、人月の"人"と"月"は置換不可能であり、プロジェクト（スタートアップの場合はプロダクト）の規模に見合わない人員を揃えてもかえって状況を悪化させてしまいます。
そのためプロダクト規模や組織体制を考えずにエンジニアの頭数をとにかく増やすと、コミュニケーションコストの高さゆえに生産性は下がり、できあがるプロダクトのクオリティも低くなってしまいます。
また人が不必要に多いと組織の機動力が低くなるため、せっかくスタートアップに飛び込んできた優秀なエンジニアのポテンシャルを活かしきれず、その結果として開発スピードも落ちてしまいます。
会社としての資金は幸い十分にあったのですが、プロダクトの方向性が固まり機能拡張していくフェーズになるまで採用系サービスをほぼ使わず、少人数組織で開発を進めてきました。
その間、 開発スピードが課題として挙がったことはありませんでした。
スクラムをどのように捉えているのか
開発体制を考える上でスクラムを下敷きにしたぐらい、個人的にはすごく参考になる開発フレームワークだと感じています。
しかしスクラムを実際にやったことある経験からも、 元のルールそのままでは融通が効かず、スタートアップには不向き だと感じています。
この章では元のスクラムのルールそのものについて、個人的にどのように捉えているのかについて説明します。
（あくまで個人的な意見なので、それは違うのではないかという意見も大歓迎です。）
ピッチ内で 「スクラムは誰がやっても一定の成果を出せることを志向した型」 だと説明しました。
言い換えると「厳密な方法論に則ることで属人性をとにかく減らし、安全な開発を行うことにフォーカスしたフレームワーク」という捉え方をしています。
スクラムの3本柱は”検査・適応・透明性”だとスクラムガイド（2020/11版）には書かれています。
この”検査と適応”があることで成果物の質の担保やメンバー教育ができ、”透明性”により現在および未来の開発メンバーに対して開発背景の記録を残し正確に伝えていくことができます。
このようにフレームワーク内に属人性を減らすための諸々の要素が上手く組み込まれており、 「人に依らず、安全に一定程度の成果を安定的に出せる」 ように設計されています。
開発現場がホワイトになるという意味では現場から好かれているフレームワークというイメージがありますが、 どちらかというと現場目線というより経営者目線のフレームワーク であり、特に大企業（その中でも特に内製組織がそこまで発達していない会社）に非常に向いているような気がします。
一方で スタートアップのように、不安定でもいいのでとんでもなく高い成果を上げる必要がある組織において、こういった特性は全くフィットしません。
またスタートアップに挑戦するようなチャレンジ精神の強いエンジニアは、自身の力を試したい意欲が強いことが多いため、 組織の枠に縛られず個人としてのポテンシャルを最大限に活かせる ような開発方式にする必要があります。
ピッチスライド再掲：スクラム開発は安定性と汎用性・再現性に特化
少人数組織にして機動力や開発速度を高めたとしても、スクラムの元のルールを忠実に守ったやり方では、開発者個人の"クリエイターとしてのパフォーマンス"は活かしきれないため 、改変してスマートラウンドに合った形にする必要がありました。
スクラムの基本的な枠組み自体は素晴らしいので参考にすべき点は取り入れつつも、あえて属人的にエンジニアの個人の技量を活かせる組織にしようとしました。
スクラムという組織としての汎用性・再現性がある”サイエンス”の部分と、開発者の個人技という”アート”の部分が両立した組織を目指そうとした のがスクラムを改変した背景です。
（ちなみに余談ですがソラコムさんも初期フェーズにおいては開発効率の最大化のためあえて属人化させていたそうです。「チームを先に作るのではなく、個人が高い技量で開発したのちその周りにチームを作る」という考え方だそうで、個人的には非常に共感できる部分がありました。（参考記事））
具体的にスクラムをどのように改変したのか
では具体的にどのように改変したのか説明します。
「改変」と言っているように、スクラムと共通する部分・異なる部分に別れます。
まずは共通する部分についてです。
共通点
スクラムには4種のイベントがあります（スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブ）。
スマートラウンドでも同じく、これらに相当するイベントを実施しています（※詳細な設計は微妙に異なります）。
スクラムにおけるスプリント単位のイテレーティブな開発リズムや"検査と適応"の概念は魅力に感じているため、これらのイベントを取り入れています。
それにより例えば以下のようなメリットが得られます。
- 1週間単位でリズムよく、開発および振り返りのサイクルを回せる
- チェックポイントとして、中間成果物について共有する機会が複数あることで（プランニング・デイリースクラム・スプリントレビュー）手戻りを少なくできる（スクラムでいう”検査と適応”の概念）
- 日次や週次での振り返りの機会（デイリースクラム・レトロスペクティブ）があることで、自己の内省やチーム内での相互フィードバックから学びを得られ、自己組織化が行われる
「スクラムとの共通点」についての、ピッチで使われなかったボツスライド
相違点
”検査と適応”については大いに取り入れつつも、スクラムの3本柱の最後の1つである "透明性"の部分については担保するには非常にコストがかかる部分なので大幅に省いています。
ここがスクラムとスマートラウンドの開発方式の大きな相違点です。
スクラムにおける"透明性"とは成果物が常に作業者以外の人にも確認可能な状態になっていることです。
その状態を実現するためには、長時間のMTGを行い認識をすり合わせ、きっちりした形でのドキュメント作成や文章のやりとりが必要となります。
属人性を低くするという意味ではそういった作業は効果があるのですが、前のほうで語ったとおり 属人性をあえて高める（つまり個人の技量に依る）ことが開発者のパフォーマンスを圧倒的に活かすためのポイント だと考えているため、なるべく省ける部分を省くようにしています。
どのぐらいの属人性であれば問題ないと考えていたのか、具体的な基準でいうと 「シニアエンジニアレベルの人が、機能開発を引き継ぐことが可能なレベルまでであれば属人的でも問題ない」 という考え方をしていました。
仕様の概要レベルの共有はチームに対して行うようにしていましたが、詳細すぎる部分の仕様や実装の詳細までは、特に共有する必要はなしという運用をしていました。
また詳細なドキュメントの作成義務はなく、コードレビューの必要可否も各エンジニアの判断に任せていました。
その一方で前述の属人性の基準のレベルを満たすために、以下の3点は非常に強く意識していました。
- プロダクトの仕様がざっくりでいいので理解できていること
- ソースコードがドキュメント代わりとなり後から他の開発者が読めばキャッチアップできること
- すべての議論を整理してまとめなおす必要はないが、 過去の個別議論をトレースできる よう参照リンクをきちんと貼ること
1については、プロダクトUXのブラッシュアップやご利用ガイドの充実の他、デイリースクラム内での仕様共有機会や、会社としてプロダクトを触る機会を設計することなどで対処していました。
2については、ソースコードの綺麗さや一貫性を非常に強く重視し続けてきました。 エンジニアの裁量でリファクタリングが常に行われるよう制度や文化として強く守り続けてきました。
3については「コミットから該当Issueを辿れるようにする」「Slackでの仕様議論はPR・Issueに貼り辿れるようにしておく」といったことをルールとして徹底していました。
「スクラムとの相違点」についての、ピッチで使われなかったボツスライド
補完的な制度
こういった体制を補完するために、特徴的な制度もいくつか設けていました。
色々あるのですが、以下の画像の2つについてのみ紹介します。
ピッチでは使われなかったボツスライドその3
1つめの「開発案件オーナー制」は「フルサイクルエンジニア」に近い考え方です。
開発案件のオーナーを決め（社内では"Epicオーナー"と呼んでいます）、そのエンジニアが中心となり他エンジニアやPdM・デザイナーとやりとりしたり助けを借りたりしながら開発を進めるスタイルです。
これは オーナーシップこそが個人の能力を最大限に活かす鍵だ と考えているからこその制度であり、この制度により開発者個人個人の力を最大限に活かすことを狙っていました。
2つめの「20%ボーイスカウトルール」は、 ソースコードがドキュメント代わりとなり「コードを読めば大体挙動がわかる」レベルのコードのクリーンさ を目指すためにあります。
組織の原理として、どこの組織でも機能開発のIssueが優先され、機能開発中に気づいたリファクタリングポイントはリリース後にやろうと思いつつも、結局リリース後は忙しくてやれない…、ということはよく起きているかと思います。
そういった課題を解決するため、エンジニア個人の裁量で特に事前のスプリント計画で話し合われていなかったとしても、改善できそうな部分を見つけたらすぐにそこに時間を割いて大丈夫だというルールです。
この制度によりクリーンなコードを保ち、生産性が高いかつ属人性が低い組織にすることができます。
今後の体制
1年ほど前までは属人性を高めることで機動力・開発速度を高めてきましたが、そのぐらいのタイミングでプロダクトとしてユーザが急速に増え始め方向性も固まってきたため、 組織として安定してスケールできるよう組織拡大をし始めています。
ユーザに価値を届ける機能を開発したいエンジニアが直近半年で2名すでに入社しましたが、やるべきことが定まりプロダクト規模に組織規模が追いついていない今、エンジニア組織を上手に構築しさらに人員拡大する必要があります。
しかし今後に関しても今まで同様、とにかく頭数を増やすのではなく、 開発者個人個人がなるべく裁量を持ち発揮できる”スタートアップらしい”環境を用意する ことが大事だと考えています。
以下の図のようなイメージで、組織として安定してユーザに価値を届けられる体制を目指すと同時に、個人の技量を最大限に活かせる場もあるような、 ”アート”と”サイエンス”を両立する組織 を目指していきます。
今後のスマートラウンドの開発組織の目指す方向性イメージ
世の中全体の流れとしてもここ最近の不景気により、これまで大量採用を進めてきたGAFAを始めとしたBig Techがここ1,2年で相次いで従業員を大量解雇しています。従業員数の2桁％レベルの解雇もざらにありました。
スタートアップ業界全体としても、できる限り大きく資金調達し可能な限り人を増やした後に事業を大きくしていく流れから、柔軟な状況に対応できる筋肉質な組織を作る流れにシフトしていっているように感じます。
スマートラウンドとしてはユーザに安全に価値提供し続けられるよう組織規模を拡大しつつも、1人1人が出す付加価値が高い組織を今後も目指していきます。
おわりに
いかがだったでしょうか。この記事が少しでも他のエンジニアの方や経営者の方の参考になれば幸いです！
記事はシリーズものとして時間がある際に書いていく予定なので、よろしければこのスマートラウンドのZennアカウントもフォローしてみてください。
最後に宣伝としてスマートラウンドの採用情報を貼っておきます。
昨年9月にシリーズA資金調達を行い、エンジニアもデザイナーもその他職種も全方位的に積極採用中です！
「今は転職する気はないけど、ちょっと興味を持ったので話を聞いてみたい」という方も歓迎ですので、ご興味ある方お待ちしてます！
採用ページ
会社紹介スライド（※時間がない人向け）
エンジニア組織紹介スライド（※時間がない人向け）
Discussion