Agile 101：アジャイル基礎講座 (日本語)

アジャイル基礎講座、Agile 101 にようこそ。こんにちは、アジャイル組織開発、チーフコーチの吉田です。

アジャイルとは何か？なぜアジャイルをやるのか？どうやってアジャイルを実践するのか？

アジャイル、スクラム、リーン、デザイン思考の違いは？

そして、アジャイルとアジリティの違いは？

本日はこちらのアジャイル基礎講座で、これらの疑問に答えていきたいと思います。

本講座の構成です。

第一部は、アジャイルとは何か？

第二部は、なぜアジャイルをやるのか？

第三部は、アジャイルはどうやって実践するのか？

こちらを順序だててご説明します。

最後に、アジャイルの最もポピュラーな実践フレームワークである、スクラムについて、入門編のご説明を用意しました。少し長くなりますので、こちらはオプションという位置づけで興味のある方が続けて学んでくだされば結構です。

では、はじめます。

まず、アジャイルとは何か、見て行きましょう。

私たちは仕事を、チームワークを円滑に進め、人を育てる英知を昔から持っています。

臨機応変さや工夫は、誰もが期待される、普段の仕事や日常生活での、自己裁量の美徳ですよね。

また、やってみなはれ、とか、当たって砕けろ！といったチャレンジ精神を鼓舞する言葉を尊敬する人からかけられた経験、みなさんありますよね？

さらに、なんでもかんでも最初から最後まで作りこむのではなく、まずおおまかに概要を作って、こんな感じでどう？、と適宜相談しながら物事を進めたりと、私たちは元来仕事にとてもクリエイティブなものです。

一方でこれらの英知を反故にする習慣もあるのは事実で、さらに問題は、こういった反義語が必ずしも愚行と言えないのも、この教えの難しさです。

やってみなはれ、と社長の後押しを受けたと思ったら、直属の上司からは確実なプランを見せてください、と出鼻をくじかれ、臨機応変に上手く対応したと思ったら、なぜ指図を守らなかったのですか、指示を仰がなかったのですか、叱責を受けたり…。サラリーマン人生あるある、ですよね。「おっしゃっていることはわかりますが、安全安定志向だけでは進歩も進化もないですよ」、と反論したいところですが、なかなか大変です。

それでも、新しいことを叶えるには、チャレンジしていかないといけない、変えていかないといけない、粗くても先に進んで行かないといけません。「アジャイル」は、この古今東西からの教えの、現代流の取り組みです。

もう少し詳しく見て行きましょう。

私の中では、アジャイルは「試行錯誤」の最新系、という位置づけです。

イノベーションには当然、試行錯誤、トライアル&エラーが不可欠です。

この試行錯誤は有史以来存在しているものであり、アジャイルが発明したものでは当然ありません。

東西の「学び」の思想家の代表例として孔子、ソクラテスがそれぞれあげられますが、両者の言語録を読むとすべて、試行錯誤の精神が鮮明です。

比較的近代では、日本では戦後すぐからデミング博士のPDCAサイクル思考が普及し、リーン生産方式の要の考え方として多くの人に影響を与えましたし、1970年代の米空軍を発祥とするOODAループも長きにわたって顕在です。これらはすべて、仮説、実験、検証、繰り返しのプロセスで、試行錯誤以外のなにものでもありません。

一方で、試行錯誤そのものは生物学的には、実は私達人間の本能に反する行動です。他の生き物同様、人間はサバイバル本能のおかげでリスクを避ける基本的性質を持っています。

そして試行錯誤はリスク無しにではできません。だから、私達は試行錯誤をできるだけやりたくないのが本音です。人間は変化を嫌うようにそもそもできているのです。

リスクはリターンの原資であり、試行錯誤の繰り返しによってリスクが下がり、リターンが上がる、これは、科学です。反対側には、本能的にリスクを取りたくない、人間の原始的性質。有史以来、私たち人間はひとりひとり、この二つのフォースの間で引っ張られ、揺れ動いて来ました。結果古くからこのクリエイティブテンションを説く教えが何千年も連綿と続いているわけです。人類史は突き詰めればこの「試行錯誤」と、「変化への抵抗」のせめぎあいの歴史です。

アジャイルは、この何千年も続いている「変化への抵抗の抵抗」の続きなわけです。つまり、最新の「試行錯誤の試行錯誤」であります。志は変わりません。

試行錯誤は大昔からの普遍的なテーマです。従って、試行錯誤の手法、現代的な表現では仮説、実験、検証を繰り返すソリューション開発手法は数多く存在します。

