00:01
最近ですね、アサドラを見てましてね。
次男がですね、そこそこ、なんかそのー、まあアンパンがやってるんですね、今。
で、まあアンパンっていう名前だけで見てると思ってて、本人は全く理解してないんですけど、
で、あのー、だいたいあのー、アンパンがやってるんですけど、
そうですね、うちは7時台にNHKを見て、で、8時になったら、
ジップか、に帰るという、そういう日テレですね、日テレに帰るという生活をしてて、
で、いつもの通り1時になったから帰るかと。
で、1時になった瞬間にアサドラってのが出てきて、
4月に入って、最初の数週間はそれで回ってたんですけど、
なんかどうもアンパンがやってるらしいと。
で、アンパンという、アンパンマンですよね。
というところから、なんか見たいと言い始めて、で、見るようになったんですよ。
なので、そこでチャンネル変えようとすると怒るので、しょうがないから見るんですけど、
そうするとですね、めちゃくちゃ面白いということに気付いてしまって、
もう見ていますと。
そうですね、今収録してるのが5月26日ですけど、さっきも見てきましたけど、
あれですね、もうちょっと、
ということで、今回は叩き台というプラクティスについて考えてみようかなと思っています。
叩き台。
そうですね、叩き台ってよくありますよね。
ブループリントとかそういうやつですよね。
つまり、あれですね、叩き台っていうのは、
叩き台というのは、
叩き台。
そうですね、叩き台ってよくありますよね。
ブループリントとかそういうやつですよね。
つまり、ある程度、何かの計画とかを考えて、
で、たぶん形にするんですよね。
ある程度の成果物というかね、ドキュメントみたいなそういうものに。
で、それを、それを誰かが考えるんですよね。
誰か一人が考えて、で、それを形にして、で、それを他のメンバーに伝えるというやつで、
結構、よく使われているやり方じゃないかなと思うんですよ。
その、例えば、プロダクトマネージャーだとか、プロダクトオーナーだとかが、
ある程度の素案を考えて、それでメンバーに提示するとか、
それも、ある意味叩き、じゃあ叩きですよね。
で、開発者同士の間でも、何かやらないといけないんですけど、
開発の方針を決めたりだとか、そういったものがありますよね。
03:00
開発の方針を決めるときに、誰か一人がある程度こうするといいんじゃないかみたいなのを考えて、
それを伝えるみたいな、そういうのがありますよね。
で、実は個人的には、あんまり叩き台って好きじゃないっていうのはありましたね。
好きじゃないんですけど、これまでの仕事、いろんな仕事を見てきた中で、
叩き台ってやっぱりうまく回ることが多いなと。
失うものもあるんですけど、物事を前に進めるという観点では、いいよなって思っていて、
ただ好きじゃないんだよなっていうところですね。
で、なんで好きじゃないのかっていうと、叩き台を作ると、誰か一人が作るんですよね。
誰か一人がめちゃくちゃ知識ある状態になって、他の人が知識ない状態なんですよ。
知識の差が生まれるんですよ、叩き台が生まれた瞬間に。
その叩き台が生まれた瞬間に知識の差分が出て、そうなると教師生徒の関係になっちゃうんですよね、どうしても。
情報伝達というよりは、どちらかというと教えるみたいな感じ。
叩き台だから結局叩いてもらうためのもので、生徒と言うけど、意見を言うのはそりゃそうなんだけど、
でも割と7,8割くらいOKみたいな感じですよね。
その7,8割OKっていった部分って、伝わったとしても、あんまり伝わってないなっていう感覚はあります。
だから好きじゃないのかなと。ただ、物事は絶対前に進むんですよ。
その観点は捨てがたいのもわかると。
じゃあどうするのって話ですよね、叩き台。
これはMOGプロに話に近いのかなと思うんですけど、
あるメンバーがすごいたくさんの知識を持っている状態で、他のメンバーがそこまで持ってないっていう状態を、
これ、意図的に生み出す仕組みなんですよね、叩き台って。
なので勝手にというか、意図してエキスパートとエキスパートじゃない人を作り出すと。
MOGプロで、どこかで聞いたことがあるので言うと、知識の差分がある状態。
エキスパートがいて、他のメンバーがそこまでエキスパートじゃないみたいな、
06:01
そういう状況だとエキスパートは役割としてはドライバーでもナビゲーターでもない、
そっと見守るような感じでやるといいよね、みたいな、あるじゃないですかと。
でもそれって、何でしょうね。
元をたどれば、メンバーの間に知識の差分がなければエキスパートの人もちゃんとというか、
普通にMOGができるんですよね。
だから身も蓋もない話ですけど、みんな強くなれと。
みんな強ければ、一人が我慢してMOGをするなんてことはする必要なかったはずなんですよ。
でもそれはそうは言っても、世の中の知識とかある程度のスキルとか、
もちろんね、社会人経験とか、経験年数みたいなものもあるので、
全員の知識が一律っていうことはないんじゃないんですけど、
だからそういう中で工夫をした結果が、エキスパートはなるべく黙るっていうプラクティスですよね。
パターンかな。
でもそれ、さっき言った通り、全員が一律の能力があったら、
そのパターンを取り入れなくていいはずなんですよね。
それを意図的に生み出すっていうところがそうですね、
なんかモヤモヤするんだろうなっていうのを今話してて思いました。
叩き台そのものを全員で作れないだろうかっていうのが、
ちょっと私の考えているところなんですよね。
必要悪な気がします。
これ、そうなんですよ。
じゃあ叩き台やめようよとはちょっと言いづらくて、
なんでかっていうと、叩き台を望んでいる人もいるというか、
あんまりエンゲージする気がないメンバーがいると、
それで何でしょうね、勧めざるを得ないんですよね。
モブプロも本当にまず全然広まっているソリューションじゃない、
プラクティスでもなんでもないので、
みんながみんなベストにやれるわけじゃないと思うんですよね。
エンゲージしないっていう言い方をしましたけど、
理解をしようとしないとき、メンバーもいるんですよね。
分かんないですけど、私が観測する限り、
本当に理解しようとしてたら、
結構頑張って糸を組み取るみたいな行動が行われるんですけど、
ちょっと分かんない、分かんない、分かんない、
みたいな感じの態度を取る人がいたことが、
過去何回かあったなと思っていて、
そういう人がいる状況では、
たぶん叩き台を最初から全員で作るってできなくて、
09:02
なぜかっていうと分かんないって言ってるメンバーは、
あんまり作る気がないからなんですよね。
そうすると、結局最初から作ったところで、
その人不在みたいな、そもそもモブとしてどうなのっていうのはあるかもしれないんですよね。
叩き台をモブでゼロから作っちゃえばいいじゃんっていうのは、
私の中の理想な働き方ではあるんですけど、
それは前提として、
メンバーのスキル、モブに対するスキルはある程度一律で、
エキスパートなのか分かんないけど、
エンゲージしようとするメンバーが多いみたいなところはあるかもしれないですね。
あと聞いたところによると、
モブの人数が多いと叩きをゼロからっていうのが難しいみたいなのは聞きますね。
確かに人数が多いと、
どうやって自分の知識を伝達するかっていうところが若干難しくなるかもしれないですよね。
だからこそ、
あるモブプロの流派では、
しっかりとドライバーだけじゃなくて、
ナビゲーターっていうのを一人置いて、
それ以外はモブっていうやり方。
確かソフトウェアチーミングだとドライバー、ナビゲーターで、
全員ドライバー以外ナビゲーターみたいな感じだったと思うんですけど、
ドライバーとナビゲーターとモブっていう、
明確な3つの役割を分けるっていうのはすごく良いだろうなと。
そしてそれを交代していくっていうのはやっぱり良いだろうなって思いますね。
そういうことをしっかりとれるモブであれば、
叩き台をゼロから作ることってできそうな気がしますよね。
なので、
そうですね。
やっぱり叩き台そのものについてしゃべろうと思ったんですけど、
結局なんか行き着くところはモブなんだなっていうところが分かりました。
ということで今回は叩き台というプラクティスについて考えるでした。
それではまた。
