-
-
スピーカー 1
そうですね。
スピーカー 2
システムの数え方の話は結構あれだな、個人的には面白いなーって思ってて。
例え話として、動物の群れの中から羊が何匹か数えるためには、まず羊って何ですかっていうのを知っていて、かつ羊とそれ以外目開けられるようになっとかないといけないよねー的な話があり。
じゃあその、今目の前で簡単にシステムシステムって言ってるけど、今目の前にしているであろうシステムとは何ですかっていうのを知らないと、分解分析、また再構築とか、これから作っていくとかっていうのができないよねーっていうようなことも言ってる気がして、あーなるほど面白いなーとか思ったりとか。
で、あとどこからどこまでがそのシステムなんですかって考えた時に、これはなんだろうな、例えば新しいプログラムを作りますって言ったとしても、そのプログラムをインストールするのが今まで使ってたサーバーとかだったら、
プログラムを含めてハードウェアとかも含めて全体のシステムの中で言うと、そのプログラムを古いものから新しいものに入れ替えただけなので、何ていうか部分的に入れ替えるってそれは新規開発じゃなくて保守だよねーとかっていうような話が出てきたりして。
で、これの話をめちゃくちゃ膨らませて広げていて、48ページ見ると、一番下にいる一番分解していって最後に残る要素として、ハードウェアっていうところから始まってるんですけど、ハードウェアがあってそれを取り囲むプログラマーがあって、それを取り囲むジョブ制御群があって、それを取り囲むテストレーターがあって、既存ファイルがあって、公式的解説文書があってっていう風になっていって、
最終的に一番外、世界になってるんですよね。これはなんかちょっと、じゃあこれを聞いてどう生かすかっていうのはすごい、まだピンときてない部分もあるんですけど、なんだろうな、この広い宇宙から見たら俺のやってることなんて些細なことだ的なことが、
なるほど、システムって簡単に一言で言っても同じことは言えるなー的な気はしましたね。
スピーカー 1
そうですね、システムの話をするときに、その対象を観察してる自分はどこにいるのかみたいなことを考えることは結構あるんですけど、自分は。
つまりサーバーってものを観察しようと思ったときに、サーバーの外に自分はいて、そのサーバーってものに対してどんな風に動いてるんだろうかみたいな、ブラックボックスとして扱ってみるみたいなことを自分はよく考えたりするんですけど、
多分それが入れ込みの回想的な感じなのかなーみたいなのをちょっと思ったりとかしてて、一方でサーバーの中に入って実際いろんなものを動いてるプロセスはなんだろうとか、何でもいいですけど、じゃあどっかにファイルがあってそのファイルを開いてとかいうことをやり始めたときに、
じゃあ自分は一体サーバーの一部なのか、サーバーの外にいるわけではなく内側にいて、じゃあうちと外の境界ってどこなんだろうとか、みたいなことを考えたりとかして、ちょっとそういうことを連想させるような面白さがあるなっていうのが、システムの観察って結構難しいよなって、
ちょっと次は観察だった気がするんで、観察にその後つながっていくんですけど、結局このやつ確かシステム論でシステムの外からシステムの対象を観察するみたいな話があったんだけども、その後外側とか内側とかないからみたいなような話がオートポイエーシスってやつにあったりとかして、
学生の頃にめちゃくちゃ読んで、マジでわからんって思った記憶がすごいあって、苦い思いがあります。
スピーカー 2
あとね、例えばソフトウェアプロダクト作ってますって言った時に、結構人間のドームっていうシステムの中の1モジュールジャン的な視点を持てるかなとかは、現代でも普通にありますもんね。
スピーカー 1
そうですね、そうですね。しかも一個のシステムでもう完結するってなくて、結局いろんなものとつながってますからね、今は。
スピーカー 2
そうですね、めちゃくちゃ綺麗にPDF出せるようになりますって言ったとしても、それ印刷して入れる箱がなかったら結局提出できませんとかっていう話もあるかもしれないし。
そうだからイベントストーミングとかやるとそっち側に着目したりしますよね。
スピーカー 1
確かに確かに。
スピーカー 2
めちゃくちゃにわからんであんまり深くは話せることないですけど。
スピーカー 1
でもイメージとして、例えばシステムを作りましょうって言う時には、コンピューターにおけるシステムはどうせインプットがあって処理があってアウトプットがあるじゃんっていう、すごく単純に言うとそうなるんだけど、
でも結局業務フローを理解しないとものが作れないとか、じゃあ業務フローを書き起こしましょうって言うとイベントストーミング的なものがあったりとか、一昔前になっちゃうかもしれないけど、例えばユースケースをちゃんと洗い出してそのユースケースに基づいてシステムを作っていきましょうとか。
スピーカー 2
大丈夫ですよ、今86年なんで。一昔前じゃないと思いますよ。
スピーカー 1
でも結局実は、昨今AIが流行りだして、流行りだしてっていうかAIにものを作ってもらいやすくなった時に、そういう抽象度のものの方が本当は大切だったんじゃねっていう気はしてきますね、そして。
結局インプットとアウトプットだけを見ながらその設計をやって、できたものが結局コードとコードに付随するコメント、あと面接されてないドキュメントみたいになっちゃった状態だと、結局何やりたかったのかよくわかんないよねっていうものが残り、本当に必要だったものは口頭で喋られて後方もなく消えてったみたいな状態が多分起きちゃってたりはすると思うので、
その辺とかを考えるとやっぱどういう視点でものを見るか、そしてどういう視点で見たものを残しておくべきなのかっていうのは難しいなってちょっと思ったりしますね。
スピーカー 2
そうですね、ちょうどこの本でも暗黙的な理解とか知識、暗黙理って話が出てきて、結構それ外側にいるんですよね。
スピーカー 1
そうですね、そうですね。
スピーカー 2
明文化された公式であろうと非公式的であろうと、そういうドキュメントはもっと内側にいて、これでも面白いな。
公式ドキュメントがあってその外、さっきのシステムっていろんなものが入れ込んだっていう図を見てるんですけど、公式ドキュメントが内側にあって非公式ドキュメントがその外側にあって、
その外側にブレインウェアってあるんですけど、たぶん頭の中にあるものって感じですよね。
だと思いますね。
明治的に理解してるものかな。
スピーカー 1
あー、確かに確かに。
スピーカー 2
で、その外側に説得的訓練があるから、カリキュラムとかが組まれてるトレーニング。
で、その外側にやっぱ暗黙の訓練っていうのが出てきますね。
暗黙のものはすごいですね。
スピーカー 1
いやでも、システムを作るのにこんな風に捉える人はなかなかいないよなっていうのは、このズンニを覚えながら。
スピーカー 2
そうですね。
面白いなっていう。
全然関係ないんですけど、あれらしいです。今調べたら、ユースケースの資格化モデリング技法が、
UMLとかラソナルプロセスの文脈でそのユースケースの資格化モデリング技法っていうのが出てくるわけですけど、それが86年らしいですね。
スピーカー 1
ちょうど。
スピーカー 2
今さっきです。
スピーカー 1
じゃあまさに、一曲システムを高速化だけすればシステムが出来上がるかって言ったらそうではなくてみたいなことがやっぱり、
本当にそれのカウンターとしてあったかどうかは分からないけども、流れとしてはそういう風に取れそうな感じで出てきているっていうのはあるんですね。
スピーカー 2
そうですね。
UMLとか自体は結構アジャイル手前ぐらいのやつなんで新しいと思うんですけど、それの前身となるユースケースの資格化したいよねっていうのはちょうどこの時期に。
スピーカー 1
やっぱり歴史を辿ると面白いですね。
スピーカー 2
面白いですね。
でもまあ第2部、なんかげんえさん的に好きだったエッセイとか。
まあエッセイ全体じゃなくても。
イラストとか具はでもいいし。
スピーカー 1
55ページのところが、55ページって言ったけど、これはたやまの石のエッセイの中で、
グーテンベルクの発明によって聖書が印刷、いっぱい活版印刷の発明があって、いろんな読めるようになりましたよっていう話があって、
でなんかその聖書の中にいろんなフォントが出てきたりとか、いたい文字っていうのがあったりとかして、
なんかよくわからないけどこうなっているみたいなものがいっぱい出てきたんだよねみたいな話があって、
でまあなんでそれがそんなよくわからんことをしてるのかなみたいなことをたどっていったら、
その本の右端にきれいに揃うようにするためにいたい文字みたいなものが誕生したんだよみたいなのがあって、
なんか別にあんまり意味がなかったというか、それ自体にはきれいにすることだけだったんだよみたいな話が出てきて、
これってあれじゃんみたいな、ボルティングの逆行原理ってやつになんかあったよなって、
なんか今こうなってるのはなんでなんだっけって言ったら、それはそうなる理由があったみたいな、いう話じゃんと思って読んでましたね。
スピーカー 2
リボードの配列とかもね、そうですもんね。
スピーカー 1
そうですね。
スピーカー 2
タイプライターが壊れにくくなるようにって、あれは本当の話なんですか?
スピーカー 1
いやなんか諸説あるっていうのを。
スピーカー 2
あれ諸説あるらしいですけどね。
スピーカー 1
クオーティの配列は壊れないようにっていうのは諸説ありっていう感じだけど、
まあでも聞いたらまあでも、なるほどそういう理由でそうなってんだねっていうのは、
なんか別に意味もなくランダムに並べたわけじゃないんだねっていうようなこととか、
スピーカー 2
偽とイラストがついてますね。
スピーカー 1
おだしょー そうですね。
スピーカー 2
イラストがマジで今までで最…いやでもソフトウェア文化を作るシリーズの方がインパクトあったか。
スピーカー 1
おだしょー うん、あっちの方が謎だったな。
スピーカー 2
で、第3部がさっきちらっと触れてた観察ってやつですね。
スピーカー 1
おだしょー そうですね、そうですね。
スピーカー 2
うん、観察はお好きですかって聞こうと思ったらそんなにゲインさんの目もないな。
スピーカー 1
おだしょー そうですね、読んでて観察難しいのはそうだよねって思いながら、難しいなって思ったんで観察の練習っていう本を昔買って読んだことあるなっていうことをちょっと思い出して、
これはどちらかというとデザインスケッチとかデザインの文脈で、物事をどういうふうに見るかみたいな。
普段見過ごしてるものをどうやって再発見するかみたいなっていうふうなことをやってる本で、なぜかこれを読んでる時期に社内に同じ本を読んでる人がいて、
なんでっていう気持ちになりながら、別につい最近出た本じゃないんで、たまたま観察って難しいねっていうことを同時期に思った人が社内にいたっていうだけなんですけど。
スピーカー 2
おだしょー それでそっちの観察いきます?
スピーカー 1
おだしょー わかんないです。
でもそういうところと、やっぱり過去読んできた話が出てきたよねっていうところがあって、そうだよねって、この話やっぱ好きなんだなワインバーグっていうふうに思ったりとかしてましたね。
スピーカー 2
ワインバーグが好きな話で言うと、白パンの自然史と列車ダイヤの逆利っていう全く知った話が出てきてましたね。これでも後に書くってことか、あれ違うか。
何に出てきたんでしたっけ。プログラミングの心理学か。じゃあコンサルタントの秘密。
スピーカー 1
おだしょー 列車ダイヤはコンサルタントに出てきた気がしますね。
おだしょー 白パンを見せすスミス。どっちだっけな。コンサルタントかな。
スピーカー 2
おだしょー コンサルタントの気するような。
おだしょー まあでもだとすると、これの後に書かれた本でもう一回逸話として使ってるって感じ。
おだしょー そうですね。
おだしょー 素敵なパンを焼くスミス夫人っていう人がいて、近所で評判になって、もっともっと売っていこうってなって興量化して、なんかよくわからない、あれ別にたいしておいしくなくねっていうパンを売るようになり、
今やスミス人は別に自分のパン、自分の名前を冠した企業が製造してるパンも別に食ってないと。
なんですけど、なんかその製造が大規模化するにつれて、例えばロジスティックス的な、運びやすいようにとか、日が持つようにとか、
そういう理由があって、ただおいしいだけでは十分じゃなくなるっていう理由があったから、今やおいしくないっていう物事が現在そうあるのはそうなったからだ。
っていうのを考えましょうぜっていうのが白パンの話ですね。
これでも同じ章であれですね、理解のために検討し批判のために検討するなとか、元のシステムの良い点を探せとか、素敵なことが書いてますね。
スピーカー 1
観察するって言うと、当たり前のことは見過ごされてしまいとか、そこは難しいですよね。
どうしても悪いとこに目が行ってしまったりすると、結局批判のために使われてしまったりとか。
スピーカー 2
あと、これ別に自分だったらこういうふうにはしないな、直せそうだなってなると、問題解決したいっていう予定に突き動かされちゃって。
本当は理由があってそうなってるし、非常に必然性が積み上がって今の姿になってる物のはずなのに、ただただイケてないだけっていう風な見方になって、
俺ならもっと上手くやれるぜっていう反応が引き出されちゃうとかはあると思うので、より良い直し方ができるなら直した方がいいなと思うんですけど。
ただ利用すると、確かにそうじゃないとまずいねっていうのもあったりするかもしれないんで。
スピーカー 1
そうですね。話の中で最初の方に観察術を学ぶためにビデオテープを利用するといいよみたいな。ビデオテープもうないかもしれないけど。
要は自分のことを客観視させるみたいな意味でこういう話が出てて。
多分今っていくらでもミーティングは録画できるしとか、スマホで撮影することもできるかもしれないけど。
多分客観視するとここ直せそうだなとかってパッと気付いたりすると思うんですけど、実際そこの当事者になった時とかにはまた上手くいくかどうかはまた別だよねとか。
外から見てたらそうだよね。でも内側に入るとそうなってしまう。例えばファシリテーションがうまくできなかったなって振り返って自分で見てうまくいかなかったなとかって思うけど、
いざその場にまた入った時には話の流れとかいろんな関係上そうなってしまうみたいなことはあるから。
もうちょい広い範囲でもちろん考えてシステム思考みたいなことで考えて、そういうことに陥らないようにどうしたらいいかとか、いろいろ予防するっていうのも一個の手だろうし。
スピーカー 1
問題がわかったからといってパッとすぐ解決できるわけではやっぱないよなっていうのを思ったりしますね。
スピーカー 2
なんかね、頭でわかってても実行が難しいっていう話もあるし、そもそも頭でわかることすら難しいって話もあるし、
だからうまく観察して何かに気づけるかって、それよりさらに手前の話だよなって気がしますよね。
さっき言ってた知らないことは数えることができないみたいな話にも近いけどね。
最近読んでるあれに出てきたな。
げんえいさんも同じ本買ってた。スポーツコーチングの話。
意外とKindleで買ったから気づかなかったけど結構ページ数がある。
スピーカー 1
分厚いやつですね。
スピーカー 2
最高のスポーツコーチング学って言って。
なんだっけな、正確な引用っていうより、例えばこんな話があったみたいになっちゃうんですけど、
球技、サッカーとかやってて、ディフェンスがうまい選手って何を見てますかっていうと、
あんまり相手の体の一部にすごい集中して見てるっていうよりか全体をぼんやりして見てて、
そこの中で重心の動きとか肩とか目線とか、
下手したら指先の動きとかそういうのに勘付いて先回りできるとかコースを下げる的な話があるけど、
あんまり経験が深くない人がうまく相手のこと守ってやろうってなったら多分、
せいぜい目線と足ぐらいしか見えないじゃないですか。
肩とか重心とかっていうのってそもそも見るもんなんだっていうのを知らないんじゃないかなとかっていう気もするし、
であとはそこら辺も知ってたからってうまく、
胴体視力的な意味とか脳みその処理速度的な意味プラス瞬発力っていうのもかみ合わさってくるんで、
やっぱり一流のプレイヤーは一流のプレイヤーなんだなってなるんですけど、
でも観察がそもそもできるできないの話はね、あるよなーっていう。
スピーカー 1
そうですね。
いやーそうなんだよ。
なんか今サッカー話出たからあれだけど、やっぱりサッカーの試合同じものを見てると思えないような観察の仕方をしてる人とかいたりするので。
スピーカー 2
いやーなんか解説つきで見るのやっぱり面白いですよね。
スピーカー 1
そうそうそう。
いやーその友達とスタジアムで見てるとやっぱりボールを、なんかこれが良い悪いとかっていう話はないですけど、
だからボールを中心に見る人と全体感を見ながら見る人と、
あとこのマッチアップが楽しいんだみたいな、フォワードとディフェンダーのバチバチのやり合いが楽しいんだとか。
スピーカー 2
あとベンチめっちゃ見てる人いますよね。
スピーカー 1
それは言い忘れます。
とか、全然こうやっぱ観察ってただ見てるっていうのはやっぱり見てるんだけども、
いろんなところのいろんな部分をこうみんな見てるんだなっていうのはあるので。
って考えると、まあやっぱりミーティングをしてる中でだったりとか、システム作りしてる中でとか、
なんかあそこ気にするんだとか、あそこを見るってことをそもそも思ってなかったとか、
見てたのに見逃してたみたいなことって大量にあるので、
やっぱなんか完璧な観察みたいなものはもちろんないと思うんですけど、
でもできるだけいろんな見方ができる方が楽しかったりとか、
システム作る上では見落としが減って、ある種もしかしたら不具合が早く見つけられたりとか、
予防できたりとか、何かしら問題があっても普及できるとか、
まあとかとかとか、いろいろあると思うんで、
なんかいろいろできた方がいいんだろうなと思いながら、
でもそれってどうやって見つけるんだっけみたいなことを考えると、
まあなかなか難しいですねっていう。
そうですね。
スピーカー 2
この章のタイトルが観察はどうしてで学べるかですからね。
スピーカー 1
そうそうそう。