【緊急企画】Book Talk：『ユニコーン企業のひみつ』をぼくたちはこう読んだ！

ご恵投いただいた『ユニコーン企業のひみつ』（オライリー・ジャパン）が素晴らしかったので、早速もう1冊購入し、当社の辣腕プロダクトマネージャーとQAブレインが感想をシェアしました！

染谷洋平 （バナー写真右：以下、S）：
グロービスのプロダクトマネージャー。テックブログ運営チーム。
河原田政典（バナー写真左：以下、K）＠mkwrd：
グロービスのQAブレイン。テックブログ運営チーム。

※バナー写真を撮影するときのみマスクを外しました。
※対談にあたっては十分な距離を取り、感染に配慮して行っています。

ベットの話

S：『ユニコーン企業のひみつ』は、すごく良い本だね。この対談のために速攻で買って読んだけど、楽しくて、全然苦にならなかった。

K：手軽に読めるから、会社のみんなにも勧めやすいよね。200ページに満たない紙幅にいろいろなことが書いてあるけど、どのあたりが気になった？

S：「5章　ベットで方向を揃える」は、今のうちの組織（デジタル部門）に必要な考え方だと思ったかな。

K：あー、ぼくそこは正直、イメージできなかったんだよね……。

S：うちの会社でも、組織の優先度に応じて柔軟に対応できるといいんだけど、なんか壁があって、一部の組織しかその高い優先度の課題に取り組めない……みたいなことが起こっているんじゃないかな。だから、この話題がうまくイメージできないのかもしれない。

K：そうなのかー。ぼくたちはちゃんとベットできてないのかもなぁ。

S：ベットの話で「なるほど」と思ったのは「大きなベットを2つ同時進行させると高くつく」（P. 84）というところだね。トッププライオリティ2つってのはダメなんだなっていう。

K：プライオリティーは「最優先」で1つってことだからね……まぁ、今うち最優先が3つくらいある気がするんだけど（苦笑）。良い・悪いではなく、なにもかもやろうとする、大企業のような考え方になっているのかもね。

HRポリシーとの親和性

S：一方で「1章　スタートアップは どこが違うのか」に書かれている情報開示・信頼・権限移譲みたいなところは、当社のHRポリシー（人事の考え方）でも強調されているところだね。「世の中はチェンジしていく」というのを前提にしていて、外部環境の変化に応じて自分たちも進化していかなければならないと考えている。そこで大事になるのがスピードだね。

K：部門間の調整は上位組織で扱うけど、部門内については部門長に任される形でエンパワーメントされていて、現場で意思決定できるようになっているよね。その中で、Open & Connectといって、部門ごとの意思決定を妨げないように情報は開示していきましょう、という考え方を持って進んでいる。

S：このあたりはSpotifyと似ているなぁって感じた。というか、当社グロービスは1992年にできた教育事業会社だから、むしろ自分たちの方が先駆けなんじゃないかなって思ったり（笑）。

K：堀さん（当社グロービスの代表 @YoshitoHori）の考え方も、昔からオープンでフラットな組織を良しとしていて、それが会社の制度として反映されている感じだね。

S：堀さんは代表でありながら、上位下達よりもフラクタルな組織を志向する人だからね。

トライブにはまだ早い？

K：トライブ（マトリクス組織）っていいよねって、みんなで考えてた時期があったよね。読書会とかもしたなぁ。

S：や、今のうちの組織（デジタル部門）でそれをやろうとすると、人が足りないんじゃないかなって思っている。4.5節で横のつながりであるチャプターとその利点が説明されているけど、3人やそこらじゃ旨味が足りない気がするんだよね。1人が忙しかったら、残り2人でチャプターを推進しなきゃならないし、その2人の人間関係が悪かったら何もコラボレーションが起こらないからさ。
だから、もうちょっと組織が大きくならないと、こういうマトリクス型の組織ってワークしないかもね。ぼくたちにトライブはまだ早いのかもしれない。それはまったく否定的な意味合いではなくて、むしろ採用を頑張らないといけないってことにつながるんだけど。

K：ぼくたちQAチームは部門横断の支援チームだから、ちょうどチャプターの形で仕事をしているんだよね。ポリシーとしては、プロダクトに関わるときに必ず2人以上参画することにしているんだ。だから、マトリクス型組織の図に必ず1人ずつしか書いていないことに、ぼくは違和感がある。まぁ、しょうがないんだけどね。場合によっては2つ以上のプロダクトに、それぞれ2人以上ついたりするわけだから、絶対数とかスキル面の幅広さでは、やっぱりQAエンジニアはまだまだ足りないんだよね。それだけプロダクトの数がたくさんあり、要求も異なっているんだもの。