これらはすべて、リニア思考型の開発手法であるウォーターフォールに対するアンチテーゼです。

PDCAもOODA、リーンスタートアップ、アジャイルスクラム、そしてデザイン思考、これらがすべて直線ではなく、円形のループ構造の思考プロセスなのは、理由があるわけなんですね。

ここから先、いろいろな用語が順不同でごちゃまぜで出てきますので、ここでいったん用語の整理をしておきましょう。

シンプルに行きます。デザイン思考、アジャイル、リーンはそれぞれ独自の起源を持ちますが、すべて一緒くたに考えて大丈夫です。いずれも仮説、実験、検証、繰り返しを経て不確定要素の高い難儀難題を解決していく開発・生産プロセス、フレームワークですので、全部似たようなものです。

リーンはさらに、リーン生産方式・リーントータルクォリティーマネジメントと、より近代のリーンスタートアップに分かれますが、いずれも仮説、検証、実験、繰り返しのプロセスですので、こちらも大まかに同義と考えてください。

アジャイルは2000年代前後のスタートアップカルチャーブームに合わせてメインストリームになってきた開発アプローチで、スクラムはその中でも最も良く使われている実践フレームワークです。スプリントはスクラムの用語で、二週間とかのスクラムの開発周期のことスプリントと言います。

全部まとめると、デザイン思考とリーンとアジャイルは似たようなもので、スクラムはアジャイルの一部、そしてスプリントはスクラムの要素です。

では、なぜアジャイルをやるか、アジャイルの存在意義を深堀りしていってみましょう。

まずはじめに明確にしたいことは、アジャイルはウォーターフォールの否定ではありません。

ウォーターフォール型開発自体は、とても良い開発手法です。緻密で生産的、計画的でクリアなため、高層ビルなどの大型建造物の建築や、インフラ整備、物流等、何千人もがかかわる大きなプロジェクトは、ウォーターフォールなしでは実現不可能です。セブンイレブンやマクドナルドといった小売りや飲食店のフランチャイズもウォーターフォールの実例です。1907年のヘンリーフォードの自動車生産改革以降、ウォーターフォールが現代の世界経済の爆発的繁栄の原動力となったことは間違いありません。

一方で、ウォーターフォールには大きな短所があります。それは柔軟性がないことです。最終完成目標まであらかじめ開発ステージごとに開発計画を緻密に設定して、各ステージ毎に品質管理のチェックポイントを置いて、粛々と実行していく、これがウォーターフォールのやり方ですが、このように最初から何を作る、どう作るを決めてから開発にとりかかるので、途中で目標変更、作戦変更は原則としてナシ、変えちゃいけないというのが思想です。

つまりウォーターフォールでは完成品を見るのは最後まで待たなくてはいけなく、これの何が問題かというと、作ってしまってから「あれ、売れないぞ」、プロダクトマーケットフィットがないぞ、と最後になってようやく気付くケースが出てきてしまうわけなんですね。要は、ウォーターフォールでは失敗が極端に高くつくわけです。

一方で、イノベーションは試行錯誤なしにはありえないので、失敗が許される、むしろ「学び」のために意図的に、積極的に失敗も含めて実験を重ねていく開発手法が必要です。ウォーターフォールではこれができないので、アジャイル、デザイン思考、リーンがあるわけです。

仮説検証型開発手法では、プロトタイプ、MVP(Minimum Viable Product, ミニマムバイアブルプロダクト)と呼ばれる実用最小限製品で、アイディアの実現可能性、そして顧客が買ってくれるかという究極の命題をこまめにこまめにテストしていくので、うまくいかなくてもロスは限定的です。失敗が安くつき、学習効果が非常に高いため、イノベーションのためにはアジャイルやデザイン思考は不可欠なわけなんですね。

ウォーターフォール型開発の一番の利点は、すっきりしていて、なにをやるかがクリアなところ、つまり、確実性の提供です。

しかし、アジャイル、デザイン思考は私たちが慣れ親しんでいる、このすっきりしたやり方に反するやり方なので、ぐちゃぐちゃしているし、めんどくさい、というのが多くの方の第一印象でしょう。目標成果が曖昧、不明瞭なところからスタートすることも多い開発アプローチなので、複雑で、イライラするし本当に大丈夫なの？と途中で投げ出したくなる性格のものです。忍耐が試されるプロセスなので、実際に多くのチームは途中であきらめてしまいます。私は組織開発の仕事をしていますので、数多くのそういったケースを見てきました。

