読者です 読者をやめる 読者になる 読者になる

メソッド屋のブログ

米マイクロソフト DevOps エバンジェリスト 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~

 今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。

f:id:simplearchitect:20160809120031j:plain

 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。

 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。

気になっていたSamの一言

 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行ったときに、彼がある先進的な会社を訪問した時に私にぽろっと言っていた事を思い出した。

f:id:simplearchitect:20160618214227j:plain

先進的な企業と言っているけど、レイアウトが全然アジャイルじゃない。オールドファッションな日本企業だ。

 その当時自分はその言葉の意味が分からなかった。オープンなスペースで、プログラマに対してもディスプレィもしっかり複数支給されていて、見晴らしも良い。だからスルーしたのだが、心には引っかかっていた。Matthewのチームを見にきて「ああ、そういうことか!」ということが相当腹落ちした。

伝説のルームレイアウトが眼前に広がった

 開発チームがいる部屋に入ってみると、みんながとても歓迎してくれた。私はみんなは、日本では有名でヒーローなんだよ という話をしてあげたらとても喜んでいた。

f:id:simplearchitect:20160809120355j:plain

ルームを見ると、小さな島で構成されている。部屋はオープンスペースで、とてもペアプログラミングがしやすい構成になって いる。その中の「マネージャ」という人がポイントを教えてくれた

すべての机に滑車がついているだろう?だから、簡単に場所を移動できるので、ペアプログラミングとかしたくなったら移動 できてすごく楽なんだよ。

 そして、彼は続けて説明してくれた。

もし、集中したくなったら、フォーカスルームを用意しているから、そこにこもって集中することもできるようになっているんだ。みんなが作業に集中できるようにね。

f:id:simplearchitect:20160809120449j:plain

 オープンスペースでの開発は、大きなディスプレイが与えられて、頻繁に声を掛け合いながら開発をしている。横の人が ペアプログラミングを始めた。

f:id:simplearchitect:20160809120505j:plain

 この感覚はなんだろう。Extreme Programmingの白本で見た、当時衝撃を受けたあのレイアウトだ。フォーカスルームの アイデアも何かで読んだことがある。しかし、日本ではここまでしっかりやってるところはどれぐらいあるだろうか?なんで私は今まで「知っている」はずのものをたいして効果がないだろうと決めつけてやらなかったのだろうか?そんなことを考えるとさらにドキドキしてきた。

強烈なフォーカスを生み出す力は、フォーカスできる環境から

 各プログラマがそれぞれフォーカスできるようにとても工夫しているようにも感じた。ペアプログラミングをしている人以外は 集中したい人は大きなヘッドフォンをしているし、スタンディングディスクになっているので、スタンディングスタイルにチェンジして開発を始めた人もいる。

f:id:simplearchitect:20160809120756j:plain

 マイクロソフト最高のチームは、特に日本にないような特別の部屋で開発をしているわけではないし、我々もやろうと思えば 全然できてしまうはずなのだが、彼らは私が本を読んで知っているはずの事を忠実に実行していた。

日本よりアクティブなスタンドアップ

 次にスタンドアップが始まった。時間は 13:30 。もちろん、VSTSのソフトウェア看板がどっかーんと表示されたバカでかい スクリーンの前にみんなが集合してきた。意味不明だが、なぜかMacだった。  みんな今日やる作業に関しての共有が始まったが、日本で行われている朝会よりもずっと「アクティブ」に感じた。日本のは もっと淡々と「きのうやったこと、きょうやること、課題」を共有していく感じだが、そこに、時間は短いけど「ディスカッション」が入る感じ。教科書通りだと、「ソリューション」は終わった後で個別に解決が定石だが、ディスカッションの時間と問題解決が速いので、特に問題に感じなかった。むしろ相当効率的に感じた。

f:id:simplearchitect:20160809120849j:plain

 このチームには、休暇含む9名のメンバーと2名のリモート(中国、インド)のメンバーがいるチームだった。リモートのメンバーの一人が、横にあるディスプレィで、常時顔が見えるようになっていた。

f:id:simplearchitect:20160809120839j:plain

カンバンの工夫

 ただ、ソフトウェアKanbanに、レーンが設定されていたので、それは何かを聞いてみた。実は一瞬「ま、まさかバッドプラクティスのミニウォーターフォール?」と思ったがそうではなかった。レーンは

Backlog -> Up coming -> Investigate / Design -> Implementation -> Pull Request -> Evaluate -> nag -> Done

f:id:simplearchitect:20160809122118j:plain

となっていた。各レーンは、ワークアイテムの最大数が決まっている。Backlogの優先順位が高いものから、Up comingに取り込んで 、Designに移る。Designは、企保的にストーリが「理解できたら」次のimplementationに移るらしい。その後、Pull request を実施したら、Evaluateだ。例えばあるペアが開発を行ったワークアイテムだと、それ以外の人がをのプルリクエストを見るようにしているらしい。駄目じゃない?というときはnagに移すとのこと。

テレメトリの徹底活用

さて、ここまでは特に特別なことはないのだが、次の2つはアジャイルチームではなく、DevOps チームである特徴にあふれていた。 まず、一点目は、徹底的にテレメトリをとって、それをいつでも見えるように共有していることだ。PowerBIをつかって、大きなスクリーンに画面いっぱいのさまざまなテレメトリをリアルでチェックできるようになっている。朝会でも見ていたが、常にこれを見ることができる。

f:id:simplearchitect:20160809122202j:plain

Fチーム / Lチーム

次のプラクティスが結構すごいと思ったのだが、Fチーム、Lチームという考え方だ。このチームは内部で2つのチームに分かれている。だから今どちらのチームにだれがいるか?というダッシュボードも存在している。

f:id:simplearchitect:20160809123933j:plain

Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。

Fチームは、プログラマがフォーカスできることと、品質を高めることを重視している。だから、開発中に実施できるワークアイテムの数を例えば5に制限している。お偉いさんがやってきて、今すぐ機能を対応してほしいときは、その枠を超えないように入れ替えをする。

 Fチームの開発に関しては、基本的にペアプログラミングのペアで作業している。これは、すべての機能を誰か一人しか知らない状況を防ぐためとのことだ。さらにペアは組み替えられる。  ここで、私はFチームは楽しそうだと感じた。メールもほぼほぼ見る必要もないし、割り込みも入らない。これは相当集中できるだろう。

しかし、Lチームはおもろないやろなー。と。しかし、Matthewは続けた

 Fチームと、Lチームは、定期的に入れ替える。単純にそれぞれのチームに最も長く滞在しているメンバをスワップするんだ。 そうしたら、ペアのうちの一人が入れ替わるから、知識共有の面でもいいだろう?

自己組織チームはこういう姿

なるほどー。と思った。これは素晴らしいアイデアだ。フォーカスルームやレイアウトもそうだが、このチームは徹底的にプログラマが集中できるような環境を工夫して改善していると感じた。Fチームは、Lチームのおかげで相当集中して、安定した機能をデリバリできるだろう。Matthewによると、この方法でもう1年ぐらい運用しているが、すごく生産性と品質が向上しているらしい。近々Mathew本人が記事を書いてくれるらしいので楽しみにしていよう。

 そして、チームメンバが同じゴールに向かって、相当いい感じで、楽しく仕事ができているようだった。完全に自律的なチームで、まさに自己組織化チームだ。マネージャと呼ばれる人はいるけど、チームを助けてすごくサポーティブだ。

9割は既に知っていたはずの事だった

 このチームを観察して感じたことは、「新しいことを知った」とか、「見たこともない最新技術を見た」とかいうことでは決してなく、最先端の DevOps チームというものは自分たちが「知っていたはず」のことを着実に忠実に実行して、そのうえでしっかり改善を続けているチームだったということだ。何のマジックもそこにはない。

f:id:simplearchitect:20160809122837j:plain

 ただ、私は今まで出会った中で最高のプロフェッショナルなチームだと感じた。観察していると全く無駄がないし、各メンバーはリラックスしながらも誰に言われるわけでもなく、すごく集中して作業を実施している。自分が勝手に「あまり効果がない」と思ってやらなかったことの積み重ねが本当は重要なんだということを思い知らされた。  彼らに限らないことなのだが、こっちにいると、本当にみんなプロフェッショナルなのだ。誰もダラダラしている人がいないし、無駄話もだれもしていない。このオフィスも遊びの要素はほとんどなくて、集中しているが、定時になったらみんなバリューを出してさっと帰っていく。  そこからいろいろ楽しむのだろう。

フォーカスへの投資が効率を生む

 スタンディングディスク、複数台の大きなディスプレィ、可動式のディスク、フォーカスルーム、大きな看板用のディスプレイなども、日本の会社だと認められないかもしれないが、そういうものが本当に生産性を生むということを本当に認識した。生産性をあげるためには、チームをルールで縛るのではなく、チームの自律的な「フォーカス」を生み出すことに集中するべきなのだろう。しかし、我々は本当に、エンジニアが、「フォーカス」できることに徹底的に投資してきたのだろうか? 彼らはフォーカスのためにあらゆることを実施していた。

 正直なところ、私がかつてこの目で見たチームの中で、圧倒的に効率がいいと感じた。しかも、それは、ほとんど自分が知っているプラクティスによって生み出されていた。我々はどこまでプラクティスを本当の意味や、価値、そしてそのバリューを理解してきたのだろうか?簡単に日本では通用しないと魔改造してきたのではないだろうか?でも、私が見た彼らは圧倒的に洗練されていた。言語とかツールじゃないのだ。

我々がすべきことは、「当たり前の事」をできること

 我々が彼らのスピードに追い付くためにやるとよさそうな事は、「まず教科書通りにやってみる」ことじゃないだろうか?と思った。彼らを観察すると、バカにされるかもしれないが本当に「教科書」的に、愚直に実施している。ソフトウェアエンジニアリングの基礎、ペアプログラミングスタンドアップ、Kanbanの運用、スプリント、継続的インテグレーション / デリバリ 我々が見たExtreme Programmingの本や、Scrum、DevOpsの本や講演で見聞きしたプラクティスが、そのまま行われている。それをきっちりやったうえで新しいプラクティスを積み重ねて、さらなる工夫をしている感じだ。

f:id:simplearchitect:20160809123229j:plain

 我々は現場に合わないと、すぐに駄目だということにして、違う方向に改造してしまう。しかし、本当に重要なことは、何千人もの人が実施して認めたベストプラクティスをまずは正しく理解して、愚直にやってみることかもしれない。我々はそこにも到達していないのでないだろうか?という思いを新たにした。

まとめ

今後、PaaS, SaaSの力が増大し、マイクロサービスの時代、そして、現在はServerlessに注目が集まっている。今後は 人手が多くいることはどんどん自動化してくるだろう。そして、人でしかやれない部分が残る。そういう時代に必要なのは、本当にプロフェッショナルでスキルの高く、自分で考えることのできるエンジニアになってくるのではないだろうか?誰かが考えたことの作業をするだけの人は、要らなくなる。  そうなってくると、本当に生産性を上げるのに重要なのは、実際に開発や運用をする人が如何に効率よく作業を実施できるかにかかってくる。

