ゼロ時計測の基本ステップ
で、第5部、ラストですね。 ゼロ時計測。 ゼロ時計測。何でゼロ時計測って言い出したの?本のタイトルはどこ行ったんですか?っていう言い訳は、ちゃんと最初に書いてあると。
最初、何でゼロ時計測っていう項目があるんだろうって。 間違えたかって。
まあ確かにね、インデックスはゼロから始まるしなとかって思いながら。
1時計測よりも前にあるゼロ時計測ですよね。
そうですね。ここでゼロ時計測っていうものをやるためには、4つの基本的なステップが必要ですよっていう話をしていて。
つまり計測を始める準備段階って考えるといいのかな。
4つっていうのが、1個が計測可能なタスクからなるプロジェクトをどう構成するかについての知識を持っていることが必要。
2個目が、処方の品質を目指すプロジェクトの進捗についてオープンな視点を作り出し維持するシステム。
今どれくらい進んでますかってことがちゃんと外から見て分かるよっていう状態にするようなことが必要ですよと。
3つ目が品質が何を意味するかを文章化する要求仕様システム。文章化してそれをどこかに保管するっていうことが必要そうですね。
4つ目が品質を目指す進歩のあらゆる結果を計測する一貫したレビューシステム。この4つが基本のステップですよっていうのがありますね。
これレビューって言ってるのが我々、先の我々が言うようなコードレビューみたいな話ではなさそうですもんね。
それも含まれてると思うんですけど、ウォーターフォールモデルでいうところの各ゲートから次に行く時の歴史的な検査みたいなぐらいのニュアンスっぽい雰囲気を感じながら読んでました。
ウォーターフォールが何か分かってないから説明間違ってるかもしれないけど。
うまくやってんのかっていうことを外からレビューする。何か問題があるんだったら改善しないといけないしっていうぐらいな感じでいいのかなって思ったりはしてましたね。
そうですね。ゼロ時計測はソフトウェア工学の第0法則に関連する。それは品質を気にかけなければ他のどんな目標でも達成できるっていうことですね。そうですかと。
そうですね。プロジェクトの進捗はもうバッチリですよ。何か動いてないのもありますけどできましたみたいなこととか言えちゃうねっていう感じですかね。
第5部の最初の章が16章。計測可能なタスクからなるプロジェクト。今ゲイさんが読み上げてくれたステップローリーの章構成になってて、計測可能なタスクからなるプロジェクトっていうのは、これはあれですよね、スクラムの人たちとかが言うような段の定義をしっかりしてようって話かなって思ったんですけど。
そうですね。結局どうなったらゴールなんだっけみたいなことを、DODもそうだし、プロジェクトってなってるんで、じゃあプロジェクトがどうやったら終わるかみたいなところも含めだと思うんで、段の定義がちゃんとされてないとあれ?できたって言ったのにできてないねみたいなことが起きたりとか。
いうふうなことがどうしても発生しちゃいますからね。
そうだよな、学生時代それでバイトのバイト代もらいそびれたからな。
それなんかちゃんと動いてないじゃんって言われて、バイト代もらえなかったってことですか。
リリースして動いてるけどまだダメなんですかって言われて、さすがにこれはちょっとねって言われて、はぁ。
いやいいんですよ、当時があったから今、プログラマーとして。
で、これ計測可能なプロジェクトを創出するステップっていうのが書いてあるんですけど、その中に小作が何に価値を置くかを童貞する、小作を童貞するっていうステップが途中にあって、その次に小作が何に価値を置くかを童貞するっていう話があって、なんかユーザーストーリーっぽいですよね。
○○として○○をできるようになりたいみたいな感じな気がする。ユーザーストーリーだっけ、ユーザーストーリー。
ユーザーストーリー、でももはや本当にみんなちゃんとこれやってるみたいな。
計測可能なようにゴールを述べる、メジャーラブルみたいな話がありますね。
そうですね、なんかもっとよくなりたい。
あれがもっと強くなるとダメだと。
強くなるっていうのは○○選手をK-1で2ラウンド以内にノックアウト後で負けさせるってことですってなると、頑張れ。
じゃあそのために何やらなきゃいけないんだっけみたいな。
確かに、分解ってないですけど。
その選手と練習試合を月に1回組んで、そこで進捗を測りみたいな。
定期的に練習試合やれば勝率を下げる気もするけど。
確かに。
16勝はどうですか、面白いというか目新しいこととかありましたか。
逆にこれをやってないからいっぱい失敗してるのか、みんなこれやってるけど失敗してたのかっていうのはちょっと気になりましたね。
あれなんでしょうね、パターン0から5歴述してるじゃないですか。
カルチャーというかサブカルチャーについて。
前の間が結構パターン、0は除外したとしてパターン1と2みたいな話が結構重きを置いてたかなっていう気がするんですけど。
なんか今回はパターン2の後半からパターン3ぐらいのちょっと上手な雰囲気がありますよね。
そうですね。パターン3とかだともうこういうことがそれなりにできてるよね。
じゃあそこにどうやっていくんだっけみたいな感じをちょっと受けてますね。
そうだからそれで言うとパターン3の組織がめちゃくちゃ少なかったはずなので、これ書かれた当時。
だからこれやってる組織はそんなに失敗してなかったのかもしれないなって感じもしますかね。
組織文化の向上
そう考えると結構ソフトウェア開発の歴史って積み上がったのかなとか思ったりとか。
なんかもうちょっとこう上手くソフトウェア開発って多分まあこんだけソフトウェア is eating the worldっていう風になんでソフトウェア世界を飲み込むっていうぐらいなんで、
もうちょっと上手く当時に比べたらできるようになったんだろうなっていうことをちょっと思ったりとか。
今読むと多分目新しさとかありましたかっていうことを考えると、実際読んでてもそうだよねぐらいにしか思わなかったんだよなっていうのはあるんだけど、
まあそこはやっぱり差分なんだろうな、現代と当時とっていうことを感じましたねすごく。
なんか一方で16章になるとなんか古びてるな、昔はこんな感じだったんだっていう印象もそんなに、ゼロじゃないですけどあんまりなくて。
なんか今の普通とか今のあるべきにもかなり近い感じがしますよねこの章は。
そうですねそうですね。
まあとはいえ8ページ目しかないのか。
まあでもちょっとやっぱり気になったな、顧客が何に価値を掛かう童貞するっていうのはなんか、やっぱり作ることがやっぱりどうしてもゴールになるとか、
そのゴール達成の条件として作るっていうことになってるようなプロジェクトってのは多分いっぱいまだまだあるんだろうなみたいな気がするので、
これはすごく感覚だし、作ってるものによりけりだと思うんで、
だんだん使えることが競争の厳選になっている時代に変わりつつ今ある気がするので、
ここはより今もっと見直されるべきというかできるようにならないといけないのかなみたいなことはちょっと感じましたね。
そうですねそうですね。
昔は作ってできて、そんなソフトウェアあるんだぐらいな感じだった時代から、
実現するのは多分できるようになったけど、もっと使いやすくとか本当に真の課題を解いてくれるのはなんだっけみたいなところとか、
いうことが大事になっていってると思うので。
そうですね。昔はお前iPhone持ってるのめっちゃすげえイケてるって言われてたのが、
今iPhone持ってるのことを自慢したとて、その先に何があるかでしょうって感じてますからね。
そう。
じゃあ次行きますか。
計画と進捗に関するコミュニケーションなんですけど、これこそ今は結構普通にやってそうっていう感じが看板です以上みたいな気がするんだよな。
看板とか動いてるものを見せて進捗を見せるとか、
当時は進捗を公開するためにPPPPっていうPが4つ並んでるポスターに今の進捗状況をパブリックに見せて、
そのポスターを毎週毎週更新していきましょうみたいなことをやっていて、まあ確かになみたいな、じらとかないもんなみたいな気持ちになりました。
そうか。看板じゃなくてポスターか。看板も物理だからな。
ホワイトボードもいいけどさみたいなこと書いてたんだ。ここでしたっけ。
ここだったっけな。
ホワイトボードも簡単に消せてしまうっていう欠点はあるもんなみたいな。
白板って書かれてたんだよな。黒板みたいな。
まあ確かに。確かにな。
でもなんか壁に張り出していくみたいなやり方とかっていうのが多分やってたってことが絶対あるんだろうなって気がするな。
そうですね。
以上みたいな感じですね。
この章でいうと、ゼロ時計測システムの必須事項っていうところがあって、312ページ。過剰書きで3つ書いてあるんですけど、次の3つの必須条件があると。
組織はオープンでなければならない。組織は誠実でなければならない。組織は人々の相互学習を奨励しなければならないっていうふうに書いてあって。
これ必須事項って書いてあるんですけど、これがちゃんとインストールされているサブカルチャーであれば、なんかだいぶ発達進化的な状態になってるんじゃないっていう気もしていて。
そうですね。
難しいですよね。文化をより良いものにしていきたいんです。どこから始めればいいんですか。
難しいだろうから、まずはゼロ時計測からやってみようかって言われてみて、ゼロ時計測さんお願いしますって言ってみると、必須条件としてすごいハロルが高いのではないかみたいな感じがする。ゼロイチじゃないんで。
そうですね。オープンっていうのも本当に組織全体にオープンするのと、とりあえず隣の島の人たちが見えるところでまではやろうぜみたいなのとかあるだろうから、誠実はあってほしいですね。
そうですね。
あとなんかこの相互学習の話が入ってるのもやっぱ面白いですね。
でもここら辺は格約ではないけど、スクラムの透明性とか価値基準の方の公開尊敬勇気みたいな。誠実っていうのは多分リスペクトに近い気がするし、学習っていうと変化を恐れないとか新しいものから目を背けないっていうのは相互学習に近い気がするし。
確かに。
透明性はね、トランスパレンシーはもちろんオープンネスなので、なんか似てるなって思うのを読んでます。
確かに。やっぱあんまり変わってないといえば変わってない。
そうですね。まあというかこれを書かれた数年後ぐらいから本当にアジャイルムーブメントが起き始めるっていう感じなんで、アジャイル善逸って考えるとそりゃ似てるよねという気もする。
そうですね。
次いきますか。計測ツールとしてのレビュー。ここはどうだろうな。なんかメモったっけ。私のコメントですね。レビューって言ってるものの感覚が多分僕が知ってるのとすごい違うって思ってしまったな。
そうですね。なんか自分の中では割と明治として思ってたのは、最後にシステムをどーんとテストする、レビューする、うまく動いてるからレビューするってやると、もうとてもとても大変っていう感じはあるので、
レビューと要求の重要性
常日頃からパブリックになってそのプロジェクトをレビューできるような状態にするっていうのは大事だよねっていうふうに思ってて、例えば設計の段階で1回レビューしましょうとか、コードレビューもそうだろうし、ADR最近だと何ですかね。要求仕様書、ADR。
プロジェクトの進み具合のものをレビューして、なんかこれって間違ってないみたいな。ないし、なんかこういうふうにこう考えてこう進んでるんだけど間違ってないかなみたいなことをどっかで確認しないと手戻りが大きくなるっていうようなところが一番つらいくなるから、そういうものがあるといいよねっていうふうな斧として読んでましたね。
レビューされるってなると人は多分ちょっとそこに頑張ろうってなるだろうなっていう気がする。
ああ、そうか。計測できるものが努力を注ぎ込まれるってやつですか。
でもなんかそれは結構ありそうな気がしますね。なんかコードレビューがあると、ちょっとめんどくさいけどこれちゃんと書かないとなみたいな。ここで概要にちゃんと書いておかないと伝わらないかもなみたいなことがあるだけで、ちょっとそれがあるだけで、なんかサボるっていう言い方をするとよくないけど、丁寧にやろうとする。
まあちょっとピリッとしますよね。確かにな。毎週英単語の小テストがあった方が期末の成績も上がったからな。これはあとあれですね、あんま本筋じゃないけど、ノームカースさんが出てきましたね。同僚、IBMの人なんですか、もともと。
最初の写事の部分とかに名前が載ってたんですよね。 ああそうだ、写事で見た気がする。あのノームカースかなと思って調べて。振り返り最優先条項の人ですね。
これでもあれかな、あとなんかちょっと厳重するとしたら、レビューにおいて感情っていうものがあるよねっていう厳重があるのはちょっと多く思ったかな。どっかにあったんだよな。まあさすがっていう感じです。
そうですね。なんだよな。 まあ次行きますか。
19が計測の基礎としての要求。 なんで計測の基礎が要求なんですかっていうと、要求をしっかり満たすというかクリアしていくことが品質なのでっていう話かな。
そうですね。結局要求に合ってないものを作ってもしょうがないし、あとなんか最近設計レビューとかコードレビューとかいろんなものを見てても、結局なんでこれを作りたいんだっけみたいなところって、要求がわからんとこれでいいのかなっていうのを何も言えないなみたいな気持ちも最近あったりとかして、ああそうそうみたいな。
確かにそこタイDBじゃなくてGoogleスプレッドシートでいいじゃんみたいな。あり得ますもんね。
ありますね。なんかデータ量がどれくらい来るか、3行ですみたいな3レコードしかできませんみたいなことを1億10億100億みたいなオーダーだと多分アプローチ全然違うのでテーブル設計見てくださいって言われても多分全然考えることいろいろ違うんだよなみたいなことがあったりするんで、そこの前提みたいなところを揃えるという意味でもやっぱ要求でないといけないし、
そもそもその要求が合ってるんだっけみたいな、どうやってそういうこのシステム使うのみたいな、そういうようなこととかいっぱいあるからなーって思ったりはしましたね。
どういうデータがあってどのぐらいのデータ量になるのかもわかったけどどうセレクトされるかわからないからインデックスが正しいかどうかわからんみたいな。
明らかにテキストカラムにインデックスを貼ったら機器が悪いとかそれぐらいは言えるかもしれないけど。
まあでも要求の単位、この要求がどういうフェーズかどこまで進んでますかっていうのをトラッキングしていけばOKっていうニュアンスも込めて計測の基礎って言ってますね。
案内人の役割
うん。 まあでもそんなにそんなにかな。 そんなにびっくりすることを言ってることはなく。
じゃあ第20章、案内人いきますか。 そうですね。 まあまとめの章ですね。終わりにみたいな。たまたま章のタイトルが案内人になってるだけで。
うん。 これはでもあの、そうですねでっけえ海で船旅するときに案内人がいるから目的の大陸に着けるみたいな話になぞらえて案内人っていうタイトルがついてて。
うん。 まああなたの文化をそのパターン3、8、4かな。3か。舵取りの文化に。あ、舵取りとかけて案内人なのか。
うんうんうん。 導いていく、育んでいくのはあなたが案内人としてナビゲーターとしてみんなを連れていくんやでみたいな。
そのための0時計測から始めて1時計測をやりっていう風にやってこうぜっていうような話ですかね。 そうですね。
うん。あなたの感情を知覚し正しい構図に舵取りしなさいって書いてあります。道中ご無事でって書いて。
そうで。本当に終わりにって感じですね。 終わりにって感じ。
うん。これで終わるんですもんね。あとは付録だから。 はい。道中ご無事でってボルドで書いてあって終わりです。
漢訳者あと書きとかもないから。 漢訳者あと書きありましたよ。
ありましたっけ。漢訳者あと書きあるか。 でもそんなに変わらない。
多分なんか言葉はこの辺から取ってきましたよってなんか前の勘でも同じようなこと書いてる気がするなと思いながら。
うん。 いやーめっちゃ喋りましたね。
喋りましたね。2時間で終わるかなと思ってた。
いやー終わると思ってたんですけどね。
いやーまあ今回もなかなか読むのが大変な感じのする本でしたけど。なんかでも1巻に比べたらだいぶ読む時間が短くなってて僕は。
まあちょっと読む時間が十分取れなかったから意識的に急げめに読んだっていうのもあるんですけど、なんか少しシステム思考法を読んだことによってちょっとワインバーグのリズムとか文体とかノリとかにちょっと耐性がついてきた感じもあり。
前回の収録で言ってたなかなか読み飛ばしづらい、見分けがつきづらいって言ってたのがだいぶ対処できてきたかなという気がします。
あとまあ今回は結構そのインプットじゃないですね。
インテークですか。
インテークから始まって反応までの流れを追っていくっていうのがまあ衝立てにもなってるし、なんか全体の流れがどう進んでいくのかは結構つかみやすかったなと思いながら読んでて。
まあもちろんなんかその全体の流れとその各個別のところを読んだ時にみたいなことはなくはないんですけど、今回のほうがなんか割とそういう意味では読みやすさがこの話どこに向かっていくんだろうなーっていうのは結構わかりやすかったなっていう気はしましたね。
なんか主題っぽいところも結構第一巻で設定済みでもありましたしね。
まあ当然違うトピック扱ってはいますけど、コンティニューアルものは全く同じではあるので。
そうそう。そこはねなんか結構ありがたいというか、あの一巻をちゃんと読んだからこういうことが言いたいんだよねみたいなのは。だからこういう話してんだよねっていうところは結構わかりましたね。
あとそんなに間を置かずに読んだのは正解でしたね。
そうですね。
まあまあまあでもたくさん喋ったからそんな感じですかね今日は。なんか言い残したことありますか?氏名入りますか?
言い残したことはないです。
じゃあ道中ご無事でということで。
本週も放送をお聞きいただきありがとうございます。ではまた次回。さよなら。
さよなら。