でも、大丈夫です。アジャイル、デザイン思考はランダムだったり、カオスな開発プロセスではありません。それぞれ科学的実証性に基づいた規律のある開発プロセスです。ですので、リスクを許容し、じっくりと取り組む意欲さえあれば、必ず成功します。トライアンドエラーで最後まで頑張りぬいた時にはなんらかの形で必ず成果はでるものですよね。それと一緒です。

大事なのはマインドセットです。繰り返し検証型開発プロセスのサポートにはリスク許容、忍耐、自由な発想を促す人的開発環境が必要です。

スタートアップ以外の一般企業にデザイン思考やアジャイルを導入するのに、組織構造を変える必要があるかと問われたら、私の答えはイェス＆ノーです。

確かに、従来型の縦組織の意思決定プロセスはイノベーションには向いていません。垂直統合型の組織では、組織のトップリーダーが戦略的決定を司り、次の層のミドルリーダーが戦術検討、判断、実践指示の責任を持ち、一般層の社員は伝達された実践計画をどれだけ確実に実行できるかで評価されます。このように、従来型の組織ではいわゆる「サークルオブコントロール」、つまり裁量権が、組織の階層の下に行くほど小さくなるため、イノベーションが生まれにくい、育ちにくい環境になってしまっています。

従来型組織のイノベーションに対する限界はなにも日本企業に限った問題ではなく、欧米企業でも同様です。その反省から、2000年前後の第一次ドットコムブーム以降、先進的な大企業のいくつかはスタートアップ文化の企業内取り込みを実験してきました。

その試行錯誤の結果どうやら円形の、分散型の新しい組織構造が安定的にイノベーションの成果を出しやすいことが分かってきました。特に強いチームは有志連合的に志を同じくする人たちが様々なスキルを持ち寄って有機的に集まって組成し、スピード感と自律性に優れた10名以下の小規模チームであることが多いようです。また、ほかのチームとはネットワーク的に繋がれ、リーダーやマネージャーも存在するものの従来の管理職とは違う役割、例えばファシリテーター型あるいはコーチ型のリーダーシップスタイルが模索されるようになりました。

さて、では従来型組織はこの新しい形の組織に変わらないといけないのか、というと、白黒つけた盲目的なやり方には、私は反対です。従来型組織には縦型組織としての利点があり、それを無理やり壊すのは決して賢明なことではありません。組織変革は、リスキービジネスです。

賢いやり方は、既存の組織構造に、イノベーションが必要なホットエリアを設けて、そこに有機的に新しい形の小組織をポツポツとおけばいいのです。英語ではトライブ (tribe)、直訳すると集落という意味ですが、日本では特務班のようなイメージを持って頂ければよいと思います。要はイノベーションをやりたい、という人たちが社内で集まったらぜひその機会とスペースを作ってあげましょう、ということです。実験からはじめて、これら tribe、特務班の成果が目立ち始めてきたら、組織の他の部分、従来型のマスの部分から一部、お、なにが起きてるんだ？、と興味を持つところが出てくるでしょう。そうしたらそういったところから次の実験に巻き込んでイノベーションを図っていく、つまり有機的なインテグレーションの組織変革アプローチ、というのが私はお勧めです。

さて、私はアジャイル、リーン、デザイン思考などのプロセスコーチであると同時に、行動心理コーチでもあります。

これは、まだ駆け出しのアジャイルコーチだったころ、チェンジ、変化が生まれるのは結局は会話を通してであり、人間関係であり、やる気スイッチが入った時なんだな、と痛感する場面が多く、ではそれをプロのスキルとしてコーチングするには何を学べばいいんだろう、と考え、ポジティブ心理学を学び、国際コーチング連盟のコーチにもなった私の経歴の背景です。デジタルトランスフォーメーションでも、スクラムを利用したイノベーション開発でも、変革の成功要因は結局は人間ゴト、アナログなものなのです。

行動心理コーチの視点からアジャイルを見ると、なるほど、アジャイルはモティベーションサイエンス、やる気の科学を良くわかってるなぁ、良く出来ているなぁ、とつくづく感心させられます。マズローの欲求ピラミッドに基づいて説明しましょう。

私達は仕事を任せられることが好きです。仕事を任せられると、自分が信頼されていることを感じられ、「安全欲求」がまず満たされ、さらにチーム、グループへの「帰属欲求」が満たされます。

自分の存在と実力が認められたと感じ、「承認欲求」が満たされます。

より良い仕事を自分の意志でやりたくなり、「自己実現欲求」が満たされます。