f:id:simplearchitect:20160809123212j:plain

プログラミングは高度な頭脳労働が残る。そして、プログラマの生産性の差は10 - 25倍と言われるのだから、これからは、「チーム」や「人」を重視して、彼らが「フォーカス」を獲得するために何をするかが、地道だが差別化のポイントじゃないだろうか?

新技術導入の遅さの一端はラーニングモデルの違いかもしれない

f:id:simplearchitect:20160804204258j:plain

以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。

 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。

バリューストリームマッピングで困っている人の話

 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。

 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。

f:id:simplearchitect:20160804204907j:plain

なぜか米英では、ソフトウェアのコンセプトの誤解が圧倒的に少ない

 幸いなことに彼は相当喜んで帰ってくれたが、ふとホテルに帰って振り返るとこっちの人は、アジャイルやDevOpsといったものに対する誤解が圧倒的に少ないことを思い出した。  そういえば、自分の上司も両方とも元Opsなのに、同僚も、上司も「あー誤解しているなぁー」みたいな場面に遭遇したことがない。

 アジャイルそして、DevOps を実践して、15年以上になるのだが、経験上日本では、それを相当専門にしていない限り「アジャイル」「DevOps」に対する理解はずれている、もしくはむっちゃくちゃずれている場合が圧倒的に多い。それどころか、専門の人でも、かなりのコンセプトを誤解しているケースもある。もちろん私もそうで、少しづつ修正して今に至っているので、今でもなんか勘違いしているかもしれない。これは一体何なのだろうか?

最高の DevOps チームの観察で得たこと

 同じ日に、マイクロソフトの最高の DevOps チームを生で観察してきた。その詳細なレポートは別の回に譲りたいのだが、私が彼らに感じたことは、見たこともないようなすごいテクニックが使われていたわけでもなく、すごい新技術を導入しているわけでもないが、むっちゃくちゃ無駄がないということだ。  しかし、そこで、使われているTipsは一つを除いて今まで見たことがないものなどなかった。私は逆にそこでびっくりした。「今まで自分が知っているはずのプラクティス」をちゃんと使ったらここまでできるのか?と。彼らは、本当にそれらのプラクティスを正確に理解して導入していると感じた。

 私がExtreme Programming の本の写真で見たような光景が目の前で本当に行われている。それはちょうど、むっちゃ歌うまい人 が基本が超絶に凄いのに似ている。

http://ronjeffries.com/xprog/images/C3Room003.jpg

ronjeffries.com

歌のうまい人の基礎力

 歌とか演奏とかが本当にうまい人は、高い声が出るとか、複雑なリズムを乗りこなせるとかそういう話ではない。そもそも、何の変哲もない、だれでも歌える音域の声を「あー」ってだすだけでも、全然違うのだ。ドラマーなら、ドラムをたたかずともスネアを一発「パン」ってたたくだけでそこから全然違う。つまり、達人というものは、ものすごく「基礎」ができている人なのだと思う。

Rochelleさんの生け花の体験

ホテルの中で、考えていると、この前一日ミーティングをした、Rochelle Koppさんの言葉を思い出した。彼女は、日本と西洋のラーニングモデルの違いを説明してくれた。

f:id:simplearchitect:20160804205115j:plain

 彼女がアメリカで生け花を習ったときは、先生は日本人だけど、アメリカに長く住んでいた。彼女は、この花をどうさすと、こういう効果があるからと、説明して実際にやってみてくれた。ところが、Rochelleさんが、日本に来て生け花を学んだら全然違ったらしい。

師匠は、「今回はななめざし」といったっきり、しゃしゃしゃしゃー。と目の前で実演してくれたけどのそのあといきなり「じゃあやってみてください」とのこと。

Rochelleさんは何とかまねてやってみたけど、師匠がやってきて、全部さしなおして修正してくれた。確かに師匠が修正した後のほうが全然いいのだけど、理由は全く分からなかった。翌週も、その翌週も同じ感じだったそうだ。  そして、しばらく通っていると、何となく自分はできるようになっていたが、なぜできるのかは他人には一切説明はできなかったという話だった。

日米のラーニングモデルの違い

 インターナショナルという意味ではまだ分からないが、Rochelleさんによると少なくともアメリカの人は「すべてを理解する」ことに重きを置く。 ところが、日本の人は「具体的なやり方」を知って真似することを好む傾向にある。それはどういうことになるかというと彼女曰く

学ぶのに時間がかかるし、スケールしないのよ。柔道や、生け花みたいな変わらないものだとそれでいいのかもしれないけど、 ビジネスみたいに変わるものには絶対向いてないわね。

 あああ、、、これだ、、、自分の中で彼女のこの言葉を思い出して自分の中で何かがつながった。アメリカ人と、日本人の多くの人はラーニングモデルが決定的に違うんだ。だから、アメリカの人は概念の説明の段階でも質問しまくるし、日本人の人は、概念ではなく具体的なものや事例を求めようとするのだ。

完全理解タイプがスピードを生む

 アメリカの人は、たとえ経験をしていなくても、本を読んだり、講演を聞いたりして、「徹底的に理解する」ことに慣れているから、未知の新しいコンセプトでも導入が進みやすい。  一方日本人は、新しいコンセプトを取り入れるときは「具体的なもの」を見て真似するのが得意だ。ところが、新しいコンセプトであり、それが、自分の置かれている現状と違えば違うほど、具体的に想像できないので、ものすごく勘違いしてしまったり、魔改造してしまったりするのではないだろうか?しかも、学びが実物からなのだから、実物から、学んでいくので、少しづつしか広まらない。だからいろんな導入が遅くなってしまうのかもしれない。 f:id:simplearchitect:20160804210719j:plain

 また、もちろんこれも仮説なのだが、ソフトウェアの場合は、問題をややこしくしているのは、日本でもトップエンジニアは、「理解を重視」している思考をしているのではないか?という部分だ。

 私は昔「オブジェクト脳のつくり方」という書籍を書いてありがたいことにたくさん読んでいただけた。その当時のモチベーションは、既存のオブジェクト指向の書籍が大変分かりにくく感じたからだ。

books.rakuten.co.jp

ラーニングモデルとわかりやすさの違い

 書籍は当然その分野が分かっている人が書くことが多い。そういう人はソフトウェアができる人なので「理解を重視」しているスタイルで学ぶ。 一方、私は、こてこての日本人なので、「やってみなければ理解できない」タイプだった。だから、そういう人が「わかりやすい」書籍を書いた。  理解重視の人にとって「わかりやすい書籍」と体験重視の人にとって「わかりやすい」は全く異なる。そして、きっと日本は「体験重視」の人のほうが多いのだろう。

 昔衝撃を受けたことがあるのだが、日本の「算数」の教科書と、米国の「Math」は相当に違っていてびっくりしたことがある。日本の教科書は定義も一応ちょろっと書いてあるが、「さあ、解いてみよう」ということが中心になっている。「Math」の場合は、徹底的に各用語の意味を定義してあり、そのあとにサンプルが乗っている。私は数学は暗記でカバーしたタイプで苦手だったが、この構成だったら、わかったかも、とびっくりした思い出がある。

日本の算数

http://www.gakujutsu.net/image555.jpg

英語の算数のページ

What is Data?

日本を米国と同じスピードにするために

 つまり、この仮説の部分においては、日本で技術導入がスローである原因の克服には2つの方法がある。1つは、日本人の気質に合わせて、説明の仕方を変えるか、「理解を重視する」考え方を広めていくかだ。  自分的には、短期的には、最初の方法を採用し、同時に、「理解を重視する」考えを広めていくのがいいかなと思っている。おそらく、ソフトウェア産業のプロフェッショナルの場合、「理解を重視する」やり方のほうが圧倒的にあっていると思う。

 しかし、そんなにすぐにモデルチェンジできるわけでもないので、多くの人のラーニングスタイルを考慮して新しいコンセプトを広めていきたいと思う。実際、オブジェクト脳の後に開発した、「オブジェクトゲーム」という手法を使えば、当時理解が難しいといわれたオブジェクト指向を、数時間で、みんなに納得してもらえるようになった。日本人でも工夫したらいけるのだ。

docs.com

日本人でも、「米国以上」のスピードになるチャンスはある

 一点だけ日本人に有利なお話しもしておきたい。日本人の多くは、「体験型」で「見て真似して学ぶ」のが得意だ。実際私も、同僚の誰よりも一度見たものを正確に真似することに関しては抜きんでていると思う。アメリカの人が完全に理解するのが得意なのと同じように、われわれも、見てまねる方法ばっかりやっているので、それは一日の長がある。つまり「本物」を観察したのならば、それを吸収するのは彼らより速いのだ。  だから、冒頭のバリューストリームマッピングの彼にも適切なアドバイスを多く送ることができたのだ。理解だけでカバーできる範囲も限界があるので、「やってみる」領域に関してはかなりの一日の長があるのだ。

f:id:simplearchitect:20160804205828j:plain

 ただ、それだけをするのは、中長期的に見ていい作戦ではない。しっかりと「理解重視」のやり方を身に着けていく方がおすすめだ。私は以前は、体感型だったが、インターナショナルチームに入って、「完全理解派」にモデルチェンジを試みている。道半ばだが、焦らずやれば、できそうな気がしている。だから、今後は、DevOps の導入も、しっかりとこの2つのラーニングモデルの違いを考慮して日本でも米国並みの実践をできるようにいろいろ準備をしていきたいと思う。

「ウォータフォールは何のメリットも無い」のラジオ番組の公開

f:id:simplearchitect:20160726045407j:plain

おかげさまでたくさん読んでいただいたブログですが、この内容について聞いてみたいということで先日アジャイルラジオという番組の収録を行いました。

simplearchitect.hatenablog.com

前半、後半になっています。私の意図していることなどについて、自分の声でお話しさせていただきました。 よかったらお楽しみください。

agileradio.github.io

agileradio.github.io

ソフトウェアの納期見積もりは、星占いレベルのものであると思う

このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは?という私のアイデアをシェアしたいと思う。

f:id:simplearchitect:20160707002214j:plain

注:このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。

ソフトウェアの見積もりの正確さ

ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。

books.rakuten.co.jp

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。

