スクラムマスターへの道

近年、はじめてのアジャイル開発と称して、プログラミングだけのアジャイル開発を行い、その前後は従来のウォーターフォールになっている“奇妙なアジャイル開発”を見かけることがあります。小手先のアジャイル開発をした結果、アジャイルでもなく、ウォーターフォールでもない“妖怪人間”のような実践をしているケースです。結果としてリリースできない品質のソフトウェアが山積みになっていたり、ステークホルダーがレビュー直前まで何が出てくるか知らされていなかったりという耳を疑いたくなるような状態が出現します。

VUCAな時代を生き延びるため、開発プロジェクトには柔軟でスピーディな対応策が不可欠です。これに対応できるのは一般にアジャイル開発といわれ、上流工程から下流工程に進める古典的なウォーターフォール開発とは異なり、近年、急速に広まってきました。しかし、アジャイル開発と呼ばれているものは、2001年のアジャイルソフトウェア開発宣言で合意に至った4つの価値と12の原則を遵守する状態を指しているのであって、アジャイル開発という具体的な開発手法が存在するわけではありません。

では、アジャイル開発を実践するには、どうするか。スクラムやXP、Kanbanといった基本フレームワーク通りに開発プロジェクトを進めてゆくことが最優先だと考えます。さらにこれらのフレームワークを組織の標準的な活動として取り込み、それに応じた人材の採用方針から評価基準、部署の配置やゴール設定、社内のカルチャーまでも対応させていき、組織全体がアジャイルに適用した状態につくり上げていくことになります。これが‘ Don’t just do agile. Be agile. （アジャイルを行うのではなく、アジャイルな状態になる）‘といわれる所以です。

従って、このコラムでは全世界で約8割を占めるフレームワークであるスクラムに焦点を当て、チームとスクラムマスターの存在について考察してみようと思います。

まずスクラムは、10人以下メンバーで構成される自治的集団です。つまり、自分たちで意思決定し、行動し、その評価を自ら行い、次の行動につなげることができる集団です。これを「自己組織化」とか、「自律型チーム」と呼んでいます。スクラムのメンバーには、それぞれに課せられた役割（ロール）に責任と権限が伴います。ウォーターフォール型との違いは、職位による指揮命令というものがありませんし、そもそも職位や上位チーム、下位チームというものがありません。メンバー全員に管理能力が求められます。

このため、プロジェクト管理を専門に行うプロジェクトマネージャー（PM）がいません。プロジェクトを進めるうえで不可欠な進捗の把握やモニタリングやコントロールなどは、自己組織化されたチームなので、あえてPMという役割は置かず、メンバー全員が自分たちで気づき、サッサと対応し、そして学習します。これを実現するには、チームの環境が、「透明性」「検査」「適応」という３本柱と、「確約」「集中」「公開」「尊敬」「勇気」という価値基準をチームで理解し、共有していることが前提です。これらを理解することなく、単にスクラムのイベントのみを形式的に行っただけでは、スクラム本来の効果は得ることはほとんどないかもしれません。

スクラムには、3－3－5（3つの役割、3つの成果物、5つのイベント）という基本ルールがあり、これを遵守します。

・3つの役割：プロダクトオーナー（PO）、開発者（Dev）、スクラムマスター（SM）
・3つの成果物：プロダクトバックログ、スプリントバックログ、インクリメント
・5つのイベント：スプリントプランニング、スプリント、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ　　
※プロダクトバックログリファインメントは随時実施するため、実施日が決まっている5つのイベントとはわけている。

スクラムは自己組織化されたチームなので、全員に決定権があり、全員がプレーヤーになるわけです。このため全員の意見を聞いたり合意する機会は、すべてこのフレームワークのなかに含まれています。

茶道の世界に「守・破・離」という修行の過程があります。守は、最初は基本を守って支援のもとで作業を遂行できる半人前の状態からはじまります。破は、作業を分析し改善・改良できるようになる一流プレーヤーへのステップアップを指します。離は、新たな知識（技術）を開発する（創造者）となることです。スクラムにおいても、まず基本を忠実に守って規定され内容を繰り返し行い、カタをしっかり身につけることを心がけていただきたいです。

