1. readline.fm
  2. EP015 『アドレナリンジャンキ..
2024-06-28 29:42

EP015 『アドレナリンジャンキー』PART2

今回は『アドレナリンジャンキー』の「魂を貸す」「ベンチに人なし」「どうしてミケランジェロになれないんだ?」「ダッシュボード」を読んだ感想を話しました。

## 取り上げた本

⁠『アドレナリンジャンキー』⁠ トム・デマルコ、ピーター・フルシュカ、ティム・リスター、スティーブ・マクメナミン、スザンヌ&ジェームズ・ロバートソン 日経BP 2009年


## shownote

https://gennei.notion.site/EP015-PART2-87cb495dd04841d9a171f90b927d9c8b?pvs=4

サマリー

魂を貸すという話と、ベンチに人なしのパターンについて考察されています。規模の異なるチームにおいて、ダッシュボードを活用することで共通指標を持ち、チームメンバーの意識統一や問題解決の促進が可能となります。また、ミケランジェロになれない理由や、お金の使い方についても考察され、マネリテラシーの重要性が示されています。ダッシュボードについての議論と意見交換を通じて、チームのメンバーが自身の関心領域やオーナーシップを発揮できるフィールドを広げることが重要であり、ダッシュボードを使った情報の可視化と活用方法について考察しています。

