ブログ

ryuzeeによるブログ記事。不定期更新

スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた

みなさんこんにちは。@ryuzeeです。

以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。

なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。

それでは、行ってみましょう。

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。 チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかったりする場合は、ある程度カタにはめることで機能するようになっていきます。 一方で、チームが機能するようになれば、チームが自分たちで良いと考えたことをやるようにしていけばよく、ただカタを守らせるのは無意味になります。 つまり、チームを継続的に観察して、チームの状況によって、打つ手を変えていく必要があります。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

アジャイルを適用する理由は、プロダクトのデリバリーの円滑化のためなので、アイデアが生まれてから実際にデプロイするまでのリードタイム、デプロイの回数はわかりやすい指標です。 また、変化に対応して最大の成果を上げるという観点では、売上やコンバージョンレートなどのビジネス面での指標も参考になります。 スクラムマスター自体の評価は、チームが成果を出せているかどうかでよく、スクラムマスター専用の指標は別のインセンティブを作るだけです。

追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

これは上の質問と同じ回答になります。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

ベロシティが安定しない理由は、選択したプロダクトバックログアイテムが完成したり完成しなかったりすることに起因します。 これは、プロダクトバックログが大きすぎる、プロダクトバックログが具体的でない(Readyでない)状態で、無理にスプリントに投入することによって起こります。 開発チームが扱えるサイズにプロダクトバックログアイテムを分割すること、プロダクトオーナーが生煮えのプロダクトバックログアイテムをスプリントに投入しようとした場合は全力で止めること、プロダクトバックログリファインメントを継続的に実施してちょっと先まで準備をしておくことなどが必要になります。 スクラムチーム自体がスプリントレトロスペクティブで、この事象を問題だと考えて改善することが望ましいので、もしレトロスペクティブの議題としてこれがでないようであれば、毎回終わらないことについて聞いてみるとよいでしょう。

製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

参加した方がよいです。プロダクトオーナーはプロダクトの責任者なのでディスカバリーの内容を踏まえてプロダクトバックログをどうするか考える必要があります。 また開発チームは、単なるプロダクトバックログアイテムを開発するマシーンではなく、プロダクトの価値を実現する一員なので、ディスカバリーに参加したほうが、自分たちに何が求められているか理解できるはずです。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

プロダクトオーナーしかできないこと、プロダクトオーナーでなくてもできることを分類して、プロダクトオーナーでなくてもできるものは開発チームや、その他の人がやるようにします。 プロダクトバックログについても、並び順の最終決定権限はプロダクトオーナーにありますが、プロダクトバックログアイテムを用意する責任がプロダクトオーナーにあるわけではないので、ほかの人が準備をしても構いません。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

これは最初が肝心かもしれません。プロダクト立ち上げの時点で、ステークホルダーにもアジャイルなやり方の考え方、スクラムの概要などを説明して理解してもらい、継続的に関与してもらえるようにします。 ステークホルダーの教育が不足していると、関与の度合いが下がったり、途中でちゃぶ台返しが発生したり、プロダクトオーナーが自分でプロダクトバックログの並び順を決められなくなったり、といった問題が起こります。

どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

関係者をあつめてトレーニングするのが王道ですが、一方で身近に成功事例がないと関心をもってくれないので、最初に1プロダクトを意地でも成功させて周りの注目をあつめるように仕向けるとよいかもしれません。

上級管理職にどのようにスクラムを紹介するか

スクラム自体はIT以外の仕事にも適用可能なので、不確実性が高い状況において成果を出すための考え方、という立て付けで説明します。

あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

激しい抵抗を受けたことはないですが、もし抵抗されるようであれば、何か懸念点があることの証なので、理由を聞いてみるのがよいでしょう。 それから、変化に対して恐怖を持つ人、失敗するリスクを極端に恐れる人がいることは事実なので、まずは安全な環境で実験してみて、安全であることを理解してもらうのもありです。 それでもだめなら、相容れないので、その人を無理に巻き込むのは止めます。合う合わないは少なからずあります。

