世の中には、プロジェクト管理に関する様々な方法論が紹介されていますが、ここで取り上げるのは、その中でも最もシンプルで、必須の要素のみを含んでいます。
内容は非常に簡単ですので。まずこの原則だけはしっかり理解してご自分の業務に当てはめてみてください。
目次
プロジェクトの状態遷移
プロジェクトは目標を達成するための、作業や管理をセットにしたもです。
まずは、プロジェクトの開始から終了までの大まかな流れをイメージしてみました。
それぞれの構成要素を確認しましょう。
【目標設定】
プロジェクトを始める際、まず最初に、そのプロジェクトが何を達成するためのものであるのか、達成すべき目標を設定しします。
【計画】
次に、どのような状況に達すれば目標達成と言えるのか、要件を定義します。その上で、その要件を満たすための必要な作業や課題、生産物等を一通りリストアップします。
実施する作業や生産物が洗い出したら、スケジュール、見積もり、メリット・デメリットなどを抽出し、プロジェクトを実施するのか判断に足る情報を提供します。
プロジェクトの実施判断を行った時点で、このプロジェクトの完了にメドが立っている状況になります。
【作業の実施】
実施する作業が決まったら、各作業に作業順序と、実施担当者、実施期限などを割り振り、一つ一つの作業を順に実施していきます。
プロジェクトを運営している期間中、作業の進み具合や、生産物のチェックなどを適宜行い、プロジェクト完了期限に、所定の生産物や作業結果などがきちんと達成されるよう、
プロジェクトの健康状態を維持していきます。
その過程で、ブロッカーやトラブルは、プロジェクト全体の期間や予算に影響を出さないよう、早め早めに対策を打っておきましょう。
【目標の達成】
最初に決めた要件を全て満たした時点で、プロジェクトの目標達成です。
プロジェクトを管理するためには、達成度を数値化する必要があります。そのためには、最小単位の完成を積み上げたら、プロジェクト全体の完了になるようにきちんと作業を洗い出しておく必要があります。
理論的には、作業を全て完了した時点で、プロジェクトは完了になるはずです。
では、次に、このプロジェクトの完了までの状態フローを実際の人間の活動にマッチさせる方法について考えていきましょう。
プロジェクトを運用するため基本的なルーチン
人間は、基本的に同時に1つのことしかできません。また、作業の内容を考えながら実施することも、不可能とまでは言いませんが、結果の質や、作業効率の点から考えると決していいこととは言えません。
ホテルなどで、最初に避難経路を確認させるのもそのためです。実際に避難する際、避難経路を探しながら逃げた場合、思考力・判断力はほとんどゼロになる一方、記憶力は70%程度維持されるそうです。
ですから、ある大きさな作業の塊を、品質を維持しながら上手くさばいていくためには、
事前に作業内容や順序を明確にし、その内容を理解した状態で、集中して作業を行うことが望ましいと言えます。
-
要件と完了条件を明確にし、資材を調達し、集中して作業行える状態にする (準備)
↓ -
予定した作業を集中して実施し、作業結果が要件を満たしていることを確認する(作業の実施)
↓ - 作業の記録、評価、報告を行う (管理)
といった流れです。
ただし、「実施」中にある「作業結果が要件を満たしていることを確認する」の部分を作業の実施と見るかは判断のわかれるところです。
この問題は、受験に例えると分かりやすいでしょう。
例えば、自宅で行う過去問の回答であれば、
- テスト解答 ⇒ 丸付け ⇒ 不正解箇所の復習
までが作業の実施、
- 記録 ⇒ 得点推移の振り返り ⇒ 不正解箇所の分析 ⇒ 今後の対策検討
などが、管理と部類出来るでしょう。
一方、受験本番であれば、
- テスト解答
だけが「作業の実施」で、
- 受付 ⇒ テストの配布・回収 ⇒ 採点 ⇒ 集計⇒ 受験生個別事情の調整(減点・加点) ⇒ 評価 ⇒ 合否判定
は「管理」と分類できます。
作業の評価を作業の一種とみるか、管理とみるかについては、契約や、成果物に原価性があるかどうかにも依存しますので、
チームや会社できちんとした基準を決めましょう。
ここで、基本的なフローを図にしてみましょう。非常に簡単です。
必ずこの順番で行うことが重要です。準備を十分に行わず、いきなり作業に入ってはいけません。
準備が不十分だとどうなるのか?
例えば、ランチミーティングにカレーライスをふるまうという小規模プロジェクトを仮定しましょう。
機材、材料は、全てあるものを使い、調理に40分を見込んでいたとします。
主催者は、通常業務を40分早く切り上げ、調理を開始します。時間のかかる作業から順に進めていきます。
ご飯を炊き、野菜を切り、肉を焼き、煮込み、15分煮たら、カレールーを入れて完成です。
しかし、カレールーを入れる段になって、ストックがないことに気付きます。
急遽、最寄りのスーパーへ200円のカレールーを買いに行き、調理を継続しました。
準備不足により、ロスが発生してしまいました。
買い出しに30分、材料を一旦しまったり、調理器具を洗いなおしたりと、追加の作業が発生します。
それだけではありません。開始遅延の周知を行ったり、参加者のリスケが必要になったりします。最悪、反省文と再発防止レポート、
次回以降のチェック体制の強化を課せられるかもしれません。
影響を受ける人が増えれば増えるほど、追加コストはいくらでも跳ね上がる可能性があります。
原因は、たった200円の材料のが1個足りなかったことです。前日にチェックさえしていれば。。。
準備・確認漏れによるロスは、得るもののない、全くの無駄であると同時に、逆に、きちんと排除できれば、丸ごと利益ですから、まず何よりも最初に排除しなければなりません。
話を戻します。
プロジェクトを進めていくにあたって、「準備」⇒「実施」⇒「管理」のセットが作業の実施には、重要であり、人間の活動にマッチしていることは、違和感なく理解いただけることと思います。
ここで大事なのは、「準備」⇒「実施」⇒「管理」のセットが、プロジェクト全体にも、プロジェクトの各工程にも、プロジェクトの1つ1つの作業にもそれぞれ同じく適用されなければならないという点です。
イラストを見て確認していきましょう。
作業ルーチンのプロジェクト全体への適用
【準備】
・要件のリストアップ
・制約条件のリストアップ
・作業工程の設定
・見積り作成
・発注計画
・生産物の内容決定
・ドキュメント類の内容検討
・テスト計画
・進捗記録・管理方法の決定
・管理ツール類の選定
・アサイン(人員配置)計画
・体制図・連絡体制の設定
・スケジュールの作成
・効果測定方法の検討
・メリット・デメリット比較
【作業実施】
【管理】
・トラブルの管理と調整
・追加要件や課題の把握と追加作業の割り振り
・アサイン(人員配置)と導入教育の実施
・進捗報告
上記でリストアップした通り、プロジェクトの正味の作業「作業実施」工程を中心として、どんな作業を行うのかを決める「計画」工程が先行し、「管理」が並行して「作業実施」を支える形となります。
「作業実施」の内容や規模、工程を問わず、このセットは変わりません。
特徴は、この場合の「準備」と「管理」での実施内容が、プロジェクト全体を対象としているという点です。
また、計画で重要なことは、プロジェクトの作業の内容が全て完全に明確になっていることよりも、作業全体に必要な工数の規模が8割方把握できていることです。
「6人でできると思っていたが1人足りなかった。」は調整の範囲と言えますが、「3人でできると思っていたが、8人必要だった」は、計画全体の見直しになります。
また、プロジェクトの実施可否を左右するような技術的な要素は、少なくともリストアップして、解決の目途を立てておかなければなりません。
例えば、何かのイベントを行う際に、すべての発注が済んでから「会場が取れなかった。」というような致命的なミスはあってはなりません。
作業ルーチンの各工程への適用
作業の基本ルーチンを、1つの作業工程に当てはめてみましょう。
以下、適用のイメージです。
【準備】
・工程の期間の設定
・工程の生産物の決定
・工程の完了条件の決定
・前工程の生産物の確認
・工程のテスト内容・密度の決定
【実施】
【管理】
・工程の課題リストの管理と調整
・追加要件や課題の記録
・工程へのメンバーアサイン(人員配置)
・工程内の作業の担当者指定(難易度・ロール・技術・作業量等による最適化)
・進捗報告
プロジェクト全体に当てはめた場合と同じく、作業本体を「準備」が先行し、「管理」が並行しています。
違なるのは、それぞれ、この工程にスコープを当てた「準備」であり、「管理」であるという点です。
工程にスコープを当てた「準備」では、工程の完了条件と、すべての作業が洗い出されていないといけません。
また、工程にスコープを当てた「管理」では、その工程に合った進捗の計測方法で計測・報告されます。
なぜなら、工程が違えば、成果の質も違うからです。決め事をするフェーズと、生産物を作るフェーズ、検査をするフェーズでは当然、進捗や品質の測り方が異なってきます。
その上で、工程の遅れやトラブルがプロジェクトの進捗全体に関わる恐れがある場合は、プロジェクト全体の管理にエスカレーションする必要があります。
例を挙げましょう。
製品のテストを「テスト1」「テスト2」に分けて、下記のようにそれぞれの工程の役割を決めたとします。
(工程の役割)
- テスト1工程 ・・・全ての機能が設計通りに作成されていること確認、機能間のデータ連携確認、障害発生時の動作確認
- テスト2工程 ・・・実際の運用フローを充足することの確認、安全性・使い勝手の確認、性能検証
「テスト2」工程で性能検証をしているときに、性能に関わる欠陥を発見してしまった場合、運転に制約に設けるのか、設計変更を行うのか、等を判断しなければなりません。
この場合、ひとまずこのフェーズので吸収できる程度の改修で済むのか、それとは別に、新たな工程か、別のプロジェクトを立ち上げる必要があるかもしれません。
問題の検出と、規模の判断。全体管理への引き渡しが、この工程の「管理」の役割です。
作業ルーチンの各作業への適用
次に、作業の基本ルーチンを、1つの作業に当てはめてみましょう。
【準備】
・作業の実施内容の確認
・工程に必要な資材の調達
・作業に必要な設計の確認
【実施】
・生産物が要件を満たしていることの確認
・生産物の保全(納品場所への保存、バックアップなど)
・証跡の保全
【管理】
・遅れの報告
・トラブルの検出と管理簿への記載
・追加要件や課題の検出と管理簿への記載
これまでプロジェクト全体、プロジェクトの工程に当てはめた場合と同じく、作業本体を「準備」が先行し、「管理」が並行しています。
大まかにいえば、
・その作業で誰が何を行うかが明確に決まっている
・その作業に必要な前作業が終わっている
・その作業に必要な材料や環境の調達が整っている
・その作業の生産物と、完了基準が明確に決まっている
という状況で作業を開始し、作業作業終了後は、
・作業の成果物が所定の場所に残る
・作業の記録が所定の場所に残る
・作業の結果が進捗管理ツールに反映される
状況になっているということです。
管理可能なプロジェクト
次に、プロジェクトを管理するための準備をしていきましょう。
プロジェクトは、計画が終わった段階から、プロジェクトの完了までの間、一貫して「期間内に終わりそうであること」を保証し続け、実際に期限到来時に完了しなければなりません。
ダメなプロジェクト管理では、下記のようなやり取りがあります。
(期中報告):「進んでいます」⇒「進んでいます」⇒「進んでいます」⇒「進んでいます」
(期限到来):「終わっていません」
このプロジェクト管理の何がダメなのか。もうお分かりいただけていると思います、
期中の進捗報告で達成度を数値で表現していません。
完了基準、作業、生産物、決定を要する課題、遅れているのであれば、どのくらい遅れいているのか?、等
プロジェクトの対象物、人間の活動を管理に乗せるためには、活動や成果、問題点などを全て数値に置き換える必要があります。
例えば、進捗報告であれば、以下のようになります。
「期間経過55%に対して、進捗率60%。現時点で問題ありませんが、次の作業に未決定事項が4点ありますが、調整できるメンバーた足りないため、2週後には遅れが発生します。」
どういった対象をどのような数値に置き換えていくかは、作業の性質によって異なります。
例えば、上記の例、「進捗率:60% 」を実際の指標で表すと以下のようになります。
- 作業数 :12点完了/全20作業
- 問い合わせへの回答 :18件解消/全30件
- 要件充足(チェックポイント数) :24ポイント達成/全40チェックポイント
- 作業工数 :30人日消化/全50人日
- ファンクションポイント :36ポイント作成済み/全60ポイント
- ストーリーポイント :43ポイント完了/全70ポイント
※ファンクションポイント、ストーリーポイントは、作成するものや作業に機能数、難易度、作業点数などをそれぞれ点数化して合算した指標です。
プロジェクトの要素を数値化して初めて、進み具合を評価することができるのです。
また、いずれの指標を使用する場合でも、作業時間との比較ができると評価の際に非常に便利です。作業コストは、作業者のレベルと掛け合わせることで金銭に換算することもできます。
時間や金銭に置き換ることができれば、異なるプロジェクトの比較を行ったり、プロジェクトの内容を知らない人が客観的にプロジェクトを評価することもできます。
以下は、数値化したプロジェクトを消化していくイメージです。
また、プロジェクトは数値として計測可能であると同時に、「進捗率100%」イコール「完了」でなければなりません。
「達成率100%だけど、いろいろ作業が残ってる。。」
「達成率100%だけど、動かない。。」
といったことのないよう、実際の作業や生産物をきちんと数値化できるようになりましょう。
実際の作業や生産物の状況と、それを表す数値が一致して初めて、正確な判断を行うことができるのです。
プロジェクトの事後処理
プロジェクトの目標達成は、作業の完了であったり、製造物の完成であったり、イベントの開催であったりします。
しかし、プロジェクトの目標達成のみをプロジェクトの作業とみなすと、後で同様のプロジェクトを実施する場合や、過去のプロジェクトのバージョンアッププロジェクトを実施する際、困ったことが発生します。
「前回どうやったのか、全然記録が残っていない。」
「既存のシステムの仕様書がなく、中がどう動いているのか、分からなくて改修できない。」
といったことがないよう、事後作業工程を設けて情報を保全しましょう。
(事後作業で実施すべき内容)
・契約書・証票類の保全
・実施した作業や手順の記録
・次回のための申し送り事項のまとめ
・作業中に発生した設計変更などの反映
・マニュアル類の更新
・経験の浅い参画者への教育の記録・評価
イベントスタッフや、プログラマー、特定の技能工など、プロジェクトの終盤になると人自体、いなくなる場合があります。
プロジェクト実地中から、情報の保全を心がけ、事後作業で確実なものとします。
さて、ここで矛盾が発生します。
つい前の項でプロジェクトの数値把握した上で100%が完了となるようにすべきと書きました。
しかし、先程事後作業で挙げたような内容も実施する必要はがありますし、そもそも、目標達成後でなければできない作業もあるでしょう。
「感謝状の送付」や「領収書の整理」(事後作業)が終わるまで、「イベント開催」(主たる作業)が100%にならないのは、違和感があります。
・事後作業をゴールとして、こうこうこうい理由で今回のゴールは、達成率89%
というよなことでは、逆に管理が煩雑になってしまいます。
ですので、プロジェクトの主たる目的が達成されるまでの工程と、事後作業や、必須でない作業の工程は分けて管理するようにしましょう。
こうすることで、プロジェクトの主たる目的の達成基準を常に「指標=100%」に保つことができます。
・・・⇒「製造工程:100%」⇒「品質工程100%」⇒「納品工程100%」=(目標達成)⇒「事後作業0%」
といった具合です。
「家に帰るまでが遠足だからなー。」という鉄板ネタがありますが、これは、学校側が主催する「遠足」プロジェクトは学校での解散までが100%。
その後、生徒主体の「帰宅」という事後作業がある、ととらえることもできます。
当然、事後作業は解散後でないと開始できませんし、どちらも100%にならなければいけませんよね。
プロジェクトの評価
プロジェクトの作業が一通り終わった段階で、必要に応じて今回のプロジェクトの評価を行いましょう。
プロジェクトの評価には次の2つの対象があります。
- 今回のプロジェクトの評価
- プロジェクト改善活動のための評価
それぞれの対象について、評価すべき内容を簡単に整理しておきます。
今回のプロジェクトの評価
- スケジュール・期限の順守、乖離の原因
- コストは予算の範囲となったか、超過量と原因
- 製品や作業の品質評価、やり直しが必要であった場合の原因
- 人員計画は適切であったか、無理がなかったか
- クレームやトラブルの件数とその原因
プロジェクト改善活動のための評価
- スケジュールの乖離と原因
- コストのずれ・ロスと原因
- コミュニケーションロス・トラブル
- 製品や作業の品質
- チームワーク・モチベーション維持
- 発注、契約に関する漏れやトラブル
問題点が整理できたら、優先順位を付けて、改善活動を行いましょう。
改善活動を実施する際のフレームワークは様々考案されています。用途に合わせて、活用していきましょう。
(代表的な改善手法)
PDCA
Plan(計画)・Do(結果)・Check(評価)・Action(改善)の4工程を1サイクルとして課題や問題点の改善を行う手法。
KPT
プロジェクトの終わりにあたり、良かったこと(Keep)・改善が必要なこと(Problem)・次に取り組むこと(Try)の3つの取り組みを
リストアップし、次のプロジェクトに役立てていく手法。
まとめ
- プロジェクトを実施するための基本ルーチンは「準備」⇒「作業実施」⇔「管理」
- 管理可能なプロジェクトとは、管理対象が数値化されている
- プロジェクトの目標達成を100%になるように数値化し、その後、事後作業、プロジェクトの評価を行う