マガジンのカバー画像

【翻訳メモ】INSIGHTS FOR THE JOURNEY

141
■全体目次 https://note.com/enflow/n/n51b86f9d3e39 ■「ティール組織」の著者であるFrederic Laloux によるINSIGHTS…
運営しているクリエイター

2018年9月の記事一覧

再生

【2.8】変容の旅に名前をつけるべきか?(should you give the journey a name?)

【2.8】Should you give the journey a name? ※ティール組織の著者Frederic Laloux によるINSIGHTS FOR THE JOURNEYの日本語訳の個人的なメモを公開しています。 ————————————————————— ■元のURL https://thejourney.reinventingorganizations.com/28.html ■翻訳メモ * あなたが直面する質問の一つで、それほど重要だと思わないかもしれませんが、「この変容のジャーニーにどういう名前をつけるべきか?」ということがある。 * また「目指したいゴール」には、どんな名前をつけるのか? * 色んなCEOと話していて、彼らの意見はとてもクリアだった。 * ジャーニー全体にも、ゴールにも、名前を与えないほうがいい、ということ。 * 私達はつい、名前をつけたくなる。目指すゴールが、teal organizationとか、self organizationとか、agile organization、とか。 * 大きな組織であれば、変容のプログラムに名前をつけたくなる。プロジェクト2025、とか。 * 強くおすすめするのは、名前はつけないこと。 * 2つの理由があります。 * 1つ目は、そうすることで「目標」を決めるのを避けやすくなります。 * ある変容を進めたリーダーと話をしていたら、彼は、同僚から「名前をつけよう」「大々的にアナウンスしよう」と言われていた。しかし、それをしたら「みんなが目指す巨大な象を作っていただけだ」と言っていた * teal organizationになりたい、というと、人々はそこを目指したくなり、生産的ではない会話が延々と繰り返されることになる * もしくはagile organizationになりたいと言っても、「ビジネスのこの部分はagileにすべきではない」といった会話が繰り返されてしまう * 2つ目の理由は、1つの単語にして簡単にしないことで、ニュアンスやイメージなどをたくさんの言葉で語らなければいけなくなる。文章で話したり。 * なぜあなたがそれを望むのか、どこに行きたいのか、など。 * ビュートゾルフでは、CEOのデブロックにしても他の人にしても、シンプルなモデルやコンセプトを聞いたことがないし、目的をドキュメントに書いたのも見たことがない。 * 色んな人が色んなことを語っている。 * 1つの単語にするのを避けることで、何度も何度も語ることを強いることになる。それはとてもパワフル。 * 組織の中には、いろんな言葉を使う人が出てきて、中には定着していくものが出てくるかもしれない。 * 私からの招待は、可能な限りそれは先延ばしすること。 * 小さなプロジェクトにはもちろん名前をつけたりするが、全体像には名前をつけなかった。取り組み全体はあまりに重要すぎるので、特定の言葉に凝縮してしまうのがふさわしくない。 * 同じように、大きな変革の取り組みの中の1つの柱として位置づける、というようなことにも慎重になったほうがいい。 * いろんな他の変化も進めているかもしれない。デジタルトランスフォーメーションなど。 * それぞれに名前をつけたくなるが、凝縮しすぎてしまわないように気をつけたほうがいい。 * なるべく長い間、文章やストーリーで語られるようにすることをおすすめする。 ■お願い 動画の最後にもあるとおり、この取り組みはすべてギフトエコノミーによって成り立っています。 この取り組みを支援されたい方は、以下のリンクからLalouxへのご支援をお願い致します。 https://thejourney.reinventingorganizations.com/in-the-gift.html

再生

【2.7】「車輪の再発明」に意味はあるのか?(Is there value in reinventing the wheel?)