プロダクトバックログのリファインメントと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログアイテムに落とし込んでその見積りをチームに求めることになる。その流れでよいか?

その流れもある、というのが正しいです。 プロダクトオーナーはプロダクトの結果責任を取るので、なんでもかんでもステークホルダーの言うことを聞いて、それをプロダクトバックログアイテムに落とさなければいけないわけではなく、自分で思いついたアイデア、開発チームから出たアイデア、スプリントレビューのフィードバックの内容などをプロダクトバックログアイテムとして追加します。 ステークホルダーの言うことを全部聞かなきゃいけないのであれば、プロダクトオーナー役はステークホルダー自身にやってもらった方がよいのではないでしょうか?

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

プロダクトオーナーがステークホルダーと握っているKGIやKPIの項目と、その数値がどうなっているか。 開発チームはプロダクトオーナーと運命共同体なので、プロダクトオーナーがどんな成果を達成しなければいけないのかを知っている必要があります。 それを知っていれば、役に立たないプロダクトバックログアイテムを提案することもないですし、同じ成果を達成するもっと簡単な方法を提案できることもあります。

誰がユーザーストーリーを書くとよいか?

誰でも書いて構いません。 プロダクトバックログアイテム自体は、そもそも必ずユーザーストーリー形式で書かなければいけないわけでもありません。 プロダクトバックログの並び順を決められるのはプロダクトオーナーだけなので、誰かが書いたアイデアやストーリーは、プロダクトバックログのいちばん下とか別のインボックスなどに入れておいて、定期的にプロダクトオーナーが選別するとよいでしょう。

よいユーザーストーリーとはどんなものか?どんな構造か?

INVESTの性質を満たすとよい、とよく言われます。 それぞれIndependent(独立している)、Negotiable(交渉可能)、Valuable(価値がある)、Estimable(見積り可能)、Sized Right(適切なサイズ)、Testable(テスト可能)の頭文字を取ったものです。 また、そもそもという点では、「誰にとってどういう価値があって、なにができるようになってほしいか」が明確であることが重要です。 個人的にはストーリー形式でなければいけないとは思いません。 あくまで会話の道具なので、プロダクトバックログを見たり話したりした結果、全員で共通認識を持てるならそれで構いません。

「Readyの定義」には何が含まれているべきか?

「べき」という質問に対する答えはほとんどの場合、そんなの現場次第でしょ、となります。「必ず」も同じ。 とはいえ、最低限、開発チームとして、そのプロダクトバックログアイテムは何ができれば完成なのか分かっていて、大きな質問はなく、サイズの見積りができている、というくらいは必要でしょう。 そうしないと、スプリントに入ってから、実はやらなきゃいけないことがたくさんあることが後から分かって完成しなかった、みたいなことが頻繁に発生して、成果の量が不安定になり、予測精度が下がるためです。

ユーザーストーリーを時間で見積もらないのはなぜか?

スクラムでは、プロダクトバックログを見積もれとは言っていますが、時間で見積もってはいけないとか、ポイントで見積もらないといけないとは言っていません。 一般論で言うと、具体的な単位がついた見積りは、独り歩きしやすく危険であること、ムダに詳細化してしまう傾向にあること、サイズの見積りに工数を使った場合、それは今も将来も同じサイズのものには同じ時間がかかる前提となっているが、チームの能力は変化するため必ずしもそうはならないことなどが挙げられます。 とはいえ、見積りは頻繁に実施しますし、どんどん精度はあがっていくので、数字が悪用されないなら別に具体的な単位がついた数字でも構いません。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

本当に重要で必要であれば実施するでしょうし、とりあえず入れておいたアイデアはいつまでたっても実施しないかもしれません。 プロダクトバックログアイテムを、必ずすべて終わらせる保証などどこにもありません。 通常プロダクトバックログの下位になればなるほど、投資対効果が下がっていき、実施する意味は減っていく傾向にあります。 なお、一度にたくさん着手するのは仕掛中が増えて、成果がでるまでの時間が伸びるので、仕掛中のプロダクトバックログアイテムの数は減らすことがおすすめです。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