f:id:simplearchitect:20160707002506j:plain

 請負開発を実施するときに、私がSIerだった頃、画面や帳票の仕様を確定する遥か前に「見積もりが間違っていてもいいので、大体でいいから見積もってくれないか?」という話を受けて見積もりを実施する。その見積を元に「予算」や「納期」が決定されていた。  実際に、見積もりとは大幅にずれるわけだが、実際そうなってみると「間違ってもいいといっても、2倍以上開きがあるのは、ありえないだろう」みたいな話になることも多かった。しかし、この図を見ると、統計上至極当たり前の現象であると言える。

 見積もりに4倍の開きがあるものなど、占いレベルでなくてなんだろうか?1.6倍の開きと言ってもかなりのものだ。しかもこれは「画面・帳票の仕様を完全にFixしたもの」という前提である。

 若干乱暴だが、この著名な書籍の結論をお話ししておくと、スケジュールの見積もりに関しては納期を1点に決めてしまう見積もりは、クレイジーなので、ここから、ここまでの範囲内の見込みといったような「レンジ」を持った見積もりを様々な見積もり手法を用いながら実施するとよいということになっている。

  つまり、現在のソフトウェア開発においては

納期を1点に正確に見積もる方法は、世の中には存在しない

のだ。

納期をある程度正確に見積もれる状態は、何回も同じような状態で繰り返し実施してどの程度の時間がかかるか想定できるものに限定されている。ソフトウェアに関していうと、毎日のように新しいツール、機能がでてきて顧客の要望も、競合の動きに合わせて変わっていく。プロジェクトは2度と同じようなプロジェクトは存在しない「不確実性」にあふれた性質をしており、ソフトウェアにおいて、納期の見積もりは、未来を予見する、博打に等しいものだと思う。

納期厳守のプレッシャー

ところが、日本では一旦決めた「納期」を守るプレッシャーが相当に存在する。それが、どれだけ妥当性に欠けるものであったとしても、それを守るためなら徹夜でもなんでもやって納品するのが「プロ」と言われる。だから、相当無理なスケジュールでも、「やるしかない」という話になり、プロジェクトが炎上して、徹夜三昧になった挙句、プロジェクトは延期されるなんてことはざらにあるだろう。

では、「納期」が絶対なものとすると、「物理的」に考えるとどういう手が打てるだろう?これは、ソフトウェア開発の「納期」「コスト」「品質」「スコープ」に関する物理的な制約を表した図だ。

f:id:simplearchitect:20160707003011j:plain

「スコープ」つまり、実施する範囲を変えないまま、「納期」を守ろうとしたら、「品質」か「コスト」を犠牲にしないといけないというトレードオフの図だ。プロジェクトが遅れている状態で、「納期」を守ろうとしたら、「コスト」「スコープ」「品質」もしくはいくつかの複合要素を妥協する必要がある。  計画通りいかなかったプロジェクトは、優秀な人がいたなら、間に合わなくなりそうな兆候を見た時点で、「作業量」を減らしたり、「テスト」の手を抜いたり、「お金」をかけて高級なツールを買ったり、人を増やしたりということをしているだろう。

物理的にいって、ソフトウェア開発において「納期」「コスト」「品質」「スコープ」を確実に守るプロジェクト遂行ができる可能性は先ほどの見積もりの話と合わせて考えると、少なくとも理論上、統計上は「無理」に等しいのだ。

インターナショナルチームでは、「納期」はほとんどない。

 私も「納期」に関しては疑問を持たず厳守するものという考えがあったが、インターナショナルチームに入ってから大きな疑問に代わっていった。インターナショナルチームに入ると、そもそも「納期」がほとんどないのだ。数が少ないが、あったとしても、例えば自分が4時間程度かけたらできそうなものに対して、2週間ぐらいの「納期」が設定される。つまり、楽勝でできる余裕がある状態でしかそういう納期が設定されない。日本だと、金曜日の夜に、「これ月曜日までに、なるはやで」みたいな仕事の依頼が来ることもしょっちゅうだったが、インターナショナルチームでは、そういう展開はありえない。

f:id:simplearchitect:20160707003258j:plain

 もしそういう話になったら、仕事を依頼したほうのマネジメント能力が疑問視される。尚且つ、やってみたけど、間に合わなかったケースがあったとしても、それを無理に詰めて1日も早く終わらせようとはしない。課題を仲間と共有して、対策をうつなり、継続してやるならさらにそこから余裕を持った目標日が設定される。そして、今回何が課題で、何が学べたか?ということを関係者で共有して、次はどうしようという前向きな話になる。

 よくよく考えると、見積もりは、未来を予見する行為なので、ロジカルに考えると、理論上も、統計上も、100%達成できるはずがないので厳守などできるはずがないのだ。見積もりや計画を立てることはいいことだと思うのだが、少なくとも理論上はそれを「Fix」してしまう行為は自殺行為とも言える。見積もりや、計画は、あくまで「予定」であり、何かが変わったり、想定外のことが発生したら、それに合わせて「変更」 していくものであると思う。

そもそも「納期」はどこまで重要なのだろうか?

 日本では大小にかかわらず、一度設定した「納期」は守ることが大変重要視される。しかし、実際のところ、「納期」はどれぐらい重要な要素なのだろうか?日本にいるときは、大小たくさんの納期が設定される。相手からも「いつまで」というのが緊急なものをたくさん含んで設定されたり、自分で決める必要があったりする。そんなこんなで、日々見積もりが想定外だったら、残業休出でカバーする場面は私もしょっちゅう あった。

 海外に行ったり、インターナショナルチームに加わると「納期」はあまり重要でない気がする。そういえば海外の電車は遅れるのもしょっちゅうだし、電車がプラットフォームに入るまで、どのプラットフォームにつくかもわからない。会議も開始時間に遅れないことは日本はむちゃくちゃ重視される。一方海外だと、開始時間に遅れても、会議自体に出なくても「自分次第」になる。問題視もされない。自分次第だからだ。

 よくよく考えると、海外の巨大なソフトウェア企業がロードマップを発表したり、いつ頃、この機能をリリースするとかアナウンスしても、しょっちゅう、しかも、がっつり遅れたりする。しかし、それでどの程度のビジネス的な損害があるのだろう?  確かに、「納期」をがっつり守ったほうが良い場面というのは存在するが、本当はそんな場面は多くないのに我々は何でも早くしようとして無駄に納期を設定していないだろうか?

f:id:simplearchitect:20160623142229j:plain

 インターナショナルチームである納期といえば、ビジネスレポートや、勤怠の提出、出張申請。ビジネスレポートは、月末だが、毎日やっていれば全然問題ないし、全体的に物量が少ないので簡単だ。勤怠も、忘れていたら相当早くからリマインドが来るし、やるのを忘れ続けてもデフォルトでサブミットされる。出張申請はやらなかったら、自分の財布にお金が入ってこないだけだ。  テクニカルワーキンググループで、自ら立候補した資料をつくるのに、「絶対的な納期」ではなくて、「ここまでにやろう」という日は設定される。でもむっちゃくちゃ余裕はあり、ぎりぎり達成可能な日とは程遠い、絶対にできるだろう日しか設定されない。もし、その日までにできなかったら、きっと自分のパートの部分がカットされてリリースされるだけだろう。なんてことはない。次回のリリースのときに追加すればいいだけだ。

私はこういうことが重要じゃないかと思う。

その「納期」が本当に重要かをもう一度自問自答してみる

 私のポジションの問題もあるかもしれないが、肌感覚で感じるのは同じポジションでも、日本でいるときより圧倒的に納期設定が少なく、あってもむっちゃくちゃ余裕があるということだ。だから、逆にみんな数少ない納期は言わなくても普通に守る感じだ。全く「無理」が無いから。

「無理を承知」をなくせばうまくいく

これらの多くの問題は、「無理」なものを「無理」と本当の意味で認識していないことからくるのではないだろうか?日本にいると「無理を承知 でお願いします」「しばらく死んでくれ」「無理だけどやるしかない」という言葉を聞くこともあるでしょう。  納期の見積もりだけではないが、「無理」なものを「無理」と認めないマインドセットというのは相当いろんな悪影響がある気がする。「無理」と認識したうえで、次どういう「無理のない」手を打つか?は建設的だと思うが、「無理」なままつっこんでも、博打程度の確率でしか成功しないのは自明なことだろう。

でも、我々は、様々なプレッシャーや過去の習慣から、「無理」でも頑張ろうとしてしまう。そもそもその「無理」は本当に価値があるものなのだろうか?納期が1週間、いや1か月、さらに3か月遅れてどれだけのビジネスインパクトがあるのだろうか?「現行のビジネスモデル」で考えると、「少なくとも自社にはインパクトがある」という話になると思うが、みんなが「無理」なものを「無理だよねー」と顧客も、開発者も、運用者も、企画も、認めるような考えを業界に広めていくほうがより重要な気がする。そうでなければ、悲惨なことが続くだけじゃないだろうか?

無理なものは無理なのだから、それを単に認めよう。認めてから対策を考えよう。

「納期厳守」がもたらす圧倒的なデメリット

「納期厳守」で無理を承知で、人をたくさんぶち込んで、徹夜徹夜で何とかソフトウェアを仕上げて納期通り納品した。これは大変な美談になることが多いが、ソフトウェアの専門家からすると、まったくプロフェッショナルさからかけ離れた行為だ。

何故なら、ソフトウェアは、リリースして、使われてからがなんぼだからだ。それは結局のところ先ほどの「納期」「コスト」「品質」「スコープ」のトレードオフに対して一番曖昧な「品質」に対して大幅に妥協した結果に過ぎないからだ。徹夜でふらふらの頭でしっかりした、メンテナンス性が良く、自動テストがついているようなコードが素早く書けるはずがない。これは物理的な制約だから。

 だから、そのあたりが妥協されていることになる。納期通りリースしたところで、そのプログラムはその先何年もメンテナンスされていくのだ。「品質」を妥協した先に待っているのは「バグ」だけではない。「技術的負債」と言われるものはある意味「バグ」より恐ろしいものだ。

f:id:simplearchitect:20160707004137j:plain  

技術的負債の恐ろしさ

「技術的負債」というものは、技術的に良くない何かがソフトウェアに組み込まれている状態だ。例えば汚いコードとか、可読性の悪いコードだ。それは必要悪として一定以上は仕方がないが、借金と同じでそれを定期的に返していけば、特に問題ないのだが、返済せずにためていると、破たんしてしまう。つまり「メンテ不能」状態に陥るのだ。だから、「コードを常にリファクタリングし、重複の無い状態をキープして、1つの変更に対するコストが膨れ上がらない」ように、コードベースを常に変更可能な状態に保つ必要がある。しかし、この「技術的負債」の問題は本当に重要かどうかわからない「納期」の前にスルーされることが多いように思う。そんな欠陥三昧のソフトウェアを本当に重要かわからない納期に合わせてリリースしたところでそれは本当にプロフェッショナルな行為で顧客のためになるのだろうか?

 さらに、「納期厳守」は「占い」レベルの確度なので、「守れない」場合もある。その場合、「技術的負債」をてんこ盛りに抱えたまま、さらに納期遅れで納品される。そういったシステムは、1つの変更に多大な工数がかかる。変更が難しいからだ。だから顧客は将来的に高いお金、そして、長い納期を受け入れないといけなくなる。

 この「技術的負債」は先端の開発手法を用いている米国であってもトップ3の問題に数えられるぐらい難しい問題だ。DevOps Enterpriseというカンファレンスに行くと、よく上がる問題として、「レガシーマイグレーション」「自動単体テストを記述すること」「技術的負債」がいつもテーマにあがる。それぐらい先端の手法を用いている会社でも苦労するポイントだ。なぜなら、「技術的負債」は、ツールを導入したら解決できるものではなく、「クリーンコード」がどういうものかを共有し、チームで、その文化を育てていくような「習慣」だからだ。それぐらいじっくりとりくまないと、「メンテに非常にコストがかかるソフトウェア」が出来てしまうものなのだ。

