こんにちは。代表の高崎です。
私達の会社では半年前からチームで知的生産物を作るためのチーム術「スクラム」という仕組みを取り入れて仕事しています。

スクラムはもともとはソフトウェア開発のために生まれましたが、「チームで働くこと」に悩んでる全ての人に有効だと思っています。

私自身も今までのキャリアで人に雇われる側、人を雇う側、プロジェクトを発注する側、受注する側と色んな立場で仕事してきて、育って来た環境も違えば、背負っている利害、正しいと信じているものも違う大人同士が、チームで働くことの難しさを痛感してきましたが、その経験からこの「スクラム」という枠組みがメンバーの自主性を尊重しながら組織として一つの目標に向かっていくための最適解だと感じています。

この記事では、そんなスクラムについての解説と、導入したい人のための導入マニュアルをお送りしたいと思います。
また、なるべく専門用語は平易な言葉に置き換えています。より詳細に知りたい方は一番最後の参考文献をご覧ください！

スクラムとは？

もともとはチームでソフトウェア開発をするための手法としてアメリカで生まれました。
特徴としては以下のことがあげられます。

• プロジェクトで起こりうる障害全てを予見した完全な計画は立てられないという前提で、大きなPDCAサイクルを一回回すのではなく、小さなPDCAをたくさん回しながら変化に柔軟に対応し、チームで学習しながらプロジェクトの完成度を上げていく
• 人間は簡単に同じ方向を向けないという前提に、論理だけでなくメンバーの「感情・自主性」を大事にしながら「共感・共振・共鳴」でチームを作る

個人的にスクラムの本質は、

"「無管理」でも「強い管理」でもなく、自主性を尊重した「柔らかなマネジメント」が重要である。" --アジャイル開発とスクラム
僕の会社として理想としていること。「見守りながら任せる」が良いチーム。

— Kenji Takasaki (@nplusone) 2018年4月25日

にあると思っています。

当社でスクラムを導入したきっかけ

私たちの会社は、在宅勤務OKで出社自由、就業時間自由、メンバーも全国各地にいるというワークスタイルなのですが、昨年の夏、新規スタッフが２名入社し、リモートを中心としながらもまったくはじめての人と会社の価値観や文化を共有しながら、チームでプロジェクトを進めていく必要があったのですが、価値観のずれや摩擦がどうしても発生していました。

この経緯などは別途記事にしましたので興味がある方はこちらの記事も読んで下さいね。

また、変化の激しいWEB制作という世界で、品質を保ちつつも変化に柔軟に対応しながらチームでの制作をスピードアップする方法はないか探していた時に出会ったのがこのスクラムという手法です。
まずは導入にあたって、ツールと流れを説明したいと思います。

スクラムの流れ

1.ITツールの準備

私たちはスクラムに、以下のツールを利用しています。

github

プロジェクトマネージメントツールです。

zenhub

githubのタスク管理表をより管理しやすくするツールです。Trelloというタスク管理ツールを使っている会社さんも多いと思います。

appear.in

毎日の朝会やMTGなどはこのWEB会議ツールを使っています。

2.３つの役割を決める

スクラムではまず３つの役割を決めます。

プロダクトオーナー

そのプロジェクトにビジョンを持ち、何をするか決める人

開発チーム

実際にそのプロジェクトに関わるメンバー

スクラムマスター

スクラムがうまくいくように奉仕型のリーダーシップでチームがうまくいくよう支援する人

3.プロジェクトの目的と想いの共有

プロジェクトを始める段階で、プロジェクトが社会にとってどう役に立つのか。メンバーがどのような気持ちでこのプロジェクトに関わるのかの共有を行います。
私が読んだ本にはPDCAサイクルのPの前に「S」を作ると書いてありました。

