現代の要求定義とプロセス
15章、要求定義の原則とプロセスみたいなところを読んでて、なんかわかるようでわからないなーみたいな気持ちになったんですよね。
なんかここら辺が感覚違うんだろうなーっていうところの一つだなーって思いながら読んでました。
スパイラルとか言われても名前しか知らんからなー。 そうそうそう。
でもなんかもうちょっとこう、要求定義の原則とプロセスみたいなところの現代っぽくアップデートして読み換えたりすると、
じゃあ今ってその要求定義とか、そのためのプロセスみたいなところってどんなことやってんだっけ世の中はって考えると、
なんか Lean Startup ってやつが出てきて、こうMVPってやつを作りましょうみたいないう話が出てきたりとか、
あと、スクラムの中で取り上げられるようなところ、スクラムとかアジャイルの中で取り上げられるものでは、デュアルトラックアジャイルみたいなものがあって、
要求を小さく作って、それを見せてフィードバックもらってみたいなところに変わってきたんだろうなー。
しかもそれがもっと絵じゃなくて、ちゃんと動くものとして見せることができたりとか、ここでいう動くっていうのは本当に実装してある場合もあるし、
フィーグマンみたいなもののプロトタイプ、画面ポチポチクリックして遷移していくっていう意味でもあるんですけど、
なんかその辺に移り変わってきたんだろうなーっていう感じはありながら、過去がもうちょいどうだったか、何に苦労してたのかとかっていうところがちょっと読んでてなんかフワフワしてるなーって思ってましたね。
作り始めたら変更が効かないっていう世界をマジで体験してないですもんね。変更って言ってるのはその要求とか要件とか仕様とか、そこらへんが。
そこが明確にやっぱなるのは無理でしょうみたいないう前提で動いているような気がするな、今の我々はみたいな。我々ソフトウェアエンジニアの人たちは。
ちょっと前にバツってたやつでもツイートとかでも結局設計ってなんか正解ってよりもその後の変更可能性をどれぐらい残せるかがいい設計だみたいなことが回ってきて。
それって結局なんでそんなこと考えないといけないかっていうと、本当に欲しいものって誰も何もわかってないし、こういうことができるんだったらこういうふうにしたいかもみたいなことって、ある種発見的なものだったりするんで。
最初から知るっていうのは無理なことだからこそ、そういう可能性を残しておく、変更可能性があるっていうことがいい設計になっていくんだっていうところっていうのはすごくわかるし、ソフトウェアのいいところってそういう柔軟さがあるソフトな部分だと思うんで。
そこをすごくみんな意識して作ってるんだろうなっていうのを思ったりしてますね。
そうすると、リファクターとかリライトとかって結局そこら辺慣れてたりとか、強い人って結構糸持たやすくやってくれるよねっていう感じになると別に設計って別にそんなに価値のあるものじゃなくて、やっぱり腕が強いやつが一番強いみたいな世界もあるなっていう気もしますよね。
だってね、ジュニアが中心のチームですっていう時に自分が設計とかのリード任された場合と、少なくとも自分より強い人しかいないよねっていう中で中規模な機能の実装とか設計任された場合って、時点やるべきこと違うじゃないですか。
なんかここは別にガードレールしかなくてもあの人たちなら道に落ちないか、最後落ちても戻ってくるかみたいな可能性はあるんで。
それがね、あまり経験がない人たちと一緒にやっていこうぜってなると、ある種冗談が通じないというか、そこはそんなに真面目に真似しなくていいですみたいなところをディスタリオさんしてくるみたいな。
ところもあると思うので、やっぱり設計のトレードオフ、何を重視するかみたいな話はやっぱり誰が使うか。
使うって言ってるのはそのコードを読んで書き換える人。
要するにユーザーが誰なのかみたいな話に結局なってくるなっていう。
そうですね。
それがさっき言ってたAIに読みやすいコード大事ではね、かもしれないし。
そうですね、そうですね。
そこら辺でいい感じに話繋がりそうなとこあったな。
398ページらしい。
20章。小さく構築し、構築を加速するっていう章ですね。
そうです。で、小さく構築し、構築を加速するってこれ直感的にアグリーみたいな。
そうだよね、大事そうみたいな感じのフレーズかなと思うんですけど。
その20の1が小さくとはどんな意味かっていうふうに書いてあって。
で、ここの定義がなるほど、それはちょっと気持ちいい表現だなって思ったんですけど、それが398ですね。
ここまで小さくという意味をいくらか曖昧なままにしてきたが、ここでもっとはっきりさせようと。
私の言う規模とはシステムの知的規模のことであり、効果的に取り込むのに必要な知的作業の総量なのだ。
この規模はコード量とおおよそ相関するが、乗数が同じコードLとコードBでも、この意味の規模で大いに異なる点がたくさんある。
例えば尺量と尺量のコードとか、クラスが10個あるプログラム2つとか比較した場合でも、そこに対してどのくらいのコストとか負荷で取り組めるかって考えた時に、
コードの読みやすさとかドキュメントがしっかり気持ちよく整備されてるかとかで全然変わってくるよねっていうところまで織り込んで、
知的規模がちっちゃくあるべきっていうふうなことが書いてあって、
なるほど、知の方がいいな、認知負荷が低いみたいな話になっちゃうのかもしれないですけど、
なんかこれはいいなーって思いましたね。
いいっすねー。
小さく構築するアプローチ
短い方がいいでしょって言って、ifじゃなくて参考絵の雑誌で書きますねみたいな話とか。
参考絵の雑誌ぐらいならいいんですけどね、参考絵の雑誌をネストするんじゃありませんっていうのは。
テストコードを短くしましたって言って、データプロバイダーでifばっかじゃんみたいな。
パラメタライズいるのかみたいな。
送料として短くなることと、実際にやっぱりわかりやすいかどうかっていうのはまた全然違うことだし、
長くなっても、例えばちゃんとコメントが書かれていて、ここってどういうことだろうっていうことに対してちゃんと補ってある、
一個のドキュメンテーションだと思いますけど、いうのでもまた変わってきますからね。
そうなんですよ、読みやすいコードを100行読むのと読みづらいコードを5行読むのだと絶対にかかる時間違うんで。
うん、絶対違う。
読みづらいコード5行とかね、本当に半日でも1日でも解かせるんで。
一回気分転換しないと無理みたいな気持ちになって、違うことやってもう一回戻ってくるんだけど、やっぱわかんねえなみたいな。
いやわかる。ちょっとまずシャワー浴びてからちょっと断定をするかって思ったら、戻る気が戻ってこないみたいな。
これの話を見て思ったけど、多分文章とかもそうですよね。
ドキュメントでも同じ文字数とか同じぐらいの小立てになっているドキュメントでも、やっぱレベル感がちゃんとあっているような見出しがついていると、
なるほどこういう流れねってなるし、なんか抽象度バラバラなレベル感だねってなると、見出しだけ見てもあれ?ここは格論の話してるし、こっちは全体話してるし、あれ?どういうこと?ってなると、
結局なんか読むのすげえ疲れた。なんか違和感だよなーみたいな。最初なんか違和感だよなーって言いながら読んでいって、結局なんだったんだっけ?みたいなことが起きたりするんで。
そうですね。これプログラムなら強盗で使ってるようなもんだよなーみたいな。レベルがバラバラっていうと。
そうそうそう。
NESTっていう概念が実はないんですみたいな。
いいですね。あとこの小さく構築し、構築を加速するっていうところ、自分も結構すごくコメント書いてたなーと思ったけど、やっぱりこの辺は結構現代においてゲームが変わったところでもあるよなーと思ってて。
出荷する回数が圧倒的に増えたので、小さくっていうものの単位をどんどんどんどん小さくできて、すぐにそれを市場に出すとかっていうことができるようになったから、
多分ここで言ってる小さく構築しっていうのが、加速する部分がもっともっと加速したんだろうなっていうのを勝手に思ったりもしてましたね。
うんうんうん。
なんか単体テスト運営みたいな話もこの章じゃないかもしれないんですけど、どっかにありましたよね。なんかそこら辺もCICD周りとかですごい、ちょっと見えてる景色違うんだろうなーっていう気がしたりとか。
そうですね。12章のプロセス原則の中で全ての段階でテストするみたいな安定性の原則のところで、なんか話があって、あ、これってなんかテスティングマニフェストってやつで、最後にテストよりもずっとテストし続けるみたいな話にちょっと近いのかなーみたいなこと思ったりとかしてて、
やっぱり、なんかこうやりたかったけどできなかったことがだんだん現代にお手できるようになってきたんじゃないかなーみたいなことを、やっぱそう思う部分はありましたね。
そうですね。なんかだから、今でも通用するようなことを表現言い回し文章がたくさん書かれてるっていう意味では、やっぱりめちゃくちゃいい本なんでしょうね、これ。
ただまあ、今の人が読むとちょっとピント来ないかもっていうところはあるんですけどね。そこを覗くと、はい。
あと、この間だけいきなり読むと、違うよって言われるんで。
読んだら、あともう40冊あるぞ、みたいなこと言われる。
第4章、第4章じゃない、さっきの20章の小さく構築し、構築を加速する理由と、要件をちっちゃくしましょうとかね、一緒に書いてあるなーとか。
めっちゃわかる。簡単だからってね、ちょっと要件を増やしたらすぐ複雑になるんですから。
いや、そうなんですよ。
これ多分今後起きると思うんですけど、それAIで書いたらすぐできるって言って、要件増やしてAIが書いてレビューしてリリースするってなって、手前で不具合見つかった、ちょっと直しますねって言って、
言うのを繰り返していったら、結局気づいたら、もっとすんなりリリースできたはずなのに、AIがあるにも関わらず遅くなってね、みたいなこととか、結構起きそうな気がするんだよな。
AIが上手に使えるかどうかってよりは、いかに小さく作ってパッと出してしまうかみたいなところの力量みたいなところは結構問われるんじゃないかなっていう気がしますね。
そこの原則は変わらない気はしますよね。
まあ、デビューが大変で人間がボトルネックになっていくみたいな話はまた別として必ずあるだろうなとは思うんですけど。
それこそ継続的デリバリー的な、1日1回デプロイしますじゃなくて、もう30分前に書いたコードは本番にやりますみたいな世界観だったりとか。
小さなチームの利点
そうですね。いっぱい作れるようになることと、いっぱい上手に作ることはちょっと違う気がするんだよなっていうのは思ってますね。
なので小さくするってことが結構より大事になるんじゃないかなみたいな。
やっぱり人間も消費特訓数が来ると大変なんで。
そうですね。そして要件を満たしてなければ何でも作れますよっていう話がまさにAIじゃなくてみたいな気がするので。
確かに。そうするとテストを消したので全部取るようになります。
そうなんだよな。結構この小さく構築して構築を加速するは、その概念的なところのレベルはやっぱり変わってなくて、今後よりもっと効いてくる気はしてきたな。
この章の中で有用なヒントと提言の412ページ読んじゃいますけど、組織が小さい時、またコミュニケーションを育む信頼がある時、小さく早く構築することが容易になる。資金もまた高くなる。
っていうようなことが書いてあって。これはもう本当にどの本でも、デッドラインでも言ってたし、組織パターンでも言ってたし、みんな言ってるなみたいな。
結局コミュニケーションパスが増えるっていうことが、とても大変なことなんだなって気もするし。
やっぱり最長小さいチームいいんですよね。小回りが効く。構成メンバーにもよるみたいな話ももちろんあるかもしれないですけど、小さいチームに向いてる人が構成要員となっている小さいチームはとてもいいですね。
そうなんですよ。5人ぐらいのチームがちょうどいいんじゃないかなってずっと最近思ってますね。
その5人はどこまでですか。CEOとか。
機能開発チームで、プロダクトオーナー、デザイナー、エンジニア、エンジニア、QAみたいな。そんな箇所バランス感覚のチームいいなっていうのは最近思ってますね。
そうですね。そうなってくるとエンジニアフルサイクルよりの方がいいなみたいな。
そうそうそう。そうなんです。それを組織としてスケールするためにどうしたらいいかみたいなところとかを考えるとまた難しいなって。
別にそのチームがコピーしてもう1チーム、2チーム、3チームってそんな簡単にできるもちろんわけではないかったりするんで。
いやーむずいなって気持ちになったり。フルサイクル志向な人がたくさんいればいいけどそうじゃない場合においてじゃあどうしましょうかねとか。
そうですね。
AIの登場によって少ない人数で加速するぞっていう方向性にはいくんじゃないかなって一応予見はしてますね自分は。
まあ人員整理みたいな話も出てきてますもんね。
そうそう。
いやというかマルチタスクができるようになってるのが強いなっていう気はしていて。
同時に3つの実装を難しいとこだけ人間がやって、ディテールとか切り終わったらもうGitのワークツリーとかでバーってやって、ローカルのCPUを持つ限りはいくらでもスケールしますみたいなことができちゃうので。
それだけはどうしてもできなかったじゃないですか。キーボード1個だけだから入力は。
入力ソースはキーボードつなげればいいんですけど。
まあまあでも。
そういう話じゃないんで。
片手で1個ずつ打つっていうことが限界ですからね言うても。
そうですね目線で入力して指で入力して足で入力して音声で入力してみたいなことをさばけるマルチプロセッサーな脳みそを持ってる人だったらできるかもしれないんですけど。
でもそれよりは明らかにエージェントの方が安いですからね。エージェントさんが安いしスケールするし。
それは本当に1人からエンパワーメントしたというかスケールアップするなっていうスケールアウトに近いなっていうのは前なんかと思ったりしたんですけど。
そうですね。自分のコピーを並列化とさせてるって感じに近いし一方でアイディアを形にするという意味ではなんというかスケールアップでもあるっちゃあるんだろうなって気もしますよね。
なんかコード書けない人がこういうものを作りたいんだけどって言った時にAIの使い方がすごい上手になっていくとアイディアを形に今までできなかったことができるって考えるとスケールアップっぽさもあるんだよなっていう気がしますね。
そうですねなんか音楽理論学んだことないけどボカロのおかげでめっちゃ刺さるとこ作れますみたいなのとか。
そうそうそう。
近いことが起こるかもしれないです。
あとはちょっと関連して思ってるのはなんかそれでたぶん生産性が上がるっていう話に行くと思うんですけど。
なんかその時の生産性アップの秘訣っていうかなんか実はAIによってアップしたっていう話もあるんだけどコミュニケーションコストの方が実は結構効いてるんじゃないかっていうことは自分は仮説を立てていて。
だからAIを導入すればなんか生産性が上がるんやって言って蓋を開けてみたらなんかあんまり1.1倍ぐらいにはあったけどてんてんてんみたいなことはなんかいっぱいこれから起きるんじゃないかなってちょっと思っていて。
だからチームが小さくなってコミュニケーションコストが下がってそこのコストが下がった上で一人ができる範囲が広がってかける行動の量が増えていってみたいところで生産性が上がるんじゃないかなっていうなんとなくの仮説を持ってますね。
コミュニケーションで言うとまあわざわざ先輩に聞いたり同じことを質問するのはいかがなものだろうかっていう遠慮みたいなものが結構軽減されるというか遠慮気のおけない遠慮が必要ない相手がターミナルにはいるねみたいな話になってくるんで。
あとはなんかやっぱみんなで決めましょうみたいなこうチームの状態とかいうのが多分10人のチームと5人のチームじゃそのやりやすさ全然違うでしょみたいなことは多分あるはずでじゃあその1時間のミーティングを10人でやったらまあ10時間分かかっててその間にAIが動かせたらもっと早くできたのにみたいな。
AIの導入と効率化
それが5人とか3人とかチームが人数が小さくなっていけばきっともっとそういうところも早く決まって前に進んでいくんじゃないかなーってちょっと思ったりしてますね。
それで言うと結構3人と5人にも壁あるなーっていう気はしてて。3人ぐらいだったらスラックでなんとなくその場でバーって話してても目に入ってくるんですけど、5人とかだとその話どこでしてましたっけが発生しやすくなりそうな気はしてて。
めちゃくちゃちゃんとスラック端から端まで追いましょうっていう文化が確立されて、それにコミットできてる人が集まればまあ5人ぐらいでもいけると思うんですけど、なんか嫌じゃないですか知らない場で決まってるみたいな。
っていうのが置きづらい人数っていうと、ちょっとねピザ2枚じゃ多すぎるなーみたいな気もするので。
いやわかります。なんか5プラ枚2じゃんっていう話ってなんか適切なサイズの時にマジックナンバーみたいなとこで言われたりするのも昔あったけど、やっぱ7多い気がすんだよなーって気持ちになっちゃいますね。
3とかでいけるとめっちゃいいけど、ちょっと手が足りないとか、作ってるものによると思うんですけど、こうなったらまあ5ぐらいかなーみたいな。
そうですね、いややっぱり元バスケ部としては3と5は全然違いますからね。
オフボールの動きが変わってくるんで。
3on3と。
いやー5人5人はすんごい難しくなる、複雑になるなーと。
そうなんですよね。結局やっぱ人数の規模もそうだし、プロダクトの性質というかプロダクトの規模もそうだし、そういうところがでかくなればなるほどゲームが難しくなる、複雑化する。
ソフトウェアなんかは複雑さが目に見えないから目に見えるようにしようねっていう話がこの本の中でも度々出てきてたけども、やっぱそこをどうやって小さく切り分けられるかみたいなところが今後もどんどんどんどん必要になっていくんだろうなーっていうのがなんか思いましたね。
そうですねそうですね。
そう考えるとまあコンピューターってそういうもんだしなーみたいな問題を小さく分割して処理させられるように扱えるようにしてあげるっていうことでもあるから。
いやーこれは面白いな。どうやってそれに立ち向かっていくのか。たぶん放置してたら膨張していくので、それをどうやったら防げるのかみたいなすごい面白いなって思いますね。
いやー本当に3年後、まあ3年後はまだ12クビになるとかは、ディストラとかは会社が潰れるとかなければまあないかなっていう気はするんですけど、5年後とかはマジでわかんないっすね。
わかんないっすね。
何してっかなーみたいな。
なんかもっと違うものが盛り上がってソフトウェアの業界自体がこう、あんまり人気がどんどん陰っていってるとか。
そうするとカンファレンス毎月やらなくなっちゃうんですか。
ちょっと5年後毎月やってるかマジでわかんないね。
毎月カンファレンスやってる界隈が増えてるかもしれないですし。
そうですね。いやーそっちもありえるからな。カンファレンスの数自体は絶対増えてるからな。
なんか情報爆発じゃないですけど、何ですかね。やっていいんだ的な雰囲気が出てきているのでは。
結構本の話から脱線しましたけど。
あとはどうすかね。
プロジェクト成功の秘訣
あとはなんか章全体っていうよりかこのフレーズが、なるほど面白いなーって思ったのがあって。
331ページなんですよね。章でいうと17章のプロジェクトを正しく開始するみたいな話で。
17章っていう章としては、本当にプロジェクトの始め方なので。
立ち上げる時にそもそも何を要素として揃えておくべきかとか、始め方始まり方としてどうあるべきか的な話がされてるんですけど。
その中でもステークホルダーとか諸々関係者との交渉みたいな話も触れられていて。
17-1-3ですね。丸く納めるウインウインな交渉みたいなところがあって。
プロジェクトが成功するには初期交渉が適合的な合意、つまり事故、他者、そして状況を均衡させる合意を形成しなければならないって書いてあって。
3巻で出てきた事故、他者、状況っていう枠組みがここでも出てきたかというところでちょっと面白いなって思った次第ですね。
事故、他者、状況って後ろのフロックの方にも書いてあったような気もするし。
他にもどっかで言及があって、やっぱなんかこれ結構ワインバグ大事にすごくしてるなっていうのを思いましたね。
関係性とか目的を持って合意してるシステムっていうところのすごい基礎的な要素分解なんだろうなっていう気が個人的にはしてますね。
ここに立脚しながら説明するみたいな感じは、フロックのEが3つの観察状の立場ってなってて、事故、他者、状況の解説が書いてあります。
なんかシリーズ全部読んでくるとフロックEですね。フロック役に立つな。
そう。あとフロックがどんどん増えていくっていうね。
相手の立場を考える難しさ
最初Cぐらいまででしたね確か。今Fですね。
めちゃくちゃあるから。
3歩よしじゃないですけど、例えば自分が今からこういう提案しようとしてるんだけどって思った時にちょっと耐性してみて、
どの立場、誰に向けてのメリットだったり合理性を提供できてるだろうかっていうのを考える時に事故、他者、状況っていうのを引き出しから出して並べてみて、
全員生きるかなー的なことをやると、何ですかね、筋が通りやすくなるのかなみたいな。
自分の要求だけつきつきでも、なんでそれ叶えないといけんのって言われて終わっちゃいますからね。
逆に他の人のためにも上等のためにも良いからやるべきだって話になっても、多分自分自身が納得してない、満足できないってことは他にも満足できない人いそうだなっていう感じもしちゃいますし。
相手の立場に立って考えるって難しいですからね。
そうなんですよね。
経験したことない立場に立って帽子をかぶり直すみたいな言い方をするけど、それっていろんな人と触れてるからそういう考え方ができるっていうのもあったりするから、なかなか難しいですね。
かといってね、その立場を俺も経験したことがあるからわかるぜって言うと、重大な勘違いになったりするので。
そうですね。なので周りをよく見て話を聞いて、うまい落とし所を合意形成をしないといけない。
プログラムと製品の相違
なんかそのフレーズがちょっと大手だったっていう感じでした。
フレーズつながりでいくと自分も1個あって、中二症、なんかすごい中二症に定期的に戻ってくる。
なんで最初飛ばしたんやっていうね。話したかったんじゃんっていう。
中二症で、これはプロセス原則っていう症で、製品原則みたいな項目があって。
僕も付箋貼ってあるな、そのページ。
で、ソフトウェア工学第0法則っていうのがたびたび研究してる。要件を満たす必要がなければ管理は問題にもならない。
これ前の3巻目でも確かあったりしましたけど。
そういうような紹介がされてる文脈の中で、もう1個研究されてるフレーズがあって。
製品はプログラムかもしれないが、プログラムは製品でないっていう話をしていて。
これ良いですよね。
いいですね。
あんまり汚い、あんまり上手にうまくいってない行動を褒めるとか、そういうことではないんだけども。
お客さんは結局何にお金を払ってるんだっけって言ったら、製品に対して払ってるから、あなたがすごく上手に綺麗に行動を書いたかどうかっていうのは、その観点で見るとあんまり関係ないんだよっていうような話をしたことがあって。
だからずっと行動を綺麗に書こう、綺麗に書こうって悩みながら、すごい時間をかけて書いてもいいけど、お客さんは別に綺麗な行動を求めてるわけじゃないんだよみたいなことを言ったこともあって、このフレーズすごい好きだなって思いました。
やっぱり世界一感動できるソフトウェアはフォトショップであるみたいな話がありましたからね。
プログラムは動けばいいでしょって汚い状態で書かれるとテストもないですって言われると、それはそれでちょっと困るんで、今後のことを考えた時には保守性も考えて書こうねっていう風になっちゃったりするんですけどね。
そのフレーズの関連で言うと、有用なヒントと提言、240ページにある1つ目のあれも結構好きだなと思ってて、この章の原理にソフトウェアプロセスが従うと全てのソフトウェア作業は保守作業、
すなわち製品の処分の振る舞いと認知された振る舞いの差異を少なくする作業と見なせるっていう風に書いてあって、ソフトウェア作業、要するに新規機能追加みたいなのも含めてだと思うんですけど、
期待されてる、求められてる要求っていうのに対して追従させるのが開発で、実装で、的な世界観にも見えたし、保守作業っていうのを製品の処分の振る舞い、製品、このプロダクトはこういうことができるはずだよねっていう期待と実際にどう動いてるのっていうところの差異を少なくする作業的な見方をしてるのも、
なるほど、確かにって思って。
品質と文化の課題
確かにそう考えると、開発と保守の間に大きな状態区分を設ける理由も、両者に対して根本的に異なるプロセスを持つ必要も全くないっていうのは、すごくソフトウェアって全身的に成長していくもんだよねっていうような前提に立つと確かになりますね。
でもちょっと好きなんですよ。
こういう前提に立っているかどうかで結構ソフトウェアに対する価値観変わるなーって気がして、別にアップデートされなくていいんだよっていう人もいるし、コロコロ変わるのが嫌だよねとかいうのもあったりするし。
なんかね、それこそさっき言った設計って変えやすさのことだよねっていうのをここに繋がり出す。今変えて今日コミットしたコードはいつか書き換えられることが前提だとしたらどういうコードのほうがいいのかなみたいなのとか。
だからこそ振る舞いの差異を少なくするときに何が変わって何が変わらないのかみたいなところをすごく見極める必要があるんでしょうね。
そうですね。
だいたいそれはデータベースに状態として持たれるんで、データベースの設計頑張った方がいいぞみたいなことと繋がってたりするんだよな。
なんかこう見るとやっぱ結構現代のソフトウェア開発ってやっぱ変わってないっていうか、注意すべきところは変わってないぞみたいなところっていうのはいっぱいありますね。
そうですね。本質的な部分って言い方してもいいのかもしれないですけど。
もうちょいやりやすくなる可能性は全然あるなっていう気がする。それこそ出荷した後に2、3分で修正が早いできますとかはやりやすくしてくれた要因だろうし。
うん。
そんなもんですか。他に触れておきたいところあります?第4部。
そうですね。自分は割と結構喋ったなっていう気がするので大丈夫かな。
337ページのイラストだけちょっとちらっと見ておいても面白いかなと。
33ページ。これはあれですね。電話を4つ持ってますね。
4つ持ってると言えないのかな。
僕大使じゃないと4つ同時に聞くことはできない。答えられないからな。
というか肩、首のところで受話器挟んでっていうのを右と左に1つずつ計2つやってて、で右手左手で受話器持ってるように見えるんですけど、手に受話器持っても耳塞がってるじゃんみたいな気もするし、面白いですね。
そうですね。
本当にこのイラストが必要だったのだろうか。
これは1人で4つの仕事をしてると言えるイラストなんだろうかみたいな気持ちになってくるな。
何ですかねこの人。何かを訴えてるぐらいにしか。
なんかモノボケかなみたいな。
第5章はエピローグなんで2ページぐらいあるけど。
エピローグなんかテストなんですよね。
そう。突然テストを受けさせられるっていう。
この本を読んで本当にシステム変革法って書いてある本なんで、予知のパターンに向けて組織の中であなたはアクションしていきましょう。
そのセルチェックリストみたいな1問5点の問いがいくつかある。
あ、違うか。問い1が。
合計3になってて、問い2が正直に答えられる25点、答えられない場合は無得点とするっていう話があったりとか。
あとは20点ずつ問いがあって、それに過去1ヶ月間どうだったかみたいなことを答えてみましょうってなってますね。
あと追加のおまけ問題もありますね。はいと答えるごとに10得点とする。
A、憎しみを小さくしたか。B、愛を大きくしたか。
前回の本でもね、愛と憎しみの話もありましたし。
ありましたね。不適合のやつで。
セルチェック確かにするには面白そう。面白そうではあるけど。
セルチェックして誰かとそれを喋れるといいんだろうな。
そうですね。
まあでもそんなところかな。どうでした?この間もそうだしシリーズ全体読んでみて。
そうですね。シリーズ全体読んでみてソフトウェア文化を作るっていうことがやっぱ難しいことなんだなっていうことをすごく思いながらも、
やってることは実際その中でいろいろ提言されていることとか、
キーとなるコンセプトみたいなものは知らなかったものはいっぱいあったけども、
実際蓋を開けて意識してやってることとかもいっぱいあるんだなっていうのはやっぱり全体通しては思いましたね。
そうですね。わかるっていうと、なるほどっていう部分と、ちょっと疑問風が頭に浮かぶような部分と、
なんかそれぞれかなりあったかなっていう気は出ますけど、まあ咀嚼に結構エネルギーがいりますねこのシリーズは。
あんまり一周で満足するっていうか多分繰り返し繰り返し読んでいくのかなみたいな。
で、まあそうですね、どうしても古びちゃってるなみたいなところもあるにはありますけど、
まあでもそれは別に2週目3週目読むときはそんなに力入れないで、ページパラパラめくる程度で付き合えばいいかなっていう気もするので。
でもそうですね、げんさんの今の感想を聞いてて思ったのが、文化を作るとか文化を変革していくっていうのはそもそもが難しい話だし、
どういう風な姿でありたいんだっけって描くところからして難しいんだよなっていうのを思ったのと合わせて、
そもそも品質みたいなイメージをしっかり複数人に共有していくところから、なかなか難しいんじゃないっけっていうのはちょっと思ったので、
まあでももちろんちゃんとしたというか、一般的で専門的な定義もあると思うんですけど品質に関しては。
このシリーズの第1巻でちゃんと触れられてもいたんで、それを読んだら文字として理解することは全然絶やすいんですけど、
なんだ、心で品質を理解する、結構それだけでも大変そうみたいな。
要するに自分たちが作ってるものをちゃんと理解しないと品質が高い低いってそもそも言えないじゃん。
さっきの情報障害の話でもありましたけど、今我々が作ってるものって、実装してるもの、今手を動かして手を書いてるコードが何を意味するか分かるんですけど、
じゃあそのコードがあることによって我々の作ろうとしてプロダクトだったり、そのサービスのユーザーの世界がどう変わるのか変わってほしいのかっていうところを真に理解するのは、
やっぱり一筋の技いかないしってなった時に品質が高いってなんだみたいな、分かるわけない気もするので、
品質っていう難しさと文化っていうものを扱う難しさと、あとはもちろん組織とか他人っていうのも出てきますし、
そういういろいろ難しいところにワインバーグすごい足突っ込んでてすごいなーって、ワインバーグすごいなーっていう感想です。
一人で一人で書いてるのはね、これを。もちろんレビュアーがいたりとか協力者がいるってのはもちろんあるけども、
ワインバーグのシステム変革法
一人でソフトウェアを作るってこういうことなんだなっていうことを文章にしてまとめて出すぞ、3冊頑張って書くぞって言った結果4冊書いたんですけど、4冊書いたんだなっていうのはすごいですね。
なんかでもどの巻もそれぞれ、なんていうんだろ、なかなかカラーが違う本だなーっていう気がしましたけど、4巻はその中でも異質な感じやっぱりします。
かなり抽象度が高いんじゃないかな。
4巻目って抽象度が高いのに後ろの方はすごい具体な話もあり。
だから全体を語るっていうよりかは、キーとなるコンセプト固めた上で後は運転をバンバン回っていくみたいな。
粒を揃えるみたいな戦い方をしてますよね。
そうですね。これを人に読んでって進めるのはちょっと、4冊読んではちょっと大変なので圧縮版が欲しくなるなみたいな気持ちもあるし。
え、でも44冊なんで。
なんかこのエッセンスを現代に置き換えている。これだからよりこっちを読むといいんじゃないみたいな提案まで揃えられると、
なんか結構もうちょっと、やっぱり現代で読むべき本はこれだよねみたいな話がやりやすくなるかもしれないなーっていうのはちょっと思いましたね。
そうですね。ワインバーグの他の本とかでもしかしたらある程度になれるのかもしれないなと思いつつ。
でもいや1巻2巻は好きな人を刺さる人多いんじゃないかなっていう気もするな。
うん。1巻はすごく引用されているのもよく見るから、読まれてるんだろうなーっていう感じはありますね。
いやーでもこれ絶対に誰か巻き込んでなかったら。
2週間、ちょっとスケジュール変えましたけど、2週間で1冊掛け読んだから1.5ヶ月ぐらいかで読んでる。
そうですね。1.5から2ヶ月ぐらいで読んでますね。絶対途中でもういいかなってなりますね。
なりますね。
まあそういう意味でも、読めてよかったはマジで読めてよかったと思うんで、いい読書はできた気はしますねってなところですか。
はい。
何か言い残したことありますか?
言い残したことはもうないです。
はい。なんだかんだ3時間ぐらい経ってるな。
そうですね。結構喋ってますね。
まあまあ500ページあるから。
そうね。しょうがない。
よし。じゃあ終わりにしますか。
はい。
TKM読むか。
今週も放送をお聞きいただきありがとうございます。ではまた次回。さよなら。
さよなら。
