【2022.09.15 イベントレポート】スタートアップは守破離の破をするな / Tebiki
皆さん、組織やカルチャーづくりにおいては非常に悩みも多く、手探りなこともあるのではないでしょうか？
特に、スタートアップフェーズにおいての組織やカルチャーは非常に大きなissueです。そこで今回はスタートアップの中でも既存産業DXをリードしている5社によるLT形式で様々な事例をご紹介するイベントを開催しました。
こちらではイベントで紹介した内容を各社のレポート形式でご紹介させていただきます。様々な企業の取り組みをぜひ参考にしてみてください。
今回は、Tebiki株式会社 渋谷氏のLTをご紹介いたします。
Tebiki 渋谷和暁氏（以下、渋谷）：Tebiki株式会社の渋谷です。弊社は現場教育、デスクレスワーカーと呼ばれる倉庫や工場で働いてる方たち向けの研修プラットフォームを作っている会社です。私はtebiki株式会社でCTO & Co-Founderをしています。会社は2018年に設立しました。最近はマネジメントと採用がメインになっております。本日は「スタートアップは守破離の破をするなという」というテーマで、お話させていただこうと思います。プロフィールの画像は4年くらい前の写真で、結構シュッとしてますね（笑）
規矩作法守りつくして破るとも離るるとても本を忘るな
というわけで「規矩作法守りつくして破るとも離るるとても本を忘るな」と、急にこんな謎の短歌から始まります。
多分皆さんもご存知だと思うんですけど、守破離は、千利休の教えをまとめた和歌から引用された言葉です。茶道など芸の道における師弟関係のあり方の一つで、それらの修行における段階を示したものらしいです。
「守」は、師の教えや型を忠実に守って確実に身につける段階で、「破」は「守」を極めた後に自分で工夫して型を発展させる段階のこと。「離」は型から離れて独自の新しいものを生み出し、確立させる段階と言われています。
ここで弊社の例をいきなり出させてもらいます。以下の内容は結構あるあるだと思いますが、弊社ではこういうことを過去にしてました。
無自覚に守をせず破をしていた
これ実は、無自覚に「守」をせず「破」をしていたんですね。
どういうことかと言うと、それぞれ以下の通りになります。
ユーザーニーズを見越してあらかじめ企画を開始しよう
実装の半年前に企画したので「よし実装するぞ」ってなった時、既にニーズが変わってしまってる
オンコール対応はインフラが最も得意なメンバーに任せよう
CTOが面接中にサーバーに問題が発生しても誰も手を出せない
実際に過去の面接中に「すみませんサーバーやばいんで、ちょっと一旦抜けます。」みたいなことをしていました。
このドメインは副業の方を専任として切り出そう
社内メンバーは誰も把握していないドメインの機能が出来上がってしまった
これらが結果として起きてしまった出来事です。これが「破」ですね。
開発組織の守とは
実は開発組織にも「守」はあります。開発組織の「守」とは、先人達が考えたプロダクトを開発する組織のための型で、エンジニア風に言うとフレームワークです。
SOLID原則とか開発そのものに対する「守」はよく知られていると思いますが、組織に対する「守」も、もちろんあります。
幾つかありますが、今回はScrumとTeam Topologiesを挙げさせていただきます。
Scrum
Scrumはご存知の通り、アジャイル開発プラクティスの一つで開発手法ですね。これは組織構造に強く依存すると思います。
例えばウォーターフォール型の組織に取り入れることは、結構難しいと思っています。
あとはSpotify Modelもアジャイル開発プラクティスの一つです。
Team Topologies
Team Topologiesは、最近よく聞くEnabling teamと言われるやつで、ざっくり言うと組織構造のフレームワークそのものです。異なる職能のチームをタイプ別に小さく分けて、その上でどうコミュニケーションしていくかというものです。
開発組織の「守」に準拠してみた
この2つを開発組織の「守」に準拠してみました。
そうすると、さっきの例で言うとそれぞれ以下の通りになります。
Scrumに準拠してスプリント直前にリファインメントしよう
オンコール対応はSteram-aligned teamに任せよう
Team Topologiesのことで、プロダクト開発をしているチームの人たちそのものに任せようということです。
副業の方のタスクはPlatform teamのものをお願いしよう
これもTeam TopologiesのPlatformや基盤的な開発をお願いする形です。
これらがどうなったかというと、
Scrumに準拠してスプリント直前にリファインメントしよう
直近の課題に絞って議論できるようになった
オンコール対応はSteram-aligned teamに任せよう
開発cのフローを回してチームが学習できるようになった
副業の方のタスクはPlatform teamのものをお願いしよう
むしろドメインとは疎の作りでプラットフォームを作れるようになった
このように、準拠することでめちゃくちゃメリットがありました。そして、改めてこう振り返ってみると、「守」のどこが重要だったかというと、やっぱり組織に対しての役割が明確に定義されているという点がとても良かったなと思っています。
組織に対しての役割が明確に定義されている
例えばScrumだとStakeholdersとかScrum masterとか、Team TopologiesだとStream-aligned teamとかPlatform teamとか。こういった形で明確に役割が定義されました。
説明もしやすいですし、役割の期待値も説明できるので、例えば採用のタイミングで「あなたにはEnabling teamのメンバーを期待してます。」と明確にに説明できます。
後はもう既に所属してるメンバーに「君達はStream-aligned teamだからこういうことを期待してるよ」と。また移譲もしやすくて。やっていることが定義された役割で分解しておくだけでも、その分解した役割を「他の人にお願いしますよ」という形で移譲しやすく、すごく重要だと思ってます。
あとは困ったら本に立ち戻れるので、もう先人たちの経験は洗練されているし、事例も多いので。改めて振り返ると役割が定義されてるってことはめちゃくちゃ重要だなと、今はすごく思っています。
守り尽くせ、本は忘れるな
「守り尽くせ、本は忘れるな」ということで、最近はチームメンバーにもさっき出てきたスクラムの本を読んでもらったり、これからチームメンバーみんなにはチームトポロジーの本を読んでもらったり。
やっぱりメンバーみんなで本に立ち戻って行動していくことを、今後もやっていこうと思っています。
Q＆A
ファストドクター 宮田芳郎氏（以下、宮田）：ありがとうございました。一つ一つのお話もわかりみが強かったです。抽象度高めな質問ですが、「破」から始める順序がよくないということはすごい共感するんですが、
この先は、引き続き「守」をもっと固めていくのか、今度は「破」をいくのか、どういう風に考えていらっしゃるのでしょうか。
渋谷：いかに支柱をチームメンバーに守り続けてもらうかっていうのはすごい重要だなと思っています。なのでチームメンバーに対して最近やろうとしたのは、課題図書を決めてメンバーが入ってきたらオンボーディングで「この本を絶対読んでくださいね。」という形でチームメンバーの「守」の部分を統一化していくところを、引き続きやっていこうかなと思ってます。
宮田：なるほど。ありがとうございます。もう1つお伺いしたいのが「ドメインとは疎の作りでプラットフォームが作れた」というお話しの部分です。どういう状況かちょっと教えていただきたいなと思いました。
渋谷：それまでの副業の方に、事業ドメインの機能そのものを作ってもらっていました。今でいうと、例えばCI/CDのところをお願いしています。ドメインではなくどちらかというとプラットホームの形なので、これはもうドメイン関係なくお願いできるなと思います。単純に、エンジニアが喜ぶ機能を作ってほしいっていう形でお願いできるようになりました。
ご清聴いただきありがとうございました！
是非また次回のイベントでお会いできることを楽しみにしています。
ここまでご覧いただきまして誠にありがとうございます！
「守」を大事にし、「本」という全員に共通するものを持ちながらプロダクト開発を加速するTebiki社。なにかお持ち帰りいただけるトピックスがあれば嬉しいです。
Tebikiにご興味をお持ちの方はこちらをご覧ください。
Startup Tech Live
Startup Tech Liveのテーマは「エンジニア組織のグロースに必要な知見の流通」です。
運営元であるGlobis Capital Partnersは、国内巨大産業のアップデート（DX）や日本発グローバル展開を志すスタートアップへの投資を行うベンチャーキャピタルです。我々は、国内産業の更なる発展の可能性や、それを強力に推進するテクノロジーの力を信じています。
Twittter: https://twitter.com/gcp_byvc
connpass: https://gcp-tech.connpass.com/
この記事が気に入ったらサポートをしてみませんか？