00:06
第3部、洗練に使うツールっていうのが、さっき言った戦略テストとシステムモデリングとゴロリアップですね。っていうのが紹介されてるんですけど、
どういう時に使うどんなツールかっていうぐらいだけ軽く言えればいいかな。 そうですね。
その前提で、じゃあ順番に行きますか。 うん。
第13章、反復的な洗練のための戦略テストっていう章なんですが、戦略テストっていうのが、ある戦略が所要できるコストで意図した目標を達成できるかどうかを検証することって書いてあって、
ある程度具体的な話をした方がわかりやすそうな気はしてますが、戦略テストって言い方も多分ちょっと抽象的というかわかりづらい感じはするんですよね。
そうなんですよね。そうなんですよね。さっきの運用とどう違うのみたいなこととかもちょっと気にはなったりしますけどね。
そうね。チェック項目とチェックポイントを作っておいてみたいな感じではあるんだよな。
さっき喋ってたエンジニアの戦略を構築するためのステップの探求診断、洗練、方針、運用みたいなところがあるから、
まだ運用が始まる前で洗練させる時にどういう風なことをやって洗練させていくかのうちの一つっていうもので、
そのアイディアみたいなものがどんだけ効果があるの?どれぐらい良さそうなの?っていうことを実際にちょっとテストしてみる。
その戦略がどれぐらい良さそうかテストして、レバレッジが効くのかどうかとかいうようなところを見てみるみたいなことですよね。
歴の悪い戦略を実装してしまうよりテストで失敗に気付く方が圧倒的に低コストであり、
大抵の場合は時間と労力に十分見合う投資になりますっていう風に書いてたりもしますね。
この中で例として出ているのが、買収したキーをシステム統合するって言って、
どんだけそれが難しいかどうかもわからんし、とりあえずちょっとだけAPI連携一つやってみるかとか、
コードベースに型ヒントを導入するって開発効率上がるでしょうって言うけど、
本当に上がるかどうかわかんないんで、経験豊富なメンバーに重要なモジュールでちょっと一回試してみて、
これがあるとないとどう変わるの?みたいなところをちょっとやってみようねとかいう話がありますね。
あと13-2見てみるとね、リリース戦略立てようとしている時に重要なリリースを一度だけその方法で実行してみるとか。
本当にこのやり方でいけそうかねっていうのをちょっと素振りしてみるみたいな感じに近いのかな。
そうですねそうですね。やってみてとか、やらずにこういう方法をやってどれぐらい有用かっていうことを検証しましょうねというところですね。
03:04
戦略の細部が実際に機能すると確信できるまで、あるいは機能しないと判明して別の切り口が必要だとわかるまで、
戦練を続ける必要がありますとかって書かれてたり。戦略テストっていう何ですかね、
テスティングフレームワークがあるっていうよりかは戦略を本当にテストしてみる、試してみるっていうニュアンスっぽい感じはするかな。
そうですねそうですね。抽象化してこういうもんですっていうのが機能することを検証しましょうっていう風にしか言えないなとか思いながら。
言われてみると確かに戦略決めましょうとか決めましたってなった時って、会議室で戦略会議だけやってここでOK取れたから確定みたいな。
確かにあるかもしれなくて、実現可能性とか効果性みたいなものっていうのをこういう風に評価する測定の指標を置いてるけど本当にそこにインパクトしそうなんだっけみたいなやつとかっていうのを
ちょっと最初に確定する前にコミットする前に試してみようっていうのは言われてなんかすごい当たり前なことを言ってそうな気もしつつ確かにこれをやれるかやれないかでかなり結果変わりそうだなっていう気が今してきましたね話しながら。
戦略っていう風に台それたことをつけるとあれだけどなんか普段じゃあ業務でどうやってるっけと思った時にじゃあ新しいライブラリーを使いたいなと思っていきなりなんかそれにもうシステムガーンと入れるっていうよりはとりあえずちょっとこの部分だけ使ってみて一時的な環境とかでこうちょっとだけ動かしてみてなんかいけそうだなとかこういう効果がありそうだなとかパフォーマンスは問題なさそうだなとかやってると言えばやってるかまあそれに近いっちゃっちゃう。
近いんだろうなと思いながらそれをもうちょっとこう大きい方針立てみたいなところでやるっていう感じでもあるんだろうなっていうのを感じますね。
確かになんか戦略っていうのを一つプロダクト化のように扱ってみると当然これはやるかっていう感じがするな。
プランニングしてインプリメーションしてデリバリーするんだからプロダクトと変わらんやんって感じだもん。
そうそうそうそう。
その後オペレーションもあるし。
そうそうそうそう。
とりあえず一チームでなんかやってみてとかそのチームに対して働きかけることだったりとかしたらフィードバックもらってなんかこれでいけそうだねなのかダメそうだねとかフィードバック受けて本当にスクラム回すみたいなイメージだなーってなんとなくちょっと思ったりとか。
で不確実なものはスパイクタスクにしてとかやるもんなーみたいなことをちょっと思ったりしますね。
まあでも戦略テストがそんな感じか。
でシステムモデリングですね。
これを冒頭で説明するのかい?
まあシステム思考の方に読んでください以上みたいな。
そうだからシステム思考的なモデリングをベースにしていて全体的にあるモジュール要素があってそこに影響したりとかそこから影響されたりするものっていうのがあるよねっていう関係図をバーって作っていってその力の流れとかどういう変化を及ぼすかっていうのをマップとして書き出してみると
06:24
戦略に足りているものとか実はこの戦略が影響を受けるものとかこの戦略が効果を上げているっていうのを測定するために最も効きそうなところレバレッジポイントとかっていうのを見つけるのに役立つからシステムモデリングは戦略立てるときの便利だよみたいな話あってる?
雑に言うとそんな感じになっちゃう気がするんですけど
そうですねまあでもそれでいいと思ってるしシステム思考とは言ったものの結局モデリングしてパラメーターがあってそのパラメーターをいじるとどういうふうに変わっていくんだっけみたいなボトルネックがここからこっちに移るよねーとか
なんか自分たちが検証したいことがそれによってこういう想定でいるけど本当にその想定あってるんだっけっていうことをシミュレーションできるようにしてみましょうねっていう風なことをやりたいんだろうなっていうのを読みながらちょっと思ってましたね
これを使うモチベーションみたいなのが本当にシステム思考と同じというか見落とされがちな影響範囲とか隠れた因子みたいなものを炙り出しやすくなるよねってなところが狙いな気がしますね
そうですね結局文章で書かれてもじゃあここがアクセスが増えたらどうなるんですかって言われてもいやーどこに影響行くかわかんないですねとかになっちゃうとなんかそれ足りてるのって言われたら足りてないですねじゃあシミュレーションしましょうかっていう風にただ行くだけだと思うんでそれを実際にやりましょうねっていうようなことだったりとかっていう
でまぁもちろんねモデルなのでいろんなものをそぎ落としてるんで見落としはあると思うんですけど見落としがあったらまたそれを追加してじゃあどういう影響関係にあるんだっけっていうのがまたもう一回図でわかるっていう風になるって感じもありますよね
そうですねそうですね実際こうシステムモデリングが有用な場面っていうのを書かれていて複雑なシステムのどこに手を入れるのが効果的か見当がつかないときとか比較対象として十分なデータが手元にあるときとかステークホルダー間の意見の相違が各自の肌感覚に基づいているときとかこの3つ目なんかお互いの理解度とか見えているものを見ようとしているものが違うよねって言うと
一回こう視点が合わせるというかいいからこれを見ろどうみたいな感じで打ち出せるのは確かにモデリングとかねダイアグラムとかっていうのは非常に効果が高いと思うんでそこのズレは後々めちゃくちゃ効いてくる気がするから早めに実装する前に潰せるのは良いですよね
09:02
そうですねそうですねだからどこを頑張らないといけないのかとかもよくこれでわかるとこっちはどれくらい手抜いていいのかとかもわかるだろうしいいですねいいですね
これは面白いな134ページの下の方に書かれているというかあれだなケーススタディのところにも載っている話な気はするんですけど
LLMを活用するとコードの作成やテストにかかる時間はかえって増えるかもしれないがそのコードが本番環境にリリースされた後に見つかる不具合の修正時間は減る可能性があるということがわかりました
って書いてあってLLMを活用するとコードとテストに時間がかかるっていうのは何ですかねそのレビューのステップを1個増やしたとかそういう感じになるのかな
思った通りに動いてくれないとか修正が意外と手直しを結局人間がいっぱい手直ししないといけないとかだったりするのかなこれが書かれたのは多分1年前とかだと思うんで
実際いろいろ試したのは1年2年前とかだと思うんでちょっと今のねなんか上手にいろいろやってくれない時期もあったりするのかなっていうこともちょっと思ったりしましたね
今だったらコードの作成やテストも減りさらに本番環境にリリースされた後に見つかる不具合の修正時間は減るになるかもしれないなっていう気はしますね
まあいずれにせよ目の前の問題だけじゃなくてその後ろとかさらにその裏にあるような間接的なところまで見てシステム全体でのスルーキュッとっていうところを改善してるならそれはポジティブだねって判断が実はこのシステムモデリングを使うことによって発見できたとかっていう話になる気はしますね
そうですね
逆にねそれによって採用を取りやめようとかっていうのもあるだろうしまあでもシステムモデリングそんなことですかね
感じですかね
で次が15章ウォートリーマップでこれこそ口で説明するのはすげー難しいなって思いながらなんなら自分がこれちゃんと理解してるのかっていうのすら怪しいと思ってますね
これなかなか難しいでしたね
あと聞き慣れてないなって思った
多分30分でわかるアーキテクチャーモダナイゼーションってアーキテクチャーモダナイゼーションの本に出てきてるの俺はそこで初めて知ってあんまりわかってないなと思いながらこの本を読んでましたね
これでもあれかビジネスとか経営系でやられる手法なんですかね元ネタは
なんかそれっぽいですよね
この本では今例として出てるのがナレッジ管理のプロダクトコンフレとかノーションとかウィキとかを題材に実際ちょっとマップを作ってみたんでそれを見てくださいねっていうのがあって
X軸とY軸があってX軸はジェネシスカスタムプロダクトコモディティっていう風に書いてあってなんて言ったらいいんですかねこのX軸は
12:05
よく言われるのは進化の軸かな右側がもう普通してるとか当たり前みたいな感じで左側が先進的とか将来あるかもねみたいな
って感じですよねでY軸が可視性でユーザーへの可視性が高い低い下をゼロに近い方が低くてゼロから離れる方が高いっていうのでユーザーからどう見えてるかみたいな感じになってるXY軸のグラフマップがありますよっていう感じで
でその中に書き手とか読み手とかそのユーザーが配置されていてそのユーザーがどういうニーズを持っているかっていうコンポーネントがあってそのニーズからケーパビリティに対してケーパビリティのコンポーネントに対して線が伸びているみたいな感じで
この1枚の絵の中でユーザーがどういうニーズを持っていてそれを実現するケーパビリティがどういう関係性にあるかで今そのプロダクトの中でプロダクトの機能みたいなものがコモディティなのか普通に使えるぐらいなのかまだまだ作られたばっかなのかみたいなそういうものが表現されている図って感じですかね
そうですねユーザーがやりたいことユーザーが持っているであろうニーズっていうのとそれを裏支えする技術っていうのが縦軸のユーザーへの活性が高いからユーザーへの活性が低いシステム内部みたいな風に
Y軸でマッピングされてでも一般的なソリューションとして確立される手に入りやすいものが多分右に来るんですよねオープンソースでリレーショナルデータベースが使えるからMySQLとかPosgreとかはコモディティ寄りだけどこれが50年前とかだったら高級商用でリソースめちゃくちゃいいデータベースしかなかったんで左側に寄ってくるかなとか
実現可能性とか入手容易性みたいな話とかがこの横軸でなるんじゃないかなみたいなユーザー目線でやりたいことっていうのとそれどうやりますかっていうのとそれってどのくらい実現が楽なんですかねどれくらい必要なんですかねっていうのを縦と横でマッピングしたようなものに見えるんですけど
だからあれなんですよねコンピテンシーとか見つけるときに多分使うんですよねうちの操作優位性はここにあるねみたいな
そうですねそうですねでこれをまあただマップして終わりではなくてここからさらにじゃあ未来どうしたいんだっけみたいなのをこの図にオーバーレイしたりとか
この本の例だとじゃあそのケーパービリティを支えているのはどのチームなんだっけとかっていうことを図に表していってそういうようなこうベースにしながら自分たちがどう動くのかどうしたいどうなっていきたいのかとか今どうなのかっていうことを理解するためにこの図を使っていくっていう感じになるんですかね
15:03
そうですねあと将来これがもっとこっち側に寄ってくるよねだったら今ここに投資しても競争優位性ってなんか維持できなそうだよねとかってそういう話もするのかな多分
そうですねそうですねこの中だとAIによってこう変わっていくよねでAIによって変わっていくところはみんなそれやっていくよねじゃあそうじゃない部分が競争優位性になるよねっていう風な使い方してますね
そうですね最近だとなんかAIによってSaaS企業が滅ぼされるみたいな話とかもあるしだったらAIができそうだなーって感じがするところにめちゃくちゃ投資するっていうよりかは
AIが手が届かない部分にちゃんとベッドするように戦略立てようとかっていうのは多分この図から読み取れるようになるはず
AIとかクラウドとかもねありますからね
そうですねクラウド完全にそうですねいやーでもこれを上手に使えるイメージがあんま湧かないんだよなまだ
でもウィルダーソン自身もなんかこれはまだ自分としてはちょっと何だ訓練中みたいなニュアンスでしたよね
この本を書いている途中に出会ってすぐ取り上げる価値がありそうだって言って取り上げてはいるもののまだ自分自身で実践値があるかっていうとまだちょっとまだまだかもみたいな
言ってた気がする
でまあそういうものを何ていうかツールを作ってたんだっけな
自分が作ったものを公開もしてるよとかいうことも書いてあったし色々学ぶためのソースとかツールとかこういうのがあるよみたいなことも
この章では触れられてますね
そうですねだからこの図ツールマップを使う有用な場面っていうのは15-3に書いてありますけど
すごい対局的なマーケット全体とかなんか5年10年20年みたいな中長期的な目線で考えるときに状況整理する認識を揃えるのに便利だよねっていう話でしたね
まあでもこういう風にならここで戦略テストだけちょっと経路違う気もするんですけど
何て言うんですかねこういろんなより俯瞰して物事を見たり状況を整理する視野を広げるっていうのにいろんなモデリングとかマッピングのツールを使って手法を生かして
現状認識を揃えるとか解像度を上げるっていうのに使っていくんだなぁみたいな
なんかそんな感じがするのがこの第3部って感じですかね
そうですね
てなところですかね
うん
でいよいよ
いよいよ