シンプルな解決策

これらに関するシンプルな解決策は、必達の「納期」というのをあきらめるというのがシンプルだ。だって無理なのだから。実際に、No Estimatesというムーヴメントがある。「無理」なものなのだから、「やる価値もない」。「計画」は見通しをよくするために立てるけど、それを「絶対」のものにするのが、意味のない行為だと思う。単にリスクを増しているだけだ。

ronjeffries.com

完成見込みを知る方法

ソフトウェアの世界で、現在の技術的にも仕様的にも不透明な現在において、妥当性があり、完成見込みがどの程度か?を知るおすすめの方法はないだろうか?先に見積もりの本にもさまざまな手法が紹介されているが、一番シンプルでおすすめで、なおかつたくさんの人が使っている方法は、その開発しているチームの「実績」を測定して、「実績」をもとに予想する方法だ。 実際見積もりを確定させるための「変数」は多すぎる。例えば、人月で考えたところで、プログラマの生産性は、10-25倍の開きがあり、チームの中にそういう人が含まれているか?というのを知るのは難しい。そういう人がいたとしても、誰かが仲たがいしたら生産性が落ちるかもしれない。顧客のチームに問題があれば、沢山の「待ち」が発生するかもしれない。こういうのを見積もりの段階ですべて見切るのは不可能だ。チームごとに生産性は異なるのだ。

だから、そのチームで、一定期間働いて、その間、何らかの指標で生産性を測定する。そして、実際にチームの生産性が安定したところで、残作業をどの程度の割合でこのチームはこなせるか?という割合から、「完了見込み」の日を設定するとよい。ただし、これはあくまで見込みだ。 もし、その日に何らかのリリースをしたいのであれば、機能が無理なく盛り込めればよし、そうでなければ、優先順位をつけて、盛り込めないものをそのリリースから落とせばよい。これは一つの方法だ。

f:id:simplearchitect:20160707004810j:plain

この方法の良いところは、実際にビルドして、「動作するアプリケーション」の進捗実績をもとに計算しているので、確実性が高まることだ。私は、「純粋なウォータフォール」はメリットが無いと思っているが、その理由の一つに、「ソフトウェアは、コードを書かずして設計はできない」ということがあるからだ。少なくとも現在のソフトウェアでは、慣れた言語ですら、バージョンアップがしょっちゅうあり、使い慣れたライブラリをインターネットから落とす際に仕様がかわって動かなくなったり、ドキュメント通り動かないことは普通だ。だから、コードも書かず、紙だけで設計するなんてことは到底できない。

マイクロソフトの伝説的なスーパープログラマの中島さんが最近「なぜ、あなたの仕事は終わらないのか?」という書籍を出している。大変面白い内容なのでよかったら是非読んでいただきたい。  そこで紹介されている、彼が必ず納期を守った作戦というのは、納期をしるために、実際にモノを作る作戦だ。ロケットスタートでモノを作ってみて、最初の2日間で8割程度の完成にもっていけたらその後の納期を受け入れる。だめなら、この仕事は難しいから、スケジュール変更を行うというもんのだ。

books.rakuten.co.jp

 これも、無理がない素晴らしい考えだと思う。  

「納期」が重要なケースにどうしていくか?

「納期」が重要ではないケースが多いのではないだろうか?という話をしたが、一方で数は我々が思ってるより少ないと思うが本当に「納期」が重要なケースは存在する。例えば、オリンピックで使われるアプリケーションをリリースするなどの場合は、納期をオーバーしたら、ほぼ意味がないような状態になってしまう。こういったケースではどうすればいいだろう?

 いくつか方法があるが、先ほどのインターナショナルチームの例や、中島さんの例のように「絶対守れる納期を設定する」方法を実施すればいい。設計書だけあるような状況は、コーディングやテストを始めたら一発で状況が変わるので危ない状況だ。だから、どうしても納期を守らないといけない場合は、楽勝でできるような納期を設定して、早い段階で、実際にアプリケーションが動作するようにしておくのが一番安全だ。  フル機能でなくてももちろんいい。ソフトウェアに実装されている機能で実際につかわれるのは4割程度なのだから。まず機能がすくなくていいのでリリース可能で、単純な動くアプリケーションをプロジェクトの早期に作り、そこに少しづつ優先順位に従って機能を追加していく。納期が来たら、そこまで出来たものをリリースする。そうすれば、多少機能は落ちるかもしれないが、確実に「リリース」は「納期」どおりにできる。

 さらに安全な方法もある。「作って」から、「納期」をアナウンスするのはどうだろうか?例えばWindowsなどのリリースを見ても、実際にそれのリリース日が発表される随分前から、αテストや、βテストが実施されている。つまり裏を返すと、バグは多いかもしれないが、リリース予定の既に動作するアプリケーションが出来ている状態なのだ。そこから、バグを取ったり、機能変更をしたりしてリリースする。つまり、バグの残りの多い少ないはあるにせよほぼ確実に「納期」は守れることになるのだ。

 こういったリリースは、大規模なものというイメージがあるが、現在だと、「フィーチャーフラグ」というプラクティスを使って、簡単に実装できるようになっている。ソフトウェアに新機能を組み込むときに特定の機能を、特定のユーザグループに公開する「スイッチ」を付けておく。そのスイッチを特定のユーザグループにOnにすると、その機能がユーザから見えるようになる。Offにするとその機能はユーザから見えなくなる。

f:id:simplearchitect:20160707005408j:plain

 こういった機能をつかって、αテスト、βテストを実施して絶対にリリース可能な状態にもっていってから、リリース日を告知するのが安全だろう。

 これは、私のアイデアでしかないので、「無理」であることをまず受け入れて思考すると、もっといろんなアイデアがわいてくるかもしれない。

「現状」に流されず「無理」を認めることから始める

私は次のようなアイデアをシェアしてきた。しかし、これらの考えは実のところ結構昔から判明していることなのだ。

  • 納期の見積もりは星占いレベルの確度
  • 納期・コスト・品質・スコープのトレードオフは物理的な制約
  • その納期は本当に重要かを考える
  • 無理なものは無理として扱う
  • 納期を設定したい場合は絶対に守れる状態にしておこう

 これらの考えも、現在の日本の商習慣や、慣習から考えて「無理」と考えるのは簡単だろう。しかし、皆さんは、その「無理」を永遠に受け入れたいだろうか?私は少なくともまっぴらごめんだ。無理なものは無理だから。しかし、無理を受け入れてから工夫をすれば、もっと我々がもっとビジネスバリューを高めながら楽しくソフトウェア開発することが可能になると思う。少なくともあなたのチーム内だけでもこのような思考で動いたり、上の人にアピールしていくことができると思う。これを組織で取り組むともっとバリューが高いだろう。実際にユーザ企業自ら「請負」ではなく「準委任」に契約を変更して、「無理」から脱出した超大手企業も存在する。ソニックガーデンさんのように、「納期」自体を削除したケースもある。

itpro.nikkeibp.co.jp

books.rakuten.co.jp

 だから、自分ができることからまず一歩、一歩、私はアイデアをシェアするところから始めてみました。日本のソフトウェア開発が、US並みのスピードで進捗しますように。

追記 (7/7)

このブログをポストしたら私の友人の、Kiro Harada さんとRyuzee さんが、タイムリーにこのトピックに関する記事を書いたというお話を知りました。私の尊敬する両名が書いた記事なので私も読んでみようと思います。是非皆様もどうぞ!より詳しい話が読めると思います。

www.ryuzee.com

そして、Kiro Haradaさんからこの写真を貼りたい、貼りたい、、、とおっしゃっていたので、ご希望通りにしておきましたw

http://s2.quickmeme.com/img/7a/7ac6c18b1bca53b88bbd8cd25a68a327396adce14cb999a7d7130cf76b07a4c6.jpg

ちなみに日本語訳は「彼らに見積もりを頼んだら、それを納期にしてしまえ!」ですw

 

マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」

最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか?ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。

f:id:simplearchitect:20160704001910j:plain

海外企業のリーダーシップスタイルの変化

ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。  従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。

 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。

books.rakuten.co.jp

マイクロソフトに入社して感じた事

私はアジャイル/DevOpsのコーチをしていたので、サーバントリーダーシップに関してはおなじみの概念だったのだが、マイクロソフトに入って気づいたことがある。マイクロソフトはソフトウェアのチームだけではなく、会社全体が「サーバントリーダーシップ」スタイルだ。ビジョンや、戦略、KPIは明確だが、誰も指示をすることは無い。現場のメンバーが日本企業とくらべると、かなりの権限を与えられて、どう実行するかを考えている。これはインターナショナルチーム、日本チームどちらもそうだ。

日本はマネジメントの世界でも遅れている

 私もマイクロソフトのことしか知らないので、詳細は分からないが、他の外資系に努めている友人に聞いても、こういうスタイルという事らしい。「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているようだ。個人的意見だが、日本もそろそろサーバントリーダーシップ型に移行してもよい気がしている。ロッシェル・カップさんの下記の本は非常に興味深いのだが、そこでも、日本のマネジメント技術が低いこと、マイクロマネジメントが横行していること、権限付与のレベルが低いことが指摘されている。

books.rakuten.co.jp

また、書籍で、「社員」と「ステークホルダ」という表が乗っていて、とても興味深い。コマンドアンドコントロールは、メンバを「社員」として扱い、サーバントリーダーシップのチームメンバは、「ステークホルダ」として扱われる。

f:id:simplearchitect:20160704002642j:plain f:id:simplearchitect:20160704002649j:plain

自己組織チーム / フィーチャーチーム

スクラムやDevOps の世界では、チームに強い権限を与えて、ソフトウェアに関する決定は、そのチームが行う。「コマンドアンドコントロール」スタイルだと、上司の承認とか説得とかあったかもしれないが、チームを「信頼」して「任せる」スタイルになっている。このようなスタイルのメリットとしては次のような要素がある

  • 生産性が高い
  • チームのエンゲージメントが高い
  • よりよいソリューションが選択されやすい

生産性の高さ

