12月の終わりに差しかかると、現場は少しずつ静まり、ようやく手元の仕事を見返す余裕が生まれます。
慌ただしく過ぎていった一年を前に、「なぜこんなに詰まっていたのだろう」と振り返る方も多いのではないでしょうか。
Webディレクターにとって、年末は“棚卸し”の季節です。
スケジュールを振り返り、トラブルの原因を探り、来年に向けて段取りを再設計する絶好のタイミング。
特に進行管理は、日々の積み重ねの中で小さなひずみが蓄積しやすいため、
振り返りを行わないまま次の年に入ってしまうと、同じ迷いを何度も繰り返してしまいます。
今回の記事では、
「詰まりやすかった理由を言語化する」
「それを来年の段取りへと結び直す」
という、年末にこそ取り組みたい進行管理の棚卸しを扱います。
後半のコラムでは、私自身が年末の振り返りを怠り、翌年に苦労した経験をもとに、
言語化の重要性についてお話しします。
目次
「詰まりやすかった工程」を地図のように描き出す
まず最初にやりたいのが、
“詰まりやすかった工程の見える化”です。
進行管理は、トラブルが発生した瞬間の記憶よりも、
その“発生しやすいパターン”を知ることが大切です。
一年を振り返ると、次のような工程で詰まりが出ていないでしょうか。
- クライアントの承認が遅れがちなタイミング
- デザイン初稿が重なる繁忙期
- ライターや開発の工数が逼迫した月
- CMS作業の差し戻しが連鎖した時期
- チーム内の負荷が偏ったプロジェクト
これらを“線”としてではなく、
“地点”として地図のように書き出すことをおすすめします。
地点で捉えることで、
- どこに負荷が集中していたか
- どの工程が渋滞の始点になりやすいか
- どこで優先順位が乱れやすかったか
といった“詰まりの傾向”が見えてきます。
年末の棚卸しは、感覚ではなく、
「どこで止まりがちだったのか」を事実として把握することから始まります。
2. 詰まりの“原因”を短く言語化する 主観ではなく構造で捉える
詰まりの地点が見えたら、次はその理由を言語化します。
ここでのポイントは、感情や忙しさではなく、
構造として原因を捉えることです。
例を挙げると、
- 承認が遅れた
→ “承認者が複数名で、判断のタイミングが合っていなかった” - デザインが詰まった
→ “差し戻しの共有が遅れ、午前の着手に間に合わなかった” - 開発が遅れた
→ “仕様確定が前倒しできず、着手日が後ろにずれ込んだ” - CMS作業が混乱した
→ “フォーマットの差異が吸収されず、作業者間で手戻りが発生した”
このように、
「何が起きたのか」ではなく、「なぜ起きたのか」に着目して言語化することが重要です。
一年分を振り返ると、ある共通点が見えてきます。
- 理由の多くは “情報の伝わり方” にある
- 共有の順番が少しズレただけで詰まりが連鎖する
- 想定のズレが工程のズレに変わっていた
- 判断理由を言語化しきれず、優先順位のズレが起きていた
意外なことに、詰まりの原因は“技術”の問題より、
コミュニケーションの粒度と順番にあることが多いのです。
この棚卸しができると、来年の段取りは驚くほど改善されます。
3. 言語化した“詰まりのパターン”を、来年の段取りに組み込む
棚卸しのゴールは、反省ではありません。
言語化した理由を
来年の段取りへ“再設計”として反映することです。
例えば、棚卸しで次のような原因が見えてきた場合、
- 承認が遅れがちだった
→ “承認者を早めに把握し、MTGやメールで優先順位を前倒し共有する” - 差し戻しで午前が潰れた
→ “デザイナーが動けるタイミングを基準に、前日のうちにFBを返す段取りを作る” - 開発の着手が遅れた
→ “仕様は60%の段階で共有し、早期確認の習慣を設ける” - CMS作業が散らばった
→ “作業ルールを年初に統一し、フォーマットを一本化する”
このように、
“来年の段取りに変えられる形”で棚卸しを設計することが重要です。
棚卸しとは、過去を振り返るだけの作業ではなく、
未来の進行管理を軽くするための“仕込み”そのものです。
詰まりの原因を曖昧にしたまま翌年を迎えてしまい、苦労した話
以前の私は、年末になると「ようやく落ち着いた」と感じ、そのまま休みに入っていました。
振り返りをせず、詰まりの原因を曖昧なままにしていたのです。
ある年、特に印象的な出来事がありました。
その年はとにかく案件が詰まり、
- 承認待ちが重なる
- 差し戻しが同時多発する
- CMS作業の着手順が崩れる
- チームが落ち着かない
という状態が続いていました。
しかし私は、理由を深掘りしないまま年末を迎え、
「忙しかったから仕方ない」と片付けてしまいました。
翌年、同じ時期に入ると、
驚くほど同じ種類のトラブルが再び発生したのです。
その瞬間、
「私は何も学べていなかったのかもしれない」
と気づきました。
そこで、初めて本気で棚卸しに取り組みました。
- どの案件で詰まりが起きたのか
- なぜその工程が止まったのか
- 共有の順番にズレはなかったか
- 判断理由を言語化できていたか
- 誰がどこで困っていたのか
この5点を中心に、一年分のメモやスケジュールを見返しました。
すると、トラブルの背後にある共通点が見えてきました。
「判断はできていたが、なぜその判断をしたのかの共有が遅かった」
「優先順位は整っていたが、揃えるところまでやり切れていなかった」
「詰まりを見つけても、再設計に反映できていなかった」
理由が言語化された瞬間、
頭の中のもやが晴れ、翌年の段取りに生かす準備が整っていきました。
棚卸しは、反省ではありません。
未来の自分に、来年のチームに、より良い段取りを手渡す作業です。
年末の静かな時間に、
詰まりの理由を一つずつ明らかにしていくことで、
翌年の進行管理は想像以上に軽く、整ったものになります。
