みんなでアジャイル 変化に対応できる顧客中心組織のつくりかた
- オライリー・ジャパン (2020年3月19日発売)
本棚登録 : 319人
感想 : 24件
本ページはアフィリエイトプログラムによる収益を得ています
本 ・本 (216ページ) / ISBN・EAN: 9784873119090
作品紹介・あらすじ
エンジニアと協業する人たちが「アジャイルである」ことを理解する !
ソフトウェアおよびプロダクト開発、運用管理では「アジャイル」は前提となっています。デジタルトランスフォーメーションの活発化が求められており、エンジニアおよびエンジニアと協業するチーム、マーケティング担当者、プロダクトマネージャ、上級管理者など、組織全体が「アジャイル」とはどういうことかをイメージでき、どうすれば機能するかを解説します。
感想・レビュー・書評
-
コメント0件をすべて表示
-
本書を読み、ぼんやりしていた「アジャイル」という言葉の意味がよりはっきり理解できるようになった。
アジャイルは、目的ではなく「顧客の成功」を達成するための手段である。
アジャイルは定型のものではなく、取り入れることでうまくいくかもしれない過去事例に基づくプラクティス集があるのみである。
常に「なぜやるか」を重視し、根本的に必要ないと判断されたことは捨てるアプローチもある。
いきなりアジャイルを効果的に使いこなすことは難しいことを理解し、来週から実践サイクルを回していきたい。
1
-
アジャイルに何のために取り組むのか、
取り組んでいくうえでどこに躓きポイントがあるか
といったことについてまとめている本。
読みやすかったといえば読みやすかったが、
こうなりがちというところが多く目立った印象でした。
気づいたら上手くいっているということは無いので、
ひっかかるところを振り返って変化に強い、
みんなが主体性を持ったチーム作りに励みたい。
【勉強になったこと】
・成功するアジャイルの適用は、
常に厳しく正直に現状を見ることからはじまる。
・顧客中心主義になるためにも、
全てにおいて顧客のフィードバックを必須とせよ。
・すでに動いているものを見つけてサポートする、
もしくは動いているネットワーク同士をネットワーク
する。そうすることで勢いが増していく。
・会議の出席を任意にすることで、
それでも出席する人からその会議から得られる
有益な情報(価値)を確認し、会議の良さを引き出す。
・振り替えりで大事なのは、どうやってその仕事を
終わらせることが出来たか？
・WHPIのステップ
なぜ、どうやって、プロトタイプ、繰り返す
・WHPIを使うときは、「なぜ」を
イテレーションの間に再考すること。
1
-
原則と価値観に立脚し、プラクティスに振り回されず本質的な意味でアジャイルを実践する。
アジャイル開発とは親戚のようなリーン、DevOps、デザイン思考との関係性、近接しているがゆえの用語の重複。そこで発生するコンフリクト。
200ページに満たないコンパクトな中に散りばめられた問題提起は、主体的にアジャイル開発と向き合う人間なら必ずといっていいほどぶちあたるものだ。
不確実性と向き合うことを体現するかのように、明確なプラクティスの提示という形での解決はほとんどない。
(そこは、初学者にとっては戸惑うところになりそうだ)
アジャイル開発の理念に共感し、自らの組織の壁に失望する。そういったアジャイルファーストペンギンたちが再び立ち上がるための強力なパートナーになりそうな一冊だ。
1
-
アジャイルの原則、プラクティス、現実の成果を同期させるために、アジャイルの3つの原則について解説し、最後にアジャイルプレブックを記載している。3つの原則は、顧客から始める、早期から頻繁にコラボレーションする、不確実性を計画するの3つ。それぞれに良い方向に進んでる兆候と悪い方向に進んでまる兆候を掲載しているため、自身の開発チームの状況と照らし合わせやすくなってる。
0
-
だが実際には、アジャイルがほかのビジネス分野にまで入り込んでいくと、組織のサイロを壊すのではなく、むしろサイロを強化するリスクがある。ビジネスの各領域には、それぞれ固有の専門用語、固有のツール、固有のフレームワークと手法がある。たとえば、「アジャイルソフトウェア開発」、「アジャイルセールス」、「アジャイルマーケティング」をそれぞれの仕事に特化した戦術や手法の集合として扱ってしまうと、顧客のニーズを満たすために一緒に働くという重要な機会を逃すことになる。言い換えれば、私たちはアジャイルムーブメントの共通の価値観を中心としてさまざまな仕事を統合するのではなく、Xという仕事とYという仕事の違いを強調して増幅させるような「Xのためのアジャイル」と「Yのためのアジャイル」なるものを作り出してしまうリスクがあるのだ。
アジャイルムーブメントを生み出した「同時進行するイノベーション」という概念を拡大すると、これらのムーブメントが極めて類似した根本課題にさまざまな方法で取り組んでいることがわかる。すなわち、急速に変化する世界において、組織はどのようにして顧客のニーズを満たすことができるのかという課題だ。これらのムーブメントの解決策はそれぞれ少しずつ異なるものの、顧客中心主義、コラボレーション、変化へのオープンさ、といったような類似した価値観を原動力にしているという点では同じである。
アジャイルが、現代の組織が抱える問題に対してどんなときでも使える革命的な解決方法だとしたら、それはすごく魅力的だ。だが、アジャイルの用語を使い、表面的にプラクティスを適用するだけでは、フレームワークの罠にはまることが保証されたようなものだ。「なぜ」と問わなければいけない。アジャイルで意味のある変化を得るためには、人をグループで働かせ、自分たちのニーズやゴールを理解させ、そして現在のやり方がどうゴールの達成を阻んでいるかを理解させなければいけない。図2-2に示すように、人を一緒に働かせて理解を得ることで、フレームワークの罠から逃れて意味のある結果を残せる。
組織重力の第1法則：組織の個人は日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける。右下にいる顧客と直接やりとりする従業員から離れた場所に組織図があることに注目してほしい。
…顧客から直接学習するために多くの時間を費やすことは、顧客が本当に欲しいものを推測したり議論したりするのに使う時間を減らす必要があることを意味する。顧客との会話や顧客からの学習は投資対効果が高いことを理解して認めることが、組織が組織重力の第1法則を乗り越え、顧客中心主義を実現する上で重要だ。
顧客の視点から速度を見るとはどういう意味だろうか？ 私たちが答えるべきいちばん重要な質問は「多くの作業をどれくらい迅速にこなしているか」ではなく、むしろ「どれだけすばやく顧客に価値を届けられるか」だ。Spotifyのグロースマーケティング担当VPのマユー・グプタは「アジリティは実行速度ではなく、顧客のニーズにもとづいて変化したり進化したりできる能力で計測する」と語った。
顧客から始めるのがアジャイル／良い方向に進んでいる兆候
・顧客に驚かされている
・組織のリーダーやチームリーダーが会議で顧客中心の質問をしている
・初期のアイデアから実行まで、顧客のフィードバックをすべてのステップに取り入れている
顧客から始めるのがアジャイル／悪い方向に進んでいる兆候
・顧客との直接なやりとりが見下されていたり、外部委託されたりしている
・新しいプロダクトやサービスのアイデアに「革新的」「破壊的」といった枕詞が付いている
・組織内に顧客からの良いフィードバックしか流れない
・アジャイルの旅の進ちょくを適応状況や速度などの運用指標のみで計測している
本章で説明したように、アジャイルは価値あるソリューションを顧客に届ける速度を向上するように設計されているのであって、いつもと同じ物を作る速度の向上を意図しているわけではない。アジャイルの旅の成功を運用指標だけで計測していて、顧客と向かい合った成功を計測していないのであれば、それはビルドトラップに陥ってしまっている。その場合、顧客やビジネスにほとんど影響を与えないものを作るために、多くの労力を使っている可能性がある。
組織重力の第2法則：組織における個人は、自分のチームやサイロの心地よさのなかでいちばん簡単に完了できる作業を優先する。右下の重力場が、ある1チームのメンバーを互いに近づけたり、組織内のほかの場所にいる同僚から遠ざけたりする様子に注目してほしい。
Spotifyモデルについて話すときは、ギルド、部隊、支部が中心になることが多いようです。ですが、それは形式的なものに過ぎません。レポートラインを変えるだけでは障壁を取り除くことはできません。本当の機能横断チームがあれば、レポートラインは意味をなさなくなるのです。ビジネスを営んだり問題を解決したりするには、本質的に機能横断的に行わなければいけません。
人生やキャリアを重ねていくうちにだんだんわかるのですが、実はこういう変化を起こすのは文化です。私にとっていちばん重要なのはそれです。組織文化なのです。どのように個人を成長させるか、どのように人材を動機付けるか、どのように人材を評価するか、といった文化です。文化が本当の意味で機能横断的になるのは、自分の座っている場所を気にしなくなり、個人を英雄視するのではなくコラボレーションを認識し始めてからです。最終的に私たちはみんな、自分の業績に対して評価されたいのです。評価がサイロのなかや個人レベルで行われているなら、個人はその評価を求めるようになります。私たちはチームワークを評価しなければいけないし、チームワークを受け入れなければいけないのです。
コカ・コーラでアジャイル導入を推進し、組織をよりアジャイルなやり方で導いたのはトーマス・スタブスだ。私は彼と話す機会があり、そこで彼は、「温室」のアプローチでチームが協力しあって、納期内に終わらせたやり方について説明してくれた。
とても簡単な原則に従って仕事をしていました。メールやパワーポイントでコミュニケーションはしません。デザイナーとエンジニア、ビジネスオーナーを同じ部屋に集めて、仕事をこなせるようにしたのです。これを「温室」アプローチと呼んでいました。アジャイルについて知る前からこのやり方を使っていました。適切な人たちが集まれば、その場で判断することができ、すばやく前に進むのです。
隣にいて一緒に解決策を考えている人とは、あまりネガティブな仕事関係になることはありません。いつも近くにいる人と会話をするときは、礼儀正しくしようとするはずです。逆に、メールは使い方を間違えると、人を攻撃的にさせてしまいやすいメディアです。アジャイルで使うには史上最悪のツールではないでしょうか。適切でない人たちがCcに加えられ、見る必要ない大量の情報にさらされます。そして、人間は、メールで内容やコンテキストを読み取ったり伝えたりするのは得意ではありません。すばやく判断して動く必要のある状況で、メールとパワーポイントはスピードを落としてしまうのです。
誰が部屋にいるべきかという問いに決まった答えはありません。意思決定者はいるべきですし、人から信頼されているチームリーダーもいるべきでしょう。部屋にいる人数も上限があります。増えすぎると扱いにくく、仕事もできません。何人が正しいかはわかりませんが、10人を超えると小さい部屋のなかの会話がカオスになり、意思疎通が難しくなるでしょう。ブラジル大会では10人にしましたが、今考えると多すぎました。それでも、なんとかやり抜いて、18か月分の仕事を6か月で片付けたのです。
カレンダーが退屈で不要な会議ですでに一杯の人にとっては、コラボレーションを増やすというアイデアは無駄で非生産的に思えるかもしれない。だが、本当の意味でコラボレーションの文化を作るのは、誰かが終わったことを話しているのを部屋で座って聞く以上のものだ。オープンな環境で失敗するという選択をすること、つまり完成して洗練する前に共有すること、プロジェクトの全体的な形や方向性に対するインプットを求めることは、本当のコラボレーション文化に対する貢献になる。そのような文化の発展に取り組んでいれば、私たちが顧客に提供する価値が、組織図のギャップやサイロによって制限されることはないのだ。
組織重力の第3法則：進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない。すべての注目が組織図の最上位に注がれていることに注意しよう。
変化を乗りこなすには、チームと組織が自分たちの使うプロセスを共同所有し、何がうまくいっていて何がうまくいっていないのか、それはなぜかを率直に話せるだけの信頼と透明性を作り上げなければいけない。アジャイルが単に上からの命令だったり外部のコンサルタントによって持ち込まれたものだったりする場合は、これを実現するのは難しいことが多い。意欲的な実践者たちのチームが自分たちでアジャイルプラクティスの適用を推進している場合でも、プラクティスについてふりかえって改善するのは難しいのだ。アップルやAmerican Expressでエンジニアリングマネージャーとして働いた経験を持つアビシェーク・グプタは、チームがアジャイルプラクティスの目標に関する会話を始めることが、チームのルーチンや儀式に難しいが重要な変化をもたらすことを説明してくれた。
アジャイルでの大きな課題の1つは、「理由」を理解することなしに、やらなければいけないことになってしまうことです。アジャイルが銀の弾丸だとみなされていると、さらに酷いことになります。「私たちのプロジェクトはアジャイルをしているので素晴らしいものになるだろう」などと言うのです。ですが、これはアジャイルの精神がなければ成り立ちません。プロダクトの品質に深い関心を持つ人たちにとっては、アジャイルは手段であって目的ではないのです。プロセスと成果をごっちゃにしていることが問題の根源です。プロダクトの品質を気にしなければ、つまり顧客に価値を届けることに関心を持たなければ、アジャイルがあなたを救うことはないのです。
私はかつてしばらく「アジャイルをしている」チームと働いたことがあります。「これはみなさんにとって価値がありますか」と聞くと、最初は「ええ、とてもとても価値があります」という答えが返ってきました。2か月後に私は彼らのアジャイルイベントに出席して何がうまくいっているかを確認しました。すると、どれも同じようなことになっていました。ソフトウェア開発ツールであるJiraに入っているチケットを見せながら、何の作業をしていて、何が終わっていて、何が終わっていないかを話していたのです。彼らは自分たちがやっている作業のインパクトを理解することよりも、実際のチケットをクローズすることに重点を置いていました。実際の成果を考えることなく、多くのプロセス管理をしていました。つまり、見せかけの仕事ばかりだったのです。
数か月後、私はチームに「これは実際のところどう役に立つのですか？」と言わなければいけませんでした。私が聞いた答えは、一度に多くのことに取り組む必要がないこと、何に取り組んでいるのかがわかること、焦点を明確にして進められること、というものでした。そこで、その焦点を維持しつつも、顧客のために私たちが作り出す価値を通じてその焦点が理解できるような、より大局的で方向性がはっきりした考え方を取り入れる方法について話し合いました。これは、多くの決まりきったアジャイルの儀式から離れて、チームとして「どうすれば、私たち自身と顧客が望む成果を達成できるだろうか」と聞き続けることを意味していました。
不確実性に対する計画づくりを実践するというアジャイルの原則を実践するうえでの良い方向に進んでいる兆候
・あなたとチームが多少の不確実性と理解の及ばない点を抱えている
・顧客価値を作り出さないプロジェクトを定期的にやめている
・あるアジャイルプラクティスがチームでうまく機能しない場合、一緒にそれを変えている
悪い方向に進んでいる兆候
・あなたの組織では、決定を下す際に100%の確実性を要求している
・次年度の年間計画会議や予算会議まで重要な情報を保留し続けている
・「アジャイルなので」その仕事の仕方をしている。それだけだ
まとめ：変化はよいものだ。それを望むなら
心理学者のヴァージニア・サティアは、「ほとんどの人は、不確実性の悲惨さよりも、不幸の確かさを好む」という名文句を残している。アジャイルは、一貫性がなく予測不能な世界から新しい情報を取り入れるための一貫していて予測可能な機会を提供する。それによって、不確実性をそれほど悲惨ではないものにできるのだ。多くの枠組みがあることで最終的には高い柔軟性がもたらされるという考えを受け入れることで、私たちはチームの日々のプラクティスを具体的な手段として使い、変化に対する恐怖とそれに伴う機会損失を軽減できるのだ。不確実性に対する計画は、新しい情報によって進ちょくが損なわれるという不安な気持ちを、手遅れになる前に新しい情報を取り込めるという感謝の気持ちに変えるのだ。
Slackで、プロダクトチームとプロダクトマーケティングチームのあいだをうまく調整する方法を探し始めたとき、まず本当に解決したいことから始めました。まず、プロダクトチームとプロダクトマーケティングチームが方向をそろえて、共通の目的を持つようにしたいと考えました。そのため、初期のアイデアからローンチまでずっと、マーケターがプロダクトに関与しプロダクトチームと連携するようにしました。こうすれば、マーケティングは全体のプロセスに積極的に関わることになります。最後に言葉で叩かれることもありません。たとえば、プロダクトのローンチのときに書くブログ記事を開発の初めに書くこともできます。そして、プロダクトがどのように進化するかを追跡できるようになります。
次に、プロダクトマーケティングを、プロダクトについての素晴らしいインサイトを開発チームに取り入れるポイントにしたいと考えました。そこで四半期ごとのプロダクトロードマップの確定前に、プロダクトマーケティングがセールスや顧客サポートなどの顧客と直接やりとりするチームから得たフィードバックを、プロダクトチームに確実に伝えるプロセスを開始することにしました。そうすることで、プロダクトチーム、プロダクトマーケティングチーム双方が顧客を本当に知り、一緒に顧客中心のチームになれるのです。
私たちにとっての質問は、「プレッシャーをかけすぎずに、調整できる適切な交差点をどうやって作れるか？」というものでした。そこで、期待値を設定し、アイデアを共有し、そして共に参加するようにしました。誰が参加するのかも明確に定義しました。また、「どうやって」に余裕を持たせておくことで、個々のチームが個別のニーズに合わせて最適化する余地を残すようにしました。
「ベロシティ」について考えるとき重要なのは、市場でのベロシティです。いちばん重要な質問は、市場でユーザー価値を実現し、ほかの選択肢よりもよいと認識してもらえるか、ということです。競合よりも先にユーザーに届けられるか？ 届けられなければ、困難が待ち受けています。内部のベロシティを測るのに時間をかけすぎてしまうと、プロセスの効率化に夢中になる一方で、市場を見失ってしまうリスクがあります。
IBMでは、スクラムのような特定のアジャイルプラクティスによる標準化はしないことにしました。それでもIBMでアジャイルはよく使われています。プロダクト開発チームにデザイナーを参加させ始めたとき、すでにチームが使っているアジャイルのプラクティスに加えて、デザイン思考から学んだユーザー中心の考え方をスケールさせるプラクティスも加えることにしました。スクラムチームレベルだけではなく、「チームのチーム」という大きなレベルに対してもです。「チームのチーム」のように大規模にプラクティスをスケールさせるには、何を達成したいのかというメンタルモデルを共有することが必要です。
アジャイルの3つの原則が大組織に意味のあるインパクトを与えられるという素晴らしい例
・内部ベロシティがゴールでないと明確に理解してから始めている点
・開発速度の向上を目指して始めるアジャイルへの取り組みも多いが、エンタープライズデザイン思考は、顧客視点でのスピードが必要であることを理解して開始している。
・企業に共鳴する言葉を利用している点
1章でも説明したが、顧客フォーカスとユーザビリティを目指す組織にとって、デザイン思考の視点は欠くことができないと認識されつつある。アジャイルとデザイン思考の公式な差で止まることなく、IBMは組織に対していちばん意味のある形で用語を利用した。
・顧客体験を中心にして、異なるチームや職能の人たちを団結させた
アジャイルの原則に即したプラクティスのなかで、プレイバックほど人を結び付けるものはない。機能横断的なコラボレーションを促し、軌道修正するための機会をあらかじめ組み込み、それらを顧客体験を中心にして進められるといった効果がある。
・「プッシュ」ではなく「プル」によるスケール
「今では、全員プレイバックをやっている」と「チームのイテレーションではプレイバックは必須としている」の差を認識してほしい。組織にプラクティスが適合し、リーダーシップのサポートが得られれば、プラクティスは自然にチームのあいだにスケールするようになる。
特定のプロジェクトやチームが「極めて重要」なのでアジャイルの原則とプラクティスは適用しないということほど、アジャイルの推進を阻害するものはない。みんなに見られながら自分のアイデアに取り組むことに耐えられない上級役員が、顧客中心主義と市場へのすばやい反応を実現するためのアジャイルプラクティスを捨ててしまうのを何度も見てきた。有名なGoogle GlassやAmazon Kindle Fire Phoneの失敗は、顧客中心主義のベストプラクティスを使わずに、役員の指示でプロダクトを作るとどうなるかを如実に示している。Fast CompanyはAmazon Kindle Fire Phoneの失敗の記事（https://bit.ly/2QvhkM1）のなかで、Amazonの従業員の言葉で、なぜ失敗したかを伝えている。「私たちは市場のためでなく、CEO ジェフ・ベゾスのための電話を作っていました」。
組織において、ある期間のうちに一定数のチームがアジャイル手法のルールや儀式に従うようにすると宣言してしまうと、それらは義務になってしまいかねない。だが、これらのアジャイルプラクティスが、根底にあるアジャイルの価値と原則に一致していない場合、緊張が生じてしまう。その緊張は、自分たちの文化、自分たちのリーダー、顧客へ奉仕する方法についての難しい問いを浮き彫りにする。
ここにアジャイルの見かけによらず強力な点がある。アジャイルプラクティスが速度と成功の銀の弾丸ではないことを組織が徐々に気づくようになっても、そのプラクティスに紐付いた価値と原則は、別のより深い変化の可能性を拓いてくれるのだ。個人やチームが価値と原則を学べば学ぶほど、自分たちの仕事の共通の目的を見つけられるようになるのだ。これは、アジャイルソフトウェア開発宣言の署名者たちが、それぞれのアプローチや手法から共通の目的を見つけられたのと同じである。
アジャイルの未来について1つ望むのは、価値を実現するための戦術を徹底的に議論するのではなく、共通の価値と原則を積み重ねることだ。非常に多くの企業がアジャイルプラクティスの採用に興味を示しているという事実は、アジャイルの価値と原則を日々の仕事に適用する素晴らしい機会を与えてくれた。だが、フレームワークの罠を避けて、本当の意味で組織を変革したいなら、アジャイルはプロセスや効率よりも、人と文化に関することであると常に主張しなければいけない。
価値と原則から始めることで、ソフトウェアエンジニアや特定のフレームワークのトレーニングを受けた人だけでなく、本当にすべての人がアジャイルにアプローチできる道を示せるのだ。そうすることで、アジャイルプラクティスを実践している人はみんな、自分自身の視点や専門知識を持ち込めるようになる。自分たちの働き方にオーナーシップを感じられるようになり、優先順位、チーム、顧客の変化に応じて軌道修正できるようになる。簡単な答えはない。だが、今から一緒に始められる有意義な仕事がたくさんあるのだ。
0
-
ライトにアジャイルを学ぶために、というノリで手に取った。その目的には合致してた。
・ライトだったので、本質っぽいものは手に入らない
・ただ本質っぽいものは、書籍からはそもそも手に入らないかもな、と読んでて思った
・それだけ、アジャイルを使っていくうえでは、実践でいかに苦労するか、が推察される、そんな本だった。
・ただし、ネガティブではない。それだけ取り扱いが難しい、難易度が高いもの、がアジャイルなんだろう(前説で及川卓也氏が、アジャイルはおすすめしない、と言ってるぐらいなので)
--
- リーン、デザイン思考などとも、似ている。同じことを違う言葉で示しているだけのこともある。大別すると、リーンは効率性、デザイン思考はユーザビリティ、アジャイルはベロシティ(機能リリースまでのスピード)を特に重視するという点で異なるが、その程度。
- cf. ガートナーは順番に示している(これのほうがわかりやすい気もする) https://ncdc.co.jp/columns/6354/
0
-
あらゆるビジネスにアジャイル開発のエッセンスを注入するインサイトを提供してくれます。
アジャイルを導入したけど以下の問題が拭えないという方は、特にお勧めできると思います。
・アジャイルな手法を導入したけど効果が感じられない
・アジャイルのマインドセットを説いても宗教のような印象を持たれてしまう
私もムーブメントとしてのアジャイルを推進できるように精進します。
0
-
開発チーム内にアジャイルのやり方を導入するのは形式的なものであったとしてもそれなりに上手く回るしそれなりの恩恵を得ることができる。しかし組織全体にアジャイルを導入するとなると非常に困難なものとなる。今の作業をアジャイルプラクティスの名称に置き換えただけで実際には何も変わらない。本書では組織にアジャイルを導入するためのアドアイスをしてくれる。まずアジャイルとは何か？から「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」そして「これら3つの原則に従い、速くて柔軟で顧客第一」という原則を導き出す。その原則ごとに組織がなぜアジャイルができないかを明らかにし、何をしなければならないかを説明している。その際、経営やマーケティングなどのチームが実践するためのポイント、良い方向に進んでいる兆候、悪い方向へ進んでいる兆候を示すことでアジャイルの導入の手助けをしてくれる。本書ではいくつかの企業の例が掲載されているが、アジャイルなやり方であるがアジャイルをやっているとは言っていない企業も存在する。また、スクラムやスプリント、レトロスペクティブなどのアジャイルの技法の解説もない。このことからアジャイルというのは手続きではなく考え方であるということを再認識させてくれる。
0
-
-
何か具体的な手法を求めていたのに何も書いてないとレビューしている人がいて、本の中身何も読んでないねんなというのが可視化されていた。
0
-
アジャイルはムーブメント。
この一言が伝わる内容。人間との対話視点だとふりかえりがほんと大事だなと。
「継続的改善とは、継続的に自分の問題を告白し、対応していくこと」という一文に出会えただけでよい。
0
-
「みんなで」アジャイル。 本当にすごい本だった。 昨年、先輩に紹介されて絶対買わなきゃと思ったメモが一年経過してしまったのですが、ようやく調達・購入できました。遅くなってすみません、という感じです。
というのも、本書の邦訳を担当されている、吉羽 龍太郎さん、そしてまえがきを担当している、及川 卓也さん、両名わが社の技術顧問としてご支援いただいておるのです。 僕は残念ながらソフトウェア技術者ではなくて、今は営業を担当している職責なのですが、相当気になっていた本で、読めてよかった。
「変化に対応できる顧客中心組織のつくりかた」という副題がとても素敵だと思いました。 企業変革のプロジェクトにいくつか関わっており、今後とも、ぜひ参考にしたいと、二度読み・熟読・ふせんはりはり・ライン引きまくりしてました。
本当に、「みんなで」アジャイル。 組織変革を行っていく上で、アジャイルの価値と原則がどのように効果的か、を説いてくれている本。 200ページもない本ではありますが、（企業理念・信条策定に関わった皆様、支店のビジョン策定に関わった皆様含め）本当に多くの方に読んでいただきたいと願う。
僕にとっては、実はかなり手ごたえのある、というか難しかった本なのですが、ちょうど先日『This is Lean』を読み切ったこともあり、なんとかどうにか理解を進めることができました。（重要なのは、「顧客の目で見たスピードだけだ」の記述も含め。） P16に記載されていたアジャイル、リーン、デザイン思考の整理が、ものすごくわかりやすくて、ストーーンと腹落ちしました。ナルホド！！！と一人で大きく感動しておりました。（そしてこの本に続いては「アジャイル開発とスクラム 第2版」を読んでみる予定）
二度読みして、この本の立体的な構造が理解でき、あらためてナルホド！と思いました。 本当に多くの方に読んでいただきたい。 すごすぎて伝えたいことが多くて、投稿（引用）のボリュームも相当多くなってしまった。。
本書の内容としては、「アジャイルソフトウェア開発宣言」の全文から「価値」を伝え、アジャイルを「ムーブメント」と捉えることにより、『手法とマインドセットの両方』を変化させ、アジャイルの3つの「原則」を各章にて分析・解説して、最後に「すべてをつなげる」として、さらにプレイブックもつけて行動を促す、という構成。
P163 の終わりに、に以下記載があって、ずしんと来る。
本当の意味で組織を変革したいなら、アジャイルはプロセスや効率よりも、人と文化に関することであると常に主張しなければいけない。
価値と原則から始めることで、ソフトウェアエンジニアや特定のフレームワークのトレーニングを受けた人だけでなく、本当にすべての人がアジャイルにアプローチできる道を示せるのだ。
ということで、いつもの抜粋引用に入る前に、「価値」と「原則」の部分を抽出しておきたい。
＝＝＝＝＝
『価値』
プロセスやツールよりも個人との対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
価値とする。
＝＝＝＝＝
＝＝＝＝＝
『原則』
・顧客から始めるのがアジャイル。
・早期から頻繁にコラボレーションするのがアジャイル。
・不確実性を計画するのがアジャイル。
＝＝＝＝＝
そして6章には 「3つの原則に従い、速くて柔軟で顧客第一なのがアジャイル」 とタイトルされていた。
以下、改めまして抜粋引用となります。(ふせんはりはりしすぎで多いです)
＝＝＝＝＝＝＝
○はじめに
アジャイルは単にプロセスやツールについてではなく、人や文化についてのものだということだ。（中略）
実際、アジャイルの本当に強力な点は、具体的で実行可能なプラクティスを提供していることだけでも、人を活気づけるような原則によって導かれていることだけでもなく、必然的にそれら両方を含んでいることなのだ。アジャイルは私たちの理想と行動を互いに密にし続けることを要求する。そのため、私たちが何らかの行動をするときには、なぜ個人、チーム、組織としてその行動をするのかを自問するよう求めるのだ。
本書は、顧客中心主義、コラボレーション、変化に対してオープンであることが現代の組織の中心にあるべきだと信じる人のためのものだ。
アジャイルソフトウェア開発宣言の署名者の一人の言葉によると、アジャイルムーブメントは「相互の信頼と尊敬にもとづく価値観の集合であり、人を中心とした組織モデルの推進、コラボレーション、そして働きたいと思えるような組織的なコミュニティの構築である」という考えにもとづいていた。
○P15
今日の不確実性の高い環境においては、顧客について学習することに寄与しないものは、リーン用語で言えば、すべてムダであるということだ。
（中略）
すなわち、急速に変化する世界において、組織はどのようにして顧客のニーズを満たすことができるのかという課題だ。これらのムーブメントの解決策はそれぞれ少しずつ異なるものの、顧客中心主義、コラボレーション、変化へのオープンさ、といったような類似した価値観を原動力にしているという点では同じである。
○P26
成功するアジャイルの適用は、常に厳しく正直に現状を見ることから始まる。何がうまくいっていて、何がうまくいっていないのか。
○P29
「アジャイルの価値と原則をどのように捉えたら、私たちのチームや組織のゴールを達成するのに役立つだろうか？」と質問することで、導入後にアジャイルを軽視したり無視したりしようとする人たちの疑念や分断を払しょくできる。
○P35
アジャイルの旅を成功させるには、単に人がどう協力し合うかだけでなく、顧客のためにどう協力しあうかが重要なのだ。（中略）
顧客中心主義は役割、チーム、職能を越えて組織を一体にして連携させる概念だ。顧客中心主義によって目的意識を共有し、ツールセットや手法に関係ない共通の成功の基準がもたらされる。
○P40
顧客の視点から速度を見るとはどういう意味だろうか？ 私たちが答えるべきいちばん重要な質問は「多くの作業をどれくらい迅速にこなしているか」ではなく、むしろ「どれだけすばやく顧客に価値を届けられるか」だ。
○P60
顧客から始めることが重要になるのだ。 顧客から始めることで、絶えず変化を続ける顧客のニーズやゴールを、何を作るか、そしてどう作るかにつなげていくだけの余裕を持てるようにするのだ。
○P63
本当のコラボレーションには、主義主張を超えて、オープンであること、弱さを認めること、当事者意識を共有する意欲が必要だ。
○P68
こういった組織は、根本的な文化の転換が必要だ。 報告と批評の文化から協調的な文化への転換である。
○P81
なぜデイリースタンドアップをやっているかを明確にする
（中略）デイリースタンドアップに価値がないと感じているようだったら、手順に従わないのを責めるのではなく学習の機会であると捉えよう。 チームのメンバーと、このプラクティスからどんな価値を得たいかについて会話をしよう。それから、今のプラクティスから価値が得られていない理由は何かについても会話をしよう。
○P90
オープンな環境で失敗するという選択をすること、つまり完成して洗練する前に共有すること、プロジェクトの全体的な形や方向性に対するインプットを求めることは、本当のコラボレーション文化に対する貢献になる。
○P93
アジャイルソフトウェア開発宣言は私たちに「計画に従うよりも変化への対応」により価値を置くことを気づかせ、アジャイルは私たちが従う実際の計画に対して堂々と変化を取り込む方法を教えてくれる。
○P99
変化を拒むのではなく変化を祝うことで、この新しく手に入れた柔軟性に注目を集められるようになる。（中略）「今この問題が見つかってよかった。四半期目標を達成する時間があるうちに軌道修正しよう」と言えるのだ。
（中略）組織全体が本来あるべき「アジャイル」でないと責めても、チームの士気とモチベーションを落とすだけだ。代わりに、組織の現実的な制約を踏まえて、何ができるかに焦点を合わせよう。
○P105
私はチームに「これは実際のところどう役に立つのですか？」と言わなければいけませんでした。（中略）顧客のために私たちが作り出す価値を通じてその焦点が理解できるような、より大局的で方向性がはっきりした考え方を取り入れる方法について話し合いました。これは、多くの決まり切ったアジャイルの儀式から離れて、チームとして「どうすれば、私たち自身と顧客が望む成果を達成できるだろうか」と聞き続けることをを意味していました。
（中略）最終的には、「本のとおり」にアジャイルを実践することで得られる安心感か安全間を捨て、チームの人たちにとって最適なプラクティスを見つけることが必要になる。
○P107
みんなを集めてオープンな対話をしなければ大きな問題になってしまうような馬鹿げた問題や誤解はたくさんあるのです。チームの前で自分のことを表現できるようなセーフティネットさえあれば、そこから十分に始められることもあります。
○P119
変わり続ける顧客のニーズを満たすために、一緒に働く個人の集まりが組織なのだ。組織の個人個人には、組織を速く、柔軟で、顧客第一にする役割がある。その意味では、「みんなでアジャイル」は、アジャイルの適用範囲が広いという意味にとどまらない。アジャイルは組織の全員に適用されたとき、一番効果を発揮し、変革を促進する。どんなレベル、チーム、役割でも、日々の仕事に原則を適用しなければいけない。
○P120
チャレンジが大きくなるにつれ、華々しいアジャイル用語でないアジャイルの根底にある価値観が、長年「いつもどおりのビジネス」を回してきた組織のリーダーたちのふるまいやきたいと合致しなくなるということだ。
○P124
価値を足し無駄をなくすには、継続的に改善しなければいけません。理解していないリーダーも多いですが、「継続的改善」とは、継続的に自分の問題を告白し、対応していくことなのです。
（中略）
アジャイルの適用によって失うものがいちばん多いミドルマネージャーのような人たちと働くときは、特に気を付ける必要がある。ミドルマネージャーの仕事は、注意深く上向きと下向きの情報の流れを管理することだった。アジャイルが信条とする透明性とコラボレーションとは逆の動きだ。
○P149
アジャイルの3つの原則は、すべて合わさったとき、明確で強い力となる。変わり続ける顧客ニーズを満たすために一緒になって働くのだ。これが本書の議論の目的だが、言うは易し、行うは難しだ。だが、オープンさと可能性を見出しながらアジャイルに取り組んでいけば、より良い新しい仕事のやり方を見つけられる可能性は常にある。
○P155
あなたの原則も顧客中心主義、コラボレーション、変化への対応という考え方をチームに響く特別な言葉で捉える必要がある。ここでは、一歩下がって組織レベルに立って、これらの原則がチームや職能に関係なく理解できるような言葉になっていることを確認する。
＝＝＝＝＝＝＝
0
-
組織重力
第一の法則:組織に属する個人は日々の責任やインセンティブと整合性がなければ顧客と向き合う仕事を避ける
第二の法則:組織における個人は自分のチームやサイロの心地よさの中で一番簡単に完了できる作業を優先する。
第三の法則:進行中のプロジェクトはそれを承認した一番上の人が止めない限り止まることはない。顧客ニーズや企業目標に合致しないことが明らかになっても、続けられる可能性が高い。
メールやチャットでのコミュニケーションは一見仕事しているように見えるし感じるが恐ろしく非効率。早期に直接会話してコラボレートすること。
報告と批判の文化か、協調的な文化かデイリースタンドアップを診断に使う。
組織における固定サイクルを洗い出し、それに逆らうのではなくそれに合わせた仕事をする。
組織の人間はリーダーが言っていることではなく、リーダーがやっている行動をまねる傾向がある。
0
-
この本にはプラクティスの話は殆ど出てこないし、なんならソフトウェア開発（だけ）の話も登場しない。
書かれているのは 3つの基本的な原則と それぞれに対応する組織重力の法則と筆者が呼んでいるもので、そのシンプルさが私としては良かった。
特に 4章の「早期にコラボレーションするのがアジャイル」は 現在自分が置かれている状況に照らして一番気づきが多かった。
時折見返したい本。
0
-
思い込みで進めてダメなところなどが羅列されているが
サブタイトルの「変化に対応できる顧客中心組織のつくりかた」についてはほとんど書かれていないのではないか
アジャイルを知っている人が、
あんたんとこもだめ？うちもだめだよ？
と楽屋落ち的に盛り上がる本なのかな
0
-
様々な人々とアジャイルによって達成するべき事を中心に書いてて、非常に良い内容だった。
アジャイルを現状の開発プロセスを良くしたり、ビジネスを成功するための銀の弾丸と受け取りがちの人が、失敗してしまう原因を捉えてると思った。
0
吉羽龍太郎の作品
