進捗管理の方法は2つしかない｜聞かなくても分かる状態にする

進捗管理の方法を調べている時点で、たいていの場合はもう「聞けば分かる」状態に疲れています。朝会で一人ずつ聞く、チャットで名指しして確認する、週末に報告フォーマットを配って集める。どれもやれば状況は分かりますが、分かるたびに誰かの時間が減っていきます。しかも、聞かなかった週の状況は残りません。

この記事では、5人から数十人のチームで進行のとりまとめをしている人に向けて、進捗管理の方法を「聞かなくても分かる状態にする」という一点から組み替える考え方を整理します。報告させる形がなぜ2週間ほどで形骸化するのか、状態が仕事の副産物として自然に残る形はどう作るのか、そして見る側が何を我慢しなければその形が定着しないのかを扱います。道具を増やす話ではなく、いまの道具のどこで詰まっているかを見極めるための記事です。

進捗管理の方法を探している人が本当に困っていること

「進捗管理 方法」で検索する人の状況は、おおよそ2種類に分かれます。ひとつは、まだ何も仕組みがなく、これから作ろうとしている人。もうひとつは、すでに何かしらの仕組みがあるのに機能しておらず、次の手を探している人です。数として多いのは後者です。

すでに仕組みがある側の困りごとは、細かく聞いていくと共通しています。工程表はあるが更新されていない。タスク一覧はあるが、そこに載っていない仕事が動いている。チャットで報告は上がってくるが、流れて消えるので後から追えない。つまり、情報が存在しないのではなく、情報が「聞いたその瞬間だけ存在する」構造になっています。

この構造の厄介なところは、進行をとりまとめている人ほど疲弊が見えにくい点にあります。聞けば分かるので、外から見ると管理は機能しています。遅れも拾えているし、問題も表に出ている。ただ、それはとりまとめ役が毎日聞いて回っているからで、その人が休んだ週にチームの状況を説明できる人が誰もいない、という状態がしばしば生まれます。属人化しているのは作業ではなく、状況把握のほうです。

もうひとつ見落とされやすいのが、聞かれる側の消耗です。作業に集中している人にとって、状況の確認は割り込みです。手を止めて、いまやっていることを言葉に直して、相手が分かる粒度に翻訳して返す。この一連の作業は数分で終わりますが、集中が戻るまでには数分では済みません。1日に何度も割り込みが入るチームでは、報告の総量よりも、割り込みで失われた時間のほうが大きくなります。

だから進捗管理の方法を考えるときの出発点は、「どうやってきちんと報告させるか」ではありません。「報告してもらわなくても状況が残るようにするには、仕事の進め方をどう変えればよいか」です。この向きの違いが、その後に選ぶ道具も、決めるルールも、全部変えます。

「見える化」という言葉が取りこぼしているもの

進捗管理の文脈では「見える化」という言葉がよく使われますが、この言葉は主語が曖昧です。誰にとって見えるのか、いつ見えるのかが抜け落ちています。

進行のとりまとめをしている人にとっての見える化は、多くの場合「一覧で見えること」を指します。全体が1画面に収まり、遅れているものが目立ち、詰まっている場所が分かる状態です。一方、作業している人にとっての見える化は「自分の次の仕事が分かること」です。この2つは重なる部分もありますが、同じではありません。

とりまとめ役だけに都合のよい見える化を作ると、必ず入力が止まります。作業者から見て入力するメリットがゼロで、コストだけがある形になるからです。逆に、作業者にとって便利な形にだけ寄せると、今度は全体が見えなくなります。両方が成り立つ設計だけが続きます。

現場でよく聞くのは、立派な管理表を作った直後の2週間はきれいに埋まり、その後じわじわと空欄が増え、1か月後には誰も見なくなった、という話です。これは意志の問題ではなく設計の問題です。埋める理由が埋める人の側になければ、どんな仕組みでも同じ経過をたどります。

