技術なきマネジメントの衰退とその対策
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。
世界は「技術力」の重視に向かっている
私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。
私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術力」を磨きたいというのがあった。ラッキーなことに、海外転勤ではないものの、インターナショナルチームでエバンジェリストというテクニカルな仕事ができているので大変幸せだ。
なぜ当時「技術力」を磨きたかったかというと、私は、アジャイルや、DevOpsの導入、超上流の技術をはじめとして、「人」系の技術を磨いてきたので、アジャイルのような新い考え方を日本に導入するということに関しては絶対の自信もあったのだが、プログラマとしての技術力は、過去のキャリアを見てもらっても分かる通り、正直３流だ。
技術力がないのは何となくやばい
お客様と接している時に、ふと「このまま技術力」を磨かないと将来やばいとぼんやりと不安に思っていた。特にクラウドコンピューティングが普通になってきた頃から、そろそろやばいという感覚があった。しかし、私にはキャリアがないし、大手SIだったので、そんなにガッツリ自分で開発もしていない。今はいいけど、近い将来やばいんじゃないか。だから、ガチのプログラマとしては通用しないと思うので、プレゼン力とか、トランスフォーメーション力がとても有効で、しかも技術力も成長できるDevOps のエバンジェリストの職はまさに私が求めていたものだった。
たった１年で起こったマイクロソフトのトランスフォーメーション
最初の１年目は私はとても良い成果を出すことができた。皆さんのご協力、そして持ち前のトランスフォーメーション力もあり、とてもいい事例も作れた。プレゼンも神のようなレベルの人に直接教えてもらえて上達したし、プレゼンの評判もありがたいことに、とても良かった。当時のエバンジェリストの評価は色々あったが、最重要の指標の一つは、プレゼンなどを実施した時の「顧客満足度評価」の指標だった。技術力は、人前で話をしたり、デモをしたりというレベルで良かったので、頑張って学んで実践していれば、対応することもできた。ところが、技術のデモやプレゼンをして人々に、新しい技術を広めるという「エバンジェリスト」の職業は、たった１年でまるっきり評価基準が変わったのだ。
ハックフェストと技術力がエバンジェリストの世界を支配した
期が変わると、評価基準が一転した。プレゼンや、「顧客満足度評価」はもはや、エバンジェストの評価としては、ほぼ意味がなくなり、お客様のところに行って、ハックフェストというイベントを実施して、最も難しい問題を「コード」で解決してくること評価に変わった。ハックフェストは、３−５日で、お客様の環境でガチでコードを実装したり、自動化したりするようなイベントだ。そして、例えば、世界で誰も解いていない問題を解いたり、オープンソースにコントリビュートするようなことが「インパクトがある」という考え方に変わった。 これはとても大きな変化だ。開発者ではないので、マーケティングのような技術者のような中間のセンスが要求されたエバンジェリストは、そこまで正直技術レベルを要求されなかった。ところが、この方針では、かなりのテクニカルスキルを要求されるようになる。プログラマとして３流の私は死ぬ気で頑張るしかない。
米国のハックフェストで感じていたレベルの高さ
日本では、正直なところ、新しい技術や方法を導入するためには、技術力というよりその前にステークホルダーの人をうまく巻き込んだり、モチベートしたりといった「技術以外の要素」が実際に技術を導入する前に必要とされることが多いように感じる。私はそういうのがとっても得意だ。だから、日本では活躍ができた。
ところが、米国で先の「ハックフェスト」を実施すると、様子が日本と全く違うことに気づいてきた。お客様のレベルが平均的レベルが非常に高い。
日本でハックフェストをやると、例えば、最初の数日は、新しい技術のハンズオンみたいな感じになる。だから、達成できることもあまり多くないことが多いが、米国でのハックフェストの場合、お客様は、チュートリアルはおろか、新しい技術でも、すでにガンガンに本番に適用していて、基本的なことはみんなわかっていて、実際使っていて、その上で、「難しい問題」をお客様と一緒に解決することになるので、インターネットで探しても解決しない「世の中で未解決」の問題に向き合うことになる。
米国では、「技術以外の要素」の重要度は低い
日本では、このような「ハックフェスト」を実施する前に、たくさんの準備、訪問、説明などような「種まき」が必要だが、米国だと、「お客様」の方からリクエストが来るので、日本で必要な「技術以外のこと」があまり必要なく、「技術力そのもの」がお客様に求められる。
また、入門レベルのことも、米国の場合はお客様が自分で勝手にやってくる。世の中にチュートリアルや、ビデオは散々あるのでそういう情報は、ハックフェストの場では、我々に特に求められない。これに関しては「英語」のハードルも違うかもしれないし、向こうの人は、基本的にコンピュータサイエンスを出ていることも関係しているかもしれない。だから、プレゼンとか、デモとかの重要度が下がって、「ガチの問題を一緒に解決してくるれる技術イケメン」への需要が高まっているのもうなづける。現にマイクロソフトの本社の「//Build」で多く発表しているのは、プロダクションチームが多く、エバンジェリストではない。（ただ、キーノートのデモとかは、エバンジェリストが作っていたりする）
マネージメントスタイルの違いと技術
マイクロソフトに入ると、そもそも「コードが書けない」マネージャは、少なくとも私の上には存在しなかった。当たり前かもしれないが、技術のプロジェクトをやるのに、技術がわからなければマネジメントもクソもない。だから、彼らと話をしても、「あー、技術わかってないねんなー」とか「勘違いしてはるわ、、、」と言う場面に全く出会ったことがなく不思議だった。日本ではそんな場面はしょっちゅうなのに。だから、会話もすごくかんたんで、日本で必要な「上司の説得」みたいな場面は必要ない感じだ。
また、このブログでも触れているように、少なくともマイクロソフトでは、「サーバントリーダーシップ」というマネジメントスタイルが主流だ。チームを「管理」するのは「チーム自身」そして「個人」が実施するので、彼らを「信じて」「任せる」スタイルだ。彼らが困っている時は、マネージャが、サポートしてくれる。だから、マネージャが指示を出すようなマネジメント方法ではなく、チームが考えて、チームが問題を解決して、マネージャがそれを支援するようなスタイルだ。
この方法は、生産性的に細かい管理が不要になり、意思決定が高速化するので、圧倒的に高く、メンバーもモチベーションも高くなる。だから、マネージャも、我々をリーディングしてくれたりサポートしてくれるだけではなく、メンバーと一緒になってハックフェストをしたりする。リーダーシップではなく、「管理」だけする人はもはや不要だ。
simplearchitect.hatenablog.com
さらなる技術シフト
マイクロソフトのエバンジェリストチームに入るとさらなる「技術シフト」を感じる。先日も、HackWeekという、本社のエバンジェリストがいろいろなものをハックするイベントが開催されたが、その時に、エバンジェリストの長が発した言葉には驚いた。「マネージャであっても、全員L3を取ること」L3というレベルは、お客様の所で、ガチのプロダクションに使えるソリューション（コード）を書いて貢献すること。という意味だ。つまり、日本でいうと、部長も課長も全員お客様の所でコード書いてバリュー出せるレベルになりましょう。ということだ。
そのエバンジェリストのトップ（日本でいうと事業部長クラス）は、さらに、そのHackWeekで自ら、CosmosDBなどのハックに参加して、彼自身が時間をとってハックをしていた。
技術の進展はめまぐるしい。だから、少なくとも米国では、マネージメントであっても、最新の技術をハックしていないと話にならない時代が来ているということだ。もちろん米国にも、プレゼンや、デモが強く、そんな技術力が高くない人もまだいるだろう。去年変わったばかりだから。しかし、急激に、マネージャであっても「技術力」のある人が求められているのは間違いない。
これは、実は米国では顕著だが、日本でも始まっている気がする。だって、そうでないと、これから、自動翻訳もできて、海外との言語の壁が少なくなると、日本マーケットに、そういう技術力が高い人が押し寄せて勝負をすることになる。
simplearchitect.hatenablog.com
そんな時に、どうやって効率が悪いことをやって勝てるのだろう。
じゃあどうすればいいのだろう
私のように、SIer出身で、若い頃からPMとかコンサルとかやっていた人はどうしたらいいのだろう？自分の当面の目標は、「世界のどこにいてもご飯が食べられるスキル」を身につけることなのだが、私のスキルは、「日本」にのみ特化している。他では現在のままでは食べられない。ポイントは「技術力」だ。これさえあれば、多少英語がしょぼくても、米国でも通用する。
しかし、現状の技術力を鑑みると、そもそもこの業界を諦めた方がいいのだろうか、とか色々考えた。今は、マイクロソフトを首になるまで、エバンジェリストとしてスキルアップをひたすら頑張るしかないと考えて、なんとか頑張っている。しかし、私は本社メンバーの仲間に比べると、まだまだなので、いつ首になってもおかしくない。もしかすると、多くの日本のマネージャの人も、薄々技術力が必要になることはわかっていても、何十年もコード書いてないし、新しい技術はバンバン出てくるしどうしたらいいのだろうと途方に暮れているかもしれない。私も似たような感じなので、このギャップがここ数年の私の最大の悩みだ。
プロダクションコードを何年も書いている人に渡り合う為には、自分でチュートリアルをやって、本を読んで自習したところで、到底及ばないだろう。しかし、技術なき人に明日はないと感じる。
Mob Programming の衝撃
しかし、私は、その解決のための一つのヒントを得た。それは、Mob Programmingだ。Mob Programming はチーム全員が同時に、同じ場所で同じコンピュータを使って同じことをする。１台のコンピュータとプロジェクタ２台を用意して、全員で、１台のコンピュータをシェアして、メンバーがドライバーと呼ばれるキーボードを入力する役とそれ以外の人がどういうコードを書くかを議論するスタイルだ。
ペアプログラミングを知っている人は、それをチームでやった版だと思うだろう。だから、私も、最初はあまり興味がなかったのだが、実際にMob Programmingを体験したら世界観が一変した。これはものすごいメソッドかもしれない。アジャイルがプログラミングの世界を変えたように、このメソッドがまたプログラミングのやり方を変えるかもしれない。下記のスライドは、楽天の及部さんが発表したスライドでMob Programming とその実際がよくわかる資料なので共有したい。
次の動画は、Mob Programming の提唱者であるWoody の講演
Mob Programming のメリット
Mob Programming はチーム（たぶん４−５名がベスト）全員で１台のPCなので、従来のマネージャなら、効率が悪いから絶対認めないスタイルかもしれない。しかし、実際にやってみると、むしろ「効率が良く」感じる。よくよく考えると、プログラミングをしていて、最も時間がかかるのは、「悩んでいる」時間だ。何かにどハマりするとか、初めての事、難しい事をやるときに、理解するのに時間がかかるとか。それがMob Programmingでやると、いろんな人が寄ってたかって、いろんな目線で解決を考えるので、詰まったり、ハマったりする事がなく、異常に早く終わる。ペアプログラミングも良かったが、その時とMobとの最大の違いは「心理的安全」かもしれない。
心理的に安全を感じること
プログラミングをやる時に、現在では毎日のように「未知の技術」に向かわないと いけない。新しいことを覚えて熟練して使えるようになるには時間がかかるし、知らない技術をやらないといけない時は、自分にできるだろうかとか不安になる。先の及部さんと、ラッキーなことに、Mob Programming を体験させてもらえる機会を作っていただいた。
Mobに最初に参加して衝撃だった一言がある。４人ぐらいのMobを常に実践しているチームがいて、彼らが、PHPを書いていた。彼らが、「Mobに加わりなよ！」って言ってくれたのだが、私は「わしPHP一秒も書いたことないねん」と言った。本当にそうなので。とても、貢献できると思えない。
ところが彼は、「あー、この前〇〇の会社さんが来て、Mobに参加してコードかいて帰ったけど、彼らもPHP知らんけど、コード書いて帰って行きました」言っていた。
知らない言語でプロジェクトにいきなり貢献する衝撃
自分が何も知らないチーム、そして知らない言語で構成されたプロジェクトに参加して、初日からコードを書くなどというのは、想像もできないが、Mobではこれが発生するようだ。しかも、続けて彼は言った。
えーーーーーー！彼曰く、
「Mobだと自分が知らなくても、他の人が知ってたらなんとかなるので、とっても気楽ですね」
結局私もその日Mobに参加して、コードを書いて帰って来た。コードを書いている時も、不安が何もなかった。だって、自分が知らないこと、遅いことも、他の人がカバーしてくれるし、わからなかったら全員で調べてくれるので早いし、たとえつまづいたとしても、「あー、わからないの俺だけじゃないんだー」と言うことがわかる。つまりむっちゃくちゃ安心感があるのだ。だから、1日終わると、しっかりバリューもでるけど、すごく幸せて楽しい気分で帰ることができた。
Mobの効果はそれだけにとどまらない。
問題 vs 私たちで、問題をフルボッコにする
Mob Programming を実施するとかなり心理的に負担が少ない。今までは自分が初めてのテクノロジーに触れるときは慣れないので、最初に相当ハマることは覚悟しないといけない感じだが、Mob Programming でやると、触れたことのない新しいテクノロジーも全然怖くない。自分のチームに誰か知っている人がいたらものすごくスムースに新しいことを学べる。全員その技術をしらなかったとしても、「あー、知らないのはわしだけじゃないんだ！」と気楽に取り組める。それでも一人でやるときよりよっぽど早いし、ストレスもない。
なんでかなと考えると、普通の問題だと、一人でハックをしているときは、問題１に対して人間１で１対１の勝負をしている感じだが、Mobだと、問題１に対して例えば人間４なので、問題をよってたかって、フルボッコという感じなので、大抵の問題はボッコボコにできる。
何より楽しい
私は、楽天さんで、Mob Programming を常に実践しているチームがあり、そこにお邪魔させてもらって数回体験させてもらった。理屈抜きに最高に楽しかった。マイクロソフトに帰ってからも、先の「ハックフェスト」を実施するときに、Mob Programming でやってみましょう！と提案してみた。お客様と、マイクロソフトのエバンジェリストと Mob Programming をやってみた。最高に詳しいエキスパートがいたこともあり、私が初めてのXamarinの開発であっても、コーディングに参加することができたし、挙動やアーキテクチャもずっと楽に理解できたし、ディスカッションもすることができた。他のメンバーも、Mob Programming を実施して本当に楽しかったという話をしてくれていた。最後にお客様から聞いたハックフェストの感想でも、Mob Programmingへの絶賛にあふれていた。楽しさは、正義だ。
暗黙知を共有できる
次に暗黙知の共有だ。通常の技術獲得の時に、本を読んだりチュートリアルをしたりすることでは得られない部分が実際のプロジェクトで活躍するためには重要だ。ちょっとした「思考回路」だったり、「ツール」だったり、「ショートカット」かもしれない。どういう習慣で、開発をして、名前をつけて、どうやってコミットログをつけるか。
これらの形式化できない「暗黙知」は通常自分が長年かけて積み重ねて、得られるものだけど、Mobだと、他人がどのように、考え、行動するのかを共有できる。これは体験してみないとわからないかもしれないが、相当協力だ。普通こんな機会はない。凄く技術的に優れた人がどういう考えで、どういう手順でコードを書くのか。これを共有できることは、チームのレベルアップの上でも最強だ。
詳細な管理が不要になる
さらに、マネジメントの観点でも革命的なことがある。先の Mob Programming を実践し続けている楽天チームのメンバーが語ってくれたことだが、「タスクを管理する必要がない」なぜなら、常に一緒に作業をしているので、他の人が何をしているか？という情報交換や、シェアの時間が必要ないのだ。この工数はバカにならないし、伝わらない。それぞれがやったことを「レビュー」しなくても、そもそも常にレビューしている感じだから、そんなことも必要ない。
彼らの壁にタスクKanban が張り出されていたが、「それはもう使っていない。Mob をやり始めてからいらなくなった」とのことだ。これって、実はものすごい事じゃないだろうか？もう細かい管理など必要ない。アジャイルやDevOpsの時代からすでに不要だったが、それを上回るほど管理が必要なくなってくる。
マネージャが本物の技術スキルを身に着けるためにも Mob をする
Mob Programming はチームのためであり、マネージャのためのものではない。ただ、チームが Mob Programming に移行すると、私や、今まで技術をあまりやっていなかったマネージャで、本当に技術を今から身に着けたいと思っている人にも最高の仕組みだ。
今まで自分が「管理」していたチームが Mob Programmingに移行して、自分が指示するかわりに、チームが全員で意思決定して、Mob Programming を実施すると、細かい管理は不要になる。その工数をどうしたらいいかというと、リーダーシップと、自分もMobに参加するようにしたらいいのだ。
例えば、技術を本気で学びたい人がいたとしたら、自分で本を読んでコードを書いたり、チュートリアルはやるだろう。しかし、それでも「プロダクション」のコードに対応するためには、「現在のアーキテクチャによる本番でコードを書いて運用する経験」が必要になってくる。これは「独学」では体験できないし、体験したければ、技術力を身に着けるしかなく、卵が先か、鶏が先かという話になってしまう。
Mob Programming が日本の技術力不足を解消するかもしれない
しかし、Mobであれば、自分で勉強は必要だが、Mob Programming に参加できれば、かなり心理的障壁低く、本物のプロジェクトに参加することができ、今の技術でどういうコードを書けばいいかも理解できるようになる。しかもかつてないほど参加への障壁が低い。日本では私含めて、実際こういう人がとても多いと思う。やる気は必要だが、そういう人が仕事をしながら「技術力」を身に着けるための、最高の方法なのではないかと思う。そして、自分のチームの技術を理解できるのだから、リーダシップを発揮したり、チームを助ける際も的確な行動がとれるようになるだろう。簡単ではないが、日本がソフトウェア技術的にも優秀になるためのチャンスがここにはあるのかもしれない。チームからしても、一人モブに加わったからといって生産性を損なうとかないので、この目的で考えると最高のツールだと思う。
simplearchitect.hatenablog.com
おわりに
私も今後は、楽天さんで教えていただいた Mob Programming をより実践して日本が、自分が世界でも勝てる方法を継続して探っていきたい。メソッド屋としては、最高にワクワクする方法を体験できて最高に幸せだ！是非皆さんも試していただきたい。
私、もしくはマイクロソフトのエバンジェリストのメンバーと、世界で誰も解いてない問題を、Azureで解決したいと思う方は是非私とハックフェストをMob Programming の形式で実施して、その威力を味わっていただきたい。楽天の先ほどのメンバーは現時点で日本最高のMob実践チームだ。NECの方面でも実践しているチームがあると聞く。皆様も是非 Mob Programmingの威力を実感していただきたい。Mob Programming でこの業界を変えよう！
新技術導入を米国並みに！働き方を変えて生産性を高めるための８つの習慣
クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める８つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください！また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。
元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ１０数分以下のサイズになっています。
序章：イントロダクション
８つの習慣をなぜ作成したのか？どういう効果があるのか？ということについて解説しています。
私が８つの習慣を作成するにあたり、感じたこと、思ったことはこのあたりのエントリに起因している。
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
次からは、各習慣についての動画をリストしておきます。補足のブログや動画へのリンクをつけておきます。またブログの最後に動画で使用したプレゼンテーションをつけておきました。
第１の習慣 Be Lazy
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第２の習慣 リスクや間違いを快く受け入れる
simplearchitect.hatenablog.com
第３の習慣 不確実性を受入れる
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第４の習慣 サーバント・リーダーシップ
サーバント・リーダーシップに関してはもう一つビデオがあります。従来は、通常のマネジメントをしていたマネージャが、どのようにサーバント・リーダーシップに変わっていったか、恐れは、そしてその効果やトレードオフについての体験をインタビューしたビデオがあります。こちらもよろしければご覧ください。
Takahiro Kaihara さん、 Mitsunori Seki さん、撮影ご協力ありがとうございました！
simplearchitect.hatenablog.com
第５の習慣 セルフマネジメントチーム
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第６の習慣 従業員への信頼
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第７の習慣 個人の自信
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第８の習慣 階層関係のパワーバランス
simplearchitect.hatenablog.com
プレゼンテーション
おわりに
西洋文化インストールという８つの習慣は変化への対応や、生産性を高めるための習慣を、マインドセットとして整理できたと思っております。是非楽しんで学んでみてください。ロッシェル・カップさん、本当にご協力ありがとうございました！皆さんの生産性が向上しますように！
「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第３の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。
ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。
不確実性を受入れる
- マネージメントは詳細まで細かく練られた計画を期待しない。
- 予算と報告のプロセスは精密な結果の予測を要求しない。
- 内部プロセスは計画や優先順位の変更に柔軟である
- 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ
- システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる
- 学びに基づいて、変化を精力的に行う。
この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思われる習慣だ。 この考えなしに新しいモダンな開発スタイルのマネジメントは不可能といっても過言ではない。逆にいうと、あなたがこの習慣をマスターすれば、日本人の良さも生かしながら相当かっこいいマネージャになれるかもしれない。
「納期は絶対」の神話
日本人には、「不確実性の忌避」という文化的性質があるらしい。つまり、不確実な状態を嫌うので、先に予見したり、計画するということをがっつりやってしまいがちになる。比較的先が見通しやすい産業においてはとても有利な性質かもしれないが、ソフトウェアのように非常に先の見通しが立てにくく変更が多い分野にはこの性質がマイナスになりがちだ。我々の傾向として、よくわからないものがあった場合、先に試してみるよりも、やる前に、いろいろ「検討」したりしてしまい、なかなか着手できなかったり、どんなに計画しても分からないものに対して、一生懸命予見し、完璧な計画を立てることに時間を使ったうえ、一度立てた計画が実態にそぐわなくても、その「計画通り」に遂行しようとして、プロジェクトが炎上してしまうという場面もしょっちゅうある。
我々は「計画通り」でないと「失敗」と思うかもしれないが、そもそも未来を予見できる人なの世の中に存在しないのではないだろうか？なぜ「計画通り」でなければならないのだろうか？計画はあくまで、当初の見込みで、作業を円滑に進めるためのものじゃないだろうか？よくわからないものに対して、事前に検討しても予見できない。その予見に時間をかける暇があったら、検証するほうがよいというのは前回のテーマにもつながることだ。
simplearchitect.hatenablog.com
私が、クロスカルチャーの専門家のロッシェルカップさんから聞いた話で衝撃的だったのは、「納期（Deadline)」の意味が日米で異なるということだった。日本の場合は、納期に、予定された機能の納品物を、予定された品質で提供するのが必須であるという感じだ。しかし、米国では、「納期は柔軟」であるらしいと聞いて目が飛び出るぐらいびっくりしたのと同時に、そういえば同僚のことを思い出しても、日本ほど「納期」に厳しくない。大抵は、納期にリリースするけど、予定よりも少ない量に変更するいうことはしょっちゅうだ。少なくとも納期を守るために、徹夜とかいう場面は見たことがない。我々はたぶん納期に厳密すぎて無理をしすぎる傾向にあると思う。それはどの程度バリューがあるだろうか？
ソフトウェアエンジニアリングでの考え方
そもそも、Q(品質)C(コスト)D(納期)+S(スコープ)は、トレードオフの関係にある。納期を短縮したければ、お金をたくさん払うか、品質を落とすか、提供する物量（スコープ）を減らすかという塩梅だ。予定通りQCDSをすべて達成するというのは非常に困難だ。だから、多くのマネージャは、大きなバッファを持って、それを達成しようとする。私も昔は常に３０％ぐらいのバッファを残しておいた。そもそも、ソフトウェアの場合は変更が入るので、当初の計画通りにはまずいかない。
つまり、エンジニアリング的には当初に想定された、QCDSをトレードオフせずに納期通り納品するのはほぼ不可能に近い。しかも、その計画はソフトウェアの場合、統計的にも相当予見しにくいものである。段階にもよるが、最初の段階で計画したコストの３倍になる確率も十二分にあるといった精度でしかない。これを信じるほうがよっぽどリスクが高い。
実績のみで判断する
その代りどうすればいいか？というと、単純化していうと「実績」だけで判断し、「納期」を固定して「スコープ」つまり、予定の機能を出し入れするほうがいい。
納期はまもって、その日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回す。もしくはやめてしまえばいい。ある機能が１週間遅れたからといってそれがどの程度インパクトがあるだろうか？それが「達成される」という前提で計画を立ててしまうから、「必達」とかになってしまうけど、そもそもそれは計画なので「いまのところは、こういう予定」ぐらいの感覚で見たほうが確実じゃないだろうか？
例えば、マイクロソフトや、他のサービスプロバイダを見回してみても、必ず納期通りすべての予定の機能をリリースしているソフトウェアジャイアントは存在するだろうか？ロードマップを持つことは見通しがよくなってよいことだが、実際リリース予定の日が近づくと、しれっとその機能が削除されていることはざらではないだろうか？ それはどの程度のインパクトを起こすのだろうか？そして、その納期とリリース機能を守ることは、プログラマの生活や健康や楽しみを犠牲にして守るほどのものだろうか？そもそもマネジメント的にも、中長期的には生産性は疲弊するためどんどん低下してしまうので効率が悪い。
予定日にはリリースする。そして、例えば開発が１週間単位でおこなわれているならば、前の週、その前の週とかがどの程度の量をこなすことができたかを測定して、次の週、その次の週も、たぶんそれぐらいの量はこなすことができるだというという想定を立てるとより現実的な計画を立てやすくなる。
ただし、この計画も状況は刻一刻と変わるので、ずっと現実的であるとは限らない。チームの誰かが病気になるかもしれないし、チームの生産性が上がるかもしれない。楽観的でも、悲観的でもなく、現在のチームの生産性を測定して次の直近の予測に使うという方法だ。そうしておけばシンプルだし、気合や根性の正解や、楽観的もしくは悲観的な感覚が入り込む余地が無くて楽ではないだろうか？
さらにこれがいいことに、無理してリリースするとすると、問題を覆い隠す。つまり、チームの生産量を超えた量を一定期間で達成した結果、今回出来たら、次回もこれぐらいできるよね。ってなりがちだ。そうするとどんどん無理が積み重なっていく。そして、無理をしていることが上層部や周りにも伝わらないことになる。だから、問題も改善されない。
無理を積み重ねるのではなく現実を見て、「工夫」をしていこう。たぶんポイントは、第一回でご紹介した「物量を減らして、より大きな価値を生み出す工夫」だ。つまり「やらないこと」を見つけることだ。
詳細な計画を求められないために
もしかすると、あなた自身ではなく、上の人から詳細な事前の計画を求められるケースがあるかもしれない。詳細な計画はコストも時間もかかるうえに、着手を遅らせるという最悪な結果を招く（少なくともソフトウェア開発の場合は）。そのようなケースだと、プロジェクトが始まる前に、その上の方に「こういう形式でレポートします。今回 Agile / DevOps なので」ということを事前に合意しておくとよい。そもそもそれが通らないって？その場合は、私のお勧めは例えば、Agile / DevOps をやる場合にはお勧めの方法がある。Value Stream Mapping という現在の開発プロセスを見える化して、改善ポイントを見つけ、リードタイムを短縮することができるツールを使うとよい。
このツールを使うと、素晴らしいことに４時間ぐらいで、無理なくリードタイムを短縮できる「見込み」を知ることができる。例えば、ある会社さんでは、リードタイム8.5か月だったのが、Value Stream Mapping を実施して自動化したら、1週間になる見込みだとわかって、数か月後、実際に1週間…どころか、1週間に数回ソフトウェアをデプロイできるまでになった。上層部にとって、細かい開発プロセスはどうでもいいことなので、こう言ってみるといい「DevOps という開発のやり方をやってみたいのです。我々のプロジェクトのリードタイムが今8.5か月なんですが、それを入れると、1週間に短縮できるみたいです。やってもいいですかね？」とかいうと大抵は「そらやるしかないだろう！」という話になる。そして、「DevOpsをやるためには、レポートの実施方法も変える必要があるので、今度、どんなレポートになるのかを事前にお見せしますね」と事前に合意しておくといい。
そうすれば、上の人は大抵シンプルなレポートに喜んでくれる。そもそも、細かいどうせ把握できないものより、リードタイムが短くなるほうがよっぽどうれしいはずなので、先に「どうせいっても無理」とあきらめるのは非常にもったいないのだ。
例えば私はチームから出すレポートは次のようなものをおすすめしている。上の方に行けば行くほど、シンプルなレポートが好まれる。
いまならさらに、BIを活用して、自動でダッシュボードをつくっちゃってもいいだろう。
確実に納期を守る方法
中には納期が絶対的なものが存在する。それは米国も日本も変わらない。オリンピックが開催されてそのアプリの納期を伸ばすのは意味があるだろうか？じゃあどうすればいいかというと単純だ。本当に納期を割りたくなかったら早く始めたらいい。
さらに、ソフトウェアの場合とかだと、既に動いているものを「リリースする」と約束すればいいだろう。例えば今だと、フィーチャーフラグというテクニックがあり、実際の機能がすでに盛り込まれているが、公開するスイッチをもっておき、そのスイッチをオンにしたら特定のユーザにのみ公開されたり、全体に公開されるようにしておく。そのスイッチを使って、先に実装しておいて、一部のユーザにつかってもらって、実際に動くし、価値もあると判断してから、本当の「公開」をするようにしたらどうだろうか？ これは、Azureや、Windows10をはじめマイクロソフト以外でも多く使われている方法だ。
皆さんの開発だと、納期を固定して、スコープを変動させる考えがある。つまり、納期に何らかのリリースをするけど、すべての予定されていた機能のうち、実装できたものをリリースするという考えだ。つまり、出来なかった分は入れないようにする。 この考えの場合、含まれる機能が増減しても、ユーザにとって価値のあるものがなんらかリリースられるようにしておくとよい。機能A、機能B、機能Cがリリースされないと意味がない、、、という場面では、機能A、機能B、機能Cを順につくるのではなく、機能A、機能B、機能Cを同時につくるけど、想定よりずっと簡単で、シンプルなものにする。だけど、連携してなんから動作して、価値を提供する単位でつくると、常にリリース可能な状態ができあがる。そうすれば、機能の増減に関係なく「いつでもリリース可能」になる。ただ、予定された機能がすべて納期通りにそろうとは限らないというだけだ。
「不確実性を受入れる」プラクティス
さて、なかなかこれは受け入れ型考えかもしれないが、モダンなソフトウェア開発メソッドではこの考えが基本となってくるので、すくなくとも「思考回路」だけは手に入れておきたいところだ。そうすれば、すくなくとも「選択可能」になれる。 まずは、この「不確実性を受入れる」ために自分で練習できるプラクティスを考えてみたい。
対象者
- 上位マネジメント
- プロダクトオーナ
- チーム
おそらく、対象者のうち、最もこのプラクティスに影響をうけるのは、上位マネジメントだろう。次にプロダクトオーナ。だが、実際には上位マネジメントの方は詳細を知りたがる人はあまり多くない。中間層のマネジメントの方に詳細を知りたがる人が多いイメージだ。
1. 楽に達成できる計画で仕事をしてみる
日々の仕事を実施して、仕事を他の人にお願いするケース（そういうのが無い人は自分の計画を立てるとき）に、その人の能力でいうと、これぐらいの日数で出来るという日を納期にするのではなく、もっともっと余裕で出来る程度の日程を設定しよう。日本にいると「なるはやで」とか、家に帰宅後「明日までに」というオーダーで仕事を依頼されることもしょっちゅうあるが、向こうにいくと、こういう依頼は「マネージメント能力の欠如」としてみなされるらしい。それは、納期を割る確率が非常に高い賭けをしているようなものだし、依頼先にも相当な負担をかける。そして、日々仕事をしていると、割り込みが入らないことのほうが少ないだろう。だから、かなりの余裕を持った日程で、しかも、早めにチェックポイントを設けて、仕事をやってもらうようにしよう。わたしだと、どうしても、自分が「理想的にできる時間」とかで見積もってしまいがちで、「あーわし全然仕事が遅いなー」とがっかりすることもなくなる。人間そんなものなのだ。
それがうまく出来なかったら、どうしたらよかったか、改善をしてみよう。ただ、「計画通り」が良いという思考は忘れてしまうほうがいいと思う。計画通りはよい事とは限らない。ものすごーーーく余裕があるかもしれない。そしたら効率悪いではないか。そして、それは、「新しいことに対応しなかった」ということも意味する。計画は単に「見通しをたてて、仕事を進めやすくするため」のものでしかない。未来は予見できない。計画や、物量ではなく、自分が創出した「価値」をどの程度定常的に提供できているか？を判断基準にして考える練習をしてみよう。そもそもその納期にどれぐらいバリューがあるかも考えてみるといい。この背景には、沢山物量をこなすのが生産性がいい事であるというマインドセットが背景にあるかもしれない。
また、初回に学んだ「時間を固定して、中身を変動させる」というプランニングの方法を練習しておくとこちらにも効果が上がる。
simplearchitect.hatenablog.com
2. 「無理・断る」と言う練習をする
先のロッシェルさんと一緒にやったワークショップで、あるとき、ブラジル人と日本人の混成チームがあった。ロッシェルさんは、日本人の人に対して次のように言った「もし、みなさんが仕事で忙しいときに、上司からこの仕事をやって欲しいと言われたらどうしますか？」というと、日本人の人は、「わかりました」といって残業とかでカバーするという回答だったのだが、同じ質問をブラジル人にすると「私は今仕事で手一杯だからごめんななさい」と断ると言っていた。
心理学では鏡の法則というのがあり、自分に適用しているルールを知らず知らずのうちに、他人に適用してしまうというのがある。例えば、自分に納期厳守を課している人は、他人にもそれを求めてしまう傾向があることだ。我々のDNAには骨の髄まで納期厳守のDNAが刷り込まれている。 つまり、自分が寛容になるためには、自分もそれでOKにしてしまうといい。そのブラジル人の人みたいに、そういうケースがあったら、「無理」だとか「断る」ということをしてみよう。そのうえで、どうしたらいいか相談にのってあげよう。自分が我慢して受けてしまうと、改善につながらないし、自分以外の人にも我慢を強要してしまう傾向になる。
「無理」というのを認識したうえで、楽に達成できる計画に２人で落とし込む計画に変更するのはどうだろうか？無理であることがわかったら工夫したらいいし計画に無理があったサインかもしれない。「ここまでだったら、協力できるよ」というラインについて話をするのもいいかもしれない。こういうマインドセットをチームでシェアすると、「無理！」が言いやすくなるので、８つの習慣をチームでシェアしておくのはおすすめだ。「無理を承知で」のお願いの連鎖が、みんなの疲弊を生んでないだろうか？「無理」と言えるようになったら、「無理じゃない」計画に対してみんな対応できるようになる。
3. 他の文化の視点を学んでみる
先ほどのブラジル人と日本人のチームの例ではないが、日本人ではない、他の国だとどうなっているだろうか？というのを学んでみる練習も楽しい。私は英国留学を３か月していた時があるが、その時マーケットリーダーというビジネス英語のテキストを使っていた。その内容は結構面白くて、いろんな国の商習慣や文化習慣についても学べる構成になっていた。我々は日本だけで生きて育っているので、例えばの納期を守るのは人として当然ぐらいの感覚がある。
しかし、他の国だと、時間通り待ち合わせに来るのが失礼という国すらある。先ほどのブラジルの例だと、日本人よりダイレクトに思っていることを話す。しかし、デンマークだともっとダイレクトだし、日本よりももっと、ダイレクトに思ったことを表現しない国もある。 そういったことを学んでいくと、もはや「常識ってなんだっけ？」という感覚になってくる。そうすると、「自分の常識」というものも、他の人には当てはまらないなぁ。という感覚になってくる。下記のロッシェルさんのクローバるマインドセットの記事はとても興味深い。もしご興味がある人はぜひご一読いただきたい。
ビジネスで成功するための グローバルマインド養成講座｜ビジネス英語｜アルク
我々は計画の変更に不寛容だ。前回も書いたが、誰もが失敗と思っているプロジェクトで価値がなくなっても計画通り継続してしまう。しかし、「リスクや間違いを快く受け入れる」マインドセットがあれば、計画通りいかなかったことを受入れて、計画を変更するマインドセットにつながるだろう。計画自体が仮説でしかないので、変更されるものなのだ。「Be Lazy」のマインドセットがあれば、無理に全ての物量を納期通りリリースすることに本当に価値があるかを考え直すことが できるかもしれない。
他の例でいうと、マイクロソフトで私に降りてきている方針も１年の間にずいぶん変わってしまった。数か月で変わっていく。それは健全なことだと思う。だって、状況が変化していくのだから、変化に対応することのほうがよっぽど大切だ。そういう環境にいると、時間をかけて計画を立てることはばかばかしくなる。どうせ変わるのだから。 つまり、「計画の変更」は悪ではない。現実をみて、フィードバックを受けての変更で、むしろ善だろう。そういうマインドセットをチーム内や関係者でシェアしているだけで、その人がさぼっているわけではなく、「不確実性を受入れる」マインドセットで行動しているということが周りも認識できる。そしたら周りももっとやりやすくなるだろう。
じゃあ、さぼる人はどうするんだ？という意見もでそうだ。それはまた違う習慣でお話ししたいが、性善説・性悪説があるときに「性悪説」でかんがえると、「性善説」で考える時より「ずっとコストがかかる」ということだけはシェアしておこう。是非「サーバントリーダシップ」の回をお楽しみに。
「検討」は無駄である - リスクや間違いを快く受け入れる第２の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。
最初の習慣は次のブログで紹介してみた。
simplearchitect.hatenablog.com
リスクや間違いを快く受け入れる
- リスクを背負うことは推奨されている
- 間違いを厳しく批判したり懲罰したりしない
- 失敗から学ぶ態度
- Fail Fast(早く失敗する）
- 実験が推奨されている
- 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される
- 非難や恐怖感の無い環境
この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない！
間違いや失敗に対するイメージの違い
マイクロソフトのインターナショナルチームで働いていて気づいたことだが、同僚や上司がよく「Miserably Failed(惨めに失敗した)」という言葉を頻繁に使っていることだ。日本では「決して失敗は許されない」というプロジェクトが過去にも多々あった。しかし、人間なので、いくら失敗が許されない状況だろうが、どんなにしっかり準備しようが、「失敗」は発生するのだ。日本だと、例えばこってこてに炎上して、お客さんが激怒し、中身もボロボロなのに、納期と予算を守ったという理由で「成功」したということになっているプロジェクトをいくつも見てきた。文化的にも失敗したら「切腹」したり、「左遷」されたりと、悲惨な目にあうので、日本の社会では「失敗した」ということをとても言いづらい。だから、多くの人は失敗しなさそうな無難な方に流れてしまう。本当にこれはもったいないことだ。
一方、インターナショナルチームで気づいたことだが、失敗とか、間違いとかで怒られたことは無いといっていい。失敗したり、間違いに気づいた後に、本社に「フィードバック」をすると、「フィードバックをありがとう！」と大変感謝される。そして、誰がやってもうまくいくようなことを実施しても誰も評価してくれない。例えば今、お客さんの本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこでいつも言われていることは「お客さんの最も難しい問題を解いてこい」と言われている。つまり、この世のどこにも情報が落ちていないような問題解決をやること。これが評価されるのだ。誰かが失敗しても、黙ってることもないし、失敗しても「あいつはだめだ」とか言ってる人を見たことがない。だからすごくチャレンジしやすく感じる。
だから、より難しいことへのチャレンジも大変気楽にできる。むしろチャレンジしないほうが、将来が不安だ。だから、成功しようが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく。この考えはアジャイルや、リーン、DevOps に全て共通する考え方だ。だって、普通人間は間違うんだもの。
最も恐ろしい事
この「リスクや失敗」を恐れる性質は、生産性の面で劇的な問題をもたらしている。失敗したくないので、ともかく慎重になるのだ。慎重に時間をかけたから失敗を減らせるわけでもないし、時間をかけている間にライバルは次に進んでしまう。
前にもブログに書いたことがあるが、私が米国でお客さんとディスカッションをしていて一番驚いたことがある。リックを１つだけ背負ったにいちゃんが、私とDamien に会いに来た。彼は私とDamienと１時間ぐらい話をしたあと。「うん。やろう」と言って、５００人規模のハックフェストをその場で決定して帰っていった。
日本で同じことが起こるとすると、まず、ベンダーが提案して、顧客がそれを見て、Excelで質問票を作り、、、といったやり取りを数か月行って、結局やっぱりやめたみたいなことがしょっちゅう起こる。これはベンダーにとっても顧客にとっても大きな損害だ。時間だけが過ぎて、工数を使って結局何も生み出せていない。ノーバリューなのだ。１時間で物事が決まって、実際にハックフェストを実施すると、本番環境でいろいろ起こるような検証が数日で出来てしまう。今の時代はExcelで質問票を作っている場合ではないのだ。それをしている暇があったら、実際にハックをして確認したほうが１００倍確実だろう。今の時代、いろいろ検討ばかりして、さっさと「やらない」ことが最大のリスクになってくる。
そして、こういうことが起こると、恐ろしいことに失敗確率が増える。卓上でいくら検討しても、実際やってみないとわからない。卓上でやっていたら、結局市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーは適切に動作するか？というフィードバックは、結局実施するまでわからない。だから、失敗確率が高くなる。だから少なくとも変更がやりやすいソフトウェアは、アジャイルのような早く実装して、早くフィードバックを得る方法が採用されている。さらに、機能しているものを変更して失敗するリスクがあるものを避ける傾向も強くなる。現状維持だ。
同じ失敗ばかり繰り返す人は？
じゃあ、まったく進歩せず、同じ失敗ばかりを繰り返す人はどうするんだ？と思うかもしれない。それはごもっともだ。その解答は「評価」だと思う。他の習慣で、「従業員への信頼」という習慣がある。人に対してごちゃごちゃ細かいことは言わない。最初に会社と合意したゴールつまり大まかなKPIを達成していたら、失敗しようが、人より不器用だろうが何だろうがいいのではないだろうか？その人を信用しよう。
できないのなら、評価のタイミングで KPIが達成しないので、給料が下がったりクビになる。ただそれだけの話だ。だから、評価はそのタイミングでよくて、失敗は結果論であるので、それよりも「フィードバック」を得たかを気にしよう。私のパートナーのクロスカルチャーの専門家のロッシェルさんがこういう話をしてくれた。米国では、プロジェクトが中止になったら、プロジェクトが成功したのと同じようにパーティをする会社があるらしい。なぜなら、その失敗から「学ぶ」ことが出来たからだ。
この「習慣」は生産性に非常に影響してくるものだ。逆にいうと、これを身に着ければ、簡単にライバルに差をつけることができる。 じゃあ、この「習慣」を獲得するにはどういう方法があるだろうか？
「リスクや間違いを快く受け入れる」プラクティス
- 成功・失敗より「フィードバック」を歓迎するムードを作る
- 「検討」をやめて「実証」する
- 「早く失敗」できるように考える
それぞれについて解説してみよう。マネジメント、チーム、プロダクトオーナ（チームに出すリクエストをきめる人）のロールがある場合、どういった順番で重要なプラクティスだろうか？
対象者
- 上位マネジメント
- プロダクトオーナ
- チーム
これもほぼ全員だが、誰かが、誰かの「失敗」を責めるケースが多い順に考えてみた。
1. 成功・失敗より「フィードバック」を歓迎するムードを作る
最初のプラクティスだが、チームメートや部下が成功したら当然喜んであげたい。失敗して、フィードバックしてくれたら、失敗する方法がわかったのでこれは大きな進歩なので、感謝しよう。失敗して「怒る」ということはあなたと対等である人を「子ども扱い」しているのと同等だ。そういう気持ちはわかるが、「怒る」という選択肢はなくして、「フィードバック」を促進するようにムードを作ろう。 たとえば、メールで、成功の報告を見たら、みんなで「おめでとう」のメールを返そう。メールで、失敗とそのフィードバックをしてくれたら「感謝」のメールを返そう。マネージャなら、本人の評価はあくまで約束したKPIの達成の可否であり、小さな成功や失敗ではない。そういうことを明確にしていこう。このムード作りは、上位マネージメントの方から仕掛けていただくほうがいいかもしれない。
2. 「検討」をやめて「検証」する
あなたがユーザ企業や上司ならば、パワーポイントに書かれた大量の資料を要求したり、完全無欠の検証を期待するより、時間をかけず、さっさと「検証」してフィードバックを得るようにしよう。人間未来は予測できない。例えば、あなたがユーザなら、ベンダーに「提案」を依頼すると、例えば私が大手のSIに勤務しているときは、提案書を作るのに何人もの人が数週間もかけて作っていた。しかし、正直に言うと今の時代、大量に検証しても制度が低いし、マニュアルに「出来る」と書いてあっても実際作ってみるとできないなんてことはしょっちゅうある。その工数は、あなたがそのベンダーに発注したときにOnされてね返ってくる。Lose-Loseの関係だ。
そんなのよりも、クラウドの時代でさらに加速したが、実際に作ってみるほうがよっぽど早い。そして、過去と比べると圧倒的に早くできてしまう。だから、ああでもない、こうでもないと検討するのではなく、実際に作ってみる「ハックフェスト」などを通じて、動くもので検証しよう。 ほかにもあの機能を実装するべきか、この機能を実装すべきかと検討している暇があったら、実際に実装して、ベータテストで実際のお客様で試してデータを取ろう。思ってもない結果になるかもしれない。 今の時代最もリスクなことは「何もしない」ことだ。検討している暇があったら、今すぐ実装して試してみよう。データをとろう。
例えばアーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがある。それを意思決定するのは簡単だ。答えは「どちらでもいい」ので趣味で選べばよい。なぜなら、圧倒的に差があるのなら、決めあぐねるはずがないので、どっちを選択しても大差ないということなのだ。 また、昔と違って、ツールやサービスの単価は高くない。１つのツールで失敗したら次のにさっさと乗り換えればいい。つまり比較検討など無駄だ。それより早く前に進もう。実践の経験を積み重ねるほうがよっぽど貴重なことだ。
3. 「早く失敗」出来るように考える
これも、2.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。例えばウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。つまり、実際の「フィードバック」を受けるまでの時間が長い。これが問題だ。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう！
いかがだっただろうか？もっといいプラクティスがあるかもしれない。私もまずは３つをピックアップしてみた。もしもっといいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。
Scrum / DevOps の導入を加速するグローバルマインドセット ～８つの習慣 その１ ～
クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「８つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。
今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「８つの習慣」を初めて発表させていただいた。
「８つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうまくいかなかったり、効率が悪くなってしまう。
そこで、米国並みのスピードでの技術導入や、本質的な導入を目指す方のために、「８つの習慣」を考案した。 Agile / DevOps の導入を本質化し、加速するための西洋文化のマインドセットだ。日本人は「生産性」が悪いせいでグローバル的には大変損をしていると思う。それさえ何とかなれば、日本人の文化の良さを生かして、ソフトウェアの世界でも輝ける存在になると私は信じている。重要なことは、西洋を崇め奉りたいわけではなく、日本文化と西洋文化の考え方を「選択可能」にすることだ。
ただ、講演では時間が４５分なので、すべてを解説する時間がなかった。まずは「興味を持ってもらう」ということをターゲットにしたので、「実際どうすればいいかわからない」だろうとう反省がある。今後ロッシェルさんとビデオを公開して「８つの習慣」をより学びやすくするつもりだが、このブログでも不定期に「８つの習慣」が何で、具体的にどういうことをすれば導入できるかについて解説していきたい。
「８つの習慣」を理解する方法
「８つの習慣」は「マインドセット」なのでなかなかに理解が難しい。ただ、一番簡単な方法がある。米国人、もしくは、西洋人のチームに参加して１年も一緒に仕事をするといい。そしたら簡単に彼らのマインドセットを体験できるし、その破壊力を体験できるはずだ。そして、彼らが「人として優れている」とかではなく、我々でも十分できる「習慣」のために生産性がいいことを体験できるので、簡単にマネできると思う。
ただ、問題は、そういう環境にいる人は国内にはあまりいないということだと思う。だから、そういう人のために、国内にいても、そういうことを学べる方法はないだろうかとロッシェルさんと一生懸命考えたものだ。もちろんまだ出来たてなので、まだまだの部分はあると思うが、それでも改善を進めながら、技術導入を本当に加速したいと思っている人がにお役に立てればと思う。
「８つの習慣」
- Be Lazy
- リスクや間違いを快く受け入れる
- 不確実性を受入れる
- サーヴァント・リーダーシップ
- セルフマネジメントチーム
- 従業員への信頼
- 個人の自信
- 階層関係のパワーバランス
これがロッシェルさんとディスカッションして整理した、「８つの習慣」だ。我々がAgileやDevOpsをうまく導入するために必要な西洋のマインドセットを整理してみた。 今回は最初の習慣である Be Lazy から具体的にどういうことをすれば、導入できるのかということに関して考察してみたい。
Be Lazy
この習慣は、スクラムや、リーンの世界でもよく言われており、アジャイル以降の開発で大変重要なポイントになっている。このブログでも何回か取り上げているが、一言でいうと「より少ない時間で価値を最大化するという考え」だ。この考えを学ぶにはエッセンシャル思考という本を読むのが一番おすすめだ。
Be Lazy を達成するための習慣
- 望んでいる結果を達成するために、最低限の努力をする。
- 不必要や付加価値のない仕事をなくす（過剰準備含む）
- 簡潔さを目指す
- 優先順位をつける
- 時間や費やした努力より、アウトプットと生産性に重点を置く
- 長時間労働しないように推奨する
- 会議は会議の時間内で効率的かつ生産的に価値を提供する
このBe Lazy の一覧を見ると、たいていの人は「当り前じゃないか？」と思うのではないだろうか？そこに落とし穴がある。例えば「優先順位をつける」という項目について考えてみよう。よくスクラム等で言われる言葉で「バックログに優先順位をつけて、優先順位の高いものに集中しよう」ということがある。この言葉を聞いて、私のような日本人の人にイメージされるのは次の図の左のようなイメージじゃないだろうか？
リストに上がっているタスクが５つぐらいあるけど、「全部できないから、優先順位をつけて、どうしてもできないのは無理だから実施しないようにしよう。でも時間が許せば全部実施したい。」ところが、同じ言葉に対して、海外のメンバーを観察していると、右のようなイメージをもっているようだ。「最初の１個をピックアップしてやったら他はやらない。その１つのフォーカスする」ぐらいの感じだ。
こういう場面はインターナショナルチームにいるとしょっちゅう目にして、そのたびに驚いていたが、例えば、バリューストリームマッピング（上記の図をプロジェクトメンバで作成しプロジェクトの無駄を発見するセッション）を、同僚のデビッドとやった時に、彼は「リリースマネージメント」というDevOpsプラクティスの一つしかアドバイスしなかった。帰りの車で彼に聞いた「私から見たら、それ以外にもDevOps プラクティスである Automated Testing もできていないし、承認作業多いのでビジネスプロセスも変えないといけないし、ほかにも沢山あるじゃない。なんで一つだけしか言わなかったの？」と聞いたら「だって、沢山言ってもそれができるかな？まず大切なことは一番インパクトのある一つを確実にすることが大切なんだ」と彼は言っていた。
我々はすぐに「あれも、これも」やらないといけないと思ってしまうが、「すべき」より、「実際にできるキャパ」を考えるほうが生産性的には有用だ。2-8の法則でも、20%の仕事が80%の価値を生むのだから、20%をしっかりやるとよくて、100%全部やろうとするから工数もかさむし、アップアップになってしまう。
我々の傾向としては、100個のタスクがあったら、100個やろうとする。たけど、本当に重要なのは20%程度だろう。そういう知識があっても、20%のタスクが終わって80%の価値がでても、残りの80%の仕事をして完璧を目指してしまう。でも、彼らを観察していると、20%のタスクを終えて、80%の価値をだしたら、残りの80%はやらずに、次の80%の価値を生む20%の新しいタスクに取り組む感じだ。そうすれば、100%の仕事をしたケースに比べて、40%の工数で160%の価値を持つ仕事ができることになる。
ざっくりとしたイメージで言うと、彼らが無理なく生産性が高い理由は、こういう理由だ。つまり、実施すべき「物量」が少なく「価値」が高いものを如何に作っていくか？の工夫を常日頃からしているのだ。
simplearchitect.hatenablog.com
彼らが優秀とかではなく、「やることを減らすか？」ということに注力している。多くの人は、例えば多くの機能を速く実装することはよいことと思わないだろうか？本当は「悪」である。なぜなら、統計によるとソフトウェアの機能のうち４０％ぐらいしか使われない。だから、100%を全力でつくったら、60%が使われない。しかも、その60%でバグが発生したら直さないといけないし、60%もコードベースが多くなるので、変更があった時にコードを読む量がさらに増えてしまう。
つまり、「やることを減らす」ことは大変素晴らしいことなのだ。ところが我々の感覚からすると、全部やらないのは、何となく悪いことに感じてしまう。だから、いまある手続きや、やり方を「減らす」のは苦手だ。だけど、重要なことは「価値」であるのと同時に、「減らすこと」自体は非常に価値がある。
例えば、マイクロソフトに在籍している間に２回報告システムが変わった。どんどん手続きが「楽」になっていっている。ミーティングも毎週だったものが、２週間に１回になったり、１年に４回あったレビューが少なくなったりとか平気で起こっている。そうすれば、それに使っていた時間が他の優先順位が高いことに使えるのだ。 しかし、「価値」というものはよくわからないものだし、どうして「より短い時間で、価値を最大化する」ことができるだろうか？ 次のようなことを実施してはいかがだろうか？
Be Lazy プラクティス
いくつかセルフチェック出来そうなプラクティスを考えてみた
1. ひとつだけピックアップする
2. 時間を固定して、出来ることを最大化する
3. 過剰な「準備」と「後でやる」をやめる
我々は西洋系の人と比べて、完璧主義の傾向が強いと思う。重要なもの、そうでないものも同じ感じで「ピカピカ」に磨いてしまう。だから時間がかかってしまう。ただしこれは、いい点も悪い点もある。例えば西洋の人は「ピカピカ」に磨く能力が我々に比べてない気がする。我々に問題なのは重要じゃないこともピカピカに磨いて工数をつかってしまうことだ（例えば、文章を書くときにExcelの細かいレイアウトまでこだわるとか）。これをやめたら、生産性が上がって、西洋の人と生産性で競争できる上、重要なことだけ「ピカピカ」磨いてやれば、ものすごい競争力になるはずだ。だからまずは、見習うところは見習うほうがいいのでは？というのが私の考えだ。
対象者
スクラムや DevOpsチームでの使用を想定するとすると、本プラクティスをマスターしておくとよい人は次の人だ。
- プロダクトオーナ
- 顧客
- チーム
- 上位マネジメント
つまり、全員が該当する。ストーリの優先順位づけや、機能のどれを実装するか否かという場面で非常に生産性に影響する。だから、プロダクトオーナや、顧客が特に深く理解している必要がある習慣だ。もちろんチームメンバも、本当に必要な機能、そして不要な機能をプロジェクト全員で見つけだすために、重要になってくる。また振り返りを行い、プロセスの改善を実施するときも如何に「楽」をしてより高い「価値」を生み出せるか、何を「やめる」かをディスカッションするための基本的なマインドセットとなる。
さて、これらのプラクティスについて解説してみよう。
1. ひとつだけピックアップする
これは、インターナショナルチームで周りの人を観察して彼らのように出来るようにマネして実施しているプラクティスだ。私は優先順位をうまくつけるのが彼らに比べて本当に苦手だ。あれも、これも大切に見えてしまう。だから、そういう時は、思い切って、一番重要なのはどれか？と考えてそれだけやろうと考えるようにすると、ちょっとマシになってきた気がする。最終的に３つピックアップするケースでも、まず最初の１つだけピックアップする癖をつけている。そのあと残りの２つをピックアップしている。
自分がやるべきと思っていることをスルーするのは恐怖があるが、結局それを受け取った人もたくさんだと理解できないのだ。最大でも３つぐらいだろう。一番重要な「ひとつだけ」ピックアップする癖をつけると、時間が無くなった時も、少なくとも「一番重要」なことは実施できている状態になれる。
そうしていくと、「やらないといけない」と思ったことをやらなくても、結局問題にならないことがわかってくる。どうでもいいことを１０やるより、１番重要なことを時間をかけてしっかりやったほうが大抵のケースはうまくいくし、沢山のことをいっぺんにやっても、本人はやった気になるけど、忙しいだけであんまり成果が出ていない感覚になる。
すべてのケースで「ひとつだけピックアップ」が通用するわけではないが、「ひとつだけピックアップ」のプラクティスを３回繰り返せば３つピックアップできる。しかし、重要なのは、１０個のうち２個しかやらないことは決して悪ではなく、そっちのほうが「バリュー」として効果的なことを「体感」し、「やらないこと」の恐怖を克服するのがこのプラクティスの目的だ。是非お試しあれ。
2. 時間を固定して、出来ることを最大化する
「すべき」思考で考えると、どうしても、時間を「延長」してしまいがちだ。彼らを観察していると、「すべき」から時間を計算するのではなく、「時間」は固定して、その中で価値を最大化するという行動をとっているように感じる。
例えばロッシェルさんと打ち合わせをするときも、時間が延びることはほぼなく、「あれも、これもやらないといけない」とお互い思うのだが、この２時間で出来る範囲のなかで、「最大にバリューが出ることにフォーカスをすると、これと、これなので、今日はこの２つだけやろう。」すべきことを全部こなそうというより、時間が最大の制約なので、この時間内に確実にできる数に絞って、最大の成果を出せることに集中する。みなさんも、なんも準備できていなけど、明日プレゼンだとかいう場面はないだろうか？その時のイメージを思い出すといいかもしれない。多分無理なものはあきらめてバッサバッサと作業を切り捨てているはずだ。それを無理ない個数に絞り込んでやるイメージだ。
だから、「きれいなドキュメント」なんかは作っている暇は当然なく、「やる事」の数を減らして時間内にできるようにして、やったらよさげなこともばっさばっさと切り捨てて、その場で出来るだけ早く意思決定するようにせざるを得なくなる。 「まだ完璧じゃない」「抜けてることがあるかもしれない」ことが最初は怖かったが、「抜けている」ようなことは大抵対して重要じゃないのだ。抜けていて困ることもあるかもしれないが、それは、何かを実施したら、フィードバックを得られるので、「心配」せず「実施」してしまえばいい。
例えばこの「８つの習慣」も完璧かは知らないが、世に出して、フィードバックを受けたほうが悩んでるよりよっぽど生産的だろう。
3. 「準備」「持ち帰り」をやめてその場で解決する
ポイントとしては、何かの作業、例えば会議をしているときに、「会議の場」のみで完結するように訓練することだ。彼らを観察していると、ざっくりしたアジェンダはあるが、準備に時間をかけて会議に臨むということはしない。さらに、会議が終わった後に「宿題」とか「もちかえって検討」とかそういうことがない。つまり、会議に出たら「会議の時間内だけで完結」する。これは大変生産的だ。 日本の会議のときは、会議の前の準備があって、会議が終わった後も、検討したり、議事録を書いたりいろいろしないといけない感じだった。
インターナショナルチームを観察していると、彼らは常に「会議の場」だけで完結される。議事録もその場でOneNoteにとって共有される。 例えばロッシェルさんとのプレゼンテーションの会議をしているときも、「ここと、ここを修正して後で直しておきます」ということはせず、その場でプレゼンを修正する。そしたら終わった後に時間を取らなくていい。そして、会議の時間の間にロッシェルさんに共有する。意思決定も、持ち帰って検討しますではなく、間違っててもいいので、その場で意思決定してこうしようと決める。
昔のブログエントリで書いたが、こういうことを元から実践している人がいる。ソニックガーデンの倉貫さんだ。私がコンサルタントの時、彼と仕事をした時の一言は忘れられない。
牛尾さん。会議の準備をしないでくださいね。無駄だから。そうではなくて、会議の時間を価値の高いものにしましょう。
彼との会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。もし、どれぐらい「準備」をしなくてもいいのか？がわかりづらいなら、いっそ準備「なし」でどの程度できるか体験してみるといいだろう。そして、出来るだけ「会議の時間内」のみで完結できるように頑張ってみる。そうすれば、思ったより「できる」ことに気づくのではないだろうか？ できない場合は、きっと、「余計なこと」を頑張っている可能性が高いので、会議のゴールに不必要なものを減らしていく練習をするとよいだろう。
おわりに
これらの３つのプラクティスは、もちろん簡単ではないとは思うし、実際の例を見ないとなかなか理解できないかもしれない。「どれぐらい」ができている状態かわかりずらいかもしれない。
だけど、これらを「意識」してみて、「実践」していると、だんだん上達してくるし、こういったことが「出来ている」人を目にするとアンテナが立っているので「あーこれぐらいできればいいんだ！」という気付きを得やすくなる。少なくとも意識して「実践」してみるだけで、かなり変わってくるはずだ。
次回は「リスクや間違いを快く受け入れる」習慣について書いてみたいと思う。
「知らないこと」を恐れないマインドセットが技術導入を加速する
先日、米マイクロソフトの Redmond キャンパスで行われたマイクロサービスのハックフェストに２週間ほどサポーターとして参加してきた。 そこで気づいた日本との技術導入の差の秘密について気づきをブログに書き留めておこうと思う。
ハックフェストというのは、お客様のガチの環境もしくはそれに近い環境/テーマで行うハッカソンだ。
例えば DevOps の文脈であれば、自動化したら効率化されそうな部分に関して、マイクロソフトの製品チーム、エバンジェリストがサポートしながら、お客様自身が我々と一緒にハックをして、実際にお客様の環境を自動化してしまうようなイベントだ。 Hello Worldやチュートリアルレベルではないので、お客様の環境が本当に自動化されてリードタイムが短縮されたり、我々にとっても、現場の難しい問題を知り、それに対してソリューションを作ることができるので、スキルアップまでできるので私は大変気に入っている。マイクロソフトはこのイベントをプッシュして展開している。
さて、今回のイベントは、米国、カナダ、欧州のマイクロソフトのパートナーを集めてマイクロサービスのハックフェストを実施していた。ほとんどのパートナーは、Service Fabric というマイクロソフトの激アツのマイクロサービスの PaaSサービスを試していた。
私が驚いたことに、Service Fabric はまだ出てそんなに経っていないというのに、ガンガンに使ってたり、基幹業務系に使っていたり、通常はクラウドサービスなのに、オンプレに自らインストールして使っていたりとそのレベルの高さに本当に驚かされた。
彼らとディスカッションをしても、正直相当レベルが高かった。普通にBoundary Contextとか、Conways's Lawとか、DDDとか普通に知っていて当然のように活用している。一体この差はなんなのだろうか？今回は、２回 x 5日間のハックフェストを体験して気づいた彼らの新しい技術に対するマインドセットをシェアしたい。
準備不足からくる不安を感じる
正直このハックフェストが始まる前に、私は相当準備をしていった。Service Fabric はとても便利だが、マイクロサービスの基盤なので、しっかり理解しようとしたら相当いろいろ学ばないといけない。 私は事前に自分でコードを書いたり、CI / CD パイプラインを作ってみたりしていた。そうでないと、私はハックフェストで役に立つはずがないから。しかも、相手の会社さんは毎日のようにプロダクションでService Fabricを使い倒しているパートナーさんもたくさんいる。しかも、日本より技術的に進んでいる米国でのハックフェストなので、正直いうと通用するか相当自信が無かった。自分の準備が十分かどうかわからないままハックフェストがスタートした。
Julien 衝撃のひとこと
初回のハックフェストは、DevOpsチームからは私のみの参加だったが、２回目のハックフェストでは、Julienという同僚が参加をしてくれていた。その時に、私が彼に「来てくれてありがとう！ちなみにService Fabricどれぐらいやったことあるの？」と聞いた時の彼の返答は衝撃だった。彼は自信満々にこういった。
やったことないよ。
えええええーーーーこんなガチのハックフェストなのに！そういえば、日本であったBot frameworkのハックフェストの時に来日した、むっちゃ技術力の高いEricに、Bot frameworkの経験を聞いた時も「やったことないけど、今日やるわ」だった。当時は彼は死ぬほど優秀だから、できちゃうんだろうなと思っていた。もちろんJulienは最高に優秀だけど、難易度の高く、ユニークなマイクロサービスのPaaSにノー準備で挑むってどういうことだろう？すごい度胸だ。彼もむっちゃ優秀なんだなと思っていた。
準備を全くしなかった人の成果
初日が終わって、彼はとてもエキサイティングしていた。彼はハックフェストのおかげで、IaCを使った、ADのセキュアクラスタの構成も体験できたし、CI／CDパイプラインもできてとても良かったと言って喜んでいた。 ガラス越しに彼がサポートしているチームの部屋を見ると、彼が堂々と、ディスカッションしている様子が見れた。後日談だが、彼のサポートしたチームはDevOpsの要素で素晴らしい成果を上げていた。この時点でも、私は単に彼が優秀だと思っていたのだが、あることで考えが変化していった。
Jason の提案
私は 幾つかのチームをサポートしたのち、最後にJasonというエバンジェリストのいるパートナーのルームを支援していた。このチームは、パートナーが作っており、リリースされているプロダクトを、Service Fabricで動かしてみるというガチハックをしていた。担当の彼はMVPで相当レベルが高い。
私はCI/CD を支援する予定だったが、まだ、彼がマルチパートのデバッグで苦労しているので待ちの状態だった。そんな時、Jsonは彼にこういった。
「俺に見せてよ。一緒にデバッグしよう」
製品のコードを書いているのは、彼だし、Jsonがコードのことを知っているはずもない。自分は「は？」という気分だった。そして、「これが原因じゃないか？」と言って彼と一緒に原因を探り始めた。彼が「知っているはずもない」ことについて。 その姿を見て、Eric, Julien, そして、Jsonの行動に関してあることを思いついた。彼ら、米国の技術者がいろいろできるのは、すでに準備して勉強しているからではなくて、「知ってようが、知っていまいが、とにかく躊躇せず一緒にやってみるから」じゃないだろうか？
そう思った私は、Jsonと一緒に彼のデバッグを手伝うことにした。コードを読んだり、インターネットを調査したりして一緒に取り組んだが、問題を解決したのは、彼らより、もっとコンテキストやその技術を知らない「私」の仮説だった。彼も、Jasonもとても喜んで我々はハイタッチした。もちろん私も、完璧にそのコードを理解したわけではないが、他の３人とディスカッションしながら進めることで、そういった仮説にたどり着くことができた。みんなの勝利だ。
私の仮説は
彼らは、もともと、「知っていた」から優秀なのではなく、準備ができてようが、知ろうが知るまいが、果敢に本番環境に近い環境で、実際に適用してやってみて、そこから学んでいるから優秀になるスピードが速いのでは？
ということだ。確かに、検討をいくら重ねても実力はつかないし、結局のところ本番環境で発生する問題には対応できない。
「とにかくやってみる習慣」がスピードを生む
私は、まず調べて、理解してできるとわかってからやるというステップを踏む癖がある。日本の多くの企業もそうじゃないだろうか？その技術が十分に使い物になって、本番でも本当に問題なく使えるということがわかって導入する。そして、あのケースはどうだろうか？このケースはどうだろうか？と思考をめぐらす。
一方、彼らを観察しているともっと単純に考えているように感じる。この新しいテクノロジーを使うと、この問題が解決しそうだからまず適用してみる。ぐらいのノリで、単純に考えてそれを実行する。実行すると決めたら、そこのマニュアルがなかろうがバグを踏もうが、回避策を考えて実際やってみてそこから学んでいく。あれこれ検討していると、時間だけ過ぎていくが、その間はノーバリューだ。しかも、長い間検討したからといって、良い回答につながるかはわからない。
だから、まず「こうだったら、難しい」「ああいう時は上手くいかない」ということを考える前に、まず適用してみて、そこから学びを得ているように感じた。早く実践して、そこから学んで方向修正をしていく方が結局早い。DevOpsのプラクティスにも、Testing in production という考えがあることを思い出した。
この２つの思考スタイルにいい悪いは特にない。ただ、おそらくソフトウェア産業においては後者のスタイルのほうが圧倒的にスピードが出やすいだろう。なぜなら、現在のソフトウェアは、バージョンアップや、新しいサービスの出現のスピードが非常に早い。だから、それが本当につかえるか調査しているうちに次のバージョンが出てしまう。
「知らないこと」を「悪」にしない空気が重要
彼らは何をするにもあまり準備をしない。そして、時間内で如何に成果を出すかに集中する。だから、彼らは「知っている、知らない」とか「準備できている」とかは、さほど重要ではなく、それぞれのメンバーが貢献できるところで貢献して、全員で成果を達成するという感覚が強いように感じる。誰がどんなスキルをどれだけ持っているとかはあまり誰も気にしない。 だから、私が知らないことがあっても、一回も不平不満を言われたことがない。
ただ一つ言えるのは「知らないけど、一緒にやってみましょう」は非常に評価されるということだ。今の時代、たとえマイクロソフトに勤めていても、そのサービスの全容を把握するのは一人の人間では不可能だろう。 これはマイクロソフトだけではなく、一つのサービスの全容を一人の人間が把握するのは無理になってきていると思う。一人のスキルですべてカバーすることも。 日本だと、プロが「知らないこと」があると、批判の対象になりやすいが、これは恐れを生んで、必要以上の準備につながっていると思う。だから、「知らないこと」があっても、当然であるという空気作りも重要と思えた。
日本では、「知りません」というのは勇気がいるが、向こうのメンバーを観察していると、本当は多少知っていることでも、「知らない」と簡単にいうのだ。「知らない」のは何も恥ずかしくない。ただ、彼らはそれでもその場で問題を解決しようとする。 助けを求めたり、人に聞いたり、お客さんと一緒にハックしたり。持ち帰りをせず、その場で解決しようとする。
「知らないこと」にアタックすることで成果が出やすくなる
ハンズオンやレクチャーの形式というものは、結局のところある人の知識がある人に移転することでしかない。ハックフェストは一つの例だが、誰かが一方的に物事を知っている事を準備するのではなく、とにかく集まって、みんなの頭脳を結集して、問題を解決するスタイルだと、二人分の知識どころか、二人が知らなかった部分にもトライすることになる。そうすると、その時間内で二人が従来持っていた以上の知識を獲得することになる。これはとても効率的だ。
新しい技術の獲得、適用に関してもこういう性質が関係しているかもしれない。実は新しい技術の初速のキャッチアップは日本の方が最近は優れているように感じる。例えばマイクロソフトの大きなイベントがあっても、次の日にはすでにまとめサイトができあがっている。これは早すぎる。
しかし、そのあとにその技術を本当に使われるか？となるとそうはならない。一方米国では、初速ははやくないものの、自分たちのアタックしたい問題にそれをともかく使おうとする。リスクの検討をがっつりするのではなく、これを試してみようとおもったら、とにもかくにもやってみる。
そして、知らないことにチャレンジしていくと、実際の問題に対応しているので複雑で難しユースケースにも対応していくことになるので経験が積まれる。さらに、自分がわからない状況でもどうやって問題を解決していけばいいか、その場でどうやってバリューを出していけばいいか？という訓練ができることになる。
米国では、技術者は基本コンピュータサイエンスを出ているというのもあるが、それよりも、あれこれ考えず素直に「ともかくやってみる」 作戦によって、たくさんの工数をかけることなく、効率よく新しい技術を獲得してスキルアップしていっている気がする。
日本でどうやってスピードアップをしていくか？
言葉だけは知っていたが、日本人の性質として語られるものに「不確実性の忌避」というものがある。不確実なものを嫌う性質だ。今回の体験で、文化の専門家が語る「不確実性の忌避」の性質の具体例を自分で体験できた気がした。自分はチャレンジングな性質だと思っていたがその自分がしっかり「不確実性の忌避」の性質をしっかり持っていたのだ。 こういう日本の「文化」に基づく、スピードの遅さに対処する方法としては、私は「西洋文化インストール」と言っているが、彼らの考え方を理解するところから始めるといい。大抵それは、彼らが優秀だからできることではなくて、それが理解できれば日本でも全然実践可能なものばかりだからだ。だから、チームで、マインドセットに関してチーム内でシェアして、チームがそれを気に入ればその考えで作業を進めると楽なことが多くなるだろう。
例えばこんなマインドセットでどうだろう？
「Just Do It」
- 自分の仕事に自分が主体性を持つ
- 知らないことは悪ではない
- 知らないことでも、自分のできる範囲で他の人を助ける
- 準備しすぎていないか？、何をやらなくてもいいだろうか？を自己に問いかける
- 例外をあれこれ考えず、単純に新しい技術をまず本番適用し、本番から学ぶ
これは、DevOpsのマインドセットにもつながる内容だ。このマインドセットは結構難しい。可能であれば米国の開発チームと一緒にはたらくと日本人でも、この辺りの感覚がわかるようになる。 次善策としては、皆さんのチームに、上記のマインドセットをグランドルールとして開発を進めてみるのはどうだろうか？
「知らないこと」のハックフェストが怖くなくなった
私もこのことに気づいてから、スタイルを変えるようになった。このハックフェストが終わった後Redmondのエバンジェリストチームの同僚が「Tsuyoshiお前、NodeJS強いか？」と言われた。今までだと「イヤーごめん、強くないわ」と言っていたところをこういってみた「さわったことあるよ。そこまで強くないけど。何が問題？」と言ったら「君の助けが必要だ」といって彼のオフィスに連れていかれた。 どうも認証周りがうまく動かないみたいだ。私は一緒にコードを読んで、とあるコールバックの部分の記述についてアドバイスしたらそれが正解だった。私はNodeJSなんて触ったことぐらいしかないし、彼はむっちゃいけてる技術力のあるエバンジェリストだけど、自分が知っているか、知らないかは気にせずとにかく彼を助けてみた。
すると、自分もHello Worldレベルじゃない、NodeJSのコードを読む機会に恵まれたし、彼は早く問題を解決することができた。会議に出ても、自分が現状で持っているものを活用し、知らないことも、相手に聞く、相手と一緒に考えるなりして、その場でその問題を解決するような方向性に変えているが、結構かなりいい感じな気がしている。
「知らないこと」を恐れず、楽しむ習慣
その後「知らなくても」一緒にハックする習慣をつけると、その後の顧客からも常に喜んでもらえるようになった。「本当に生産性が高かったよ！」と。私はただ、知らなくても、知っていても一緒に「問題解決」を「その場」でしようとしているだけだが、これがかなりの効果とスピードを生んでいるようだ。自分のレベルが変わったわけじゃない。以前は「知らない」状況は非常に怖かったが、今は「知らないこと」が来ても成果が出せることがわかってきたので、逆に「知らないこと」がやってくると嬉しくなってくるようになった。
おわりに
こちらに来て何度も思っていることだが、彼らは日本より進んでいるし、技術力も総じて高いと思うが、個人の個体差が大きいわけじゃ 決していない。本の小さな「習慣」や「考え方」がちょっとだけ違うだけで差がついているだけだ。これは非常にもったいない。先ほど書いた日本の「準備を入念 に行う」「例外ばかりをたくさん考えてしまう」マインドセットは、時間をかけて精緻なことをしたいときは非常に役に立つだろう。 実際私がハックフェストや、同僚の問題を解決できたのは日本人のこの性質な気がする。 こういう日本人が、彼らの「速さ」の原因になっているちょっとしたマインドセットを獲得すれば、ガンガンに世界でも同じように活躍できるようになると思う。だから、私もいろいろ試して調査して、そして個人的に気づいたことをシェアしてきたいなと思っている。
ハックフェストの成果として、Service Fabric のデプロイメント戦略について書いておいたの蛇足だが記載しておきたい。
Serverlessconf 最高でした！ーAWSな人に贈る、最も簡単に分かる Azure の Serverless
10/1に、ServerlessConf 出店ブース始め、会場におられる方も、AWSを利用されている方がほとんどだった様子だったので、講演では、AWSを普段使っておられる方を想定して、お話しをしました。ただ、盛り上がった一方、詳細なアーキテクチャが知りたかったとか、AWSのλとの違いがわからなかったというご意見をいただきましたので、そういうフォローアップ記事を書いてみようと思いました。
個人的には、Serverless は、Microservicesの次のパラダイムぐらいの勢いがありますが、どのような利用がされているかのアイデアとその未来を知りたくて参加しました。ちなみに、スポンサーセッションと思われていますが、一応、スポンサーセッションではなく、サブミッションを出しています。本イベントは、非常に熱気があり、学びも多く、素晴らしいイベントでした。こんなにも素晴らしいイベントをこんなにも早く日本でも開催いただいた、主催の吉田さんに本当に感謝です!
では、早速、AWSな人に贈る Azure のServerless のお話し、そして最後に、私が感じたServerless の未来についてお話ししてみたいと思います。
1. 講演概要
講演の概要は、9/26-30 まさに直前に行われたMicrosoft Igniteでの発表の資料を中心に、いくつかのデモを加えて行われたものです。講演資料はこちらになります。講演資料は、当日、日本人と海外の方が両方おられたので、英語の資料で、日本語で講演というスタイルにしました。
2. Azure Functions (AWSのλっぽいもの)
Azureでの、Serverless のサービスは、Azure Functions というサービスです。一緒に講演した、佐藤(NEO)直生さんが、当日早速 Getting Started 等のURLを整理したブログを書いてくれたので共有したいと思います。
[ServerlessConf Tokyo] Serverless Patterns with Azure Functions (Azure Functionsでのサーバーレス パターン)satonaoki.wordpress.com
このサービスは、元々 Azure で使われていた、WebJobs という仕組みが元になっています。何らかのトリガーをきっかけに、バッチ等 の小さなプログラムを動かすこの仕組みは、Serverless のAzure Functions を動作させるためには最適な仕組みでした。
AWS のλに相当する Azure Functions は Azure の PaaS 基盤である App Service の上に構築された仕組みで、Web Appsをはじめとした、例えばWebのPaaSを使っていれば、そこにサーバーを新たに建てることなく、バッチを実行することができました。 そして、C#はもちろんの事、様々な言語で動作します。中身は現在のところ、Windowsサーバーがベースとなった、Windowsの技術がバックグラウンドにあります。ただ、このWebJobsを創るためには、そこまで大変ではありませんが、ちょっとめんどくさい部分があったのは事実でした。
2.1. トリガ
Azure Functions では、Severless を実現するため、この仕組みをつかって、そもそもの Web Appsすらも起動することなくこのサービスを利用可能にしました。想定するシナリオとしては
- Timer
- Data Processing
- Webhook + API
それに加えて、Blobストレージ(S3相当)へファイルをアップロードする、Queueにメッセージを投げるなどのきっかけを元に、プログラムを実行します。結果は、Blob(S3相当)、HTTP, ServiceBus (SQS相当)、データベース、通知のハブや、SendGrid, Twilio へのサポートをテンプレートレベルでサポートしており、他のものも自分でコードを書けば何とでもなります。
2.2. インプット / アウトプット
インプット、アウトプットのリソースとしては、様々なサービス、プロトコルと連携します。下記の図がわかりやすいと思います。
Azure Functions の画面では次のようなイメージでインプット、アウトプットを設定できますし、設定ファイルでももちろん設定できます。
2.3. 言語
使用できる言語は、C#, Node.js, F#, Python, PHP, 等、、、と書いています。他にもBashや、Cmd、PowerShell等も動作するみたいですし、私の同僚は、Goを動かすものを書いていました。
2.4. プログラム構成
これはC#の例ですが、下記のようなプログラム構成になっており、run.csxがC#のファイルです。function.json が設定ファイル。そしてproject.json は、nugetパッケージ（npm や、Ruby gemsの様なもの)を取得するために使えるファイルです。
function.json
{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "pictures",
"connection": "pooryou_STORAGE"
}
],
"disabled": false
}
project.json
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.ProjectOxford.Face": "1.2.1.2"
}
}
}
}
今回私がデモで使用したソースコードは、簡単ですが、GitHubにあげておきました。より細かい情報は、佐藤さんがPowerPointの資料に書いてくれています。より細かいプログラム構造(nodeの場合)、使える言語、トリガの種類などです。
2.5. AWS λと比較したメリット
ブースにいるときにAWSを普段使っておられる方から、「ここはAzureのほうがいいね！」と言っていただいたポイントがいくつかあったので、それを共有しておきたいと思います。私も深くAWSの事を知っているわけではありませんが、あくまでブースに来ていただいた人から学んだことですので、細かいミスなどはご容赦ください。また、そういうものがあれば本ブログをリンクして是非皆様のブログでフォローしていただければと思います。
これは個人的な意見ですが、ざっくりうと「すべてをコントロールしたい人は AWS」、「レールに乗って楽したい人は Azure」というイメージを持っています。 もちろん、Azure でも、Linux/Windows の IaaSとかは使えますが、Azureの面白さはやっぱり、PaaSや、SaaSだと思います。またこの辺りは別のポストでお話ししてみたいので、割愛します。
Azure Functionsに絞ると、ざっくりいうと次の通りです。
2.5.1. わかりやすい GUI
統一されたわかりやすい GUIは、Azure の良さの一つです。 Azure Functions の場合は、結構 Azure で操作する、エディタがなかなかイケています。なぜなら、このエディタはかのエリック・ガンマが作成した、Visual Studio Online の技術が使われているからです。彼もマイクロソフトの一員です。結構これだけでも、自分的にはうれしい！
2.5.2. 様々なトリガ・イベント
Serverless の選定要素の一つを現在実現されているもののみで考えると、どれぐらいいろいろな、トリガや言語に対応しているか？というのがキーになると思います。Azure Functions では、Blob(S3相当), Timer, IoT/EventHub, Webhook, http, Queue(SQS相当), SaaS SendGrit, ServiceBus等のトリガに対して、C#, Node, Bash, PowerShell, Python, PHP等多くの言語に対応しています。
2.5.3. プログラム構造の透明化
λでは、サーバレスのコードを書くとそれが、どういう形で格納されているかわかりません。一方 Azure Functions では、先に説明 した通り、構造が明確であり、サーバーレスですので、しばらくしたら寝てしまいますが、サーバーぽいものの中にどのように格納されている かが、KUDOというツールで見ることができます。また、パッケージマネージャ(npm, nuget)等も、使えるというのも利点です。
2.5.4. デバッグ機能の充実
デバッグも先のKUDUを使ってログを見たり、コマンドをたたいてみたりということができて大変便利です。
2.5.5. Azure の機能との連携
これはあまり比較のメリットではありませんが、Serverless の場合、いかに楽にnano serviceを書けるのががポイントになると思います。そのケースで、Azure はいろんなサービスがあり、Azure Functions と連携しているのでこれはラクチンです。
2.5.6. API Gateway不要
AWSのAPI Gateway に相当する httpのトリガが用意されていますので、API Gatewayの様なものを設置する必要がありません。つまりそこに課金もされません。
もちろん、λの利点もあると思いますので、このようなメリットデメリットを考慮して皆様の環境で便利なほうを是非ご利用ください！先行されておられるAWSさんと比較してもなかなかのものですね。(2016/10/3時点の情報)
ちなみに、ブースの会場で、AWSの方と話したのですが、「競合とかなんとかいうより、Cloudをもっと多くの人に使ってほしいですよね」という素敵な話されていて、本当にその通りだなと思いました。DevOps もそうですが、競合とかそんなパイを食い合うようなセコい話ではなくて、もっと多くの人がCloudを使うようになれば、みんなHappyになってくると思います。
3．デモンストレーション
当日じっくり解説する時間がなかったので、こちらのデモの内容とコードを公開しておこうと思います。このデモは、Unityと、Cognitive Service という、マイクロソフトのAIの研究の成果を使ったAPIサービスを利用しています。
弊社の藤本氏が作成した、Interactive いちゃLoveゲームというUnityで作られたゲームが元になっています。このゲームは、Cognitive Service のEmotion APIという人の顔の感情を読み取るAPIを使っています。ゲームをやっている人の感情に合わせてゲームの反応を変えるというデモンストレーションです。スペースバーを押すと、PCのカメラで画像を撮り、それを、Emotion APIにRESTベースで送付して感情分析をして、キャラクターの振る舞いを変更しています。 キャラクターデザインと、ボイスは、ちょまどさんが担当しています。
この面白いゲームの詳細を知りたい人は、次のブログポストで説明されています。
私の方では、このゲームに対して、プレイヤーの属性を分析したいと思ったので、写真を撮った後に、それをBlobストレージ(S3相当)にアップし、それをトリガーに、Azure Functions(λ相当) を起動しています。Functionsで、Cognitive ServiceのFace APIをコールして、プレイヤーの年齢、感情、顔の輪郭、ひげの位置などの情報を分析して、それをSQLサーバーに送付しています。このFACEAPIを使うと、社員をいくつか覚えさせると、その人かどうかの判別を行うこともできます。 最後に、PowerBIというBIサービスにその情報を連携させて、分析を行うというデモでした。実際に、Serverless アーキテクチャを使うと、簡単に実装できたのでとても楽しかったです。パターンとしては、ある意味王道的な使い方ですが、本当にさっくり作ることができました。これは楽です！
ご興味がある方は、ソースコードを置いておきましたので、ご参照ください。実は佐藤さんは、更に凄いCognitive Service を使い倒したデモを用意していましたが、時間の関係でお見せできませんでした。
4. Azure の関連情報
さて、AWSを使ったままでも使える、Cognitive Service 等の情報を共有しておきたいと思います。 Cognitive Service に関してはエバンジェリストの大森彩子さんがいい資料をたくさん作ってくれています。紹介したもの以外にも動画をリアルタイムに解析したり、画像/文章の感情分析したり、言語解析したり、翻訳したりとむっちゃ凄いサービスになっているので、個人的にも熱いサービスですが、REST-APIを呼ぶだけなので簡単に使えます。 次のような情報が日本語でもあるようです。
1. Cognitive Services の機能紹介などは MSDN Blog
2. 実装方法など具体的な手順、コードなどは Qiita
3. 説明資料 (PPT)
最初のステップとしては、以下の記事がおすすめです。
a. Cognitive Service でできることをざっと知りたい人向け (from ①)
「人間にとって “自然な” アクションの実装 ～ Microsoft Cognitive Services を始める前に」
b. エンジニアで実際にコード書いて理解したい人向け (from ②)
「人工知能パーツ Microsoft Cognitive Services を使った表情分析アプリを作ろう！」 Emotion API × JavaScript 編
Emotion API × Bot Framework (C#)編 qiita.com
Azure Functions のサンプル等
真壁さんがこんなサンプルとその解説を書いてくれています！
Azure Functionsで運用管理サーバレス生活(使用量データ取得編) · re-imagine
まだ仕掛ですがこんなものもある様子
もちろん、プレゼンテーション資料にもたくさんリンクをつけていますので、Azure Functions 自体の資料もお楽しみください。
5. Serverless に感じる未来
マーチンファウラー氏の、Serverless アーキテクチャで有名なサーバーレスですが、日本語では、会場にも来てブースをサポートしてくれていたデプロイ王子こと廣瀬一海さんの記事が私はわかりやすくて好きです。
今回のサーバーレスカンファレンスでも、いろいろ面白い事例や使い方が出てきてとても面白かったのですが、Nano Serviceという言葉もある通り、マイクロサービスとのつながりもとても強く感じました。
個人的な意見では、現在マイクロサービスの環境がたくさん出ています。例えば、DC/OSは、データセンタOSと呼ばれて、クラスタ自体をまるで１台のサーバーかのように扱い、リソースのアロケーションをしてくれたりします。大変未来的で私は大好きなプラットフォームですが、残念ながら現時点では、せっかくリソースを最適化してくれていますが、使わなくても、使っても、VMを上げておく必要があります。 デプロイ後もVMの存在を意識する必要があります。
現在のアーキテクチャでいうと、IaaS, Container, PaaS, Serverless の順番にどんどんやることが減っており、よりプログラムに集中できる環境ができています。ただ、現時点では、Serverless は、サーバーを立てるまでもないものや、グルーコード、イベントの処理などの簡単なもに対するユースケースがうまく行きそうです。
しかし、ちょっと先の未来を見ていくと、DC/OSみたいなサービスは本来、VMの存在は忘れてリソース配置をしてくれるものだと思いますし、PaaSもできれば、VMの境目を意識しなくていいような状態になったとしたら、凄く楽で便利な世界が広がると思います。 つまり、それは思いっきりサーバーレスの世界で、サーバーレスで出来ることが、PaaSと、現時点でのサーバーレスで出来ることの間が縮まって、PaaSと見分けがつかなくなるときに、本当にサーバーレスの凄い世界がやってくる気がします。しかも、それは、たぶん数年とかからない気がします。私が知らないだけですでにそういうものが存在するかもしれませんが。
また、Ito Naoya さんのパネルもすごく面白いお話しでしたが、最後に、「この事例は、本当は、Actorを使うとうまくいくと思う」という話をされておられました。個人的に、マイクロソフトの出しているものでも最もホットなものとして、Service Fabricというのがあります。 これ激アツです。これは、マイクロサービスのPaaSというとんでもないもので、もともと、Azureの各種サービスに使われていた基盤を公開したものです。Stateless/Stateful のサービス、そして、Actorをホストしてくれます。Stateful / Actor に関しては、デプロイするとサーバーに対して、レプリカを自動で組んでくれて、VMがダウンしたとしても、メモリを共有しているので、処理がそのまま継続して実行されたります。つまり、Netflixさんがやっているような、カオスモンキーを使うようなFault Injectionをぶちかませる基盤が最初から手に入る感じです。実際に、Service Fabric には、そのようなChaos Testing のAPIが最初から組み込まれています。
そして、Actorをガンガンにサポートしています。次のゲームとかを見ると基盤の凄さが伝わるかもしれません。余談ですが熱くなってしまいました。
このように、Azure も個人的には激熱なテクノロジーがたくさんあって、むっちゃ楽しいです。是非皆さんもよかったら楽しんでくださいね！
最後に
主催の吉田さんが、世界に向けて、日本のServerlessの盛り上がりを記事にされておられます。素晴らしいです！
これは単に宣伝ですが、Azure が気になる方はこんなイベントもあります！
