アジャイル・DevOps 実践企業サーベイの集計結果と考察
先日、113名もの皆さまの協力を得て、「アジャイル・DevOps 実践企業サーベイ(2016)」を実施させていただきました。その集計結果を公開したいと思います。
サーベイにバイアスが入らないように、事前に公開をしていなかったのですが、本サーベイの目的は、日本に、DevOps を導入するにあたり、その前提条件である、アジャイル開発の導入がどの程度本質的に進んでいるか？ということを調査したかったというのが発端になっています。著名なIPAのサーベイ(2013)では、５１％の企業がアジャイル導入済みになっていましたが、肌感覚的には本当かな？というのがあったので、調査してみたくなりました。
今回はサーベイの結果をフル公開いたします。私もサーベイのプロではありませんし、コメントはあくまで私の見方ですので、みなさんご自由のこのサーベイの結果をご利用ください。皆様の分析を皆様のブログに書いていただいてももちろん大歓迎です。
1. テストおよびその他の自動化の達成状況
分析結果
この項目で調査したかったのは、どの程度のプロジェクトがユニットテストのコードをちゃんと書いているかです。欧米でもユニットテストがアジャイル、DevOps の自動化に関しては最も基礎であり重要なポイントになります。ユニットテストが自動化できていなければ後続の継続的インテグレーションや、継続的デリバリも実現できません。つまり、繰り返し型開発を実施しても、回帰テストがないため、大変不安定でバグなどが多くなると思われます。
上記の実態を見てみると、アジャイル実践企業のうち、32%は手動でユニットテストを手動で実施しているという、衝撃の結果があり、48% ぐらいが実質ユニットテストが継続的インテグレーションができる程度に実施されており、11%がしっかりとしたユニットテストを書く「習慣」ができた企業であるということが読み取れます。実際、継続的インテグレーションの導入も44.2%にとどまっています。
継続的デリバリや、フィーチャーフラグ、システムテストの自働化などの高度な実践は10%程度のプロジェクトが実施している目測になります。
おすすめ事項
もし、皆さまの企業で、アジャイル開発、DevOps を実施して繰り返し型の開発をしているにも関わらず、テスト駆動開発や、継続的インテグレーションを導入していないのであれば、もしよろしければ、導入をご検討ください。お勧めとしては、テスト駆動開発の経験が長いエンジニアをあなたのチームにしばらくでもいいので雇って一緒に開発するのが最も近道だと思われます。なぜなら、テストを書くことは「習慣」なので、座学だけでは身につきにくいからです。私も下記のDevOps スターターキットに、テスト駆動開発の実施イメージをビデオにして公開していますので、どんなものかイメージがわかなければごらんください。
simplearchitect.hatenablog.com
サーベイの詳細データ
2. 企業内のプロジェクト導入の割合
分析結果
先に述べたIPAのサーベイのサーベイが正しいとすると、各企業が個人的に「野良」でアジャイル開発を導入しているのか、ある程度組織として認められて実践しているのかを知りたいと思ったのがこの項目です。48% の企業が、導入が5%以下、つまり、あまり組織的な導入でないということが読み取れます。17%の企業が、アジャイル開発実践企業サーベイであるにも関わらず「0%」であるということも驚きです。一方で16%もの企業が、70%以上のプロジェクトでアジャイル開発を導入しています。
おすすめ事項
この項目では特におすすめ事項はありませんが、草の根活動のアジャイル開発やDevOps 導入を広めたい時には、事例を作って、ビジネスKPIで証明できる成果を上げることをお勧めします。日本の場合は、ある程度権限のある人に対して、説明をして、取り組みを認めてもらうのがよいと思われます。ビジネスKPIとしては、リードタイムなどが図りやすいと思います。Value Stream Mapping などの手法を用いて、Before / After の数値を比較すると、経営層の皆さまに納得してもらいやすくなります。
サーベイの詳細データ
3. アジャイル・DevOps プロジェクト導入の課題
分析結果
課題に関しては、全体的にはアジャイル導入に関する課題が多く、DevOps に関する導入課題がまだ高くないことから、多くの企業はウォータフォールからアジャイル開発へのジャーニーの部分でいまだ苦労していることが伺えます。
数が多い内容に関して記述します。
メンバーがテスト駆動開発が出来ない課題
多くの企業でユニットテストを書く習慣が出来ておらず(54%)、TDD/BDDを実践できるメンバーが少ない(57%)という課題を持っています。
アジャイル開発のマインドセットの導入の課題
マイクロマネジメントがやめられない(42.7%) つまり、自己組織化チームができないのは、アジャイル開発の生産性を大きく阻害する要素ですが、40%以上の企業がそのような課題を持っています。
経営層への説明の問題
経営層が事前に納期、機能、コストを求める(53%) 、会社のルールが、ウォータフォール前提になっており、無駄な作業が多い(43.7%) も高いスコアになっています。これは、うまく上位マネジメント層を巻き込めていないことに起因すると思われます。
技術的負債が膨らんでおりメンテナンスできない
この問題は、米国でも頻繁にあるもので特別ではありません。が解決策に関しては次に記述いたします。
おすすめ事項
テストに関する対策はすでに最初の対策で記述いたしましたので割愛します。経営層の巻き込みに関しては、経営層のわかりやすい言葉と数字で説明する必要があります。またそもそも彼らを「巻き込もう」という意思が必要です。 そのためには、Value Stream Mapping 等のビジネスKPIを明確に出せて、尚且つ本質的な改善につながるものを実施し、定期的に経営層に報告ポイントを設けることを事前合意しておくなどが効果があります。 また、技術的負債に関してはこれも実は「テストを書く習慣」にかかわってきます。しかし、すでに負債となっているものがある場合は、コードレビューなどの静的解析ツールを導入して、技術的負債を見える化するところから始めるのをおすすめします。自動のユニットテスト、そして、リファクタリングという設計変更のテクニックをチームがマスタしているとよりこのアクティビティは進みやすくなります。また、マイクロサービスの考えをつかって、少しづつ、分離できるサービスからマイクロサービスにしていくと、コードベースが小さくなるかもしれません。また、技術的負債はあきらめて、REST-APIの向こう側として扱って、インターフェイスのみ自動テストをできるようにする（せめてスモークテストでも）という手もあります。 いづれにしても難しい問題なので、ケースバイケースです。
一方、「マイクロマネージメントがやめられない」という問題は、サーバントリーダーシップや、自己組織化チームについて学ぶとよいと思います。下記にリソースを提示しておきます。下記のブログを見ると、サーバントリーダーシップや、自己組織化チームの具体例について学ぶことができるかもしれません。一つだけ言えるのは、マネジメントの経験が不要になるわけではありません。ただ、今後この新しいマネジメントスタイルを学ぶとグローバルの市場でも最後にご紹介しているサーベイの結果からも、圧倒的に有利になることは間違いないでしょう。
simplearchitect.hatenablog.com
サーベィの詳細データ
4. 所属企業の属性
この項目は、どのような属性の企業がこのサーベィに答えているか？の分析ですが、結構妥当な割合といえます。（肌感覚でしかありませんが、、、）
サーベイの詳細データ
世界の動向と日本の他のサーベイ
日本の他のサーベイでは、PMIのサーベイ(2015)（日本）では、31%の企業がアジャイル導入済みというデータがあります。先に紹介したIPAのサーベイ(2013)では51%になっています。
世界のサーベイでは、Version One の年次サーベイ(2015)では何と95%もの企業が既にアジャイル開発を導入済みになっており、世界のデファクトになっていることがうかがえます。
余談ですが、著名なSam Guckenheimer が客先訪問をしているときに「アジャイルとウォータフォールの使い分け」について質問された際、「ウォータフォールにメリットはないので、やめておいたほうが良い」とコメントしたことだけは共有しておきます。バージョンワンの世界サーベイの95%の企業がアジャイルを導入済みという数値を見てもそれは裏付けられている言っていいのかもしれません。
一方、日本のアジャイル導入の難易度は世界一高い言っても過言ではありません。
here's the chart. Fun to look at.
— Alistair Cockburn (@TotherAlistair) May 14, 2016
Scandinavia rocks.
India came out surprisingly high.@arne_mertz @RonJeffries pic.twitter.com/NVqDnCGQns
これは、Twitter でアジャイルの父として世界的に著名なアリスターコバーン氏がアジャイル導入の文化的導入難度に関して算出したものです。元のデータはアカデミックなデータに基づいています。
世界がすべて優れているわけではありませんが、少なくとも DevOps の導入に関してはデータ上もリードタイムの削減が1/200等の劇的な削減のデータが出ています。DevOps はツールを導入するだけでは達成できず、アジャイル開発を既に導入済みであることは前提条件になっています。
このデータを見てみなさんがどう感じるかは皆さんにお任せいたします。
DevOps スタータキットの公開
DevOps の概要、プラクティス、そしてそれに関するリソースを整理して自ら学習しやすいようにしてみました。DevOps の考え方、プラクティス毎に、ビデオとそこで使っているPPTを公開しますのでお楽しみください。
1. DevOps の歴史
DevOps を学ぶときに、海外と比べると日本の商習慣が異なるので、向こうで話されているDevOps の概要を聞いてもピンと来ないかもしれません。そこで、DevOps の歴史を7分程度で学べる動画を作成しました。 これで、DevOps が生まれきた背景が学べると思います。
2. DevOps の概要
DevOps の歴史を知るとと、DevOps の概要がよりわかりやすいかもしれません。次のビデオをご覧ください。
DevOps プラクティス
ビデオで解説されているとおり、マイクロソフトが定義している 主要な DevOps プラクティスを学べるようなコンテンツを作成 してみました。
3. Infrastructure as Code
インフラストラクチャをコード化するInfrastructure as Code の解説とデモです。
Infrastructure as Code の技術はたくさんありますが、いくつかご紹介していきたいと思います。
3.1. Azure Resource Manager
ビデオでもご紹介している Azureを使っている人には便利なツールで、Visual Studio を使うと相当楽にコードが書けます。 それだけではなく、実態はJson なので、普通のテキストエディタでもコーディング可能です。
私のお好みはエバンジェリスト仲間の安納さんのチュートリアルです。ゼロから作っていくのでコンセプトなどがわかりやすいです。
ちなみに、自分でAzure Resource Managerのテンプレートを公開することも可能です。これは、HashiCorpのNomadを好きな 台数だけプロビジョンできるテンプレートになっています。このコードは公開していますので、イメージがわきやすいかもしれません。
GitHubに Azure Resource Template がアップロードされています。これは、Azure で実際に使わているテンプレート ですので、書き方に困ったときに参考になります。
3.2. Terraform
HashiCorpの Terraform も最近お気に入りのツールの一つです。Go言語で書かれているため、Windows でも、Macでも、 Linux でも機嫌よく動作します。私が、de:code 2016 のキーノートで Jenkins 2.0 から、Terraform を自動実行して 実際にサーバーをプロビジョニングしました。
Terraform バーチャルマシンを ARM対応の Terraform を使ってプロビジョンしてみる
3.3. Chef
ARM や、Terraform は、VMや、ネットワークを作成するのは得意なのですが、その中身（ミドルウェアのインストール） などはそんなに得意ではありません。その時に使うと便利なツールがChef です。Linux 系でも、Windows 系でも動作 します。
Chef のチュートリアルシリーズは大変わかりやすく、Linux, Windows どちらでも実行可能です。英語ですが、チュートリアル なので、手順をおってやればイメージは相当わきやすいと思います。
他にも Ansible や、Itamae 等様々なツールが存在します。
3.4. PowerShell DSC / PowerShell
PowerShell を作ったJeffrey Snover自らが解説するシリーズでがっつり学べます Getting Started with PowerShell 3.0 Jump Start Getting Started with PowerShell Desired State Configuration (DSC)
日本語で学びたい人はここにがっつりとした安納さんの資料が！ 【ハンズオン】PowerShell で Hyper-V を構築・管理
3.5. xPlat / Azure PowerShell
Azure SDK を使うと、クライアントの生成なども可能になります。様々な言語がサポートされています。Azure SDKを使うと、 生の挙動が確認できるので、感覚をつかみやすいので触ってみるのをお勧めします。
https://azure.microsoft.com/ja-jp/downloads/ https://azure.microsoft.com/ja-jp/documentation/articles/powershell-install-configure/
3.4. Packer
Packer は、HashiCorpが作ったツールで、ゴールデンイメージを作るときに、Infrastructure as Code ができるツールです。 ゴールデンイメージも手作りをしていると、バージョンアップの時に面倒なことになりますが、Packer だとコード化されているので、 安定した運用が可能になります。
3.5. Docker
コンテナ技術のデファクトといえる Docker は今後の基礎知識になりそうです。最高の日本語サイトは、クリエーションラインの 前佛さんの作成したここですね。
David Tesar が私に話してくれたConfiguration as Code の話はこちらのエントリからご覧ください。
4. テストの自動化
自動化するテストと、その種類について解説しています。
5. 継続的インテグレーション
継続的インテグレーションの解説とデモです。
HOL - Parts Unlimited MRP App Continuous Integration with Visual Studio Online Build
6. リリースマネジメント と継続的デプロイメント
リリースや、デプロイの自動化の解説とデモです。Visual Studio Team Services
Visual Studio Team Services の日本語情報は武田さんが書かれたチュートリアルがよいと思います。
https://docs.com/takeda-masaki-1/1805/visual-studio-2015-team-foundation-server-2015
7. アプリケーションパフォーマンスモニタリング / マネジメント
アプリケーションパフォーマンスモニタリングです。具体的な例として、Application Insightという ツールを使っています。
8. テスト駆動開発
テスト駆動開発は、アジャイルや、DevOps を導入するときに Infrastructure as Code と同じぐらい 重要な開発の「習慣」です。このビデオを見て、雰囲気をつかんでください。
これで雰囲気をつかんだら、下記の本は原本なので、それでチュートリアルをやると良いでしょう。 また、リファクタリングはとても重要で、コードが汚いなと思ったときに、このパターンでリファクタリングすると どんどんきれいなコードの書き方が身についてきます。
テスト駆動開発入門 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
8.1. テスト駆動開発が難しい場合は
テスト駆動開発が難しい場合は、OOP(Object Oriented Programming) が十分できていないケースがあります。その場合は、「オブジェクトゲーム」という手法をもちいると、 OOPの基本とアーキテクチャが半日程度で理解できるようになります。オブジェクトゲームの、プレゼン、カード、ソースを置いておきました。
9. Advanced DevOps プラクティス
上級の DevOps に関するご紹介です。
10. Git の基本操作
Ops の方が初めてGitに触れるときは戸惑いを感じるようです。私も最初はとても訳が分かりませんでしたが、 なれると手放せなくなってきます。このビデオでは、Gitの最低限の基本操作のみを解説しています。
11. アジャイルの導入
DevOps を始める前に アジャイルの考えがまだ理解できていない場合は、下記のプレゼンテーションが役に立つかもしれません。
プロダクトオーナーの技術に関してはこれ
12. DevOps の事例
以上です
DevOps で成功するための７つの習慣 ～ Microsoft が SaaS 運営で学んだこと ～
Microsoft の DevOps 実践の第一人者の Sam Guckenheimer が長年の経験をもとに、DevOps をうまく実践するための７つの習慣をまとめてくれました。その内容を原文と共に共有したいと思います。
７つの習慣は特に DevOps のマインドセットを学びたい人にはとてもいいまとめになっています。「リードタイムの短縮」以上の Advanced DevOps を学びたい人にもお勧めです！簡単に翻訳してみましたが翻訳や、解釈の間違いがありましたら是非コメントをお願いいたします。
1. Production First Mindset （本番を第一に考える)
Production is the heart of any software delivery organization, and the best ones recognize that the real production should be top priority for every team member in every role, not just IT operations. Intermediate artifacts like documents and disconnected pre-prod environments are not enough. High performers always track the live site status, remediate any live site issues at root cause, and proactively identify any outliers in performance to see why they are experiencing slowdowns.
本何環境は、ソフトウェアを作成する組織の心臓部です。すべての役割の人(Dev, Ops, PO, Manager...)にとって、最もプライオリティが高いものであるべきです。ITPro (インフラ/運用技術者)にとってだけ優先順位が高いわけではありません。ドキュメントや、プロダクション以前の環境の成果物では十分ではありません。ハイパフォーマーは常にライブステータスをトラッキングし、根本原因の特定や、問題が発生する前にパフォーマンスが悪化している人がなぜそんな目にあっているのかを理解することで、ライブサイトの問題を軽減するようにしていいます。
2. Backlog Groomed with Learning (学びから Backlog をブラッシュアップする)
The Backlog is the stack of work to be done. Different organizations plan, define and manage requirements and projects differently. This can include how you engage with stakeholders and how you request, capture, and track work. It can also include how well you align, agree, and make decisions. High performers treat the backlog as a set of hypotheses, which we need to turn into experiments, and for which they need to collect data that supports or diminishes the hypotheses. Based on that evidence they can determine the next move in the backlog and persevere (do more) or pivot (do something different).
バックログは、すべき仕事が積まれたものです。組織の計画と異なり、要求とプロジェクトでの違いについて定義して管理します。 このことは、どのようにあなたが、リクエストしたか、とらえたか、そして、トラッキングしたか、さらに利害関係者を巻き込むかも含まれています。また、あなたが、どのように整合性をとって合意して、意思決定するかも含まれます。ハイパフォーマーは、バックログを、「仮説」の集合としてとらえます。ですので、我々は、仮説を検証するために、「実験」して、「仮説」を 検証する、もしくは、それが外れていることを証明するデータを集める必要があります。エビデンスに基づいて、バックログのなかで、次にどうするか、そのままの考えですすめるのか、それともピボット（何か違うことをすること）するのかを決定していきます。
3. Evidence Gathered in Production (エビデンスを本番で集める)
Good decisions are informed by data. High performers instrument everything, not just for health, availability, performance, and other qualities of service, but to understand usage and to collect evidence relative to the backlog hypotheses. For example, they will experiment with changes to user experience and measure the impact on conversion rates in the funnel. They will contrast usage data among cohorts, such as weekday and weekend users, to hypothesize ways of improving the experience for each.
良い意思決定は、データによってもたらされます。ハイパフォーマーはすべてを収集します。ヘルスチェックや、可用性、パフォーマンスそして、他のサービスの品質属性だけではありません。 ユーザの利用状況や、バックログの仮説検証を支えるためのデータをも取得します。例えば、あるチームが、ユーザエクスペリエンスの変更を実験していたとしますそして、フューネルの コンバージョン率へのインパクトを測定していたとします。彼らはきっとコホート分析の利用率のデータを比較します。週中、週末の利用率です。ユーザエクスペリエンスを改善するためにの、 か改善仮説の検証のためです。
4. Flow of Customer value (顧客価値のフロー)
Flow refers to an organization’s ability to move software swiftly from initial idea through creation and validation into a production release, without impediments or rework loops. Reduced rework allows teams to focus on delivering more net-new value. Shorter cycle times support increased responsiveness, in turn fostering stakeholder satisfaction and trust.
フローは、ある組織が、ソフトウェアを、最初にアイデアを思いついてから、ものづくりをして、検証して、本番にリリースするのをいかに早くできるかの能力です。もちろん、障害や作業の やり直しをすることなくです。再作業を少なくすることで、チームは新しい資産価値を生み出すことに集中することができます。短いサイクルタイムは、市場への反応性をあげます、 それにより、株主の満足と信用を得ることができます。
5. Team Autonomy and Enterprise Alignment (チームの自立性とエンタープライズへの適合)
The goal for modern application delivery is responsiveness, which relies on flexible scheduling, limiting long-term commitments in favor of iterative experiments, and close team collaboration to facilitate real-time communication and eliminate wasteful handoffs. High performers have multidisciplinary feature crews who pull from a common product-backlog, minimize work in process, and deliver work ready to deploy live at the end of each sprint.
モダンなアプリケーションデリバリのゴールは、「反応性」です。それは次の要素に依存しています。柔軟なスケジュール、繰り返し型開発により長い期間のコミットメントを制限すること、密接なチームのコラボレーション 、リアルタイムなコミュニケーションそして、無駄な「ハンズオフ（成果物を他の人に引き渡すこと）」を削減することです。ハイパフォーマーは、様々なスキルをもった人があつまった、(権限をもち自立した)バックログを実行するフィーチャーチームのメンバ が、仕掛仕事を最小化し、毎スプリントの終わりに、本番にデプロイできる成果を作り出します。
6. Managing Technical Debt (技術的負債を管理する）
The Technical Debt category considers behaviors for strategically managing the impact of short-term and long-term technical decisions.
技術的負債は、短期、長期のインパクトを鑑みて、戦略的に技術的決定を実施していくことを管理するふるまいのことです。
7. Managin infrastructure as a Flexible Resource (インフラを柔軟なリソースとして管理する)
The best performers use the flexible infrastructure of the public cloud and continually improve their architecture to refactor into more independent, discrete services. Using the cloud provides scale on demand and makes it easy to stand up services for continuous feedback from constant usage.
最高のパフォーマンスを出すチームは、パブリッククラウドの柔軟なインフラを使って、継続的にアーキテクチャを改善し、より独立性が高く、分離されたサービスにリファクタリングします。 クラウドは、コンスタントな利用状況からの継続的フィードバック基づいて、需要に合わせてスケールするようなことが簡単になります。
おわりに
最後に、Sam Guckenheimer の印象的な一言でこのポストを締めたいと思います。
There's no place like production!
本番環境などという場所はない。
本番環境は今までのような慎重に慎重を重ねてデプロイする「聖域」ではなく、「学びを得る」場所なのです。
Sam は de:code 2016にも来てくれたのでお楽しみに！
simplearchitect.hatenablog.com
参考
DevOps Chat: 7 habits of successful DevOps 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
日本でインターナショナルチーム文化を作る方法を考えてみる
今まで、幾つかのポストで書いてきたのですが、私は今のインターナショナルチームのポジションをとても気に入っています。楽しく、気に入ってるだけではなく、実際の生産性やワークライフバランスも過去最高です。
私は、「Be lazy」の回で書いた通り、「Be Lazy」を極めるために、「エッセンシャル思考」を実践しています。日本Microsoftは相当素晴らしい会社ですが、それでも、正直いうと、日本で「エッセンシャル思考」を実践すると、若干肩身が狭い思いをします。かといってこの人体実験をやめるつもりはありません。私の職業上の次のゴールは、「世界のどこでもご飯を食べられる様になること」だからです。
simplearchitect.hatenablog.com
一方、「Be Lazy」の考えを、チーム丸ごと受け入れてくれて実践しているお客様がいます。そうか、チーム丸ごとその考えを受け入れるならば、問題なくなるのかもしれない！
そう考えて、日本で、インターナショナル文化を実践する方法を考えてみました。なぜこのインターナショナルチーム文化が、快適なのか、どうしたらインストールできるのか？
私が考えた結果、今の所の仮説ですが、Microsoftの考えを受けて、私のチームのマネージャである「Damien」がこの素晴らしい文化を作ったのではないかと思っています。つまり、日本とかインターナショナルとか関係なく、「Damien」がやってくれたことを再現すれば同じ文化ができないだろうか？という思考実験です。
試したことはないので、効能はお約束できませんが、彼が私たちにやってくれたことを整理してみたいと思います。あなたがマネージャならこのようなチームを作ることができるかもしれません。
上下感覚がないチーム作り
実はDamienは私より年下です。しかし、そんなことは誰も気にしません。私のチームメートは大抵私よりずっと下だと思います。しかし、それも誰も気にしません。上も、下も気にしないのです。年齢だけではなくスキル、経験、それで、上だとか、下だとか誰も考えていないと思います。Damienの上司にあたる、Volkerも同じです。私が話すときも、偉い人と話しているという感じではなく全くの対等です。
きっと、サティアと喋ることになっても緊張もせず、「Hi」って言っちゃうと思います。しかし、日本にいると、偉い人に喋りかけてもいいんだろうか？とか考えている自分に気づきました。
どんな人でも、新人であっても、ベテランでも、社長でも、同じ仕事をする仲間です。やってることが違うだけで上とか下とかなく、上の人が下の人をコントロールするという感覚自体がありません。仕事は、Bossであっても、私たちに仕事を依頼するときは「お願い」モードです。例えそれが決まっている「月次週報」であっても。偉そうな人は見たことがありません。他の人に「教えてやる」とかそういうものもありません。全ての仕事がプル型です。誰か困った人がいたら主体的に助けを求めて、他の人が助ける。それだけです。
ボスの言うことが絶対というイメージもありません。ディスカッションもみんなで意見を遠慮なく言い合いますが一度もバトル的になったことはありません。ボスに決定権はありますが、それを振りかざす人はいません。
サーバントリーダーシップ
ボスが仕事を割り振って、「このよのような仕事をやり方をしなさい」と細かく指示していくやり方をマイクロマネージメントと言います。最近ではサーバントリーダーシップという、ボスが細かく指示をしていくというよりも、メンバーが与えられたミッションに対して、やり方を考える。それをボスがサポートしていくというリーダーシップの形態になっていると思われます。
Damienも本当にその通りです。チームとしてのゴールやミッションの共有はしっかりしてくれます。それは数値で書かれていて無理がなく、明確です。
そして私のゴール設定もかなり親身にやってくれます。私がそのゴールを達成するためにいろいろ困って彼に相談したらいろいろアドバイスをくれます。が、彼が私に「あれしろ、これしろ」と細かく指示することはありません。私の仕事の遂行を助けてくれるサポーターという面持ちです。また、彼は私に何かのデッドラインが近づくと、リマインドをしてくれたりします。彼は、誰かを見習えとかそんなしょーもないことも言いません。だから、全てのメンバーがそれぞれの個性を発揮して、それぞれイキイキいい仕事をしています。
またその上のVolkerも同じなのですが、自分が判断に困ったら、素直にチームに聞いてきます。チームでそこに知見がある人や意見を持っている人が彼らにアドバイスします。
だからと言ってチームメンバーは誰れも彼らのことを「頼りない」とは思っていない様子で、「素晴らしいマネジメントだ」と思っています。少なくとも私はそうだし、チームメンバーも彼らの悪口を言っているのを聞いたことがありません。
One on One ミーティング
Damien、そして、私の日本側のサポーターである Drew は One one One ミーティングを毎週30分やってくれます。私に共有したいことや、やってみたいことの相談、悩み事がなければすっと終わりますが、あれば、いろいろアドバイスをしてくれたり、助けてくれたりします。また、私が日本での、DevOps エバンジェリストに就任したときに、DevOps ハッカソンを実施しに、Davidと一緒に来てくれて、直接日本に来て過ごしてくれました。彼は他の国にも同じように行っているようです。そして、彼はみんなに「指示」をしたり、「いうことを聞かせよう」とする代わりに、メンバーを「理解」して「助けよう」としてくれるのです。
「Be Lazy」を推奨する空気作り
Damien そして、Drew、Volker、もちろん他のチームメートも同じですが、「Be Lazy」つまり、より少ない工数で、多くのバリューを出す考え方、たくさんの物量をするのではなく、「減らして、インパクトのあるものに集中する」考え方を良しとしています。だから、逆に残業とか休出とかをしていると、渋い顔をして「休暇をとろう。」と心の底から言ってくれます。楽にいい成果を達成することを発見したらみんなが喜んでくれます！「うまくやったな！今日はもうPubにでもにいこうぜ！」って。だれも「定時まではいないといけない」とか言い出しません。
simplearchitect.hatenablog.com
休暇を尊重する
休暇を尊重される空気も素晴らしいです。日本だと、仕事が終わっていないと休暇中でも「終わってないのだから仕事しなあかんやろ」とプレッシャーが来ることは珍しくありません。休暇をとりたかったら、それまでに終わらせておくことが求められます。 インターナショナルチームでは、休暇をとるということは本当に尊重されます。仕事が途中だから、と誰れも責められることはありません。
この前の話をしておきます。私はある記事を書きました。英語だったので、ネイティブのメンバーにレビューをお願いしました。レビューをしてくれる人が、私にコメントを求めてきたのですが、その翌日休暇で、他の仕事でいっぱいだったこともあり、コメントを返しませんでした。
休暇が開けた当日、その人のボスが私に「コメントを今日中にお願いします。」と珍しく催促してきました。流石にせっかくフォローしてあげているのに、全然レスポンスがこないし、ムッとしたのかもしれません。
私は「大変レスポンスが遅くなって申し訳ない。ここ直近休暇だったのです。今日やります。」と返しました。すると、「ありがとう。おお、そうやったんか。君が素敵な休日を楽しんだことを願ってるよ！」と帰ってきました。休暇の間に途中だからと言って、何かが求められることはまずありません。
（余程の大事件でもない限り、、、今まであったことはありませんが）
自分もそうですが、相手が休暇だったら、「あー休暇だったら仕方ないよね」と諦めます。社外の人であってもそのノリです。自分だってせっかく休暇しているのに、メールがバンバンやってきて対応に追われたら何しに来ているのか分からなくなります。休暇は貴重なものという認識のようです。
でも、チームでそういうことが推奨されていなかったらこのムードは作りにくいと思うので、チーム単位で作っていくといいかもしれませんね。
ダイバーシティの学習
前回の記事でもダイバーシティを取り上げましたが、Damien は２３カ国のメンバーをマネジメントしたことがあり、尚且つ、彼は２５カ国以上の文化や、商習慣を学んでいるらしいです。彼はそういうダイバーシティや相違を理解するべく努力をし、さらに、先に書いた通り実際に会いに行ったり一緒に仕事をして、チームを作っています。
simplearchitect.hatenablog.com
テクニカルエクセレンス
日本でマネージャというと、あまり技術ができない感じですが、彼は例えばChefのレシピは余裕でかけますし、ハックフェストも余裕でサポートします。彼に聞いてみました。「君は私よりずっと忙しいとおもうんやけど、どうやって技術をキープしているの？」彼は言いました。
「毎週金曜のPMは時間をブロックしてハックしているんだよ。」同じようにその上のVolkerも、DevOpsの技術やプロセスの話をしても通じなかったとか、話がわからないとかはありません。日本ではたまに「お前がしたかったら、俺に理解させてみろ」とか昔言われたこともありますが、そういうことはありません。DockerConに行ったときも、メールで懇親会の場所が送られてきたのですが彼がGitHubにアップロードした、Dockerfile を使って、Docker コンテナをデプロイしたら、懇親会の場所がわかるという仕掛けを作っていました。 :)
ただ、自分の知らないことに関しては素直に「知らないので教えてくれないか？」と言います。
ハッカソンを支援するDamien
「楽しんでいるか？」を確認する
Damienが私と One on One をするときに必ず聞いてくることは、「Tsuyoshi よ、仕事をエンジョイしているか？」彼は毎回そう聞いてきます。私の答えが No だったら、エンジョイできるようにいろいろ助けてくれます。
だから、うちのチームは、「仕事つまんねー」とか「なっとくいかねー」と言っているメンバーを見たことがありません。最初は気にしていませんでしたが、チームメンバーが「エンジョイしているか？」を確認するのはすごく生産性に貢献しているのかもしれません。
そして、そうすることで、仕事が「エンジョイしてなんぼ」なものとしてのムードを作ってくれているのかもしれません。 日本では仕事は「我慢してなんぼ」みたいなムードがありますが、誰だって、楽しく、エンジョイ出来ている方が、よりパワーを発揮できるのではないでしょうか？多分「我慢してなんぼ」の流れは、ボスが、他のメンバーを「指示してコントロール」していた頃の名残で、メンバーがゴールを与えられてそれをメンバーが個性を発揮して実施し、ボスがその達成を助けるというマネジメントスタイルでは、他の人に「いうことを聞かせる必要がない」ので、必要ないし、そもそも、エンジョイ出来ている方が少なくとも私は楽しいし、生産的な感じがしています。
おわりに
Damien は、私にとって今まで遭遇した中で最高のマネージャです。彼は自分の夢を語っていました。「私はいつかこのチームが世界で もっとも素晴らしいワークプレースだと言われるようにしたいんだ」私はこう答えました。
「少なくとも私にとっていまでもそうやで。Damien君はいままで出会った中で最高のマネージャだよ」
これは私が心のそこから思っている言葉です。私の視点でしかない記事ですが、少しでもなんらかのお役に立てれば嬉しく思います。
ダイバーシティの本質はそういうことじゃないんじゃないかな
いつも通り、生産性に関するブログを書こうと思ったのですが、その過程で、ダイバーシティについて少し調査しようと ブログや本をチェックして、とても違和感を感じました。そこで自分の意見を整理するために、ブログを書いてみました。
私は単にインターナショナルチームのメンバーであるだけで、専門家でもなんでもないので、稚拙で誤った意見かもしれませんが、それでも何か書いておくと自分の整理と学び（プロセスの改善のプロフェッショナルとして）になるかと思い筆をとってみました。
自分の感じるダイバーシティの違和感
私はインターナショナルチームで働いています。そして実際にその環境で働いていると、本当に楽しく快適に働けています。だから、その環境の素晴らしさと、その環境を日本でも実現する方法を考察するために、インターネットを調査してみました。
Microsoftはダイバーシティに非常に力をいれているので、必須教育でもダイバーシティの説明があったのですが、それは非常にためになる内容でとても楽しめました。
ところが、Amazonの日本語書籍 や、インターネットの日本語サイトを見ていると、ダイバーシティというと、女性の権利がどうこうとか、マイノリティや外国人の受け入れのために云々という言葉が並んでいます。そこに凄く違和感を感じました。
自分が何故、違和感を感じるかを考えてみると、「自分たちはマジョリティだけど、マイノリティを受け入れて、より生産性をあげよう」というノリを感じるからということに気づきました。
マジョリティ / マイノリティなど存在しない。
インターナショナルチームで働いたり、そうでなくても、例えば、ロンドンに語学留学をしてみるとわかりますが、インターナショナルな環境だと、マジョリティなどないし、常識などないのです。日本人は、開始時間に厳しいですが、国によっては、「遅刻しないと失礼。時間どうりのほうが失礼」という国もあります。
我々はいろんなものに知らず知らず「常識」をもっていて、勝手な価値観で「これぐらいは人として当然」思っています。これはある意味仕方がない事ですが、「すべての事が多様で違いがある事が当然」と考えることが重要だと思います。すべての人が、世界のコミュニティの「一部」にすぎず、マジョリティなどいません。
それは国籍の違い、人種、性別の違いだけではありません。人間は、すべての要素が違っていて当然という前提で考える事がダイバーシティのポイントじゃないでしょうか？
マイノリティの告白 ADHDである人生を生きる事
自分にとって、ダイバーシティが当然のごとく受け入れられているインターナショナルチームの環境は本当に楽しいです。何故かというと、どんな人でも受け入れられて、「自分以外の何か」になる事を要求されないからです。
私は、日本に帰ってくると「マイノリティ」です。私は医師にも診断された注意欠陥症候群(ADHD)という特性を持っています。 原因は不明ですが、現在では前頭葉が不活性で、短期記憶が少ないため、集中力が続かなかったり、自分に興味がないことが一切できないため、記憶力が乏しく、例えば銀行振込、事務処理、片付け、調整作業などが大変苦手です。また、集中力がないため、何をやっても、完成しません。だから自尊心はズタズタで、自分はなんてダメなんだろうといつも思っていました。
人の心をおもんばかることも苦手です。なぜなら作業がいつもバタバタで、そんな余裕がないからです。それがさらに自分の自尊心をズタズタにしてきました。
日本だと普通の人は「大人ならそれぐらいできて当然」と思われることが、全然できません。実際にやろうとすると人の３倍ぐらいかかるし、できても普通の人より雑だったりします。そういう人は日本の社会では、「いいかげんで、だらしない人」というクラスターになるので、社会生活が非常に辛いものになります。
だから、私は「作業」を「完成」させないといけない２０代は全く活躍できず、「思考力」や「発想力」が重要になってくる３０代以降はなんとか仕事ができるようになりました。しかし、最終的に自分で会社をやっていたのは、会社で「社会人としてこうなるべき」というストレスに耐えられなかったのかもしれません。
リタリンを服用した時の衝撃
私の転機はあるインターネットの記事で、「自分がADHDである」という事がわかったことです。
実際に専門医師の元に行き、診断を受けて、リタリンという処方された薬を飲んだ時の衝撃は今でも忘れられません。部屋や机が生まれてから片付いた事がありませんでしたが、薬を飲んだら、なんと、自分が知らず知らずに片付けているのです。机の線に、置いているものの線がずれていると気になりました。
ヴォーカルをやっていましたが、今までできなかったコーラスを耳コピするのも一瞬でできました。
「ああ、これが、普通のいや、集中力がある人の気持ちなのだな」と思いました。こういう人からすると、私は相当いい加減にしかみえないでしょう。「なんで、こんな簡単な事ができないんだ？やる気がないからだろう」と。
しかし、同時にこうも思いました。薬を飲む程のことで、こんなに違うんだ。「自分がいい加減なのでもなく、ダメなわけでもないんだ。」この事がわかってから、自分ができない事を諦める事を覚えました。だから自分への罪悪感みたいなものも少なくなりました。私は多分生来的にポジティブな性格だったと思うのですが、自分自身を傷つけてきたため、当時はネガティブな性格でしたが、今は相当ポジティブだと思います。:)
しかも、ADHDには先に書いた様なマイナスがありますが、人が見つけにくい関連を発見しやすかったり、発想力があるといういい特徴もあるようです。
しかし、日本の社会で、生きていると、そういったいわゆる「大人の行動」をする必要があるので、様々な手法で、ADHDの症状を軽減するために 努力してきました。リタリンの効きは最高でしたが、薬なので徐々に効きが悪くなってきました。
ところが、「整理力がある状態」というのを「認識」できたので、それだけでも以前と相当違う感じになってきました。 その後、私が有効だった方法を共有しておくと、Lumosity という脳トレのようなゲームで、短期記憶を徹底的に鍛えるようにする と、ゲームを継続してやっているとかなり症状が軽減できました。
最近知ったのですが、「オメガ３」のサプリメントを飲むと、私のような短期記憶に問題のある人には非常に有効なようで、 かなり作業ができるようになってきました。それはワーキングメモリという参考文献に乗っていたのでそれをそのままやってみました。他にもランニングなども効果がある様です。
Lumosity (ルモシティ) - 脳トレ｜あなたの脳の可能性を見つけましょう - Lumosity
脱線しましたが、正直にお話すると、私は日本社会で常に生きづらさを感じていたのです。そして、日本社会で生きて行く限り、上記のような 「自分が自分以外になる」という行動が求められるのです。
インターナショナルチームは居心地が最高
久しぶりに「会社勤め」を始めた先は、Microsoftのインターナショナルチーム。英語での仕事は生まれて初めてでした。 相当ストレスフルなはずですが、私自身は、非常に居心地が良いと感じていました。
自分が苦手なはずの事務処理系の仕事ですが、チームでも平均すると私の方がちゃんとできるぐらいの勢いです。みんなが得意なことも苦手なこともバラバラです。会議に真面目に出る人もいればほぼでない人もいます。それでも誰れも何もいいませんし、減点される雰囲気もありません。
私がいろいろ忘れて何回か同じ事を上司のDamienに聞いても、彼は喜んで教えてくれます。
ネイティブの英語スピーカーと喋るときも、私や同僚が理解できてなくても、英語勉強不足とか言い出す人はいません。言葉が通じないのが前提なので色んな手を使って「コミュニケーション」を達成しようと、こちらも、向こうも頑張るからです。
日本では「ダメ人間」の烙印のADHDも、文化も、年齢も、国も、考え方も、得意分野もすべて違う人が集まってるのが前提なのでそれが「違う」とすら 認識しません。だから、「君はこうあるべき」「君はこうすべき」などと言われた事がありません。
例えば、Drew に対して DevOps インタビューという記事を英語で書くのが大変な時に相談したら、彼は英語力を上げるアドバイスをするのではなく、「お金を払って誰かにやってもらえるように調整しよう」といったアドバイスをくれました。
他の人も同じですが「自分を変える、鍛えて違うものになる」ことをアドバイスされることがありません。仕事も、ごく少ない仕事以外は、できなければやらなくてよくて、それをだれもととやかくいいません。早く帰っても誰れもなにもいいません。
いい仕事ができてみんなにシェアしたら、みんな「おめでとう！」って褒めてくれます。そして、他の人がうまくいったら自分もうれしくなって「おめでとう！」といいます。仕事をしていても、基本KPIで定められた仕事を達成する方法を自分で考えるので、他の人から頼まれることは、基本「すべきこと」ではなくて、「助けてあげている」ということになります。だから断っても誰れもそれでとやかく言われることもありませんし、助けてあげたら、とても喜んでくれます。
ここで自分は生まれて初めて、「自分が受け入れてもらえている」感を受けました。
イギリスで友達の家に泊まった時の事
先日休暇で久々にイギリスに行ってきました。そこで友達の家に泊めてもらったのですが、その友達の彼氏のお宅でした。友達に私のADHDの事を話すと、友達は「あーわたしもそうかもしれない」といいました。彼氏がやってきて、そのことをシェアすると彼は
「ADHDってもっと凄いよ。君たちは全然ちゃうから」
あー、そうか、自分は日本ではそうだけど、（ダイバーシティが当然な）イギリスだと、ADHDですらないのか、、、と実感しました。日本では息苦しいかもしれないけど、世界にでたら、自分の「差異」なんてないに等しいんだなと。
ダイバーシティが産む生産性
ちょっと横道にそれましたが、ダイバーシティのある環境では、「人と、人はすべての面において違っていて当然」人とコミュニケーションする時も「つたわらなくて当然」が前提になりましす。誰も、「前にいったよね？」とか、「メールで送ったのに見てないの？」とか言われません。
ましてや、「大人なんだから、察しないとね」とかいうことも存在しません。同調圧力とか何それ？という感じです。
年齢や、職種、職位によって、「えらい・えらくない」という感覚もなく、全くのフラットな感じです。単なるロールの違いです。みんな違うから、違いを尊重して、自分ができることをやって、自分ができないことを人に助けてもらうそのような感覚になります。
つまり、人と、人の間に共通点が全く、母国語も違うので、コミュニケーション自体が難しいので、コミュニケーションに前提がなく、明確で、単純です。いろんな事を「深読み」とかしなくてもよくて、失礼にあたるとか、めんどくさいことも考える必要もなく、向こうが表現したことをそのまま受け取ってコミュニケーションをすればいいのです。
また、コミュニケーションが元来難しいものという前提なので、すべての決定がロジカルです。誰もが合意できる「ロジック」という共通言語がないと、誰も納得感ある状態が作れないからなのかもしれません。だから、日本のように「政治」や「寝業」とかの入り込む隙がなく、誰もが納得感のある「ロジック」で物事が進むので、日本にいるときより、圧倒的に納得感があるのです。
日本では、「空気を読む」ことや、言葉の意味がそのままとは限らないので、何かを推進しようとしたら、正攻法では難しくて、じっと我慢してランクを上げるか、力を持った人に接触するなど本来の業務的な能力以外の能力がないと難しいので、そういうのが得意な人が力を持つことも多くありますが、インターナショナルチームでは、そんな人はいません。ロジックで物事が進み、めんどくさいことがないので、そこに力を使う必要がありません。
自分の専門分野に注力して、腕を磨けばいいのです。マネージャはマネジメントを、プログラマはプログラミングを。そして、そういう専門的なことがしっかりできる人が尊敬されます。 日本では重要な「おもんばかる」ということも必要ありません。みんな基本的に、チームではありますが、一人一人が独立を基本として明確に数値で定義されたKPIを持ってそれの実行を求められているだけなので、それ以外のことは要求されません。「これぐらいはやって当然だろう」という暗黙の話などもありません。おもんばかるに近いのですが日本人の「相手を優先し思いやる」という感覚はある意味美しいのですが、仕事においては鏡の法則が発動され、「これぐらいやってくれて当然」という空気を作ってしまうこともよくあります。そういう変な「深読み」は必要ありませんのでシンプルです。
実力主義の意味
日本で「実力主義」というと、凄い数字で縛られてしんどいイメージがありますが、インターナショナルチームにいるとそういうイメージではありません。
KPIは楽に達成できる納得感のある数値になっています。評価は、仕事の成果や実力の反映されるKPIで評価されます。「政治」は一切する必要がありません。
だから技術チームのマネージャなのに、技術の話をしても通じない人やBossyな人や今時マイクロマネージメントな人なども今のところあったことがありません。（多分マネジメントを勉強していない無能な人ということでクビになるのかと思います。）
だから、実力主義といっても、普通に積み重ねて努力している人には何も恐れることはない環境なのです。普通に努力していれば、普通に評価されるフェアな世界で、やり方の違いとか、考え方の違いとか、そういうのは違っていて当然なので、だれもとやかくいいません。
また、「クオリティ」は求められますが「挑戦」には開いています。だから何かにチャレンジした時に失敗したからどうこうというのは一切ありません。誰でも平等にチャレンジできますが、「基準」に到達していなければ、誰でも合格はしません。例えば、何歳までとかよくわからない基準はないので、何回でもチャレンジできますし、自分に不足しているものがあれば、例えば大学にいって学んでくれば単純に「基準」に達成できる感じなので不公平感はありません。そこに達成するのに、どの程度早いか、遅いかとかも、特に気にされません。シンプルな世界です。
私はそういうところが気に入っているのかもしれません。だから、「人はこうであるべき！」と思いが強い人にとっては、とてもストレスフルな環境かもしれません。
ダイバーシティが 楽しく生産的な職場を産む
私はこのダイバーシティが当然である職場の楽しさを伝えたいと思ってこのブログを書きました。誰れも自分が「マイノリティ」だとも「受け入れられない」とも感じないこの快適さを。そして、フェアな環境で、純粋に「仕事を楽しんで、自分の成果を出す」ことを求めれる環境を。
様々な統計が、ダイバーシティあるチームが生産性が高いことを示しています。私はなぜだか知りませんが、単一の集団だけだと、同じ様な特性があるから、弱点をカバーし合えないからでしょうか？私はまったくその辺の知識がありませんし、自分の勝手な想像でしかない浅はかな考えですが「人のコミュニケーションは難しい」からではないでしょうか？
どうしても同一グループだと「常識」や「伝わって当然」という「暗黙の想定」があります。それが、ダイバーシティのある環境だとその根底が崩れ、全員が、「常識や暗黙の了解はない」という世界でわかりやすく、伝わるまで、シンプルにコミュニケーションしようと頑張ります。そして、誰れもがわかる「ロジック」で共通認識をもち、思考をします。ダイバーシティある環境では、私は「社会人失格」ではなく、「発想力のある人」として、チームに貢献することが出来ています。
単一の集団と思い込んでいる人々も、本来は、伝わったと思っても、本当は伝わっていないのではないでしょうか？それは難しいことなのではないでしょうか？ だから、ダイバーシティの環境でそれが崩れることで、本来の「効率的なコミュニケーション」について必死で考えて実践するから、生産性が向上するのではないでしょうか？
私はダイバーシティが当然の社会が日本にも来てほしいと思っています。いつになるかはわかりませんが、誰も「変わってる」とか、「外国人」とか言われることのない社会に。
マーチンルーサーキングの言った世界、それ以上の世界が、ロンドンには存在しました。その様な世界では、みんなが「同じであること」に気を使う世界ではなく「違うことを尊重する」ということに気を使う世界です。アメリカでも、その感覚は相当に進んでいる様に感じます。私の大好きなgleeというTVドラマを見ていてもそれを感じます。
きっと日本が移民を受け入れたら少しづつ変わってくるのでしょうか？それとも、グローバルな仕事をしている会社がそういう世界を少しづつ変えていってくれるのでしょうか？
自分は、このダイバーシティの楽しさをみんなに伝えることで、少しでも貢献したいと思っています。自分がそうなってほしいから。
DevOps ハッカソンは日本で通用したのか？ 〜ハッカソン運営での学びと中の人〜
私は入社以来、月1回以上のペースで、DevOps ハッカソンという無料イベントを実施しています。
DevOps が学べて、関連技術を自由にハックして楽しめるイベントです。マイクロソフトが、DevOps を広く普及させて将来DevOps の良い事例になってくれるお客様を探すことを目的としています。マイクロソフトというとWindowsみたいなイメージがありますが、このハッカソンはそういった縛りはありません。Azureを使っていただくことと、 Visual Studio Team Services という Git / Kanban / Build(CI) / Release Management / Testingみたいなのが便利にできる SaaSサービスをちょっとだけでいいので使っていただくこと、DevOpsプラクティス (例えばInfrastructure as Code)をどんな技術を使ってもいいので、実装するという条件です。
だから、Linux でも、Docker でも HashiCorp でも技術は好きな物を使って楽しんでもらえればいいイベント になっています。もちろんMSのフルスタックで決めていただいても問題ありません。
実際何回も開催しているとだんだんとコツがわかってくるものです。Microsoftでは、NSATという顧客満足度の指標が あるのですが、この数値もFESTやde:codeの最高レベルぐらいの点数を稼ぐことができています。（もちろん、プレゼン とハッカソンという違いはあるので、一概に比較できませんが）きっと少なくとも、来ていただいた人には体感的にも とても喜んでいただいているようです。
正直に言うと、これは私の努力ではありません。私をサポートしてくれている人が素晴らしいのです。 だから日頃からの感謝を込めて、その内情を正直にお話させていただきます。
DevOps ハッカソン上陸の経緯
私がマイクロソフトに入社したのは、昨年の8月になります。入社した当時最も重要な私の仕事はこの DevOps ハッカソンでした。私は結構チャレンジャー体質かつ、不器用なので「失敗は学ぶチャンス！」と考えています。ですので、「もちろんやるよ〜」と上司に言いました。しかし、正直に言うと、上手くいく確信など何もありませんでした。「最初は失敗して学ぶかな」ぐらいに思っていました。
私の上司はフランスに住んでいるフランス人です。エンタープライズの技術者がメインのターゲットと言っていましたが、少なくとも当時は、日本のエンタープライズの人がハッカソンに参加してくれるイメージがありませんでした。もちろんイベントとしてはスタートアップ系の皆さんも大歓迎です。日本へDevOpsを広める為のイベントという目的がありますので、楽しんでいただければどなたでも大歓迎です。
当時、開催まで３週間ぐらいしかありませんでした。私はマイクロソフトに入りたてで、「Azure とか全然しらんしどうするんよ？そもそも集客大変ちゃうか？」と思っていました。しかし、なんでもやろうと思えばなんとかなるものです。
初回は David という向こうのトップの DevOps エバンジェリストが来てくれることになっていました。本来それは私にやり方を伝えるためなのですが、私たちは、彼がガチハンサムということもあり、「DevOps プリンス」と名前をつけて、「外タレきますよ！」的なノリで宣伝させていただいた。もちろん、個別で自分の知り合いに直接アタックして、DevOps 好きそうな人に声をかけました。
通常のMSのルートじゃない、connpass なども活用して、日英両方でアタックすることで、第一回はかなり盛況で終えることができました。
超絶優秀なマーケティングマネージャが活躍
実は私のポジション（米マイクロソフトのDevOpsエバンジェリスト) は「RG」と内部でよばれているポジションで、マイクロソフトがある技術に力を入れたいときに、３年ぐらい一時的にできるポジションです。過去には Azureのエバとして、尊敬する佐藤(NEO)直生さんや増渕大輔さんが、このポジションにいました。そういう重要なポジションなので、だからきっと凄く優秀な人をアサインしてくれたのだと思います。
今もDevOps のマーケティングは秋山さんという人が担当しています。初回から、今まで変わらず超優秀です。彼女はこのタイミングを逃さず、完璧にプレスの各社にリークをしてしっかり記事にすることをしかけました。
おかげさまで今回話題になっている de:code も彼女が活躍が裏にあります。さらに素晴らしいのが、この初回の成功を一瞬でシンプルで楽しめるレポートにまとめ、本社側のマーケティングやエバンジェリストに共有して、素晴らしい評価を受けたことです。 本社側は、日本市場は相当やりにくい場所と思っていたらしく、とても喜んでもらえたようでした。後に本社から、日本のDevOps ハッカソンはうまくいっているということで、視察が来ることになります。
simplearchitect.hatenablog.com
正直私はエバンジェリストとしては相当「ひよこちゃん」です。人前に出るから目立つけど、「アイコン」みたいなもので、実際の成功のエンジンは彼女なのです。彼女は、その他の細かい手配、アレンジなども完璧です。
視察に来た本社メンバと日本メンバ
ただ、一回目の課題としては、Azure や Visual Sutdio Team Services のセットアップで、混乱し、初日のハックがスムースにいかなかったことがありました。
第二回目からが勝負のタイミング
私は１回目は David がきてくれるのだから、集客さえできればある程度上手くいくのは当然と思っていました。問題は二回目です。 1回目はエッジな人が来てくれました。ですので、ハッカソンという形態も大丈夫でしたが、2回目からはそうとは限りません。
いろいろなレベルの人が来てくれる。そして、Davidはいない。MS入社２ヶ月の私は対応できるだろうか？
私はアジャイルコンサルタントだったので、DevOps のプロセスや考え方、プラクティスに関しては得意分野です。そして、OSSのIaCも大丈夫なところ。問題は、Azure や Visual Studio Team Services だ。さすがにマスターするには時間はありませんでした。
もちろん、自分でデモを作ったり、ランスルーをしてみたりはしているが、ハックを支援できるほどできるだろうか？
ここでも、先の秋山氏がファインプレーを見せました。彼女は、ハッカソンの立案をするだけではなく、他のテクニカルエバンジェリストに適切に助けを求めるだけではなく、ハッカソンごとに、誰が支援するかのアレンジを行って、支援が薄いところは、調整をして、適切なサポートを得られるようにしてくれた。もちろん会場の手配も同じだ。むっちゃ美味しいお弁当や、お菓子もしっかり用意して、みんなが楽しめる雰囲気を巧みに演出してくれました。
無限の守備範囲を持つ神エバンジェリストが支援
私は DevOps といっても、プロセスが最も強く、技術力はスーパー高くない。技術は アジャイル系技術、IaC やコンテナなどの技術は得意な方ですが、ITPro系は経験がありません。（私の所属はITPro - Japanなのだがw) DevOps 系の技術に強いエバといえば高添さんが有名だが、彼はご存知の通り超絶売れっ子です。どうしたものか、、、と考えていたら、秋山さんがまたもやファインプレーをして、エバンジェリストの小塚さんをこのタスクにアサインしてくれました。
吉田パクえさんと小塚さん
彼ははっきり言って超絶優秀。そして無限の守備範囲。VSTSから、Azure、OSのディープなところから、Azure Stack、コンテナ、PowerBI、Office 思いつく限り殆どの分野をカバーする超人なのだ。(ちなみに、たくさんできるが本人は、OSとかのディープな部分が好きらしい。高添さんがやっている分野をやってるのが楽しそう。彼は高添さんのサポートと兼務) 実際、彼は優秀すぎて、いろんなエバンジェリストから引っ張りだこになってしまうので、秋山さんがいろんなエバから要求される彼のアサインをブロックしていた。
彼の才能はそれだけではなく、こういったイベントの運営も完璧なプロフェッショナル。彼はパフォーマンスネックあったときのために、予備のWifiを準備していたり、初回に混乱を招いたVSTS/Azureの導入手順、審査のためのプレゼンテーションのテンプレートから、会場の案内まで完璧にこなした。正直雑な私では到底できないことだ。彼の才能は神がかっている。
DevOps T-シャツ登場
さらに、このイベントを盛り上げるべく、秋山さんが、密かに発注してたのが、DevOps T-シャツだ。背面の毛筆は書道家の友人に書いてもらったらしい。DevとOps が協力して、ソフトウェアのライフサイクルを改善するDevOpsのコンセプトのごとく、DevとOpsのT-シャツを作成した。これはとても喜んでもらえて、海外の同僚もとても羨ましがっている様子だった！参加者はこのDevOps T-シャツがもらえることになっている（現在のところ。在庫切れ後は秋山さんのアイデア次第w）このハッカソンのあと、ハックフェストという別イベントをやったときもわざわざ来てくれて人もいてなかなか嬉しいものだ。
エンタープライズにハッカソンは通用したか？
私が得意のプロセス、プラクティス、アジャイル系技術のデモを行い、秋山さんが私の足りない技術を持ったエバンジェリストを集め、小塚さんが、最高の運営と、高度な技術で参加者の皆さんの問題をガンガンに解決していった。やはり想定した通り特にエンタープライズ系やSI系の方はハッカソンが初めてで、参加に躊躇したとおっしゃっておられる方多くいました。
ハッカソンはすごい技術力が無いと来れないみたいなイメージがあります。
しかし、終わってみると、殆どの方は、「来て良かった」「楽しかった」と言っていただけてほっと一安心です。さすがに、プログラミングが出来る、もしくは、インフラ構築や運用したことがあるとか、そういう基礎的なスキルは必要ですが、エッジでないと楽しめないとかではないので、お気軽に参加されたら楽しんでいただけると思います。
エッジな方はエッジな方で、いろいろな技術をハックできて楽しんでいただけている様子です。大体チームは、毎回マイクロソフト系と、オープンソース系のチームが半々ぐらいになることが多くて、秋山さんのファインプレーもあり、DevとOps を別サイトで募集しているので、Devが8割何てことはこのハッカソンに関しては存在しません。だから、どのチームも、DevとOps が一緒のチームになります。だから、普段体験でき無い、DevとOpsが一緒になって一つのチームでコミュニケーションをとりながら作業をするという体験が得られて喜んでいただけている様子です。 技術に関してもOSSだとDockerやChef、DockerCloud、Jenkins、Slack + Hubot などは人気が高いです。中にはMesosやAzure Container Servicesを実施した人もいます。MS系で固めるチームは、.NET - VSTS - WebApps - SQL serviceの構成で、CI / CD / Release Management を決めて、さらに PowerBI や Application Insight で可視化して、Iacは、 Azure Resource Manager を使ってキメるというパターンが多くありました。
いつもびっくりしますが、たった二日で、CI / CD / Release Management までがっつり自動化したり、ブルーグリーン やロールバックを実装したり、負荷テストを決めたり、監視までうまく回したり、いつもびっくりさせられます。レベルは関係なく 皆さん、みなさんになりに役割分担して、楽しんでいただけているようです。日本でハッカソンなんてできるだろうか？と 思っていましたが、本当にやってみて良かったです。
先日福岡のチームは、このハッカソンで作ったソリューション（Minecraft のサーバーをプロビジョンするサービス）を立ち上げて、GitHub に公開してくれました。そして、このチームは、Dev x Ops だけではなく、デザイナーもいました。もちろん優勝です。
尚、このハッカソンでは、商品のためにハックして欲しくないので、優勝チームは決めますが特に豪華景品はありません。弁当は美味しいですが。
### DevOps ハッカソンの効能
観察してみると、通常のプレゼンテーションやハンズオンと比べて、ハッカソンはどういう効果があるでしょうか？実はマイクロソフト の社内の教育でも、近年では必ずハッカソンのイベントがあります。私も社内イベントがあるのですが、そこでもハッカソンに参加して きました。マイクロソフトでは、スキルレベルを四段階に定義しています。100, 200, 300, 400 のレベルです。100は知ってるレベル 200 は使えるレベル、300 はコードを含む深いレベル 400 がハッカソン主催とかのレベルです。社内のハッカソンに出れば、自動的に その分野で200のレベルを獲得することができます。
Redmond で行われた MS 社内ハッカソンの様子
何かの技術を習得したいときに、プレゼンだけだと、聞いて満足して終わりというパターンが多いでしょう。デモを見てもある意味わかったきになるだけで、実際にできるとは別問題です。その点ハンズオンはいい感じですが、「失敗」がないので理解が浅くてもなんとかなります。
ハッカソンは違います。明確なゴールや目的があり、最初から「応用」を目指して考える必要があります。だから、理解せずできるものではありません。そしていいのは必ず、チームメートがいますし、エバンジェリストやスペシャルゲストがいるので「聞ける」のです。
しかも、懇切丁寧に教えてくれたり、一緒にペアプログラミングまでしてくれたりもします。
何かをマスターするときに、達人の人に聞いて、一緒にやることほど最速で本質がわかる方法はありません。自分で実感していますが、これは最強です。
私も昔は教育コースに出たら分厚い資料をもらってありがたがっていましたが、今から考えると、それを見返すことはどれぐらいあったかな？と思います。自分が「実際できるようになる」ことこそが最高の宝だと思います！そして、何より技術ハックが楽しいものだ！とうまくいってもうまくいかなくても、新しい技術に触れたり試せたり、それをディスカッションするのは最高に楽しいことですね！ ちなみに、主催する側も空き時間が発生するケースがあって、その時はハックを楽しんでいます。もちろん質問があって、参加者の皆さんとハックするのも非常に楽しいですし、勉強にもなっています。本番で対面する「課題」は、決してハンズオンでは体験できません！
それ以外にも、DevOps という要素が大きいです。DevOps という概念は、ソフトウェアライフサイクルの改善を実施するので、範囲が大変広いのです。それとプラクティス、ツール、マインドセットまであるので、これを座学で学ぶのは相当難しいでしょう。しかし、ハッカソンなら概念を理解したのち、本番に程なく近い状態で体験できます。そのため、かなり効率よく理解できると思います。当初は懐疑的でしたが私も、ハッカソンは日本でも、エンタープライズ系でも有効という確信が得られました。
DevOps で使われるツールセット。多すぎっす
後はどうやってみんなに知ってもらうかが課題です。このブログポストもその一つの手段です。無料ですし、マイクロソフトのロックインもないですし、DevOps を広める楽しいものですので、是非広めるのにご協力いただければと思います。
DevOps ハッカソンの改善
実は安定したハッカソンを提供できるためには、いろいろ施策を打っています。秋山さん、小塚さんが完璧に支援してくれていることもありますが、私たちは毎回振り返りをして、改善点と解決策を考えたり、いろいろ手を変え品を変えて、A/Bテストみたいなことをやったりもしています。休日に開催してみたり、平日にしてみたり、品川のマイクロソフトでやってみたり、渋谷の.dots でやってみたり、Java User Groupでやってみたり、ゲストを呼んでみたり。様々です。私のパートも、一人でやったり、小塚さんと分担してみたり、ゲストを加えてみたりと様々なトライをして、その実践から学んで改善をかけています。
大きな傾向としては、平日はよりエンタープライズ色が濃くなる傾向にあるようです。休日の場合の方はオープンソース色、サービス、スタートアップ色が若干濃くなります。ただし、これは、色という程度で、味見程度です。 地方は、大阪、福岡、札幌と実施しましたが、集客に苦労しました。来ていただいた皆さんには楽しんでいただいたようですが、今後も継続して開催するためには、どのように地方で集客するかは大きな課題です。やはり、「ハッカソン」というハードルがまだ高いのかもしれません。
このままでは、地方開催は福岡を除いて厳しい状況になるかもしれません。是非いいアイデアや、ご支援などありましたらコメントいただければと思います。
DevOps ハッカソンの満足度を高めるポイント
さて、様々なテストや試行を繰り返して、現在のところの DevOps ハッカソンの満足度をあげる為の必殺パターンを共有させていただきます。 コンテンツはもちろんあるのですが、「安定した運営」です。DevOps だとネットワークの帯域を消費しますので、しょぼいWifi環境だと相当ストレスになります。ですので、Wifiの帯域はかなり気を使っています。Azure のセットアップや、VSTSのセットアップで、苦労すると、本来のハックが楽しめません。そういう部分をスムースにするのも大変重要です。
次に、オーバービューと、具体的な技術の解説の両方という要素があります。私がするトークやデモはあくまでDevOps の概念やプラクティスを理解するためのオーバービューになっています。それだけにしてしまうと、満足度が落ちることがわかりました。私と小塚さんで２人で担当して同じことをしても、私一人でやる時よりスコアは良い傾向にありました。そこで、１人より２人でやる方がいいことを学びました。
何回か実施して観察してみると特定の回の満足度が高いことがわかりました。それは概要をお話したのち、何か一つのとんがった技術を解説するスペシャルセッションを設けた回が常に非常に高い満足度を得ていることがわかりました。
それをヒントに今は、概要と、詳細の技術を解説したスペシャルセッションを実施する形態にしています。その学びを得た後は毎回満足度が高い状態をキープできています。ちなみにスペシャルゲストがいた回の内訳は次のようになっています。
おそらく、DevOps の場合、概念だけだと、ふわっとしていますし、技術だけだと、腹落ち感がないので、両方をうまくミックスさせて、概念、オーバービューと、詳細な尖った面白い技術 というコンビネーションが良いようです。
- Jug CCC スペシャル: Java エバンジェリスト 寺田が、JenkinsやDocker / Tutum を解説
- Dockerスペシャル : 吉田パクえさんがDocker解説そして、真壁さんと共にサポート
- Chefスペシャル : Chef社から Andrewが来日して通訳付きで、解説とサポート
- Doker / HashiCorpスペシャル: Creationline社の前佛さんが Docker やHashiCorpの解説とサポート
- 地方開催スペシャル : 自動化マスター安納さん、松崎さんのコンビでARM解説とサポート
一般的なプレゼンテーションやハンズオンに比べてスコアが高いのは、秋山さんの努力があり、スペシャルゲスト以外にもテクニカルエバンジェリストが合計４名ほどいる分厚いサポート体制が効いていると思います。そして、何より「ハック」を自分で実施する楽しさが大きいと思います。
自分でハックして、むっちゃ詳しい人に簡単に聞けるのは本当に楽しいことです。それは、チーム内でもあり、サポート陣でもあります。普段交流をあまりしない Dev / Ops そして、他の会社の皆さんと交流するのもいろいろ刺激があって楽しいのかもしれません。
Ruby好きのOSSエンジニアがAzureアーキテクトになった理由 - ZDNet Japanより
スペシャルの回も、吉田パクえさんの回が非常にスコアが高かったため、そこからいろいろ学ばせていただいて、その後の運営に多大な影響を与えてもらっています。
ちなみに、スペシャルの回であっても、それと違う技術でハックしてもまったく問題ないので、MS系技術の人でも、OSS系技術の人でも皆さん楽しんでいただけます。
この DevOps ハッカソンは上記でお話した通り、いろんな皆さんのおかげで非常に高い満足度をいただいています。私はほんま踊ってる程度なのですが、運営の裏でこんなたくさんの人が活躍していただいているのです。
次回以降のアイデアベースのお話。
５月に関しては、DevOps ハッカソンは実施しません。de:code に集中させていただきます。de:code ではDevOps系の 強烈ゲストと、それに対抗するMS技術のDevOpsを楽しんでいただきます。
６月以降のアイデアですが、次のような思いつきがあります。どれをやるか決めていません。是非これ実現してほしい！というのがありましたら、是非ともお気軽にコメントいただければと思います！ では、今後とも、DevOps ハッカソン １ヶ月に１回ペースで実施していきますので、よろしくお願いいたします！ ちなみに、ここで書いていあるのはジャストアイデアであり、本人たちにもまだ開催可能か聞いていませんw ですが、コメントがいろいろつけば、その後押しになるような気がします。
- マイクロサービス監訳 佐藤(NEO) 直生氏をゲストにした「マイクロサービス」スペシャル！
- Xamarin エバンジェリスト兼漫画家 ちょまど氏をゲストにした Xamarin Mobile DevOps スペシャル！
- 高添・小塚ペア Windows コンテナ / Service Fabric スペシャル！
- Docker 日本唯一の公認トレーナー 前佛氏をゲストにした「Docker / HashiCorp」 スペシャル！
- 高添・小塚・安納・前佛さん Ops技術中心！ DevOps スペシャル （OSS、MSの両方のOps技術にフォーカスを当てた回）
- 安納・松崎ペア ARM自動化＆MS技術でDevOps スペシャル！
- Microsoft Bot Framework x Cortana スペシャル! ChatOps の先を行け！
- Microsoft IoT x DevOps スペシャル！
などなど、他にこんなのしてほしいとかありましたら是非ともコメントいただければと思います！
次回の 4/15,16 DevOps ハッカソン
折角なので次回の宣伝をさせてください。次回は 4/15, 16 の金土どいう新たなパターンで実施させていただきます。必勝パターンに則って、今回も「Chefスペシャル」と銘打ってお届けします。Chef を日本にインストールしてきた問いっても過言ではないクリエーションラインさんがその中でも特にスペシャリストである荒井さんがきてお話をしてくれます。しかも、緊急参戦で、Chef社からAlex Vinyar氏が参戦してくれます。彼がサポートした顧客は、IBM, GE, HP, Rakuten, Yahoo, Bloomberg といった超一流どころばかり。これはChef に興味がある人はこんな機会は滅多にないかと思われます。また、Chef x Azure の組み合わせに興味がある人も見逃せない回になりそうですね！
今回も凄いゲストが参戦していただいて、本当に嬉しいです！
Alex Vinyar
I am an Automation Consultant with Chef (Opscode). I help companies get started with the DevOps journey by working with management team to create a roadmap, assessing current state of the organizaton and DevOps readiness, and leading teams in the early stages of implementation. Presently I am in Japan until August to supporting Chef in the APAC region. Some of the companies I've helped: GE Capital,HP,IBM,Microsoft,Rakuten,Yahoo,Walgreens,Bloomberg,etc.
荒井 裕貴
クリエーションライン株式会社のChefエンジニア 前職ではネットワークの運用保守業務をしながら、ネットワークの管理自動化WEBシステムの開発等を行っていた。 クリエーションラインではChefを担当しており、コミュニティーでの講演やChefのトレーニング、COOKBOOK開発等を行っている。 趣味はガンプラと熱帯魚。
「Be Lazy」を極めるためには残業をしてはいけない
「Be Lazy」というのは、日本側の上司にあたる Drew がいつも口にしている言葉だ。その意味合いは、「最小の工数で、最大のインパクトを出す」 という考え方だ。私もアジャイルやリーンを学んできたので、「大量のものを高速に作れること」はむしろ悪であり、いかに「作らなくていいか」を考えてインパクトの出るものにエネルギーをフォーカスするのが重要と思っている。
しかし、正直に言うと、それは、日本人の感覚からいうと最も縁遠い感覚だ。私がなぜ「Be Lazy」を極めたいと思っているか？というと、インターナショナル チームの同僚は仕事で成果をガッツリ出すのも尊敬に値するが、仕事をしている様子も実に楽しそうだ。誰も苦しそうだったり、我慢したりしていない。
仕事は楽しむものと言っていて、「我慢するべきもの」という日本側の空気とは相当違う。私は自分も人生や仕事を楽しみたいし、多くの人がそうなったらいいのにな！と思うので、その謎を解明したいのだ。
私は今もBe Lazy」を身につけるため試行錯誤しているが、気づいた内容をシェアしていきたい。
Be Lazy 思考を感じた出来事
少し前のエントリで、「日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む」というエントリを書いた。ここで、海外の人は、すごく沢山の仕事をこなしているわけではなく、そもそもこなしている物量が少ないという話を書いた。 インターナショナルチームで仕事をするときは、同じ仕事をするにしても、日本と比べて物量が圧倒的に少ない。レポートもそうだし、報告会もそうだそもそも、報告会自体あったっけ？という感じだ。
simplearchitect.hatenablog.com
この前も「Be Lazy」思考の良い事例があった。あるお客様のところで、私の専門外のハンズオンを英語で実施することになった。私はDrewに依頼して、ハンズオンを実施してくれる人を探した。どうやらオーストラリアかどこかにいている人がやってくれるということになった。 彼は私がリクエストをすると、さっとハンズオンの大枠を決めてくれて、ハンズオンの素晴らしいマテリアルを提供するよと行ってきた。その後、彼は「たった半日のために日本に来れない」という話になったので、私はその「素晴らしい」マテリアルをくれ無いか？と言った。私は「さぞかし素晴らしいパワーポイントが送られてくるんだろう」と思ったのだが、実際送られてきたのは、誰でも読める、AzureのWebサイトにあるハンズオンのURLだった。
きっと日本人だったら、ハンズオンのしっかりしたパワーポイントを作って、事前にGitHub にサンプルを作って上げて、、、とかやってしまいそうだが 彼がやったことは、メールを１本書いただけだ。多分ハンズオンも彼が作ったものですらないだろう。
同時に彼のものでは無いが、神と呼ばれる素晴らしい技術力を持った同僚の佐藤さんがより素晴らしいHoLのURLを教えてくれた。それをそのままお客様にお伝えすると、お客様はすごく喜んでいた。「内容も素晴らしいし、これをいただけたら、事前にみんなにシェアできる！」
今回のお客様はかなりインターナショナルなお客様なので、日本人的な感覚が無いからだと思われるが、これこそ、Be Lazy な仕事のやり方だと思う。
丁寧な仕事がさらなる無駄を生成する
もし、私がそのチュートリアルを見ながら解説を加えて、パワーポイントを作り、、、ということをしていたら私の工数が大量にかかっただけではなく、お客様も直前にならないと、パワーポイントを入手できないので事前にみんなにシェア出来なかっただろう。しかも、上記であげたURLは、沢山のハンズオンが載っているので、簡単で退屈ならAdvanceなものも実施できる。パワーポイント化していたら、そこまでは手が回らないだろう。それどころか、Azure がバージョンアップしたら、そのパワポを修正する工数が発生してしまう。これは相当無駄だ。
私を含めた日本人は、どうしても「献上先」の工数を削減しようと頑張って、自分たちが時間をかけて頑張る傾向にある。しかし、それは、本当に「価値」を向上させているアクティビティだろうか？
日本人での Be Lazy 事例
こういうのはお客様が特殊だからできることだろう？と思うかもしれ無いが、私は前々職の大手SIerに所属しているときに完璧にこの思考を持った人がいた。 彼は、本当に優秀なのだが、ガチで１７時に帰って、飲みに行くのだ。残業はよっぽどのことが無い限りしない。しかし、私は彼が仕事は人３倍ぐらいこなしているように感じた。そして、彼がプロジェクトをやって炎上させたのを見たことがない。ウォータフォールなのに。私はアジャイラーだが、彼ならウォータフォールをやっててもなんの文句も言えない。完璧だ。必要が無い。
彼がそうできる理由は「多分むっちゃ優秀なんやろうな」と思っていた。私は最近になってようやく手がかりが見えた気がしてきた。
そんなときふと気がついた。そういえば、Drew もまったく残業しない。もしかして、、、
残業が生産性を破壊している
「Be Lazy を実践したければ残業をしてはいけないのではないだろうか？」という仮説が頭に浮かんだ。私たち日本人だと、「Be Lazy」のコンセプトを素晴らしく感じて、一度は残業はし無いようにしようと思うとする。しかし、１７時の時点になって、自分が思った仕事ができていなければ、「今日のバリューが出ていないので、それが終わるまではやり遂げて帰ろう」と思う人が多いと思う。私は少なくともそうだった。
私は過去にもこういうトライをしてみて、何回も結局残業している。「私は効率が悪いので仕方が無い。」と思っていた。結局ズルズルと、残業、休日での作業をガッツリしてしまうことになって元に戻るというのを繰り返してきた。
これを、もし、定時が１７時なら、１７時に帰ろうとすると、どうなるだろう？と考えると、１７時でバチっと終ざるを得なければ、現状だと多分１７時にはすごく中途半端に仕事が残るだろう。しかし、これで安易に残業するのは良く無い。残業をしてこなせてしまったら、「やっぱり俺は効率悪いなー。」で終了する。つまり、本当の問題を隠してしまうのだ。
強制的に定時に帰ることが生み出す効果
強制的に、１７時に帰るとして、家に帰っても仕事をし無いと決めてみるとどうなるかというと、相当気持ち悪い気分で変えることになる。次の日もまた想定したよりもバリューが出ない。するとどうなるかというと、「工夫」を始めるのだ。
よくよく考えたら、自分は会社に出てから、やろうと思った作業にフォーカスしているか？というとそこまで集中していないし、余分なことも随分やっていることに気づく。時間を固定して今日こそ想定したバリューを時間内に出そう！とガチで考えるようになる。物量ではなく、バリューなら時間内で出来るはず、もしくは、自分のバリューに対する見積もりが甘いことになる。残業や休日の安易な作業は、そういう点を覆い隠してしまって、問題が発覚しない。そしたら、次も安易に残業、休日でカバーする。それでは、いつまでたっても、定時に帰るなど出来るはずがないのだ。
先にすべきは「定時に帰り始める」ことだったのだ。私たちは、どうやったら最小の工数でバリューを最大化出来るのだろうか？
「努力」ではなく「楽にできる仕組みづくり」
そう考えて、「文化の違い」を理解すべく話題の厚切りジェィソン氏の本を読んでみたりした。彼の考えはすごく腹落ちする。違和感が無い。そのいろんな考えの中でも素晴らしいいものがあった。彼が何かを身に付けたい時は、絶対に出来る程度の簡単さにして継続するというテクニックだった。例えば、大抵の人は単語を覚える時に、毎日一時間やりとげようと大きな努力目標を掲げる。ところがそれは続かない。だから、もっと、楽勝でできるレベルに落とし込む。 例えば、５分でいいから毎日単語を覚えるなどだ。こういう0.1%向上させるちょっとした努力を続けていると、1年では、44％スキルアップする。
私を含む日本人は、大抵「努力、頑張る」に持っていく傾向がある。しかし、彼らと付き合っていると、「努力」とか「頑張る」とかいうのがなく「楽しむ」とか「幸せになる」「ロジカル」ということしか頭に無い感がある。よくよく考えると、努力とか、頑張るということは、美しいけど、無理をしていることを意味する。
Be Lazy の具体的実践方法と考え方
もちろん、私は当初想定のバリューが達成できず、すごく居心地が悪い気分になっているが、上記の気づきにある程度の確信があったので、定時帰りを継続していた。 そうした時に、尊敬する同僚の大田さんと、「Be Lazy」に関するディスカッションをした。その時彼が私に教えてくれた本が決定的だった。
「エッセンシャル思考 最小の時間で成果を最大にする」という書籍だ。この本は、まさにどうやって「Be Lazy」を実践するかの答えと意義を教えてくれる素晴らしい名著だった。是非みなさんも手にとっていただきたいのだが、大きなポイントは次の通りだ。
- 大抵のタスクはノイズ。本当に実施すべきものは本当に少ない。
- 自分にとって重要なことを考えて、今、本当にすべき仕事を１つだけ選んで実施する。
- 他人のではなく、自分の人生を生きる。それを明確にして、依頼を断る。
書籍は素晴らしく、是非読んでもらいたいので、これ以上はかかないが、これだけでも相当なバリューが出るようになるはずだ。結局価値の高い仕事は物量をこなすことでは無い。こなすことが少ないから、価値の高い仕事に集中してできるのだ。何故なら大抵のタスクはノイズにすぎないから。
そういえば、私の前々職の上司も、しょっちゅう仕事を断っていた。しかし、受けた仕事は黄金の輝きを放つぐらいにうまくやっていた。しかも、定時帰りで。
Be Lazy の文化を育てる
この本を教えてくれた大田さんと、「Be Lazy」についてディスカッションしたときに、お互いの、もしくは、同僚の素晴らしい「Be Lazy」事例を交換しあって、「すごいな、素晴らしいな！」と感心し合った。
きっとこの会話を聞いたら、眉をしかめる人もいるかもしれない。努力や頑張りの匂いがゼロで楽をしているように感じるからだ。でも楽をすることは本当に素晴らしいことで、それが、生産性を高めて、インパクトあることに注力できることになる。スラック（余裕）が生まれるから変化にも対応できる。
時間ではなく、インパクトについて一生懸命考えるので、だらだらと今のやり方をやるより、ずっと真剣にバリューを考えるようになる… などいいことづくめだ。
この方法は、USの人々の方が、日本よりずっと文化的に導入が楽なのだろう。だから、私のインターナショナルチームの同僚はほぼこういう考え方をしていることに気づく。
日本の価値観と、Be Lazy のコンフリクト
日本だと、このやり方が賞賛される職場はまだ少ない気がする。残業をしている同僚を横目に変えるのも気がひけるだろう。でも負けてはいけない。 もし、できたとしても日本人だったら、 Be Lazy を実施して、少ない工数で、インパクトが出せるようになったら、さらに残業したらもっと成果が出せると思うかもしれない。残念ながらそうではない。無理をするのは、結局「安定しない」し「リスク」が高い。人々が健康で、楽しんで仕事をするのが最も生産性が高いし、持続可能性が高い。
どうも、日本だと、プロジェクトのストーリも「楽」にできたものは賞賛されず、根性とか、超人的な努力で達成したものの方がもてはやされる。 頑張った方がもてはやされるが、実際は、すごいバリューのあることを「楽に」できるような仕組みと工夫を無理なく、一歩一歩重ねる方が、中長期的にみるとよっぽど生産的だと思う。少なくともロジカルだ。
私はどうも昔から気になっていることがある。歴史的に日本は最初は相手を圧倒するのだが、だんだん息切れして、そのうち逆転されてしまう。という展開が昔からすごく多い気がする。本来日本人は優秀な人が多いと思うのだ。ほんまちょっとした考え方で相当損をしている気がする。
おわりに
私はこのやり方をしばらく続けて、Drew に「お前も Be Lazyがうまくなったな！」と言ってもらえるように自分も楽しんでみたい。幸い私の職場はこういうことには理解がある。もし、そうでない環境の方も、私の前々職の上司の例もあるので、トライしてみてはいかがだろうか？あなたが上司ならこういう考えを気に入ってもらえたら広めてみたらどうだろうか？
彼はしょっちゅう仕事を断っていたが、みんなは素晴らしい仕事っぷりに誰も文句をいうどころか尊敬していた。でも、その秘密はきっと「Be Lazy」の思考を彼がマスターしていたからではないか？と思う。多くの物量の仕事をこなしていたら価値の高くインパクトのある仕事はできないのだ。
それよりももっと重要なことは、他人の目よりも、自分の幸せ、そして、自分がお客さんにとっていい仕事をすることが自分にとっては重要だ。だから継続して仮説検証をつづけていきたい。
