シアトル生活はじめました

20年以上すんだ東海岸から西海岸に引っ越してきました。MicrosoftのUniversal Storeで働いてます。

子育てもアジャイルプロセスと同じだった!?

昨日「アジャイルスクラム」のトレーニングに参加して気づいたこと。

マイクロマネージメントがいかに効率が悪いかを実感する

f:id:watanabe_tsuyoshi:20190224033707p:plain

私の所属する部総勢100人ぐらいが参加したんだけど、その中でこんなエクササイズがあった。

2人1組のチームに分かれて、一人が「ボス役」でもう一人が「ロボット役」になります。丸テーブルとイスが置いてある、大きな会場の部屋の両側の壁を「1往復」すると、1ワットの電力が生産されるとします。ボスはロボットに「進め、右に曲がれ、左に曲がれ、止まれ」のコマンドだけを使ってロボットを操作します。ロボットはボスの命令を聞く以外は何もしてはいけません。全体が「電力発電会社」みたいな組織を想定しているのです。まず1回目として8分間で何ワット発電できるかやってみよう、ということでスタートの号令とともに各ペアが動き始めました。

この1回目は「カオス」そのものでした。ボスとロボットが二人で移動するわけですが、そういうのが50組ほど一切統制がとれていない状態で動き回るわけですから、あちこちでぶつかったり渋滞になったりして、結局1往復できたチームはほんの一握りでした。

実はボス&ロボットのチーム以外にも20人ほど「中間管理職」のような役割の人たちも設定されていて、その人達は「カオス」の中になんとか「秩序」をもたらそうと、椅子やテーブルで流れを制御しようと試みたりして頑張るんですが、効果を上げられないどころか、邪魔になったりしてました。

1回目が終わったところで反省会です。どうして上手くいかなかったのか、会場からフィードバックを集めます。中でも講師が求めていたフィードバックが以下のようなものでした。

  • ロボットのコマンドが細かすぎて大変
  • ロボットにいちいちコマンドを与えるのが効率が悪い。ロボットに自律的に動いてもらった方がいい
  • ボスはコマンドを出す仕事以外なんら生産性の向上に役立っていない。だったらロボットが動きやすいように道を作ったりとか、他のことをした方がいい
  • 管理職の連中がいろいろ手を出すことでチームがむしろ動きにくくなっている

これらのフィードバックを元に、2回目はいくつかの変更点が加えられました。まず、ボスはロボットに「両方の壁を出来るだけ多く往復する」というゴールだけ伝えて、あとはロボットの判断に任せる。ボスはテーブルを整理して(その段階では会場はめちゃめちゃな状態でした)ロボットが動きやすいようにする。管理職の人たちは全体的にワット生産量を数えて8分後にどのぐらい生産できるか予想したりすして、原則現場には手をださない。

2回目は1回目よりもよりスムーズに動き始めました。なんとなく暗黙の了解で「時計回り」に列で動く、というやり方がロボットの間に芽生えたらしく、何となくそういう動きが出てきました。ボスたちも壁を触って発電する作業に加わったりしてました。結果、最高7往復を達成したチームも出てきました。

こんな感じでエクササイズは終了しました。これを実際にソフトウェア開発として見てみると、なるほどたしかにロボット(=プログラマー)にいちいちあれしろこれしろと細かくコマンドを与えても生産性はあまり上がらない。それよりも、ボス(プロダクトマネージャー)が「アプリを使ってユーザーは住所を変更することができる」というような具体的なストーリーをゴールとして共有して、細かい判断についてはロボットに任せる。その方が結果的には効率があがる、というのがアジャイルの考え方です。他にもボスはロボット(達)と定期的に会って進捗状況を聞き、障害がある場合は助けたりします。

アジャイルの原理を学ぶのに良く出来たエクササイズだと思いました。

マイクロマネージメントは子育てでもカオスを生む

レーニングが終わってふと、これは子育てに置いても同じことが言えるんじゃないかと思ったわけです。

1回目のエクササイズはまさに、あまり効果的でない子育てモデルです。子供のやることなすことに口をはさんで、あれこれ指図する。子供が失敗しないように親がやり方を細かく指示する(最悪の場合、子供に代わってやってしまう)。子供にぴったり着いて、子供が上手くやれるように監視する(そしてコマンドを出す)。子供は親のコマンドにしか聞かない(自分で考えない)。子供と親の間にゴールの共通認識が無い。カオスになっただけでほどんど何も達成されない。

逆に2回目のトレーニングは理想的な子育てと共通している部分が多いと感じました。親は子供に細かく口を挟まない。子供が失敗をしても前向きに再チャレンジできるように励ます(子供が失敗体験・成功体験する機会を決して奪わない)。子供にある程度任せて、時々上手くやってるかどうか双方向コミュニケーションで確認する。子供は親から言われたことだけするのではなく、自分で考えて行動する。子供と親はゴールを共有していて、同じ目的意識をもっている。少しづつ、パターン化していき、良い結果が出て来るようになる。

