ADHD プログラマの私がやっと見つけた「達成すること」が出来る方法
私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。
遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。
多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。
「自分で何かを作れる人」が長年の憧れ
大変な偶然なのだが、今は私はエバンジェリストからプログラマになれた。ただ、それは私の実力というより、組織変更でロールが変わったためだった。NEC に新卒で入社した時は、OSのコマンドを担当したいと言ったのだが、配属は営業部門だった。営業活動は全くやる気が出ず、仕事が終わったら、会社に行ってUnixをずっと触っていた。そしたらある先輩が私をSEにしてくれた。
それからもプログラマになる事は心の中で燻っていたのだけど、「自分がやる仕事」は本当に全く出来なかった。仕事だけじゃなくて、スポーツも、勉強も、音楽も、何か「自分が上達する」という事に関しては致命的にうまくいかない。
スポーツも全然だめ。皆勤賞で、６年間やってたバスケは誰より１時間早く来てシューティングしたり毎朝ランニングとかやってたけど、レギュラーどころか、一秒も試合に出れなかった。
風向きが変わって来たのは、オブジェクト指向とか、アジャイルとかをやり始めてから、「コンサル」や「コーチ」みたいなもの、つまり、「人に何かやってもらう」とか、「仕組みを考える」とかは得意な様だった。それからもそういう人生だったけど、自分が本当になりたかったものは、「自分で何かを作れる人」だった。
3倍の努力をいつまで続けたらいいだろう？
今回はたまたま、憧れのプログラマになって、多分会社としては、今はロールが変わったばかりで能力に関しては多めに見てくれているが、私がマイクロソフトに入れる程優れたプログラマではない事は明白だ。このまま、３倍の努力を続けていないと、実力が無いのだからいつクビになっても仕方がない。しかし、「三倍の努力」は生活の殆どの時間を奪う。朝起きて、寝るまで、今はほぼ仕事、筋トレしかやっていない様な生活だ。同僚がバケーションを楽しみながらも、効率よく色々なものをマスターしていくのを横目に、自分は時間がずっとかかり、しかも中途半端。
４７年も ADHDをやっていると、こういう事も自分では受け入れている。ないものを嘆いても仕方ないから、別の方法を試すしかない。効果があったものとして、医師に処方されたリタリン。これは現在禁止されている。Lumosity というゲーム（科学的に効果がないと判定されたらしいが、ADHDの自分には集中力を上げる効果があるので今も契約している。）
あとは、それよりも強力なのが、オメガスリーのフィッシュオイル（こちらは、科学的にも効果が認められている）ただし、１日の「ここぞ」というところでそれを飲むので、効果は長くは続かない。
他に BCAA という筋トレで使うパウダーも集中力を保ってくれる働きがあるので、よく使う。朝型にして、仕事の後、運動をがっつりして仕事に戻るという働き方も、物凄くよくて、脳のキレも最高にはなるのだが、ADHDの「達成出来ない」問題は解決しない。しかし、ある日ふとした事で、解決策を思いつた。
プログラミングをしていて気づいた事
先日プログラミングの技術調査をして、サンプルコードを書こうと思っていてパソコンに向った。やりたかった事は、たった１つのAPIの検証。しかし朝７時から初めて気づいたら１５時だった。しかも、終わっていない。ADHDの私が昔から何回も体験した感覚。いつもながら自分にがっかりする。自分が知らず知らずに無意識にやってる見積りでは、「２時間ぐらいでできるかな。余裕を持って」だった。しかし、いつも私の考えている見積りは大幅に遅い方に間違うのが普通だ。
XP とかだったら、理想見積という考え方をやるときは、邪魔が一切入らない状態でという条件で見積もりをして、初回は2.5倍する。人はだいたい見積りが下手だ。しかし、私の場合はこの度合いがもっとひどい感じ。
筋トレに向かう電車の中で、なんでこんなことが起こったのだろう？というのをふと考えてみる事にした。今までは、ADHDだからこんなもんと思っていたけど、本人は本当に嫌な事だった。本当に。思い起こしてみると、もっとも大きな問題は「最初に思ったことと、関係ないことを大量にしていること」だった。ちなみに、次点は、「何かを調べているうちに、前にやっていたことを忘れる」だった。
全ての行動をはじめる前に書いてから始める
次の日にやってみたこととしては、やるタスクをリストアップしてから仕事をしてみようと思ったことだった。これは、例えばアジャイルの世界で有名なテスト駆動開発でも、最初にタスクリストを自分の手元の紙に書いてから始めるというのがある。
一定の効果はあるものの、ADHDの自分には「効ききらない」のも過去に試して知っている。しかし、今回は何かをするときに、先に紙に書かないと行動しないと決めてやってみた。
すぐに違うことを初めてしまう事に気づく
すると気づいたのだが、自分はすぐに違うことを始めようとするのだ。それも、「Webサーフィンしてしまう」とか、「Youtubeを見てしまう」とかわかりやすいもの以外が大量にあるのだ。
一つの例として私は、API の使い方を理解して、あるプロジェクトにコントリビュートしようと思った。今日のゴールは、無理せず、APIを調べて、その使い方を理解するためにサンプルを書くことだ。
Task 1. Azure Functions の Function Keys を Golang で取得する方法を調べる
今回は、Azure Functions の Functions Keys をGo lang で取得する方法を調べたかったはずなのに、APIリファレンスを見ているうちに、次々と違うことが頭に浮かぶ。
- 「あ、そういえば、次は CORSもすぐ調べないといけないな」
- 「あ、これ、CORSのAPIだ。」
- 「この構造体一体なんだろう？」
- 「コード読んでみよう」
- 「あれ、このプロバイダって一体なんだ？」
- 「この文法よくわからないな」
- 「サンプルプログラム作ってみよう」
- 「あれ、venderのディレクトリが認識できないぞ」
- 「Google で調べてみよう」
- 「うーんよくわからない」
- 「さっき何を調べているんだっけ？」
-> 時間ぎれ
みたいな感じで、一切何も達成できておらず、身にもなっていない。
こんな事だと、いくら最初にタスクリストを書いても効果がないのは当然だ。多かれ少なかれ人にはあるのかもしれないけど、ADHDの人にはこの特徴が顕著なのかもしれない。ADHDの原因として、今有力な説は、前頭葉が不活性で、短期記憶が人より短く、短期に覚えておけるものが少ない→だからすぐ気が散るというものらしいので、そらそうだなという感じだ。
行動する直前にタスクを書く
通常にタスクをリストアップするのは自分には通用しないと悟ったので、次にとった作戦は、タスクをこなしている途中で、「これをしてみよう」と途中で思った事も、まず、その場でタスクリストにまず書いてから、それをやるべきか考えてから、行動するという作戦にして見た。
これは正直めちゃめちゃ有効な作戦だった。途中で思いついた事は、今すぐやるのが「悪い事」とは限らないのだが、今は違う事に集中した方がいい事の方が圧倒的に多い。だから、一旦紙に書いてみると、「あー、これ今しないほうがいいや」と思うことが多い。たまに「確かに今のゴールにはこれはやった方がいい」となる場合もあるけど、前のように、あっちいって、こっち行って何も達成できないとかが激減して、自分が普段見かけた「普通の人」と同じ程度の生産性を出せている。
ADHD 特有の短期記憶の弱さにも有効
しかも、いいことにこの方法で行くと、ADHDの短期記憶が弱い欠点の助けにもなる。例えば、よくあるのが、コードの意味を理解すために、メソッドを読む -> ロジックを読む -> その過程で知らない構造体が出てくる -> 構造体を探し回る -> その間になぜ構造体を理解したかったのかを忘れる ということなのだが、これも最初は
1. ○○メソッドを理解する
というタスクだったとすると、これを調べているうちに、内部で使われている認証ライブラリがサンプルに必要であると気づく。そこの引数にはどんな値が渡せるのだろう。その型を調べないとと考える。 その時点でタスクを追加する。なぜ調べているかも書いておき、調べたら、Linkなども貼って置いたりする（すぐに忘れて、 ブラウザがタブの嵐になって、探せなくなるから）
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる https://docs.microsoft.com/en-us/.......
その構造体を探している間にもいろんな事に気が散る。あれ、このGetXXというメソッドこんなところにあったとか。前に調べていたやつだ。コードを見てみようとか考える。でもそれをやり始める前にグッとがまんして、先にに書いてみる
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる 1.3. GetXXメソッドのコードを読む
そこで、ふと我に帰る。「おっと、これは全然関係ないじゃないか」と。そこで、このタスクを Parking Lot （駐車場に入れる）Parking Lot は今やらないけど、重要なことという意味。
1. ○○メソッドを理解する 1.2. 認証ライブラリに引き渡せる構造体の条件を調べる
Parking Lot GetXXメソッドのコードを読む
ポイントをまとめると
- 何か思いついてやろうと思う前に書いてから始める
- タスクの内容は常にアップデートする
- タスクリストは常に追記し続ける
という単純なもの。通常のタスクリストの粒度よりずっと細かくなるのだが、ADHDの私にとっては「思いつく」-> 「違う事始める」にめちゃめちゃ効果がある。たったこれだけ。
別のサンプル
このやり方をより理解するためにに、私がこのメソッドを「歌の練習」に適用した時の手書きのカオスなタスクリストを公開したい。これをみるとどんだけ気が散ってるねん！という感じがわかると思う。どんな感じだったかをシェアしたい
最初に書いたタスクリストはこれだけだった。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
もちろん、全部できると思っていないので、1. 2. 3. は優先順位で最悪 1. だけでもいいと思って練習を始める。練習をし始めると、いろんな事を頭が思いつく。突然ウォームアップを歌い出そうとする。ちょっと待て、その前に、書いてから。これは、ゴールに近いのか？と考える。どう考えても違うので、Parking Lot の方に
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする
次に思いついたのが、喉があいた状態をキープするために、テンポを落とした状態で歌ってみる。という事。確かに、これは、最初にやっている「あいた喉の状態をキープ」の練習に有効で今やるべきなので書いてから、今実施。（ちなみに、実際の写真は自分でも字が読めないほどカオスやけど、やってるときは認識している）
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
次に思いついたのが、あー、そういえば、イタリアに旅行に行きたかったけど、まだ予約してないなという事。もちろん関係ないから、パーキングロットへ。もちろん今やらない。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする イタリア旅行調査
次に思いついたのが、ヘッドボイス、ミドルボイス、チェストヴォイスをいつ切り替えるかを考えないといけないなという事。これは重要だけど、「あいた喉の状態をキープする事を できるようになる練習」とは違うよな。今しない。
最初の１小節を完璧に歌う 1. あいた喉の状態をキープする ・ゆっくり歌ってみる（キープしたまま） 2. 母音、子音のバランスをとる 3. 正しい音程と、音の長さを確認する
ウォーミングアップする イタリア旅行 ピアノで音をとって、ヘッドヴォイス、ミドルヴォイス、チェストヴォイスの切り替えを確認する
次に思いついたのは、「あー、英語の発音悪いな。母音と子音のバランスを調整しないと聞こえが悪い」しかし、これは書く前に、リストをみると、２でやる事になっているので、今はまずは喉の状態をキープする練習を続ける。
といった感じで、振り返ってみると、これがこの後もずっと続いて「これでもか！」というほど気が散っている。しかし、この単純なリストがあれば、気が散っても、元の目的に戻ってくることができるので、結局この日は、1. はおろか 2. まで達成できた。まじで、人生でこんなことはじめてちゃうやろか！
まとめ
先の例でも、この方法を使ったら、プログラミングの方も超順調で何回も脱線しそうになったり、忘れたりということなく、「達成」することができた。こんなのは人生ではじめて。 この方法がADHDの人の全員に有効かはわからないですが、自分を救ってくれた方法なので、シェアしておこうと思いました。
日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない
ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。
Microsoft Hack week
日本人はイノベーティブ
Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。
自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日本から出ていかない。もちろん例外はあるがとても少ない。実際に、米国で働いて見ると、彼らと比べて「人」としての能力に違いはない。日本人のエンジニアでイケてる人にたくさん出会って来たし、向こうは基本コンピュータサイエンスは出ているからベースラインは高いけど、日本のエンジニアでもイケてる人はたくさん現場にも溢れている。むしろ極めているような人は日本の方が多いのではないかとも感じる。ではなぜイノベーティブにならないのだろう。
日本流ハードワークと米国流ハードワーク
自分が日本に帰って来て、久々に、人に言われたからではなく、ついつい仕事をたくさん受けて日本流のハードワークをしてしまった。米国にもハードワークな人も沢山いるが、例えば、「忙しい」というイメージが彼らと違うことに気がついた。日本では忙しいというと、残業は当たり前で、そろそろ休出しないと回らないぐらいのイメージが「忙しい」だが、向こうにいるときは、残業はおろか、定時内にできる仕事量で、しかもそれがだいたい埋まっていたら「Busy」という感じだ。
定時だけを使って、新しい仕事を始められない状態が「Busy」だから、ハードワークな人も、朝も昼も夜もなく働いている人ではなくて、バリューを出すために、たまに日曜とかでも仕事したりするけど、５時に帰るときは帰るし、みたいな感じで、日本みたいな仕事量に追われてパツパツという感じでもない。そもそも仕事量を沢山こなすことが求められないし、誰も喜んでくれない。求められるのはインパクトだ。
simplearchitect.hatenablog.com
余裕があるからイノベーティブになれる
そういう日本流のハードワークを久々にしてみて気づいたのだが、米国にいて仕事をしているときは、毎日５時で終わりで、大量の仕事をこなすのを求められないので、５時の時点で会社の仕事をしなくてよくなる。私は、３流プログラマなので、家に帰ったら、その日に学んだことを自分のためにブログに書いたり、オープンソースのプロジェクトにプロバイダを書いて貢献したりとかしていた。
ところが、日本流ハードワークをやってしまうとどうなるかというと、そんな余裕は全くない。仕事で新しい技術を使ったら、学んだことをブログにしないと身につかない性格なのに、それをしている暇がない、オープンソースに貢献する時間も圧倒的に減った。米国にいるときみたいに、仕事の中で疑問に思ったことを調べて、コードを書いてブログを書くみたいなことをする暇が全くなくなった。つまり、「仕事をこなす」ことをやっているだけだ。
Bruno と David と会社帰りにウェイクボーディング
私の仮説だが、米国でも Moon lighting と言って、会社の仕事とは別に夜にソフトウェアのプロジェクトをやるという話があるが、前者だと、十分できそうだが、後者の環境だとそんなことしている体力も気力も相当なものが必要だろう。また、日本のハードワークだと仕事をこなしているだけなので、仕事で学んだことをより深く学んだり、全然違うことを学んだり、プロジェクトをしてみたりという時間が取れない。だから、折角イノベーティブな性質を持った私たちが、仕事を沢山こなすことを求められる日本のIT 業界ではイノベーティブになれようがないのではないだろうか？
よりイノベーティブになるための方策は？
つまり、エンジニアに余裕がないから、イノベーティブになりようがないので、「余裕」ができるようにすればいいということになる。
この問題の対策としては、日本に止まるなら、Rochelle さんと作った８つの習慣みたいなものがもっと広まって、多くの人が違いを「認識」し始めることじゃないだろうか。
simplearchitect.hatenablog.com
それよりさらに良いのは、働き方改革とかの成果を待つより、どんどん転職して海外の企業を体験するのはどうだろう。今まで、「常識」で「無理」と思っていたことが平気で実現されている世界に触れると、「あー、あれって不可能じゃなかったんだ」と思えるようになる。日本では３５歳定年説と言われるのに、４６歳の私が、今年からSoftware Development Engineer としてコードと再び格闘している。私が得意だった政治的なことは一切していないが、過去最高の給料をもらっている。我慢とか勿体無い。もし、あなたがプロフェッショナルであろうと思うエンジニアであれば、海外の企業とかを一回でもいいので体験するのは本当におすすめだ。
Microsoft のオフィスでの風景
良いエンジニアを確保したい会社さんはチャンスだ。他の会社さんが、低賃金で、仕事量をエンジニアに求めている間に、米国みたいな労働環境を提供してみると、エンジニアにとっては日本にいながらそうなれるのは、超魅力的だろう。しかも、そうなると、エンジニアの成長も早く、イノベーティブになるので、海外進出とかではなく、普通に、世界の一員として活躍できるだろう。ソフトウェアは頭脳労働の権化で、早くタイプできる人が必要なわけではない。成果は数や量ではない。コードで如何にインパクトを出すかだ。そのためには、「こなす」ではなく、本当に「理解し、出来るようになる」ことのほうが重要だ。
海外の企業を体験してみよう
日本では我慢しなければならないものが、全くなく、政治より技術が求められる世界は本当に楽しく、もっとエンジニアリングができるので成長も早い、給料もいい、無理に忙しくないからイノベーティブになれる。
こんな話を聞いたことがある。ある地域のレストランがまずいのは、お客さんが「まずい」と認識していないからで、お客さんが本当に「美味しい」ものを見分けられるようになると、「まずい」ところには誰も寄り付かなくなるので、相対的にレストランの味のレベルが向上するという話だ。それと同じかもしれない。
どんどんそういう人が会社をやめて海外に流れていけば、日本企業でもITの良い人材を確保するために待遇を上げざるを得なくなるかもしれない。プログラマを出来るだけたくさん働かせたいと思うような、労働条件の悪いところで働かなくなるかもしれない。少なくとも、世界が変わるのを待ってるより自分が幸せな方がいいし、もしかするとそっちの方がより日本のためかもしれない。
アジャイル開発の導入のビデオシリーズを作ってみた
今年から会社の方針も変わり、エバンジェリストからSoftware Development Engineer という職種に変わった。プレゼンとデモの世界から、お客様と一緒にハックしたりコードで世の中にインパクトを出す仕事に変わったので、楽しくも四苦八苦しながら頑張っている。
先日友人の Rochelle Kopp さんから Agile のビデオを作ってくれないか？という依頼があった。今から Agile を始めたいと思っている企業さんが増えてきたのだが、残念ながら私はコードを書くのが`今の仕事なので、エバンジェリストやコンサルをやっているときのように対応できない。出来るとしたら、自分が新技術導入 (Serverless, Microservices等)をご支援しているプロジェクトに限られる。 だから、彼女がビデオを作ってくれたらうれしいといったので、既存の資料を少しカスタマイズして、ビデオをいくつか撮ることにした。ビデオでは、インタラクティブにお話しできないので、どこまで皆さんのお役に立つかはしらないが、クローズにするよりは、とりあえずシェアしてみようと思った。
現在プログラマとして米国の開発プロジェクトに参画したりするなかで、学んだ内容などももりこみながら、アジャイルの全体像と、日本で多くの人がアジャイルの世界にはいってくるときに、「なんでこうなるんだろう」と疑問に思いそうな部分に関してお話ししてみました。
プレゼンテーション
アジャイルの全体像 (17:22)
背景とか、全体像のお話し
アジャイルの考え方 (43:42)
アジャイルの考え方で日本人的にしっくりこないと思われる部分の解説や、本を読んだだけで実行したら誤解しそうな部分についてのお話し
simplearchitect.hatenablog.com
simplearchitect.hatenablog.com
アジャイルプラクティス (27:47)
アジャイルの具体的なテクニックをいくつかご紹介。ただ、これだけですべてカバーできているわけではないので、是非次はアジャイルコーチを呼んで実践を。やる前からたくさん学んでも、頭にはいらないので、全部学び終えようと思わず、この程度の知識を得たら、やったことがある人と、すぐにやり始めるのがいいと思います。
Q&A (26:47)
よくあるQ&Aに対して回答してみました。本来はお客様や状況によって違うのですがビデオなので、ありがちなシナリオについてコメントしてみました。
次の一歩
この程度の情報を得たら、まずはやってみることをお勧めします。まずお勧めのステップは、上層部を巻き込んで目的を明確にしたのち、アジャイルコーチを連れてきます。次に、誰もアジャイルをやった人がチームにいないなら、アジャイル開発がバリバリできるプログラマをつれてきて、小さくてもいいからチームをつくって、そこで、濃度１００％の妥協なしアジャイルチームを実際にやってみるのをおすすめします。
技術なきマネジメントの衰退とその対策
今回は、マイクロソフトにいて自分が感じている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.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。例えばウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。つまり、実際の「フィードバック」を受けるまでの時間が長い。これが問題だ。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう！
いかがだっただろうか？もっといいプラクティスがあるかもしれない。私もまずは３つをピックアップしてみた。もしもっといいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。
