初心者PMにも優しい！ガントチャートの書き方をワークショップで学ぼう_準備編
この記事について
フリーランスPMとしてIT系システム案件を担当してきた経験を活かし、
現場で使えるガントチャート作成方法についてご紹介します。
これからPMになる人でも使いこなせるように、
なるべくシンプルな方法をご紹介したいと思います。
また、ガントチャートにも色々な流派がありますので、
あくまで一例として参考にしていただければ嬉しいです。
ガントチャートってなに？
よくあるのは下図のようなものです。
あるプロジェクトが完了するまでの全てのタスクを洗い出し、
各タスクをいつ誰が行うかを可視化したスケジュール表になります。
上図はサンプルなので案件完了までのスケジュールを書いていないですが。。。
ただ、上図のガントチャートは記載内容も多く、
初心者にはちょっとツライですよね。
そこで、この記事でご紹介するガントチャート
はもっとシンプルにします。
これなら書けそうな気がしませんか？？
もしそう思っていただけたなら、続きをお読みいただけると嬉しいです。
ガントチャートを作るメリットは？
①スケジュールが可視化されることで、計画の不足点に気がつけます
ガントチャートを作成していく中で、おのずと下記が明確になります。
・そのプロジェクトを完了させるために必要な全てのタスク
・各タスクを完了させるために必要な日数
・各タスクの優先順位
・全てのタスクが完了する日付
上記を明確化していく中で
必要なタスクが漏れていることに気がついたり、
プロジェクトの納期までに完了させるには時間が足りないと気づいたり、
様々な気づきがあるはずです。
これらの計画の不足点に気が付けないと
プロジェクト着手後になってから問題になる場合が多いので、
早めに気がつけることは大きなメリットではないでしょうか。
②プロジェクトが計画通りに進んでいないことに気がつけます
プロジェクトを進めていくと
驚くほど色々なトラブルが発生するもので、
最初に作成したガントチャートの通りに進むことは殆どありません。
ただ、ガントチャートがあれば
どのタスクに問題があり、計画と比べてどのくらい遅延しているか、
また、その遅延が後続のスケジュールにどう影響するかなど、
確認がしやすくなります。
トラブルが発生したら、
ガントチャートが無くても問題に気がつけるのでは？
と思われると思いますが、意外と気が付けないものです。。。
プロジェクトの遅延原因でよくあるパターンとして
日々で小さい問題が発生し、対応に追われる中で
少しずつ遅延が積み重なって、気づけば納期に間に合わない。。。
というケースがありますので、
ガントチャートを使って日々スケジュール遅延をチェックして
致命的な問題になる前に対応を行えることはメリットとなります。
③どのタスクを誰に任せるかを考えやすい
ITプロジェクトのチームには
複数人のタスク担当者(プログラマー等) がいる場合が多く、
複数のタスクが同時期に進んでいくことになります。
また、タスクには前後関係があり
あるタスクが完了していないと、着手出来ないタスクもあります。
そのため、やみくもにタスクを割り振ってしまうと
進められるタスクが無くなってしまったり、
あるメンバーが担当できるタスクが枯渇してしまったり、
お客様が希望した優先度でタスクが完了しなかったりと、
様々な問題を引き起こします。
ガントチャートを用いて
タスクとスケジュールを可視化しておけば、
今、誰にどのタスクを任せるべきかを考えやすくなります
ガントチャートをどうやって学ぶの？
今回はワークショップ形式で学ぶ方法をご紹介します！
ガントチャートに限ったことではないのですが、
多くの仕事には様々な解決方法がありますので、
人それぞれの考え方や得意不得意などの特性に合わせて
自分の特性に合った解決方法を探して仕事をこなしています。
そのため、先生から正解を教わる学習方法(ティーチング) ですと
その先生の特性に合った解決方法しか教われないので、
よほど先生と特性が合わない限り、学んだことはそのまま使用できません。
ワークショップ形式で学習していただき、
自分で考えて試行錯誤をしていく中で
自分なりの解決方法を探してもらいたいと思い、
ワークショップ形式にいたしました。
ワークショップを始める準備
1. 教材を準備する
先ず、ワークショップに使うガントチャートフォーマットを用意します。
私が作成したサンプルを置いておきますので、良かったら使ってください。
2. プロジェクト名を決める
次に、ガントチャートの作成対象となるプロジェクト名を考えます。
サンプルでは「ファシリテーターが喜ぶカレーを、夕飯に提供する」
という名前に設定しました。
システム開発等の専門知識が無くても
カレーの作り方でしたら、家庭科の授業などで習ったことがあるかな…
と考えたことと、単純にカレーが好きなので選びました(笑)
また、もし他のプロジェクト名にされる場合は
「ファシリテーターが…」という部分は残すようにしてください。
プロジェクトの成果物の納品先をファシリテーターに設定しておく方が、
作成されたガントチャートをレビューする時に
不足点などの確認がしやすくなると思います。
3. 参加者を集める
ワークショップの内容的に
ファシリテーター・学習者のポジションが必要になります。
【ファシリテーター】
学習者のサポート役となりまして、
ワークショップを始める時のルール説明や質問回答、
レビュー依頼を受け、アドバイスを行う役割となりますので、
可能であればガントチャート作成経験のある人が望ましいです。
また、プロジェクトのオーナーの役割も持っており、
期待される納品物を決めたり、急な要求変更をしたりと
色々な権限を持っております。。
上記の権限をワークショップでどのように活かすかは
今後の記事でご紹介させていただく予定です。
【学習者】
ガントチャートの作成方法を学ぶ人であり、
自分なりに考えながら、ガントチャートを作成する人です。
特に必要なスキルは有りませんが、
ワークショップを楽しむ心があると良いかもしれませんね。
また、参加者の基本人数は
ファシリテーター1名、学習者1名の計2名ですが、
3名以上になっても大丈夫です。
逆に、1人でワークショップを行いたい場合もあると思います。
どの人数でもワークショップに取り組んでいただけるよう
この後にやり方を記載させていただければ幸いです。
ワークショップを始める
1. 役割を決める
先ずはワークショップ参加者に
ファシリテーターと学習者に分かれてもらいましょう。
基本はファシリテーター1名、学習者1名での
1on1形式が最も行いやすいですが、
参加人数に応じてバランスが変わっても大丈夫です。
例えば3名以上の場合は学習者を複数人にして、
学習者同士で相談をしながら1つのガントチャートを
作成するのも面白いです。
ファシリテーターは
ワークショップの進行管理と、
学習者からの質問回答で結構忙しくなりますので、
上記役割を2名で分担するのも良いかもしれません。
1人の場合は学習者になっていただき、
ガントチャートを完成させたらファシリテータにジョブチェンジしてもらい
自分の作ったガントチャートを客観的に評価してみてください。
今後の記事にて
ファシリテーター目線でのレビュー例を書いていきますので
そちらも参考にしていただければ嬉しいです。
2. ワークショップのルールを説明する
サンプルでは下記のようにルール設定しています。
a. ファシリテーターへの質問は自由
ガントチャートの作成経験がある人ならお気づきかもしれませんが、
このプロジェクトはタイトルしか決まっておらず、
納期・納品物・使えるリソースなど、全てが未設定です。
実際のシステム開発案件でも
ふわっとした状態でプロジェクトが始まることが多いので
そこを明確にするために、適切な質問を行うことも
本ワークショップの学習ポイントになります。
学習者が優秀なほどファシリテーターは質問攻めにされますので
覚悟して挑んでください(笑)
b. ファシリテーターはレビューの時しか助言しない
学習者がガントチャート初心者の場合、
最初から完全なものは作成できないと思いますので、
完成させるためには、経験者の助けが必要になるはずです。
しかし、実際のプロジェクトでは
経験者となる先輩社員もとても忙しく、
ただ待っているだけでは何も教えてくれない場合もあります。
そのため、このワークショップでは
あえてレビューの依頼方法・タイミングについて決めておらず、
「レビュー時しか助言がもらえない」ことのみをルールに記載しています。
ファシリテーターの人はついアドバイスしたくなると思いますが
ぐっと我慢していただき、学習者がどのようにファシリテーターを
活用できるか見守ってみてください。
また、レビュー依頼を受けてアドバイスをする時は
できれば直接的に改善ポイントを教えるのではなく、
問題点の伝えて、解決方法を学習者に考えてもらうようにしてください。
また、ワークショップ終了時間まで
1度もレビュー依頼をしてこないと、学びが少なくなってしまいますので、
状況に応じて助け舟を出しても良いかもしれません。
c. 上手く作れなくてもOK
前述した2つのルールからも感じていただけたと思いますが、
このワークショップは、学習者とファシリテーターの
コミュニケーションが重要になります。
多くの場合は
ファシリテーターは先輩や上司、
学習者は後輩や若手社員になると思いますので、
立場の差からコミュニケーションにハードルがある場合が多いでしょう。
「上手く作れなくてOK」というルールは
そのハードルを少し下げるための工夫として記載しましたが、
それだけでは不十分かもしれません。
必要に応じてアイスブレイク等も取り入れていただき、
学習者が積極的に発言できる状態にすることが
ファシリテーターの腕の見せ所となります。
3. ガントチャートを書き始める
いよいよガントチャートを学習者に書いてもらいましょう。
学習者が初心者の場合は
そもそもフォーマットの使い方が分からないと思いますので、
タスクの洗い出し方や、スケジュール線の書き方等、
基本的なところはファシリテーターから教えてあげてください。
また、学習者の性格によっては
黙々と書き始めてしまう場合もあると思いますが、
それがその人にとってベストな方法である可能性もありますので、
しばらくはそっと見守っていきましょう。
また、ワークショップに時間制限がある場合
ファシリテーターの方でタイムマネジメントもしてあげると良いでしょう。
4. レビューを行う
学習者がルールの意図に気がつければ
ファシリテーターにレビュー依頼が来るはずです。
前述させていただきましたが、
可能であれば、問題点のみを伝えて
解決方法は学習者に考えてもらうようにしてください。
もし学習者が行き詰まってしまうようでしたら
答えを教えるのではなく、一緒に考えてあげるのが良いかもしれません。
5. ガントチャートを修正する
ファシリテーターからの助言をもとに
学習者はガントチャートを修正します。
修正が完了したら、再度レビュー依頼に出してみましょう。
このレビュー・修正サイクルが
ワークショップ中に何周行われるかは
学習者の性格や、制限時間にもよると思いますが、
可能であれば2周以上行っていただけたら嬉しいです。
レビューを繰り返すことで
ガントチャートがどんどん良くなっていくことを実感していただき
レビューに対してポジティブな印象を受けてもらえたら幸いです。
若手を見ていると
「レビュー = 答え合わせ」という感覚が強いのか、
レビュー時に指摘を受けると、まるで試験に落ちたかのような
ネガティブな反応をされる人が多いように思います。
指摘を受けることは…良くない場合もありますが、
過度に恐れすぎては成長の妨げにもなりますので
指摘をアドバイスと捉えて成長につなげる感覚も
得ていただけたら嬉しいです。
6. ワークショップを終える
ワークショップの終了条件の指定はありませんので、
制限時間の終了、ファシリテーターのOKを貰う等々
自由に設定していただいて大丈夫です。
また、終了後に振り返りの時間を設けて
ワークショップを通してどのような学びがあったのか、
全員で話し合ってみるのも面白いかもしれません。
学習者だけでなく、ファシリテーターにも学びがあると思いますので
学習者と一緒に振り返ってみても面白いかもしれません。
最後に
本記事はここで終わりとなりますが、
今後の記事にて、ファシリテーターのレビュー時の
アドバイス例について書いていきたいと考えています。
こういった記事を書くのはあまり得意ではありませんので
ゆっくりした更新ペースになると思いますが、
もし新しい記事を見かけたら、お読みいただけたら嬉しいです。
本記事の注意事項
・ガントチャートフォーマットはスプレッドシートで作成しましたが、
実際のプロジェクトではbacklog等のツールを用いて
ガントチャートを作成することが多いと思います。
ただ、有料ツールになりますので、
だれでもワークショップに取り組めるように
今回はスプレッドシートを使用いたしました。
・また、チケット管理ツールとガントチャートを連動させて、
各タスクの詳細をチケットに記載することも多いですが、
このワークショップではチケット作成については割愛しています。
(いつか余裕があれば別記事にてご紹介しようと思います。)
・私は5名前後のチームをマネジメントすることが多いので、
もしかすると大規模プロジェクトを担当されている方には
学習内容として不足があるかもしれません。
あくまで参考としてお読みください。
この記事が気に入ったらサポートをしてみませんか？