雑記帳

情報を自分の言葉で蓄積しておく場所

全ては問いの質で決まる 〜"みんなでアジャイル"書評〜

とあるきっかけがあって、"みんなでアジャイル"をお盆休み中に読んだ。

www.oreilly.co.jp

存在は知っていたものの、またアジャイルとかスクラムのテクニック本でしょとかひねくれた偏見を持っていたが、日々改善を繰り返しながらチームとして共通のゴールへ向かうための価値観や考え方を丁寧に言語化してくれているとても良い本だった。

感想

全体を通して、エンジニアの文脈で語られがちだったり、具体的なプラクティスについて背景や解決したい課題について深ぼられることなく議論されがちなアジャイルというものについて、なぜアジャイルな文化をつくりたいのか、どういった価値観であればよいのか、どういった組織課題を解決したいのか、など目的についてしつこいほど何度も繰り返し言及している。
巷で見かける、"いわゆる"スクラムアジャイルについての議論に対して漠然と抱えていた的外れ感の答えや、自分たちがチームで作り出そうとしてるムーブメントについての強力な武器を得られた気がした。

1章のまとめにある"アジャイルはシンプルにできている(だが簡単ではない)"というタイトルがアジャイルを浸透させる難しさを端的に表しているなと感じた。
シンプルだからこそさまざまな手法が存在する余地があり、様々な課題や方向性を持つ組織に持ち込む器の広さがアジャイルにはあるからこそ、自分たちの組織の課題を解消するためにどのようにアジャイルの原則を適用すべきか自分たちの頭で徹底的に考え、行動しなければならない。

幼い頃から今に至るまで目的を考え行動する訓練をあまりしてこなかった人には確かにとてもむずかしいだろうし、個人ではなくチームや組織として実現するために能動的な進行役として推進していかなければならないということを改めて突きつけられ、身の引き締まる思いをした。

この本をおすすめする人

  • どういったかたちであれ、チームでものづくりをしている人
  • チームや組織での仕事のしざまに停滞感を感じている人
  • スクラムアジャイルの文脈でよく紹介される手法に違和感を感じている、または導入してもあまりうまくいっていないと感じている人

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

様々な失敗を繰り返しながら自分たちなりにアジャイルの本質の一部だけでも理解できたチームが、改めてアジャイルソフトウェア開発宣言の全文を見ると17人の賢人が言いたかったことがより深く理解できると思う。

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発宣言

著者は、本書内でこの宣言の引用の次に、ツールは人間よりも価値が低い。つまり、よく取り沙汰されがちなプロセスやツール駆動ではなく、(それらも経験豊富な先人たちが発見したプラクティスの例としては有用ではあるものの)チームに息づく価値観や文化によって手法は駆動されるべきであり、逆に文化や価値観は具体的な実践を通じて成立させなければならないと述べている。価値観を優先し手法をおざなりにするわけではないという点が重要である。

このことをより深く理解するために、著者が定義しているアジャイルの3つの姿を読み解くとよい。

アジャイルは手法やマインドセットではなく、ムーブメントとして捉えることでチームメンバーがオーナーシップを持ち、共通の目標に向かって協力し合うことができる。

プロセスやツールとしてのアジャイル、つまり価値観より手法が優先されるアジャイルは、宣言や上に書いた著者の意見を読めばなにがいけないかは想像に難くないだろう。
マインドセットとしてのアジャイル、つまり手法より価値観が優先されるアジャイルでは、これも結局"マインドセット"というツールとしてアジャイルを取り入れることになり、それは他人が決めた価値観を使うということに他ならない。
ムーブメントとしてアジャイルを捉えることで、自分たちが目指したい方向性は何か、どういった課題を解決したいのか、そのためにアジャイルの原則やプラクティスを適用するのか、それにあたって自分たちにはどういった役割があるのかということを徹底的に考え、実践しながら価値観や文化を醸成していくことができる。

ムーブメントとして捉えるために必要なチームの北極星や、アジャイルの原則を適用することで回避していくべき組織課題についてはこのあと触れる。

自分たちの北極星

アジャイルをムーブメントとして捉えるために重要なのがチームや組織が目指したい方向性、つまり北極星である。
巷でも手法の話がよく目立つように、組織においても自分たちが解決したい課題やそのために従うべき原則について理解することなく、表面的にアジャイルラクティスのみを取り入れ実践しようとしてしまう事が多い。これを著者はフレームワークの罠と呼んでいる。
根本的な治療を行うことなく対処療法だけ行うことで、結局仕事のやり方がもとに戻り、"取り入れたフレームワークではダメだった、また別のフレームワークを試してみよう"と特に振り返ることなく手当り次第様々な手法を試すだけ試して失敗するという状況に陥る。