また、アジャイルはチームワークです。自律型組織のサーバントリーダーシップ、リーダーとしての奉仕の精神に目覚めると、「帰属と愛」の欲求がより満たされ、究極的には自己実現を超えて、チーム、組織、社会への貢献に自分の存在意義を見出し、自己超越欲求が満たされます。

アジャイルが上手にできるようになると、仕事が、チームが楽しくなります。楽しいことはやっぱりやる気が出ますよね。

さて、ソフトな話をしたあとは、ハードなお金の話をしましょう。アジャイルは儲かる、という話です。

イノベーションは投資です。経営陣としては、イノベーションに投資する以上は当然成果を求めます。

この点においてもやはり、仮説検証の繰り返しパターンは強力です。ただベンチャー投資をするのと、アジャイルやデザイン思考のようなプロセスをきっちりと持っているベンチャーに投資するのでは大きな違いが生まれます。

例えば、この仮説例では、成功率が20%、ただし当たれば20倍のリターンが戻ってくるハイリスク、ハイリターン的性格のプロジェクトを想定しています。

一回で全投資した場合、加重平均リターンは1,000万円かける20%かける20倍で、4,000万円になります。これはベンチャーキャピタルが投資する案件の典型的リスクリターンプロファイルに近いのであながちありえないシナリオではありません。

これはこれで悪くないのですが、たとえばこのベンチャーチームがデザイン思考集団で、1,000万円を五回に小分けして仮説、実験、検証を繰り返す賢明なチームだった場合を考えます。

例えばの話、この仮説検証の繰り返しの過程で、毎繰り返し時に商品開発のプロダクトマーケットフィットが20%ずつ向上して、最終的には5回目の繰り返しでついに市場が欲しがるドンピシャの商品を開発ができたと仮定します。

このように加重平均リターンは3倍の1億2千万円に向上します。

さらにここからは競合商品が出るまでや市場が飽きるまでは作れば売れる入れ食い状態になるので、ますます儲かるという状況が達成されます。

もちろんこれはシンプルな仮説の話で、現実には100%のプロダクトマーケットフィットというのはまずありえませんが、少なくとも仮説検証型開発を経て事業成功確率を向上させていく手法のパワーを感じて頂けたと思います。

さて、アジャイル基礎講座三部構成の最後、アジャイルの実践についてです。

まず、アジャイルには、大文字 “A” の Agile と 、 小文字 “a” の agile 、あるいは agility があることを知りましょう。

大文字 Agile (アジャイル)は、スクラムなどのフレームワークを忠実に導入して実践します。

一方で、小文字 agile / agility (アジャイル・アジリティー)は、アジャイルの精神、マインドセットと習慣を既存の仕事のフローに取り汲むことを主眼としますので、必ずしもスクラムのようなフレームワークを導入しなくても、アジャイルを実践できます。

なぜこのような違いを知って欲しいかというと、小文字 agile / agility は既存組織にそのまま導入することが比較的容易な一方、大文字 Agile の導入には、組織の構造にメスを入れる覚悟が必要だからです。

大文字 Agile (アジャイル)は、こちらの表に、マインドセット、プロセス、組織構造に分類してまとめた通り、導入要件がたくさんあります。

数多くの企業で大文字 Agile の導入、正確に言えば大文字 Agile の導入の失敗の手直し、を見て参りましたが、失敗要因はこちらの表の導入要件のどれかに躓いているケースが大概です。

大文字 Agile は、チーム員とステークホルダーがコラボレーションしてうまく運用できれば、爆発的な生産性を生み出し、素晴らしいブレークスルーイノベーションに結実することは珍しくありません。それだけパワフルです。

しかし、やるならば徹底してやらなければなりません。リーン生産方式も、工場フロアのみならず、サプライチェーンにいたるまで大改革をやってこそ成功しました。大文字 Agile をやるならば、組織を手術する覚悟が必要です。

一方で、組織全部が大文字 Agile になる必要性があるかと言われると、私はほとんどの大企業ではその必要性は感じません。ベストなのは、組織内で大文字 Agile が必要なゾーンを認識して、そのゾーン内では制限なく自由に大文字 Agile 活動をさせてあげることでしょう。これは、organizational ambidexterity, 組織の両利き経営と一般に呼ばれる考えです。

では、大文字 Agile ゾーンでない、残りの大部分の組織はどうなるでしょうか？

ここで、小文字 agile / agility (アジャイル・アジリティー)の概念が登場します。