最初の生産性が高いということは、「コマンドアンドコントロール」時代だと、リーダーの承認や、説得、日本だと合議・根回しもあるかもしれないが、とかく何かを決定するのに時間がかかる。これは、現在のソフトウェアのデリバリのスピードを考えると致命的だ。 だから、チームを信頼して、チームでビジネスの仮説や、仕様、そして、そのアーキテクチャ、使用する技術を決定していく。タスクの割り振りもチームが自らやっていく。基本的にチームメンバーがやりたい仕事を「自分がやるよ」と選択していく。

エンゲージメントの高さ

 インターナショナルチームの基本は、メンバーが「楽しんでいる」か?はすごく重要視されているので、メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。だから「やらされる」仕事より圧倒的に「楽しい」し、「自分がやっている感」がある。正直な話やらされている仕事なんて何にも面白くない。

だから、こういった「自己組織チーム」は、エンゲージメントが高い傾向にある。ロッシェルカップさんの先の書籍を読んでもやはり、日本のマネジメントはまだコマンドコントロールが主体だが、海外だと、サーバントリーダーシップ型になっていて、そういう点もチームメンバのエンゲージメント(満足度)に大きく影響していると思われる。単純な話、自分が面白いと思うことのほうが生産性は何倍も高くなるだろう。

良質なソリューション

最後に、よりよいソリューションが選択されやすい点だが、これは単純で、現在の技術は日進月歩で、それを一番把握しているのは、そのツールや言語で毎日コーディングをしたり運用しているメンバである。つまりチームメンバが一番知っている。何年も前にプログラマを引退した人では鼻が利かない。だから、現場で様々の選択をしてもらうのが一番質がいいことになる。稀にリーダーが一人で判断したほうがいいと感じることもあるかもしれないが、それだと、チームが指示待ちになって、何も考えなくなってしまう。いつまでたってもリーダーの指示が必要だ。

ただし、リーダーでも、例外的に技術に対して超人的に鼻が利く人もいる。グルーブノーツの最首さんはその例だ。しかし、彼も社長をやっているが、自分で様々な技術をハックしたうえで、チームに技術を推薦している。それも特に押し付けではない。

エンゲージメントの重要性

日本では、我慢が大人、西洋では、自分で自分の考えで人生に責任を持つのが大人であり、雇用制度も異なっている。日本に閉じている場合は、ロッシェルさんの本でも示されているが、日本のエンゲージメントの低さはそんなにダメージがないと考えるかもしれない。

f:id:simplearchitect:20160626063947j:plain    しかし、海外に進出したときはどうだろう?近年海外にオフショアしている企業も多いが、現地のエンジニアは、日本ほどエンゲージメントが低くない環境にいるので、自分が面白くないと、当然他のもっと楽しい企業に流れてしまうだろう。プログラマの生産性は10 - 25倍の差があるといわれている。「低いスキルの人」に全体を合わせる時代は終わって、より全体の生産性を高めていく、そのためにも、メンバーがエンジョイできる環境を作り出すということが重要になってくる。実際私も上司からは指示は一切なく「エンジョイしてるか?」ということは頻繁にきかれる。人をコントロールしようとする時代は終わったのだと思う。

simplearchitect.hatenablog.com

おかげで私は自分の考えで、自分で判断して仕事ができている。とても楽しい。はっきり言ってDream Jobだ。

Damienとのレビューでの出来事

先日年次レビューがあって、小さなことかもしれないけど、自分的には感動的な体験をした。Damienは、日本での私の成果をとても喜んでくれいる様だった。彼がとてもほめてくれるので、私は彼に「私の力じゃないよ。Damienが凄く助けてくれたからだよ。」という話をしたらDamienはこう言った

誰が、Hackathonをやったんだ?de:codeで他のイベントで凄いインパクトを出したのは?みんな君がやったことじゃないか。僕じゃない

私はADHDで普通の人が出来ることができない。だから、Damienは凄く私のカバーをしてくれているのを知っている。そんなことを一言も言わす、「みんな君がやったことだ」と彼は言い切った。当時Skypeミーティングだったが、不覚にもいろんなことを思い出して泣いてしまった。彼は初対面の私を信じて一切を任せてくれた。過去も素晴らしい人に囲まれていたがこれほどのことは初めてだ。あれはダメ、これはダメと子ども扱いされる職場と比べると凄い差じゃないだろうか。

こんな気持ちになれる会社と「言われたことをただ単にやればいい」という会社では、採用できるメンバーに大きく差が出てくるのは当然ではないだろうか?今は国内だけだから、成り立つかもしれないが、こういった事情に気づいた人が、どんどん海外の「楽しい」職場環境を求めて日本を去る人が増えてくるのではないだろうか?

ソフトウェアチームレベルに留まるスクラム

t.co

 先日英語の記事だが、「スクラムがアジアでは機能しない」というポストを見かけて大変興味深く読んだ。私が特に印象に残ったパートは、「欧米では、組織にスクラムを導入しているが、アジアでは、ソフトウェアチームでの導入に留まっている」という箇所だ。  これは、一見「スクラム原理主義」みたいに聞こえるが、そうではない気がしてきた。私も昔は、スクラムを会社全体に入れるという話を聞いたときは、「スクラムは、ソフトウェアの方法なのだから、何にでも適用するのは違う」と思っていた。今はもしかすると、そういうニュアンスではないのではないかと思い始めた。

組織でスクラムをしていない意味

「自己組織チーム」を作るためには、ソフトウェアチームだけを変えても機能しないことに気づく。例えば、折角チームが自己組織チームであっても、その上のマネジメントが「コマンドアンドコントロール型」の管理を続けていれば、そのチームを「コマンドアンドコントロール」しようとしてしまうだろう。上位マネジメントはそうでもなくても、中間のマネジメントの方が、コマンドアンドコントロールしてしまうかもしれない。人事制度も、「自己組織チーム」で仕事をすること前提のものに変えていかないと、不公平感が出てしまうかもしれない。

 また、アジャイル以降のパラダイムでは、「計画」や「納期」に関する考え方も大きく異なる。この辺りは次回のポストで解説したい。

 つまり、「自己組織チーム」は単にソフトウェアチームをそのような形態にしたらいいだけではなくて、効果を出すためには、その周囲も変えていかないといけない。これが、「ソフトウェアだけにスクラムの導入がとどまっている」ということの意味だろう。

日本で自己組織チームを実践する方法

 では、日本で自己組織チームを導入し、実践していくにはどういうTipsがあるだろうか?私の個人的な経験に基づく意見だが、記述しておきたい。

トップ層

まず、日本の場合は、上下関係があるので、出来るだけ上の方のOKを取り付けるのが良い。そして、アジャイル / DevOps などを推進するコミットを得て、それをしっかり資料化するのをお勧めする。どういった理由で、それを導入するのか、何を目指しているのか?また、定期的にステータスを報告することを約束しておくとより安心していただけるだろう。他には、可能であれば、バリューストリームマッピングなどの手法を使うと、例えばリードタイムの短縮など目に見える効果を提示することも可能だ。

docs.com

ミドル層

サーバントリーダーシップ型への転換で一番抵抗が激しいのがこの層だ。しかし、それにはれっきとした理由がある。トップ層は、自分のKPI的には新技術を導入するとか、様々な変革をするミッションがあるのでサポーティブになりやすい。しかし現場のマネジメントからすると、プロジェクトやサービスごとに数字を持っているので、当然自分の慣れていない方法で新しいことを始めるのは相当勇気がいるはずだ。だから、トップ層でも書いたが「トップ層」が明確に「自己組織チーム」で「サーバントリーダーシップ型を推進する」とコミットしていたら、ミドル層も、そちらに進みやすい。

また、ミドル層の方が反対する理由は、大抵は「石頭」とかではなく「不安」があるからだ。そらそうだろう。今まで慣れ親しんだ方法じゃない方法で、リーダーシップを発揮しなければならない。だから、「それはアジャイルだから」とか「それはスクラムで決まっているから」とかではなく、彼らの不安に耳を傾けて、それに答えていく必要がある。そして、しっかりとトレーニングをすると、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。そうやって、いったんサーバントリーダー型になると、細かいことを計画・管理しなくてよくなるので、ビジョンや戦略や改善などより本質的な部分に注力することができるようになる。  

できれば、KPIもサーバントリーダーや、自己組織チーム前提にするのが望ましい。

また、進捗報告など、アジャイルやDevOpsサービスではどうすればいいかを具体的にお話ししておくと、安心してもらえやすい。大体私がやりがちなパターンは、「スピードチャート、開発進捗サマリ、課題」程度の報告にとどめている。しかし、それらがあれば、終了の見込み、全体像、課題がわかるので、シンプルながら十分だ。下記の資料のP42, P43あたりのイメージだ。

docs.com

チーム

最後にチームだが、「自己組織チーム」になっても、大抵の場合は、今まで「指示」を受けて動いていた人が多いので、自ら考えて、行動する習慣を持った人が少ないことが多い。だから、最初は自己組織チームになっても、みんな「どうしたらいいんだろう」という雰囲気になることが多い。そういう場合は、誰かが「ファシリテーター」役になって、行動を促進する質問をするといい。最初は「どう考えたらいいかわからない」と言わることもある。彼らに「アドバイス」をするのはよいがそれはあくまで「彼らが求めたとき」にする。 その前に「質問しやすくする空気」を作っておくのは効果的だ。私はよく「Ask For Help」の話をする。次のブログ参照してほしい。すると、メンバーが「あ!気軽に質問していいんだ!」と思えるようになってくるので、どんどん質問がやってくるようになる。

simplearchitect.hatenablog.com

指示待ち系の人も多いが、そのような場合も「じゃあ、○○さん、どのタスクやっときます?」とか、こちらが指示するのではなく、あくまで彼らを「促進」するようにだけする。決定はあくまで本人だ。アーキテクチャの議論をしていても、年上の人に遠慮して、本当に思っていることを言えなさそうにしている人がいることを発見するかもしれない。そしたら例えば「○○さん、このアーキテクチャの議論で、気になっていることはありますか?もし、ほんの小さなことでも結構なのですが、ちょっとでも気になっていることがあったら共有してくれませんか?」ぐらいのニュアンスで「促進」すると、少しづつ話をしてくれるようになったりする。

また、本当は「自己組織チーム」で自分たちに決定権限があるのに、「会社のルールで決まっているから無理」と自主規制してしまうケースもある。その場合は、上の人を連れてきて、その人から、「変えちゃっていいよ!」ということを言ってもらうようにする。そうすれば、徐々に「あ、会社のルールも変えようと思ったら変えられるんだ、自分で考えて自分で仕事をやったらいいんだ」ということに全員が徐々に気づいてくる。これにはプロセスは変えていいんだと気づくことができる副作用のあるバリューストリームマッピングのセッションも有効だ。

  こんなことをしていくと、明日からスグという感じではないが、1週間もたつと「自己組織チーム」にチーム自体が慣れてくる。