進捗管理の方法は、構造としては2つしかない

やり方の名前はいくらでもありますが、構造で分けると進捗管理の方法は2つに集約されます。報告してもらって集める形と、仕事の副産物として状態が残る形です。

観点	報告して集める形	状態が副産物として残る形
情報が発生する瞬間	報告のタイミング	仕事が動いたタイミング
更新する動機	求められたから	次に進めるため
抜けたときの状態	その期間の記録が消える	動いていないことが残る
とりまとめ役の仕事	集める、催促する	見る、詰まりを外す
情報の鮮度	報告周期に依存する	常に最新

表の最後の行の違いが、実務では一番効きます。報告して集める形では、報告周期より短い変化は絶対に見えません。週次で集めているなら、火曜に発生して水曜に解決した問題は記録に残らないし、金曜に詰まった案件は翌週の報告まで誰も気づきません。周期を短くすれば鮮度は上がりますが、そのぶん報告のコストが増えます。この二律背反から、報告型は原理的に抜け出せません。

もうひとつ重要なのが、抜けたときの挙動です。報告型では、報告がなかった週は「情報なし」になります。順調だったのか、忙しくて報告できなかったのか、そもそも止まっていたのかが区別できません。副産物型では、動かなかったものは「動いていない」という状態としてそのまま残ります。空欄ではなく、事実として残る。ここが決定的な差です。

報告して集める形にも向いている場面はある

副産物型が常に正しいわけではありません。報告型が向く場面は確実にあります。

ひとつは、複数の会社や部署にまたがっていて、同じ道具を共有できない場合です。相手先のシステムに入れない、こちらの道具に相手を招待できないという制約があるなら、決まった様式で報告をもらうほうが現実的です。ふたつめは、進行の単位が非常に大きく、動きが月単位でしか出ない仕事です。研究開発や長期の建設案件のように、日々の状態がほとんど変わらないなら、細かい状態を持つ意味が薄くなります。

3つめは、報告そのものが成果物として要求されている場合です。委託契約で月次報告書の提出が定められている、監査で記録が必要といったケースでは、報告を省くことはできません。この場合に考えるべきなのは報告をなくすことではなく、日々の状態から報告書を組み立てられるようにして、報告のために別途書き起こす手間を減らすことです。

逆に言えば、これら以外のほとんどのチーム、つまり同じ道具を共有でき、週の中で状況が動き、報告書の提出義務がないチームでは、副産物型に寄せたほうが全員の総作業時間が減ります。

報告させる形が形骸化する4つの理由

報告型が続かないのは、担当者の意識が低いからではありません。構造的に続かない理由が4つあります。この4つのどれに引っかかっているかを特定すると、直すべき場所が具体的になります。

更新のコストが、報告する人にだけ乗っている

進捗の報告は、報告する人にとって直接の利益がありません。書いても自分の仕事は1ミリも前に進みません。利益を受け取るのは、それを見るとりまとめ役や上位の管理者です。コストを払う人と利益を受け取る人がずれている仕組みは、例外なく劣化します。

これを直す方向は2つあります。ひとつは、コストそのものを限りなく小さくすること。もうひとつは、更新した人にも見返りが出るようにすることです。前者は、報告を書く行為をやめて、カードを次の列に動かすといった1回の操作に置き換えるアプローチです。後者は、更新すると次の担当者に自動的に渡る、更新しないと自分のところに仕事が溜まって見える、といった形で、更新が自分のためになる状態を作ることです。

理想は両方成り立つ形です。作業が終わったらカードを動かす。その操作は数秒で済み、動かした結果として次の人に仕事が渡る。報告のために別途何かを書く必要はなく、動かさなければ自分の列に溜まって見えるので、動かす動機が自分の側にあります。

実作業の言葉から、報告の言葉への翻訳が挟まっている