※ティール組織の著者Frederic Laloux によるINSIGHTS FOR THE JOURNEYの日本語訳の個人的なメモを公開しています。 ------------------------------------------ ■元のURL https://thejourney.reinventingorganizations.com/27.html ■翻訳メモ * 本のためにリサーチしているとき、また出版してからも、多くの人と話していて、面白いことを学んだ * それは、試行錯誤しているチームや、「車輪の再発明」をしているチームにも意義がある、ということ * 私達は、ミスを避けられるときは避けるべき、混乱は回避するべき、という考え方が染み付いてみる * ただ、変容の中では、それは必ずしも正しくないかもしれない * 最初にそれを思ったのは、ビュートゾルフのCEOに話を聞いたとき * 彼らの最初のチームは2007年ごろに始まったが、そのチームは手厚いサポートを受けすぎた * 彼らにはコーチがついて、たくさんの時間を一緒に過ごしてくれた。 * そのチームは、後のチームほど試行錯誤しなかった、すなわち、後のチームほどは学ばなかった。 * 今は40-50チームに1人しかコーチを付けないことで、コーチがあまりたくさんの時間を特定のチームにかけないようにしている * なぜならチームは試行錯誤した期間や、コンフリクトが生じることを通じて、チームが強くなり、一体感が生まれる、と今は考えているから。 * ほかにも、ミシュランのリーダーたちと話していたときに、いろんな工場で試した結果、70000人の工場で働く人たちにセルフマネジメントを実践しようとしている * 彼らはチームにどうやってオペレートするかは決して教えない * チームには原則(principle)は教えるが、それ以上の細かいやり方はおしえない * もちろん、たくさんの実践をしているので、教えようと思えば教えられる具体的な実践の仕方は色々ある。 * そのかわりに、原則だけを教える。たとえばチームが自分たちでどんどんやるので、サポートは声がかかったときに動く * 例えば、マネージャーがやっていたタスクはチームに分散化される、など。それもプリンシプルなので具体的なやり方は教えない。 * ホールネスに進むチームであれば、採用のプロセスで、スキルで雇うのではなく、私達のビジョンと同共鳴できるかで選ぶ。 * もしくは、スペースを用意して候補者の物語を語ってもらうようにする。それも原則で、やり方ではない。 * すでにうまくいく具体的なやり方を知っているのに、なぜ、それを教えないのか?なぜ試行錯誤するように促すのか?ときには失敗もするのに。 * ミシュランの人が言うには、そこにはアンラーニング、リラーニングがある。 * それは、自分たちが試行錯誤してこそ起きる。やり方を教えてしまうと、背後にあるものの見方を学ばずに、やり方だけを覚えてしまう * 私自身は、プラクティスを教えることに熱中してしまう。中にはあまりに違うやり方があるから自分たちでは作るのが難しいものある。 * ティール組織の書籍の中でも、サウンズトゥルーという組織で行われる非常に美しいフィードバックのやり方をとっている。 * それをそのまま真似するほうが簡単なのではないか?と思ってしまう * 良いやり方があるときに、そのままやり方を伝えるのか、プリンシプルを伝えるのか、どっちを選ぶのか?というのを、多くの人と話してみた * デ・ブロックやミシュランは、試行錯誤を通じてアンラーニングやリラーニングをすることに意味がある、と考える * 一方で、具体的なやり方を伝えることにも意味がある。それはあまりに珍しかったり、違ったやり方なので、ほとんどの人が作れない、もしくは作るのにすごく長い時間がかかってしまうことがある。 * それならば、最適なやり方は、プリンシプルを教えて、やり方は2-3の具体例を伝えることがいいのではないか。 * そうすれば、1つをそのまま選ぶことは難しく、いくつかを比較しながら考えなければならない * もしくは、プリンシプルをしばらくかんがえたうえで、しばらくしてから具体的なことを教える * これはリーダーシップの役割も変えた。 * 古典的には、リーダーは失敗を回避させるべきだった。ものごとか効率よく進むように。 * リーダーの役割として、よく観察して、いつ介入するかを見極めることが求められる * あるグローバルな会社では、フランスの支社が最も先に進んでいて、すでにいろんな失敗も経験していた。 * その立場からは、他の拠点が失敗するのを見るのはとても苦痛だった * どうすれば助けられるか?ということを考えていたが、そもそも、助けることをやるべきか?という議論があった * ミスをすること自体が、組織が強くなるきっかけになる * 多くの組織で、極端に振れるケースがあった。あるときは古典的、官僚的すぎるし、あるときは逆に振れて一切の階層をなくしてしまう。 * そのどちらもがうまくいかなかった。そこから自分たちで考え始める * その振り子の動き自体が、アンラーニングやリラーニングの自然なプロセスなのではないかと思う * リーダーとしてはそのことを理解して、いつ介入するか、「車輪の再発明」を止めすぎないか、ということを考えてほしい * 他の人の中には、リーダーの役割は失敗が起きないように支援することだ、と考える人も居る。なので居心地が悪いかもしれない。 * あなたへのインビテーションは、改めて、チームが試行錯誤する期間があることはいいことなのか?意味があることなのか?を考えみてほしい。 ■お願い 動画の最後にもあるとおり、この取り組みはすべてギフトエコノミーによって成り立っています。 この取り組みを支援されたい方は、以下のリンクからLalouxへのご支援をお願い致します。 https://thejourney.reinventingorganizations.com/in-the-gift.html

再生

【2.6】実験と標準化のあいだのテンション (Tension between experimentation and standardization)