他にも、自己組織チームのはずなのに、何となく上下関係を感じる場合がある。そうすると、チーム内部で指示待ちが発生してしまうことがある。ポイントは、チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」としてふるまうことだ。最初の「社員 vs ステークホルダ」を思い出そう。 もちろんスキル差があるのは事実だが、聞いてはいけないということではない。「指示」をうけるのではなく「主体的に聞く」ことが必要なのだ。そして、目上の人も「教えたくなるのを我慢」することだ。「考える」のはそれぞれの仕事で、「考えてあげる」のは相手を子供としてみなしていることになる。新人であっても「(西洋の)大人」として扱おう。

チームにパワーを持たせる価値

海外の同僚の活動を見ていると気づくことに、日本以外の国は「開発者」「運用者」つまり現場の人が技術や方法論選定のパワーを持っている。日本は「マネージャ」が決めるので、「開発者」「運用者」の決定権がない。しかし、新技術導入のペースを勧めるために必要なのは、そこに対して鼻の利かない人の承認ではなく、彼らを「信頼」して「任す」ことによって「現場」がパワーをもって、チームが自ら考え意思決定していく組織にある。 チームが自ら判断していけば、新しい技術の導入も、新しいチャレンジも活発化されてくる。

f:id:simplearchitect:20160704004618j:plain

「自分で指示するほうがチームメンバーを考えるとよいと思う」とか「チームメンバーは指示待ちだから厳しいと思う」とか「自分勝手な行動をチームが取り始めたらどうするのだ」という意見もあると思う。

それでも私は「自己組織チーム」をお勧めしたい。1人が、他人に対してすべての要素で優れているということはほぼ無いだろう。だから、みんなのCPUを結集して問題解決に当たるほうが効果が出やすい。

「指示待ち」ということに関してはその通りの場合もあるかもしれないが、「人間は成長する」ため、「できない人を何とか管理」という方向性ではなく、「できる人」にする方向性のほうが、人による生産性の違いが10-25倍と言われるソフトウェア開発の場合は、効率的な気がする。「できない人」に焦点を合わせるといつまでたっても生産性は上がらない。

最後に何より、チームメンバーが「仕事を楽しめる」ことだ。これが最も自分的に大きい。私だったら指示されて仕事するなんて面白くもなんともないのでまっぴらごめんだ。自分の意志で自分で選択した仕事をプロフェッショナルにこなしていきたい。あくまで個人的な意見ではあるのだが、私はそう考えている。

日本に合わせるのではなくルールを変える

こういった「サーバントリーダーシップ」の考え方なども、現在の日本の組織や、ルールになじまないように感じる。ここで「できない」というのは簡単だが、そうやっている間に、海外とどんどん差をあけられていくのも確かだ。しかし、会社のルールなんて所詮どっかのおっさんが過去に決めたものだ。過去にはそのルールは有効だったが、現時点でそのルールが有効かは分からない。ルールは目的があったはずで、それに人間が縛られるのはナンセンスだ。東洋の端っこの小さな「日本のやりかた」にこだわるよりも、私は自分がより良い仕事をして楽に成果を出せるようにしたい。世界の基準でよい仕事ができるようになって、もっと世界に貢献したいなと思う。

次回は、自己組織チームに関係する、計画や、納期の考えの違いに関して整理しておきたい。

日本をクビになる日

今回のブログは沢山の人に読んでもらいたい内容ではなく、単純に自分が考えたことの整理です。

f:id:simplearchitect:20160702222739j:plain

私が初めて、オブジェクト指向アジャイルを取り組み始めたのは2001年頃でした。なぜそのようなことを始めたか?というと、当時のシステムは自分から見ると「かろうじて動いている」という感じで、「しっかりと作られている」というイメージがありませんでした。徹夜で何とかふらふらになりながら納品したものが高品質なはずがありません。だから、自分なりにいろいろ「よいシステム開発の仕方」について学び始めました。

「現場」と正反対の開発方法論

 すると様々な気づきがありました。まず「オブジェクト指向」の分析・設計・それに使われるプロセスを学んでみると、当時の開発で行われている考え方やスタイルとまったくと言って異なっていました。「どうして会社でやっている開発と、ソフトウェアエンジニアリングで説明されているスタイルがこんなに違うんだろう?」まだそれは、あくまで疑問のレベルでした。

 ところが、平鍋さんのWebページで紹介されていた「eXtreme Programming」と出会って、人生が変わる程の衝撃を受けました。

今までの開発手法と、時には正反対のことを言っているが、自分の感覚的に凄く「正しい」気がする」これなら、私でもお客様に本当にいいソフトウェアを届けられるんじゃないか?

books.rakuten.co.jp

 そういう思いがあり夢中になり、コミュニティ、社内外への啓もう、事例づくりにいそしみました。私としては絶対にこれは重要になるからうちの会社でもやるべき、いやうちの会社だけではなく業界でやるべき。もし、万が一、仮にそれが正しかったとしても、それは人への押し付けでしかありません。

龍野さんの一言

そんな当時の私に対して、人は「やったらいいんじゃない」、とか、「あれは宗教だ」とか様々な反応でした。私が今も尊敬する龍野さんという方がいて、その人が私に言ってくれたことが私のスタイルを永遠に変えました。

なあ牛尾よ、お前がやっていることは押し売りやぞ。北風と太陽やないけど、みんながやりたくなるようにせなあかんのちゃうか?

 当時の私にとって、その言葉はとても響きました。龍野さんは誰からも尊敬されるような方ですが、決して偉ぶっているわけでもなく、仕事もものすごくできましたがお客様からも、社員のメンバーからも上下隔てなく尊敬される人格者です。  私の行動も多くの人にはスルーされるなかで、龍野さんは相当にサポーティブに助けてくれていました。そんな方の一言だから響いたのかもしれません。  

 その後私はスタイルを変えて、自分のモットーが「相手を理解する」になりました。お客様に対峙するときでも、何かを説明するときでも、常に自分ではなく、相手がどう思っているか、どう感じているかを常に観察、考えて、試行錯誤して、自分ではなく、その人にとっての価値を出せるようにするというスタイルです。この言葉の価値は今も変わりありません。

 そのお陰で私は、コンサルや、新しい技術導入や、教育が大変得意になることができました。独立もしましたし、教育やコンサルをやるときはいつも高い顧客満足度を得ることができるようになりました。

 更に、アジャイルのマインドセット、コンサルティングや、セラピーなどの理論や技術を学んでいく中で、どの分野であっても「人は変えることはできない」という原則を見ることができました。仕事においてだけなのですが、「人とうまくやる」ということにおいてはこの頃が人生のピークだったのかもしれません。内向的な性格ですので「無理」と思っていた結婚もすることもできました。

自分のために生きること

しかし、その後、いろいろなことが崩壊していきます。仕事上でストレスを感じることも多くなり、私の責任なのですが、妻は私の元を去りました。仕事でも、自分が相当役立ってると思えるときもあれば、ちょっとだけしか役にやっていないと思うこともありました。当時コンサル料金をたくさん頂いていたのもあり、バリューが出ないと、相当申し訳ない気分でした。何よりも自分がイヤでした。

セラピーを本当のセラピストから実地を通じて学ぶことで自分的に頂点を極めた「人のことを理解する」という能力ですが、このころの私は「人のために生きている」ということに気づいていませんでした。ただ、お客様には最高に気に入られるのですが「自分が無い」気はしていました。

私の友人の細川さんは、当時の私を振り返って「あの当時のうっしーは面白くなかったよ」って言ってくれました。人にとって心地よいことはできるし、日本社会ではうまくいくのですが、私が本当に幸せだったは相当謎ですし、様々なことを我慢していました。さらに、お客様にとって、私はプロとして「本物」を迷うことなく届けられたのか?というと疑問が残ります。

  その後、先のポストでもお話しした通り「幸せシフト」を行い、「人のためではなく、自分の幸せのために、自分で人生の選択を行う生き方」にスタイルチェンジし始めました。

simplearchitect.hatenablog.com

コーチが一人前になる条件

「自分の幸せのため」に行動するようになると、私の「自分は何か一つでもいいから、プロフェッショナルと呼べるレベルの物事を達成したい」という欲がでてきました。お客様に対しても、耳障りの良くないことも言うようになってきました。コンサルタントが役に立つ大きな理由は彼らが優秀だからとかでは決してなくて、「第三者」の視点を持てることです。だから、耳障りのよくないことも正確にフィードバックする必要があります。これはとても勇気のいることで、自分がクビになるかもしれません。

ある時、一緒に働いているお客様のチームに対して、お偉いさんがたくさん並んでいるシーンで、ネガティブなフィードバックをしないといけない場面がありました。正直非常にストレスで、人に嫌われることは確実で心も痛みましたが、勇気をもって、少なくとも自分的には正確なフィードバックを実施しました。今はすぐにわかってもらえないと思うけど、そのチームに必要だと思ったからです。 

その後そのチームにはあまりかかわれなくなりました。当然だと思います。スクラムコーチの世界では「クビになったら一人前」という言葉があります。チームに耳障りのいいことだけしている人は半人前。 私はその会社さんではその後もほかのチームのご支援をしていましたので、まだ私は半人前と言えます。

第三の方法

そんな過程を経ている中でマイクロソフトのインターナショナルチームに参加して、世界と日本の圧倒的な差、そして、15年経過しても進歩が少ない現状を目の当たりにして、今までの「ソフトランディング」な方法でよいのだろうか?という疑問がでてきました。そんな中インターナショナルチームのメンバーから刺激を受け、学んだことで、日本と、西洋のマインドセットの違いに到達しました。 しかし、マインドセット、つまり、人の考え方を私が変えようというのはおこがましいことです。しかし、このままでは、、、というジレンマがあります。どうしたものか、、、そこで考えた作戦が次の仮説です。

人には何も押し付けないけど、自分の思った事は発言する。そして、自分が自ら自分がいいと思う行動することで、それを気に入ってくれる人を増やすようにしてみる。

  世界を変えたかったらやることは一つで、自分が変わることしかありません。人は変えることはできませんが、私が、西洋のマインドセットのうち見習ったほうが良いと考えたことを自分で常に実践することで、もしかすると人が「あの人楽しそうだな!とか、あの人生産性高いな!」とか感じてくれるかもしれません。また、「本当はそう思っていても言えない」と思っている人がいたとして、私が常に思っていることを躊躇なく発言していると、「ああ、言ってもいいんだ!」と思う人が増えて、自由でフラットなコミュニケーションができるようになるかもしれません。

 これは万人に受け入れられる考えでもないですし、仮説でうまくいくかも全然わかりませんが、自分が思った事を誰に対しても発言するが、他人にはそれを求めない。「人から学ぶ」「人を理解する」ことは続けるが、「自分はこう思う」というのは明確に発言する。ということを実験してみたいと思います。