もうひとつ大きいのが、報告様式が実作業と別の言葉でできていることです。「進捗率」「消化工数」「残作業見込み」といった欄は、管理する側にとっては扱いやすい形ですが、作業している人はその形で仕事をしていません。

作業者の頭の中にあるのは、「あの画面のここが決まっていないから止まっている」「先方の返事待ち」「あと2つ直せば出せる」といった具体です。これを進捗率という数字に翻訳するのは、それ自体が思考を要する作業です。しかも翻訳の基準が人によって違うので、出てきた数字を並べても比較できません。80%と書いた人と50%と書いた人のどちらが先に終わるかは、その数字からは分かりません。

進捗率が意味を持つのは、作業が均質に分割されていて、1つ終わるごとに同じだけ全体が進む仕事だけです。多くの企画職や開発職の仕事はそうなっていません。だから、翻訳を要求するのをやめて、作業者が普段使っている言葉のまま残せる形に寄せたほうが、情報の質は上がります。「どの工程にいるか」「誰が持っているか」「何を待っているか」なら、翻訳なしで答えられます。

報告の周期と、仕事が動く周期がずれている

週次報告のチームで、月曜に週次報告を出す運用にしているとします。金曜の夕方に発生した問題は、月曜の朝まで報告に載りません。載ったころには週明けの動きが始まっていて、報告の内容はすでに古くなっています。

かといって周期を短くすると、今度は報告が重くなります。日次報告を全員に課すと、報告に取られる時間が積み上がり、内容も薄くなります。実際、日報の運用が長続きしているチームでは、書く内容が「本日は◯◯を進めました」の定型になっていることが多く、それは情報としてほとんど価値を持ちません。

周期の調整でこの問題は解けません。解けるのは、周期そのものをなくしたときだけです。仕事が動いた瞬間に状態が変わる形なら、周期という概念自体が要りません。見たい人が見たいときに見れば、そこには常に最新の状態があります。

報告した内容が、使われているように見えない

最後の理由が、実は一番大きいかもしれません。報告を出したのに、次の打ち合わせで同じことを口頭で聞かれる。書いた課題が放置されている。誰も読んでいないように見える。こうなると、報告は「出すことが目的の儀式」に変わります。

儀式になった報告は、内容が形式的になり、やがて出す人が減ります。これを防ぐには、報告された内容に対して見た側が何かを返す必要がありますが、それはとりまとめ役の負荷を増やします。ここでも構造の無理が出ます。

副産物型では、この問題の出方が変わります。状態はチーム全員が見られる場所に置かれているので、とりまとめ役が反応しなくても、次の工程の人が拾って動きます。誰かに読まれるために書くのではなく、次に進めるために動かす。読まれなかったことによる徒労感が発生しません。

「聞かなくても分かる状態」を3つに分解する

では、何が残っていれば聞かなくてよくなるのか。実務で必要になるのは、突き詰めると3つです。

いま誰が持っているか

進行で最初に詰まるのは、たいてい「これ、いま誰の手元にあるのか」が分からない状態です。依頼はしたが受け取られたか分からない、複数人が関わっていて誰が次に動くのか曖昧、レビューを回したが誰のところで止まっているか見えない。

この不明が発生すると、確認の連絡が飛びます。確認された側は作業を中断します。しかも確認は往復するので、1回の不明で最低2回の割り込みが生まれます。担当が常に1人だけ明示されている状態を保つだけで、この往復はほぼ消えます。

大事なのは、担当を「関係者全員」にしないことです。関係者が3人いる仕事でも、いま手を動かして次に進める責任を持つ人は1人に決まります。残りは関係者であって担当ではありません。この区別を曖昧にすると、全員が「誰かがやるだろう」と思って誰も動かない時間が生まれます。

どこで止まっているか

次に必要なのが、どの工程で止まっているかです。同じ「進行中」でも、着手前で止まっているのか、作業の途中なのか、レビュー待ちなのか、先方の返事待ちなのかで、とりまとめ役が打つ手は全部違います。

