Small is Beautifulと一つのことをうまくやらせる
てなことで、第2章ですね。人類にとっての小さな一歩。 第2章でいうと、取り上げられている定理、今言った9つのうちの2つか、Small is Beautifulと一つのプログラムには一つのことをうまくやらせるが、第2章に出てきてるやつですね。
そうですね。Small is Beautifulの例として出てるのが、ファイルAをファイルBにコピーするというプログラムを考えると、じゃあSmall is Beautifulってどういうことなのっていうような例が出てますね。
で、コピーするときに結構、人間っていろいろ考えてるんだなみたいなことを思うような手順みたいなものが、アルゴリズム手順みたいなのがあって、コピーするときって何やってるんだっけっていうと、ユーザーにコピーする元のファイル名を尋ねて、ファイルがあるかどうかちゃんとチェックして、ファイルがなければそれをユーザーに通知する。
ユーザーにコピー先のファイル名を尋ねて、またファイルがあるかどうかチェックして、それがあるんだったら上書きしていいかどうか尋ねて、元のファイルを開いて、元のファイルが空だったらそれをユーザーに通知し、プログラムを終了しましょうと。
で、空じゃなかったらちゃんとコピー先のファイルを開いて、データを元のファイルからコピー先のファイルにコピーして、元のファイルを閉じてコピー先のファイルを閉じるっていう12のステップで書かれてるんですけど、結構いろいろあるんだなっていうことを思いますね、こう見ると。
で、手順10のみが実際にコピー作業をしていることに注意して欲しいと。
そうそうそうそう。だからUNIXのSmall is Beautifulの考え方でいくと、この10番目、データをコピー元のファイルからコピー先のファイルにコピーする。これだけをやればいいんだよっていうふうなことを言ってますね。
じゃあ他のものってどうするのみたいなファイルがあるかどうかっていうのは、ここではテストコマンドっていうのがあるからそっちを使って、そのテストコマンドとコピーっていうものを組み合わせて使いましょうねっていうような話をしていますね。
これだから知らない人にはできないですよね。あらかじめ事前条件としてテストっていうのをちゃんとやっておきましょうみたいな。
ただ知ってると、コピーをする際にファイルの存在とか安全性とかをチェックするっていう機能がこのcpコマンドの中に含まれていたとしたら、cp君の言ってるファイルの安全性とか存在チェックっていうのはどういうことなんだいっていうのを知らなきゃいけなくなっちゃうので。
そういう意味ではね、一個一個のちょっとこれの次の話と混じっちゃうかもしれないですけど、一つ一つちっちゃいものが組み合わさって動くっていうのは確かに便利なんだろうなみたいな。
そうですね。その次のやつも一緒にここで紹介してしゃべっちゃった方が楽かもしれないなとちょっと今思ったんで、もう一個の定理も紹介して、もう一個の定理は一つのプログラムには一つのことをうまくやらせるってやつですね。
なのでさっきのコピーするってこととちゃんと条件、事前条件として存在するかとか、存在するんだったら上書きしていいかとかそういうような話っていうのを全部一つのものに入れるんじゃなくて、バラバラにして一つのことをうまくやるようにしましょうねっていうような話が出てますねここで。
でもこれも今Unixの考え方という文脈で出てるけども、普段プログラム書くときとかも似たようなことすげえあるなみたいな、このバリデーションってこっちでもやってあっちでもやってってやると大変だからこっちでやっておいて、先言ってバリデーション済みのものとして渡していいんだっけみたいなこととかを結構考えたりするなっていうのはありますね。
コンポーザーにおけるUNIX的設計
そうですね。あとあれだな、我々PHPユーザー的にコンポーザーの中がまさにそうなってるなという発見があって非常に面白いんだぜっていう話をしようと思うと、これ20分トークいけるなって思ったからどっかプロポーザー出そう。
いや、コンポーザーのリクワイヤーってあるじゃないですか。パッケージを見つけてきて、コンポーザー.jsonに追記してコンポーザー.logを更新して、ダウンロードして配置するみたいな。
コンポーザー.logの更新って、本当はそれコンポーザーアップデートっていうコマンドで実行されるものだし、解決されたパッケージとバージョンをダウンロードして配置してくるっていうのはコンポーザーインストールっていうコマンドなんですよ。
コンポーザーリクワイヤーっていうのは、それとプラス新しいパッケージを見つけるっていう機能を追加した上で、パッケージを見つけますでアップデートしてインストールします。中のクラスとしてはそういう機能の表彰になっていて、非常にそこらへんはよくできたというか、というのを思い出しながら聞いてましたね。
そうですね。本当、仕事で書くコードでそういうのよくあるなと思いながら、こういろんなものを組み合わせられてやれるとうまくいくんだけどなと思いながら、あれなんかこっちにもあっちにも同じ処理書いてあんなって言って、これを結合すると最後爆発するみたいなことがあったりとか、微妙にこっちとあっちで実は違ったりとかっていうのもあるし。
シンプルとイージーみたいな話でもあると思うので、シンプルなものを組み合わせてイージーなものを作るっていうのが、保守性だったりとか再利用性みたいなことを考えたときに結構大事になってくるよねっていうのはありますね。
シャローモジュールとディープモジュール
そうするとやっぱりシャローモジュール、ディープモジュールみたいな話が出てきて、ちゃけりゃいいっていうのが中直の哲学なんだっけっていうと、ユーザーインターフェースというか、全体オーケストレーションするような層っていうのは必要だよねとかっていうふうにもいくかもしれないし。
そうなんだよな、なんかその薄いものをどんどん作ってた結果、一つのプログラムには一つのことをうまくやらせるって書いてあるけど、その一つのことに足りてないんじゃないみたいなことが起きたりとか。
だから一つのことってじゃあどこまでを指すのみたいなのこそがある意味ではもしかしたらより大事な設計の部分かもしれないしとか。
そうですね。
っていうのが出てきたりするんで、細かく刻めばいいんだよっていう話でもないというか、別に最初は細かく刻めていいと思うんですけど、どれぐらいのサイズにしたらいいんだっけみたいなことはまた刻んでいった先でまた考えないといけないよねっていうのがあったりしますね。
でもそうですよね、細かいユーティリティというかプログラムがあって、ユースケースとか目的に応じてそれらを組み合わせる。
もしくは組み合わせたスクリプトを書いておくとかっていうふうになるとね、さっき言ったテストコマンドっていうのが一個あれば、なんかCPと組み合わせていろんなものでも使えるし、CP以外のところでも多分かなり活躍するしみたいな。
で、そのファイルが存在しますかどうですかっていうのは、それもテストコマンドで保証されるというか定義されてるんです。
こいつのコマンドがその責任を負ってますみたいなのは楽しいですよね。
いやー、ずっとこれでいろいろ喋れそうだなっていう。
このほう危ないと思うんですよマジで。本当に危ないと思う。
言ってることはシンプルだけど、そこの深淵を覗きに行こうとするとずっと引きずり込まれて帰ってこれなくなりそうな気配が。
LSコマンドの表示形式と組み合わせ
あと読んでて、ここの中で一つのプログラムには一つのことをうまくやらせるって話の中で、ここではLSコマンドの例が出て、
そうね、LSね。
LSってやると一覧になって出てくるんだけど、あるバージョンからはそれが縦に並ぶんじゃなくて、なんていうんですかねこれ。
横を絡む表示というかね、テーブル表示というか。
そうそうになっていて、これが4列表示がいいのか2列表示がいいかって、モニターのサイズによるんじゃないとか、ターミナルの幅によるんじゃないみたいなことがあったりとかして、
そうか、LSで一つ出すだけで、なんていうか、うまくやるっていうのは、この表示っていう部分に関してもそうなのかとかって、
いろいろどこまでが一つのことなんだろうなっていうのは、いろいろ考えちゃうなっていうのはあるなって思いましたね。
そうですよね、あるよな。
LSコマンドで言うと、ソムさんがやってるOSS for Funっていうポッドキャストで、めちゃくちゃLSコマンド突っ込んで話してる回があったんで、あれがクソ面白いんで。
いいですね、いいですね。
なんて言ってたっけな、あっちで言ってるのは、ファイルごとに一乗一エントリーっていう形式で表示されてるから、
乗数を数えればファイル数がわかるとかっていう、WCコマンドと組み合わせで使いやすかったりとか、
他の組み合わせやすいものはやっぱりちっちゃいものだよねっていう話とかは、その話聞いててすごい思ったりとかして。
人間がターミナル上で見やすいんだったら、いい感じレイアウト配置みたいなコマンドに渡してあげればいいだけだし、
LSが本当にやるべき仕事なのかっていうのは、いろんな考え方があるよねみたいな。
コマンドの組み合わせと負担
そうですね、その時にいろんなコマンドと組み合わせてあれこれやるのを覚えないといけないっていう負担はやっぱりかかるので、
LSの場合はそうかもしれないけど、ちょっと今いい例がない、思い浮かばないですけど、
例えばブリューインフォとかブリューのインストールしたものをバーっと一覧で出されても長すぎて読めんなみたいなこと、
グリップすればいいだろうみたいな気持ちもあるけども、一覧でパッと見たいときに、
ファミナルがずっとスクロールされて辛いよねみたいなことがあったときに、
これ何のコマンドを叩かないといけないんだっけってなると、それでしんどさはきっとある場合もあるんだろうなと思って、
なかなか時と場合によるみたいな感じはあったりするんですけど、難しいですね。
個人的には縦に並んでくれた方がその後エクサウスとかパイプして渡すときにイメージしやすいからいいなって思うんですけどね。
そうなんですよね、知っておくとそうなるんですよね。
結局LS-Lってやるじゃんとか、毎回打つのだるいからLLにってエディアスをつけるじゃんみたいなこととか、あれあれだと思うんですけど。
LLとかLってこの本でも触れられてたんだなっていうのを今回読んで発見したエディアスを張るみたいなやつね。
みんなやること一緒っていうか、こういうのをやってそれがだいだい受け継がれてみんなこうやっとくと便利だぞっていうので、
SSHしたサーバーにLLって打ったら、ここにはあるじゃんみたいなことになってたりとかしてるんだなっていうのをちょっと思ったりしましたね。
優しいソフトウェア工学の原則
あとあれだな、この章でいうと、今スモール・イズ・ビューティフルと一つのことをうまくやるような話したんですけど、
その間ですね、2章の第2節に優しいソフトウェア工学っていうところがあって、
そこで語られてるのは、小さなプログラムは分かりやすいとか、小さなプログラムは保守しやすいとか、
小さなプログラムはシステムリソースに優しいとかって書かれてて、
あとは今言ってたような小さなプログラムは他のツールと組み合わせやすいっていうのも出てきて、
分かりやすいとか保守しやすいってめっちゃ大事ですよね。
この本読むと全体的にそれは当たり前やろうみたいなことしか言ってないような気がするんだけど、
でも結構当時の使えるメモリとかCPUのサイズだったりとかっていうところからも、
分かりやすさだったりリソースに優しさっていうのは大事だったりするっていうのも一個あるんだろうけど、
現代においてプログラムがどんどんデカくなっていく中で余計なこといっぱいやってないみたいなことを言われると、
確かにそうかもとか思ったりとかして、保守しやすくリソースに優しいプログラムを書くぞって思うと、
やっぱできるだけSmall is Beautifulって考え方を持っておかないとよくないなっていうのは思ったりしましたね、読んでて。
AIとスキルの設計
何ですかね、使いやすいっていうのがやりたかったことをちゃんとやってくれる、そのための手間が少ないっていう話もある一方で、
期待してないこと、余計なことをやらないみたいなのもあると思うので、そこらへんがね、これやったら当然ここもやるでしょうって思ってたのに、
ユーザーに何て余計なことしてくれるんですかみたいな場面がね、この何て余計なことしてくれるんですかっていうのは僕が毎日クロードに行ってるやつなんですけど、
分析してって言っただけで、なんでコミットまでやってんのよみたいなのとかね、よくあるんで。
でもなんか最近そのAIのハンドリングはまさに、AIのスキルと設計とかを見てると結構やっぱ人によって、
イージーなものを作る人とシンプルなものを組み合わせて、そのシンプルなもののワークフローを書いて、スキルとしてはそのワークフローを実行するみたいな、
シンプルなスキルを組み合わせて、イージーなワークフローにしてあげるみたいなのを、結構人によって設計質を分かれるなみたいなのを思ったりとかすることもあって、
だからそれは結局あとはAIがどれぐらいそのスキルをちょっとずつ使いたい場面があるかとか、いうことまで想定してるなと思ったりとかして、
やっぱこうハンドリングが100%効かないものに対して、やっていいことやっちゃダメなこととかをどうやって伝えるかなって思うと、
なんかその辺のスキルの設計だったりとかも必要なのかなーってちょっと思ったりとかしたことがありましたね。
全体的なところで結構大きめのゴールを与えて上手く自律的にやらせるんだとは思うんですけど、それを支えるためのハーネスだったりスキルだったりっていうのは、
なんかやっぱりちっちゃくかつ明確に、要するに確定性が高まるように一個一個は作っていくんだろうなっていう気もしていて、
それってやっぱりスモール・イズ・ビューティフルが効いてくるんだろうなーっていう感じとかちょっと思ったりしますね。
そうですね。分析してっていうのが、仮に分析スキルみたいなのがあったらそこにはコミットまではやらんやろってなるよなーって気がするけど、
まあええやろな、勝手にコミットしてプッシュするからなー、禁止してなければ。さっきコミットしてプッシュしましたよね、じゃあ今回も気を利かせてやってきましたってなるからな、割と。
第3章: できるだけ早く試作を作成する
そうなんですよね、そうなんですよね。まあでも、第3章いきますか。
いきますか。第3章が、楽しみと実績を兼ねた早めの試作っていうタイトルで、ここも定理がいくつか紹介されていて、2つかな。
1つですね。
1つか。
ここは1つです。
で、できるだけ早く試作を作成するっていうので、早く作って早く失敗しましょうっていうような感じがあるなっていうのをちょっと自分は思ったりしましたね。
これあれなんですよね、関連性が強いとか似たような目的、分野の定理を同じ章にまとめていて、さっきの第2章だったらSmall is Beautifulと1つのことをうまくやらせるっていうのはすごい関連性がある。
思想互換関係にあるし、だけでと第3章のできるだけ早く試作を作成するのは割と他の定理とはちょっと経路が異なるようなやつですね。
ここはプロトタイピング的なやつで使ってみたらいろいろ見つかるから早くやっちゃおうぜっていうのが、ざっくり言うとそんな感じだと思うんですけど、面白いなって思ったのがやっぱりあれですね、3つのシステムっていうのが出てきて。
初期バージョン、第2バージョン、第3バージョンみたいな意味で人間による3つのシステムって言ってるんですけど、1つ目が一番かっこいいやつですね。
それを見た人を沸き立たせる斬新なもの、すごい新しい価値を感じさせるようなものみたいなこと言ってて、第2のシステムはそれを見た、それを目をつけた、一丁噛みさせろみたいな人が集まってくるようなフェーズで作られた、
第2のシステムはあまりにも多くの機能がある、すごいたるんだ脂肪まみれのシステムみたいなこと言ってて、脂肪じゃない税肉がつき遅いって書いてありますね。
第3のシステムは、第1のシステムの素晴らしさと第2のシステムの失敗っていう両方から学んで、やっとちゃんとしたものができるみたいな、オリジナルのコンセプトはそのまま残り常識となるとか、
第2のシステムから大きく名前が変わるとか書いてあるんですけど、そんな感じで、一発目でうまくいかないよねとか、振り子?螺旋のように別のベクトルの失敗をした上で、3回目でやっとうまくいくっていうような感じの話ですね。
ソフトウェア開発の成長サイクル
今もそれは変わってないなっていうことしか感じないから、すごいわかるなって思うし、こうやってある種ソフトウェアを成長させていくということでもあるんだろうなっていうのが、我々は歴史から学べることなのかもしれないなっていうのをちょっと思ったりしましたね。
これ新卒で入った会社で、社長っていうか本当にめちゃくちゃちっちゃい会社だったんで、社長と2人3宅とか3人チームみたいな感じのぐらいの規模だったんですけど、プログラマーサイドは。
その時新卒というかインターンの時代から3回ぐらいやらないとやっぱりうまくいかないからみたいなことがすごい言われてて、後からこの本で言ってたのは話。
この本であの時言われてたようなことはこの本に書かれてた、この話だったんだなっていうのに気づいた時におおってなったんですけど。
で、そうですね。さらにその後に気づいたのが、僕が内定社時代から入社直後ぐらいに書かれてたソフトはバージョン3って言われてたなって思ってて、最初から失敗できなくねっていう気がちょっとしたりしたんですけど。
確かにな。
重要な仕事を任せてもらってたなって。その前にねちょっとライトワンみたいなの作ってたんで別に。月桂本番では全然ないんですけど。
まあでもバージョン3ってのはだいたい3の倍数で不吉なことが起きるみたいな話が、パイソン3とかルビー3とかなんかいろいろなんか昔聞いたことあるなと思いながらPHPの6の話とか聞いたりしたから。
なんか3つ目で成功するかは本当かみたいな。
そうですね。PARもMySQLもPHPも6はちょっと辛そうな。
そうですね。
でもマイクロソフトは比較的3番目がうまくいくみたいな。Windows3.2とかいう気がしますね。
いいですね。なんかこう、なんかのサイクルがあるんでしょうね。
きっと。
ではそのサイクルがこれなんじゃないですか。人間による第三のシステム。
なんかそんな気がしますよね。
試作のサイクルと迅速な到達
でもやっぱなんか自分も社内で雑談してる時に、どうやったら上手に作れるかみたいな話になって、3回作ることだよみたいなまさに同じ話が社内でもあって。
3回作ると大体要求も固まってるし、何が不要で何が必要なのかもだんだんわかってきていて。
しかも一回やったことあることだから、なんかそのソリューションもなんか思いつかないっていう部分もないから、大体3回くらいやるとうまくできるよみたいな話があって。
本当にこのこの法則当てはまってるなーって思ったりしましたね。
そうですよね。なんか左端と右端を決めて真ん中に行くみたいななんかそういう揺り戻しというか、調整がなんか3回目でやっとできるみたいな気がしますよね。
まあみんな掲示板を3回作ればウェブシステムは上手く作れる可能性が高そうって思ってます。
掲示板とかオレオレフレームワークは何回作ったかわかんないけど。
ビジネスで成功するかはまだ別ですからね。
あとこれ第二のシステムはあれですよね、ブルックスの人月の神話の本に出てきたセカンドシステム昇降軍の話はこれですよね。
そうですね。
昨日あれもこれもやりたくなるみたいな。
大体あれもこれもやりたくなって、てかあれもこれもつけて欲しいって言われて作ってパフォーマンスはどんどん落ちていき、後で痛い目を見るっていうのは本当ありますからね。
いろいろ盛り込んだ昨日の何割が喜ばれてるんですか?みたいなね。
そうですね。
でもそれを乗り越えるとスタートアップが大きく跳ねて成功するみたいな、そういうこともあるんだろうなって気がするし。
でもけぐ3回ぐらい作ることを想定して早く失敗して早く次のものをもう一回作れるとか、作りやすくしておくとか、そういうようなことがとてもとても大事そうだし。
もうちょっと引いた目で見るとあれかもですね、スタートアップの界隈とかで過去2回上場したことがあると痛みはこの辺にあるみたいなのがわかってるから、3度目の会社ではスムーズにいくとかそういうのがありそうだなってちょっと思ったりもしましたね。
プロトタイピングの手段と捨てる勇気
うん。
思い出していろいろ思い出した結果、ここで言うべきじゃねえなっていうことが浮かんだので、ちょっと注目してしまったんですが。
あとあれですね、3回作らないとうまくいくのが難しいよっていう中で、じゃあどうしたら早く成功したい、無駄となってしまうような時間を過ごしたくないっていう中で、どうしたら早くそこにたどり着けますかって話も書いてあって、それを探してるんですけど。
素早く3回目に到達することが大事だみたいなことが書いてあったはずなんだよな。
今ちょっと探してるんですが。
あったあった43ページですね。
ではどのようにすれば第3のシステムを作れるだろうか。
最初に他の2つのシステムを作るのだ。それ以外の方法はない。
って書いてあって、その後にちょっと飛んで、しかし近道がないわけではない。それは第1のシステムから第3のシステムへとできるだけ早く進むことだって書いてあります。
構築のサイクルを短くできれば、それだけ第3のシステムへの到達が早まると言えるって書いてあるんで、ゆっくり第1のシステムを作って、ゆっくり第2のシステムを作ってとかってやってると、到達が遅くなるから、
もうとっととプロスタイピングして、これでどう、これでどう、みたいなのを当てていき、こうじゃない、ああじゃないと言われながら、どんどんどんどん第3のシステムに近づいていきましょうねっていうようなことですよね。
それで第3の定理である、できるだけ早く試作を作成するっていうところにつながってくるんですよね。
そうですね。今のウェブアプリケーションみたいな規模感みたいなものとかを考えるとちょっと難しいかもしれないけど、
でも例えばデータベースからファイルをフィルターしてこういうものが見たいですって言ったときに、
まあ試作するって別にリッチな画面を作るってことじゃなくて、スケール書くとだいたいこんなデータが出てきてこんな表になるんですよねっていうのを、
もしかしたらExcelで見せるでもいいかもしれないし、スプレッドシートで見せるとかもあるかもしれないし、
時と場合によってはログファイルからこれを抽出したいんだよねって言ったときにこれで合ってますかみたいなので、
グレップとオークとセドとかで作るとかでも、もしかしたらいいのかなっていう気もしたりとかして、
あんまりリッチないろんな、じゃあまずAWSのこういうこれを使ってあれを組んでみたいなことをしなくたって試作は作れそうだから、
そういうものを組み合わせて上手に作っていくっていうのが結構早くやるコツなのかなって思ったりとかもしましたね。
なんか試作をすることの目的が、やっぱりユーザーに見てもらうとか、できれば実際に動かして触ってもらうとか、
それでフィードバックをもらうっていうところが一番やっぱりやりたいことだなって思うと、
何が何でも動かすんやっていうための手段をやっぱり引き出しに、道具箱にたくさん入ってた方が良いですよね。
経験値とベテランの勘どころ
そうですね、いやほんとそうなんだよな、どんだけアプリケーションコードを書かずに試作できるか、
ほんと大事なんだよなと思いながら、最近もずっとスプレッドシートで画面イメージこんな感じ、表を出したいからっていうのもあるんですけど、
表のイメージこれでやってますってひたすらスプレッドシートでやり取りしてますからね。
大丈夫ですか、神XLみたいになっていかないんですか。
神XLが欲しいかどうかをまず聞くみたいなところからですね、やって神XLになりそうになったらここは分割していいやつですかとか聞くとかね、
そうやってフィードバックを集めるみたいなことをやったりしてますね。
それ聞いて思いましたけど、できるだけ早く試作を作成するっていうのは、できるだけ早く捨てるみたいなところも含まれてそうだなって今ちょっと思いましたね。
そうですね、捨てられないとちょっと辛いですからね。
捨てられない恐怖感があるとやっぱりしっかり作らなきゃってなって、
頭でっかちというかウォーターフォール的な設計をしっかりやりましょうみたいな世界になっていくと思うので、
設計とか仕様を上手く作り上げるところに割いてる時間をもっともっと動くソフトウェアっていうところに割り振ってるっていうのがユニックス開発者の伝統的なやり方なんだっていうのも書かれてますしね。
それが結局その後も変わらず、ドキュメントよりも動くものを見せるっていうのが大事だよって話ってずっと続けているっていうのがまた面白いというか、
プロトタイプで作って動くものを見せて、ちゃんと書き直す時間は確保するからって言われて、
これ重要ありそうだからって言って、このままリースしちゃうねって言って、いつ書き直す時間はみたいな、ビジネス忙しいから次はこの機能を作ってくださいみたいなのが、
そして世の中には張り通ってたりするんで、ちゃんと捨てられるように書こうねとかっていうのは大事なんだよなって思ったりしましたね。
そうですよね、だから本当にいくら時間がなくなってもちゃんと捨てられるとか、ごそっと入れ替えられるための仕組み作っておくっていうのは経験値によるところというか、
それこそがベテランの勘どころ、見極め力みたいな気はしますよね。
そうですね、この文言に全部バーンと入れたデータ、どうやってマイアスケールに移行するんだみたいなこととかね、いっぱいシアターのスキマレスは便利だからとやってみたりとか、いろんな経験をした人がいると思うんで。
たぶんこういうバッジがあれば、このぐらいならモンゴーとかドチュメントDBでもいけるだろうなみたいなの、やっぱりベテランはなんとなく頭の片隅に置きながら、
シートベルトよしって言ってからアクセルベタ踏みするみたいなことをやったりするわけですよね、たぶん。
ただまあね、シートベルトをつけててもやっぱりちょっと飛び込む先が悪いと、ちょっとうわーってなっちゃうんで、そういうこともあると。
そうですね、必ず失敗しないっていうことはないんでね、そういった場合によっては失敗してしまう場合もあるんで。
いやー、ほんと変わってないんだな、色。
そうですね。
第4章か。
ちょっとこれはどう変わったっけ。
