小さく実験して学ぶにはどうするか？〜月と、人狼。第03回〜

【 月と、人狼。 第03回「小さく実験して学ぶにはどうするか？」 】の話です。

「月と人狼。」の背景は 市谷と中村洋の2人が、毎回テーマを決めて語り合う場を始めました。 に書いているので、よければ読んでみてください。

第03回「小さく実験して学ぶにはどうするか？」

価値探索における小さく実験して学ぶとはどういうものか？

• ・ 巻き込む範囲をいきなり大きくしない。社内でやる時にうまくいかなかった時に説明する範囲が広くなる。
• ・“実験”も計画に織り込んでしまう。
• ・バリューストリームマップを当事者だけでいきなりやるのは難しい。チームで練習してやる、達者な人を連れてくるなど。
• ・まずは想像で書いてみるのも1つの手段。自分達が何にわからないのかわからないことが起きる。
• ・わかっていないところをわかるようにする。利用者はどんな状況に置かれているのか、どんな行動をしているのか？
• ・自分の理解が広まることで観察の範囲、深さは変わる。

現場コーチにおける”小さく実験して学ぶ”というのはどういうものか？

• ・ 取り組みをいろいろやっていく中での小さく始める。それでやりやすくなる。
• ・ ”うまくいかなかった”という表現。
• ・ 1：「小さくやってみる。まずは1人でやってみる」のが大事。自分のタスクをタスクボードに見えるだけでもいい。最初からうまくやらないと意味がないという人が一定数いる。
• ・ 2：「安全地帯を用意する」こっから先は安全。
• ・ 3：「周囲との期待マネジメント」最初はパフォーマンスがいったん下がることもある。

「小さく実験して学ぶ」コツや難しさ

• ・ みんなでその場に行くこと。
• ・ 解釈を感想戦のように話す。
• ・ unlearningができない状況。
• ・ ”ゆとり”がない状況。

その他

• ・ ソフトウェア開発とは演出である。
• ・ わかったことをどう伝えるか？必要な人間は全員現場に行け。最後はコードの1行に落ちる。
• ・ プロダクトオーナーだけがインタビューして観察してレポートにまとめるのはアンチパターンかも。
• ・ 何次加工された情報よりも、現場に行くことの情報のほうが濃度が濃い。またその情報を”解釈する時間”を持つ時間が必要。その解釈をチームの力でやる。感想戦大事。
  • プロダクトオーナーと開発チームがプロダクトバックログを投げ合うのは意味がない。

次回は？

第4回の 「越境のやり方〜クライアントと共に進む〜」 は終了しています(またアップします)。第5回は「アジャイルソフトウェア開発宣言の4つの価値、12の原則」をテーマに以下のようなことを話す予定です。

現場で遭遇する状況や課題、実践していること、取り組み、学んだことなどを取扱ます。世の中の他のモノづくりや組織ではどんなことが起きているの？という方、耳を傾けてみてください。

月と、人狼。 第05回「アジャイルソフトウェア開発宣言の4つの価値、12の原則」