IT Project Management Japanese Practical Guide: Agile, Scrum, Kanban Terminology and Business Expressions

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

(Translation: Good morning. Let's begin the morning meeting.
Please share in the order of yesterday's work, today's plan,
and any blockers. Tanaka-san, please go first.)

[Team Member - Report]
「おはようございます。田中です。

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

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

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

以上です。」

(Translation: Good morning. This is Tanaka.
Yesterday's results: Completed backend implementation of user auth.
Submitted a PR and requested review from Suzuki-san.
Today's plan: Starting frontend integration for auth feature.
Will also work on test case creation in parallel.
Blockers: The DB connection in staging sometimes times out.
I'm checking with the infra team, but if anyone has insight,
I'd appreciate the advice. That's all.)

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

(Translation: Thank you. For the DB connection issue, Sato-san
has expertise, so please consult with them after the meeting.
Any other items to share? If not, let's have a productive day.)

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

(Translation: I'd like to propose the MVP release of the payment
feature as this sprint's goal. Specifically, the goal is to
complete the following 3 user stories.)

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

(Translation: Let's estimate the points for this story.
On the count of three, show your cards.
Ah, we have a spread between 3 and 8.
Could those who estimated 8 share their reasoning?)

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

(Translation: We're planning for 34 points this sprint based on
last sprint's velocity. The current backlog items total 38 points,
so we'll need to defer one lower-priority item. Which one should
we move to the next sprint?)

[Sprint Review Presentation Template]
「第15スプリントの成果を報告いたします。

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

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

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

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

(Translation: I will report the results of Sprint 15.
Sprint Goal: MVP release of payment feature
Achievement: Goal met (11 SP completed out of planned 12 SP)
Completed stories: 1. Basic credit card payment flow (5SP)...
Incomplete: 4. Payment email notification (1SP) - Not completed.
Reason: The email delivery service API spec was changed, requiring
more investigation time than expected. Carried over to next sprint.
Let me show you the demo. I'll share my screen.)

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

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

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

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

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

(Translation: Let's begin the retrospective.
We'll use the KPT format this time.
First, take 5 minutes to write on sticky notes.
K (Keep): Pair programming was effective, leading to early bug detection.
PR review speed improved - 80% reviewed within 24 hours.
P (Problem): Tasks tend to pile up in the second half of the sprint.
Impact estimation for spec changes was too optimistic.
T (Try): We want to break tasks into smaller pieces for daily output.
When spec changes occur, we want to list all impacted areas first.
Which Try items would you like to prioritize? Please vote.)

Subject: [Weekly Progress Report] User Management System Development
         Week 15 (3/5-3/11)

関係者各位 (To all concerned parties)

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

(Thank you for your hard work. This is Kim, Project Leader.
I am reporting this week's progress.)

■ Overall Status: On Track (Green Signal)

■ This Week's Results
1. User Authentication Module: 100% Complete
   - Unit tests and integration tests completed
   - Deployed to staging environment
2. Payment Integration: 75% Complete (60% last week -> 75% this week)
   - Basic Stripe API integration flow implemented
   - Error handling under testing
3. Admin Dashboard: 20% Complete
   - Wireframes approved
   - Frontend implementation started

■ Next Week's Plan
1. Complete payment integration (target 100%)
2. Implement admin dashboard basic layout
3. Develop performance test plan

■ Risks and Issues
[RISK] Payment API rate limits may affect load testing
[MITIGATION] Requesting temporary limit increase from vendor

■ Items Requiring Discussion
- Please confirm attendees for March 20th release decision meeting
- Need approval for staging environment spec upgrade

ご確認よろしくお願いいたします。
(Thank you for your review.)

金 (Kim)

[Nemawashi Email Example]
Subject: [Prior Consultation] Regarding Architecture Change Proposal

鈴木部長 (Director Suzuki)

お疲れ様です。金です。
(Thank you for your hard work. This is Kim.)

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

(I am writing to consult with you in advance regarding the
architecture change I plan to propose at next week's technical
review meeting.)

■ Proposal Overview
We are considering separating the payment service from our current
monolithic architecture into a microservice.

■ Background
- Risk of payment processing failures affecting the entire system
- Need for independent deployment cycle for the payment team
- Desire for flexible support of future payment methods

■ Points for Your Input
1. Could you share your thoughts on this direction?
2. Are there any points we should be mindful of for the
   technical review discussion?

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

(I apologize for the imposition on your busy schedule, but
I would be grateful if you could spare some time by next Wednesday.)

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

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

第1段階（3月12日-14日）：機能テスト完了、統合テスト
第2段階（3月15日-17日）：パフォーマンステスト、セキュリティレビュー
第3段階（3月18日-19日）：リリース判定会議、手順書最終確認
第4段階（3月20日）：本番リリース実施、リリース後モニタリング

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

(Translation: Let me confirm the preparation stages for the release.
Stage 1 (Mar 12-14): Function test completion, integration testing
Stage 2 (Mar 15-17): Performance testing, security review
Stage 3 (Mar 18-19): Release decision meeting, final procedure review
Stage 4 (Mar 20): Production release, post-release monitoring
Owners and deadlines for each stage are as attached.
Please contact me if you have any questions.)

[Responding to a Spec Change Request]
「仕様変更のご依頼について確認いたしました。

■ Change Details
Add department name filtering to the user search screen

■ Impact Analysis
1. Frontend: Add dropdown to search form (2SP)
2. Backend: Add query parameter to search API (1SP)
3. Database: Add index on department table (0.5SP)
4. Testing: Update existing test cases and add new ones (1.5SP)
Total: 5SP (approximately 2.5 days of work)

■ Schedule Impact
If added to the current sprint, one of the following is needed:
Option A: Defer current sprint task (admin graph display) to next sprint
Option B: Handle in next sprint (estimated completion March 25th)

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

(If you could decide which option to proceed with by tomorrow,
schedule adjustments can proceed smoothly.)

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

[Jira Ticket Example]

■ Title:
【決済】クレジットカード決済のリトライ処理実装
(Payment: Implement credit card payment retry processing)

■ Type: Story
■ Priority: High
■ Story Points: 5
■ Sprint: Sprint 15
■ Assignee: Tanaka Taro
■ Labels: Payment, Backend

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

(As a user, I want payment processing to automatically retry
on temporary failures to improve payment completion rates.)

■ Acceptance Criteria:
1. When payment API returns temporary error (HTTP 429, 503),
   retry up to 3 times
2. Retry interval uses Exponential Backoff (1s, 2s, 4s)
3. On final failure, display error message to user
4. Retry history is logged
5. Retry count and success rate metrics are available

■ Technical Notes:
- Follow Stripe API retry policy
- Use Idempotency Key to prevent duplicate payments
- Plan to use SQS for retry queue

■ Related Tickets:
- PROJ-123 (Basic payment flow implementation) - Blocking
- PROJ-125 (Payment error notification) - Related

[Situation]
An architecture change was proposed for the first time at a technical
review meeting, but the department director said they hadn't heard about
it and the conclusion was "持ち帰り検討" (take it back for further review).

[Lesson]
In Japanese organizations, nemawashi is essential before important
proposals. It is critical to send prior consultation emails to senior
stakeholders or gather opinions through 1:1 meetings beforehand.

[Improvement Actions]
- Send prior consultation email to stakeholders 1 week before proposal
- Confirm direction through 1:1 with department director
- Share review materials in advance and request comments

[Situation]
Verbally communicated spec changes were implemented without documentation.
Later, the stakeholder claimed "そんな話は聞いていない" (I never heard about
that), resulting in rework.

[Lesson]
In Japan, recording all changes in a 仕様変更管理台帳 (spec change
management ledger) and obtaining written 承認 (approval) from
stakeholders is essential.

[Improvement Actions]
- Always confirm verbal spec changes via email
- Record in spec change management ledger and share with stakeholders
- Document impact analysis and schedule effects of changes

[Situation]
Team members did not honestly share problems during retrospectives,
causing the same issues to recur repeatedly.

[Lesson]
Japanese culture tends to avoid 直接的な批判 (direct criticism).
Mechanisms to ensure 心理的安全性 (psychological safety) are necessary.

[Improvement Actions]
- Use anonymous sticky note format for writing feedback
- Rephrase "things we're struggling with" as "things we can improve"
- Have the Scrum Master share their own failures first to ease the atmosphere