着手前で止まっているなら、優先度か情報が足りていません。作業の途中で止まっているなら、難易度か作業量の見積もりがずれています。レビュー待ちで止まっているなら、レビューする人の手が足りていません。先方の返事待ちなら、こちらにできることはなく、待ち時間として織り込むだけです。

この4つは打ち手がまったく違うのに、進捗率という1つの数字にすると全部が「50%」に潰れます。工程を列として持ち、いまどの列にあるかが分かる形にしておくと、数字を見なくても打ち手が決まります。

いつ最後に動いたか

3つめが最終更新の時刻です。これが一番軽視されがちで、実は一番使えます。

止まっている仕事を見つける方法として、担当者に「進んでいますか」と聞くのは効率が悪い方法です。順調なものにも聞くことになるし、聞かれた側は答えを用意しなければなりません。最終更新だけを見れば、5日間動いていないカードだけが浮かび上がります。順調なものは自然に更新されるので、確認の対象から自動的に外れます。

この見方の良いところは、責める材料にならないことです。「5日動いていない」は事実であって評価ではありません。理由は、忙しい、詰まっている、優先度が下がった、そもそも終わっているのに動かし忘れた、のどれかです。声のかけ方も「進んでますか」ではなく「これ、何かで詰まってますか」になります。前者は報告を求める質問で、後者は障害を外す申し出です。受け取り方がまったく違います。

状態が自然に残る形をどう作るか

ここからは具体的な作り方です。道具を何にするかより先に、仕事の載せ方を決める必要があります。

仕事の単位を1枚のカードにそろえる

最初に決めるのが、何を1件として扱うかです。ここがそろっていないと、後の全部が崩れます。

目安は、1人が担当でき、状態が1つに定まる大きさです。「サイトリニューアル」は大きすぎます。担当が複数いて、状態も部分ごとに違うからです。逆に「メールを1通送る」は小さすぎて、カードにする手間のほうが大きくなります。数日から2週間程度で終わり、終わったかどうかを他人が判定できる単位が扱いやすい大きさです。

粒度は完全にそろいません。そろえようとしないほうがよいのですが、それは後述します。ここで決めるべきは「1枚のカードには担当が1人で、状態が1つ」という原則だけです。この原則さえ守れば、大きさが多少ばらついても運用は成立します。

列を工程の言葉にする

次に列です。「未着手・進行中・完了」の3列は、どんな仕事にも当てはまる代わりに、何も教えてくれません。進行中の列に全部が溜まって、結局そこを開いて中を確認することになります。

列は、そのチームが実際に通る工程の名前にします。制作なら「情報待ち・作業中・社内確認・先方確認・修正・完了」といった形です。開発なら「起票・設計・実装・レビュー・検証・完了」。営業なら「初回接触・提案準備・提案済み・検討中・受注」。大事なのは、列を見ただけで次に何が起きるかが分かることです。

列の数は5から7あたりが扱いやすい範囲です。少なすぎると情報が潰れ、多すぎると画面に収まらず、どの列に置くべきかの判断に迷いが出ます。迷いが出る設計は、それだけで入力が止まる原因になります。

待ちと差し戻しを独立した列にする

多くのチームが最初に見落とすのが、待ちの状態です。先方の返事待ち、他部署の承認待ち、素材の入稿待ち。これらを「進行中」に入れておくと、進行中の列がふくらんで、本当に手が動いているものが埋もれます。

待ちを独立させると、とりまとめ役の仕事が明確になります。待ちの列に溜まっているものは、担当者にできることがありません。外に催促するのはとりまとめ役の役割です。つまり待ちの列は、そのままとりまとめ役のタスクリストになります。