とはいえ、昔から成果物については、要求する側とつくる側の対立は絶えることがありません。よくある対立の構図には以下のようなケースがあります。

・要求する側はよくわからないため、あれもこれも要件に入れてくる。
・つくる側は要求事項の行間が読めず、成果物が本来の目的を達したものに至らず。
・双方のコミュニケーションがとれておらず、フタをあけてみると期待とは異なるものを見せられる。

これらを、うまくするためには、要件に優先順位をつけてそれがなぜ必要なのかを説明し、その説明を受けて今度は成果物をどんなものにするかを作る側が説明し、双方、納得した上で進めてゆくことになります。

スクラムでは、要求側とつくり手がプロダクトオーナーと開発者という形で同居しており、短いサイクル（スプリント）で最小単位の成果物をリリースしていきます。１回のリリースで100%満足のいくケースというのは稀なので、リリースした後の結果をフィードバックしながら、次のリリースではどうするかを検討します。効果がわからないのであれば、一旦、リリースしてみて、その結果を判断材料にするという方法もあります。（A／B分析）。しかし、これらのチャンスを活かせないまま、要求と開発者が平行線のままというケースがよくあります。

一方、最初からパフォーマンスの高いチームが成立することは極めてむずかしいものです。単に人が集まっただけの集団としてはチームとしては機能しない。明確な目的に対し、さまざまな考えをもったメンバーが、ベクトルを合わせた活動になれば、チームとして機能しはじめますが、単なる人の集団からチームに移り変わる初期段階では、メンバー同士の意見のぶつかり合いが生じます。特にメンバーのなかには得意分野をもつ“尖った人”もいるでしょうから、衝突は避けられない状態でしょう。ですが「雨降って地固まる」ということわざのように、強いチームができあがる過程では必然の状態なのです（タックマンモデル）。ただし、対立したままの状態だったり、あるいは物別れで険悪な雰囲気だけが残ったままでは、雨降った後の泥沼状態でしかありません。

スクラムの成果物やイベントは、これらの課題を打開するものなのです。重要なことは、このスクラムの基本ルールを着実に遂行することであり、それをリードするのがスクラムマスターです。

スクラムは自己組織化されたチームがイベントを着実に実施するためには、ファシリテーターが必要です。スクラムマスターは、チームメンバーが自分たちで決めたルールを守らせ、コーチングしたりします。一方でメンバーが自分たちの仕事に集中できるよう、環境づくりや、障害を取り除くなど多方面にわたり、チームの運営がうまく進むように内から外から専門的に支援する役割があるのです。

ここでお気づきの方もいるかと思いますが、スクラムマスターは、決して高いITスキルが求められるのではなく、むしろチームをうまくまわすスキルの方が重要であって、つねにチームのためになることを先まわりして考えて行動する人が求められます。実際に機能するよう振る舞うのは、むずかしい内容になります。

そして、チームがうまくまわらなかった場合、それはスクラムマスターの責任になります。

スクラムでつかわれる標準語や仕組み、振る舞いなどの基本事項を理解しているかを問う認定資格があります。
（SHIFTでもアジャイル、スクラムの基礎をどれだけ理解できているかを測る検定診断を用意しています。）

グローバルなものとしては、下表のようなものがあります。

ただし、スクラムマスターの認定資格を保有していることと、スクラムマスターとして機能することは、別のこと考えた方がよいです。資格の保有は、これまでにお話ししてきた内容を理解しており、これからスクラムを開始するスタートラインに立てる状態だと考えた方がよいかもしれません。スクラムマスターのスキルは、実践で腕を磨くことになります。

スクラムはチームメンバーのコミュニケーションが基盤です。このため、スクラムマスターは、チームを引っ張るファシリテーティング、プロジェクトの達成のために必要な技術や知識を開発者に伝えるティーチング、気づかせるコーチング、空気を読んで状況を判断するなど人に関わる幅広いスキルが求められます。その一助として、アジャイルコーチが口にするのは、組織学、集団心理学の学習をすすめられます。

