TL;DR
ネガティブな話が多く、読むのしんどかったが、それも含めてあの時大変だったことがよくわかる本だった。
あの時Twitterに起きていたこと
全体的にネガティブな雰囲気のある本で読んでいてしんどかった、というのが読後の感想。
ただ、それも著者が経験したことを考えるとそうなるかな、と思った。こういった経験を本にまとめてもらえるのはありがたい。経験のある著者でもしんどかった、というのだから、よく聞くようにだいたいの人にとってイーロン・マスクと働くのはしんどいのだろう。
本書で描かれているイーロン・マスクはXで見たり、ネット記事で読んできた内容と差はなかった。まあそうだろうな、という内容がほとんどだった。だから、そういう意味では驚きはなかった。
イーロン・マスクと働くというのはどういう感じか、ということは、雇われ側というか部下視点だどどうか、というのは本書を読むとよくわかる。一部本書から引用する。
イーロンのような独裁的なリーダーというのは、その良さが生きるときとそうでないときがあると思います。独裁者が「裸の王様」になってしまい、自滅していくときというのは、まわりの人間とのコミュニケーションに共感が伴わなくなり、深い考察がなされなくなるのではないかと思います。
イーロンは、決してコミュニケーションが取れないわけではありません。難易度は高いが、正しい情報を伝えれば、きちんと正しい判断をしてくれるはずなのです。
引用
社員数が少ないその辺のベンチャーなり中小企業ならこういう独裁的な経営者というか創業者がいることで起きるこういう状況はまあよくありえるだろうなと思う。そして、そういう組織でのコミュニケーションはこうなるだろうなと。それがはまればどかっと成長したりもするだろう。よくいえば組織の文化が良かったんだね、という話になるんだと思う。でも、それがはまらなければ、裸の王様になり、自滅する。
ただ、Twitterみたいなグローバルな企業でこれはしんどいだろう。見聞きしてた通りではあるけど、雇われる側としてのストレスはすごい。その辺のあたるかどうかわからないベンチャーや中小企業のような環境で働くことを想定して雇われてないだろう。だから、組織に合わない、指示にコミットできない、という理由で辞めていくことは自然だと思う。
Twitterのようなグローバルなサービスを展開する企業でこんな災害級のカタストロフィが起きたらどうなったか、という話を渦中にいる人の視点からこういった話を聞けるのは貴重だ。想像していた通りだな、という気はするものの、勉強になった。少なくとも僕がこの渦中にいたらサクッと辞めてただろうと思う。多分。
グローバルなソフトウェア開発の難しさ
本全体で著者が伝えたいことを踏まえると小事なことなんだけど、仕事柄気になってしまったので一つだけ。
著者の以下の話はグローバルにソフトウェア開発を行うという観点（Global Software Development (GSD)など）において、うまくいかないだろうな、という感想を持ったのでコメントしておく。TwitterはSI屋ではないし、プロダクトを作る組織なので特にそういう印象を持った。
新たな Twitterを創造していくなら、たとえば、東京にプロダクトデザインをする人たちを置いて、シンガポールにソフトウェアのデザインをする人を置く。そしてインドに開発体制を置く。私はこの ３拠点制を提案していたのですが、少し時期尚早だったのかもしれません。
せっかくなのでGSDの話について、何か良い資料はないかなと思って探したんだけど、この辺が良さそうだった。
GSDの難しさとは、という観点でいうとこう書かれているとおり。
GSD is a complex socio-technical system where a number of geographically distributed teams collaborate with a view to produce working software [1,6]. Hence, the adoption of the GSD model is not straightforward and presents a number of challenges (e.g. cultural, temporal and communication issues [4,7–10]) including the key challenge of global project management across borders [11,12].
引用：Key factors that influence task allocation in global software development - ScienceDirect
簡単にまとめると、以下の通り。
- GSD は多くの地理的に分散したチームがソフトウェアを生産すること
- GSDが難しい理由、課題としては以下
- 国境を越えたグローバルなプロジェクト管理
- 文化的、時間的、コミュニケーション上の問題など
引用した論文では、GSDにおける難しさや問題になることの一つとしてtask allocationを問題として捉え、課題設定をしているようだった。ザクっとサイトに記載のハイライトとabstractをちょっと読んだ程度なので全体像は把握していないが。
2017年の論文のようなので、もしかすると他に良いアプローチが出てきてるかもしれないけど、おそらくそんなことはなさそう。というか、そんな簡単にうまい方法論が出てくるものでもないと思うので、現在もGSDが難しいのは変わらないと思う。
グローバルな企業でどうしているか、というと、僕の知ってる限りは地理的、文化的な背景が同じチームや組織ごとに担当するモジュール（ソフトウェアを構成する要素のこと、プロダクトなりライブラリなりに読み替えてもらって良いです）を割り当てることでうまいことGSDにおける課題の発生を避けている、という認識。今のところこれがベターなプラクティスなはず。Xでも近しい話のやり取り見かけたけど多分そうだろう。
プロダクトマネジメント
— Makoto Sakata (@sakatam) 2024年8月14日
デザイン
エンジニアリング
の三つ巴がアメリカでの一般的なソフトウェアプロダクト開発体制。SI業界のようにソフトウェア設計と開発を別組織に分けるのは聞いたことがない。
SIとかだとまた文脈変わりそうだけども、少なくともTwitterではこの話は当てはまるんじゃないだろうか。SIだったとしてもGSDにおける困難さにはぶつかるはずなので、簡単ではないのはそうだろう。僕はSIで働いたことないし想像でしかないけど、大変そうなのは想像つく。
当時はTwitterジャパンにはプロダクトチームがいないようなので、相談する相手がいなかったのかなと思う。プロダクトチームがいればこのアイデアは苦労しそうだよ、と誰かが進言しただろう。
まとめ
色々想像しながら読むと、辛さが伝わってきて読んでいて苦しい本だった。が、こういった話を知れることができてよかった、ありがたい。
Xが今後どうなるか気になるが好きなサービスの一つではあるので引き続き楽しく利用しつつ、注目していく。終わり。
