Scrum / DevOps ã®å°Žå…¥ã‚’åŠ é€Ÿã™ã‚‹ã‚°ãƒ­ãƒ¼ãƒãƒ«ãƒžã‚¤ãƒ³ãƒ‰ã‚»ãƒƒãƒˆã€€ï½žï¼˜ã¤ã®ç¿’æ…£ その１ ～

クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「８つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。

今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「８つの習慣」を初めて発表させていただいた。

2017.scrumgatheringtokyo.org

　「８つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうまくいかなかったり、効率が悪くなってしまう。

　そこで、米国並みのスピードでの技術導入や、本質的な導入を目指す方のために、「８つの習慣」を考案した。 Agile / DevOps の導入を本質化し、加速するための西洋文化のマインドセットだ。日本人は「生産性」が悪いせいでグローバル的には大変損をしていると思う。それさえ何とかなれば、日本人の文化の良さを生かして、ソフトウェアの世界でも輝ける存在になると私は信じている。重要なことは、西洋を崇め奉りたいわけではなく、日本文化と西洋文化の考え方を「選択可能」にすることだ。

docs.com

　ただ、講演では時間が４５分なので、すべてを解説する時間がなかった。まずは「興味を持ってもらう」ということをターゲットにしたので、「実際どうすればいいかわからない」だろうとう反省がある。今後ロッシェルさんとビデオを公開して「８つの習慣」をより学びやすくするつもりだが、このブログでも不定期に「８つの習慣」が何で、具体的にどういうことをすれば導入できるかについて解説していきたい。

「８つの習慣」を理解する方法

「８つの習慣」は「マインドセット」なのでなかなかに理解が難しい。ただ、一番簡単な方法がある。米国人、もしくは、西洋人のチームに参加して１年も一緒に仕事をするといい。そしたら簡単に彼らのマインドセットを体験できるし、その破壊力を体験できるはずだ。そして、彼らが「人として優れている」とかではなく、我々でも十分できる「習慣」のために生産性がいいことを体験できるので、簡単にマネできると思う。

　ただ、問題は、そういう環境にいる人は国内にはあまりいないということだと思う。だから、そういう人のために、国内にいても、そういうことを学べる方法はないだろうかとロッシェルさんと一生懸命考えたものだ。もちろんまだ出来たてなので、まだまだの部分はあると思うが、それでも改善を進めながら、技術導入を本当に加速したいと思っている人がにお役に立てればと思う。

「８つの習慣」

1. Be Lazy　
2. リスクや間違いを快く受け入れる
3. 不確実性を受入れる
4. サーヴァント・リーダーシップ
5. セルフマネジメントチーム
6. 従業員への信頼
7. 個人の自信
8. 階層関係のパワーバランス

これがロッシェルさんとディスカッションして整理した、「８つの習慣」だ。我々が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にとって共有される。 　例えばロッシェルさんとのプレゼンテーションの会議をしているときも、「ここと、ここを修正して後で直しておきます」ということはせず、その場でプレゼンを修正する。そしたら終わった後に時間を取らなくていい。そして、会議の時間の間にロッシェルさんに共有する。意思決定も、持ち帰って検討しますではなく、間違っててもいいので、その場で意思決定してこうしようと決める。

　昔のブログエントリで書いたが、こういうことを元から実践している人がいる。ソニックガーデンの倉貫さんだ。私がコンサルタントの時、彼と仕事をした時の一言は忘れられない。

牛尾さん。会議の準備をしないでくださいね。無駄だから。そうではなくて、会議の時間を価値の高いものにしましょう。 　

kuranuki.sonicgarden.jp

　彼との会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。もし、どれぐらい「準備」をしなくてもいいのか？がわかりづらいなら、いっそ準備「なし」でどの程度できるか体験してみるといいだろう。そして、出来るだけ「会議の時間内」のみで完結できるように頑張ってみる。そうすれば、思ったより「できる」ことに気づくのではないだろうか？ 　できない場合は、きっと、「余計なこと」を頑張っている可能性が高いので、会議のゴールに不必要なものを減らしていく練習をするとよいだろう。

おわりに

　これらの３つのプラクティスは、もちろん簡単ではないとは思うし、実際の例を見ないとなかなか理解できないかもしれない。「どれぐらい」ができている状態かわかりずらいかもしれない。

　だけど、これらを「意識」してみて、「実践」していると、だんだん上達してくるし、こういったことが「出来ている」人を目にするとアンテナが立っているので「あーこれぐらいできればいいんだ！」という気付きを得やすくなる。少なくとも意識して「実践」してみるだけで、かなり変わってくるはずだ。

次回は「リスクや間違いを快く受け入れる」習慣について書いてみたいと思う。