同じく重要なのが差し戻しです。レビューで戻ったものを「作業中」に戻すと、初回の作業と再作業の区別がつきません。差し戻しが多い工程は、その手前の工程に問題があります。区別して残しておくと、どこで手戻りが発生しているかが後から見えます。ここは責任追及のためではなく、指示の出し方や前提の共有を直すために使う情報です。

担当と期日は、カードを作った瞬間に置く

後から埋めるつもりの欄は、永久に埋まりません。カードを作る時点で担当と期日を必須にしておくと、この問題は起きません。

期日については、正確な予測を求めないことが肝心です。求めると、担当者は安全側に大きく振った日付を置くか、そもそも置くのを避けます。置いてほしいのは「この日までに何も起きなかったら、様子を見に行くべき日」です。この定義なら気軽に置けますし、外れても誰も困りません。期日は約束ではなく、確認のきっかけとして扱います。

担当については、まだ決まっていない仕事にとりまとめ役の名前を入れておく運用が使えます。誰の仕事でもないカードは消えますが、とりまとめ役に割り当てられていれば、割り振りという仕事として残ります。

置き場所を1つに決めて、残りは入口にする

いちばん効く一手が、これです。状態が置かれる場所を1つに決めます。そこに書いていないものは存在しない、という扱いにします。

現実には、依頼はチャットで来るし、詳細はメールに書いてあるし、資料は共有ドライブにあります。それは変えられません。変えるのは、それらを状態の置き場所にしないという点だけです。チャットで依頼が来たら、カードを1枚作って、そのチャットのリンクを貼る。メールで仕様が届いたら、カードに要点を写すかリンクを貼る。入口はいくつあっても構いませんが、状態の置き場所は1つにします。

この運用が定着すると、「あの件どうなってた」という質問の答えが、必ず同じ場所にあるようになります。逆に、この一貫性が崩れているチームでは、どんな高機能な道具を入れても状況把握のコストは下がりません。道具の問題ではなく、置き場所が分散していることの問題だからです。

更新の操作を1回に減らす

最後に、更新にかかる操作の回数を数えてみることを勧めます。作業が1つ終わったとき、状態を最新にするために何回の操作が必要か。カードを開いて、進捗率を書き換えて、コメントを書いて、担当を変えて、保存する。これで5操作です。この量だと、忙しい日には飛ばされます。

カードを1つ隣の列に動かす。これで1操作です。担当が自動的に次の人に変わる設計にできるなら、さらに手間は減ります。操作が1回で済む形にできているかどうかが、3か月後に運用が残っているかどうかを分けます。

見る側が我慢すべき4つのこと

ここが実は一番重要です。仕組みを作っても定着しないチームの大半は、見る側の振る舞いによって壊しています。

更新されていないことを、人の怠慢として扱わない

更新が止まったカードを見つけたとき、最初に出てくる反応が「更新してください」だと、その仕組みは終わりに向かいます。更新の催促は、報告の催促と同じものです。副産物型に移したはずが、報告型に戻ります。

止まっているカードは、原因を示す情報として扱います。動いていないのは、詰まっているか、優先度が実質的に下がっているか、終わっているのに動かし忘れているかです。前2つならとりまとめ役の出番があり、3つめなら操作が面倒である可能性が高いので、設計を見直す材料になります。どれも、人を責めても改善しません。

現場でよく聞くのは、更新の催促を始めた途端に、実態と違う更新が増えたという話です。責められるのが嫌なので、動いていなくても何かしら動かすようになる。こうなると状態は嘘になり、見る意味がなくなります。正直に止まったままにしておける空気を保つことが、情報の正確さを守る唯一の方法です。

粒度をそろえろと言わない

カードの大きさは必ずばらつきます。半日で終わるものと2週間かかるものが同じ板に並びます。見る側からすると気持ち悪いので、そろえたくなります。

しかし粒度をそろえる作業は、作業者にとって完全な追加コストです。仕事の自然な区切りを、管理の都合に合わせて切り直す作業だからです。しかも切り直したところで、実際の作業量がそろうわけではありません。

