「ウォータフォールは何のメリットも無い」のラジオ番組の公開
おかげさまでたくさん読んでいただいたブログですが、この内容について聞いてみたいということで先日アジャイルラジオという番組の収録を行いました。
simplearchitect.hatenablog.com
前半、後半になっています。私の意図していることなどについて、自分の声でお話しさせていただきました。 よかったらお楽しみください。
ソフトウェアの納期見積もりは、星占いレベルのものであると思う
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。
注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。
ソフトウェアの見積もりの正確さ
ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。
この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。
請負開発を実施するときに、私がSIerだった頃、画面や帳票の仕様を確定する遥か前に「見積もりが間違っていてもいいので、大体でいいから見積もってくれないか？」という話を受けて見積もりを実施する。その見積を元に「予算」や「納期」が決定されていた。 実際に、見積もりとは大幅にずれるわけだが、実際そうなってみると「間違ってもいいといっても、2倍以上開きがあるのは、ありえないだろう」みたいな話になることも多かった。しかし、この図を見ると、統計上至極当たり前の現象であると言える。
見積もりに４倍の開きがあるものなど、占いレベルでなくてなんだろうか？1.6倍の開きと言ってもかなりのものだ。しかもこれは「画面・帳票の仕様を完全にFixしたもの」という前提である。
若干乱暴だが、この著名な書籍の結論をお話ししておくと、スケジュールの見積もりに関しては納期を１点に決めてしまう見積もりは、クレイジーなので、ここから、ここまでの範囲内の見込みといったような「レンジ」を持った見積もりを様々な見積もり手法を用いながら実施するとよいということになっている。
つまり、現在のソフトウェア開発においては
納期を１点に正確に見積もる方法は、世の中には存在しない
のだ。
納期をある程度正確に見積もれる状態は、何回も同じような状態で繰り返し実施してどの程度の時間がかかるか想定できるものに限定されている。ソフトウェアに関していうと、毎日のように新しいツール、機能がでてきて顧客の要望も、競合の動きに合わせて変わっていく。プロジェクトは２度と同じようなプロジェクトは存在しない「不確実性」にあふれた性質をしており、ソフトウェアにおいて、納期の見積もりは、未来を予見する、博打に等しいものだと思う。
納期厳守のプレッシャー
ところが、日本では一旦決めた「納期」を守るプレッシャーが相当に存在する。それが、どれだけ妥当性に欠けるものであったとしても、それを守るためなら徹夜でもなんでもやって納品するのが「プロ」と言われる。だから、相当無理なスケジュールでも、「やるしかない」という話になり、プロジェクトが炎上して、徹夜三昧になった挙句、プロジェクトは延期されるなんてことはざらにあるだろう。
では、「納期」が絶対なものとすると、「物理的」に考えるとどういう手が打てるだろう？これは、ソフトウェア開発の「納期」「コスト」「品質」「スコープ」に関する物理的な制約を表した図だ。
「スコープ」つまり、実施する範囲を変えないまま、「納期」を守ろうとしたら、「品質」か「コスト」を犠牲にしないといけないというトレードオフの図だ。プロジェクトが遅れている状態で、「納期」を守ろうとしたら、「コスト」「スコープ」「品質」もしくはいくつかの複合要素を妥協する必要がある。 計画通りいかなかったプロジェクトは、優秀な人がいたなら、間に合わなくなりそうな兆候を見た時点で、「作業量」を減らしたり、「テスト」の手を抜いたり、「お金」をかけて高級なツールを買ったり、人を増やしたりということをしているだろう。
物理的にいって、ソフトウェア開発において「納期」「コスト」「品質」「スコープ」を確実に守るプロジェクト遂行ができる可能性は先ほどの見積もりの話と合わせて考えると、少なくとも理論上、統計上は「無理」に等しいのだ。
インターナショナルチームでは、「納期」はほとんどない。
私も「納期」に関しては疑問を持たず厳守するものという考えがあったが、インターナショナルチームに入ってから大きな疑問に代わっていった。インターナショナルチームに入ると、そもそも「納期」がほとんどないのだ。数が少ないが、あったとしても、例えば自分が４時間程度かけたらできそうなものに対して、２週間ぐらいの「納期」が設定される。つまり、楽勝でできる余裕がある状態でしかそういう納期が設定されない。日本だと、金曜日の夜に、「これ月曜日までに、なるはやで」みたいな仕事の依頼が来ることもしょっちゅうだったが、インターナショナルチームでは、そういう展開はありえない。
もしそういう話になったら、仕事を依頼したほうのマネジメント能力が疑問視される。尚且つ、やってみたけど、間に合わなかったケースがあったとしても、それを無理に詰めて１日も早く終わらせようとはしない。課題を仲間と共有して、対策をうつなり、継続してやるならさらにそこから余裕を持った目標日が設定される。そして、今回何が課題で、何が学べたか？ということを関係者で共有して、次はどうしようという前向きな話になる。
よくよく考えると、見積もりは、未来を予見する行為なので、ロジカルに考えると、理論上も、統計上も、100%達成できるはずがないので厳守などできるはずがないのだ。見積もりや計画を立てることはいいことだと思うのだが、少なくとも理論上はそれを「Fix」してしまう行為は自殺行為とも言える。見積もりや、計画は、あくまで「予定」であり、何かが変わったり、想定外のことが発生したら、それに合わせて「変更」 していくものであると思う。
そもそも「納期」はどこまで重要なのだろうか？
日本では大小にかかわらず、一度設定した「納期」は守ることが大変重要視される。しかし、実際のところ、「納期」はどれぐらい重要な要素なのだろうか？日本にいるときは、大小たくさんの納期が設定される。相手からも「いつまで」というのが緊急なものをたくさん含んで設定されたり、自分で決める必要があったりする。そんなこんなで、日々見積もりが想定外だったら、残業休出でカバーする場面は私もしょっちゅう あった。
海外に行ったり、インターナショナルチームに加わると「納期」はあまり重要でない気がする。そういえば海外の電車は遅れるのもしょっちゅうだし、電車がプラットフォームに入るまで、どのプラットフォームにつくかもわからない。会議も開始時間に遅れないことは日本はむちゃくちゃ重視される。一方海外だと、開始時間に遅れても、会議自体に出なくても「自分次第」になる。問題視もされない。自分次第だからだ。
よくよく考えると、海外の巨大なソフトウェア企業がロードマップを発表したり、いつ頃、この機能をリリースするとかアナウンスしても、しょっちゅう、しかも、がっつり遅れたりする。しかし、それでどの程度のビジネス的な損害があるのだろう？ 確かに、「納期」をがっつり守ったほうが良い場面というのは存在するが、本当はそんな場面は多くないのに我々は何でも早くしようとして無駄に納期を設定していないだろうか？
インターナショナルチームである納期といえば、ビジネスレポートや、勤怠の提出、出張申請。ビジネスレポートは、月末だが、毎日やっていれば全然問題ないし、全体的に物量が少ないので簡単だ。勤怠も、忘れていたら相当早くからリマインドが来るし、やるのを忘れ続けてもデフォルトでサブミットされる。出張申請はやらなかったら、自分の財布にお金が入ってこないだけだ。 テクニカルワーキンググループで、自ら立候補した資料をつくるのに、「絶対的な納期」ではなくて、「ここまでにやろう」という日は設定される。でもむっちゃくちゃ余裕はあり、ぎりぎり達成可能な日とは程遠い、絶対にできるだろう日しか設定されない。もし、その日までにできなかったら、きっと自分のパートの部分がカットされてリリースされるだけだろう。なんてことはない。次回のリリースのときに追加すればいいだけだ。
私はこういうことが重要じゃないかと思う。
その「納期」が本当に重要かをもう一度自問自答してみる
私のポジションの問題もあるかもしれないが、肌感覚で感じるのは同じポジションでも、日本でいるときより圧倒的に納期設定が少なく、あってもむっちゃくちゃ余裕があるということだ。だから、逆にみんな数少ない納期は言わなくても普通に守る感じだ。全く「無理」が無いから。
「無理を承知」をなくせばうまくいく
これらの多くの問題は、「無理」なものを「無理」と本当の意味で認識していないことからくるのではないだろうか？日本にいると「無理を承知 でお願いします」「しばらく死んでくれ」「無理だけどやるしかない」という言葉を聞くこともあるでしょう。 納期の見積もりだけではないが、「無理」なものを「無理」と認めないマインドセットというのは相当いろんな悪影響がある気がする。「無理」と認識したうえで、次どういう「無理のない」手を打つか？は建設的だと思うが、「無理」なままつっこんでも、博打程度の確率でしか成功しないのは自明なことだろう。
でも、我々は、様々なプレッシャーや過去の習慣から、「無理」でも頑張ろうとしてしまう。そもそもその「無理」は本当に価値があるものなのだろうか？納期が１週間、いや１か月、さらに３か月遅れてどれだけのビジネスインパクトがあるのだろうか？「現行のビジネスモデル」で考えると、「少なくとも自社にはインパクトがある」という話になると思うが、みんなが「無理」なものを「無理だよねー」と顧客も、開発者も、運用者も、企画も、認めるような考えを業界に広めていくほうがより重要な気がする。そうでなければ、悲惨なことが続くだけじゃないだろうか？
無理なものは無理なのだから、それを単に認めよう。認めてから対策を考えよう。
「納期厳守」がもたらす圧倒的なデメリット
「納期厳守」で無理を承知で、人をたくさんぶち込んで、徹夜徹夜で何とかソフトウェアを仕上げて納期通り納品した。これは大変な美談になることが多いが、ソフトウェアの専門家からすると、まったくプロフェッショナルさからかけ離れた行為だ。
何故なら、ソフトウェアは、リリースして、使われてからがなんぼだからだ。それは結局のところ先ほどの「納期」「コスト」「品質」「スコープ」のトレードオフに対して一番曖昧な「品質」に対して大幅に妥協した結果に過ぎないからだ。徹夜でふらふらの頭でしっかりした、メンテナンス性が良く、自動テストがついているようなコードが素早く書けるはずがない。これは物理的な制約だから。
だから、そのあたりが妥協されていることになる。納期通りリースしたところで、そのプログラムはその先何年もメンテナンスされていくのだ。「品質」を妥協した先に待っているのは「バグ」だけではない。「技術的負債」と言われるものはある意味「バグ」より恐ろしいものだ。
技術的負債の恐ろしさ
「技術的負債」というものは、技術的に良くない何かがソフトウェアに組み込まれている状態だ。例えば汚いコードとか、可読性の悪いコードだ。それは必要悪として一定以上は仕方がないが、借金と同じでそれを定期的に返していけば、特に問題ないのだが、返済せずにためていると、破たんしてしまう。つまり「メンテ不能」状態に陥るのだ。だから、「コードを常にリファクタリングし、重複の無い状態をキープして、１つの変更に対するコストが膨れ上がらない」ように、コードベースを常に変更可能な状態に保つ必要がある。しかし、この「技術的負債」の問題は本当に重要かどうかわからない「納期」の前にスルーされることが多いように思う。そんな欠陥三昧のソフトウェアを本当に重要かわからない納期に合わせてリリースしたところでそれは本当にプロフェッショナルな行為で顧客のためになるのだろうか？
さらに、「納期厳守」は「占い」レベルの確度なので、「守れない」場合もある。その場合、「技術的負債」をてんこ盛りに抱えたまま、さらに納期遅れで納品される。そういったシステムは、１つの変更に多大な工数がかかる。変更が難しいからだ。だから顧客は将来的に高いお金、そして、長い納期を受け入れないといけなくなる。
この「技術的負債」は先端の開発手法を用いている米国であってもトップ３の問題に数えられるぐらい難しい問題だ。DevOps Enterpriseというカンファレンスに行くと、よく上がる問題として、「レガシーマイグレーション」「自動単体テストを記述すること」「技術的負債」がいつもテーマにあがる。それぐらい先端の手法を用いている会社でも苦労するポイントだ。なぜなら、「技術的負債」は、ツールを導入したら解決できるものではなく、「クリーンコード」がどういうものかを共有し、チームで、その文化を育てていくような「習慣」だからだ。それぐらいじっくりとりくまないと、「メンテに非常にコストがかかるソフトウェア」が出来てしまうものなのだ。
シンプルな解決策
これらに関するシンプルな解決策は、必達の「納期」というのをあきらめるというのがシンプルだ。だって無理なのだから。実際に、No Estimatesというムーヴメントがある。「無理」なものなのだから、「やる価値もない」。「計画」は見通しをよくするために立てるけど、それを「絶対」のものにするのが、意味のない行為だと思う。単にリスクを増しているだけだ。
完成見込みを知る方法
ソフトウェアの世界で、現在の技術的にも仕様的にも不透明な現在において、妥当性があり、完成見込みがどの程度か？を知るおすすめの方法はないだろうか？先に見積もりの本にもさまざまな手法が紹介されているが、一番シンプルでおすすめで、なおかつたくさんの人が使っている方法は、その開発しているチームの「実績」を測定して、「実績」をもとに予想する方法だ。 実際見積もりを確定させるための「変数」は多すぎる。例えば、人月で考えたところで、プログラマの生産性は、10-25倍の開きがあり、チームの中にそういう人が含まれているか？というのを知るのは難しい。そういう人がいたとしても、誰かが仲たがいしたら生産性が落ちるかもしれない。顧客のチームに問題があれば、沢山の「待ち」が発生するかもしれない。こういうのを見積もりの段階ですべて見切るのは不可能だ。チームごとに生産性は異なるのだ。
だから、そのチームで、一定期間働いて、その間、何らかの指標で生産性を測定する。そして、実際にチームの生産性が安定したところで、残作業をどの程度の割合でこのチームはこなせるか？という割合から、「完了見込み」の日を設定するとよい。ただし、これはあくまで見込みだ。 もし、その日に何らかのリリースをしたいのであれば、機能が無理なく盛り込めればよし、そうでなければ、優先順位をつけて、盛り込めないものをそのリリースから落とせばよい。これは一つの方法だ。
この方法の良いところは、実際にビルドして、「動作するアプリケーション」の進捗実績をもとに計算しているので、確実性が高まることだ。私は、「純粋なウォータフォール」はメリットが無いと思っているが、その理由の一つに、「ソフトウェアは、コードを書かずして設計はできない」ということがあるからだ。少なくとも現在のソフトウェアでは、慣れた言語ですら、バージョンアップがしょっちゅうあり、使い慣れたライブラリをインターネットから落とす際に仕様がかわって動かなくなったり、ドキュメント通り動かないことは普通だ。だから、コードも書かず、紙だけで設計するなんてことは到底できない。
マイクロソフトの伝説的なスーパープログラマの中島さんが最近「なぜ、あなたの仕事は終わらないのか？」という書籍を出している。大変面白い内容なのでよかったら是非読んでいただきたい。 そこで紹介されている、彼が必ず納期を守った作戦というのは、納期をしるために、実際にモノを作る作戦だ。ロケットスタートでモノを作ってみて、最初の２日間で８割程度の完成にもっていけたらその後の納期を受け入れる。だめなら、この仕事は難しいから、スケジュール変更を行うというもんのだ。
これも、無理がない素晴らしい考えだと思う。
「納期」が重要なケースにどうしていくか？
「納期」が重要ではないケースが多いのではないだろうか？という話をしたが、一方で数は我々が思ってるより少ないと思うが本当に「納期」が重要なケースは存在する。例えば、オリンピックで使われるアプリケーションをリリースするなどの場合は、納期をオーバーしたら、ほぼ意味がないような状態になってしまう。こういったケースではどうすればいいだろう？
いくつか方法があるが、先ほどのインターナショナルチームの例や、中島さんの例のように「絶対守れる納期を設定する」方法を実施すればいい。設計書だけあるような状況は、コーディングやテストを始めたら一発で状況が変わるので危ない状況だ。だから、どうしても納期を守らないといけない場合は、楽勝でできるような納期を設定して、早い段階で、実際にアプリケーションが動作するようにしておくのが一番安全だ。 フル機能でなくてももちろんいい。ソフトウェアに実装されている機能で実際につかわれるのは４割程度なのだから。まず機能がすくなくていいのでリリース可能で、単純な動くアプリケーションをプロジェクトの早期に作り、そこに少しづつ優先順位に従って機能を追加していく。納期が来たら、そこまで出来たものをリリースする。そうすれば、多少機能は落ちるかもしれないが、確実に「リリース」は「納期」どおりにできる。
さらに安全な方法もある。「作って」から、「納期」をアナウンスするのはどうだろうか？例えばWindowsなどのリリースを見ても、実際にそれのリリース日が発表される随分前から、αテストや、βテストが実施されている。つまり裏を返すと、バグは多いかもしれないが、リリース予定の既に動作するアプリケーションが出来ている状態なのだ。そこから、バグを取ったり、機能変更をしたりしてリリースする。つまり、バグの残りの多い少ないはあるにせよほぼ確実に「納期」は守れることになるのだ。
こういったリリースは、大規模なものというイメージがあるが、現在だと、「フィーチャーフラグ」というプラクティスを使って、簡単に実装できるようになっている。ソフトウェアに新機能を組み込むときに特定の機能を、特定のユーザグループに公開する「スイッチ」を付けておく。そのスイッチを特定のユーザグループにOnにすると、その機能がユーザから見えるようになる。Offにするとその機能はユーザから見えなくなる。
こういった機能をつかって、αテスト、βテストを実施して絶対にリリース可能な状態にもっていってから、リリース日を告知するのが安全だろう。
これは、私のアイデアでしかないので、「無理」であることをまず受け入れて思考すると、もっといろんなアイデアがわいてくるかもしれない。
「現状」に流されず「無理」を認めることから始める
私は次のようなアイデアをシェアしてきた。しかし、これらの考えは実のところ結構昔から判明していることなのだ。
- 納期の見積もりは星占いレベルの確度
- 納期・コスト・品質・スコープのトレードオフは物理的な制約
- その納期は本当に重要かを考える
- 無理なものは無理として扱う
- 納期を設定したい場合は絶対に守れる状態にしておこう
これらの考えも、現在の日本の商習慣や、慣習から考えて「無理」と考えるのは簡単だろう。しかし、皆さんは、その「無理」を永遠に受け入れたいだろうか？私は少なくともまっぴらごめんだ。無理なものは無理だから。しかし、無理を受け入れてから工夫をすれば、もっと我々がもっとビジネスバリューを高めながら楽しくソフトウェア開発することが可能になると思う。少なくともあなたのチーム内だけでもこのような思考で動いたり、上の人にアピールしていくことができると思う。これを組織で取り組むともっとバリューが高いだろう。実際にユーザ企業自ら「請負」ではなく「準委任」に契約を変更して、「無理」から脱出した超大手企業も存在する。ソニックガーデンさんのように、「納期」自体を削除したケースもある。
だから、自分ができることからまず一歩、一歩、私はアイデアをシェアするところから始めてみました。日本のソフトウェア開発が、US並みのスピードで進捗しますように。
追記 (7/7)
このブログをポストしたら私の友人の、Kiro Harada さんとRyuzee さんが、タイムリーにこのトピックに関する記事を書いたというお話を知りました。私の尊敬する両名が書いた記事なので私も読んでみようと思います。是非皆様もどうぞ！より詳しい話が読めると思います。
そして、Kiro Haradaさんからこの写真を貼りたい、貼りたい、、、とおっしゃっていたので、ご希望通りにしておきましたw
ちなみに日本語訳は「彼らに見積もりを頼んだら、それを納期にしてしまえ！」ですw
マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」
最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか？ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。
海外企業のリーダーシップスタイルの変化
ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。
この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。
マイクロソフトに入社して感じた事
私はアジャイル/DevOpsのコーチをしていたので、サーバントリーダーシップに関してはおなじみの概念だったのだが、マイクロソフトに入って気づいたことがある。マイクロソフトはソフトウェアのチームだけではなく、会社全体が「サーバントリーダーシップ」スタイルだ。ビジョンや、戦略、KPIは明確だが、誰も指示をすることは無い。現場のメンバーが日本企業とくらべると、かなりの権限を与えられて、どう実行するかを考えている。これはインターナショナルチーム、日本チームどちらもそうだ。
日本はマネジメントの世界でも遅れている
私もマイクロソフトのことしか知らないので、詳細は分からないが、他の外資系に努めている友人に聞いても、こういうスタイルという事らしい。「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているようだ。個人的意見だが、日本もそろそろサーバントリーダーシップ型に移行してもよい気がしている。ロッシェル・カップさんの下記の本は非常に興味深いのだが、そこでも、日本のマネジメント技術が低いこと、マイクロマネジメントが横行していること、権限付与のレベルが低いことが指摘されている。
また、書籍で、「社員」と「ステークホルダ」という表が乗っていて、とても興味深い。コマンドアンドコントロールは、メンバを「社員」として扱い、サーバントリーダーシップのチームメンバは、「ステークホルダ」として扱われる。
自己組織チーム / フィーチャーチーム
スクラムやDevOps の世界では、チームに強い権限を与えて、ソフトウェアに関する決定は、そのチームが行う。「コマンドアンドコントロール」スタイルだと、上司の承認とか説得とかあったかもしれないが、チームを「信頼」して「任せる」スタイルになっている。このようなスタイルのメリットとしては次のような要素がある
- 生産性が高い
- チームのエンゲージメントが高い
- よりよいソリューションが選択されやすい
生産性の高さ
最初の生産性が高いということは、「コマンドアンドコントロール」時代だと、リーダーの承認や、説得、日本だと合議・根回しもあるかもしれないが、とかく何かを決定するのに時間がかかる。これは、現在のソフトウェアのデリバリのスピードを考えると致命的だ。 だから、チームを信頼して、チームでビジネスの仮説や、仕様、そして、そのアーキテクチャ、使用する技術を決定していく。タスクの割り振りもチームが自らやっていく。基本的にチームメンバーがやりたい仕事を「自分がやるよ」と選択していく。
エンゲージメントの高さ
インターナショナルチームの基本は、メンバーが「楽しんでいる」か？はすごく重要視されているので、メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。だから「やらされる」仕事より圧倒的に「楽しい」し、「自分がやっている感」がある。正直な話やらされている仕事なんて何にも面白くない。
だから、こういった「自己組織チーム」は、エンゲージメントが高い傾向にある。ロッシェルカップさんの先の書籍を読んでもやはり、日本のマネジメントはまだコマンドコントロールが主体だが、海外だと、サーバントリーダーシップ型になっていて、そういう点もチームメンバのエンゲージメント（満足度）に大きく影響していると思われる。単純な話、自分が面白いと思うことのほうが生産性は何倍も高くなるだろう。
良質なソリューション
最後に、よりよいソリューションが選択されやすい点だが、これは単純で、現在の技術は日進月歩で、それを一番把握しているのは、そのツールや言語で毎日コーディングをしたり運用しているメンバである。つまりチームメンバが一番知っている。何年も前にプログラマを引退した人では鼻が利かない。だから、現場で様々の選択をしてもらうのが一番質がいいことになる。稀にリーダーが一人で判断したほうがいいと感じることもあるかもしれないが、それだと、チームが指示待ちになって、何も考えなくなってしまう。いつまでたってもリーダーの指示が必要だ。
ただし、リーダーでも、例外的に技術に対して超人的に鼻が利く人もいる。グルーブノーツの最首さんはその例だ。しかし、彼も社長をやっているが、自分で様々な技術をハックしたうえで、チームに技術を推薦している。それも特に押し付けではない。
エンゲージメントの重要性
日本では、我慢が大人、西洋では、自分で自分の考えで人生に責任を持つのが大人であり、雇用制度も異なっている。日本に閉じている場合は、ロッシェルさんの本でも示されているが、日本のエンゲージメントの低さはそんなにダメージがないと考えるかもしれない。
しかし、海外に進出したときはどうだろう？近年海外にオフショアしている企業も多いが、現地のエンジニアは、日本ほどエンゲージメントが低くない環境にいるので、自分が面白くないと、当然他のもっと楽しい企業に流れてしまうだろう。プログラマの生産性は10 - 25倍の差があるといわれている。「低いスキルの人」に全体を合わせる時代は終わって、より全体の生産性を高めていく、そのためにも、メンバーがエンジョイできる環境を作り出すということが重要になってくる。実際私も上司からは指示は一切なく「エンジョイしてるか？」ということは頻繁にきかれる。人をコントロールしようとする時代は終わったのだと思う。
simplearchitect.hatenablog.com
おかげで私は自分の考えで、自分で判断して仕事ができている。とても楽しい。はっきり言ってDream Jobだ。
Damienとのレビューでの出来事
先日年次レビューがあって、小さなことかもしれないけど、自分的には感動的な体験をした。Damienは、日本での私の成果をとても喜んでくれいる様だった。彼がとてもほめてくれるので、私は彼に「私の力じゃないよ。Damienが凄く助けてくれたからだよ。」という話をしたらDamienはこう言った
誰が、Hackathonをやったんだ？de:codeで他のイベントで凄いインパクトを出したのは？みんな君がやったことじゃないか。僕じゃない
私はADHDで普通の人が出来ることができない。だから、Damienは凄く私のカバーをしてくれているのを知っている。そんなことを一言も言わす、「みんな君がやったことだ」と彼は言い切った。当時Skypeミーティングだったが、不覚にもいろんなことを思い出して泣いてしまった。彼は初対面の私を信じて一切を任せてくれた。過去も素晴らしい人に囲まれていたがこれほどのことは初めてだ。あれはダメ、これはダメと子ども扱いされる職場と比べると凄い差じゃないだろうか。
こんな気持ちになれる会社と「言われたことをただ単にやればいい」という会社では、採用できるメンバーに大きく差が出てくるのは当然ではないだろうか？今は国内だけだから、成り立つかもしれないが、こういった事情に気づいた人が、どんどん海外の「楽しい」職場環境を求めて日本を去る人が増えてくるのではないだろうか？
ソフトウェアチームレベルに留まるスクラム
先日英語の記事だが、「スクラムがアジアでは機能しない」というポストを見かけて大変興味深く読んだ。私が特に印象に残ったパートは、「欧米では、組織にスクラムを導入しているが、アジアでは、ソフトウェアチームでの導入に留まっている」という箇所だ。 これは、一見「スクラムの原理主義」みたいに聞こえるが、そうではない気がしてきた。私も昔は、スクラムを会社全体に入れるという話を聞いたときは、「スクラムは、ソフトウェアの方法なのだから、何にでも適用するのは違う」と思っていた。今はもしかすると、そういうニュアンスではないのではないかと思い始めた。
組織でスクラムをしていない意味
「自己組織チーム」を作るためには、ソフトウェアチームだけを変えても機能しないことに気づく。例えば、折角チームが自己組織チームであっても、その上のマネジメントが「コマンドアンドコントロール型」の管理を続けていれば、そのチームを「コマンドアンドコントロール」しようとしてしまうだろう。上位マネジメントはそうでもなくても、中間のマネジメントの方が、コマンドアンドコントロールしてしまうかもしれない。人事制度も、「自己組織チーム」で仕事をすること前提のものに変えていかないと、不公平感が出てしまうかもしれない。
また、アジャイル以降のパラダイムでは、「計画」や「納期」に関する考え方も大きく異なる。この辺りは次回のポストで解説したい。
つまり、「自己組織チーム」は単にソフトウェアチームをそのような形態にしたらいいだけではなくて、効果を出すためには、その周囲も変えていかないといけない。これが、「ソフトウェアだけにスクラムの導入がとどまっている」ということの意味だろう。
日本で自己組織チームを実践する方法
では、日本で自己組織チームを導入し、実践していくにはどういうTipsがあるだろうか？私の個人的な経験に基づく意見だが、記述しておきたい。
トップ層
まず、日本の場合は、上下関係があるので、出来るだけ上の方のOKを取り付けるのが良い。そして、アジャイル / DevOps などを推進するコミットを得て、それをしっかり資料化するのをお勧めする。どういった理由で、それを導入するのか、何を目指しているのか？また、定期的にステータスを報告することを約束しておくとより安心していただけるだろう。他には、可能であれば、バリューストリームマッピングなどの手法を使うと、例えばリードタイムの短縮など目に見える効果を提示することも可能だ。
ミドル層
サーバントリーダーシップ型への転換で一番抵抗が激しいのがこの層だ。しかし、それにはれっきとした理由がある。トップ層は、自分のKPI的には新技術を導入するとか、様々な変革をするミッションがあるのでサポーティブになりやすい。しかし現場のマネジメントからすると、プロジェクトやサービスごとに数字を持っているので、当然自分の慣れていない方法で新しいことを始めるのは相当勇気がいるはずだ。だから、トップ層でも書いたが「トップ層」が明確に「自己組織チーム」で「サーバントリーダーシップ型を推進する」とコミットしていたら、ミドル層も、そちらに進みやすい。
また、ミドル層の方が反対する理由は、大抵は「石頭」とかではなく「不安」があるからだ。そらそうだろう。今まで慣れ親しんだ方法じゃない方法で、リーダーシップを発揮しなければならない。だから、「それはアジャイルだから」とか「それはスクラムで決まっているから」とかではなく、彼らの不安に耳を傾けて、それに答えていく必要がある。そして、しっかりとトレーニングをすると、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。そうやって、いったんサーバントリーダー型になると、細かいことを計画・管理しなくてよくなるので、ビジョンや戦略や改善などより本質的な部分に注力することができるようになる。
できれば、KPIもサーバントリーダーや、自己組織チーム前提にするのが望ましい。
また、進捗報告など、アジャイルやDevOpsサービスではどうすればいいかを具体的にお話ししておくと、安心してもらえやすい。大体私がやりがちなパターンは、「スピードチャート、開発進捗サマリ、課題」程度の報告にとどめている。しかし、それらがあれば、終了の見込み、全体像、課題がわかるので、シンプルながら十分だ。下記の資料のP42, P43あたりのイメージだ。
チーム
最後にチームだが、「自己組織チーム」になっても、大抵の場合は、今まで「指示」を受けて動いていた人が多いので、自ら考えて、行動する習慣を持った人が少ないことが多い。だから、最初は自己組織チームになっても、みんな「どうしたらいいんだろう」という雰囲気になることが多い。そういう場合は、誰かが「ファシリテーター」役になって、行動を促進する質問をするといい。最初は「どう考えたらいいかわからない」と言わることもある。彼らに「アドバイス」をするのはよいがそれはあくまで「彼らが求めたとき」にする。 その前に「質問しやすくする空気」を作っておくのは効果的だ。私はよく「Ask For Help」の話をする。次のブログ参照してほしい。すると、メンバーが「あ！気軽に質問していいんだ！」と思えるようになってくるので、どんどん質問がやってくるようになる。
simplearchitect.hatenablog.com
指示待ち系の人も多いが、そのような場合も「じゃあ、○○さん、どのタスクやっときます？」とか、こちらが指示するのではなく、あくまで彼らを「促進」するようにだけする。決定はあくまで本人だ。アーキテクチャの議論をしていても、年上の人に遠慮して、本当に思っていることを言えなさそうにしている人がいることを発見するかもしれない。そしたら例えば「○○さん、このアーキテクチャの議論で、気になっていることはありますか？もし、ほんの小さなことでも結構なのですが、ちょっとでも気になっていることがあったら共有してくれませんか？」ぐらいのニュアンスで「促進」すると、少しづつ話をしてくれるようになったりする。
また、本当は「自己組織チーム」で自分たちに決定権限があるのに、「会社のルールで決まっているから無理」と自主規制してしまうケースもある。その場合は、上の人を連れてきて、その人から、「変えちゃっていいよ！」ということを言ってもらうようにする。そうすれば、徐々に「あ、会社のルールも変えようと思ったら変えられるんだ、自分で考えて自分で仕事をやったらいいんだ」ということに全員が徐々に気づいてくる。これにはプロセスは変えていいんだと気づくことができる副作用のあるバリューストリームマッピングのセッションも有効だ。
こんなことをしていくと、明日からスグという感じではないが、１週間もたつと「自己組織チーム」にチーム自体が慣れてくる。
他にも、自己組織チームのはずなのに、何となく上下関係を感じる場合がある。そうすると、チーム内部で指示待ちが発生してしまうことがある。ポイントは、チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」としてふるまうことだ。最初の「社員 vs ステークホルダ」を思い出そう。 もちろんスキル差があるのは事実だが、聞いてはいけないということではない。「指示」をうけるのではなく「主体的に聞く」ことが必要なのだ。そして、目上の人も「教えたくなるのを我慢」することだ。「考える」のはそれぞれの仕事で、「考えてあげる」のは相手を子供としてみなしていることになる。新人であっても「（西洋の）大人」として扱おう。
チームにパワーを持たせる価値
海外の同僚の活動を見ていると気づくことに、日本以外の国は「開発者」「運用者」つまり現場の人が技術や方法論選定のパワーを持っている。日本は「マネージャ」が決めるので、「開発者」「運用者」の決定権がない。しかし、新技術導入のペースを勧めるために必要なのは、そこに対して鼻の利かない人の承認ではなく、彼らを「信頼」して「任す」ことによって「現場」がパワーをもって、チームが自ら考え意思決定していく組織にある。 チームが自ら判断していけば、新しい技術の導入も、新しいチャレンジも活発化されてくる。
「自分で指示するほうがチームメンバーを考えるとよいと思う」とか「チームメンバーは指示待ちだから厳しいと思う」とか「自分勝手な行動をチームが取り始めたらどうするのだ」という意見もあると思う。
それでも私は「自己組織チーム」をお勧めしたい。１人が、他人に対してすべての要素で優れているということはほぼ無いだろう。だから、みんなのCPUを結集して問題解決に当たるほうが効果が出やすい。
「指示待ち」ということに関してはその通りの場合もあるかもしれないが、「人間は成長する」ため、「できない人を何とか管理」という方向性ではなく、「できる人」にする方向性のほうが、人による生産性の違いが10-25倍と言われるソフトウェア開発の場合は、効率的な気がする。「できない人」に焦点を合わせるといつまでたっても生産性は上がらない。
最後に何より、チームメンバーが「仕事を楽しめる」ことだ。これが最も自分的に大きい。私だったら指示されて仕事するなんて面白くもなんともないのでまっぴらごめんだ。自分の意志で自分で選択した仕事をプロフェッショナルにこなしていきたい。あくまで個人的な意見ではあるのだが、私はそう考えている。
日本に合わせるのではなくルールを変える
こういった「サーバントリーダーシップ」の考え方なども、現在の日本の組織や、ルールになじまないように感じる。ここで「できない」というのは簡単だが、そうやっている間に、海外とどんどん差をあけられていくのも確かだ。しかし、会社のルールなんて所詮どっかのおっさんが過去に決めたものだ。過去にはそのルールは有効だったが、現時点でそのルールが有効かは分からない。ルールは目的があったはずで、それに人間が縛られるのはナンセンスだ。東洋の端っこの小さな「日本のやりかた」にこだわるよりも、私は自分がより良い仕事をして楽に成果を出せるようにしたい。世界の基準でよい仕事ができるようになって、もっと世界に貢献したいなと思う。
次回は、自己組織チームに関係する、計画や、納期の考えの違いに関して整理しておきたい。
日本をクビになる日
今回のブログは沢山の人に読んでもらいたい内容ではなく、単純に自分が考えたことの整理です。
私が初めて、オブジェクト指向やアジャイルを取り組み始めたのは2001年頃でした。なぜそのようなことを始めたか？というと、当時のシステムは自分から見ると「かろうじて動いている」という感じで、「しっかりと作られている」というイメージがありませんでした。徹夜で何とかふらふらになりながら納品したものが高品質なはずがありません。だから、自分なりにいろいろ「よいシステム開発の仕方」について学び始めました。
「現場」と正反対の開発方法論
すると様々な気づきがありました。まず「オブジェクト指向」の分析・設計・それに使われるプロセスを学んでみると、当時の開発で行われている考え方やスタイルとまったくと言って異なっていました。「どうして会社でやっている開発と、ソフトウェアエンジニアリングで説明されているスタイルがこんなに違うんだろう？」まだそれは、あくまで疑問のレベルでした。
ところが、平鍋さんのWebページで紹介されていた「eXtreme Programming」と出会って、人生が変わる程の衝撃を受けました。
今までの開発手法と、時には正反対のことを言っているが、自分の感覚的に凄く「正しい」気がする」これなら、私でもお客様に本当にいいソフトウェアを届けられるんじゃないか？
そういう思いがあり夢中になり、コミュニティ、社内外への啓もう、事例づくりにいそしみました。私としては絶対にこれは重要になるからうちの会社でもやるべき、いやうちの会社だけではなく業界でやるべき。もし、万が一、仮にそれが正しかったとしても、それは人への押し付けでしかありません。
龍野さんの一言
そんな当時の私に対して、人は「やったらいいんじゃない」、とか、「あれは宗教だ」とか様々な反応でした。私が今も尊敬する龍野さんという方がいて、その人が私に言ってくれたことが私のスタイルを永遠に変えました。
なあ牛尾よ、お前がやっていることは押し売りやぞ。北風と太陽やないけど、みんながやりたくなるようにせなあかんのちゃうか？
当時の私にとって、その言葉はとても響きました。龍野さんは誰からも尊敬されるような方ですが、決して偉ぶっているわけでもなく、仕事もものすごくできましたがお客様からも、社員のメンバーからも上下隔てなく尊敬される人格者です。 私の行動も多くの人にはスルーされるなかで、龍野さんは相当にサポーティブに助けてくれていました。そんな方の一言だから響いたのかもしれません。
その後私はスタイルを変えて、自分のモットーが「相手を理解する」になりました。お客様に対峙するときでも、何かを説明するときでも、常に自分ではなく、相手がどう思っているか、どう感じているかを常に観察、考えて、試行錯誤して、自分ではなく、その人にとっての価値を出せるようにするというスタイルです。この言葉の価値は今も変わりありません。
そのお陰で私は、コンサルや、新しい技術導入や、教育が大変得意になることができました。独立もしましたし、教育やコンサルをやるときはいつも高い顧客満足度を得ることができるようになりました。
更に、アジャイルのマインドセット、コンサルティングや、セラピーなどの理論や技術を学んでいく中で、どの分野であっても「人は変えることはできない」という原則を見ることができました。仕事においてだけなのですが、「人とうまくやる」ということにおいてはこの頃が人生のピークだったのかもしれません。内向的な性格ですので「無理」と思っていた結婚もすることもできました。
自分のために生きること
しかし、その後、いろいろなことが崩壊していきます。仕事上でストレスを感じることも多くなり、私の責任なのですが、妻は私の元を去りました。仕事でも、自分が相当役立ってると思えるときもあれば、ちょっとだけしか役にやっていないと思うこともありました。当時コンサル料金をたくさん頂いていたのもあり、バリューが出ないと、相当申し訳ない気分でした。何よりも自分がイヤでした。
セラピーを本当のセラピストから実地を通じて学ぶことで自分的に頂点を極めた「人のことを理解する」という能力ですが、このころの私は「人のために生きている」ということに気づいていませんでした。ただ、お客様には最高に気に入られるのですが「自分が無い」気はしていました。
私の友人の細川さんは、当時の私を振り返って「あの当時のうっしーは面白くなかったよ」って言ってくれました。人にとって心地よいことはできるし、日本社会ではうまくいくのですが、私が本当に幸せだったは相当謎ですし、様々なことを我慢していました。さらに、お客様にとって、私はプロとして「本物」を迷うことなく届けられたのか？というと疑問が残ります。
その後、先のポストでもお話しした通り「幸せシフト」を行い、「人のためではなく、自分の幸せのために、自分で人生の選択を行う生き方」にスタイルチェンジし始めました。
simplearchitect.hatenablog.com
コーチが一人前になる条件
「自分の幸せのため」に行動するようになると、私の「自分は何か一つでもいいから、プロフェッショナルと呼べるレベルの物事を達成したい」という欲がでてきました。お客様に対しても、耳障りの良くないことも言うようになってきました。コンサルタントが役に立つ大きな理由は彼らが優秀だからとかでは決してなくて、「第三者」の視点を持てることです。だから、耳障りのよくないことも正確にフィードバックする必要があります。これはとても勇気のいることで、自分がクビになるかもしれません。
ある時、一緒に働いているお客様のチームに対して、お偉いさんがたくさん並んでいるシーンで、ネガティブなフィードバックをしないといけない場面がありました。正直非常にストレスで、人に嫌われることは確実で心も痛みましたが、勇気をもって、少なくとも自分的には正確なフィードバックを実施しました。今はすぐにわかってもらえないと思うけど、そのチームに必要だと思ったからです。
その後そのチームにはあまりかかわれなくなりました。当然だと思います。スクラムコーチの世界では「クビになったら一人前」という言葉があります。チームに耳障りのいいことだけしている人は半人前。 私はその会社さんではその後もほかのチームのご支援をしていましたので、まだ私は半人前と言えます。
第三の方法
そんな過程を経ている中でマイクロソフトのインターナショナルチームに参加して、世界と日本の圧倒的な差、そして、１５年経過しても進歩が少ない現状を目の当たりにして、今までの「ソフトランディング」な方法でよいのだろうか？という疑問がでてきました。そんな中インターナショナルチームのメンバーから刺激を受け、学んだことで、日本と、西洋のマインドセットの違いに到達しました。 しかし、マインドセット、つまり、人の考え方を私が変えようというのはおこがましいことです。しかし、このままでは、、、というジレンマがあります。どうしたものか、、、そこで考えた作戦が次の仮説です。
人には何も押し付けないけど、自分の思った事は発言する。そして、自分が自ら自分がいいと思う行動することで、それを気に入ってくれる人を増やすようにしてみる。
世界を変えたかったらやることは一つで、自分が変わることしかありません。人は変えることはできませんが、私が、西洋のマインドセットのうち見習ったほうが良いと考えたことを自分で常に実践することで、もしかすると人が「あの人楽しそうだな！とか、あの人生産性高いな！」とか感じてくれるかもしれません。また、「本当はそう思っていても言えない」と思っている人がいたとして、私が常に思っていることを躊躇なく発言していると、「ああ、言ってもいいんだ！」と思う人が増えて、自由でフラットなコミュニケーションができるようになるかもしれません。
これは万人に受け入れられる考えでもないですし、仮説でうまくいくかも全然わかりませんが、自分が思った事を誰に対しても発言するが、他人にはそれを求めない。「人から学ぶ」「人を理解する」ことは続けるが、「自分はこう思う」というのは明確に発言する。ということを実験してみたいと思います。
日本をクビになる日
よくよく考えると、今も尊敬する龍野さんも、人の気持ちを理解できるだけではなく、主任の当時、事業部長を説教したといっていました。私が多大な影響を受けている倉貫さんも、自分の思うことは誰の前でも明確に発言しています。私は正直気が弱いので、内心は勇気を出していますが、今後もこのアプローチをまず一定期間実施して仮説検証をしてみようと思っています。
私は常に何か一つでもできる人になりたいと思っています。今はどれも中途半端です。でも、いつかこれを続けていたら、日本を「クビ」になる日が来るかもしれません。先日の投稿を読んで「震えた」と言ってくれた人がいました。あの投稿がほんの少しでもいい影響があったて、喜んでくれた人がいるなら、本当に怖かったけどやってよかったなと思います。
そして、「日本」をクビになる日がやってきたら、もしかしたらそのときこそ、私がやっと一人前になれるときなのかもしれません。
龍野さんや、倉貫さんのレベルにはまだまだほど遠いですが、自分のために、楽しんでぼちぼちやっていきます。
自分で人生を決めるマインドセットが、生産性と、仕事の楽しさをもたらす
今回は、前回のブログの内容をより考えてみたいと思う。
「自分で人生を決める」人は、他人に対して「すべき」がない
前回のブログの主張は、「自分で人生を決めない」マインドセットが、新しい考えや技術導入を遅らせるというアイデアだった。今回はさらに、「自分で人生を決める」マインドセットをもっていると、どういう効果があるのかを考えてみたい。
simplearchitect.hatenablog.com
「自分で人生を決める」というマインドセットを持っていると、「自分のことは自分で決める」という考えになる。心理学で鏡の法則というのがある。自分に適用している考えを他人にも適用するという法則だ。「自分のことは自分で決める」人は、「他人のことは他人が決める」という考え方になる。新しいアイデアや技術の導入スピードにはこれがとても効いている気がする。 逆に自分の人生が自分でコントロールできないと思っている人は、他人も他人がコントロールできないと考える。つまり、自分だけではなく、他人も他の何かに従うべきと考えるようになる。
インターナショナルチームで働いる時に感じることの一つは、人に「こうすべき」と言われることが全くないことだ。
もうすぐ期限の経費精算とか、必ずやることになっているものでもそうだ。例えばビジネスレポートの期限が迫っていて、私が忘れてた時ですら、「期限だから、入力してくれないだろうか？」ぐらいの口調で上司がリマインドしてくれる。 それぐらい、ほかに人にどうしろ、こうしろと言われることは本当にないのだ。もし、そうしなかったら、自分の評価が下がるだけだ。やるか、やらないかは私次第。人に「やらされる」ではないのだ。大人だから自分で決めて、判断しようという考えだ。
「本当に思った事」を言うエネルギー量の違い
今回ブログを書いて気づいたことだが、何か「意見を言う」ことの負荷が、インターナショナル環境と、日本では全然違うことに気が付いた。インターナショナル環境だと、「自分の人生に責任を持つ」マインドセットだから、私が同じような意見を書いたところで、たとえ多くの人と考えが違っていても、「あー、君はそう考えるのね」というノリだし、そうでない考えの人は自分でブログを書いて、「私はこう考える」ポストをする。 もちろん、そのアイデアに対してさらに自分がブログを書くか否かは私次第ということになるので、書いてもいいし、書かなくてもいい。だから相当気軽にアイデアをシェアできる。
ところが、日本で同じことをやると、そうもいかないようだ。今回のことでも、様々な方面から、「あなたはこうすべきだった」「フォローアップブログを書くべきだ」「きみのせいで、ほかの人が困る」「人の気持ちに気を配るべきだ」・・・。これは、人の考え方だし、文化に対して何かを言うつもりはない。ただし、メソッド屋として「新技術やアイデアの導入スピード」ということのみを考えると、これは相当問題だ。私の意見が正しいと私が思い込んでいるいう意味では取らないでほしいが、例えば、天動説が主流の頃に、自分はそう思うということで、地動説を唱えると、人は大きなショックを受けるかもしれない。天動説で商売をしている人は大きな打撃を受けて困るだろう。あなたの顧客には天動説の人もいるかもしれない。でも、それに遠慮をして、本当に自分が思う意見を言わないほうがいいだろうか？もちろん、あっているかどうかはわからないが、それを言えないとなると、相当いろんなものが歪んでしまう気がする。
日本では、そういったことに、いろいろ気を使って、何かをしなければならなくて、尚且つ、何かやった後も人々の要請があったり、「こうすべき」という意見があれば、それを実行しないといけないとすると、相当な負担だ。つまり、「めんどうくさい」のだ。
自分の意見をいうことに、ハラキリの覚悟は不用
だから、日本式でいくと、こういうセンシティブなブログは、書かないほうがめんどくさくなくていいし、多くの他の人と違う意見を書くときはハラキリレベルの相当な覚悟をもって言わないといけない。これは、相当なエネルギーロスじゃないだろうか？ だから、多くの人は本当は思っていることでも、「あとで面倒なことになるから、言わないでおこう」ということになるだろう。実際、今回私もブログを辞めようかとも思った。だってしんどいし、めんどくさいんだもん。
それよりも、単なる意見なのだから、「自分はこう思うよ」でよいと思う。気楽に言えたほうがよっぽどディスカッションみたいなものは気軽に、簡単にいかないだろうか？
そうでなければ、本当は心に思っていることが多いことでもみんな自粛して「言わないほうが得策」みたいな流れになってしまい、意見も「トレードオフがあるのでケースバイケース」みたいな聞き分けのいい話にしかならなくなる。
インターナショナルチームのディスカッションは楽
インターナショナルチームでディスカッションしていつも思うが、ディスカッションが本当に楽だ。自分が思っていることを単純に言えばいいだけだし、「気をつかう」なんてことは不用だ。純粋に思っていることを言うだけで、そこに、気をつかわなくていいし、「言ったからには・・・」といった変な責任が発生するわけでもない。 ダイバーシティが前提で、人がひとりひとりまったく違っていて当然という考え方だから、他の人の意見に対して「私はこう思う」というコメントはあるが、「お前は間違っている！こうすべき」みたいなことは無い。だから、ディスカッションも余計な要素がなくてとてもスムースに終了する。 もちろん「偉い人」なんて存在しないから、お伺いを立てたりすることも不用だ。
simplearchitect.hatenablog.com
Agile Rootsでの出来事
ここで、私も印象深かった、Agile Roots 2014での出来事をご紹介したい。Jeff Pattonという著名なアジャイルコーチが開催するワークショップに参加していた時の事。
そこにメアリー・ポペンディークという著名人が一緒にワークショップを受けていた。ジェフが、Scrumの世界で有名な「鶏と豚がレストランを開くたとえ話」を始めたときに、メアリーは立ち上がってシャウトした。メアリーはこのたとえ話が大嫌いなようだ。
ジェフ。君がこのたとえばなしをするなら、私はこの場を出ていく！
そういって、彼女は実際に会場を出て行った。ジェフは、何もなかったように講義を続けて、数十分後にメアリーは帰ってきて引き続き彼のワークショップに参加した。 ワークショップに参加したあと、メアリーはジェフに「君のワークショップとてもいいね！」と楽しく談笑し、褒めていた。
私はその姿を見て当時はすごくびっくりしたのだが、「意見の違い」なんてものはそんな程度のもので、そこに余計なものがいろいろはいるのがややこしいのだな。というのを学んだ。違う考えがある。時に腹も立つ。だからといって、ジェフに対してどうこうしろというのではなく、自分がしたいから自分が出ていく。それで終わり。何のわだかまりもない。
books.rakuten.co.jp books.rakuten.co.jp
他の例でも、海外のカンファレンスにいくと、参加者の人が、しょっちゅう席を立って退出する。日本だとよっぽど面白くないセッションでもない限りスピーカーに気を使って、立たないことが多い。しかし、向こうだと「自分がほかのを見たかったら」他のを見に行くし、スピーカーも、退出する人をみてショックだとかは特に思わない。自分次第。
「自分の人生を自分で決めない」マインドセットから生まれる、自分以外のものに対する「こうすべき」という考え方は、もちろん良し悪しだが、新技術の導入や、新しいアイデアの導入に関しては、相当なマイナスをもたらす。自分が何かしようと思った時に、いろんな角度から、「ああすべき」「君は間違ってる」「それは認められない」など凄い反発がやってくる。
「大人」という考え方の相違点
今回ある人がこんなコメントをくれて非常に興味深かったのでシェアしたい。彼は日本と、インターナショナルの混在環境で働いている。彼はこう言っていた。
西洋では「自分の人生や幸せを自分で責任を持ちコントロールする人」が大人という認識で、日本だと「我慢するのが大人」という文化のコンフリクトがあって困っている
なるほど！面白いと思った。私は生産性が良いし、自分が楽しいので前者を選択する。今は世界の文化を体感することのできる時代だし、自分がいいなと思うのを取りいれることができるので楽しい時代だ。 今回、２本のブログが読まれてたくさんの賛否両論があった。正直相当疲れてダメージも大きかった。そんなポストをしていたら、なんとロッシェルさんが私にコメントをくれた。
ブログを書くのは、ほかのクリエーティブな活動と同様です。In the moodだったら楽だが、そうじゃないと負担です。そのため、書きたいムードじゃない時に書かなくてもいい。そして書きたいムードになったら、書いてください。書くことによってハッピーになるのは第一です
自分は自分の人生をコントロールするマインドセットだと思っていたが、彼女のコメントは、凄く興味深いと思った。一番重要なのは本人が「ハッピー」かどうかという観点だ。ダメージを受けている時点で自分もまだまだ。私もそっちのマインドセットのほうが自分的に好きなので、更にそっちに慣れるように楽しんでみよう。でも一番は、それをして「自分がハッピー」と言えるかが重要なのだろう！
日本の新技術導入のめんどくささ
ふと、思い返したのだが、自分が、2001年にその後、アジャイルを初めて、エンプラな環境でも実施するために当時やったことを振り返るとこんな感じだった。
- 小さなアジャイル案件を作るために、自分で営業して、自分でコードを書いた
- アジャイルのコミュニティを社内でつくったり、社外のコミュニティの運営に参加した
- 内外でプレゼンテーションを実施して、仲間を集めた
- 大きな規模のアジャイル案件を実施するため、RFPの段階から参加して顧客にメリットを説明した
- その案件でアジャイルを実施するために、請負契約でアジャイルを実施する契約方法を考案して実施した
- その案件でアジャイルを実施するために、WF型の品質管理方式に対応するために、品質部門の人とディスカッションしてアジャイルでもまわるようにした
- アジャイルで必要な「テスト駆動開発」をするためには、OOPが必要だが、OOPができる人が当時少なかった。だから、OOPが誰でも理解できるようなメソッドを作った。
- 実際にアジャイルができる人をプロジェクトのメンバーに加えた。他のメンバーも教育した。
- 平鍋さんを呼んできてコーチをしてもらった。そのためにいろいろ説得した。
- アジャイルを実施すると、「要求」の部分がスムースにいかないことが多く、要求開発手法を学び実践した（当時プロダクトオーナという概念はまだなかった）
- いろいろなステークホルダ、上司、さらに上の上司と話を話をして、アジャイルプロジェクトがつぶされないように、交渉した
- お客様経由でマスコミに取り上げてもらって、より動きやすくした ：その後につづく、、、、
たかだか、新しいやり方を導入するだけでなんでこんなめんどくさいことをしないといけないのだろうか？私は新しくて効率のよさそうなやり方があるので、それを実施したかっただけだ。普段「やろうと思えばできるよ」と軽く言っているが、今と違って最初の頃にそれをやるときはこれぐらいめんどくさかった。 今回インターナショナルチームに参加して、他国の様子を観察していると衝撃だったのが、他国ではこんなめんどくさいことはいらないようすだ、「開発者」の人がやってみようと思ったら「やる」だけの話だ。
前にも書いたのだが、５００人ものハッカソンの開催が、１回の会議で決まっていく。日本だったらいろんな人の承認とか、合意とかを得ないと実施できない。こんな「めんどくさい」なら、日本では「無理」という気持ちはとてもよくわかる。だから、それをぶち壊したいのだ。
simplearchitect.hatenablog.com
素直に考えると、これだけめんどくさいと、「あー、もうめんどくさいから、海外いくわー」とか、「めんどくさいから自分で会社やるわー」とか「めんどくさいから、めんどくさくない文化をもったスタートアップに参加するわー」となるのも当然だろう。 そもそも、新しい技術や考え方の導入は、ずっと遅くなるのも当然だ。でも、新技術や、新しいモノの考え方の導入は、本来楽しくてエキサイティングなものだと思う。
「自分の人生に責任をもつ」マインドセットの楽さとチームの楽しさ
正直いって、私も昨年から始てインターナショナル環境で働き始めたので、その後初めて知ったことだが、インターナショナル環境で働くのは楽しいし、すごく生産的だ。自分の上司は、明確で無理のないKPI,ビジョンを示したら、あとは自分にフルに任せてもらえる。
simplearchitect.hatenablog.com
自分で考えて自分で実施する。チームメンバーや、ほかのステークホルダからも、「あなたはこうすべきだ」みたいなことは一切言われない。
ただ、自分がフィードバックしてほしい時に聞いたら喜んでアドバイスをくれる。みんなそれぞれが自分の仕事を楽しんでいる。「我慢」は一切だれもしていない。チームでやる必要がある仕事があって、誰も手を上げない場合は、「誰かこれにパッションある人を雇うか」となるか、普段自分がやりたいことをやっているので、「今回は俺やるわ」みたいな感じで、やらされるのではなく、自分が決めてそれを実行するので、何の不満もない。また、それを誰も選択しなくても、誰がわるいとかそんな話にはならない。
みんな主体的に自分の仕事を持っている。だから、誰も助けてくれなくても、それが普通だ。「助けるべき」みたいな変なプレッシャーは存在しない。忙しいときに、会議をスキップしても、メールをスルーしても、特になにも言われない。その人が仕事に対して責任をもっているので、誰かのせいではない。自分がKPIを達成できなければ、自分の給料が下がるか首になるだけだ。
だから、誰かが助けてくれたときは、とてもうれしい。
チームのために何かを作業したら、みんなからほめてもらえる。「ここがだめ、あそこがだめだ、さらにこうすべきだ」みたいなことにはまったくならない。ただ、正直なコメントは飛び交うけど、それをしたからといって、「誰かがきずつくからオブラートに包んで、、、」みたいなことはない。みんな「大人」とみなして行動する。意見が違っていたりしても誰も気にしないし、言ってはいけない意見とかも、仕事上は特にない。早く帰っても、いつ休暇をとってもだれも、それをさぼってるとかは思わない。むしろエンジョイしろよと言ってくれる。
プロフェッショナルさは重視される
そのわりにとても結果に関しては、プロフェッショナルだ。日本でのプロフェッショナルというのは、すごい厳しいイメージなのだが、インターナショナルチームだと、厳しさはみじんもない。「基準」に達している、否かは非常に明確だが、失敗しても、チャレンジには開いているので、何回でもチャレンジできる。 さらに、仕事も人生もエンジョイするものという考えだ。だから、各個人は楽しみながらスキルを常に磨いているので、アウトプットはみんなレベルが高いし、スキルアップを怠ってる人なんて人も見たことがない。
たぶんこれは「雇用制度」の違いも大きいと思う。こちらでは、簡単にクビにできるので、みんな「自分」が売れるようにしておく必要がある。会社も、働かない人は、残念ながら退職していただくことができる。一瞬これは厳しそうに見えるがKPIが達成不可能なものになっていないので、日本での「厳しさ」感はないし、裏を返せば、社員のほうも、嫌だったらいつでもやめてもっと楽しい会社に移ることができる。だから、今のところより条件が良いところがあったら、あっさりそっちに乗り換える。そんなことをしても、誰も「裏切りだ」とかは言わない。だって、本人のチョイスだからだ。
simplearchitect.hatenablog.com
海外の労働環境の楽しさが伝わりつつある
今まで私はインターナショナルチームで体験したような環境が存在すると思っていなかった。でも、海外に出たらそれが存在した。自分がハッピーで仲間もハッピーでイキイキ仕事ができてめんどくささがないので、生産性も高く、みんな一年ごとにさらに向上しあえている。マイクロソフトだからと片づけるのは簡単だけど、海外で働いて、日本に帰ってきた人で「日本に帰ったらいろいろめんどくさい、また戻りたい」と言っている話を少なくとも私はよく聞いている。たぶん同じような感じなのだろう。
前回のポストをした後に、こういうコメントをくれた人がいた。彼はUSに住んで働いている。
牛尾さんの新しい記事、自分には全面的に理解できるんだけど、他の人はどうかな？わかると日本にいられなくなる可能性大だけど https://t.co/TLTQhPCCVt
— 帝国兵 (@superriver) 2016年6月23日
彼のコメントは、今ならどういう意味かわかるのではないだろうか？
この事実は一瞬ネガティブな情報に思える。しかし、もしあなたの会社が、海外のようなハッピーな職場にすることが出来たらものすごい行列のできるようなお店になれる可能性があるのではないだろうか？カルチャーに取り組むところはそんな多くないから差別化の大チャンスだ！
日本で「自分で人生を決める」マインドセットのチームを作るには？
これは私も試行錯誤の最中だ。しかし、確実に作れるとは思っている。ポイントは「チーム全体のカルチャーのチェンジ」だと思う。例えば、チーム１０名のうち、１名だけ、「自分で人生を決める」マインドセットの人がいたとする。その人が海外で過ごしていたのと同じノリで仕事をすると、針の筵のような感じになるだろう。
一方、海外のチームに参加した日本人で、このような、「快適さ」に気づく人は多いと思う。こっちのほうが楽しくて、待遇もよくて、スキルアップできて、チームに喜んでもらえるし、自分の思うようにできる。最初は、自分が持っていた「自分で人生を決めない」マインドセットで、戸惑うことがあるが、２か月もすればなれてくる。そうなったら、日本での勤務を思い出すと本当にバカバカしく思えてくる。
だから、そういう人は私も含めて将来海外でまた働きたいと思っている人も多いと思う。
つまり、そういう環境にいたら、日本人でもすぐ慣れてしまうわけだ。ということは、こういうマインドセットをチームのカルチャーにして、チームのみんながそれになじんでくると、新しく来た人もそのカルチャーにすぐ慣れてくるということが可能な気がする。 Pivotal Labs はサービスとして、Extreme Programmingというアジャイルの手法を顧客に伝えるときに、顧客をPivotalにしばらく呼んで、一緒に開発をして、その開発習慣を伝授するサービスをやっている。非常に本質的だ。
つまり、それと同じことを、自分のチーム、もしくは会社でやればいいのではと思う。もちろんまだ私もこれに関しては事例はないがご希望の会社さんがいたら一緒に実施してみようと思う。
そうできたら、日本でも、「USと同じスピードで技術導入できるチーム」が増えてくるのではないだろうか？
simplearchitect.hatenablog.com
外から見てるだけなのでわからないですが、きっと、ソラコムさんとか、ソニックガーデンさんとかはこんなマインドセットな気がします。日本でもきっとできると思います！
www.slideshare.net
統計からみた従業員エンゲージメントの低さ
私もロッシェルさんの著書で初めて知ったのだが、従業員エンゲージメントという指標がある。従業員満足度のことだ。この満足度の調査があるのだが、私は世界平均と、日本の従業員エンゲージメントの比較を見てびっくりした。
なんと、世界平均だと、「満足」が圧倒的に突出しているのに、日本では、「非常に低い」というのが圧倒している。そして、５年連続で、日本は最下位らしいのだ。そらそうだよな。。。これはやはり雇用形態が大きく影響しているものと思われる。 そして、海外経験者中心に、この実態に気づいている人が少しづつ増えている気がする。そうした人は当然日本の企業で働くのが嫌になって海外に行ってしまうだろう。自分ができることからこの状況にアタックしていきたいと思っている。
「マインドセット」を変えて、世界に勝てるチームを作ろう！
日本人は、海外の人から見るといろいろいいところがある。磨き上げる能力、イノベーティブでユニークな発想、勤勉さなど、これぐらい世界と違うということは相当な競争力なのだ。そのユニークさが生産性のあだとなるなら、あだとなる部分だけ、「マインドセット」としてインストールして、課題を克服してしまえば、日本からもっと世界を「凄い！」と言わしめることができるのではないだろうか？
そのためには、ソフトウェアの先進国に学んで、その課題を解決していくしかない。私の考えはもちろん私の単なるアイデアで、うまくいくかもわからない。しかし、私的には、他人は変えられないので、想定する「マインドセット」を変えて仕組みをつくる。つまり、「大人とはどういう人か？」の基準をそちらにして仕事の仕組みを変える。楽しくなるし、チームでやれば仕事もめんどくさいことがなくなるし、いろいろ気づかいをすることなく、本当のことが言いあえるし、「我慢」もしなくてもいいし、チームで称えあってハイレベルの仕事ができるチームが出来るかもしれない。そんなチームが作れたらすごくうれしくないかなって思っています。
ダメだったらだって？私も海外で職をさがすだけですね！
だって、自分は自分らしくあり、楽しく仕事をしつつ、正直で、プロフェッショナルでありたいですから！
次回は自己組織化チームのことを掘り下げてお話ししていきたいと思います。
「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない
先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので
申し訳ないが、今後も読まないだろう。自分の人生は自分で決めるのだから。
simplearchitect.hatenablog.com
実は、この炎上の過程でいろんな仮説を考えることができた。なぜ、日本のソフトウェア産業は、海外に大きく後れを取ってしまっているのか？どうすれば、進化する手助けができるのだろうか？
自分の現在の仮説はマインドセット、つまり「考え方」が根本的な原因ではないか？という気がしてきた。
私が最近研究しているのは、 DevOps や Agile といった新しい考え方が日本になじまないのはそれらの考え方が、USやグローバルスタンダードの考えの上に成り立っているからという仮説だ。だから 日本文化にそのままインストールしようとするとなじまないということになる。
そういった「西洋文化の考え」を必要な部分だけインストールすれば、もしかすると、DevOps やAgileなどがもっと効率よくインストールできるのでは？という仮説だ。
simplearchitect.hatenablog.com
実際にいくつかのプロジェクトで試行しているが、今のところ上手くいっている。私もそのアクティビティの中では気づいていなかったのだが、最も根本的に変えたほうがよさそうなマインドセットを今回発見できた。
海外のメンバーと働いていて、根本的に大きく異なる点は彼らは「自分の人生や幸せに責任を持っていて、自分でコントロールしている」ところだ。それをベースとして、人を「大人として扱う」ということがある。
ここは非常に大きな相違で、このマインドセットが大幅に日本の進化を妨げているのでは？という仮説に至った。
新しい考え方や技術の導入で必ず言われること
今回の炎上もそうだが、新しい技術の導入でよく言われるのは例えば次のようなものだ
- 契約や商習慣の問題があり、導入できない
- 会社のルールで定められているので弊社では無理
- 要員のスキルレベルが対応できないからうちでは無理
- 日本の雇用に関する法律で決まっているから無理
- 経営層や上司がわかってくれないから無理
ほかにちらっとTwitterで見かけた意見これは私のブログに対してだが
- 不安を煽るのではなく、もうちょっと具体的にわかりやすくメリットデメリットを説明してほしかった...
などなど。これらの理由はすべて、これを言っていっている人以外に対して語っており、自分はどうだという話になっていないのだ。
本当にあなたがそれがやりたければ、自分でそれを変えたり、工夫したりしてやればいいのだ。それを、やりたくなければやらなければいいのだ。これらの考え方は、自分以外のものに、自分の人生をコントロールされているという考え方なのだ。 なぜ、それを「他の人」に求めるのだろう？ 自分が、「具体的にわかりやすくメリットを説明してほしかった」と思うのであれば、自分で調べて、具体的にわかりやすくメリットデメリットを説明するブログを書けばいいんじゃないだろうか？
海外の人の目から見た日本人の考え方の課題
日本とグローバルの文化を研究しているロッシェル・カップさんという方がいる。彼女は、日本でも長年働き、米国人で、シリコンバレーでもお仕事している。だから日本の文化、グローバルの文化を知り尽くしていて、日本企業に対して、グローバルマインドセットを教えたり、海外のみなさんに日本の企業と付き合う時の考え方を伝えたりしている。彼女は、日本語、英語の両方でたくさんの書籍を執筆されている。彼女の本を読むと衝撃的だった。日本人の私が読んでも日本語で書かれた彼女の本の分析は完璧で衝撃を受けた。その彼女の本の一つに次の本がある
この本では、彼女は、グローバルに働く人向けに、日本人のいいところ、直したほうがいいことを書いている。彼女は、グローバルで働く人向けにこの本を書いているが、グローバルで働くという観点じゃなくても、日本企業が生産性を上げるという面で考えても同じだ思う項目はとても多い。その課題について述べている一節をご紹介しよう。ほかのパートも面白いので是非手に取っていただきたい。
疑問をもっていてもお役所で決まったことなら黙ってしたがう、誰かに言われたからある行動をする、新聞でかいてあるから真実に決まっていると信じ込む発想、また海外で話題になったという理由だけで日本でも話題になる － 「お上と外圧に弱い日本」と「外国人に弱い日本人」と言われる側面にはこうした考え方が表れていないでしょうか？ ： 中略 社会的な慣習 ： 中略 公に決まったことならいやでも黙って従うしかないという発想・・・「中身より形が大切」というのも日本の社会を表すのによく使われる言い方ですが、形イコール規制（ルール）になってしまっている実例を見ましょう
ここで彼女はこんな例を紹介していました。
たとえば、私が初めて東京のスイミングプールに行った時にびっくりしたのは、強制的にさせられた「準備体操」でした。そして全然疲れていないのに１時間ごとに５分間か１０分間か休まなければならないということでした。また、スイミングキャップを着用しなければならないし、飛び込みはいけないし、泳ぐ方向にも決まりがあるし、楽しむために来たのに、まるで自由がないという気持ちでした。これらのルールは「安全のため」とされますが、大人なら全部自己判断で決められるはずだというのが欧米人的発想です。 日本人はそのような細かいことを命令されるのに何も感じないかもしれませんが、西洋人にとってこれは「余計なお世話」なのです。自分の体の管理のことまでどうして言われなければならないだろうと感じるでしょう。
そして、こう述べています。
脱出の方法
・「政府、医者、マスコミ、えらい人がそう言ったから正しい、だから従わなければならない」という考え方を捨てて、いろいろな事実などを確認しながら、自分で考えて、自分で決めて、自分で行動して、自分で責任を持つこと ・ ルールなどに対してフレキシブル（柔軟）に対応すること
人生は結局のところ、自分で決めている
自分の人生は、自分で決められないと思っている人は多いかもしれません。しかし、そういう人でも結局のところ自分で決めてしまっていると思います。
例えば、「会社のルールで決まっているから出来ない」という話であれば、会社のルールを変えるように動けばいいだけの話しですし、どうしてもいやなら、会社を辞めればいいです。それだったら家族が反対するという人がいるかもしれませんが、どうしてもやりたければ家族を説得すればいいでしょう。もし、これが政府の法律で決まっているということであれば、海外にいけばいいだけの話です。お金がないって？それに向けて今から貯金を始めたらどうでしょうか？
結局のところ、そういうめんどくさいことをするパワーがないので、「自分でやらないことを選択」しているだけなのです。
海外チームに不幸そうな人のいない理由
今の科学で無理なものだったとしてもその研究をしたらもしかするとできるかもしれません。自分がそう決めてるだけなのに、何か自分以外の力が働いていてどうしてもできないなんてポーズはダサすぎじゃないでしょうか？今すぐは無理だろうだって？じゃあ、１０年でも２０年でもかけてやればいいです。本当にやりたければ。
海外のチームで働いていて感じたのは、「不幸そうな人がいない」のです。みんな楽しそうで、人生をエンジョイしています。彼らは自分の人生に責任をもって、自分で考えて、どうやったら自分の人生が幸せになるかを必死に考えて選択し、行動しています。
自分の人生や幸せが自分のコントロール配下にないと思っている人は、自然と、自分が「不幸」になる選択を受け入れているからより不幸で面白くないことになると思うのです。人生に「我慢」など不要です。もし「我慢」を受け入れているとすれば、それはあなたのチョイスです。
幸せシフトをした話
私自身もこのことに昔から気づいていたわけではありません。確か３０後半あたりでしょうか。ソニックガーデンの倉貫さんが私にいろいろな衝撃を与えてくれました。彼はみんなが、「アジャイルでどうやったら、請負契約が・・・云々」「部長が・・・」「商習慣が…」とか言ってる時に、彼は自分で会社を作って、自分の理想の環境をつくってしまいました。彼の思考回路は、本当に素晴らしくて、ストレートでそしてシンプルです。そして、それを実際に行動しています。彼から「自分で選択して実行すること」を学びました。
それと同時期に、私は会社を経営していましたが、周りの会社を経営して、お金をがっつり儲けている人はたくさんいたのですが、多くの人は全く幸せそうじゃなかったんです。お金をがっつり儲けているはずなのに。いつも忙しそうで、しんどそうです。 そんな時に友人のがく君がいました。彼は特にお金持ちというわけではありませんが、私が彼に「がくくんは幸せなん？」って聞いたら、「むっちゃ幸せですよ！」って満面の笑みで答えていてそれがとても衝撃でした。
私は何となく、お金儲けとか、成功とかそういう先に幸せがあるのかと思っていましたが、実際のところお金と幸せには相関はなかったのです。だから、それ以降は、私は「幸せシフト」と言って、お金ではなく、自分が幸せになる方向に常に人生の選択をするようにしました。自分で決めたポリシーは一つで
「自分がやりたくないことは一切やらないし、いやになったらいつでも辞めていい」
そう考えて行動するようになってからは自分がする選択は、常に自分が好きだからする選択になりました。だからうまくいかなくても一切後悔しなくなりました。例えば、あまり面白くない事務処理とかはこう考えています。「事務処理は好きじゃないからやらなくてもいい。でもやらないと会社を辞めないといけない。今面白い仕事をしている会社を辞めることと、事務処理をすることの天秤をかけると、事務処理やっとくか」と自分で選択しているという感じです。
自分の人生を自分で決めると後悔が無い
だから、自分が人生において、他人にやらされることは一切ないのです。もちろん、すぐにうまくいかないこと、失敗もありますが、そういうのがあっても、自分が「幸せ」だと思う方向性に常に舵を切る選択をつづけていくと、ちょっとずつそちらに近づきます。実際にマイクロソフトに入る前も就職失敗とかしましたけど、結果として今もとても幸せです。 たぶんマイクロソフトの今のポジションがなくなったとしても、私は幸せだと思います。幸せに対して選択していますし、幸せじゃなければ辞めるだけだからです。金や、地位やポジションの問題ではないのです。
たぶん、海外の同僚もきっとこんな考えなのではないでしょうか？だから、私は海外の同僚ともとてもよくなじみます。はなしもポジティブだし、面白いし、正直言うと日本に帰ってくると居心地悪く感じるぐらいです。
自分の人生をコントロールできるのは、自分だけで、自分が幸せになるのも自分の選択。そういう感じで、自分が「自立したもの」としてとらえていれば、他人が何を言ったかとかはどうでもいい話です。他人がわたしに「どうすべき」という話をしたところで、「何言ってんだこのハゲちゃびん。やりたいなら自分でやれよ」という感覚です。
上下関係と自分の人生
日本に帰ってくると不思議な感覚になるのは「上下関係」です。上司だから上で言うことを聞く、後輩だから下で面倒見ないといけない感は今となっては結構不思議な感覚です。人間は上下はそもそもないし、それぞれが独立した大人の人と考えると、新人も、会社にバリューをもたらす仲間です。だから私は常にフラットです。スキルの上下はもちろんありますが、それでも、自分なりのバリューを出すという契約を会社としている仲間であって、私は彼らの人生に責任を持てないし、彼らも自分の人生に責任を持ってくれません。でも、そういうものだとおもうのです。そういう人同士が、助けられることがあれば、助け合うけど、そうでなければ、自分で何とかするしかないのだから、その人次第なのです。
自分の人生を自分でコントロールしないマインドセットと生産性の問題
もちろん、これは私の体験談であり、皆さんが私のようにしなくていいと思うのですが、「自分で自分の人生や、幸せに責任をもって、自分でコントロールする」というマインドセットは生産性や、新しい技術や考え方の導入に大きく影響していると思います。
「会社で決まっているから」ということを深く考えずに制約事項にしてしまえば、いろんなものが歪んでしまいます。商習慣が違うので無理といえば、そこで、新技術の導入は終了でしょう。偉い人が「ダメ」と言ったからダメだとあきらめたら、一瞬で終わり。しかし、自分で考えて、自分でチョイスをする人が増えて行けば、その状況は変わります。
私も長年 Agile とか、 DevOps とか導入しています。相当ポジティブな人からも、「会社のルールで決まっているから難しいと思います」とか、「うちは品質重視だから無理だと思います」「あの部署の部長は絶対認めてくれないと思います」とか何度も聞いてきました。そんな時、私は必ずその人に会いに行くようにしています。
そうすると大抵のケースは、「そういう理由だったらこの承認いらないよ！効率化されていいね！」とか、「品質は重視していなくて、本当はデリバリのスピードが重要で、品質は二の次で大丈夫」と言われたり絶対無理と言われた部長が「一緒に協力して改善していきましょう」といってくれたり。
やる前から自主規制していることがほとんどだし、一回言われたダメと思い込んだりというケースがほとんどで、やりようによってはナンボでもでもやり方はあるのです。やらないとしたら、それはあなたのチョイスです。
自己組織チームと生産性
「自分で考えて意思決定する人」が増えてくると、生産性が強力にアップする方法を使えることになります。それは、「自己組織チーム」と言われるものです。チームに意思決定を任せて、彼らに考えてもらうマネジメントスタイルです。サーバントリーダーシップとも呼ばれており、最近ではこちらのほうが主流のリーダーシップの考え方です。それどころか、今はさらに先に進んだ「ホロクラシー」という考え方もあるようです。
従来の考えでは、部下にやり方を指示して、報告を受けて、その結果をもらって、承認してというスタイルです。一方サーバントリーダーシップではリーダーは、ビジョンを示して、具体的にどうするかは部下・もしくはチームが考えます。リーダーはその実行の時に部下やチームが困ったら助けて上げるというコーチングのようなスタイルです。
このスタイルは生産性的には相当強力なのです。細かく指示をしていたら、常にリーダーは忙しくなりますし、実行がリーダーの実力を超えることはありません。部下も上長の承認がなければ意思決定できなければいろいろな待ちや無駄が発生します。今はソフトウェア開発だけではなく、仕事が高度化しています。誰でも指示通りできる仕事は機械で自動化されます。だから、ツールのサポートも「考える人」の生産性を上げるようにシフトしています。「考える人」が最大の生産性を上げられるように。
自己組織チームの威力はまた別の機会にブログを書こうと思っています。
上下関係が生む導入の無駄
こういうマインドセットと、従来型のコマンドアンドコントロール型のマネジメントがまだまた主流の日本で、新技術や考え方の導入が遅れるのも納得がいきます。自己組織型チーム的な管理がされていない日本では、技術や、メソドロジーの選択の権限を持っているのは、実際にそれを使う現場の技術者ではなく、上位マネジメントの方になります。上位マネジメントの方は、普段コードにふれていませんので、妥当な選択ができるはずが ありません。商売がうまいベンダーは、本当に現場で使いやすく、生産性があがるものではなく、上位マネジメントにとって都合がいいツールを作るようになるでしょう。本当に現場でつかえるツールは、現場で運用している人だったり、現場で毎日コードを書いている人がわかることです。
ツールや方法の選定は、単純な比較や、お金ではない「手触り感、嗅覚」みたいなもんが本当に重要です。
このことはインターナショナルポジションでDevOpsエバンジェリストをしているとひしひしと感じます。例えば我々が、DevOps ハッカソンというハッカソンイベントを無料でやっているのは、DevOps のよい事例を作るために、そういったお客様とつながるためにやっています。
他の国ではこのイベントは効果絶大です。何故なら、そこにやってくるエンジニアが技術選定や、DevOpsの導入を決めるので、彼らが「いいな」と思うとすぐに「導入しよう」という話になるのです。そこに承認とか時間のかかるものはありません。 ところが、日本では、DevOps ハッカソンから事例につながったものは残念ながら今のところありません。日本ではエンジニアではなく、マネージャが決定権を持っているからです。
日本でも、「自己組織チーム」を運用してうまくいっている会社さんは本当にたくさんあります。私のかかわったアジャイル / DevOps プロジェクトはすべてそうですし、倉貫さんのソニックガーデンもそうですし、大手のKDDIさんの導入は完全に本質をついたものです。未来工業という会社さんだとずっと昔からずっとそうみたいです。だから、日本だとできないとかそういう話ではないのです。ただ、私もこの炎上で気づきましたが、こういうマインドセットがあれば、より、自己組織チームが強力に働くようになって、なおかつ、チームのメンバーも、マネージャさんも楽しく、成果があがる仕事ができるようになってくると思いました。
マインドセットを変える方向性
私はそういう背景があるので、日本の文化に合わせる方向性ではなく、マインドセットを変えて、より効果を高める選択をしました。みなさんのチョイスはみなさん次第で私がどうこういう話ではありません。ただ、別に厳しい話をしたいわけでも、全員の方にDevOpsをやっていただきたいわけではありません。
最後にこのエピソードを紹介して終わりたいと思います。
私が今回ブログが炎上したあとに、こういうコメントをしました。
牛尾： アジャイルやりたくないのならやりたくないといえばいいのにね。
私の友人はこう言いました。
友人： お前が言うか？
私はこう答えました。
牛尾： はい。「やりたくない」というのは立派な理由です。
今なら私がこう答えた意図がわかってもらえるかもしれません。私の人生は私のもの、皆さんの人生もみなさんのもの。誰も自分の人生を左右する権利などない。
ならば、自分で選択して、より幸せな方向性を目指しませんか！
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。
尚、これは所属会社の見解ではないことは明確にしておきます。
サム・グッケンハイマーの一言
私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。
ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答していた。
しかし、そんな考えを吹き飛ばすような事件が先日発生した。
サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダーだ。世界的にも著名で、多くの書籍を執筆し、世界最大のアジャイルカンファレンスでキーノートも務めた。そんな彼が de:code 2016で来日した。その時に数社の顧客訪問を実施し、私も数社のアテンドを手伝った。
私は彼といろいろ話をして大変勉強になったが、彼が帰国後送ってくれた議事録を読んで、ハンマーを頭で殴られたような衝撃的な一言があった。彼はエンタープライズ系の企業の方から「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」という顧客からの質問に対してこう答えたのだ。
「ウォータフォールは一切メリットがないので止めておきなさい」
普段彼はスーツは着ないがその彼が顧客訪問のためにスーツに身を包んでいたのに、こんなことを顧客に言い放ったのだ。その一文を読んだとき私は「ああ、本当は心の中でそう思っていたんだ、だけど、世間の目だとか、角が立つとか、炎上するのでは？とか仕事がなくなるのでは？とかそういうことを気にして自分は大人の態度とやらをとっていただけじゃないか」と気づいたのだ。つまり、本当の意見をいうことから逃げていたのだ。
自分の本当の心の中
自分の心の中ではとっくに決着がついている。大規模だと、ウォータフォールしかない、基幹系はウォータフォールだとかいろいろ意見はある。では、所属会社のことで恐縮だが、マイクロソフト以上の大企業が日本のどこにあるのだろうか？マイクロソフトは、アジャイル化を終えて、さらに DevOps ジャーニーを進めている。
マイクロソフトじゃなくても、海外の他のTech系の企業のどこにウォータフォール押しの企業があるだろうか？
海外で出版されている新しい技術系の本を見ても、アジャイル以降のノウハウがどんどんデファクトの考えになっており、それを実践したときに発生する課題について書かれている。 最近のどの本を見ても「この本ウォータフォールが前提だな」というのは見当たらなくなっている。ソーシャルコーディング等、アジャイルからさらに先の新しいパラダイムのプログラミングの習慣、文化の上に新しいノウハウが構築されている。
統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで９５％の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている。
マイクロソフトの面接での出来事
私が、マイクロソフトの面接を受けた時にも、自分の現在の２つ上の上司が面接官だった。彼は面接の最初にちょっとびっくりした声で私に聞いた
Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か？
私は正直に答えた。「そうだよ。特にエンタープライズ系で。スタートアップとか、サービス系だとそうでもないけど」
彼は相当びっくりしていた。別の機会だが、最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの！そんなの誰もやってないよ！」と本当に驚いていた。彼女は特にアジャイルや DevOps の専門家とかではない。
ウォータフォールを紐解いてみる
ここでWikipediaでウォータフォールの項目を改めて調査してみた。定義のところにこんなことが書いてある。
Waterfall model - Wikipedia, the free encyclopedia
ウォータフォール開発モデルは、製造業や建築業に起源をもっている。高度に構造化された物理的な環境特に、あとで、変更があったときに著しく高価になるもしくは不可能になる環境だ。当時、ソフトウェアのフォーマルな開発手法が存在して居なかった。このハードウェアオリエンテドなモデルが、シンプルにソフトウェアに適用されたのだった（過去形）
という説明になっている。ポジティブで公平な記述をピックアップしてもこんな感じだ。
ウォータフォールモデルが向いているのは、スコープが固定されており、プロジェクトが固定的で、確実であり、技術が 明確に理解されているものである。
今のソフトウェア開発にはとても向くとは思えない特徴になっている。私は２０年以上この業界にいるが、そんなソフトウェア 開発プロジェクトにお目にかかったことがない。
実際ウォータフォールモデルは、建築とかだと、素晴らしい成果を出しているところもある。私が昔訪問したあるお客さんが 言っていた。「私たちは８０年代に作成したWBSをいまだに現役で使うことができている。でも、ソフトウェアだけはそうはいかないんだよな。」と。
ウォータフォールは起源から異なっていた
さらにお話をすると、ウォータフォールの起源はどのようなものか？というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている。しかし、この論文を見ていただければわかるが、この時点でも、成功するためには、繰り返しや行ったり来たりが必要であり、できれば２回繰り返しなさいといったことが書かれている。現在、日本でイメージするウォータフォールは起源の時点から異なるのだ。英語が苦手な人も上記のリンクを見ていただければ絵で描いているのでご確認いただけると思う。
この後国防総省に広まったときに、なぜか「繰り返し」「戻りの線」がカットされて広まったという歴史がある。彼はとても悔しかったそうだが、その意思を受け継いで彼の子供が作ったのが、繰り返し型のRational Unified Process である。 ちなみにWikipeidaのWaterfallの項目を見ると、その後国防総省は、ウォータフォールを嫌い、イテレーティブで、インクりメンタルな方法に変更したとの記述がある。
ウォータフォールを前提とするのが本当に日本のためだろうか？
ソフトウェアの専門家だったら、こういう歴史を知っている人も多いだろう。ウォータフォールのメリットを語る人も、こういうことを知らずに言っているのではなく、日本がウォータフォール前提にいろんな制度を作っていることや、要員、メンバーの慣れ、エンプラ系のプログラマのレベル、商習慣、日本文化の不確実性の忌避などの性質を考慮して、日本でやるなら、ウォータフォールで実施することも否定できないという考えを持つのもわかる。
しかし、これらは、ソフトウェア開発の本質だろいうか？オブジェクト指向以降に生まれた技術を使ってソフトウェア開発を０から、何のしがらみもない状態から開発するとしたら、誰がウォータフォールを選択するのだろうか？そこに利点はあるのだろうか？
今、時代はDevOpsやマイクロサービスの時代に突入している。リードタイムが短縮されて、１日に１０回も１００回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が１５分で当て終わるような時代だ。
しかし、日本の特にエンタープライズはいまだウォータフォールで、数か月以上のリードタイムになっている。こんなのでどうやって海外のベンダーと対等に戦うのだろうか？ まさに、竹やりで戦闘機と戦っているようなものだ。みんな竹やりの技術を必死に磨いているうちに、海外では、戦闘機でどんどん飛行時間を伸ばして、経験を積んで新たなノウハウを獲得している。
人や人種の優秀さの問題ではないのだ。今までは内需で、飯を食えたかもしれないけど、本当にそんなのでいいとは思えない。海外の新しい方法、テクノロジーの経験を積んだ企業が乗り込んで来たら国内はむちゃくちゃになってしまう。
私は人は変えられないと思っている。変えられるのは自分だけ。だから、このチョイスは人次第だと思うし、ウォータフォールを続ける人も特にダメだか、間違っているとは思わない。
方法は二つある。自分たちの「習慣・現状」に新しい考えを合わせるのか、新しい考えに合わせて「習慣・現状」を変えるのか。私は「習慣・現状」を変える方が本質だと思う。敵と戦うときに、余計な重りを背負ってどうやって勝てるのだろう？我々の価値は顧客にバリューを届けることが勝負で、「日本の事情」は誰も考慮してくれないのは当然じゃないだろうか？だから、「重り」を減らす方がよっぽど楽じゃないだろうか？
だから、自分は、嫌われても、炎上してもいいから、ソフトウェアの専門家として、自分は現在のソフトウェア開発においてはウォータフォールは何のメリットも無いという意見であることを明確にしておきたい。
自分の恥ずかしい体験談 私はインターナショナルでは無価値である
このように思い至ったのはSamの事件以外にもいくつかの事件があった。マイクロソフトに入る前に、私は外資系、できれば海外に住むことをターゲットに仕事を探していた。その時にある会社さんがいて、私のことを気に入ってくれた英国の企業があった。
私はアジャイルコーチとして、日本でよく遭遇しそうな課題について彼らと話をした。彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか？みたいな話をしてくれた。特に先進的なIT企業ではない。一般的なユーザ企業だ。私はただ、日本のブランチはそうなってないから、そこを助けてほしいみたいな話だった。日本では価値はあるのだが、海外のポジションで働こうと思ったら、私は無価値なのだ。彼らにアドバイスできることなどない。だって、日本の支援ではそのレベルの濃いアジャイル支援の経験できないのだから。
一方、私は日本では自分で言うのもなんだが、アジャイル導入に関しては無敵といえるほどの適応力を見せていた。2003年にアジャイルをはじめて数年の自分が、ソルトレークのカンファレンスに行ったとき、私が請負契約の中でアジャイルをやるためにどんな工夫をしているか？などの話をすると、参加者の人はものすごく関心を持って聞いてくれた。日本でアジャイルの導入の時にテスト駆動開発が出来ない問題を解消するための、オブジェクトゲームという手法を、2011年にアジャイルカンファレンスで紹介したときは、米国以外の人は関心をもってもらえたが、米国の人からは「子供の教育にとてもいいね」とセッション自体はとてもほめてもらえたが、米国でのニーズのなさを感じた。つまり、私は日本で働いているから価値があるが、米国や英国に行ったら無価値なのだ。これは現時点でも自分の悩みでああるので解決するためにもがいているところだ。
私のアジャイル歴はおそらく米国の平均的なアジャイルコーチよりずっと長いだろう。では、なぜこんなことになってしまったのだろうか？それは「経験」だ。
最も深刻なことは、「経験」を積めないこと
2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった理由は、日本では「経験」を積めないからだと思う。アジャイルコーチとして、１５年ぐらいやっていても、日本ではいつまでたっても「導入」なのだ。深い知識より、日本の商習慣の中で如何にアジャイルの能力を最大限に発揮できるよう「調整」したり足りないところを「埋めたり」する能力が必要だ。アジャイルの知識や、プロダクトオーナー、リーンスタートアップ、そして技術力よりもよっぽど必要とされる。多くの人はこれに気づいていない。私は「そっち」も鍛えているから、国内では活躍できるのだ。逆にせっかくアジャイルコーチとして深い知識をもつことに注力していても、そういう「寝技」的な技術がないため、実力を発揮できない人も多く見てきた。しかし、国際的には彼らの方が「価値」があるのだ。
現在でも日本はアジャイルのコーチングといえば、基本導入部分になってくるので、アジャイルコーチも導入ばかりの経験になってくる。アジャイル(2001)->アジャイルテスティング(2009)->継続的デリバリー(2009)-> DevOps(origin 2009)に移っていったチームをずっと面倒見て経験をつめているアジャイルコーチは、一部のインハウスの人だろう。それは、アジャイル実践企業(31%)の中でも10%以下に過ぎない。スタートアップや、サービス系だと、そういう企業もあると思うが、エンタープライズ系だと今からアジャイルというのも非常に多いと思う。
simplearchitect.hatenablog.com
アジャイルコーチ以外のロールの人もそうだ。ウォータフォール文化で開発を続けている人は、技術的負債をなくすための、新しいコードの考え方や書き方、新しいチームのコラボレーションやワークスタイルを経験することができない。マネージャの人は、米国では「オールドファッション」と呼ばれるコマンドアンドコントロールと呼ばれるスタイルのマネジメントスタイルしか経験できず、モダンなサーバントリーダーシップ型のマネジメントの経験を積むことができない。Opsの人だってとっくに塩漬けになったような技術のお守りをマニュアルベースの手動で運用するのにいっぱいいっぱいで、自働化されたような最先端のモダンな、運用環境や、開発やビジネスとのコラボレーションの経験を積むことができない、企画の人も、本番から頻繁にフィードバックを受けて、企画や、戦略を洗練させていく仕事の経験を積むことができない。これこそが最も深刻な問題だと思う。なぜならこうなると差は開く一方だからだ。経験だけは、お金を払っても解決できない問題なのだ。
日本はソフトウェア開発の後進国
ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた。この差は年々広がっていると思う。経験というのは短縮できない。彼らが戦闘機の経験を積み重ねている間、竹やりの経験を積み重ねても、戦闘機に乗れるわけではない。 あるとき気づいて戦闘機に乗り始めたとしても、その操作になれるのには、やはり同じだけの経験が必要になってくるだろう。
私はインターナショナルチームに所属する経験から、日本人が彼らに劣ってるとは思わないのだ。それどころかイケてるところがいっぱいある。仕事を一生懸命やるし、イノベーティブだし、世界に勝てる要素はゴロゴロある。もったいなすぎる。
自分の素直な気持ちに従うと、なぜ明らかにソフトウェア産業で後進国となっているのに、先進国のことを学び実践しないのだろうか？
インターナショナルチームにいると、同僚がどんどん先に進んでいるのに、日本で足踏みするのは面白くなさすぎる感覚がある。
自分が目指すビジョン
私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ。そして、Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい。そのようなスピードで動いている人も既にいる。きっとできるはずだ。みんながみんなそうならないと思うけど、まずはそうなりたいと思っているお客様や仲間と一緒にそのビジョンを実現していきたい。
これは難しいことじゃない。単に「一歩」そっちの方向に足を踏み出すことだけでいいと思うのだ。数年後振り返るとそれはきっと凄い差になっていると思うから。