S：カンパニーベットが（笑）。

K：そうそう（笑）。

S：ぼくが見ているプロダクト開発でも、絶対1人にはしないようにしていて。属人化するのを避けるって意味もあるけど、それ以上に、1人だと動ききれないときに止まっちゃうんだよね。
「この開発、ちょっと無理だなー」って思ったときに、2人だと相談しながら調整したりしやすいんだけど、1人だと「できないのは自分の能力が低いからじゃないか」ってモチベーションが下がっちゃったりする。

K：（開発者だった新卒時代を思い出して遠い目）

S：あと、業務委託の方も多いのもあるかな。1人だとリスクを避けてできる範囲のことをしようと考えるのが普通だし。

K：難題に向かってチャレンジしてくれるかっていうことだよね、2人だとハードルが下がるし、実際にやってみたら楽しいと思うことも多いんじゃないかな。レビューも頼みやすそう。品質向上の基本はQAエンジニアの号令ではなく開発者のアクティビティだから、この点は大きい。良いものを届けようって意識を共有していないと難しいよね。

文化と「らしさ」

S：他の書評記事ではあまり取り上げられない章の話をしたいな（笑）。

K：その意味だと「9章　文化によって強くなる」が興味深かったんだよね。

S：「シンプルさとは究極の洗練の形である」っていうAppleの牛の絵の話がおもしろかった。

K：文化というものの一側面がよく表れているところだと思うね。「シンプル」っていう一般名詞について「シンプルってなによ？」への答えを、自分たちの言葉で表現できること。

S：文化って、そこに集まっている人たちによって形作られ・醸成されていくものじゃん？　9.6節ではスウェーデンっぽさって話が出てくるけど、じゃあ日本っぽさってなんだろうとか、グロービスらしさってなんだろうとか、考えるよね。

K：「うちはアジャイル開発をやってます」って企業はたくさんあるけど、十把一絡げにレッテルを貼ったりはできなくて、それぞれ違う良さとか問題点を持っているんだよなぁって思うかな。アメリカのスタートアップと日本のスタートアップは前提からしてもうまるっきり違っているよ、とかね。

S：「スウェーデンにはサーバントリーダーシップが実在する」（P. 147）って書いてあるけど、このあたりもスウェーデンの人たちの国民性というのか、ナチュラルにそういう考え方をしているってことの表れなのかもなって思う。

K：スウェーデンの生活様式はLagom（ラーゴム：多すぎず、少なすぎず。ちょうどいい）と言われるとP. 149に書いてあるけど、日本の生活様式はどんな言葉で表されるかな？

S：「出る杭は打たれる」か。

K：それはちょっと（笑）。

S：「郷に入っては郷に従え」というのもあるよね。自分の信念というより、その土地ごとの考え方に従おうっていう。大自然の前には人間なんてちっぽけなんだから、協力して生きていこうっていう農耕民族っぽさがあるね。

K：興味深いところだね。無視できないと思う。QAチームとしては、ぼくは「品質文化」の研究を進めているし、実際にそれを作ろうと動いているけれど、文化を醸成するって並大抵のことじゃないってつくづく思ってる。

認識していないものを考えることはできない

S：「7章　生産性向上に投資する」もよかったね。特に後半の社内オープンソースとか、フィーチャーフラグとか、リリーストレインとか。

K：フィーチャーフラグはうちでも取り入れているよね。でも違いがあって、ぼくが見た範囲だと、完成した機能のON・OFFを切り替える使い方をしているなって。これが、本に載っているリリーストレインの図（P. 113）だと、未完成の機能もフィーチャーフラグをOFFにした状態でリリースはされていて、後続のリリーストレインで完成するっていう感じになっている。フィーチャーフラグを活用しきれていないのかなぁ。

S：最近MBAの授業で企業家リーダーシップっていうのを受けていて、そこで認識していないものを考えることはできないんだっていうのを勉強したんだよね。人間同士のコミュニケーションで誤解やコンフリクト（衝突）が生じるときって、この認識の相違が原因ってことがすごく多いんだって。フィーチャーフラグの使い方がまだまだ限定的になっているのも、最初に導入を提案した人の考えていたことと、実際に手を動かして開発する人とで認識が違っているのかもしれない。そうなると「みんなで考える」ってことがだんだんできなくなっちゃうかもなぁって思う。認識している人とそうでない人で溝ができて「ぼくしかわかっている人はいないんだ」みたいに孤立しちゃう、みたいな。

