発売されてから1ヶ月ほど経過しますが、『みんなでアジャイル』を読みました。

書籍は、原田さん(@haradakiro) からスクラム道関西宛に献本いただき、僕が一番最初に読ませていただきました。
まことに、ありがとうございます！

献本いただいたので書籍に加えて、いろいろな方に知っていただきたい内容も数多くあるので、ブログで書籍の紹介および、僕の感想を記します。

1章　「アジャイル」とは何か？　なぜ重要なのか？
2章　自分たちの北極星を見つける
3章　顧客から始めるのがアジャイル
4章　早期から頻繁にコラボレーションするのがアジャイル
5章　不確実性を計画するのがアジャイル
6章　3つの原則に従い、速くて柔軟で顧客第一なのがアジャイル
7章　あなたのアジャイルプレイブック

3章から5章が、本書のオリジナル要素です。
各章のタイトルが、本書で重要だとされているアジャイル原則であり、組織運営において陥りがちな3つの重力（いわゆる課題）に対して取り組む必要があることが記載されています。
また、それぞれのアジャイル原則において、組織が良い方向に進んでいるのか？、悪い方向に進んでいるのか？、を判断できる組織の兆候が記されているため、自身が所属している組織の状態を、明確に知ることができることも本書の良さだと思います。

ムーブメントとしてのアジャイル

この書籍では、アジャイルには、「手法としてのアジャイル」と「マインドセットのアジャイル」の２つがあると言っています。

「手法としてのアジャイル」とは、数多くあるアジャイルな手法のうち、チーム内で定められたプラクティスや方法を活用すること。
「マインドセットとしてのアジャイル」とは、チーム内で各自が、アジャイルな考え方や価値・原則を受け入れ、育てていくこと。

しかし、真にアジャイルな状態は、上記２つのどちらかを採用している状態ではなく、２つがコラボレーションしている状態であるとしています。

その状態が、ムーブメントとしてのアジャイルです。

様々なアジャイルといわれる手法（例えば、スクラム、XP、クリスタル）は、アジャイルという言葉が生み出される前に、同時期(1990年代)に次々に生み出され、まさにムーブメントと言えます。

また、ムーブメントと捉えることで、個人で取り組むものではなく、チームや組織が協力して取り組むべきものであり、思考（マインドセット）と行動（手法）のどちらかではく、それらを両輪として捉える必要がでてきます。

感じたこと

ムーブメントとしてのアジャイルは、僕が、アジャイルに対してモヤモヤしていたことを解決する一つの考え方でした。

ここ数年のアジャイルに対するイメージは、マインドセットとしてのアジャイルが中心になり、手法としてのアジャイルは後回しになりがちです。
数年前から、心理的安全性という言葉に、大きな注目が集まり、良いチームを作ろうということばかりが叫ばれるようになっていると感じています。

もちろん、心理的安全性は非常に重要で、マインドセットとしてのアジャイルは必要です。
しかし、技術に関するアジャイル手法（特にXPに代表されるテスト駆動開発、リファクタリング、継続的インテグレーションなど）については、語られることが少ないと感じています。

逆に、手法としてのアジャイルを採用していれば、アジャイルな状態であるとしている現場も、ちらほら見かけます。
スクラム道関西のイベントに参加してくださっている参加者の方々から、「会社がスクラムを採用する方針を出したので、スクラムをはじめました」は、この2〜3年の間によく聞くようになりました。
また、「リファクタリング、継続的インテグレーションなどアジャイルな技術的な手法を採用してるから、私達はアジャイル開発に取り組んでいる」ということも目にしました。

真のアジャイルな状態は、手法としてのアジャイルとマインドセットとしてのアジャイルがコラボレーションしている状態であることを言語化して認識できたことが、収穫でした。

顧客から始めるのがアジャイル

組織重力の第1法則は「組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける」です。
予算やスケジュールによって評価される個人にとって、顧客に向き合うことは、気を散らすだけ。最悪の場合、既存の計画が複雑になる、見直しが入るなどにより、進行が遅れ、個人は危機に陥るというものです。

また、多くの場合、組織内で顧客と直接やり取りするのは、UXやサポートの担当者であり、ビジネスに対して重要な意思決定をする人は顧客と遠く離れた場所にいて、顧客のニーズやゴールに対する知識を持っていないことが多いとされています。

