「すべき事」をなくせばうまくいく。- インターナショナルチームでの学び
私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は日本でプロジェクトの改善活動を実施している時に気づいたことをシェアしたいと思います。
先日、ハックフェストというイベントを実施していました。現在実施している開発チームの作業工程を見える化して、無駄を発見し、マイクロソフトのメンバーが支援して、自動化のハックをして、実際に改善しちゃおう！というイベントです。このようなステップを踏むと、実際に自動化する前に、現在のソフトウェアリリースのリードタイムが８ヶ月だったものが、１週間ぐらいになることがわかったります。
それを実際にハックして実現しちゃおう！というものがハックフェストなのでなんともエキサイティングな仕事です！
ところが、先日ハックフェストを実施したときに、メンバーの人と一緒にペアプログラミングをしていたのですが、その人がとっても辛そうな顔をしていたのです。本来プログラマにとって「ハック」とは楽しいものです。なんで、そんな辛そうなんだろう？ととても気にかかっていました。
インターナショナルチームでは仕事は楽しむもの
そういえば日本では仕事を「楽しい！」といってる人は多くないイメージです。私も実の母からも
好きな事を仕事にできる事はそうそうないのでお前は幸せや。でも世間様はそうやないんやで、みんな我慢してるんや
と良く言われます。しかし、インターナショナルチームや、USに行って仕事をすると、全く逆のイメージで辛そうに仕事をしている人を探す方が難しい感じです。私はマイクロソフトしか経験がないですが、USでマイクロソフト以外でハッカソンのお手伝いをした時も、何かに「悩み」はしても「仕事は辛いがやらなければならない」なんて言っている人に会った事がありません。日本側の私のサポーターのDrewもいつも仕事が楽しそうです。
私の上司のDamienが私にいつも聞いてくるのもこの一言です。
Tsuyoshiエンジョイしてるか？
この違いは一体なんなのでしょうか？ 今回は、なぜ、仕事が辛いものになってしまうのかを考えてみました。
仕事が辛いものになってしまう理由
メンバーの一人は私の友人だったので、「なんでハックしているのに辛そうなのですか？」と個別に聞いてみました。
牛尾さんや、前佛さんに来ていただいているので、嬉しいのですが、結果を出さないといけないのでプレッシャーがあるんです
ここで初めて、インターナショナルチームで、バリューを出す事と、日本式の「結果を出さないといけない」という事のイメージが大きく違う事に気がつきました。
「目標」を立てた後の実行フェーズの違い
インターナショナルチームでも、日本でも、「目標」は立てます。例えば今回でいうと、「従来８ヶ月かかっていたソフトウェアのリリースを１週間に短縮する」になります。それを目標に、５日間のハックフェストを実施するとします。
日本だと、一度目標が決まったら、途中で未知の問題が発覚しても、「プロなのだから、一度決めた納期はしっかり守り通そう」というノリになって、徹夜などをして必死で達成しようとします。そして、その目標が達成できなかった時は「失敗」の烙印を押されて次回は二度とこういうチャンレンジができなくなることもよくあります。
一方インターナショナルチームだと、「目標」は立てます。途中で問題が発生したら、「どうやったら達成できるか？」は常に考えたり、工夫したりしますが、目標設定に無理があると判明した場合は、最も優先順位の高いの最初の１ステップのみを目指すように方向転換します。定時以降の仕事や、休出でカバーしようという流れになることはありません。できないものはできないのです。
上司 Damien の一言
私が今のチームに勤めて最初に衝撃的だった事があります。私はインターナショナルチームですが、普段は日本にいますので、日本チームとも仕事をします。 インターナショナルチームのKPIは定時で無理なく楽に達成できる程度のものになっていますが、日本チームの仕事もお手伝いする事があります。 それに、最初入社した頃は、大量の英文メールにも慣れず、いろんな仕事に手を出してアップアップになっていました。その事を上司に相談しました。
きっと日本だといい上司でもこんな感じじゃないでしょうか？「最初は大変だが、しばらく慣れるまで頑張るしかない。私も出来る限り手伝うから頑張ろう」しかし、Damien が言った事は全く異なりました。
Tsuyoshi 君の一番重要な仕事は何だ？うん DevOps ハッカソンだな。君はいまそれだけをやればいい
彼に限らず、インターナショナルメンバーや、Drew からくるアドバイスで、「ちょっとしんどいけど頑張ろう」「君が本来やるべきだから時間がかかってもやり遂げるべきだ」的なものがあった試しがありません。日本の場合は、やると目標を決めた事を、リソースを追加しても何があってもやりきる方向に倒れますが、インターナショナルチームだと、単純に定時でできる量になるように「作業量」をいまの実力でできる範囲内に調整するのがほとんどです。予定されたアウトプットより少なくなっても気にしません。何故なら、できない事は出来ないからです。
期間内にやりきる対象 vs 実際にやった結果の学びを得る対象
もちろん全ての日本のチームがそうではないと思いますが、多くのチームが日本では目標を決めたらそれが「期間内にやりきるための対象」になり、目測を誤っていても、やりきる対象になるので、相当プレシャーがかかります。失敗は許されないムードのもあります。 インターナショナルチームでは、目標はあくまで目標であり、重要な事は実際やってみて、実際どうだったか？どれぐらいできたか？のフィードバックが重要と考えているようです。最終的に達成した事が計画を超えているか？という観点ではありません。ですので定例会議みたいなものでも、「やってみて実際どうだったか？、改善ポイントやベストプラクティスは？」という事を聞かれます。決して「計画通りかどうか？」とかそんな話は聞かれた試しがありません。
「すべきこと」の量が圧倒的に違う
他の観点で言っても、日本と比べると「すべきこと」が圧倒的に少ないイメージです。インターナショナルチームだと、やるべき対象は KPI の達成だけであり、それも、そんな無理なものが設定されているわけではありません。やりかたは自由で細かく指示はされませんので、自由にやってOKです。
日本だと、そういう評価基準があるのに加えて、日本人として、社会人として「こうあるべきだ」みたいなものが圧倒的にたくさんあります。仕事の結果に対しても「このようにやるべきだ」「これぐらいやるべきだ」「この期間内にやるべきだ」みたいな暗黙の期待が多くあり、それを達成しないと、いまいちな人と思われてしまうケースもあります。本当にそうすべきかはわかりませんが、その期待に全て答えようとするとそれは大変です。
インターナショナルチームは、KPI以外に「やるべき事」ほぼありません。KPIさえ達成していたら、細かく言われる事はありません。やり方も自分で決めるので「やらされること」も、せいぜい月次レポートと、必須教育程度です。
目標設定に関しても、実際やってみて、学んだことをシェアすることが十分バリューであり、目標通り行くことはどうでもいいのです。やるかどうかも自分が決めますし、やらなくても何も言われません。自分がやりたければやるというノリです。だから、みんなその「難しい」チャレンジに対してパズルを解くのと同じノリで楽しめるのです。
自分 vs 他人
向こうの文化で考えると、「自分」が一番大切で、自分の幸せが一番大切です。「自分」が「自分以外のもの」になる事も期待されません。むしろ、「自分」だけでなく「他人」も「幸せ」で、「自分らしくいられること」は重視されます。日本だと、「人の期待と違っている」といろいろ言われますが、インターナショナルチームでは、ダイバーシティを受け入れないと、仲間に入れてもらえません。私が衝撃的だったのは、イギリスに短期留学している時の話です。
ホストファミリーのお母さんが言っていました。「学校にジプシーがいるのよ。その子がむちゃくちゃ暴れるのね。親もいるんだけど、親も一緒にあばれるのよ。だから、その家族のためだけにボディーガードを雇ってるのよ。」それを聞いた私は「なんで、イギリスに来ているのに、ちゃんとイギリスのルールにのっとって振舞わないんだろうね？学校もお金の無駄やん」と言ったのですが、彼女はこう言いました。
Tsuyoshiそれは違うよ。我々から見てむちゃくちゃでも、彼らは彼らの文化があるからそれを尊重しないといけないのよ
これは自分にとって衝撃的な一言でした。
「すべきこと」をなくせば上手くいく
このように、日本には「すべきこと」がたくさんあるため、多くの時間がかかったり、多くの人がいろんな事をやる前から諦めているように見えます。私もバリューストリームマッピングという、ソフトウェア開発作業の見える化を行って無駄を見つけるワークショップを実施しています。すると、たくさんの承認作業や、手作業、有効だと思えないドキュメント書きが明らかになったりします。そして大抵は現場の人もその事を無駄だと思っています。
ところが、「決まっているから変えられない」とか、「変えようとしたら大変だから」という事を言って今の制約の中で仕事をしようとします。
そしてその「すべきこと」は何か問題が発生するたびに、どんどん増えてしまいます。本番へのリリースも、「失敗しないように、慎重にテストをしないといけないから、たくさん仕様書を書いて、マニュアルテストをします。それでないと本番にはリリースできません」と現場では言う事が殆どです。
ところが、実際に社長さんをつれてきて一緒にディスカッションをすると、「この承認無駄だね。カットしよう。」とか、「別に品質にそこまでこだわらなくていいから、早くリリースできるように倒そうよ」「そこは現場で判断していいよ」とか一気に話が進む場面をよく見てきました。
日本でも、「すべき」と思い込んでるだけでそうでないケースは本当はもっと多いのではないでしょうか？
幸せに、バリューを出す仕事をするために
私はその後のハックフェストからは、次のように言うようにしました。
- 「目標」は必ずしも達成しなくてもいいし、自分たちのペースでみんなが楽しんでくれたらいい
- 実際にやってみる事が重要で、どこまで行けたかは終わってからでないとわからないのでどうでもいい
- 終わった後に、無理ないペースでどこまでバリューが出せたかを学んでみよう
私の他のブログエントリにあるような、Be Lazy のような、時間をかけてピカピカなものを目指すより、もっとも楽な手段でバリューを出す方法のお話もしてみました。途中で無理があったら、頑張るのではなく、無理ないように物量を減らす方にシフトすることを推奨しました。
すると、みんな笑顔でハックしてくれるようになって、誰一人として、しんどそうな顔をしなくなり、結果としてかなりの成果が達成できました。
この辺りは、日本の文化なので、「すべきこと」を一気になくす事は出来ないでしょう。でも、まず自分がそういう考えをする事はできるかもしれませんし、自分のチームはそういう考えで運営する事も可能かもしれません。
私は少なくとも、自分が幸せを感じて、楽しい仕事ができる方を選択したいと思っています。ですので、自分と関わる人も、その人がやりたい事をやって、仕事を楽しんでもらいたいなと思います。そして、それが結果としてチームの幸せと、バリューに繋がるんじゃないかなと思っています。
だから、自分も、まず自分が仕事を楽しんで、幸せを感じて、そして、自分以外の人もそう感じてもらえるようまずは「すべき」という事を自分からなくすように小さな一歩を進めてみたいと思います。
P.S. 今回のタイトルは尊敬するソニックガーデンの倉貫さんの著書をオマージュさせていただきました。
倉貫さんの会社の仕事のやり方はこういった「すべき」が見当たらないやり方で昔から凄いなと思っていましたが、今インターナショナルチームになった視点から見ても素晴らしいと改めて思います。
