Mind Map Studio で次の Jira リリースを視覚的に計画する
カスタマーポータルのリリースを例に、Jira の課題一覧から、対象範囲の視覚的なレビュー、共有の公開チェックリストまでを見ていきます。
Jira リリースの課題一覧がきれいに整理されていても、チームに疑問が残ることはあります。
このリリースで顧客にとって何が変わるのでしょうか。どの作業が関連しているのでしょうか。公開前に何をテストすべきでしょうか。そして開発が完了した後、すべてを本番環境に反映するには何が必要でしょうか。
課題一覧は、こうした話し合いの出発点です。マインドマップを使えば、別の角度から検討できます。関連する作業をまとめ、計画上の疑問を該当する領域のそばに置き、チームで対象範囲を確認できます。
このガイドでは、カスタマーポータルのリリースを準備する架空のチームを取り上げます。Mind Map Studio を使ってリリースの Jira 課題をマップに追加し、対象範囲を整理して、共有のリリース手順書を作成します。
次のリリースでも、少数の課題と短いチェックリストから同じ方法を始められます。
Jira の今後のリリースから始める
例に登場するチームは、次の3つの領域を含むカスタマーポータルの更新を準備しています。
- ログイン：パスワード再設定の案内をわかりやすくし、期限切れリンクのメッセージを改善する。
- 通知：メールの設定項目を追加し、通知の重複を修正する。
- 請求：請求書に表示される請求先住所を修正する。
チームは Jira で未リリースのバージョンを作成し、「Fix versions」から関連する課題を割り当て済みです。
この準備は重要です。Mind Map Studio の「Jira releases」パネルには、現在の Jira プロジェクトのバージョンがリリース済み・未リリースの状態とともに表示され、割り当てられた課題を確認できます。このパネルで作業を計画する前に、Jira でバージョンを作成し、課題の割り当てを管理してください。
手順を試すには、プロジェクトとその課題を表示する権限、および編集できるマインドマップが必要です。
マップを開き、ヘッダーで「Jira releases」を選択して、話し合いたい未リリースのバージョンを見つけます。「Attached issues」セクションには、Jira でそのバージョンに割り当て済みの作業が表示されます。
リリースに課題が割り当てられていない場合は、表示されるはずの課題の「Fix versions」フィールドを確認してください。空のリリースにも手順書は作れますが、マップに追加する割り当て済み課題はまだありません。
チームで話し合える形にリリースを整理する
リリースが明確にわかる名前の中心トピックから始めます。
カスタマーポータル — 10月リリース
その下に3つのブランチを追加します。
- ログインとアカウントへのアクセス
- 通知設定
- 請求の正確性
これらのブランチは、サポート、プロダクト、エンジニアリングの各担当者と話し合いやすい言葉で変更内容を表しています。
リリースに合ったグループ分けを選んでください。顧客向けの変更なら、ユーザー体験の各部分に沿って分類できます。インフラのリリースなら、サービスやシステム別のほうが確認しやすいかもしれません。小規模なリリースなら、ブランチは2つで十分な場合もあります。
「この構成なら、何を提供するのかを説明しやすいか」と考えてみてください。
カスタマーポータルの例では、パスワード再設定の課題をまとめると、共通の目的が明確になります。通知の変更をまとめれば、新しい設定項目とメール重複の修正をあわせて話し合えます。
割り当て済みの Jira 課題をマップに追加する
課題を配置したいブランチを選択します。「Jira releases」パネルの「Attached issues」で課題を見つけ、ポインターを重ねてプラスボタンを選択します。
Mind Map Studio は、Jira の課題キーと要約を含む子カードを追加します。リリースパネルから課題をキャンバスにドラッグし、目的の親トピックの近くにドロップすることもできます。
ほかの課題にも繰り返し、リリースを把握しやすい視覚的な構成にします。
課題をマップに追加しても、変わるのはマップだけです。課題の「Fix versions」の変更、課題の編集、Jira 課題リンクの作成は行われません。そのため、Jira での作業の割り当てを変えずに、視覚的なグループ分けをリリースの話し合いに活用できます。
マップを使って対象範囲を確認する
課題を配置できたら、チームでマップを確認します。
まず、シンプルな質問から始めましょう。
提供する予定のものは、すべてここに示されていますか？
ブランチを1つずつ確認します。この例ではログインのブランチに2つの変更がありますが、話し合いの中で別の検討事項が見つかります。サポートチームのパスワード再設定の案内も、更新が必要かもしれません。
関連する作業のそばに、計画用のトピックを追加します。
サポートガイドの更新が必要か確認する。
調査中は疑問のまま残しておいて構いません。進捗を管理すべき作業が必要だと判断した場合は、適切な Jira ワークフローでその作業を作成し、割り当てます。
疑問を関連ブランチの近くに置くと、背景を保てます。ログインの変更を確認する人にも、なぜサポートガイドが話題になったのかがわかります。
個々の課題をまたぐ確認事項を探す
次に、こう尋ねます。
どの変更をまとめて検証すべきでしょうか？
通知のブランチには、新しい設定画面とメール重複の修正があります。各課題にはそれぞれ受け入れ基準があっても、リリースの話し合いでは、組み合わせたときの体験も検討する必要があります。
例えば、次のような点です。
- 通知をオフにすると、対応するメールは送信されなくなりますか？
- 再びオンにすると、期待どおりの動作に戻りますか？
- 通知が有効なとき、顧客に届くメールは1通だけですか？
これらは架空の製品に対する質問の例です。実際の確認事項は、リリースによって変わる動作に合わせてください。
マップは関連する作業を近くに配置することで話し合いを支えます。何をテストするかの判断と、通常のテストプロセスに沿った結果の記録は、引き続きチームが行います。
未解決の疑問を具体的にする
「請求に関する懸念」というトピックだけでは、チームは何をすべきかわかりにくいものです。
より役立つ質問は、次のようなものです。
住所の修正は、すでに発行された請求書にも影響しますか？
この表現なら、不明点が明確になり、回答できる適切な担当者を見つけやすくなります。
レビューを終える前に、未解決の疑問を確認し、誰がフォローするかを決めましょう。話し合いから明確な次の行動が生まれると、視覚的な計画が役に立ちます。
共有のリリース手順書を作成する
対象範囲の理解はリリース計画の一部です。公開当日の調整も欠かせません。
「Jira releases」パネルで、対象バージョンの「Deploy Notes & Checklist」を開きます。ここで、デプロイ手順を順番に並べたチェックリストを作成できます。
手順書はその Jira プロジェクトとリリースに属するため、同じリリースに携わる人が、保存された同じ順序に従えます。
手順を入力し、Enter キーを押すか追加ボタンを選択します。チームで調整すべき作業を網羅するまで追加します。
カスタマーポータルのリリースなら、最初の案は次のようになります。
| 1 | 合意したリリース確認項目にすべて合格したことを確認する。 |
| 2 | デプロイ責任者と復旧手順を確認する。 |
| 3 | カスタマーポータルの更新をデプロイする。 |
| 4 | 本番環境でパスワード再設定の流れを検証する。 |
| 5 | 通知設定とメール配信を検証する。 |
| 6 | 請求書の請求先住所を検証する。 |
| 7 | 監視情報で想定外のエラーがないか確認する。 |
| 8 | リリースの結果をチームに共有する。 |
これは出発点として使ってください。適切な順序は、システム、デプロイプロセス、リリースのリスクによって異なります。
バックアップ、承認、メンテナンスの告知を明示的な手順にする必要があるチームもあります。一方、デプロイが自動化されており、手順書では主に検証と連絡を調整するチームもあります。
迷わず完了できる手順を書く
「すべて確認する」では、毎回同じように実行するのが困難です。
「顧客がパスワード再設定メールを要求し、リンクを正常に使えることを検証する」なら、確認する人に具体的な行動が伝わります。
手順書全体で、この原則を適用しましょう。
- 行動を明記する。
- 対象の機能やシステムを特定する。
- 役立つ場合は、期待する結果を明確にする。
チェックリストは読みやすく保ちましょう。詳細な運用手順はチームの既存文書に残して構いません。手順書では、リリースの順序を追いやすくすることが大切です。
Mind Map Studio では、手順を上下に移動したり、削除したり、完了にしたりできます。完了した手順の数と進捗バーで、手順書がどこまで終わったかがわかります。
この進捗は手順書のものです。手順を完了しても、Jira 課題のステータスは変わらず、Jira バージョンがリリース済みになることもありません。
計画を Jira と整合させる
最初の計画会議の後に、リリースの対象範囲が変わることがあります。
課題が後のバージョンに移るかもしれません。テスト後に修正が追加されるかもしれません。本番環境で別の確認が必要になるような実装変更を、チームが行うこともあります。
Jira でバージョンや課題の割り当てが変わったら、「Refresh Jira releases」を選択して、現在のバージョンと割り当てられた課題を取得します。
その後、更新された対象範囲とマップおよび手順書を照らし合わせます。視覚的な計画がリリースを引き続き表しているか、デプロイ手順が今も適切かを確認してください。
リリース一覧を更新した後には、計画のレビューが必要です。既存マップのすべての部分が自動的に整合されたとは考えないでください。
次の役割分担を明確にしておきましょう。
| リリースバージョンの作成 | リリースの視覚的な配置 |
| 「Fix versions」による課題の割り当て | 割り当て済み課題のマップへの追加 |
| リリース日の設定 | 関連作業のそばへの計画トピックの配置 |
| 課題とリリースのステータスの更新 | リリース手順書の手順の作成と完了 |
何かが見当たらないときにも、この区別が役立ちます。「Attached issues」に課題がない場合は、Jira でそのリリースへの割り当てを確認してから、パネルを更新してください。
よくある3つの計画ミスを避ける
マップを細かくしすぎてレビューしづらくする
すべてのブランチに長いメモや細かな実装詳細が入っていると、リリース全体を理解しにくくなります。
リリースの主要な領域と関連する Jira 課題から始めましょう。計画上の疑問に答える助けになる場合に、補足トピックを追加します。詳細な要件は Jira 課題に持たせてください。
検証手順を曖昧なままにする
「ログインをテストする」は、人によって意味が異なることがあります。
リリースで変わる動作を明記しましょう。この例では、更新対象であるパスワード再設定の要求と期限切れリンクについて、具体的な確認が必要です。
チェックリストの完了をリリース成功の証拠とする
完了した手順書が示すのは、各手順に完了のチェックが付いたことです。チームには引き続き、適切なテスト結果、本番環境の観察結果、リリースの成否に関する判断が必要です。
検証手順を完了する前に必要な証拠を合意し、Jira でのリリース更新は通常のプロセスに従ってください。
次の Jira リリースで試してみる
課題数が扱いやすい、今後のリリースを1つ選びます。
Mind Map Studio でマップを開き、「Jira releases」でバージョンを見つけ、割り当てられた課題を意味のあるいくつかのブランチに配置します。その全体像を使って対象範囲を話し合い、未回答の疑問を見つけましょう。その後「Deploy Notes & Checklist」を開き、公開当日にチームがたどる順序を書きます。
カスタマーポータルのチームには、同じリリースを示す2つの有用な見方が得られます。何が変わるかを説明するマップと、公開および検証を調整するチェックリストです。
まずはこの小さな成果から始めましょう。次のリリース会議で、どのグループ分け、疑問、確認事項がチームに最も役立つかを確かめられます。
次の Jira リリースで Mind Map Studio を試し、チームで一緒に確認できる視覚的な計画を作成しましょう。
関連記事
お問い合わせ
この記事についてご質問がありますか？技術目標についてお話ししましょう。