【これだけでOK】プロジェクト日程の作り方|報告会で伝わるシンプル管理術

ビジネス
記事内に広告が含まれています。
スポンサーリンク
この記事でわかること
  • 報告会で使用できる日程の作り方が分かる
  • 細かくなりすぎないための書き方が分かる
  • 初めて見た人にも伝わる日程の書き方が分かる

この記事の対象になる方

  • プロジェクト日程をどう作ればいいか分からない人
  • 報告用の日程が細かくなりすぎてしまう人
  • 簡単かつシンプルにスケジュール調整したい人

はじめに

最末端エンジニアのにこらです。

今日はタイトル通り、初心者でも新入社員でも分かる、

報告で使えるプロジェクト日程の書き方について共有します。

プロジェクト日程というと、つい気合いを入れて細かく作り込みたくなります。
ですが実務で本当に求められているのは、芸術作品のようなスケジュール表ではありません。

求められているのは、今どこまで進んでいて、どこが遅れていて、誰が何をやるのかが一目で分かることです。

細かく書きすぎると何が起きるか。
作るのに時間がかかる。更新にも時間がかかる。会議のたびに直すだけで疲れる。
しかも見る側は細かすぎて分からない。これでは本末転倒です。

良い日程表は、細かいことを全部書いた表ではなく、進み具合が一発で伝わる表です。

特に報告会で使う日程は、詳細なタスク管理表とは役割が違います。
細かい仕様や個別タスクは別で管理し、日程表は全体を俯瞰して判断するための道具として使うのが正解です。

この記事では、その考え方をできるだけシンプルに整理していきます。

誰でも分かる日程の書き方はこれだ!!

この図で大事なのは、誰が・どこで・何を・いつまでにやるかが見えることです。
そしてもうひとつ大事なのが、遅れが発生したときにすぐ分かることです。
現在位置の目安として、更新日時点の日付に赤線を引いておきましょう。

日程表は、計画を飾るために作るものではありません。
ズレを見つけて、すぐ打ち手を考えるために作ります。

列の分け方について

プロジェクト日程は、あれこれ情報を盛り込むよりも、まず列の考え方を整えると一気に見やすくなります。
基本は次の3つで十分です。

1.部署

まずは部署です。
どの部署がどこまで担当するのかを明確にしましょう。

例えば設備導入やシステム導入の案件であれば、こんな分け方がよくあります。

  • 生技
  • 製造
  • 保全
  • 購買
  • 品証
  • システム
  • ベンダ

この列があるだけで、この工程は誰のボールなのかが一目で分かります。
逆にこれがないと、日程表を見ながら毎回口頭で説明する羽目になります。

2.誰がやるか

次に担当者です。
部署だけでは大きすぎるので、部署内で誰が持つのかを明確にしておきます。

もちろん、報告会向けならフルネームまで細かく書かなくても構いません。
ただ、少なくとも主担当が分かるようにしておくと、遅れや課題が出たときにボールの所在がはっきりします。

日程表でよくある事故のひとつが、みんなの仕事になっていて誰の仕事でもない状態です。
これを防ぐだけでも、日程を作る価値は上がります。

3.日程

そしてメインの日程列です。
ここで重要なのは、中規模のイベントを書くことです。

例えば次のようなものです。

  • 見積取得
  • 仕様確定
  • 稟議
  • 発注
  • 製作
  • 立上げ
  • 検収

こういったイベント単位で記載するのがちょうどいいです。
逆に、あまりに細かい作業までは書かない方がいいです。

例えば、

  • メール送付
  • 会議資料作成
  • 図面修正
  • 社内確認依頼
  • 仕様文言調整

こういった細かいタスクを全部入れ始めると、日程表はすぐに崩壊します。
見る側にとってもそんな細かい情報は管理せんでもええやろ、、、、とノイズが増えるだけです。

報告用の日程表に必要なのは、作業一覧ではなく節目!!

終わったイベントはグレーでハッチング

このルールはとても大事です。
終わったイベントは、そのまま色を残すのではなく、グレーでハッチングして完了扱いにしましょう。

なぜなら、終わったものと進行中のものが同じ見た目だと、今どこが動いているのかが分かりにくくなるからです。
会議の場では、過去の情報より今どこに注目すべきかが大切です。

完了したイベントをグレーにすると、自然と視線が未完了の工程に向きます。
これだけで日程表としての使いやすさがかなり上がります。

延期や遅れ、挽回案は黄色で見せる

予定が延期になった、または遅れが出た。
このときは元の矢印を無理やり引き伸ばすだけではなく、黄色の矢印を新たに作るのがおすすめです。

これは見た目の問題ではなく、経緯を分かりやすくするためです。

元の予定だけを書き換えると、
どこでズレたのか
どれくらいズレたのか
どう挽回したのか
が見えなくなります。

一方で、遅れや挽回案を色分けして見せると、報告を受ける側もすぐ理解できます。

  • 元の計画はどうだったか
  • 今の見込みはどうか

これが見えるだけで、日程表はただの予定表から進捗管理の資料に変わります。

遅れは隠すより、見える化した方が良い。結果として後れを挽回するきっかけにつながる

ハッキリ言えば日程について重要なのはこれだけです。

プロジェクト日程は、思っているより少ない情報で十分に機能します。

むしろ、最初から情報を盛り込みすぎると、表の役割が曖昧になります。
日程表はあくまで日程を見る場所。
仕様書は仕様を見る場所。
KPI表は評価や進捗の深掘りを見る場所。