※ティール組織の著者Frederic Laloux によるINSIGHTS FOR THE JOURNEYの日本語訳の個人的なメモを公開しています。 ------------------------------------------ ■元のURL https://thejourney.reinventingorganizations.com/26.html ■翻訳メモ * あなたが気をつけたほうが良いテンションがある。それは、実験(experimentation)と標準化(standarization)の間のテンション。 * これはあなたが変容の旅の中で間違いなく直面するものなので、意識できるようになっていることに意味がある。 * 私達は、なにごとも標準化されていることが望ましいと考えるバックグラウンドを経験してきている。 * 多くのプロセスは書き出され、組織の中で同じように行われる * 組織を再発明(reinvent)するにあたって、そのようなやりかたを選ぶこともできる。 * ただ、私が見てきた多くの組織は、違うルートを選ぶ。大きな方向性を示して、色んな人が実験することを奨励する。いろんな地域、職種などで、同じ方向だが、それぞれが違ったやり方をする。 * 例えば、ある小売のチェーンでは、セルフマネジメントを試している中で、それぞれの店舗が独自にチャレンジしていた。 * ある店舗では、現場の役割はフラットにして、一方で、高い役職はしばらくはそのままにしておいた。 * 他の店舗では、店長を交代させることに決めて、その上の上司に決めてもらうのではなく、自分たちでjob descriptionを書くことから始めた。 * 他には、店長をやめて、店長の役割を4人で分けて担った場合もあった * そのやり方にはすごいパワーがあった。 * 実験(experimentation)と標準化(standarization)の間には、いつもテンションが生じる。 * 実験のメリットは、たくさんの学習ができる。何がうまくいって、なにがうまくいかないかを、たくさん試すことができる。 * また、多くの人が巻き込まれていく。人を動かそうとしなくて良くて、多くのエネルギーが生まれる。 * 標準化にも、もちろんメリットがある。実験を長くしすぎると、色んな人にとっては混乱のもとになる。全部のチームが違うやり方をする、誰に話せばいいかわからない、など。 * 一定の期間、実験してみることには価値がある。そのうえで、何がうまくいって何がうまくいかないかを学習してきたら、ベストプラクティスを標準化していけばいい * これは役割の決め方にも適用できるし、意思決定の仕方、ミーティングの仕方、評価の仕方、など、色々なことをそうやって決めていけばいい。 * 一定のタイミングでシンプルにして標準化することにバリューがある * 私からの招待(invitation)は、実験をするのに良いタイミングと、標準化するのに良いタイミングをそれぞれ見極めてほしい * あなたのリーダーとしての個人的な好みに引っ張られないでください。標準化してものごとをクリアにしたいタイプの人にとっては、標準化を早く進めすぎてしまうことがある。 * そうやって失敗してしまう組織では、十分な学習ができないままで終わってしまうし、旧来的なトップダウンのような印象を受けてしまう。 * 一方で、実験をしすぎて、標準化を全くしようとしない組織もある。そうするといつも混乱が生じてしまう。 * そこでの思い違いは、新しい組織の中では、決して標準化をしてはいけない、と思っていることもある。 * もちろん透明性は必要だし、ゲームのルールが分かっている必要がある。 * 大事なのは、この新しい世界では、「今のゲームのルール」であって、誰でもそのルールを変えられる、ということ。 * 多くの組織が標準化をしない、もしくは遅くなりすぎることがある * 概念的に「標準化すべき」「標準化すべきでない」ということを考えるのではなく、シンプルに、現実に何が起きているのかに目を向けてほしい。 * まずは実験から始めてみて、それから生まれる痛みが大きくなりすぎたら、標準化を試したほうがいい * 私自身、面白いことを学んだのだが、中には決して標準化する必要がないものもある。 * 最初にそれを思ったのは、ビュートゾルフで、彼らは固定された評価方法がまったくない。 * あるのはシンプルなガイドラインだけで、チームは年に一度は集まって、互いのオペレーションを話し合って、フィードバックすること、だけがきまっている。ただそれ以上のやり方はチームに任されている。 * 標準化に意味があるのは、他の人達がどうやってオペレーションをしているかを知る必要があるとき。 * たとえば、パフォーマンスを図る指標を標準化することにはとても意味がある。他のチームと比較してうちのチームはどうか?を判断できる。 * あとは役割。最初はチームごとにバラバラでも良いが、しばらくすると、他のチームに話したいときに、誰に話せばよいかがわかったほうが混乱が少ない。そうやって役割をクリアにしておくとバリューがある。 * 一方で、いつまでも標準化する必要がまったくないものもある。チーム内で行われることは、必ずしも標準化する必要はない。 * 私達は標準化するという世界になれすぎていて、標準化することの力を過大評価し、モチベーションに基づく新しいやり方のもつ力を過小評価してしまう傾向がある。 * ここでの大事なインサイトは、コンセプトや概念から考えるのではなく、その状況を具体的に見ることから始めて、この常用ではどこにテンションがあるのか、どこに痛みがあるのかを見て、実験を進めるべきか、標準化がいいのかを見極めることが必要になる。 ■お願い 動画の最後にもあるとおり、この取り組みはすべてギフトエコノミーによって成り立っています。 この取り組みを支援されたい方は、以下のリンクからLalouxへのご支援をお願い致します。 https://thejourney.reinventingorganizations.com/in-the-gift.html