スプリントプランニングで、どのプロダクトバックログアイテムに着手するかを延々と検討するのでは遅いので、あらかじめプロダクトバックログリファインメントの場で、プロダクトバックログが最新の状態になるように手入れをするように促します。 手入れができているかどうかは、スプリントプランニングでの議論の内容や所要時間を観察することで判断できるはずです。 リファインメントのタイミングで、プロダクトオーナーに対して、なぜその順番にプロダクトバックログが並んでいるのかを説明してもらうようにすると、開発チームのメンバーが順番に対してフィードバックできるようになります。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

ビジネス価値とか、KGIとかKPIへの影響度合いでしょうね。目的を達成するために何かを作るので。 受け入れがたいメトリクスはあまり経験がないのですが、社内の政治的な話に起因するメトリクスに基づいて何かを作ってもプロダクトとしての成果には関係ないのでムダです。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

プロダクトバックログを上位から選ぶ際に、まず過去のベロシティと相当する程度のプロダクトバックログアイテムを選択し、その実行計画をたててみます。 その実行計画が妥当なものであれば問題ないですし、もし量が少なそうであれば、プロダクトバックログアイテムをさらに追加します。 もし量が多いようであれば、対象とするプロダクトバックログアイテムを減らすことを提案します。 あんまりぎちぎちにプロダクトバックログアイテムをスプリントに投入する必要もないので、もしプロダクトオーナーが毎回溢れんばかりのプロダクトバックログアイテムを投入したがるなら、それをやめるように提案します。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

チームによって違うので一概には言えませんが、2-3割くらいではないでしょうか。 機能開発だけにフォーカスしつづけると無理が溜まっていき、どこかでいきなり速度が落ちることもあるので、継続的に機能開発とリファクタリングのバランスをとってやっていくのがよいと考えます。 もちろん時期によって割合の変動はあるはずです。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

チームの誰がどのタスクをやるかはチームが決める話ですし、プロダクトバックログアイテムに担当者を割り当てると、あちこち完成しない状況になるって説明するところから始めます。 それでも聞かないようであれば、一旦個人で受けておいて、それをチームでやるようにすれば、いずれ気付くのではないかという気がします。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

自分の得意なタスクしかやらず、複数のプロダクトバックログアイテムからつまみぐいしてしまうと、これもあちこち完成しない原因になります。 チームとしてプロダクトバックログアイテム自体の同時仕掛り数を制限して、上から確実に終わらせるようにするのがひとつ。 ほかには、その人のスキルをつけてもらえばよいので、ペアプロ・モブプロなどを活用して、ほかのこともできるようにしていくのもよいでしょう。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

Readyではないので、さらに次のスプリントに回すようにするのが安全です。 とはいえ、最終的に確定していなくてもサイズが十分小さくて、現状の不確実性がチームで吸収可能だと判断でき、さらにそのプロダクトバックログアイテムは急ぎでやらなければいけないものなのであれば、着手してみてもよいのでは、という気がします。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

実際にすごく時間がかかっているのかもしれません。まずは参加したくない理由、時間のムダだと思っている理由を個別に聞くところから始めるのが良さそうです。 いきなりみんなの前で詰めるようなことをすると、色々こじれてしまうので避けておくのが無難です。

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

チームがスクラムで進めているのであれば、やるように薦めるでしょう。 とはいえ、この質問の背景には、チームがデイリースクラムに意味がない、と感じている状況だと思われるので、どんな話をしているのか観察した上で、進め方や話す内容を改善していくのが良さそうです。 個人的な意見としては、チームのサイズが小さくて、みんなが同じ場所にいるような状況では、いつでも気軽に同期を取れるので、デイリースクラムという名前じゃなくても、それ相当のことができていることが多いと思いますが、一方でチームのサイズが大きくなると、見えていないことやコミュニケーションロスが増えていくので、デイリースクラムの重要性が増すと考えます。

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

待たなくてよいです。むしろ早め早め、先手先手で解決していくほうがよいです。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