役割を分けることが大切です。

細かい部分が分からないときはどうするか

ここでよく出るのが、
いや、これだけじゃ細かい部分が分からない
という意見です。

その通りです。
でも、それは日程表の仕事ではありません。

細かい部分は、KPIや仕様書、課題管理表、ToDo一覧で管理していきましょう。
日程表でやるべきことは、何が遅れているかが分かる状態にすることです。

例えば次のように役割分担すると整理しやすいです。

  • 日程表:全体進捗と主要イベントの見える化
  • KPI表:進捗率や評価指標の管理
  • 仕様書:詳細仕様の整理
  • 課題管理表:問題点と対策の管理
  • アクションリスト:担当と期限の管理

この切り分けができると、資料が一気に扱いやすくなります。

細かすぎる日程はなぜダメなのか

ここはかなり重要です。

細かい日程表は一見すると丁寧に見えます。

ですが、実務では逆効果になることが多いです。

作るだけで時間が溶ける

細かいスケジュールは、作るのも直すのもとにかく大変です。
少しズレただけで、後ろの工程まで全部直す必要が出てきます。

更新が追いつかない

実務は必ず変動します。
細かい表ほど、現実に追いつけなくなります。結果として、最新ではない資料が会議に出てくることになります。

読む側が疲れる

報告会で見せる資料は、詳細な分析資料ではありません。
関係者が短時間で状況を理解できる必要があります。
細かすぎる表は、見た瞬間に読む気を失わせます。

管理のための管理になりやすい

本来はプロジェクトを前に進めるための資料なのに、いつの間にか日程表を維持すること自体が目的になります。
これがいちばんもったいないです。

日程表は、きれいに維持するためのものではなく、判断を早くするためのものです。

筆者自身、昔はかなり細かい日程を作っていました。
何でも書けば親切だと思っていた時期です。

ですが現実は逆でした。
細かく書けば書くほど、修正が大変になる。
更新に時間を取られる。
会議で見せても細かすぎて伝わらない。
結局、誰も幸せにならない。

その経験から感じるのは、日程はオンスケか否かがパッと分かるものにするべきということです。
そして、なぜ遅れているかは別表から拾って、必要ならスケジュール上にコメントで補足するくらいがちょうどいいです。

これが一番、運用が続きます。

報告会で使える日程表のコツ

報告会で使うなら、次のポイントを意識するとかなり見やすくなります。

1.1ページで全体が見えるようにする

複数ページにまたがると、全体感が伝わりにくくなります。
可能であれば、主要イベントだけに絞って1ページで見えるようにしましょう。

2.イベント名は短く書く

説明文のような長さにすると読みにくくなります。
できるだけ短い言葉で統一しましょう。

  • 見積取得
  • 稟議承認
  • 発注
  • 製作
  • 立上げ
  • 検収

3.色の意味を固定する

例えば次のように決めておくと分かりやすいです。

  • グレー:完了
  • 白:計画
  • 黄:変更、挽回案
  • 赤:重大な遅れ、注意点

色の意味が毎回変わると逆に混乱します。

4.コメントは最小限にする

遅れ理由や課題は必要ですが、長文は避けた方がよいです。
一言で読める程度にとどめましょう。

  • 部品納期遅れ
  • 稟議待ち
  • 仕様変更対応
  • 人員調整中

5.節目をそろえる

各部署の工程粒度がバラバラだと読みにくくなります。
A部署は週単位、B部署は日単位、C部署は月単位、のようになると混乱します。
同じレベルのイベントでそろえるのがコツです。

日程とKPIはセットで考えると強い

この記事のテーマは日程ですが、実務ではKPIとセットで考えるとより強くなります。

日程表だけだと、遅れていることは見えても、どの程度深刻なのかが分かりにくいことがあります。
そこでKPIや進捗率を別表で持っておくと、遅れの中身まで説明しやすくなります。

例えば、

  • 仕様確定率
  • 見積取得率
  • 稟議完了率
  • 製作進捗率
  • 検収項目完了率

といった形です。

日程表で全体を見せ、KPI表で深掘りする。
この組み合わせが、現場でも報告でもかなり使いやすいです。

KPIの作り方はこちら↓

まとめ

  • プロジェクト日程は、誰が・何を・いつやるかが一発で分かれば十分
  • 列は 部署・担当・日程 の3つを基本にすると見やすい
  • 日程には細かい作業ではなく、見積取得・稟議・発注・検収 といった中規模イベントを書く
  • 完了はグレーでハッチング、遅れや挽回案は黄色で新たに示すと分かりやすい
  • 細かい仕様や進捗管理は、日程表ではなくKPIや仕様書、課題管理表で分けて管理する

プロジェクト日程は、作り込みすぎるほど良くなるわけではありません。
むしろ、シンプルで、今の状況がすぐ伝わることの方が圧倒的に大事です。

見た瞬間に分かる。遅れたときにすぐ分かる。次に何をすべきか判断できる。
この3つを満たせば、その日程表はかなり優秀です。

使う日程は、細かさより伝わりやすさ。
これだけ覚えておけば、かなり強いです。


本記事は学習目的の情報提供です。実際の電気工事・設計・配線・機器選定・部材選定・改造は、法令・社内基準に従い、有資格者および責任者の管理下で実施してください。現場条件により最適解は変わるため、必ずメーカー仕様書・設計基準・安全規程・JISを確認のうえ判断してください。

スポンサーリンク
Nikolaをフォローする

この記事へのコメント