「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない
先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので
申し訳ないが、今後も読まないだろう。自分の人生は自分で決めるのだから。
simplearchitect.hatenablog.com
実は、この炎上の過程でいろんな仮説を考えることができた。なぜ、日本のソフトウェア産業は、海外に大きく後れを取ってしまっているのか？どうすれば、進化する手助けができるのだろうか？
自分の現在の仮説はマインドセット、つまり「考え方」が根本的な原因ではないか？という気がしてきた。
私が最近研究しているのは、 DevOps や Agile といった新しい考え方が日本になじまないのはそれらの考え方が、USやグローバルスタンダードの考えの上に成り立っているからという仮説だ。だから 日本文化にそのままインストールしようとするとなじまないということになる。
そういった「西洋文化の考え」を必要な部分だけインストールすれば、もしかすると、DevOps やAgileなどがもっと効率よくインストールできるのでは？という仮説だ。
simplearchitect.hatenablog.com
実際にいくつかのプロジェクトで試行しているが、今のところ上手くいっている。私もそのアクティビティの中では気づいていなかったのだが、最も根本的に変えたほうがよさそうなマインドセットを今回発見できた。
海外のメンバーと働いていて、根本的に大きく異なる点は彼らは「自分の人生や幸せに責任を持っていて、自分でコントロールしている」ところだ。それをベースとして、人を「大人として扱う」ということがある。
ここは非常に大きな相違で、このマインドセットが大幅に日本の進化を妨げているのでは？という仮説に至った。
新しい考え方や技術の導入で必ず言われること
今回の炎上もそうだが、新しい技術の導入でよく言われるのは例えば次のようなものだ
- 契約や商習慣の問題があり、導入できない
- 会社のルールで定められているので弊社では無理
- 要員のスキルレベルが対応できないからうちでは無理
- 日本の雇用に関する法律で決まっているから無理
- 経営層や上司がわかってくれないから無理
ほかにちらっとTwitterで見かけた意見これは私のブログに対してだが
- 不安を煽るのではなく、もうちょっと具体的にわかりやすくメリットデメリットを説明してほしかった...
などなど。これらの理由はすべて、これを言っていっている人以外に対して語っており、自分はどうだという話になっていないのだ。
本当にあなたがそれがやりたければ、自分でそれを変えたり、工夫したりしてやればいいのだ。それを、やりたくなければやらなければいいのだ。これらの考え方は、自分以外のものに、自分の人生をコントロールされているという考え方なのだ。 なぜ、それを「他の人」に求めるのだろう？ 自分が、「具体的にわかりやすくメリットを説明してほしかった」と思うのであれば、自分で調べて、具体的にわかりやすくメリットデメリットを説明するブログを書けばいいんじゃないだろうか？
海外の人の目から見た日本人の考え方の課題
日本とグローバルの文化を研究しているロッシェル・カップさんという方がいる。彼女は、日本でも長年働き、米国人で、シリコンバレーでもお仕事している。だから日本の文化、グローバルの文化を知り尽くしていて、日本企業に対して、グローバルマインドセットを教えたり、海外のみなさんに日本の企業と付き合う時の考え方を伝えたりしている。彼女は、日本語、英語の両方でたくさんの書籍を執筆されている。彼女の本を読むと衝撃的だった。日本人の私が読んでも日本語で書かれた彼女の本の分析は完璧で衝撃を受けた。その彼女の本の一つに次の本がある
この本では、彼女は、グローバルに働く人向けに、日本人のいいところ、直したほうがいいことを書いている。彼女は、グローバルで働く人向けにこの本を書いているが、グローバルで働くという観点じゃなくても、日本企業が生産性を上げるという面で考えても同じだ思う項目はとても多い。その課題について述べている一節をご紹介しよう。ほかのパートも面白いので是非手に取っていただきたい。
疑問をもっていてもお役所で決まったことなら黙ってしたがう、誰かに言われたからある行動をする、新聞でかいてあるから真実に決まっていると信じ込む発想、また海外で話題になったという理由だけで日本でも話題になる － 「お上と外圧に弱い日本」と「外国人に弱い日本人」と言われる側面にはこうした考え方が表れていないでしょうか？ ： 中略 社会的な慣習 ： 中略 公に決まったことならいやでも黙って従うしかないという発想・・・「中身より形が大切」というのも日本の社会を表すのによく使われる言い方ですが、形イコール規制（ルール）になってしまっている実例を見ましょう
ここで彼女はこんな例を紹介していました。
たとえば、私が初めて東京のスイミングプールに行った時にびっくりしたのは、強制的にさせられた「準備体操」でした。そして全然疲れていないのに１時間ごとに５分間か１０分間か休まなければならないということでした。また、スイミングキャップを着用しなければならないし、飛び込みはいけないし、泳ぐ方向にも決まりがあるし、楽しむために来たのに、まるで自由がないという気持ちでした。これらのルールは「安全のため」とされますが、大人なら全部自己判断で決められるはずだというのが欧米人的発想です。 日本人はそのような細かいことを命令されるのに何も感じないかもしれませんが、西洋人にとってこれは「余計なお世話」なのです。自分の体の管理のことまでどうして言われなければならないだろうと感じるでしょう。
そして、こう述べています。
脱出の方法
・「政府、医者、マスコミ、えらい人がそう言ったから正しい、だから従わなければならない」という考え方を捨てて、いろいろな事実などを確認しながら、自分で考えて、自分で決めて、自分で行動して、自分で責任を持つこと ・ ルールなどに対してフレキシブル（柔軟）に対応すること
人生は結局のところ、自分で決めている
自分の人生は、自分で決められないと思っている人は多いかもしれません。しかし、そういう人でも結局のところ自分で決めてしまっていると思います。
例えば、「会社のルールで決まっているから出来ない」という話であれば、会社のルールを変えるように動けばいいだけの話しですし、どうしてもいやなら、会社を辞めればいいです。それだったら家族が反対するという人がいるかもしれませんが、どうしてもやりたければ家族を説得すればいいでしょう。もし、これが政府の法律で決まっているということであれば、海外にいけばいいだけの話です。お金がないって？それに向けて今から貯金を始めたらどうでしょうか？
結局のところ、そういうめんどくさいことをするパワーがないので、「自分でやらないことを選択」しているだけなのです。
海外チームに不幸そうな人のいない理由
今の科学で無理なものだったとしてもその研究をしたらもしかするとできるかもしれません。自分がそう決めてるだけなのに、何か自分以外の力が働いていてどうしてもできないなんてポーズはダサすぎじゃないでしょうか？今すぐは無理だろうだって？じゃあ、１０年でも２０年でもかけてやればいいです。本当にやりたければ。
海外のチームで働いていて感じたのは、「不幸そうな人がいない」のです。みんな楽しそうで、人生をエンジョイしています。彼らは自分の人生に責任をもって、自分で考えて、どうやったら自分の人生が幸せになるかを必死に考えて選択し、行動しています。
自分の人生や幸せが自分のコントロール配下にないと思っている人は、自然と、自分が「不幸」になる選択を受け入れているからより不幸で面白くないことになると思うのです。人生に「我慢」など不要です。もし「我慢」を受け入れているとすれば、それはあなたのチョイスです。
幸せシフトをした話
私自身もこのことに昔から気づいていたわけではありません。確か３０後半あたりでしょうか。ソニックガーデンの倉貫さんが私にいろいろな衝撃を与えてくれました。彼はみんなが、「アジャイルでどうやったら、請負契約が・・・云々」「部長が・・・」「商習慣が…」とか言ってる時に、彼は自分で会社を作って、自分の理想の環境をつくってしまいました。彼の思考回路は、本当に素晴らしくて、ストレートでそしてシンプルです。そして、それを実際に行動しています。彼から「自分で選択して実行すること」を学びました。
それと同時期に、私は会社を経営していましたが、周りの会社を経営して、お金をがっつり儲けている人はたくさんいたのですが、多くの人は全く幸せそうじゃなかったんです。お金をがっつり儲けているはずなのに。いつも忙しそうで、しんどそうです。 そんな時に友人のがく君がいました。彼は特にお金持ちというわけではありませんが、私が彼に「がくくんは幸せなん？」って聞いたら、「むっちゃ幸せですよ！」って満面の笑みで答えていてそれがとても衝撃でした。
私は何となく、お金儲けとか、成功とかそういう先に幸せがあるのかと思っていましたが、実際のところお金と幸せには相関はなかったのです。だから、それ以降は、私は「幸せシフト」と言って、お金ではなく、自分が幸せになる方向に常に人生の選択をするようにしました。自分で決めたポリシーは一つで
「自分がやりたくないことは一切やらないし、いやになったらいつでも辞めていい」
そう考えて行動するようになってからは自分がする選択は、常に自分が好きだからする選択になりました。だからうまくいかなくても一切後悔しなくなりました。例えば、あまり面白くない事務処理とかはこう考えています。「事務処理は好きじゃないからやらなくてもいい。でもやらないと会社を辞めないといけない。今面白い仕事をしている会社を辞めることと、事務処理をすることの天秤をかけると、事務処理やっとくか」と自分で選択しているという感じです。
自分の人生を自分で決めると後悔が無い
だから、自分が人生において、他人にやらされることは一切ないのです。もちろん、すぐにうまくいかないこと、失敗もありますが、そういうのがあっても、自分が「幸せ」だと思う方向性に常に舵を切る選択をつづけていくと、ちょっとずつそちらに近づきます。実際にマイクロソフトに入る前も就職失敗とかしましたけど、結果として今もとても幸せです。 たぶんマイクロソフトの今のポジションがなくなったとしても、私は幸せだと思います。幸せに対して選択していますし、幸せじゃなければ辞めるだけだからです。金や、地位やポジションの問題ではないのです。
たぶん、海外の同僚もきっとこんな考えなのではないでしょうか？だから、私は海外の同僚ともとてもよくなじみます。はなしもポジティブだし、面白いし、正直言うと日本に帰ってくると居心地悪く感じるぐらいです。
自分の人生をコントロールできるのは、自分だけで、自分が幸せになるのも自分の選択。そういう感じで、自分が「自立したもの」としてとらえていれば、他人が何を言ったかとかはどうでもいい話です。他人がわたしに「どうすべき」という話をしたところで、「何言ってんだこのハゲちゃびん。やりたいなら自分でやれよ」という感覚です。
上下関係と自分の人生
日本に帰ってくると不思議な感覚になるのは「上下関係」です。上司だから上で言うことを聞く、後輩だから下で面倒見ないといけない感は今となっては結構不思議な感覚です。人間は上下はそもそもないし、それぞれが独立した大人の人と考えると、新人も、会社にバリューをもたらす仲間です。だから私は常にフラットです。スキルの上下はもちろんありますが、それでも、自分なりのバリューを出すという契約を会社としている仲間であって、私は彼らの人生に責任を持てないし、彼らも自分の人生に責任を持ってくれません。でも、そういうものだとおもうのです。そういう人同士が、助けられることがあれば、助け合うけど、そうでなければ、自分で何とかするしかないのだから、その人次第なのです。
自分の人生を自分でコントロールしないマインドセットと生産性の問題
もちろん、これは私の体験談であり、皆さんが私のようにしなくていいと思うのですが、「自分で自分の人生や、幸せに責任をもって、自分でコントロールする」というマインドセットは生産性や、新しい技術や考え方の導入に大きく影響していると思います。
「会社で決まっているから」ということを深く考えずに制約事項にしてしまえば、いろんなものが歪んでしまいます。商習慣が違うので無理といえば、そこで、新技術の導入は終了でしょう。偉い人が「ダメ」と言ったからダメだとあきらめたら、一瞬で終わり。しかし、自分で考えて、自分でチョイスをする人が増えて行けば、その状況は変わります。
私も長年 Agile とか、 DevOps とか導入しています。相当ポジティブな人からも、「会社のルールで決まっているから難しいと思います」とか、「うちは品質重視だから無理だと思います」「あの部署の部長は絶対認めてくれないと思います」とか何度も聞いてきました。そんな時、私は必ずその人に会いに行くようにしています。
そうすると大抵のケースは、「そういう理由だったらこの承認いらないよ！効率化されていいね！」とか、「品質は重視していなくて、本当はデリバリのスピードが重要で、品質は二の次で大丈夫」と言われたり絶対無理と言われた部長が「一緒に協力して改善していきましょう」といってくれたり。
やる前から自主規制していることがほとんどだし、一回言われたダメと思い込んだりというケースがほとんどで、やりようによってはナンボでもでもやり方はあるのです。やらないとしたら、それはあなたのチョイスです。
自己組織チームと生産性
「自分で考えて意思決定する人」が増えてくると、生産性が強力にアップする方法を使えることになります。それは、「自己組織チーム」と言われるものです。チームに意思決定を任せて、彼らに考えてもらうマネジメントスタイルです。サーバントリーダーシップとも呼ばれており、最近ではこちらのほうが主流のリーダーシップの考え方です。それどころか、今はさらに先に進んだ「ホロクラシー」という考え方もあるようです。
従来の考えでは、部下にやり方を指示して、報告を受けて、その結果をもらって、承認してというスタイルです。一方サーバントリーダーシップではリーダーは、ビジョンを示して、具体的にどうするかは部下・もしくはチームが考えます。リーダーはその実行の時に部下やチームが困ったら助けて上げるというコーチングのようなスタイルです。
このスタイルは生産性的には相当強力なのです。細かく指示をしていたら、常にリーダーは忙しくなりますし、実行がリーダーの実力を超えることはありません。部下も上長の承認がなければ意思決定できなければいろいろな待ちや無駄が発生します。今はソフトウェア開発だけではなく、仕事が高度化しています。誰でも指示通りできる仕事は機械で自動化されます。だから、ツールのサポートも「考える人」の生産性を上げるようにシフトしています。「考える人」が最大の生産性を上げられるように。
自己組織チームの威力はまた別の機会にブログを書こうと思っています。
上下関係が生む導入の無駄
こういうマインドセットと、従来型のコマンドアンドコントロール型のマネジメントがまだまた主流の日本で、新技術や考え方の導入が遅れるのも納得がいきます。自己組織型チーム的な管理がされていない日本では、技術や、メソドロジーの選択の権限を持っているのは、実際にそれを使う現場の技術者ではなく、上位マネジメントの方になります。上位マネジメントの方は、普段コードにふれていませんので、妥当な選択ができるはずが ありません。商売がうまいベンダーは、本当に現場で使いやすく、生産性があがるものではなく、上位マネジメントにとって都合がいいツールを作るようになるでしょう。本当に現場でつかえるツールは、現場で運用している人だったり、現場で毎日コードを書いている人がわかることです。
ツールや方法の選定は、単純な比較や、お金ではない「手触り感、嗅覚」みたいなもんが本当に重要です。
このことはインターナショナルポジションでDevOpsエバンジェリストをしているとひしひしと感じます。例えば我々が、DevOps ハッカソンというハッカソンイベントを無料でやっているのは、DevOps のよい事例を作るために、そういったお客様とつながるためにやっています。
他の国ではこのイベントは効果絶大です。何故なら、そこにやってくるエンジニアが技術選定や、DevOpsの導入を決めるので、彼らが「いいな」と思うとすぐに「導入しよう」という話になるのです。そこに承認とか時間のかかるものはありません。 ところが、日本では、DevOps ハッカソンから事例につながったものは残念ながら今のところありません。日本ではエンジニアではなく、マネージャが決定権を持っているからです。
日本でも、「自己組織チーム」を運用してうまくいっている会社さんは本当にたくさんあります。私のかかわったアジャイル / DevOps プロジェクトはすべてそうですし、倉貫さんのソニックガーデンもそうですし、大手のKDDIさんの導入は完全に本質をついたものです。未来工業という会社さんだとずっと昔からずっとそうみたいです。だから、日本だとできないとかそういう話ではないのです。ただ、私もこの炎上で気づきましたが、こういうマインドセットがあれば、より、自己組織チームが強力に働くようになって、なおかつ、チームのメンバーも、マネージャさんも楽しく、成果があがる仕事ができるようになってくると思いました。
マインドセットを変える方向性
私はそういう背景があるので、日本の文化に合わせる方向性ではなく、マインドセットを変えて、より効果を高める選択をしました。みなさんのチョイスはみなさん次第で私がどうこういう話ではありません。ただ、別に厳しい話をしたいわけでも、全員の方にDevOpsをやっていただきたいわけではありません。
最後にこのエピソードを紹介して終わりたいと思います。
私が今回ブログが炎上したあとに、こういうコメントをしました。
牛尾： アジャイルやりたくないのならやりたくないといえばいいのにね。
私の友人はこう言いました。
友人： お前が言うか？
私はこう答えました。
牛尾： はい。「やりたくない」というのは立派な理由です。
今なら私がこう答えた意図がわかってもらえるかもしれません。私の人生は私のもの、皆さんの人生もみなさんのもの。誰も自分の人生を左右する権利などない。
ならば、自分で選択して、より幸せな方向性を目指しませんか！
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。
尚、これは所属会社の見解ではないことは明確にしておきます。
サム・グッケンハイマーの一言
私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。
ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答していた。
しかし、そんな考えを吹き飛ばすような事件が先日発生した。
サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダーだ。世界的にも著名で、多くの書籍を執筆し、世界最大のアジャイルカンファレンスでキーノートも務めた。そんな彼が de:code 2016で来日した。その時に数社の顧客訪問を実施し、私も数社のアテンドを手伝った。
私は彼といろいろ話をして大変勉強になったが、彼が帰国後送ってくれた議事録を読んで、ハンマーを頭で殴られたような衝撃的な一言があった。彼はエンタープライズ系の企業の方から「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」という顧客からの質問に対してこう答えたのだ。
「ウォータフォールは一切メリットがないので止めておきなさい」
普段彼はスーツは着ないがその彼が顧客訪問のためにスーツに身を包んでいたのに、こんなことを顧客に言い放ったのだ。その一文を読んだとき私は「ああ、本当は心の中でそう思っていたんだ、だけど、世間の目だとか、角が立つとか、炎上するのでは？とか仕事がなくなるのでは？とかそういうことを気にして自分は大人の態度とやらをとっていただけじゃないか」と気づいたのだ。つまり、本当の意見をいうことから逃げていたのだ。
自分の本当の心の中
自分の心の中ではとっくに決着がついている。大規模だと、ウォータフォールしかない、基幹系はウォータフォールだとかいろいろ意見はある。では、所属会社のことで恐縮だが、マイクロソフト以上の大企業が日本のどこにあるのだろうか？マイクロソフトは、アジャイル化を終えて、さらに DevOps ジャーニーを進めている。
マイクロソフトじゃなくても、海外の他のTech系の企業のどこにウォータフォール押しの企業があるだろうか？
海外で出版されている新しい技術系の本を見ても、アジャイル以降のノウハウがどんどんデファクトの考えになっており、それを実践したときに発生する課題について書かれている。 最近のどの本を見ても「この本ウォータフォールが前提だな」というのは見当たらなくなっている。ソーシャルコーディング等、アジャイルからさらに先の新しいパラダイムのプログラミングの習慣、文化の上に新しいノウハウが構築されている。
統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで９５％の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている。
マイクロソフトの面接での出来事
私が、マイクロソフトの面接を受けた時にも、自分の現在の２つ上の上司が面接官だった。彼は面接の最初にちょっとびっくりした声で私に聞いた
Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か？
私は正直に答えた。「そうだよ。特にエンタープライズ系で。スタートアップとか、サービス系だとそうでもないけど」
彼は相当びっくりしていた。別の機会だが、最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの！そんなの誰もやってないよ！」と本当に驚いていた。彼女は特にアジャイルや DevOps の専門家とかではない。
ウォータフォールを紐解いてみる
ここでWikipediaでウォータフォールの項目を改めて調査してみた。定義のところにこんなことが書いてある。
Waterfall model - Wikipedia, the free encyclopedia
ウォータフォール開発モデルは、製造業や建築業に起源をもっている。高度に構造化された物理的な環境特に、あとで、変更があったときに著しく高価になるもしくは不可能になる環境だ。当時、ソフトウェアのフォーマルな開発手法が存在して居なかった。このハードウェアオリエンテドなモデルが、シンプルにソフトウェアに適用されたのだった（過去形）
という説明になっている。ポジティブで公平な記述をピックアップしてもこんな感じだ。
ウォータフォールモデルが向いているのは、スコープが固定されており、プロジェクトが固定的で、確実であり、技術が 明確に理解されているものである。
今のソフトウェア開発にはとても向くとは思えない特徴になっている。私は２０年以上この業界にいるが、そんなソフトウェア 開発プロジェクトにお目にかかったことがない。
実際ウォータフォールモデルは、建築とかだと、素晴らしい成果を出しているところもある。私が昔訪問したあるお客さんが 言っていた。「私たちは８０年代に作成したWBSをいまだに現役で使うことができている。でも、ソフトウェアだけはそうはいかないんだよな。」と。
ウォータフォールは起源から異なっていた
さらにお話をすると、ウォータフォールの起源はどのようなものか？というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている。しかし、この論文を見ていただければわかるが、この時点でも、成功するためには、繰り返しや行ったり来たりが必要であり、できれば２回繰り返しなさいといったことが書かれている。現在、日本でイメージするウォータフォールは起源の時点から異なるのだ。英語が苦手な人も上記のリンクを見ていただければ絵で描いているのでご確認いただけると思う。
この後国防総省に広まったときに、なぜか「繰り返し」「戻りの線」がカットされて広まったという歴史がある。彼はとても悔しかったそうだが、その意思を受け継いで彼の子供が作ったのが、繰り返し型のRational Unified Process である。 ちなみにWikipeidaのWaterfallの項目を見ると、その後国防総省は、ウォータフォールを嫌い、イテレーティブで、インクりメンタルな方法に変更したとの記述がある。
ウォータフォールを前提とするのが本当に日本のためだろうか？
ソフトウェアの専門家だったら、こういう歴史を知っている人も多いだろう。ウォータフォールのメリットを語る人も、こういうことを知らずに言っているのではなく、日本がウォータフォール前提にいろんな制度を作っていることや、要員、メンバーの慣れ、エンプラ系のプログラマのレベル、商習慣、日本文化の不確実性の忌避などの性質を考慮して、日本でやるなら、ウォータフォールで実施することも否定できないという考えを持つのもわかる。
しかし、これらは、ソフトウェア開発の本質だろいうか？オブジェクト指向以降に生まれた技術を使ってソフトウェア開発を０から、何のしがらみもない状態から開発するとしたら、誰がウォータフォールを選択するのだろうか？そこに利点はあるのだろうか？
今、時代はDevOpsやマイクロサービスの時代に突入している。リードタイムが短縮されて、１日に１０回も１００回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が１５分で当て終わるような時代だ。
しかし、日本の特にエンタープライズはいまだウォータフォールで、数か月以上のリードタイムになっている。こんなのでどうやって海外のベンダーと対等に戦うのだろうか？ まさに、竹やりで戦闘機と戦っているようなものだ。みんな竹やりの技術を必死に磨いているうちに、海外では、戦闘機でどんどん飛行時間を伸ばして、経験を積んで新たなノウハウを獲得している。
人や人種の優秀さの問題ではないのだ。今までは内需で、飯を食えたかもしれないけど、本当にそんなのでいいとは思えない。海外の新しい方法、テクノロジーの経験を積んだ企業が乗り込んで来たら国内はむちゃくちゃになってしまう。
私は人は変えられないと思っている。変えられるのは自分だけ。だから、このチョイスは人次第だと思うし、ウォータフォールを続ける人も特にダメだか、間違っているとは思わない。
方法は二つある。自分たちの「習慣・現状」に新しい考えを合わせるのか、新しい考えに合わせて「習慣・現状」を変えるのか。私は「習慣・現状」を変える方が本質だと思う。敵と戦うときに、余計な重りを背負ってどうやって勝てるのだろう？我々の価値は顧客にバリューを届けることが勝負で、「日本の事情」は誰も考慮してくれないのは当然じゃないだろうか？だから、「重り」を減らす方がよっぽど楽じゃないだろうか？
だから、自分は、嫌われても、炎上してもいいから、ソフトウェアの専門家として、自分は現在のソフトウェア開発においてはウォータフォールは何のメリットも無いという意見であることを明確にしておきたい。
自分の恥ずかしい体験談 私はインターナショナルでは無価値である
このように思い至ったのはSamの事件以外にもいくつかの事件があった。マイクロソフトに入る前に、私は外資系、できれば海外に住むことをターゲットに仕事を探していた。その時にある会社さんがいて、私のことを気に入ってくれた英国の企業があった。
私はアジャイルコーチとして、日本でよく遭遇しそうな課題について彼らと話をした。彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか？みたいな話をしてくれた。特に先進的なIT企業ではない。一般的なユーザ企業だ。私はただ、日本のブランチはそうなってないから、そこを助けてほしいみたいな話だった。日本では価値はあるのだが、海外のポジションで働こうと思ったら、私は無価値なのだ。彼らにアドバイスできることなどない。だって、日本の支援ではそのレベルの濃いアジャイル支援の経験できないのだから。
一方、私は日本では自分で言うのもなんだが、アジャイル導入に関しては無敵といえるほどの適応力を見せていた。2003年にアジャイルをはじめて数年の自分が、ソルトレークのカンファレンスに行ったとき、私が請負契約の中でアジャイルをやるためにどんな工夫をしているか？などの話をすると、参加者の人はものすごく関心を持って聞いてくれた。日本でアジャイルの導入の時にテスト駆動開発が出来ない問題を解消するための、オブジェクトゲームという手法を、2011年にアジャイルカンファレンスで紹介したときは、米国以外の人は関心をもってもらえたが、米国の人からは「子供の教育にとてもいいね」とセッション自体はとてもほめてもらえたが、米国でのニーズのなさを感じた。つまり、私は日本で働いているから価値があるが、米国や英国に行ったら無価値なのだ。これは現時点でも自分の悩みでああるので解決するためにもがいているところだ。
私のアジャイル歴はおそらく米国の平均的なアジャイルコーチよりずっと長いだろう。では、なぜこんなことになってしまったのだろうか？それは「経験」だ。
最も深刻なことは、「経験」を積めないこと
2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった理由は、日本では「経験」を積めないからだと思う。アジャイルコーチとして、１５年ぐらいやっていても、日本ではいつまでたっても「導入」なのだ。深い知識より、日本の商習慣の中で如何にアジャイルの能力を最大限に発揮できるよう「調整」したり足りないところを「埋めたり」する能力が必要だ。アジャイルの知識や、プロダクトオーナー、リーンスタートアップ、そして技術力よりもよっぽど必要とされる。多くの人はこれに気づいていない。私は「そっち」も鍛えているから、国内では活躍できるのだ。逆にせっかくアジャイルコーチとして深い知識をもつことに注力していても、そういう「寝技」的な技術がないため、実力を発揮できない人も多く見てきた。しかし、国際的には彼らの方が「価値」があるのだ。
現在でも日本はアジャイルのコーチングといえば、基本導入部分になってくるので、アジャイルコーチも導入ばかりの経験になってくる。アジャイル(2001)->アジャイルテスティング(2009)->継続的デリバリー(2009)-> DevOps(origin 2009)に移っていったチームをずっと面倒見て経験をつめているアジャイルコーチは、一部のインハウスの人だろう。それは、アジャイル実践企業(31%)の中でも10%以下に過ぎない。スタートアップや、サービス系だと、そういう企業もあると思うが、エンタープライズ系だと今からアジャイルというのも非常に多いと思う。
simplearchitect.hatenablog.com
アジャイルコーチ以外のロールの人もそうだ。ウォータフォール文化で開発を続けている人は、技術的負債をなくすための、新しいコードの考え方や書き方、新しいチームのコラボレーションやワークスタイルを経験することができない。マネージャの人は、米国では「オールドファッション」と呼ばれるコマンドアンドコントロールと呼ばれるスタイルのマネジメントスタイルしか経験できず、モダンなサーバントリーダーシップ型のマネジメントの経験を積むことができない。Opsの人だってとっくに塩漬けになったような技術のお守りをマニュアルベースの手動で運用するのにいっぱいいっぱいで、自働化されたような最先端のモダンな、運用環境や、開発やビジネスとのコラボレーションの経験を積むことができない、企画の人も、本番から頻繁にフィードバックを受けて、企画や、戦略を洗練させていく仕事の経験を積むことができない。これこそが最も深刻な問題だと思う。なぜならこうなると差は開く一方だからだ。経験だけは、お金を払っても解決できない問題なのだ。
日本はソフトウェア開発の後進国
ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた。この差は年々広がっていると思う。経験というのは短縮できない。彼らが戦闘機の経験を積み重ねている間、竹やりの経験を積み重ねても、戦闘機に乗れるわけではない。 あるとき気づいて戦闘機に乗り始めたとしても、その操作になれるのには、やはり同じだけの経験が必要になってくるだろう。
私はインターナショナルチームに所属する経験から、日本人が彼らに劣ってるとは思わないのだ。それどころかイケてるところがいっぱいある。仕事を一生懸命やるし、イノベーティブだし、世界に勝てる要素はゴロゴロある。もったいなすぎる。
自分の素直な気持ちに従うと、なぜ明らかにソフトウェア産業で後進国となっているのに、先進国のことを学び実践しないのだろうか？
インターナショナルチームにいると、同僚がどんどん先に進んでいるのに、日本で足踏みするのは面白くなさすぎる感覚がある。
自分が目指すビジョン
私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ。そして、Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい。そのようなスピードで動いている人も既にいる。きっとできるはずだ。みんながみんなそうならないと思うけど、まずはそうなりたいと思っているお客様や仲間と一緒にそのビジョンを実現していきたい。
これは難しいことじゃない。単に「一歩」そっちの方向に足を踏み出すことだけでいいと思うのだ。数年後振り返るとそれはきっと凄い差になっていると思うから。
アジャイル・DevOps 実践企業サーベイの集計結果と考察
先日、113名もの皆さまの協力を得て、「アジャイル・DevOps 実践企業サーベイ(2016)」を実施させていただきました。その集計結果を公開したいと思います。
サーベイにバイアスが入らないように、事前に公開をしていなかったのですが、本サーベイの目的は、日本に、DevOps を導入するにあたり、その前提条件である、アジャイル開発の導入がどの程度本質的に進んでいるか？ということを調査したかったというのが発端になっています。著名なIPAのサーベイ(2013)では、５１％の企業がアジャイル導入済みになっていましたが、肌感覚的には本当かな？というのがあったので、調査してみたくなりました。
今回はサーベイの結果をフル公開いたします。私もサーベイのプロではありませんし、コメントはあくまで私の見方ですので、みなさんご自由のこのサーベイの結果をご利用ください。皆様の分析を皆様のブログに書いていただいてももちろん大歓迎です。
1. テストおよびその他の自動化の達成状況
分析結果
この項目で調査したかったのは、どの程度のプロジェクトがユニットテストのコードをちゃんと書いているかです。欧米でもユニットテストがアジャイル、DevOps の自動化に関しては最も基礎であり重要なポイントになります。ユニットテストが自動化できていなければ後続の継続的インテグレーションや、継続的デリバリも実現できません。つまり、繰り返し型開発を実施しても、回帰テストがないため、大変不安定でバグなどが多くなると思われます。
上記の実態を見てみると、アジャイル実践企業のうち、32%は手動でユニットテストを手動で実施しているという、衝撃の結果があり、48% ぐらいが実質ユニットテストが継続的インテグレーションができる程度に実施されており、11%がしっかりとしたユニットテストを書く「習慣」ができた企業であるということが読み取れます。実際、継続的インテグレーションの導入も44.2%にとどまっています。
継続的デリバリや、フィーチャーフラグ、システムテストの自働化などの高度な実践は10%程度のプロジェクトが実施している目測になります。
おすすめ事項
もし、皆さまの企業で、アジャイル開発、DevOps を実施して繰り返し型の開発をしているにも関わらず、テスト駆動開発や、継続的インテグレーションを導入していないのであれば、もしよろしければ、導入をご検討ください。お勧めとしては、テスト駆動開発の経験が長いエンジニアをあなたのチームにしばらくでもいいので雇って一緒に開発するのが最も近道だと思われます。なぜなら、テストを書くことは「習慣」なので、座学だけでは身につきにくいからです。私も下記のDevOps スターターキットに、テスト駆動開発の実施イメージをビデオにして公開していますので、どんなものかイメージがわかなければごらんください。
simplearchitect.hatenablog.com
サーベイの詳細データ
2. 企業内のプロジェクト導入の割合
分析結果
先に述べたIPAのサーベイのサーベイが正しいとすると、各企業が個人的に「野良」でアジャイル開発を導入しているのか、ある程度組織として認められて実践しているのかを知りたいと思ったのがこの項目です。48% の企業が、導入が5%以下、つまり、あまり組織的な導入でないということが読み取れます。17%の企業が、アジャイル開発実践企業サーベイであるにも関わらず「0%」であるということも驚きです。一方で16%もの企業が、70%以上のプロジェクトでアジャイル開発を導入しています。
おすすめ事項
この項目では特におすすめ事項はありませんが、草の根活動のアジャイル開発やDevOps 導入を広めたい時には、事例を作って、ビジネスKPIで証明できる成果を上げることをお勧めします。日本の場合は、ある程度権限のある人に対して、説明をして、取り組みを認めてもらうのがよいと思われます。ビジネスKPIとしては、リードタイムなどが図りやすいと思います。Value Stream Mapping などの手法を用いて、Before / After の数値を比較すると、経営層の皆さまに納得してもらいやすくなります。
サーベイの詳細データ
3. アジャイル・DevOps プロジェクト導入の課題
分析結果
課題に関しては、全体的にはアジャイル導入に関する課題が多く、DevOps に関する導入課題がまだ高くないことから、多くの企業はウォータフォールからアジャイル開発へのジャーニーの部分でいまだ苦労していることが伺えます。
数が多い内容に関して記述します。
メンバーがテスト駆動開発が出来ない課題
多くの企業でユニットテストを書く習慣が出来ておらず(54%)、TDD/BDDを実践できるメンバーが少ない(57%)という課題を持っています。
アジャイル開発のマインドセットの導入の課題
マイクロマネジメントがやめられない(42.7%) つまり、自己組織化チームができないのは、アジャイル開発の生産性を大きく阻害する要素ですが、40%以上の企業がそのような課題を持っています。
経営層への説明の問題
経営層が事前に納期、機能、コストを求める(53%) 、会社のルールが、ウォータフォール前提になっており、無駄な作業が多い(43.7%) も高いスコアになっています。これは、うまく上位マネジメント層を巻き込めていないことに起因すると思われます。
技術的負債が膨らんでおりメンテナンスできない
この問題は、米国でも頻繁にあるもので特別ではありません。が解決策に関しては次に記述いたします。
おすすめ事項
テストに関する対策はすでに最初の対策で記述いたしましたので割愛します。経営層の巻き込みに関しては、経営層のわかりやすい言葉と数字で説明する必要があります。またそもそも彼らを「巻き込もう」という意思が必要です。 そのためには、Value Stream Mapping 等のビジネスKPIを明確に出せて、尚且つ本質的な改善につながるものを実施し、定期的に経営層に報告ポイントを設けることを事前合意しておくなどが効果があります。 また、技術的負債に関してはこれも実は「テストを書く習慣」にかかわってきます。しかし、すでに負債となっているものがある場合は、コードレビューなどの静的解析ツールを導入して、技術的負債を見える化するところから始めるのをおすすめします。自動のユニットテスト、そして、リファクタリングという設計変更のテクニックをチームがマスタしているとよりこのアクティビティは進みやすくなります。また、マイクロサービスの考えをつかって、少しづつ、分離できるサービスからマイクロサービスにしていくと、コードベースが小さくなるかもしれません。また、技術的負債はあきらめて、REST-APIの向こう側として扱って、インターフェイスのみ自動テストをできるようにする（せめてスモークテストでも）という手もあります。 いづれにしても難しい問題なので、ケースバイケースです。
一方、「マイクロマネージメントがやめられない」という問題は、サーバントリーダーシップや、自己組織化チームについて学ぶとよいと思います。下記にリソースを提示しておきます。下記のブログを見ると、サーバントリーダーシップや、自己組織化チームの具体例について学ぶことができるかもしれません。一つだけ言えるのは、マネジメントの経験が不要になるわけではありません。ただ、今後この新しいマネジメントスタイルを学ぶとグローバルの市場でも最後にご紹介しているサーベイの結果からも、圧倒的に有利になることは間違いないでしょう。
simplearchitect.hatenablog.com
サーベィの詳細データ
4. 所属企業の属性
この項目は、どのような属性の企業がこのサーベィに答えているか？の分析ですが、結構妥当な割合といえます。（肌感覚でしかありませんが、、、）
サーベイの詳細データ
世界の動向と日本の他のサーベイ
日本の他のサーベイでは、PMIのサーベイ(2015)（日本）では、31%の企業がアジャイル導入済みというデータがあります。先に紹介したIPAのサーベイ(2013)では51%になっています。
世界のサーベイでは、Version One の年次サーベイ(2015)では何と95%もの企業が既にアジャイル開発を導入済みになっており、世界のデファクトになっていることがうかがえます。
余談ですが、著名なSam Guckenheimer が客先訪問をしているときに「アジャイルとウォータフォールの使い分け」について質問された際、「ウォータフォールにメリットはないので、やめておいたほうが良い」とコメントしたことだけは共有しておきます。バージョンワンの世界サーベイの95%の企業がアジャイルを導入済みという数値を見てもそれは裏付けられている言っていいのかもしれません。
一方、日本のアジャイル導入の難易度は世界一高い言っても過言ではありません。
here's the chart. Fun to look at.
— Alistair Cockburn (@TotherAlistair) May 14, 2016
Scandinavia rocks.
India came out surprisingly high.@arne_mertz @RonJeffries pic.twitter.com/NVqDnCGQns
これは、Twitter でアジャイルの父として世界的に著名なアリスターコバーン氏がアジャイル導入の文化的導入難度に関して算出したものです。元のデータはアカデミックなデータに基づいています。
世界がすべて優れているわけではありませんが、少なくとも DevOps の導入に関してはデータ上もリードタイムの削減が1/200等の劇的な削減のデータが出ています。DevOps はツールを導入するだけでは達成できず、アジャイル開発を既に導入済みであることは前提条件になっています。
このデータを見てみなさんがどう感じるかは皆さんにお任せいたします。
DevOps スタータキットの公開
DevOps の概要、プラクティス、そしてそれに関するリソースを整理して自ら学習しやすいようにしてみました。DevOps の考え方、プラクティス毎に、ビデオとそこで使っているPPTを公開しますのでお楽しみください。
1. DevOps の歴史
DevOps を学ぶときに、海外と比べると日本の商習慣が異なるので、向こうで話されているDevOps の概要を聞いてもピンと来ないかもしれません。そこで、DevOps の歴史を7分程度で学べる動画を作成しました。 これで、DevOps が生まれきた背景が学べると思います。
2. DevOps の概要
DevOps の歴史を知るとと、DevOps の概要がよりわかりやすいかもしれません。次のビデオをご覧ください。
DevOps プラクティス
ビデオで解説されているとおり、マイクロソフトが定義している 主要な DevOps プラクティスを学べるようなコンテンツを作成 してみました。
3. Infrastructure as Code
インフラストラクチャをコード化するInfrastructure as Code の解説とデモです。
Infrastructure as Code の技術はたくさんありますが、いくつかご紹介していきたいと思います。
3.1. Azure Resource Manager
ビデオでもご紹介している Azureを使っている人には便利なツールで、Visual Studio を使うと相当楽にコードが書けます。 それだけではなく、実態はJson なので、普通のテキストエディタでもコーディング可能です。
私のお好みはエバンジェリスト仲間の安納さんのチュートリアルです。ゼロから作っていくのでコンセプトなどがわかりやすいです。
ちなみに、自分でAzure Resource Managerのテンプレートを公開することも可能です。これは、HashiCorpのNomadを好きな 台数だけプロビジョンできるテンプレートになっています。このコードは公開していますので、イメージがわきやすいかもしれません。
GitHubに Azure Resource Template がアップロードされています。これは、Azure で実際に使わているテンプレート ですので、書き方に困ったときに参考になります。
3.2. Terraform
HashiCorpの Terraform も最近お気に入りのツールの一つです。Go言語で書かれているため、Windows でも、Macでも、 Linux でも機嫌よく動作します。私が、de:code 2016 のキーノートで Jenkins 2.0 から、Terraform を自動実行して 実際にサーバーをプロビジョニングしました。
Terraform バーチャルマシンを ARM対応の Terraform を使ってプロビジョンしてみる
3.3. Chef
ARM や、Terraform は、VMや、ネットワークを作成するのは得意なのですが、その中身（ミドルウェアのインストール） などはそんなに得意ではありません。その時に使うと便利なツールがChef です。Linux 系でも、Windows 系でも動作 します。
Chef のチュートリアルシリーズは大変わかりやすく、Linux, Windows どちらでも実行可能です。英語ですが、チュートリアル なので、手順をおってやればイメージは相当わきやすいと思います。
他にも Ansible や、Itamae 等様々なツールが存在します。
3.4. PowerShell DSC / PowerShell
PowerShell を作ったJeffrey Snover自らが解説するシリーズでがっつり学べます Getting Started with PowerShell 3.0 Jump Start Getting Started with PowerShell Desired State Configuration (DSC)
日本語で学びたい人はここにがっつりとした安納さんの資料が！ 【ハンズオン】PowerShell で Hyper-V を構築・管理
3.5. xPlat / Azure PowerShell
Azure SDK を使うと、クライアントの生成なども可能になります。様々な言語がサポートされています。Azure SDKを使うと、 生の挙動が確認できるので、感覚をつかみやすいので触ってみるのをお勧めします。
https://azure.microsoft.com/ja-jp/downloads/ https://azure.microsoft.com/ja-jp/documentation/articles/powershell-install-configure/
3.4. Packer
Packer は、HashiCorpが作ったツールで、ゴールデンイメージを作るときに、Infrastructure as Code ができるツールです。 ゴールデンイメージも手作りをしていると、バージョンアップの時に面倒なことになりますが、Packer だとコード化されているので、 安定した運用が可能になります。
3.5. Docker
コンテナ技術のデファクトといえる Docker は今後の基礎知識になりそうです。最高の日本語サイトは、クリエーションラインの 前佛さんの作成したここですね。
David Tesar が私に話してくれたConfiguration as Code の話はこちらのエントリからご覧ください。
4. テストの自動化
自動化するテストと、その種類について解説しています。
5. 継続的インテグレーション
継続的インテグレーションの解説とデモです。
HOL - Parts Unlimited MRP App Continuous Integration with Visual Studio Online Build
6. リリースマネジメント と継続的デプロイメント
リリースや、デプロイの自動化の解説とデモです。Visual Studio Team Services
Visual Studio Team Services の日本語情報は武田さんが書かれたチュートリアルがよいと思います。
https://docs.com/takeda-masaki-1/1805/visual-studio-2015-team-foundation-server-2015
7. アプリケーションパフォーマンスモニタリング / マネジメント
アプリケーションパフォーマンスモニタリングです。具体的な例として、Application Insightという ツールを使っています。
8. テスト駆動開発
テスト駆動開発は、アジャイルや、DevOps を導入するときに Infrastructure as Code と同じぐらい 重要な開発の「習慣」です。このビデオを見て、雰囲気をつかんでください。
これで雰囲気をつかんだら、下記の本は原本なので、それでチュートリアルをやると良いでしょう。 また、リファクタリングはとても重要で、コードが汚いなと思ったときに、このパターンでリファクタリングすると どんどんきれいなコードの書き方が身についてきます。
テスト駆動開発入門 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
8.1. テスト駆動開発が難しい場合は
テスト駆動開発が難しい場合は、OOP(Object Oriented Programming) が十分できていないケースがあります。その場合は、「オブジェクトゲーム」という手法をもちいると、 OOPの基本とアーキテクチャが半日程度で理解できるようになります。オブジェクトゲームの、プレゼン、カード、ソースを置いておきました。
9. Advanced DevOps プラクティス
上級の DevOps に関するご紹介です。
10. Git の基本操作
Ops の方が初めてGitに触れるときは戸惑いを感じるようです。私も最初はとても訳が分かりませんでしたが、 なれると手放せなくなってきます。このビデオでは、Gitの最低限の基本操作のみを解説しています。
11. アジャイルの導入
DevOps を始める前に アジャイルの考えがまだ理解できていない場合は、下記のプレゼンテーションが役に立つかもしれません。
プロダクトオーナーの技術に関してはこれ
12. DevOps の事例
以上です
DevOps で成功するための７つの習慣 ～ Microsoft が SaaS 運営で学んだこと ～
Microsoft の DevOps 実践の第一人者の Sam Guckenheimer が長年の経験をもとに、DevOps をうまく実践するための７つの習慣をまとめてくれました。その内容を原文と共に共有したいと思います。
７つの習慣は特に DevOps のマインドセットを学びたい人にはとてもいいまとめになっています。「リードタイムの短縮」以上の Advanced DevOps を学びたい人にもお勧めです！簡単に翻訳してみましたが翻訳や、解釈の間違いがありましたら是非コメントをお願いいたします。
1. Production First Mindset （本番を第一に考える)
Production is the heart of any software delivery organization, and the best ones recognize that the real production should be top priority for every team member in every role, not just IT operations. Intermediate artifacts like documents and disconnected pre-prod environments are not enough. High performers always track the live site status, remediate any live site issues at root cause, and proactively identify any outliers in performance to see why they are experiencing slowdowns.
本何環境は、ソフトウェアを作成する組織の心臓部です。すべての役割の人(Dev, Ops, PO, Manager...)にとって、最もプライオリティが高いものであるべきです。ITPro (インフラ/運用技術者)にとってだけ優先順位が高いわけではありません。ドキュメントや、プロダクション以前の環境の成果物では十分ではありません。ハイパフォーマーは常にライブステータスをトラッキングし、根本原因の特定や、問題が発生する前にパフォーマンスが悪化している人がなぜそんな目にあっているのかを理解することで、ライブサイトの問題を軽減するようにしていいます。
2. Backlog Groomed with Learning (学びから Backlog をブラッシュアップする)
The Backlog is the stack of work to be done. Different organizations plan, define and manage requirements and projects differently. This can include how you engage with stakeholders and how you request, capture, and track work. It can also include how well you align, agree, and make decisions. High performers treat the backlog as a set of hypotheses, which we need to turn into experiments, and for which they need to collect data that supports or diminishes the hypotheses. Based on that evidence they can determine the next move in the backlog and persevere (do more) or pivot (do something different).
バックログは、すべき仕事が積まれたものです。組織の計画と異なり、要求とプロジェクトでの違いについて定義して管理します。 このことは、どのようにあなたが、リクエストしたか、とらえたか、そして、トラッキングしたか、さらに利害関係者を巻き込むかも含まれています。また、あなたが、どのように整合性をとって合意して、意思決定するかも含まれます。ハイパフォーマーは、バックログを、「仮説」の集合としてとらえます。ですので、我々は、仮説を検証するために、「実験」して、「仮説」を 検証する、もしくは、それが外れていることを証明するデータを集める必要があります。エビデンスに基づいて、バックログのなかで、次にどうするか、そのままの考えですすめるのか、それともピボット（何か違うことをすること）するのかを決定していきます。
3. Evidence Gathered in Production (エビデンスを本番で集める)
Good decisions are informed by data. High performers instrument everything, not just for health, availability, performance, and other qualities of service, but to understand usage and to collect evidence relative to the backlog hypotheses. For example, they will experiment with changes to user experience and measure the impact on conversion rates in the funnel. They will contrast usage data among cohorts, such as weekday and weekend users, to hypothesize ways of improving the experience for each.
良い意思決定は、データによってもたらされます。ハイパフォーマーはすべてを収集します。ヘルスチェックや、可用性、パフォーマンスそして、他のサービスの品質属性だけではありません。 ユーザの利用状況や、バックログの仮説検証を支えるためのデータをも取得します。例えば、あるチームが、ユーザエクスペリエンスの変更を実験していたとしますそして、フューネルの コンバージョン率へのインパクトを測定していたとします。彼らはきっとコホート分析の利用率のデータを比較します。週中、週末の利用率です。ユーザエクスペリエンスを改善するためにの、 か改善仮説の検証のためです。
4. Flow of Customer value (顧客価値のフロー)
Flow refers to an organization’s ability to move software swiftly from initial idea through creation and validation into a production release, without impediments or rework loops. Reduced rework allows teams to focus on delivering more net-new value. Shorter cycle times support increased responsiveness, in turn fostering stakeholder satisfaction and trust.
フローは、ある組織が、ソフトウェアを、最初にアイデアを思いついてから、ものづくりをして、検証して、本番にリリースするのをいかに早くできるかの能力です。もちろん、障害や作業の やり直しをすることなくです。再作業を少なくすることで、チームは新しい資産価値を生み出すことに集中することができます。短いサイクルタイムは、市場への反応性をあげます、 それにより、株主の満足と信用を得ることができます。
5. Team Autonomy and Enterprise Alignment (チームの自立性とエンタープライズへの適合)
The goal for modern application delivery is responsiveness, which relies on flexible scheduling, limiting long-term commitments in favor of iterative experiments, and close team collaboration to facilitate real-time communication and eliminate wasteful handoffs. High performers have multidisciplinary feature crews who pull from a common product-backlog, minimize work in process, and deliver work ready to deploy live at the end of each sprint.
モダンなアプリケーションデリバリのゴールは、「反応性」です。それは次の要素に依存しています。柔軟なスケジュール、繰り返し型開発により長い期間のコミットメントを制限すること、密接なチームのコラボレーション 、リアルタイムなコミュニケーションそして、無駄な「ハンズオフ（成果物を他の人に引き渡すこと）」を削減することです。ハイパフォーマーは、様々なスキルをもった人があつまった、(権限をもち自立した)バックログを実行するフィーチャーチームのメンバ が、仕掛仕事を最小化し、毎スプリントの終わりに、本番にデプロイできる成果を作り出します。
6. Managing Technical Debt (技術的負債を管理する）
The Technical Debt category considers behaviors for strategically managing the impact of short-term and long-term technical decisions.
技術的負債は、短期、長期のインパクトを鑑みて、戦略的に技術的決定を実施していくことを管理するふるまいのことです。
7. Managin infrastructure as a Flexible Resource (インフラを柔軟なリソースとして管理する)
The best performers use the flexible infrastructure of the public cloud and continually improve their architecture to refactor into more independent, discrete services. Using the cloud provides scale on demand and makes it easy to stand up services for continuous feedback from constant usage.
最高のパフォーマンスを出すチームは、パブリッククラウドの柔軟なインフラを使って、継続的にアーキテクチャを改善し、より独立性が高く、分離されたサービスにリファクタリングします。 クラウドは、コンスタントな利用状況からの継続的フィードバック基づいて、需要に合わせてスケールするようなことが簡単になります。
おわりに
最後に、Sam Guckenheimer の印象的な一言でこのポストを締めたいと思います。
There's no place like production!
本番環境などという場所はない。
本番環境は今までのような慎重に慎重を重ねてデプロイする「聖域」ではなく、「学びを得る」場所なのです。
Sam は de:code 2016にも来てくれたのでお楽しみに！
simplearchitect.hatenablog.com
参考
DevOps Chat: 7 habits of successful DevOps 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
日本でインターナショナルチーム文化を作る方法を考えてみる
今まで、幾つかのポストで書いてきたのですが、私は今のインターナショナルチームのポジションをとても気に入っています。楽しく、気に入ってるだけではなく、実際の生産性やワークライフバランスも過去最高です。
私は、「Be lazy」の回で書いた通り、「Be Lazy」を極めるために、「エッセンシャル思考」を実践しています。日本Microsoftは相当素晴らしい会社ですが、それでも、正直いうと、日本で「エッセンシャル思考」を実践すると、若干肩身が狭い思いをします。かといってこの人体実験をやめるつもりはありません。私の職業上の次のゴールは、「世界のどこでもご飯を食べられる様になること」だからです。
simplearchitect.hatenablog.com
一方、「Be Lazy」の考えを、チーム丸ごと受け入れてくれて実践しているお客様がいます。そうか、チーム丸ごとその考えを受け入れるならば、問題なくなるのかもしれない！
そう考えて、日本で、インターナショナル文化を実践する方法を考えてみました。なぜこのインターナショナルチーム文化が、快適なのか、どうしたらインストールできるのか？
私が考えた結果、今の所の仮説ですが、Microsoftの考えを受けて、私のチームのマネージャである「Damien」がこの素晴らしい文化を作ったのではないかと思っています。つまり、日本とかインターナショナルとか関係なく、「Damien」がやってくれたことを再現すれば同じ文化ができないだろうか？という思考実験です。
試したことはないので、効能はお約束できませんが、彼が私たちにやってくれたことを整理してみたいと思います。あなたがマネージャならこのようなチームを作ることができるかもしれません。
上下感覚がないチーム作り
実はDamienは私より年下です。しかし、そんなことは誰も気にしません。私のチームメートは大抵私よりずっと下だと思います。しかし、それも誰も気にしません。上も、下も気にしないのです。年齢だけではなくスキル、経験、それで、上だとか、下だとか誰も考えていないと思います。Damienの上司にあたる、Volkerも同じです。私が話すときも、偉い人と話しているという感じではなく全くの対等です。
きっと、サティアと喋ることになっても緊張もせず、「Hi」って言っちゃうと思います。しかし、日本にいると、偉い人に喋りかけてもいいんだろうか？とか考えている自分に気づきました。
どんな人でも、新人であっても、ベテランでも、社長でも、同じ仕事をする仲間です。やってることが違うだけで上とか下とかなく、上の人が下の人をコントロールするという感覚自体がありません。仕事は、Bossであっても、私たちに仕事を依頼するときは「お願い」モードです。例えそれが決まっている「月次週報」であっても。偉そうな人は見たことがありません。他の人に「教えてやる」とかそういうものもありません。全ての仕事がプル型です。誰か困った人がいたら主体的に助けを求めて、他の人が助ける。それだけです。
ボスの言うことが絶対というイメージもありません。ディスカッションもみんなで意見を遠慮なく言い合いますが一度もバトル的になったことはありません。ボスに決定権はありますが、それを振りかざす人はいません。
サーバントリーダーシップ
ボスが仕事を割り振って、「このよのような仕事をやり方をしなさい」と細かく指示していくやり方をマイクロマネージメントと言います。最近ではサーバントリーダーシップという、ボスが細かく指示をしていくというよりも、メンバーが与えられたミッションに対して、やり方を考える。それをボスがサポートしていくというリーダーシップの形態になっていると思われます。
Damienも本当にその通りです。チームとしてのゴールやミッションの共有はしっかりしてくれます。それは数値で書かれていて無理がなく、明確です。
そして私のゴール設定もかなり親身にやってくれます。私がそのゴールを達成するためにいろいろ困って彼に相談したらいろいろアドバイスをくれます。が、彼が私に「あれしろ、これしろ」と細かく指示することはありません。私の仕事の遂行を助けてくれるサポーターという面持ちです。また、彼は私に何かのデッドラインが近づくと、リマインドをしてくれたりします。彼は、誰かを見習えとかそんなしょーもないことも言いません。だから、全てのメンバーがそれぞれの個性を発揮して、それぞれイキイキいい仕事をしています。
またその上のVolkerも同じなのですが、自分が判断に困ったら、素直にチームに聞いてきます。チームでそこに知見がある人や意見を持っている人が彼らにアドバイスします。
だからと言ってチームメンバーは誰れも彼らのことを「頼りない」とは思っていない様子で、「素晴らしいマネジメントだ」と思っています。少なくとも私はそうだし、チームメンバーも彼らの悪口を言っているのを聞いたことがありません。
One on One ミーティング
Damien、そして、私の日本側のサポーターである Drew は One one One ミーティングを毎週30分やってくれます。私に共有したいことや、やってみたいことの相談、悩み事がなければすっと終わりますが、あれば、いろいろアドバイスをしてくれたり、助けてくれたりします。また、私が日本での、DevOps エバンジェリストに就任したときに、DevOps ハッカソンを実施しに、Davidと一緒に来てくれて、直接日本に来て過ごしてくれました。彼は他の国にも同じように行っているようです。そして、彼はみんなに「指示」をしたり、「いうことを聞かせよう」とする代わりに、メンバーを「理解」して「助けよう」としてくれるのです。
「Be Lazy」を推奨する空気作り
Damien そして、Drew、Volker、もちろん他のチームメートも同じですが、「Be Lazy」つまり、より少ない工数で、多くのバリューを出す考え方、たくさんの物量をするのではなく、「減らして、インパクトのあるものに集中する」考え方を良しとしています。だから、逆に残業とか休出とかをしていると、渋い顔をして「休暇をとろう。」と心の底から言ってくれます。楽にいい成果を達成することを発見したらみんなが喜んでくれます！「うまくやったな！今日はもうPubにでもにいこうぜ！」って。だれも「定時まではいないといけない」とか言い出しません。
simplearchitect.hatenablog.com
休暇を尊重する
休暇を尊重される空気も素晴らしいです。日本だと、仕事が終わっていないと休暇中でも「終わってないのだから仕事しなあかんやろ」とプレッシャーが来ることは珍しくありません。休暇をとりたかったら、それまでに終わらせておくことが求められます。 インターナショナルチームでは、休暇をとるということは本当に尊重されます。仕事が途中だから、と誰れも責められることはありません。
この前の話をしておきます。私はある記事を書きました。英語だったので、ネイティブのメンバーにレビューをお願いしました。レビューをしてくれる人が、私にコメントを求めてきたのですが、その翌日休暇で、他の仕事でいっぱいだったこともあり、コメントを返しませんでした。
休暇が開けた当日、その人のボスが私に「コメントを今日中にお願いします。」と珍しく催促してきました。流石にせっかくフォローしてあげているのに、全然レスポンスがこないし、ムッとしたのかもしれません。
私は「大変レスポンスが遅くなって申し訳ない。ここ直近休暇だったのです。今日やります。」と返しました。すると、「ありがとう。おお、そうやったんか。君が素敵な休日を楽しんだことを願ってるよ！」と帰ってきました。休暇の間に途中だからと言って、何かが求められることはまずありません。
（余程の大事件でもない限り、、、今まであったことはありませんが）
自分もそうですが、相手が休暇だったら、「あー休暇だったら仕方ないよね」と諦めます。社外の人であってもそのノリです。自分だってせっかく休暇しているのに、メールがバンバンやってきて対応に追われたら何しに来ているのか分からなくなります。休暇は貴重なものという認識のようです。
でも、チームでそういうことが推奨されていなかったらこのムードは作りにくいと思うので、チーム単位で作っていくといいかもしれませんね。
ダイバーシティの学習
前回の記事でもダイバーシティを取り上げましたが、Damien は２３カ国のメンバーをマネジメントしたことがあり、尚且つ、彼は２５カ国以上の文化や、商習慣を学んでいるらしいです。彼はそういうダイバーシティや相違を理解するべく努力をし、さらに、先に書いた通り実際に会いに行ったり一緒に仕事をして、チームを作っています。
simplearchitect.hatenablog.com
テクニカルエクセレンス
日本でマネージャというと、あまり技術ができない感じですが、彼は例えばChefのレシピは余裕でかけますし、ハックフェストも余裕でサポートします。彼に聞いてみました。「君は私よりずっと忙しいとおもうんやけど、どうやって技術をキープしているの？」彼は言いました。
「毎週金曜のPMは時間をブロックしてハックしているんだよ。」同じようにその上のVolkerも、DevOpsの技術やプロセスの話をしても通じなかったとか、話がわからないとかはありません。日本ではたまに「お前がしたかったら、俺に理解させてみろ」とか昔言われたこともありますが、そういうことはありません。DockerConに行ったときも、メールで懇親会の場所が送られてきたのですが彼がGitHubにアップロードした、Dockerfile を使って、Docker コンテナをデプロイしたら、懇親会の場所がわかるという仕掛けを作っていました。 :)
ただ、自分の知らないことに関しては素直に「知らないので教えてくれないか？」と言います。
ハッカソンを支援するDamien
「楽しんでいるか？」を確認する
Damienが私と One on One をするときに必ず聞いてくることは、「Tsuyoshi よ、仕事をエンジョイしているか？」彼は毎回そう聞いてきます。私の答えが No だったら、エンジョイできるようにいろいろ助けてくれます。
だから、うちのチームは、「仕事つまんねー」とか「なっとくいかねー」と言っているメンバーを見たことがありません。最初は気にしていませんでしたが、チームメンバーが「エンジョイしているか？」を確認するのはすごく生産性に貢献しているのかもしれません。
そして、そうすることで、仕事が「エンジョイしてなんぼ」なものとしてのムードを作ってくれているのかもしれません。 日本では仕事は「我慢してなんぼ」みたいなムードがありますが、誰だって、楽しく、エンジョイ出来ている方が、よりパワーを発揮できるのではないでしょうか？多分「我慢してなんぼ」の流れは、ボスが、他のメンバーを「指示してコントロール」していた頃の名残で、メンバーがゴールを与えられてそれをメンバーが個性を発揮して実施し、ボスがその達成を助けるというマネジメントスタイルでは、他の人に「いうことを聞かせる必要がない」ので、必要ないし、そもそも、エンジョイ出来ている方が少なくとも私は楽しいし、生産的な感じがしています。
おわりに
Damien は、私にとって今まで遭遇した中で最高のマネージャです。彼は自分の夢を語っていました。「私はいつかこのチームが世界で もっとも素晴らしいワークプレースだと言われるようにしたいんだ」私はこう答えました。
「少なくとも私にとっていまでもそうやで。Damien君はいままで出会った中で最高のマネージャだよ」
これは私が心のそこから思っている言葉です。私の視点でしかない記事ですが、少しでもなんらかのお役に立てれば嬉しく思います。
ダイバーシティの本質はそういうことじゃないんじゃないかな
いつも通り、生産性に関するブログを書こうと思ったのですが、その過程で、ダイバーシティについて少し調査しようと ブログや本をチェックして、とても違和感を感じました。そこで自分の意見を整理するために、ブログを書いてみました。
私は単にインターナショナルチームのメンバーであるだけで、専門家でもなんでもないので、稚拙で誤った意見かもしれませんが、それでも何か書いておくと自分の整理と学び（プロセスの改善のプロフェッショナルとして）になるかと思い筆をとってみました。
自分の感じるダイバーシティの違和感
私はインターナショナルチームで働いています。そして実際にその環境で働いていると、本当に楽しく快適に働けています。だから、その環境の素晴らしさと、その環境を日本でも実現する方法を考察するために、インターネットを調査してみました。
Microsoftはダイバーシティに非常に力をいれているので、必須教育でもダイバーシティの説明があったのですが、それは非常にためになる内容でとても楽しめました。
ところが、Amazonの日本語書籍 や、インターネットの日本語サイトを見ていると、ダイバーシティというと、女性の権利がどうこうとか、マイノリティや外国人の受け入れのために云々という言葉が並んでいます。そこに凄く違和感を感じました。
自分が何故、違和感を感じるかを考えてみると、「自分たちはマジョリティだけど、マイノリティを受け入れて、より生産性をあげよう」というノリを感じるからということに気づきました。
マジョリティ / マイノリティなど存在しない。
インターナショナルチームで働いたり、そうでなくても、例えば、ロンドンに語学留学をしてみるとわかりますが、インターナショナルな環境だと、マジョリティなどないし、常識などないのです。日本人は、開始時間に厳しいですが、国によっては、「遅刻しないと失礼。時間どうりのほうが失礼」という国もあります。
我々はいろんなものに知らず知らず「常識」をもっていて、勝手な価値観で「これぐらいは人として当然」思っています。これはある意味仕方がない事ですが、「すべての事が多様で違いがある事が当然」と考えることが重要だと思います。すべての人が、世界のコミュニティの「一部」にすぎず、マジョリティなどいません。
それは国籍の違い、人種、性別の違いだけではありません。人間は、すべての要素が違っていて当然という前提で考える事がダイバーシティのポイントじゃないでしょうか？
マイノリティの告白 ADHDである人生を生きる事
自分にとって、ダイバーシティが当然のごとく受け入れられているインターナショナルチームの環境は本当に楽しいです。何故かというと、どんな人でも受け入れられて、「自分以外の何か」になる事を要求されないからです。
私は、日本に帰ってくると「マイノリティ」です。私は医師にも診断された注意欠陥症候群(ADHD)という特性を持っています。 原因は不明ですが、現在では前頭葉が不活性で、短期記憶が少ないため、集中力が続かなかったり、自分に興味がないことが一切できないため、記憶力が乏しく、例えば銀行振込、事務処理、片付け、調整作業などが大変苦手です。また、集中力がないため、何をやっても、完成しません。だから自尊心はズタズタで、自分はなんてダメなんだろうといつも思っていました。
人の心をおもんばかることも苦手です。なぜなら作業がいつもバタバタで、そんな余裕がないからです。それがさらに自分の自尊心をズタズタにしてきました。
日本だと普通の人は「大人ならそれぐらいできて当然」と思われることが、全然できません。実際にやろうとすると人の３倍ぐらいかかるし、できても普通の人より雑だったりします。そういう人は日本の社会では、「いいかげんで、だらしない人」というクラスターになるので、社会生活が非常に辛いものになります。
だから、私は「作業」を「完成」させないといけない２０代は全く活躍できず、「思考力」や「発想力」が重要になってくる３０代以降はなんとか仕事ができるようになりました。しかし、最終的に自分で会社をやっていたのは、会社で「社会人としてこうなるべき」というストレスに耐えられなかったのかもしれません。
リタリンを服用した時の衝撃
私の転機はあるインターネットの記事で、「自分がADHDである」という事がわかったことです。
実際に専門医師の元に行き、診断を受けて、リタリンという処方された薬を飲んだ時の衝撃は今でも忘れられません。部屋や机が生まれてから片付いた事がありませんでしたが、薬を飲んだら、なんと、自分が知らず知らずに片付けているのです。机の線に、置いているものの線がずれていると気になりました。
ヴォーカルをやっていましたが、今までできなかったコーラスを耳コピするのも一瞬でできました。
「ああ、これが、普通のいや、集中力がある人の気持ちなのだな」と思いました。こういう人からすると、私は相当いい加減にしかみえないでしょう。「なんで、こんな簡単な事ができないんだ？やる気がないからだろう」と。
しかし、同時にこうも思いました。薬を飲む程のことで、こんなに違うんだ。「自分がいい加減なのでもなく、ダメなわけでもないんだ。」この事がわかってから、自分ができない事を諦める事を覚えました。だから自分への罪悪感みたいなものも少なくなりました。私は多分生来的にポジティブな性格だったと思うのですが、自分自身を傷つけてきたため、当時はネガティブな性格でしたが、今は相当ポジティブだと思います。:)
しかも、ADHDには先に書いた様なマイナスがありますが、人が見つけにくい関連を発見しやすかったり、発想力があるといういい特徴もあるようです。
しかし、日本の社会で、生きていると、そういったいわゆる「大人の行動」をする必要があるので、様々な手法で、ADHDの症状を軽減するために 努力してきました。リタリンの効きは最高でしたが、薬なので徐々に効きが悪くなってきました。
ところが、「整理力がある状態」というのを「認識」できたので、それだけでも以前と相当違う感じになってきました。 その後、私が有効だった方法を共有しておくと、Lumosity という脳トレのようなゲームで、短期記憶を徹底的に鍛えるようにする と、ゲームを継続してやっているとかなり症状が軽減できました。
最近知ったのですが、「オメガ３」のサプリメントを飲むと、私のような短期記憶に問題のある人には非常に有効なようで、 かなり作業ができるようになってきました。それはワーキングメモリという参考文献に乗っていたのでそれをそのままやってみました。他にもランニングなども効果がある様です。
Lumosity (ルモシティ) - 脳トレ｜あなたの脳の可能性を見つけましょう - Lumosity
脱線しましたが、正直にお話すると、私は日本社会で常に生きづらさを感じていたのです。そして、日本社会で生きて行く限り、上記のような 「自分が自分以外になる」という行動が求められるのです。
インターナショナルチームは居心地が最高
久しぶりに「会社勤め」を始めた先は、Microsoftのインターナショナルチーム。英語での仕事は生まれて初めてでした。 相当ストレスフルなはずですが、私自身は、非常に居心地が良いと感じていました。
自分が苦手なはずの事務処理系の仕事ですが、チームでも平均すると私の方がちゃんとできるぐらいの勢いです。みんなが得意なことも苦手なこともバラバラです。会議に真面目に出る人もいればほぼでない人もいます。それでも誰れも何もいいませんし、減点される雰囲気もありません。
私がいろいろ忘れて何回か同じ事を上司のDamienに聞いても、彼は喜んで教えてくれます。
ネイティブの英語スピーカーと喋るときも、私や同僚が理解できてなくても、英語勉強不足とか言い出す人はいません。言葉が通じないのが前提なので色んな手を使って「コミュニケーション」を達成しようと、こちらも、向こうも頑張るからです。
日本では「ダメ人間」の烙印のADHDも、文化も、年齢も、国も、考え方も、得意分野もすべて違う人が集まってるのが前提なのでそれが「違う」とすら 認識しません。だから、「君はこうあるべき」「君はこうすべき」などと言われた事がありません。
例えば、Drew に対して DevOps インタビューという記事を英語で書くのが大変な時に相談したら、彼は英語力を上げるアドバイスをするのではなく、「お金を払って誰かにやってもらえるように調整しよう」といったアドバイスをくれました。
他の人も同じですが「自分を変える、鍛えて違うものになる」ことをアドバイスされることがありません。仕事も、ごく少ない仕事以外は、できなければやらなくてよくて、それをだれもととやかくいいません。早く帰っても誰れもなにもいいません。
いい仕事ができてみんなにシェアしたら、みんな「おめでとう！」って褒めてくれます。そして、他の人がうまくいったら自分もうれしくなって「おめでとう！」といいます。仕事をしていても、基本KPIで定められた仕事を達成する方法を自分で考えるので、他の人から頼まれることは、基本「すべきこと」ではなくて、「助けてあげている」ということになります。だから断っても誰れもそれでとやかく言われることもありませんし、助けてあげたら、とても喜んでくれます。
ここで自分は生まれて初めて、「自分が受け入れてもらえている」感を受けました。
イギリスで友達の家に泊まった時の事
先日休暇で久々にイギリスに行ってきました。そこで友達の家に泊めてもらったのですが、その友達の彼氏のお宅でした。友達に私のADHDの事を話すと、友達は「あーわたしもそうかもしれない」といいました。彼氏がやってきて、そのことをシェアすると彼は
「ADHDってもっと凄いよ。君たちは全然ちゃうから」
あー、そうか、自分は日本ではそうだけど、（ダイバーシティが当然な）イギリスだと、ADHDですらないのか、、、と実感しました。日本では息苦しいかもしれないけど、世界にでたら、自分の「差異」なんてないに等しいんだなと。
ダイバーシティが産む生産性
ちょっと横道にそれましたが、ダイバーシティのある環境では、「人と、人はすべての面において違っていて当然」人とコミュニケーションする時も「つたわらなくて当然」が前提になりましす。誰も、「前にいったよね？」とか、「メールで送ったのに見てないの？」とか言われません。
ましてや、「大人なんだから、察しないとね」とかいうことも存在しません。同調圧力とか何それ？という感じです。
年齢や、職種、職位によって、「えらい・えらくない」という感覚もなく、全くのフラットな感じです。単なるロールの違いです。みんな違うから、違いを尊重して、自分ができることをやって、自分ができないことを人に助けてもらうそのような感覚になります。
つまり、人と、人の間に共通点が全く、母国語も違うので、コミュニケーション自体が難しいので、コミュニケーションに前提がなく、明確で、単純です。いろんな事を「深読み」とかしなくてもよくて、失礼にあたるとか、めんどくさいことも考える必要もなく、向こうが表現したことをそのまま受け取ってコミュニケーションをすればいいのです。
また、コミュニケーションが元来難しいものという前提なので、すべての決定がロジカルです。誰もが合意できる「ロジック」という共通言語がないと、誰も納得感ある状態が作れないからなのかもしれません。だから、日本のように「政治」や「寝業」とかの入り込む隙がなく、誰もが納得感のある「ロジック」で物事が進むので、日本にいるときより、圧倒的に納得感があるのです。
日本では、「空気を読む」ことや、言葉の意味がそのままとは限らないので、何かを推進しようとしたら、正攻法では難しくて、じっと我慢してランクを上げるか、力を持った人に接触するなど本来の業務的な能力以外の能力がないと難しいので、そういうのが得意な人が力を持つことも多くありますが、インターナショナルチームでは、そんな人はいません。ロジックで物事が進み、めんどくさいことがないので、そこに力を使う必要がありません。
自分の専門分野に注力して、腕を磨けばいいのです。マネージャはマネジメントを、プログラマはプログラミングを。そして、そういう専門的なことがしっかりできる人が尊敬されます。 日本では重要な「おもんばかる」ということも必要ありません。みんな基本的に、チームではありますが、一人一人が独立を基本として明確に数値で定義されたKPIを持ってそれの実行を求められているだけなので、それ以外のことは要求されません。「これぐらいはやって当然だろう」という暗黙の話などもありません。おもんばかるに近いのですが日本人の「相手を優先し思いやる」という感覚はある意味美しいのですが、仕事においては鏡の法則が発動され、「これぐらいやってくれて当然」という空気を作ってしまうこともよくあります。そういう変な「深読み」は必要ありませんのでシンプルです。
実力主義の意味
日本で「実力主義」というと、凄い数字で縛られてしんどいイメージがありますが、インターナショナルチームにいるとそういうイメージではありません。
KPIは楽に達成できる納得感のある数値になっています。評価は、仕事の成果や実力の反映されるKPIで評価されます。「政治」は一切する必要がありません。
だから技術チームのマネージャなのに、技術の話をしても通じない人やBossyな人や今時マイクロマネージメントな人なども今のところあったことがありません。（多分マネジメントを勉強していない無能な人ということでクビになるのかと思います。）
だから、実力主義といっても、普通に積み重ねて努力している人には何も恐れることはない環境なのです。普通に努力していれば、普通に評価されるフェアな世界で、やり方の違いとか、考え方の違いとか、そういうのは違っていて当然なので、だれもとやかくいいません。
また、「クオリティ」は求められますが「挑戦」には開いています。だから何かにチャレンジした時に失敗したからどうこうというのは一切ありません。誰でも平等にチャレンジできますが、「基準」に到達していなければ、誰でも合格はしません。例えば、何歳までとかよくわからない基準はないので、何回でもチャレンジできますし、自分に不足しているものがあれば、例えば大学にいって学んでくれば単純に「基準」に達成できる感じなので不公平感はありません。そこに達成するのに、どの程度早いか、遅いかとかも、特に気にされません。シンプルな世界です。
私はそういうところが気に入っているのかもしれません。だから、「人はこうであるべき！」と思いが強い人にとっては、とてもストレスフルな環境かもしれません。
ダイバーシティが 楽しく生産的な職場を産む
私はこのダイバーシティが当然である職場の楽しさを伝えたいと思ってこのブログを書きました。誰れも自分が「マイノリティ」だとも「受け入れられない」とも感じないこの快適さを。そして、フェアな環境で、純粋に「仕事を楽しんで、自分の成果を出す」ことを求めれる環境を。
様々な統計が、ダイバーシティあるチームが生産性が高いことを示しています。私はなぜだか知りませんが、単一の集団だけだと、同じ様な特性があるから、弱点をカバーし合えないからでしょうか？私はまったくその辺の知識がありませんし、自分の勝手な想像でしかない浅はかな考えですが「人のコミュニケーションは難しい」からではないでしょうか？
どうしても同一グループだと「常識」や「伝わって当然」という「暗黙の想定」があります。それが、ダイバーシティのある環境だとその根底が崩れ、全員が、「常識や暗黙の了解はない」という世界でわかりやすく、伝わるまで、シンプルにコミュニケーションしようと頑張ります。そして、誰れもがわかる「ロジック」で共通認識をもち、思考をします。ダイバーシティある環境では、私は「社会人失格」ではなく、「発想力のある人」として、チームに貢献することが出来ています。
単一の集団と思い込んでいる人々も、本来は、伝わったと思っても、本当は伝わっていないのではないでしょうか？それは難しいことなのではないでしょうか？ だから、ダイバーシティの環境でそれが崩れることで、本来の「効率的なコミュニケーション」について必死で考えて実践するから、生産性が向上するのではないでしょうか？
私はダイバーシティが当然の社会が日本にも来てほしいと思っています。いつになるかはわかりませんが、誰も「変わってる」とか、「外国人」とか言われることのない社会に。
マーチンルーサーキングの言った世界、それ以上の世界が、ロンドンには存在しました。その様な世界では、みんなが「同じであること」に気を使う世界ではなく「違うことを尊重する」ということに気を使う世界です。アメリカでも、その感覚は相当に進んでいる様に感じます。私の大好きなgleeというTVドラマを見ていてもそれを感じます。
きっと日本が移民を受け入れたら少しづつ変わってくるのでしょうか？それとも、グローバルな仕事をしている会社がそういう世界を少しづつ変えていってくれるのでしょうか？
自分は、このダイバーシティの楽しさをみんなに伝えることで、少しでも貢献したいと思っています。自分がそうなってほしいから。
