00:06
きんじょうひでき
受け入れテストの話とかちょっと触れますか?大丈夫ですか?
げんえい
そうですね。あとは、この本の中で26章が受け入れテストになっていて、
やっとテストの話が来たな、みたいな。だいぶ後ろの方にあるなと思いながら、
読んでて、シフトレストしてないなって思いながら読んでて、
受け入れテストの話の中で、受け入れテストは仕様書であるっていう表現が出てきて、
これは友田丸子が言ってることではなくて、別の人が言ってるんですけど、
受け入れテストは仕様書であるよって話をしていて、著者はこれをひっくり返して、
こう言いたいよって言ってて、仕様書っていうのは受け入れテストであるよっていう話をしていて。
きんじょうひでき
本当にひっくり返すだけじゃんって思いました。
げんえい
でもこれってまさにATDDとか、あとV字モデルの話をするとき、
開発のフローでV字モデルってありますけど、あの時に仕様書を書くってことは、
それがそのままテストに使われるんだよって話とか、
さっきのストーリーチケットの話でも受け入れ条件が書いてあってっていう中で、
受け入れ条件がちゃんと書ければ、そのまま受け入れテストは、
結局そこに書いてあることをテストしていけばいいんでしょっていうことが明確になるんで、
やっぱり仕様書っていうのは受け入れテストなんだよ。
つまり受け入れテストのときに何するんだっけってことが分かるように書かれてないといけないんだよっていうことっていうふうに思うと、
この当時にこれを言ってるっていうのはやっぱりすごいなって思いましたね。
きんじょうひでき
QAの項目ぐらいの、こういう操作した時にこういう結果が期待されるみたいなのが打列されてたら、
げんえい
多分それが仕様書、具体的な仕様書にはなってしかるべきですもんね。
そんな細かいところまで仕様書を書くみたいなところあるかもしれないけども、
でも結局そこをサボるから、なんか期待してたのとあれ違う動きになってるねってことが起きるので。
きんじょうひでき
でもやっぱりあれじゃないですか、そんな細かいところまでやるとプログラマーの権利を侵害してるんじゃないですか。
げんえい
確かに。
まあでも、プログラマーって権利なので、
まあだからプログラマーが書けばいいんじゃないっていう話でもあるっちゃあるかもしれないですね、もしかしたら。
そう、なんか結構ストーリーチケット誰が書く問題みたいな、ちょっとこれは一気に現代の話になりますけど、
スクラムとかでバックログを作ってチケットを作っていくときに、そのチケットの受け入れ基準とか詳細なことを書くのって、
誰書くといいのかなみたいなこと結構悩んだり自分はしていて。
03:01
げんえい
え、でもそれあれじゃないですか、リュウジー.comに答え書いてあるじゃないですか。
うん、けど、
例えばそのPOが起点としてチケットを書くってことはあるけど、
でもそこにHowをあんまり書かれてもなっていう気持ちもあるんですよね、自分の中で。
きんじょうひでき
そうですね、そうですね。
げんえい
でも、いわゆるユーザーにこういうことをさせたいから達成させたいことが書かれていて欲しいけど、
でもそれが達成されてるかって、いろんな人の観点からだと曖昧さがあって、
この時どうします?みたいなことってやっぱりいっぱい出てきちゃうんで、
そうするとまあ、できるだけHowの部分も決めちゃった方がいいよねっていうこともありながら、
で、それをさらに網羅的に書くってなる時に、誰が書くといいのかなとか、
それを前スクラムマスターの友人と話してたら、
それはチームの成熟度とかチームのイルメンツとかによって変わってくるんじゃない?っていう見もふたもないことを。
きんじょうひでき
スクラムマスターは大体の質問にそれで返しますからね。
げんえい
になったけど、じゃあ今のチームだったらどういうふうに書くのがいいかっていうのを話すっていうのがいいんじゃない?みたいなことを言われて、
それはそうみたいな、それは本当にそうっていう感じではあるんだけど、
なかなかそうですね、アナリストが使用書を書くとか作るみたいなところはあるんだけども、
結局誰がどういうことをやった方が現代において開発はやりやすいとか成果が出しやすいみたいなところ。
っていうのは結構難しい。
いきなり集まってパンとやればできるとか、
事前にPOとか仕様を考える人がドキュメントをパッと書いていて、
きんじょうひでき
あと開発者に作ってって言えばできるかというとそうではないなって思ったりとかをちょっとしましたね。
これは僕はライセンスが執行してなければ一応認定スクラムマスターなんで、
ある程度そこらへんについては考えたこともあって、
まあまあまあプロダクトオーナーが基本的に書きます。
でも全然悪くはないと思うんですけど、
ただチーム全員がユーザーストーリー書けるようになってたら、
どうですか?なんか力強くてワクワクしませんか?みたいなのはちょっと問いかけてみてもいいかなって思っていて、
モブワーク的にみんなでワークショップでユーザーストーリー書いてみましょうとか、
清書してみましょうとかでも最初はいいかもしれなくて、
最終的にユーザーストーリーというかプロダクトバックログに責任を持つのはプロダクトオーナーであるべきだなと思うんですけど、
開発者がストーリー書けることのメリットって少なくないと思ってて、
実装的な技術的な難しさっていうのがどうしても目についてしまうから、
ここで分割したいよねってなった時に、最初の努力、最初の労力でどんだけ価値の高いバックログのスライスできそうかみたいなのって、
06:08
きんじょうひでき
開発者の視点が入るとなんかめちゃくちゃ効果的になるよなぁみたいな気はしていて、
そういう意味でプロダクトオーナーに対等な立場でこのストーリーでどうすかって提案できるぐらいのユーザーストーリー書ける腕力みたいなのを開発者とかデザイナーとか、
テスターでも誰でもいいんですけど、持ってるとなんかめちゃくちゃうまくいきそうだなぁみたいな感じはしますね。
げんえい
で、プロダクトオーナーが全部書くんでしょうってなると多分ゾンビスクラブになっちゃうなっていうのはありつつ、
きんじょうひでき
なんかそんな個人的なあれはあります。
げんえい
いやーなんかそれ何でもできるやつ集めると強いみたいな世界観で、
すげー同意するし、実際自分は書けるようになりたいと思ってめっちゃいろんなスライド読んだりとかブログ記事読んだりとか、
そういう発想がなかったからやっぱりAPIを作るとか、データベースを設計するみたいなチケットを作って、
これじゃないなーみたいなこととか、やっぱりサイズをちっちゃく切る。
価値があるんだけどチケットの単位はちっちゃくできる。どうやったらできるかなって。
本当に練習しないと書けないなっていうのは感じたし、
けどそれがみんなにやってねって言うと、やっぱりすぐはできないんで、練習が必要で。
そもそもなんかシステムの見方を変えないといけないですからね。
今まではAPIとかコンポーネントみたいな単位で見てるけど、
ソースライスするんじゃないよ、ケーキのカットの話が有名ですけど、
クリームだけ食べたいわけじゃなくて、いちごがちゃんと入ったショートケーキが食べたいんだから、
ちゃんとそうやってカットするべきだっていう話があるけど、それができるようになるってなかなか結構ハードですよね。
きんじょうひでき
ハードなんですけど、ただユーザーは質の高いAPI見て喜んでるかというと、
プログラマーは他人のサイトで質の悪いAPI見て喜んでるかもしれないですけど、
そうじゃないんだから、結局どんだけユーザー目線でやれるかとか、ユーザーファーストですとか言ってるくせに、
私はAPIドリブンで思想を持ってますみたいな話だと、君は一体何なんだいってなるんで、
ユーザー目線を持ててる方がいいよねっていうところに共感したり同意できる人たちなのであれば、
その最多の例として、いかに早くユーザーを喜ばせるかっていうのを考えるのが、
ROIの高そうな期待値の高いプロダクトバックログユーザーストーリーを書くことだと思うんで、
げんえい
やれた方がいいですよね。スクラムは基本的に全部できるやつが最強みたいな目指すのが前提だと思うので、
09:08
げんえい
個人個人じゃなくてもいいんですけど、少なくともチームとして最強である必要があるので。
いや、そうなんですよ。
きんじょうひでき
逆に開発者はユーザーストーリー書けませんっていうのであれば、
じゃあプロダクトオーナーと対等に対話できてるんですかみたいな話になるんで、
POが言ったことが全て正解ですって言ってるチームと何が違うのみたいな話をすると、ちょっと煽ることができます。
げんえい
そこがピンとくる人たちが集まってるといいけど、そうですねで終わると悲しい結末がゾンビになっていくなみたいなことはありますね。
きんじょうひでき
やりたい人からやり始めるでいいと思いますけどね。いきなりチーム全員でここを目指すって決めたんで、
7人全員が一気にやりましょうって話じゃないと思うんで。
逆に言うと全員がすべて同じようにできるのであれば専門家が集まってる集団である意味が逆になくなるので、
勇気もしつつ、チームの成績とプロダクトオーナーの忙しさによります。
何でもいいけど価値は出してねっていう。アウトカムが生まれてればOKですみたいな感じで。
げんえい
そうなんですよね。結構悩んだなと思いながら。
きんじょうひでき
難しいですからね。コード書くだけで難しいのに。
げんえい
そうそうそう。でもこうやったら早く届けられるんだよねみたいな話はやっぱり開発者の方からできる方がいいなって思うんですよね。
やっぱりPOの持ってる引き出しというか見てる視点とプログラマーが見てる視点って全然違うと思うし、
こういう風に切れるっていうことがストーリーチケットを分割できるっていうことっていうのが、
開発者の視点でこれは実はそんなコストが高くないんだみたいな話っていうのは。
POはやっぱりわからない場合が多いんで、システムの中身を知ってるわけでも全部を把握してるわけでもないし。
ってなるとやっぱりどんどん提案をすべきだよなって思いながら。
だんだん任されるようになって大体こういうことを実現したいんだよねだけで、
成熟していくとハウの部分を取っ払って、こういうことをやりたいからあとちょっと埋めといてっていうふうな会話ができるようになっていくんだろうなって思ったりしますね。
きんじょうひでき
それこそ認定スクラムマスター研修で、2&Aの時にいいプロダクトバックログとか、
うまくスクラムができてる、スクラムのチームっぽく活動できてる人たちの作ってるバックログってどんな感じですかっていう質問があって、
12:07
きんじょうひでき
それトレーナーの方が答えてたのが、なんかアウンのことになっちゃってるからプロダクトバックログマジで1行2行しかないですみたいな話をしてて、
いかに正確に情報量を盛り込んでるテンプレートというか形式、組織みたいなものが知りたいなノウハウを盗みたいなみたいな質問だったはずなんですけど、
うまくいってるうちは全部伝わるから1行2行かけるみたいな話をしてて、いや面白いなって思いましたけどね。
げんえい
今のその話すごい面白いなと思って、これで締めに入っていきたいなって思ってるんですけど、
今この本読んできて我々はいかに膨大なドキュメントを作るかとか、その膨大なドキュメントをいかにメンテナンスができたりとか、ユーザーと会話に使えるかとかって色々話してきたんだけど、
それぐらい当時の開発規模とかでかいってことなのが、現代は大きくものを考えて作るっていうのは難しい。
複雑さに耐えるっていうのは予期しないことがたくさん出てくるから難しいから、できるだけ効果的なところを探りながら、
小さいチームでデカいドキュメントを保持するんじゃなくて、運の呼吸で伝わるようなサイズ感を維持しながら価値を届けていくっていう方がいいんじゃないっていう価値観がカウンターとして出てきてるっていうのが、
この50年ぐらい、40年ぐらいなのかなっていうのを今の話を聞きながら思ったりしましたね。
きんじょうひでき
小さなチーム大きな仕事ってことですね。
げんえい
でも確かに一人でできることの幅が広がってると思うんですよね。まさにレールズが出てきて、10分でブログが作れるようになっていくとか。
きんじょうひでき
別にCDRとか焼かなくてもデプロイできるわけですからね。
げんえい
CDRに焼いて、バイク便で届けて、客先に持ってってインストールしてとか、そういうことはない世界。あるのかもしれないけど、ほとんどそういうことは前提とされてないような時代なんで。
きんじょうひでき
ゲームのルールの中で出間どこが戦ってるとこの本が出てきたんですけど、
そもそもビッグプロジェクトをいかに成功させるかじゃなくて、ビッグプロジェクトやめようやみたいな。
1年後にうまくいくことじゃなくて、2週間に1回リリースしていこうみたいな話になってきてるから。
そこら辺があるとやっぱりこの本をそのままの身にした明日から使えますっていうにはなりづらいのかもしれないですね。
げんえい
そうですね。だからその2週間の範囲のためのものに、その限定されたコンテキストで限定された小さいサイズで辞書を作っておくとか、
15:05
げんえい
データフローを作っておくというのは多分すごく有効なんだろうけど、どんどん変化が激しくて変わっていく中で、
そういうものがすぐ、もしかしたら破棄されてしまうからもう1回作り直さないといけないとかなっていく状態だと、
結構ドキュメントを作る時間がどれぐらい割けるかとか、アナリストが2週間のうち1週間を分析に使いますっていうのが
どれぐらい現代において価値があるかみたいなところがやっぱりちょっとゲームのルールが違うんだろうなっていう気がしますね。
きんじょうひでき
これただ長期的な時間軸の中ではこういう戦い方が荒れてる有効相だみたいなところはあるのかなっていう気もしていて、
ピープルウェアに書かれてたのかな、なんかいろんな方に書かれてたと思うんですけど、ピープルウェアでも確か言及されてたやつが、
新人がやっと価値を出せるまでにかかる時間ってすごい損失、投資のフェーズで流れてるお金ってでかいよねみたいな話が書かれてたと思うんですけど、
このドキュメント、それこそナレッジデータベースとか、この本で言うとデータディクショナリーとか、仕様が明確に書かれてるとか、
オンボーディングというかタッチアップするのめちゃくちゃ使えると思うんですよね。
だから即戦力とまで言わなくても、今までプログラミングの力がある人、経験者が戦力化するのに、
どうしてもこの半年ぐらいのシール期間みたいな、育成期間みたいなのがどうしても発生してしまっていた、オーバーヘッドになっていたっていうところが、
実はここで書かれているような明確で厳密な詳細な具体的なドキュメントがあることによって結構そこ削れるんですよってなったら、
割と今だと1個の機能を作るのに2年3年かかりますみたいなリードタイムでソフトウェア開発あまり特に上向きはしてないと思うんですけど、
まあ捧げ、どっかの捧げをしてたかと思うんですけど、
きんじょうひでき
メンバーの入れ替わりっていうのは何だったら最近の方があるかもしれなくて、
そういうところも変数として織り込んだ上で2,3年で生み出す価値を最大化するってなると、
なかなかこのドキュメントってやつは捨てたもんじゃないのかもなとか思ったりしました。
げんえい
いいですね、その人の入れ替わりとさっきのアウンの呼吸っていうのは多分対になってますよね。
きんじょうひでき
そうなんですね、だからチーム単位で転職してるとか素晴らしいと思うし、
今デマルコトーネリスターさんみたいなずっと一緒にやってますみたいなのはあるべき姿でしょうね。
18:06
きんじょうひでき
最近だとねPerfumeが25周年でした。
げんえい
そうですね、その話は結構したいけど時間があれなんで。
これをしたらこれでまた1時間、2時間って経っちゃうんで、ちょっとしないですけど。
っていうところですかね。
きんじょうひでき
どうですか、読んでもらいたいですか、この本は。
げんえい
いや、読まなくていいんじゃないって思ってたんだけど。
やっぱりこれよりも現代におけるいろんな前提があって、その本を読んだ上で、
今我々が読んできたように、現代から過去に戻りながら何が差分は何なのかみたいなところを認識して、
現代のゲームのルールがどうなってるかってことを認識する上で、読むにはすごくいいかなって思ったりはしましたね。
きんじょうひでき
いい話、いい感想になってしまったね。
げんえい
あとは、トム・デ・マルコ大好きだって言ってる人たちはぜひみんな1回は読んでみるといいんじゃないかなって思ったりとかしますね。
きんじょうひでき
そうですね、トム・デ・マルコ大好きくらいの皆さんは。
げんえい
全然今までの経路が違うから、読んでみるとそれはそれでやっぱり面白いだろうなって思いますね。
きんじょうひでき
直近2回というか前回の本とは割と似たような時代に書かれてますしね。
げんえい
そうですね。
きんじょうひでき
僕はそこまで悲観的に、本を読む時間を年節するのが厳しいぐらい忙しい人は別に読まなくていいんじゃないって思うんですけど、
現代、働いてるのに本を読む人なんて暇人しかいないはずなんで、
そんな人は読んでみても応用として面白いかもしれないし、いいんじゃないかなって思ったのと、
あとなんかデータハローダイアグラムの考え方、なかなか個人的には面白いな、刺激的だなって感じた面もあって、
今回のゲインさんとの話の中でもこれを厳密に高いレベルでやろうとするとなかなか骨が折れるだろうなみたいな結論というか感想は投入しましたけど、
楽に言うとこれがサクサクできたら我々の伸びしろのはずじゃないですか、みたいな。
確かに。
こういうことができると使える武器が増える。
現代において誰も使ってないかもしれないウェポンが装備できるかもしれないので、結構アクシブキとして使えたら面白いかもしれないし、
本当にプログラミングとかモデリングってシェアの広さとか選択肢、手数の多さとか選択肢の種類の多さとか、そこで総合格闘技的に戦っていくものだと思うので、
21:12
きんじょうひでき
こんなに明確に説明されていて、投入されているアイディアがあって、ここに斬新だぞ、難しそうだぞって思っている以上は、やってみるといいんじゃないかなって個人的には思ったりしましたね。
やるとは言ってないですよ。やれるといいなって言ってたんですよ。
という感想です。
げんえい
やってプロポーザルのネタが一個できるみたいな感じはありますね。
きんじょうひでき
それで言うとマジでペチコンの2024のプロポーザルで、なんだ、構造化プログラミングじゃない手続き方やってみようみたいな仕事をしたんで、面白いんじゃないかなと思って。
げんえい
すでにあった。
きんじょうひでき
現代につながる歴史の中で絶対に通過して、我々はそこの上に立っているはずなのに、我々は知らなすぎるみたいな話って、掘り下げてみると発見ありそうだなっていうのを、
ここ3回ぐらいの著作読んでてちょっと感じた部分はあり、微量のケーブルに詳しくなるとかそういうのは一切ないんですけど。
それもあって、オブジェクト思考とか関数型とか、JQuery以前のJavaScriptユーザーなんでプロトタイプ思考みたいなのが増えましたけど、それ以前のパラダイム知らないなっていうのがあって。
それ以前の困った問題点、残ってる課題っていうのを知らないのに、オブジェクト思考がこんなにエレガントに何かを解決したって語っても全部嘘じゃんって気もするんですよね。
なので、GoToを使いこなせるようになりたいですね。
げんえい
そうなんですよね。やっぱり自分もその話ってちょっと似たことを思っていて、現代にあるものを理解する上でどうやると理解が早くできるかなと思った時に、過去との差分が何なのかみたいなところを知るっていうのが大事だなと思っていて。
なのでそうすると、結局歴史を掘っていくみたいなことっていうのは結構やるんですよね。知らない分野の本を読む時とかって、まずどういう対局の流れがあって、現代はこういうゲームになっていて、じゃあなんでそういう今起きてるのかをもうちょっと掘り下げていくみたいな。
アートの歴史とかで言うと、写真が出てきて印象派が出てきて、ただ単に絵を描くだけだったら写真を撮ればいいってことになっちゃったんで、もうちょっと表現の幅がいろいろ広がっていって。
現代においてはアートって言うと、現代アートっていうものがあって、よくわかんないものがあるけど、じゃあこの辺の連続性ってどういうふうなことが起きてるのかみたいな。そこを繋いでいくと、たぶん現代のよくわかんないなって思ってる現代アートがもっと理解できるんじゃないかなっていうふうに読んだりとかするので、今の話すごい共感するなって思いましたね。
24:17
きんじょうひでき
なんかね、それこそティーワダさんの技術選定の新聞版とかで、螺旋のイメージを持って今出てきた新しそうに見えるものを見つめられると、単純に前のやつの名前変えてパッケージ変えて売り出してるだけじゃないかっていう見方にもなりづらい差分を見つけようっていう建設的に見るようになると思うし、
逆にね、このアイディアとかこのコンセプトが引き継がれてこういう形で生き延びてるんだなっていうふうに感じたりとかなりますもんね。
げんえい
そうですね。まあでもね、歴史を知っても現代のルールがまず把握して、そこで叩かないと仕事にならないっていうのは、まあなかなかまた難しいところでもあるんですよ。
きんじょうひでき
そうですね。まあでもね、それこそこの前の大吉のGPMのLinuxコンテナの歴史を追うとコンテナの仕組みがわかるって発表とか。
げんえい
そうですね。カソカではなく隔離だよっていう話をされてましたからね。
きんじょうひでき
面白かったですよね。
げんえい
うん、あれめちゃくちゃ面白かった。好きなタイプの発表だと思いながら見てました。
ああ、いいっすよね。ああいうのやりたい。まあそうですね、この本に関してはそんなところですかね。
いや、トムネ丸子全部読み切りましたね。
きんじょうひでき
読み切りましたね。まあ僕は英語で一冊詰めましたけど。
げんえい
まあまあ、多分最初のルール設定は日本語で読める権限の全部だったはずなんで。
きんじょうひでき
日本語の範囲で。
これ、そうか、収録始める前に打ち合わせしとけばよかったなと思ったんですけど。
一つはね、次の方は決めてあって、これは次何読みますかっていうのを発表すると、組織パターンを読んでいきたいというか、
僕が周りの人にめちゃくちゃ周りの人、同じ会社でTechLeadとかEMやってた人とかに、
組織パターンこそ読むべきでしょ、ぐらいの圧を振りまいてたつもりなんですけど、
いよいよ誰一人として読まなかったので、源永さんが犠牲になった感じ。
げんえい
いやでも読みたいんだよねって言われて、なんかね、たまたま目の前に置いてあったんですよね。
これを予期してたかのように。これは運命だなと思って、じゃあ読みましょうって思いながら。
多分どっかでもね、いろんなところで紹介されてる本ではあると思うので。
きんじょうひでき
これはめちゃくちゃ最近ですよ、たった10年前の本なんで。
げんえい
そうなんですよ、今いつ発売かなと思って見たら2013年って書いちゃったから、日本語版運命を。
27:01
げんえい
いやもう最近で近いですね、だいぶ近代ですね。
きんじょうひでき
近いですね、でこれ著者がジム・コプリエンでマルチパラダイムデザインとか同じ人。
なのでデザインパターンとかのムーブメントって言うとあれかもしれないですけど、明確に組み込まれてるというか関わってる人だし。
ジェルサザーランドとかと一緒に、スクラムって本来フレームワークなんですけど、
スクラムをデザインパターンのパターンランゲージとして捉え直したらどうなるかなっていうのは、
スクラムはコミュニティの人たちがワークショップやって本にまとめてたアースクラムブックっていうのがあるんですけど、
スクラムブックはコプリエンが結構筆頭で代表的な2人ぐらいの位置づけでまとめてたりとかなので、
組織とかアジャイルとかパターンとか大好きな方のはずのジノコプリエンが組織における課題とか、
組織とプロジェクトをどう回すかみたいなのをパターンランゲージで語ってるんで、
なんでみんな読まないんですかねってマジで思ってるんですけど。
げんえい
そうですね、なんででしょうかね、そう言われるとめちゃくちゃ面白そうやみたいなことしかないけど、
思ったよりは取り上げられてない感じはありますよね。
きんじょうひでき
なんですかね、これこそ網羅性が高いと思うんですけどね。
げんえい
この翔永社のこの本のシリーズって結構表紙が似てるシリーズも、
このやつって結構プログラミング、それこそアーキテクチャーだったりとか、
プログラミングっぽい話が多いから、もしかしたらこの組織パターンっていうのがあんまり知られてないのかな。
紹介はされるけど、これは自分たちのフィールドじゃないと思われて読まれてないのかな。
とかちょっと思ったりはしますけど。
きんじょうひでき
埋もれてる名作なので、読むことでライバルに差をつけられるんで。
原初の日本語でもサブタイにアジャイルソフトウェアデベロップメントっていう風に書かれていて、
アジャイルっていう単語ついてるんですけど、これ多分前書きで、
アジャイルって付けた方が売れるって言われたから付けましたみたいなことはあるはずだから、
アジャイルの流行に乗ってアジャイルっぽいものを目指すためにやったっていうかは、
柔軟性が高い、機動性が高いとか、ちゃんと進化できる。
そもそもアジャイルソフトウェア開発省を使ってるとかそういう話じゃなくて、
ちゃんといい組織を作るための視点みたいな話に主題としてはなってるはずだし、
30:07
きんじょうひでき
それこそ目次見ると多分わかると思うんですけど、
コンウェイの法則とかにもパターンとして一個出てきたりとかぐらいの、
なんかそういう温度感の本なんで。
げんえい
いいですね。
きんじょうひでき
面白いはず。
げんえい
よし、じゃあ次はこれを読んで話しましょう。
きんじょうひでき
これちょっと分量があるんで、一回読み切るかどうかちょっと打ち合わせを。
げんえい
多分2回に分けましょう。
ちょっと多分めっちゃ話すことになるんじゃないかなっていう気がする。
きんじょうひでき
そうですね。
いくらでも、アドレナリンジャンキーの時に感じたと思うんですけど、
いくらでも喋れますね、パターンっていうのもんだと。
げんえい
そうですね。
きんじょうひでき
いかようにでも転がせるっていう。
げんえい
これ一個のパターンを一個ずつ切り刻んで配信すると、
1年間多分ネタが持つんじゃないかぐらいな気がします。
毎日ソスケパターン。
はい、じゃあ締めていきますか。
はい。
唐突ですが。
はい、ではいつも通り定型文を読んで締めようと思います。
きんじょうひでき
はい、お願いします。
げんえい
今週も放送をお聞きいただきありがとうございます。
ではまた次回、さよなら。
きんじょうひでき
さよなら。