2章で、

本章では、フレームワークの罠から逃れる2つの方法について説明する。意義あるものにする、自分のものにする、だ。 どちらもアジャイルのプラクティスをアジャイルの価値観に結びつけ、それぞれの組織のニーズやゴールとも結び付ける。こうして、表面的な変化を限りなく繰り返すフレームワークの罠から逃れることができる。

と述べているように、
フレームワークの罠から逃れるために、現状の仕事のやり方等をふまえて自分たちが目指したい方向性、つまり北極星を示すことで、日々の取り組みを意義あるものにすることができる。
そしてそこに向かうためにどういったアジャイルの原則をどのように適用することができるかを定義することで、アジャイルの原則やそれに基づくアジャイルラクティスを自分のものにすることができる。

原則を適用しアジャイルを自分たちのものにする際に、著者はアジャイルの価値や原則の特殊化と骨抜きの違いについて述べている。
特殊化と骨抜きの一番の違いは、アジャイルの原則を組織やチームに合わせて適用する際にこれまでの仕事のやり方を変え、組織の課題解決やゴール達成の助けとなるか、それとも今のやり方を変えないように表面的にアジャイルの用語と組織の用語を組み合わせるだけかという点にある。
自分たちの課題に合わせてアジャイルを特殊化すると同時に、それによって課題解決ができているか?できてなければ何が問題なのか?を定期的に振り返らなければならない。

組織重力の法則

著者は以下のアジャイルの3原則を唱えている。

逆に、組織としてどういった状態に陥りやすいか、それを解決するために上記3原則をどのように取り入れるべきかを説明するために、以下の組織重力の法則も提唱している。

  • 第1法則: 組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける
  • 第2法則: 組織における個人は、自分のチームやサイロの心地よさの中で一番簡単に完了できる作業を優先する
  • 第3法則: 進行中のプロジェクトは、それを承認した一番上の人が止めない限り、止まることはない

    我々は顧客のためにものづくりをしている。チームや組織のニーズやゴールも、最終的に顧客中心のプロダクトアウトプットにつながるべきであり、現代のビジネスにおいては顧客中心主義が浸透しつつある。
    しかし顧客中心主義を唱えるだけでは、当然チームやメンバーが課題解決のために積極的に顧客に向き合うことはない。なぜなら、企業本位のスケジュールや予算などが組まれている組織に所属するメンバーにとっては、顧客に向き合うことはそもそもの計画が複雑になったりスケジュールの遅延につながる可能性があるからである。
    第1法則を乗り越えるためには、"顧客から始めるのがアジャイル"という原則を取り入れ、それを実現するために顧客からの学習が費用対効果が高いことを組織の共通認識とする必要がある。

我々が日々仕事をこなす中で陥りがちなのが、どれだけのタスクをこなしたかやどれだけのストーリーポイントを消化できたかでアジリティを測定してしまうことである。
どれだけタスクをこなせたか?という問いはあくまで企業本位の視点でどれだけアウトプットできたかというものにほかならず、真に顧客中心になるためにはどれだけ素早く顧客にとっての重要なイシューを見つけ、価値提供できているか?を問わなければならない。
そのために、定期的に顧客からのフィードバックを得るためにスプリントなどタイムボックスに区切ったイテレーションを回す手法をとりいれる。

組織として同じ方向を向き続けるためには、戦術の前の戦略的な段階から関係者と頻繁に協力しあう必要がある。
しかし自分のチームなど普段仕事をしている境界線内で心地の良い仕事をこなす状態に陥いる。つまり第2法則の状態になってしまう。なぜなら越境してコラボレーションすることで、別チームの目標や優先順位と、自分たちのチームのそれが競合状態になる可能性がある組織が多いからである。
これを解決するために、組織全体が顧客にとって最優先のイシューを解決するための仕事をしている状態にする。そのための目標や北極星、評価の設計を行いチームやサイロを越えたコラボレーションの文化醸成を促す必要がある。
これにより早期から"頻繁にコラボレーションするのがアジャイル"というアジャイルの原則を取り入れ実現することができる。
他チームの表面的な意思決定や動きだけを見ていると、例えば、機能開発を行うチームとリスクマネジメントや情報統制を責務とするチームの間で、方向性の違いが発生しているように見えるようなことは様々な組織で発生しているのではないだろうか。
しかし普段からコミュニケーションを取り合い、最終的な意思決定の前から議論をしていると、互いに同じ顧客のためという方向を向いており、決して互いの仕事の邪魔をしたいわけではないことがわかる。
その認識が取れていると、お互いの責務を全うしながら同じ目的を達成するためにどの様な落とし所があるかというより建設的な議論ができるようになる。
完成したものをただ報告し批評しあうだけの文化から、完成させるための目的や方法などから頻繁にコラボレーションしあう文化への転換を行う必要がある。