日本をクビになる日

 よくよく考えると、今も尊敬する龍野さんも、人の気持ちを理解できるだけではなく、主任の当時、事業部長を説教したといっていました。私が多大な影響を受けている倉貫さんも、自分の思うことは誰の前でも明確に発言しています。私は正直気が弱いので、内心は勇気を出していますが、今後もこのアプローチをまず一定期間実施して仮説検証をしてみようと思っています。

 私は常に何か一つでもできる人になりたいと思っています。今はどれも中途半端です。でも、いつかこれを続けていたら、日本を「クビ」になる日が来るかもしれません。先日の投稿を読んで「震えた」と言ってくれた人がいました。あの投稿がほんの少しでもいい影響があったて、喜んでくれた人がいるなら、本当に怖かったけどやってよかったなと思います。

そして、「日本」をクビになる日がやってきたら、もしかしたらそのときこそ、私がやっと一人前になれるときなのかもしれません。

龍野さんや、倉貫さんのレベルにはまだまだほど遠いですが、自分のために、楽しんでぼちぼちやっていきます。 

自分で人生を決めるマインドセットが、生産性と、仕事の楽しさをもたらす

今回は、前回のブログの内容をより考えてみたいと思う。

f:id:simplearchitect:20160625232007j:plain

「自分で人生を決める」人は、他人に対して「すべき」がない

前回のブログの主張は、「自分で人生を決めない」マインドセットが、新しい考えや技術導入を遅らせるというアイデアだった。今回はさらに、「自分で人生を決める」マインドセットをもっていると、どういう効果があるのかを考えてみたい。

simplearchitect.hatenablog.com

「自分で人生を決める」というマインドセットを持っていると、「自分のことは自分で決める」という考えになる。心理学で鏡の法則というのがある。自分に適用している考えを他人にも適用するという法則だ。「自分のことは自分で決める」人は、「他人のことは他人が決める」という考え方になる。新しいアイデアや技術の導入スピードにはこれがとても効いている気がする。  逆に自分の人生が自分でコントロールできないと思っている人は、他人も他人がコントロールできないと考える。つまり、自分だけではなく、他人も他の何かに従うべきと考えるようになる。

インターナショナルチームで働いる時に感じることの一つは、人に「こうすべき」と言われることが全くないことだ。

 もうすぐ期限の経費精算とか、必ずやることになっているものでもそうだ。例えばビジネスレポートの期限が迫っていて、私が忘れてた時ですら、「期限だから、入力してくれないだろうか?」ぐらいの口調で上司がリマインドしてくれる。  それぐらい、ほかに人にどうしろ、こうしろと言われることは本当にないのだ。もし、そうしなかったら、自分の評価が下がるだけだ。やるか、やらないかは私次第。人に「やらされる」ではないのだ。大人だから自分で決めて、判断しようという考えだ。

「本当に思った事」を言うエネルギー量の違い

今回ブログを書いて気づいたことだが、何か「意見を言う」ことの負荷が、インターナショナル環境と、日本では全然違うことに気が付いた。インターナショナル環境だと、「自分の人生に責任を持つ」マインドセットだから、私が同じような意見を書いたところで、たとえ多くの人と考えが違っていても、「あー、君はそう考えるのね」というノリだし、そうでない考えの人は自分でブログを書いて、「私はこう考える」ポストをする。  もちろん、そのアイデアに対してさらに自分がブログを書くか否かは私次第ということになるので、書いてもいいし、書かなくてもいい。だから相当気軽にアイデアをシェアできる。

 ところが、日本で同じことをやると、そうもいかないようだ。今回のことでも、様々な方面から、「あなたはこうすべきだった」「フォローアップブログを書くべきだ」「きみのせいで、ほかの人が困る」「人の気持ちに気を配るべきだ」・・・。これは、人の考え方だし、文化に対して何かを言うつもりはない。ただし、メソッド屋として「新技術やアイデアの導入スピード」ということのみを考えると、これは相当問題だ。私の意見が正しいと私が思い込んでいるいう意味では取らないでほしいが、例えば、天動説が主流の頃に、自分はそう思うということで、地動説を唱えると、人は大きなショックを受けるかもしれない。天動説で商売をしている人は大きな打撃を受けて困るだろう。あなたの顧客には天動説の人もいるかもしれない。でも、それに遠慮をして、本当に自分が思う意見を言わないほうがいいだろうか?もちろん、あっているかどうかはわからないが、それを言えないとなると、相当いろんなものが歪んでしまう気がする。

 日本では、そういったことに、いろいろ気を使って、何かをしなければならなくて、尚且つ、何かやった後も人々の要請があったり、「こうすべき」という意見があれば、それを実行しないといけないとすると、相当な負担だ。つまり、「めんどうくさい」のだ。

自分の意見をいうことに、ハラキリの覚悟は不用

 だから、日本式でいくと、こういうセンシティブなブログは、書かないほうがめんどくさくなくていいし、多くの他の人と違う意見を書くときはハラキリレベルの相当な覚悟をもって言わないといけない。これは、相当なエネルギーロスじゃないだろうか? だから、多くの人は本当は思っていることでも、「あとで面倒なことになるから、言わないでおこう」ということになるだろう。実際、今回私もブログを辞めようかとも思った。だってしんどいし、めんどくさいんだもん。

 それよりも、単なる意見なのだから、「自分はこう思うよ」でよいと思う。気楽に言えたほうがよっぽどディスカッションみたいなものは気軽に、簡単にいかないだろうか?

 そうでなければ、本当は心に思っていることが多いことでもみんな自粛して「言わないほうが得策」みたいな流れになってしまい、意見も「トレードオフがあるのでケースバイケース」みたいな聞き分けのいい話にしかならなくなる。

インターナショナルチームのディスカッションは楽

 インターナショナルチームでディスカッションしていつも思うが、ディスカッションが本当に楽だ。自分が思っていることを単純に言えばいいだけだし、「気をつかう」なんてことは不用だ。純粋に思っていることを言うだけで、そこに、気をつかわなくていいし、「言ったからには・・・」といった変な責任が発生するわけでもない。  ダイバーシティが前提で、人がひとりひとりまったく違っていて当然という考え方だから、他の人の意見に対して「私はこう思う」というコメントはあるが、「お前は間違っている!こうすべき」みたいなことは無い。だから、ディスカッションも余計な要素がなくてとてもスムースに終了する。 もちろん「偉い人」なんて存在しないから、お伺いを立てたりすることも不用だ。

simplearchitect.hatenablog.com

Agile Rootsでの出来事

 ここで、私も印象深かった、Agile Roots 2014での出来事をご紹介したい。Jeff Pattonという著名なアジャイルコーチが開催するワークショップに参加していた時の事。

f:id:simplearchitect:20160626061045j:plain

そこにメアリー・ポペンディークという著名人が一緒にワークショップを受けていた。ジェフが、Scrumの世界で有名な「鶏と豚がレストランを開くたとえ話」を始めたときに、メアリーは立ち上がってシャウトした。メアリーはこのたとえ話が大嫌いなようだ。

ジェフ。君がこのたとえばなしをするなら、私はこの場を出ていく!

そういって、彼女は実際に会場を出て行った。ジェフは、何もなかったように講義を続けて、数十分後にメアリーは帰ってきて引き続き彼のワークショップに参加した。 ワークショップに参加したあと、メアリーはジェフに「君のワークショップとてもいいね!」と楽しく談笑し、褒めていた。

 私はその姿を見て当時はすごくびっくりしたのだが、「意見の違い」なんてものはそんな程度のもので、そこに余計なものがいろいろはいるのがややこしいのだな。というのを学んだ。違う考えがある。時に腹も立つ。だからといって、ジェフに対してどうこうしろというのではなく、自分がしたいから自分が出ていく。それで終わり。何のわだかまりもない。

books.rakuten.co.jp books.rakuten.co.jp

他の例でも、海外のカンファレンスにいくと、参加者の人が、しょっちゅう席を立って退出する。日本だとよっぽど面白くないセッションでもない限りスピーカーに気を使って、立たないことが多い。しかし、向こうだと「自分がほかのを見たかったら」他のを見に行くし、スピーカーも、退出する人をみてショックだとかは特に思わない。自分次第。

「自分の人生を自分で決めない」マインドセットから生まれる、自分以外のものに対する「こうすべき」という考え方は、もちろん良し悪しだが、新技術の導入や、新しいアイデアの導入に関しては、相当なマイナスをもたらす。自分が何かしようと思った時に、いろんな角度から、「ああすべき」「君は間違ってる」「それは認められない」など凄い反発がやってくる。

「大人」という考え方の相違点

今回ある人がこんなコメントをくれて非常に興味深かったのでシェアしたい。彼は日本と、インターナショナルの混在環境で働いている。彼はこう言っていた。

西洋では「自分の人生や幸せを自分で責任を持ちコントロールする人」が大人という認識で、日本だと「我慢するのが大人」という文化のコンフリクトがあって困っている

なるほど!面白いと思った。私は生産性が良いし、自分が楽しいので前者を選択する。今は世界の文化を体感することのできる時代だし、自分がいいなと思うのを取りいれることができるので楽しい時代だ。 今回、2本のブログが読まれてたくさんの賛否両論があった。正直相当疲れてダメージも大きかった。そんなポストをしていたら、なんとロッシェルさんが私にコメントをくれた。

ブログを書くのは、ほかのクリエーティブな活動と同様です。In the moodだったら楽だが、そうじゃないと負担です。そのため、書きたいムードじゃない時に書かなくてもいい。そして書きたいムードになったら、書いてください。書くことによってハッピーになるのは第一です

自分は自分の人生をコントロールするマインドセットだと思っていたが、彼女のコメントは、凄く興味深いと思った。一番重要なのは本人が「ハッピー」かどうかという観点だ。ダメージを受けている時点で自分もまだまだ。私もそっちのマインドセットのほうが自分的に好きなので、更にそっちに慣れるように楽しんでみよう。でも一番は、それをして「自分がハッピー」と言えるかが重要なのだろう!

日本の新技術導入のめんどくささ

ふと、思い返したのだが、自分が、2001年にその後、アジャイルを初めて、エンプラな環境でも実施するために当時やったことを振り返るとこんな感じだった。

  • 小さなアジャイル案件を作るために、自分で営業して、自分でコードを書いた
  • アジャイルのコミュニティを社内でつくったり、社外のコミュニティの運営に参加した
  • 内外でプレゼンテーションを実施して、仲間を集めた
  • 大きな規模のアジャイル案件を実施するため、RFPの段階から参加して顧客にメリットを説明した
  • その案件でアジャイルを実施するために、請負契約でアジャイルを実施する契約方法を考案して実施した
  • その案件でアジャイルを実施するために、WF型の品質管理方式に対応するために、品質部門の人とディスカッションしてアジャイルでもまわるようにした
  • アジャイルで必要な「テスト駆動開発」をするためには、OOPが必要だが、OOPができる人が当時少なかった。だから、OOPが誰でも理解できるようなメソッドを作った。
  • 実際にアジャイルができる人をプロジェクトのメンバーに加えた。他のメンバーも教育した。
  • 平鍋さんを呼んできてコーチをしてもらった。そのためにいろいろ説得した。
  • アジャイルを実施すると、「要求」の部分がスムースにいかないことが多く、要求開発手法を学び実践した(当時プロダクトオーナという概念はまだなかった)
  • いろいろなステークホルダ、上司、さらに上の上司と話を話をして、アジャイルプロジェクトがつぶされないように、交渉した
  • お客様経由でマスコミに取り上げてもらって、より動きやすくした   :その後につづく、、、、

