アジャイル開発フレームワーク「スクラム」を実践でどう活かすか？

はじめに

仲間達と仕事を進めるうえで、基礎的な理論を踏まえて、業務を行うと、良いことがあるのかどうか、試してみました。今回は、スクラムという理論を実践に活かしてみました。

スクラムのイベントは、やる価値がありますね。スプリントレトロスペクティブ というのがあり、スプリントを振り返り、改善点を特定するという手法があります。スプリントの終了後に行われる振り返りミーティングです。チームはスプリント中にうまくいったこと、うまくいかなかったこと、改善すべき点について話し合います。これにより、チームのプロセスを継続的に改善します。 これをやるのとやらないのとでは、かなり違いますね。

スクラムは、複雑な製品開発プロジェクトを管理するためのアジャイル開発フレームワークです。ラグビーのスクラムになぞらえて名付けられ、チームワーク、適応性、自己組織化を重視する反復的な開発プロセスを特徴としています。

スクラムの3つの柱

情報は、隠さない。意見は、放置しない。いいものは、どん欲に取り入れる。

柱	説明
透明性	開発プロセスのすべての側面を関係者全員に公開します。
検査	頻繁に検査を行い、フィードバックを得て、必要に応じてコースを修正します。
適応	変化に柔軟に対応し、計画を必要に応じて調整します。

これを踏まえて、実践でどう活かすか？ですが、

情報は、そもそも、掴みに行かないと得られないものなので、誰よりも積極的に、仮説を提示して、自分の意見が他人からどう見られるのかを確認する事を繰り返す ことになるんだと思います。だから、恥ずかしがらずにどんどん意見をいうのが基本的な姿勢だと思いました。意見を言わずに、聞いているだけならば、スクラム出来ていないんだと思います。

スクラムの役割

意見をばらばらに放置しない。障害を放置しない。実践する。

役割	説明
プロダクトオーナー	プロダクトの価値を最大化することに責任を持ちます。プロダクトバックログを管理し、優先順位を付けます。ステークホルダーと連携し、要件を収集し、チームに伝えます。
スクラムマスター	スクラムプロセスを促進し、チームが効率的に作業できるように支援します。チームの障害を取り除き、チームが自己組織化されるようにサポートします。スクラムの原則とプラクティスを守り、チームにコーチングを行います。
開発チーム	プロダクトの設計、構築、テストを行います。実際にプロダクトを開発するメンバーで構成されます。チームはクロスファンクショナルであり、必要なスキルを持つメンバーが集まっています。チームは自己組織化され、スプリントゴールを達成するために協力します。

これを踏まえて、実践でどう活かすか？ですが、

ただ、自分の意見を積極的に言えばいいという事ではないんだと思います。「三人寄れば文殊の知恵」という言葉が指し示す通り、誰かの異見と自分の意見が合わさったからこそ、いいアイデアになる事もあります。また、良い意見を持っている人が居るのに、聞くスタンスがなっていないがために、意見を拾い上げることが出来ていないというのも悲しい話です。なので、どんな些細なアイディアも拾い上げようというマインドが必要 なんだと思います。

スクラムのイベント

重要なタスクにフォーカスする。歩調を合わせる。認識齟齬を放置しない。机上の空論にしない。

イベント	説明
スプリントプランニング	各スプリントで完了する作業を計画します。スプリントの開始時に行われる計画ミーティングです。プロダクトオーナーがプロダクトバックログから優先順位の高いアイテム選び、チームと一緒にスプリントバックログを作成します。チームはスプリントの目標（スプリントゴール）を設定し、達成するためのタスクを計画します。
デイリースクラム	チームの進捗状況を共有し、問題を特定して解決します。毎日行われる短いミーティング（通常15分）です。チームメンバーは、前日の作業内容、当日の計画、および障害となっている問題について共有します。これにより、チームの進捗状況を把握し、迅速に問題を解決することができます。
スプリントレビュー	スプリント中に完了した作業を関係者に示します。スプリントの終了時に行われるレビューです。チームはスプリント中に作成したインクリメントをデモンストレーションし、ステークホルダーからフィードバックを受けます。これにより、次のスプリントに向けて改善点を特定します。
スプリントレトロスペクティブ	スプリントを振り返り、改善点を特定します。スプリントの終了後に行われる振り返りミーティングです。チームはスプリント中にうまくいったこと、うまくいかなかったこと、改善すべき点について話し合います。これにより、チームのプロセスを継続的に改善します。

