2025年11月29日、パシフィコ横浜にて開催された「Backlog World 2025」。今年も多くの参加者が集まり、現場のリアルな課題と向き合うセッションが続く中、会場には熱気と学びに満ちた時間が流れました。
本記事では、北海道ガスの峠幸寛氏によるセッションをレポート。プロジェクトの背景共有や進捗の把握、会議運営の改善など、チームが抱えがちな非効率をどう解消してきたのか。中間管理職がBacklogを活用する際のハードルを下げた、峠さん渾身の取り組みについてご紹介します。
目次
登壇者紹介
峠 幸寛 氏
北海道ガス株式会社
新潟で育ち、大学進学を機に北海道へ。澄んだ空気で長年の鼻炎が治り、永住を決意。都市ガス会社に入社し、電力自由化では夢だった“ガス会社での発電所建設”を担当。次の挑戦を求め、2018年にIoT・クラウドを学ぶ社内有志コミュニティを立ち上げる。活動範囲を社外コミュニティへ広げ、JBUGやBacklog World2023で事例登壇。2024年以降のBacklogWorldの運営に携わる。基幹システム刷新プロジェクトに従事し、社内のBacklog浸透にも力を注ぐ。
報告だけで時間が溶ける…「もったいない」定例会議をなんとかしたい
日々の業務では複数の部署や外部パートナーとの連携も多く、自然とプロジェクトマネジメントに関わる機会が増えていった峠さん。
これまで公私合わせて数多くのBacklog導入支援を実施。「Backlogは、触れば触るほど良さが分かっていき、チームがより働きやすくなる運用を整えたくなるんです」と語ります。
Backlog はIT開発のプロジェクトで使われることが多いツールですが、あらゆる会社や部署でも使えるという視点こそ、今回お伝えしたいテーマです。
北海道ガス株式会社
峠 幸寛 氏
その中でも特にフォーカスしたのは、Backlogを“管理者（中間管理職／マネージャー）に使ってもらうための取り組み”です。峠さんの実体験をもとに語っていただきました。
その当時を振り返ると、以下のような状況でした。
- 3つのチームを束ねる管理者がいて、そのさらに上には部長や経営層がおり、管理者が全体の進捗や判断を取りまとめていた
- チーム横断の全体定例会議を週1回実施していた
- 管理者はBacklogの利用に不慣れで、十分に活用できているのは3つのうち1つのチームだけだった
この「板挟みの管理者」をBacklogの力で救いたい ―― その使命感から、現場で起きている課題を分析していきました。
「まず注目したのは、週1回の定例会議が情報共有だけで終わってしまう問題です。3つのチームが順番に報告する流れでしたが、報告だけでかなりの時間を消費していました。その結果、本来議論すべき論点に対して十分な時間を取ることができず、会議終了時間がきてしまいます。さらに、管理者とBチームの議論に対して、AチームやCチームで深い情報を持っていないメンバーは話題に入れず、ただ状況を聞くだけの状態になってしまうことも。」
また、管理者が「あの件どうなった？」と聞かないと進捗が分からず、もったいなさを実感。特定のタスクや依頼の進捗が見えず、結局は都度確認しなければなりません。今後、関係者が増えれば増えるほど、確認の数も手間も膨れ上がり、どんどん時間が溶けてしまう状態に陥ってしまいます。
知りたい情報を“届ける”仕組み。管理者視点の理解とシンプルなルール
こうした非効率をBacklogで解消するため、次の3つの要素を整理しました。
①管理者の視点を理解すること
②シンプルなルールをつくること
③Backlogへのアクセス動線を整えること
「最初のポイントは『管理者の視点を理解すること』です。そもそも管理者が求める情報と担当者が欲しい情報はまったく異なります。双方の知りたい情報には大きなギャップがあるんです」
＜管理者が知りたいこと＝俯瞰の情報＞
- 全体として計画どおりに進んでいるのか
- 突発的に依頼したタスクがどうなったのか
- 問題が発生していないか
- 自分の権限を行使する判断が必要なのか
＜メンバーが知りたいこと＝安心して作業するための情報＞
- 具体的に何をすべきか
- 誰が担当なのか
- 期限はいつなのか
- どんな制約があるのか
だからこそ、「管理者の視点をBacklogにどう組み込むか」が重要です。まずは管理者の担当領域を整理するため、プロジェクトや案件、経営会議向けの提出物など、管理者が担う業務の全体像の棚卸しに着手しました。
「複数のプロジェクトがあるなら、それぞれについて『何をどのタイミングで行うのか』を計画に落とし込みます。計画自体が存在しない場合は、管理者と一緒に作るところから始めます。こうして明らかになったスコープや計画を、今度は各チームに分担していきました。これは『管理者が知りたい情報』であると同時に、『担当者が迷わないための情報』にもなります」
この構造をBacklogで運用するために必要なのが、「シンプルなルール作り」です。
「まず、管理者専用の“種別”をつくりました。管理者が確認したい内容だけを起票できるように、複雑なルールは一切排除。管理者とすり合わせた計画のタスク、そして突発依頼のタスクを、この種別にまとめていきます」
これにより、管理者が見るべき情報はすべてここにあるという状態が完成しました。
カテゴリ設計も重要です。主カテゴリにAチーム・Bチーム・Cチームなどのチーム単位、副カテゴリには「チームマネジメント」「外注」「経営会議」「資料」などを設定します。これらの「主」「副」はBacklogの標準機能ではなく、峠さん自身が運用の中で編み出したとのことですが、管理者の視点を整理するうえで極めて有効だったといいます。
こうした設計により、管理者が求める「チーム」「スコープ」「計画」が一覧で把握できる構造が完成します。たとえば、研修プロジェクトを管理する場合、親課題に計画をまとめ、その下に月別の展開を子課題として紐づけることで、管理者が見たい情報が整理されていきます。
重要なのは“課題の切り方”。粒度を揃えて徹底的に管理
続いて峠さんは「親課題の切り方」こそが、最も重要だと強調します。
- なぜこのプロジェクトが始まったのか？
- どこに向かって進んでいくのか？
- 期末までの達成目標や具体的な数値は？
- 社内承認を得るために使用した資料（経営会議資料、中期経営計画資料など）は何か？
- 経営会議で使用した元データ
- 成果物を格納するフォルダはどこか？
- 意思決定に必要なステークホルダーは誰か？
「これらを踏まえて、プロジェクトの背景と根拠を親課題に揃えている状態にすると、親課題を読むだけで、プロジェクトに関わる人がすべての背景を理解できるようになります。ここが整っていないと、本質的な情報がチームに共有されず、進捗管理も形骸化してしまいます」
一方で、月別に展開される子課題では、作業内容をチェックボックス単位で具体的に入力し、作成資料の保存先（フォルダパスやURL）も必ず記載。こうすることで、Backlogを開けば「何をすべきか」「資料はどこにあるか」が即座に分かる状態になるのです。
親子課題でこれらを徹底すると、すべての進捗に対してアクセス可能な環境が整います。こうして整理されたタスク群をガントチャートで表示すると、管理者視点で状況を俯瞰できるといいます。これにより、「中間報告は終わっているはずなのに、課題が処理済みのまま動いていないのは、別部門が未承認だからだ」といったことが、ひと目で理解できるようになります。
「親課題に全タスクを紐づけると、新たな計画やチーム進捗も、同じ枠組みで管理できます。背景と進捗の双方が共有されることで、チーム間のフォローも自然と生まれていくんです」
こうした“シンプルだが丁寧な”運用が、相互作用を生み、組織全体に波及していくと話します。
「正直、使いたくない」を突破。管理者を動かす「ワンクリックBacklog」の仕掛け
Backlogへのアクセス導線を整えることも忘れてはいけません。峠さんの口調にも自然と熱がこもります。これこそ、セッションタイトルにある「管理者に向けたワンクリックBacklog」に直結する、最重要パートだからです。
「どれだけきれいにBacklogを整えても、管理者が開いてくれなければ価値は出ません。管理者はBacklogに不慣れなケースが多く、『正直開きたくない』『どこに何があるのか探したくない』『仕事が増えるだけでは？』と抵抗感があるのは致し方ないのです。そこで重要になるのが、『ワンクリックBacklog』の仕組みづくりです」
まず取り組んだのが、管理者向けドキュメントの整備でした。Backlogのドキュメント機能を活用し、「ワンクリックするだけで各チームの進捗や計画に一瞬でアクセスできるページ」を用意したのです。
作り方は簡単です。必要な情報に絞ったURLを、管理者専用のドキュメントページに貼りつけるだけ。
Backlogの課題一覧やガントチャートの検索結果ページでは、検索条件の情報がURLに保持されます。つまり、課題の種別はもちろん、カテゴリー、開始日など、管理者が見たい条件の結果ページをクリックすれば、即座に必要な情報にたどり着けるのです。
「手間がかからず、欲しい情報に迷わずたどり着ける。この利便性が功を奏し、管理者は自然とBacklogを使うようになっていきます」
もうひと手間としておすすめなのが、“管理者が普段使い慣れているツール”の導線にBacklogを組み込むことです。たとえば会議予定のカレンダーに、ワンクリックBacklogのURLを貼り付けておきます。こうしておけば、管理者は普段通り会議情報を見る中でBacklogへ遷移しますし、Backlogを開く機会が自然と生まれるんです。
「この“定期的に触れる”体験が非常に強力で、約2か月が経つ頃には、管理者自らBacklogを開き、タスクの起票やコメントを書き始めるようになります」
峠さんの実体験からくる効果には、大きな説得力を感じますね。
さらに、峠さんがBacklog導入支援を行う際の「絶対に譲れないルール」にも言及しました。それは、「導入支援はハンズオンを含めて90分（30分×3回）で完結させる」ということです。
もし90分で伝えきれないような複雑なルールを作ってしまえば、現場は途端に「難しい」と感じ、運用は決して定着しません。だからこそ、仕組みはとにかくシンプルであるべきだと峠さんは強調します。
導入初期の会議は、峠さんがファシリテーターとして進行し、「このボタンを押すと情報が見られます」と何度も実演していきます。すると、上司が自分からBacklogを確認するようになり、1か月も経つ頃には、メンバー全員が自然とコメントを書き、運用が自走し始める状態へと変わっていったそうです。
チームワークマネジメントが、事例や現状分析の羅針盤になる
最後に峠さんは、今回紹介した取り組みと、ヌーラボが提唱する「チームワークマネジメント」の要素を照らし合わせながら、締めくくりに向けて話を進めていきます。
峠さんがBacklogの運用を通じた問題解決に向けて重視したポイントは、次の3つだと説明します。
①「相手の目線を知る」＝管理者がどんな情報を求めていて、どこに不安を感じているのかを理解した
②「相手に合わせてルールをシンプルにする」＝複雑になりがちな進捗管理を、管理者が迷わず理解できる構造にまとめた
③「作った仕組みを相手に見せ続ける」＝Backlogで設計した構造を、継続的に管理者が触れる環境を整えた
これらのポイントを、ヌーラボが提唱するチームワークマネジメントに照らし合わせると、重なる部分があるのです。
「コミュニケーション設計」では、管理者が欲しい情報にすぐアクセスできる状態をBacklogに落とし込んだことが大きなポイントになりました。また、「目的の共有」のために親課題で情報を整備しています。
背景と進捗の両方が見えるようになることで、メンバー同士が状況を理解し、問題に対して提案できる状態が生まれ、「心理的安全性を高める」ことにもつながります。このようなコミュニケーション設計に至る仕組みを私自身が「リーダーシップを発揮」して第一歩を踏み出し、チームの協力を得ながら全体を整えていきました。
一方で「役割の明確化」に関しては、明確にしたにもかかわらずうまくいかないケースもあります。多くの場合、役割そのものではなく、役割に付随する権限が実行されていないことも原因の１つとなるため、考えるきっかけにしてみてください。
峠さんは、チームワークマネジメントの5つの要素を「羅針盤」のように使っていると言います。
「さまざまな事例を見るとき、“あ、ここでこの要素を使っているな”と気づけるようになります。自分の取り組みがうまくいかずモヤモヤするときも、どの要素が欠けているのかを確認すれば、自然と検討すべき課題が見えてきます」
Backlogを“使わせる”のではなく、“使いたくなる”仕組みへ
セッションの終わりには、あらためて「組織マネジメントへのBacklogの適用」のポイントをまとめました。
「管理者が欲しい情報をBacklogに反映する。そのために、管理者専用の種別をつくり、さらに管理者専用のドキュメントページを用意して、欲しい情報にすぐアクセスできる状態を整える。こうすることで、管理者だけでなくチーム全体が計画と進捗をBacklog上で俯瞰できるようになります。情報の透明性が高まれば、会議は報告の場から議論の場へと質が変わり、生産性の高いチームへの移行が現実的なものになっていきます」
しかし、ここまで徹底した準備が本当に必要なのか、疑問に思う方もいるかもしれません。峠さんはそんな心の声を代弁するかのように、笑いを交えてこう続けます。
「ワンクリックBacklogに象徴されるように、『そこまでしないと使ってくれないの？』と思うかもしれませんが、使ってくれないんですよね（笑）。ただ、丁寧に情報を整理していくと、これまで共有されず埋もれていた『なぜこうなっているのか』というモヤモヤが、ようやく言葉として表に出てきます。中間管理職の上司と一緒にBacklogを整え、情報の透明性を高めながら、本当に向き合うべき課題に近づいていく、そのプロセスこそが、想像以上に大きな価値を生むのだと考えています」
峠さんの取り組みの核心は、Backlogを「使わせる」のではなく、「迷わず使える環境をつくり込む」ことにありました。管理者の視点を丁寧に捉え、情報をシンプルに整理し、ワンクリックでたどり着ける導線を整える。こうした小さな工夫を積み重ねることで、管理者が自然とBacklogを開き、自走できる土台が形づくられていったのです。
「Backlogを導入したものの、肝心の上司がなかなか使ってくれない……」 そんなもどかしい壁に直面している方にとって、峠さんの事例は現状を打開する糸口になったのではないでしょうか。
関連ブログ
ドキュメント機能の正式リリースとWikiからの移行機能提供のお知らせ | Backlogブログ
ベータ版としてアップデートを重ねてきたドキュメント機能を、2025年12月1日に正式にリリースいたしました。これに伴い、Wikiのデータをワ…
backlog.comこちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com