ソフトウェアの可視化の重要性
たぶんその次の3章のとこにもまさにつながっていって、でソフトウェアってでもわかんないじゃんみたいな、その中身が見えないじゃんっていうところがありますよね。
そうね、垂直0と1作っているだけなんで。
でもこれたぶん本当にあれですよね、我々0と1なんだけど、よく技術的塞がとか、さっきの数行変えるぐらいだったら大丈夫だよねみたいな部分とかって、結局そこがどこに影響してるかみたいな客観的に、
みんなが見て同じように解釈できるように物理法則があるわけでもないし、スーパーのエンジニアは嫌な予感みたいなキツな匂いみたいなことによってわかるんだけど、
じゃあ経営者がそれがわかるのかとか、セールスの人だったりとかが、ここちょっと変えるだけでしょみたいなことによってうまく光っていったらたぶんそうではなくて、ずっと苦しめられてるようなっていう気がしますね。
よく言うようなソフトウェアは建築に例えられがちだけど、建築とは全然違うんや、例的なのにそういったような要素に関わりますよね。
ありますね。建築は。
こっちは重力がありませんみたいな。
建築は重力があることによって、この机もうちょっと宙に浮いてる方がいいんだけどとかって要求がなかなか来ないと思うんですよね。プルスみたいなことをしてる前提であればいいんだけど。
でもソフトウェアだとできてしまうっていう部分もあるんだけど、それをやったことによる副作用がどういうものがあるかとかいうことがわかんないっていうのは難しさですよね。
紙飛行機リゾーを運搬しますみたいなことがソフトウェアできますからね。
そうですね。この辺でソフトウェアの製品を可視化していきましょうみたいな話が出てきて、どうやって我々はソフトウェアの可視性に対して向き合っていくといいのかなみたいなちょっと思ったりしましたね。
結局直接観察できないから、例えばバグが出た件数で考えるとか、あと書いた行数で判断しましょうとか、どうにか数値として観察できそうなもの、相関がありそうなものを探し当てるみたいなことになっていくと思うんですけど、なかなか難しいですよね。
難しいですよね。そこら辺の話を踏み込んでというか、厳重してる本だし厳重してる章ではあるんですけど、これだっていう感じのものがやっぱり出てきてないよなっていう感想にちょっと個人的にはなってますね。
例えばこういうのがヒントとして生きるんじゃないだろうかっていう提案とすら言うのちょっと怪しくて、この昔にはなってるんですけど、どうなのだろうかという。
そうですよね。だから結局、現代の我々においてもなかなかそこがオブザバビリティみたいな、ソフトウェアの中身がどうのこうのっていう、正しく動いてるかどうかっていうところを観察するとかいう手段は手に入れたけど、なかなか書いたプログラムのそのものとかはあんまりうまいこと探し当てることはできてないっていう感じもするし、
でもこの最初の方にエドワード・デミングが引用として出てますけど、あれデミングだったよなって今一瞬ふと思ったけど。
デミングですね。
はい。
計測できないものは改善ができませんみたいな話はあったりもするので、じゃあ計測できないと良くならないんだろうねっていうのもあって、やっぱこう観察できるようにするっていうのはなんか今後もずっと課題になるのかなっていうのをちょっと読みながら思ったりしてましたね。
計測と改善の関係
そうですね、まあ価値を生んでるかどうかみたいなところと、価値を生むのを妨げてるものは何かっていう中直はそこの2点だけなんでしょうけど。
なんかそこに到達する前に早期に発見できるといいなみたいなものとかも多分あるんだろうなって思いながら。
そうなんですよね、先行指標じゃないですけど、先に今日の仕事がどうだったかのフィードバックが欲しいですもんね。
そう。
来年をお楽しみにとか言われても、いやいやいやみたいな、じゃあ明日休むぞっていう。
ちょっと読みながらあと関連しそうな話としては、循環複雑度とか、ああいうやつとかだったらパッと出せるっちゃ出せるんだけど、なかなかそれだけでどうのこうのっていうのはやっぱ難しいですもんね。
でもあれですね、そのあたりに関連してっていうのも変かもですけど、同じ章の第3章の53ページにある計測を使う前にその計測の背後にある物語を理解せよっていうようなことが書いてあって、
これが究極に便利な計測手法です、統計手法です、摩擦対象ですっていうのが仮に発見されたとしても、やっぱり数字として一人歩きしちゃうとさっきギエさんが言ってたようなハックされちゃうっていうのもあると思うし、
ハック対象として数字を乱したら正しい行動なんてそこから生まれないと思うので、その計測の背後にある物語を理解せよっていうのがいいでしょうね、大事な言葉だなと思って。
そうですね、フォーキーズを追いかければいいんでしょって言われたらこの言葉言いたくなりますね。
そうですね。
難しいですね、結局その背後にある物語もセットで理解してほしいんだけど、それまで含めてメッセージングしようとするとめっちゃ長くなったりとか、要求する、つまり認知してほしいものがものすごく量が増えて、
なかなかそこにそれを理解するのが大変になるってなると、この数値が良くなったらいいんですみたいな、体重が減ればオッケーですって言いたくなる気持ちはあるなと思いながら。
ただ単に痩せればいいだけでは、多分健康的に痩せる必要があると思うんですよね、本当にその体重を減らすぞみたいな話でいくと。
でもじゃあなんか飲まず食わずで減らせばいいんですねって言ってがししたら意味がないので。
そこら辺を補うのが文化の力だよねっていう話は多分あるんですよね。
そうだと思いますね、結局妄心的にじゃあこの数値を下げましょうって言ってハックすればいいんだよねっていう風にならないためにはやっぱり働いてる人たちがそれをどう理解するかみたいなところまで含めて大事そうって気がしますね。
誰かに指図されなくてもその中にいる人が自然とそう行動するのが文化であるっていうような、この本でも言ってましたもんね。
どっかに出てきたはず。
だから文化をソフトウェア文化を作るの大事だなという。
プロセスの透明性を高める
あとは後ろ側プロセスを可視化するですね。
ここはソフトウェア開発のその中のプロセスを可視化してみて計測をするっていう部分の話が書かれていて、確かにこれはすごくやろうと思ったらできそうだなっていう気持ちになりましたね。
この辺はなんかすごい最終章、最終部のゼロ時計測の話とめちゃくちゃ近いですよね。
ここで言ったやつの実践方法踏み込み方がゼロ時計測の話だなとか思いながら読んでましたね。
結局、例えば計測をしてこういう手戻りが多いみたいなのもプロセスを並べてって、どこで問題が起きてるんだっけみたいなのとかを可視化するっていうのはすごく今でもやりそうだし、
今だとバリューストリームマッピングみたいなので、自分たちのソフトウェアがどう作られてシップされてるのかみたいな話のところを一連書いていけば、
じゃあどこで今ボトルネックになってるんだっけとかっていう話とかすごくやりやすそうだなーみたいなことを思ったりしてましたね。
そういうのやりたいなーって思いますか?
やりたいと思ってますね。
実際にチームのプロセスを改善しましょうみたいな、今自分たちが作ったソフトウェアが出るまでにどこに時間がすごく取られてるんだっけとか、
例えば2週に1回リリースをしたいと思っていたとしても、なんでそれができてないんだっけみたいなときに、そもそも我々は今どういうふうにリリースされてるんだっけみたいな、
作ったものはリリースされてるんだっけみたいなのを認識を揃えるっていう意味でも流れを知りたいし、流れが分かるとじゃあここだよねみたいなのをみんなで指差しながら喋れるようになるんで、
すごく精緻なものが必要ってよりは全体の流れとして今ここの話してんだよねみたいな認識を揃える意味でもあると便利だなって思ったりしてますね。
すごく雑に言えばアイディアが出てきてコート書いてデプロイするんやみたいなことでもあるんですけどね、すごく雑に考えれば。
なんかそこら辺の話を扱った本を積んでた気するなぁとか思ったけど、ちょっと違えのかなぁこれは。なんかPSPガイドブックって本を昔買ったなぁっていうのを思い出したんですけど。
気になるな、ちょっと後で、これは小ノートに貼っておいて、みなさんも読めるようにしておきたいな。
なんかこれP、パーソナルのPかもしれない。SPはソフトウェアプロセスなんですよ。
プレイステーションポータブルではなく。
改善したとて、精神性が上がるかは別。
まずはなんかその全体のプロセスをみんなで並べて喋んなくてもいいよねっていうぐらい大単位で動けてたりすると、今の話ってたぶんあんまいらないんだよなぁとか思いながら。
規模がでっかくなってくるとやっぱどうしても自分の作ってる領域以外の部分がわからないとかいうことが発生したりするんで、そういう意味では必要なんだろうなって思ったりしてますね。
そうですね、そうですね。
説明責任とかあんまりないとか。
責任がないって言うとちょっと。
説明する対象がいなければ別にあれなんですよね。ちっちゃくくれてるしとか説明相手がいなければ、なんでこんな遅いのって聞かれたときにちゃんと説明できないと困るみたいな状況がなければ多分作らなくてもいいんだろうなって思ってますね。
そういうコミュニケーションコストというか非資産行動時間みたいなのを減らしたいですよね。
そうですね。
そのワインバーグというかこのシリーズはずっと品質側っていう話をしているので、欠陥とか修正の対応とかっていうのが一番大きいコスト増大につながるので、そういうのを防ぎたいよね。
そのためにはどこら辺を観察していくんだっけどう対処していくんだっけっていうようなところがちょっとこの章だと触れられてましたかね。
そうですね。
テストでやるかレビューでやるかみたいな。
うん。どっかにそもそもソフトウェアの何パーセントは成功しないみたいな話もあったりとかして、その期日通りにうまくいくものなんてほとんどないんやみたいな話もあって、結局多分そこの大きな原因としてはその部分っていうところですよね。
あとあれか、プロジェクトのヘルスチェックというか計測するのにあたって、ちゃんとインターバルどういう感覚で計測するかっていうのをちゃんと考えようなって話もあって、これもすごい当たり前のこと言ってるけど大事だなっていうような気がしました。
要するに1週間遅れたら困るっていうプロジェクトとかソフトウェアのヘルスチェックを2週間単位でやってたらもうダメじゃんっていう。1週間遅れたら致命的に困るんだったら計測可視化は1週間以下の単位で行われなければならないっていうような話ですね。
じゃあこの本には1ヶ月単位でやるって書いてあったんでって言ってやっても目の前の問題は解決しないですからね。
それで言うとあれだな、目標基礎に立てて半期に1回しかフィードをかけませんみたいな話、たまにありますけど。
あまりって書いてよくある。
確実に当たりかハズリかしかって結果が出ないから、てこいでどうすんのみたいな気はしちゃうけど。
そうなんですよね。あと半年後とかにはそれが最重要指標じゃないってなった時とかに、でも基礎にこの数値を良くするって言っちゃったんでって一生懸命それをやっちゃうってなるとすげえ無駄だよねみたいな。
で多分これ意味なくなったんで、やりませんでしたって言ったら評価されなくて、一生懸命頑張ってその指標を改善したら、でもそれ重要じゃなくなったんで、これ上げられてもちょっと評価できないんだよなとかって言われて、どっちにしろ評価されないみたいなこととか起きちゃうから、じゃあどうしたらいいんだろうねって言ったらもうちょっと間々で確認しようねみたいなことになるよね。
部下が評価上がらなくて困るのはマネージャーのはずなんで、なんで一緒に飛び降りるみたいなことしてんのかなって。
まあでも第一部そんな感じですかね。 そんな感じかなと思ってます。 取り込みやってこうぜと。で第二部ですね意味ですね。厚いストーブの蓋の上に座ったことがある猫は二度と厚いストーブの蓋の上には乗ろうとはしない。冷たくてもそうだっていう引用から始まってますね。
そうなんすよね。えーそうなんだみたいな。で意味って何なんだろうみたいな気持ちになるような引用だなと思う。
まあまあまあなんか行動の量数がちっちゃいから安全ですっていうのは、本来はそうじゃないのに意味を取り違えてるから意味づけ大事だよねっていう意図での引用だと思うんですけど。
そうですね。
このステップのキーワードは正確さであると。
頭の中にあるものと世界にあるものとできるだけ厳密に一致させるのが大事。
でここはあれかなスリップ図っていうのがよくツールとして使われてますね。
そうですね。
こいつはなんか嬉しいんですかできると。
スリップ図の紹介
これはスリップ図っていうのをまずここで私は初めて見ました。でこいつはまあどれぐらいこうずれているのかずれが多く発生しているのかその予定と現在の出荷までの
ベースライン1年後にリリースしますよって言ったときに遅れてますよみたいなのが実際今どれぐらいずれているのかみたいなことがわかったときに図を説明するのがむずいなって今思いながら喋ってたんですけど。
びっくりした。急に何を笑ったんだと思ったらそういうことですね。
なんか何を言っても俺は何を喋ってんだろうっておかしくなっちゃったなと思いながら実際どれぐらいずれてるかみたいなことを把握しやすくしてくれるっていう感じですかね。
なんかね、駅伝とかだとよくありますよね。今戦闘集団から15秒差ですみたいな。なんかあんな感じでラップタイムというか、期待、想定される、想定されるというか、想定される理想ラインなのかベースラインなのかっていうのと本当に超えたらあかんっていうレッドラインなのかでまた別かもしれないですけど、予定より何日遅れてるかなっていうのを図にする。あれ?同じこと言ってるだけだな。
なんか身近なもので言うとあれなのかな。バンアップチャートとかバンダウンチャートみたいなものに近いと言ったらいいのかな。そのあれに理想ラインみたいなの引かれていて、今の消化ペースでいくと間に合う間に合わないみたいなのが間に合う。理想スプリントの終わりまでにそれがうまくいくかどうかみたいな。みたいなやつですね。
週間単位とか日時の単位で今の時点で何日遅れてますねっていう記録をとって、それをちゃんとグラスとして記録していくと、ずれがどういうふうに変動していったかなっていう推移が見えるというのが嬉しいよねと。
そうですね。傾きが分かればこのまま引くと?みたいなのが分かるので。 これを第2部の一番最初の章であるところの第5章で一番最初にスリップ図っていうのがあるよっていうのを説明していって、なんでだっけ?
これはあれですね。結局こういうデータをプロットしていった結果、この章が意味なので実際の自分の頭の中にあるものと現実で起きていることを一致させて、どれぐらい本当に遅れているのかをちゃんと図で表すっていうところですかね。
何を取り込んで実際そのデータの意味っていうところをプロットすることによって分かるようにする。最初が解釈の事例研究なんで、とりあえず事例としてプロジェクトがうまくいってるのかいってないのかとか、うまくいってないところの特徴みたいなところを見るみたいなところですかね。
取り込みと可視化まではやってみたから、じゃあこれを元にどういうふうに解釈していくんだっけっていうちょっと事例エクササイズみたいなところで、例えばスリップ図っていうのができたとしたら、あなたのプロジェクトはどういうふうに理解が進んでいきますかっていう話か。
そういうことだと思うよ。 なんか面白いエピソードありました。何か架空なのか分かんないけど、何かケーススタディ的なところですよね。この章でやってるのは。 そうですね。実際元ネタはきっとあるんだろうなって内緒に読んでたんですけど。
終了を恐れるプロジェクトってすごいなんか、終了を恐れるとはみたいな。スリップ図をいくつか出しながら、例えばこういうカルチャーの会社だとどういうリアクションするのっていうのがさっき言ったケーススタディ的に触れられてると。
そうですね。 そんなに豊富に事例が並んでるわけでもないな。
実際こういう図を見ながら解釈するっていうのは、バンアップバンダウンみたいに見たときに本当にこれで間に合うのか、よくやってるような気がするなって一瞬ちょっと思ったりとか。
なんかそれが繰り返されてるってことはこのチームやばいかもみたいな。やばいかもうまくいってそうみたいなことをそこから読み取るみたいなのってなんか日頃やってそうだなっていう。
日頃やれてるってことはアレレスにちゃんとしたカルチャーがあると。
あると言えるでしょうみたいな。あとは多分この公表日、何日ずれてますみたいな。観測した日でもって言い換えてもいいと思うんですけど。
なんか終了に近づくにつれてドーンと上がったりとか、前倒しするとかのは多分なんか結構そこは組織の特徴みたいなの出てくるんだろうなみたいな。
そうですね。終盤にめっちゃペース上がったね。どんな工夫をしたんだいって開いてみたらテストがなるほどねってなったりとか。
そうするとやっぱりテストとか品質をおざなりにする文化っていうのは良くないよね。じゃあ次どうしていくって話になったりとか。
逆に言うとなんかマジでやる気出すからラスト1週間はすごいんですって話だったらどうするんですかね。
プロジェクト短くしてもやる気が過ぎそうだし、かといってラスト1週間になったらあいつらはやってくれるかなって信じるのもなんかちょっとヒヤヒヤするし。
いやですね。
まあ信頼。
NBAでもプレイオフになるとめっちゃ活躍する選手とかいるかな。
信頼とかを得るためには安心したいですからね。やっぱりヒヤヒヤしながらはやるのは難しいので。
なんかこう後ろに行くにつれてドーンと上がったりする。あるタイミングでドーンと上がるみたいなものがあった場合はなんか悪いことをこのチームは隠しがちなんだなとかって思ったりとかしちゃったりするんだろうなって思いましたね。
まあいろんなパターンあると思いますけどね。実際作ってみたら仕様の漏れがめちゃくちゃあって手戻りがあって遅れますみたいなこととか。
そうですね。
一概には隠そうとしていたっていうことがすぐパッとわかるわけではないんですけど。
仕様漏れの変更とかがあれなのであれば、もうちょいプロトタイピング的な思考を強めようかとか、技術的なハードルっていうのをもっと優先的に解決したいねとかできるかもしれないですもんね。
でもいいな。なんかこれ、チームの振り返りとかでちょっと見ながら、我々って早く行ったんだっけ遅く行ったんだっけみたいなことを喋れると。あとこれになんかイベントごとプロットしていくと、結構立派な振り返りの資料に、材料になりそうだなって気がします。
それやるんだったら僕だったら、あれですねテンションチャートというか天気図みたいなものを組み合わせて、なんかこの時プロジェクトの進捗はいいけどみんなストレス溜まってたねとか。なんかまだ進捗上がりきってない時期だけど結構平和な気持ちで前向きにやれてたんだねとかっていうのをやりたいな。
いいっすね。なんかそのやっぱ感情とセットになるのって、なんか最近振り返りやっててもなんか結構いいなと思いながら。なんかデータとか事実だけ集めても、まあ感情もデータ事実の一個であるかもしれないけど。組み合わせるとなんかいい結果だけど満足してないって思ってるのか満足してるかとかでも全然やっぱ捉え方変わるなーって思ったりもするので。
感情的に満たされてる状態だったらまあ割と何でもうまくいくというか。ぬるま湯になってそうだったらハードル上げるのはそんなに難しくないので。 そうっすね。
スリップ図一つとってもいろいろ意味付け以上に読み込んだ話になってるかもしれないですけど今の。まあでもそうっすよね。なんか見る人それこそマインドモデルによってこれが何を表しているのか何を語っている、語りうるのかって全然違いますもんねっていうのを改めて思ったな。
そうっすね。じゃあまあちゃんとグラフを観察して意味付けできればバッチリなんですねって思ってると落とし穴があるんですねっていうのが次の章ですね。
そうですね。第6章は観察を意味付けする落とし穴っていう章ですね。
