gantt
開発の現場でガントチャートの話を出すと、反応が2つに分かれます。工程を管理する立場からは「無いと先が読めない」という声が出て、作る側からは「先の予定を引いても必ず変わるので意味がない」という声が出ます。どちらも正しく、だから議論が終わりません。
先に結論を書きます。開発でガントチャートが噛み合わないのは、図そのものが悪いからではなく、棒にしている作業の粒度が細かすぎるからです。個々の実装を1本の棒にすると、仕様が変わるたびに全部を引き直すことになります。棒にするのは、外部との約束と、他のチームが待っている引き渡しの2つだけにしてください。この形にすると、作り直しが起きても図はほとんど変わりません。
この記事では、開発でガントチャートが嫌われる理由、それでも必要になる場面、作り直しを前提にした粒度の決め方、棒にすべき作業とすべきでない作業、遅れが出たときの直し方、そして道具を選ぶときの軸までを扱います。
反発の理由を具体的に分けます。ここを曖昧にしたまま「導入します」と宣言すると、形だけ作って誰も更新しない資料が増えます。
1つ目は、引いた瞬間に古くなることです。設計を始める前に実装の期間を日単位で決めても、設計の結論によって実装の内容が変わります。変わるたびに図を直すなら、直す作業のために時間を使うことになります。作る側から見ると、この作業は価値を生みません。
2つ目は、進捗の割合が実態と合わないことです。実装を80%終えたという数字は、残りの20%に何が含まれているかで意味が変わります。残っているのが画面の細かい調整なら本当に80%ですが、いちばん難しい部分が残っているなら実質は30%です。この差が図には表れません。
3つ目は、遅れの責任を問う道具として使われた経験です。図の上で棒が今日の線を越えていると、その作業の担当者が説明を求められます。何度か経験すると、人は棒が越えないように見積もりを膨らませます。膨らんだ見積もりを合計した計画は、実際より長い期間を示します。
4つ目を加えるなら、図を作る人と作業をする人が違うことです。とりまとめている人が1人で図を引き、開発の側は見るだけという形になると、図は外から与えられた指示書になります。指示書として扱われた図は、現場の実態を反映しません。作る段階で担当者に棒の区切りを相談すると、この関係が変わります。
この4つは、どれも図の作り方と運用に原因があります。図を捨てる前に、作り方を変える余地があります。
開発の進め方を作り直し前提にしても、工程表が要る場面は残ります。
1つ目は、外部との約束がある場合です。取引先に納品する日、キャンペーンの開始日、法令の対応の期限。これらは自社の都合で動かせません。動かせない日付がある以上、そこから逆算した計画は必要になります。カンバンだけでは、間に合うかどうかが分かりません。
2つ目は、他のチームが待っている場合です。自分たちの成果物を使って別のチームが作業を始める場合、いつ渡せるかを伝える必要があります。相手はその日付で自分たちの計画を立てます。ここで「まだ分かりません」と答え続けると、相手の計画が立ちません。
この2つは、開発の内部の都合とは別の要求です。だから、内部の進め方をカンバンにしたまま、外向けの工程表を持つという形が成り立ちます。
ソフトウェア開発におけるプロジェクト管理を円滑に行うには「ガントチャート」の活用が役立ちます。実際に自社の開発プロジェクトにおいて複雑で多岐にわたるプロセス管理に課題を感じており、ガントチャートの活用を検討している人もいるのではないでしょうか。 この記事では、ガントチャートの役割や活用のメリット、具体的な作成方法などを解説します。ガントチャートの作成やプロジェクト管理におすすめのツールも紹介しているのでぜひ参考にして下さい。 出典: about.gitlab.com
開発の道具を提供している側も、工程の見える化には工程表が向くという立場を取っています。対立させる話ではなく、どこに使うかという話になります。
ここが本題です。棒の粒度を1段上げると、図は作り直しに耐えるようになります。
細かすぎる例を挙げます。「ログイン画面の実装」「パスワード再設定の実装」「セッション管理の実装」を3本の棒にすると、仕様の変更で1つが消えたり2つに分かれたりします。そのたびに図を直すので、更新が追いつきません。
粒度を上げた形はこうです。「認証の機能を使える状態にする」を1本の棒にします。中に何の作業が含まれるかは、カンバンの側で管理します。仕様が変わって作業の数が変わっても、棒の始まりと終わりは変わりません。
棒の長さの目安は、2週間から1か月です。1週間より短い棒は細かすぎて、作り直しに巻き込まれます。2か月より長い棒は、途中の進み具合が分かりません。この範囲に収めると、図を直す頻度が月に1回程度まで落ちます。
棒の数の目安は、3か月の計画で10本から15本です。それより多い図は、開いた人が読めません。多くなっている場合は、粒度を1段上げられる余地があります。
進捗の表し方も変えてください。割合ではなく、終わったかどうかの2択にします。棒の中に含まれる作業のうち何件が終わったかで、自動的に割合が出るなら、それを使います。人が感覚で入力する割合は、数字としての意味を持ちません。
粒度の話を具体にします。新しい申込の仕組みを3か月で作る例で考えます。
棒にするのは、外部との約束と引き渡しです。この例では「公開の日」が動かせない日付で、社内の別チームへの引き渡しが2回あります。運用を担当する部署に管理の画面を渡す日、広報に画面の素材を渡す日です。
そこから逆算して並べると、棒は次のようになります。認証の機能を使える状態にする、申込の画面を使える状態にする、決済の連携を使える状態にする、管理の画面を渡す、検証の環境で通しの確認を終える、公開の準備を終える。6本です。
それぞれの棒の中には、10件から30件の作業が入ります。その作業は板の側にカードとして並びます。図の上には出てきません。仕様が変わって作業が5件増えても、棒の数は6本のままです。
余裕の持たせ方も決めます。各棒に余裕を含めると、担当する側はその余裕を使い切ります。棒の見積もりは素直な数字にして、公開の日の前に2週間の余裕を1本の棒として並べるほうが、期限が守られやすくなります。この余裕の棒は、遅れが出たときに削る対象として全員に見えている必要があります。
この形で作った図は、3か月の間に2回から3回しか直すことになりません。直すのは、棒の終わりの日が動いたときだけです。毎週直している図は、粒度が細かすぎるという合図です。
判断の基準を明文化します。
棒にするのは、外部に渡すものと、他のチームが待っているものです。納品、公開、社内の別チームへの引き渡し、検証環境の提供。これらは日付が意味を持ちます。
棒にしないのは、内部の作業です。個々の実装、調査、修正、リファクタリング。これらは日付ではなく順番で管理します。カンバンの列を移すだけで済むものを、図に載せる必要はありません。
判断に迷う場合は、その作業の日付が動いたときに誰かに連絡が必要かを考えてください。連絡が必要なら棒にします。必要ないなら棒にしません。この基準だけで、ほとんどの作業を振り分けられます。
例外として、長い期間を占める調査は棒にする価値があります。「新しい方式で作れるかを調べる」という作業が2週間かかるなら、その2週間は他の作業に影響します。ただし、この場合も期間を見積もるのではなく、期限を決めて打ち切る形にしてください。「2週間調べて結論が出なければ既存の方式で進める」と決めておけば、調査が工程全体を止めることを防げます。
依存関係の線も、棒にしたものの間だけで引きます。内部の作業まで線で繋ぐと、1つの遅れで図の全体が右にずれて、実態より悪く見えます。
仕様が変わったときの手順を決めておきます。決めていないと、変わるたびに図を作り直す作業が発生します。
まず、棒の数が変わるかを確認します。変わらないなら、図は直さなくて済みます。認証の機能の中身が変わっても、認証の機能を渡す日が変わらないなら、図は正しいままです。
次に、終わりの日が動くかを確認します。動く場合、後ろに繋がっている棒と、外部との約束に影響が出るかを見ます。影響が無ければ、その棒だけを伸ばします。影響がある場合は、並行させられる作業があるか、範囲を削れるかを検討します。
範囲を削る判断は、図の上でやると話が早く進みます。棒を2本に分けて、前半だけを約束の日までに渡す形にする。この操作は、口頭の議論では合意しにくく、図の上では合意しやすくなります。見えているものが同じだからです。
そして、動かした記録を残してください。誰がいつ何を動かしたかの履歴が残る道具であれば、後から経緯を説明できます。履歴が残らないファイルで管理していると、「いつ変わったのか」という不毛な話になります。
図の上で遅れに気づくのは、棒が今日の線を越えてからです。それでは遅すぎる場合に、先に気づくための数字が2つあります。
1つ目は、板の中で止まっているカードの数です。レビュー待ちや確認待ちの列にカードが溜まり始めたら、その先の作業が進みません。図の上では棒がまだ今日の線を越えていなくても、数日後に越えることが分かります。列ごとのカードの数を週に1回数えるだけで、この予兆が見えます。
2つ目は、終わった作業の件数の推移です。先週5件終わり、今週2件しか終わっていないなら、何かが起きています。割り込みの対応が増えた、難しい部分に入った、人が休んでいる。原因はその場で聞けば分かります。件数の推移は、進捗の割合よりも正直な数字です。
この2つを見る習慣があると、図を直す回数が減ります。遅れが確定してから図を直すのではなく、確定する前に手を打てるからです。手を打った結果として棒が動かなければ、図はそのままで済みます。
数字を毎週手で数える必要はありません。列ごとの件数が画面に出る道具であれば、開いて見るだけです。出ない道具でも、板を開いて目で数えれば1分で終わります。
反復して作る進め方と工程表は、対立するものとして語られがちです。実際には併用されています。
たとえば、ガントチャートを活用することで、アジャイル開発の円滑化が可能です。柔軟で継続的なソフトウエア開発において、誰がいつ何を担当するのかを可視化でき、プロジェクト全体を見通しながら計画と実績を比較することは重要です。 出典: crowdlog.jp
併用の形は決まっています。反復の単位を棒にするのです。2週間の反復を1本の棒にして、その中で何を作るかは板の側で管理します。図の上では、反復が何回あって、どの反復の終わりに何を渡すかだけが見えます。
この形にすると、反復の中身が変わっても図が壊れません。6回目の反復で認証を渡す、という約束が守られていれば、その中の作業が入れ替わっても外部への説明は変わりません。
燃え尽きの図と併用する場合は、役割を分けてください。燃え尽きの図は反復の中の進み具合を見るためのもので、期間が数週間です。工程表は数か月の見通しを見るためのものです。同じ情報を2つの図で見ようとすると、どちらも更新されなくなります。
棒の長さを決めるには見積もりが要ります。開発の見積もりは外れるものだという前提で、扱い方を決めておきます。
出し方は、担当する本人に聞く方法が基本です。ただし、そのまま使うと短すぎる数字になります。人は自分の作業時間を短く見積もり、レビューの待ち時間や、割り込みで入る問い合わせの対応を計算に入れません。聞いた数字に1.5倍程度の余裕を見ておくと実績に近づきます。
似た作業の実績が残っているなら、そちらを優先してください。前に同じような機能を作ったときに3週間かかったのであれば、今回も3週間から始めます。実績を残すには記録が必要で、記録が無い組織では使えません。だから、いま記録を始めることが次回の精度を決めます。
見積もれない作業の扱いも決めます。やったことのない方式を試す作業や、外部の回答を待つ作業です。期間を見積もるのではなく、期限を決めて打ち切る形にします。2週間調べて結論が出なければ別の方式に切り替える、と最初に決めておけば、見積もれない作業が全体を止めることを防げます。
そして、見積もりを約束として扱わないことを明示してください。見積もりが約束として扱われると、人は外れないように大きい数字を出します。大きい数字を合計した計画は、実際より長い期間を示します。約束として扱うのは、外部に伝える日付だけにします。
同じカードを板としても工程表としても見られる形にすると、運用が変わります。
まず、二重の入力が消えます。板でカードを右に移せば、図の側の進捗も変わります。開発の側は板だけを触り、工程の管理をする側は図だけを見る。同じデータを別の角度から見ているので、ずれません。
次に、図の更新が自動になります。棒の終わりの日を人が入力するのではなく、カードに入っている期限から棒が引かれます。期限が変わると棒が動きます。更新の作業そのものが消えます。
そして、図から板へ降りられます。図の上で遅れている棒を見つけたら、その棒に含まれるカードの一覧を開いて、どのカードで止まっているかを確かめられます。図と板が別の道具だと、この移動ができません。会議で「どこで止まっているのか」を聞いて回ることになります。
一方で、注意点もあります。板のカードに期限が入っていないと、図に棒が出ません。期限を入れる習慣が無いチームでは、まず期限を入れる運用から始める必要があります。全部のカードに期限を入れるのではなく、棒にしたい単位のカードにだけ入れる形で足ります。
道具の選び方に移ります。開発のチームで見るべき軸は5つです。
1つ目は、ソースコードのリポジトリを同じ画面で扱えるかです。課題番号とコミットが結びつくと、変更の理由を後から追えます。この機能を持つ道具は限られていて、持たない道具ではGitHubなどと連携で繋ぐ形になります。国産のボード型の道具の多くはリポジトリ機能を持たないため、そこは割り切って外部のサービスと組み合わせることになります。
2つ目は、課題に持たせられる項目の自由度です。見積もりの点数、優先度、対象の版。開発では独自の項目が必要になります。カスタムフィールドが有料プランの機能になっている道具もあるので、無料で試した形がそのまま続けられるかを確かめてください。項目の扱いはできることのページで一覧になっています。
3つ目は、反復の管理ができるかです。2週間の単位で課題をまとめて、その単位の進み具合を見る仕組みが要ります。無い場合は、ラベルやカスタムフィールドで代用することになります。
4つ目は、工程表がどのプランに含まれるかです。無料で使える範囲が機能で切られていると、工程表を使う段階で有料になります。人数やボードの数で切られているなら、試した形のまま人が増えるだけです。区切り方は料金のページで確かめられます。
5つ目は、社外の協力者に見せる範囲を決められるかです。外部の開発者が入る体制では、見せる範囲を絞る設定と操作の記録が要ります。考え方は安全性の考え方のページにまとめられています。
よく候補に挙がる道具を、公開されている条件で並べます。金額は2026年9月27日時点のものです。
国産のBacklogは、GitとSubversionが全プランで使えます。スタータープラン（月額2,700円、税抜、スペース単位）でも課題管理とリポジトリが同じスペースに入ります。一方でガントチャートはスタンダードプラン以上で、月額16,000円から、表示範囲は6か月分です。燃え尽きの図もスタンダード以上、孫課題と属性のカスタマイズはプレミアム（月額27,000円）以上です。開発でリポジトリを使うなら有力な候補になります。対応の整理はBacklogとの比較にあります。
Asanaは2人までのPersonalプランが無料で、タイムラインとガントビューは有料のStarterプラン以上です。Starterは1人あたり月額1,200円、Advancedは2,700円（いずれも年払い）です。人数単位なので、開発のチームが小さいうちは安く、大きくなると総額が伸びます。整理はAsanaとの比較を見てください。
Trelloは無料プランがワークスペースあたり10人・ボード10個までで、期間を横棒で見る機能は拡張機能として扱われます。有料のStandardは年払いで1人あたり月額5ドル、月払いで6ドルです。板の操作は軽い一方、課題の属性を細かく持たせる使い方には向きません。違いはTrelloとの比較にまとめました。
Notionはフリープランがあり、プラスが1人あたり月額1,650円、ビジネスが3,150円です。仕様書と課題管理を同じ場所で扱えるので、文書が多い開発に向きます。ただし構造を自分で設計することになるため、作った人しか全体を理解していない状態になりがちです。違いはNotionとの比較を見てください。
料金の比べ方は、人数単位かスペース単位かをそろえて、1年間の総額で出すことです。5人のときと20人のときで順位が入れ替わります。
工程表を入れる提案は、開発のチームから歓迎されないことがあります。説明の組み方を書きます。
まず、棒にするものを先に示してください。「個々の実装は図に載せません」と最初に言えば、反発の大半が消えます。反発の原因は図そのものではなく、細かい作業を日付で縛られることへの警戒です。
次に、更新の担当を明確にしてください。図の更新はとりまとめる人が行い、開発の側に追加の入力を求めないと決めれば、負担の話が消えます。板の情報から自動で図が作られる道具であれば、そもそも二重の入力が発生しません。
そして、図を使う目的を1つに絞ってください。外部への説明のためであると宣言すると、内部の評価に使われる心配が無くなります。遅れの責任を問う道具として使わないことを、最初に約束してください。この約束が守られれば、見積もりが膨らむことも防げます。
工程の管理を求める側の要望は、たいてい具体的です。実際に相談された内容として、次のような例が公開されています。
・製品開発の上流から下流までのスケジュールとタスク管理を一元化したい・現状はExcelでガントチャートを作成しているが情報が少なく、各部門の実務担当者が自分たちで日割りのガントチャートやタスクに落とし込む作業が発生している・タスクの洗い出しが担当者の経験によって差が出てしまう・特定の人に業務が偏っている状況を可視化したい・また、タスク間の従属関係（このタスクが終わらないと次のタスクに進めない等）を視覚的に把握したい・まずは課内でスモールスタートで導入し、よければ他部署展開をして利用者を広げていきたい 出典: wish-sc.co.jp
並んでいる要望のうち、工程表が解決するのは従属関係の把握と偏りの可視化です。一元化と洗い出しの差は、図ではなく作業の分け方の設計で解決します。要望をそのまま道具の要件にすると、選定が終わらなくなります。
道具を変えずに表計算ソフトで続ける判断も、条件が合えば成り立ちます。
続けられる条件は3つです。工程表を見るのがとりまとめている人と、その上の立場の人だけである場合。棒の数が10本以下で、直す頻度が月に1回である場合。そして、板の側の情報を図に反映する必要がない場合です。この3つが揃っていれば、ファイルで持っていても困りません。
逆に、開発の担当者が自分の進捗を図に書き込む運用にすると、そこから崩れます。1つのファイルを複数人で扱えないため、書き込みのために順番待ちが発生します。順番待ちが発生すると、代わりにチャットで報告する形になり、とりまとめている人が転記することになります。この転記の作業が、工程の管理で最も時間を使う部分です。
もう1つの崩れ方は、版が増えることです。同じ名前のファイルに日付を付けた版が3つ並び、どれが最新か分からなくなります。会議の席で「それは先週の版です」というやり取りが起きたら、道具を変える段階に入っています。
図をPDFや画像で書き出して配る運用も、同じ問題を持ちます。配った時点で古くなるので、配る先は社外に限り、社内はURLで共有する線を引いてください。
最後に、運用の設計を3点挙げます。
1つ目は、更新の頻度を決めることです。図は月に1回、反復の切り替えのタイミングで見直します。毎週直すと、直すこと自体が仕事になります。月に1回で足りる粒度になっているかどうかが、設計が正しいかの検査になります。
2つ目は、図を見る場を決めることです。月に1回の見直しの場で画面を開き、外部との約束に影響が出ていないかだけを確認します。この場で個々の実装の話を始めると、時間が足りなくなります。
そして、3か月に一度は棒の区切り方を見直してください。プロジェクトが進むと、外部との約束や引き渡しの相手が変わります。最初に決めた6本が、途中からは実態と合わなくなることがあります。区切りを直すのは図を直すより大きい作業ですが、3か月に一度なら負担になりません。
3つ目は、板と図を同じデータで持つことです。別々に管理すると、片方が必ず古くなります。同じカードを板としても工程表としても見られるなら、更新が1か所で済みます。導入の前に人数の数え方や上限の扱いを確かめたいときは、よくある質問に条件が書かれています。
工程表を1人が引き直している間、他の人はその表を見られません。開発で工程表が嫌われる理由の半分は、この引き直しの作業を誰かが背負っていることにあります。棒の粒度を上げて、板と同じデータで持つ。この2つを変えるだけで、図は作り直しに耐えるようになります。
棒の粒度を上げれば引き直しは起きません。個々の実装を棒にすると仕様の変更で崩れますが、外部に渡すものと他のチームが待っているものだけを棒にすれば、中身が変わっても始まりと終わりは変わりません。棒の長さは2週間から1か月が目安です。
両立します。反復の単位を1本の棒にして、その中で何を作るかは板の側で管理する形が使われています。図の上では反復の回数と、どの反復の終わりに何を渡すかだけが見えます。燃え尽きの図は反復の中を見るもので、工程表は数か月の見通しを見るものとして役割を分けてください。
Backlogは全プランでGitとSubversionが使え、課題番号とコミットが結びつきます。国産のボード型の道具の多くはリポジトリ機能を持たないため、その場合はGitHubなどと連携で繋ぐ形になり、画面が2つに分かれます。リポジトリを日常的に使っているなら、選定の最初の条件になります。
人が感覚で入力する割合は数字としての意味を持たないため、終わったかどうかの2択にしてください。棒に含まれる作業のうち何件が終わったかで自動的に割合が出る道具であれば、それを使います。残りの20%に最も難しい部分が含まれている場合、割合の入力は実態を隠します。