メソッド屋のブログ

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

英語鎖国で深刻なのは情報入手のスピードじゃないと思う

エンジニアに英語が必要と言われて久しい。技術情報を早く入手するためには、英語を使えないといけないからとあるがこれは本当なのだろうか?自分的な気づきがあったので、その考察をシェアしたい。

f:id:simplearchitect:20160906194626j:plain

 エンジニアに英語が必要と言われている。いろんなことが言われているが、情報の入手のスピードが遅くなるという意見がある。個人的にはこの意見はある意味微妙な意見だと思う。 最近だと例えば最新技術に関する海外イベントがあったとしても、翌日、早ければ当日の間に誰かがまとめブログをアップしてくれたりする。もっと時間がかかったとして、2カ月程度後に誰かが書いた日本語の情報でそのことを学んだ ところで、大勢に影響はない。 また、日本語で出ている書籍は確かに翻訳のタイムラグがあるが、海外の人も主だったすべての本を読んでいるわけではないし、日本語になったものを着実に勉強しても、勉強の知識としては、相当なエンジニアになれるはずだ。 では、なぜ?

日本人の英語アレルギー

日本にいると、英語の拒否っぷりにすがすがしい気分すら覚える。私は英語でもブログを書いているが全く読まれないし、それどころか、Facebook に英語でポストするだけで、「いいね」はほとんどつかない。もちろん、英語のMeetupには絶望的に人がいないし、海外の人と会議をしても全くしゃべらない人も多い。

f:id:simplearchitect:20160906200438j:plain

一方、ネイティブじゃなくても、他国の人は英語がむっちゃくちゃでもとにかくしゃべってコミュニケーションを取ってくる。昔、今のインターナショナルチームに入った時に、最初は同僚がしゃべりまくるスカイプコールがつらくて、Damien に自分は英語がうまくないからといった時がある。そしたら彼はこういった。

Tsuyoshi は英語がうまいよ

私は明らかに同僚より全然聞けていない感じがする。しかし、それは、Damienが気を利かせたわけではないということに気づいた。彼らの中には文法とかぐっちゃくちゃの人もいる。それに比べると私のは相当ましということなのだろう。彼にとってはそう聞こえようだ。  私がどうこうではなく、本来高度な教育を受けている日本人は平均して、英語はわるくないのかもしれない。ところが、圧倒的に英語を「敬遠」する人が多いように感じる。  私は厚かましいたちなので、あまり遠慮はしないたちだが、同僚と働いている中で「英語」を避けることの本当の大きな問題に気が付いてきた。

インターナショナルチームでの苦悩

 インターナショナルチームでは楽しくやらせていただいているが、一つだけ心苦しいことがある。自分のチームに対してバリューが出せていないのだ。私の純粋なチームには「英語ネイティブ」はいない。だけど、彼らは全員英語で仕事をしている。それは、対お客様に対してもだ。もちろんイベントの資料もそうだ。だから、彼らは自分が作った資料やアセットをチームに共有すると、他のチームメンバーがとても喜ぶ。英語でデモをするコードを作ったら超喜ばれる。  ところが、日本だけが、日本語で書かないとお客様や、イベントでは見向きもされない。だから、私がどんだけ一生懸命資料を作ったところで、それは日本限定であり、チームには貢献できない。

 他にもある。私のチームで、PartsUnlimited という、Hello Worldレベルではない DevOps のハンズオンラボをGitHub 上で公開している。今期の戦略に合わせて、その内容を修正/追加しないといけない。

github.com

 ところが、私は日本側の準備(日本語化)をするので手一杯だ。しかも、そのプロジェクトに貢献したところで、日本では英語だから全く役に立たない。だから、メンバーには言わないけど、いつも心の中でメンバーに申し訳ないという気持ちを 持っている。

世界コミュニティは、特にハードルが高くない

日本にいると、「世界挑戦」という言葉があるとおり、「世界」は凄いところで世界に出ていくのはハードルが高いというイメージがある。ところが、他国のメンバーや、他国の友達をみているとそんなことは全くない。私の友達のポーランドの マリアは、16歳のころからモデルをして、他の国を渡り歩いていた。

f:id:simplearchitect:20160906200801j:plain

ほかのイギリスの語学留学時代の友達も、英語が下手でもなんでもその人が他の国で働くこと自体にハードルを感じている人はいない様子だった。  実際にインターナショナル環境で働いてみると、彼らが圧倒的に優秀とかではない。世界にも優秀な人そうでない人もいる。MLBは、本当に世界の超一流が集まっているのでハードルは高いが、普通の仕事はそうではない。日本はそうでも ないが、海外に行くと、他の国の人々を頻繁に見かける。

