見出し画像

ユニコーン企業のひみつ イベントレポート【MIDAS TECH STUDY #1】

はじめに

2021年7月1日に、ミダスキャピタル協賛のエンジニア向け勉強会を開催しました。

テーマの書籍として同年4月に発売されたオライリー・ジャパン「ユニコーン企業のひみつーSpotifyで学んだソフトウェアづくりと働き方」を利用しました。

当日は、エンジニアリングに関する各領域トップランナーの方々をお呼びし、彼らが経験してきた成功体験・失敗体験を交えながら、「良いプロダクトを作る」ための会社の文化、方針、制度運用を参加者を含めて議論を行いながら探るイベントです。
https://connpass.com/event/215773/

本レポートでは、約2時間にわたって行われたパネルディスカッションの中から、特に盛り上がった部分を抜粋してお届けします。
また、全編の様子は以下から確認いただけます。

当日の流れ


本編に先立って開催されたパネルディスカッションでは、自社あるいは自身の経験の中で印象深い企業の事例紹介と、今回のテーマ本に対する全体的な感想をお話ししていただいくことからはじめました。

スクリーンショット 2021-09-02 15.02.37

その後の本編では、テーマ本の流れに従って設定した5つのトピック(チームミッション / 組織体制 / 横断的な意思決定 / 情報の透明性 / 非日常業務)に関して、各自の考えや経験を伺いました。

ex. ディスカッションペーパーの一部

スクリーンショット 2021-08-11 0.12.41
スクリーンショット 2021-08-11 0.13.09

組織・人に関して


前半は主に組織や人に関するトピックとして「チームミッション」と「組織体制」を取り上げました。

まずはじめのトピックは「チームミッション」です。共通して強調されていたことは、「企業/プロダクト/個人の一貫したミッションを定めること、またそれを繰り返し伝えて全体に浸透させること」でした。具体的な運用方法や調整期間は組織規模や事業フェーズで異なっていました。

続いてのトピック「組織体制」では、各自の経験と「スクワッド、トライブ、チャプター、ギルド」といったSpotifyのチーム構築事例との比較、類似具体事例が紹介されました。 そして、書籍上ではあまり語られなかった「評価との紐付け」に関しても言及されていました。

やはり、どの企業も拡大していく過程で、事業割や機能割の組織設計を色々試し、学習しながら設計が行われている様子でした。なお、今回の本を参考にしてではなく、試行錯誤の中で結果的に似通ったことを経験されたということなのですが、成功事例・失敗事例・発展事例という形で各自から具体的な事例を紹介いただいたので、その一部を紹介します。

今村さん
前職のZOZOでSpotifyに類似したマトリックス組織形態を試験導入した際に、意思決定ラインや評価の煩雑さから混乱をきたしてしまい撤退を判断せざるを得なかった失敗談を紹介。「事前の責任設計の工夫があればもっとうまくいったかもしれない」という振り返りを次に活かしたいとのこと。

芹澤さん
SmartHRでも同形態での運用を行っており、過去に壁にぶつかったこともあるが権限をチームにしっかりと渡したことで、現在は順調に運用できているとのこと。 専門的なキャリアパスの設計などを重視し、評価は職能ベースで行われている。

豊島さん
ビジネスドメインによる分割だと、必ずしも開発を疎に仕切れないというよくぶつかる事例をベースに、チーム境界とシステム境界の悩みに対してどのようなアプローチでチーム組成の見直し検討を行ったか、その見直し判断にメンバーをどうコミットさせたかなどを紹介。また、Spotifyの事例については、単に組織形態だけをそのまま参考にするのではなく、書籍には書かれていなかった、システム側をどのようにマイクロサービスに分割していくかを調査し参考にしているとのこと。

そして、この組織設計の話題からコミュニケーション設計についても派生しました。企業としてテック活用強化を図るBuySellおよびSheepMedicalでは「情報の非対称性を埋める」ことをCTOの役割として強く意識していること、監督責任や執行責任をお互いに果たせるようにするための「権限委譲」のあり方の議論へ発展しました。

参加者からは、権限委譲に関連して 「CTOやCPOはプロダクトの意思決定にどの程度関わっているか」という質問がありました。その内容が興味深かったため、概要を紹介します。

今村さん
BuySellでは、どの山に登るかはCEOも関わるが、どういうモノを作るかはCTOに一任されており、PMと一緒に「企業としての方向性とずれていないか」を確認しながら進めている。

豊島さん
SheepMedicalは事業が医療分野ということもあり、新規事業の種などはドメインエキスパートであるCEOが見つけてくることが多い。しかし、どういうモノを作っていくかのデリバリーはCTOとPMに一任されている

芹澤さん
SmartHRではプロダクトの意思決定にはCEOやCTOはほとんど関与せず、月1でPMが策定したロードマップをベースとして様々なステークホルダーで議論しながら合議で決めている。「問題に直面している人の方がエレガントな解法が出せる」という考えで、基本的にはチームの判断を信頼している

制度・文化について

後半は制度・文化に関するトピックとして「横断的な意思決定」「情報の透明性」「非日常業務」を扱いました。

「横断的な意思決定」では特に様々なステークホルダーが関わる「開発ロードマップの作り方」と、それを実現するための「採用のあり方」の各社の事例を紹介していただきました。