見る側が持つべき前提は、「カードの枚数は仕事量を表さない」というものです。枚数で進み具合を測ろうとするから、粒度をそろえたくなります。測るのをやめれば、そろえる必要もなくなります。大きいカードは大きいまま置いておき、止まったら中を見に行けば十分です。

全部を見ようとしない

板に載っているカードが100枚を超えると、全部に目を通すのは無理になります。それでも全部を把握しようとすると、とりまとめ役が破綻するか、板を細かく分割して全体が見えなくなるかのどちらかです。

見るべきは3種類だけです。止まっているもの、待ちの列にあるもの、期日を過ぎているもの。この3つ以外は、動いている限り見なくて構いません。動いているものを確認するのは、順調な人の手を止める行為です。

この割り切りができると、担当している板の数が増えても、とりまとめにかかる時間はあまり増えません。逆に、全部を把握しようとする姿勢を保ったままだと、扱える範囲は人数に対して直線的に苦しくなります。

数字にするのを急がない

板の運用が回り始めると、次に出てくるのが集計の要求です。全体で何%進んだのか、今月何件終わったのか、部署別ではどうか。

数字にすること自体は悪くありませんが、順番を間違えると壊れます。集計を先に決めると、集計しやすい形の入力を作業者に求めることになり、そこから翻訳のコストが戻ってきます。進捗率の欄が復活し、工数の入力欄が増え、また埋まらなくなります。

先に固めるのは、状態が正しく残る形です。数字はその後、残っている状態から機械的に取り出せる範囲で出します。取り出せない数字は、いったん諦めるのが正解です。上位に報告する数字のために現場の入力を重くするのは、優先順位が逆になっています。

道具のどこで詰まっているのかを見極める

ここまでの設計を、いまの道具でそのまま実現できるなら、道具を変える必要はありません。詰まる場所は道具の種類ごとにおおよそ決まっているので、自分のケースがどれかを当てはめてみることができます。

表計算ソフトで管理している場合、詰まるのは同時編集と一覧性です。1人が行を挿入して整形している間、他の人は最新の状態を見られません。日付を1日ずらすだけで、線を引き直す作業が発生する形式になっていると、更新の心理的コストが跳ね上がります。一方で、集計と加工の自由度は表計算が圧倒的に高いので、報告書を作る作業が中心のチームでは無理に移す必要はありません。

チャットで管理している場合、詰まるのは残らないことです。話す場所と残す場所が同じだと、決定事項が会話に埋もれます。チャットは依頼の入口としては優秀なので、入口として残しつつ、状態の置き場所を別にするのが現実的な解です。

すでにタスク管理ツールを使っていて機能しない場合は、詰まりの場所が2つに分かれます。ひとつは機能が足りない場合。もうひとつは、機能が多すぎて入力が重い場合です。後者のほうがはるかに多く、そして自覚されにくい詰まり方です。使っていない項目が画面に並んでいるだけで、カードを1枚作る心理的コストは上がります。

道具の乗り換えを検討する段階なら、それぞれの道具が何を得意にしていて何を捨てているかを並べて見るのが早道です。付箋を貼るように仕事を並べる形の道具との違いをまとめたTrelloとの比較、タスクの依存関係や複数の見え方を持つ道具との違いを整理したAsanaとの比較、文書とデータベースを自由に組める道具との違いを扱ったNotionとの比較があります。仕事の自動化や外部サービスとのつなぎ込みを重視する道具との違いはmonday.comとの比較にまとめられています。

日本語で作られた開発向けの道具を検討しているなら、課題管理とバージョン管理を1か所に持つ設計との違いを扱ったBacklogとの比較、同じくボード型で日本語対応の道具との違いを整理したJootoとの比較が参考になります。どれか1つを読むより、まず比較の一覧で全体の並びを見てから、いま使っているものと近いページに進むほうが判断が早くなります。

