00:04
きんじょうひでき
おだしょー ですね。26いきますか。カカシ。
ちょっと進んだ。
げんえい
カカシ。
きんじょうひでき
おだしょー でもな、24とかも好きなんだけどな。25も好きなんだけど。26はカカシっていう風なタイトルで、チームのメンバーはフィードバックと感想を早く意識出すために、平然とカカシソリューションを提供するっていうのが書かれていて、これはポジティブな方の、
グッドパターンの方として紹介されています。これは何かというと、とりあえずバージョンみたいなものでも、一旦待って出して、これ叩き台にしましょうよとか、フィードバック出してくださいみたいな風に言うと、そこからいろんな議論が回りやすくなるので、最初のバージョン、最初の叩き台みたいなところを早く出していきましょう。
不完全でもいいから、議論を進めるためにフィードバックを情報量を増やすためにやっていきましょうみたいなやつですね。
げんえい
そうですよね。早く見せないとフィードバックが来ないし、最後の最後で違うんだけどって言われて、もう一回やるのか、サングレースみたいなことがあると、それはやっぱり大変なんで、低コストで、たぶんカカシってなってるのはコストが低いってことですよね、きっとこれ作るのが。
きんじょうひでき
そう、カカシのニュアンスが分からなかったですよ。
げんえい
ハリボートですよね。
きんじょうひでき
そうですね、モックとかカンプですよね。
げんえい
カカシって向こうだったらもうちょっと他の意味があるのかな、もしかしたら。
きんじょうひでき
そうですよね、カカシとか泥団子とか言われても分からないですよね、我々。
げんえい
カカシとコマンドで、木の進発のことをカカシってすごい呼んでたような気がしますけど。
なるほど、なるほど、デクノボ的なニュアンスかな。
きんじょうひでき
マクドナルド理論みたいな感じだな。
げんえい
お昼ご飯何するって言ってとりあえずマクドナルドって言うと、みんな違うものをアイデアと。
きんじょうひでき
そうですね、意外とマクドナルドいいじゃんってなるかもしれないし。
げんえい
そう、月見バーガー食べたかったんだよね。
きんじょうひでき
そうそう、なんかハンバーガーではないかなってなった時に、
じゃあハンバーガーじゃないものが欲しいのかっていう内省が進んだりとか。
まあでもそうですね、この章というかこの本はアドレナリンジャンキーがやっぱり名前つけたとか、
響きの面白さっていうのが一個よりにしている価値だと思うんで、
っていうところで言うとカカシソリューションとかカカシモデルっていう風なことが書いてあって、
なんかちょっと使ってみたい響き、面白さを感じてました。
げんえい
そうですね、これでもうちょっと流行ってくれて、
現代にこの15年後にも残ってて欲しかったなっていうワードですね。
今は別になんかモックとかプロットタイプってしか基本言わないので。
03:01
きんじょうひでき
なんかおっさんサラリーマン用語みたいな位置づけになるかもしれない。
あの部長いつもカカシカカシとか言ってるけど、カカシってなんだよみたいな。
鉛筆なめなめとか話位置づけになるかもしれない。
げんえい
確かに。
きんじょうひでき
カカシソリューション、カカシモデル、カカシの哲学っていう不思議な言葉が出てくるそうだなって思いました。
げんえい
うん。
きんじょうひでき
はい。
げんえい
はい、じゃあ次はちょっとググっといて33ポーカーの夕べっていうところで、
これは職務に関係のない活動のために組織のあちこちから従業員が集まるという話で、
これはなんか業務時間外とかにオフィスとかで、
全然普段関わらない人たちが一緒にコミュニケーションを取る場がおのずと生まれてくるみたいな。
設定してもいいんですけど、設計してやってもいいんですけど、
業務外の人とかが交流があるっていうようなものっていうのがいいパターンとして取り上げられてますね。
いやー、めちゃくちゃいいなと思うんですよね。
昔、今はカルタホールディングスって名前ですけど、ボヤージュグループのアジトっていう名前にもついてた場所があって、
そこに人が集まってくるみたいな話を勉強会が行った時に、実際そのオフィスに行って話を聞いたことがあって、
いやー、こうやって仕事が終わっておのずと人が集まって勉強会が発生したりとか飲み会があったりとか、
そこで最近どうなのみたいな情報交換生まれてるんですよねって話を聞いてめちゃくちゃうらやましいなって思ったことがあって、
これを読んですごくそれを連想しましたね。
これ聞くと、国内というか我々の世代なのかどっちなのかわからないですけど、やっぱりアジトを想像しちゃいますよね。
きんじょうひでき
たまり場とか自由に取れる冷えたお酒みたいなのを用意しても結構うまくいかないがちじゃないですか。
今のゲイさんの話を聞いて、あ、ワークしてるんだなって思って。
ポトチャストのアジトFMっていうのがあると思うんですけど、
あの人たちはいつもプシュって缶を開ける音から始めていて、
あれはもしかしたらフィクションじゃなくて本当にそもそもそういうプシュの文化が社内にあったのかとか今ちょっとちらっと思ったりしました。
げんえい
そういうのって多分みんなどこもおかしくも考えて、
オフィスって単純な質問スペースじゃなくて交流スペースとか、バーを持ちたものを作ってみたりとかいろいろやってると思うんですけど、
あんまり成功してるって話を聞かないのか、ただ単に発信してないのか、本当に失敗してるのかどうなんだろうなとか。
06:07
げんえい
海外で行くとGoogleとかそういう綺麗なオフィスとか見ると、あれってオフィスにたまってほしくて、
すごい設備をいろいろ投資したりとか、無料でご飯を取っていいよとか多分やってると思うんですけど、
きんじょうひでき
どれくらい機能してるのかなって結構思ったりとか。
使う人が本当に限られて3、4人ですみたいになっちゃったりとかあるんじゃないかなっていう気はしますよね。
そこそこっていうか、結構ちゃんと大きい規模の会社だったら3、4人とかっていうことはないと思うんですけど、
いわゆるベンチャーぐらい、50人、100人ぐらいの会社でそういうことをやると、
げんえい
結構メンツが固定したりとか、そこから新しい交流っていうところまでは期待するほどいかなかったりしちゃうのかなとか思ったり。
きんじょうひでき
そうするとさっき品質の話出てたので、34のエセ品質ゲートいきますか。
これも結構名前からストレートに想像するようなものって言っていいんじゃないかなっていう気はしていて。
プロジェクトの品質保証担当は本当の品質向上には役に立たない形式チェックにとられているみたいな。
さっきげんさんも言ってたバグをゼロにするっていうことが目的になっちゃって、やたらコストが高くなったり、
すごい重厚なプロセスが生まれちゃったりとか。
あとは、昔あったんでチェックリストに入ってるけど、結局それは何のバグを潰してるんだみたいな。
っていうのがありがちかなとか。
げんえい
あとは文章構成の誤字脱字をチェックして学校を直しておいてみたいな。
いや、めちゃくちゃあったんだよな。
ドキュメントの間違い、送り金がないですとか言われて。
うーん、そうだねって。
高校の品質って言った時に、動いてるもの以外の付属しているものとかのチェックとかで、
すごい時間を取られた記憶が昔あって。
すごい辛くなってなかったなって思いながら。
きんじょうひでき
ドキュメントって言ってるのは別にお客さんに出す、お客さんっていうかエンドユーザーに出すものではなく、
社内とか開発で使うものとか。
げんえい
そうですね、発注元の納品の一部としてあるExcelにある詳細設計書だったりとか。
きんじょうひでき
なるほど。
げんえい
そうだねって、間違ってるねって思いながら。
きんじょうひでき
そうですね。
げんえい
でも本質的なところは何も言われていないなって思いながら、これでいいのかって。
すごい悩んでた1年目とか2年目くらいの時ですね。
きんじょうひでき
この34章をちょっと話してみたいなって思ったのが、
げんえさんがノーソンに書いてくれてるQAの人にいつも何を担保するためのエンドユーザー設計なのか、目的を聞くようにしてるって。
09:03
きんじょうひでき
これちょっと今、不意打ちで原文を読み上げちゃったんですけど。
ここの話ちょっと聞いてみたいなと思って。
これは何て言って聞けばいいんだろうな。
いいコミュニケーションを埋めているということですか。
げんえい
そうですね。
すごくいい話で、として聞いてもらってよくて。
性能試験とかをしたいって思った時に、メンバー数これぐらい、ユーザー数これぐらいで、
これぐらいの入力データが入っている想定として、
何かある画面を動かした時にこれぐらいで画面が表示されますよみたいな。
そういうことを仮にテストしたいとして、
じゃあそのユーザー数って1万人でいいですかとかってコミュニケーションが発生することがあるんですよね。
多いっていうことに対して、みんなの多いっていうのは数値が難しかったりするんですよね。
何をもっと多いとしますかみたいな。
きんじょうひでき
分かるな。似たやりとりしたな。
一定期間でこれパージした方が良くないですか、多くないですかって言ったら、
そんな多くないで大丈夫だと思いましたって言われて、
なるほど確かに多いってなんだよって感じだなって今話してたのを思い出しました。
げんえい
で、その時に結局その動作を担保したいって、
どういう顧客が使って、どういう操作をした時にこれがちゃんと動いているってことを担保したいんですかっていうことを問いかけると、
ある種テンプレートに沿って数を入れていくっていうこととか、
データベースから最大値を見て、これが最大値だから最大値をとりあえず入れてってやっていく作業に対して、
まさにこれエースで言うかどうかちょっと微妙ですけど、
何も考えずにテンプレートに沿ったテストをしていくっていうことから、
もうちょっと具体性を1個上げれると思うんですよね。
こういうお客さんがこういう場面でこういう風に使ってどうやって動作するってことを担保したいから、
こういうテストケースを考えました。
こういうデータ量でやろうと思いますっていう話になった瞬間に、
妥当性がみんなそれでいいんだっけとか、
それだったら問題なさそうだよねとか、
その顧客はきっとまだ使わないから段階的に出していくし、
一旦そこまでやらなくても、
つまり過剰品質を満たそうとしてないかとかっていうことが聞けたりとかして、
テストする時っていうのは何を目的にどういうことを担保してるんですかってことを
常に問いかけるようにしてるっていうのは、
割となんか自分の中でよくやってることというか。
いいですかって聞かれても、なかなかいいですって言いづらいんですよね。
いいっていうためには、要はレビューの観点が欲しい。
レビューの観点って考えた時に、どういう風なケースを想定していて、
それに対してこのテストケースで十分か、
必要十分なのかっていうことを言うためには、
12:01
げんえい
どういうことを考えてますかとか。
そこにそれさえ聞ければ、
これ漏れてるねっていうことの話ができたりもするだろうし、
ここの辺ちょっと充電的に見てほしいんだよねとか、
いうことが、
私やっぱりそこで一緒に受入れ基準をもう一回見直したりとかをして、
この観点ちょっと危なそうだね、ちょっと調べておくわとか。
そこをきっかけに結構品質を上げたり、
過剰品質を防いだりとかっていうことを結構見つけたりしてますね。
きんじょうひでき
なるほど、プロセスより対話をっていうのをいじり行く感じですね。
げんえい
そうですね、そうですね。
きんじょうひでき
なんかでも、今話聞いててちょっと頭よぎったのが、
単体テストの考え方使い方とかで出てくるような、
フォルスポジティブとかの考え方に近い気もしましたね。
要するに、このテスト項目がエラーになったとて、
じゃあそれでどういう風に困るんでしたっけとか、
何がダメなんでしたっけっていう答えが、
そのテスト項目は本当は持ってないみたいな、
それって擬応性じゃないですか、
なったけど対応する必要がないとか、
なったことに対して救われてる価値がないみたいな、
そういう風に繋がりましたね、僕の中で今。
げんえい
そうですね。
きんじょうひでき
意味のあるテスト多いもんなっていうのが、
なるほど、2A的なテストでも発生しているのかって。
げんえい
そうです。いっぱいありますよ。
100文字まで入るって言って101文字チェックするとかってやるけど、
ユーザー別に3文字しか入れんかみたいなこととか、
あると思うんですよね。
使われる境界値とシステム上の境界値って違うというか、
品質、ここまで担保できてればもう99%のユーザーは担保できますとかだったら、
そこだけやっとけばいったほうがいいでしょうとか、
そもそも仕様が間違ってるんじゃないっていうことにそこで気づけるとか、
ここまで担保する必要ありますかみたいな、
そういうのでどんどん今回気づいたら、
その次の時に受け入れ基準を見た時とかに、
ここってこんなに文字数入れますかねっていうことを言えるようになっていくし、
これ結構シフトレフトするためにすごくいいというか。
きんじょうひでき
なるほどな。
そうですよね。ちゃんと対話してみたら意外と考えて、
手に入れたい価値とか、実現したい目的っていうのが背景にあって、
そういうプロセスがあって出てきたアウトプット、
そしてこのチェックリストとかテスト項目があるよねって考えると、
その生み出した本人に聞いてみようかってなりますよね。
げんえい
うん。
きんじょうひでき
なんかどっかのカミソリとは逆だなみたいな。
じゃあ次行きますか。
げんえい
いやー35行きたいんだけどな。
なんかちょっと関連するしなと思って。
35はテストの前のテストって言って、
テストにはテスト以上の意味がある。
だからテストの前に始めるべきであるっていう。
なんか何を言ってるんだっていうような感じになってしまうんですけど、
15:02
げんえい
この章はテストの前にテストをするということは、
プロジェクトについて最初に話し合うときから品質管理を導入するということであるっていうので、
さっきの話とちょっとつながってくるかなと自分の中で結構思っていて、
最後にテストするっていうことじゃなくて、
最後にテストするのはいいんだけども、
それよりも前にもうちょっと品質について考えるタイミングを必要なんじゃないかというような話というふうに自分は思っていて、
てかまあそれって今まさにもうそういうことを言っているのがあって、
テストマニフェストっていうのがあったりとか、
最後にテストするよりもずっとテストし続けるとか、
バグの発見よりもバグの防止用とか、
機能性をチェックするよりもチームが理解している価値をテストしましょう、
システムを破壊するよりも最高のシステムを構築する、
テスター責任よりも品質に対するチームの責任っていうマニフェストがあったりとかして、
まさにもうこの35章の話が進化していって、
こういうマニフェストができたりとかしていて、
多分この話っていうのはアジャイルテスティングコンデンスドっていう本に書いてあるんで、
詳しくはそっちを読んでもらうといいんですけど、
だから自分は結構これを読んで、
最後にテストするだけがテストじゃないんだなっていうのもすごい発見というか、
結構衝撃だったんですよね。
その話を2009年にここで学びましたということですね、逆に言うと。
きんじょうひでき
なんかでもそうですよね、フェーズっていうのとかステップっていうのを区切って、
そこにある種最適化というか直所最大化したテストだからテストをクリアすることを考えますっていう風にやるんじゃなくて、
最終的にどうなりたいかっていうのをあらかじめ、もっと前の工程から考えていってやっていくと、
当然防止にもつながるし、無駄なものを省くっていうのにもつながるし、品質も上がりますよねみたいな。
話ですよね、シフトレフトとかそういうのがあると思うんですけど、
これでもなんかもっと大きい話で言うと、ユーザーがどういう気持ちで使ってるのかを考えながら普段コードを書くみたいなのとかも、
ある意味後のフェーズっていうのをどんどん手前に持ってくるっていう意味で言うと、
結局同じこと言ってるなみたいな。
げんえい
そうですね。
きんじょうひでき
これをチェックしましょうってチェックリストに書いてあるから、そういうチェックをしてグリーンになることを確認するのがテストフェーズですっていうんじゃなくて、
そもそもユーザーに価値を届けるためにソフトウェア開発、プロダクト開発してるんだから、
ユーザーにとって価値があるものができているかどうかっていうのを考えながら、
普段の開発とか設計とかバックログのリファイメントとかやってみようみたいな話。
18:01
きんじょうひでき
言うはやさしい、行うは堅しいみたいな感じはあるかもしれないですけど、
なかなかそうありたいんですよね。
げんえい
なんか昨今、エンジニアがユーザーインタビュー行くとか、
ドメインキャッチアップのために一回業務やってみるとか、
よく最近話を聞くようになってきたなとか思ったりしていて、
結局小さなチームで大きな成果を生もうと思ったらそれぐらいまでやらないと、
作ってるものの価値を最大化しようと思ったら無駄なものを作らないようにする。
無駄なものを作らないようにするためには、
プロダクトオーナーとかプロダクトマネージャーが、
これを作ればいいっていうものを支持するだけじゃ足りなくて、
エンジニアをもっと越した方がいいんじゃないかとか、
作る観点で言うとこっちの方が早かったりとか、
これをトレードにすると素早く出せるんだけどどうとか、
チームでそういうコミュニケーションがユーザーの状態というか、
ペインとかを見ながらそういうコミュニケーションを取れるチームっていうのは、
やっぱり強いんだろうなって思ったりとかしますね。
きんじょうひでき
そうですね、小さなチームで大きな成果っていうと、
フレームワークあれですねみたいな感じがしちゃいますけど、
目的論というか最終的に得たいものってこれだよねっていう視点に立って考えると、
うちの部署の仕事はこれだからとか、2Aの人がこれ言ってるからみたいな、
結構固定的な観念から抜け出せるっていうか、
変更可能な変数がどれかっていうのを見極める考え方が変わってくるよね、
みたいな話はある気はしますよね。
だからテスター2Aの人の気持ちになって、
そういう人の見方とか考え方、気持ち、感じ方っていうのを取り入れながら開発すると、
あれ、こんなことやらなくてよくないとか、
もっとこうしたら楽じゃね、ハッピーじゃね、みたいな風になっていったりとか、
ユーザー目線っていうのはそれやるための最大の武器だなって思ったりとか、
そんなことを今聞きながら感じましたね。
げんえい
ブロッコリーさんっていう方が、QAっていうのは創造的な仕事なんだっていう話を、
どっかブログに書いてたんですけど、今ちょっとパッと出せないんですけど、
何をテストしたらいいかということを探索しないといけないから、
ユーザーにどんどん疑問を投げかけるんですよね。
例えば返品処理があったときに、返品したときにどうなってないといけないですかって聞くと、
レジの中にお金が戻ってないといけなくてとかって言って、
それでその後他に何するんですか、作業はとかっていろいろ聞いていくと、
在庫の数をプラス1しないといけなくてとかいうことをどんどん質問していくことによって、
何を担保しないといけないかを見つけていく。
つまりそこで出てくるものっていうのは、多分キーになるものが絶対いっぱい出てくるはずで、
そういうものを早く見つけて、それをテストするよってエンジニアに伝えておくと、
21:03
げんえい
エンジニアがこうテストされるから、ユニットテスト集めにとかフィーチャーテスト集めにとか、
動いてることをちゃんと担保しないといけないなってなるわけだから、
そうすると多分不具合も全然出なくて、ユーザーにとって必要な価値の高いものが出てくるはずっていうふうな話をしていて。
きんじょうひでき
ここはテストに出るぞっていうのを聞きながら授業を聞いていくと無駄がないんですよね。
げんえい
っていうので、全然QAって俺が思ってたものと全然違うんだっていうことを、
ブロッコリーさんのスライドとか非常に見ながら、チームでもやっぱりブロッコリーさんのスライド見ながら、
自分たちがやってることっていうのはまだまだもっといろんなことができるし、
ユーザーに話を聞いていくことが大事だなとか、じゃあユーザーに聞いてみようとか、ユーザーの業務実際やってみようとか、
そういうようなところでどうやって品質を担保していきますかみたいな話とかできるようになったりとかしていて、
非常にこの辺大事だなって思ったりしてます。
きんじょうひでき
そうですね。何がどうなったら困りますかねとか、こういうことが起きたときにどういうことをアクションとして取れますかねみたいな、
そういう理解・解像度・想像力みたいなものを持って行動を書いていくと、
ログに何を残すかとかどういうログ欲しいかとかっていうのがめっちゃ変わってくるんじゃねっていうのを、
どっかのプロポーザーで出してみようかなって最近考えてます。
げんえい
そうなんですよね。ログはまさに本当にそうで、
どう使われてこのリカバリを今すぐしないといけないのかとか、これ別に明日でいいかとかって、
多分ソースコード書いてる中だけでは判断がつかないんですよね。
実際そのどういう業務をやってるかっていうことを想像しながら、
いやこれはなんか今日こけても別に月末までにしまってればいいですとかいうことが分かってるだけで取れる選択肢はどんどん増えていく。
きんじょうひでき
あとね、CSの人にどういう問い合わせくること多いですかっていうのを聞いて、
もしくはエンジニアにエスカレーションされてきたものを過去ログとか見ていくと、
あ、この一両にこのIDとここのIDがちゃんと分かれてたら、
なんかもう瞬殺で対応できるじゃんみたいなことを思ったりとかありますもんね。
げんえい
そうなんですよ。そうなんですよ。
いやー、これでたぶん1本取れるんじゃない?たぶんすごい。
きんじょうひでき
やばいな。え、83本取りますか、じゃあ。
げんえい
いやー、この辺はね。
きんじょうひでき
次行きますか、じゃあ。
げんえい
次行きますか。いくらでも反省するな。
きんじょうひでき
いやー、36も行きたかったんですけど、さすがに伸ばしていくか。
いやー、サイドハウスルールっていうのがね、なんか運営の法則とか、
なんか人事部のやってる労務管理と普段のめんどくささみたいなものって対立しがちだよねとかって話を思ったりとかしたんですけど、
44に行きますか。
やっと10個近く飛ばした。
あとですね、ブルーゾーンっていう話ですね。
24:02
きんじょうひでき
レッドゾーンの逆のブルー、あ、レッドゾーンの逆でもないのか。
まあまあまあ、説明があるんですが、これはアンチパターンではないはず。
げんえい
そうですね。
きんじょうひでき
まあ、グッドパターンだと思ってて、権限を超越して好きなことをやっちゃうやついるよねみたいなニュアンスだけで書かれてるわけじゃなくて、
言われたことしかやりませんにならずに、なんかこれも必要じゃねとか、あれこれ誰もやってなくねって気づいたら、
まあ手を出して、手を動かしてやっていくみたいな、そういうゾーンで動いてる人いるよね的なことを書いてあって、
その悪い意味での越見行為とか、他の人と責務とか業務とか仕事でコンリクトしちゃうような動き、そこまで手を出しちゃうっていうのはレッドゾーンっていうふうに言われていて、
でまあそうですね、レッドゾーンよりも内側にあるブルーゾーンっていうのをちゃんと視界に捉えて動いてくれるっていう人っていいメンバーだよねとか、
そういう動きができるチームはいいチームだよねみたいな話が書かれていて。
げんえい
いやーめっちゃわかりますねこれは。
いやーこういう人がいるから多分チームってこううまく回るような気もしていて、多分なんかこう遂行するためのことを全てやるっていうのって、
やるべきことを全部遂行したら終わるっていうのは本当に作業が明確でわかりきっている時だけだと思っていて、大体やってみたらうまくいかないことが多いわけじゃないですか。
なので多分こういう、それは言われてないけどここまでやんないと、さっきの話に続けていくとユーザーが満足するものできないんだから必要でしょって言って手を出すような人がいないとなんかタスクは終わったかもしれないけど、
結果がついてこなかったりとかするよなーとか思ったりとか普通に思ったりしましたね。
きんじょうひでき
そうですね。なんかこれ自分の話をすると僕結構このブルーゾーンみたいなものが、ブルーゾーンで活動するみたいなのがなんか割とこう苦手な方だと思ってて、
なぜ自分がこれをやるのかっていう理屈っていうのがすっかり踏み落ちた時にパワーを発揮しやすいタイプだなーっていう風に結構前にアセスメントとか受けて思ったんですけど、
なんかですね、それで前職が結構テックリードになってEMになってVPOEになってみたいななんか上が薄くなっていったんです。
ってなるとなんかすげーやりやすくて、何でかっていうとこれ俺の仕事じゃなくてもっと上の人が考えてるんじゃねって疑える余白がなくなっていくんですよ。
あ、これ自分が全部やらなきゃダメかみたいな。じゃあやるかみたいな。
っていうのがあって、なんかこうブルーゾーン、この本で言うとグリーンゾーンっていう与えられた仕事と手を出してはいけないっていうさっき言ったレッドゾーンとその間にブルーゾーンがあるよりみたいな、
27:11
きんじょうひでき
3層構造で話してるんですけど、なんかブルーゾーンがみるみる薄くなっていて、グリーンゾーンがめちゃくちゃ広がりまくってるように見えた時に、
自分で考えた仕事っていうのがすげー楽しいなーっていう風になったんで、
そうした方が仕事が楽になるみたいな体験をしてたんですけど。
なるほどね。
はい。いや、いいんですよね。だから結構文句が多いやつマネージャーにしたら面白えんだろうなみたいな。
お前今言っているやつ、次のクォーターから全部お前に自分でブーメラン帰ってくるからなみたいな気持ちでリーダー任命したりとかしてたのがあって、
なんかこのブルーゾーン、グリーンゾーン、レッドゾーンって考え方面白いなって思ったり。
げんえい
そうですね。
いやなんかあんまこういう風にブルーゾーン、グリーンゾーン、レッドゾーンって考えたことなかったなーって思いながら、
明確にこれ期待されてるってことと、これは期待してないよとか、これはやらなくていいよって言われてることと、
その間にあるものがあるってことは、もちろんなんとなく思ってはいるものの、
なるほど、こういう風にちゃんと言語化されるとすごいわかりやすいなって、このショーは思いましたね。
きんじょうひでき
あとなんか僕がこのショーに反応したのが、マネジメント3.0っていう考え方というか、
フレーマークみたいなものがあって、そこのファンデーションレベル、基本レベルの研修を受けたことがあるんですけど、
研修というかワークショップというか、それでマネージャーが失敗するときって、
どこまでやってほしいかっていうのを伝えたつもりでもうまく伝わってないとか、
あなたはここまでやっていいですよっていうボーダーライン、境界線がここにあるからギリギリまで踏み込んでいいですよみたいな、
っていうのを示すのが下手なのが結構マネージャー多いとか、そういうことができないと、
自律的なチームっていうのを育んでいくっていうのが、どんどんどんどん難しくなっていくよねみたいな話があってですね。
なるほど、耳が痛いですね。
げんえい
これ実際に研修で使われたスライドとほぼ同じ内容のがスライドして上がってて、
きんじょうひでき
牧場みたいな馬とか羊とかがいる空間で柵が敷いてあって、
こういう柵をあなたのマネジメントとか権限移情とかする際にちゃんと所有できてますかっていうような話があって、
そのイメージがなるほどわかりやすいなみたいな。柵がない、もしくは柵が見えてない状態だと怖くなって動けなくなっちゃうようで、
げんえい
でも柵が明確にあるとギリギリまで行ってやってくれるじゃんみたいなっていうのがあって。
いやー、これ確か今のいろいろな話を通すと、与えられた権限移情にいろんなことをやってくれるメンバーがいるっていうことも大事だし、
30:07
げんえい
そういうことをやりたいと思っている人に権限を渡すとか、ある種ブルーゾーン、グリーンゾーンを広げてあげるみたいな動きができると、
割と組織全体としてうまくいくのかなっていうのをちょっと思ったりしましたね。
きんじょうひでき
やっぱりね、やる気があって威力がある奴には好きにやらせた方がいいんで。
ハンターハンターの黒の団長も、「よし、みんな行くぞ!」ってなった時に大暴れって言ったわけじゃないですか。
確かに。
やっぱりね、大暴れしていいんだなって思わせると自律的に両団のメンバーが動き始めたりとかしてたんで。
げんえい
いやー、たった3ページだけどすごいいい話が詰まっている。
きんじょうひでき
いいですね。
じゃあまたげんえいさんのピックに。
げんえい
じゃあちょっと一個しか進まなくて、ただこれサクッといきたいんですけど。
A45社のニュースの改良っていうので、悪いニュースが組織の下から上へ正確に伝わらないって言って、
写真ではチームリーダーは、おそらく1月は無理ですねって言って、プロジェクトマネージャーは正直って1月では普段ですねって言って、
アプリケーションマネージャーの上司は、1月というのは難題だとは思いますがって言って、
CIOのところには1月に間に合うと自信を持ってご報告できますって言って、下から上に上がりにつれて悲観具合がどんどんどんどん下がっていきっていう話で、
もうこれを見た瞬間にイラスト屋で耳打ちをして、最終的に大助ですって可能ですっていう絵を思い浮かべてしまってめちゃくちゃ笑ってしまいました。
きんじょうひでき
僕もこの章を読んだ時に、あれじゃんって思ってノーションに貼りに来たんですけど、
ゲイさんのコメントでするに書いてあって、ああだよねそうなるよねみたいな。
げんえい
俺はこの画像を探して見つけられなくて、とりあえずテキストで書いとこうと思って、テキストで書いてました。
きんじょうひでき
これのオリジナルがわかんないですよね。なんかいろんなバリエーションというか、みんな相関してすぎて各々作ってる感じがあり。
げんえい
究極の出典はどこなんだっていう。
きんじょうひでき
そうですね。あとエンジニアが技術的には可能ですっていう。やりますっていうふうに解釈されるから、気をつけねばならぬみたいなね。
げんえい
そうね。
きんじょうひでき
プロジェクト言葉みたいなやつが言われたりしてますけど。
げんえい
まあでも難しいですね。無理ですっていう。この文脈で無理ですって言ってるのが、いろいろこう説明をした結果無理ですって言ってることであるのかもしれないけど。
どう伝えるとうまくいくのかなっていうのは結構難しいですよね。
33:05
げんえい
伝言ゲームにならないようにするっていうのが一個の方法ではあるんだけども。
きんじょうひでき
この45章、ニュースの改良っていう名前がついてますけど、悪いニュースは上がってきづらいよねっていう背景がそもそもあるよね的なことが書いてあって。
悪いニュースは伝わりづらいし、いいニュース側に改良されて伝言ゲームになってしまうみたいな話がある中で。
この章は対処法をどうするかみたいなところを少し章の後半で踏み込んでますね。
げんえい
そうですね。しかもチャレンジャー打ち上げの話があったりするんで、そこから我々は結構人類は学んでいるからっていうのもあるような気がしますね。
きんじょうひでき
失敗の方針とかそういう話でしかないからな。
げんえい
そうそうそう。というイラスト屋の話がしたかったんだけど。
きんじょうひでき
いやちょっとねイラスト屋の話触れざるを得ないですよね。
げんえい
そうですね。じゃあ次行きますか。
きんじょうひでき
これどうしよっかな46か、47か52、47進んでないんですけど、ちょっとちらっといっていいですか。
これ47、エンドゲームの練習っていう風に書かれていて、エンドゲームって映画であった気がするんですがそれとは関係ないはず。
げんえい
そうですね。
きんじょうひでき
チームは開発期間中一定の間隔で作りかけの製品をリリース基準と照らし合わせるみたいなことが書いてあるんですけど、
3ヶ月のプロジェクトですって言った時に3ヶ月後に全部まとめて大答え合わせしますっていう風にするんじゃなくて、
中間チェックポイント作りましょうよとか、今の状態でリリース本当にできるんだっけっていうのは適宜。
げんえい
頻繁にというか1回きりの答え合わせにしないでよそよそで見ていきましょうよみたいな話。
きんじょうひでき
そういうのがアンチパターンだとしてエンドゲームの練習っていうのはプロジェクト期間中にリリース可能かどうかチェック基準に照らし合わせてやっていこうっていうグッドパターンとして持っていってますね。
だからスクリームとかで言うとスプリントレビューがこれに当たるはず。
げんえい
そうですね。スプリント出荷可能なインクリメントを積み上げていって、スプリントレビューではスティックホルダーと議論をしてその結果計画を変えたりとか変化に影響していきましょうと。
ということをやってれば多分ここってそうだよねって話で終わるし、やってなくて3ヶ月後に突然リリースするぞだと多分失敗しますね。多くは。
きんじょうひでき
僕がこの章を話したいというか紹介したいなって思ったのがここに書いてある内容自体本文としてはそんなにスクラムっていうのをした後にこの本を読むと今言ったリリース可能なものをちゃんとインクリメンタルにって話なんでそんなに目新しいことはないなとか思うんですけど知ってる話。
36:18
きんじょうひでき
なんか違う表現に聞いたことがあるなと思って。ただこれ名前がエンドゲームの練習っていうのがちょっとビビッときてですね。出荷可能ですかみたいな聞き方をしても正直ちょっと緩い。つまりどういうことなんだっていうふうに思ってたんですけど。
エンドゲームは本当に週末みたいな終わりの方の週末っていうのが迫っていたとしたら何を選びますかみたいな世界が滅びるとしたらどのプロジェクトバックログを実装しますかみたいな話だとすると。
そんな状態でプロダクトバックログとかだりなんですけど。なんか来週にはもうこのプロジェクトのチームは解散なのでコードはいじれません。あと一週間何しますかみたいな問いかけにすると少し見え方変わってきそうだなっていうのをエンドゲームっていうかなり強い言葉で表現されてたんでなんかそういうふうにプロダクトとかスコープっていうのを見ていったらいいのかもなとかちょっと思ったっていう感じですね。
僕の感想を共有したくて47章を拾いました。
げんえい
よくチームメンバーに俺は言ってるんですけど、これ明日リリースしようよって言ったらリリースできるようになってないとダメだよっていう話をよくするんですよね。実際機能としてここまでできてないからどうせリリースしないでしょってやっぱ思っちゃうし、それは自分が作ってる時はやっぱそう思うし。
けどテイクホルダーがこれでいいじゃん。ここまでできたらもうお客さんに見せたいし使ってもらいたいからこれ出そうよって言われた時にはもう出すぞってできる?わかりましたって言ってできるようになったらダメなんだよって話をしていていつそれがムキ打ちでテストとしてくるかわかんないように思いながら作っておかないと。
もしかしてやらなくていい仕事をやっちゃってるかもしれないし、優先度が低いものをやっちゃってるとか、後回しにした結果いやリリースできないっすみたいなバグが残っちゃってるとかいうことが大きい。兼ねないと思ったりするんで、そういう問いかけみたいなのはある程度チームにしておかないとプロジェクトが長くなればなるほどちょっと緊張感もなくなり、程よい緊張感を持っておかないといけないのかなって思ったりしますね。
きんじょうひでき
いいですね。僕が思ったことはすでにゲイさんが実践してるんだなって思いました。
げんえい
問いかけをしたからといって返事が出てくるかどうかはまた別だったりとか、チームの技量によってそうは言うてもさみたいな。一個イントリメントを作るためにパフォーマンステストまで全部やらないといけないんですかとかって言われると、まあ確かにそれは大変よなってなっちゃうんでね。
39:00
きんじょうひでき
そうですね。それはね、またさっきのQAエセ品質ゲートになりそうな。そんなところでまたゲイさんは次は。
げんえい
じゃあ50番風石っていうところですかね。これは何かっていうと、ユーザーエクスペリエンス全体を考えコンセプトの統一性を図る人がいないっていう話で、思ったのはこの2009年2008年9年ぐらいの時点でこの本を書いてる時には、もしかしたらUXの話って全然されてなかったのかなとか。
やっぱりプロダクトマネージャーって言葉って、やっぱり結構最近言われたんだなってことを実感しましたね。本当に最近の概念なんだなっていう。もちろんあったかもしれないけど、それが一般的にチームに1人は当たり前にいるみたいなプロダクトマネージャー。チームだったり会社にある事業部の中にいるっていうのが当たり前っていう感じではなかったんだなっていうのをちょっと思ったりしました。
きんじょうひでき
そうですね。2009年だとXPとかスクラムとかももちろんあった時代だとは思うんですけど。でもそうですよね。アジャイドマニフェストとか見てもユーザーが、ユーザーっていうのはエンドユーザーも発注者、ステイコハルダーも含むと思うんですけど、その人たちとの距離が遠いのって害だよね。損失だよねっていうのにまだまだ気づけてない。
気づけてないことをやっていないっていうのが当たり前だみたいな時代背景はやっぱりあったんだろうなっていう気はしますし。
契約書とか計画に従うことっていうのが何かを作ることですみたいな。っていうののアンチテージとしてアジャイドマニフェスト出てきたと思うんで。
そうですね。契約交渉よりもコタクとの協調をとか、計画に従うことよりも変化への対応っていうのが書いてあるんで。
それをわざわざ言わなきゃいけないっていうのはやっぱりプロダクトマネージャーとかプロダクトオーナーとかっていうのがいなかった。
旧席になってた。そんな席があることすらみんな気づいてなかった。
げんえい
誰かが肩代わりで仕事はしてたんだけども、それをもうちょっと重点的にそういう仕事を中心としてやらないと、コードを書いてうまく作っていけるようにはなりつつあるんだけども、一歩足りないみたいな状態が多分、
プロダクトたちのチームがいろんな現場を見た感じではそういうふうに感じたのかなっていう気配はある。
でも2009年でしょ。iPhone出てきた直後とかって考えると、確かにそんな感じじゃないのかなみたいな。
きんじょうひでき
一応、この本の中で書かれているのは、小作は対象領域について詳しいドメイン情報を提供してくれるが、サブプロジェクトごとに別々のドメインエキスパートが任命される。
42:07
きんじょうひでき
そしてこれらのドメインエキスパートは仲間の誰が同じプロジェクトの別の部分で仕事をしているかもしれないことがあるっていう感じなんで、
小作、オンサイト小作みたいな人とかドメインエキスパートは提供してくれるけど、本当にプロダクト全体ということの統一性っていうのがないよねみたいな話。
契約書とか計画に従うよりかは進んでるかもしれないけど、まだまだだねみたいなところですかね。
げんえい
これが多分今はもうちょっと解消されてるはずってことですよね、きっと。
考えるには少なくなっているはず。
うまくいってるかどうかは、難しいと思うんですよね、そもそも難しくて。難しい問題だけが残り、それを頑張って何とかしますって言ってるのがプロダクトマネージャーだったりするような気もするので、難しい問題は残ってて、うまくできるかどうかはまた別の話って感じでもあるな。
きんじょうひでき
そうですね。通信とかやってると収益化チームとユーザーグロース扱うようなチームでやりたいことが違うみたいな。
そうですね。
検索結果に広告を入れるVS検索結果に広告を開けそうだみたいな。そこがハグになっていったりとかね。
げんえい
そういうような話のことです。
