日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない
ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。
Microsoft Hack week
日本人はイノベーティブ
Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。
自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日本から出ていかない。もちろん例外はあるがとても少ない。実際に、米国で働いて見ると、彼らと比べて「人」としての能力に違いはない。日本人のエンジニアでイケてる人にたくさん出会って来たし、向こうは基本コンピュータサイエンスは出ているからベースラインは高いけど、日本のエンジニアでもイケてる人はたくさん現場にも溢れている。むしろ極めているような人は日本の方が多いのではないかとも感じる。ではなぜイノベーティブにならないのだろう。
日本流ハードワークと米国流ハードワーク
自分が日本に帰って来て、久々に、人に言われたからではなく、ついつい仕事をたくさん受けて日本流のハードワークをしてしまった。米国にもハードワークな人も沢山いるが、例えば、「忙しい」というイメージが彼らと違うことに気がついた。日本では忙しいというと、残業は当たり前で、そろそろ休出しないと回らないぐらいのイメージが「忙しい」だが、向こうにいるときは、残業はおろか、定時内にできる仕事量で、しかもそれがだいたい埋まっていたら「Busy」という感じだ。
定時だけを使って、新しい仕事を始められない状態が「Busy」だから、ハードワークな人も、朝も昼も夜もなく働いている人ではなくて、バリューを出すために、たまに日曜とかでも仕事したりするけど、５時に帰るときは帰るし、みたいな感じで、日本みたいな仕事量に追われてパツパツという感じでもない。そもそも仕事量を沢山こなすことが求められないし、誰も喜んでくれない。求められるのはインパクトだ。
simplearchitect.hatenablog.com
余裕があるからイノベーティブになれる
そういう日本流のハードワークを久々にしてみて気づいたのだが、米国にいて仕事をしているときは、毎日５時で終わりで、大量の仕事をこなすのを求められないので、５時の時点で会社の仕事をしなくてよくなる。私は、３流プログラマなので、家に帰ったら、その日に学んだことを自分のためにブログに書いたり、オープンソースのプロジェクトにプロバイダを書いて貢献したりとかしていた。
ところが、日本流ハードワークをやってしまうとどうなるかというと、そんな余裕は全くない。仕事で新しい技術を使ったら、学んだことをブログにしないと身につかない性格なのに、それをしている暇がない、オープンソースに貢献する時間も圧倒的に減った。米国にいるときみたいに、仕事の中で疑問に思ったことを調べて、コードを書いてブログを書くみたいなことをする暇が全くなくなった。つまり、「仕事をこなす」ことをやっているだけだ。
Bruno と David と会社帰りにウェイクボーディング
私の仮説だが、米国でも Moon lighting と言って、会社の仕事とは別に夜にソフトウェアのプロジェクトをやるという話があるが、前者だと、十分できそうだが、後者の環境だとそんなことしている体力も気力も相当なものが必要だろう。また、日本のハードワークだと仕事をこなしているだけなので、仕事で学んだことをより深く学んだり、全然違うことを学んだり、プロジェクトをしてみたりという時間が取れない。だから、折角イノベーティブな性質を持った私たちが、仕事を沢山こなすことを求められる日本のIT 業界ではイノベーティブになれようがないのではないだろうか？
よりイノベーティブになるための方策は？
つまり、エンジニアに余裕がないから、イノベーティブになりようがないので、「余裕」ができるようにすればいいということになる。
この問題の対策としては、日本に止まるなら、Rochelle さんと作った８つの習慣みたいなものがもっと広まって、多くの人が違いを「認識」し始めることじゃないだろうか。
simplearchitect.hatenablog.com
それよりさらに良いのは、働き方改革とかの成果を待つより、どんどん転職して海外の企業を体験するのはどうだろう。今まで、「常識」で「無理」と思っていたことが平気で実現されている世界に触れると、「あー、あれって不可能じゃなかったんだ」と思えるようになる。日本では３５歳定年説と言われるのに、４６歳の私が、今年からSoftware Development Engineer としてコードと再び格闘している。私が得意だった政治的なことは一切していないが、過去最高の給料をもらっている。我慢とか勿体無い。もし、あなたがプロフェッショナルであろうと思うエンジニアであれば、海外の企業とかを一回でもいいので体験するのは本当におすすめだ。
Microsoft のオフィスでの風景
良いエンジニアを確保したい会社さんはチャンスだ。他の会社さんが、低賃金で、仕事量をエンジニアに求めている間に、米国みたいな労働環境を提供してみると、エンジニアにとっては日本にいながらそうなれるのは、超魅力的だろう。しかも、そうなると、エンジニアの成長も早く、イノベーティブになるので、海外進出とかではなく、普通に、世界の一員として活躍できるだろう。ソフトウェアは頭脳労働の権化で、早くタイプできる人が必要なわけではない。成果は数や量ではない。コードで如何にインパクトを出すかだ。そのためには、「こなす」ではなく、本当に「理解し、出来るようになる」ことのほうが重要だ。
海外の企業を体験してみよう
日本では我慢しなければならないものが、全くなく、政治より技術が求められる世界は本当に楽しく、もっとエンジニアリングができるので成長も早い、給料もいい、無理に忙しくないからイノベーティブになれる。
こんな話を聞いたことがある。ある地域のレストランがまずいのは、お客さんが「まずい」と認識していないからで、お客さんが本当に「美味しい」ものを見分けられるようになると、「まずい」ところには誰も寄り付かなくなるので、相対的にレストランの味のレベルが向上するという話だ。それと同じかもしれない。
どんどんそういう人が会社をやめて海外に流れていけば、日本企業でもITの良い人材を確保するために待遇を上げざるを得なくなるかもしれない。プログラマを出来るだけたくさん働かせたいと思うような、労働条件の悪いところで働かなくなるかもしれない。少なくとも、世界が変わるのを待ってるより自分が幸せな方がいいし、もしかするとそっちの方がより日本のためかもしれない。
アジャイル開発の導入のビデオシリーズを作ってみた
今年から会社の方針も変わり、エバンジェリストからSoftware Development Engineer という職種に変わった。プレゼンとデモの世界から、お客様と一緒にハックしたりコードで世の中にインパクトを出す仕事に変わったので、楽しくも四苦八苦しながら頑張っている。
先日友人の Rochelle Kopp さんから Agile のビデオを作ってくれないか？という依頼があった。今から Agile を始めたいと思っている企業さんが増えてきたのだが、残念ながら私はコードを書くのが`今の仕事なので、エバンジェリストやコンサルをやっているときのように対応できない。出来るとしたら、自分が新技術導入 (Serverless, Microservices等)をご支援しているプロジェクトに限られる。 だから、彼女がビデオを作ってくれたらうれしいといったので、既存の資料を少しカスタマイズして、ビデオをいくつか撮ることにした。ビデオでは、インタラクティブにお話しできないので、どこまで皆さんのお役に立つかはしらないが、クローズにするよりは、とりあえずシェアしてみようと思った。
現在プログラマとして米国の開発プロジェクトに参画したりするなかで、学んだ内容などももりこみながら、アジャイルの全体像と、日本で多くの人がアジャイルの世界にはいってくるときに、「なんでこうなるんだろう」と疑問に思いそうな部分に関してお話ししてみました。
プレゼンテーション
アジャイルの全体像 (17:22)
背景とか、全体像のお話し
アジャイルの考え方 (43:42)
アジャイルの考え方で日本人的にしっくりこないと思われる部分の解説や、本を読んだだけで実行したら誤解しそうな部分についてのお話し
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
アジャイルプラクティス (27:47)
アジャイルの具体的なテクニックをいくつかご紹介。ただ、これだけですべてカバーできているわけではないので、是非次はアジャイルコーチを呼んで実践を。やる前からたくさん学んでも、頭にはいらないので、全部学び終えようと思わず、この程度の知識を得たら、やったことがある人と、すぐにやり始めるのがいいと思います。
Q&A (26:47)
よくあるQ&Aに対して回答してみました。本来はお客様や状況によって違うのですがビデオなので、ありがちなシナリオについてコメントしてみました。
次の一歩
この程度の情報を得たら、まずはやってみることをお勧めします。まずお勧めのステップは、上層部を巻き込んで目的を明確にしたのち、アジャイルコーチを連れてきます。次に、誰もアジャイルをやった人がチームにいないなら、アジャイル開発がバリバリできるプログラマをつれてきて、小さくてもいいからチームをつくって、そこで、濃度１００％の妥協なしアジャイルチームを実際にやってみるのをおすすめします。
技術なきマネジメントの衰退とその対策
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。
世界は「技術力」の重視に向かっている
私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。
私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術力」を磨きたいというのがあった。ラッキーなことに、海外転勤ではないものの、インターナショナルチームでエバンジェリストというテクニカルな仕事ができているので大変幸せだ。
なぜ当時「技術力」を磨きたかったかというと、私は、アジャイルや、DevOpsの導入、超上流の技術をはじめとして、「人」系の技術を磨いてきたので、アジャイルのような新い考え方を日本に導入するということに関しては絶対の自信もあったのだが、プログラマとしての技術力は、過去のキャリアを見てもらっても分かる通り、正直３流だ。
技術力がないのは何となくやばい
お客様と接している時に、ふと「このまま技術力」を磨かないと将来やばいとぼんやりと不安に思っていた。特にクラウドコンピューティングが普通になってきた頃から、そろそろやばいという感覚があった。しかし、私にはキャリアがないし、大手SIだったので、そんなにガッツリ自分で開発もしていない。今はいいけど、近い将来やばいんじゃないか。だから、ガチのプログラマとしては通用しないと思うので、プレゼン力とか、トランスフォーメーション力がとても有効で、しかも技術力も成長できるDevOps のエバンジェリストの職はまさに私が求めていたものだった。
たった１年で起こったマイクロソフトのトランスフォーメーション
最初の１年目は私はとても良い成果を出すことができた。皆さんのご協力、そして持ち前のトランスフォーメーション力もあり、とてもいい事例も作れた。プレゼンも神のようなレベルの人に直接教えてもらえて上達したし、プレゼンの評判もありがたいことに、とても良かった。当時のエバンジェリストの評価は色々あったが、最重要の指標の一つは、プレゼンなどを実施した時の「顧客満足度評価」の指標だった。技術力は、人前で話をしたり、デモをしたりというレベルで良かったので、頑張って学んで実践していれば、対応することもできた。ところが、技術のデモやプレゼンをして人々に、新しい技術を広めるという「エバンジェリスト」の職業は、たった１年でまるっきり評価基準が変わったのだ。
ハックフェストと技術力がエバンジェリストの世界を支配した
期が変わると、評価基準が一転した。プレゼンや、「顧客満足度評価」はもはや、エバンジェストの評価としては、ほぼ意味がなくなり、お客様のところに行って、ハックフェストというイベントを実施して、最も難しい問題を「コード」で解決してくること評価に変わった。ハックフェストは、３−５日で、お客様の環境でガチでコードを実装したり、自動化したりするようなイベントだ。そして、例えば、世界で誰も解いていない問題を解いたり、オープンソースにコントリビュートするようなことが「インパクトがある」という考え方に変わった。 これはとても大きな変化だ。開発者ではないので、マーケティングのような技術者のような中間のセンスが要求されたエバンジェリストは、そこまで正直技術レベルを要求されなかった。ところが、この方針では、かなりのテクニカルスキルを要求されるようになる。プログラマとして３流の私は死ぬ気で頑張るしかない。
米国のハックフェストで感じていたレベルの高さ
日本では、正直なところ、新しい技術や方法を導入するためには、技術力というよりその前にステークホルダーの人をうまく巻き込んだり、モチベートしたりといった「技術以外の要素」が実際に技術を導入する前に必要とされることが多いように感じる。私はそういうのがとっても得意だ。だから、日本では活躍ができた。
ところが、米国で先の「ハックフェスト」を実施すると、様子が日本と全く違うことに気づいてきた。お客様のレベルが平均的レベルが非常に高い。
日本でハックフェストをやると、例えば、最初の数日は、新しい技術のハンズオンみたいな感じになる。だから、達成できることもあまり多くないことが多いが、米国でのハックフェストの場合、お客様は、チュートリアルはおろか、新しい技術でも、すでにガンガンに本番に適用していて、基本的なことはみんなわかっていて、実際使っていて、その上で、「難しい問題」をお客様と一緒に解決することになるので、インターネットで探しても解決しない「世の中で未解決」の問題に向き合うことになる。
米国では、「技術以外の要素」の重要度は低い
日本では、このような「ハックフェスト」を実施する前に、たくさんの準備、訪問、説明などような「種まき」が必要だが、米国だと、「お客様」の方からリクエストが来るので、日本で必要な「技術以外のこと」があまり必要なく、「技術力そのもの」がお客様に求められる。
また、入門レベルのことも、米国の場合はお客様が自分で勝手にやってくる。世の中にチュートリアルや、ビデオは散々あるのでそういう情報は、ハックフェストの場では、我々に特に求められない。これに関しては「英語」のハードルも違うかもしれないし、向こうの人は、基本的にコンピュータサイエンスを出ていることも関係しているかもしれない。だから、プレゼンとか、デモとかの重要度が下がって、「ガチの問題を一緒に解決してくるれる技術イケメン」への需要が高まっているのもうなづける。現にマイクロソフトの本社の「//Build」で多く発表しているのは、プロダクションチームが多く、エバンジェリストではない。（ただ、キーノートのデモとかは、エバンジェリストが作っていたりする）
マネージメントスタイルの違いと技術
マイクロソフトに入ると、そもそも「コードが書けない」マネージャは、少なくとも私の上には存在しなかった。当たり前かもしれないが、技術のプロジェクトをやるのに、技術がわからなければマネジメントもクソもない。だから、彼らと話をしても、「あー、技術わかってないねんなー」とか「勘違いしてはるわ、、、」と言う場面に全く出会ったことがなく不思議だった。日本ではそんな場面はしょっちゅうなのに。だから、会話もすごくかんたんで、日本で必要な「上司の説得」みたいな場面は必要ない感じだ。
また、このブログでも触れているように、少なくともマイクロソフトでは、「サーバントリーダーシップ」というマネジメントスタイルが主流だ。チームを「管理」するのは「チーム自身」そして「個人」が実施するので、彼らを「信じて」「任せる」スタイルだ。彼らが困っている時は、マネージャが、サポートしてくれる。だから、マネージャが指示を出すようなマネジメント方法ではなく、チームが考えて、チームが問題を解決して、マネージャがそれを支援するようなスタイルだ。
この方法は、生産性的に細かい管理が不要になり、意思決定が高速化するので、圧倒的に高く、メンバーもモチベーションも高くなる。だから、マネージャも、我々をリーディングしてくれたりサポートしてくれるだけではなく、メンバーと一緒になってハックフェストをしたりする。リーダーシップではなく、「管理」だけする人はもはや不要だ。
simplearchitect.hatenablog.com
さらなる技術シフト
マイクロソフトのエバンジェリストチームに入るとさらなる「技術シフト」を感じる。先日も、HackWeekという、本社のエバンジェリストがいろいろなものをハックするイベントが開催されたが、その時に、エバンジェリストの長が発した言葉には驚いた。「マネージャであっても、全員L3を取ること」L3というレベルは、お客様の所で、ガチのプロダクションに使えるソリューション（コード）を書いて貢献すること。という意味だ。つまり、日本でいうと、部長も課長も全員お客様の所でコード書いてバリュー出せるレベルになりましょう。ということだ。
そのエバンジェリストのトップ（日本でいうと事業部長クラス）は、さらに、そのHackWeekで自ら、CosmosDBなどのハックに参加して、彼自身が時間をとってハックをしていた。
技術の進展はめまぐるしい。だから、少なくとも米国では、マネージメントであっても、最新の技術をハックしていないと話にならない時代が来ているということだ。もちろん米国にも、プレゼンや、デモが強く、そんな技術力が高くない人もまだいるだろう。去年変わったばかりだから。しかし、急激に、マネージャであっても「技術力」のある人が求められているのは間違いない。
これは、実は米国では顕著だが、日本でも始まっている気がする。だって、そうでないと、これから、自動翻訳もできて、海外との言語の壁が少なくなると、日本マーケットに、そういう技術力が高い人が押し寄せて勝負をすることになる。
simplearchitect.hatenablog.com
そんな時に、どうやって効率が悪いことをやって勝てるのだろう。
じゃあどうすればいいのだろう
私のように、SIer出身で、若い頃からPMとかコンサルとかやっていた人はどうしたらいいのだろう？自分の当面の目標は、「世界のどこにいてもご飯が食べられるスキル」を身につけることなのだが、私のスキルは、「日本」にのみ特化している。他では現在のままでは食べられない。ポイントは「技術力」だ。これさえあれば、多少英語がしょぼくても、米国でも通用する。
しかし、現状の技術力を鑑みると、そもそもこの業界を諦めた方がいいのだろうか、とか色々考えた。今は、マイクロソフトを首になるまで、エバンジェリストとしてスキルアップをひたすら頑張るしかないと考えて、なんとか頑張っている。しかし、私は本社メンバーの仲間に比べると、まだまだなので、いつ首になってもおかしくない。もしかすると、多くの日本のマネージャの人も、薄々技術力が必要になることはわかっていても、何十年もコード書いてないし、新しい技術はバンバン出てくるしどうしたらいいのだろうと途方に暮れているかもしれない。私も似たような感じなので、このギャップがここ数年の私の最大の悩みだ。
プロダクションコードを何年も書いている人に渡り合う為には、自分でチュートリアルをやって、本を読んで自習したところで、到底及ばないだろう。しかし、技術なき人に明日はないと感じる。
Mob Programming の衝撃
しかし、私は、その解決のための一つのヒントを得た。それは、Mob Programmingだ。Mob Programming はチーム全員が同時に、同じ場所で同じコンピュータを使って同じことをする。１台のコンピュータとプロジェクタ２台を用意して、全員で、１台のコンピュータをシェアして、メンバーがドライバーと呼ばれるキーボードを入力する役とそれ以外の人がどういうコードを書くかを議論するスタイルだ。
ペアプログラミングを知っている人は、それをチームでやった版だと思うだろう。だから、私も、最初はあまり興味がなかったのだが、実際にMob Programmingを体験したら世界観が一変した。これはものすごいメソッドかもしれない。アジャイルがプログラミングの世界を変えたように、このメソッドがまたプログラミングのやり方を変えるかもしれない。下記のスライドは、楽天の及部さんが発表したスライドでMob Programming とその実際がよくわかる資料なので共有したい。
次の動画は、Mob Programming の提唱者であるWoody の講演
Mob Programming のメリット
Mob Programming はチーム（たぶん４−５名がベスト）全員で１台のPCなので、従来のマネージャなら、効率が悪いから絶対認めないスタイルかもしれない。しかし、実際にやってみると、むしろ「効率が良く」感じる。よくよく考えると、プログラミングをしていて、最も時間がかかるのは、「悩んでいる」時間だ。何かにどハマりするとか、初めての事、難しい事をやるときに、理解するのに時間がかかるとか。それがMob Programmingでやると、いろんな人が寄ってたかって、いろんな目線で解決を考えるので、詰まったり、ハマったりする事がなく、異常に早く終わる。ペアプログラミングも良かったが、その時とMobとの最大の違いは「心理的安全」かもしれない。
心理的に安全を感じること
プログラミングをやる時に、現在では毎日のように「未知の技術」に向かわないと いけない。新しいことを覚えて熟練して使えるようになるには時間がかかるし、知らない技術をやらないといけない時は、自分にできるだろうかとか不安になる。先の及部さんと、ラッキーなことに、Mob Programming を体験させてもらえる機会を作っていただいた。
Mobに最初に参加して衝撃だった一言がある。４人ぐらいのMobを常に実践しているチームがいて、彼らが、PHPを書いていた。彼らが、「Mobに加わりなよ！」って言ってくれたのだが、私は「わしPHP一秒も書いたことないねん」と言った。本当にそうなので。とても、貢献できると思えない。
ところが彼は、「あー、この前〇〇の会社さんが来て、Mobに参加してコードかいて帰ったけど、彼らもPHP知らんけど、コード書いて帰って行きました」言っていた。
知らない言語でプロジェクトにいきなり貢献する衝撃
自分が何も知らないチーム、そして知らない言語で構成されたプロジェクトに参加して、初日からコードを書くなどというのは、想像もできないが、Mobではこれが発生するようだ。しかも、続けて彼は言った。
えーーーーーー！彼曰く、
「Mobだと自分が知らなくても、他の人が知ってたらなんとかなるので、とっても気楽ですね」
結局私もその日Mobに参加して、コードを書いて帰って来た。コードを書いている時も、不安が何もなかった。だって、自分が知らないこと、遅いことも、他の人がカバーしてくれるし、わからなかったら全員で調べてくれるので早いし、たとえつまづいたとしても、「あー、わからないの俺だけじゃないんだー」と言うことがわかる。つまりむっちゃくちゃ安心感があるのだ。だから、1日終わると、しっかりバリューもでるけど、すごく幸せて楽しい気分で帰ることができた。
Mobの効果はそれだけにとどまらない。
問題 vs 私たちで、問題をフルボッコにする
Mob Programming を実施するとかなり心理的に負担が少ない。今までは自分が初めてのテクノロジーに触れるときは慣れないので、最初に相当ハマることは覚悟しないといけない感じだが、Mob Programming でやると、触れたことのない新しいテクノロジーも全然怖くない。自分のチームに誰か知っている人がいたらものすごくスムースに新しいことを学べる。全員その技術をしらなかったとしても、「あー、知らないのはわしだけじゃないんだ！」と気楽に取り組める。それでも一人でやるときよりよっぽど早いし、ストレスもない。
なんでかなと考えると、普通の問題だと、一人でハックをしているときは、問題１に対して人間１で１対１の勝負をしている感じだが、Mobだと、問題１に対して例えば人間４なので、問題をよってたかって、フルボッコという感じなので、大抵の問題はボッコボコにできる。
何より楽しい
私は、楽天さんで、Mob Programming を常に実践しているチームがあり、そこにお邪魔させてもらって数回体験させてもらった。理屈抜きに最高に楽しかった。マイクロソフトに帰ってからも、先の「ハックフェスト」を実施するときに、Mob Programming でやってみましょう！と提案してみた。お客様と、マイクロソフトのエバンジェリストと Mob Programming をやってみた。最高に詳しいエキスパートがいたこともあり、私が初めてのXamarinの開発であっても、コーディングに参加することができたし、挙動やアーキテクチャもずっと楽に理解できたし、ディスカッションもすることができた。他のメンバーも、Mob Programming を実施して本当に楽しかったという話をしてくれていた。最後にお客様から聞いたハックフェストの感想でも、Mob Programmingへの絶賛にあふれていた。楽しさは、正義だ。
暗黙知を共有できる
次に暗黙知の共有だ。通常の技術獲得の時に、本を読んだりチュートリアルをしたりすることでは得られない部分が実際のプロジェクトで活躍するためには重要だ。ちょっとした「思考回路」だったり、「ツール」だったり、「ショートカット」かもしれない。どういう習慣で、開発をして、名前をつけて、どうやってコミットログをつけるか。
これらの形式化できない「暗黙知」は通常自分が長年かけて積み重ねて、得られるものだけど、Mobだと、他人がどのように、考え、行動するのかを共有できる。これは体験してみないとわからないかもしれないが、相当協力だ。普通こんな機会はない。凄く技術的に優れた人がどういう考えで、どういう手順でコードを書くのか。これを共有できることは、チームのレベルアップの上でも最強だ。
詳細な管理が不要になる
さらに、マネジメントの観点でも革命的なことがある。先の Mob Programming を実践し続けている楽天チームのメンバーが語ってくれたことだが、「タスクを管理する必要がない」なぜなら、常に一緒に作業をしているので、他の人が何をしているか？という情報交換や、シェアの時間が必要ないのだ。この工数はバカにならないし、伝わらない。それぞれがやったことを「レビュー」しなくても、そもそも常にレビューしている感じだから、そんなことも必要ない。
彼らの壁にタスクKanban が張り出されていたが、「それはもう使っていない。Mob をやり始めてからいらなくなった」とのことだ。これって、実はものすごい事じゃないだろうか？もう細かい管理など必要ない。アジャイルやDevOpsの時代からすでに不要だったが、それを上回るほど管理が必要なくなってくる。
マネージャが本物の技術スキルを身に着けるためにも Mob をする
Mob Programming はチームのためであり、マネージャのためのものではない。ただ、チームが Mob Programming に移行すると、私や、今まで技術をあまりやっていなかったマネージャで、本当に技術を今から身に着けたいと思っている人にも最高の仕組みだ。
今まで自分が「管理」していたチームが Mob Programmingに移行して、自分が指示するかわりに、チームが全員で意思決定して、Mob Programming を実施すると、細かい管理は不要になる。その工数をどうしたらいいかというと、リーダーシップと、自分もMobに参加するようにしたらいいのだ。
例えば、技術を本気で学びたい人がいたとしたら、自分で本を読んでコードを書いたり、チュートリアルはやるだろう。しかし、それでも「プロダクション」のコードに対応するためには、「現在のアーキテクチャによる本番でコードを書いて運用する経験」が必要になってくる。これは「独学」では体験できないし、体験したければ、技術力を身に着けるしかなく、卵が先か、鶏が先かという話になってしまう。
Mob Programming が日本の技術力不足を解消するかもしれない
しかし、Mobであれば、自分で勉強は必要だが、Mob Programming に参加できれば、かなり心理的障壁低く、本物のプロジェクトに参加することができ、今の技術でどういうコードを書けばいいかも理解できるようになる。しかもかつてないほど参加への障壁が低い。日本では私含めて、実際こういう人がとても多いと思う。やる気は必要だが、そういう人が仕事をしながら「技術力」を身に着けるための、最高の方法なのではないかと思う。そして、自分のチームの技術を理解できるのだから、リーダシップを発揮したり、チームを助ける際も的確な行動がとれるようになるだろう。簡単ではないが、日本がソフトウェア技術的にも優秀になるためのチャンスがここにはあるのかもしれない。チームからしても、一人モブに加わったからといって生産性を損なうとかないので、この目的で考えると最高のツールだと思う。
simplearchitect.hatenablog.com
おわりに
私も今後は、楽天さんで教えていただいた Mob Programming をより実践して日本が、自分が世界でも勝てる方法を継続して探っていきたい。メソッド屋としては、最高にワクワクする方法を体験できて最高に幸せだ！是非皆さんも試していただきたい。
私、もしくはマイクロソフトのエバンジェリストのメンバーと、世界で誰も解いてない問題を、Azureで解決したいと思う方は是非私とハックフェストをMob Programming の形式で実施して、その威力を味わっていただきたい。楽天の先ほどのメンバーは現時点で日本最高のMob実践チームだ。NECの方面でも実践しているチームがあると聞く。皆様も是非 Mob Programmingの威力を実感していただきたい。Mob Programming でこの業界を変えよう！
新技術導入を米国並みに！働き方を変えて生産性を高めるための８つの習慣
クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める８つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください！また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。
元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ１０数分以下のサイズになっています。
序章：イントロダクション
８つの習慣をなぜ作成したのか？どういう効果があるのか？ということについて解説しています。
私が８つの習慣を作成するにあたり、感じたこと、思ったことはこのあたりのエントリに起因している。
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
次からは、各習慣についての動画をリストしておきます。補足のブログや動画へのリンクをつけておきます。またブログの最後に動画で使用したプレゼンテーションをつけておきました。
第１の習慣 Be Lazy
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第２の習慣 リスクや間違いを快く受け入れる
simplearchitect.hatenablog.com
第３の習慣 不確実性を受入れる
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第４の習慣 サーバント・リーダーシップ
サーバント・リーダーシップに関してはもう一つビデオがあります。従来は、通常のマネジメントをしていたマネージャが、どのようにサーバント・リーダーシップに変わっていったか、恐れは、そしてその効果やトレードオフについての体験をインタビューしたビデオがあります。こちらもよろしければご覧ください。
Takahiro Kaihara さん、 Mitsunori Seki さん、撮影ご協力ありがとうございました！
simplearchitect.hatenablog.com
第５の習慣 セルフマネジメントチーム
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第６の習慣 従業員への信頼
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第７の習慣 個人の自信
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第８の習慣 階層関係のパワーバランス
simplearchitect.hatenablog.com
プレゼンテーション
おわりに
西洋文化インストールという８つの習慣は変化への対応や、生産性を高めるための習慣を、マインドセットとして整理できたと思っております。是非楽しんで学んでみてください。ロッシェル・カップさん、本当にご協力ありがとうございました！皆さんの生産性が向上しますように！
「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第３の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。
ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。
不確実性を受入れる
- マネージメントは詳細まで細かく練られた計画を期待しない。
- 予算と報告のプロセスは精密な結果の予測を要求しない。
- 内部プロセスは計画や優先順位の変更に柔軟である
- 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ
- システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる
- 学びに基づいて、変化を精力的に行う。
この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思われる習慣だ。 この考えなしに新しいモダンな開発スタイルのマネジメントは不可能といっても過言ではない。逆にいうと、あなたがこの習慣をマスターすれば、日本人の良さも生かしながら相当かっこいいマネージャになれるかもしれない。
「納期は絶対」の神話
日本人には、「不確実性の忌避」という文化的性質があるらしい。つまり、不確実な状態を嫌うので、先に予見したり、計画するということをがっつりやってしまいがちになる。比較的先が見通しやすい産業においてはとても有利な性質かもしれないが、ソフトウェアのように非常に先の見通しが立てにくく変更が多い分野にはこの性質がマイナスになりがちだ。我々の傾向として、よくわからないものがあった場合、先に試してみるよりも、やる前に、いろいろ「検討」したりしてしまい、なかなか着手できなかったり、どんなに計画しても分からないものに対して、一生懸命予見し、完璧な計画を立てることに時間を使ったうえ、一度立てた計画が実態にそぐわなくても、その「計画通り」に遂行しようとして、プロジェクトが炎上してしまうという場面もしょっちゅうある。
我々は「計画通り」でないと「失敗」と思うかもしれないが、そもそも未来を予見できる人なの世の中に存在しないのではないだろうか？なぜ「計画通り」でなければならないのだろうか？計画はあくまで、当初の見込みで、作業を円滑に進めるためのものじゃないだろうか？よくわからないものに対して、事前に検討しても予見できない。その予見に時間をかける暇があったら、検証するほうがよいというのは前回のテーマにもつながることだ。
simplearchitect.hatenablog.com
私が、クロスカルチャーの専門家のロッシェルカップさんから聞いた話で衝撃的だったのは、「納期（Deadline)」の意味が日米で異なるということだった。日本の場合は、納期に、予定された機能の納品物を、予定された品質で提供するのが必須であるという感じだ。しかし、米国では、「納期は柔軟」であるらしいと聞いて目が飛び出るぐらいびっくりしたのと同時に、そういえば同僚のことを思い出しても、日本ほど「納期」に厳しくない。大抵は、納期にリリースするけど、予定よりも少ない量に変更するいうことはしょっちゅうだ。少なくとも納期を守るために、徹夜とかいう場面は見たことがない。我々はたぶん納期に厳密すぎて無理をしすぎる傾向にあると思う。それはどの程度バリューがあるだろうか？
ソフトウェアエンジニアリングでの考え方
そもそも、Q(品質)C(コスト)D(納期)+S(スコープ)は、トレードオフの関係にある。納期を短縮したければ、お金をたくさん払うか、品質を落とすか、提供する物量（スコープ）を減らすかという塩梅だ。予定通りQCDSをすべて達成するというのは非常に困難だ。だから、多くのマネージャは、大きなバッファを持って、それを達成しようとする。私も昔は常に３０％ぐらいのバッファを残しておいた。そもそも、ソフトウェアの場合は変更が入るので、当初の計画通りにはまずいかない。
つまり、エンジニアリング的には当初に想定された、QCDSをトレードオフせずに納期通り納品するのはほぼ不可能に近い。しかも、その計画はソフトウェアの場合、統計的にも相当予見しにくいものである。段階にもよるが、最初の段階で計画したコストの３倍になる確率も十二分にあるといった精度でしかない。これを信じるほうがよっぽどリスクが高い。
実績のみで判断する
その代りどうすればいいか？というと、単純化していうと「実績」だけで判断し、「納期」を固定して「スコープ」つまり、予定の機能を出し入れするほうがいい。
納期はまもって、その日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回す。もしくはやめてしまえばいい。ある機能が１週間遅れたからといってそれがどの程度インパクトがあるだろうか？それが「達成される」という前提で計画を立ててしまうから、「必達」とかになってしまうけど、そもそもそれは計画なので「いまのところは、こういう予定」ぐらいの感覚で見たほうが確実じゃないだろうか？
例えば、マイクロソフトや、他のサービスプロバイダを見回してみても、必ず納期通りすべての予定の機能をリリースしているソフトウェアジャイアントは存在するだろうか？ロードマップを持つことは見通しがよくなってよいことだが、実際リリース予定の日が近づくと、しれっとその機能が削除されていることはざらではないだろうか？ それはどの程度のインパクトを起こすのだろうか？そして、その納期とリリース機能を守ることは、プログラマの生活や健康や楽しみを犠牲にして守るほどのものだろうか？そもそもマネジメント的にも、中長期的には生産性は疲弊するためどんどん低下してしまうので効率が悪い。
予定日にはリリースする。そして、例えば開発が１週間単位でおこなわれているならば、前の週、その前の週とかがどの程度の量をこなすことができたかを測定して、次の週、その次の週も、たぶんそれぐらいの量はこなすことができるだというという想定を立てるとより現実的な計画を立てやすくなる。
ただし、この計画も状況は刻一刻と変わるので、ずっと現実的であるとは限らない。チームの誰かが病気になるかもしれないし、チームの生産性が上がるかもしれない。楽観的でも、悲観的でもなく、現在のチームの生産性を測定して次の直近の予測に使うという方法だ。そうしておけばシンプルだし、気合や根性の正解や、楽観的もしくは悲観的な感覚が入り込む余地が無くて楽ではないだろうか？
さらにこれがいいことに、無理してリリースするとすると、問題を覆い隠す。つまり、チームの生産量を超えた量を一定期間で達成した結果、今回出来たら、次回もこれぐらいできるよね。ってなりがちだ。そうするとどんどん無理が積み重なっていく。そして、無理をしていることが上層部や周りにも伝わらないことになる。だから、問題も改善されない。
無理を積み重ねるのではなく現実を見て、「工夫」をしていこう。たぶんポイントは、第一回でご紹介した「物量を減らして、より大きな価値を生み出す工夫」だ。つまり「やらないこと」を見つけることだ。
詳細な計画を求められないために
もしかすると、あなた自身ではなく、上の人から詳細な事前の計画を求められるケースがあるかもしれない。詳細な計画はコストも時間もかかるうえに、着手を遅らせるという最悪な結果を招く（少なくともソフトウェア開発の場合は）。そのようなケースだと、プロジェクトが始まる前に、その上の方に「こういう形式でレポートします。今回 Agile / DevOps なので」ということを事前に合意しておくとよい。そもそもそれが通らないって？その場合は、私のお勧めは例えば、Agile / DevOps をやる場合にはお勧めの方法がある。Value Stream Mapping という現在の開発プロセスを見える化して、改善ポイントを見つけ、リードタイムを短縮することができるツールを使うとよい。
このツールを使うと、素晴らしいことに４時間ぐらいで、無理なくリードタイムを短縮できる「見込み」を知ることができる。例えば、ある会社さんでは、リードタイム8.5か月だったのが、Value Stream Mapping を実施して自動化したら、1週間になる見込みだとわかって、数か月後、実際に1週間…どころか、1週間に数回ソフトウェアをデプロイできるまでになった。上層部にとって、細かい開発プロセスはどうでもいいことなので、こう言ってみるといい「DevOps という開発のやり方をやってみたいのです。我々のプロジェクトのリードタイムが今8.5か月なんですが、それを入れると、1週間に短縮できるみたいです。やってもいいですかね？」とかいうと大抵は「そらやるしかないだろう！」という話になる。そして、「DevOpsをやるためには、レポートの実施方法も変える必要があるので、今度、どんなレポートになるのかを事前にお見せしますね」と事前に合意しておくといい。
そうすれば、上の人は大抵シンプルなレポートに喜んでくれる。そもそも、細かいどうせ把握できないものより、リードタイムが短くなるほうがよっぽどうれしいはずなので、先に「どうせいっても無理」とあきらめるのは非常にもったいないのだ。
例えば私はチームから出すレポートは次のようなものをおすすめしている。上の方に行けば行くほど、シンプルなレポートが好まれる。
いまならさらに、BIを活用して、自動でダッシュボードをつくっちゃってもいいだろう。
確実に納期を守る方法
中には納期が絶対的なものが存在する。それは米国も日本も変わらない。オリンピックが開催されてそのアプリの納期を伸ばすのは意味があるだろうか？じゃあどうすればいいかというと単純だ。本当に納期を割りたくなかったら早く始めたらいい。
さらに、ソフトウェアの場合とかだと、既に動いているものを「リリースする」と約束すればいいだろう。例えば今だと、フィーチャーフラグというテクニックがあり、実際の機能がすでに盛り込まれているが、公開するスイッチをもっておき、そのスイッチをオンにしたら特定のユーザにのみ公開されたり、全体に公開されるようにしておく。そのスイッチを使って、先に実装しておいて、一部のユーザにつかってもらって、実際に動くし、価値もあると判断してから、本当の「公開」をするようにしたらどうだろうか？ これは、Azureや、Windows10をはじめマイクロソフト以外でも多く使われている方法だ。
皆さんの開発だと、納期を固定して、スコープを変動させる考えがある。つまり、納期に何らかのリリースをするけど、すべての予定されていた機能のうち、実装できたものをリリースするという考えだ。つまり、出来なかった分は入れないようにする。 この考えの場合、含まれる機能が増減しても、ユーザにとって価値のあるものがなんらかリリースられるようにしておくとよい。機能A、機能B、機能Cがリリースされないと意味がない、、、という場面では、機能A、機能B、機能Cを順につくるのではなく、機能A、機能B、機能Cを同時につくるけど、想定よりずっと簡単で、シンプルなものにする。だけど、連携してなんから動作して、価値を提供する単位でつくると、常にリリース可能な状態ができあがる。そうすれば、機能の増減に関係なく「いつでもリリース可能」になる。ただ、予定された機能がすべて納期通りにそろうとは限らないというだけだ。
「不確実性を受入れる」プラクティス
さて、なかなかこれは受け入れ型考えかもしれないが、モダンなソフトウェア開発メソッドではこの考えが基本となってくるので、すくなくとも「思考回路」だけは手に入れておきたいところだ。そうすれば、すくなくとも「選択可能」になれる。 まずは、この「不確実性を受入れる」ために自分で練習できるプラクティスを考えてみたい。
対象者
- 上位マネジメント
- プロダクトオーナ
- チーム
おそらく、対象者のうち、最もこのプラクティスに影響をうけるのは、上位マネジメントだろう。次にプロダクトオーナ。だが、実際には上位マネジメントの方は詳細を知りたがる人はあまり多くない。中間層のマネジメントの方に詳細を知りたがる人が多いイメージだ。
1. 楽に達成できる計画で仕事をしてみる
日々の仕事を実施して、仕事を他の人にお願いするケース（そういうのが無い人は自分の計画を立てるとき）に、その人の能力でいうと、これぐらいの日数で出来るという日を納期にするのではなく、もっともっと余裕で出来る程度の日程を設定しよう。日本にいると「なるはやで」とか、家に帰宅後「明日までに」というオーダーで仕事を依頼されることもしょっちゅうあるが、向こうにいくと、こういう依頼は「マネージメント能力の欠如」としてみなされるらしい。それは、納期を割る確率が非常に高い賭けをしているようなものだし、依頼先にも相当な負担をかける。そして、日々仕事をしていると、割り込みが入らないことのほうが少ないだろう。だから、かなりの余裕を持った日程で、しかも、早めにチェックポイントを設けて、仕事をやってもらうようにしよう。わたしだと、どうしても、自分が「理想的にできる時間」とかで見積もってしまいがちで、「あーわし全然仕事が遅いなー」とがっかりすることもなくなる。人間そんなものなのだ。
それがうまく出来なかったら、どうしたらよかったか、改善をしてみよう。ただ、「計画通り」が良いという思考は忘れてしまうほうがいいと思う。計画通りはよい事とは限らない。ものすごーーーく余裕があるかもしれない。そしたら効率悪いではないか。そして、それは、「新しいことに対応しなかった」ということも意味する。計画は単に「見通しをたてて、仕事を進めやすくするため」のものでしかない。未来は予見できない。計画や、物量ではなく、自分が創出した「価値」をどの程度定常的に提供できているか？を判断基準にして考える練習をしてみよう。そもそもその納期にどれぐらいバリューがあるかも考えてみるといい。この背景には、沢山物量をこなすのが生産性がいい事であるというマインドセットが背景にあるかもしれない。
また、初回に学んだ「時間を固定して、中身を変動させる」というプランニングの方法を練習しておくとこちらにも効果が上がる。
simplearchitect.hatenablog.com
2. 「無理・断る」と言う練習をする
先のロッシェルさんと一緒にやったワークショップで、あるとき、ブラジル人と日本人の混成チームがあった。ロッシェルさんは、日本人の人に対して次のように言った「もし、みなさんが仕事で忙しいときに、上司からこの仕事をやって欲しいと言われたらどうしますか？」というと、日本人の人は、「わかりました」といって残業とかでカバーするという回答だったのだが、同じ質問をブラジル人にすると「私は今仕事で手一杯だからごめんななさい」と断ると言っていた。
心理学では鏡の法則というのがあり、自分に適用しているルールを知らず知らずのうちに、他人に適用してしまうというのがある。例えば、自分に納期厳守を課している人は、他人にもそれを求めてしまう傾向があることだ。我々のDNAには骨の髄まで納期厳守のDNAが刷り込まれている。 つまり、自分が寛容になるためには、自分もそれでOKにしてしまうといい。そのブラジル人の人みたいに、そういうケースがあったら、「無理」だとか「断る」ということをしてみよう。そのうえで、どうしたらいいか相談にのってあげよう。自分が我慢して受けてしまうと、改善につながらないし、自分以外の人にも我慢を強要してしまう傾向になる。
「無理」というのを認識したうえで、楽に達成できる計画に２人で落とし込む計画に変更するのはどうだろうか？無理であることがわかったら工夫したらいいし計画に無理があったサインかもしれない。「ここまでだったら、協力できるよ」というラインについて話をするのもいいかもしれない。こういうマインドセットをチームでシェアすると、「無理！」が言いやすくなるので、８つの習慣をチームでシェアしておくのはおすすめだ。「無理を承知で」のお願いの連鎖が、みんなの疲弊を生んでないだろうか？「無理」と言えるようになったら、「無理じゃない」計画に対してみんな対応できるようになる。
3. 他の文化の視点を学んでみる
先ほどのブラジル人と日本人のチームの例ではないが、日本人ではない、他の国だとどうなっているだろうか？というのを学んでみる練習も楽しい。私は英国留学を３か月していた時があるが、その時マーケットリーダーというビジネス英語のテキストを使っていた。その内容は結構面白くて、いろんな国の商習慣や文化習慣についても学べる構成になっていた。我々は日本だけで生きて育っているので、例えばの納期を守るのは人として当然ぐらいの感覚がある。
しかし、他の国だと、時間通り待ち合わせに来るのが失礼という国すらある。先ほどのブラジルの例だと、日本人よりダイレクトに思っていることを話す。しかし、デンマークだともっとダイレクトだし、日本よりももっと、ダイレクトに思ったことを表現しない国もある。 そういったことを学んでいくと、もはや「常識ってなんだっけ？」という感覚になってくる。そうすると、「自分の常識」というものも、他の人には当てはまらないなぁ。という感覚になってくる。下記のロッシェルさんのクローバるマインドセットの記事はとても興味深い。もしご興味がある人はぜひご一読いただきたい。
ビジネスで成功するための グローバルマインド養成講座｜ビジネス英語｜アルク
我々は計画の変更に不寛容だ。前回も書いたが、誰もが失敗と思っているプロジェクトで価値がなくなっても計画通り継続してしまう。しかし、「リスクや間違いを快く受け入れる」マインドセットがあれば、計画通りいかなかったことを受入れて、計画を変更するマインドセットにつながるだろう。計画自体が仮説でしかないので、変更されるものなのだ。「Be Lazy」のマインドセットがあれば、無理に全ての物量を納期通りリリースすることに本当に価値があるかを考え直すことが できるかもしれない。
他の例でいうと、マイクロソフトで私に降りてきている方針も１年の間にずいぶん変わってしまった。数か月で変わっていく。それは健全なことだと思う。だって、状況が変化していくのだから、変化に対応することのほうがよっぽど大切だ。そういう環境にいると、時間をかけて計画を立てることはばかばかしくなる。どうせ変わるのだから。 つまり、「計画の変更」は悪ではない。現実をみて、フィードバックを受けての変更で、むしろ善だろう。そういうマインドセットをチーム内や関係者でシェアしているだけで、その人がさぼっているわけではなく、「不確実性を受入れる」マインドセットで行動しているということが周りも認識できる。そしたら周りももっとやりやすくなるだろう。
じゃあ、さぼる人はどうするんだ？という意見もでそうだ。それはまた違う習慣でお話ししたいが、性善説・性悪説があるときに「性悪説」でかんがえると、「性善説」で考える時より「ずっとコストがかかる」ということだけはシェアしておこう。是非「サーバントリーダシップ」の回をお楽しみに。
「検討」は無駄である - リスクや間違いを快く受け入れる第２の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。
最初の習慣は次のブログで紹介してみた。
simplearchitect.hatenablog.com
リスクや間違いを快く受け入れる
- リスクを背負うことは推奨されている
- 間違いを厳しく批判したり懲罰したりしない
- 失敗から学ぶ態度
- Fail Fast(早く失敗する）
- 実験が推奨されている
- 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される
- 非難や恐怖感の無い環境
この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない！
間違いや失敗に対するイメージの違い
マイクロソフトのインターナショナルチームで働いていて気づいたことだが、同僚や上司がよく「Miserably Failed(惨めに失敗した)」という言葉を頻繁に使っていることだ。日本では「決して失敗は許されない」というプロジェクトが過去にも多々あった。しかし、人間なので、いくら失敗が許されない状況だろうが、どんなにしっかり準備しようが、「失敗」は発生するのだ。日本だと、例えばこってこてに炎上して、お客さんが激怒し、中身もボロボロなのに、納期と予算を守ったという理由で「成功」したということになっているプロジェクトをいくつも見てきた。文化的にも失敗したら「切腹」したり、「左遷」されたりと、悲惨な目にあうので、日本の社会では「失敗した」ということをとても言いづらい。だから、多くの人は失敗しなさそうな無難な方に流れてしまう。本当にこれはもったいないことだ。
一方、インターナショナルチームで気づいたことだが、失敗とか、間違いとかで怒られたことは無いといっていい。失敗したり、間違いに気づいた後に、本社に「フィードバック」をすると、「フィードバックをありがとう！」と大変感謝される。そして、誰がやってもうまくいくようなことを実施しても誰も評価してくれない。例えば今、お客さんの本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこでいつも言われていることは「お客さんの最も難しい問題を解いてこい」と言われている。つまり、この世のどこにも情報が落ちていないような問題解決をやること。これが評価されるのだ。誰かが失敗しても、黙ってることもないし、失敗しても「あいつはだめだ」とか言ってる人を見たことがない。だからすごくチャレンジしやすく感じる。
だから、より難しいことへのチャレンジも大変気楽にできる。むしろチャレンジしないほうが、将来が不安だ。だから、成功しようが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく。この考えはアジャイルや、リーン、DevOps に全て共通する考え方だ。だって、普通人間は間違うんだもの。
最も恐ろしい事
この「リスクや失敗」を恐れる性質は、生産性の面で劇的な問題をもたらしている。失敗したくないので、ともかく慎重になるのだ。慎重に時間をかけたから失敗を減らせるわけでもないし、時間をかけている間にライバルは次に進んでしまう。
前にもブログに書いたことがあるが、私が米国でお客さんとディスカッションをしていて一番驚いたことがある。リックを１つだけ背負ったにいちゃんが、私とDamien に会いに来た。彼は私とDamienと１時間ぐらい話をしたあと。「うん。やろう」と言って、５００人規模のハックフェストをその場で決定して帰っていった。
日本で同じことが起こるとすると、まず、ベンダーが提案して、顧客がそれを見て、Excelで質問票を作り、、、といったやり取りを数か月行って、結局やっぱりやめたみたいなことがしょっちゅう起こる。これはベンダーにとっても顧客にとっても大きな損害だ。時間だけが過ぎて、工数を使って結局何も生み出せていない。ノーバリューなのだ。１時間で物事が決まって、実際にハックフェストを実施すると、本番環境でいろいろ起こるような検証が数日で出来てしまう。今の時代はExcelで質問票を作っている場合ではないのだ。それをしている暇があったら、実際にハックをして確認したほうが１００倍確実だろう。今の時代、いろいろ検討ばかりして、さっさと「やらない」ことが最大のリスクになってくる。
そして、こういうことが起こると、恐ろしいことに失敗確率が増える。卓上でいくら検討しても、実際やってみないとわからない。卓上でやっていたら、結局市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーは適切に動作するか？というフィードバックは、結局実施するまでわからない。だから、失敗確率が高くなる。だから少なくとも変更がやりやすいソフトウェアは、アジャイルのような早く実装して、早くフィードバックを得る方法が採用されている。さらに、機能しているものを変更して失敗するリスクがあるものを避ける傾向も強くなる。現状維持だ。
同じ失敗ばかり繰り返す人は？
じゃあ、まったく進歩せず、同じ失敗ばかりを繰り返す人はどうするんだ？と思うかもしれない。それはごもっともだ。その解答は「評価」だと思う。他の習慣で、「従業員への信頼」という習慣がある。人に対してごちゃごちゃ細かいことは言わない。最初に会社と合意したゴールつまり大まかなKPIを達成していたら、失敗しようが、人より不器用だろうが何だろうがいいのではないだろうか？その人を信用しよう。
できないのなら、評価のタイミングで KPIが達成しないので、給料が下がったりクビになる。ただそれだけの話だ。だから、評価はそのタイミングでよくて、失敗は結果論であるので、それよりも「フィードバック」を得たかを気にしよう。私のパートナーのクロスカルチャーの専門家のロッシェルさんがこういう話をしてくれた。米国では、プロジェクトが中止になったら、プロジェクトが成功したのと同じようにパーティをする会社があるらしい。なぜなら、その失敗から「学ぶ」ことが出来たからだ。
この「習慣」は生産性に非常に影響してくるものだ。逆にいうと、これを身に着ければ、簡単にライバルに差をつけることができる。 じゃあ、この「習慣」を獲得するにはどういう方法があるだろうか？
「リスクや間違いを快く受け入れる」プラクティス
- 成功・失敗より「フィードバック」を歓迎するムードを作る
- 「検討」をやめて「実証」する
- 「早く失敗」できるように考える
それぞれについて解説してみよう。マネジメント、チーム、プロダクトオーナ（チームに出すリクエストをきめる人）のロールがある場合、どういった順番で重要なプラクティスだろうか？
対象者
- 上位マネジメント
- プロダクトオーナ
- チーム
これもほぼ全員だが、誰かが、誰かの「失敗」を責めるケースが多い順に考えてみた。
1. 成功・失敗より「フィードバック」を歓迎するムードを作る
最初のプラクティスだが、チームメートや部下が成功したら当然喜んであげたい。失敗して、フィードバックしてくれたら、失敗する方法がわかったのでこれは大きな進歩なので、感謝しよう。失敗して「怒る」ということはあなたと対等である人を「子ども扱い」しているのと同等だ。そういう気持ちはわかるが、「怒る」という選択肢はなくして、「フィードバック」を促進するようにムードを作ろう。 たとえば、メールで、成功の報告を見たら、みんなで「おめでとう」のメールを返そう。メールで、失敗とそのフィードバックをしてくれたら「感謝」のメールを返そう。マネージャなら、本人の評価はあくまで約束したKPIの達成の可否であり、小さな成功や失敗ではない。そういうことを明確にしていこう。このムード作りは、上位マネージメントの方から仕掛けていただくほうがいいかもしれない。
2. 「検討」をやめて「検証」する
あなたがユーザ企業や上司ならば、パワーポイントに書かれた大量の資料を要求したり、完全無欠の検証を期待するより、時間をかけず、さっさと「検証」してフィードバックを得るようにしよう。人間未来は予測できない。例えば、あなたがユーザなら、ベンダーに「提案」を依頼すると、例えば私が大手のSIに勤務しているときは、提案書を作るのに何人もの人が数週間もかけて作っていた。しかし、正直に言うと今の時代、大量に検証しても制度が低いし、マニュアルに「出来る」と書いてあっても実際作ってみるとできないなんてことはしょっちゅうある。その工数は、あなたがそのベンダーに発注したときにOnされてね返ってくる。Lose-Loseの関係だ。
そんなのよりも、クラウドの時代でさらに加速したが、実際に作ってみるほうがよっぽど早い。そして、過去と比べると圧倒的に早くできてしまう。だから、ああでもない、こうでもないと検討するのではなく、実際に作ってみる「ハックフェスト」などを通じて、動くもので検証しよう。 ほかにもあの機能を実装するべきか、この機能を実装すべきかと検討している暇があったら、実際に実装して、ベータテストで実際のお客様で試してデータを取ろう。思ってもない結果になるかもしれない。 今の時代最もリスクなことは「何もしない」ことだ。検討している暇があったら、今すぐ実装して試してみよう。データをとろう。
例えばアーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがある。それを意思決定するのは簡単だ。答えは「どちらでもいい」ので趣味で選べばよい。なぜなら、圧倒的に差があるのなら、決めあぐねるはずがないので、どっちを選択しても大差ないということなのだ。 また、昔と違って、ツールやサービスの単価は高くない。１つのツールで失敗したら次のにさっさと乗り換えればいい。つまり比較検討など無駄だ。それより早く前に進もう。実践の経験を積み重ねるほうがよっぽど貴重なことだ。
3. 「早く失敗」出来るように考える
これも、2.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。例えばウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。つまり、実際の「フィードバック」を受けるまでの時間が長い。これが問題だ。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう！
いかがだっただろうか？もっといいプラクティスがあるかもしれない。私もまずは３つをピックアップしてみた。もしもっといいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。
Scrum / DevOps の導入を加速するグローバルマインドセット ～８つの習慣 その１ ～
クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「８つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。
今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「８つの習慣」を初めて発表させていただいた。
「８つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうまくいかなかったり、効率が悪くなってしまう。
そこで、米国並みのスピードでの技術導入や、本質的な導入を目指す方のために、「８つの習慣」を考案した。 Agile / DevOps の導入を本質化し、加速するための西洋文化のマインドセットだ。日本人は「生産性」が悪いせいでグローバル的には大変損をしていると思う。それさえ何とかなれば、日本人の文化の良さを生かして、ソフトウェアの世界でも輝ける存在になると私は信じている。重要なことは、西洋を崇め奉りたいわけではなく、日本文化と西洋文化の考え方を「選択可能」にすることだ。
ただ、講演では時間が４５分なので、すべてを解説する時間がなかった。まずは「興味を持ってもらう」ということをターゲットにしたので、「実際どうすればいいかわからない」だろうとう反省がある。今後ロッシェルさんとビデオを公開して「８つの習慣」をより学びやすくするつもりだが、このブログでも不定期に「８つの習慣」が何で、具体的にどういうことをすれば導入できるかについて解説していきたい。
「８つの習慣」を理解する方法
「８つの習慣」は「マインドセット」なのでなかなかに理解が難しい。ただ、一番簡単な方法がある。米国人、もしくは、西洋人のチームに参加して１年も一緒に仕事をするといい。そしたら簡単に彼らのマインドセットを体験できるし、その破壊力を体験できるはずだ。そして、彼らが「人として優れている」とかではなく、我々でも十分できる「習慣」のために生産性がいいことを体験できるので、簡単にマネできると思う。
ただ、問題は、そういう環境にいる人は国内にはあまりいないということだと思う。だから、そういう人のために、国内にいても、そういうことを学べる方法はないだろうかとロッシェルさんと一生懸命考えたものだ。もちろんまだ出来たてなので、まだまだの部分はあると思うが、それでも改善を進めながら、技術導入を本当に加速したいと思っている人がにお役に立てればと思う。
「８つの習慣」
- Be Lazy
- リスクや間違いを快く受け入れる
- 不確実性を受入れる
- サーヴァント・リーダーシップ
- セルフマネジメントチーム
- 従業員への信頼
- 個人の自信
- 階層関係のパワーバランス
これがロッシェルさんとディスカッションして整理した、「８つの習慣」だ。我々がAgileやDevOpsをうまく導入するために必要な西洋のマインドセットを整理してみた。 今回は最初の習慣である Be Lazy から具体的にどういうことをすれば、導入できるのかということに関して考察してみたい。
Be Lazy
この習慣は、スクラムや、リーンの世界でもよく言われており、アジャイル以降の開発で大変重要なポイントになっている。このブログでも何回か取り上げているが、一言でいうと「より少ない時間で価値を最大化するという考え」だ。この考えを学ぶにはエッセンシャル思考という本を読むのが一番おすすめだ。
Be Lazy を達成するための習慣
- 望んでいる結果を達成するために、最低限の努力をする。
- 不必要や付加価値のない仕事をなくす（過剰準備含む）
- 簡潔さを目指す
- 優先順位をつける
- 時間や費やした努力より、アウトプットと生産性に重点を置く
- 長時間労働しないように推奨する
- 会議は会議の時間内で効率的かつ生産的に価値を提供する
このBe Lazy の一覧を見ると、たいていの人は「当り前じゃないか？」と思うのではないだろうか？そこに落とし穴がある。例えば「優先順位をつける」という項目について考えてみよう。よくスクラム等で言われる言葉で「バックログに優先順位をつけて、優先順位の高いものに集中しよう」ということがある。この言葉を聞いて、私のような日本人の人にイメージされるのは次の図の左のようなイメージじゃないだろうか？
リストに上がっているタスクが５つぐらいあるけど、「全部できないから、優先順位をつけて、どうしてもできないのは無理だから実施しないようにしよう。でも時間が許せば全部実施したい。」ところが、同じ言葉に対して、海外のメンバーを観察していると、右のようなイメージをもっているようだ。「最初の１個をピックアップしてやったら他はやらない。その１つのフォーカスする」ぐらいの感じだ。
こういう場面はインターナショナルチームにいるとしょっちゅう目にして、そのたびに驚いていたが、例えば、バリューストリームマッピング（上記の図をプロジェクトメンバで作成しプロジェクトの無駄を発見するセッション）を、同僚のデビッドとやった時に、彼は「リリースマネージメント」というDevOpsプラクティスの一つしかアドバイスしなかった。帰りの車で彼に聞いた「私から見たら、それ以外にもDevOps プラクティスである Automated Testing もできていないし、承認作業多いのでビジネスプロセスも変えないといけないし、ほかにも沢山あるじゃない。なんで一つだけしか言わなかったの？」と聞いたら「だって、沢山言ってもそれができるかな？まず大切なことは一番インパクトのある一つを確実にすることが大切なんだ」と彼は言っていた。
我々はすぐに「あれも、これも」やらないといけないと思ってしまうが、「すべき」より、「実際にできるキャパ」を考えるほうが生産性的には有用だ。2-8の法則でも、20%の仕事が80%の価値を生むのだから、20%をしっかりやるとよくて、100%全部やろうとするから工数もかさむし、アップアップになってしまう。
我々の傾向としては、100個のタスクがあったら、100個やろうとする。たけど、本当に重要なのは20%程度だろう。そういう知識があっても、20%のタスクが終わって80%の価値がでても、残りの80%の仕事をして完璧を目指してしまう。でも、彼らを観察していると、20%のタスクを終えて、80%の価値をだしたら、残りの80%はやらずに、次の80%の価値を生む20%の新しいタスクに取り組む感じだ。そうすれば、100%の仕事をしたケースに比べて、40%の工数で160%の価値を持つ仕事ができることになる。
ざっくりとしたイメージで言うと、彼らが無理なく生産性が高い理由は、こういう理由だ。つまり、実施すべき「物量」が少なく「価値」が高いものを如何に作っていくか？の工夫を常日頃からしているのだ。
simplearchitect.hatenablog.com
彼らが優秀とかではなく、「やることを減らすか？」ということに注力している。多くの人は、例えば多くの機能を速く実装することはよいことと思わないだろうか？本当は「悪」である。なぜなら、統計によるとソフトウェアの機能のうち４０％ぐらいしか使われない。だから、100%を全力でつくったら、60%が使われない。しかも、その60%でバグが発生したら直さないといけないし、60%もコードベースが多くなるので、変更があった時にコードを読む量がさらに増えてしまう。
つまり、「やることを減らす」ことは大変素晴らしいことなのだ。ところが我々の感覚からすると、全部やらないのは、何となく悪いことに感じてしまう。だから、いまある手続きや、やり方を「減らす」のは苦手だ。だけど、重要なことは「価値」であるのと同時に、「減らすこと」自体は非常に価値がある。
例えば、マイクロソフトに在籍している間に２回報告システムが変わった。どんどん手続きが「楽」になっていっている。ミーティングも毎週だったものが、２週間に１回になったり、１年に４回あったレビューが少なくなったりとか平気で起こっている。そうすれば、それに使っていた時間が他の優先順位が高いことに使えるのだ。 しかし、「価値」というものはよくわからないものだし、どうして「より短い時間で、価値を最大化する」ことができるだろうか？ 次のようなことを実施してはいかがだろうか？
Be Lazy プラクティス
いくつかセルフチェック出来そうなプラクティスを考えてみた
1. ひとつだけピックアップする
2. 時間を固定して、出来ることを最大化する
3. 過剰な「準備」と「後でやる」をやめる
我々は西洋系の人と比べて、完璧主義の傾向が強いと思う。重要なもの、そうでないものも同じ感じで「ピカピカ」に磨いてしまう。だから時間がかかってしまう。ただしこれは、いい点も悪い点もある。例えば西洋の人は「ピカピカ」に磨く能力が我々に比べてない気がする。我々に問題なのは重要じゃないこともピカピカに磨いて工数をつかってしまうことだ（例えば、文章を書くときにExcelの細かいレイアウトまでこだわるとか）。これをやめたら、生産性が上がって、西洋の人と生産性で競争できる上、重要なことだけ「ピカピカ」磨いてやれば、ものすごい競争力になるはずだ。だからまずは、見習うところは見習うほうがいいのでは？というのが私の考えだ。
対象者
スクラムや DevOpsチームでの使用を想定するとすると、本プラクティスをマスターしておくとよい人は次の人だ。
- プロダクトオーナ
- 顧客
- チーム
- 上位マネジメント
つまり、全員が該当する。ストーリの優先順位づけや、機能のどれを実装するか否かという場面で非常に生産性に影響する。だから、プロダクトオーナや、顧客が特に深く理解している必要がある習慣だ。もちろんチームメンバも、本当に必要な機能、そして不要な機能をプロジェクト全員で見つけだすために、重要になってくる。また振り返りを行い、プロセスの改善を実施するときも如何に「楽」をしてより高い「価値」を生み出せるか、何を「やめる」かをディスカッションするための基本的なマインドセットとなる。
さて、これらのプラクティスについて解説してみよう。
1. ひとつだけピックアップする
これは、インターナショナルチームで周りの人を観察して彼らのように出来るようにマネして実施しているプラクティスだ。私は優先順位をうまくつけるのが彼らに比べて本当に苦手だ。あれも、これも大切に見えてしまう。だから、そういう時は、思い切って、一番重要なのはどれか？と考えてそれだけやろうと考えるようにすると、ちょっとマシになってきた気がする。最終的に３つピックアップするケースでも、まず最初の１つだけピックアップする癖をつけている。そのあと残りの２つをピックアップしている。
自分がやるべきと思っていることをスルーするのは恐怖があるが、結局それを受け取った人もたくさんだと理解できないのだ。最大でも３つぐらいだろう。一番重要な「ひとつだけ」ピックアップする癖をつけると、時間が無くなった時も、少なくとも「一番重要」なことは実施できている状態になれる。
そうしていくと、「やらないといけない」と思ったことをやらなくても、結局問題にならないことがわかってくる。どうでもいいことを１０やるより、１番重要なことを時間をかけてしっかりやったほうが大抵のケースはうまくいくし、沢山のことをいっぺんにやっても、本人はやった気になるけど、忙しいだけであんまり成果が出ていない感覚になる。
すべてのケースで「ひとつだけピックアップ」が通用するわけではないが、「ひとつだけピックアップ」のプラクティスを３回繰り返せば３つピックアップできる。しかし、重要なのは、１０個のうち２個しかやらないことは決して悪ではなく、そっちのほうが「バリュー」として効果的なことを「体感」し、「やらないこと」の恐怖を克服するのがこのプラクティスの目的だ。是非お試しあれ。
2. 時間を固定して、出来ることを最大化する
「すべき」思考で考えると、どうしても、時間を「延長」してしまいがちだ。彼らを観察していると、「すべき」から時間を計算するのではなく、「時間」は固定して、その中で価値を最大化するという行動をとっているように感じる。
例えばロッシェルさんと打ち合わせをするときも、時間が延びることはほぼなく、「あれも、これもやらないといけない」とお互い思うのだが、この２時間で出来る範囲のなかで、「最大にバリューが出ることにフォーカスをすると、これと、これなので、今日はこの２つだけやろう。」すべきことを全部こなそうというより、時間が最大の制約なので、この時間内に確実にできる数に絞って、最大の成果を出せることに集中する。みなさんも、なんも準備できていなけど、明日プレゼンだとかいう場面はないだろうか？その時のイメージを思い出すといいかもしれない。多分無理なものはあきらめてバッサバッサと作業を切り捨てているはずだ。それを無理ない個数に絞り込んでやるイメージだ。
だから、「きれいなドキュメント」なんかは作っている暇は当然なく、「やる事」の数を減らして時間内にできるようにして、やったらよさげなこともばっさばっさと切り捨てて、その場で出来るだけ早く意思決定するようにせざるを得なくなる。 「まだ完璧じゃない」「抜けてることがあるかもしれない」ことが最初は怖かったが、「抜けている」ようなことは大抵対して重要じゃないのだ。抜けていて困ることもあるかもしれないが、それは、何かを実施したら、フィードバックを得られるので、「心配」せず「実施」してしまえばいい。
例えばこの「８つの習慣」も完璧かは知らないが、世に出して、フィードバックを受けたほうが悩んでるよりよっぽど生産的だろう。
3. 「準備」「持ち帰り」をやめてその場で解決する
ポイントとしては、何かの作業、例えば会議をしているときに、「会議の場」のみで完結するように訓練することだ。彼らを観察していると、ざっくりしたアジェンダはあるが、準備に時間をかけて会議に臨むということはしない。さらに、会議が終わった後に「宿題」とか「もちかえって検討」とかそういうことがない。つまり、会議に出たら「会議の時間内だけで完結」する。これは大変生産的だ。 日本の会議のときは、会議の前の準備があって、会議が終わった後も、検討したり、議事録を書いたりいろいろしないといけない感じだった。
インターナショナルチームを観察していると、彼らは常に「会議の場」だけで完結される。議事録もその場でOneNoteにとって共有される。 例えばロッシェルさんとのプレゼンテーションの会議をしているときも、「ここと、ここを修正して後で直しておきます」ということはせず、その場でプレゼンを修正する。そしたら終わった後に時間を取らなくていい。そして、会議の時間の間にロッシェルさんに共有する。意思決定も、持ち帰って検討しますではなく、間違っててもいいので、その場で意思決定してこうしようと決める。
昔のブログエントリで書いたが、こういうことを元から実践している人がいる。ソニックガーデンの倉貫さんだ。私がコンサルタントの時、彼と仕事をした時の一言は忘れられない。
牛尾さん。会議の準備をしないでくださいね。無駄だから。そうではなくて、会議の時間を価値の高いものにしましょう。
彼との会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。もし、どれぐらい「準備」をしなくてもいいのか？がわかりづらいなら、いっそ準備「なし」でどの程度できるか体験してみるといいだろう。そして、出来るだけ「会議の時間内」のみで完結できるように頑張ってみる。そうすれば、思ったより「できる」ことに気づくのではないだろうか？ できない場合は、きっと、「余計なこと」を頑張っている可能性が高いので、会議のゴールに不必要なものを減らしていく練習をするとよいだろう。
おわりに
これらの３つのプラクティスは、もちろん簡単ではないとは思うし、実際の例を見ないとなかなか理解できないかもしれない。「どれぐらい」ができている状態かわかりずらいかもしれない。
だけど、これらを「意識」してみて、「実践」していると、だんだん上達してくるし、こういったことが「出来ている」人を目にするとアンテナが立っているので「あーこれぐらいできればいいんだ！」という気付きを得やすくなる。少なくとも意識して「実践」してみるだけで、かなり変わってくるはずだ。
次回は「リスクや間違いを快く受け入れる」習慣について書いてみたいと思う。
