1. readline.fm
  2. EP201エンジニアリング戦略の..
EP201エンジニアリング戦略の作り方 PART5
2026-06-15 31:36

EP201エンジニアリング戦略の作り方 PART5

spotify apple_podcasts

## とりあげた本


『エンジニアリング戦略の作り方』 ウィルラーソン著, 岩瀬 義昌、岩瀬 迪子訳 オライリージャパン 2026


## mixi2


https://mixi.social/communities/513e0bc9-582b-4962-a9c1-c5c076175e08/about


## ShowNote

https://gennei.notion.site/EP201-PART5-37fc645d49118085bda0da5ed311a724

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

このエピソードでは、「エンジニアリング戦略の作り方」という書籍の第4部、ケーススタディに焦点を当てています。特にUberのサービスマイグレーション戦略を例に、戦略策定のプロセス、システムモデリング、シミュレーション、そして現状診断に至るまでの具体的な流れを解説しています。また、ウォードリーマップを用いた将来予測や、戦略立案におけるリソースや他の書籍の紹介も行われ、実践的なエンジニアリング戦略の重要性と、その学習方法について議論されています。

ケーススタディの重要性とUberのサービスマイグレーション戦略
スピーカー 1
で、いよいよ、第4部、ケーススタディ。 なんかでもやっぱりここの第4部が一番この本の特徴だなーっていう気はしますよね。
スピーカー 2
そうですねそうですね。始まる前にもこの本のいいところとして、実際のそのドキュメントが例というか実際にあるものとしてこんなふうに書かれてるんだよっていうふうに紹介されていることによって、
前回読んだ良い戦略、悪い戦略の具体的にどんなふうにみんな書いてるんだろうかな、戦略どういうふうにやってるのかなっていうのが、あの本だけだとちょっとわかりにくいよねっていうところがこの本ではそこはちゃんとしっかり書かれてるから、
なるほどこんなふうにドキュメントを書くといいのかとか、こういうことをやりたいと思っている時にこういうことを考えながらこういうふうにやってたのかみたいなことが読めるっていうのが、
しかも1個だけじゃなくてかなりの量あるっていうのが、いろんなケースが知れていいよねっていうところを話してましたね。
スピーカー 1
でね、この本で散々解説されてきた手法とか取り組み方っていうのをベースにして解説もついてるんで、
当然全部の事例にそのなんだ、このケーススタディに対して単中から運用まで全部エンドツーエンドで解説されてるっていうわけではもちろんないんですけど、実在の企業の事例を使ってたりするし、
まあでもそれにしても面白いなとか、戦略考えようって言った時のアウトプットってこういう形になるのかっていうのが知れるのはすごい嬉しいですね。
スピーカー 2
1個だけちょっと取り上げてまず喋ってみますか。 16章のサービスマイグレーション戦略ってやつをちょっと取り上げてみましょうと。
まあ状況としては2014年にウィル・ラーソンがインフラチームのEMとしてUberに入社して、新規サービスのプロビジョニングを含む他機に渡る業務を担当してましたよと。
でサービスのプロビジョニングをするところに結構課題を感じていましたよっていうところがあって、じゃあそのためにどうやって戦略を立ててやっていたかっていうのが書かれているという感じですかね。
すごいな。サービスプロビジョニングに取り組むメンバーは4人で1000以上のサービスがあってこれがどんどん増えていくでしょうと。
でさらにUberに在籍してたのは2000人以上のエンジニアだそうです。
スピーカー 1
1個1個のチームが割と小さい規模を保つようになっているからプロビジョニングの負荷を各チームで
どうにかしてねって投げつけるわけにもいかず自分たちのチームでウィルダソンがいるチームで引き受けるようにしたよと。
スピーカー 2
すごいな。
スピーカー 1
すごいないや解決できるようなかっこいいですね。
スピーカー 2
そうですね人を増やすかみたいなこととかいろいろ考えられると思うんですけどね。
スピーカー 1
でここで言ってるのがあれかそもそもGitHubにもこの本にある以上の完全な情報がまあ一部ですけど一部とか完全とか言ったりしてますけどより詳しい情報が載ってるよっていうのもありますね。
スピーカー 2
うんうん。
じゃあドキュメントをステップワイステップに本当はやるんだった探求から始め診断へっていうのがあるけど一旦方針から行きますか。
この書かれている順、そのページの順番に行くとマイグレーション戦略として方針と言うとしては以下の方針を採用しましたよと。
セルフサービス化への投資を最大化するため手動プロビジョニングへのリソースバリアティを制限しますよと。
要は4人全員でやるんじゃなくてもう1人固定にしましょうと。
で、Uberのコンテキストを知らない新入社員でも安全に使えるセルフサービスにしましょうと。
で、チケットベース今まではチケットにお願いしますって言ってやったんだけどそれから構造化されたリクエストへ移行しましょうと。
スピーカー 1
これはあれですねなんかフリーテキストで自由な文章で書かれるんじゃなくてなんかフィールド項目が決まっててそこに入れていくみたいな形にしたよって感じですね。
スピーカー 2
そうです。で、ユーザー入力を求めるよりも親切なデフォルト値で新規サービスを初期化することを優先しましょうという方針立てをしましたよっていうのがドキュメントとして最初にあるって感じですかね。
スピーカー 1
これがそうですよね書き手の順序だったらやっぱり単通から欲しいものを読み手のための文章なので最初に決定されたことこういう方針ですっていうのを書くっていう素晴らしいですね。
スピーカー 2
そうですね。で、だんだん時間が経つにつれ多分背景とかはまあ後で知りたいってなるかもしれないけどいやまず結論くれよみたいなどういう方針でうちやってんだっけって後から入ってきた人とか多分思うんで。
ここだけまず一旦読んでおけばいいよって言われるとすごい助かりそうっていうのを思いましたね。
スピーカー 1
この方針の原則があってこれを実現していくため、戦略なんでこれからこうしていきますっていう未来系の現在進行形とか未来系の話だからこれを実装するためにこういう順番でタスクをこなしていきますねっていうのがその下に書かれていると。
スピーカー 2
なります。
スピーカー 1
全部読む必要はないと思うんですが。
スピーカー 2
さっきのチケットのひな形っていうかに入力をちゃんと矯正させるとか、プロビジョニングの自動化にためにパペットのひな形を生成できるようにするよとか懐かしいですねパペット。
あとなんかポートの再利用とか結構問題になってたところを解決するよとか。
スピーカー 1
ここら辺はね手動でやっていくとなんかサービスがドカーンってなる可能性。
うっかり爆破しやすいからここら辺はもう自動化してしまえっていう。
それはプログラムにやらせるようにするよとかね。
スピーカー 2
新規サービスのサーバーへの割り当てとかも自動でシステムにやらせるよっていうのは基本的に自動化をして気にしなくてもいいような感じになっているよみたいなことが書かれてますね。
その戦略を洗練させるよっていうところも図が描かれていて、システムモデルが描かれていて、こういうことが増えていくとこういうことが増えてリクエスト、サービスをこれホストしてほしいんだよねって言って依頼が増えると一定の確率で情報が足りないとか、さっきのポートが被ってるとかパペットのエラーとかによってどこが問題になっていくかみたいなことがシステムモデリング。
書かれていて、結局これを解決するような戦略になってないと意味がないよねっていうようなことが出てたりしますね。いいですね。わかりやすい。
スピーカー 1
そうっすね。システムモデルで各ステップというかなんだプロビジョニングまでの流れっていうのが一個一個のモジュールというか四角形で書かれてるわけですけど。
それが矢印でハッピーパスというか正常に行くとこうで失敗するとここでエラーになってここからここへ手戻りがあるよねっていう逆向きの矢印もあるんですけど、いやわかりやすいですね。ここでエラーが起きます。ここが問題なんですっていうのが図にされると何も考えないでも一目でわかる感じがするなーって思って。
スピーカー 2
そうそう。しかも採用率とかプロダクトのエンジニアが増えていくとか、その結果リクエストされる依頼が増えていくよみたいなところまで書かれてますからね。その実際のパペットのっていうかそのサーバーが出来上がるところからではなくて、そもそも依頼ってどこから来るんだっけって、その依頼って関節的に何が要因としてあるんだっけみたいなところとかまで含めて図にしてあるのですごいわかりやすいですね。
なんかそこまで考えないといけないよねっていうところが、まあ多分この一発でこれができたわけではないと思うけど、漏れなく書かれてていいなーっていうのはありますね。
スピーカー 1
で、これでシステムモデルで静的なというか関係図みたいなものを作った上で、あれですね、ここの変数がこう変わったらどういう風になっていくんだっけっていうシミュレーション?この後にしてるわけですよね。
スピーカー 2
そうですね。まあ仮にエラーがなかったらこの数値が増えていくと、どんどんどんどんこれが増えていくよとか、その増え方が大きいのか小さいのかとかいうところがわかるようなグラフを作ってやるって感じですね。
スピーカー 1
これによってね、ここの変数がこういう風に変化した時に、ここにこういう反応が出るんだみたいな因果関係とそのフォースの強さみたいなのがわかってくるから、
スピーカー 2
じゃあレバレッジが効く、解くべき問題はここだっていうのが見えてくるみたいなことをちゃんと表してくれてると。
スピーカー 1
という風に、実はこっちを自動化した方がいいんじゃないかっていうのがこの洗練のフェーズでわかってくるっていうようなお話ですかね。
スピーカー 2
そうですね。診断がその次に書かれていて、要はなんでこういう図が出てきた背景として現状どうなってんだっけっていうところで、
エンジニアリング組織は6ヶ月ごとに倍増してますよとか、1年後には毎週これぐらいのリクエストが来そうですよとかいう話があったりとか、
今の4人チームでうちのチームに人が増えるっていうことは今のところ見通しがないよとか、だから人を増やしてどうにかするってことは無理だよみたいなこととか。
現状だとそうですね、じゃあ依頼が来てからその実行されるまでの給はどんどん長くなってるんで、サービスがタイムに本番に出ていかないからこれは課題だよみたいなこととかあったりとかそうですね。
そういう現状の問題点みたいなのが課題がいっぱい書き出されてるって感じですね。
スピーカー 1
この診断の中で結構グーッと来たのが163ページの下の方にあるんですけど、
例えば現時点で組織全体を完璧にトレーニングできたとしても、6ヶ月後には同じ数のトレーニングを受けていないエンジニアがいることになるっていうふうに書かれてて、
こうなってくると努力と根性で解決無理だから仕組み作ろうっていうのはすごい説得力ありますよね。
スピーカー 2
そうですね。入社して全員このトレーニングやるんかいみたいな話になりますしね。
スピーカー 1
トレーニングしたとて関わる人が増えていくというか、主導で関わり続けている限りはヒューマンエラー起きるよねって話もあるだろうし。
スピーカー 2
そう、リーダー層からしたらこんなことこんなトレーニングの時間割きたくないんだよなーって思っちゃうわけだし、
こう見るとUberもあんだけ大きい会社でもこういうもんなんだな最初の頃はっていうことをちょっと思ったりとかっていうところもしましたね。
スピーカー 1
最初の頃って言うほど最初じゃない気がするので、エンジニアは2020年だけですよね、プロダクトだけで。
スピーカー 2
確かにそうですね。意外とこういうので乗り切ってんだな。プロダクトが当たらないとこういうことにはならないからな。
スピーカー 1
で、このドキュメントの期日の順番で言うと最後になりますけど、一番最初のフェーズステップとして短中っていうのがセクションが最後にあるわけですね。
スピーカー 2
そうですね。
スピーカー 1
短中面白いのは、クバネティースとかが出てき始めたタイミングで有用層期待はできるけど、まだこれが作成された時期においてはプロダクションへの導入とかがまだまだ少ないとか、
ちょっとまだ安定してきてない、進化が早すぎる、バージョンアップが早すぎるとかかなっていうのがあるから、
現時点で飛びつくんじゃなくて、一旦その手前というか、それがあったとしても必要になりそうな部分からまず自動化していこうねとか、
っていうようなのがその短中の結果から診断されていっているとかありますね。
スピーカー 2
いいですね。なんかすごい冷静だなっていう感じがしますね。サーバーレスの話もあったりするし、
メソス、オーロラっていうのがあるけど、これ自分知らなかったんだよな。
スピーカー 1
そこら辺もね、面白いですよね。
ウーバー社内にはツイッターでメソスオーロラを運用した経験について自信を持って語れる元ツイッターエンジニアが多数在籍しています。
一方、一万台以上の大規模なサーバーフリートでKubernetesを運用した本番経験を持つ人間は、人物は見つけられていません。
ってなると、いきなりKubernetes行こうぜーはちょっと駆け足すぎる気がするよなとか。
スピーカー 2
そうですね、そうですね。
ここの探求でいろんなソリューションは絶対これだとか、こうしようみたいなこと決め打ちではなくて、どういう可能性があるかな、
世の中の人たちはどうやってるのかな、社内にそういう知見を持っている人はどういう人がいて、どういう経験はあるのかな、
っていうようなヒアリングをいろいろしているっていうのがこの探求のフェーズで、
絶対これがいいとか、これにしましょうってどこまで決めてないからこそ、
なんか順当にこう、いや一旦パペットでええやろみたいな感じになって、
プロビジョニング自動化しようぜっていう風なところに行ってるのもいいですね、いいですね。
スピーカー 1
いやここ、まあ規模が違う、今まで自分が関わってきたような組織とは規模が何桁も違うからっていうのはあるんですけど、
なんかプロビジョニング、明らかにプロビジョニングできる人材がいるチームが4人しかいなくて、
こんなにプロダクトが、サービスがめっちゃ多くて増え続けてるってなったら、
自動化した方がいいよね、でも目に見えてる問題な気はしちゃうんですよね。
っていうのに対して、なんかここまで、なるほどなんか発散と収束を繰り返して、
こういう風にやるべき理由積み上げていくのかっていうのはめっちゃ面白いなって思いながら読んでました。
ここまでやった方がいい気がしちゃうもんな、こんなん読んだら。
スピーカー 2
そうですね、これどうやってドキュメントで書いて方針立てて運用を実際に回したか、
だんだん次気になってくるなみたいなことをちょっと見てみたいなって気持ちになりましたね。
スピーカー 1
そうですね、あとあれか、他のドキュメントも一応あるのか、サービスオンボーリングモデルとか。
スピーカー 2
そうですね、そうですね。
スピーカー 1
16章他に触れておきたいところありますか。
スピーカー 2
でも、なんか実際どういうことをやっているのかが、これによってだいぶ理解・解像度が上がったので、
非常にいいですねっていうことを思いましたね。
スピーカー 1
その戦略のドキュメントっていうのが題材としてこういうアウトプットになってくるのかっていうのも分かるし、
ツールキットを紹介されてたシステムモデリングとか、
オードリーマッピングとかオードリーマップかっていうのを使って、
こういう解釈をしてこういう判断につながってるんだなっていうのも、
やっぱり概念だけ説明されてるとあんまりこうピンときづらいというか、
ふーんって感じになっちゃうと思うんで、そこら辺がやっぱり実例に勝る先生はいないなみたいな気がしますよね。
スピーカー 2
あとは多分実際に今度は自分でやってみて、書いてみて、
なるほどこういうことかっていうことにいくんだろうなっていうような気がしますね。
スピーカー 1
179ページの将来の状態への移行っていうのが、さっき言ってたオードリーマップで書いてあるんですけど、
これが横軸で言うと左側が先進的・野心的で、右側が普通してるコモディティみたいなマッピングになるんじゃないかなって言ってましたけど、
これ現状はオンプレのパペットアートっていうのを使っててっていうのが、
だんだん将来的にはオンプレのメソス・オーロラっていうのが出てきて、
そのさらに将来はより右側、要するに普通して当たり前に使える技術として、
クラウド上のメソス・オーロラ、もしくはKubernetesっていうのが出てきて、
さらに右側、将来的にはこれよりさらに右側にクラウド上のサーバーレスっていうのが出てきてるんじゃないかっていうのを一つのマップの中で表現してて、
スピーカー 1
じゃあその未来に向けて今何に準備しとくのとか、逆にこれは今やっても将来的に捨てそうだねっていうのが分かりやすいっすね、これ。
スピーカー 2
そうですね。どういうふうにどこに向かっていくだろうという予測があると、この現状認識を揃えて、
じゃあ自分たちが今どこに力を入れるべきなのかとか、やらなくてもいいんじゃないっていう判断もできるだろうし、
やるってことはこういうことを見据えてやっていこうねっていうことが言いやすくなりますね。
スピーカー 1
いやすごいな、将来的にクラウド上のサーバーレスっていう技術が出てくるだろうっていうだけじゃなくて、
ウォードリーマップと将来予測
スピーカー 1
今自分たちが持っている利用しているケーパビリティがここに置き換わっていくよねっていうのは、確かにこの書き方だとめっちゃ分かりやすいな。
スピーカー 2
そうですね、そうですね。
しかもそれが自分たちのチームというか、会社から見た時にどういう関係性にあるんだっけってことまで一目で分かるように図示されてるっていうのが、
そこだけ切り取って今我々は話したけど、それ以外にもこのマップには書いてあるので、プロダクトエンジニアとかサービスプロフィッショニングチームがあって、
トラフィックが増えてみたいな、それと今のものがどういう関係性にあるんだっけっていうところが図示されてるので、
スピーカー 2
ここがもしサボるとどこに影響がいくんだっけみたいなところまで分かるっていうのが面白いところでもあるっていう感じですかね。
スピーカー 1
そうか、ユーザーというかそれに依存してそのコンポーネント、ケーパビリティに依存しているのが誰ですかっていうところまでグラフでつながってるから、
将来的に置き換わるこれからこれっていうのって誰がオーナーとして取り組むべき問題なんだっけっていうのもすごいパッと分かりますね。
スピーカー 2
いやすごいな。
スピーカー 1
なるほど。
スピーカー 2
なるほどな。
スピーカー 1
これ確かに使えると便利そうだから書く練習しとくといいんだろうな。
スピーカー 2
自分たちは読み書きできるようになったけどこのウォードリーマップっていうのがあったよなってまた紹介するところからどんどん始めていくようになるから、業界としてみんな見ることあって当たり前になっていくといいな。
スピーカー 1
まあでもね、そんなこと言ってもUMLなんか雰囲気で、習ったことなくても雰囲気でなんとなく読めるじゃないですか。
スピーカー 2
うん、確かに。
スピーカー 1
あのくらいになればいいんじゃないですか。
スピーカー 2
そうですね。
戦略立案のリソースと他の書籍の紹介
スピーカー 1
でも16章そんなところかな。
スピーカー 2
そうですね。
スピーカー 1
なんかね、他にもケーススタリーが4つ5つありますけど、どうしましょうね。なかなか喋ってんだよな。
スピーカー 2
そう、もう3時間近い喋ってるので。
スピーカー 1
まあね、こんなだいぶ中身こんな触れちゃって大丈夫かってくらいちょっと読み上げちゃってるので、ケーススタリーはそんなところにしときますか。
スピーカー 2
そうですね。で、じゃああとは5分って言ってもまとめみたいなもんなんですよね最後。
スピーカー 1
5分そうですね。どんなことが書いてあるかって言われると、今後に向けてというタイトルの部なので、立てた戦略が優れているのかってどうやって考えるのとか、
あと戦略を立てられるようにする、その戦略スキルを高める方法ってどうしたらいいですかとかっていうのがちょっと書いてあるって感じですかね。
スピーカー 2
そうですね。一丁最後が戦略に関するリソースで、いろんなアイディアの種になりそうなものはこういうものがあるから、こういうのにも触れてみてねっていうような感じのことが書いてありますね。
スピーカー 1
いろんな本が紹介されていますね。
スピーカー 2
そうですね。書籍の紹介とケーススタディの紹介とってあるから、この辺を読みましょうねっていう感じなのかなって思いながら、
いくつかねちょっとあのサイト開いてみて、ブログ記事とかをジェミニに予約させながら読んでみたりとかしましたけど、
なんか結構やっぱ面白いんで、結構いろんな事例を読むっていうのが、まさにこうなんていうか自分の引き出しを増やすという意味でいいのかなっていうのは思いましたね。
スピーカー 1
いやー面白そうな本がたくさんあるしな。
スピーカー 2
そうなんですよね。本もね、ただびっくりすることに、ここに載ってる翻訳があるような本は、なんかどうやらうちにほとんどあるぞっていうことが分かったりとかして、ちょっと怖いですね。
スピーカー 1
マジか。いやでも言う程度なら人のこと言えないな多分。
スピーカー 2
いや多分金城さんね、翻訳あるものは多分ほとんど持ってるんじゃないかな。
スピーカー 1
翻訳ないものに関してはオライリーから出てるのが多いせいで、多分読める。
スピーカー 2
そう、読めちゃうんですよね。
スピーカー 1
確かにな、翻訳出てるのは下手したら全部持ってるかな。
スピーカー 2
そうですよね、そうですよね。
スピーカー 1
関心領域が近いと言うと偉そうですけど、ここら辺のテーマで読んでたりはするから、ビッグシングス買ってるんだっけなっていうのをずっと思い出せないんだよな。でも多分買わされてるからな。
スピーカー 2
多分ね、このポッドキャストでも最近読んだ本かなんか紹介するときにビッグシングスを紹介したような記憶があるので。
スピーカー 1
そう、だって絶対サンマーク出版意外と侮れないですよねって話をその時にしてるから。
スピーカー 2
このビッグシングスも面白いんでね、是非って感じですね。
スピーカー 1
それで言うとザ・フェニックスプロジェクトは結構面白いんでおすすめですね。
スピーカー 2
小説仕立てになってるやつですよね。
スピーカー 1
小説ですね、フェニックス、どっちだっけな。たまたま酒飲んでる時に出会った人が実はすごい人でパターンだった気がする。
スピーカー 2
完全にザ・ゴールで見た流れやんみたいな感じの。なんかすごいメンターみたいなやつがどうにか助けてくれてみたいな。
スピーカー 1
まあよくあるやつ。
スピーカー 2
よくあるやつ。
スピーカー 1
あれなんですよ、ザ・フェニックスプロジェクトとザ・ユニコーンプロジェクトっていうのがあって。
ユニコーンプロジェクトがユニコーンプロジェクトだっけな。ザ・デブオープス楽天だとザ・デブオープス勝利をつかみってあるんですけど。
続編になってて、それもまたよくあるこの人出世したんだみたいなパターンですね。チラッと出てくるやつ。
スピーカー 2
もう完全にザ・ゴールじゃねえかみたいな。アメリカのビジネスショーの典型パターンみたいな。
スピーカー 1
あれでしょうね、小説家養成講座のテンプレートであるんでしょうね。
スピーカー 2
きっとそう。
スピーカー 1
まあでもそんなところか。
「良い戦略、悪い戦略」との比較と学習方法
スピーカー 2
全体通して読もうと思うとページ数ももちろんあるんで、そんなパッと読めるもんではないけども。
でもやっぱりそれなりにボリュームあるだけかなり濃密にいろんな話題が書かれていて、いい本ですね。やっぱり面白いですね。
スピーカー 1
面白いですね。
僕らのこのポッドタストで言うと、これの事前準備として良い戦略、悪い戦略読んでるじゃないですか。
どうでした?あっちを読んでからこっちを読むべきなのか、読まなくても全然良くないなのか、どう感じました?
スピーカー 2
読まなくてもいいんじゃね?とは思いますね。
みんなにあれをまず読んでからっていうのは知ることは特にないかなとは思うものの。
でもやっぱり戦略の大事さっていうか、戦略っていうものを軽視しないというか、重みみたいなものを考えた時に、
なぜルメルトがそんなに戦略っていう言葉にこだわって、良い戦略、悪い戦略っていうものがあるのかっていう部分をちゃんと知っておくという意味では、あの本を読んだ方がいいんだろうなっていう風に思いますね。
スピーカー 1
そうですよね。似たような感覚ではいるんですけど、あっちを先に読んでからだと、この本の中で語られている戦略とか診断とかっていうのがスッと入ってきやすいだろうなっていう意味で、
先に読んでからこっちを読むとわかりやすそうかなとは思いつつ、この本読むならまず先にこっちを読んだ方が良くてっていうノリで進めるにはちょっとボリュームあるというか、
スピーカー 2
あんまりコンパクトにまとまっている本ではないので、そこまで労力を払って読まないといけないかっていうと、全然一発目でエンジニアリング戦略の作り方読んでいいですよみたいな気持ちになったり。
そうですね。ようやくブログとかチャットGPTとかに聞いて、だいたい向こうの本ではどういう話をしているのかみたいなざっくりとしたことを頭に入れながら、あっちの本を手に取るときは重要そうなとこだけ抜き出して読んでみたいな読み方しながら、このエンジニア戦略の作り方を読むといいのかなぐらいなもしかしたら感じなのかなっていうのをちょっと今思ったりしてましたね。
スピーカー 1
そうなりそうっすね。
スピーカー 2
むずいんだよな。一冊読んだから、ようやくブログとかああいうものの、ああそうだよね、結局抜き出すとこれだよねっていう気持ちには、結局一冊読んだからなるんだよなと思って。
スピーカー 1
そうなんだよな。スクラムの本を10冊読むと、スクラムガイド読めば永遠ここに全部書いてあったなってなるのと似た気持ちになる気がする。
スピーカー 2
難しいけど、なんとなく良い戦略、悪い戦略がどういうことを言おうとしてたのかってことは、知っておくと読みやすいかなっていう気がするっていう感じですかね。
スピーカー 1
あと、エンジニアリング統括責任者の手引きは、たぶんめちゃくちゃ関連性は強いなーっていう気はしたんで、順番どっちでもいいかなっていう気がするけど、読んでみると面白そうな気がするな。
スピーカー 2
まだ読めてないからな。
スピーカー 1
僕も途中までしか読めてないんですけど、エンジニアリング戦略を立てるっていうのが第3章で出てくるので、一章一章の長さはたぶんこの本とそんなに変わらん気はするので、小5トンのボリュームはそんなに多くないじゃないですか。
たぶんウィルラーソンの本が全盤的にそんな気はするんですけど、その上で3章でエンジニアリング戦略っていう章が出てくるんで、正式な名前なんだっけ、エンジニアリング戦略を立てるか。だからオライリー学習プラットフォームに入ってればサブスク読み放題なんで、3章まではとりあえず読んでみるっていうだけでも、もしかしたらちょっと面白いかもしれない。
スピーカー 2
そうですね。そこで気になって、じゃあもうちょい深掘りしたいねってなったらこっちの本に来るっていうのも全然ありかもしれないですね。
スピーカー 1
いやー面白かったなぁ。最初に言いましたけど、マジでマネージャーとかVPやってる時に惜しかったなぁ。
スピーカー 2
そうですね。こういう本があるっていうのはすごい幸せなことだなって思いますね。
スピーカー 1
いい戦略、悪い戦略とかはあったんだからそれ読んでやればいいじゃんなんですけど、読んでなかったんで、そうするとどうなるかっていうと勘でやってるんですよね。
だいたいこういうことを言いたくて、それを人に受け取ってもらえるためにはこういう風にすればいいかみたいなのを教科書なしでやってるんですよ。なんか怖いこと言ってますよね。
スピーカー 2
とりあえずなんかハンドルはこう回すと曲がるよねって。研修受けないまま運転するみたいな。
スピーカー 1
いやー、だからすごい自分の経験も踏まえて読んでみて納得感があるなって思うのと、今これ読んだ上で納得感あるなって思ってるんですけど、
なんかこういう系はやっぱり実践と知識の改良はすごい激しいと思うので、そういう意味で言うとこの本すごいいいなって思ったのが、
なんかそれこそ一番ミクロな自分の戦略っていうような表現もありましたけど、ちっちゃい単位でもいいからその戦略的な思考をしてみる、戦略を考えてみるアトプットしてみる形にしてみるっていうのを、
なんかそれってやらないとできるようにならないじゃないですか。繰り返しの訓練というか素振りは必要だなーって思ってる中で、
でも組織戦略を立てる機会なんてそうそうないというかそんなね、毎週1個戦略立ててたらよくわからないのでっていう中で、
1回そのしざって言葉で表現されてましたけど、いろんなスケールで考えてみるっていうのをやると実践値をなんか色々蓄積できそうだなーみたいな気がして、
そこらへんも言ってくれてるのはすごい良かったなって思いました。
スピーカー 2
そうですねなんか始めるためのなんかたくさんやる必要もないし、とりあえず1個でいいんだよっていうことを言ってくれるし、始めるためのハードルがすごく低いんだよっていうことをいっぱい言ってくれるから、
なんかそんなに遠い難しい問題っていうわけではないんだなっていう風に結構受け取ったのもあるんで、
まあじゃあとりあえず立ててみるかとか、とりあえずまずは日々探求みたいなことはやってたりするかもしれないけども、じゃあそれをちょっとまとめてみるかとか、
1回リストにしてみるかぐらいのことは全然できるだろうし、それがちょっとずつでき始めると、別に周りに話聞くぐらいはできるよねって言って、
診断として社内の人に話を聞くは別にミーティング入れたらできるしな、普段やってるしなって思えばそんなにハードル高くないんじゃないかなっていう風にも感じたので、すごくやっぱいいですね。
スピーカー 1
そうだな、戦略っていうのはこういうライフサイクルとか要素が必要だよねっていうのは共通理解を育みると楽だろうなとか思ったんで、
そういう意味でもまとまってこういう形になっているのはありがたいですね。
スピーカー 2
そして日本語で読めるのもありがたい。
書籍の文章スタイルとまとめ
スピーカー 1
そうそう、日本語でっていう話に近い気がするんですけど、なんか文章がすごい優しくなかったです。
優しいって言っていい字の方の優しいじゃなくて、読みやすいっていうのはもちろんあるんですけど、優しい先輩みたいな口調でずっと喋ってくれるなみたいな気がした。
スピーカー 2
ウィルラーソンってすげえ人だなって、読んで改めてそう思ったし、CTOとかだからこれぐらいできるやろうとか、なんかそういうような感じではやってこないなみたいな。
いいかい?って誰にも丁寧に接してそうみたいなのが、もしかしたらこれは翻訳のあれかもしれないですけども、そういう雰囲気がすごくあるような文章だなっていうのが読んでて思いましたね。
スピーカー 1
なんか皮肉めいたりもしてないですしね。悪態はついてないからな。
スピーカー 2
うん、今までそういう本があったなって今ちょっと思ったりとかしながら。
スピーカー 1
割とそういう本多いからな。
スピーカー 2
そうそうそう。
スピーカー 1
まあでもそんなとこですかね。
スピーカー 2
ですね、はい。
スピーカー 1
えーっと、これがたぶん6月の頭ぐらいから配信されるのかな。
スピーカー 2
そうですね。
スピーカー 1
たぶんね、ちょっと収録してる順番を入れ替えたりはしてるんで、早めに出したいのはあるんですけど、出てきますよと。
出てきますよっていうのを4本目聞いた後に言われてもな。出てきましたがみたいになりそう。
スピーカー 2
そう?
スピーカー 1
よし、じゃあおしまいにしますか。
スピーカー 2
はい。
スピーカー 1
今週も放送を聞きいただきありがとうございます。ではまた次回。さよなら。
スピーカー 2
さよなら。
31:36

コメント

スクロール