ChatGPTソラ先生と学ぶ!中級者のためのAI実践講座【第56回】ChatGPTで業務改善プロジェクトを管理する方法|課題・担当・期限・進捗を整理して成果につなげる実践講座
こんにちは、ソラ先生です。
前回は、ChatGPTを使ってPDCAを実践し、計画・実行・評価・改善を繰り返しながら、仕事の進め方を良くしていく方法を学びました。
今回は、その改善活動を、複数の人や工程が関わる仕事へ発展させてみましょう。
テーマは「業務改善プロジェクトの管理」です。
皆さんは、こんな経験はありませんか?
「改善することは決まったけれど、誰が何をするのか曖昧になっている」
「作業は進んでいるはずなのに、予定していた日に完成しない」
「担当者はそれぞれ仕事を進めているのに、全体としては前へ進んでいない」
「会議で進捗を確認しても、問題が見つかるのはいつも期限の直前」
「改善が終わったと思ったのに、実際の現場では新しい方法が使われていない」
業務改善では、一人で完結する仕事もあれば、複数の担当者が協力しなければ進まない仕事もあります。
例えば、見積業務を改善する場合です。
営業担当者が必要な情報を整理します。
技術担当者が加工条件を検討します。
材料調達の担当者が価格や納期を確認します。
見積担当者が原価を計算します。
そして、新しい方法を現場で試し、結果を確認します。
このような仕事では、それぞれの作業が関係しています。
そのため、個々の作業が進んでいるだけでは、プロジェクト全体が順調とは限りません。
ChatGPTは、改善テーマを具体的な作業へ分解し、作業の順番や依存関係を整理し、進捗状況を分析する手助けができます。
今回は、**「改善目的を決める → 作業へ分解する → 順番と担当を決める → 進捗を記録する → 遅延の原因を調べる → 完了を確認する → 成果を定着させる」**という流れを学びましょう。
1.業務改善プロジェクトとは何でしょうか?
プロジェクトとは、一般に、特定の目的を達成するために、一定の期間や条件のもとで進める取り組みです。
例えば、次のようなものがあります。
見積業務の標準化。
加工工程の段取り時間短縮。
品質記録の管理方法改善。
在庫管理表の整備。
新しい業務システムの導入。
これらは、日々繰り返す通常業務とは異なり、何らかの変化を実現するための取り組みです。
例えば、毎日見積書を作成することは通常業務です。
一方、見積書を作成する仕組みそのものを改善することは、プロジェクトとして管理できる場合があります。
ただし、すべての改善について、大がかりな管理体制が必要なわけではありません。
一人で短時間に実施できる改善なら、簡単な記録で十分な場合もあります。
重要なのは、仕事の規模に合った方法で管理することです。
プロジェクト管理の目的は、管理表を増やすことではありません。必要な作業を、必要な順番で進め、実際の成果へつなげることです。
実践プロンプト①
「製造会社で見積業務の改善を行います。通常の見積業務と、見積の仕組みを改善するプロジェクトの違いを整理してください。目的、期間、成果物、担当する役割、完了条件を考えてください」
2.最初に「何を完成させるのか」を決める
例えば、
「見積業務を改善する」
という目標があったとします。
しかし、この言葉だけでは、どの状態になれば完了なのか分かりません。
見積提出までの時間を短くするのでしょうか。
見積内容の確認漏れを減らすのでしょうか。
担当者によって異なる作業方法を統一するのでしょうか。
そこで、改善目的を具体化します。
例えば、
「見積提出までの平均日数を6日から5日以内に短縮する」
という目標です。
さらに、どのような仕組みを作るのか考えます。
例えば、
受付時の確認項目を整理する。
見積作成の手順を明確にする。
必要な資料の保存方法を統一する。
改善後の実績を確認できるようにする。
こうしたことです。
ただし、これらは手段です。
最終的な目的は、見積業務をより適切に進められるようにすることです。
実践プロンプト②
「見積提出までの平均日数を6日から5日以内へ改善するプロジェクトを計画しています。目的、実施範囲、作成する成果物、品質上の確認事項、完了条件を整理してください」
3.実践例|見積業務改善プロジェクトを考える
ここからは、架空の製造会社で見積業務を改善する例を考えてみましょう。
今回のプロジェクトでは、見積提出までの時間短縮と、確認漏れの防止を目的にします。
説明用として、次の条件を設定します。
| 項目 | 内容 |
|---|---|
| プロジェクト名 | 見積業務改善 |
| 現状 | 見積提出まで平均6日 |
| 目標 | 平均5日以内 |
| 改善対象 | 受付から見積提出まで |
| 実施期間 | 8週間 |
| 成果物 | 受付チェック表、作業手順、進捗管理表 |
| 効果確認 | 見積日数、訂正件数、未提出案件の状況 |
※学習用の架空のプロジェクトです。
この条件では、8週間で改善を実施し、効果を確認する計画です。
しかし、8週間という期間を設定しただけでは、具体的な仕事は進みません。
そこで、実施する内容を作業へ分解する必要があります。
4.WBSとは何でしょうか?
プロジェクト管理では、WBSという考え方があります。
WBSは、Work Breakdown Structureの略です。
プロジェクト全体の仕事を、管理しやすい作業や成果物の単位へ分解するための方法です。
例えば、「見積業務を改善する」という大きな仕事を考えます。
それを、次のように分けます。
現状調査。
問題の分析。
改善方法の設計。
試験運用。
効果確認。
正式運用。
こうした作業です。
さらに、現状調査を細かく分解することもできます。
例えば、
過去の見積案件を集める。
見積提出までの日数を計算する。
時間がかかった工程を確認する。
未提出案件の状況を調べる。
こうした内容です。
ただし、作業を細かく分けすぎると、管理の負担が大きくなる場合があります。
そこで、進捗や完了を確認できる程度へ分解することが重要です。
実践プロンプト③
「8週間で見積業務を改善するプロジェクトを計画しています。現状調査、原因分析、改善設計、試験運用、効果確認、正式運用という段階に分け、WBSを作成してください。それぞれの作業について、成果物と完了条件も整理してください」
5.具体的な作業へ分解する
今回のプロジェクトについて、次のような作業を設定してみましょう。
| ID | 作業 | 成果物 |
|---|---|---|
| T01 | 過去の見積案件を集計 | 現状データ |
| T02 | 作業工程と所要時間を分析 | 原因分析表 |
| T03 | 受付チェック表を作成 | チェック表案 |
| T04 | 技術確認・見積作成手順を整理 | 作業手順案 |
| T05 | 新しい方法を試験運用 | 実施記録 |
| T06 | 改善前後の結果を比較 | 効果分析 |
| T07 | 必要な修正を行う | 修正版資料 |
| T08 | 正式運用の方法を決定 | 運用手順・担当 |
このように分解すれば、具体的に何をするのか分かりやすくなります。
ただし、作業の一覧を作っただけでは、十分ではありません。
例えば、原因分析が終わっていないのに、改善方法を正式に決めることは適切でしょうか。
そこで、次に作業の順番と依存関係を考える必要があります。
6.作業の順番が重要になる
例えば、見積業務を改善するために、新しい受付チェック表を作成するとします。
しかし、実際にどの情報が不足しているのか確認していなければ、必要のない項目を追加してしまう可能性があります。
そこで、最初に現状調査を行います。
次に、問題の原因を分析します。
その結果をもとに改善方法を考えます。
そして、試験運用によって効果を確認します。
このように、作業には順番があります。
<box border radius="lg" padding={3} gap={2}>
<text weight="medium">見積業務改善の基本的な進行例</text>
{#each ["現状調査","原因分析","改善方法の設計","試験運用","効果確認","修正・正式運用"] as item,i}
<box align="center" gap={1}>
<box background="surface-secondary" width="100%" radius="md" padding={2} align="center">
<text weight="medium" size="sm">{item}</text>
</box>
{#if i<5}
<icon name="arrow-down" size="sm" color="tertiary"/>
{/if}
</box>
{/each}
</box>
一方、同時に進められる作業もあります。
例えば、過去の見積案件を集計している間に、現在使用している帳票や手順を確認することは可能かもしれません。
そのため、必ずすべての作業を一列に並べる必要はありません。
作業の順番を考えることは、無駄な手戻りを減らすために重要です。
7.依存関係とは何でしょうか?
プロジェクトでは、ある作業が終わらなければ、次の作業を始められない場合があります。
これを作業の依存関係と呼びます。
例えば、
原因分析が終わってから、改善方法を確定する。
チェック表が完成してから、試験運用する。
試験運用が終わってから、実績を比較する。
といった関係です。
ただし、実際には、改善設計と試験運用を部分的に重ねる場合もあります。
そのため、どこまで完了すれば次の作業を始められるか考えることが重要です。
例えば、T05の試験運用は、T03とT04の必要な準備が終わってから開始するという条件です。
このように、作業ごとの開始条件を整理できます。
実践プロンプト④
「見積業務改善の作業T01〜T08について、どの作業が完了してから次の作業を進める必要があるか、依存関係を整理してください。同時に進められる作業と、先に完了が必要な作業を区別してください」
8.担当者と責任を明確にする
複数の人が関わるプロジェクトでは、役割分担が重要です。
例えば、今回の見積業務改善では、
営業担当者。
技術担当者。
材料調達担当者。
見積担当者。
責任者。
などが関係する場合があります。
しかし、実際の会社では、一人が複数の役割を兼任することもあります。
そのため、役職名にこだわる必要はありません。
重要なのは、誰が作業を進め、誰が内容を確認し、誰が最終判断をするのか分かることです。
例えば、次のような表を考えます。
| 作業 | 実施する役割 | 確認する役割 |
|---|---|---|
| 現状データ集計 | 見積担当 | 責任者 |
| 技術課題の整理 | 技術担当 | 見積担当 |
| チェック表作成 | 見積担当 | 技術担当 |
| 試験運用 | 対象業務の担当者 | 責任者 |
| 効果分析 | 集計担当 | 責任者 |
| 正式運用の判断 | 責任者 | 関係担当者と協議 |
※架空の役割分担です。
ただし、担当者を決めたからといって、すべての問題をその人だけの責任として扱うわけではありません。
必要な情報や権限、作業時間が確保されているか確認することが重要です。
9.RACIという役割整理の方法
プロジェクト管理では、RACIという役割分担の考え方があります。
RACIは、次の四つの役割を表します。
R:Responsible
作業を実施する人や役割。
A:Accountable
成果について最終的な説明責任を持つ人や役割。
C:Consulted
作業や判断について相談する相手。
I:Informed
結果や進捗の情報を共有する相手。
例えば、受付チェック表を作成する場合です。
見積担当者が作成します。
責任者が最終的に確認・承認します。
技術担当者へ内容を相談します。
関係する業務担当者へ結果を共有します。
このように整理できます。
ただし、小規模なプロジェクトでは、すべての役割を別々の人へ割り当てる必要はありません。
重要なのは、判断や連絡が曖昧にならないことです。
実践プロンプト⑤
「見積業務改善プロジェクトについて、RACIの考え方を使って役割分担を整理してください。作業を実施する人、最終責任を持つ人、相談する相手、情報共有する相手を区別し、少人数の会社でも使える簡潔な方法にしてください」
10.期限を決めるだけでは不十分
例えば、T05の試験運用について、
「6週目までに完了」
という期限を設定したとします。
しかし、試験運用に必要なチェック表が完成していなければ、予定どおりに開始できません。
また、試験対象となる見積案件が少なければ、十分な実績を集められない可能性もあります。
そのため、期限だけでなく、開始条件と完了条件を考える必要があります。
例えば、
開始条件
受付チェック表と作業手順案が完成している。
実施内容
対象案件へ新しい方法を適用する。
完了条件
対象案件の実施記録がそろい、効果確認に必要なデータを集計できる。
このように整理します。
期限は重要ですが、期限までに何が完成していなければならないのかを明確にすることが大切です。
11.8週間のスケジュールを作る
今回の架空のプロジェクトについて、8週間のスケジュールを考えてみましょう。
| 作業 | 予定期間 |
|---|---|
| T01 現状データ集計 | 第1週 |
| T02 原因分析 | 第2週 |
| T03 受付チェック表作成 | 第3週 |
| T04 作業手順案の整理 | 第3〜4週 |
| T05 試験運用 | 第5〜6週 |
| T06 効果分析 | 第7週 |
| T07 修正 | 第8週前半 |
| T08 正式運用判断 | 第8週後半 |
この計画では、第4週までに試験運用の準備を整える必要があります。
また、第6週までの実績を使って、第7週に効果を分析します。
その結果をもとに、第8週に正式運用を判断します。
ただし、対象案件が少ない場合には、2週間の試験運用では十分なデータを集められない可能性があります。
そのため、期間と検証条件を合わせて考える必要があります。
実践プロンプト⑥
「見積業務改善プロジェクトを8週間で進めたいです。T01〜T08について、作業期間、開始条件、完了条件、担当する役割を整理したスケジュールを作成してください。試験運用に必要なデータが集まらない場合の対応も考えてください」
12.ガントチャートとは何でしょうか?
ガントチャートとは、作業と期間を横棒などで表し、プロジェクトのスケジュールを見える化する方法です。
例えば、どの作業を何週目に行うのかを整理できます。
| 作業 | 1週 | 2週 | 3週 | 4週 | 5週 | 6週 | 7週 | 8週 |
|---|---|---|---|---|---|---|---|---|
| 現状調査 | ● | |||||||
| 原因分析 | ● | |||||||
| チェック表作成 | ● | |||||||
| 手順の整理 | ● | ● | ||||||
| 試験運用 | ● | ● | ||||||
| 効果分析 | ● | |||||||
| 修正・正式運用判断 | ● |
このように表示すれば、複数の作業の期間を把握しやすくなります。
ただし、ガントチャートは予定を示すだけではありません。
実績と比較することで、どの作業が遅れているのか確認できます。
また、作業同士の依存関係を合わせて管理することも重要です。
13.進捗率100%なら、本当に完成している?
例えば、受付チェック表の作成について、担当者から、
「進捗率100%です」
という報告があったとします。
それなら、完成したと判断してよいでしょうか。
確認が必要です。
例えば、チェック表のファイルは完成しているかもしれません。
しかし、技術担当者による確認が終わっていない可能性があります。
また、実際の見積案件で使えるか試していない場合もあるでしょう。
そこで、進捗率だけでなく、完了条件を確認する必要があります。
例えば、
チェック表案を作成した。
必要な関係者が確認した。
修正事項を反映した。
試験運用に使える状態になった。
こうした条件です。
進捗率が100%という報告と、必要な成果物が完成していることは、必ずしも同じではありません。
14.進捗状況をどう分類する?
プロジェクト管理では、進捗を「未着手」「進行中」「完了」などに分類する方法があります。
しかし、それだけでは問題が分かりにくい場合があります。
例えば、「進行中」の作業が、必要な資料の回答待ちで止まっているかもしれません。
そこで、次のような状態を区別します。
未着手
まだ作業を開始していない。
進行中
作業を進めている。
確認待ち
必要な確認や承認を待っている。
保留・停止
何らかの問題によって進められない。
完了
決めた完了条件を満たした。
このように分類すると、進行中の作業と、実際に止まっている作業を区別しやすくなります。
実践プロンプト⑦
「業務改善プロジェクトの進捗状態を管理したいです。未着手、進行中、確認待ち、保留・停止、完了を区別し、作業が止まっている理由を記録できる管理表を考えてください」
15.実践例|計画どおりに見えるのに遅れている
ここで、架空の進捗状況を考えてみましょう。
第4週の終了時点で、次のような報告がありました。
| 作業 | 予定 | 実際の状態 |
|---|---|---|
| T01 現状調査 | 完了 | 完了 |
| T02 原因分析 | 完了 | 完了 |
| T03 チェック表作成 | 完了 | 確認待ち |
| T04 手順の整理 | 完了 | 進行中 |
| T05 試験運用 | 第5週開始 | 未着手 |
一見すると、ほとんどの作業が進んでいるように見えます。
しかし、T03のチェック表は確認待ちです。
T04の作業手順も完成していません。
そして、T05の試験運用は、これらの準備が整わなければ始められません。
つまり、個々の作業がある程度進んでいても、プロジェクト全体としては遅延リスクがあります。
重要なのは、作業ごとの進捗率よりも、次の工程を開始できる状態かどうかです。
16.クリティカルパスという考え方
プロジェクト管理には、クリティカルパスという考え方があります。
クリティカルパスとは、作業の依存関係と所要期間から考えたとき、プロジェクト全体の完了時期を左右する重要な作業の経路です。
例えば、今回のプロジェクトでは、
現状調査。
原因分析。
改善設計。
試験運用。
効果確認。
正式運用判断。
という流れがあります。
この経路上の作業が遅れれば、全体の完了も遅れる可能性があります。
一方、ほかの作業と並行して進められ、多少遅れても全体の完了に影響しない作業もあるかもしれません。
ただし、実際にクリティカルパスを特定するには、各作業の期間と依存関係を確認する必要があります。
単に重要そうな作業を選ぶこととは異なります。
実践プロンプト⑧
「見積業務改善プロジェクトについて、各作業の所要期間と依存関係から、全体の完了時期へ影響する作業を特定したいです。クリティカルパスを求めるために必要な情報と、計算方法を整理してください」
17.遅延が見つかったら、どう対応する?
例えば、チェック表の確認が一週間遅れているとします。
この場合、担当者へ作業を急ぐよう伝えればよいのでしょうか。
まず、なぜ確認が止まっているのか調べる必要があります。
例えば、技術担当者の作業が集中しているのかもしれません。
チェック内容に判断が難しい項目がある可能性もあります。
また、必要な資料が不足している場合も考えられます。
そこで、遅延の原因を整理します。
作業量の問題
必要な時間が確保できていない。
情報の問題
判断に必要な資料が不足している。
技術的な問題
確認すべき内容が難しい。
判断の問題
承認や方針の決定が進んでいない。
こうした分類です。
そのうえで、必要な対応を検討します。
実践プロンプト⑨
「チェック表の確認が一週間遅れています。担当者の作業負荷、必要資料、技術的な問題、承認待ちなどに分けて、遅延原因を確認する項目を整理してください。原因に応じて、対応方法を検討してください」
18.課題管理表を作る
プロジェクトを進めていると、さまざまな問題が発生する場合があります。
例えば、
必要なデータが集まらない。
担当者の確認が遅れている。
チェック表の内容が複雑すぎる。
試験運用の対象案件が少ない。
改善前後の条件がそろわない。
こうしたことです。
そこで、問題を課題管理表へ整理する方法があります。
| 課題ID | 内容 | 影響 | 次の対応 |
|---|---|---|---|
| I01 | 技術確認が未完了 | 試験運用が始められない | 未確認項目を整理する |
| I02 | 対象案件が少ない | 効果を評価しにくい | 検証期間を検討する |
| I03 | 入力項目が多い | 作業負担が増える | 必要項目を見直す |
このように整理すれば、何が問題になっているのか確認できます。
さらに、担当する役割、確認期限、現在の状態などを追加する方法もあります。
ただし、課題を記録するだけで解決するわけではありません。
次に誰が何を確認するのか、明確にすることが重要です。
19.リスクと課題を区別する
ここで、少し重要な違いを学びましょう。
例えば、
「試験運用の対象案件が集まらないかもしれない」
という心配があったとします。
これは、まだ発生していない将来の可能性です。
このようなものを、リスクとして管理する場合があります。
一方、
「試験運用を始めたが、対象案件が少なく、必要なデータが集まっていない」
という状態です。
こちらは、すでに発生している問題です。
課題として管理することが考えられます。
このように、将来発生する可能性と、現在発生している問題を区別します。
リスクは、起こる前に備えるもの。課題は、起きていることに対応するものです。
実践プロンプト⑩
「業務改善プロジェクトについて、将来発生する可能性があるリスクと、すでに発生している課題を区別したいです。それぞれの記録項目と対応方法を整理してください」
20.優先順位をどう決める?
プロジェクトを進めていると、複数の課題が同時に見つかる場合があります。
例えば、
チェック表の確認が遅れている。
管理表の表示が分かりにくい。
資料の保存場所が統一されていない。
試験運用の対象案件が不足している。
こうした問題です。
これらを、すべて同じ優先順位で対応する必要があるでしょうか。
例えば、チェック表の確認が終わらなければ試験運用を開始できない場合です。
その課題は、プロジェクト全体の完了へ直接影響する可能性があります。
一方、管理表の表示改善は、試験運用と並行して進められるかもしれません。
そこで、次の観点から優先順位を考えます。
全体日程への影響。
品質や安全性への影響。
ほかの作業との依存関係。
対応に必要な時間。
代替方法の有無。
こうした項目です。
ただし、重大な品質・安全上の問題は、単純な作業効率だけで優先順位を決めるべきではありません。
21.進捗会議では何を確認する?
プロジェクト管理では、定期的に進捗を確認することがあります。
しかし、会議で各担当者が、
「進んでいます」
と報告するだけでは、問題が見つからない場合があります。
そこで、次のことを確認します。
前回から何が完了したか。
今週、何を完了させる予定か。
作業が止まっているものはないか。
必要な確認や判断は何か。
期限へ影響する問題はあるか。
こうした項目です。
また、会議で決めた内容について、誰が何をするのか記録することが重要です。
例えば、
「技術確認を行う」
ではなく、
「チェック表の未確認項目を整理し、担当者が次回会議までに確認結果を報告する」
というように具体化します。
実践プロンプト⑪
「業務改善プロジェクトの週次進捗会議を行いたいです。完了した作業、今週の予定、遅延、課題、必要な判断、次の行動を短時間で確認できる会議資料の構成を考えてください」
22.ChatGPTで週次進捗レポートを作る
例えば、次のような情報があったとします。
T01とT02は完了。
T03は技術確認待ち。
T04は作業中。
T05は第5週開始予定。
この情報をChatGPTへ伝えます。
すると、次のような報告書に整理できます。
今週完了したこと
現状調査と原因分析。
現在進行中のこと
チェック表の確認と作業手順の整理。
遅延リスク
チェック表の確認が終わらなければ、試験運用を開始できない。
必要な対応
未確認項目を明確にし、確認できる担当と期限を設定する。
このように、進捗情報を整理することができます。
ただし、ChatGPTが実際の担当者の作業状況を自動的に把握しているわけではありません。
報告内容は、実際の記録や担当者からの情報に基づく必要があります。
実践プロンプト⑫
「次の進捗情報をもとに、週次プロジェクト報告書を作成してください。T01・T02は完了、T03は技術確認待ち、T04は作業中、T05は第5週開始予定です。完了事項、進行中の作業、遅延リスク、必要な判断、次の行動を整理してください」
23.変更が発生した場合はどうする?
プロジェクトでは、途中で条件が変わる場合があります。
例えば、見積受付チェック表の改善を進めている途中で、新しい見積システムの導入が決まったとします。
この場合、計画を変更する必要があるかもしれません。
しかし、変更をそのまま追加していくと、作業が増え続ける可能性があります。
そこで、変更の内容を整理します。
何が変わるのか。
なぜ変更するのか。
追加の作業は必要か。
スケジュールへ影響するか。
費用や人員へ影響するか。
既存の成果物を変更する必要があるか。
こうしたことです。
そのうえで、変更を採用するか判断します。
実践プロンプト⑬
「見積業務改善プロジェクトの途中で、新しいシステム導入が決まりました。既存の作業計画、成果物、担当、期限、費用への影響を整理し、変更を承認する前に確認する項目を考えてください」
24.プロジェクトの完了をどう判断する?
例えば、8週間の改善プロジェクトが終了したとします。
受付チェック表も完成しました。
作業手順も整理しました。
それなら、プロジェクトは成功したと判断してよいでしょうか。
まだ確認が必要です。
例えば、次のようなことです。
チェック表は実際の仕事で使えるか。
担当者へ共有されているか。
見積提出までの時間は改善したか。
見積訂正件数が増えていないか。
問題が発生したときの対応方法は決まっているか。
こうしたことです。
つまり、成果物が完成したことと、改善効果が確認されたことは異なります。
そこで、プロジェクトの完了条件を、事前に設定する必要があります。
例えば、
必要な資料が完成した。
試験運用が完了した。
結果を評価した。
正式運用の判断を行った。
担当者への引き継ぎが完了した。
こうした条件です。
ただし、効果を評価するには、正式運用後も一定期間の確認が必要になる場合があります。
その場合、プロジェクト終了と、改善効果の継続確認を分けて管理する方法があります。
25.改善効果を確認する
今回のプロジェクトでは、見積提出までの平均日数を短縮することが目的でした。
例えば、次のような結果だったとします。
改善前は平均6.0日。
改善後は平均4.5日。
見積訂正件数は、増加していません。
この場合、平均日数は1.5日短縮しています。
短縮率は、
1.5÷6.0×100=25%。
です。
ただし、この数字だけで、すべての効果を判断できるとは限りません。
例えば、改善後の案件が簡単なものに偏っていた可能性があります。
また、一部の難しい案件では、依然として提出まで時間がかかっているかもしれません。
そこで、改善前後の条件や、未提出案件の状況も確認する必要があります。
実践プロンプト⑭
「見積業務改善プロジェクトの結果、平均提出日数が6.0日から4.5日へ短縮しました。短縮率を計算し、案件難易度、未提出案件、見積訂正件数なども考慮して、改善効果を評価する方法を整理してください」
26.成果を通常業務へ引き継ぐ
プロジェクトが完了した後、改善した方法を誰が管理するのでしょうか。
例えば、新しい見積受付チェック表を正式運用する場合です。
チェック表の保存場所。
更新する担当。
使い方の説明。
不具合が見つかった場合の連絡先。
変更履歴の管理。
こうしたことを決める必要があります。
また、チェック表を使わなくなってしまえば、改善効果が維持できない可能性があります。
そこで、一定期間後に実際の運用状況を確認する方法があります。
例えば、正式運用から一か月後に、使用状況と見積提出までの時間を確認します。
このように、プロジェクトの成果を通常業務へ引き継ぐことが重要です。
27.Excelでプロジェクト管理表を作る
業務改善プロジェクトは、Excelでも管理できます。
例えば、次のような項目です。
| 項目 | 内容 |
|---|---|
| 作業ID | 一意の管理番号 |
| 作業名 | 実施する作業 |
| 担当 | 実施する役割 |
| 開始予定日 | 作業を始める予定 |
| 完了予定日 | 作業を終える予定 |
| 実際の開始日 | 実際に着手した日 |
| 実際の完了日 | 完了した日 |
| 状態 | 未着手・進行中・確認待ちなど |
| 先行作業 | 開始に必要な作業 |
| 完了条件 | 作業を完了と判断する条件 |
| 課題 | 現在の問題 |
| 次の行動 | 次に実施すること |
こうした管理表を使えば、作業の状態を整理できます。
また、期限が近づいている作業や、予定日を過ぎた作業を確認することもできます。
ただし、表を細かくしすぎると、更新に時間がかかる場合があります。
そのため、仕事の規模に合わせた構成を考える必要があります。
実践プロンプト⑮
「業務改善プロジェクトをExcelで管理したいです。作業ID、作業名、担当、開始日、期限、状態、依存関係、完了条件、課題、次の行動を管理できる表を設計してください。遅延や確認待ちを見つけやすくする方法も考えてください」
28.プロジェクト管理を複雑にしすぎない
プロジェクト管理には、さまざまな方法があります。
WBS。
ガントチャート。
RACI。
クリティカルパス。
課題管理表。
リスク管理表。
こうしたものです。
しかし、すべての道具を使う必要はありません。
例えば、数日で完了する小さな改善なら、作業一覧と担当、期限、完了条件があれば十分な場合があります。
一方、複数の担当者や設備が関係し、数か月かかるプロジェクトでは、依存関係や進捗、リスクを詳しく管理する必要があるかもしれません。
重要なのは、管理方法を増やすことではありません。
仕事を進めるために必要な情報を、適切な形で整理することです。
29.今日の実践課題|8週間の改善プロジェクトを管理しよう
今回は、ChatGPTを使って、見積業務改善プロジェクトを設計する練習をしましょう。
ステップ① プロジェクトの目的を整理する
ChatGPTに次のように質問します。
「見積提出までの平均日数を6日から5日以内へ短縮する、8週間の業務改善プロジェクトを計画してください」
ステップ② 成果物を決める
「受付チェック表、作業手順、進捗管理表、効果分析資料について、完成条件を整理してください」
ステップ③ WBSを作成する
「現状調査、原因分析、改善設計、試験運用、効果確認、正式運用へ作業を分解してください」
ステップ④ 作業の依存関係を整理する
「どの作業が終わらなければ次へ進めないか、同時に進められる作業は何かを整理してください」
ステップ⑤ 役割分担を考える
「営業、技術、材料調達、見積、責任者の役割を整理してください」
ステップ⑥ スケジュールを作る
「8週間の作業期間を設定し、各週の予定と完了条件を表にしてください」
ステップ⑦ ガントチャートを作る
「各作業の予定期間を、週単位のガントチャートへ整理してください」
ステップ⑧ 進捗を管理する
「未着手、進行中、確認待ち、保留・停止、完了を区別した進捗管理表を考えてください」
ステップ⑨ 遅延の影響を分析する
「第4週終了時点で、チェック表が確認待ち、手順案が作業中です。第5週開始予定の試験運用へどのような影響があるか整理してください」
ステップ⑩ 課題管理表を作る
「遅延、情報不足、技術検討、試験対象案件の不足について、課題ID、影響、次の対応、担当、期限を管理する表を考えてください」
ステップ⑪ 効果を確認する
「改善前の平均提出日数6.0日、改善後4.5日です。短縮日数と短縮率を計算し、品質への影響も確認する方法を考えてください」
ステップ⑫ プロジェクトの完了を判断する
「成果物の完成、試験運用、効果分析、正式運用判断、引き継ぎを含む完了条件を整理してください」
ステップ⑬ 最終報告書へまとめる
「プロジェクトの目的、作業計画、進捗、課題、効果、未確認事項、正式運用への引き継ぎをまとめた最終報告書を作成してください」
この練習では、管理表を完成させることだけを目的にしないでください。
必要な作業を明確にし、問題が見つかったときに早めに対応できる状態を作ることが目的です。
30.ChatGPTでプロジェクトを管理するときの注意点
ChatGPTは、作業分解、スケジュール作成、役割分担、進捗分析、課題整理、報告書作成などを支援できます。
しかし、実際の担当者が作業を完了したかどうかを、記録なしで把握することはできません。
また、予定された作業の進捗率だけで、成果物の完成を判断することも適切ではありません。
そのため、実際の作業記録や完成物を確認する必要があります。
さらに、作業の依存関係や必要期間を正しく設定しなければ、全体のスケジュールが実態と合わなくなる場合があります。
また、プロジェクトを予定どおりに終わらせることだけを目的にすると、品質や改善効果の確認が不十分になる可能性があります。
そこで、日程、成果物、品質、改善効果を組み合わせて考える必要があります。
AIは、プロジェクトの情報を整理し、判断に必要な材料を作るための道具です。
実際の作業を進め、状況を確認し、必要な判断を行うことが重要です。
31.プロジェクト管理の本当の目的は何でしょうか?
最後に、プロジェクト管理について考えてみましょう。
仕事を改善するとき、さまざまな人や工程が関係する場合があります。
一人が作業を終えても、別の確認が終わっていなければ、次へ進めない場合があります。
また、すべての担当者が忙しく働いていても、必要な判断が止まっていれば、プロジェクト全体は進まないかもしれません。
そこで、全体の流れを理解することが重要です。
何を完成させるのか。
そのために、どのような作業が必要なのか。
どの順番で進めるのか。
誰が実施し、誰が確認するのか。
いつまでに完了させるのか。
そして、予定と違うことが起きた場合、何を判断するのか。
こうした情報を整理することで、改善活動を進めやすくなります。
また、問題が起きたときに、担当者を責めるのではなく、何が作業を止めているのかを確認することも重要です。
プロジェクト管理は、人を監視するためのものではありません。
複数の仕事をつなげ、必要な判断を行い、目標を実現するためのものです。
まとめ|作業の進捗ではなく、成果へ向かう流れを管理する
今回は、ChatGPTを使って業務改善プロジェクトを管理する方法を学びました。
重要なポイントは、次のとおりです。
- プロジェクトの目的と完了条件を明確にする。
- 通常業務と、改善のための取り組みを区別する。
- WBSを使って、仕事を管理しやすい作業へ分解する。
- 各作業の成果物と完了条件を設定する。
- 作業の順番と依存関係を整理する。
- 誰が実施し、誰が確認・判断するか明確にする。
- RACIなどを活用して、役割分担を整理する。
- スケジュールを作り、期限だけでなく開始条件も確認する。
- ガントチャートなどで、作業期間を見える化する。
- 進捗率だけでなく、実際の完成状況を確認する。
- 確認待ちや停止している作業を区別する。
- クリティカルパスの考え方から、全体日程へ影響する作業を理解する。
- 遅延が見つかった場合は、原因を確認する。
- リスクと課題を区別して管理する。
- 進捗会議では、必要な判断と次の行動を明確にする。
- プロジェクト途中の変更が与える影響を確認する。
- 成果物の完成と、改善効果の確認を区別する。
- 改善した方法を通常業務へ引き継ぐ。
- Excelなどを使って、無理のない管理の仕組みを作る。
業務改善のプロジェクトでは、計画を立てることが重要です。
しかし、計画を作っただけでは、仕事は進みません。
作業を具体的に分解する。
必要な順番を考える。
担当する役割を決める。
進捗を確認する。
問題が見つかったら、早めに対応する。
そして、実際に成果が得られたか確認する。
こうした流れが必要です。
ChatGPTは、作業の整理やスケジュール作成、課題の分析、報告書の作成などを手伝うことができます。
しかし、実際に何が進んでいて、何が止まっているかは、現場の情報を確認する必要があります。
プロジェクト管理で大切なのは、すべての作業を計画どおりに進めることだけではありません。必要な仕事をつなげ、問題を早めに見つけ、実際の成果へ向かって進められる状態を作ることです。
AIと一緒に全体を整理し、必要な作業へ分解し、一つずつ実行する。
そして、進捗と結果を確認しながら、必要な修正を行う。
その積み重ねが、中級編で身につけていきたい実践的なAI活用です。
次回【中級編・第57回】
「ChatGPTでリスク管理を行う方法|問題が起こる前に備えるためのリスク分析と対応計画の実践講座」
次回は、業務改善や新規事業、日々の製造業務で発生する可能性があるリスクについて考えます。
品質不良。
納期遅延。
設備故障。
材料調達の問題。
人員不足。
情報管理上の問題。
こうした出来事について、発生する可能性と影響を整理し、事前にどのような準備ができるか検討します。
ChatGPTを使って、リスクの洗い出しから対応計画、発生時の行動までを具体的に整理する方法を学んでいきましょう。