PDCAサイクルの前にSを置くことが重要。SはSocializion（共有化）。計画の前に自分の主観と情熱を周りの人と対話して共有し、「共感・共振・共鳴」を起こすこと。そのプロセス抜きにイノベーションは起こらない。-書籍「アジャイル開発とスクラム(https://t.co/R0eLwT28Wt )」より要約。しびれる言葉！

— Kenji Takasaki (@nplusone) 2018年5月1日

私達は以下の手法で、プロジェクトのビジョン、戦略を共有しています。

エレベーターピッチ

プロジェクトをエレベーターに乗っている３０秒でも説明できるように説明する手法で、以下のような文で作ります。

たとえば私達の会社のWeb制作事業部では、以下のようなエレベーターピッチをメンバーで共有しています。

私達はなぜここにいるのか？

エレベーターピッチが終わった後、メンバー一人ひとり、「なぜ私はこのプロジェクトに関わるのか？」という個人の動機を発表していき、それを最終的に私達のチームはなぜここにいるのかというステートメントにします。
私達の会社のWeb制作事業では以下のようになりました。

このエレベータピッチとチームとしてのステートメント「私達はなぜここにいるのか？」をチームがよく見る場所に張り出し、つねに原点を忘れないようにしています。

４.スプリント期間を決める

さきほど、スクラムでは小さなPDCAサイクルをたくさん回すと言いましたが、この小さなPDCAサイクルを回す期間のことを「スプリント期間」と呼び、プロジェクトの規模にあわせて「１週間から4週間」の間の期間でスプリント期間を決めます。
私達の会社では、２週間のスプリント期間でスクラムをやっています。

5.スプリント計画

ここからが実際のスプリントと呼ばれるPDCAサイクルの始まりです。
まずは以下の流れで計画を立てます。

5-1．プロジェクトのタスクを洗い出す

スクラムではもともとトヨタで生まれた課題管理法「かんばん式」でタスクをチーム全体で共有します。

このかんばん式のタスク管理では、タスクを以下のように分けます。

未着手

まだ着手していないタスク

実行中

このスプリント期間で実行するタスク

レビュー・QA

実行が終わりプロダクトオーナーの確認待ち、もしくは質問等のやりとりのあるタスク

完了（Closed）

実行が完了したタスク

5-2.各タスクにユーザーストーリーを記入する

各タスクを「なぜやるのか？」目的を共有するために、ユーザーストーリーというフォーマットを使って、お客さんから見た際にこの仕事はどんな意味があるのかを共有します。

たとえば自社サイトに会社案内のPDFをダウンロードできる機能を追加する場合、このような形になります。

5-3.そのタスクの完成基準を設定する

ユーザーストーリーで目的を共有したらこんどはそのタスクを「何をもって完成とするか」の基準を共有します。
上記の例では、会社案内をダウンロードのシステムが完成し、テスト環境でテストできる状態になっている。というのが完成基準として設定されました。

目的と求める完成基準を明文化して共有することで、仕事の出し手と受け手の不幸なすれ違いを防ぎます。

5-4.そのタスクの工数をみんなで見積もる

次にそのタスクの工数を見積もります。
見積もりは各タスクに付与したユーザーストーリーを実現するために必要な時間や難易度を考慮した、ストーリーポイントという数字で見積もります。
また見積もりは「人間は正確な見積もりは苦手だが、比較することによって大体の大きさを推測することができる」という前提でメンバー全員で行うのが特徴で、一番簡単なタスクを終わらせるまでのポイントを１とした場合と比較して、そのタスクがいくつになるのかをみんなで考えます。

さらに見積もりは、プランニングポーカーと呼ばれる、以下のルールで行います。

• 数字は全員同時に言う（人の意見に左右されない）
• 数字にかなりばらつきがあった際は、一度全員で理由を話し合って３回まで見積もりをやり直しても良い
• ３回で一致しなかった場合、最大値と最小値を切った平均を採用する

5-5.そのスプリント期間で実行するタスクを「実行中」にいれる

この前のプロセスまでで、タスクをやる目的、求めている完成度、タスク実行のためにかかる労力をメンバーで洗い出し共有してきました。
いよいよ、このスプリント期間でやることをプロダクトオーナーが決めて、前述のかんばん式で管理しているタスクボードの「実行中」に入れてメンバーに伝えます。
メンバーはそれを受けてタスク実行の段取りを記入します。

6.朝会（デイリースクラム）

スプリントが始まってからは、チームメンバー全員で毎朝15分以内を目標に朝会を行い、各メンバーは以下のことを発表します。

• 昨日したこと
• 今日やろうと思っていること
• 仕事を進める上でつまずいていること

このように日々の進捗を全員で確認しあうほか、各メンバーがつまずいていることがあった場合、メンバーみんなで解決するよう話し合います。
あまり話し合いが長くなる場合、２次会と称してその問題に関わる人だけが残ってMTGを続けます。

また完了したタスクは完了の項目に移します。
完了したタスクのストーリーポイントをグラフ化したものを「バーンダウンチャート」と呼び、順調にタスクが消化できているかをこのグラフで確認します。

7.成果物のお披露目会（スプリントレビュー）

スプリント期間の最終日に、全員で完成したタスクのお披露目をやります。

8.ふりかえり(レトロスペクティブ)

KPT（ケプト）と呼ばれるフレームワークを使ってメンバー全員でこのスプリント期間を振り返ります。
KPTとはKeep,　Problem,　Tryの略で、以下のようなことを発表していきます。

Keep

今回、良かったこと、続けていきたいこと

Problem

今回、つまずいたこと、課題に感じたこと

Try

次に挑戦してみたいこと

またこの順番にも意味があるので、Keep,　Problem,　Tryの順に発表するようにしましょう。

これでスプリントの期間は終わりです。
プロジェクトが継続する場合、３に戻って８までこの「スプリント」と呼ばれる小さなPDCAサイクルを繰り返していきます。

もっと詳しく知りたい人は、、

スクラムという言葉を使わずにスクラムを説明してる資料で、すごくわかりやすいです。

本ですと、こちらの本がとてもよく書かれていましたので、ぜひ御覧ください！「失敗の本質」という日本の組織の典型的な失敗パターンを研究した名著の著者も加わった、単なる開発論を超えてこれからの会社組織論としてもすごく良い内容が書かれています。

それでは、良いチームでの協働を願ってこの記事を終わりにしたいと思います。
最後まで読んでいただき、ありがとうございました！