f:id:simplearchitect:20160906202133j:plain

 しかし、問題は、ソフトウェア開発だと平均すると、日本のレベルははっきり言って相当低いと言わざるを得ない。世界が凄いのではなく、日本がしょぼいのだ。これはなぜだろう?

世界コミュニティに貢献できないことがもたらす問題

 英語を避けることによって、最も問題なのは、世界コミュニティに参加できなくなることだ。私が「インターナショナルチームでの苦悩」で書いたことは、日本の縮図である気がする。

f:id:simplearchitect:20160906204906j:plain

 例えば何かの仕事を一緒にするときに、日本以外の国は、英語でも突撃して、世界コミュニティがやっていることに対して「貢献」をする。それはブログかもしれないし、コードかもしれない。講演をして、アイデアをシェアするのもその一つだ。  実際にアジャイルカンファレンスに出かけると、スピーカーが「ネイティブ」とは限らない。普通に講演しているし、ブログや書籍も英語でガンガンに書くし、例え英語がしょぼくても、英語でガンガンにコミュニケーションを取って、その場でバリューを出して貢献しようという姿が感じられる。

 ところが、日本だと、「英語での最新情報を早く入手したい」という意識はあれど、「貢献しよう」という人は相当少ない。もし、それを、「世界コミュニティ」のメンバーから見たらどう感じるだろう。何の貢献もしないけど、情報だけを欲しがる 「クレクレ君」に見えるのではないだろうか?私は少なくとも、みんなにいろんなことをしてもらっているのに、もらう一方だと相当肩身が狭いので、貢献をしたいという気持ちになる。誰が「クレクレ君」と一緒に仕事をしたいと思うだろうか?

 その為には、英語のレベルがどうや、こうや、と言っている暇があったら、世界コミュニティに「貢献」を始めたほうがいい。気軽に始めるのは、ソフトウェアだと、Issueを送るとかPull Requestを送るでもいい、ブログでもいい。なんでもいいけど あれだけ情報をもらっているのだから、こちらもシェアしないのは相当イケていないと思う。

 我々はどれだけ日本語で情報発信したところで、日本国内の人にしか役に立たない。素晴らしいアイデアをもらっている世界コミュニティーには何の貢献もできていないのだ。情報だけをゲットしておいて、自分の成果は、自分だけで享受なんてなんとも虫がいい話じゃないか?

翻訳業にパワーを割くのをやめよう

 また、他にも問題がある。世界コミュニティに「貢献」することは、単に親切だからとかではなく、自分が欲しいものを作った時に、他にも同じ問題で困る人がいるようだったら、それを単にシェアすると、その人が助かる。特に成果物がコピーできる ソフトウェアはそういうものだ。そして、「貢献」によって作り上げられた成果物は、みんなでシェアすることができる。  例えば、ハンズオンラボをみんなで作ったら、URLをシェアして、お客さんに渡してあげると喜んでもらえてバリューが出る。しかし、日本だとその成果が翻訳されるのを待つしかなく、それをお客さんに渡しても、英語のままだと全く喜ばれない。しかも、文化的背景もあり、向こうでうれしいものがこちらでもうれしいかはわからない。

f:id:simplearchitect:20160906205220j:plain

だから、多くの日本人の人は「翻訳業」に多くの工数を使っている。しかし、ソフトウェアはバージョンアップするものなので、その保守はどうしたらいいのだろうか? そんなことをしている間に世界コミュニティのメンバーは、協力・貢献して、どんどん成果をシェアしていってその恩恵をうけて生産性が向上していくことになる。翻訳を鍛えるよりハックを鍛えよう!

フィードバックを受けられない問題

それだけではない。世界コミュニティに参加できないことの問題として、フィードバックを受けられない問題がある。それは、最初の英語力のレベルとかそういう問題ではない。

 例えば、ブログを書いたら反応があるし、コードで貢献したら、コードがイケてないと受け入れてもらえない。そういう過程を経て世界の人がどういうレベルなのかを肌で感じることができる。また自分に足りないことはどこだということも、試行錯誤を繰り返す中でだんだん明らかになってくるだろう。世界の中で働くことで自分が世界で働くには何が足りないかが明確に見えてくる。

blogs.technet.microsoft.com

しかし、日本のサイロに閉じこもって、日本国内だけで思考していると、そういうフィードバックを受けることはできない。以前のポストでも書いたが、海外の人はAgileでもDevOps でもコンセプトを誤解していることが非常に少ない。それは、ロジカルに、抽象的に考えることが得意な傾向があるからではないか?と以前のポストで書いたが、そのほかにも「フィードバック問題」があるかもしれない。

