パターンと圧力の関係
じゃあ、第3部いきますか。 第3部は、パターンに圧力をかける要求ですね。 パターンって言ってるのは、まあ今まで扱ってきたパターンで、圧力っていうのは、パターンって言ってるのが今までこれでいいじゃん、うまくいってるよねっていう状態っていうか平和なありさまだったと思うんですけど。
そこに対して、それだと立ち行かなくなる的な圧力ですね、ストレスっていうのがあるよねっての話してる部ですかね。 そうですね。
どういうストレスがあるのかっていうのと、それに対してどんな典型的な反応があるのか。で、それによって何が起こるのかっていうところなんですけど、ここは何か面白かったところありますか? おうですね。どこでも何か線形でないって話をしているなーって思ったんだよな。
複雑度が上がる、問題の混乱性が上がるっていうのがストレスになるっていう話はありましたもんね。 そうですね。 なんか○×ゲームぐらいだったら簡単だけどチェスだと難しくないみたい。問題のスケールが違うよね。で、ここに対して線形的なモデルで対処していくのは嫌な予感しかしねーなーっていう。
しかも完全情報ゲームだったらまだ時間をかければ全部読み切れるかもしれないけど、現実はそうではなく、実際何が起きるかわかんないみたいな運の予想みたいな部分もいっぱいあるんで、余計にわけわかんないですよね。 そうですね。そっか、それで規模複雑性のダイナミクスっていう話が出てくるのか。
あと153ページの、毎回練習問題っていうのがついてるんですけど、同僚のトム・デ・マルコはソフトウェア開発の管理はチェスよりも困難であることに同意するかみたいな話が出てきて、やっぱ同僚だったんだみたいな、いうところが面白いなと思いながら、過去読んできた本と繋がっていいなって思ったりもちょっとしてました。 でもリスターさん出てこなかったですからね。
で、結局複雑で大変、規模が複雑さのダイナミクスみたいな問題に対してどうやって立ち向かうみたいな話をしてるんですけど、結局規模を小さくしましょうとかリスクを減らしましょうみたいな話をしていて、この辺はやっぱりそうなんだよねみたいな気持ちになりましたね。
モデルを複数、レパートリーか、モデルのレパートリーを増やすとか、情報に応じて複数のモデルを複合して融合して使いましょうとかっていうのが出てきたりしましたね。
スクラムでやろうと思ってるんですって言われた時に、それは何でだいって聞くと、スクラムっていうのが偉らしくて、偉いやろっつって。
でもこれ結局90年の初頭に書かれて、今が2025年でしょ。30年ぐらい経って、でもソフトウェアをドーンと大きく作ったりとかいうことは、まだいっぱいやってるんだろうなって思うと難しいですね。
そうですね。 規模が小さいとお金にならないとか、小さく作っていくっていう方法は別な方法としてはあると思うんですけど、契約の問題だったりとか、複雑さを成し遂げてくれるからこそ大きいお金が引っ張ってこれるとか、
そういうようなものもあると思うので、その辺とかはビジネスとしてソフトウェアを作って納品したりとか動かしていくっていうことに、違うアプローチがなかなか取れないとかっていうところはあるんだろうなって勝手に妄想してます。
解かなくていい問題も増えてるでしょうからね。ネット通販やりたいんですって言ってもショピファイでいっかみたいな。100万円かけて独自ECパッケージ導入しなくていっか。
直近だと多分AIによって安上がりするものがいっぱい出てくるのと同時にAIを使った難しいプロダクトみたいなのいっぱいあるだろうし、そういうのって結局AIで〇〇がやりたいみたいにしてお金を引っ張ってこれとすると規模が大きくてリスクが大きいものを成し遂げるんやつって案件を取ってきましたみたいなこととか知らないですけどあるのかなって勝手に思ったりしましたね。
だってね、昔は柄系のキャリアによって画像が直送できないから変換するサービスみたいなのあったわけですからね。
そうですね。
まああれは無料でしたけど。どこからお金取るかっていう話はさておき。ちゃんと事情として成り立ってたなーみたいな。
実際この中に顧客の要求の話も入ってて、そこに顧客が増えると要求が増えて開発保守業務が規模がどんどん大きくなっていって混乱していくよねみたいな話とか。
あと子舎対応みたいな話みたいなの出てきて。子舎対応するとそこにミーティングで呼び出されてみたいなことになってみたいな話も出てきて。
だって第11章がその顧客の要求に対する反応っていう章なんですけど、書き出しというか第一節が顧客は組織の健康を損なうですからね。これ損なうって読むんですか?
わかんないです。でも損なうって読みそうって今。
読みそう。有害の害に送りがななうで。害なうって書いてありますね。
なんかツイッターか?みたいな。健康害なうみたいな。
健康害なう。
そう、ところどころ普段使わないような漢字がいっぱい出てくるんですよね。
そうですね。
わざわざセリフが漢字で書いてあったりとかして、しかも何ていうか。
歌白で。
歌白って書いてセリフって読ませる。それは多分時代的なものなんだろうなって思いながら。
あれはそうですね。あれは高校の時にヘミング読みまくってたからスッと入ってくる。損なうでいいらしいです。
よかった。
そうですね。より多い固着は開発負荷を増す。固着が増えると種の負荷も増えるとか。
うん。
あと固着との緊密な接触が破壊的になる。これはあれですね、さっき言ってた固者対応とかに近い漢字がするな。声の大きいお客さんのことを無視できなくなるかな?
うん。
あと逆に組織が固着に破壊的になるっていうのがありますよね。明日来月からAPI100万円なんでみたいな。
突然の値上げとか。
突然の値上げとか。
ツイッターのAPI高いみたいな。
言わなかったのに今。ここら辺が今までの平和で牧歌的にやってた開発とか事業の組織に対してストレス、圧力をかけてくるっていう話ですね。
うん。ここの全体の話として圧力ってどこからやってきて、それは自分たちでコントロールできるものなのかどうかみたいな。これやっぱり全体のテーマっていう感じかなっていう気はしましたね。
ソフトウェア開発とエラー
うんうん。そうですね。
まあでもマジでそうだよなって思いながら。ソフトウェア開発よく目にするな、こういう話って思いながら全体読んでましたね。
そうっすね。多重バージョンとかね。
いやー大変ですからね。
大変ですからね。あーでも第三部そんな感じかな。
うん。そんな感じだと思います。
はい。じゃあ第四部いきますか。
はい。
欠陥パターンですね。ここは結構この本読んでよかったなーって個人的に感じている章ではございますが。
はい。
欠陥なので、まあ故障とかそういう失敗とかそういうやつで失敗?失敗違うかな。
まあフェイラーとか。
それで言うとこの故障も違うか。
まあなんかエラーにまつわる話を結構してますよね。ここは。
そうですね。エラーっていうのに対してどう向き合ってるかどう対応してるかどう反応するのか的なところをパターンと紐づけてパターン、文化レベルって言っていいと思うんですけど、紐づけて語ってるよっていうようなセクションですね。
セクションパート。
一応なんかエラーっていうのはプログラミングだけじゃなくて、エラーっていう概念が世の中の発展をさせてきたんだよみたいな話とかもしてますね。なんか最初の方で。
結局なんかここはポエム的だなってバカにするって意味ではなくて。
エモいってことですか?
そういう感じの。一応人間の心のプログラミング、精神分析の話とかDNAによるDNAのコピーの時に出てくるエラーみたいな話と、
いわゆるコンピューターの今、我々が仕事で扱ってるようなプログラミングのエラーみたいな話を3つ並べて、エラーっていうのは価値ある情報源なんですよっていう。
エラーっていうのはすごくネガティブなイメージはあるけども、そうではなくてこれらは結構大事なことなんだよっていう話をするために最初の方にちょっとそういうようなことを書いてます。
なんかまさにあれですよね、生き残ったものが生き残るであるみたいな。ちょっと違う気がする、言い回しが違う気がしますけど。
結局そのエラーによって引き起こされたものによって生存が続いているっていうような話っていうのはありますね、DNAの話とかでよく。
あとあれですね、僕のこのショーとかで言うと好きだったのが、エラーは道徳上の問題ではないっていう説の下だからこうですか、12の1の1にあって、これなんか言い回しがすごい好きでよく使いますね。
まあなんかプロとしてやってるんだからエラーなんてないようにちゃんときれいなコードを書きましょうみたいな話じゃなくて、いえいえ経済的に損失だからみたいな話につなげてるんですよね。
でこれ道徳上の問題だとするとエラーを出さない人は立派であるみたいな話だけで終わっちゃうので、なんかそういう次元を脱するために大部分のエラーは予防よりも処理によりコストがかかる。だから生み出さないに潰しておくと経済的に有利である。要するに合理的だよねって話があって。
一番最初のクロスビーの品質はタダであるって話にここでまたつながってくるっていう感じもあって面白いですね。
でこれエラー、そっかエラーの用語法っていう話はあるか。
顧客の要求の影響
欠陥と故障っていう言葉を使い分けるみたいな感じのことが書いてありますねここは。
あとエラーについて議論するときに全てをバグと呼ぶ人々は自身のプロセスを制御する責任を取っているとは到底言えないって書いてあって。
急にめっちゃ指してくるなと。
これで関係者跡書きとかを見るとその欠陥とか故障とかそこら辺のしっかり工学的に次数で決められている用語は特に訳語気をつけてよっていうふうなことも書いてますね。
可変、可変ってバリアブルなのかなるほど。
なるほど。ここで慣習的とか舵取りとかいろいろここに書いてありましたね。
早く気づきたかった。なるほど。
欠陥と故障っていうのがあって、症状である故障、フェーラーと病気そのものである欠陥、フォルトっていうのを区別するよっていうのことですね。
だから実際見えているものとそれの原因となっているものみたいなところは訳で考えましょうねっていう話をしてますね。
体重100キロでも困らないみたいな話してたのここのくだりでしたっけ?もっと前か。
ちょっと前ぐらいに900ポンドにも太った人がなぜ900ポンドも太ってしまったのかみたいな話はちょっと前にありましたね。
ずっとねその後背中の肥満の問題と背中の痛みな。適的に背中の痛みっていう言葉が出てきて。
出てきますね。
ちょっとこれに引っ張られて読みづらいなって思いながら読んでましたね。
あとそうだなそのちょっと前ですけど198。さっきのエラーの用語法とか書いてたより少し上のくだりですけど。
エラーと品質の関係
まあなんか読めないんだよな。おそらく私たちの顧客は1万のエラーがあっても我慢するだろう。しかしトムデマルコが尋ねたように彼らはこれゼロが何個あるんだって話なんですけど。
とても大きい数字。
はい。10の14乗ぐらいかな。だったら我慢するだろうかみたいな。でこの意味ではエラーはまさに品質の問題である。
要するにさっき言った欠陥とかUIが使いづらいとかも含めてエラーだと思うんですけど。
っていうのが何個かあってもそれでもソフトウェアちゃんと使えるようにっていう話だったらそんなに問題、経済的な価値は損なわないっていう意味で
要するに誰かにとっての価値であり続ける価値を提供しているっていう状態ではあるだろうから問題ではない。我慢できるだろうけど。
なんだこの桁数の10の14乗ぐらいのエラーがあるとおそらくもはや起動しないとかそういうレベルだと思うので。
そういう意味ではエラー、品質によりイコール価値っていうのに繋がってくる。
だから10個ですか100個ですかじゃないっていう話ではあるんだけど、そんな1億個とか1k個とか、kって日本語の方のkですね。
とかあったら、それは品質の問題だよね的に。話ですね。だからゼロエラーとかゼロバグっていうことを言いたいんじゃん、ではないんだがみたいな話だし、
エラーがゼロだから品質が高いではないでしょっていうところとかを繋げつつ。
数が重要ではないが数は重要であるみたいなすごい。
なんかありましたよね。このクリームパンを食べると発芽性物質があるので癌になりますみたいな。
食べるのやめた方がいいんですか。1日に10億個食べたら癌になります。
そんな話があった気がする。
まあそこまで食べると別のものにかかってそうですけど。
そうなんですね。どうやって食べたって。
欠陥パターンの話はなんかどこら辺が面白かったりとか、なるほどってなったりとか。
面白かったなと思ったのは、故障検出曲線、ページ数を書いてない、自分がメモを取った時に。
故障検出曲線は第13章、そのタイトル216ページ。
の中で、故障が見つかるのって、だいたいS型の曲線をたどりますよみたいな話が出てきたりとかして。
最初のごく少量のテスト時間がいくつかの優しい問題に増やされ、次に大部分の容易な問題はテストサイクルに見つけられるみたいな話とかも出てて。
結局、後半になるにつれてどんどん故障を見つけるっていうことが難しくなっていく。
最初は簡単な問題がいっぱい見つかって、後ろにいくにつれて疲れにくくなるんだよって話をしていて。
ちょっと前に、1個前のページでも間違い探しみたいなのが載っていて、サイゼリアに来た気分になりましたね、読んでて。
間違い探しの例は分かりやすかったですね。
そうですね。
だから開発の初期の段階でテストフェーズみたいなものとか作って、テストフェーズって呼べるほどしっかりしてるならあれかもしれないですけど。
最初の1ヶ月でバグがこれしか見つからなかったから、半年でこれぐらいしか見つからないだろうみたいな予測っていうのは怪しいよねっていう話とかもあって。
間違い探しの例で言うと、分かりやすい見つかりやすい間違いっていうのはもちろんあるけど、間違いを発見した順っていうのは誰一人として一緒じゃなかったとかありましたもんね。
多分誰も見つけられなかった、制限時間内に見つけられなかった間違いとかもあるんじゃなかろうかっていう気もするし。
結局ここもまたなんか典型の罠みたいなものがあるよなーっていうことも思うし、あと簡単な問題ほど手前に来て難しい問題ほど後期に来るってことを考えると、
ソフトウェアの開発って後ろに行けばV字型の工程とかで考えると後ろに行けば行くほど難しい問題が残っていて、パッと解決できないみたいな状態になっていくってことが起きたりするんだろうなっていうのが、
ここでも話されていて、自分の経験したことみたいなところと、ここで喋っていること、実際にこのグラフにされたことっていうのが結構合ってるなっていう気持ちになりましたね。
関連するようなもしかしたらちょっと違うかもしれないんですけど、途中中途入社とかでプログラミングの経験はあるけど、そのプロダクトの知識はまだないっていう人も含めて、
その問い合わせ対象のローテーション、1週間交代でやりましょうって言うと、いきなり新人に超難しい問題しか回ってこないみたいなやつがあったりするな。
確かに。そうなんだよな。だからこそグッドファースト1週ってものを作るのかなっていう気もしたな。連想して思ったことですけど。
そしてトムデマルコの話でもありましたよね。簡単な問題ほどすぐ解かれて、常に難しい問題だけは残されていくというか、そういうのもあったよなって思って。やっぱこれっていうのはそういう法則性みたいなものがあるんだろうなっていう気持ちになりますね。
そうですね。あとその故障率の可視化予測みたいなので言うと、デマルコ大いに語るからであった。発見した故障をすぐに報告しないで、後で報告して、かつ自分で直すことによって二重に報酬を得るみたいな、人間に働いてしまいみたいな話もありましたよね。
欠陥特定の重要性
だからそれに似たような話があった気がするんだよな、この本にも。まあでも故障検出特選、予測として使うにはこのモデルはなかなか難しそうだし、いろいろあるねっていう感じがしますね。
今の何ですかね、今自分がやってるソフトウェア開発とこの辺とかがどうリンクさせるといいかなとかっていうのはやっぱちょっと難しいなって思ったりしますね。
なんかテストフェーズっていうものは明確にあるわけでもないし、なかなか今じゃあこれで起きたから、じゃあ未来どうなるかみたいな予測を立てるってこともあんまりそんな積極的にはしないなって気がするから。
まあでもあまりにも多いと他にもあるんじゃないかっていうことはちょっと疑ってかかるみたいなことはやるな、でもそれぐらいだなやっぱり。
いやー悪口になるから、なんか言いますもんね。あとそのテスト、当然出荷とか統合の前に統合テストっていうのがあるからあれか、出荷してユーザーの手元でデリーになる前にいろいろバグ取りとか故障の探索とかすると思うんですけど。
でもそのための検証とかテストの期間っていうのを置いてあった時に、さっき言ってたパターン2、パターン3の管理者はどうやってそのテスト期間取り扱う系とか、欠陥が見つかった時にどうやって対処する系的な話もちらっと出てますね。
例えばパターン2の監修で生きてるというか、今まで通りこれからもうまくいくよね的なモデルで生きてる人たちは、何かとあるモジュールのテストで不幸、不幸じゃねえや、何か良くないことが見つかった時もそれぐらいの問題だったら後で対処するかっていう楽観的な見方を
しがちなのに対してパターン3の人は、じゃあそのモジュールちょっと怪しいから、もっとどうにかしないとねっていうふうな判断してくれるとか、テストのカバリッジ上げましょうなのか、っていうふうに変わってくるよねっていう話も作られてます。
これで実際自分の経験といろんなことを結びつけて喋ろうとすると色々と難しいなってちょっと今思いました。
ちょっと怖いですよね、いろんな時代が。あとは僕がこの欠陥パターンの下りです、結構好きだなって思ったのが、欠陥特定のダイナミックスっていう話があって
まあなんかバグがあった時に、バグって言うと無能だと思われるのか、欠陥があった時に、あ、欠陥だってなった時にすぐ直せる。もしくはその欠陥が埋め込まれてから早い段階で見つけられることができると修正のコストも非常に軽くなる。
けどその欠陥を生んでるコードが1年前に書かれたものです、2年前に書かれたものですってなると、そもそもどこが悪いんだ、どのコードが間違ってるんだって発見とか特定も難しくなるし、
欠陥に対応してるライフサイクルというか、スパンというか時間の全体の中で特定どこが壊れてるんだみたいな話とか、そもそもここ実は欠陥があるじゃんっていうのを検知するまでの時間的なコストがすごい上がっていく的な話があってですね
まあ要するに早く見つけて早く直すのが一番お得。結構年期の入った交渉結果はなかなか特定も難しければ特定した後の修正も難しいみたいなやつがあって、お、なるほどオブザバビリティ大事やなって思いますね。
そうっすよね。その話ってプロダクションで動いててっていう感じなのか、システム開発の1年間、1年で作るものがあって、後半になって昔書かれたコードに誤りがあると前提が覆ってしまうみたいな話なのか。
まあ両方ともそうなのかみたいな、なんかちょっとそういうことをちょっと連想したんですけど、どっちなんだろうなっていうのは思ったりしました。
なんかどっちもな気はしますけどね。単純にそのモジュールに依存している他のモジュールが動いてくるっていうのもあるし、開発の最初の段階と後半というか終盤に差し掛かってくると、動いているもの自体、開発中のもの自体の完成度というか複雑度も違うと思うので、
なんか計算合わないけどこれはどこでだみたいな話とか。
でちょっと直すと他に影響が増えて、影響する場所がたくさんあるから。
影響範囲のいい概念がね、生まれてくる。
でだ。いや、まあそうですよね。
これ前なんか自分で書いててめっちゃ面白かったのがなんかめっちゃフレーキーなテストがあって、あれなんでCI回すと結果が変わるんだって思ったんですけど、よく見たらデートタイムのオブジェクトがイメータブルになってなくて、毎回テスト回すたびに50分増えていくみたいな。
時が進んでると思ってすぐ笑ってました。
それは怖いですね。
テスト書いててよかったっていうかテストの書き方が悪いから、そこでしか再現しないんですけど、なんかすげえかわいいバグ運だなと思って。笑って。
やっぱテストのテストが必要ですねみたいなことに。
確かにな。いや全部最大入荷でイミュータブルにしてほしい。
わかる。めっちゃわかる。聞くそれも不具合を起こさないテクニックの一つみたいなところでは。
ちょっとこれどういう文脈でこうなったか読んでて忘れてしまったんだけど。
はい。
規模・複雑性・ダイナミクスに打ち勝つ分割統治の話がこっちに出てて、235?
故障から欠陥を特定するっていうところで、システム規模がでかくなっていくから、欠陥特定時間も伸びていくから、分割統治せよってことか。モジュールに分割しましょうみたいな。
これなんかテストピラミッド的な話を思い浮かべながら読んでましたね。
その中で14.1.32出荷時間に打ち勝つには作業を分割せよみたいな話があって、部品1、2、3統合してリリースするみたいなやつが、
この部品を作る人を3人とかにすると、1と2と3を作るのを並行にできるから早く作れるよみたいな話が書いてあって、そういう話がこういうタイミングでもされてるのかって思ってて、
欠陥解決のダイナミクス
これ普通のことじゃないって思って読んでたんですけど、でもわざわざここに書かれてるってことはあれなんですかね。
当時そんなことあんまり考えてなかったみたいなことなのかなっていうのがちょっと気になったなっていうのがありました。
そうですね。いや考えてなかったってことはなかろうっていう気はしますもんね。
そうそう。まあでも分割装置も結局、うまくやらないとくっつけるタイミングで爆発するよみたいな話も書いてあったりとかして、なんかもっと世の中シンプルになると気になって思ったりしました。
これしかも欠陥の話ではないですよね、ここは。
そうそうそう。
時間に打ち勝つには作業を分割せよっていうのが、故障から欠陥ごとって、ああそういうことか、時間が経つと故障が円爆したタイミング、どこに円爆されたのかっていうのが、
特定が難しくなるから絶対の時間量を減らす必要があって、要するに最近行われた作業に全部するべきなんですよね。だから時間の短縮、カレンダー時間の短縮っていうのが重要な意味を持ってて。
そういうことか。
部品一人でリニアにモジュール1モジュール2モジュール3っていうのを開発して統合ってやると、作業者がその一人であっても、半年前に書いたコードレスソレーみたいなところまで含めて、
多分Gitとかないからブレイムとかもできない状態で、どこが悪いんだっけっていうのを全部、なんかもうおもちゃ箱をひっくり返すような感じで探すのかなと思うんですけど、
うん。 並行作業して全部1ヶ月以内に書かれたコードにしか原因はあり得ないですってなると、楽だよねっていうところで繋がるのかな。繋がりそうな気はしますよね。
うん、繋がりそうな気はする。
ただそれを直接書いてるわけではないからわからん。わからんけど、欠陥の検出特定っていうのが欠陥の解決全体に関わる半分以上を占める重要なファクターなので、時間っていうのを解決することによって品質も高まるはず。
だからまあやっぱここも結局いかに規模を小さくするかみたいな話がやっぱされていて。
そうですね。その次の講座、システム規模の間接講座です。
いや、規模が小さくなるといいんだけどな。
うん。一番規模を小さくするにはユーザーを減らして売り上げを減らすと効きますね。
ビジネスが立ち行かないと。
提供すべき価値を低くする。
まあそうですね。そうなると今度別の問題が別の方向からやってきて、やっぱライトついてはずなみたいな感じに。
あれ何のためにやってたんだっけってなって。
そうそう。
いやでもそうですよ。別のところにもあった気がします。さっきのコタクの圧力の話はありましたけど、売り上げを立てないといけないから機能を追加しないといけないみたいなやつとかはありますからね。
うん。
重要性はそんなところかな。
うん。そんなところですかね。欠陥パターンは。
圧力の影響
そうですね。STIとかの話は出てきますけど、振れると長いからいいか。
笑
欠陥解決ダイナミクスとかも、システム規模が増えると欠陥数も増え売るし、各欠陥も牽動する副次効果ってこれはなんか取り味というか。
うん。
どれが優先的に解消しなきゃいけない、修正しなきゃいけない欠陥だっけなっていうのを決める必要もあるよねとか。
うん。
っていうダイナミクスというか、そのシステム思考的な影響が働いてきたりとか。
うん。
しますね。劣化のダイナミクスとか、はい。
あ、大丈夫です。
なんかでも15章そんな感じな。
うん。
次の圧力パターンに行きますか。
いきましょう。
はい。圧力パターンはでも結構短めですよね。
そうですね。
どうですか?なんかここ正直ほとんど今までに触れた話をちょっとだけ見方変えてる感じかなーって思ったりとか。
うんうん。
そうですね。あと一番最後の最後があれじゃないですか。
私たちは何を達成したかっていう章になってるんですけど、ここまでの部分って結構パターン012とかがフォーカスされてて。
それでいい場合もあるんだけど、やっぱこういう問題があるよねとか。
フィードバックに感応ができないみたいなところとか、なんかダメだなみたいな部分。
ソフトウェア開発って進化してなかったんじゃないかなみたいな、いう気持ちになりながら読んでたんですけど。
なんか最後の最後でこうちょっと希望というか。
うん。
みたいなこう、いや状況は変わってるんだよって話をしてくれて。
なんていうんですかね。ちょっといい章だなって思いましたね。
うん。
なんか厳しいことしか言わなかった子もが、引退戦終わった時にちょっとお前らよくやったよなって言ってくれるみたいな。
そうそうそう。
そんな味わいがありますね。
そう。あとまあ、まあこれ40年間っていうスパンで捉えてましたけど。
結局なんかソフトウェア開発の蓄積みたいなものっていうのは、まあやっぱちゃんとされてるんだなっていう気になって。
じゃあそのどういう蓄積が今、今もなおされているのかみたいなとこはちょっと気になるなみたいな。
いうふうにこう、なんていうかね、気になるなって思わされるような本だなって思いましたね。
うん。そうですね。
あれですね、圧力パターンのとこ読んでて、圧力ってプレッシャーだと思うんで、
こうプレッシャーをかけるとちょっと速くなるけど、継続的には速くならないみたいなのを知って、
なんかともデマルコもしてたなーみたいな。
何書いたの?
思ったりしましたね。
はい。大体デマルコと同じこと言ってるんだよな。
そうそう。
あーでもそっか、私たちは何を達成したかのところに、なぜシステム志向かっていうのを書いてたっけ?
そういう説は18の1がなぜシステム志向かなんですけど、なぜシステム志向なんだ?システム志向とは何かっていうのは言ってないのか?
そうなんすよね。この本の一貫してシステム志向ってこうこういうものでみたいなのは書いてない気がします。
まあでもシステム志向の能力があることによって救われてきた的なことは述べていて、
3つのことがしばしば可能になったと。
システム志向の重要性
1つ目が観察すべき対象の選択。2つ目が観察結果の解釈。3つ目が目標達成のために取るべき行動。
ってなんかここら辺がシステム志向の関連するというか、紐づくような重要な能力が磨かれてたなーっていうようなことは振り返ってますね。
だから他の人にも役に立つんじゃないかと。それは言ってることすごい繋がる気がする。
でもまあまあまあ、そんなところですかね。
あえて他に取り上げるものはあるかな。
そうですね。パターン3・4・5に関しての言中もちらっとありますね。
うんうん。
うん。いいな。パターン5は今のところ幻想に近いけれども、
それは良い文化の関心を移転可能とし、世代に渡ってそれらを追求するに違いない、というふうに書いてあって、すごいな。
どこかにあるらしい、伝説の○○を探すみたいな。
幻想に近いけれどもって、それはほぼないっていう。
世代に渡ってそれらを追求するに違いないっていうのが、考えてるスパン、タイムスパンが全然違うなっていう感じがしますね。
そうですね。ただまあそのパターンが0から5っていう高いところに向かっていくにあたって、
理想状態、こうあるべきだっていうのを想像したり、具体化する能力、態度って大事だよねっていうことも書いてあったんで。
うん。
幻想を追い求めるの大事なんでしょうね。
うん。
はい。要はまあそんな感じですかね。
そうですね。
めちゃくちゃ時間かかってるけど、なんか全体通してみたいな話をしますか。
どこら辺が面白かった、面白くなかったでもいいんですけど、どうでした読んでて。
いや全体通してみると、なるほどって思いながらだったんですけど、品質のやっぱりそのカルチャー、サブカルチャーのところがマジでわからんって思いながら読んでたので、
すげえ大変な本だなって思ったっていうのがやっぱり一個と、なんかこれが結局シリーズとして今後どういうふうに繋がっていくのかみたいなのはちょっと気になるなって思いましたね。
すげえ似たような感想だな。
2巻3巻と途中で追加された4巻読んでみた後に、パラパラっとでもいいから見返してみたら、ぐっとくる部分増えてるのかなっていう、そこの期待はありますね、個人的には。
そうですね、これだけで何かがすごく理解できるかって言われると、もしかしてそうでもないのではっていう気持ちになりますね。
難しいなあ。
もちろん学びが全くないかって言われたらそんなことはもちろんないんですけど。
そう、面白い部分は要所要所であったんで。
ワインバーグがもうちょっと全体像としてどういう絵を描いていて、その全体像をわかるためにまずこの大きいプロジェクトの中のこの部分をやりましたっていうことだと思うんだけど、その部分だけを読んで全体がどうなってるかってことはやっぱ当たり前ですけど、理解が全部ができたとはやっぱ思えないですよね。
あとあれですかね、ワインバーグ節みたいな言い回しとかテンポとかに慣れてくると読みやすくなる気はするんで。
確かに。
なる気はするんですけど、2巻3巻進むにつれて本の内容自体難しくなっていきそうだなあっていう気もしつつ。
うん。
でも我々でマルコも一通り翻訳されてるので読みましたけど、読む順番逆だったら大変でしたでしょうしね。
そうですね。
そうですね。
ピープルウェアぐらいまでいけばどうにかなったって感じはするんですけど。
こんなとこですかね。でもやっぱ現代との差分がもうちょっと間を埋めるみたいなものがあると。
じゃあ今これ結局どうなってるんだっけみたいな話っていうのはもうちょっとされてんのかな。
どうやって接続して語られるといいのかなみたいなことはちょっと思って。
で、やっぱソフトウェア工学、もうちょい体系だったソフトウェア工学みたいなものを勉強してみてもいいのかなっていうのは読んだ後の自分の中でぶつぶつと湧いてきた気持ちですね。
なんかそうっすよね。わからない、わからなすぎてじれったいみたいな、なりますよね。
とはいいつつ、今の時点でこれはすごい活かせそうだな、持って帰れそうだなみたいなところとかはなんかありましたか。
ありましたかっていうかゼロではもちろんないと思うんで、特に良かったなって思う上位のものとか。
そうですね、でもそういう話をするとついこうやっぱ知ってるものっていうか普段気にしてることに行きがちだから。
まあ確かに。
品質と文化の考察
まあやっぱ規模を小さくするとかリスクを減らすってやっぱそうだよねって気になるし、あと品質っていう言葉の使い方みたいなのをなんかここ数ヶ月ぐらいちょっと気にしながら過ごしてたんですけど、
やっとワインバーグが品質の話、品質とは誰かにとっての価値であるってセリフ自体は知ってたんですけど、
言葉自体は知ってたけども、知ってたんだけど、なんかそれがもうちょっとこうどういう文脈があってどういうふうに出てきてこういうふうに言ってるのかっていうところがちゃんと理解できたので、
なんかよりもうちょっとこう気をつけながら喋れるようになりそうだなっていうのはありましたね。
そうっすね、標準とか企画っていう意味で品質っていう定義はそれはそれであると思うんですけど、
確かにな、なんかこの組織において重要に知っているものとかその背景にあるコンテキストというかカルチャーみたいなものっていうのがすごい密接に関わってくるよね、
というかすごい変動的なものだよねっていうのは個人的には読んでみて、ああそうかそういう捉え方もあるのかって思って、面白かったりしたかな。
あとはまあ欠陥パターンの話は結構自分が登壇する時に何回か引用してたりもするくらいは結構感動したというか、
めっちゃいい説明じゃんって思ってやってたりするんで、そこら辺も個人的には好きですね。
そこもいいですよね。
ここはいいですね。だから全体的にはやっぱりそのより上のサブカルチャーというかパターンに行こうぜっていうのを好み化す本ではあるので、
なんていうか啓蒙的というか強化的というか、資産が上がる話本ではあるなっていう気もしますね。
いやでも成熟とかレベルではないって言ってるっていうかまたちょっとややこしいんだよなって思いながら。
そうですね。まあまあ言わんとしてることはあった上で、そんなに気にしなくてもいいかなってやっぱり思っちゃうので、怒られるかもしれない。
そうですね。そこはそういう前提はあるものの、こういうこと言ってるんだぞって踏まえていればきっと大きな間違いはしないはずなので。
そうですね。やっぱり文化が大事なんだなと思いつつ。そんなとこですかね。
エピソードの締めくくり
はい。
じゃあおしまいにしてきますか。
はい。
じゃあ例によって例のアレを読み上げます。
今週も放送をお聞きいただきありがとうございます。ではまた次回。さよなら。
さよなら。