立場が上の人、声が大きい人がいるとそうなりやすいです。その人がデイリースクラムの目的を理解していないことに起因することが多いので、イベントの役割を別の場で説明してみます。 またデイリースクラムでの立ち位置をみんなの後ろにしてもらったり、試しに発言しないようにしてもらったり、場合によっては他のところに連れ出してみたりしてみます。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

まずはイベントの意味を説明して理解してもらうところがスタートでしょう。あとはデイリースクラムは必ずしも朝やらなければいけないわけではないので、遅刻しない時間に設定する手もあります。 また、デイリースクラム自体がそもそも形骸化していて、本当に意味がない可能性もあるので、デイリースクラム自体を観察して、機能しているのかどうかを確認する必要もあります。 それでもだめであれば、その人はすくなくとも、そのチームで働くのは難しいという判断をするかもしれません。その意思決定自体はスクラムマスターではなくて、チームのメンバーが下します。

スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか?

デイリースクラムは開発チームのためのイベントなので、別にそれでも構いません。 むしろ多数のステークホルダーが参加して、好き勝手に発言するほうが害になります。

分散チーム間のスタンドアップをどのように進めるか?

最近はビデオ通話のツールもだいぶ良くなっているので、そういうのを活用しましょう。

スクラムチーム用の物理カンバンボードをいま書いてください

たとえば、こんなかんじです。

ふりかえりについて

だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

スクラムチーム全体、つまりプロダクトオーナーと開発チームとスクラムマスターが参加します。 あとは、必要だと思うステークホルダーも呼んで構いません。 スプリント単位ではスクラムチームでやっておいて、4半期ごととかリリースごとにもうちょっと大きく全体ふりかえりする、というのをよくやっています。

チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

逆に確認しなかったらまずいです。 問題がないかどうか、問題にはどんなものがあるかを識別した上で、アクションプランを考えていく必要があります。 現状の把握もなく、思いつきでいろいろやってもムダな労力になってしまいます。 確認の方法は、チームの関係性にもよります。 成熟したチームであればディスカッションでも大丈夫でしょうし、そうでないチームであれば、なんらかのフォーマットを使うことになるかもしれません。

過去に使ったふりかえりのフォーマットはどんなものか?

タイムライン、Story of Story、WWW、Happiness Radar、Good/Bad、Fun/Done/Learn、KPT、闇鍋などなど。

どうやってマンネリを防いでいるか?

マンネリはやり方が同じだから起きるのではなく、同じ問題が何回も顕在化するにも関わらず解決しないことに起因することが多いです。 したがって、まずは少量でもよいので、チームで決めたアクションアイテムを確実に実行できるようにするところがスタートになります。 やり方のマンネリという点では、同じやり方を続けると視点が偏るので、複数のやり方を使い分けるのがよさそうです。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

最新のスクラムガイドだと、スプリントレトロスペクティブで選択したアクションアイテムを、最低1つは次のスプリントバックログに入れろと言っています。 複数のリストを持っていると、それぞれの順番をどう捉えるかがわからなくなるので、アクションアイテム自体をスプリントバックログやプロダクトバックログに入れていき、全体の中で管理するのがわかりやすいでしょう。 なお、いつも行動できない理由として、そもそもそのアクションが具体的でない、何ができたら終わりなのかはっきりしていない、自分たちで扱えるサイズより大きいといったことも考えられます。 具体的で測定可能にしないと放置されるので、プロダクトバックログアイテムやスプリントバックログのタスクと同様に具体的にするようにアドバイスするのも良さそうです。

どうやってアクションアイテムのフォローアップを進めるか?

上に書いたとおり。あとは次回のレトロスペクティブで実際にやったのか、効果があったのか、そのまま継続するのかそれともやめるのか、もっとよいやり方がありそうか、というような確認をするとよいです。

最後に

この38個の質問に対する答えは人によって違うものになるでしょうし、どれがあってる間違っているという話でもないはずです。 上に書いたのはあくまで私の見解というふうに理解してください。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック