ITプロジェクト管理日本語実践ガイド: アジャイル・スクラム・カンバン用語とビジネス表現

[スクラムマスター - 開始]
「おはようございます。それでは朝会を始めます。
昨日の作業、今日の予定、困っていることの順番でお願いします。
では、田中さんからお願いします。」

[チームメンバー - 報告]
「おはようございます。田中です。

昨日の実績：
・ユーザー認証機能のバックエンド実装を完了しました。
・PRを出して、鈴木さんにレビューをお願いしました。

今日の予定：
・認証機能のフロントエンド統合に着手します。
・テストケースの作成も並行して進めます。

困っていること：
・ステージング環境のDBへの接続がタイムアウトすることがあります。
 インフラチームに確認中ですが、もし詳しい方がいたらアドバイスをいただけると
 助かります。

以上です。」

[スクラムマスター - 終了]
「ありがとうございます。DB接続の件、佐藤さんが詳しいので、
朝会後に相談してみてください。
他に共有事項はありますか？
なければ、今日もよろしくお願いします。」

[スプリントゴールの提案]
「今回のスプリントのゴールとして、決済機能のMVPリリースを
提案したいと思います。具体的には、以下の3つのユーザーストーリーを
完了することを目標とします。」

[見積もり - プランニングポーカー]
「このストーリーのポイントを見積もりましょう。
せーの、で見せてください。
あ、3と8でバラつきがありますね。
8を出した方、理由を教えていただけますか？」

[キャパシティ確認]
「今スプリントのベロシティは前回実績から34ポイントを想定しています。
現在のバックログアイテムの合計は38ポイントですので、
優先度の低いものを1つ外す必要がありそうです。
どれを次のスプリントに回しましょうか？」

[スプリントレビュー発表テンプレート]
「第15スプリントの成果を報告いたします。

■ スプリントゴール：決済機能のMVPリリース
■ 達成状況：ゴール達成（計画12SP中、11SP完了）

完了したストーリー：
1. クレジットカード決済の基本フロー（5SP）→ 完了
2. 決済履歴の表示機能（3SP）→ 完了
3. エラーハンドリングとリトライ処理（3SP）→ 完了

未完了：
4. 決済のメール通知機能（1SP）→ 未完了
   理由：メール配信サービスのAPI仕様が変更されたため、
   調査に想定以上の時間がかかりました。
   次スプリントに持ち越します。

デモをお見せします。画面を共有いたします。」

[KPT進行]
「それでは振り返りを始めます。
今回はKPT形式で進めます。
まず5分間、各自で付箋に書き出してください。

K（Keep - 続けたいこと）：
・ペアプログラミングの取り組みが効果的でした。
 バグの早期発見につながりました。
・PRのレビュー速度が改善されました。
 24時間以内のレビュー率が80%に達しました。

P（Problem - 問題だったこと）：
・スプリント後半にタスクが集中する傾向があります。
・仕様変更の影響範囲の見積もりが甘かったです。
 特にDB変更の影響を過小評価していました。

T（Try - 次に試したいこと）：
・タスクの分割をより細かくして、毎日成果が出るようにしたい。
・仕様変更があった場合、影響範囲を一覧にしてから
 着手するようにしたい。

皆さん、Tryの中で特に優先したいものはどれですか？
投票をお願いします。」

件名：【週次進捗報告】ユーザー管理システム開発 第15週（3/5-3/11）

関係者各位

お疲れ様です。プロジェクトリーダーの金です。
今週の進捗を報告いたします。

■ 全体ステータス：予定通り（青信号）

■ 今週の実績
1. ユーザー認証モジュール：100%完了
   ・単体テスト、統合テスト完了
   ・ステージング環境へのデプロイ完了
2. 決済連携：75%完了（先週60%→今週75%）
   ・Stripe API連携の基本フロー実装完了
   ・エラーハンドリングのテスト中
3. 管理画面：20%完了
   ・ワイヤーフレーム承認済み
   ・フロントエンド実装着手

■ 来週の予定
1. 決済連携の完了（100%目標）
2. 管理画面の基本レイアウト実装
3. パフォーマンステスト計画策定

■ リスク・課題
【リスク】決済APIのレート制限により負荷テストに影響の可能性
【対策】ベンダーに一時的な制限緩和を依頼中

■ 要相談事項
・3月20日のリリース判定会議の参加者確認をお願いします。
・ステージング環境のスペック増強について承認をいただきたいです。

ご確認よろしくお願いいたします。

金

[根回しメール例]
件名：【事前相談】アーキテクチャ変更案について

鈴木部長

お疲れ様です。金です。

来週の技術検討会で提案予定のアーキテクチャ変更について、
事前にご相談させていただきたくご連絡いたしました。

■ 提案概要
現行のモノリシックアーキテクチャから、決済サービスを
マイクロサービスとして分離することを検討しています。

■ 背景
・決済処理の障害が全体システムに波及するリスクがある
・決済チームの独立したデプロイサイクルが必要
・将来的な決済手段の拡張に柔軟に対応したい

■ ご確認いただきたい点
1. この方向性について、部長のお考えをお聞かせいただけますか
2. 技術検討会での議論に際して、留意すべき点がありましたら
   ご教示ください

お忙しいところ恐れ入りますが、
来週水曜日までにお時間をいただけると幸いです。

よろしくお願いいたします。

金

[リリースに向けた段取りの例]
「リリースに向けた段取りを確認させてください。

第1段階（3月12日-14日）：
・機能テスト完了
・ステージング環境での統合テスト

第2段階（3月15日-17日）：
・パフォーマンステスト実施
・セキュリティレビュー

第3段階（3月18日-19日）：
・リリース判定会議
・リリースノート作成
・本番環境デプロイ手順書の最終確認

第4段階（3月20日）：
・本番リリース実施
・リリース後モニタリング（2時間）
・問題がなければ完了報告

各段階の担当者と期限は別紙の通りです。
何かご不明な点があればご連絡ください。」

[仕様変更依頼への対応]
「仕様変更のご依頼について確認いたしました。

■ 変更内容
ユーザー検索画面に「部署名」での絞り込み機能を追加

■ 影響範囲の分析
1. フロントエンド：検索フォームにドロップダウン追加（2SP）
2. バックエンド：検索APIのクエリパラメータ追加（1SP）
3. データベース：部署テーブルのインデックス追加（0.5SP）
4. テスト：既存テストケースの更新と新規追加（1.5SP）
合計：5SP（約2.5日の作業量）

■ スケジュールへの影響
現在のスプリントに追加する場合、以下のいずれかが必要です：
A案：現スプリントの他タスク（管理画面のグラフ表示）を次スプリントに延期
B案：次スプリントで対応（3月25日完了見込み）

■ お願い
どちらの案で進めるか、明日中にご判断をいただけますと
スケジュール調整がスムーズに進められます。

ご検討よろしくお願いいたします。」

[Jira チケット例]

■ タイトル：
【決済】クレジットカード決済のリトライ処理実装

■ 種別：ストーリー
■ 優先度：高
■ ストーリーポイント：5
■ スプリント：Sprint 15
■ 担当者：田中太郎
■ ラベル：決済, バックエンド

■ 概要：
ユーザーとして、決済処理が一時的なエラーで失敗した場合に
自動的にリトライされることで、決済完了率を向上させたい。

■ 受入条件：
1. 決済APIが一時的エラー（HTTP 429, 503）を返した場合、
   最大3回までリトライすること
2. リトライ間隔はExponential Backoff（1秒、2秒、4秒）とすること
3. 最終的に失敗した場合、ユーザーにエラーメッセージを表示すること
4. リトライの履歴がログに記録されること
5. リトライ回数と成功率のメトリクスが取得できること

■ 技術的な補足：
・Stripe APIのリトライポリシーに準拠
・Idempotency Keyを使用して二重決済を防止
・リトライキューにはSQSを使用予定

■ 関連チケット：
・PROJ-123（決済基本フロー実装）ブロック中
・PROJ-125（決済エラー通知）関連

件名：【リリースのお知らせ】ユーザー管理システム v2.5.0（3月20日予定）

関係者各位

お疲れ様です。
開発チームの金です。

ユーザー管理システムの次期リリースについてお知らせいたします。

■ リリース日時：3月20日（木）22:00-24:00（JST）
■ バージョン：v2.5.0
■ メンテナンス時間：約2時間（この間サービスは利用不可）

■ 主な変更点
1. クレジットカード決済機能の追加
2. ユーザー検索の高速化（レスポンス時間50%改善）
3. セキュリティパッチの適用

■ 影響範囲
・全ユーザーに影響があります
・メンテナンス中はシステムにアクセスできません
・データの損失はありません

■ お客様への事前通知
・3月18日にアプリ内通知を配信予定
・メンテナンスページの表示を準備済み

■ ロールバック計画
万が一の問題発生時は、v2.4.3へのロールバックを実施します。
ロールバック所要時間：約30分

ご質問やご懸念がありましたら、お気軽にご連絡ください。

よろしくお願いいたします。

金

[状況]
アーキテクチャ変更を技術検討会で初めて提案したが、
部長が事前に聞いていないとして「持ち帰り検討」で結論が出ず。

[教訓]
日本の組織では重要な提案の前に必ず根回しが必要。
関連する上位関係者への事前相談メールの送付や
1on1ミーティングでの意見聴取が不可欠。

[改善アクション]
・提案の1週間前に関係者へ事前相談メールを送る
・部長との1on1で方向性の確認を得る
・検討会資料を事前に共有し、コメントを求める

[状況]
口頭で伝えられた仕様変更を記録せずに実装したところ、
後になって「そんな話は聞いていない」と否定され、
手戻り作業が発生。

[教訓]
日本では仕様変更管理台帳にすべての変更を記録し、
関係者の承認を得ることが不可欠。

[改善アクション]
・口頭での仕様変更は必ずメールで確認を取る
・仕様変更管理台帳に記録し、関係者に共有する
・変更の影響範囲とスケジュールへの影響を文書化する

[状況]
レトロスペクティブでチームメンバーが問題点を率直に話さず、
同じ問題が繰り返し発生。

[教訓]
日本では直接的な批判を避ける文化がある。
心理的安全性を確保するための仕組みが必要。

[改善アクション]
・匿名で付箋を書く形式にする
・「困っていること」を「改善できること」と言い換える
・スクラムマスターが最初に自分の失敗を共有して場を和らげる