2023年4月25日開催ウェビナー｜ITプロジェクトマネジメントに携わる方必見！ガントチャートとロードマップの考え方を市場背景から学び直し

[#1]

2023年4月25日(火)に、アトラシアン主催の無料ウェビナー『ITプロジェクトマネジメントに携わる方必見！ガントチャートとロードマップの考え方を市場背景から学び直し』を開催いたします。

本ウェビナーでは、ガントチャートとロードマップを効果的に業務に活用するにあたって知っておきたい背景知識を、IT開発プロジェクトのトレンドを交えながら、わかりやすく解説いたします。

プロダクト開発にまつわる用語や手法の基本的な理解にご関心のある方は、事前登録の上、ぜひご参加ください。

後日、本投稿に当日のQ&Aでいただいたご質問とそれに対する回答を追記させていただきます。

（以下、4月28日 更新）
本ウェビナーの視聴者からいただいたご質問とそれに対する回答は、以下の通りです。

質問	回答
無理やりガントチャートをロードマップとして使用することはできるのでしょうか？取り扱い方が問題であり、文書のフォーマットや形式の問題というわけではない、と本日のセミナーから理解したのですが。	可能か不可能か、という意味では可能です。ご指摘の通り取り扱い方の問題であるからです。 ただ、その取り扱い方こそが非常に重要である、というのが今回のウェビナーのテーマです。その「ガントチャートをロードマップとして使う」という前提条件を、社内でしっかり認識合わせしておく必要があります。なぜならロードマップとして更新し続けたり、市場情勢や議論の結果、どんどんタイムラインが変わっていく中で万が一社内の誰かが「ウォーターフォール的思考や認識」でその文書を扱い始めたりすると、非常に大きな混乱に繋がるからです。 日本では外部委託開発案件である場合など、アジャイルであっても「期日」「締切」を死守する必要があるケースも有り得るかと存じます。そのような背景から、しっかり精査しつつ、ガントチャート・ロードマップのそれぞれの特徴を適切に理解した上で、「ガントチャートの粒度を細かくしすぎずにロードマップとして使う」というのがキーポイントになるかも知れません。
アジャイルかウォーターフォールか、決めあぐねてしまうパターンというのは存在し得ますか？その場合、どうやって最適解を選ぶべきでしょうか？	ウェビナーでも取り上げたクネビンフレームワークなどを活用して、自身・自社のプロジェクトなりプロダクトがどのような前提に立っているものなのかを改めて理解する、というのが非常に重要かと思われます。関係者の中で合意形成に向かって議論し、例えば「完了日が決まっている」「明確な手順が明らかである」など、ウォーターフォールに向いているキーポイントや、「ひとまず開発してみてフィードバックを得ないと分からないことが多い環境や商材」などアジャイルが適合する要素が、どれぐらいあるのかを社内で合意形成に向買っていくことになるかと思います。業種・業態により様々なケースが想定されますが、上記が一つの選択肢になれば幸いです。
ツールの切り替えに留まらず、企業文化すら変えないと本当の意味でロードマップをロードマップっぽく使うことは難しいのかなと感じました。どのように変えていくのが良いのでしょうか？	ご指摘の通り、企業文化に関わる社内プロセスや会社の意思決定の手順に関わってくるのがロードマップかと思われます。先日対談しました村上臣さんのお言葉でもありますが、「自社の差異化とは本質的に無関係なプロセスについては、全て世界標準のツールを使い、ツールに業務を合わせるよう会社のトップが動く」というグローバル企業の特徴を指摘されていました。企業文化を変える方法は色々あるかも知れませんが、やはりトップが考え方を変えて日々の組織に落とし込むのも効果的な選択肢かと思われます。
途中からの参加になってしまったのですが、今回のウェビナーでは、Jiraでガントチャートを作る方法に関するご紹介はありますでしょうか？	今回のウェビナーは言葉の定義や考え方についての説明がメインとなっており、Jiraの具体的な使い方については触れられません。 Jira Softwareのロードマップ機能については、来月開催のウェビナーで取り上げる予定ですが、ガントチャートの作成方法について取り上げるウェビナーは現時点で予定はない状況です。Jira Softwareの標準機能としてガントチャートの作成機能は提供されておりませんので、Jira Software上でのガントチャートの作成方法については、マーケットプレイスで該当アプリを提供されているサードパーティ各社の情報をご確認ください。
Jiraでは、ガントチャートを作成することは可能なのでしょうか？	Jira Softwareの標準機能としてはガントチャートの作成機能が提供されていないため、マーケットプレイスからサードパーティ各社から提供されているアプリをご利用頂ければ幸いです。
この度は無料セミナーの開催、ありがとうございます。ガントチャートとロードマップは、１つのプロジェクトで同時に使うということもあり得ますか？	例えばアジャイル開発の中で特定のスプリントの作業定義にガントチャートを活用しつつ、プロジェクトの包括的な計画立てにロードマップを活用することは可能です。ですが、スクラムにおけるスプリントのタスク管理にはカンバンなどの選択肢もあり、その方がより見やすいという意見も聞きます。 また、日本では外部委託開発案件である場合など、アジャイルであっても「期日」「締切」を死守する必要があるケースも有り得るかと存じます。そのような背景から、しっかり精査しつつ、ガントチャート・ロードマップのそれぞれの特徴を適切に理解した上で、「ガントチャートの粒度を細かくしすぎずにロードマップとして使う」というのがキーポイントになるかも知れません。
ガントチャートのサマリーがロードマップと捉えるのは間違えでしょうか。	ガントチャートのサマリーをロードマップという位置づけの作り方は可能です。しかし、ロードマップの頻繁な更新に対して、細かい作業項目を書き込んでいるガントチャートを、ロードマップと同じ頻度とスピード感で更新し続ける事が現実的かどうか？この点の議論の余地はあるかも知れません。しかし、一番のポイントはガントチャートとロードマップの思想の違いを理解する事かと存じます。
弊社ではJIRA Softwareを使っています。 今日のお話をお伺いして、弊社ではウォーターフォール型の開発をしているということを改めて認識しました。 開発の現場ではガントチャートを求める声が多く、私自身も現在の開発スタイルからガントチャートを必要としています。 ロードマップ（advanced roadmap？）をガントチャートのように使用することは可能でしょうか？	ご質問いただいた「ガントチャートのように」が具体的にどのレベルの活用方法を指すかによって、一概にはお答えできないため、もしよろしければ次回5月のウェビナーにご参加頂きロードマップのご紹介をお聞き頂ければと思います。また、ガントチャートはマーケットプレイスからサードパーティ各社から提供されているアプリを活用頂くことも可能でございますので、その選択肢も合わせてご検討頂ければ幸いです。
変動に関する情報の流れとして、ガントはフィードバック、ロードはフィードフォワードが主要な情報流通になると考えますが、方法流通を考えるベンダーとして利用のコツとかありますか？	「ガントチャート＝フィードバックの情報流通」というのが期日に対する進捗管理を指すのであればその通りです。頂きました質問では、ガントチャートは過去を振り返って見るもの、ロードマップは未来を見るもの、という捉え方でいらっしゃると想定して、以下がポイントになるかと存じます。 ロードマップがフィードフォワードのように、未来志向であるとはいえ、アジャイルでは経験に基づく振り返りなどを通して、ロードマップを更新していくのがよいこと ガントチャートがフィードバック的な性格であるがゆえ、それに未来志向である各プラクティス（例えば、振り返りを受けて、次どうするのか、を話し合う等）を取り入れるべきであること また、フィードバック・フィードフォワード問わず組織内の情報流通（＝組織間コラボレーションと言い換えても良いかも知れません）を促進するため、弊社は製品群も、それらを組織内で効果的に活用する知見をご提案するプレイブックもご提供しております。ぜひこちらもご覧ください。
ロードマップを描くにあたってエピックの粒度や長さをどうすべきか、が悩ましいと感じています。具体的には、マイルストーンとしての「バージョン」の中で一つのエピックが終わるようにしていくべきなのか、もっと長い期間（複数のバージョン）をまたいでエピックが実現されていくように描いたほうが良いのか。	エピックやストーリーの構造はこちらのページに参考情報がございますが、ケースバイケースで様々なパターンが想定されますため、一概に「必ずこうなる」というものは申し上げられないかと思います。ただ、エピックは一般的には数回のスプリントに渡り完了できる目標となっており、バージョンのリリースの規模によっては１つのリリースに複数のエピックが含まれる場合や１つのエピックのみが含まれるパターンがあるかと思います。そのため、結局のところはリリースの規模によるものになります。 まずは一つのパターンを作り、回してみて、振り返りを経て様々なパターンを試行錯誤していくのも一つの選択肢かも知れません。
プロダクトロードマップの一部を実行するときに使用するのが、ガントチャートなのか？	例えば、アジャイルのスプリントの中の作業項目管理にガントチャートを活用する、というのは可能かと思います。ただ、その場合アジャイルに適した粒度や、柔軟性なども考慮して運用して頂ければと思います。前項「6.」の回答内容もぜひ併せてご確認頂ければ幸いです。
プロダクトマネジメントのフェーズをプロジェクトとして分割して並行連動しながらマネジメントする事例はありますか？経営判断層が混同しやすいですが、関連して把握すべき両方だと思うのですが。	前項の内容と近いご回答になりますが、例えば、プロダクトマネジメントをアジャイルで進める中でスプリントを「一つのプロジェクト」として捉えることは有り得るかと思います。ただ、柔軟性を維持する、頻繁な計画の変更を許容するなどのアジャイルならではの思想・進め方を維持して運用して頂ければ幸いです。
ガントチャートとロードマップ、類似点や違いを理解できました。実際の現場で、ロードマップで立案した計画を一部ガントチャートで管理したり、ガントチャートの進捗やフィードバックをうまくロードマップに取り入れたりできるものなのでしょうか？それに使える便利なツールなどあるのでしょうか？	ロードマップで立案した計画の中で、各作用項目をどこまで細かく厳密に管理するか、というところでガントチャートを活用するかしないか、という議論と思われます。7.のご質問へのご回答の繰り返しとなり恐縮ですが、ロードマップの頻繁な更新に対して、細かい作業項目を書き込んでいるガントチャートを、ロードマップと同じ頻度とスピード感で更新し続ける事が現実的かどうか？この点の議論の余地はあるかも知れません。結果的に、ガントチャートのレベルまで落とし込まないでアジャイルを進めるケースも多いかと思われます。
プロジェクト・プロダクトマネージメント、ウォーターフォール・アジャイル、そのような選択を正しく行うためにお客様や社内でどのような知識を得ることで優れた判断ができるようになるのでしょうか？言葉の定義を理解するだけで簡単に解決する問題でもないかな？と考えたためです。	おっしゃる通り、言葉の定義を理解するだけでは充分とは言えないかと思います。少し前に比べて、アジャイルやプロダクトマネジメントに関する記事・書籍も近年日本で増えてきている印象です。弊社も対談やコラボレーションさせていただいている、小城久美子さんや浪川舞（まいどる）さんのnote記事、そしてプロダクトマネジメントのすべてという書籍などは有名な情報源かと思われます。
ガントチャート機能はいつリリースされるご予定でしょうか	大変恐縮ですが、弊社ではガントチャート機能のリリース予定はございません。マーケットプレイスからサードパーティ各社から提供されている機能をアドオンする選択肢もご検討頂ければ幸いです。
JIRAのPJTをまたがるチケットをロードマップに表示させられるようにはならないでしょうか。	こちらの機能につきましては来月のAdvanced Roadmapsご紹介ウェビナーにて触れさせていただきます！来月開催のウェビナーぜひご参加下さい。
最近使い始めたので使い方が間違っているのかもしれませんが、ガントチャートに使っている日付とロードマップの日付が違いますが、合わせることはできますか？	こちらのご質問はお手数ですが弊社サポートにお問い合わせ頂いてもよろしいでしょうか？
GantチャートはProject向け、RoadmapはProduct向けという切り分けはありますでしょうか。	終了の期日がきまっていて変更がないプロジェクトマネジメントに適しているのがGanttチャート、市場のニーズに合わせて継続的な開発と改善を続ける前提のプロダクトを管理するプロジェクトにはロードマップが向いております。
ガントチャートの日付は開始実績と終了実績日だと思いますが、開始予定と開始実績、終了予定と周力実績を並べて表示することはできますか？	Jira Softwareのロードマップ機能では課題の「開始日」および「期日」フィールドの値をもとに表示されるものとなっており、カスタムフィールドとして「開始予定」や「終了予定」を課題上に表示させることはできますが、ロードマップ上では表示できません。本機能はサードパーティ製のガントチャートアプリにて表示できる可能性がありますので、ツール提供のベンダー様にお問い合わせください。
ガントチャートを更新するのに時間が掛かりますが、ロードマップのように、すぐに開くようになりませんか？	こちらはどちらのアプリの話かによりますため、ツール提供されているベンダー様にお問い合わせ頂ければ幸いです。
タスクがどうしても終わらずスプリントを超えて伸びてしまうことがあり、その場合にスプリントを切り替えてしまうと全体の作業量がわからなくなってしまいます。何か対処法はありますか？	タスクがスプリント内で終了しない場合は、タスクが適切なサイズでない可能性があります。より小さく分割することをご検討ください。タスクやストーリーの作業サイズなどについて詳しくは エピック、ストーリー、テーマ、そしてイニシアティブ | Atlassian をご参照ください。 また、サブタスクに分割することもよろしければご検討ください。詳しくは課題やサブタスクを作成する | Jira Software Cloud | アトラシアン サポート をご参照ください。