本講座の冒頭で、やってみなはれの精神や、自己裁量や工夫といった昔から英知も実はアジャイルですよ、とお話ししました。

小文字 agile / agility (アジャイル・アジリティー)は、この精神、英知で、当然組織の中で大文字 Agile ゾーン以外にも適用可能です。むしろ、組織全体で、アジャイルの精神 (スピリット)を生きても、いいことばかりで何ら問題ありません。

カスタマーバリューのあくなき追及、仮説、実験、検証の学びのループ、漸次漸進して少しずつ成果を出していくこと、チャレンジは繰り返を前提にしてこそ効果があること、個人、チームの自己裁量の尊重、失敗を恐れない、むしろ歓迎する風土、そして正しい失敗を責めない、心理的安全性のある組織、コーチ、ファシリテーターとしてのリーダー、マネージャー像、サイロ型ではなく機能横断型のチーム体制、自律型組織、自己管理型チームワーク: 志からはじめて、できることから変えて行こう、というのが小文字 agile / agility の実践方法です。

さて、「アジャイルメソッド」という言葉を時々聞きますが、これは正しい表現でしょうか？

* 答えです：アジャイルはメソッドやプロセスを使いますが、メソッド、メソドロジー、プロセスそのものではありません。

先ほどのアジャイルの精神のスライドで見た通り、アジャイルは、アプローチ、フレームワーク、スタイル、仕事のモード、態度、思考、マインドセット、スピリット、志、道、そしてカルチャーです。

メソッドではないからこそ、アジャイル、特に小文字 agile / agility は組織のどこでも適用可能なんですね。

くどいようですが、アジャイルはメソッドではありません。

なぜそれが重要かというと、メソッドの先にアジャイルの真髄があるからです。

メソッドは、ステップを踏んで物事を整理して考える、いわゆるロジカル思考の実践で、大事です。しかし、ロジカル思考だけでは世の中の難しい課題は解決できません。

ロジカル思考、ロジカルシンキングの先にあるものがクリティカルシンキングで、アジャイルはまさしくこのクリティカルシンキングの実行実践であると言っても過言ではありません。

ロジカルシンキング、クリティカルシンキングの違いは、リニア思考、ノンリニア思考に分けて考えるとわかりやすいです。

説明しましょう。

私たちは日常的にリストや予定表作りに慣れています。○○メソッド、と言われるとステップバイステップの方式を直感的に想像しやすく受け容れ易いので、メソッドは大人気です。

そのメソッドは、言い換えればロジカルシンキングの実践です。理路整然として取り組みやすく、他の人に何をやっているか説明しやすいですし、結果も予測がついて安心、といったメリットがたくさんあります。

でも、メソッドは結局、直線的なアプローチ、リニア思考の域をでません。

リニア思考の問題点は二つです。ひとつはちょっとでも想定外のことが起きるとすぐに詰まってしまう、臨機応変さに欠けることです。

もうひとつは、機会損失です。リニア思考だけでは、近視眼的になりがちで、いわゆる木を見て森を見ずの状態になってしまいます。あ、なにか違う、という気づきの喜びも、ちょっと違う風にやってみようかな、という工夫の楽しみもスルーしがちです。

時には立ち止まり周りを見回してみないと、そもそも機会、つまりオポチュニティ、チャンスを捉える以前に、機会があること自体を知らずに看過してしまいます。このあたりがリニア思考の残念なところです。

現実問題として、私たちの多くの過ちは難しい問題に直面した時にデフォルトのリニア思考で解決しようしてしまうことに起因します。ちょっとでも難しい問題をリニア思考で解決しようとしたら、当然すぐ詰まります。

ノンリニア思考には、並列思考、発散収束型思考、そしてこれは私の個人的な表現ですが、モザイク思考など、いろいろ楽しい考え方があります。
並列思考は、もし、例えば、といった言葉を使いながらいろいろなシナリオや、可能性を考えます。

デザイン思考で使う発散収束型思考は、実は論理、哲学で言う演繹法、帰納法と密接に関りがあります。

そして、モザイク思考。イメージとしては、頭を開けてテーブルの上に考えていることを全部ぶちまけます。そして、一歩下がって、どこにパターンがあるか、つながりがあるか、あらためて見てみる、という考え方です。すっきりして、驚きの発見があることもあったりして、とても楽しいですよ！

クリティカルシンキングが習慣になると、世の中が違う景色に見えてきます。ぜひ、ノンリニア思考を日常に取り入れて、日々ブレークスルーを探っていきましょう！