K：あぁ、それは悲しい。

明らかにプロジェクト型になっている件

K：そもそもフィーチャーフラグとかリリーストレインって、実験をするための仕組みなわけで、そう考えると、ぼくたちは実はまだまだ実験できていないのかもしれないね。

S：「2章　ミッションで目的を与える」にある、プロジェクトとミッションの比較表（P. 25）を見てみるとわかるけど、うちらは結局プロジェクトをやってるんだよね。
「予算がある」確かにある。
「終わりがある」確かにある。
「短期間」はミッション型ほど長くないから当てはまる。
「プロジェクトマネージャーがいる」うん、なにかしら責任を取るポジションの人がいるね。うちだとプロダクトオーナーが多いかな。
「開発だけして引き継ぐ」は、ちょうど引き継いでるのがある（笑）。
「完成したら解散する」のは次の開発に向けて再編成するからだし、業務委託さんで開発の切れ目で去っていく方もいらっしゃるからね。
「計画にフォーカス」はめっちゃ当てはまる。進捗報告とか。「オンスケです」って言えればいいけど「あっ、やばいです。見積もりしっかりします」なんてケースも多い。
「期待に応じることが価値」は、MBOやOKRに入っていないからちょっとできないです、みたいな話が出るとか。
「トップダウン」は……結構色濃いね。

K：ぜ、全然キラキラしていない内情が明らかにされていく……！？（笑）

S：や、伸び代があるってことですよ。これをどれだけアプローチして変えていけるか。

ロードマネージャー

K：染谷さんのチームは、プロジェクト型の悪い特徴である「力を奪う」とか「融通が効かない」って状態に陥ってない気がするんだけど。

S：かなり気をつけてチームを回しているからねぇ。こういう悪い状態に陥ってしまう原因のひとつは、プロダクトの責任者同士が頻繁にコミュニケーションをとっていないことがあるんじゃないかなって思っている。その点では、P. 82のロードマネージャーの話が印象的で、うちでももっと部門単位でしっかりとマネージする動きが出てきてもいいと思うんだよね。

さぁ、ぼくらはどうする？

K：この本は「Spotifyではこうだけど、読者の会社ではどう？」っていう、問いを投げかけてくれているけど、染谷さんは今後トライしていきたいことはある？

S：さっきのロードマネージャーの話に絡めて、プロジェクト責任者間の連携はもっと進めたいな。ベットするときにコンセンサスが取れなくなるからね。
もうひとつ、1チームだけが信頼感醸成とか権限委譲とかやっていてもレバレッジが効かないよね。だからこの本を啓蒙したりして、浸透させていきたいよね。

K：社内読書会はひとつ良い方法だと思うね……あぁ、でもそれだと傾向として、エンジニアやマネージャー陣は参加しやすいけど、全体に広めるには弱いか。

S：コロナになってから部門全体を巻き込んだ活動はしにくくなっているからね。その前は部門全体で1泊2日の合宿をしたりっていうこともしていたよ。まぁ、つまるところ、どこかで成功するチームが出て、そこで注目されるっていうのがナッジ（行動経済学の用語。自身にとってより良い選択を自発的に取れるように手法・デザインのこと）になるっぽいかな。成功パターンを積み重ねていくのが多分王道なんだろうね。

K：GWは家にこもって、何度か読み返そうかな。もっと考えを深めていきたい。こういう本が日本語で読めるというのは幸せだと思う。これは、ぼくが文系脳で、技術書だけじゃなくて、古代ギリシアも含めた世界中の文学を日本語で読めるっていうことにも通じるんだけど。

S：確かにね（笑）。日本は世界の文化のハブになっている側面があるかもね。
この記事ではぼくたちだけで喋ったけど、他のメンバーがどう思ったかも聞いてみたいなぁ。

成功パターンを作り上げる仲間たちを募集しています！

グロービスのデジタル部門では広い職種にわたってエンジニア採用を強化しています！　『ユニコーン企業のひみつ』に刺激を受けた皆さま、この記事で対談した辣腕プロダクトマネージャーやQAブレインと直接話をしてみたい方、まずはカジュアル面談はいかがでしょうか？
ご希望の方はお気軽にこちらの採用URLか、@mkwrdまでどうぞー！

https://recruiting-tech.globis.co.jp/