みなさん、ご機嫌いかがですか？
どうも。スクラムおじさんこと、バックエンドエンジニアのKJです。しれっと初登場ですが、よろしくお願いします。心臓をわし掴みにされる音楽と、いろんなレザーを育てることが好きです。
さて突然ですが、みなさんはスクラムってご存知でしょうか。
「耳にしたことはあるけど、雰囲気しかわからない」という方も、「実際に現場で導入済みだよ」という方も、「そもそもなんだそれ」っていう方もいらっしゃるかと思います。
実は私、認定スクラムマスター（CSM（Certified ScrumMaster）。3日間の研修と、最終試験をパスすることで取得できる資格）という一面を持っていまして、実際に担当しているプロジェクトでもスクラムを導入しております。今回は「10分でスクラムの概要を”雰囲気で”理解してみよう」これを目標として記事を書いてみました。
スクラムってなに？
- スクラム（名詞）
- 複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り 価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムとは、以下のようなものである。
・軽量
・理解が容易
・習得は困難スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。これらのプロダクト管理や開発プラクティスの相対的な有効性を明確にし、改善を可能にするのである。スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されて いる。それぞれに目的があり、スクラムの成功や利用に欠かせない。
引用元：The Scrum Guide
スクラムとは「現状を把握するためのフレームワーク」です。皮肉なことに、現状を把握した結果、パーフェクトだというプロジェクトはほぼ皆無であることから「問題を発見するフレームワーク」と言われることもあります。先ほどの出典元のThe Scrum Guideにもありますが、
- ・軽量
・理解が容易
・習得は困難
という特徴があります。この辺りから「わかっちゃいるんだけどねー」という、よくあるあの空気が見え隠れしていますよね。
実際にどんなことをやるのか
具体的には、
- ・プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る。
・固定の短い期間（1～4週間程度）の単位で開発を区切り、その中で計画を立てる。
・プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう。
・作っている機能が正しいかどうか、定期的に確認の場を設ける。
上記のような内容がスクラム開発の要素として挙げられます。「スクラム」という名称はもともとスポーツ（ラグビー）用語から取られたもの。チームメンバー同士でコミュニケーションをとりながら、力を合わせて開発を進めるというのがスクラム開発なんです。
よくある勘違い
「スクラムをやるといいことしかない！」という神話をご存知でしょうか？ 目的がぶれてしまうと、こういう誤解が蔓延してしまいます。
- 生産性の向上
- 人間の成長
- プロダクトの劇的な改善
これらを「目的」としてスクラムを導入すると、
「おい話が違うぞ。何も向上も成長も改善もしないじゃないか」
「面倒な時間ばかり増えて効率落ちたぞ」
「嘘つきやがってこのやろう」
と罵詈雑言を浴びることもあります。
上記のような目的は、現状を把握できたあとにリターンとして得られる成果であり、スクラム自体にそれを求めるのはお門違いということになります。銀の弾丸ではない。スクラムもまたしかりなのです。
ここで想像してみてください。自分が置かれている状況をしっかり把握できている状態と、まったく状況がわからずふわふわした状態、みなさんはどちらがお好みでしょう。どちらが自分のパフォーマンス出せそうでしょうか？
自分が今いる状況を把握することによって、「何が必要なのか」、そして「何が効率的なのか、効果的なのか」を判断できるようになります。その結果として、はじめてリターンが生まれてくるのです。
前提となる三本柱
スクラムには大事な三本柱があります。
- 1. 透明性 – Transparency
2. 検証 – Inspect
3. 適合 – Adapt
最低限、この三本柱を念頭に置いておくと「なぜだろう」が解消されやすいです。
現状に透明性があり、検証できるかどうか。良い方向への変化・適応がなされている状態かどうか、考えることが重要なんですね。言われてみるとそうだな、と感じます。なにごとも不透明な状態だと不安ですよね。
大切な3つの役割
ここで、スクラムチームを構成する役割を紹介します。
-
- プロダクトオーナー：プロダクトの責任者。「チームのROIを最大化させる」のが役割。
- スクラムマスター：「開発がScrumと呼べる状態にする」、バランサーのような役割。
- 開発チーム：実際に「開発を行う」メンバー。
スクラムチームに所属するうえでは、この３つの役割のどれかに必ず属することになります。詳しい説明はこちらのサイトにわかりやすくまとまっていたのでぜひご覧ください。
ちなみに、7人プラスマイナス２人がスクラムチーム構成に適していると言われています。チーム人数が多すぎても少なすぎても難しい、ということですね。
どんなチームを作るのか
スクラム開発によって、「自律的なチーム」を作ることができると言われています。
ここで言う「自律的なチーム」には
-
- チームの明確なゴールがある
- チームの明確なバウンダリー（境界線）がある
上記の要素が不可欠となります。
また「チームのゴールもバウンダリーも設定したから自律的チームの完成！」というものでもありません。「自律的なチームかどうか」を判断するための基準は、「個人がチームのゴールを達成するために何をすべきか、0.1秒以内に判別し行動できるかどうか」とされています。
自らを律して考え判断し行動する。これって、当たり前のようでいてなかなか体得するのは難儀だなぁと日々痛感しています。
勝手な自己判断に陥りがちだったり、即座に行動できなかったり。意識的に行動を積み上げて行くことが一番の近道だと信じていますが、いや、本当に難しいです。
でも、楽しい。
とはいえスクラムって万能？
実は、そもそもスクラム出来ない状況もあります。
ひとつが、「プロダクトの生産期間が短い」ケース。
スクラムはチームビルディングに最低3ヶ月必要とされています。そのため、3ヶ月未満の生産期間プロジェクトでは不適切とされることが多いです（勿論出来なくはないですが……）。
もうひとつは、「要件や技術が単純（シンプル）なプロダクト」である場合。
もともとスクラムは要件や技術が複雑な場合に本領発揮するアプローチのため、シンプルなものでは目に見える恩恵を受けにくいとされています。むやみやたらに「よっしゃスクラムやるぞ！」と導入してはダメということですね。
まとめ
以上、今回はスクラムの概要についてお話させていただきました。
「おいKJ、実践的・具体的な内容がなにもないじゃないか」
という方のために、第二弾（予定）では、スクラムのセレモニーやアーティファクトなど具体的な部分に触れていきたいと思っています（いつになるのでしょう）。
……「自分は状況把握ができている」という盛大な勘違いに気付けたのはスクラムのおかげです。これぞ現状把握。
・朝会やってるから大丈夫
・スプリントを回しているから大丈夫
・カンバンタスク管理してるから大丈夫
・スクラムマスターとプロダクトオーナー兼任だけどちゃんとやれてるから大丈夫
といった「なんちゃってスクラム」にだけはならないように、スクラム導入済の環境下の方々も、これから導入予定の方々も十分お気をつけください。
自分も誰よりも気をつけて、日々しっかり思考し続けるよう心がけます。師匠に怒られないように、スクラムマスターとして日々精進です。KJでした。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
