for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

【フォースタ テックブログ】「ユニコーン企業のひみつ」を読んで自社の開発組織と比べてみた

こんにちは。サーバーサイドエンジニアの速水です。
今回は、「ユニコーン企業のひみつ――Spotifyで学んだソフトウェアづくりと働き方」という書籍のレビューを投稿させていただきます。

www.oreilly.co.jp

フォースタートアップス(以下、フォースタ)でも、スクラムをベースにしたアジャイル開発を行っているわけですが、事業環境や組織は日々変化しており、どう変化に対応していくべきなのか、悩みは尽きません。
ユニコーン企業のひみつ」は、SpotifyAmazonGoogleFacebookといったユニコーン企業はどうやっているのか?というのをヒントに、何万人もの従業員を抱える企業がなぜスタートアップのような組織・環境であり続けられるのかを紐解いていく内容となっており、印象に残ったところ、自らに引き寄せて考えたこと、感想をまとめました。

今回の書評は、弊社の村林(@bayashimura)がこちらのツイートを見つけたことがきっかけになっています。

村林はフォースタの開発組織であるテックラボのアジャイル旗振り役として、振り返りやチームビルディングを浸透させてきました。社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」を開発しているチームでは、振り返りのファシリテーターを交代で行うなど、スクラムの要素を取り入れながら開発プロセスの改善に努めています。

tech.forstartups.com

tech.forstartups.com

不確実性だらけだからこそ学習が大事

スタートアップで取り組むソフトウェア開発は、不確実性だらけであると語られています。

「答え」が既にわかっているというつもりなら、それは思い込みだ。

わからないから、たくさん実験をして、失敗をすることもあり、ただ毎回インパクトと価値を計測しているから、前に進んでいける。わからないから、「答え」を見つけるために、各自が考えて、手を動かして、学習していかなければならない、と説かれていました。

自らに引き寄せると、やはり普段の仕事の内容は、「答え」がわかっているとは言えません。議論した上で「この方向だよね」という合意はあれど、それが絶対に正解とは言い切れないし、アプローチ方法も様々です。

テックラボでうまくできていると感じるのが、アプローチへの寛容さと、失敗に対する心理的安全性(失敗をしてはいけないという思い込みは払拭する)です。フロント、バックエンド、様々な視点から実現方法を考えるのはもちろん、そもそも手動の作業で同じような物を見せて解決できないか、ヒアリングして課題をもう少し深堀りたい、といったこともフラットに出し合うことができます。失敗はしないに越したことはありませんが、バグが入ったまま機能をリリースしてしまった、レビューでバグを見逃してしまった、という時もあります。そういった時に、チーム全体で今できるリカバリ策を考え、対応する姿勢があるからこそ、苦手な領域の開発であっても挑戦してみよう!という気になります。

一方、インパクトと価値の計測においては、まだまだ課題があるように感じています。社内向けプロダクトは、ビジネス上の価値とプロダクトの価値がぴったり一致はしないため、指標の設定、評価には苦戦しています。

自律、権限、信頼

ユニコーン企業ではアジャイル開発が企業文化に染み込んでおり、わざわざスクラムマスターを置いて形式としてのスクラムをやる必要はないようです。とても自律したチームであり、信頼があるからこそ、権限もしっかり持っています。ですが企業としてバラバラにならないための仕組みとして、"カンパニーベット"を設定するということもやっているようです。
※カンパニーベット(Company Bet):会社が取り組みたい重要事項を、終わらせたい順に並べたリスト。小さな目標ではなく、大きな取り組みに関するもの。

企業においてチームに権限を渡すというのは、そう簡単なことではないと思います。しかし、学習のスピードを出すためには必要なことでもあります。本書の中では経営側の視点で「現場の言い訳を取り除く」と表現されていますが、現場としても権限をもらう以上、本当に自分ごと化できないと辛いことになりそうです。渡す側、もらう側、双方の信頼あっての権限移譲で、それがあっての自律したチームなのだと理解しました。

また、見習いたいポイントとして、データ(数値、ファクト)と解釈(どういう意味を見出したか、仮説)を、フレームワークとして切り分けている点がありました。本書では、DIBBという、やるべきことを系統立てて検証するための意思決定フレームワークが紹介されており、データ(Data)、インサイト(Insight)、確信(Belief)、ベット(Bet)に分解して、整理されていました。
私はこれまで、人への伝わりやすさという観点で「主張+根拠づけとしてのデータ」をまとめてとらえることが多かったのですが、学習の最中ということを考えると、データと解釈をわかりやすく分けて共有した方がチームとしての学習は進むのかもしれません。私も意識してやってみようと思います。

まとめ

著者Jonathan Rasmusson氏のSpotifyでの経験を中心に、ユニコーン企業におけるソフトウェア開発で組織として気をつけていることがわかりやすくまとまっている1冊でした。特に、アジャイル開発におけるスクラムの形式的イメージを強く持っている方にとっては、それが浸透した先を知れる内容となっているので、面白いと思います。

フォースタではエンジニアを募集中です!
開発スタイルや雰囲気はもちろん、事業や技術スタックに関するお話もさせていただきますので、ご興味をお持ち頂けましたら、下記「話を聞きに行きたい」ボタンより気軽にエントリーいただければ幸いです。