クネビンフレームワークというものがあります。世の中のいろいろな問題課題を、シンプル、複合的に難易、複雑、カオスの四分類したモデルです。
リニア思考、ロジカルシンキングで対応可能なのは複合的な課題までです。

複雑で不確実な課題にはノンリニア思考、クリティカルシンキングが必須です。

冒頭にウォーターフォール型開発のお話をしました。ウォーターフォールは川と滝のイメージ通りリニア思考型の開発アプローチです。アジャイルは複雑な問題にクリティカルシンキングを適用して開発を進めるノンリニアなアプローチです。

ぜひ、リニア思考、ノンリニア思考の違いを習慣的に意識して、課題の難易度に基づいて使い分けてください。

少なくとも、複雑な課題に対してリニア思考で取り組んでしまった時のストレスから解放されることでしょう！

アジャイル基礎講座、最後のまとめです。

最終的には、大文字でも小文字でも、アジャイルで大切なのは、組織レベルではアジャイルのスピリット、そして個々人レベルではクリティカルシンキングです。

何度も申し上げますが、アジャイルはメソッドではありません。新しいメソッドを導入したからといって組織が変わるわけでありません。意識があってこそ、本当の変化が生まれます。アジャイル導入の際は、ぜひその精神、思考を意識して、取り組んでください。

以上でAgile 101、基礎編を修了します。

さて、ここからは、付録講座です。

最もポピュラーな大文字 Agile 実践フレームワークである、アジャイルスクラムに興味がある方に対して、入門的なご説明をいたします。

スクラムはソフトウェア開発フレームワークとして発祥しましたが、現代では一般的な商品・サービス開発にもその適用は広まっており、アジャイルと言えばまずはスクラム、ととらえられています。

スクラムは「時間制約型」の開発フレームワークです。1~4週間のスプリントに開発周期をタイムボックスして、開発成果をアウトプット、検証、これを繰り返して行きます。

スクラムは小集団活動です。スクラムチームは最大10名、そして3つの役割のチーム員のみで構成されます：ディベロッパー(開発者、”Developer”)複数人、スクラムマスター(“SM”)一名, そしてプロダクトオーナー(“PO”)一名、の構成です。

スクラムチームには管理職がいません。自律型組織としてチーム員自身全員でチームをセルフマネージ(自己管理)します。PO、SMはマネージャーではありません。POがスクラムチームの「What、何を」、そしてSMが「How、どうやって」開発するかをファシリテートする、サーバントリーダーです。

スクラムは、スクラムガイドという英語版で14ページ、日本語版で18ページの比較的短いドキュメントで規定されています。「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」、と定義される所以です。

スクラムの一つの特徴として、プロダクト志向があげられます。「プロダクト」、直訳すれば「製品」ですが、スクラムガイドでは、「プロダクトとは価値を提供する手段である。プロダクトは明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある」と、プロダクトの定義を拡大解釈しています。サービスでも、社内プロセスでも、使う人がいて価値を生み出す活動であれば、なんでもプロダクトと考えていいですよ、と便利に考えています。

こちらの丸いビジュアルが、スクラムの流れです。左から右へ直線形ではなく、丸くくるくる繰り返す「スプリント」というのが特徴です。

スプリントは「プロダクトバックログ」からスタートして、「スプリントプランニング」という例えば次の二週間はなにやりますよ、という計画作成をして、そこから毎日の開発に入り、デイリースクラムという毎日定時定型15分のチームミーティングを実施してしっかりチーム員同士でシンクロして、スプリントの最終日にスプリントレビューとスプリントレトロという二つのミーティングでスプリントを終了する、という流れです。もちろん、スクラムはそれで終わりというわけではなく、すぐに次のスプリントサイクルに入ってくるくる続けて行く、というイメージです。

長年にわたり、スクラムコミュニティから、スクラムフレームワークを補完する多くの有用なツール、方法、技術が生まれてきました。

スクラムでは、開発の内容とすべてまとめたものを、プロダクトバックログと呼びます。

プロダクトバックログを構築する際、開発の全体像をイメージしながら、まずは大枠の作りたいもの、やりたいことの分類からはじめ、次にそれを少し砕いて解像度を上げて開発の方針を立て、最終的に細かい作業のレベルに落とし込む、「チャンキング」という方法があります。英語で塊という意味の言葉「チャンク」から由来します。複雑な作業の塊を分解して管理するのに非常に便利な方法です。

このチャンキングのテクニックを使ってプロダクトバックログを作る方法を見て行きましょう。