テーマ本で紹介されていた「DIBB」のような決め方は、実践できる機会はあまりなく、そんな綺麗に決められないよね、という話から始まりました。その中で、各社の社風や事業フェーズ、経営の捉え方が表れていたので、一部を紹介します。

芹澤さん
「プロダクトの方向性を決める」ということは究極的には「アートの世界」。そのため、熱く議論しながら「コレがいいね」とみんなで泥臭く決めていくしか無いと割り切っている。前述の通り、メンバーも自由参加なてんやわんやな会議の中で作り上げていく。 0→1フェーズとそれ以外のフェーズで求められるスキルは違うと考えている。しかし、特にそこを分けて採用することは行っていない。やはり、社内で継続的に新しいことをはじめていくためにも、一定比率で0→1フェーズをやりたい社員を抱えておくべきと感じている。

豊島さん
現状はPMFフェーズなので「どこをコアにすべきか」を仮説検証的に決めていくことが非常に重要。手元にまだデータが集まっていない中で、各自の気づきをベースに議題が上がり、集まって議論する形態をとっている。

今村さん
「有限なリソースをどういった比率で割り振るのか」を考えることを大事にしている。また、そこで決めた比率をあまり気軽に変えないことで技術負債の蓄積を回避する、研究開発/新規事業にも投資を怠らない、などの大枠の方針を担保している。プロダクト機能レベルでの優先順位などはチームにまかせて決めてもらうようにしている。 例えば、新規事業だと事業自体が無くなる可能性がありえる。そのため、リソース配分の変化に対応しやすくするためにも、特定フェーズや特定のハードウェア技術に特化するのではなく、他事業でも適用可能な「何でもやりたい」メンバーを中心に採用する工夫を行っていた。

次のテーマの「情報の透明性」では、情報公開範囲の考え方から実践されているドキュメント管理の仕方まで、お互いの発言に被せる形で議論がどんどん広がり、各人のエンジニアらしい情報管理への強いこだわりが垣間見えました。そこで発表されたそれぞれの考え方と具体的に行われていることを紹介します。

今村さん
株価に影響を与えるようなインサイダー情報を秘匿するのはしょうがないが、基本的にはオープンであるべき。Slackもプライベートチャンネル禁止で運用するようにしたが、浸透させきるまでの労力や時間は必要だが、結果として非常に有効だった。 前職ZOZOではConfluence(一覧性が優れているということでGoogle Workspaceと併用)にドキュメントを絶対残すことを徹底していくように変えていった。BuySellでもテクノロジー部門以外では、まだまだドキュメントを残す文化が浸透しきっていないので、同様の方針で変えていくつもり。

芹澤さん
公開内容/範囲については今村さんと同様の考え。 経営層の「説明責任」がよく取りざたされるが、サイボウズさんが提唱している「質問責任(https://teamwork.cybozu.co.jp/blog/teamwork-explain-ask.html)」 という両方面からのアプローチが重要と考える。 エンジニアリング文化が先にあった企業なので、「ドキュメントを残すようにする」といったことで苦労した記憶はなく、ビジネスサイドもどんどん書いてくれる。 常に「より良いサービスはないか」ということで3〜4回ドキュメント管理サービスを引っ越している。なお、今はDocBaseを利用中。書くモチベーションを上げるための工夫は、Slackに更新を流して見られるようにしたり、「ポエム」というタグで自分の考えを発信する慣習をつけたり、意識するようにしている。一方で、検索性は永遠の課題だと感じている

豊島さん
公開内容/範囲については今村さんと同様の考え。ドキュメントを残していくべきということも同様に大切にしている。 意図しない情報の非対称性へのケアは大事。一方で、「公開されている状態」なだけではなく、「ちゃんと使えるようにアクセシビリティを担保する」ことも大切である。エンジニア観点でいうとADR(architecture decision records)などは非常に有効な仕組みだと考えている。 ドキュメントを書き続けてもらうためのモチベーション維持も意識していた。「良い記事を紹介してくれたら褒める」文化もある。

それぞれが大切にしていきたいこと


最後に各人が文化において大切にされていることをご紹介いただきました、皆さん経営者として特定個別の何かというよりは、メタな視点から文化を醸成/維持させていくためにはといったお話をいただきました。


豊島さん
文化がこれからも変わっていくだろうからこそ変化を楽しむ。ダニエル・ピンクの「モチベーション3.0」にあるような「自分で自分のやることを決められる、やり方を改善できる、やっていることに意味を見いだせる」を大切にする

芹澤さん
文化は団結力を生み出すための概念。「ウチらしさ」「ウチっぽさ」を全員がなんとなく共通認識として心に持っているという状態を保つために経営から率先して「らしさ」を体現し続ける

今村さん
「HRT」「メンバーに成長実感を持ってもらう」「足元ではなく未来を見せる」の3つを忘れない

まとめ

ミダスキャピタルが協賛する初めてのイベントでしたが、非常に長丁場で有益なパネルディスカッションをお届けすることができました。登壇者・参加者の皆様ありがとうございました。

「当たり前と思われることをどこまで当たり前にできるか」が企業やプロダクト、テックの強さにつながっていくということを感じた会でした。また、どの企業に関してもまだまだ成長を続けている最中ということもあり、「とにかくやってみる、ダメなら変えてみる」ということを大事にされていることも印象的でした。

実践知と本音も交えた意見が交わされ、非常に濃い時間を過ごすことができました。