判断の材料として、何ができて何ができないかを一覧にしたページも見ておく価値があります。できることには、板の作り方や状態の持ち方に加えて、あえて持たない機能も書かれています。ソースコードを置く機能は持たないこと、自動化と外部サービス連携では勝負しないこと、画面が日本語のみであること。この3つがチームの必須条件に入っているなら、他の道具を選ぶほうが幸せになります。

進め方を変えるときの段取り

仕組みを変えると決めたとき、全部を一度に移すのは失敗しやすい進め方です。移行そのものが大仕事になり、その負荷が新しい仕組みへの反発として跳ね返ります。

現実的なのは、いま動いているプロジェクトを1つだけ選んで、そこだけ新しい形にすることです。選ぶなら、期間が数週間から2か月程度で、関わる人が3人から6人くらいの案件が適しています。小さすぎると効果が分からず、大きすぎると失敗したときの傷が深くなります。

この試行期間には、古い仕組みを並行して残します。二重管理になるので手間は増えますが、期間を区切れば耐えられます。並行させる理由は、新しい形が合わなかったときに戻れるようにするためです。退路を断つ移行は、合わないと分かった後も引き返せず、結局どちらも中途半端になります。

判断の基準は、試行期間の終わりに「聞かずに分かる状態になったか」の1点で見ます。とりまとめ役が状況を聞いて回った回数が減ったか。板を見れば説明できる状態になったか。作業者が更新を負担と感じていないか。この3つが満たされていれば、他のプロジェクトにも広げてよい段階です。

すでにボード型の道具を使っていて、そこから移りたい場合は、手作業でカードを作り直すのが一番重い工程になります。この点については、既存の板をそのまま取り込む仕組みを説明したTrelloからの移行にまとめられています。ただし、自動で取り込めるのはTrelloからだけで、他の道具からは手作業になります。ここは正直に見積もっておく必要があります。

社内で導入の話を通す段階では、費用とデータの扱いの2点が必ず聞かれます。費用については、プランの区切りが何によって決まるのかを載せた料金を見ておくと、人数が増えたときにどう変わるかの見当がつきます。区切りの考え方が機能で絞らず、区切るのは人数とボードの数だけという形になっているため、上のプランに移らないと使えない機能を心配する必要がありません。データの扱いについては、預けた情報がどう保管され、誰が触れるのかの考え方を書いた安全性の考え方があります。稟議に添える資料としては、この2つのページで大半の質問に答えられます。細かい疑問が残る場合はよくある質問を先に見ておくと、問い合わせの往復を減らせます。

独自データ考察

進捗管理の方法をめぐる相談を分類していくと、比較ページへの関心の集まり方に一定の傾向が見えます。ここでは、比較のページ群がどういう軸で書かれているかから、判断に使える観点を取り出します。

比較のページ群で共通して先に置かれているのが、「相手のままがいい場合」です。乗り換えを促す前に、乗り換えなくてよい条件を明示する構成になっています。これは書き方の作法という以上に、実務的な意味があります。道具の入れ替えは、それ自体が数週間の負荷を生む作業だからです。負荷を払う価値があるのは、いまの道具の弱点が毎週の作業時間として表に出ているときだけです。

もうひとつ読み取れるのが、比較の軸が機能の多寡になっていない点です。ソースコードを置く機能は持たない、自動化と外部連携では勝負しない、画面は日本語のみ、自動で取り込めるのはTrelloだけ。この4つが自分の側の制約として明記されています。機能表で勝つ構成にするなら書かないほうが得な情報ですが、それを先に出しているということは、比較の軸を機能数ではなく別のところに置いているということです。