これまで顧客中心のものづくりや組織の方向性について触れてきたが、顧客のために解かなければならないイシューやそれを実現するための組織の方向性は動的に変化していくものだ。
個人の仕事だけでなく、チームや組織が取り組んでいるプロジェクトについても同様で、プロジェクトが解決するイシューも時によって変わったり、元々の想定から外れていくということはままある。
しかし第3法則のように、顧客や市場のニーズに直接触れられる機会から遠いリーダーがそういった変化に気づくことができず、プロジェクトに関わるメンバーもそういった状況に対し異議を申し立てる労力を避け、間違った仕事の舵を切り直したり止められることなく世の中にリリースされてしまうということは見かけたことがあるだろう。
短い単位のプロジェクトだろうが、大きな予算のついた年単位の計画をしている組織だろうが、事前に定期的に舵修正のための振り返りを行うタイミングを設けておくことで、"不確実性を計画するのがアジャイル"という原則を適用することができる。

上に書いたように、組織によって様々な仕事のサイクルがあるだろう。大きな予算のついた仕事で2週間ごとに振り返り舵修正を行うのは難易度が高いと思う。
そういった場合は、組織における固定のサイクルを洗い出し、それに合わせて振り返りのタイミングを計画し、そのサイクル内で柔軟性の余地を増やすことはできる。
またふりかえりによる軌道修正というのは場合によっては手戻りが発生するなど苛立たしい状態になることもあるだろう。しかし事前に不確実性を盛り込み、ふりかえりのなかで得た発見や変化を歓迎することで、組織として柔軟性を持たせるための様々なムーブメントを呼び込むことができる。

これは覚えておいてほしい。組織のニーズを理解し原則に従おう。そうすれば、私達は新しい働き方を見つけられるようになり、チームがオーナーシップを感じられるようになるのだ。

と著者も言っているように、アジャイルの原則や組織重力法則の話を通して、ひたすらに組織の向かうべき方向性にどのように原則を適合し、新しい働き方を作り出すのか について訴えかけている。

ちょっと脱線

解法のすばらしさや問題を解くスピードよりも、解く問題について徹底的に議論すべきという考えは、個人的に読んだことのあるイシューからはじめよ正しいものを正しく作る採用基準など様々な本で触れられている。

www.amazon.co.jp www.amazon.co.jp www.amazon.co.jp

また、最近だとachikuさんが良い問題がチームをリードするというタイトルで記事を投稿しており、この中でも良い問いとはなにかについて触れられている。 akirachiku.com

良い問いがあるとメンバーがオーナーシップを持って積極的に議論し、自分ごととして結論を出していく中でチームの方向性を揃えることができ、真に顧客中心なマインドを取り入れ、それを実現するための様々なプラクティスを自分たちの課題解決のために取り入れられるようになる。ムーブメントとしてのアジャイルが出来上がっていく。

アジャイルラクティスの追求

ムーブメントとしてのアジャイルの項でも書いたように、文化や価値観の追求と実践両方を行うことでアジャイルをムーブメントとして捉え実行することができる。
そのためのフレームワークとして著者はWHPI(Why, How, Prototype, Iterate)というフレームワークを提唱している。
手法にこだわるなといいつつフレームワークの話ではないかと思うかも知れないが、ここまでこの記事を読んだり、実際にみんなでアジャイルを読んだ人であれば、このフレームワークを表面的に取り入れるようなことはしないだろう。

あくまでこれまで著者が何度も繰り返し主張してきた内容をフレームワークに落とし込んだにすぎず、Whyでなぜその成果物を作るのかをチームやサイロの垣根を超えて協力して決定し、Howでどのようにそれを実現するかをメンバーで決定する。タイムボックスを決めてPrototypeを作成し、振り返りやレビューを通じて顧客やステークホルダーからのフィードバックを得ながらどれだけゴールに近づけたかを確認しWHPをIterateし続ける。

さいごに

感想の項にも書いたが、改めてまとめてみると、我々はどこを目指し、なぜその仕事をやらなければならないのか、それを実現するために仕事のしざまを変えるべきと判断した場合、どのようにアジャイルの原則を適用すべきなのかについて何度も言及していることがわかる。
結局これらを認識した上で、実際にそれを実行できているかを確認することが何より重要であり、そのためには振り返りがアジャイルというムーブメントの中で重要な位置を占めているべきなのではないかと感じた。

正しい問いを選び解決へと結びつけることができているか、それによってチームや組織がうまく駆動しているかを徹底的に自分や組織に問い続けなければならない。