00:02
きんじょうひでき
そうじゃあ26章、27章、第4部あたりの話していきますか。
なんか26あたりから本当にいよいよ学習っていうのをテーマに話が進んでいってますよね。
げんえい
そうですね。ちなみに学習する組織とかとどっちがどうなんだ、順番的には。
でも学習する組織は今ちょっと調べると、日本のもので1990年とかって出てくるから、もうすでに言われてるのか、この本が出たぐらいには。
きんじょうひでき
なんかどっちかっていうとこうやっぱりソフトウェア的な領域の話がここ20年ぐらいにだいたい固まってて、
経営とか組織論みたいな話はその20年30年前に発生してると思うので。
なんか全然触れなかったですけど、マトリックス経営みたいな話とかも第2部あたりでしたっけ、出てきて、第1部かな。
げんえい
うん、ありましたね。
きんじょうひでき
あれとかも調べてみると70年代、80年代に1回トレンドになったよね、みたいな話とか。
だから学習する組織は全然知らないで書いてるってことはまずないでしょうね、デマロコが。
げんえい
さすがに知らずに書いてるってことはきっとないと思いますね。
きんじょうひでき
26章、学習はどこで起きるかみたいな話で言うと、チームが重要っていうことも話していて、好きだなって思ったの。
タスクは結構個々人でバラバラなことやってても、チームっていうのがあることはすごい大事だよね、みたいな話をしていて。
別の本ですけど、人間は社会的な動物なんだなっていう感じがあって非常に良いですよね。
げんえい
そうですね、チームで学習をするみたいなところは自分のチームとかでは重要視してて。
きんじょうひでき
素敵なチームじゃないですか。
げんえい
そうなんですよ、素敵なチームなんですよ。
割とこれで自判したいと思って、割とプロポーザルパッと書いて、LTとかで喋ろうかなと思って出してるんですけど、落ち続けてるので。
喋る機会がどっかであればいいなと思ってるんですけど、結局学習は必要です。
で、一人が頑張ってもチームの結局はアウトプットだったりとかアウトカメに繋がらないとしょうがないと思ってるし、
隣の人が何やってるかっていうことが漏れ出てくるみたいなのって結構大事かなと思っていて、
私はエンジニアなんでデザイナーのことは何もわかりませんってなってコラボレーションしようと思うと難しさだったりとかすると思うので、
そういうところで一緒に共通のものを学習して、
エンジニアから見た視点で言うとある問題はこう見えてて、デザイナーからはこう見えてますとか、
QAからはこう見えてますみたいなことを話すことによって、
一人で学習する効果よりも大きい効果があるんじゃないかなっていうのは結構思って、
意図的にチームでみんなで勉強する時間を取るみたいなのを結構やったりとかしてますね。
03:01
きんじょうひでき
学習って一言に言ってもプラクティスを学ぶとかマインドを身につけるとかっていうだけじゃなくて、
そもそも自分たちが扱っているプロダクトとか、ビジネスだったり問題領域だったりって、
どういう問題があるんだっけ、どういう複雑性があるんだっけみたいな、
担当することも全然学習の一環だなという気はしていて、
そういうのを本当にチームで取り、チームっていうかあれですよね、
同じドメインにいる人たちがちゃんと同じ目線で、
同じものを見て会話できるっていうのは非常にやらないといけないなっていう感じがありますもんね。
げんえい
そうですね、結局エンジニアは作っている対象領域が何なのか、
QAがテストしました、品質OKですって言ったときに、前回も出てきたけど、
そこで品質って不具合がないことで使いやすいかどうかはまた別の話だよねとか、
結局バグを潰すためだけにめちゃくちゃ時間をかけてもしょうがないので、
これは期待したいユーザー体験ができているかどうかを考えましょうとかっていうことをするときに、
POと喋れるとか、デザイナーと一緒にディスカバリーができるとか、
徐々に越境していかないと価値あるものを届けるっていうのは難しいんだろうなっていうふうに思ったりしますね。
きんじょうひでき
そうですね、あと我々の趣味に紐付けて考えると、サッカーでもバスケでも、
スター選手を中心に戦略立てることができても、スター選手一人だけだとやっぱり勝てないよねみたいな話もあると思うので、
一人だけめちゃくちゃレベルつけても結構仕方なかったりするなっていう感じもあったりしますね。
げんえい
そうなんですよね、その市場がまだ未開拓で、
ファーストペンギンで競合もいなければそれで全然成り立つんですけど、
今となってはもうだいたいどこも競合がいるとかいう状態がほとんどだと思うので、
そうなるとチームプレイでうまく成果が出ないと、
一人が頑張っても出せるアウトプットってその一人に依存してしまうので結構難しいなって思ったりしますね。
あといいチームを隣に増やしたいっていうか、その人は一人しかいないから、
会社としてその人を10人増やすっていうのはやっぱり難しいし、
でもチームはコピーって言い方をするとちょっと違うんだけど、
いいチームを増やしていくみたいな活動は多分できると思うんですよね。
ターセンションを育てるのは難しいかもしれないけど、
いいチームを作るのはきっとできるはずと思ってるんで、
いいチームが一朝一夕にできるわけではもちろんないんだけども。
きんじょうひでき
まあチームづくりね、難しいですからね。
難しいけどやらないと結局ゆとりが出てこないのでみたいな話になるんだよな。
げんえい
人は辞めていくので、辞めていくと一気に全てが崩壊する状態っていうのはやっぱり避けたいし、
避けたいってなるとチームを解体すると良くないけど、
06:01
げんえい
チームから徐々に人が抜けるぐらいの余裕はある状態にしておきたいよねとかいうのはあったりしますね。
きんじょうひでき
そうですね。
いやなんか、第三部あれですね、一章一章がすごい、
いくら噛んでも味が出るぞみたいな状態になってて。
なんか大変な。
げんえい
そうですね。
きんじょうひでき
ちょっと急ぎ目に行ってみますか。
27章。
知的組織には健全な闘争など存在しないと断言していて。
そうですね。
これすごいなと思いますね。
内部の闘争は全て破滅的であるとのことです。
げんえい
こう言い切るってことは相当いろんな現場を見てこう思ったってことですよね、きっと彼は。
そうですよね、コンサルの人ですもんね。
きんじょうひでき
どうですか、やっぱり健全な闘争存在しないなって思いますか。
げんえい
ここでいう競争っていうのはどういう競争なんですかね。
そこなんですよね、そこなんだよなと思いながら。
きんじょうひでき
まあでも俺の方が評価されるようにしよう、出世しよう、お給料を上げてもらおうみたいな。
それが最大のインセンティブになった時にお互いにライバルみたいな関係になって刺激し合ってっていうよりも、
相手の足を引っ張ったり妨害した方が自分の成功につながりやすいみたいな、そういう話なのかなっていう気はしたんですが。
げんえい
そうなった時に知的組織じゃない場合は健全な競争が存在するっていうことですかね。
知的組織もわからなくなってきたな。
これは知的組織には健全な競争が存在しないっていうことは何かと対比しながら言ってるってことなのかなって思いながら。
そうすると工場の生産とかでラインが3つあって競争があるみたいな。
こういう言い方をすると工場のラインが知的じゃないみたいな発言になってしまうけど。
きんじょうひでき
難しいですよね。
げんえい
テイラーイズム的に言えばそうじゃそうなんですよね、ベルトコンベアみたいなところ。
きんじょうひでき
生産量がそのまま価値につながるとかそういう感じかな。
げんえい
トレードオフにならないとかなんですかね。
こっちがゼロサムでAとBが競い合うとAが80%取ってBが20%しか取らないみたいな状況ではなくて、
知的な組織においては別に両者総取りできるゲームになってるでしょっていうことなのかな。
きんじょうひでき
確かに。組織内の競争っていうものに対してすごい批判的な立場を取ってる人だとは思うんですが、
じゃあどうしろっていうことだな。
げんえい
そうですね。攻撃と防御が出てきて有害な行動を取ってしまって、
09:05
げんえい
非協力的なことが起きてしまうから、君たちは知的でスマートなんだから、
そういうことはしないでしょっていうことなのかな。
きんじょうひでき
曖昧な倫理観に頼ってるからクソだみたいなこと言ってる本人がそんな結論に。
でもあれですね、競争というか攻撃と防御とか妨害みたいな関係が発生すると何が問題かっていうと、
あくまで学習が進むような組織状態にならないよねっていうところが問題だっていう立場のはず。
この27章の最後のまとめみたいなところを見てみると、
学習しない組織のための処方箋っていうふうに書いてあって、
組織から内部の競争を排除し、管理者同士で党力協調共有ができるようにするみたいなことが書いてありますね。
げんえい
確かに。
きんじょうひでき
競争を排除するのか。
げんえい
競争よりも協力とか協調、共有をしましょうと。
いやー、でも人間はね、社会的に嫉妬もするしねとか。
きんじょうひでき
そうですね。
げんえい
なんとなくこの文脈で思い浮かぶのって、いかに問題と我々みたいな構造を作るかとかっていうのはそういうことの一つかもしれないなって思ったりとか。
きんじょうひでき
確かに。
げんえい
結局隣の人は別に対戦相手ではなくて、
同じ問題を解く協力プレイのプレイヤーだよっていうふうに捉えるように設定しておくとうまく回るし、
じゃあこの問題に対して今我々が足りてないことは何だろうみたいなことを考えて、
これを勉強しないとダメなんだみたいなとか。
学習しないとわかんないんだなっていうことがあれば学習をするだろうしとか。
そういうことを捉えることもできそうな気がしますね。
きんじょうひでき
そうですね。
げんえい
そして最後に言うだけなら非常に簡単なことだ。実行するとなると複雑であるって書いてあるので、まあですよねみたいな。
きんじょうひでき
今さら何言ってるんだお前みたいな感じがある。ずっと難しいこと言ってるじゃねえかみたいな。
げんえい
簡単だったらこんな本は出さなくてもみんなできてるってなるんで苦労はないですよね。
きんじょうひでき
27章はそんな感じか。
第4部ですね。リスクとリスク管理。これが最終章じゃない部になっていて、
ここはタイトルの通りリスクとかリスク管理みたいな話をするセクションではあるんですが、
これでも結構このゆとりの法則っていうところでここが最終部になってるのは結構面白いなっていう感じが個人的にはするんですけど、
12:01
きんじょうひでき
なんかリスクを回避しましょうって話を一切してない感じがあり、
どっちかっていうとリスクを取って挑戦するからこそ学習とか成長につながるよねみたいな。
リスクを取るっていうのがどれだけ価値のあることかみたいな話をしている感じの第4部ですね。素敵な素敵な本だなあと思いながら。
げんえい
自分が読んでこの4部全体的に思ったところで言うと、リスク管理ってみんなどれぐらいしてるのかなみたいな。
言葉を使い分けとかちゃんとしたものはあるかもしれないけど、リスクって結構発見的なもの、表面化されてないものって結構それは不確実性という時と場合によって読むのかもしれないけど、
ことが多くてそれに対する管理ってみんな結構してるのって思うとどうなんですかねみたいなことはちょっと聞いてみたいなって思いましたね。
きんじょうひでき
言葉の定義みたいな話がもちろんあるなあと思いながら、例えばプロジェクトを始めるとか新しいチームで集まって何か始めるよっていう時に、
どういうリスクがありそうですかねみたいなところは結構洗い出すというか、僕はチームビルディングとしてどういうことがリスクに感じますかっていうのを全員で話すっていうワークショップをやったりしますね。
話がずれちゃうかもしれないですけど、そうすると一人一人がどういうところに対して豆腐とか不安とか逆に自信を持っているメンバーがこのチームの中にいるのかなみたいなところが開示されていってですね結構面白いんですよ。
全員がリスクに感じている部分に関しては早めに実験しましょうとか何か学習しないとねみたいなところに持っていけたりするのでよく使ってましたね。
げんえい
インセプションデッキとかで夜も眠れなくなるような問題は何だろうかってあるけど、まあそれって感じですよね。
きんじょうひでき
それっていう感じです。
そこらへんでよく出てくるリスクとして挙げられるものとか、リスク管理っていうのは健在化したときにそのリスクに対してどう対処するかみたいな話なんですけど、ソフトウェア開発やっているので技術的な課題、
仕様がわからないとかパフォーマンスちゃんと出るかっていうのがわからないみたいなところがリスクとか困難なところに挙げられていたりとか、あとはめちゃくちゃ出るのはスケジュールの話ですよね。
げんえい
そうですね。
きんじょうひでき
なのでそこらへんはもう話題に誰かが出しちゃったんだから目を反らせないねっていう雰囲気になって、じゃあどういうふうにモニタリングしてどういうふうにアクションを打っていこうかっていうような話につなげてたりするけど、
そのぐらいはやってるかなぁ。ロザクトゴールがはっきりしないままであるとかは出たりしますけど、なんかちょっと経路が違う気もしていて。
15:11
げんえい
そうですね。なんかやっぱ最初にリスクとしてあるのは作ったけど使われないとか、じゃあ私が作っているものは本当に顧客が価値を感じるものなのかみたいな。
ってなるとじゃあ早めに検証したいねみたいなって。
Mockを作って、内緒はペーパープロットなのかもしれないけど、実際触ってもらう。ユーザーのとこに行ってみるとか、ディスカバリーやるとか。
そういうのは確かにリスクコントロールっていうか、もはやプロダクトってゾッ作るんでしょうぐらいな気持ちに思ってるから、リスクなんだよな実際それは。
リスクだからそういう手を打ってるんだけど、息を吸うようにそういうふうに考えてしまってるなっていうのを思ったりしました。
きんじょうひでき
あれもありますよね。最近言うと円が安いですみたいなのも非常にリスクだなと思うので。
そうするとデータベース使えるインスタンス変わってくるんですけどみたいな。
げんえい
そうですね。
きんじょうひでき
ソフトウェアアーキテクチャの基礎のほうに技術課題的なものに関してはどういうふうにプライオリティつけていこうかみたいな話が非常によく触れられてましたね。
あの本よかったな。パフォーマンスが大事っていうプロダクトという認識なんですね。
じゃあこういうアーキテクチャでいきましょうみたいな話をしてる本なんですけど。
なんかそれもある意味リスク管理に多分通じてくるんだろうなみたいな。
げんえい
確かに。
きんじょうひでき
逆に言うと100万ユーザーに耐えられるように実装しますっていうとコスト、時間とかお金みたいなところの別のリスクが出てくるわけなので。
げんえい
っていうのがあれなんですかね。リスクの抑制というか。
そうですね。あんま自分ならそういうのをリスクっていうか考えることの一覧みたいな感じとして思ってるっていう捉え方のほうが、なんか当然やるでしょみたいな感じに思ってて。
あんまりリスク分析のためにそういうことをやっているっていう感覚がなかったなっていうのをちょっと今話を聞いて思いましたね。
きんじょうひでき
そうですね。立ち行かなくなって失敗するみたいなところを避けることにつながるのはすべてリスクだったりリスク管理なのかなぐらいのすごいふわっとした感覚ではあるので。個人的には。
そうですね。対応計画を事前に立てておくとか、プランB、プランCをちゃんと出しに入れておくみたいなのはありますかね。
18:08
げんえい
そうですね。大体いつも気にされるのって、テイクホルダーから期待されることは大体いつ出てくるんだっていうことと、リリースが間に合うのかみたいなこと言われるから、割と実行部分というかプロジェクトの進捗みたいなところを管理するみたいなのはやっぱり一番多いような気がするなっていう。
きんじょうひでき
特に自社プロダクトだと余計にそうなりがちかなっていう気がしますね。スケジュール的な話と。それ以外のお金を自分たちで取ってきてないみたいなところで、本当は全然抱えているリスクって変わらないはずなんですけど、なかなか意識されづらい、見えづらいものになっているのかなっていう感じもしますね。スケジュールだけははっきりわかるので。
あれ、7月までにやるって言ってたよね、みたいな。ここら辺だけバレやすいので、非常に顕在化しやすい。
げんえい
本当はこれも権限みたいなところもセットでっていうのはあるんですけど、お金的な部分、さっき見えにくくなっている部分とか、たぶんちっちゃいスタートアップだったら緊張させないと終わりますみたいなところが見えたりするんでしょうけど、それぐらいに規模が大きくなるとたぶん見えなくて。
結局我々が一体どれだけ時間と人数を投入して作った機能は使われているのか、もしくは売り上げに貢献しているのか、何ならアップセルとかMRRとかにどれぐらい反映しているのかって、もはや規模が大きくなってくると追うのが難しくなっていったりとか。
あとマネージャーレイヤーはもしかしたらその情報を持っているけど、マネージャーから別にその下に話が降りてくるかっていうと、たぶんそんなことはなかったりとかいうのはありそうだなと思いながら。
きんじょうひでき
そして目標管理の話に戻るみたいな。
げんえい
そうですね。
きんじょうひでき
セールスとマーケット、プロダクトで何でも持っている目標が違うんだっけみたいな話になってきますね。
げんえい
そうですね。会社の期待値としては機能を作ってほしいとだけ伝えられたりとかして、セールスは新規の契約を取るとかになっていると、新しい機能を作った方がいいのか、単純にアップセルのために既存の機能を回収した方がいいのかとかね。
そこでもう既にずれが発生したりだして、これは強調しないとバラバラなのではみたいなことは起きがちですね。
21:00
きんじょうひでき
そうですね。本当はカートに入れるっていうフォントサイズを上げる方が一応売り上げに効くかもしれない。
そうですね。本の話に戻ると第4部というか第32章で、そもそもリスク管理などしていないのではっていうドチョックな説がありますね。
これはリスクっていうのを明確に意識してギリギリまでアクセル踏もうぜみたいな話に近い気もするので、この本が言っているリスク管理って。
そうするとプロジェクトがちゃんと納期に間に合ってるし、成功してるんでリスク管理してないですよってなったら、実はもっと攻められるかもしれないねっていう話に繋がっていくのかなとかも思ったり。
げんえい
ディフェンシブなリスク管理にばっか目が行ってると、さっき言ってた変質向上プログラムみたいなところに繋がっていってプロセスのドレインになってくるよねみたいな。
そうですね。最後の方とかも予想完成日より前に完成する可能性十分にある。それがない場合は予想完成日ではなく完成目標が完成予定になっている。ここに終わるよって言って前倒しにならないってことはそこに間に合わせるように作ってるでしょみたいなことだったりとか。
それで結果アクセル踏んでないよねっていう感じはあったりするし。
きんじょうひでき
この辺を意識してリスク管理していこうと。
げんえい
そうですね。リスクを特定できない企業は目標と予想を区別できずリスクを回避しようとしたり、やみくもにリスクを取ろうとする。いずれも良い仕業にならない。
きんじょうひでき
本当に怖いことを言う。
げんえい
リスクを追って勝負に出るって言った時には、ハイリスクハイリターンみたいな言葉があるぐらいだから、何を自分たちはトレードしているのかとか、何を手に入れるためにこういうリスクを取っているのかみたいな。回避することだけだと小さく別途することしかできないみたいなことっていうのは大いにありそうだから。
きんじょうひでき
そうですね。
げんえい
やばい、何も考えていないことを露呈してしまった。
きんじょうひでき
あと多分若干言葉遊びっぽくはなりますけど、ゆとりというか余裕とか安心安全みたいなのがないと結局リスク取れなくなっちゃうので。
本当は大したことじゃないとかクリティカルじゃないことに対して大げさに反応してないかみたいな。そのせいで重厚長大なプロセスが生まれてないんですかとか。
24:10
きんじょうひでき
5年前に作られたJSOCKSの対応のためのルールが見直されておらずみたいな。DXが進んでないみたいな。
げんえい
そうですね。イメージでしゃべるんで、これは架空のプロジェクトだし、フィクションですけど、重厚長大なプロセスとかマイクロマネジメントみたいな。
つまりプロセスにこだわって、オンスケですって言わせるにはどうしたらいいかみたいなことにこだわった結果、オンスケになるようにリスク回避をしているというふうに捉えると絶対に失敗しないように重厚長大なプロセスを作り、早めにアラートを上げさせるようにしてみたいな。
それ自体はいいことかもしれないけど、それが結局プロダクトの価値にどう寄与しているのって言われると、そうですねみたいな気持ちになってきますね。
そこにはいろんなものがごまかされているわけですよね。進捗80%です。お前ダンになってないってことは価値ゼロやぞってこととか。
きんじょうひでき
そうですね。
げんえい
僕はちょっと使いにくいって思ったとしても、この要求仕様に書かれていることは満たしているからOKとか、ちょっと使いにくいなって思った違和感みたいなのがあちこちにあって、それがそのままリリースされ、ユーザーがそれをテストして、実はユーザビリティのテストの部分をユーザーに押し付けているとか。
リスクを回避した結果、何を得たんだろうかって言われると、結構確かにうーんってなっちゃいますね。
きんじょうひでき
そうですね。進捗何%をやめたいですよね。
そうですね。やめたいですね。
げんえい
完成する確率みたいな話も出てきてたりはしますね。
きんじょうひでき
うん。
げんえい
でもこれで一通りスラック、ゆとりの法則をなぞった感じですかね。
きんじょうひでき
そうですね。いい本ですね。
いい本でしたね。
げんえい
もちろん変わるために、スクラムみたいなものとか、XPとか、アジャイルとか、リーン志向だったりとか、いろんなものは出てきているものの、まだそれがすごく浸透しきっているわけではないってことを考えると、
20年前にこういうことがすぐに書かれている。
四半世紀か、四半世紀前に書かれている中で、
27:00
げんえい
どれくらいかけたら自分たちはこう変わるのかな、みたいなのをちょっと思ったりしますね。
うん。
まあ、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
自分たちが、
きんじょうひでき
同じ所を行ったり来ているように見えるけど、
同じ所を行ったり来ているように見えるけど、
10年前、20年前よりは、
ユニットテストも書くようになったし、
ユニットテストも書くようになったし、
げんえい
デプロイ頻度も上がったし、
きんじょうひでき
4keysを測っていない人なんて多分、
もういないので、
げんえい
猫の尺寸は4keysで、
猫の尺分は4keysで、
きんじょうひでき
自分の目で動いているように見えない 仕事しているように見えないものを
出して慶応感とか不安を抱くみたいなのが 多分本当の本質的だからこそ
20年後も言っていいんじゃないかなっていう気がする
あとは結局そんだけこういろんなスキルというか 考え方とか手法
げんえい
いろんなものが出てきて
一方でまだ納期に間に合ってないとか リスクテイクしてないとかっていうことに考えると
結局簡単な問題はもう解決してくれてるんだけど 難しい問題の時は残り続けてるって話がこの中にあったけど
結局我々ずっと難しい問題と向き合っている以上 そこには不確実さだったりとかリスクだったりとか
いろんなものがあり うまいことプロジェクトを完了させるっていうのはずっと難しいってついて回るんだろうなっていう気はしましたね
そうですね なので10年経ってもこの本はちゃんと売れてるという
きんじょうひでき
そうですね
そのためにはやっぱり学習だったり 言い取りを生み出しておかないと
げんえい
リソース効率だけ上げたってしょうがないんだっていうことにやっぱり気づいたりとかするので
今読んでもすごくいいし 実際いろんな人に読ませてもらったりとか
そうですね 内容的に古びた感じがほとんど一切しないって言ってもいいぐらい個人的にはしなかったので
きんじょうひでき
ただ具体的なプロジェクトマネジメントの秘訣というか 実際のプロジェクトマネジメントというか
心構えとか捉え方みたいな話が多いので
どっちかというと組織作り系のマネジメントをやっていると
5人の1チームを見ているリーダーですっていう人よりかは
間接的にプロジェクトマネジメントをしている人
そういう人たちにとっては
中間管理職に呼んでもらいたいですね
そうですね
30:01
きんじょうひでき
多分触れなかったけど 中間管理職にこれを呼びますと
例えば 製造と製造の人は 製造の人は製造の人とは別のプロジェクトをしているのかなっていう
バランスがないというのはすごくいいと思うんですけど
そういったプロジェクトマネジメントの中に入ってから
げんえい
で 多分 触れなかったけど 中間管理職にこれを寄せると 上の人にこの本を
読んでほしいですって言われるんだな みたいな
きんじょうひでき
ああ はい その感想を聞くと この本の講演をしたデマドコが この講演は成功だったんだなって思うようにしたって言ってましたね
そうですね
昔はそれ言われるのが嫌だったけど
うん じゃあ誰に話せばいいんだつって ずっと
彷徨ってたんだけど
げんえい
そんなとこですかね
はい
きんじょうひでき
めちゃくちゃ時間がオーバーしましたね
げんえい
めっちゃ喋りましたね
きんじょうひでき
いや ゆとりがないとできない
じゃあ 第1回というか第1シリーズは締めていきますか これで
はい
で 次回が
げんえい
さっきの最後のとこがリスクと リスクの話があったんで
きんじょうひでき
じゃあリスクの足を続けて読んでいこうと
うん
でも目次見てもやっぱり面白そうですね
げんえい
確定性を数量化するとか 価値の数量化とか
うん
確定性を数量化するとか
うん
きんじょうひでき
確定性を数量化するとか
うん
確定性を数量化するとか
確定性を数量化するとか
価値の数量化とか
うん
げんえい
リスク管理の検証みたいな
きんじょうひでき
いや いいですね
これをじゃあ
はい
げんえい
2週間後には読み終わってここにいると
きんじょうひでき
そうですね
はい そんなところですかね
なんか言い残したこととか宣伝とか 大丈夫ですか
げんえい
言い残したこと
みんなで丸声で読みましょうぐらいですかね
きんじょうひでき
はい
我々も読んでるんで
げんえい
あとは小ノートに多分今回取り上げた本が いっぱい出てくると思うので
気になったものもセットで読んでもらえると 嬉しいなという感じですかね
きんじょうひでき
ハッシュタグつけて詰んだよって ボストしてくれると
げんえい
そう
きんじょうひでき
俺も俺もっていう気持ちになるんで
げんえい
喋りても嬉しいので
きんじょうひでき
そうですね
はい じゃあおしまいにしていこうと思いますので 提携文を読みますね
げんえい
はい
きんじょうひでき
はい じゃあ今週も放送をお聞きいただき ありがとうございました
ではまた次回 さよなら
げんえい
さよなら