その別の軸が、料金ページの設計に表れています。区切りが人数とボードの数だけで、機能によるプランの差がない構造です。この構造が実務で持つ意味は、進行の設計に対する制約が減ることです。機能でプランが分かれる料金体系では、「この機能を使いたいから上のプランに」という判断が定期的に発生します。判断が発生するたびに稟議が要り、稟議のたびに導入は止まります。区切りが人数とボードの数だけなら、増えるかどうかは事前に読めるので、費用の予測が立ちます。

また、比較の一覧に並ぶ相手の顔ぶれからも、想定されている読者像が読み取れます。付箋型のシンプルな道具、複数の見え方を持つ道具、文書とデータベースを組み合わせる道具、自動化に強い道具、日本語の開発向けの道具。この並びは、いずれも5人から数十人のチームが実際に検討の俎上に載せるものです。数百人規模の全社導入や、大規模開発のための道具は並んでいません。想定している規模がはっきりしているぶん、この規模から外れるチームは早い段階で別の候補に移ったほうがよい、という読み方もできます。

最後に、外部の統計に触れておきます。ソフトウェア開発の分野では、プロジェクトの定量データを継続的に収集して分析結果を公開する取り組みが行われており、進捗の遅れがどのように発生するかについても記録が蓄積されています。

ソフトウェア開発プロジェクトの基礎データを収集し、統計処理や分析を行って、その結果を継続的に公開している。開発の途中で追加の要求や仕様の変更が重なり、規模がふくらんだ結果として進捗が遅れ、品質にも影響が出るという経過は、事例として繰り返し報告されている。 出典: ipa.go.jp

ここで注目したいのは、遅れの原因として挙げられているのが「報告が不足していたこと」ではない点です。挙げられているのは、途中で増えた要求と、それによってふくらんだ規模です。つまり、遅れは報告の精度を上げれば防げるものではなく、増えていく作業量が見えるかどうかで決まります。

この視点に立つと、進捗管理の方法として最初に整えるべきものが変わります。いま何%終わったかを正確に集めることではなく、いま何枚のカードがあり、そのうち何枚が新しく増えたものかが見える状態を作ることです。カードが増えたことは、誰かが報告しなくても、板を見れば分かります。増えた分をどう扱うかを決めるのは人の判断ですが、増えたこと自体に気づくのは仕組みの仕事です。聞かなくても分かる状態というのは、この「気づく」の部分を人の努力から仕組みに移すことに他なりません。

Q1. 進捗管理の方法を変えたいのですが、まず何から手を付けるべきですか？

状態の置き場所を1つに決めることから始めてください。依頼の入口はチャットでもメールでも構いませんが、「いま誰が持っていて、どの工程で止まっているか」が書かれる場所は1か所にします。ここが分散したままだと、どんな道具を入れても状況を集める手間は減りません。道具選びはその後です。

Q2. 報告や日報をやめてしまって、本当に状況を把握できますか？

把握できる形にするには、担当・工程・最終更新の3つが仕事の副産物として残る必要があります。この3つがあれば、動いていないカードだけが浮かび上がるので、確認する相手を絞り込めます。ただし、契約で報告書の提出が定められている場合や、他社と道具を共有できない場合は、報告の形を残したほうが現実的です。

Q3. せっかく仕組みを作っても、2週間ほどで更新されなくなります。原因は何ですか？

多くは、更新のコストを払う人と、その情報で得をする人がずれていることが原因です。更新に必要な操作が何回あるか数えてみてください。カードを開いて複数の欄を埋めて保存する形になっているなら重すぎます。列を1つ動かすだけで状態が変わる形まで削ると、忙しい日でも飛ばされにくくなります。

Q4. 進捗率で管理するのはやめたほうがよいのでしょうか？

作業が均質に分割されていて、1つ終わるごとに同じだけ全体が進む仕事なら有効です。そうでない仕事では、進捗率の基準が人によって違うため、並べても比較できません。代わりに「どの工程にいるか」を列として持つと、着手前・作業中・レビュー待ち・先方待ちのどれで止まっているかが分かり、打つ手が具体的に決まります。