新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣
クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める8つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください!また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。
元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ10数分以下のサイズになっています。
序章:イントロダクション
8つの習慣をなぜ作成したのか?どういう効果があるのか?ということについて解説しています。
私が8つの習慣を作成するにあたり、感じたこと、思ったことはこのあたりのエントリに起因している。
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
次からは、各習慣についての動画をリストしておきます。補足のブログや動画へのリンクをつけておきます。またブログの最後に動画で使用したプレゼンテーションをつけておきました。
第1の習慣 Be Lazy
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第2の習慣 リスクや間違いを快く受け入れる
simplearchitect.hatenablog.com
第3の習慣 不確実性を受入れる
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第4の習慣 サーバント・リーダーシップ
サーバント・リーダーシップに関してはもう一つビデオがあります。従来は、通常のマネジメントをしていたマネージャが、どのようにサーバント・リーダーシップに変わっていったか、恐れは、そしてその効果やトレードオフについての体験をインタビューしたビデオがあります。こちらもよろしければご覧ください。
Takahiro Kaihara さん、 Mitsunori Seki さん、撮影ご協力ありがとうございました!
simplearchitect.hatenablog.com
第5の習慣 セルフマネジメントチーム
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第6の習慣 従業員への信頼
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第7の習慣 個人の自信
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
第8の習慣 階層関係のパワーバランス
simplearchitect.hatenablog.com
プレゼンテーション
おわりに
西洋文化インストールという8つの習慣は変化への対応や、生産性を高めるための習慣を、マインドセットとして整理できたと思っております。是非楽しんで学んでみてください。ロッシェル・カップさん、本当にご協力ありがとうございました!皆さんの生産性が向上しますように!
「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第3の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。
ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。
不確実性を受入れる
- マネージメントは詳細まで細かく練られた計画を期待しない。
- 予算と報告のプロセスは精密な結果の予測を要求しない。
- 内部プロセスは計画や優先順位の変更に柔軟である
- 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ
- システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる
- 学びに基づいて、変化を精力的に行う。
この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思われる習慣だ。 この考えなしに新しいモダンな開発スタイルのマネジメントは不可能といっても過言ではない。逆にいうと、あなたがこの習慣をマスターすれば、日本人の良さも生かしながら相当かっこいいマネージャになれるかもしれない。
「納期は絶対」の神話
日本人には、「不確実性の忌避」という文化的性質があるらしい。つまり、不確実な状態を嫌うので、先に予見したり、計画するということをがっつりやってしまいがちになる。比較的先が見通しやすい産業においてはとても有利な性質かもしれないが、ソフトウェアのように非常に先の見通しが立てにくく変更が多い分野にはこの性質がマイナスになりがちだ。我々の傾向として、よくわからないものがあった場合、先に試してみるよりも、やる前に、いろいろ「検討」したりしてしまい、なかなか着手できなかったり、どんなに計画しても分からないものに対して、一生懸命予見し、完璧な計画を立てることに時間を使ったうえ、一度立てた計画が実態にそぐわなくても、その「計画通り」に遂行しようとして、プロジェクトが炎上してしまうという場面もしょっちゅうある。
我々は「計画通り」でないと「失敗」と思うかもしれないが、そもそも未来を予見できる人なの世の中に存在しないのではないだろうか?なぜ「計画通り」でなければならないのだろうか?計画はあくまで、当初の見込みで、作業を円滑に進めるためのものじゃないだろうか?よくわからないものに対して、事前に検討しても予見できない。その予見に時間をかける暇があったら、検証するほうがよいというのは前回のテーマにもつながることだ。
simplearchitect.hatenablog.com
私が、クロスカルチャーの専門家のロッシェルカップさんから聞いた話で衝撃的だったのは、「納期(Deadline)」の意味が日米で異なるということだった。日本の場合は、納期に、予定された機能の納品物を、予定された品質で提供するのが必須であるという感じだ。しかし、米国では、「納期は柔軟」であるらしいと聞いて目が飛び出るぐらいびっくりしたのと同時に、そういえば同僚のことを思い出しても、日本ほど「納期」に厳しくない。大抵は、納期にリリースするけど、予定よりも少ない量に変更するいうことはしょっちゅうだ。少なくとも納期を守るために、徹夜とかいう場面は見たことがない。我々はたぶん納期に厳密すぎて無理をしすぎる傾向にあると思う。それはどの程度バリューがあるだろうか?
ソフトウェアエンジニアリングでの考え方
そもそも、Q(品質)C(コスト)D(納期)+S(スコープ)は、トレードオフの関係にある。納期を短縮したければ、お金をたくさん払うか、品質を落とすか、提供する物量(スコープ)を減らすかという塩梅だ。予定通りQCDSをすべて達成するというのは非常に困難だ。だから、多くのマネージャは、大きなバッファを持って、それを達成しようとする。私も昔は常に30%ぐらいのバッファを残しておいた。そもそも、ソフトウェアの場合は変更が入るので、当初の計画通りにはまずいかない。
つまり、エンジニアリング的には当初に想定された、QCDSをトレードオフせずに納期通り納品するのはほぼ不可能に近い。しかも、その計画はソフトウェアの場合、統計的にも相当予見しにくいものである。段階にもよるが、最初の段階で計画したコストの3倍になる確率も十二分にあるといった精度でしかない。これを信じるほうがよっぽどリスクが高い。
実績のみで判断する
その代りどうすればいいか?というと、単純化していうと「実績」だけで判断し、「納期」を固定して「スコープ」つまり、予定の機能を出し入れするほうがいい。
納期はまもって、その日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回す。もしくはやめてしまえばいい。ある機能が1週間遅れたからといってそれがどの程度インパクトがあるだろうか?それが「達成される」という前提で計画を立ててしまうから、「必達」とかになってしまうけど、そもそもそれは計画なので「いまのところは、こういう予定」ぐらいの感覚で見たほうが確実じゃないだろうか?
例えば、マイクロソフトや、他のサービスプロバイダを見回してみても、必ず納期通りすべての予定の機能をリリースしているソフトウェアジャイアントは存在するだろうか?ロードマップを持つことは見通しがよくなってよいことだが、実際リリース予定の日が近づくと、しれっとその機能が削除されていることはざらではないだろうか? それはどの程度のインパクトを起こすのだろうか?そして、その納期とリリース機能を守ることは、プログラマの生活や健康や楽しみを犠牲にして守るほどのものだろうか?そもそもマネジメント的にも、中長期的には生産性は疲弊するためどんどん低下してしまうので効率が悪い。
予定日にはリリースする。そして、例えば開発が1週間単位でおこなわれているならば、前の週、その前の週とかがどの程度の量をこなすことができたかを測定して、次の週、その次の週も、たぶんそれぐらいの量はこなすことができるだというという想定を立てるとより現実的な計画を立てやすくなる。
ただし、この計画も状況は刻一刻と変わるので、ずっと現実的であるとは限らない。チームの誰かが病気になるかもしれないし、チームの生産性が上がるかもしれない。楽観的でも、悲観的でもなく、現在のチームの生産性を測定して次の直近の予測に使うという方法だ。そうしておけばシンプルだし、気合や根性の正解や、楽観的もしくは悲観的な感覚が入り込む余地が無くて楽ではないだろうか?
さらにこれがいいことに、無理してリリースするとすると、問題を覆い隠す。つまり、チームの生産量を超えた量を一定期間で達成した結果、今回出来たら、次回もこれぐらいできるよね。ってなりがちだ。そうするとどんどん無理が積み重なっていく。そして、無理をしていることが上層部や周りにも伝わらないことになる。だから、問題も改善されない。
無理を積み重ねるのではなく現実を見て、「工夫」をしていこう。たぶんポイントは、第一回でご紹介した「物量を減らして、より大きな価値を生み出す工夫」だ。つまり「やらないこと」を見つけることだ。
詳細な計画を求められないために
もしかすると、あなた自身ではなく、上の人から詳細な事前の計画を求められるケースがあるかもしれない。詳細な計画はコストも時間もかかるうえに、着手を遅らせるという最悪な結果を招く(少なくともソフトウェア開発の場合は)。そのようなケースだと、プロジェクトが始まる前に、その上の方に「こういう形式でレポートします。今回 Agile / DevOps なので」ということを事前に合意しておくとよい。そもそもそれが通らないって?その場合は、私のお勧めは例えば、Agile / DevOps をやる場合にはお勧めの方法がある。Value Stream Mapping という現在の開発プロセスを見える化して、改善ポイントを見つけ、リードタイムを短縮することができるツールを使うとよい。
このツールを使うと、素晴らしいことに4時間ぐらいで、無理なくリードタイムを短縮できる「見込み」を知ることができる。例えば、ある会社さんでは、リードタイム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にしてしまうといい。そのブラジル人の人みたいに、そういうケースがあったら、「無理」だとか「断る」ということをしてみよう。そのうえで、どうしたらいいか相談にのってあげよう。自分が我慢して受けてしまうと、改善につながらないし、自分以外の人にも我慢を強要してしまう傾向になる。
「無理」というのを認識したうえで、楽に達成できる計画に2人で落とし込む計画に変更するのはどうだろうか?無理であることがわかったら工夫したらいいし計画に無理があったサインかもしれない。「ここまでだったら、協力できるよ」というラインについて話をするのもいいかもしれない。こういうマインドセットをチームでシェアすると、「無理!」が言いやすくなるので、8つの習慣をチームでシェアしておくのはおすすめだ。「無理を承知で」のお願いの連鎖が、みんなの疲弊を生んでないだろうか?「無理」と言えるようになったら、「無理じゃない」計画に対してみんな対応できるようになる。
3. 他の文化の視点を学んでみる
先ほどのブラジル人と日本人のチームの例ではないが、日本人ではない、他の国だとどうなっているだろうか?というのを学んでみる練習も楽しい。私は英国留学を3か月していた時があるが、その時マーケットリーダーというビジネス英語のテキストを使っていた。その内容は結構面白くて、いろんな国の商習慣や文化習慣についても学べる構成になっていた。我々は日本だけで生きて育っているので、例えばの納期を守るのは人として当然ぐらいの感覚がある。
しかし、他の国だと、時間通り待ち合わせに来るのが失礼という国すらある。先ほどのブラジルの例だと、日本人よりダイレクトに思っていることを話す。しかし、デンマークだともっとダイレクトだし、日本よりももっと、ダイレクトに思ったことを表現しない国もある。 そういったことを学んでいくと、もはや「常識ってなんだっけ?」という感覚になってくる。そうすると、「自分の常識」というものも、他の人には当てはまらないなぁ。という感覚になってくる。下記のロッシェルさんのクローバるマインドセットの記事はとても興味深い。もしご興味がある人はぜひご一読いただきたい。
ビジネスで成功するための グローバルマインド養成講座|ビジネス英語|アルク
我々は計画の変更に不寛容だ。前回も書いたが、誰もが失敗と思っているプロジェクトで価値がなくなっても計画通り継続してしまう。しかし、「リスクや間違いを快く受け入れる」マインドセットがあれば、計画通りいかなかったことを受入れて、計画を変更するマインドセットにつながるだろう。計画自体が仮説でしかないので、変更されるものなのだ。「Be Lazy」のマインドセットがあれば、無理に全ての物量を納期通りリリースすることに本当に価値があるかを考え直すことが できるかもしれない。
他の例でいうと、マイクロソフトで私に降りてきている方針も1年の間にずいぶん変わってしまった。数か月で変わっていく。それは健全なことだと思う。だって、状況が変化していくのだから、変化に対応することのほうがよっぽど大切だ。そういう環境にいると、時間をかけて計画を立てることはばかばかしくなる。どうせ変わるのだから。 つまり、「計画の変更」は悪ではない。現実をみて、フィードバックを受けての変更で、むしろ善だろう。そういうマインドセットをチーム内や関係者でシェアしているだけで、その人がさぼっているわけではなく、「不確実性を受入れる」マインドセットで行動しているということが周りも認識できる。そしたら周りももっとやりやすくなるだろう。
じゃあ、さぼる人はどうするんだ?という意見もでそうだ。それはまた違う習慣でお話ししたいが、性善説・性悪説があるときに「性悪説」でかんがえると、「性善説」で考える時より「ずっとコストがかかる」ということだけはシェアしておこう。是非「サーバントリーダシップ」の回をお楽しみに。
「検討」は無駄である - リスクや間違いを快く受け入れる第2の習慣
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。
最初の習慣は次のブログで紹介してみた。
simplearchitect.hatenablog.com
リスクや間違いを快く受け入れる
- リスクを背負うことは推奨されている
- 間違いを厳しく批判したり懲罰したりしない
- 失敗から学ぶ態度
- Fail Fast(早く失敗する)
- 実験が推奨されている
- 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される
- 非難や恐怖感の無い環境
この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない!
間違いや失敗に対するイメージの違い
マイクロソフトのインターナショナルチームで働いていて気づいたことだが、同僚や上司がよく「Miserably Failed(惨めに失敗した)」という言葉を頻繁に使っていることだ。日本では「決して失敗は許されない」というプロジェクトが過去にも多々あった。しかし、人間なので、いくら失敗が許されない状況だろうが、どんなにしっかり準備しようが、「失敗」は発生するのだ。日本だと、例えばこってこてに炎上して、お客さんが激怒し、中身もボロボロなのに、納期と予算を守ったという理由で「成功」したということになっているプロジェクトをいくつも見てきた。文化的にも失敗したら「切腹」したり、「左遷」されたりと、悲惨な目にあうので、日本の社会では「失敗した」ということをとても言いづらい。だから、多くの人は失敗しなさそうな無難な方に流れてしまう。本当にこれはもったいないことだ。
一方、インターナショナルチームで気づいたことだが、失敗とか、間違いとかで怒られたことは無いといっていい。失敗したり、間違いに気づいた後に、本社に「フィードバック」をすると、「フィードバックをありがとう!」と大変感謝される。そして、誰がやってもうまくいくようなことを実施しても誰も評価してくれない。例えば今、お客さんの本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこでいつも言われていることは「お客さんの最も難しい問題を解いてこい」と言われている。つまり、この世のどこにも情報が落ちていないような問題解決をやること。これが評価されるのだ。誰かが失敗しても、黙ってることもないし、失敗しても「あいつはだめだ」とか言ってる人を見たことがない。だからすごくチャレンジしやすく感じる。
だから、より難しいことへのチャレンジも大変気楽にできる。むしろチャレンジしないほうが、将来が不安だ。だから、成功しようが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく。この考えはアジャイルや、リーン、DevOps に全て共通する考え方だ。だって、普通人間は間違うんだもの。
最も恐ろしい事
この「リスクや失敗」を恐れる性質は、生産性の面で劇的な問題をもたらしている。失敗したくないので、ともかく慎重になるのだ。慎重に時間をかけたから失敗を減らせるわけでもないし、時間をかけている間にライバルは次に進んでしまう。
前にもブログに書いたことがあるが、私が米国でお客さんとディスカッションをしていて一番驚いたことがある。リックを1つだけ背負ったにいちゃんが、私とDamien に会いに来た。彼は私とDamienと1時間ぐらい話をしたあと。「うん。やろう」と言って、500人規模のハックフェストをその場で決定して帰っていった。
日本で同じことが起こるとすると、まず、ベンダーが提案して、顧客がそれを見て、Excelで質問票を作り、、、といったやり取りを数か月行って、結局やっぱりやめたみたいなことがしょっちゅう起こる。これはベンダーにとっても顧客にとっても大きな損害だ。時間だけが過ぎて、工数を使って結局何も生み出せていない。ノーバリューなのだ。1時間で物事が決まって、実際にハックフェストを実施すると、本番環境でいろいろ起こるような検証が数日で出来てしまう。今の時代はExcelで質問票を作っている場合ではないのだ。それをしている暇があったら、実際にハックをして確認したほうが100倍確実だろう。今の時代、いろいろ検討ばかりして、さっさと「やらない」ことが最大のリスクになってくる。
そして、こういうことが起こると、恐ろしいことに失敗確率が増える。卓上でいくら検討しても、実際やってみないとわからない。卓上でやっていたら、結局市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーは適切に動作するか?というフィードバックは、結局実施するまでわからない。だから、失敗確率が高くなる。だから少なくとも変更がやりやすいソフトウェアは、アジャイルのような早く実装して、早くフィードバックを得る方法が採用されている。さらに、機能しているものを変更して失敗するリスクがあるものを避ける傾向も強くなる。現状維持だ。
同じ失敗ばかり繰り返す人は?
じゃあ、まったく進歩せず、同じ失敗ばかりを繰り返す人はどうするんだ?と思うかもしれない。それはごもっともだ。その解答は「評価」だと思う。他の習慣で、「従業員への信頼」という習慣がある。人に対してごちゃごちゃ細かいことは言わない。最初に会社と合意したゴールつまり大まかなKPIを達成していたら、失敗しようが、人より不器用だろうが何だろうがいいのではないだろうか?その人を信用しよう。
できないのなら、評価のタイミングで KPIが達成しないので、給料が下がったりクビになる。ただそれだけの話だ。だから、評価はそのタイミングでよくて、失敗は結果論であるので、それよりも「フィードバック」を得たかを気にしよう。私のパートナーのクロスカルチャーの専門家のロッシェルさんがこういう話をしてくれた。米国では、プロジェクトが中止になったら、プロジェクトが成功したのと同じようにパーティをする会社があるらしい。なぜなら、その失敗から「学ぶ」ことが出来たからだ。
この「習慣」は生産性に非常に影響してくるものだ。逆にいうと、これを身に着ければ、簡単にライバルに差をつけることができる。 じゃあ、この「習慣」を獲得するにはどういう方法があるだろうか?
「リスクや間違いを快く受け入れる」プラクティス
- 成功・失敗より「フィードバック」を歓迎するムードを作る
- 「検討」をやめて「実証」する
- 「早く失敗」できるように考える
それぞれについて解説してみよう。マネジメント、チーム、プロダクトオーナ(チームに出すリクエストをきめる人)のロールがある場合、どういった順番で重要なプラクティスだろうか?
対象者
- 上位マネジメント
- プロダクトオーナ
- チーム
これもほぼ全員だが、誰かが、誰かの「失敗」を責めるケースが多い順に考えてみた。
1. 成功・失敗より「フィードバック」を歓迎するムードを作る
最初のプラクティスだが、チームメートや部下が成功したら当然喜んであげたい。失敗して、フィードバックしてくれたら、失敗する方法がわかったのでこれは大きな進歩なので、感謝しよう。失敗して「怒る」ということはあなたと対等である人を「子ども扱い」しているのと同等だ。そういう気持ちはわかるが、「怒る」という選択肢はなくして、「フィードバック」を促進するようにムードを作ろう。 たとえば、メールで、成功の報告を見たら、みんなで「おめでとう」のメールを返そう。メールで、失敗とそのフィードバックをしてくれたら「感謝」のメールを返そう。マネージャなら、本人の評価はあくまで約束したKPIの達成の可否であり、小さな成功や失敗ではない。そういうことを明確にしていこう。このムード作りは、上位マネージメントの方から仕掛けていただくほうがいいかもしれない。
2. 「検討」をやめて「検証」する
あなたがユーザ企業や上司ならば、パワーポイントに書かれた大量の資料を要求したり、完全無欠の検証を期待するより、時間をかけず、さっさと「検証」してフィードバックを得るようにしよう。人間未来は予測できない。例えば、あなたがユーザなら、ベンダーに「提案」を依頼すると、例えば私が大手のSIに勤務しているときは、提案書を作るのに何人もの人が数週間もかけて作っていた。しかし、正直に言うと今の時代、大量に検証しても制度が低いし、マニュアルに「出来る」と書いてあっても実際作ってみるとできないなんてことはしょっちゅうある。その工数は、あなたがそのベンダーに発注したときにOnされてね返ってくる。Lose-Loseの関係だ。
そんなのよりも、クラウドの時代でさらに加速したが、実際に作ってみるほうがよっぽど早い。そして、過去と比べると圧倒的に早くできてしまう。だから、ああでもない、こうでもないと検討するのではなく、実際に作ってみる「ハックフェスト」などを通じて、動くもので検証しよう。 ほかにもあの機能を実装するべきか、この機能を実装すべきかと検討している暇があったら、実際に実装して、ベータテストで実際のお客様で試してデータを取ろう。思ってもない結果になるかもしれない。 今の時代最もリスクなことは「何もしない」ことだ。検討している暇があったら、今すぐ実装して試してみよう。データをとろう。
例えばアーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがある。それを意思決定するのは簡単だ。答えは「どちらでもいい」ので趣味で選べばよい。なぜなら、圧倒的に差があるのなら、決めあぐねるはずがないので、どっちを選択しても大差ないということなのだ。 また、昔と違って、ツールやサービスの単価は高くない。1つのツールで失敗したら次のにさっさと乗り換えればいい。つまり比較検討など無駄だ。それより早く前に進もう。実践の経験を積み重ねるほうがよっぽど貴重なことだ。
3. 「早く失敗」出来るように考える
これも、2.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。例えばウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。つまり、実際の「フィードバック」を受けるまでの時間が長い。これが問題だ。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう!
いかがだっただろうか?もっといいプラクティスがあるかもしれない。私もまずは3つをピックアップしてみた。もしもっといいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。
Scrum / DevOps の導入を加速するグローバルマインドセット ~8つの習慣 その1 ~
クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「8つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。
今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「8つの習慣」を初めて発表させていただいた。
「8つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうまくいかなかったり、効率が悪くなってしまう。
そこで、米国並みのスピードでの技術導入や、本質的な導入を目指す方のために、「8つの習慣」を考案した。 Agile / DevOps の導入を本質化し、加速するための西洋文化のマインドセットだ。日本人は「生産性」が悪いせいでグローバル的には大変損をしていると思う。それさえ何とかなれば、日本人の文化の良さを生かして、ソフトウェアの世界でも輝ける存在になると私は信じている。重要なことは、西洋を崇め奉りたいわけではなく、日本文化と西洋文化の考え方を「選択可能」にすることだ。
ただ、講演では時間が45分なので、すべてを解説する時間がなかった。まずは「興味を持ってもらう」ということをターゲットにしたので、「実際どうすればいいかわからない」だろうとう反省がある。今後ロッシェルさんとビデオを公開して「8つの習慣」をより学びやすくするつもりだが、このブログでも不定期に「8つの習慣」が何で、具体的にどういうことをすれば導入できるかについて解説していきたい。
「8つの習慣」を理解する方法
「8つの習慣」は「マインドセット」なのでなかなかに理解が難しい。ただ、一番簡単な方法がある。米国人、もしくは、西洋人のチームに参加して1年も一緒に仕事をするといい。そしたら簡単に彼らのマインドセットを体験できるし、その破壊力を体験できるはずだ。そして、彼らが「人として優れている」とかではなく、我々でも十分できる「習慣」のために生産性がいいことを体験できるので、簡単にマネできると思う。
ただ、問題は、そういう環境にいる人は国内にはあまりいないということだと思う。だから、そういう人のために、国内にいても、そういうことを学べる方法はないだろうかとロッシェルさんと一生懸命考えたものだ。もちろんまだ出来たてなので、まだまだの部分はあると思うが、それでも改善を進めながら、技術導入を本当に加速したいと思っている人がにお役に立てればと思う。
「8つの習慣」
- Be Lazy
- リスクや間違いを快く受け入れる
- 不確実性を受入れる
- サーヴァント・リーダーシップ
- セルフマネジメントチーム
- 従業員への信頼
- 個人の自信
- 階層関係のパワーバランス
これがロッシェルさんとディスカッションして整理した、「8つの習慣」だ。我々がAgileやDevOpsをうまく導入するために必要な西洋のマインドセットを整理してみた。 今回は最初の習慣である Be Lazy から具体的にどういうことをすれば、導入できるのかということに関して考察してみたい。
Be Lazy
この習慣は、スクラムや、リーンの世界でもよく言われており、アジャイル以降の開発で大変重要なポイントになっている。このブログでも何回か取り上げているが、一言でいうと「より少ない時間で価値を最大化するという考え」だ。この考えを学ぶにはエッセンシャル思考という本を読むのが一番おすすめだ。
Be Lazy を達成するための習慣
- 望んでいる結果を達成するために、最低限の努力をする。
- 不必要や付加価値のない仕事をなくす(過剰準備含む)
- 簡潔さを目指す
- 優先順位をつける
- 時間や費やした努力より、アウトプットと生産性に重点を置く
- 長時間労働しないように推奨する
- 会議は会議の時間内で効率的かつ生産的に価値を提供する
このBe Lazy の一覧を見ると、たいていの人は「当り前じゃないか?」と思うのではないだろうか?そこに落とし穴がある。例えば「優先順位をつける」という項目について考えてみよう。よくスクラム等で言われる言葉で「バックログに優先順位をつけて、優先順位の高いものに集中しよう」ということがある。この言葉を聞いて、私のような日本人の人にイメージされるのは次の図の左のようなイメージじゃないだろうか?
リストに上がっているタスクが5つぐらいあるけど、「全部できないから、優先順位をつけて、どうしてもできないのは無理だから実施しないようにしよう。でも時間が許せば全部実施したい。」ところが、同じ言葉に対して、海外のメンバーを観察していると、右のようなイメージをもっているようだ。「最初の1個をピックアップしてやったら他はやらない。その1つのフォーカスする」ぐらいの感じだ。
こういう場面はインターナショナルチームにいるとしょっちゅう目にして、そのたびに驚いていたが、例えば、バリューストリームマッピング(上記の図をプロジェクトメンバで作成しプロジェクトの無駄を発見するセッション)を、同僚のデビッドとやった時に、彼は「リリースマネージメント」という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
彼らが優秀とかではなく、「やることを減らすか?」ということに注力している。多くの人は、例えば多くの機能を速く実装することはよいことと思わないだろうか?本当は「悪」である。なぜなら、統計によるとソフトウェアの機能のうち40%ぐらいしか使われない。だから、100%を全力でつくったら、60%が使われない。しかも、その60%でバグが発生したら直さないといけないし、60%もコードベースが多くなるので、変更があった時にコードを読む量がさらに増えてしまう。
つまり、「やることを減らす」ことは大変素晴らしいことなのだ。ところが我々の感覚からすると、全部やらないのは、何となく悪いことに感じてしまう。だから、いまある手続きや、やり方を「減らす」のは苦手だ。だけど、重要なことは「価値」であるのと同時に、「減らすこと」自体は非常に価値がある。
例えば、マイクロソフトに在籍している間に2回報告システムが変わった。どんどん手続きが「楽」になっていっている。ミーティングも毎週だったものが、2週間に1回になったり、1年に4回あったレビューが少なくなったりとか平気で起こっている。そうすれば、それに使っていた時間が他の優先順位が高いことに使えるのだ。 しかし、「価値」というものはよくわからないものだし、どうして「より短い時間で、価値を最大化する」ことができるだろうか? 次のようなことを実施してはいかがだろうか?
Be Lazy プラクティス
いくつかセルフチェック出来そうなプラクティスを考えてみた
1. ひとつだけピックアップする
2. 時間を固定して、出来ることを最大化する
3. 過剰な「準備」と「後でやる」をやめる
我々は西洋系の人と比べて、完璧主義の傾向が強いと思う。重要なもの、そうでないものも同じ感じで「ピカピカ」に磨いてしまう。だから時間がかかってしまう。ただしこれは、いい点も悪い点もある。例えば西洋の人は「ピカピカ」に磨く能力が我々に比べてない気がする。我々に問題なのは重要じゃないこともピカピカに磨いて工数をつかってしまうことだ(例えば、文章を書くときにExcelの細かいレイアウトまでこだわるとか)。これをやめたら、生産性が上がって、西洋の人と生産性で競争できる上、重要なことだけ「ピカピカ」磨いてやれば、ものすごい競争力になるはずだ。だからまずは、見習うところは見習うほうがいいのでは?というのが私の考えだ。
対象者
スクラムや DevOpsチームでの使用を想定するとすると、本プラクティスをマスターしておくとよい人は次の人だ。
- プロダクトオーナ
- 顧客
- チーム
- 上位マネジメント
つまり、全員が該当する。ストーリの優先順位づけや、機能のどれを実装するか否かという場面で非常に生産性に影響する。だから、プロダクトオーナや、顧客が特に深く理解している必要がある習慣だ。もちろんチームメンバも、本当に必要な機能、そして不要な機能をプロジェクト全員で見つけだすために、重要になってくる。また振り返りを行い、プロセスの改善を実施するときも如何に「楽」をしてより高い「価値」を生み出せるか、何を「やめる」かをディスカッションするための基本的なマインドセットとなる。
さて、これらのプラクティスについて解説してみよう。
1. ひとつだけピックアップする
これは、インターナショナルチームで周りの人を観察して彼らのように出来るようにマネして実施しているプラクティスだ。私は優先順位をうまくつけるのが彼らに比べて本当に苦手だ。あれも、これも大切に見えてしまう。だから、そういう時は、思い切って、一番重要なのはどれか?と考えてそれだけやろうと考えるようにすると、ちょっとマシになってきた気がする。最終的に3つピックアップするケースでも、まず最初の1つだけピックアップする癖をつけている。そのあと残りの2つをピックアップしている。
自分がやるべきと思っていることをスルーするのは恐怖があるが、結局それを受け取った人もたくさんだと理解できないのだ。最大でも3つぐらいだろう。一番重要な「ひとつだけ」ピックアップする癖をつけると、時間が無くなった時も、少なくとも「一番重要」なことは実施できている状態になれる。
そうしていくと、「やらないといけない」と思ったことをやらなくても、結局問題にならないことがわかってくる。どうでもいいことを10やるより、1番重要なことを時間をかけてしっかりやったほうが大抵のケースはうまくいくし、沢山のことをいっぺんにやっても、本人はやった気になるけど、忙しいだけであんまり成果が出ていない感覚になる。
すべてのケースで「ひとつだけピックアップ」が通用するわけではないが、「ひとつだけピックアップ」のプラクティスを3回繰り返せば3つピックアップできる。しかし、重要なのは、10個のうち2個しかやらないことは決して悪ではなく、そっちのほうが「バリュー」として効果的なことを「体感」し、「やらないこと」の恐怖を克服するのがこのプラクティスの目的だ。是非お試しあれ。
2. 時間を固定して、出来ることを最大化する
「すべき」思考で考えると、どうしても、時間を「延長」してしまいがちだ。彼らを観察していると、「すべき」から時間を計算するのではなく、「時間」は固定して、その中で価値を最大化するという行動をとっているように感じる。
例えばロッシェルさんと打ち合わせをするときも、時間が延びることはほぼなく、「あれも、これもやらないといけない」とお互い思うのだが、この2時間で出来る範囲のなかで、「最大にバリューが出ることにフォーカスをすると、これと、これなので、今日はこの2つだけやろう。」すべきことを全部こなそうというより、時間が最大の制約なので、この時間内に確実にできる数に絞って、最大の成果を出せることに集中する。みなさんも、なんも準備できていなけど、明日プレゼンだとかいう場面はないだろうか?その時のイメージを思い出すといいかもしれない。多分無理なものはあきらめてバッサバッサと作業を切り捨てているはずだ。それを無理ない個数に絞り込んでやるイメージだ。
だから、「きれいなドキュメント」なんかは作っている暇は当然なく、「やる事」の数を減らして時間内にできるようにして、やったらよさげなこともばっさばっさと切り捨てて、その場で出来るだけ早く意思決定するようにせざるを得なくなる。 「まだ完璧じゃない」「抜けてることがあるかもしれない」ことが最初は怖かったが、「抜けている」ようなことは大抵対して重要じゃないのだ。抜けていて困ることもあるかもしれないが、それは、何かを実施したら、フィードバックを得られるので、「心配」せず「実施」してしまえばいい。
例えばこの「8つの習慣」も完璧かは知らないが、世に出して、フィードバックを受けたほうが悩んでるよりよっぽど生産的だろう。
3. 「準備」「持ち帰り」をやめてその場で解決する
ポイントとしては、何かの作業、例えば会議をしているときに、「会議の場」のみで完結するように訓練することだ。彼らを観察していると、ざっくりしたアジェンダはあるが、準備に時間をかけて会議に臨むということはしない。さらに、会議が終わった後に「宿題」とか「もちかえって検討」とかそういうことがない。つまり、会議に出たら「会議の時間内だけで完結」する。これは大変生産的だ。 日本の会議のときは、会議の前の準備があって、会議が終わった後も、検討したり、議事録を書いたりいろいろしないといけない感じだった。
インターナショナルチームを観察していると、彼らは常に「会議の場」だけで完結される。議事録もその場でOneNoteにとって共有される。 例えばロッシェルさんとのプレゼンテーションの会議をしているときも、「ここと、ここを修正して後で直しておきます」ということはせず、その場でプレゼンを修正する。そしたら終わった後に時間を取らなくていい。そして、会議の時間の間にロッシェルさんに共有する。意思決定も、持ち帰って検討しますではなく、間違っててもいいので、その場で意思決定してこうしようと決める。
昔のブログエントリで書いたが、こういうことを元から実践している人がいる。ソニックガーデンの倉貫さんだ。私がコンサルタントの時、彼と仕事をした時の一言は忘れられない。
牛尾さん。会議の準備をしないでくださいね。無駄だから。そうではなくて、会議の時間を価値の高いものにしましょう。
彼との会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。もし、どれぐらい「準備」をしなくてもいいのか?がわかりづらいなら、いっそ準備「なし」でどの程度できるか体験してみるといいだろう。そして、出来るだけ「会議の時間内」のみで完結できるように頑張ってみる。そうすれば、思ったより「できる」ことに気づくのではないだろうか? できない場合は、きっと、「余計なこと」を頑張っている可能性が高いので、会議のゴールに不必要なものを減らしていく練習をするとよいだろう。
おわりに
これらの3つのプラクティスは、もちろん簡単ではないとは思うし、実際の例を見ないとなかなか理解できないかもしれない。「どれぐらい」ができている状態かわかりずらいかもしれない。
だけど、これらを「意識」してみて、「実践」していると、だんだん上達してくるし、こういったことが「出来ている」人を目にするとアンテナが立っているので「あーこれぐらいできればいいんだ!」という気付きを得やすくなる。少なくとも意識して「実践」してみるだけで、かなり変わってくるはずだ。
次回は「リスクや間違いを快く受け入れる」習慣について書いてみたいと思う。
「知らないこと」を恐れないマインドセットが技術導入を加速する
先日、米マイクロソフトの Redmond キャンパスで行われたマイクロサービスのハックフェストに2週間ほどサポーターとして参加してきた。 そこで気づいた日本との技術導入の差の秘密について気づきをブログに書き留めておこうと思う。
ハックフェストというのは、お客様のガチの環境もしくはそれに近い環境/テーマで行うハッカソンだ。
例えば DevOps の文脈であれば、自動化したら効率化されそうな部分に関して、マイクロソフトの製品チーム、エバンジェリストがサポートしながら、お客様自身が我々と一緒にハックをして、実際にお客様の環境を自動化してしまうようなイベントだ。 Hello Worldやチュートリアルレベルではないので、お客様の環境が本当に自動化されてリードタイムが短縮されたり、我々にとっても、現場の難しい問題を知り、それに対してソリューションを作ることができるので、スキルアップまでできるので私は大変気に入っている。マイクロソフトはこのイベントをプッシュして展開している。
さて、今回のイベントは、米国、カナダ、欧州のマイクロソフトのパートナーを集めてマイクロサービスのハックフェストを実施していた。ほとんどのパートナーは、Service Fabric というマイクロソフトの激アツのマイクロサービスの PaaSサービスを試していた。
私が驚いたことに、Service Fabric はまだ出てそんなに経っていないというのに、ガンガンに使ってたり、基幹業務系に使っていたり、通常はクラウドサービスなのに、オンプレに自らインストールして使っていたりとそのレベルの高さに本当に驚かされた。
彼らとディスカッションをしても、正直相当レベルが高かった。普通にBoundary Contextとか、Conways's Lawとか、DDDとか普通に知っていて当然のように活用している。一体この差はなんなのだろうか?今回は、2回 x 5日間のハックフェストを体験して気づいた彼らの新しい技術に対するマインドセットをシェアしたい。
準備不足からくる不安を感じる
正直このハックフェストが始まる前に、私は相当準備をしていった。Service Fabric はとても便利だが、マイクロサービスの基盤なので、しっかり理解しようとしたら相当いろいろ学ばないといけない。 私は事前に自分でコードを書いたり、CI / CD パイプラインを作ってみたりしていた。そうでないと、私はハックフェストで役に立つはずがないから。しかも、相手の会社さんは毎日のようにプロダクションでService Fabricを使い倒しているパートナーさんもたくさんいる。しかも、日本より技術的に進んでいる米国でのハックフェストなので、正直いうと通用するか相当自信が無かった。自分の準備が十分かどうかわからないままハックフェストがスタートした。
Julien 衝撃のひとこと
初回のハックフェストは、DevOpsチームからは私のみの参加だったが、2回目のハックフェストでは、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もとても喜んで我々はハイタッチした。もちろん私も、完璧にそのコードを理解したわけではないが、他の3人とディスカッションしながら進めることで、そういった仮説にたどり着くことができた。みんなの勝利だ。
私の仮説は
彼らは、もともと、「知っていた」から優秀なのではなく、準備ができてようが、知ろうが知るまいが、果敢に本番環境に近い環境で、実際に適用してやってみて、そこから学んでいるから優秀になるスピードが速いのでは?
ということだ。確かに、検討をいくら重ねても実力はつかないし、結局のところ本番環境で発生する問題には対応できない。
「とにかくやってみる習慣」がスピードを生む
私は、まず調べて、理解してできるとわかってからやるというステップを踏む癖がある。日本の多くの企業もそうじゃないだろうか?その技術が十分に使い物になって、本番でも本当に問題なく使えるということがわかって導入する。そして、あのケースはどうだろうか?このケースはどうだろうか?と思考をめぐらす。
一方、彼らを観察しているともっと単純に考えているように感じる。この新しいテクノロジーを使うと、この問題が解決しそうだからまず適用してみる。ぐらいのノリで、単純に考えてそれを実行する。実行すると決めたら、そこのマニュアルがなかろうがバグを踏もうが、回避策を考えて実際やってみてそこから学んでいく。あれこれ検討していると、時間だけ過ぎていくが、その間はノーバリューだ。しかも、長い間検討したからといって、良い回答につながるかはわからない。
だから、まず「こうだったら、難しい」「ああいう時は上手くいかない」ということを考える前に、まず適用してみて、そこから学びを得ているように感じた。早く実践して、そこから学んで方向修正をしていく方が結局早い。DevOpsのプラクティスにも、Testing in production という考えがあることを思い出した。
この2つの思考スタイルにいい悪いは特にない。ただ、おそらくソフトウェア産業においては後者のスタイルのほうが圧倒的にスピードが出やすいだろう。なぜなら、現在のソフトウェアは、バージョンアップや、新しいサービスの出現のスピードが非常に早い。だから、それが本当につかえるか調査しているうちに次のバージョンが出てしまう。
「知らないこと」を「悪」にしない空気が重要
彼らは何をするにもあまり準備をしない。そして、時間内で如何に成果を出すかに集中する。だから、彼らは「知っている、知らない」とか「準備できている」とかは、さほど重要ではなく、それぞれのメンバーが貢献できるところで貢献して、全員で成果を達成するという感覚が強いように感じる。誰がどんなスキルをどれだけ持っているとかはあまり誰も気にしない。 だから、私が知らないことがあっても、一回も不平不満を言われたことがない。
ただ一つ言えるのは「知らないけど、一緒にやってみましょう」は非常に評価されるということだ。今の時代、たとえマイクロソフトに勤めていても、そのサービスの全容を把握するのは一人の人間では不可能だろう。 これはマイクロソフトだけではなく、一つのサービスの全容を一人の人間が把握するのは無理になってきていると思う。一人のスキルですべてカバーすることも。 日本だと、プロが「知らないこと」があると、批判の対象になりやすいが、これは恐れを生んで、必要以上の準備につながっていると思う。だから、「知らないこと」があっても、当然であるという空気作りも重要と思えた。
日本では、「知りません」というのは勇気がいるが、向こうのメンバーを観察していると、本当は多少知っていることでも、「知らない」と簡単にいうのだ。「知らない」のは何も恥ずかしくない。ただ、彼らはそれでもその場で問題を解決しようとする。 助けを求めたり、人に聞いたり、お客さんと一緒にハックしたり。持ち帰りをせず、その場で解決しようとする。
「知らないこと」にアタックすることで成果が出やすくなる
ハンズオンやレクチャーの形式というものは、結局のところある人の知識がある人に移転することでしかない。ハックフェストは一つの例だが、誰かが一方的に物事を知っている事を準備するのではなく、とにかく集まって、みんなの頭脳を結集して、問題を解決するスタイルだと、二人分の知識どころか、二人が知らなかった部分にもトライすることになる。そうすると、その時間内で二人が従来持っていた以上の知識を獲得することになる。これはとても効率的だ。
新しい技術の獲得、適用に関してもこういう性質が関係しているかもしれない。実は新しい技術の初速のキャッチアップは日本の方が最近は優れているように感じる。例えばマイクロソフトの大きなイベントがあっても、次の日にはすでにまとめサイトができあがっている。これは早すぎる。
しかし、そのあとにその技術を本当に使われるか?となるとそうはならない。一方米国では、初速ははやくないものの、自分たちのアタックしたい問題にそれをともかく使おうとする。リスクの検討をがっつりするのではなく、これを試してみようとおもったら、とにもかくにもやってみる。
そして、知らないことにチャレンジしていくと、実際の問題に対応しているので複雑で難しユースケースにも対応していくことになるので経験が積まれる。さらに、自分がわからない状況でもどうやって問題を解決していけばいいか、その場でどうやってバリューを出していけばいいか?という訓練ができることになる。
米国では、技術者は基本コンピュータサイエンスを出ているというのもあるが、それよりも、あれこれ考えず素直に「ともかくやってみる」 作戦によって、たくさんの工数をかけることなく、効率よく新しい技術を獲得してスキルアップしていっている気がする。
日本でどうやってスピードアップをしていくか?
言葉だけは知っていたが、日本人の性質として語られるものに「不確実性の忌避」というものがある。不確実なものを嫌う性質だ。今回の体験で、文化の専門家が語る「不確実性の忌避」の性質の具体例を自分で体験できた気がした。自分はチャレンジングな性質だと思っていたがその自分がしっかり「不確実性の忌避」の性質をしっかり持っていたのだ。 こういう日本の「文化」に基づく、スピードの遅さに対処する方法としては、私は「西洋文化インストール」と言っているが、彼らの考え方を理解するところから始めるといい。大抵それは、彼らが優秀だからできることではなくて、それが理解できれば日本でも全然実践可能なものばかりだからだ。だから、チームで、マインドセットに関してチーム内でシェアして、チームがそれを気に入ればその考えで作業を進めると楽なことが多くなるだろう。
例えばこんなマインドセットでどうだろう?
「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と呼ばれて、クラスタ自体をまるで1台のサーバーかのように扱い、リソースのアロケーションをしてくれたりします。大変未来的で私は大好きなプラットフォームですが、残念ながら現時点では、せっかくリソースを最適化してくれていますが、使わなくても、使っても、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 が気になる方はこんなイベントもあります!
「それ、アジャイルできてへんのちゃいますか?」チェックリストの公開
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。
そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます!」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。
1. 進化型設計ができていない
アジャイル開発を実施するということは、単に繰り返し型で開発すればいいものではない。アジャイルは「変化に対応する」ことが大きな目的の一つになっている。スプリントや、イテレーションで繰り返し型の開発を行う場合、繰り返し型で開発を行って、変化があっても、メンテナンスを実施しやすいコードベースをキープしないといけない。 そうでなければ、早晩、プロジェクトはメンテ不可能になって破たんする。スプリントを通して、変化を受け入れても、メンテ可能な状態を保つには、十分な自動実行できるユニットテストが書かれている事、変更があったときに、それが自動で検査されること、そして、設計が「変化前提」の方式になっているということが重要だ。
こういったアジャイルにおける「テクニカルプラクティス」やその「マインドセット」を学ぶには、Extreme Programming を学ぶのが一番おすすめだ。更に高度なテクニカルプラクティスを学ぶには、DevOps のプラクティスを学ぶとよい。
アジャイルは世界的にスクラムが最も流行っているが、スクラムの作者も、「テクニカルプラクティス」を軽視しているわけではない。確か、Ken Schwaber がQ&Aでこんなことを言っていた。
Q: スクラムを採用しているが、エンジニアリングがちゃんとできないメンバーだったらどうなりますか?
A: うん。10倍のスピードでものができるよ。ただしゴミだけどね。
スクラムを回していても、ソフトウェアを開発しているケースでは、「テクニカルプラクティス」を無視してしまうと、非常に危険なこと になる。
1.1. テスト駆動開発
まず、最初におすすめしたいのが、テスト駆動開発(Test Driven Development) もしくは、振る舞い駆動開発(Behavior Driven Development) で開発するのをおすすめしている。最先端での議論では、TDDは死んだと言っている向きもあり、すべてをそれで開発しなくてもいいが、このいづれかの開発スタイルが「やろうと思ったら出来る」ということは絶対的に重要だ。だから、これが「できない」と言っているアジャイルベンダーは「エセ」といっても差し支えない。変更があったら当然テストが必要だが、変更が当然のアジャイルで、変更の度に全量手動テストなんてやってられないだろう。
十分な単体テストを書こうと思うときに、後追いで、ユニットテストのコードを書くと死ぬほど難しく、複雑になる。本番のコードは甘くないのだ。じゃあどうする かというと、少しだけ先に「テストコード」を書いて、テスト実行。エラーになったのを確認してから、本番コードを数行実装、テストを実行してパスしたら、次のテストコードの実装を少しだけ、、、更に、コードが重複したら「リファクタリング」という方法でコードの設計を改善する。 このようなステップを踏んで開発をすると、常にテストコードが十分な状態で無理なく開発を進めることができる。イメージがわきやすいようにビデオを作成したので、参考にされるとよいかもしれない。15分程度だ。
1.2. 進化型設計
次に進化型設計。アジャイル以前の世界の設計の考え方は、Big Desgin Upfront という設計の方法だ。時間をかけて分析、設計を行って、そのあと実装やテストに入る方法だ。一方、アジャイル以降は、進化型設計と言われる方法をとっている。ソフトウェアエンジニアリングの技術、例えばデザインパターンなどの知識が変わるとかそういう話ではないが、設計の進め方が変わる感じだ。これは、次のようなパラダイムの変更が影響している。
この図はExtreme Programmingから紹介された概念だ。1つの変更に対してどの程度変更のコストがかかるか?という図になっている。ウォータフォール開発時代は、一つの変更に対するコストは、後のフェーズに行けば行くほど指数関数的に高価になってしまっていた。例えば要件定義フェーズで問題を発見したら、要件定義書を直すだけだが、テストフェーズで発見したら、実装をおなして、設計書を書き直して、要件定義書を、、、といったように非常に高くついてしまう。 だから、要件を固めよう!ということを一生懸命やっていたのだ。一方アジャイルの世界では、テスト駆動開発などで適切に自動テストが書かれており、継続的インテグレーションにより、それが常時結合されて、テストされており、なおかつ、「進化型設計」を用いて、変更が簡単にできるのであれば、開発の後半になっても一つの変更に対するコストがあまり変わらないという状態を創れるようになった。
Big Design Upfront で設計している場合、最初の設計で想定していない変更が入ると、どんどん設計は崩れていく。そもそも、設計に長く時間をかけても、現在のソフトウェアは実装するまで本当のところがわからないケースが多いため、実装せずに設計するのは相当に難しいことだ。一方、進化型設計は、テスト駆動等を用いて、テストがある状態をキープしているので、変更を行っても、おかしくなったらすぐわかるし、DRY(Don't Repeat Yourself)をはじめとしたマインドセットでコードが作られていると、1箇所変えるだけで変更ができるので、こういった、コストカーブが実現できるようになる。だから変更に強くなる。
ということは、そういうことをしていなかったら、いくらアジャイルっぽくスプリントを回したところで、ソフトウェアはその変更に耐えられなくなってしまう。だから、テスト駆動などの方法を学んで、常にクリーンコードを書くことを実践しないと、あなたのコードベースは遅かれ早かれメンテ不能に陥ってしまう。
こういったことは、ツールをいくら導入しても解決できない。これは「開発の習慣」だから、本を読んでもすぐにできるわけでもない。じゃあどうするかというと、本当に「テスト駆動などの開発習慣を何年も当然として実施できる」メンバーを開発チームに入れるのだ。これは数カ月でもいい。本で読んでもすぐわからないかもしれないが、そういう「イケメン」と一緒に開発をすると、「あーこうだったのか!」と簡単に理解できる。ただ、こういう「技術イケメン」は普段あなたがお付き合いしているベンダーにはいないかもしれない。実際問題として、できないベンダーでも受注するために「できます!」というケースもあるし、自分が「できない」ことに気づいていないベンダーさんも多い。これを、一人で見分けるのは最初は難しいかもしれないが、シンプルな方法としては、アジャイル系のイベントに参加して、スポンサーセッション以外で登壇している人を捕まえて、その人に、「テスト駆動をホンマにできる人紹介してくれませんか?」とお願いしてみよう。そしたら、本当にそういうことができるベンダーさんを教えてくれるだろう。アジャイルができる人は、ちょっと話をしたら、誰がちゃんとできるかもわかるものだ。 もしくは、t-wadaという男を見つけて、彼にしっかりとした対価をお支払いするのがいいかもしれないw (注:TDDと言えばt-wadaと言われる日本のテスト駆動の大家ですw)
もちろん私に聞いてもらっても結構だ。
1.3. スプリントはミニウォーターフォールではない
よくある誤解で、スプリントの内部はウォータフォールになっているというのがある。実際はそうではない。進化型設計で開発すると、「要件ー>分析・設計ー>実装ー>テスト」という順番で物事は進まない。
先ほどのテスト駆動開発だって、そもそも実装の前にテストであり、実装をした後にリファクタリングで「設計」変更を行う。進化型設計とは、常に設計をしているような状態だ。実際に実装してから、ユーザさんに見せると、「あーイメージが違うよ」となるかもしれない。それは要件を確認している行為だろう。 つまりアジャイルの開発では、要件、分析、設計、実装、テストはいったり来たりする感じで開発されるので、シーケンシャルに流れるものではない。だから、もしそうなっていたら、ミニウォータフォールと呼ばれるバッドプラクティスに陥っている可能性が高い。これも、先ほどの「良い開発習慣を持った人をチームに雇う」ことが最も良い解決策だと思う。
2. ビルドが中心になっていない
次によくありがちな状態としては、開発のスケジュールが決まっていて、機能1を第一スプリントで、機能2を第二スプリントで、、というような形態になているケース。
これは何が問題か?というと、アジャイルの考え方では、「動作するアプリケーションで物事を判断する」ということがある。例えば、機能1ができて、機能2ができてから、機能3を作ってやっとお客様に見せて価値があるとかいうスケージュールになっている場合が多い。でも、それだと、第三スプリントが終わるまで、仕掛品を作り続けていることになり大変危険だ。アジャイルの場合は、最初のスプリントから、価値の出る単位で、開発していこう。別に「最終製品」のクオリティが実装されていなくてもいい。 最初のうちに必要なのは、価値の出る単位ものが、つながってビルドとなっているかだ。仕掛品は、つなげてみるまで結局本当にできているかはわからない。だから小さくてもいいし、機能がフルに実装できてなくていいので、つながっているものを創っていく。最初に作ったものがそのまま本番に使われると考えるよりも、最初のものは、アーキテクチャ的だったり、仕様的だったり、どれが正しいかを探索する実験のようなものだ。工数をかけず、さっとつなげて、ビルドをつくって、そこからフィードバックを得よう。だから、がっつり機能1、機能2を実装していくなんてことは、本当にそれでよいかわからないものに対して多大な工数をかけていくことに他ならない。 それは大変アジャイルの世界では危険な行為なのだ。まずそれがそのプロジェクトにとって「正しいか」を確かめよう。最小の工数で。
3. 予定の機能の実現がMUSTになっている
さらによくあるのが、予定の作業をすべて実装しようとしているケースである。アジャイルでやったからといって、自動的にウォーターフォールに対して生産性が強烈にアップするだろうか?ポイントは、「無駄なことをやらない」ことだ。すべての機能実装を100%やって、それを劇的に早める方式などない。
しかし、実際のところ、機能のうち、本当に使われるものは、40%未満だ。それを考えると、使われない機能を実装しないだけで、生産性は倍になる。多くの人は、「たくさん早く実装する」ことがよいと思っているかもしれないが、ポイントは、「やらないことを見つける」事だ。そのためにアジャイルでは「スプリント」をつかって学びを得て、いかに少ない工数で、より高い価値を提供するかを追求している。ものをたくさん生産したらたくさん価値が出るわけではない。だから、最初に予定している機能を100%実装するということは、無駄を大量に実装していることになり、そんなことをしたら、アジャイルで開発しても全然価値が出ないことになる。
たくさん機能を実装したら、たくさん価値が出るという考えを捨てることから始めよう。
simplearchitect.hatenablog.com
こういう「マインドセット」は、プロジェクトの開始前に関係者にプレゼンテーションなどをしてシェアするのをおすすめしている。後出しじゃんけんになると、反発してくる人も多く出てくるが、始まる前で、かつアジャイルを導入しよう!と会社で決めているならば、皆さん喜んで学ぼうとしてくれる。アジャイルコーチを採用して、こういう事を最初の段階から共有するようにしよう。「シンプルさ」に関するマインドセットもExtreme Programming から来たものだ。
Do The Simplest Thing That Could Possibly Work
4. マネージャーの指示でチームが動いている
最後のアンチパターンとしては、マネージャの人が、スプリントでの実施内容を決めていたり、マネージャの指示にしたがって、メンバーが動いているようなケースだ。
アジャイルの場合は「自己組織チーム」といわれる考えでチームを運用する。チームに技術的決定や、タスクの分割、割り当て、見積もり、、などなど大きく権限を与えて彼ら自身が考えて判断するようにする。DevOps の時代でもそれが進化したフィーチャーチームという考えになる。そこには開発チームだけではなく、Opsのメンバ、テスター、プロダクトオーナーも含まれる。そういうチームにがっさりと権限を与えて、彼ら自身に判断してもらいながら、プロジェクトを遂行させる。 普段プログラムを書いていない人が、現在の流れのはやい技術の世界で正確な指示が出せるはずもない。諦めて、彼らに任せよう。もしかすると、受け身なメンバーを見ていると、任せるのが不安かもしれないが、任せて、メンバーも慣れてくると、生き生きと自分で考えて行動するようになってくる。最初のしばらくの辛抱だ。 そうやって、自己組織チームができてくると、上の人が判断していた時代と比べても、圧倒的に早く生産的でイノベーティブになることができる。
任せる方法がわからない場合は、やはりアジャイルコーチをやとって、自己組織チームを構成するようにするとよい。組織的にそれが現在はできないって? 上に掛け合って実現しちゃえばいい。人事制度がって?変えればいい。やらなければ、生産性が相当わるくなって、チームがやらされムードに支配されてあまり生産的でもイノベーティブにもならないだけだ。
5. 日本の「常識」で考えている
最後に、私の自戒も込めて。我々はどうしても、制約事項を「日本の常識」で考えてしまい、「これはできない」とか判断してしまいがちだ。しかし、アジャイルは西洋の人が考えたものなので、西洋の人の考え方を学べば、もともとどういう概念でそれが提唱されたか、どういう前提条件があるのかが非常に理解しやすくなる。
これに関しては今すぐおすすめの解決策はなく、私のブログを読んでぐらいしかないのだが、現在Rochelle Koppさんという専門家の方と共に、そういった考え方を学びやすくする取り組みを始めている。しばしお待ちを。
おわりに
自分の経験ベースではあるが、日本の現場におけるアジャイルのアンチパターンとその対策についてまとめてみた。より多くの人が、アジャイル開発を実施して、実際にそのメリットを享受できればという思いでまとめてみた。基本的には、ツールや方法を表面上インストールしてもたいした変化は期待できない。重要な事は、本質を理解しすること、それから、良い開発の習慣を身につけることだという理解を持つこと。考え方や、習慣はすぐには身につかない。だからこそ価値があり、効果がある。
少しでも皆さんの参考になれば幸いである。