たかだか、新しいやり方を導入するだけでなんでこんなめんどくさいことをしないといけないのだろうか?私は新しくて効率のよさそうなやり方があるので、それを実施したかっただけだ。普段「やろうと思えばできるよ」と軽く言っているが、今と違って最初の頃にそれをやるときはこれぐらいめんどくさかった。  今回インターナショナルチームに参加して、他国の様子を観察していると衝撃だったのが、他国ではこんなめんどくさいことはいらないようすだ、「開発者」の人がやってみようと思ったら「やる」だけの話だ。

 前にも書いたのだが、500人ものハッカソンの開催が、1回の会議で決まっていく。日本だったらいろんな人の承認とか、合意とかを得ないと実施できない。こんな「めんどくさい」なら、日本では「無理」という気持ちはとてもよくわかる。だから、それをぶち壊したいのだ。

simplearchitect.hatenablog.com

素直に考えると、これだけめんどくさいと、「あー、もうめんどくさいから、海外いくわー」とか、「めんどくさいから自分で会社やるわー」とか「めんどくさいから、めんどくさくない文化をもったスタートアップに参加するわー」となるのも当然だろう。 そもそも、新しい技術や考え方の導入は、ずっと遅くなるのも当然だ。でも、新技術や、新しいモノの考え方の導入は、本来楽しくてエキサイティングなものだと思う。

「自分の人生に責任をもつ」マインドセットの楽さとチームの楽しさ

 正直いって、私も昨年から始てインターナショナル環境で働き始めたので、その後初めて知ったことだが、インターナショナル環境で働くのは楽しいし、すごく生産的だ。自分の上司は、明確で無理のないKPI,ビジョンを示したら、あとは自分にフルに任せてもらえる。

simplearchitect.hatenablog.com

自分で考えて自分で実施する。チームメンバーや、ほかのステークホルダからも、「あなたはこうすべきだ」みたいなことは一切言われない。

 ただ、自分がフィードバックしてほしい時に聞いたら喜んでアドバイスをくれる。みんなそれぞれが自分の仕事を楽しんでいる。「我慢」は一切だれもしていない。チームでやる必要がある仕事があって、誰も手を上げない場合は、「誰かこれにパッションある人を雇うか」となるか、普段自分がやりたいことをやっているので、「今回は俺やるわ」みたいな感じで、やらされるのではなく、自分が決めてそれを実行するので、何の不満もない。また、それを誰も選択しなくても、誰がわるいとかそんな話にはならない。

 みんな主体的に自分の仕事を持っている。だから、誰も助けてくれなくても、それが普通だ。「助けるべき」みたいな変なプレッシャーは存在しない。忙しいときに、会議をスキップしても、メールをスルーしても、特になにも言われない。その人が仕事に対して責任をもっているので、誰かのせいではない。自分がKPIを達成できなければ、自分の給料が下がるか首になるだけだ。

 だから、誰かが助けてくれたときは、とてもうれしい。

 チームのために何かを作業したら、みんなからほめてもらえる。「ここがだめ、あそこがだめだ、さらにこうすべきだ」みたいなことにはまったくならない。ただ、正直なコメントは飛び交うけど、それをしたからといって、「誰かがきずつくからオブラートに包んで、、、」みたいなことはない。みんな「大人」とみなして行動する。意見が違っていたりしても誰も気にしないし、言ってはいけない意見とかも、仕事上は特にない。早く帰っても、いつ休暇をとってもだれも、それをさぼってるとかは思わない。むしろエンジョイしろよと言ってくれる。

プロフェッショナルさは重視される

 そのわりにとても結果に関しては、プロフェッショナルだ。日本でのプロフェッショナルというのは、すごい厳しいイメージなのだが、インターナショナルチームだと、厳しさはみじんもない。「基準」に達している、否かは非常に明確だが、失敗しても、チャレンジには開いているので、何回でもチャレンジできる。  さらに、仕事も人生もエンジョイするものという考えだ。だから、各個人は楽しみながらスキルを常に磨いているので、アウトプットはみんなレベルが高いし、スキルアップを怠ってる人なんて人も見たことがない。

 たぶんこれは「雇用制度」の違いも大きいと思う。こちらでは、簡単にクビにできるので、みんな「自分」が売れるようにしておく必要がある。会社も、働かない人は、残念ながら退職していただくことができる。一瞬これは厳しそうに見えるがKPIが達成不可能なものになっていないので、日本での「厳しさ」感はないし、裏を返せば、社員のほうも、嫌だったらいつでもやめてもっと楽しい会社に移ることができる。だから、今のところより条件が良いところがあったら、あっさりそっちに乗り換える。そんなことをしても、誰も「裏切りだ」とかは言わない。だって、本人のチョイスだからだ。

simplearchitect.hatenablog.com

海外の労働環境の楽しさが伝わりつつある

 今まで私はインターナショナルチームで体験したような環境が存在すると思っていなかった。でも、海外に出たらそれが存在した。自分がハッピーで仲間もハッピーでイキイキ仕事ができてめんどくささがないので、生産性も高く、みんな一年ごとにさらに向上しあえている。マイクロソフトだからと片づけるのは簡単だけど、海外で働いて、日本に帰ってきた人で「日本に帰ったらいろいろめんどくさい、また戻りたい」と言っている話を少なくとも私はよく聞いている。たぶん同じような感じなのだろう。

前回のポストをした後に、こういうコメントをくれた人がいた。彼はUSに住んで働いている。

彼のコメントは、今ならどういう意味かわかるのではないだろうか?

この事実は一瞬ネガティブな情報に思える。しかし、もしあなたの会社が、海外のようなハッピーな職場にすることが出来たらものすごい行列のできるようなお店になれる可能性があるのではないだろうか?カルチャーに取り組むところはそんな多くないから差別化の大チャンスだ!

日本で「自分で人生を決める」マインドセットのチームを作るには?

これは私も試行錯誤の最中だ。しかし、確実に作れるとは思っている。ポイントは「チーム全体のカルチャーのチェンジ」だと思う。例えば、チーム10名のうち、1名だけ、「自分で人生を決める」マインドセットの人がいたとする。その人が海外で過ごしていたのと同じノリで仕事をすると、針の筵のような感じになるだろう。

 一方、海外のチームに参加した日本人で、このような、「快適さ」に気づく人は多いと思う。こっちのほうが楽しくて、待遇もよくて、スキルアップできて、チームに喜んでもらえるし、自分の思うようにできる。最初は、自分が持っていた「自分で人生を決めない」マインドセットで、戸惑うことがあるが、2か月もすればなれてくる。そうなったら、日本での勤務を思い出すと本当にバカバカしく思えてくる。

だから、そういう人は私も含めて将来海外でまた働きたいと思っている人も多いと思う。

 つまり、そういう環境にいたら、日本人でもすぐ慣れてしまうわけだ。ということは、こういうマインドセットをチームのカルチャーにして、チームのみんながそれになじんでくると、新しく来た人もそのカルチャーにすぐ慣れてくるということが可能な気がする。  Pivotal Labs はサービスとして、Extreme Programmingというアジャイルの手法を顧客に伝えるときに、顧客をPivotalにしばらく呼んで、一緒に開発をして、その開発習慣を伝授するサービスをやっている。非常に本質的だ。

 つまり、それと同じことを、自分のチーム、もしくは会社でやればいいのではと思う。もちろんまだ私もこれに関しては事例はないがご希望の会社さんがいたら一緒に実施してみようと思う。

 そうできたら、日本でも、「USと同じスピードで技術導入できるチーム」が増えてくるのではないだろうか?

simplearchitect.hatenablog.com

外から見てるだけなのでわからないですが、きっと、ソラコムさんとか、ソニックガーデンさんとかはこんなマインドセットな気がします。日本でもきっとできると思います!

www.slideshare.net

kuranuki.sonicgarden.jp

統計からみた従業員エンゲージメントの低さ

私もロッシェルさんの著書で初めて知ったのだが、従業員エンゲージメントという指標がある。従業員満足度のことだ。この満足度の調査があるのだが、私は世界平均と、日本の従業員エンゲージメントの比較を見てびっくりした。

f:id:simplearchitect:20160626063947j:plain

なんと、世界平均だと、「満足」が圧倒的に突出しているのに、日本では、「非常に低い」というのが圧倒している。そして、5年連続で、日本は最下位らしいのだ。そらそうだよな。。。これはやはり雇用形態が大きく影響しているものと思われる。 そして、海外経験者中心に、この実態に気づいている人が少しづつ増えている気がする。そうした人は当然日本の企業で働くのが嫌になって海外に行ってしまうだろう。自分ができることからこの状況にアタックしていきたいと思っている。

books.rakuten.co.jp

「マインドセット」を変えて、世界に勝てるチームを作ろう!

日本人は、海外の人から見るといろいろいいところがある。磨き上げる能力、イノベーティブでユニークな発想、勤勉さなど、これぐらい世界と違うということは相当な競争力なのだ。そのユニークさが生産性のあだとなるなら、あだとなる部分だけ、「マインドセット」としてインストールして、課題を克服してしまえば、日本からもっと世界を「凄い!」と言わしめることができるのではないだろうか?

 そのためには、ソフトウェアの先進国に学んで、その課題を解決していくしかない。私の考えはもちろん私の単なるアイデアで、うまくいくかもわからない。しかし、私的には、他人は変えられないので、想定する「マインドセット」を変えて仕組みをつくる。つまり、「大人とはどういう人か?」の基準をそちらにして仕事の仕組みを変える。楽しくなるし、チームでやれば仕事もめんどくさいことがなくなるし、いろいろ気づかいをすることなく、本当のことが言いあえるし、「我慢」もしなくてもいいし、チームで称えあってハイレベルの仕事ができるチームが出来るかもしれない。そんなチームが作れたらすごくうれしくないかなって思っています。

f:id:simplearchitect:20160626064457j:plain

 ダメだったらだって?私も海外で職をさがすだけですね!

だって、自分は自分らしくあり、楽しく仕事をしつつ、正直で、プロフェッショナルでありたいですから!

  次回は自己組織化チームのことを掘り下げてお話ししていきたいと思います。