この重力から脱却するアジャイル原則が「顧客から始めるのがアジャイル」です。
作成するアウトプットではなく、顧客に届ける価値（アウトカム）にフォーカスし、「どうすれば顧客のいちばん重要な問題を可能な限りすばやく解決できるか」を考えます。

この原則を達成するために、アジャイルソフトウェア開発宣言の「包括的なドキュメントよりも動くソフトウェアを」に着目し、ソフトウェアプロダクト、マーケティングキャンペーン、プレゼンテーションなどにおける

検討すべき顧客体験
動くソフトウェア
包括的なドキュメント

とは何かを示しています。

そして、限られた時間の中で何を届けるかを考えるためにも、タイムボックス化したイテレーションの重要性を示しています。

感じたこと

顧客中心主義は、ありとあらゆる企業で口酸っぱく言われていると思います。それでも、実現することは非常に難しく、多くの企業で失敗しています*1。

また、エンジニアが顧客とペアプログラミングすることの有用性は、『XPエクストリーム・プログラミング Web開発編』の第5章プロジェクトチームにおいても述べられています。
しかし、書籍の出版から20年近く経過しても、実践している企業はまだまだ少ないと感じています。

私自身が、顧客に価値を届けることへの重要性を痛感したのは、ある新規事業に取り組み、失敗した後でした。
誰がこのプロダクトを購入してくれるのか、利用するのかを正面から考えないまま、開発していました。

加えて、Drift社の事例である「すべての従業員が、顧客からのチャットに直接答える」のように、顧客と直接接点を持つことは非常に重要だと、私が心のそこから思えるのは、私がテクニカルサポートエンジニアとして、働いていたことも大きいです。
個別具体的な顧客の課題を解決する仕事に取り組むことによって、積極的に利用してくれる顧客の課題から一定のパターンに気づき、プロダクトへフィードバックできるからです。

組織が悪い方向に進んでいる兆候として「組織内に顧客からの良いフィードバックしか流れない」は、個人の観測の範囲内ではありますが、あんまり存在しないのかなと思いました。
むしろ、「営業から○○機能がないから売れない」、「顧客サポートから△△機能の使い勝手が悪いと顧客からクレームが入った」など、悪いフィードバックしか流れないが、多いと感じています。
当然なのですが、アメリカ企業と日本企業の差を掴んで、判断するべきだと思います。

早期から頻繁にコラボレーションするのがアジャイル

組織重力の第2法則は「組織における個人は、自分のチームやサイロの心地よさのなかでいちばん簡単に完了できる作業を優先する」です。現代的な組織において、リスクを最小限に抑えることが成功戦略です。それ故に、上司から求められた成果物の締切を優先するとなると、ほかのチームからのインプットがあれば成果物がより良いものになることがわかっていても、成果物完成に対するリスクが高くなるため自分のチーム内に閉じてしまいます。
また、コラボレーションした場合、ほかのチームに仕事を台無しにされたり、成功した場合にも手柄を横取りされてしまうといったリスクがあり、コラボレーションしづらいとうこともあります。

この重力から脱却するアジャイル原則が「早期から頻繁にコラボレーションするのがアジャイル」です。
報告と批評の文化から、Spotifyモデルに代表されるような協調的な文化へ移行することが重要となっています。
完成する前の成果物が、組織やチームで区切られた範囲に関わらず共有され、機能横断的なチームが同じ場所（物理的に同じとは限らない）で作業しているような感触を得ることが出来る状態にします。

定められた公式な会議だけでなく、非公式に話をしたり、一緒にランチをとることで、様々な職能のメンバーが、お互いに関心をもてるようにします。

感じたこと

「風通しの良い組織づくり」
この言葉も、様々な企業において、何度も企業方針や理念として耳にします。

しかし、エンジニアは「私達は、良いものを作っているのに、営業が売ってこないから悪い。」、営業は「私達は顧客と会い、製品の要望を上げているのに、エンジニアがまともなものを作らないから悪い。」といった話を聞きます。

組織がコラボレーションすることの重要性はわかっていても、仕事がフェーズによって区切られていることで、各職能の人だけが担当することになりがちです。