simplearchitect.hatenablog.com

 我々は、数年後だが、翻訳本を入手できるし、ブログで最新技術を紹介してくれる日本語ブログを書いてくれる人もいる。だから「情報」だけでは、「5年とか、8年」と言われる日本の遅れは説明できない。問題はそこではなく、実際にプロジェクトで実施する レベルに到達する程度に本に書いてあることを理解するためには、やってみて、失敗して、フィードバックを受けたり、経験者とディスカッションする必要がある。日本だと、せいぜい狭い日本人コミュニティの中でしかこれができない。日本人の中だけだと、 すべを日本人の常識や、日本人の現在の状況だけで物事を判断しがちになってしまい、結果として、魔改造が「正」として横行するケースもあるように思う。

channel9.msdn.com

 今は海外に行くハードルは高くないので、海外カンファレンスに行けば、本を書いている著者と直接話すことができる。そうじゃなくても、海外のカンファレンスに来ている人々と、ディスカッションをしてみることで、他の国の人がどの程度のアジャイルを実践しているかがわかる。そういう、インタラクションを通じて、「肌感覚」みたいなものはわかるのだと思う。

 これが、日本だと、「海外だからうちは関係ない」となりがちだが、日本は大したプレイヤーがいないから、と日本市場になだれ込んで来たらどうするのだろうか?今は「鎖国」だから、そうはなっていないが、少しづつ、文明開化を足音が聞こえてきている気がする。 私のおすすめは、日本にいても、世界コミュニティの一員という視点で考えてみるのがいいのではないだろうか?

どうやって、世界コミュニティに進出するか?

 世界コミュニティに進出する方法は、基本単に進出すればよい。特にそこに準備は必要ない。英語があったほうがいいとは思うが、「〇〇ができるようになってから」というタイミングは永遠に来ない。じゃあ、どうやって、日本にいたままそれを達成するか? 現在の私のおすすめは、「英語のMeet up」に参加するというものだ。もちろんすべて英語だ。

f:id:simplearchitect:20160906201054j:plain

www.meetup.com

 英語がわからない不安が当然あると思うが、ここでは、「英語がわかる」を目的としていない。英語勉強にはモチベーションが重要だ。全く英語を使う必要がない人と、月に1回でもいいので、英語をしゃべれないと何もできない環境にやってきて、「次こそやってやる」 と思うのと、どちらが英語が上達しそうだろうか? 今の時代「英語を学ぶ方法」はいくらでも転がっている。それよりも、パッションが最も重要だ。遊び系がよければ、完全英語のコメディショーも面白くておすすめだ。

itpro.nikkeibp.co.jp

東京で行けるガチ英語コメディショー: Improvazilla Main Stage Show

日本ではなく、世界コミュニティに貢献する

私は日本人のためだけに仕事をするのをやめよう。日本人に対して仕事をするのをやめるという意味ではなく、世界コミュニティの一員として貢献していこうと考えている。たくさん失敗もすると思うが、そうしていくと、「世界平均」ぐらいの実力は身につくかもしれない。  私は、本当に重要なノウハウというのは、人の中にあると思う。本やビデオで習得するのは限界がある。だから、マイクロソフトでも、講演やデモを中心としたスタイルから、ハックフェストといって、お客様の社内でハッカソンをしてお客さんと一緒に最も難しい問題を解くことを支援するという動きに変わってきている。

f:id:simplearchitect:20160906205517j:plain

 これは、おそらく、講演やビデオは、いくらでもオンラインで見れる。だから、本当の価値は、それぞれの人の中に潜むノウハウなので、ディープな知識を移転し、かつ、実際にコードを共同で書いて問題を解決するのが、最も成果(リードタイム短縮など)を出しやすい。だから そういうスタイルを本社も押しているのだろう。そのためにも、自分がまず世界コミュニティの一員になれるように頑張ってみて、そこで世界平均ぐらいのレベルを獲得してみたい。

 だから、「世界コミュニティに参加しよう!」思っている人を今後は積極的にご支援していきたいと思っている。それが、私のビジョンである「日本をUSと同じスピードで技術やプロセスを導入することができる国にする」ことには必要な気がしている。

衝撃的な効率性~最高の 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年経過しても進歩が少ない現状を目の当たりにして、今までの「ソフトランディング」な方法でよいのだろうか?という疑問がでてきました。そんな中インターナショナルチームのメンバーから刺激を受け、学んだことで、日本と、西洋のマインドセットの違いに到達しました。 しかし、マインドセット、つまり、人の考え方を私が変えようというのはおこがましいことです。しかし、このままでは、、、というジレンマがあります。どうしたものか、、、そこで考えた作戦が次の仮説です。

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

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

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

日本をクビになる日

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

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

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

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