00:06
こんにちは、readline.fmです。readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュ・リードライン・FMです。ウィクシー2にもコミュニティがあるので、そちらでも感想などお待ちしております。
お主役は、ゲイエイさんと金城です。それではゲイエイさん、よろしくお願いします。
よろしくお願いします。
シリーズの概要
で、早速、本の話を久々、久々でもないか、やっていきましょうと。今日読む本は、発表しちゃいますか。何の本ですか、今日は。
はい、今日の本は、ワインバーグのシステム思考法 ソフトウェア文化をつくる①ですね。
GMワインバーグさんですね。
そうですね。
いつも肩書かなって思いますよね、これ。
ゼネラルマネージャーみたいな。
なんだあれ、偉い人だなーっつって。
ワインバーグとはみたいな話は、あんまり触れなくてもいい気がするんだよな。
そうですね。私はよく、ライトついてますかって本がすごい好きで、よく人におすすめしたりしてます。
なるほど、あれはいいですね。
この本の話に入っていくと、シリーズなんですよね。ソフトウェア文化をつくるっていうシリーズの第一冊目というか一巻ですね。
そうですね。
もともと全3巻を予定してたシリーズで、これ書いてるときはその予定だったけど、書いていくうちにもう一冊やるかって言って、結局全4巻になってる感じ。
我々のホットゲストみたいですね。
我々のホットゲストそんな大したことじゃないです。
いつも苦いよ。許していい意味で。
第1巻、この本がシステム思考法で、第2巻が動作法が2巻目で、3巻目がシステム行動法ですかね。
第4巻だけ手元に置いてなかったな。変革法ですね。え、てか第4巻一番厚くないですか?
そう、めちゃくちゃ分厚いんですよね。
めちゃくちゃやること余っとるやんけっていう。
3冊で終わるはずだったのに。
ホントですね。
ワインバーグの〇〇法っていうタイトルになってて、日本語だとソフトウェア文化を作るっていうシリーズ名なんですけど、
現代がクオリティソフトウェアマネジメントっていう風になっているらしいので、そっちの方が分かりやすい気がするな。
ソフトウェア品質に関して、いろんな角度からというか、どういう風にハイクオリティなソフトウェアを作ってデリバリーしていけるようになるのかみたいな話がされているシリーズのはずですね。
僕はまだ第1巻しか読んでないので。
自分もこの1巻目がちょうどこの収録のために読み終わったっていうところではありますね。
いいですね。本来やりたかった形ですね。
そうですね。このシリーズで成し遂げたいことというか、ちょっと前書きの方に書いてあって、必要な3つの基礎能力、ソフトウェア開発をする上で必要な3つの基礎能力みたいなところがあって、
何が起こっているかを観察し、観察の意義を理解する能力が1個目で、2個目が難しい人間関係の中で混乱したり腹を立てたり、あるいは逃げ隠れしたい時でも一貫して行動する能力。
3つ目が複雑な状況を理解する能力っていうこの3つが経験上大事だなって、ソフトウェアの品質管理に対して本質的な3つの能力があるんだよっていうことを感じたと。
で、この3つのプロジェクト、3つのことを本にまとめたいなと思って、この本を書き始めたと言っていて、この複雑な状況を理解する能力っていうのが今回のこの本に、このソフトウェア文化を作る1がそれに当たるんだよっていうようなことが書いてありましたね。
そうですね、なんか第4部が何なのかがまだわからんと。
そうなんですよね、まだ全然たどり着いてないから、なんか、まあ書きながらなのか、書いてる途中に仕事でなのかわかんないですけど、いや4つ目の能力があるんじゃないかって思ったのか、いやこれ3つ書いた上で全体を総括するような一冊が必要なんじゃないかって思ったのか。
そういうようなことがあるんじゃないかなというところで、楽しみにしているというところですね。
で、付け加えるとあの会員役者の絵描きの方に、なんかさっきちらっと触れたシリーズのタイトルが全然本役と現代違くないみたいなところもちゃんと触れられていて、どこだっけな。
ソフトウェア企業の変容はソフトウェア文化ないし、サブカルチャーによるほかはないという宣言は現職者と役者に共通しているっていうふうに書かれてるんで、まあだから品質について、品質を目的とした話ではあるけど、それをやっていくには、企業文化というか風土というかそっち側に対していかに観察していかにアプローチしていくかっていうところが肝だよね。
ということで、日本語のタイトルはソフトウェア文化を作るっていうシリーズ名になったよーっていう感じですかね。
あれですね、三部作っていうと最近のケントベックのタイリーファーストとかも、あれも今のところは三部作の予定のはずなので、
あれも個人の話から始まって、チームとか政治とかの話に踏み込んでいくよーって書いてあった気がするんで、まあ少し共通するようなところも感じますね。
ケントベックの本は3冊に収まるのか。
あれは1冊目がめっちゃ薄かったからな。
そう、めっちゃ読みやすくていいなって思いながら、あれぐらいキュッとまとまってると、読み手としてもすごくありがたいし、人に勧めるときに分厚くてちょっと嫌だなって思われなくて済むからいいなって思ってるんですよね。
そうですね、ただまぁあっちも第二部第三部は厚くなっていく気するけどな。
そう、いやそんな気はしてます、あっちは。
リファクタリングでやったじゃんみたいな気持ちで書かれてた気がする。
背景と歴史
まあいいや、で、あれですね、時代の話してますか。
時代は出版、日本語が94年か。
94年、で、原著が91年なので、まだインターネットギリギリ家庭用はなくてまだ大学とか限られたところで使われているみたいな、そういうぐらいのタイミングですね。
でも平成がすっかり根付いてた時代ではありそうですね。
そうですね、で、いつもの任天堂でいうところのっていう話でいくと、90年がスーパーファミコンが発売されているぐらいなので、えっとまぁ任天堂64よりは以前、スーパーファミコン、任天堂64以前っていう感じですね。
ヒントくるのかな。
でも実物をやったことあるようにっていう時代にはなりそうですよね、なんかバーチャルコンソールでやりましたとかじゃなくて。
そうですね、もう今だとやったことあるっていうのがリメイクなのか元々のやつなのか、リメイクも何回もされているものもいっぱいあるし、それこそバーチャルコンソールとかスイッチのオンラインとかでいくらでもできちゃうから、なかなかわからないってなりますね。
そうなんですよね。
プログラミング的にいくと、Javaとかが出てきたぐらいなんですかね。
てことはPHPと同じぐらい。
同い年ぐらいでしたもんね、PHPとかJavaとかって。
だいたい同じですね。ただ最初のPHPはPHPなのかっていうのはわかりますけど。
そうですね。それぐらいの時代のソフトウェア開発の現場を見てきた人が書いたというような今回の本ですね。
そうですね。あ、でも本当だ、パーソナルホームページツールズが公開されたのが94年らしいので、翻訳と一緒ですね。翻訳のこの本の出版。
じゃあ、今我々がやっているプログラミングとはちょっと逃走なイメージがありますね。
でもそっか、確かに読んでてJavaとかって言葉が出てこなかったですね。
うん、確かに。
Pythonも出てこなかったから、たぶん仕事としてまだ使われてないのかな。
ボルとかフォートランみたいな感じでしたもんね、出てきたものが。
そうですね。てか、プログラミング言語の話はほぼほぼ出てこなかったな。
そうですね。ソフトウェアを作る話はいっぱい出てきたけど、具体的にテクニックだったりとか、例えば現代で言うと環境構築とかテストとかいっぱいいろんなキーワードになりそうなものがありますけど、一切そういうもの出てこなかったですね。
生産性とか結果みたいな話出てくるから、LOCは出てきたか、生産性を測るのにコード動数で測りましょうみたいな考え方あるよね的なところはチラッと触れてたはずですけど、あんまり人欲の話は出てきたか。
そうですね。チラッとで。
どうやってテストするのがいいのかとか、どういうデバッグがいいのかみたいな話は出てきてはいるけど踏み込んではなくて、その結果プログラミング言語、この言語はこうだみたいな話は出てこなかったです。
面白いのは、今こうやって話してると結構、今の現代の我々の開発と遠いんじゃないかっていう気もするんだけども、読んでるとそんなに遠くないなって思えるような本だなって思ったりもしましたね。
うん、確かに。なんだろう、開発の仕方とかサイクルは全然違うような感じするけど、扱ってる問題が1ミリも変わってねぇなみたいな。
そうなんですよね。
品質の話はどうしても継続的デリバリーとかウェブシステムとかって出てきちゃうとそこはもう完全に変わっちゃいますけど、なんかバケューを品質にいつ気を払うのがいいのかとか、マネージャーがプレッシャーかけてくるよねとか言ってること変わらんなーって一気にしますね。
そうですね。
そうですね、この人、ワインバーグ自体はIBMで描いてたのか。オートランなんですかね、役やってたのは。
なんですかね、なんか全然イメージがつかないから、オートランを描いてたのかコブロを描いてたのかマシーだったのかなんだったんだろうかなって、そこは想像するしかないって感じはありますけど。
そんな感じか、背景的なところは。
そうですね。
本の印象と反響
内容的なところに行くと、いつも聞いてるような、読んでみて全体的にどうでした?印象とか面白かったところとか、気に食わなかったところとか。
読んでみての全体の感想としては、言葉遣い、キーワードとしてパターンとかハブカルチャーとかいう言葉が出てくるんですけど、今、我々が話している組織パターンとかって本読みましたけど、
組織パターンのパターンとはちょっと違う使い方だし、言葉遣いみたいなものが定着しなかったものっていうものがあったりとかして、ちょっと読んでると違和感だったりとか、サブカルチャーなんて言葉っていうのはソフトウェア開発の文脈では全然聞かないなっていうのもあったりするんで、
ちょっとそこが、ん?って思うような感じもあって、なんか最初はわかりにくいなみたいなところはありましたね。で、読み進めていくと、だんだんそこの意味がなんとなくこういうふうなことなんじゃないかとか、
この本ではこういうふうに使ってるんだなみたいなことをわかってくると、ソフトウェアの開発ってものを技芸からどうにか工学の方に近づけていこう、近づけていこうっていうような努力をしているのかなっていうふうなことを思うぐらいに、
やっぱこう、普段のソフトウェア開発の中で起きたことをモデル化して、同じことが起きた時にも同じように対処できるようにっていうようなことを考えてそうだなっていうのを、これはなんか深読みというか勝手にそう思ってるだけかもしれないですけど、そんなふうなものがすごい感じられるような本だなっていうふうに思いました。
あーなるほど、なんかそこに関して言うと僕ちょっと違う感じを受けていて、前半の単語がスッと入ってきづらいはめちゃくちゃ同意なんですけど、なんか工学的にやろうとしすぎてたところに人間的な側面を無視できないよねー的な話っぽいかなーっていう気もしたので、
矛盾はしないんですけど、何だろう、技芸、工学からさらに一歩踏み込んでどこに行くかみたいな話になってるかなーっていう気もしたりとかしましたねーって思って、言ってて思ったけど、そうか、ピープルウェアと同世代の本ですもんね。
そうですね、そうですね。
流行ってたのかな。
流行ってたかもしれないし、ところどころ本の中で一緒に働いてるトムデマルコっていうのが出てきて、一緒なとこにやっぱいたんだなーみたいなところを思ったりとかもしましたね。
だから、ディスカッションしてるんですよね、きっと本の内容とか。本の内容に限らずソフトウェア開発において、人間っていうものをどう扱ったらいいかっていうのを手名付けるとかっていう意味じゃなくて、どういうふうに捉えて考えていけばいいかっていうふうに、そういうディスカッションをきっとしてたんだろうなっていうような気がしますよね。
シャジの2番目にもトムデマルコって書いてありますもんね。
うんうん。
あとあれですよ、翻訳したのがデマルコオイに語ると同じ人。
そうそうそう。そこも繋がってくるのかみたいな気持ちになりながら読んでましたね。
まあ似た分野ですからね。
そうだなー。
確かにさっきの工学よりからもうちょっと人の要素みたいなところっていうのは、確かに過去読んできた本の時代背景的な捉え方、我々で言うとトムデマルコの構造分析、構造化の話の時とかにはちょっと工学的アプローチすぎるよねっていうところから、
みたいな捉え方をしたという意味では、確かにそうだなーっていうのは近所さんが聞いて今思いましたね。
なんか今吐かれてるものだけで説明しようとするとなんかピタッとこないぞーな時代なんですかね。
うん。
こういう雰囲気は感じるかもな。
結構やっぱり限界はあるんだろうけど、じゃあ逆に振り切らないみたいな感じはあるんだなみたいな、ちょっとずつ工学っていうところには多分寄り添いながら、どうにか軸足はそのまま残してるんだけど、ちょっと周りの方に染み出していこうみたいな、そんな感じはやっぱりありますよね。
そうですね。
あとあれかな、サイバネティクスっていう言葉が出てきたと思うんですけど、これもあんまり馴染みのある単語じゃないので、なんだろうなーと思って調べたんですが、
なんですかね、ウィキペディアによると、通信工学と生理工学を融合し、生理学、科学、システム工学、さらには人間機械の相互関係、コミュニケーションを統一的に扱うことを意図して作られ、発展した学問って書いてあるんで、
なんかここら辺からも人間味、生臭さみたいなところを取り込もうとしてるのかなーっていう印象が受けたりしましたね。しましたけど、シリーズの2巻以降読まないと、全然真逆やんけってなるかもしれないので、今のところは何とも言えないです。
あと多分サイバネティクスの文脈でいくと、多分結構いろんなものがそれで説明できるんだみたいな、連動なのかわかんないですけど、なんとなくあったんじゃないかって気がしていて、最初は通信工学の意味で、つまりよく我々の身近なものでいくと、
インターネットのパケットの話とかいうようなところで、よく出てくると言えば出てきたりするんですけど、なんかそのシステムみたいなものっていうものを見つけると、結局それって自然界にも応用できるんじゃないかとか、人間社会にも応用できるんじゃないかみたいな、
いうような話って、社会学でも見たことあるし、生物の世界でも見たことあるし、なんとなくそういう、何ですかね、見つけたものが同じようなロジックで周りも動いてるんじゃないかっていうのをこうやって当てはめてみて、それこそ今までわからなかった事象をどうにか理論づけて説明するみたいなところっていうのは、
なんか社会学者の宮台真嗣っていう人も、昔まさに社会学の中でサイバーネティックスの話を扱いながら社会を記述するみたいなことをやっていたよなとかって思ったりとかして、なんかこう、やっぱみんな同じようなことを考えてるんだなっていうのはちょっと思ったりもしました。
たしかにエントロピーとかどこ行っても聞くなみたいな、なんかありますよね、他の領域から概念というか単語を削除、輸入してきて説明つけるみたいな、行為自体に名前がついてましたよね、たしか。
なんだっけ、パッと出てこない。 パッと出ないけど。 まあまあまあそうですね、でも全体的なところで言うとそんなところですかね。 全体の感想なんか多くなってメモしてたっけ。
品質と価値の関係
そうですね、品質っていうのが主題にあるシリーズで、文化っていうものが大事そうだねっていうモチベーションで書いてそうな本だなっていうのを抑えておくとグッと読みやすくなるんじゃないかな的な感想ですね。
というか、わりと読みづらかった気はしてるので、なんだろうな、どういう読みにくさなの、なんか読みとかしにくかった気がするんですよね。 そうですね、そうですね。
なんか重要な、今話してるのはこういうことだな、ここが主題だなっていうのに目星をつけて、そんなに大事なところ、結論とか意見とか提起してないかっていうところはささっと飛ばすみたいな、ちょっと濃淡つけて読むっていうのを特に技術書だとやるんですけど、
なんかそれがあんまりしづらかったというか、一瞬で話が飛んだなみたいな感じに何回もなって、大変だった。 そうですね、どういう道のりで結論に行くのかが見えないから、どこが大事かっていうのをちょっと気抜かずに読まないといけないっていうのがしんどいですね。
楽に言うと密度が高い話なのかもしれないし、あとここは良かったなと思うのが各章ごとに要約っていうのがついてて、要約がちゃんと要約してる本珍しいっちゃ珍しい。要約のクオリティが高かったなっていう気がします。
なんか要約を読んで本部に戻って、要約を読んで本部に戻ってみたいなことを繰り返しながら読んでました、自分は。 そうですね、そうですね。だから一回目読む時からもまず最初に要約読んで頭に地図作ってから本書を読むみたいなのがもしかしたらいいのかもしれない。
2冊目からは僕はそうしようって思いました。
っていうところでじゃあちょっと本部入っていきますか。 本部前書はでもさっき振れたからいいっすよね。 そうですね。
本部入る前全体構成みたいなところがあるか。 確かに。 何部構成だ、ページ数としては300等ですね。
全部で5部立てでしたっけ。 そうです、5部立てですね。 5部ですね。
第1部は品質のパターンっていうところから入っていて、第2部が管理、アドミンの管理パターンと、第3部がパターンに圧力をかける要求ですね。
第4部が欠陥パターンで、ここでまたちょっと違ったパターンの話が導入されて、第5部が圧力パターンですね。
当たり前なんですけど、それぞれ繋がりを持って発展していってるみたいなところですけど、一番肝となる明大に近いところの品質っていう話から入っていって、第1部の品質のパターンですかね。
そうですね。 第1部の品質のパターンはどこから行けばいいかな、どうでした、ここら辺をまず導入してから入りましょうみたいなのがありますか。
そうですね。品質って何なのっていう話と、この品質のパターンの中ではソフトウェアサブカルチャーっていう話が出てくるんで、ここの2つ、品質とソフトウェアサブカルチャーを、この本全体としてもテーマの主軸になると思うんで、
そこを一旦押さえてから話を進めていきたいねっていうふうに思いますね。
そうですね。ソフトウェア文化とサブカルチャーっていうふうに書かれてて、なんでソフトウェアカルチャーにしなかったんだろうなって思ったんですけど。
うん、それは本当にそうですね。
まあその二軸って感じですよね、カルチャーとかサブカルチャー的なものと、それが何をやるんだっけって話として品質っていうのがあるよねって話をしたいと。
品質の話、品質って何ですかって聞かれたら、この本の立場としては品質は誰かにとっての価値だっていうのが言い切っちゃっていいんじゃないかな。
そうですね。ワインバーグが品質ってものを定義しようと試みた時に、彼は品質とは誰かにとっての価値であるっていうふうにこの本では定義してますね。
そう、でここの誰かっていうのがプレイスホルダーというかワイルドカードというか、結局誰にとってのなんだっけっていうところでめちゃくちゃ話変わってくるよね的な話もしててちょっと面白かったですね。
スケジュールを守れるのが品質が高いってことだとか、ユーザーが満足して高いお金を払ってくれることだとか、あとエラーがないことだとか、いろいろその文脈というか見方によって変わるよねっていう話がありますね。
なんか読んでて面白かったなと思ったのが、なんかゲームの計算ロジック間違えてるんだけど、別に気にならないから喜んでお金を払って、遊ぶ楽しむためには十分に遊べるゲームだから別にちょっと間違いがあったところで別にお金を払って遊べるから、
エラーを直したらさらにお金をプラスして払うかって言ったらこんなことないんだみたいな話があって、まあでもなんかそうだよねみたいなクラッシュしないっていうのは本当に起動して何もできないだったら金返せって思いますけど、
まあ普通に今の我々でも多分iOSアプリとかってこうとかAndroidアプリとかって使ってて、たまにクラッシュしたことあるけども、まあでもお金払って普通に使ってるしなって思うとなんかこの辺の話ってなんか遠い話かと思いきや全然最近もそうだなって思ったりとかちょっとしながら読んでましたね。
なんか若干話それるんですけど、なんかそのゲームの話出てくるところですげえいいなって思ったのがワインバグたぶんマジでそのゲーム好きなんですよね。なんか父と一緒に遊んだクリベッジがあるっていうところから書き出してて。
うん。なんか熱中してて。で、ハガキも要所?要所ってこれきってなのかな。わざわざね、ありがとうございますって楽しいですって送るような姿とか。で、たぶんやり込んでいった結果結構ニッチなバグを見つけたって話なんだろうなーみたいな気もするし。
ゲームにおける品質の実例
で、だからなんかそこがすごい重要かなっていう気はしてて。そもそもそんなニッチなバグ、欠陥ではあるけどそれに困ってる人っていうのがそもそも数が限られてる。それで困ってる本人もめちゃくちゃ困ってるかっていうともう十分に楽しませてもらってるみたいな。
だからじゃあこの欠陥を修正するのにお金払いますかっていうと払わないよねっていう雰囲気がありますよね。
だからこそ品質がいいっていうのはエラーがないとかそういうことじゃないんだよっていうことに繋がってくるわけですよね。
そうだからエラーが少ないとか正常に動作するっていうのはある側面誰かにとってのそれが重要視される価値と見なされる場合もあるかもしれないし。
っていうか一個でも欠陥があるならばお金払いませんとか契約違反ですみたいなね、世界も業界によってはあるでしょうから。
そういう話もあるし、いやいやそれよりもゲームがすごい楽しくていろんな思い出が作れることに価値があるよねっていう話かもしれないし。
でそういうすごい多面的なというかいろんな文脈いろんな立場によってその中身定義が変わってくるよねっていう話があるから
品質っていう話の後にその組織文化何を重要視するかっていう話が出てくるよね的な繋がりですかね。
そうですね。
品質品あって文化があってあれどこ行ったっけソフトウェアこれか13ページのあるやつか。
そうですね1.6がソフトウェア文化とサブカルチャーの話がちょうどここで出てくるという感じですね。
これはどの2つのソフトウェア組織も全く同じではないっていうのと同時に全く異なっているわけでもないみたいな話が出てますけど。
だからそれはそうだろうなっていう気はするんですけど、でもこれは結構なんですかね。
つまり全く同じことをして失敗しているとか全く同じことをして成功しているっていうわけではないってことですよね。
あっちではなんとなくうまくいってるしこっちでもなんとなくうまくいってるように同じやり方してうまくやってるように見えてるんだけど失敗しちゃったり。
結果が違うってこともあるだろうしそのプロセスの方が違うみたいなようなことがあちこちで起きてますっていうことでそれはそうなんだけどっていう気もするんですが。
だから全く同じやり方すれば私の組織でうまくいきますっていう話はありえないよねって言ってる一方である程度抽象化してここは共通してると言えるんじゃないかとか
これは部分的にでも適応できるんじゃないかとかっていう話が出てくるのでパターンっていう話がよくこの本で取り沙汰されているわけですね。
フォーキーズの指標と成功
いや全く違って共通点なんかないですよ、共有できるものなんかないですよっていう話であればパターンって繰り返し出てくるもの、再現性があるもののはずなので。
全く適応できませんだったらパターンっていうのがそもそも無価値になりますけどこの本はさっき言った通り五分立てでそれぞれのいろんなカテゴリーのパターンを説明していく本でもあるので。
共通してると言える部分がある共通性を見出せるっていうのも重要な話だからこそ文化について語る価値があるみたいなところかなという感じですかね。
これ読んでた時に、ここ読んでた時に、じゃあもうちょっと現代のソフトウェア開発とかソフトウェア開発組織に近づけて話をすると何になるんかなと思った時に、
何となく連想したのはリーンとデブオプスの価格の20いくつの指標みたいなのを見て、うまくいってる会社に共通するものはこういうものでしたみたいなことでフォーキーズが出てきたっていうのがあったと思うんですけど、
でも結局多分フォーキーズを満たしていれば良い組織になるっていうのは多分違うと思うんですよね。つまりフォーキーズだけ追いかけてそこの数値が良くなったら良いものができるかって言ったら多分そんなことはなくて、結果的にそのフォーキーズが大事だったっていうところはあるんだけども、それがあれば絶対どのソフトウェア組織も同じように成功するわけではない。
それは多分異なっていることが、とか前提条件が違うとか、それこそ文化や風土が違うってことによって色々左右されるものがあるんだろうなと思ってて、なんかその辺とかが現代風に近づけて言うと近いのかなみたいなのはちょっと思ったりしましたね。
そうですね。高速疎外ゴミ製造機にしかならない、そのフォーキーズだけ。
そうですね。いやーすごく不具合も起きないし、修正も早くパッと出せるんですけど、ほとんどお金は払われてない、使われてないとかいうことがあったら、それは結局意味ないですからね。
今期は障害ゼロです。なぜならリリースもしなかったから変更がないんですみたいな話があるかな。
でもそうですよね。リントン・デブオプスの科学も、カルチャーみたいなものが定量化しづらいというか、比較しづらい、一般化しづらい、成功モデルを組み立てづらいから、検索可能なケーパビリティの中の一部の側面を表すような代表的な指標ないかな、で4つに絞りました。
まあ、もはや4つじゃない話はありますけど、そういう話でしたもんね。
そうですね、そうですね。