スクラムでは、スクラムガイドに記載の通り「スクラムチームは自己組織化されており、機能横断的である。」と機能横断チームを目指しています。
開発者とテスター、サーバーサイドエンジニアとフロントエンドエンジニア、機能開発チームと保守運用チームといった、エンジニア内でのコラボレーションの事例は、よく耳にします。
しかし、開発と営業、開発と顧客サポート、開発とマーケティング、開発と法務といったコラボレーションを見かけることは、まだまだ少ないです。プロダクトをリリースする、つまり顧客に価値を届けるには、様々な組織との連携が必要であり、まだまだ真のコラボレーションを実現する組織を作るには、まだまだ道は遠そうです。

書籍では、アメリカらしく、非公式な場面での組織間コラボレーションは、ランチやコーヒーブレイクを例にしていました。
日本では、就業後の飲み会が鉄板だと思います。アメリカと日本の文化の差を感じました。
もちろん、飲み会をうまく生かした企業も多く、ホンダのワイガヤ、京セラのコンパは有名です。
中には、こういった文化に対して良いイメージを持たない方もいらっしゃると思います。ただ、2社とも日本を代表する企業であることは間違いなく、これらの文化が貢献したことは間違いないと考えています。

不確実性を計画するのがアジャイル

組織重力の第3法則は「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない」です。プロジェクトやプロダクトが経営幹部から承認されれば、仮に顧客ニーズや企業の目標に合致しないことが明らかになっても、そのまま続けられるというものです。
顧客からのフィードバックがあり、失敗することが明らかな場合であっても、組織における政治の世界では、人前で恥をかくことは、上司が承認したアイデアに対して間違ったということより、リスクが低いと思えてしまうのです。

この重力から脱却するアジャイル原則が「不確実性を計画するのがアジャイル」です。
個人にこの重力に逆らうのではなく、プロセスを変更することが唯一の方法です。プロジェクトを承認する経営者は、プロジェクトには必ず変化の余地を残さなければならないことを理解し、組織が共感する言葉を使って短いサイクルを広め、不確実性に対するより良い計画を立てることが重要です。

この重力を克服するアジャイルプラクティスとしては、ふりかえりが重要とされています。
アジャイル原則を重視することで、チームが、そもそもなぜ仕事のやり方を変えようとしているのかを着目し続けるのにも役立ちます。
また、将来の変更を強制ではなく実験として扱うことで、新しいプラクティスやアプローチを試すことに、ほとんどリスクがないことを意味します。

感じたこと

経営層の判断が非常に重要であり、経営層が承認した計画をなかなか変更できないことが、アメリカ企業であっても、よくある課題に挙がるのは個人的には意外でした。
日本のライン重視の組織体系ならではという感じもしていたのですが、世界のどこでも発生してるようです。

日本企業で典型的な問題は、悪い方向に進んでいる兆候に記載されている「決定を下す際に100%の確実性を要求している」だと思います。

「顧客のニーズを100%叶えなければならない」、「この機能を、この期日までに完成させることは絶対です」、「バグの発生は0%の状態でなければ出荷しません」など、具体例は、幾つもあがります。

顧客のニーズは日々変化していますし、技術的な要素も目まぐるしく変化しています。
AWS、GCP、Azureなどのクラウドサービスをインフラとして利用する限り、データがロストする可能性が0%、サーバー稼働率100%の状態などは、理想の理想で、一般的な企業が達成できるものではありません。(むしろ、自社管理のオンプレ環境の方が、リスクが高いでしょう。)

そもそもビジネスの話になるのですが、儲かることが明確なのであれば、困らないです。
「このタイミングでリリースすれば、〇〇円儲かること」がわかるのは、神のみぞ知る世界だと、私は考えています。
儲かるかどうかわからない不確実な世界で活動しなければならないからこそ、不確実性を計画することが重要だと、思っています。

おわりに

本書を一番読んでほしい方は、各企業の社長やCEOといった企業のトップの方だと感じました。
個人的に一番抵抗できない組織重力は、「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない」だと考えたからです。
いくら、各チーム内で、他のチームとコラボレーションし、顧客に向き合ったとしても、会社の方針を覆すには、トップの判断が必要だからです。

と言いつつ、組織全体をアジャイルな状態で運営にするには、各人がアジャイルなマインドセットを持って、アジャイルな手法で取り組む必要があるため、どんな役割の方でも読んだ方が良いとも思いました。

タイトルの「みんなでアジャイル」という言葉こそが、組織内での共通言語となり、組織内におけるアジャイルなムーブメントを起こすためには、必要なんだと思います。