日本をクビになる日
今回のブログは沢山の人に読んでもらいたい内容ではなく、単純に自分が考えたことの整理です。
私が初めて、オブジェクト指向やアジャイルを取り組み始めたのは2001年頃でした。なぜそのようなことを始めたか？というと、当時のシステムは自分から見ると「かろうじて動いている」という感じで、「しっかりと作られている」というイメージがありませんでした。徹夜で何とかふらふらになりながら納品したものが高品質なはずがありません。だから、自分なりにいろいろ「よいシステム開発の仕方」について学び始めました。
「現場」と正反対の開発方法論
すると様々な気づきがありました。まず「オブジェクト指向」の分析・設計・それに使われるプロセスを学んでみると、当時の開発で行われている考え方やスタイルとまったくと言って異なっていました。「どうして会社でやっている開発と、ソフトウェアエンジニアリングで説明されているスタイルがこんなに違うんだろう？」まだそれは、あくまで疑問のレベルでした。
ところが、平鍋さんのWebページで紹介されていた「eXtreme Programming」と出会って、人生が変わる程の衝撃を受けました。
今までの開発手法と、時には正反対のことを言っているが、自分の感覚的に凄く「正しい」気がする」これなら、私でもお客様に本当にいいソフトウェアを届けられるんじゃないか？
そういう思いがあり夢中になり、コミュニティ、社内外への啓もう、事例づくりにいそしみました。私としては絶対にこれは重要になるからうちの会社でもやるべき、いやうちの会社だけではなく業界でやるべき。もし、万が一、仮にそれが正しかったとしても、それは人への押し付けでしかありません。
龍野さんの一言
そんな当時の私に対して、人は「やったらいいんじゃない」、とか、「あれは宗教だ」とか様々な反応でした。私が今も尊敬する龍野さんという方がいて、その人が私に言ってくれたことが私のスタイルを永遠に変えました。
なあ牛尾よ、お前がやっていることは押し売りやぞ。北風と太陽やないけど、みんながやりたくなるようにせなあかんのちゃうか？
当時の私にとって、その言葉はとても響きました。龍野さんは誰からも尊敬されるような方ですが、決して偉ぶっているわけでもなく、仕事もものすごくできましたがお客様からも、社員のメンバーからも上下隔てなく尊敬される人格者です。 私の行動も多くの人にはスルーされるなかで、龍野さんは相当にサポーティブに助けてくれていました。そんな方の一言だから響いたのかもしれません。
その後私はスタイルを変えて、自分のモットーが「相手を理解する」になりました。お客様に対峙するときでも、何かを説明するときでも、常に自分ではなく、相手がどう思っているか、どう感じているかを常に観察、考えて、試行錯誤して、自分ではなく、その人にとっての価値を出せるようにするというスタイルです。この言葉の価値は今も変わりありません。
そのお陰で私は、コンサルや、新しい技術導入や、教育が大変得意になることができました。独立もしましたし、教育やコンサルをやるときはいつも高い顧客満足度を得ることができるようになりました。
更に、アジャイルのマインドセット、コンサルティングや、セラピーなどの理論や技術を学んでいく中で、どの分野であっても「人は変えることはできない」という原則を見ることができました。仕事においてだけなのですが、「人とうまくやる」ということにおいてはこの頃が人生のピークだったのかもしれません。内向的な性格ですので「無理」と思っていた結婚もすることもできました。
自分のために生きること
しかし、その後、いろいろなことが崩壊していきます。仕事上でストレスを感じることも多くなり、私の責任なのですが、妻は私の元を去りました。仕事でも、自分が相当役立ってると思えるときもあれば、ちょっとだけしか役にやっていないと思うこともありました。当時コンサル料金をたくさん頂いていたのもあり、バリューが出ないと、相当申し訳ない気分でした。何よりも自分がイヤでした。
セラピーを本当のセラピストから実地を通じて学ぶことで自分的に頂点を極めた「人のことを理解する」という能力ですが、このころの私は「人のために生きている」ということに気づいていませんでした。ただ、お客様には最高に気に入られるのですが「自分が無い」気はしていました。
私の友人の細川さんは、当時の私を振り返って「あの当時のうっしーは面白くなかったよ」って言ってくれました。人にとって心地よいことはできるし、日本社会ではうまくいくのですが、私が本当に幸せだったは相当謎ですし、様々なことを我慢していました。さらに、お客様にとって、私はプロとして「本物」を迷うことなく届けられたのか？というと疑問が残ります。
その後、先のポストでもお話しした通り「幸せシフト」を行い、「人のためではなく、自分の幸せのために、自分で人生の選択を行う生き方」にスタイルチェンジし始めました。
simplearchitect.hatenablog.com
コーチが一人前になる条件
「自分の幸せのため」に行動するようになると、私の「自分は何か一つでもいいから、プロフェッショナルと呼べるレベルの物事を達成したい」という欲がでてきました。お客様に対しても、耳障りの良くないことも言うようになってきました。コンサルタントが役に立つ大きな理由は彼らが優秀だからとかでは決してなくて、「第三者」の視点を持てることです。だから、耳障りのよくないことも正確にフィードバックする必要があります。これはとても勇気のいることで、自分がクビになるかもしれません。
ある時、一緒に働いているお客様のチームに対して、お偉いさんがたくさん並んでいるシーンで、ネガティブなフィードバックをしないといけない場面がありました。正直非常にストレスで、人に嫌われることは確実で心も痛みましたが、勇気をもって、少なくとも自分的には正確なフィードバックを実施しました。今はすぐにわかってもらえないと思うけど、そのチームに必要だと思ったからです。
その後そのチームにはあまりかかわれなくなりました。当然だと思います。スクラムコーチの世界では「クビになったら一人前」という言葉があります。チームに耳障りのいいことだけしている人は半人前。 私はその会社さんではその後もほかのチームのご支援をしていましたので、まだ私は半人前と言えます。
第三の方法
そんな過程を経ている中でマイクロソフトのインターナショナルチームに参加して、世界と日本の圧倒的な差、そして、１５年経過しても進歩が少ない現状を目の当たりにして、今までの「ソフトランディング」な方法でよいのだろうか？という疑問がでてきました。そんな中インターナショナルチームのメンバーから刺激を受け、学んだことで、日本と、西洋のマインドセットの違いに到達しました。 しかし、マインドセット、つまり、人の考え方を私が変えようというのはおこがましいことです。しかし、このままでは、、、というジレンマがあります。どうしたものか、、、そこで考えた作戦が次の仮説です。
人には何も押し付けないけど、自分の思った事は発言する。そして、自分が自ら自分がいいと思う行動することで、それを気に入ってくれる人を増やすようにしてみる。
世界を変えたかったらやることは一つで、自分が変わることしかありません。人は変えることはできませんが、私が、西洋のマインドセットのうち見習ったほうが良いと考えたことを自分で常に実践することで、もしかすると人が「あの人楽しそうだな！とか、あの人生産性高いな！」とか感じてくれるかもしれません。また、「本当はそう思っていても言えない」と思っている人がいたとして、私が常に思っていることを躊躇なく発言していると、「ああ、言ってもいいんだ！」と思う人が増えて、自由でフラットなコミュニケーションができるようになるかもしれません。
これは万人に受け入れられる考えでもないですし、仮説でうまくいくかも全然わかりませんが、自分が思った事を誰に対しても発言するが、他人にはそれを求めない。「人から学ぶ」「人を理解する」ことは続けるが、「自分はこう思う」というのは明確に発言する。ということを実験してみたいと思います。
日本をクビになる日
よくよく考えると、今も尊敬する龍野さんも、人の気持ちを理解できるだけではなく、主任の当時、事業部長を説教したといっていました。私が多大な影響を受けている倉貫さんも、自分の思うことは誰の前でも明確に発言しています。私は正直気が弱いので、内心は勇気を出していますが、今後もこのアプローチをまず一定期間実施して仮説検証をしてみようと思っています。
私は常に何か一つでもできる人になりたいと思っています。今はどれも中途半端です。でも、いつかこれを続けていたら、日本を「クビ」になる日が来るかもしれません。先日の投稿を読んで「震えた」と言ってくれた人がいました。あの投稿がほんの少しでもいい影響があったて、喜んでくれた人がいるなら、本当に怖かったけどやってよかったなと思います。
そして、「日本」をクビになる日がやってきたら、もしかしたらそのときこそ、私がやっと一人前になれるときなのかもしれません。
龍野さんや、倉貫さんのレベルにはまだまだほど遠いですが、自分のために、楽しんでぼちぼちやっていきます。
自分で人生を決めるマインドセットが、生産性と、仕事の楽しさをもたらす
今回は、前回のブログの内容をより考えてみたいと思う。
「自分で人生を決める」人は、他人に対して「すべき」がない
前回のブログの主張は、「自分で人生を決めない」マインドセットが、新しい考えや技術導入を遅らせるというアイデアだった。今回はさらに、「自分で人生を決める」マインドセットをもっていると、どういう効果があるのかを考えてみたい。
simplearchitect.hatenablog.com
「自分で人生を決める」というマインドセットを持っていると、「自分のことは自分で決める」という考えになる。心理学で鏡の法則というのがある。自分に適用している考えを他人にも適用するという法則だ。「自分のことは自分で決める」人は、「他人のことは他人が決める」という考え方になる。新しいアイデアや技術の導入スピードにはこれがとても効いている気がする。 逆に自分の人生が自分でコントロールできないと思っている人は、他人も他人がコントロールできないと考える。つまり、自分だけではなく、他人も他の何かに従うべきと考えるようになる。
インターナショナルチームで働いる時に感じることの一つは、人に「こうすべき」と言われることが全くないことだ。
もうすぐ期限の経費精算とか、必ずやることになっているものでもそうだ。例えばビジネスレポートの期限が迫っていて、私が忘れてた時ですら、「期限だから、入力してくれないだろうか？」ぐらいの口調で上司がリマインドしてくれる。 それぐらい、ほかに人にどうしろ、こうしろと言われることは本当にないのだ。もし、そうしなかったら、自分の評価が下がるだけだ。やるか、やらないかは私次第。人に「やらされる」ではないのだ。大人だから自分で決めて、判断しようという考えだ。
「本当に思った事」を言うエネルギー量の違い
今回ブログを書いて気づいたことだが、何か「意見を言う」ことの負荷が、インターナショナル環境と、日本では全然違うことに気が付いた。インターナショナル環境だと、「自分の人生に責任を持つ」マインドセットだから、私が同じような意見を書いたところで、たとえ多くの人と考えが違っていても、「あー、君はそう考えるのね」というノリだし、そうでない考えの人は自分でブログを書いて、「私はこう考える」ポストをする。 もちろん、そのアイデアに対してさらに自分がブログを書くか否かは私次第ということになるので、書いてもいいし、書かなくてもいい。だから相当気軽にアイデアをシェアできる。
ところが、日本で同じことをやると、そうもいかないようだ。今回のことでも、様々な方面から、「あなたはこうすべきだった」「フォローアップブログを書くべきだ」「きみのせいで、ほかの人が困る」「人の気持ちに気を配るべきだ」・・・。これは、人の考え方だし、文化に対して何かを言うつもりはない。ただし、メソッド屋として「新技術やアイデアの導入スピード」ということのみを考えると、これは相当問題だ。私の意見が正しいと私が思い込んでいるいう意味では取らないでほしいが、例えば、天動説が主流の頃に、自分はそう思うということで、地動説を唱えると、人は大きなショックを受けるかもしれない。天動説で商売をしている人は大きな打撃を受けて困るだろう。あなたの顧客には天動説の人もいるかもしれない。でも、それに遠慮をして、本当に自分が思う意見を言わないほうがいいだろうか？もちろん、あっているかどうかはわからないが、それを言えないとなると、相当いろんなものが歪んでしまう気がする。
日本では、そういったことに、いろいろ気を使って、何かをしなければならなくて、尚且つ、何かやった後も人々の要請があったり、「こうすべき」という意見があれば、それを実行しないといけないとすると、相当な負担だ。つまり、「めんどうくさい」のだ。
自分の意見をいうことに、ハラキリの覚悟は不用
だから、日本式でいくと、こういうセンシティブなブログは、書かないほうがめんどくさくなくていいし、多くの他の人と違う意見を書くときはハラキリレベルの相当な覚悟をもって言わないといけない。これは、相当なエネルギーロスじゃないだろうか？ だから、多くの人は本当は思っていることでも、「あとで面倒なことになるから、言わないでおこう」ということになるだろう。実際、今回私もブログを辞めようかとも思った。だってしんどいし、めんどくさいんだもん。
それよりも、単なる意見なのだから、「自分はこう思うよ」でよいと思う。気楽に言えたほうがよっぽどディスカッションみたいなものは気軽に、簡単にいかないだろうか？
そうでなければ、本当は心に思っていることが多いことでもみんな自粛して「言わないほうが得策」みたいな流れになってしまい、意見も「トレードオフがあるのでケースバイケース」みたいな聞き分けのいい話にしかならなくなる。
インターナショナルチームのディスカッションは楽
インターナショナルチームでディスカッションしていつも思うが、ディスカッションが本当に楽だ。自分が思っていることを単純に言えばいいだけだし、「気をつかう」なんてことは不用だ。純粋に思っていることを言うだけで、そこに、気をつかわなくていいし、「言ったからには・・・」といった変な責任が発生するわけでもない。 ダイバーシティが前提で、人がひとりひとりまったく違っていて当然という考え方だから、他の人の意見に対して「私はこう思う」というコメントはあるが、「お前は間違っている！こうすべき」みたいなことは無い。だから、ディスカッションも余計な要素がなくてとてもスムースに終了する。 もちろん「偉い人」なんて存在しないから、お伺いを立てたりすることも不用だ。
simplearchitect.hatenablog.com
Agile Rootsでの出来事
ここで、私も印象深かった、Agile Roots 2014での出来事をご紹介したい。Jeff Pattonという著名なアジャイルコーチが開催するワークショップに参加していた時の事。
そこにメアリー・ポペンディークという著名人が一緒にワークショップを受けていた。ジェフが、Scrumの世界で有名な「鶏と豚がレストランを開くたとえ話」を始めたときに、メアリーは立ち上がってシャウトした。メアリーはこのたとえ話が大嫌いなようだ。
ジェフ。君がこのたとえばなしをするなら、私はこの場を出ていく！
そういって、彼女は実際に会場を出て行った。ジェフは、何もなかったように講義を続けて、数十分後にメアリーは帰ってきて引き続き彼のワークショップに参加した。 ワークショップに参加したあと、メアリーはジェフに「君のワークショップとてもいいね！」と楽しく談笑し、褒めていた。
私はその姿を見て当時はすごくびっくりしたのだが、「意見の違い」なんてものはそんな程度のもので、そこに余計なものがいろいろはいるのがややこしいのだな。というのを学んだ。違う考えがある。時に腹も立つ。だからといって、ジェフに対してどうこうしろというのではなく、自分がしたいから自分が出ていく。それで終わり。何のわだかまりもない。
books.rakuten.co.jp books.rakuten.co.jp
他の例でも、海外のカンファレンスにいくと、参加者の人が、しょっちゅう席を立って退出する。日本だとよっぽど面白くないセッションでもない限りスピーカーに気を使って、立たないことが多い。しかし、向こうだと「自分がほかのを見たかったら」他のを見に行くし、スピーカーも、退出する人をみてショックだとかは特に思わない。自分次第。
「自分の人生を自分で決めない」マインドセットから生まれる、自分以外のものに対する「こうすべき」という考え方は、もちろん良し悪しだが、新技術の導入や、新しいアイデアの導入に関しては、相当なマイナスをもたらす。自分が何かしようと思った時に、いろんな角度から、「ああすべき」「君は間違ってる」「それは認められない」など凄い反発がやってくる。
「大人」という考え方の相違点
今回ある人がこんなコメントをくれて非常に興味深かったのでシェアしたい。彼は日本と、インターナショナルの混在環境で働いている。彼はこう言っていた。
西洋では「自分の人生や幸せを自分で責任を持ちコントロールする人」が大人という認識で、日本だと「我慢するのが大人」という文化のコンフリクトがあって困っている
なるほど！面白いと思った。私は生産性が良いし、自分が楽しいので前者を選択する。今は世界の文化を体感することのできる時代だし、自分がいいなと思うのを取りいれることができるので楽しい時代だ。 今回、２本のブログが読まれてたくさんの賛否両論があった。正直相当疲れてダメージも大きかった。そんなポストをしていたら、なんとロッシェルさんが私にコメントをくれた。
ブログを書くのは、ほかのクリエーティブな活動と同様です。In the moodだったら楽だが、そうじゃないと負担です。そのため、書きたいムードじゃない時に書かなくてもいい。そして書きたいムードになったら、書いてください。書くことによってハッピーになるのは第一です
自分は自分の人生をコントロールするマインドセットだと思っていたが、彼女のコメントは、凄く興味深いと思った。一番重要なのは本人が「ハッピー」かどうかという観点だ。ダメージを受けている時点で自分もまだまだ。私もそっちのマインドセットのほうが自分的に好きなので、更にそっちに慣れるように楽しんでみよう。でも一番は、それをして「自分がハッピー」と言えるかが重要なのだろう！
日本の新技術導入のめんどくささ
ふと、思い返したのだが、自分が、2001年にその後、アジャイルを初めて、エンプラな環境でも実施するために当時やったことを振り返るとこんな感じだった。
- 小さなアジャイル案件を作るために、自分で営業して、自分でコードを書いた
- アジャイルのコミュニティを社内でつくったり、社外のコミュニティの運営に参加した
- 内外でプレゼンテーションを実施して、仲間を集めた
- 大きな規模のアジャイル案件を実施するため、RFPの段階から参加して顧客にメリットを説明した
- その案件でアジャイルを実施するために、請負契約でアジャイルを実施する契約方法を考案して実施した
- その案件でアジャイルを実施するために、WF型の品質管理方式に対応するために、品質部門の人とディスカッションしてアジャイルでもまわるようにした
- アジャイルで必要な「テスト駆動開発」をするためには、OOPが必要だが、OOPができる人が当時少なかった。だから、OOPが誰でも理解できるようなメソッドを作った。
- 実際にアジャイルができる人をプロジェクトのメンバーに加えた。他のメンバーも教育した。
- 平鍋さんを呼んできてコーチをしてもらった。そのためにいろいろ説得した。
- アジャイルを実施すると、「要求」の部分がスムースにいかないことが多く、要求開発手法を学び実践した（当時プロダクトオーナという概念はまだなかった）
- いろいろなステークホルダ、上司、さらに上の上司と話を話をして、アジャイルプロジェクトがつぶされないように、交渉した
- お客様経由でマスコミに取り上げてもらって、より動きやすくした ：その後につづく、、、、
たかだか、新しいやり方を導入するだけでなんでこんなめんどくさいことをしないといけないのだろうか？私は新しくて効率のよさそうなやり方があるので、それを実施したかっただけだ。普段「やろうと思えばできるよ」と軽く言っているが、今と違って最初の頃にそれをやるときはこれぐらいめんどくさかった。 今回インターナショナルチームに参加して、他国の様子を観察していると衝撃だったのが、他国ではこんなめんどくさいことはいらないようすだ、「開発者」の人がやってみようと思ったら「やる」だけの話だ。
前にも書いたのだが、５００人ものハッカソンの開催が、１回の会議で決まっていく。日本だったらいろんな人の承認とか、合意とかを得ないと実施できない。こんな「めんどくさい」なら、日本では「無理」という気持ちはとてもよくわかる。だから、それをぶち壊したいのだ。
simplearchitect.hatenablog.com
素直に考えると、これだけめんどくさいと、「あー、もうめんどくさいから、海外いくわー」とか、「めんどくさいから自分で会社やるわー」とか「めんどくさいから、めんどくさくない文化をもったスタートアップに参加するわー」となるのも当然だろう。 そもそも、新しい技術や考え方の導入は、ずっと遅くなるのも当然だ。でも、新技術や、新しいモノの考え方の導入は、本来楽しくてエキサイティングなものだと思う。
「自分の人生に責任をもつ」マインドセットの楽さとチームの楽しさ
正直いって、私も昨年から始てインターナショナル環境で働き始めたので、その後初めて知ったことだが、インターナショナル環境で働くのは楽しいし、すごく生産的だ。自分の上司は、明確で無理のないKPI,ビジョンを示したら、あとは自分にフルに任せてもらえる。
simplearchitect.hatenablog.com
自分で考えて自分で実施する。チームメンバーや、ほかのステークホルダからも、「あなたはこうすべきだ」みたいなことは一切言われない。
ただ、自分がフィードバックしてほしい時に聞いたら喜んでアドバイスをくれる。みんなそれぞれが自分の仕事を楽しんでいる。「我慢」は一切だれもしていない。チームでやる必要がある仕事があって、誰も手を上げない場合は、「誰かこれにパッションある人を雇うか」となるか、普段自分がやりたいことをやっているので、「今回は俺やるわ」みたいな感じで、やらされるのではなく、自分が決めてそれを実行するので、何の不満もない。また、それを誰も選択しなくても、誰がわるいとかそんな話にはならない。
みんな主体的に自分の仕事を持っている。だから、誰も助けてくれなくても、それが普通だ。「助けるべき」みたいな変なプレッシャーは存在しない。忙しいときに、会議をスキップしても、メールをスルーしても、特になにも言われない。その人が仕事に対して責任をもっているので、誰かのせいではない。自分がKPIを達成できなければ、自分の給料が下がるか首になるだけだ。
だから、誰かが助けてくれたときは、とてもうれしい。
チームのために何かを作業したら、みんなからほめてもらえる。「ここがだめ、あそこがだめだ、さらにこうすべきだ」みたいなことにはまったくならない。ただ、正直なコメントは飛び交うけど、それをしたからといって、「誰かがきずつくからオブラートに包んで、、、」みたいなことはない。みんな「大人」とみなして行動する。意見が違っていたりしても誰も気にしないし、言ってはいけない意見とかも、仕事上は特にない。早く帰っても、いつ休暇をとってもだれも、それをさぼってるとかは思わない。むしろエンジョイしろよと言ってくれる。
プロフェッショナルさは重視される
そのわりにとても結果に関しては、プロフェッショナルだ。日本でのプロフェッショナルというのは、すごい厳しいイメージなのだが、インターナショナルチームだと、厳しさはみじんもない。「基準」に達している、否かは非常に明確だが、失敗しても、チャレンジには開いているので、何回でもチャレンジできる。 さらに、仕事も人生もエンジョイするものという考えだ。だから、各個人は楽しみながらスキルを常に磨いているので、アウトプットはみんなレベルが高いし、スキルアップを怠ってる人なんて人も見たことがない。
たぶんこれは「雇用制度」の違いも大きいと思う。こちらでは、簡単にクビにできるので、みんな「自分」が売れるようにしておく必要がある。会社も、働かない人は、残念ながら退職していただくことができる。一瞬これは厳しそうに見えるがKPIが達成不可能なものになっていないので、日本での「厳しさ」感はないし、裏を返せば、社員のほうも、嫌だったらいつでもやめてもっと楽しい会社に移ることができる。だから、今のところより条件が良いところがあったら、あっさりそっちに乗り換える。そんなことをしても、誰も「裏切りだ」とかは言わない。だって、本人のチョイスだからだ。
simplearchitect.hatenablog.com
海外の労働環境の楽しさが伝わりつつある
今まで私はインターナショナルチームで体験したような環境が存在すると思っていなかった。でも、海外に出たらそれが存在した。自分がハッピーで仲間もハッピーでイキイキ仕事ができてめんどくささがないので、生産性も高く、みんな一年ごとにさらに向上しあえている。マイクロソフトだからと片づけるのは簡単だけど、海外で働いて、日本に帰ってきた人で「日本に帰ったらいろいろめんどくさい、また戻りたい」と言っている話を少なくとも私はよく聞いている。たぶん同じような感じなのだろう。
前回のポストをした後に、こういうコメントをくれた人がいた。彼はUSに住んで働いている。
牛尾さんの新しい記事、自分には全面的に理解できるんだけど、他の人はどうかな？わかると日本にいられなくなる可能性大だけど https://t.co/TLTQhPCCVt
— 帝国兵 (@superriver) 2016年6月23日
彼のコメントは、今ならどういう意味かわかるのではないだろうか？
この事実は一瞬ネガティブな情報に思える。しかし、もしあなたの会社が、海外のようなハッピーな職場にすることが出来たらものすごい行列のできるようなお店になれる可能性があるのではないだろうか？カルチャーに取り組むところはそんな多くないから差別化の大チャンスだ！
日本で「自分で人生を決める」マインドセットのチームを作るには？
これは私も試行錯誤の最中だ。しかし、確実に作れるとは思っている。ポイントは「チーム全体のカルチャーのチェンジ」だと思う。例えば、チーム１０名のうち、１名だけ、「自分で人生を決める」マインドセットの人がいたとする。その人が海外で過ごしていたのと同じノリで仕事をすると、針の筵のような感じになるだろう。
一方、海外のチームに参加した日本人で、このような、「快適さ」に気づく人は多いと思う。こっちのほうが楽しくて、待遇もよくて、スキルアップできて、チームに喜んでもらえるし、自分の思うようにできる。最初は、自分が持っていた「自分で人生を決めない」マインドセットで、戸惑うことがあるが、２か月もすればなれてくる。そうなったら、日本での勤務を思い出すと本当にバカバカしく思えてくる。
だから、そういう人は私も含めて将来海外でまた働きたいと思っている人も多いと思う。
つまり、そういう環境にいたら、日本人でもすぐ慣れてしまうわけだ。ということは、こういうマインドセットをチームのカルチャーにして、チームのみんながそれになじんでくると、新しく来た人もそのカルチャーにすぐ慣れてくるということが可能な気がする。 Pivotal Labs はサービスとして、Extreme Programmingというアジャイルの手法を顧客に伝えるときに、顧客をPivotalにしばらく呼んで、一緒に開発をして、その開発習慣を伝授するサービスをやっている。非常に本質的だ。
つまり、それと同じことを、自分のチーム、もしくは会社でやればいいのではと思う。もちろんまだ私もこれに関しては事例はないがご希望の会社さんがいたら一緒に実施してみようと思う。
そうできたら、日本でも、「USと同じスピードで技術導入できるチーム」が増えてくるのではないだろうか？
simplearchitect.hatenablog.com
外から見てるだけなのでわからないですが、きっと、ソラコムさんとか、ソニックガーデンさんとかはこんなマインドセットな気がします。日本でもきっとできると思います！
www.slideshare.net
統計からみた従業員エンゲージメントの低さ
私もロッシェルさんの著書で初めて知ったのだが、従業員エンゲージメントという指標がある。従業員満足度のことだ。この満足度の調査があるのだが、私は世界平均と、日本の従業員エンゲージメントの比較を見てびっくりした。
なんと、世界平均だと、「満足」が圧倒的に突出しているのに、日本では、「非常に低い」というのが圧倒している。そして、５年連続で、日本は最下位らしいのだ。そらそうだよな。。。これはやはり雇用形態が大きく影響しているものと思われる。 そして、海外経験者中心に、この実態に気づいている人が少しづつ増えている気がする。そうした人は当然日本の企業で働くのが嫌になって海外に行ってしまうだろう。自分ができることからこの状況にアタックしていきたいと思っている。
「マインドセット」を変えて、世界に勝てるチームを作ろう！
日本人は、海外の人から見るといろいろいいところがある。磨き上げる能力、イノベーティブでユニークな発想、勤勉さなど、これぐらい世界と違うということは相当な競争力なのだ。そのユニークさが生産性のあだとなるなら、あだとなる部分だけ、「マインドセット」としてインストールして、課題を克服してしまえば、日本からもっと世界を「凄い！」と言わしめることができるのではないだろうか？
そのためには、ソフトウェアの先進国に学んで、その課題を解決していくしかない。私の考えはもちろん私の単なるアイデアで、うまくいくかもわからない。しかし、私的には、他人は変えられないので、想定する「マインドセット」を変えて仕組みをつくる。つまり、「大人とはどういう人か？」の基準をそちらにして仕事の仕組みを変える。楽しくなるし、チームでやれば仕事もめんどくさいことがなくなるし、いろいろ気づかいをすることなく、本当のことが言いあえるし、「我慢」もしなくてもいいし、チームで称えあってハイレベルの仕事ができるチームが出来るかもしれない。そんなチームが作れたらすごくうれしくないかなって思っています。
ダメだったらだって？私も海外で職をさがすだけですね！
だって、自分は自分らしくあり、楽しく仕事をしつつ、正直で、プロフェッショナルでありたいですから！
次回は自己組織化チームのことを掘り下げてお話ししていきたいと思います。
「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない
先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール 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
