この本は、ソフトウェア開発手法としてのScrum（スクラム）だけでなく、教育、製品開発、研究機関、マスメディア、国防などの分野で広く活用できる新しいプロジェクト手法の外観をつかみ、各業界での活用例やScrum活用のポイントについてを抑えることができます。
Scrumの開発手法が発表されて既に数十年たち、今ではアメリカを中心に活用事例が集まりつつあります。国内ではまだまだIT業界中心かもしれませんが、PM系学会のPMI（Project management Institute）やBA系学会のIIBA（International Institute of Business Analysis)ではIT業界以外でのAgile（特にScrum）を使ったプロジェクト手法の採用が増えてきているようです。2018年のIIBA Salary Surveyによると約70%のBAがAgile手法を利用し、中でもScrumが80%を占めているというレポートがあります。時代の変化に合った俊敏性や柔軟性を持ったAgileは今後ますます活用が進むでしょう。一方でScrumが合わないプロジェクトもあるように思いますので、引き続きウォーターフォール型プロジェクトマネジメントも生き続けることでしょう。
本のタイトル：
Scrumというと日本ではまだIT業界、特に開発チームでの話題が多いので必然的にスクラム・マスターやチーム（開発）についての話題が多いように思います。しかしここではScrumでキーとなるプロダクトオーナー（以下PO）について簡単に触れたいと思います。スクラム・マスターやチームとPOとでは行動の基準が異なります。チームやスクラム・マスターは仕事を進めるスピードをどれだけ上げられるかを各スプリントを通して改善していくことを行動基準としますが、POはそのTeamの生産物を価値としてアウトプットすることをにあります。
著者はPOに求められる能力には主に次の4つの要素が必要だと述べています。（参照：第8章 優先順位）
①仕事の領域に精通していること。
POはチームの生産性を価値としてアウトプットする責任があるので、『チーム全体の明確な目的意識とチームの自主性を持つこと』がスクラムにおけるプロダクト開発の成功には欠かせないことだといいます。確かに状況は刻一刻と変わるものだが、プロダクトの意義や各バックログアイテムのストーリーに一貫性を持ったディスカッションが出来なくては、開発チームは混乱するかもしれませんし、思ったものと違ったものが出来上がってしまうかもしれません。また、開発チームは、POと合意したプロダクトバックログを作りステークホルダーに公開するので、ここが顧客から否定されるようなフィードバックが来てしまうと、顧客との窓口になっているPOへの信頼感が揺らいで、強固なスクラムチームを維持することができないのです。
Scrumの開発手法が発表されて既に数十年たち、今ではアメリカを中心に活用事例が集まりつつあります。国内ではまだまだIT業界中心かもしれませんが、PM系学会のPMI（Project management Institute）やBA系学会のIIBA（International Institute of Business Analysis)ではIT業界以外でのAgile（特にScrum）を使ったプロジェクト手法の採用が増えてきているようです。2018年のIIBA Salary Surveyによると約70%のBAがAgile手法を利用し、中でもScrumが80%を占めているというレポートがあります。時代の変化に合った俊敏性や柔軟性を持ったAgileは今後ますます活用が進むでしょう。一方でScrumが合わないプロジェクトもあるように思いますので、引き続きウォーターフォール型プロジェクトマネジメントも生き続けることでしょう。
本のタイトル：
原題）Scrum
- the art of Doing Twice the work in half the time / Jeff Surtherland
ジェフ・サザーランド
著者： Jeff
Sutherland/ジェフ・サザーランド
出版社： 早川書房
分類： ビジネス書
発行日：2015年6月25日（初版） - 2020年1月時点で第6版まで発行済
1. この本を読むきっかけ
大学院でAgile開発の一つとしてScrumに関する講義を受講したことがきっかけです。ちょうど2019年ラグビーワールドカップ開催時期だったため妙な盛り上がりが自分の中にもありました。PMPの試験勉強をしている際にもアジャイル概念が出てきたので、改めて読み直してみて、私なりに気になってポイントをまとめます。
2. この本をお勧めする読者
この本は、Scrumの概観を知り、Scrum採用の意義を理解知りたい人には、最適な導入本であると思いました。
本文の大半は、アメリカで発行されるビジネス手法や成功本のように、その方法がどのように効果的だったかといったストーリーが語られていますが、この本はその点が簡潔に語られているのでさらっと読めます。
これからスクラムを始めてみたい開発者、PM、プロダクトオーナー、企業の代表の方などどの層でもスクラムの外観をつかむための1冊目としておすすめです。
本文の大半は、アメリカで発行されるビジネス手法や成功本のように、その方法がどのように効果的だったかといったストーリーが語られていますが、この本はその点が簡潔に語られているのでさらっと読めます。
これからスクラムを始めてみたい開発者、PM、プロダクトオーナー、企業の代表の方などどの層でもスクラムの外観をつかむための1冊目としておすすめです。
3. Scrumの外観と各役割
3-1. Scrumをどう実践するべきか？外観をつかもう！
Scrumとは何なのか、これからどう実践したらいいのかを知りたい方は、本書のなんと付録「付録のスクラム実践 - 今日から取り入れるにあたって」にまとめられています。ですので実はScrumがなんなのか、どう実践するかを知りたい方は付録から読んでいただくのをお勧めします。そのうえで、本書の冒頭から読み進めると、Scrumのプロセスの中のどこについて注意を払うべきか理解が深まります。3-2. プロダクトオーナーの人物像と評価軸
Scrumというと日本ではまだIT業界、特に開発チームでの話題が多いので必然的にスクラム・マスターやチーム（開発）についての話題が多いように思います。しかしここではScrumでキーとなるプロダクトオーナー（以下PO）について簡単に触れたいと思います。スクラム・マスターやチームとPOとでは行動の基準が異なります。チームやスクラム・マスターは仕事を進めるスピードをどれだけ上げられるかを各スプリントを通して改善していくことを行動基準としますが、POはそのTeamの生産物を価値としてアウトプットすることをにあります。
著者はPOに求められる能力には主に次の4つの要素が必要だと述べています。（参照：第8章 優先順位）
①仕事の領域に精通していること。
②決定権を行使できること。
③すべきことは何か、またなぜそれが必要なのかをいつでもチームに説明できること。
④価値を説明できること。
POはチームの生産性を価値としてアウトプットする責任があるので、『チーム全体の明確な目的意識とチームの自主性を持つこと』がスクラムにおけるプロダクト開発の成功には欠かせないことだといいます。確かに状況は刻一刻と変わるものだが、プロダクトの意義や各バックログアイテムのストーリーに一貫性を持ったディスカッションが出来なくては、開発チームは混乱するかもしれませんし、思ったものと違ったものが出来上がってしまうかもしれません。また、開発チームは、POと合意したプロダクトバックログを作りステークホルダーに公開するので、ここが顧客から否定されるようなフィードバックが来てしまうと、顧客との窓口になっているPOへの信頼感が揺らいで、強固なスクラムチームを維持することができないのです。
なお、POの評価をする必要がある場合には、そのスプリントのポイント当たりに生み出した利益を図るという方法が紹介されているので、明確なプロダクトのリリースが金額指標に結び付けられる場合は採用価値があるでしょう。
4. チームの成長を促進させる、レトロスぺクティブの勘所
レトロプロスぺクティブといえば、そのスプリントでうまくいったことやどうやったら次のスプリントをうまく回せるかというチーム活動における課題を考えることです。しかし、スプリントをこなしていくとこの改善点が出てこなくなり、膠着状態になる場合があるでしょう。そんな時は、目に見える課題ではなく「チームの幸福度」という切り口からカイゼンを促すという手法が紹介されています。また改善活動がモチベーションの低下や慣れにより膠着した際のポイントも、当たり前のようでついつい忘れがちです
以下にその具体的なポイントをまとめます。
以下にその具体的なポイントをまとめます。
4-1.チームの幸福度
Scrumは同じチームでやり続けるのが理想とされています。ある程度チームが慣れてくると成長の停滞期に差し掛かるかも。レトロスペクティブをしてもデイリースクラムもただの業務連絡になっていないでしょうか？メンバーはそれで満足しているでしょうか？
著者によるとチーム活動における成長促進要因として「幸福度」は重要項目の一つだといいます。チームが今どのような状況にあるのか「幸福度の計測」により改善課題と改善案をあぶりだすことができます。（第三章 チーム）
この時に重要なことは「合格判定基準」を設けておくことです。なぜなら、何をもってその課題が解決されたかを図る指標（＝バックログの達成基準）がなくては改善したかどうかが分からないからです。
チーム活動における「幸福度評価項目」
1. 会社内での自分の役割について、一から五までのスケールであらわすとどう感じているのか
2. 同じスケールで、会社全体についてどう感じるか。
3. なぜそう感じるか
4. 何を一つ買えれば次のスプリントでもっと幸せだと感じられるか
レトロスペクティブがただの業務連絡になってしまっている場合には、こういった評価項目を入れていくと、チームのパフォーマンスを向上する課題を見つけてみるとよいでしょう。
4-2. 非難は無駄 - 建設的なレトロスぺクティブのポイント
Project managementの世界では、チームの成長過程によってメンバーの衝突などの過程があるといわれています。Scrumでももちろんこれは起こりえます。むしろ、チーム内のディスカッション機会や意思決定をする機会がウォーターフォール型プロジェクト手法よりも頻度が高いため意見の食い違いや前提理解の相違でバックログの消化が思ったより進まないといったこともあるでしょう。
Scrumではこういったスプリントの進行を遅らせたり開発を阻害要因をどのように排除するかを、レトロスペクティブで話会います。
問題を話し合うときに注意が必要なことは、「根本的な帰属の誤り（Fundamental
Attribution Error）の回避です。
”一方で言えるのが他人を非難するときはその人個人の欠陥を攻めたのに対して、自分が非難される側になった時は、問題の発生に至った背景や、自分がなぜそう行動したのかといった全体像にもっと目をむけているのではないのかということだ。”
つまり、レトロプロスぺクティブではうまくいかなかった原因を話し合う場では、チーム全体が感情面において大人であること、チームに信頼関係という土壌が必要でです。自己弁護や他者批判ではなく、問題解決志向で取り組むことの重要性を指摘しています。
実際に所属する様々な組織活動において、感情的な”反省会”場面に出くわす場合もあります。私は時折ファシリテーターとしては社内の会議進行や意見の整理などをする機会が多いのですが、自分が中に入ってしまうとその感情にひっぱられそうになることがあります。そんな時は、数歩引いて全体を俯瞰し、その失敗に至った原因はプロセスにあるという点にフォーカスしてディスカッションできるように働きかけるように努めていきたいと思う次第です。
5. まとめ
Scrumは実際にやってみて様々な疑問にぶつかることがあります。この本はそういった細かな疑問に答えるものではありませんが、Scrumを始めるならばScrum創設者のひとりである著者のこの1冊は目を通すことをお勧めします。なぜかというとこれがScrumの”型”だからです。本書は『守・破・離』として紹介されています。何か新しいことを学ぶとき、まずはその『型』を覚えその流れを守って実践します。慣れてきたらそこに肩を『破』って工夫を加えてみる、そして最後に『型』から『離』れて流れに身を任せるのだそうです。本書ではこれを武道で例えていますが、基本を知らずに一足飛びにうまくいく方法はないということともとらえられます。基本を知り、工夫をして、その時最善の取捨選択をできるようになるのが理想ですね。
我々を取り巻くビジネス環境は日々変化しており、STEP BY STEPの手法ではうまく回せないことも増えてきました。
去年の年始に決意した目標を年末にやり残したと後悔することはありません。それはその一年間、もしかしたら自分にとって重要ではなくなったことかもしれません。もちろん、その”目標”が昇進の条件だったり人生の転機に必要なアクションなら、今年こそは優先順位をあげて実行可能なサイズで切り分けて、取り掛かったほうがいいことは言うまでもありません。
Scrumの細かな疑問や関連書籍は日本語版も増えてきましたので、順次読んで記録に残していきたいと思います。
コメント