これを踏まえて、実践でどう活かすか？ですが、

やってみないとわからないので、とにかくやってみようという事だと思います。方法論なので、その場その場に合わせて、こういうノウハウを活かしたいものですね。スプリントレトロスペクティブ以外は、やっていて当たり前のことである気がしました。

スクラムのアーティファクト

改善をどん欲に求める。タスクリストに漏れがないようにする。現状に満足しない。常に新たなものを求め続ける。

アーティファクト	説明
プロダクトバックログ	プロダクトに必要な機能や改善点のリストです。プロダクトオーナーが管理し、優先順位を付けます。
スプリントバックログ	スプリント期間中に実施するタスクのリストです。チームがスプリントプランニングで作成し、スプリントゴールを達成するための具体的な作業項目が含まれます。
インクリメント	スプリントの終了時に提供される動作するソフトウェアの部分です。インクリメントは「リリース判断可能な状態」である必要があります。

これを踏まえて、実践でどう活かすか？ですが、

ちゃんと、成果物を出し続ける事だと思います。アウトプットがなければ、インプットの意味がありません。

スクラムの利点

遅れを取らない。フィードバックを取りいれる。求められていないものは、作らない。必要なものへ力を注ぐ。変なことに振り回せられる事を避ける。一人だけで満足しない。

利点	説明
迅速な納品	短い開発サイクルにより、迅速な製品納品が可能になります。
高い品質	頻繁な検査とフィードバックにより、高品質な製品を構築できます。
顧客満足度	顧客との密接なコラボレーションにより、顧客満足度の高い製品を開発できます。
リスク軽減	変化への適応性により、プロジェクトのリスクを軽減できます。
チームワークの向上	チームワークとコラボレーションを促進します。

これを踏まえて、実践でどう活かすか？ですが、

要らないものは、作らない。コミュニケーションを密に取ることを疎かにしないという事だと思います。要らないものを作ってしまうと、なに無駄な事やってんだお前はと詰められますから、気をつけましょう。

スクラムの課題

学び続ける。結果にコミットする。過去の成功体験に縛られない。使えるものは、どんどん使う。

課題	説明
習得曲線	スクラムのフレームワークと用語を理解するには、学習曲線が必要です。
コミットメントの必要性	スクラムは、チームメンバー全員からの高いレベルのコミットメントと協力が必要です。
変化への適応	変化に迅速かつ柔軟に適応できる必要があります。
適切なツールとサポート	スクラムを効果的に実装するには、適切なツールとサポートが必要です。

これを踏まえて、実践でどう活かすか？ですが、

学び続ける。結果にコミットする。過去の成功体験に縛られない。使えるものは、どんどん使う。言葉の通り。

スクラムが適しているケース

要件が曖昧。顧客の困っている事がコロコロ変わる。平凡なものでは、受け入れられない。顧客の立場からコロコロ変わる。全体像を把握していないと、対応できない。

ケース	説明
複雑で変化する要件を持つプロジェクト	要件が頻繁に変わるプロジェクトに適しています。
迅速な納品と頻繁なフィードバックが必要なプロジェクト	短期間での納品とフィードバックが求められるプロジェクトに適しています。
高い品質の製品が求められるプロジェクト	高品質な製品を提供する必要があるプロジェクトに適しています。
顧客との密接なコラボレーションが必要なプロジェクト	顧客と密接に連携する必要があるプロジェクトに適しています。
チームワークとコラボレーションが重要なプロジェクト	チームメンバー間の協力が重要なプロジェクトに適しています。

読んで頂きまして、ありがとうございました。