この記事は、「スクラムマスター初学者」もしくは「ANGEL Dojo参加者」の方向けに、スクラムマスターがAWSで開発を進める上で意識したポイントについて解説します。
※本記事では、スクラム開発の全体像や用語の詳細についてはご存知であることを前提に解説しています。
- はじめに
- スクラム開発を選択した背景と実際の成果
- スクラム開発を進める上で意識したこと
- スクラム開発 実践時に意識した AWS アーキテクチャ
- まとめ
こんにちは！エンタープライズクラウド部クラウドコンサルティング課の日高です。
もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。
はじめに
私は、3ヶ月間でサービスの企画から開発まで行うトレーニング「ANGEL Dojo 2024」に参加しました。
本記事の前提として、ANGEL Dojo 2024の評価制度を簡単にご紹介します。
ANGEL Dojoでは、全チームが最終発表でプレゼンを行い、ユーザー企業チームとパートナー企業チームそれぞれから「Angel賞」（聴講者投票によるサービス観点の賞）と「ベストアーキテクチャ賞」（AWSが選定するアーキテクチャ観点の賞）が選ばれます。
さらに、頂上決戦ではこれらの表彰チームの中から4チームが選ばれ、最優秀チームを競います。
私が参加したチームはパートナー部門で「Angel賞」と「ベストアーキテクチャ賞」をW受賞し、頂上決戦に進出しましたが、最優秀チームには選ばれませんでした。
頂上決戦の様子はYouTubeで配信されているので、ぜひご覧ください。
さて、本記事では、ANGEL Dojo 2024でパートナー部門W受賞チームのスクラムマスターを初めて務めた私が、「スクラムマスター初学者」や「ANGEL Dojo参加者」の方々に向けて、AWSでスクラム開発を進める上で意識したポイントを解説していきます！（※スクラム開発の全体像や用語の詳細についてはご存知であることを前提に解説していきます。）
本題に入る前に、まずはスクラム開発を選択した「背景と実際の成果」から記載していきます。
スクラム開発を選択した背景と実際の成果
スクラム開発（アジャイル開発）を選んだ理由は、「ユーザーが本当に望む価値を届けたかったから」です。
ウォーターフォール型開発では、長期的な開発の中でユーザーのニーズが変わっても対応が難しいという課題がありました。
そこで、短いサイクルでユーザーのフィードバック（FB）を迅速に反映できるスクラム開発を採用しました。
具体的には、上記画像のようにユーザーインタビューで課題を抽出し、最小限のプロダクト（MVP）を作成。その後、何度もフィードバックを収集して改善を繰り返し、実際に価値ある機能を提供する体制を構築しました。
こうしてユーザーのニーズに素早く応えることを実現したのです。
スクラム開発の成果としては、チームのベロシティが当初の3.5倍に成長。また、数ヶ月でアーキテクチャも大幅に改善されました。（詳しくは、以下の画像参照）
それでは、具体的にスクラム開発を進める上でスクラムマスターとして意識したことについて説明していきます。
スクラム開発を進める上で意識したこと
ここでは、実際にスクラム開発を進める中で直面した課題と、その対処法をTips形式で紹介します。
初対面メンバーでの開発！チームビルディング時の工夫
チームの初対面時の状況
ANGEL Dojo 2024 では、異なる企業のメンバーが 1 つのチームとなり、初対面で開発をスタートすることが標準でした。
私のチームでも、社内のメンバーとは面識があったものの、実際に一緒に働くのは初めてで、他社（NECソリューションイノベータ株式会社様）のメンバーとは完全に初対面の状態でした。
取り組んだ工夫
こうした状況でチームワークを構築するために、初顔合わせ時に各自に「自身の取り扱い説明書」を作成してもらい、共有し合いました。
取り扱い説明書の準備内容として、各メンバーに事前に以下の項目を Slack の Canvas に記載してもらいました。
- 普段の業務内容と技術スタック: 自分が普段担当している仕事や使用している（していた）技術
- 仕事の好き/嫌い: 好きな作業や苦手な業務
- 得意/不得意: 自分が得意なことと不得意なこと
- 今後やりたいこと: 今後伸ばしたいスキルや挑戦したいこと
- 働く時間帯: 自分が集中しやすい時間帯や仕事のスタイル
- コミュニケーション方法: フォーマル/カジュアル、テキスト/口頭の好みなど
- 会議の進め方: 会議の理想的な進行方法や好み
- ソーシャルスタイル診断の結果: 自分の性格タイプとその特徴
この「自身の取り扱い説明書」をもとにメンバー同士で説明し合うことで、以下のメリットがありました。
- メンバーの強みと弱みを把握: どの分野で誰が力を発揮できるかが明確になり、タスクの割り振りがスムーズにできました。
- 仕事の進め方に対する理解: 各メンバーの性格や好みを事前に知っておくことで、ストレスなくコミュニケーションが取れる環境を作れました。
- 効率的なチーム運営: 会議やタスク進行の仕方も互いに配慮できるようになり、プロジェクトの進行がスムーズになりました。
この工夫のおかげで、初対面のメンバー同士でも早い段階でお互いを理解し、効率よくチームワークを発揮することができたと感じています。
読者の方が、実践する際に役立つように ANGEL Dojo 2024 の開始前に作成した私の取り扱い説明書を以下に記載します。
| Slack表示名 | @SWX-日高僚太 |
|---|---|
| 普段の業務内容と技術スタック | ・業務：エンタープライズ企業向けのAWS利用のコンサルティングエンタープライズ企業向けにAWSを用いてシステム設計構築案件参画 ・技術スタック（最近触った技術）：基本的なAWSサービス全般、特には CICD、ECS（コンテナ）CloudFormationNetwork Firewall、Route 53 Resolver DNS FirewallWell-Arc レビュースクラム開発 ※アプリケーション開発は未経験（プログラミング言語は触ったことがない） |
| 仕事の好き/嫌い | 好き 抱えている課題に対して解決策を提示すること仕組み化をすること IaCのコードを書いたり、アーキテクチャを考えること ゴールが不明瞭なものを徐々に明確にして前に進めること 嫌い 細かい仕様等の調査（技術要件の細かい内容を詰め切ること） 決まり切った定型作業 誰でもできるような内容の調査 |
| 得意/不得意 | 得意 スピード感を持って仕事をすること 課題解決手法の提案抽象的な内容を、フレーム等の具体的な内容に落とし込むもの 不得意 完全に質重視の仕事（細かいミスをしてしまうことがある） 自分1人でじっくり考え込むことが必要な仕事 |
| 今後やりたい・伸ばしたいと思っている事 | ・PMとしてのマネジメント力 ・お客様との調整力のスキルサービス立案（サービス企画のスキル） ・Webアプリケーション構築ができるようになりたい |
| 働く時間 | 出社時間は10:00~19:00が多い。 一番頭が冴えているのは午前中（ミーティングはなるべく午後がいい） |
| コミュニケーション方法 | ・回りくどい言い方ではなく、ドストレートに言いたいし、言われたい（なのでオブラートに包むのは苦手） ・基本的には砕けた感じでコミュニケーションはしたいが、締める時や集中する時間は雑談等は不要と考えている（メリハリをつけたい） ・全員が共通のビジョンを持った状態で、その目的に最短で進んでいる状態が理想（余計なことに気を使いたくない） |
| MTG | ・’会議をするときは、会議のゴールが明確になっていてほしい ・無駄な会議はこの世で一番無駄な時間だと思っている時 ・間内にゴールが達成できているかどうかで、会議の価値を測りがち ・ブレスト系も時間を決めてきっちりやりたい |
| ソーシャルスタイル診断 | 結果：エクスプレッシブ（説明文が当たっている箇所は以下） ・基本的には楽天的で、⾃分のことを話すことが⼤好き。 ・調⼦に乗りすぎると⽻⽬をはずすタイプ ・タスクを安請け合いする傾向がある ・曖昧な褒め⾔葉でも何でも基本的に喜びます。褒められると単純にやる気を出す傾向が強いので、どんどん褒めましょう ・ただ、調⼦にも乗りやすい ・モチベーション向上：期待される、新しい分野に挑戦する、任される、特別扱いされるとやる気が出る ・モチベーション低下：命令⼀⽅的な指⽰、嫌いな上司からの指⽰、縛られる、細かい指示 |
| ANGEL Dojo で成し遂げたいこと | ・サービス立案の経験を積んでみたい（今後のキャリアパスとして、自分でサービスを作ってみたいと思っているため、その土台となる知識・経験をしたい） ・Webアプリケーションを作れるようになりたい（そのための土台の知識をつけたい） ・受賞する |
チームの目標が曖昧！共通のビジョン設定の工夫
課題の認識
「取り扱い説明書」の共有でメンバー各自の「ANGEL Dojoで成し遂げたいこと」は把握できましたが、チームとしての共通ビジョンが曖昧でした。
このままでは開発中に認識やモチベーションのズレが生じる懸念がありました。
具体的な対策
チーム活動を円滑に進めるため、初回の活動時間を多めに確保し、以下の手順で共通のビジョンを設定しました。
チームゴールのすり合わせ
チーム全員で話し合い、プロジェクトの最終目標や成果を具体化し、全員が同じ方向を向いて進めるようにしました。チームルールの設定
開発中に守るべき基本的なルールを定め、調和を保つことを意識しました。ルールはスプリントレトロスペクティブで定期的に見直し、改善しました。チームのルール（ANGEL Dojo 2024時）:
- 意見を忌憚なく言える環境を作るため、叱責はNG（反対意見を言うことはOK）
- オブラートに包む発言は「それオブラートじゃない？」と指摘する
- 15分考えてもわからなければチームメンバーに質問する
- 問いかけには必ず反応する（テキスト、会議問わず）
- Disagree and Commit の精神で取り組む
- テキストコミュニケーションの敷居を下げるため、挨拶や敬称は省略（例：@sabawa でOK）
- MTG後は必ずメモを取り、認識齟齬をなくす
- 調査内容は資料に残し、情報共有を徹底す
- 質問する際は以下のフレームに従い質問する（軽微な質問はその限りではない）
- 聞きたいこと: 簡潔に一言でまとめる
- 状況: 背景、理解できていること、理解できていないこと
- 最終的に実現したいこと: 質問を通じて達成したい目的
各ツールの目的と使用ルール
使用ツール（Box、Backlog、Slack、Git）の役割と利用ルールを共有し、情報共有とタスク管理を効率化しました。Box の利用ルールの実際の例
- 利用する目的: 情報の透明化で作業効率向上、コミュニケーションコスト削減を狙う
- ディレクトリ構造:以下のディレクトリ構造に沿ってドキュメントを保存することで、素早く自身が求めているドキュメントに到達できるようにする
.
├── 001-チーム作業フォルダ
│ ├── 000-チームビルディング
│ ├── 001-企画フェーズ
│ ├── 002-設計・開発フェーズ
│ ├── 003-発表フェーズ
│ ├── 004-チーム朝会
│ └── 999-その他
├── 002-資料
│ ├── 000-キックオフ
│ ├── 001-朝会
│ ├── 002-夕会
│ └── 999-その他
├── 003-AWS講義
├── 004-ナレッジ共有
├── 099-個人フォルダ
├── README.boxnote
└── 全体スケジュール.xlsx
このように、チームビジョンやルールを固めたことで、プロジェクトを一貫した方向性で進められる基盤が整い、メンバー間の温度感のズレを最小限に抑えられました。
スクラム開発をした人が自分以外いない！スクラムの理念の伝え方の工夫
チームのスクラム開発の習熟度
ANGEL Dojo 2024では、私以外にスクラム開発の経験があるメンバーは誰もいませんでした。
ただ、AWSさんの提供する講義の中でスクラム開発の基本的な語句や知識を学んでいたため、座学で基礎は理解している状況でした。（もし講義がなければ、まずスクラム開発の基礎を学ぶワークショップが必要だと考えています。）
「ユーザーに本当に価値あるものを届ける」ためにスクラム開発を採用した以上、チームがうまく回らなければ意味がありません。
そこで、以下の2つの対策を実施しました。
know-whyで伝える
スクラムの理念を伝える際には、「know-why」で説明することを心掛けました。
know-whyの説明: 単に「何をするか」ではなく、「なぜそれを行うのか」を説明することで、目的を理解してもらう方法です。
私自身が初めてスクラム開発を経験した際、各スプリントイベントの目的やスクラムの理念（例: 透明性の向上）を一度で理解するのが難しかった経験があります。スクラムには特有の用語が多く、それらを短期間で全て理解するのは大変でした。
そこで、スクラム開発の初期段階では、「なぜこれが必要なのか」「なぜこのイベントを行うのか」をくどいほど丁寧に説明しました。ただし、スプリントを一度経験した後の方が理解が深まると考え、次のような手順を取りました。
- 1回目のスプリントでは、スクラムの用語やイベントを簡単に説明し、全体像（What）を理解してもらう。
- 2回目以降のスプリントで、「なぜこのイベントが重要なのか」（Why）を詳しく伝える。
この方法を実践した結果、メンバーから「これ、講義や最初のスプリントで学んだやつだ！わかるぞ！」といった某ゼミ様の広告のようなポジティブな反応を得られました。
チームノートにスクラム開発の情報を記載
「know-why」で説明するだけでは、人は忘れてしまいます。そのため、スクラムの重要な情報をまとめたチームノートを作成しました。
これにより、メンバーは必要な情報をいつでも見返せるようにし、最低限の知識をすぐに得られる体制を構築しました。（もしプロジェクトの規模が大きかったり、期間が長かった場合は、より工夫が必要だと考えています。）
実際に記載していた、スクラム開発の体制は以下のように記載していました。
| 役割 | 担当者 | 責任を持つ範囲 | 具体的な内容 |
|---|---|---|---|
| PO（プロダクトオーナー） | 滝澤 | プロダクト（What）について責任を持つ | ・プロダクトビジョンを決定する：なぜこのプロダクトが存在するのか、何を成し遂げるのかを明確にする ・プロダクトゴールを設定する：ビジョンに到達するための段階的な目標を決める ・プロダクトバックログを作成し、関係者をゴールへ導くロードマップを構築する ・顧客へ価値を届けるためのリリース計画を作成する ・プロダクトバックログを整理し、必要な項目をタイムリーに揃える ・顧客に価値を提供する責任を負う |
| SM（スクラムマスター） | 日高 | スクラムプロセスの管理を担う | ・スクラムとアジャイルの価値をチームに理解させ、実践する ・プロダクトバックログを効果的に管理する方法を見つける ・長期的なプロダクト計画を理解し、伝える ・ビジョン、優先順位、ゴールを明確にスクラムチームに伝達する ・明確なバックログアイテムを作成するためにチームと協働する ・スクラムイベントをファシリテートし、ステークホルダーとの協力を促進する |
| D（開発者） | 全員 | どのように（How）の部分に責任を持つ | ・プロダクトオーナーが定めたWhatを、どのように届けるかを考え実行する ・スプリントバックログを作成し、計画を立てる ・スプリントゴールを達成するために日々計画を調整する ・完成の定義を守り、品質を確保する ・お互いに専門家として責任を持って作業を進める |
チーム内のメンバーのスキルセットがバラバラ！チームの習熟度向上の工夫
開発初期のスキルセット状況
開発初期、チームメンバーのスキルセットには大きなばらつきがあり、経験や知識に差がある状態でした。
そこで、以下の3つの対策を行いました。
プランニングポーカーの活用
スプリントプランニング時には、プランニングポーカーを取り入れました。
- プランニングポーカーとは：タスクの見積もりをする際、各メンバーが自分の見積もりポイントを一斉に提示し、意見をすり合わせる手法です。これにより、メンバーの知見を集約できます。たとえば、一人が大きなポイントで見積もり、もう一人が小さいポイントで見積もった場合、それぞれが異なる視点（リスクや簡略化の方法）を提供できるかもしれません。
この手法の目的は、タスクの見積もりにとどまらず、メンバー同士の知識交換を促進することです。
見積もりの議論を通して、不明点を解消し、技術レベルの向上を目指しました。
特に初期のスプリントプランニングでは、スクラムチームの成熟を促すために時間をかけて実施しました。
またプランニングポーカーには「Plapo」を利用しました。Plapoは無料で使え、1人がルームを作れば簡単に始められるため、スムーズに進行できます。
有識者とのペアプログラミング
経験豊富なメンバーと初心者をペアにしてコーディングを実施しました。これにより、リソースの有効活用と知識の効率的な習得を図りました。
また、各メンバーがANGEL Dojoの初期にやりたいと述べていた技術領域に重点的に取り組めるよう調整しました。
勉強会の開催
最低限必要な技術（CICD、IaC、Gitの操作方法など）について、テーマごとに勉強会を開催しました。
メンバーが互いに不明点を教え合うことで、理解度を高めました。
スプリントプランニング準備の過負荷！現実的なタスク見積もりの工夫
スプリントプランニング準備の課題
初期の開発段階では、メンバーのスキル差が大きく、開発者の習熟度が低かったため、スプリントプランニングを行うまでに熟練したメンバーの協力を得ながら、すべてのPBI（プロダクトバックログアイテム）とSBI（スプリントバックログアイテム）を詳細に準備していました。
依存関係や開発手順、関連する参考資料のリンクなどを一つ一つ記載する必要があり、準備に非常に多くの時間を費やしていました。
現実的なタスク見積もりの工夫
スプリントプランニング準備の過負荷を軽減し、より現実的な方法で進めるために、次の具体的な工夫を取り入れました。
PBIを事前に準備し、SBIの詳細はプランニング時に決定
スプリントプランニング前には、PBI（プロダクトバックログアイテム）をテンプレートに基づいて準備しました。PBIには以下の内容を簡潔に記載することで、スプリントプランニングの時間を有効に活用しました。- 前提条件： PBIを実施するための環境や準備事項を明確化
- インクリメントの定義： 完了後に得られる成果物を具体的に記述
- 完了条件： PBIがどのような状態で完了とするかの基準を設定
- スプリントバックログアイテム（SBI）： PBIを実行するために必要なタスクを箇条書きで記載（例：学習タスク、導入タスク、手順のまとめ）
SBIの詳細化はスプリントプランニング時に実施しました。チームメンバー全員が集まり、具体的なタスク内容を議論し、依存関係や開発手順をその場で決定することで、時間を効率よく使いました。
PBIのポイント見積もりとSBIの時間見積もり
PBIはプランニングポーカーを使ってポイントで見積もりました。プランニングポーカーでは、各メンバーが一斉に見積もりカードを提示し、意見の違いがある場合は理由を共有し、全員が納得するまで議論しました。これにより、タスクに対するリスクや複雑さを共有しやすくなりました。- 具体例: 「PBIのポイント見積もり」は、タスクの規模や難易度に応じて1, 2, 3, 5, 8, 13などの フィボナッチ数列を使用。数値が大きくばらついた場合は、メンバーがリスクや効率的な方法について話し合います。
- SBIの時間見積もり: SBIは、各メンバーが主観的に「実際に作業するのにどれくらい時間がかかるか」を見積もります。時間は「2時間」などの具体的な単位で設定し、スプリントの進捗を正確に追跡できるようにしました。
スプリントプランニングの進め方
- 1. スプリントゴールの決定: スプリントの目的を全員で確認し、「このスプリントで達成するべきこと」を具体的に決めました。例：「このスプリントでは中間発表用の機能を完成させる」といった目標設定。
- 2. PBIの選出: プロダクトオーナーがスプリントで取り組むPBIを選出し、開発者と共に確認。各PBIに対して、チーム全員でポイントを見積もりました。
- 3. SBIの分解と担当割り振り: 選出したPBIを、実際の作業タスクであるSBIに分解しました。このとき、各メンバーがSBIの詳細について質問し合い、理解を深めました。疑問点がある場合はその場で解決し、具体的な開発手順や必要なリソースを決めます。
- 4. 所要時間の見積もり: 各SBIに対して担当者が予測所要時間を記入。例えば、「このタスクは1人で4時間かかる」「ペアプログラミングなら6時間」など。完了後には、実際にかかった時間を記録することで、次回以降の見積もり精度を向上させました。
スプリントプランニング後のフォロー
スプリントプランニング終了後も、疑問や問題が発生した場合はすぐに話し合えるよう、チーム内で定期的なコミュニケーションを確保しました。これにより、計画と実際の作業との乖離が最小限に抑えられました。
この工夫により、スプリントプランニングの準備が効率化され、メンバーの理解度が向上しました。また、タスクの進め方を自ら考えることで、開発者としてのスキルアップにもつながりました。
タスクの進捗やチームの成長が見えにくい！可視化して情報の透明性を上げる
2種類のバーンダウンチャートの導入
スクラム開発で進捗の透明性を高めるため、PBIとSBIの2種類のバーンダウンチャートを導入しました。これにより、進捗を詳細に管理し、計画の見直しがしやすくなりました。
バーンダウンチャートとは：
バーンダウンチャートは、プロジェクトのタスク量を時間とともに可視化するグラフです。縦軸にタスク量、横軸に時間を取り、進捗を折れ線グラフで示します。3種類の線があります：
- 実績線： 実際に完了したタスクを示す線。タスクが完了するたびに減少します。
- 計画線： 予定通りに進行する場合のタスク消化量を示す線。これと実績線を比較することで、進捗の遅れや順調さを判断します。
- 理想線： タスクが理想的に消化される場合を表す線。均等に進行するペースを示します。
ANGEL Dojo 2024 では具体的に 2 種類のバーンダウンチャートを導入しました。
- PBIバーンダウンチャート： スプリント全体の進捗を把握し、大まかなスケジュールの遅れや成果物の完成状況の比率を確認できます。
- SBIバーンダウンチャート： スプリント内の細かい進捗を追跡し、タスク単位での課題を早期に発見します。
今回は、タスク管理ツールに Backlog を利用したので純正で用意されているバーンダウンチャートを利用しました。
昨日の天気の実践
スクラム開発でのチームの成長を可視化（成長を実感できるとモチベーション向上にも寄与）するために、「昨日の天気」を活用してベロシティを計測し、次回のスプリント計画に役立てました。
これにより、メンバーが自分たちの生産性や改善点を具体的に把握でき、振り返り（レトロスペクティブ）での議論もより有意義なものになりました。
- 昨日の天気とは：
「昨日の天気」は、過去のスプリントで達成した実績をもとに、次回スプリントの計画を現実的に立てるための指標です。
具体的には、以下の要素を活用しました。
- Sprint: スプリント番号を記載します（例: 1, 2, 3...）。
- 計画値のベロシティー: スプリント開始前に設定した計画ベロシティー（達成したいポイント数）を記入します。
- 実際のベロシティー (point): スプリント終了時に実際に達成できたPBIのポイント数を記載します。これがスプリントごとの生産性の指標になります。
- 木金稼働可能時間 (h): スプリント中にメンバーが確保できる稼働時間（木曜・金曜）を記入します。スプリントによって異なる場合があるので調整が必要です。
- キャパシティ: チームの稼働率を記録します（例: 100%で全員フル稼働、50%で半分の稼働）。
- 補正したベロシティー (point): 実際の稼働状況に基づき、計画ベロシティーを補正した値を算出します。これを参考に次回のスプリント計画を調整します。
- 実績値 (h): 実際に確保できた稼働時間を記録します。
- 昨日の天気: 実績値と補正したベロシティーを比較し、スプリントごとの生産性を示します。
- 生産性 (point/h): PBIのポイント数を稼働時間で割って、生産性（1時間あたりのポイント数）を算出します。
PBI・SBIの更新がされない！リマインドルールで更新タイミングを決定
PBIやSBIが同期的に更新されず、口頭で何度伝えても反映されない問題がありました。
この状態では、バーンダウンチャートを見ても正確な進捗がわからず、スクラム開発の透明性が確保できていませんでした。
原因の分析
チームで話し合ったところ、メンバーは複数のSBIをまとめて一気に処理する性質があり、その集中作業が優先されるため、タスクの更新が後回しになっていることが判明しました。
解決策の実施
そこで、特定の時間を決めて、全メンバーが一括でPBI・SBIを更新する運用に変更しました。また、更新を忘れないようにするため、Slackで以下の自動リマインドルールを設定しました。
- 自動リマインド: 決まった時間にSlackで通知を送信
- メンション付きリマインド: チーム全員に通知が届くようにメンションを設定
- 対応確認: 更新が完了したら、各メンバーがスタンプを付与することで対応完了を確認
スプリントプランニングの成功法！ユーザーストーリーを明確化
スプリントプランニングの際に、顧客が本当に困っていることや必要としているものを具体的に把握するため、プロダクトオーナーが優先順位を正確に付けられるよう工夫しました。
- 1. ユーザーインタビューの実施 ：顧客が抱える課題や要望を正確に把握するために、実際のユーザーとインタビューを行いました。ユーザーが何に困っているのか、どのような解決策を求めているのかを掘り下げて聞き出しました。
- 2. マインドマップで整理 ：インタビューで得た情報を、Miroなどのマインドマッピングツールを使って可視化しました。これにより、ユーザーのニーズが視覚的に整理され、チーム全体での共通理解が得られました。
- 3. ユーザーストーリーの明確化 ：マインドマップをもとに、ユーザーストーリーを具体化しました。「〇〇として、△△することで、□□を実現したい」という形式で記述し、全メンバーが顧客の価値を共有できるようにしました。
デイリースクラムの効率化！
デイリースクラムですが、毎日行う作業となるので目標は達成しつつ、少しでも効率化しておきたいイベントだと思っていました。
そのためメンバーの関係値により以下 2 STEP でデイリースクラムを効率化していきました。
1. 初期はF2Fで実施 ：開発初期は、メンバーが顔を合わせて進捗を報告するF2Fのデイリースクラムを実施しました。これにより、相互理解が深まりました。
2. 関係値構築後にテキストベースへ移行
ある程度の信頼関係が構築されたタイミングで、デイリースクラムを効率化するために、以下のテンプレートを用いてSlackで進捗を報告する形式に変更しました
【前活動日やったこと】 【今日やること】 【困り事や共有事項】 【チームとして改善した方がいいこと/アイデア】
振り返り内容を忘れる！KPTフレームワークで改善を促進
忙しい開発の中で、振り返りをした際の内容が忘れられることがあり、改善が後回しになることがありました。
そのため以下の 2 点で対策をしました。
1. KPTフレームワークの導入
定期的にKPT（Keep, Problem, Try）フレームワークを使って振り返りを実施しました。
- Keep: 継続したい良い取り組みを共有
- Problem: 問題点や課題を洗い出し
- Try: 改善策を提案し、次のスプリントに向けたアクションを決定
2. Tryの継続確認とPBI化
改善点をPBIとして管理し、完了したらクローズすることで、改善が確実に行われるようにしました。
これにより、チームは改善サイクルを確実に回し続けることができ、プロジェクトのクオリティが向上しました。
スクラム開発 実践時に意識した AWS アーキテクチャ
スクラム開発を AWS を使って実践する上で、意識していたのが「開発以外の負担を軽減させる工夫」です。
ポイントに絞って説明していきます。
サーバーレスサービス・マネージドサービスの採用
AWSを活用してスクラム開発を進める際、「開発以外の負担を軽減させる工夫」として、サーバーレスやマネージドサービスを積極的に取り入れることは非常に有効です。
これにより、インフラの管理やセキュリティのアップデートといった運用負担が軽減され、開発チームがプロダクト開発に専念できるようになります。
負担軽減の背景にある責任共有モデル
AWSでは「責任共有モデル」という考え方が基本にあります。これは、クラウドプロバイダーであるAWSとユーザーが、それぞれ異なる責任を持つというモデルです。
- AWSの責任: ハードウェア管理、インフラの物理的なセキュリティ、ネットワーク構成、ホストOSのパッチ適用など、クラウドの「セキュリティそのもの」を担います。また、マネージドサービスでは、バックアップの仕組みや耐障害性のある設計などもAWSが自動で管理します。
- ユーザーの責任: アプリケーションのセキュリティ設定、データ保護、アクセス管理など、クラウド上で「どのようにサービスを利用するか」に関する設定です。
このモデルから分かる通りにより、サーバーレスやマネージドサービスを取り入れることで開発チームがプロダクト開発に専念しやすい環境を作ることができます。
CICD + IaC の導入
スクラム開発をAWS環境で実践する際、CICD（継続的インテグレーションと継続的デプロイメント）とIaC（Infrastructure as Code）の導入は、開発チームの生産性向上に大きく貢献します。
CICD の導入によるメリット
- 迅速なフィードバック: コードの変更が自動的にビルド・テストされることで、バグや問題点が即座にフィードバックされます。これにより、開発者は素早く修正に取り組むことができ、品質の高いコードが継続的にデプロイされます。
- リリースの高速化: 手動のデプロイ作業を自動化することで、ソフトウェアのリリースが迅速かつ頻繁に行えるようになります。これにより、ユーザーからのフィードバックを早期に取り込み、製品の改善に活かすことが可能になります。
- 信頼性の向上: 自動化されたパイプラインにより、人為的なミスが減少し、安定したデプロイが実現します。さらに、すべてのテストが通過しなければリリースされないため、コードの品質が保証されます。
IaC の導入によるメリット
- 環境の一貫性: インフラをコードで管理することで、本番環境・テスト環境・開発環境を完全に同じ設定で構築できます。これにより、環境間の違いによる不具合を防ぎ、一貫した動作が保証されます。
- スケーラビリティ: コードでインフラを定義することで、リソースのプロビジョニングやスケーリングが迅速に行えるようになります。スケールアップやスケールダウンの対応も容易になり、変化に柔軟に適応できます。
- 変更管理とトレーサビリティ: インフラの設定もコードとしてバージョン管理できるため、誰が、いつ、どのような変更を行ったかが明確になります。これにより、トラブル発生時の原因特定や復旧もスムーズです。
AWS のサービスで上記を実現するには以下のサービスが利用できます。
- CICD：AWS CodePipeline、Amazon CodeCatalyst
- IaC：AWS CDK、CloudFormation、SAM
私のチームでは、ANGEL Dojo 2024 で Amazon CodeCatalyst と AWS CDK を使いました。
詳しくは以下をご覧ください。
通知監視
AWS環境における通知監視は、開発以外の負担を軽減するための重要な要素です。
特に、エラーや異常の即時発見を実現し、迅速な対応を促進する仕組みを実装することで開発に集中できる体制が整うと考えています。
実際の通知実装については、弊社ブログで様々な種類の実装方法を解説していますので、ぜひ参考にしてください！
負荷テストツール
実際にサービスを作成した際に、想定ユーザー数のアクセスに耐えられるか/どこがボトルネックにあるかは、負荷テストを実施して確認する必要があると思います。
ANGEL Dojo 2024 での 負荷テストは Distributed Load Testing on AWS を使用して実施しました。
以下の理由から、このツールを選定しました。
AWS環境内で完結できる make it ! の検証環境が既にAWS上に構築されているため、AWSサービスを利用することでテストをシームレスに実施できます。これにより、開発者の負担を最小限に抑えることができると考えました。
既存で利用しているサービスを活用したい 既に利用しているAWSのサービスを使うことで、新たなツールの導入にかかる登録や設定時間、コンソールの操作に慣れるための時間を節約できると考えました
GUIベースの操作が可能 Distributed Load Testing on AWS はGUIベースの操作が可能なため、負荷テストを実施したことが 1 人もいないチームでも直感的に操作できる点がメリットとしてあります。これにより、負荷テストの実施経験がないうちのチームでも効果的にテストを実施できると考えました。
「Distributed Load Testing on AWS 」を使った負荷テストの実践は以下にまとめているのでよければご覧ください。
まとめ
最後まで読んでいただきありがとうございます。
本記事では、ANGEL Dojo 2024でパートナー部門W受賞チームのスクラムマスターを初めて務めた私が、「スクラムマスター初学者」や「ANGEL Dojo参加者」の方々に向けて、AWSでスクラム開発を進める上で意識したポイントを解説させていただきました。
本記事が誰かの助けになれば幸いです。
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
