記述の難しさ
で、そう、それ、なんかそういうのがすごいこの本根っこにあって、でももう一つのインピーダンスミスマックというか難しさ。
なんか形が歪んじゃうような障壁みたいなところで、記述の難しさって話が。
なんかもう一個の柱っぽい感じがしますよね、この。
そうですね、そうですね。
記述関連、なんか個人的にこの考え方便利だなって思ったのが、スコープとスパン、範囲とスパン。
はいはい。
記述のスパンと記述の範囲か。
あります。
っていうのがあって、ここはなるほどなーっていう気がしましたね。
えーと、スパンっていうのはどこからどっちだっけな、えーと、どっちがどっちでしたっけ。
待ってね、呪文を今。
あー完全に理解したって思ったんだけどな、読んでるときは。
記述の範囲、でもこれ記述はって書いてある。
記述の範囲とはそれが何についてのものであるか、つまり記述される領域のうちどのような現象に関心があるかを定める。書いてありますね。
記述のスパンの方でいうと、記述のスパンとはそれが関わる世界の部分であるって書いてますね。どうですか、この説明。
むずいですね、なんか。
もう一つ。
例えばこの本のスパンの方でこの本が出している例で言うと、留守番電話の録音みたいなときに、それに関わる記述をしましょうって言ったときに、なんだろうな。
一人が使う1回の通話だとしたら、その通話に対して1回しか起きません、留守番の録音っていうのは。
みたいな風に捉えるか、なんか電話の管理者側からすると通話とかって何回も何回も起きるじゃないですか、いろんな人で。
考えるとその通話とか留守番の録音っていうのが唯一の存在じゃなくなるんですよね。
みたいなところかな、スパン。
ある世界においてある人から見たら1に見えるけど、とある人から見たらNになる。
やっぱりこの辺とかもあれですよね、前哨量化師と、2の1個以上のものがあると1つしかないみたいな。
いう風になって、これって術語論理のやつで見る量化師ってやつだなって思ったりとか。
いうことをちょっと連想しちゃったりしますけど。
スパンと範囲についてわかりやすくスクリプト作ってって今クロードに書かせてるんで。
違うんだよな、マークファイルダウン、マークダウンファイルとして作成しますねって言われた。
オープニングから書き始めたらそういうことじゃないんだよな。
でも、ある適応領域あって、その中のものをどういう範囲で書きますか、表現しますかっていうことは絶対考えないといけない話ではあるので。
だいぶ結構曖昧になりがちですもんね。
そうですね。結局じゃあこれってどこまでが対象なんですかって話って、なんか本当によくするなっていうシステム作ってても。
全員ですとかって言われて、全員?全員とは?みたいな。
もうちょっとこう本当に条件ないですかって言ったら、じゃあ大会した人はどうなんですか、大会した人は除きますねとかって言われて。
それそうですよねーみたいな気持ちになったりとかして、このビッグユーザーテーブルの中には大会者フラグがあってたなーみたいな気持ちになると、全員って言った時ってどこまでどこを指すんでしたっけとか、
同一メールで複数アカウント作れる場合は、じゃあこれ全員って言ってるけど、本当はメールアドレスでユニークだよねとか、いろいろ考えないといけないよなーとかっていうのはやっぱありますよね。
記述の中心性
なんかね、このスパンとかスコープっていう話がたくさん出てくるけど、それもいいか、これ以上あんまり膨らまない気がするな。
そうですね、でももうちょっと広く記述ってことについて喋るというか考えると、そうですね、てかこの本の中ではちょっと面白いのが記述っていうものがソフトウェア開発の中心であるってすごい強い言い切りをしてるんですよね。
あれなんかワインバーグはソフトウェア開発は記述であるみたいなこと言ってるよって言い終わりましたよね。
ワインバーグが出てくるよっていうところをちゃんとハイライトしておいたから、ハイライトから辿ればいける。
ここじゃなかったっけな。
ここって言ってないと記述っていう章があるんですよね。
でも後ろの方で出てきたから、この角じゃなかった気がするな。
だから絶対本筋じゃないところで話を終わってしまった。
批判的に読むことってワインバーグが出てきた。
そうなんか、ワインバーグとかデマルコとか我々がよく読んでた人たちが出てきますよね。
ワインバーグ、デマルコ、ダイクストのあたりがたくさん出てきたなという印象。
そうですね。
ヨードも出てきたか。
ヨードも出てきたね。読んでないけどフォンノイマンとかも出てきて、オールスターズ集合みたいな気持ちになりながら読んでましたね。
アリストテレスとかも出てきた気がする。
そうですね。術語論理とかの話が出てくると、論理学三段論法なんてアリストテレスの時代からありますからみたいな話ですからね。
話戻ると、記述の技法っていうところで、このマイケル・ジャクソンは記述こそがソフトウェア開発の中心であるっていうふうに言っていて、
これを聞いて思ったのが、強い言い切りだけど、結構自分もそう思ってて、
どうやってその世界を捉えて、どうやってそれを言語化するかっていうか、言葉に落とし込むとか、
どういうふうに物を見て、どういうふうに記述するかってことって、これできたらもう勝ちなんだよなみたいな。
ここに曖昧さを減らしながら、いろんなことを考えて、自分にはこういうふうに世界が見えて、こういうふうに物が動いてほしいとか、
顧客の課題はこうだから、こういうふうに仕様に落とし込むみたいな部分を言えたら勝ちで、
ここがうまく言えないと曖昧だったり、ハッピーパスというか一番やりたいケースっていうのは多分うまくいくんだけど、
じゃあそのエッジケースだったりとか、こういう時どうなりますかみたいなことをうまく表せないと、
そういうことがいっぱい出てきて、しまいにはそれに対してバータリ的にこういう時にはこうしよう、こういう時にはこうしよう、こういう時にはこうしようっていう例外をいっぱい作っちゃって、
ソフトウェアがどんどん複雑化していくみたいなふうになると自分は思っていて、
そこの技術のセンスというかトレーニングというか、その人が世の中の物の見方みたいなものをどれだけうまく見ているかによって、
ソフトウェアっていうものがうまく作れるかどうかっていうのは結構決まるなっていうふうに思ったりもしていて、
この著者がすごい言い切ってるし、自分も結構賛同できるなっていうので、すごいこの本いいなって思ったのはありましたね。
おだしょー すごいな、技術に関して考えることは思考について考えることであるとか、いいですよね。
記述と依存関係
技術とは思考を人間の外側で目に見える形にするための媒体であるって、媒体ってことはメッセージってことですかね、じゃあ。
おだしょー そうですね。マクルー・ハン的に言えばってことですよね。
でもこれってもうちょい我々のソフトウェア開発の中に近づけてしゃべると、結局ある処理を書こうと思ったときに、
言ったらその順次実行と条件分岐と繰り返しで全部書けるわけですよね、全てが。
究極的には。で、じゃあコントローラーにリクエストが飛んできて、コントローラーが動いて、
if、else、if、else、何でもいいですけど、slow、exception、何でもいいですけど、そこに処理を書いていくときに、
人によってきっと物の見え方が違って、上から順に処理が本当に流れていくんだ。
で、条件分岐、ifで条件分岐していって、その場合分けを考えていけばいいんだっていうふうな物の見方もあるし、
いやいやその振る舞いってものは外から注入できるようにして、その場合分けの部分は別の部分で管理しましょうみたいな、
いうことを考えて拡張性を高く持ちましょうとか、結局どうやってある要求を満たしたいものを仕様に落とし込んで、
その仕様を実装に落とし込んでいくかっていったときに、どうやってプログラムを書くかっていうのは、
まさにその人がどういうふうに物を見ていて、どういうふうに記述しようとしているかっていうことであるなって自分は結構思っていて、
そこがどんなふうに見えるかによってソフトウェアの複雑性とか拡張性だったりとか、保守性みたいなものだったりとかパフォーマンスだったりとか、
っていうものに全部関わってくるようなと思っていて、ある意味ではここっていうのはソフトウェア開発の中心であるって言い切ってるのは、
穴がち間違ってないかなっていうのはちょっと思ったりはしますね。
そうですね、そこでさっきのスコープとかが来てくるのか、今私が語ってるこれは、これについてとかこの範囲について示しているものですっていう定義というか前提が来ると、
難しいですもんね。
そうですね。
この場合はこういうこともあり得ますよねっていう可能性が爆発したとやっぱり難しいので。
そうですね、そうですね。この配列には任意の値が入りますって言われた瞬間に多分爆発するじゃないですか。
ストリングかもしれないし配列かもしれない。CDクラスかもしれない。任意のものを取りますって言われるとなんかすごく良さそうに感じるけど、
そんなこと全部考慮してられないよっていう風にやっぱりなっちゃうし。
どんだけ防御的に書けばいいんやってなりますからね。
そうそうそうそう。で、戻り値はミックスドって書いて。任意のものが戻ります。なんか君はフレームワークを作ろうとしているのかなみたいな。
なんかあると怖いからルートのエクセプションをキャッチしますみたいなね。
スローアブルをキャッチした結果全てがここで消えていきます。やっぱフレームワークを作ろうとしているみたいな。
いう気持ちになっていくので。ソフトウェアってやっぱりどうしても記述せざるを得ないっていう部分があるので、やっぱりここってのは一番大事だよねっていうのは、
なんかこの95年当時と今現代においても実は変わらないよなっていう風に結構思ったりしましたね。
たぶん変わらないんでしょうね、ずっと。あれはそこのパラダイム変わることあるのかな。
漁師コンピューターとかはそもそも状態をいろいろ持とうってなって、全然変わってきたりするんですかね。わかんないけど。
全然イメージができないから、たぶん我々は今イメージできないからそれについて語ることがすごく難しいけど。
でもたぶんなんか処理のフローみたいなものがあるときに、そのフローの制御構造を反転させたいみたいなこととかっていうのは、つまり反転させることによって振る舞いを変えられるんだとか、
いうような、物の見方を正面から見るんじゃなくて横から見たり裏から見たり下から見たりみたいなアイディアみたいなものっていうのは、いつの時代においても絶対出てくるものだと思うんで。
そう考えると、じゃあどこにどういう風に依存しましょうかとか、ここは別にそんなこと考えずに具体に依存していいんだよとか、
やっぱりここは中小に依存すべきで、そこから先のことはここでは知らない方がいいんだよとかいう話っていうのは、たぶんどこでも出てくるよねみたいな。
結局安定しているものに依存したいよねっていう話っていうのは、たぶん絶対ずっとついて回る。
ソフトウェア要求の曖昧さ
今のAIの話でも、AIに全部ファイルを直させればいいんだってなるんだけども、そのAIってものは不安定なので、ちゃんと決定論的に動いた方がいいよね。
じゃあ正規表現を書かせて、その正規表現を実行するのは人間がやるんだけども、書かせるのはやっぱりAIにやらせた方が楽だからいいよねとか、
レクターのルールを考えてもらうとか、そういう風に使った方が安定するよねみたいな発想は今でもAIが出てきてもやってるので、変わんないんじゃないかなっていう気がします。
そうですね、我々だと偏見があるので、人間は。だから勝手にこういうことがしたいんだよねっていう範囲を、スコープを絞りがちですけど、
やっぱりLAレームってそこらへんがちゃんと調査をしない限りはすごいフラットなんで、それによっておいおいおいみたいな、それはどこの世界の可能性を持ってきたんやお前みたいなやりがちっていうのは、
なんかここらへんはすごい、この本に通ずるというか、曖昧可能性を、生身の人間だったらほとんど無意識的にしょぶり込んでる可能性っていうのを、彼らは非常に豊かにフラットに持ってきてしまうので、
可能性が広がった結果、当然比例的な曖昧さもずっと持ち込んでしまうから、そりゃ出力安定せんよなみたいな。
そうですね。だからやっぱり記述のスパンだったりとか、範囲だったりとか、スコープだったりとかっていうのは、とてもとても大事ですね、やっぱり。
なんかね、それこそライトついてますか、で聞くだけでオッケーっていうのはやっぱりスコープがパンなのかな、スコープなのかな、がちゃんと絞り込まれてるからっていうのはありますもんね。
そうですね。だからトンネルを抜けるタイミングで、ちゃんと車が運転できる人がパッと見てわかるものって考えた時に、スパンもスコープもちゃんと絞り込んでるから、あの一言でやっぱりいいわけですもんね。
曖昧さっていう章もありますね。で、「あ」から始まるから一番最初に出てくるんですけど、これ結構好きだったんだよな。なんかここで紹介されてる例え話、何もでした、刺さらなかった。
何もメモしてなかったなって今、今自分のメモを見ておりました。
曖昧さ、流行のエスカレーターの足元に見かけた次の2つの注意書きが気に入っている、というふうに書かれてて、1つ目の注意書きが靴を履いてください、で2つ目が犬を抱いてくださいなんですけど、
これじゃあ犬を抱いてくださいっていうのは、小犬というかちっちゃい犬を連れてる人はエスカレーター乗る時危ないから抱き上げてエスカレーター乗ってくださいねっていうことを言ってるわけですけど、
確かに靴を履いてくださいと犬を抱いてくださいって並べるとすごいおかしいんですよね。じゃあ犬探してこないとこのエスカレーター乗っちゃダメですかみたいな。
靴を履いてくださいは、お前が例えば裸足で靴持ってなかろうとも、ちゃんとシューズを着用せいなんですよね。犬はもしあなたが犬を今連れているんであれば、そうした方がいいよ的な、かなり条件がつくみたいな。
あとこの中で犬に靴を履かせるべきなのかみたいな人があって、確かにね、靴を履いてくださいっていうのは人間がって書いてないから、犬を抱いてる犬が靴を履いてくださいなのか。
犬を抱いてくださいが、本当になんか、何ですかね、世の中から争いをなくそう、ペットに愛用みたいな話だったら、いい話ですもんね。
さっきそういえば靴買ったんだよね。俺靴手に持ってるけど、これさらにもう一足履かないといけないのみたいな。手に持ってる靴は全部履いてくださいってことなのかなみたいな。でも足は2本しかないしなみたいな。
この辺は常識ってものがあれば、ある程度わかるはずなんだけども、どこまでこれを間に受けていいのかとか、どれだけ、これソフトウェア開発の中にあったら、靴を履いてくださいじゃないですけどね、
ここではこうしてください、ここではこうしてくださいって書いてあるのが、じゃあそうじゃないときはどうなるんですか。これは&条件ですか、or条件ですかとか、っていうようなことっていうのは多分めちゃくちゃみんな聞くはずなんですよね。
予知を記述しようとした時に意外とこういう曖昧さっていうのが紛れ込んできがちっていう話ですかね。
記述方法の重要性
そうですね。多分記述の仕方で混乱する。例えばA&BorCっていうのは、A&Bの欠陥に対してorCなのか、A&BorCのことなのかっていうのは多分記述の曖昧化みたいなところもあるだろうし、
ここの中ではあれでしたね、直接法っていうやつと願望法っていうのがあって、片方は絶対にこうしてくださいっていう話と、こうした方がいいよっていうさっきの、犬を連れてるんだったら抱えた方が安全でいいよっていうような話と両方あったりして、どっちとも取れてしまうから困るんだよっていうような話がされてましたね。
高校の授業でやった気するのは直接法願望とですね。
ってことはやっぱり日本語とか言語ってものの曖昧さっていうものがあるので、全部数式で形式ロランディで全部書いてしまったほうがいいってなりそうだけど、そんなことしたら耐えられないんで多分、読み解けないんで辛いよねっていう感じでもなります。
なんかこの靴を履いてくださいの抱いてくださいの形式的にちゃんと表したらどうなるのかっていうのも書いてますもんね。
書いてますね。
エスカレーター上にあり得る個体Xそれぞれに対してXに履かれている靴Yが少なくとも一足存在するっていうのと、エスカレーターの上でありかつ犬であるような個体Xがある場合それらはみんな抱かれているって書いてもまだ完璧じゃないよねっていう風に話は続くんですけど。
そう。
面白い。
面白いですよね。
さっき自分がソフトウェア開発の技術ってものが中心であるって話に対してすごいわかるって思う一方で、でもそれってどこまで行ってもその完璧な技術ってものはないので、どこかで妥協しないといけないし、どこまでやればいいのかっていうものっていうのもそんばそんばで結構判断しないといけないし、
どこまで書けば伝わるかみたいな部分とか、どこまでやっとけば常識的な範囲で人が判断できるだろうかっていうものがついてもあるので、なんていうか完璧な技術みたいなものはないし、このままいくと完璧な絶望もないって言いたくなるんですけど、なぜか。
完璧な技術ってものはなくて、だからこそ難しさでもあるっていう感じであるんですよね。
うん。でもこのね、直接法願望法っていうのをある程度寄り分けてというか明確に区別して意識的にやろうぜっていうのは何か、行動閣議でも聞きそうですよね。
そうですね。
直接法は完了状態というか、事前条件事後条件みたいになるんですかね、技術すると。要するにあさとするものみたいな。
そうですね、そうです。そうなりそうな気がする。
願望は振る舞いになりますもんね多分。お前がやるんやでみたいな。
こう考えると論理学とか明大論理とか術語論理とか勉強したほうがいいのかなって気持ちになってきます。
あと単純にやっぱ国語の勉強したほうがいいよねってなりますね。
めっちゃ思っためっちゃ思った。論理学ずっと苦手意識があるんですけど、こういう本読むとやっぱりやったほうが自分が楽になるなっていう気はしてて。
なんかちゃんと勉強したりトレーニングしたことがないから苦手なだけかもなっていう気もするんです。
しました、この本を読んで。
っていうのがあれですね、最近すげえ社会人になってから習い事をしたっていう人の本が出たせいで、あれやればできることって意外と世の中たくさんあるのかっていう気持ちがあり。
論理学、論理思考とか具体と抽象トレーニングみたいな本は多分、札10冊ぐらい家に転がってると思うんですけど、論理学何があるのかな、チャート式の数学Aとかしかない気がするな。数一A。
取り寄せたんで、実家から取り寄せたんであるんですよ。
確かに中にもありますよね、命題の話があったりとか、裏とか大愚とか、これが真であるとは偽であるとはどういうことかみたいな話とか、マドモルガンの法則だったりとか。
結構我々、やっぱりプログラミングって論理回路だったり、アンドワーとかXワーとかいろいろありますけど、ああいうものの上に成り立ってるから意外と生きてくるんですよね。
何回勉強してもね、最初の手前のところは何回も何回も勉強するので多少覚えるんですけど、そこから先に健全性、完全性とかちょっと難しくなった瞬間に毎回忘れてもう無理って思って、論理学が毎回ちょっと進んだところで諦めてます。
誰かそういう登壇してくれないかな。
まあデータベースとかも集合論が元になったりするんで、集合論っていうものを勉強する中にはやっぱり論理学が必要だったりするんで、術語論理もSKN実践入門だったかな、じゃないな、データベース入門の奥野さんのやつとかにも一生の方とかに確か術語論理が載っていて、
術語論理これっていうのはデータベースの元になってるから知っておく必要があるんだよって話があって、まあとりあえず壊す、飛ばすかみたいな気持ちになりながらSKNの書き方を勉強した記憶がありますね。
そうだよなー。
難しいなー。でもできそうなところからやっていかないと問題がちっちゃくならないですからね。
そうなんですよね。問題のスコープを小さくしたいのに。
ただ構造化分析手法の話で分割統治とか出てきたから、あんまり本気で取り合ってないというか、まあまあ確かそういうのもあるよねぐらいの感じのトーンで、この本だと取り扱われてた気がしないではない。
そうですね。あとは何かその辺で関連するとトップダウン、ボトムアップみたいな話もありましたね。トップダウンの章ですごい面白いなと思ったのが、最大の決定は全問題の分割であるという話が出ていて、そこから続いて、これは規模が最も大きく、その結果が追い越す影響も最大である。
しかしこの決定はまだ何も分かっておらず、全てこれから発見されなければならないという最初に下さらなければならないのである。もしこの決定を間違えると、後に続く仕事のほとんどが、もしかすると全部が謝りとなって無意味となったりする。
さらに悪いことにもしこの決定が謝りだった場合、再開レベルに達するかコーディングを行うまでそのことに気がつかないというふうな話があって、要はトップダウンって問題をいかに分割するかって話であるんだよっていうふうなことがあって、
ただしその問題の分割の仕方っていうのは手探りな状態で最初にいきなりやらないといけなくて、すごく間違いやすいし間違うととても大変なことになるんだよってあって、なんかすごいわかるなーって気持ちになりながら、問題を分割せよってことはわかってるわけじゃないですかみんな。
その複雑な問題っていうのは問題を分割して簡単にして、それらの組み合わせによって対処するんだっていうことはいくらでもわかってるんだけども、最初からどういうふうに分割したらいいかわかってないってことが一番難しいんだよねっていうふうになって、それなっていう気持ちになりながら、結局この本だと結局最初に作ったものは一回捨ててもう一回やりなさいっていうふうになるんだよっていうようなことが書いてあって、
そうですよねーみたいな気持ちになって、だからこそ早く失敗してフィードバックサイクルを回してうまくやっていくんだっていうことが大事なんだよねっていうふうに思ったりもしましたね。
トップダウンアプローチ
なんか1個目は早く捨てようぜっていうのはあれでしたね、ブレックスの引用として書いてましたね。 そうそうそう。どうせ2回作ることになるんだっていう話が民月の終盤に出てくるって書いてありました。
あれだよな、この章一番インパクトが残ったのはやっぱり最後の文ですね。要するにトップダウンを行おうとしている人への私の忠告はパンチ師が結婚しようとしている人にする忠告と同じである、やめときなさいで終わる。
ではトップダウンどうなんですかね、トップダウン、ボトムアップとかそういうやり方を紹介してるではないですもんね。
レニカル方法としてはボトムアップがある。これも階層構造を仮定するが最下位レベルの部品群から順に組み上げていくことにより作られる。最下位レベルのはどこから手をつけるんだっていうのが見えないと思ったんだよな。
私、ボトムから積み上げた結果、四角の上に三角のっけてその上に丸のっけるみたいなことをやったら終わりじゃないですか。なのでボトムアップ的に作るっていうのも割と危ないんじゃないって思ってて。
多分今って結局そうじゃなくて一気通貫でメインのハッピーパスをまず作ってみなさいよっていう、とりあえず一通り動くものっていう方向でいくのがいいんじゃないっていうのが現代っぽいのかなーっていう気はしますけどね。
そうですね。分割されないと実装できない。テスト駆動開発のインサイダーアートとアウトサイドAみたいなやつはあるなって考えると、ボトムからコードを書くこともあるかとか思ったりはしたんですけど。
だからそれって設計と実装を一緒にやってるからできることなんだよなみたいな。書いてみてちょっとわかったって設計的な概念にフィードバックして、じゃあ次ここ必要かっていうふうにわかるからそこに実装の歩みを進めていく。
っていう行ったり来たりをすると一歩ずつ、ボトムから始めて一歩ずつ進めるなと思ったんですけど、どうなんですかね。この人たちが言ってる世界観で言うと設計と実装って別のフェーズな気がするし、そんなにフィードバックゼロとは言わないですけど、そんなに簡単に行ったり来たりする前提ではない気はするので、ここでいうボトムアップってなんだろうなーって気がします。
そうですね。
さっきトップダウンのところを声に出して読みながら、やっぱり思ったのはウォーターフォールっぽいなって思ったんですよね。すごく頭、最初にいろんなものをすべて決めきっていって、何とか画面と何とか画面と何とか画面が必要だよねってブレイクダウンしていって、じゃああとこれを実装すればいいよねっていうところまで落とし込んでいって、じゃあ今度実装してそれをテストしてみたいな。
フェーズがあって、もちろんそうではないのかもしれないけど、やっぱり読みながらそういうことをイメージしてしまうなと思ってて、そう考えるとやっぱり今のソフトウェア開発とはちょっと全然違う世界観だよなーっていうのは思ったり、もちろんウォーターフォールでやってるところもあると思うんですけども、
なんかそれよりも早く失敗してフィードバック得てみたいな方がいいよねとか、そのコアの部分から作っていきましょうねみたいな、優先度ってものがあるよねっていうことを考えたりするよなーっていうふうにちょっと思ったりしました。
なんかそうですね、いやあれだな、トップダウンもボトムアップも難しいから両方やるんだな。
両方からいってこうすれ違いましょうみたいな。
いや、そうですね、トップダウンっていうのが、もしくはボトムアップでもいいんですけど、こっちでやった方がいいし、これを使った方が正解なんだっていうのは、銀の弾丸を追い求めるようなものだなって思ったんで今。
使えるものを全部バランスよく何でも使うんだろうなって。
そうやって不確実さを下げていって、プロジェクトを安定起動させるみたいなふうにいくだろうし。
トップダウンって言っても、それこそゲインさんが今言った、今風だととりあえずハッピーパスエンドツーエンドで通して的なやつで言うと、一番下まで詳細まで作り込みすぎないリアルみたいな話じゃないですか。
ここのエッジケースどうしますかとか、こういう異常系どうしますかっていうところまで、要するに一番下のボトムまで折り切らないで上からスタートして途中で引き返してみたいな。
ここから先はハリボテですって一旦済ませてみたいな感じですもんね。
いや、まさにまさに。
だから、両方やってんだろうなっていう。
そうですね、そうですね。経験的にいいと思ったものを取り入れて頑張ってやるみたいな、そういう感じですね。