こうやって比べてみると人(子供)が関わるプロセスをより効果的にするにはいくつかの重要な要素があると分かる

  • 任せて育てる: ソフトウェア開発に限らず、仕事場で「人にまかせる」が出来ないボスがいる組織は停滞していきます。まだ上手くこなせない人材(子供)に、ある程度任せて、自分は最小限のエンゲージメントでメンターしたりアドバイスしたり、困っている時に助けたりする。
  • 失敗は成長プロセスの一部として容認する: Agileでは「Fail fast」の考え方が特に重要視されます。Sprintが2週間などと短いのは、ある決断(とその実装)が本質的に問題解決につながるかどうかの判断を出来るだけ早く行えるようにするためです。子供も成長の過程で何度も失敗を繰り返し、そこから学んでいきます。なのに子供が失敗しないようにと親が余計な干渉をあれこれしてしまうと、子供の成長に必要な失敗を体験することが出来なくなってしまいます。
  • ゴールを明確に共有する: ソフトウェア開発でもユーザーストーリ(実際に使う人目線のソフトウェアの振る舞い)を理解せずにデザインや実装をすると、使い物にならない機能をリリースしてしまうことになりかねません(ほぼ間違いなくそうなります)。子供も親も「そもそも何が目的なのか?」の部分で認識を一致させておかないと、あとで「いったい何のためにやってきたんだろう」と後悔する日が来ることになります。このゴールを共有するって、親子の間ではなかなか難しいことなのかもしれません。そもそも「あなたのゴールは何ですか?」って聞かれてすぐに答えられない人は大人・子供に限らず割りといるようです。ですから認識の共有以前の問題です。
  • HowではなくWhatに注目する: 私たちのほとんどは「How(どうやって、方法論)」の話になりがちです。そもそもの目的(What)を忘れてしまって、Howの部分でどうやったらうまくいくかという議論に熱中してしまいます。まさに「方法が目的になってしまうパターン」です。この現象は本当にいろんなところで見かけます。しかも子育ての場合は親が子供の細かい成功・失敗に強く関与してくるケースも少なくないようです。そうやって子供もWhatではなくHowだけに固執するように育っていきます。
  • フィードバックを活用する:ソフトウェア開発では顧客(もしくは顧客を代表するPM)からの意見を開発工程の一部に組み込んで「進行方向の微調整」を行います。逆に開発側から、その視点からしか見えない考察などをPMにフィードバックすることで、PMは「現実的」な解決へ微調整することが出来きます。親と子の関係においても、経験豊富な親(大人)から見て、常識・非常識の判断なども含めて、子供に適切なアドバイス(コマンドではない)をシェアできます。また子供も「本当にやりたいか、やりたくないか」という気持ちや「私にはこの量は無理」といったキャパシティー面での現実を親に伝えることが出来るチャンネルは絶対必要です(子供の自殺をなくすためにも絶対必要)
  • コミュニケーションを軽く、しかし継続的にする:ソフトウェア開発、とくにアジャイルではだらだらと会議をすることは非生産的だという認識です。細かい話は個別で、というのが一般的になってきました(日本はどうか分かりません。まだ会議が長いという話は耳にします。心配です)。親と子供のコミュニケーションも、年齢が上がるにつれ、より自立した大人同士の会話モデルに1ミリづつ近づいていくという自覚をもって親が望むべきだと思います。特に、得に「お説教」というコミュニケーションは、要点を絞って、分かりやすく、簡潔に、すべきです。いくら叱られることをしたからといって、それ相応以上の苦痛を子供(という人間)が受けるべきではないです。

まとめ

「子育てにアジャイル」って言ってもソフトウェア業界の人以外は「いったい何それ?」なんだけど、すくなくともアジャイルプロセスを理解している人達で親・保護者の立場にいる人は、アジャイルの原理が子育てにも応用できる可能性を模索するのも悪くないと思うのです。ですが、アジャイルという言葉や概念は脇に置いて、「子育て」つまり「人間の成長」においては、同様の原理が働くことはおそらく間違いない、という認識に立って、その原理に基づいてその人間の成長に関わっていくというのはどうでしょうか、と問いかけたいのです。

ちなみに、アジャイル的な考えかたに「Cross pollination」というのがあります。日本語で「他花受粉」と訳すそうです。これは、異なるチームや部署、業種を跨いで人材が交流することで、新しい知見やプロセスが広まり、最適化が進み、全体によい結果をもたらす効果を表します。「子育て」と「ソフトウェア開発」は全く関係ないことですが、お互いに学びを得られるかもしれないという点では cross pollination なのかもしれません。