まず、やりたいことを全部書き出しましょう。もちろん、まずは作ろうとしているものの名称や、何を作ろうとしているのかは当然書き出さなければいけませんが、そこからは順不同で現時点で考え得る限りのコトをどんどんアウトプットすればいいだけです。完全である必要性はありませんし、小さいことから大きいことまで、あとで並べ直しますので整理しながら考える必要はありません。

一旦頭の中にあるものをアウトプットしてから、次にそれらを分類、整理しましょう。

大中小と、イメージとしてはロシアのマトリョーシカ人形のように入れ子構造にグルーピングしましょう。

さて、たくさんやりたいことが見えてきて、次は実行計画作りです。

まずは、どれから取り掛かるか優先順位をつけて行きましょう。

一番大事なことや、順序だててやらないといけないことの最初のものなどを第一に優先して、そこから第二、第三と優先順位を決めて行きます。

選んだ優先順位の高いものは早速、これからはじめる「スプリント」で取り掛かります。復習ですが、スクラムでは1-4週間の短周期のスプリントで開発を回して行きます。

ここで、「スプリントバックログ」の登場です。ここまで作ったこちらの左側にあらためて寄せた「プロダクトバックログ」は言って見ればマスター計画です。このプロダクトバックログから、選んだ優先順位の高い仕事を右側の「スプリントバックログ」の「作業予定（To Do）」のカラムに引っ張ってきて置きます。こうやってスプリント毎の計画、スプリントプランニングをしていきます。

ちなみに、このスプリントバックログは、一般的に「かんばんボード」と呼ばれるものです。この概念はリーン生産方式から発祥したものです。

「作業予定（To Do）」のカラムに入った仕事は、それぞれ取り掛かり始めたら「作業中（Work in Progress）」のカラムに動かし、完了したらその名の通り、「完了（Done）」のボックスに置いて、管理する仕組みです。シンプルなボードですが、スクラムチームやステークホルダーに対して情報の持続的な可視化を提供する強力なツールです。

かんばんボードはどんどんカスタムして使いましょう。

大中小の入れ子構造のグルーピングを各カラム内でそのまま活用したり、チーム員毎に区切ったボックスで誰が何をやっているか見える化したりできます。

作業中（Work In Progress）カラムと、完成（Done）のカラムの間に、検査（Testing）というカラムを使って、完成した仕事の品質管理をするプロセスを入れるのも良いアイディアです。

最後に、「トリアージュ」という仕組みも紹介します。仕事の予定がパンパンに詰まっているところに、予定外の仕事のリクエストが入って来ると毎回大変ですよね。そこで、救急病院の「トリアージュ」、急患が入った際は闇雲に受け入れるのではなく、緊急度に応じて治療の優先順位をつける仕組みを真似してみましょう。予定外の仕事が入ってきたら、一旦トリアージュボックスに入れて、リクエストをしてきた人にその緊急度、重要度を説明してもらいましょう。そのうえで、すでに仕事のキャパシティーがいっぱいでその仕事を受け入れると、すでに予定している他の仕事のうちどれかを取り出さないといけない、つまり犠牲にしないといけないことを理解してもらいましょう。それでもそのリクエストが必要であれば受け入れ、そうでない場合は、次のスプリントで対応を検討する旨伝えれば良い、というシステムです。

プロダクトバックログ、スプリントバックログの説明は、以上です。

次に、デイリースクラムのお話をしましょう。

デイリースクラム、「毎日、同じ時間、15分以内」に開催するチームのシンクロミーティングです。

普通の朝礼や日次報告会との違いは、上司からの伝達事項、上司への報告の場ではない、ということです。

復習ですが、スクラムチームは、開発者と、スクラムマスター、プロダクトオーナーで構成される10名以下の小チームです。要は、スクラムマスターとプロダクトオーナーはマネージャーでも、ボスでも、上司でもない、ということです。

全員がフラットです。したがって、デイリースクラムはスクラムマスターやプロダクトオーナーへの、ではなく、お互いへの、報告、連絡、相談会です。
デイリースクラムの形式ですが、この「報連相」三点共有のパターンで良いと思います。昨日やった仕事の報告、本日やる予定の仕事の連絡、そして障害、問題点、要支援事項などが上がってきましたら、相談リクエストしましょう。

必要に応じてSMがファシリテート可能ですが、必ずしも毎日取り仕切る必要はありません。参加必須者は開発者だけです。つまり、SMやPOが開発者の一員でない場合は、SMとPOは必ずしもデイリースクラムに出席する必要はありません。むしろ、チームが慣れてきたらぜひ自己管理の原則に任せて開発者だけのデイリースクラムを奨励ください。