魂を貸す
げんえい
じゃあ、次、サクサクいきますか。次は、キッドさんどれにしますか。
きんじょうひでき
そうですね。9か11で迷ってるんですが、11いきますか。
魂を貸すっていう話があって、これは、グッドパターンの方のニュアンスで、こういうのが敵であるっていうふうに書かれてあると思うんですけど、
これ、プロは技術に魂を売らず、魂を貸すっていうふうなことが書いてあって、
何て言うんですかね、なんか昔やったやり方でそのままやってしまうっていうのがもう、なんか技術ありきり技術選定するみたいな、そういうのが魂を売ってる状態。
だとしたら、魂を貸すっていうのは、新しいイケてる技術っていうのを、なんかしっかり評価して、めちゃくちゃ頼って活用しまくってみるんですけど、
魂売ってなくて、貸せるだけなので、いつでも取り返せるみたいな、もっといい技術があったらちゃんとそこ行きましょうみたいな、
なんかね、そういう話が書いてあって、何て言うんですかね、これ振り分け選定とかはすごいこういうスタンス大事だろうなと思ってて、
なんか最近は、最近はとか言うとあれなのかな、意味もないし言われもないのにやったら老人ぶってる感じの発言になったんですけど、
クリーンアーキテクターとかドメイン層を保護しましょうとか、コアドメインをどうするかみたいな話があって、フレームワークと隔離すべきであるみたいなやつはまあ一般的にというか当然大事だなと思うんですけど、
そういう話が出てきた時に、なんか僕は結構言うてフレームワークを骨の髄まで使いこなった方がコードのクオリティも上がるし、スピードももちろん上がるし、
学習コストも何らかんら下がるんじゃないみたいな、ではあるんです。チームとか状況によるんですけど、個人でやるとケーキPHPが好きなんで、
ケーキスタウンだったらケーキっぽい書き方すればそっちの方がすっかりハマるじゃんみたいな感じのところがあり、
これは別に魂を売ってるっていうよりかは魂を貸すっていうことでありたいなと思いながら、魂を売ると魂を貸すっていう対比なので、
魂を貸すっていう方がすごいアサイライトな感じかなって思うんですけど、冷静に考えたら魂を貸すってとんでもないことをしているのが、
開約オプション付きで悪魔と契約してるみたいな感じがして、ここは技術に対する態度みたいなところで、
表面的に良いものを選んでいきましょう、いろいろなものに飛び散っていきましょうじゃなくて、魂を貸すぐらいの覚悟、
げんえい
しっかり自分の道具とかそれを使うことのリスクに対して真摯に向き合っていって、ちゃんとディープダイブするみたいなところが必要なのかなっていうふうなニュアンスもワーディングから受けて、
きんじょうひでき
なるほどなーって思いながら、ちょっと印象に残った章ですかっていう話でございました。
げんえい
そうですね、この魂を貸すの37ページの最後とか、大事なのはこの技術は何に適してるかであって、どうしたらこの技術でこの問題を解決できるかではないっていう話があって、
そうなんですよね、やっぱり我々なんかの問題を解決するために基本的には技術選定をしたりとか、
今このメンバーでどういうものを使ってどうやったら早く問題が解決できるか、内緒は早くだったりとか長期的にだったりとかかもしれないですけど、
で、問題と解決策を区別できることは魂を貸すものになるための第一歩であるっていう話もその後に書いてあって、
いやなんかこうすごく自分は良いなーって思ったりとかしましたね。
きんじょうひでき
うんうんうん。
げんえい
やっぱなんかさっきのケークとか、自分だとララベルとか、いろんなレベルを考えてると、せっかくこういろいろ用意されてるのに自前で作っちゃうといろいろ大変になったりとか、
どういうバランスを取るかっていうのはまあなかなか難しいものはあると思うんですけど、なんか自分でこの問題を解くためにじゃあやっぱクリーンアーキテクチャーでみたいなこう、
みたいなことをこうやり始めると、なんかそれはこうやっぱ目的と手段が入れ替わってるような気も、あのもちろんマッチする場合もあるんで全てが全てじゃないと思いますけど、
そういうような場合もあったりとかするし、なんかそもそもそういうことをやりたいんだったらPHPじゃないゲームを使った方がいいんじゃないっていうケースがあったりとかするような、すごいすごい思いますね。
きんじょうひでき
うんうんうん。そうなんですよね。じゃあ、げんえいさん次何か。なんか交互に指名するみたいな形式で。
げんえい
じゃあ次は13章ですかね、こう2人とも聞いて。
ベンチに人なし
きんじょうひでき
あーこれね、はい。
げんえい
13章はベンチに人なしっていうパターンで、組織をスリム化しすぎて重要なメンバーが1人欠けたら破綻するっていうとこですね。
なのでチームでちょっとこの人しばらくお休みに入りますみたいになった瞬間に、え、終わったわみたいな。
っていう状況が、人件費を削って組織を筋肉質にみたいなことをやっていくと、あるタイミングではぶつかる問題で。
言ってることは、ベンチに人がいなくてフィールドに立ってる選手が1人でも怪我したら終わるみたいなのって、
よくない状態だと思いながら、でも一方でベンチに人を抱えるって結構やっぱ難しいと思うんですよね。
サッカーとかで言うと、11人フィールドに立っていて、この人しかサッカーの試合に出ないってなってたら、その11人のマネジメントをすればいいんだけども、
ベンチに人が集めた瞬間に誰をベンチにするかってことを考えないといけないとか、そのベンチの人が実力がないから試合に出られないって言った時にモチベーションが下がっていくことも気にしないといけないしとか、
突然問題が難しくなるような気がするんですよね。1人増えるだけで、人が1人増えた以上の問題の難しさになるような部下っていうのを、
組織においても多分、例えばここが新卒だったら育成のことを考えないといけないしとか、
ある種、もしかしたら仕事が手が空いてしまうから、なんか仕事を作らなきゃみたいなこととかってたまにあったりする気がするんですけど、
大体それって作っちゃダメじゃないですか、アンチパターンじゃないですか、この人のために仕事を作ろうって、何かが間違ってる状態だと思うんで、
なかなかこう、ベンチに人を抱えるっていう、理想っちゃ理想だと思うんですよね。入れ替わっても同じぐらい成果が出せる人をもう1人抱えておくとかって、
そんな上手くいかねえよなっていうのは、すごく思ったりとかして、面白いパターン見えたなっていう。
なんかこれグッと、いいとも悪いともどっちとも取れるような名前だなって自分は結構思ったりしましたね。
きんじょうひでき
なんか今の源永さんのお話聞いてて、別のパターンとしてここから派生して、ベンチ育成みたいな話もできそうだなっていう気がして。
げんえい
そうですね。
きんじょうひでき
最近やってないんでわかんないですけど、初代のポケモンとかって経験値を稼ぐために1人、育成中のレベルが低いやつを先頭に置いておいて、
げんえい
バトル始まると最初にそいつが出るんですけど、1ターン目で本命のリザーノンとかと交換して、倒したらでも平等に経験値入りますみたいな。
試合に、ベンチに入っているだけだと基本的に経験値済まないので、やっぱり試合に出さなきゃいけないみたいな。
きんじょうひでき
そうせないとスタミナとの差が開く一方で、結局使い物にならない。おかかえのコストだけかかってくるみたいな話とかもあるんで、ベンチ育成っていうパターンいけんじゃないかなって思う。
げんえい
で今度それに対して、育成しながら普段と変わらないスピードを出せ。ないしは人間比が増えてるんだから早くしろとかっていう、上からプレッシャーを上げるとさらに辛みが増していくみたいな感じがしますね。
きんじょうひでき
僕がノーションに、この13章ベンチに人なしのところでメモってるのが、じゃあ使いやすいベンチ、もしくはベンチ育成ができればいいんだよなみたいなところ。現実的に対処方法どうするのがいいんだろうかみたいな話で。
ペアプロをやりながら、ホットスタンバイをちゃんとウォーミングアップさせとくみたいな話で。これはさっきゲイさんが言ってたような、評価コストを2人分の人件費に対してちゃんと2倍のアウトプットが出てるかっていうふうにはなりづらいかもしれないけど。
ペアプロとかモブプロは難しいですけどね、評価するのが。どういうふうに軽量化できるのか難しいんですけど、となくともここのコードをいじっている人が1人しかいないのでできませんみたいな技術力の差じゃなくて、コードに対する知識量の差っていうのはある程度埋められるというか、日常的に普段の仕事の中で知識交換が行われてるっていうふうになってくると、
これは1個ベンチに人を置いておくパターンだなぁとか思ったりとか。あとはもうなんでもできる消し専門部隊みたいな人をテックリードとかICとして置いておくとか。
データベースとかはね、普通にDBREとかDBAとかの人が困った時に呼んだら解決してくれるみたいなチームとか個人として確立されたりしがちだなと思うんですけど、なんかチートポニーもそういうパターンある気がしますけど、アプリケーションってなかなかそういうふうにならないですね。
困った時に特能的に対応してくれる消防隊ですみたいな人を1人浮かべて囲っておきましょうみたいな。なりづらいですよね。
げんえい
そうですね。なんか囲ってる余裕があるんだったらもう1チーム作りたくなり始めるんですかね。
機能を増やしたいとか作りたいとかっていうのは多分改善に手が回ってないんだから、あれもこれも多分十分になるっていうことってなんかあんま経験じゃないんです。人が足りてますって、組織全体として人が足りてますって、あんまり多分運用フェーズとか本当にもう機能開発止めてますみたいな場合はあるかもしれないですけど。
だいたいサービスを拡充していくって言った時は手足りないって言ってる時しか思い浮かばないからなって思ったりすると、ベンチに座らせてた人をなぜかフッと引き抜かれ、向こうでもう1個チーム作ってくれるみたいなことが起きがちかなっていう気がしたりとかします。
きんじょうひでき
だからあれですよね、リソースってなんていうか、パーキーソンの法則って時間があったら時間ギリギリまでやらないとか使ってしまうみたいな、余計な本来は削れるようなところにこだわりすぎちゃう、リカインパイ使っちゃうみたいな話とかと一緒で、人がいたらその分だけあれもできるんじゃねって言って解きたい課題とかバックログ増やしがちなんだろうなみたいな気はしますよね。
エンジニアだけじゃなくて、プロジェクトマネージャーも結局愚かな人類なんだなみたいな気はしますね。
げんえい
基本的にリソースっていう観点でプライドした時って、やっぱ浮いてる、我々のCPU余ってるなって思ったらインスタンスサイズ下げたくなったりするし、なんか遊んでるんだったら。
それはお金かかってるからそうするよね。人気人もかかってるわけで、でもそうすると結局何かさせたくなってくるし、なんかサイズを下げるとか、このマルチリージョンはいるのかみたいなとか。
きんじょうひでき
やだな、胸に刺さりますね。
げんえい
とかっていうことと、ある種パラレルの話題だなと思いながら、このショーの最後とかは、なんで余計に人を抱えておく必要があるのかっていった時に、誰かが抜けた時に次の人を探すための時間がめちゃくちゃかかるので、
そのところを時間をかけずに次の人をすぐパッとアサインできる。ないしはもう用意ができている状態になっているっていうのがいいんだよって話が書かれていて、まあ確かになみたいな。でもこれがどれくらい人が入れ替わりませんかっていうのはわからないですからね、なかなか。
きんじょうひでき
そうですね。キャパプラなしでリザーブドインスタンス買うわけにいかないですからね。
なるほどな。そこら辺がベンチに人なしっていうラベルでこういうことあるでしょっていう風に語られていると。
げんえい
そういうことです。面白いですね。
面白いですね。
きんじょうひでき
面白いですね。
げんえい
じゃあ次は何しましょうか。
ミケランジェロになれない理由
きんじょうひでき
これそうですね。名前が面白いっていう観点で、15章ですかね。どうしてミケランジェロになれないんだっていう通にセリフ調の名前がついてるんですけど、これはミケランジェロって言ってるのはもちろん才能のある芸術作品を作れるアーティスト。
で、なぜそれになれないんだって言ってるのは、道具を渡したから同じ道具使ってるんならできるんじゃないの。なんで君は道具があるのにミケランジェロみたいな彫刻を作れない。彫刻ですよね、ミケランジェロ。
げんえい
彫刻だと思いますね。
きんじょうひでき
まあまあ芸術作品を作れないみたいな。っていうのがよくありませんかみたいな。
次の話と関連して言うと、プログラマー3人連れてきたんだからもうそんな簡単にできるでしょみたいな。リピネーションしちゃったよみたいな。いやその3人はちょっと申し上げにくいのですが、クズイカですみたいな。話はね。
げんえい
そういうことですよね。だからソフトウェア開発、道具があればやっぱできるわけでもないし、じゃあミケランジェロをいっぱい連れてこれるかっていったら多くは連れてこないわけで。
それはエンジニアからすると当たり前じゃないかと思うけど、その人にどうアドバイスするかとかって難しいですよね。
きんじょうひでき
難しいですね。じゃあどういうエンジニアならいいですかって言われても説明が結局できないので。
げんえい
そうするととにかく有名人の名前をあげるしかなくて、いやミケランジェロじゃないけどレオナルドビーチ連れていきましょうよみたいな話になって無理やろみたいなさ。
きんじょうひでき
そうですね。ちょっと設計今悩んでて、マーチン・ファウラーっていう人がいるんで、明日連れてきてくださいみたいな。
げんえい
そうそうそう。一休さんのポンチじゃないんだからさみたいな。
きんじょうひでき
でも楽天的に問題を解決できるでしょうって思ってるマネージャーみたいなの発言、そしてどうやってミケランジェロになれないんだみたいなイメージが最初に浮かぶんですけど、
エンジニア作る側も道具に対して過度の期待をしてしまうみたいなのは表裏一体であるかなみたいな気がしていて、
リファクトできれば解決するのになぁみたいなのと近いんですけど、このSaaS契約してくれたらいや、うちら生産性もっと上がるはずなんですよみたいな。
スポーキー図測ればみんな上手くいくはずないやみたいな。
げんえい
そうですね。
きんじょうひでき
なわけないので。
げんえい
測ったとて現実は炙り出されるだけで、それをまた改善していけるかどうかはまた別の問題出そうみたいなね。
お金の使い方とマネリテラシー
きんじょうひでき
そうなんですよね。だから道具を手に入れた後に本当に進化が問われるみたいな。
障害が取り除かれた時に、どこまでやれるかみたいなね。
結構なんか、目標設定とかコーチングとかで、自由に使える1億円があったら明日から何しますかみたいなことを考えると、
意外と1億円あっても自分の力でできることが少ないかもみたいな話が。
っていうか、これあれだな。僕が新卒で就活してる時に最終面接で聞かれて落とされた。
げんえい
いやー、これ脱線なんであれだったら切っちゃっていいんですけど。
1億円渡されても結局なんか難しいのは、お金の使い方を知らないじゃないですか。そもそも。
そうなんですよ。しかも学生ですよ。
げんえい
学生もそうだし、例えばエンジニアにしても、じゃあ1億円お前予算つけてやるからどうにかしろって言われた時に、多分難しいと思うんですよね。
多くのエンジニア。その中でCTOだったりとか、開発部のトップとか、そういうのだったらまた違うと思うんですけど。
きんじょうひでき
エグゼクティブの判断になってくるんですよね。金額の桁に。
げんえい
そうそう。経営判断に近いから。
お金を渡すっていうのはある種、制約条件を取っ払ってるようなイメージはあるものの、
ラスト書いたことない人に、じゃあラスト使っていいからラストにしないと、ラストで何できるか知らない私みたいな状態と一緒だと思うんですよね。
だからこそお金って、それを使ってどうやって価値を生み出すかみたいなところとかって、どっかで勉強する必要があるんだよなってずっと思ってたりとかして。
マネリテラシーが低いみたいなのは、ある種それに近いのかなとか、投資をどうやるかって日本人あんまり得意じゃないみたいな。
大事に抱える方が多いというか。
お金は大事だよって言われるんだけど、大事だからこそ貯めてしまうし、大事だからこそなかなか思い切って使えない。
思い切って使えないから、パッとお金が手に入ったときに、どういうふうに、何に移行するかみたいな。
例えば今だったら採用でいい人を取ってくるんやなのか、Macを買い替えた方がいいのかとか、そういう判断ってあんまりイメージつかないんだよなって自分は結構思ったりするんですよね。
お金を渡される話を聞くといつも。
きんじょうひでき
何を解決できるのか、どういう問題がコープに入ってくるのかっていうのがわかんないです。
今話聞いてて思ったのが、スケールが変わってくると同じように見えても全く別物だなみたいな感じがしますよね。
1,000円とか5,000円とか10万円、50万円くらいだったら普段の生活を良くするために使うと思うんですけど、1億円とか10億円とかになってくると増やすためにお金を使うと思うんで。
そもそもインプリメントされてるインターフェースが違うクラスみたいな、全然別物だなとか思ったりとか。
あとね、11インチのMacBook使っててディスプレイがちっちゃいんですよって言われた時に、あ、じゃあ競馬場にあるデカいディスプレイ買ってきてあげるよみたいな、何百円となるやつ。
言われても違うよねってなるし。
そうそう。
そっか、だからミケランジェロのなり方を知ってないとそもそもミケランジェロになれないなっていうのは今思いましたね。
げんえい
そうですね。ミケランジェロになり方もそうだし、このチームに必要なのは彫刻家じゃないんだが、水彩画の方が大事なんだが、みたいな場合もあったりするし。
良かれと思ってマネージャー困ってそうな顔してるし、持ってきてやるぞってこれを持ってきたんだけど、そもそも問題設定が間違ってましたみたいなことかっていうのは結構ありそうだなって思ったりとか。
きんじょうひでき
そうですね。15章でいうと、どうしてミケランジェロになれないんだ的なことを他人に対して自分が発言してないかみたいなところは少し意識できると、豊かな人生を手に入りやすくなるかもしれないっていうのはありますね。
げんえい
そうですね。
きんじょうひでき
15章読んでて病みそうだな。
はい。
げんえさんの。
げんえい
じゃあもう次はそのまま16章ダッシュボード、次の章で。
ダッシュボードを活用したチームの改善
げんえい
強いチームと弱いチームはダッシュボードを使うが、波のチームはほとんど使わないっていうところで。
自分がこの章いいなって思うのは、ダッシュボード作るときって何がキーメトリックになるかっていうことを考えて、多分ダッシュボード作っていくと思うんですけど、それをやった先に同じ指標を見ながらチームメンバーが話をすることになると思うんですよね。
ダッシュボードを作って終わらなければ。なので、ダッシュボードのそこに出てる数字が上がったり下がったりっていうことも大事なんだけど、やっぱりその過程とみんなで目線が揃ってるっていう意味で、この章なんかすごいいいなって思ったんですよね。
ダッシュボード。
きんじょうひでき
さっきのフォーキー図の話じゃないですか。
げんえい
そうですね。フォーキー図を測ろうぜって言って、ちゃんと測って、自分たちのヘルスチェックができて、それを元に考えたりとか、そこの数字を見ながらここを改善していきたいよねとかっていう会話ができるようになると、問題と私たちみたいな形にもなるし、なのでものすごくいいなって思ったりしますね。
きんじょうひでき
数字を見てその背景に何が起きてるとか、どういうプロセスでこの結果が目に見える数字につながってるのかっていうのを想像できるっていう状態になってくると、本当に問題について自分ごと化してるオーナーシップの意識が持ててるんだなっていうことの現れにもなりますし。
ダッシュボードって基本的にコミュニケーションツールだなっていう気はしますよね。
げんえい
そうですね。間違った数字を追いかけたらしょうがないっていう部分はあるかもしれないですけど、間違ってるってことにどっかで多分気づくと思うので、なんか数値上がってるのに売り上げ上がってねぇなとか。
たぶんそうなった時にちゃんとチームは、ここの中では弱いチームっていうのはそうなった時に責任を押し付けたりとかしてしまうっていうふうに書いてあるけども、基本的にはそこを見ながら目線が揃って改善していくっていう方向に行くと思うので、
そうなっていくだろうから、こういうチームの共通指標みたいなのは必要なんだよなーっていうのを思ったり。
きんじょうひでき
そうですね。昔公開されてたスライドがちょっと非公開になっちゃってるんで、現中するのあんまり伝わってないのかもしれないですけどもしかしたら。
日経新聞社がやってた弁当会かな。ちょっと曖昧なんですけど。
ダッシュボードの重要性と関心領域
きんじょうひでき
ザ・ギルドの安藤さんっていう方が発表してた、ダッシュボードこういうもの作りましたみたいなやつがすごいよくて、ここにもダッシュボードをきっかけにしてチームで話し合い、議論とか雑談しましょうっていうふうに書いてあって、
そうすると議論を起こすとか考えさせられるようなダッシュボードってどんなものですかっていう思考に繋がっていったりとか、ダッシュボードっていうのは回答、答えじゃなくて、何か問題を提起するテーマを投げかけるようなものが素敵なダッシュボードなんだろうなーみたいなことを、
ちょっとそういう資料とか見ながら個人的に思ったりしてましたね。ダッシュボードを見てここ何だろう、掘り下げてみたいなって思わせるフックにしたいなーみたいな感じはありますね。
げんえい
こうできるとね最高ですね本当に。しかしなんかだいたいダッシュボードを作ってみたが、なんかこの数字おかしいなって言ったら、あーなんか取れてないですねみたいな落ちがまってたり、なんかこの時だけ異常に跳ねてますねって言って、うーん何なんだろうねーみたいな。
きんじょうひでき
なんか本来的にはやっぱり今月の契約数が、2Bのビジネスやってるんだったら今月の契約数がいくらでしたーとか、売上がこのぐらいでしたーみたいな話に、プログラマー、まあ末端って言い方はあれですけど、
なんかね、ちゃんと組織の下々のプログラマーとか開発者っていうのもなんかそこに対して一騎一駆できるぐらいのほうが本当は、多分物作ってても楽しいじゃないですか、みたいなね話とか、もう何かの数字見たときに自分の関心領域とかオーナーシップを発揮できるフィールドの中に入ってるかどうかみたいなその面積というか、
縁の領域をどのくらいまで広げられるかみたいなところが、あれかエンジニア基礎的にシザっていう話なんだろうなーとか思ったりとか、だからチームの自分も含めてチームのメンバーのなんかシザとか関心に合わせてダッシュボードを作って、まあみんなで見ていきましょうよという風にできると多分いいんでしょうね。
げんえい
なんかダッシュボード、まあ多分今、前からか、基本的には多分BIツールだったりとかで可視化すると思うんですけど、こうなった時に、なんかやっぱ目に入るところにないといけないじゃないですか。
きんじょうひでき
そうですね。
げんえい
で、なんかオフィスにいた時はオフィスのでかいモニターに映しとくとか、まあどっかしら見えるところに出すっていうのは結構できたなと思うんですけど、フルリモートになってこう自分から見に行かないと目に入らない状況になっていくと、まあなかなか目にしなくなってしまうなっていうのをちょっと今話をしながら思ったりとかして、どうしたらいいんだろうなーとか。
チームで例えば毎週月曜日にこの時間に見るとか、そこから見えてくることは何だろうとか、まあそういう機会を作るっていうのはまあ一個なのかなと思いながら、なんかもっとうまいことできないかなとか、今ちょっとふと思ったりしましたね。
きんじょうひでき
そうですね。スラックのデイリーリマインドでバーってチャプチャー流すとかっていうのもあるし、あとあれか、前にいた会社だと、まあダッシュボードとはちょっと違うんですけど、なんかAWSのコストっていうのは僕はSRE部だったんで、有名なSRE部だったんで、なんかそのSRE文脈の、SREって言い方よくない?SREsのチームの人と結構近い文脈にいたんですけど、
なんか月1ぐらいで今月のコストどうだったかみたいなものを、そのミーティングの時間をとって眺めてみるみたいなことをやって、なんていうか、ダッシュボードがあるかないかじゃなくて、直接言うとそのデータに興味があるかどうかだと思うんで、データの裏にある問題に興味があるかが肝だと思うんで。
で、そこの関心とか興味とか意欲っていうのが湧いてくるまではある程度こう、なんですかね、能動的に仕掛けていってみんなで見てみましょうとか、どういう意味を感じられますかみたいな、まあちょっと半導育、半分導育みたいな形でやってみるとかはありな気がしますよね。
ダッシュボードの活用方法
げんえい
うん。そうですよね。まあ今でも確かに今の会社でも割と日に1回いろんなメトリックを取ったものをお便りしてニュースレターとして出したりとかしてるチームもあったりとかして、そういうのとかで極力目に触れる可能性を増やしていくみたいな。そういうのが多分今だと効くのか、そんな感じですかね。
きんじょうひでき
そうですね。まああと単純に流してるだけとか、ウィキに載せてるだけだと多分フーンで終わっちゃったりもしがちなので、なんか現場で所管を書かせてみるとか、持ち回りやってみるとかは、なんか自分ごと化させるっていう意味で1個ツールになるかなっていう気はしたりとか。
げんえい
そうですよね。まあなんかただ流れてくるだけだとフーンって確かに終わっちゃいますよね。
きんじょうひでき
そうなんですよ。シフトプラスエスケープに飲まれて終わっちゃうんです。
じゃあ16そんな感じですかね。
げんえい
はい。じゃあ次金城さん。
29:42

コメント

スクロール