もともと、スクラム自体が、これら2つの理論をベースに構成されていますから、根本の理論に立ち返って、見直してみればスキルアップにつながると考えられます。例えばスクラムでは、チームはどう変化していくか、メンバーのある行動はチームにどのような影響を与えるかなど、組織論や集団心理学のフレームで、ある程度予測することができます。実際に関連書籍を数冊読むと、過去のスクラムで起こった事象と同じような現象が登場し、「あるある状態」に気づきます。ただし、これは自分だけの経験なので、みなさんには臨場感をもって説明できないのが少々、残念です。

私は講座で「スクラムやっていると、こんなケースに出くわしますよ、お楽しみに！」とお伝えしています。

スキルを考えるとき、歴史上の人物を引き合いに対して、「この人の工夫や配慮があれば、スクラムマスターとしてのスキルは十分だっただろうな～」というシュミレーションしてみることで、直面した課題と、チームをどうリードして乗り切ったかについて、実際の記録から必要なスキルを探ってみます。

ロアール・アムンゼン：人類初の南極点に到達したノルウェーの探検家。隊員4名で人類初の南極点到達というプロジェクトに向けた取り組みは参考になります。当時、南極点初到達は、イギリスのスコット隊が最有力候補であったが、アムンゼン隊は世界中の批判と妨害を避けるため、最初は北極点を目指す準備を進め、出発後に南極点に切り替えて隊員全員の精神的な負担を軽減しています。また、極寒の地での移動に有利な犬ゾリをイヌイットから学び、衣服も耐水性と保温性に優れたアザラシ毛皮を用いるなど効率的で機能的な装備で臨んでいます。チームのモチベーションにも気をつかい、テントの広さも1人につき1.5人分の広さのもので、密閉された空間のストレス緩和や食事にもかなりの配慮をしています。コミュニケーションについても、隊員4名が毎朝“温度あてクイズ”なるものを行い、朝の外気温の予想値に一番近かった人が、葉巻をもらえるという他愛もないゲームも行っています。

出発から帰還までおよそ3ヶ月間は、死と隣り合わせの極寒の地で南極点を目指して進んでいくチームです。隊員をまとめあげ、安全に目標を達成したアムンゼンの探検家としてのスキルは、いまでもチーム運営のトップレベルであったと考えられます。

もちろんこれらの偉人たちの時代には、スクラムというフレームワークは存在しないので、こういった考えは単なる遊びに過ぎないのかもしれません。しかし、フレームワークとして整理されていないだけで、チームをリードする考えや工夫には共通する点や参考にすべきところは、大いにあると考えます。（この他にも坂本龍馬など幕末の人物について話し合ってみるのも面白いと思います。）

近年、ITは我々の生活にも浸透し、ものすごいスピードで変化しています。それが大きなうねりとなって、現在のDX社会を形成するようになり、今後も変化のスピードは加速していくことでしょう。従来の上位下達型の組織体系ではとても太刀打ちできません。対応するには、ITサービスを提供する現場に責任・権限をもたせ、スピーディな意思決定と実行が求められます。人が考え、決め、実行する集団には、チームの一員となってときには厳しく、ときには優しくフォローし、気づかせ、成功に導く役割が必要になります。さらにこれが単に開発分野だけに適用するにとどまらず、組織全体に普及すれば、企業カルチャーとして定着し、DX化の促進になります。

「ヒンシツ大学」とは品質／ソフトウェアテスト専門会社・株式会社SHIFTの教育専門機関です。ソフトウェアテスト業界著名人の監修テキストと、経験豊富な弊社講師陣により、入門、実践、応用から管理、テスト戦略まで、バリエーションに富んだ講座を提供しております。高品質なテストスキル／マネジメントスキルを組織として身につけて、短い時間、少人数でも品質を担保する。そういった人材育成をお手伝いするのが「ヒンシツ大学」です。