Magnolia Tech

いつもコードのことばかり考えている人のために。

『ユニコーン企業のひみつ』を読んだけど、ひみつは書かれてたっけ？と思ってしまった

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

  • 作者:Jonathan Rasmusson
  • 発売日: 2021/04/26
  • メディア: 単行本（ソフトカバー）

たぶんこの本の一番間違った使い方は、エライ人が読んで「よし、うちもこんな組織運営に変えるぞ！」って言い出すことなんじゃないかなって。

まずは、「メンバを信頼し、権限・裁量を与えても大丈夫な組織に変えていくために何をやるか？」から考えていくところが出発点ではないでしょうか。そういう意味では、そこはこれまでも散々語られてきたことなので、「ひみつ」なのかなーとまず思ってしまいました…（だからと言って、本書の価値が低いわけでは無いですよ)

あと、この本で頻繁に出てくる「プロジェクトでは◯◯はやらない」「エンタープライズ企業では□□はできていない」みたいな言説は、割り引いて読んでおいた方がいいかな。

結局、冒頭ででてくる、以下の言葉を鵜呑みにし過ぎない、ってことが大事だし、案外一番重要なのは「訳者あとがき』に書かれている、その後のSpotifyの組織変遷だったり、Spotifyモデルに対する評価だったりするのかも。

今どきのテック系ユニコーン企業のソフトウェア開発はこれまでとは別物だ。書籍に書かれているようなアジャイルなんてやっていない。もちろんスクラムもだ。ユニコーン企業のやり方はもう全然違っている。なんだかうまいことやっていて、スタータアップみたいな働き方で、エンタープライズ企業みたいなスケールを達成しているんだ。

そういう意味でも和書で読むことをお勧めします。

あとはコレに尽きる気もするけどね。

というわけで、次は『アジャイルサムライ』を読み直します。

追記

大事なことを書くのを忘れてた

「役割」と、「振る舞い」について

ドメインエキスパートを外部のリソースと捉えるのは違うんじゃない？

実践ドメイン駆動設計

実践ドメイン駆動設計

『実践ドメイン駆動設計』の一節にこんなくだりがある。

ドメインエキスパートをプロジェクトに参加させる方法

コーヒーにきまっている。こんなユビキタス言語を使えばいい。「やあ、サリー。トール・ハーフスキニー・ハーフワンパーセント・エクストラホット・エクストラショット・ラテのホイップ入りだよ。ちょっと話したいことがあるんだけど、いいかな？」

いやいやいや...要たるドメインエキスパートが、その程度のコミット度合いでプロジェクトが上手くいくわけないでしょ…

なかなか”適切な”ドメインエキスパートを見つけることは難しい。だからこそ、正しい視点を持ったドメインエキスパートがコミットすることは大事なんだよね。

『ドメイン駆動設計』も『実践ドメイン駆動設計』も、なぜかドメインエキスパートに関しては深く踏み込んでいないし、なんだかすごく都合の良い存在に定義することで現実のプロジェクトの難しさの一番大事な部分に触れていないように読めるんだよね。それがそれぞれの本のスコープではないっていうことなんだろうけどさ。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

成長は経験の質の掛け算じゃないかって考えた

それぞれの要素のうち、どこを強く経験するかは人それぞれだけどね

if文を追加したくない高校　校歌斉唱！

闇雲にif文無くせばいいって訳じゃないのは当然なんだけど、それでも単純に増加していくのを単に「要件を実装したらそうなりました」って言い切るのもまた違うんじゃないか。

場当たり的な分岐を雑に追加すべきではない、は常に正しいけどさ。

『エクストリームプログラミング』...僕らはいったいどういう「価値観の変えかた」をすればいいのかと考えるきっかけになる一冊

そういえば読んでいなかった。

エクストリームプログラミング

エクストリームプログラミング

XPは、私自身のソフトウェア開発の実践のなかで人間性と生産性を調和させ、その調和を共有しようとする試みである。自分や他人に思いやりのある接し方をすれば、生産性が高まることがわかってきた。成功の鍵は、個人の努力ではなく、「人と人」のビジネスに自分が携わっていることを受け入れることである。

本書で、冒頭のこの言葉が一番が刺さり、かつ「どうすればこれを理解、啓蒙することができるのだろうか」とずっと考えている。

ソフトウェア開発／運用、という物理的な制約が（比較的）少ない領域において、従来の物理的な制約の強い製造業の考え方を起点においたマネジメントスタイルから何らかの変化点が有るのは当然のことと言えるが、じゃあ果たして上記のことを、例えば石油プラントを開発する人たちが言わない、実践していないか、といえば、それはきっと違っててきっと同じことを言っているのではないか。

ソフトウェアに限らず、プロジェクトに参加している多種多様な人たちの価値観を擦り合わせ、ゴールに到達するための道筋を、取り巻く環境の変化に合わせてやっていくのはどんな業界・業種でも変わらないのではないか。

続くページに書かれている、以下のメッセージについて、

  • XPとは、効果のない技術的／社会的な古い慣習を捨て、効果のある新しい習慣を選ぶことである。
  • XPとは、自分が今日やるべきことを十分に理解することである。
  • XPとは、明日をよりよくしようとすることである。
  • XPとは、チームのゴールに貢献した自分を評価することである。
  • XPとは、ソフトウェア開発で人間としての要求を満たすことである。

最後以外は、ソフトウェア開発以外の世界でも当てはまるのではないか。「古い慣習を捨てる必要はありません」と言うリーダーはいない（実践できているかは別として）し、「今日やるべきことを理解しなくていい」と言う人もいない。

当然ソフトウェア開発の特性、”ユニットテストにより、より小さい単位で確からしさを確認できる”、”継続的なリリースにより、より小さい単位で方向転換ができる”などがもたらす価値観は従来の仕事の進め方とは違うかもしれないし、それらがより上記のことを「やりやすく」する側面があるのも間違いない。

ゴールは変わらないけど、そのプロジェクトの主要な特性から、そのゴールを実現するための方法論が違うだけ、と捉えるとスッキリすると思っている。

ウォーターフォール的なプロジェクトの進め方は、”フィードバックに基づく計画の見直しの累積は、回復不可能なロスを生み、計画の進捗に大きなマイナスの影響を与える”という前提に立っている。そのため、各階層にバッファを積むし、計画に対する遅れに敏感になる。

つまり、これ

そして、こうなる。

アジャイルの方法論は、突き詰めていけば、この事象を解決するために有ると自分は理解している。フィードバックが正しく行われ、正しい方向にプロジェクトが向かうように、すべての階層の人の価値観を尊重したプロセスや評価方法が必要になってくる。

本書の内容に戻ると、まずは「6章プラクティス」や「7章主要プラクティス」あたりから読み始めると良い。ただ、そこでいきなりそれを適用するというより、他の章に立ち返って、「そのプラクティスをもたらす背景・価値観」を理解した上で導入しないと、よくある「外形だけをなぞったアジャイル」となってしまう。達成したい価値観は何だろう？と考えながら読まないとミスリードが起きてしまう。

というわけで、この本は「ソフトウェア開発における価値観を変えたい人」におすすめです。読みやすく、170ページくらいしかないので、半日もあれば読めると思います。