コミュニケーションの重要性
11章、正確に聞くなんですけど、これも本当にワインバーグの話っぽくないけど、今までの話とつなげて続きとして見ていくと、めちゃくちゃ納得感のある章ではありつつ。
お、すごい好きだなと思ってますね、正確に聞く。
最近好きですよね、げんえさん、ここら辺。
因果関係の話が出てきたりとか、不適切な一般化みたいな話があって、よくあれですよね、子供が言う、クラスのみんなが持ってるって言って、誰が持ってるのって聞くと、2人ぐらいしか名前がわからないみたいな、みんなとか、みたいなところの量化子の話、数量子の話があったりとかが出てきたりとかして、
なので、みんなが今こういうのは当たり前だからさ、みたいな語り口とか、そういうようなことっていうのは、発言する時にも気をつけないといけないし、相手が、別に大げさに言おうとしてるわけじゃないと思うんだけども、つまり、みんなって言ってるのは、すごく自分が欲しいっていうことを強調するためにだったりとか、大事だみたいなことを言うために一般化しているみたいなこともあったりとかするんで、
みんなって誰?って問い詰めていくと、それはそれでちゃんとした方が聞けなくなるので、この辺とかはすごく気をつけながらコミュニケーションと、自分が発言する時も気をつけないといけないし、相手が言うことをそのままに受けるっていうこともしないようにしないと、適切に聞くっていうことが、正確に聞くっていうのが結構難しいんだろうなっていうことを思ったりしましたね。
なんかね、悪気はないけど観察対象範囲が偏ってるとか、あり得ますもんね。
そうそう。
さっき言うと2人しか持ってないって言ってるけど、でも僕2人しか友達いないもんって言うと、あーみんなだねってなるから、これでもあれですね、11の1から2あたりはなんていうか、SNSで炎上発言を避けるためのいくつかの指針みたいな感じもあるな。
そうですね。過剰な一般化っていうのは本当に危ないですから。
そうですね。
あとクソリプがつく傾向もありますからね。すべてこうですっていうと、いやこういう範例がありますっていうのがいっぱい、そういうことを伝えたいと思ってすべてって言ってるわけじゃないじゃんみたいな、言うのがあったりとかして、難しいねって。
この中で言うと僕あれですね、省略に注意するとか、弁詞化っていう話は結構やりがちというか、やらない、SNS炎上発言、ああみたいなこと言った後にやりがちっていうのはすげえ嫌なんですけど、陥りがちな気はしていて、名詞化、なんか名前がついちゃうとそこにあるかのような感じがするってよくあるじゃないですか、人の心理として。
これを悪用すると、相手のバイアスにうまく引っ掛けるというか、思考の誘導につなげやすくなるはずなんですよね。だから大層な、横文字嫌いとか横文字でカッコつけてるとかっていうアレルギー反応的なことを示す人も、主語例会かな、過剰な一般化かな。
権威じゃないですけど、やっぱり名前をつける、名詞化するってちょっと偉そうになる威圧感を与える気はするので。で、この名詞化しました、もう概念が確立されました、はいもう通じますよねってなると多分コミュニケーションがある程度、よく言えば効率化されてるショートカットされてるなんですけど、
悪く言うと、取るべきコミュニケーション、伝えるべき情報っていうのが、省略されてる、カットされてしまってるという側面もあると思うので、この省略に注意する名詞化とかっていうのは、ああなるほどなーって思ったり、他の省略もね、いろいろ並んでるんですけど、特にこの名詞化って、ちょっとやっぱりやりがちだなーって思って、なるほどって思ってました。
心理的安全性は大事ですって言った時に、どの心理的安全性のどの部分が大事ですかって聞いたら、相手は何も答えてくれない可能性が、なんかありそうだなーみたいなことをちょっと思ったりしましたね。
まあそうですね、スクラムやりましょうとか、フォーキーズ追いましょうとかっていうのもあるし、それに近いっちゃ近いのかって。
最初はそこの前提が揃ってる状態でいろいろ始まってたのが、一般化されていくにつれて、みんながあれが大事って言ってるから、そうだよね大事だよねって言いつつ、結局なんで心理的安全性が大事なんですかって聞いたら、いやなんか一般的にそう言われてるのでとか、
その心理的安全性のこのある部分だけを抜き出して、誰も批判しちゃいけないっていうところがいいと思うんですよねみたいなとか、けど本当はそこじゃないよねみたいな、いうのが起きがちですね。
確かになんか価値の押し付けみたいな、これは良いとされてます、これは必要、大事なものですって押し付けにも繋がるのか。
ちょうど例題がソフトウェア工学、例で出てるのはソフトウェア工学は時間の浪費だっていう話があって、ソフトウェア工学の中にいろんなものがあるはずなんだけど、どの部分が時間の浪費ですかみたいな聞き方をすると、真に大事な部分がわかるではないだろうかっていう、省略されてる部分っていうのは何なのかっていう話をしていて、
それっていうのは結局、ソフトウェア工学っていうのは内緒は大事じゃないみたいなって言ったときに、ある種価値の押し付けみたいなとこ、浪費だってこの例ではなってるけど、とても大事だって言ったら価値の押し付けっぽい感じには確かになっちゃうかもしれないです。
ハウだけよこさないでくださいの話にも、ちょっと近い気がしますね。それはどう受け取ればいいんだ、どういうふうに私の中でそれを生きづけすればいいんだっていう判断するための情報がやっぱり欠落してるっていう感じかな。アップルパイについて賛成ですか、どうなんだっていう気がするけど。
ちょっとアップルパイのことは忘れましょう。
あと名詞とか動詞が省略されてないかっていうのに気をつけましょうとかね。
日本語って結構省略されがちじゃないですか。主語省略するし。
英語でも実際そういろいろ他の言語と比べてってことはできないけども、割といろんなものを省略しながらハイコンテキストなコミュニケーションしがちっていうのは言われるので、そう思うとよりちょっと気をつけないといけないんだなっていうのを感じますね。
そうですね。かといって名詞とか諸々を一切省略しないで喋るべきかっていうと、普段のコンテキストとか慣習から外れたことをするっていうことはつまり何かいつもと比較して違うことが起きてるのかなっていう観察をまた招いたりするので、そういうそれが必ずしも正解じゃない気もするし、なんか難しい、コミュニケーション難しいってなりますね。
そうですね。しかもコミュニケーション難しいんだって言って、正確さに気をつけて自分がいくら喋っても相手がそういう正確さみたいなものに関してそんなに強い関心を持ってないと、結局すごい丁寧に言ってもなんでこの人は言ったんだろうというだけで終わってしまうみたいなオチもありますからね。
そうですね。気づかないで反応が先は知ってしまったら余計にそこでこじれて一発アウトとかなりがちだし。すごいな。品質の話でそこまでいくのかワインバーク。
そうですね。この正確に聞くっていうのが入ってると面白いですね。
面白いですね。すごい面白いなって思います。
次に進みます?
いきますか。
次はメタ計測ですね。
なんでプラトン引用してるんだ。
まあいいや。
ここは計測してることが正しく計測されてることをどうやって計測するかっていう話になっていくってことですね。
何ですかね。例えば開発生産性が気になりますって言って、みんながコードを書いてる時間とか、どのプロジェクトにどのくらい時間を費やしてるのかっていうのを報告させて計測しましたって言ったときに、
その上がってきたデータを見ていろいろ判断して改善回していくのはいいんですけど、そもそもその計測、どのプロジェクトにどのくらい時間を抑えたのかっていうのをちゃんと記録する文化がありましたっけとか、
そっちのデータを生み出す元になってる何かっていうのが健全に機能してるかいっていうところも大事だよね、なメタですね。
そうですね。あってますあってます。あってると信じてます私はそれを。
物を紛失するっていうのがね、計測を妨げるって書いてますね。
ここの章はどうでした?
いやもうなんかまあ大事だよねってぐらいしかちょっと思わず軽く流しちゃったんですけど、何ですかね。
なんかでもやっぱその計測してることがちゃんと正常であるっていうことを計測できてないっていうか正常に動いて働いてるってことを認識できないと、
なんか結局なんかゴミのデータを集めてわかんないねとか間違った結果を導くってことは多分こう起きてしまうよなって思ってて、
それをなんかどうやって自分たちに組み込むかみたいなところっていうのが自分たちに、
まあ自分普段の日頃の自分の行動とかに組み込むのかってどうやったらうまくいくんだろうなとかっていうのをちょっとなんか連想して考えたりとかしていて、
難しそうだなそれはっていうことを思ったりとかしてましたね。
何が敵なんですかね。サボろうとするとか、手を抜こうとする、隠そうとする、誤魔化そうとする、騙そうとする、あと楽しみか。
誰が敵なのかな。
まあなんか自動的に取れるデータって結構まあコンピューターというか我々の業界的に、
例えばGitのコミットログとかああいうのって結構自動的に取れたりすると思うんですけど、
日々なんかじゃあ1日8時間働いたうち、こっちのプロジェクトは4時間でこっちのプロジェクトは何時間でみたいな、
ちゃんと入れてねって言ってもまあちゃんと入れてくれなくなるし、
なんか人間が勤勉にこう行動しないと入力できないものとかは多分、
なんかそれって結局どこに使われてるんだっけってこと分かんないと、
なんか人はサボって入力しなくなるよなとかみたいなことを思ったりとか、
でもその数字が合ってるか合ってないかみたいなのってどうやって気づけるんだろうかとか、
いうのは難しいなあっていうのを思ったりしましたね。
データの信頼性
なんかそういうとこそこの数値的な正しさ、正確さって別に欲しいものどんぴしゃでそこっていうわけでもないんだよなってなりがちですかね。
そうそうそう。
本当にやりたかったのはなんだっけみたいな。
私まあどれくらいこうブレがあってもいいものかっていうものを、
その取りたいものによってまあまた変わってきたりとかするんで。
なんかねプロジェクトにどのくらい時間を配分してるかよりも、
なんかすっかり元気に眠くないかの方が大事とかね。
あとは結局ハックされるっていうことに対して、
まあそのハックされるってことは分かってるから、
じゃあどうやってそれをハックさせないようにするとか、
まあさせないようにする仕組みなのかもしれないし、
インセンティブ設計なのかもしれないし、
メタ計測の重要性
複数の指標によって導き出しましょうとかいうようなことかもしれないし、
まあなんかその対応手段は多分いくつかあるんだろうけど、
まあそこをちゃんと機能させるっていうことっていうのは、
うまくやらないといけないんだよなあっていうのを思いながら、
いやでもその目の前の計測自体がとても大変なのに、
メタ計測のことを考えるのまで考えないといけないっていうのも、
また大変かなんだよなって思ったりしますね。
それってでもすごい根本的なところ言うと、
この本のどっかでも書いてあった気がするし、
デマルコも言ってそうな気がするんですけど、
なんか自分たちで測ろうって決めたデータ以外は、
他人にとって意味ないなあっていう気はしますよね。
自分たちがこういうデータが欲しいから、
こういうふうに取りましょうって決めてしっかり測りますっていう同意、
要するにそのデータがどんな意義を持つかっていうのに同意した人が、
自分たちのためにそのデータを取ります。
だったらギリギリ成立する気はするんですよ。
それで言うと、数値的な正しさ正確さっていうのを超えて、
私たちにとってのそれが価値じゃないですか。
そのデータがある、ちゃんと取れているっていうのが、
そこから得たい、その先にある何かが欲しいので。
それはすごい正確さとか数値的な意味での正しさっていうところを超えて、
本当に意味のあるっていうに合わせるような正しさに繋がる気はしていて。
っていうふうにして取られたデータ以外って別にあんまり意味がなくなっちゃう。
どうしても形骸化しちゃうのかなっていう気はちょっとしましたね。
そうですね。なんか自分たちの行動をトラッキングしようという意味では、
なんかそれでいいのかなっていう気持ちと、
でも一方でなんかこう、
これも今金城さんの言ったことを否定できるような話ではないんだけども、
結局アクセスログとか、
そのユーザーの行動をトラッキングしようとか、
数値データを集めようと思ったときに、
そのユーザーがどういう行動をするかって別に、
データを取ろうと決めた人たちのことは全然分かってない、
知らない状態で振る舞っているものの場合に、
そのデータが正しいかどうかとか、
その振る舞いがうまく計測できているかどうかっていうことをどうやって把握しようかっていうのは、
ちょっと難しいかもしれないなっていうのを、
そんなことを念頭に思いながらさっきはちょっと話してたっていうところです。
観察の立場
なるほど、それは難しそうですね。
多分会社みたいな大きい組織になって、
会社で大きい組織になってたときに、
もう開発生産性を図りましょうとかっていうのは、
それにちょっと近いっちゃ近いことだと思うんですよね。
うん、近いと思いますね。
なったときに、じゃあみんながちゃんと事務をしてくれるかどうかとか、
みんながどういう振る舞いをしているのかっていうことをトラッキングしようと思ったら、
うまくいかないときもあるだろうし、
うまくいくときもあるだろうし、
この辺を機能しているってことの保証担保みたいなものってどうやるんだろうな、
出てきた数字はやっぱ信じるしかないよねなのか、
これぐらいのぶれがあるだろうって仮定をしてやるとか、
明らかな平均からの外れ値は除外しましょうねみたいな、
たぶんある程度そういうようなカンプリング手法みたいなこと考えて、
きっと数字を扱っていくんだろうなみたいなことは何となく思ってはいるんですけどね。
ユーザーの話だと別というか、
自分たちのことをヘルシーチェックして改善していくとっていったときには、
さっきの話で価値があるというか、
自分たちで取ろうって決めたんだから、
自分たちの振る舞いを見て、
その数値を信じて改善していくっていうのは究極的には全然、
一人のレベルでいけば体重圏に乗って、
その体重を下げていくみたいな話ではあると思うんで、
そこで片足ついて体重を減らして、
今日は数値を少なす先を見たことを把握したら、
それはもう価値がないよねっていう風になっていくから、
そうですね。
そういうところはなかなかねって思ったりしましたね。
小堀でもそうだよな。
今言われて思ったのは結構あれですね、
このメタ計測の章が特になのかな、
というかシリーズ全体でか、
プロダクトの価値をどう高めるかっていう話っていうよりか、
価値の高いものを作れる組織を、
どうその文化を作るかっていう話なので、
比較的目線が内向きではあるんですよね。
特に今章はかもしれないですけど。
自分たちのよりやりたいことに近づいていく、
次のパターンに持っていく変化をもたらすには、
的な話になっている気がするな。
そうですね。
中とかでも、
数値は品質の欠如を隠しますよみたいな話とか、
疑似レビューはレビューの欠如を隠しますよとか、
結局白書として使い物にならない数値を生み出してしまうみたいな、
いいようなところをどうしましょうかみたいな話だったりするんです。
結構自分たちをどうにか改善するぞっていうような話に行ってますね。
そうですね。カルチャーの話ですからね。
メタ計測そんなところ。
知りって言うんだったら、計測いろいろやりたいよねって言ったときに、
さっき言ってたちゃんとデータが上がってくるかなって話とかもそうなんですけど、
コミュニケーションがしっかり行われているかっていうような話とかもあったりしましたね。
というようにちょっと厳重だけして、次行きますか。
取り込み、意味付け、意義付けが終わって、その後のアクション、同じリアクションですよと。
この4つのステップの最後ですね。
そうですね。
なんかどうでした?面白そうなところ。
そうですね。前のソーシャル文化作るの1のときに、スケジュールが遅れているのが問題ではないと。
そのスケジュールが遅れていることに対して何もしてないのが問題なんだみたいな話があったときに、
反応っていう言葉を確か使っていた気がしていて、そこと繋がってるんだろうなっていうのをまず一番最初に感じましたね。
そうですね。似たようなことを思ったのに。問題は何でもない。問題の対象が全てであるっていう言い回しが今回出てきてますね。
それはそうですね。
でも結局スケジュールを見て遅れてるなっていう理解をして、
じゃあその遅れてるってことがどういうふうなことを教えてくれてるのかとか、
次に何をしなきゃいけないのかみたいな意気づけを何もしないまま放置してると、
出荷の日がやってくるという、そういうようなことだったということですね。
あとは反応がどういうふうに引き起こされるのかっていう話で、
何か外的な刺激に対する反応としての感情があるよねとか、
分殴られてムカつくって言ったときに別に分殴られたことに対しては感情が乗ってるんじゃなくて、
分殴られたっていうことに対して相手との社会的な関係性とか諸々考えた上で、
なんかめっちゃ納得いかないんだけどってなって怒りが湧いてくる的な、
ということは怒りは自分の内側から湧いてきてますよね的な話、感情っていうのがあったりとか、
あと批評規則、サバイバル規則、
サバイバル規則がさっき出てきてるのか。
批評規則、防御反応とかいうのが出てますね。意外とそんなところかな。
おーですね。
次が共感の立場からの観察っていうのがあって、観察するときの。
反応って言ってるけど観察の話をしてますよね、さっきから。
そうなんですよね。
まあいいんですが。
次が立場、どういう立場で観察をするのかみたいなところの話が出てきて、
3つの基本的な観察者の立場っていうのがありますよみたいなのがあって、
1,2,3とあって、1個目が事故の立場っていう風に名前がついてるんですけど、
内部で外を眺めたり、あるいは家を眺めたりする。
ちょっとこれだけはどんなに言ってるんだって感じになりますけど。
次に進んで立場の2個目は他者の立場、あるいは共感の立場っていう風な名前がついていて、
他人の内部で彼もしくは彼女の視点から観察する。
立場3が状況の立場、外部から私自身と他の人々を眺めるっていう風な、
3つの立場から観察するっていうものがあるんだよっていう話が出てきてますね。
これはあれですかね、すごくこの解釈で合ってるかちょっと不安はあるものの、
立場1っていうのが自分の主観的な視点で見ていて、立場2っていうのは自分の主観ではなく、
他者がどう見てるかっていうことを通してその状況を観察する。
立場3がもうちょっと客観的な視点、自分の視点というよりは今自分が置かれているこの状況っていうのはどうなってるんだろうみたいな、
私とそれ以外の人も含め、外からまるで見ているかのような状況で見るっていうのが、
この3つの視点の違いなのかなっていうのをちょっと読んでて思いましたね。
立場の2番目、他者の視点から観察するよっていう話で、参用観察の話が出てましたね。
参用観察っていうのは文化人類学の手法って言っていいのかな。
文化人類学でよくやられる方法で知らない土地に行って、
同じ生活をして、つまりそこの住んでいる人たちの視点を通しながら、
状況、物事を見ていく。普通観察って言ったらシステムの外側に立って、
そのシステムがどうなってるか。
内種は人間観察、趣味は人間観察ですっていうような言い方で、
どっか窓があるようなカフェで人が通っていくのをずっと眺めて、
この街はこういう人がいるんだな、みたいな。
そういう観察っていうようなことがよくあったりするけど、
ここでは参用観察の話があって、一緒に暮らして、
ここにどういう人がいて、その人たちはどういう風に物事を見ているのかっていうのを、
観察対象に一緒に入っていくっていうところですね。
がちょっと変わっているっていうものですね。
共感的な観察方法
なんか果樹面で話聞くか、お試し服にどうするかみたいな違いですね。
そのコミュニティの中に入って、
この人たちは普段どういう世界見てるんだろうっていうのを自分の目で見てみるみたいなやつですね。
これが反応の話の中なんだけど、またここでも2つの話になってるんですよね。
観察なんですよね。
いぎづけ対してどういう立場から観察するかっていうのは非常に大きい、
いぎづけの話をしているのを大きい意義を持つっていうとすごい紛らわしいんですけど、
インパクトあるよねっていうのはわかる。反応の話はあんましてないんですよね。
だからこういうふうに反応したんだっていうのがわかりやすくはなると思うんですけど、
でもそれっていぎづけのはずなんで。
もしかしてこの反応っていうのはあれなんですかね。
その自分がどう反応するかっていう話もあるんだけど、
その人がどう反応したのかっていう話もがあって、
結局なんでそういう反応したんだろうかとかっていうところをわかるためには、
こういうような観察の手法を用いることによって反応を理解するみたいなことかな。
たぶんどっちも込みで言ってるような気はしてはいつつですけど、
でも少なくともここら辺意識できるとその認知の歪みというか、
気づかないですごい自分が攻撃されたみたいな反応というか、
誤った対応、解釈っていうのが減りそうな気はするかな。
ちょっと難しいんだよな。
分かります。でも劇的に本のタイトル出してますけど、
リフレクションにそういうような感じのことがあったような気がするなと思いながら、
結局何かが起きたときになんで自分はそう感じたんだろうかっていう、
結局メタ認知を働かせたときに自分の主観的な話が最初に先行するんだけど、
その置かれた状況とかコンテキストみたいなところを含め客観的な、
この立場でいうとこれも3番目、状況の立場みたいなところを見たときに、
自分と相手の関係性があって、そういう関係性の中でなんでこういうこと言われたんだろうかとか、
いうことを理解していくと、この人はもしかしたらこういうような理由で攻撃しようと思ったわけではなく、
こういうふうにただ物を伝えようとした可能性もあるんだなみたいな解釈だったりとか、
いうのがあると、じゃあ別にこれは大したことじゃなかったんだなっていうふうに、
理解したり息づけしたりっていうことができるとかいうのは全然ありそうだなって気がしますね。
あと何かしらの出来事が生じたときに、それぞれの立場1,2,3から考えてみたら、
自分がどういう行動をとるべきかっていうのが少し回答が変わってくると思うので、
そういう話もあるかなっていう、それはちょっと反応っぽい話かなという気がしますね。
障害が起きちゃいましたって言ったときに、この行動を書いた人は今どんな気持ちかなっていうのを想像するんだったら立場2ですし、
自分も同じシステムの運用に関わっているチームメンバーとして何をすべきか、
とりあえず原因の特定と修正しなきゃな、だったら自分の立場1だ気がしますし、
なんかうちのチームに対して他の人、今何を求めてそうかなっていうところまで想像するんだったら立場3、上等の立場な気がしますし、
とかとかっていう結構インスタントな例えでしたけど、そういう視点の切り替えみたいなものはあるかなという感じはしますね。
ソフトウェア故障の管理
ここは意識的に選択できるはず。
今の説明めっちゃいいっすね。
いいですか?
めっちゃわかりやすいなと思って。
元マネージャーなんで。逆に言うとあれですよね、さっき言ってた三要観察法の話じゃないですけど、
実際に超解像度上げてそこにいる人の立場に立って何か世界を捉えられるか想像できるかっていうと、
やっぱり普段の積み重ねとか関係性大事だなっていう気もしますよね。ちょっとずれた話にはなりますけど。
実際の三要観察してその記録を本にして外に出てくるものとか、成功事例なんで当たり前なんですけど、
めちゃくちゃ地元に馴染んでたりその村で人間関係はちゃんと作れてみたいになってたりするんで、
そもそもそれが三要観察をうまくやるためには前提条件としてそういうのは必須になりますね。
なんかね、本とか読むと結構まあリサーチとしてその現地コミュニティでしばらく暮らしてみて、
一定期間過ぎたら引き上げてきたけど、その1年後2年後にフォローアップ的なリサーチしに行ったらすごい覚えててくれてて歓迎されたとかっていうような話とか、
結構耳にしますよね。
そうですね。
いやその学部厳しそうだから行かなくてよかったって思ったけど、私には無理じゃ。
人や開発の現場とかにこう入り込んでそういうのをやる人とか出てきたら面白いのになって、
あの面白いのになってのはすごい無責任ですけど思ったりとかしてて、
なんかそういう研究あるのかなみたいなちょっと気にしてたりもしますね。
でも普通に社会人インターンシップというか交換留学的なのやってみたいですよね。
分かる分かる。
あいつらのレトロスペクティブどうなってんのかなみたいな。
それは別にチーム間とかでもできるかな。
でも会社が違うとやっぱり前提条件はもっと大きく異なるっていうのはあるんで、
多分もっと普段と違う発見があったりとかすると思うんで、
そういう意味でも全然違うカルチャーの中に入っていくみたいなのは面白いんだろうなとか。
ある種エンジニアが転職する一個の理由みたいなところって、
なんか全然違う環境において自分がどれぐらいできるのかとか、
もっと違うような会社ではどういうふうな開発をやってるのかを知りたいとか、
作る対象が変わったらまた2Bと2Cだとどう違うのかとか、
もうちょっとアドの配信システム、広告配信システムと何でもいいですけど、
特徴管理のサービスとかでは多分考えることは全然違うから、
それによってどういうふうに組織が変わってるんだろうとか、
そういうのは見ていくときっと面白いんだろうなって思ったりはします。
楽しみってやつですね。
この流れでいくとすごい良くない結果になりそうな。
何か故障の原因となる。
故障の原因になりそう。
まあまあでも次行きますか。
とはいえここら辺から結構、
15章どこでした?面白かった。結構読み飛ばした気するな。
そうですね。
故障の大群に対して。
自分のメモを読むとソフトウェアが故障してから修正して、
再発防止する前にどのような管理するのかみたいな話があって、
プロジェクト内において不具合を直すためにどれくらい時間かかったかみたいな話があって、
なんか面白いなと思ったっていうかその修正みたいなもんですけど、
時間経過と除去されたSTIの略語をいつも覚えられないんですけど、
システムトラブルインシデントなんでシステム障害事故のことなんですけど、
時間とともに除去される事故の数がだんだんだんだん減っていくよみたいな話があって、
簡単な不具合はパッと直しちゃうんだけど、
だんだん最後に残った不具合とかって、
これ再現手順わかんなくてとか、再現しないんですよねって言って、
解消が難しいやつだけ残っていってパッと直せないから、
こういうグラフになるのかなみたいなのをちょっと読みながら考えてたりとかするのとか、
あとは多分この中で修正をするのに1行変更するのにどれくらい時間かかったか、
まあ多分原因を特定して実際対処するのに、その行数変更するのにどれくらい時間かかってましたか、
みたいないうようなのを取るみたいな指標として取るみたいな話があったんだけど、
いや現在だとそれ全然やってないよねみたいなのがあったりもしたので、
結局この辺の話その大枠の概念自体は生きていると思うんだけども、
その指標の取り方みたいなところっていうのは多分全然今と変わってはいるんだろうな、
今は変わってるんだろうなっていうふうに思っていながら、
この辺全然詳しくないから、じゃあ現代ってどういうふうにそういうものを扱ってるんだろうっていうのはもうちょっと勉強してないとなーっていうのは読みながら、
故障の大群がやってきたら対処をどうやってやるんだろうな、現代っていうふうにちょっと読みながら思ってましたね。
現代の問題解決アプローチ
おそー、あ、故障、欠陥じゃなくて故障でしたっけ。
故障の大群に対処するっていうのがタイトルで、
傷害ですね、はい。
そうですね、欠陥と故障で、これなんか前回も出てたけど、フォルトとフェイラー、そうか、故障は症状で欠陥は病気。
うん、で、そうだから原因特定から修正までは確かになーって思ったんですけど、なんかそれこそMTTRはフォーキーズでも大事にされてるじゃないですか。
うんうん。
だから発生というか検知から修復までの時間は多分現代でも非常に重要視されてはいるなーっていうのは、なんかそれにちょっと近い話として。
うん、確かに確かに。
っていう気はしたんですよね。欠陥か、欠陥、欠陥、そうですよね。
欠陥が発生しましたって対処しなきゃいけないよね、対処しなきゃいけないって言うとあれだな、それが本当に価値を生むんですかって突っ込まれたら、
すみません守護がでかかったですってなるんですけど。なんか問題があったらちゃんと対応した方が良さそうだっていうのは別に昔も今も変わってないと思うんですけど、
それこそなんかデリバリーのシステムの改善というか進化というか改革があったりとか、それこそビルドとかコンパイルとかめちゃくちゃ早くなってたりとか、
っていうのもあって、なんか少し欠陥に対する捉え方、当時と今でニュアンス変わってきてるのかもなーとか、ちょっと話し聞きながら思ったりしました。
そうっすよね、なんか半年に1回しかアップデートできませんっていうのと、毎日デプロイしてます、毎日リリースが発生してますわ、やっぱちょっと違うゲームって感じはしますよね。
なんかめちゃくちゃクソみたいな言い方しますけど、「あ、明日直しときます。」が通用しやすくなっていると思いますよね。
なぜなら今日やらなくても明日でもできそうだとか、今やっとかないと絶対にもっと問題が大きくなるぞっていう、今やるか明日やるかでのコスト損失の大きさの開きが減ったんじゃないかな、昔より。
まあ邪気も言えますけどね、なんか気づいた時にパッと直しちゃうはやりやすくなったはずなんで。
ゲームプログラミングの進化
うん、パッケージのゲームとかはね、1回出荷したらもうアップデートできないってなったりするんで、今はなんか割とできる場合もありますけど。
今だとめちゃくちゃあれですもんね、最初のダウンロード、っていうか配信初日にいきなりパッチのダウンロード必要みたいな、結構常にありますからね。
ありますね。
まだ起動できない、くそ寝るか。
そうなんだよな、なんかパッケージソフトを買ってきたのに、ネットワークにつながってると、ダウンロード始まってあれーみたいな。
いやでもゲームプログラミングやってる人は尊敬しかないから。
非修理系だったものが結構修理系に寄ってきたこともあり、割とこの辺は確かにゲームチェンジはあったことによって、もうちょっと柔軟さが生まれたって感じはありますよね。
だから本質的な概念みたいなところは何か共通しているものがあったとしても、少し形、トラッキングすべき重視すべき指標としては、ちょっとニュアンス変わってたりとか、インパクト順位付けした時に、
いや今だとこっちの方がまといてるよねってなったりするのかとか。
確かに。
可能性と適応のコストが下がってるんだったら、欠陥あたりの損失、一失利益は減ってるはずなので、昔より大事になりづらいみたいな。
なんかすげー僕がやる気のない食料プログラマーみたいなことばっか言ってるの。そんなことないですよ。なんかね少し温度感が違うかもなーとかいう気がしますね。
そうですね。まあなんならどんどんその考え方が発展していって、不具合がゼロが本当にいいことなんだっけっていう話までありますからね。
とりあえず動くと思うからデプロイしようぜって言っても、怒られ、怒ったりしない人が増えてそうですからね。
だし、むしろ何も起きてない。
お前はキロフローにするぞみたいな怒り方がなくなってる。
何も起きてないってことはそもそもそのシステムに対して変更を入れようとしてないっていうことでもあるから、こうチャレンジがないんじゃないかっていう話でエラーバジェットみたいな考え方も出てきてるし、なんかやっぱちょっとゲームのルールが変わったっていうのは結構ありそうですね。
そうですねそうですね。
言っていることはリトケリギリスなんですけどね。
そうですね。
まあまあまあでも、第五はそんな感じ?
第四部か。
