変革へのアプローチ
で、第4部が長いし骨が折れると。
そう。
で、冒頭で触れた通り、結構具体寄りの話なので、そうすると何が起こるかっていうと、結構取り留めもないっちゃ取り留めもないんですよね。
うーん。
だから好き勝手、気に入った部分、気になった部分をピックアップしていく形で、なんか全体をパッケージとして説明する、投入するっていうのは、ちょっと諦めようかなって思ってます。
そうですね。
なので、第4部の、なんだっけ、どんな変革を起こすべきかに入っていきますけど、どこら辺が好きですか?
そうですね。
あーでもそうそう、今と変わってるなーっていう部分と、これはどういうことだ、時代的な違いかって強く感じる部分とかが入り混ざってますね。
そうなんですよ。どこがいいかな。一番すごいわかりやすいなーって思ったところは、もう一番最後なんですけどいきなり、23の技術を導入するってやつで、
この技術を導入するって言ってるのは、新しいテクノロジーみたいなものをチームの中にインストールしていきましょうっていう話ではあるんだけども、導入したとってみんな上手に使いこなせてんの?みたいな話が出てきたりとかして、
ちゃんとその道具の使い方をみんな勉強して、その有用さみたいなところを感じて、ちゃんと使うようにしようねっていうような話が書いてあります。
これって多分、今でもマジで変わってないなーって気がしていて、新しいツールが出るたびに、世の中のトレンドはノーションが出てきたら、ノーションってやつがいいらしいぞ、コンフルは古い、もうノーションだみたいな言って、
ノーションを使うぞとかって旗振りをするんだけども、実際蓋を開けると、そもそもコンフルの時ドキュメント書いてなかった人がノーションに変わったら書くんか?みたいな話があったりとかして、こんなに便利な世の中になっているが、実際は変わってないんだなーみたいな気持ちになりましたね。
情報障害の理解
うん、確かになー。技術定義の実解の話がありますもんね。ていうかすごいなー。そっか、今、セレット23章最後の、いきなり最後ですけどって言ったけど、まさか250ページスキップされると思ってなかった。びっくりした。
読んでて、これ読みながら、この話の中でもツールをやたら増やしてしまうみたいなのがあったりとかして、上手く使えないみたいな話があって、結構ここ、なんか自分はすごい意識していて、ツールをあっちの道具がいいなーみたいなことって思うことすごくあるんですけど、
流行ってるからこっち使ってみたいなーとかって気持ちあるんだけども、個人でそれを使うことと組織で使うことっていうのはやっぱりすごく明確に分けていて、道具を一個増やすたびに管理コストがめちゃくちゃ上がるっていうようなことはすごく思っているので、
極力道具を増やしたくないなって思うことがあって、そのせいである種人からこれ使いたいんだけどって言われた時に、脳をどうしても威張らざるを得ないことがあったりとかして、ちょっと心苦しいなっていう気持ちもあったりとかして、ここの章はものすごい共感することがいっぱい書いてあったんですよね。
なるほどなー、一週間に何のか働くべからずとか書いてありますもんね。
書いてありますね、はい。
これそっか、僕結構あんまりこの章はちょっと軽く流しながら読んだ感じがあったけど、それ面白いなーと思ったのはその、どういうくらいだっけ、ツールをどうやって付き合っていくかみたいな話で、
パターンごとの違いみたいな、パターンゼロの組織文化、サブカルチャーだとこういう反応をしますとか、可変だとこうです、慣習パターン2だとこうです、舵取りだとこうです、予知だとこうですみたいな話が、
まあそのツールを入れましょう、もしくは書き方決めましょうみたいな、ひきんな例で各パターンの反応とか態度の違いっていうことが語られているので、なんかイメージ分けやすいなーって思いながら読んでましたね。
ここはまさに23-2の表図の部分で、活用とか社会化方法、社会化どうやって広めていくかっていうところとかってなんか組織がでかくなればなるほどやっぱ難しくなっていくし、どうやったらうまくいくのかなーみたいなのとかは
あんまり、ここに書いてあることはイメージ浮かぶけど、実際それを現場でうまくできるかって言われると、結構大変そうだなーみたいな予知とかになると。
変革アーティストによる明治的活動を奨励する管理層による社会化方法って書いてありますね。わかるかーっつって。
今だとAI流行ってるし、使っていきましょうってなった時に、別に仕事できてるし困ってないよなーみたいな人と、これ便利なんだからもっと使っていってみんなの生産性上げようみたいになっている人と、
2局かではないけど2パターンとかあった中でどうやってそれを広めていくかとか、広めた結果ちゃんと生産性上がってるよねみたいなことを評価するかとかいうのって結構やっぱ大変だよなーって思ったりしてますね。
いやしかもね、コパイロット入れましょうって言って、なんか翌月ぐらいにはお前先月はそう言ってたのにグロード入れましょうとか言ってるじゃんみたいな世界になってたりするんで、すごい難しいなって思いますねさらに。
いや難しいですよね。それこそね、ビューにするかニクストにするかみたいな話とかもそうだろうし、アンプにするかスウォールにするかフランケンにするかみたいな話もあるかもしれないし。
なんかアンプできるものは試してみて、ダメだったらやめましょうって全然いいんですけどね。
そうなんですよね。これなんか新しいやつを入れるときは何か1個捨てましょうみたいなこと書かれてたのここでしたっけ?
あーどうだったっけな。
なんかどっかに書いてあった気がするんだよな。
自分はそこはもしかしたらあまりピントをきてないというか、入れないっていう方向を頑張ってた人だから、昔。
でもそうですよね。でも基本的にそれの代替となるものがより良さそうだから入れるってなった時に古いものを減らしたいっすよね。
うーん。難しいですよね。移行計画みたいな話になってくるからな。
ドキュメントはどうするんですか。捨てますかみたいな。捨てていいぐらいのことしか書いてなかったら、じゃあリセットでっていいんですけど。
そうではないですからね。
ドキュメンテーションとコミュニケーション系のツールは本当に厄介ですよね。
ギットのログとかもそうだし、GitHubの一周とかもそうなんですけど、会社が分かれたりとかして、GitHub Enterpriseから移動しないといけないとかってなると、
一周のリンクがついてるけど全部無効になっちゃったりとか、飛んでも何も見れなかったりとか。
スラックのワークスペース分かれた時結構あったな。
あとGitLogで最後たどってたらサブバージョンから移行にたどり着いた時の絶望感とか、なかなか道具のチョイスって難しいなっていう気持ちになりましたね。
あとそうですよね。最初のGitに移行したての歴史まで掘り当てちゃって、コミットが全部なぜかルートになってるみたいな。ここで歴史が途絶えたかみたいな。
なので今後必要な情報、必要ってか自分たちが保持できる情報は全部当たったので、ここから先はもう自分たちで頑張って意思決定するしかないですねっていう。
まあある種諦めみたいなところがついたりとかしていっちゃうんですけど。
まあ確かに。
導入したけど使わなくなったツールとかもたぶんいっぱいあるだろうしな。スラックの通知とかでなんでこれ飛んできてるんだっけって誰も見てないんですよねみたいなのとか。
あったりとか。流行ってるから入れたいって気持ちはわかるものの管理コストは高いんだよな。
そして入れたいって言った人はだいたい見なくなっているみたいな世界があったりとかもして。
嘘ですよね。
なかなか難しいなっていうので、逆に新しいツールを入れる時の上手な入れ方、導入の仕方みたいなところも気になりつつ。
このところはすごく自分は気に、読んでて最後の最後にこの話が来るのかっていうことを思ったっていう。ここですごい面白かったなっていうところですね。
なんだっけな、なんか面白そうって思った章があったんだよな。大当たりテストの話?
十二章。
イラストが面白いだけか。
十二章のとこですね。
イラストちょいちょい面白いノリはまだ継続されてますね。
されてますね。なんならこのイラストのとこに俺は付箋を貼ってますね。
どこだっけな。11-5らしい。情報障害のところか。情報障害っていう言葉が出てきて、これどういう文脈で出てきてるかっていうと。
そうですね。どんな変革を起こすべきかっていうこの第4部の一番最初の章が11章で、安定的ソフトウェア工学の構成要素っていうような章なんですけど、お察しの通りのお話をしてる章ですよと。
で、ソフトウェアプロジェクトはなぜ失敗するのかっていうくだりとかがあって、そのうちのいくつか利用員のうちの一つが情報障害っていうようなカテゴライズされてて、
情報障害が何かっていうと、ソフトウェアプロセスモデルや実績データのような制御情報が欠けていたか、売却されていたか、関連性がなかったか、ただ単に間違っていた。
計画を立てる上で必要な情報がそもそも腐ってたみたいな、腐ってたり不十分だったりっていうところですね。材料が間違ってるんだからそれをどう調理したって意識って間違うじゃんみたいな話が情報障害であって、
情報障害っていうのはもう少し掘り下げると何ですかって話がめちゃくちゃ今もやってる話じゃんって思って面白かったなって思いました。過剰書きでいくつか書いてあるんですけど、どんな製品が要求されているかを知らない、プロセスの性質を理解していない、進捗の可視的証拠がない、有意義な計測に必要な安定性が不足している、
設計の完全性が不足しているかなくなっているとのことなので、これは我々が現代も敗北し続けてるやつらじゃないですか。
アジャイルとスクラムの活用
そうですね。いやー何にも変わってない。
透明性の話だなみたいな。
結局こういう問題に対してどうやって立ち向かってきたかっていうのが、アジャイルだったりとかスクラムだったりとかいうようなものが出てきた背景としてこういうものがあるっていうのはすごく納得がいくって感じがしますよね。
そうですね。
だからじゃあスクラムやってればOKですとか、アジャイルなんでOKですみたいな話ではなくて、そのフレームワークだったりプラクティスを生かしてこういうところの問題と立ち向かっていく。
知らないとか理解してないとか、いろんなものがない情報障害になっていること自体はしょうがない部分もあるかもしれないけど、早くそれに気づいて早く手を打つっていうことをどうやればいいのかっていうようなことに結局現代では繋がってきてるよねっていう気はしますよね。
そうですね。
でもなんかすごいわかるな。やっぱこれ見てて。結局進捗の可視的、証拠がない、つまり見えるものがなくて、終わってますって言って、終わってるけど何も見せてもらえないみたいな、その言葉を信じるしかないみたいなことをやってると、基本的には最後に爆発するんだよなっていう気持ちしかないですね。
なんかあれですよね、12章以降、11章もあったかな。えーっと、何だっけ、注意すべき言い回しみたいなものが第4部ずっと連続で出てきてるんですよね。
11章までが結構基本的な、11、12あたりがこの部における基本的なインプットで、13、いやそれもないか、11が基本的なインプットで12以降が割と具体、個別的なトピックになっていて、その時の構成として注意すべき言い回し、要するにこういう言い回しが組織の中から出てきたら注意せよみたいな話があるんですけど、
12-5-1、第12章プロセス原則の中の12-5の注意すべき言い回しで、読者のプロセス、読者っていう我々ですよね、のプロセスがキーソフトウェア関係部分に全く及んでいないかどうかを見るには完成性インディストから始めよう、そのリストを念頭において次の言い回しに聞き耳を立てようがあれですね。
その一発目がまさにプログラムはほとんど完成した、他のことには何も触れずにとか書いてあって。
あとエラーケース書くだけなんで、大丈夫ですよつって。よくありますね。
いや、ちょっと胸が痛すぎて嫌になる。
最近チームで開発するときに、割とこれでいいんだっけみたいなものがあったりするんで、結構プロトタイプ作ること多いんですよ。
なのでソフトウェアのもう一個ベタ書きしたりとか、一旦ここは固定値でみたいなことをやったりするんで、そうするとなんかできてる風な感じするんですよね。動いてるし。
なんか良さそうじゃんつって。じゃあこれをストーリーチケットに分割してポイント入れて、だいたい1スクリーンターで何ポイントぐらいできるかな。
じゃあこの辺までいけるんじゃねってやると、あれこの時どうなるんだっけみたいなのがやっぱりいっぱい出てきて、プロトタイプやっぱその一番見たいケースに関してのフィードバックをもらうとか
どういう風に作らないといけないのかとか、どういうことに気をつけないといけないのかみたいな、一番そのコアな部分っていうところはパッと知れていいよねっていうことはみんな同意するんだけど、その反面結構次からやる作業が簡単に見積もってしまう。
これはイージーでしょって思ってしまうことがありがちで、まあほとんど関連してるしみたいな言いまししてるなーって思いました。
予知のパターンにまだ至ってないということですね。
そうですね。
そう考えるとプロトタイプが機能してるんだなぁとは思いつつ、やっぱり万能ではないんだろうなーっていう気はしますよね。
何のためにプロトタイプやってどこまで、どこっていうのはスコープっていう意味で、そういう形で役に立てばいいんだっけっていうのがなかなか。
なんとなくプロトタイプちょっと作ってみようは結構危ないなっていうことをさらに思いましたね、最近作って。
なるほど。
やっぱなんかこのフィードバックをもらいたいからとか、自分たちの不安を解消したいから、まずちょっと動くもの、コードレビューとか一旦いいし、
コントローラーにベタ書き、なんなら固定値返すだけでもいいから、なんとなくこういう風にAPIやり取りするよねとか、そういう不安を解消するために作るとか、
そういう目的を定めるとかないと、なんとなくプロトタイプできたけど、なんかこれで自信持って作れるんだっけとかいうことが得られなかったら、
これ何のためにやってたんだっけってやっぱなっちゃうなーっていうのを思いますよね。
AIとの連携
いいですね。今ちょうどパラパラページめくってたらソフトウェアの第0法則って書いてあって、ソフトウェアがまともに作動する必要がなければ他のどんな要件も満たすことができるって書いてあるんで、
プロトタイプぐらいのクオリティとか機能数で良ければ、明日にでもマージできますよね。
そうそうそうそう。
きっとその後ですもんね。その前も大変なんですけど、その後のちゃんとしたものにするっていうところに、いい意味でこだわり切れるかっていうようなところがやっぱり大事になってきますもんね。
パレートの法則みたいなのもありますし、8割の機能は2割の時間でできて、あとはエッジケースを潰していく作業ですみたいな。
でも本当にそうなんだよな。こういう予期しない値が来た時どうすんっけみたいなのとか、ユーザーがいいとしない操作をした時にどうあるべきなんだっけみたいな話してる時間がやっぱ長いんだよな。
ましてやね、エアエージェントとか出てきたら、楽できる部分が増えますもんね。だから人間がやるべきというか、デポジトリの中にないことはやっぱり人間が、デポジトリって言ってるのは自分たちだけじゃなくてもしかしたらGitHub上の全てのデポジトリかもしれないですけど、
そういうところに書かれてない部分は人間の仕事なのかなっていう気はするので。
そうですね。
いやびっくりしますもんね。他のチームからこういうことやりたいんですよね、どうすかみたいな言われてもらった一周そのままクラウドコードに突っ込んだら実装してくれたんで、ああ助かる。
なんか似たようなことを最近やったなと思いながら。POがこれやりたいって言った時に、なるほどそうですねっつって裏でAIにマルチするみたいな。初手はでも多分そういう感じにもなっていくんだろうなって気がしましたね。
うん、それができちゃいますからね。まあでもやっぱり、既存のコードベースがしっかりしていれば本当にエンパワーメントされるなーっていう感じがするので。
いやでも難しいっすよ、そのコードを書くのはAIの仕事なんだよなってなっちゃうと、あれ?どこに介入するんだっけみたいな気はするけど。
なんかその辺は結構コードの新生産みたいな、歴史的経緯によりなかなか変えるのは難しくて、これが残り続けてるんですよねーみたいなものがどれだけあるかによっても変わってくるかなーって気もするし、
やっぱりAIが読めるようにコードを書くっていうのが、なんか今までは人間が読めるようにっていうことだったけど、もっと読み間違えないように明示的な、それこそ型がちゃんとあるとか、ミックスドって見てないとかいうこととかがもっと大事になっていくなーって考えたときに、
昔はこういう書き方が言語機能としてなかったんで、こういう制約の中でやってたんで、こういうことをマジックメソッド使ってますとか、否めなかったんで無理やりゴニゴニやってますみたいなことが過去あったりしたものが残り続けてると、やっぱりAIが読むの大変だったりして、難しくなっていくのかなーみたいなちょっと思ったりもしましたね、使ってて。
いやーでもそうだよなーと思いつつ、まあ1ヶ月後にはどこまで優秀になってるかわかんないから、難しいっすね。
難しい?
まあ、どんな便利なツールが出てきてもそれに負けないぐらい楽してやるぞっていう気持ちが、やっぱ人間に大事な気がするんで。
そうですね、そうですね。
絶対に楽してやるからなーみたいな。そのためだったらいくらでも勉強しますみたいな世界だと思うんで。
まさに三大美徳が利用された。
あとは本の話もそれと、他は多分まだね、触れてない部分が200ページぐらいあると思うんで、どこからでも。
なんか重工章、要求定義の原則とプロセスみたいな場合。
なんか読んでてわかるようではない。