繰り返しですが、デイリースタンドアップの目的はチームワークのシンクロです。15分の短い時間にギュッと凝縮した、チームワークに貢献する価値ある情報共有を図りましょう。

1~4週間のスプリントがいよいよ大詰めを迎えたところの最後のイベント二つのひとつめ、スプリントレビューです。

スプリントレビューは、スプリント最終日に開催する開発成果発表、報告、検証ミーティングです。

スクラムチームが主宰し、顧客、ステークホルダー、その他パートナー等を招待して開催します。スクラムチーム員のみでの内輪のスプリントレビューは本来の目標から外れています。

プロダクトオーナーがスプリントレビューをファシリテートします。

開発者は、スプリントで開発した項目のうち、「完成の定義 (Definition of Done)」を満たしたものを、参加者に発表、デモンストレーションします。完成の定義を満たしていない開発項目(WIP項目)の発表は避けます。参加者に作りかけのものを検証してもらっても意味がないためです。

大事なのは、参加者からフィードバックをもらうことです。フィードバックに基づき、次のスプリントを現状想定している計画のまま進めるか、修正を入れるか、あるいは開発を中止するか、大事な判断が次に待っています。スプリントレビューがだたの進捗状況報告会で終わってしまったら、それは良くないレビューです。繰り返しますが、スプリントレビューは検証の場です。

スプリントレビューが「What、何を開発したか」を共有、振り返りするミーティングだとしたら、スプリントの大とりイベント、スプリントレトロスペクティブは「How、どうやって開発したか」、つまりチームワークの振り返りをするミーティングです。

スプリントレトロは、スクラムチームのみが参加します。外部オブザーバーは参加不可です。スクラムマスターがファシリテートします。

チームワーク、開発手法、アプローチが、うまく行っていてもっとやるべき点、うまく行っていなくてやめるべき点、新しく試してみたいやり方を議論するやり方が一例です。レトロはその他いろいろなやり方がありますので、自由に試してみてください。

レトロの最後までに必ずひとつ、チームとして改善をコミットするアクションを決めてください。このアクションは次のスプリントプランニングでスプリントバックログに入れて、確実に取り組めるようにします。もちろん、このチームワーク向上アイテムにも、完成の定義の設定と次のスプリントレビューでの検証も忘れないようにしましょう。

スクラムの説明の最後に、「人」の話に戻りましょう。

スクラムチームには3つの役割しかありません。プロダクトの価値を最大化する結果に責任を持つプロダクトオーナー(PO)、スクラムチームが仕事しやすい環境を作るスクラムマスター(SM)、そしてプロダクトゴールを実現するディベロッパー(開発者)の3つの役割のみです。

スクラムチームは最大10人までで、POとSMは開発者を兼任することもできます。この最大10人の開発者は、いろいろなスキルやエキスパート知識を持ち寄りますが、開発者の中でサブチームや階層を作ることは避け、全員イコール、フラットであることを実践します。

スクラムチームには3つの役割しかありませんが、どれも必須の役割です。

スクラムチームをボートに例えましょう。

まず、開発者がいなければ、ボートの漕ぎ手がいないようなものですので、そもそも船出できません。ボートは波止場にとまったままです。

プロダクトオーナーがいなければ、どこに向かうかわかりません。なんとなくの目標設定では、あっという間に迷子になることでしょう。プロダクトオーナーが常に、私達は正しい方向に進んでいるのか検査と適合を促すことによって、ボートは目標に向かってスピード良く進むことができます。

難題に挑戦してこそのアジャイルですので、開発の過程でいろいろ障害も出てくることでしょう。そういった時に、スクラムマスターがいなければ、いとも簡単に座礁するかもしれません。スクラムの成功の可否は、スクラムマスターの緻密なサポートにかかっていると言っても過言ではありません。

開発者、プロダクトオーナー、スクラムマスター全員の一致団結があってこそ、スクラムチームは最終到達点であるプロダクトゴールにたどり着くことができます。

スクラム入門編のご説明は以上です。

スクラムを本格的に導入したいという方向けに、スクラム導入講習を用意しております。

リンクはこちらです: https://agile-od.com/mmdojo/14937/scrum-a-to-z-j。どうぞご活用ください。

以上でアジャイル基礎講座本編及び付録を修了します。

情報量が多く大変だったかと思いますが、良い学びだったことを願います。

では、ぜひアジャイルをトライしてみてください！