プロジェクト運営の流れ

プロジェクトの状態遷移

プロジェクトは目標を達成するための、作業や管理をセットにしたもです。
まずは、プロジェクトの開始から終了までの大まかな流れをイメージしてみました。

それぞれの構成要素を確認しましょう。

【目標設定】

プロジェクトを始める際、まず最初に、そのプロジェクトが何を達成するためのものであるのか、達成すべき目標を設定しします。

【計画】

次に、どのような状況に達すれば目標達成と言えるのか、要件を定義します。その上で、その要件を満たすための必要な作業や課題、生産物等を一通りリストアップします。
実施する作業や生産物が洗い出したら、スケジュール、見積もり、メリット・デメリットなどを抽出し、プロジェクトを実施するのか判断に足る情報を提供します。
プロジェクトの実施判断を行った時点で、このプロジェクトの完了にメドが立っている状況になります。

【作業の実施】

実施する作業が決まったら、各作業に作業順序と、実施担当者、実施期限などを割り振り、一つ一つの作業を順に実施していきます。
プロジェクトを運営している期間中、作業の進み具合や、生産物のチェックなどを適宜行い、プロジェクト完了期限に、所定の生産物や作業結果などがきちんと達成されるよう、
プロジェクトの健康状態を維持していきます。
その過程で、ブロッカーやトラブルは、プロジェクト全体の期間や予算に影響を出さないよう、早め早めに対策を打っておきましょう。

【目標の達成】

最初に決めた要件を全て満たした時点で、プロジェクトの目標達成です。
プロジェクトを管理するためには、達成度を数値化する必要があります。そのためには、最小単位の完成を積み上げたら、プロジェクト全体の完了になるようにきちんと作業を洗い出しておく必要があります。

理論的には、作業を全て完了した時点で、プロジェクトは完了になるはずです。

では、次に、このプロジェクトの完了までの状態フローを実際の人間の活動にマッチさせる方法について考えていきましょう。

プロジェクトを運用するため基本的なルーチン

人間は、基本的に同時に１つのことしかできません。また、作業の内容を考えながら実施することも、不可能とまでは言いませんが、結果の質や、作業効率の点から考えると決していいこととは言えません。

ホテルなどで、最初に避難経路を確認させるのもそのためです。実際に避難する際、避難経路を探しながら逃げた場合、思考力・判断力はほとんどゼロになる一方、記憶力は７０％程度維持されるそうです。

ですから、ある大きさな作業の塊を、品質を維持しながら上手くさばいていくためには、

事前に作業内容や順序を明確にし、その内容を理解した状態で、集中して作業を行うことが望ましいと言えます。

といった流れです。

ただし、「実施」中にある「作業結果が要件を満たしていることを確認する」の部分を作業の実施と見るかは判断のわかれるところです。

この問題は、受験に例えると分かりやすいでしょう。

例えば、自宅で行う過去問の回答であれば、

• テスト解答 ⇒ 丸付け ⇒ 不正解箇所の復習

までが作業の実施、

• 記録 ⇒ 得点推移の振り返り ⇒ 不正解箇所の分析 ⇒ 今後の対策検討

などが、管理と部類出来るでしょう。

一方、受験本番であれば、

• テスト解答

だけが「作業の実施」で、

• 受付 ⇒ テストの配布・回収 ⇒ 採点 ⇒ 集計⇒ 受験生個別事情の調整（減点・加点） ⇒ 評価 ⇒ 合否判定

は「管理」と分類できます。

作業の評価を作業の一種とみるか、管理とみるかについては、契約や、成果物に原価性があるかどうかにも依存しますので、
チームや会社できちんとした基準を決めましょう。

ここで、基本的なフローを図にしてみましょう。非常に簡単です。

必ずこの順番で行うことが重要です。準備を十分に行わず、いきなり作業に入ってはいけません。

準備が不十分だとどうなるのか？

例えば、ランチミーティングにカレーライスをふるまうという小規模プロジェクトを仮定しましょう。

機材、材料は、全てあるものを使い、調理に４０分を見込んでいたとします。

主催者は、通常業務を４０分早く切り上げ、調理を開始します。時間のかかる作業から順に進めていきます。
ご飯を炊き、野菜を切り、肉を焼き、煮込み、１５分煮たら、カレールーを入れて完成です。

しかし、カレールーを入れる段になって、ストックがないことに気付きます。

急遽、最寄りのスーパーへ200円のカレールーを買いに行き、調理を継続しました。

準備不足により、ロスが発生してしまいました。

買い出しに３０分、材料を一旦しまったり、調理器具を洗いなおしたりと、追加の作業が発生します。

それだけではありません。開始遅延の周知を行ったり、参加者のリスケが必要になったりします。最悪、反省文と再発防止レポート、
次回以降のチェック体制の強化を課せられるかもしれません。

影響を受ける人が増えれば増えるほど、追加コストはいくらでも跳ね上がる可能性があります。

原因は、たった200円の材料のが１個足りなかったことです。前日にチェックさえしていれば。。。

準備・確認漏れによるロスは、得るもののない、全くの無駄であると同時に、逆に、きちんと排除できれば、丸ごと利益ですから、まず何よりも最初に排除しなければなりません。

話を戻します。

プロジェクトを進めていくにあたって、「準備」⇒「実施」⇒「管理」のセットが作業の実施には、重要であり、人間の活動にマッチしていることは、違和感なく理解いただけることと思います。

ここで大事なのは、「準備」⇒「実施」⇒「管理」のセットが、プロジェクト全体にも、プロジェクトの各工程にも、プロジェクトの１つ１つの作業にもそれぞれ同じく適用されなければならないという点です。

イラストを見て確認していきましょう。

作業ルーチンのプロジェクト全体への適用

【準備】

【作業実施】

【管理】

上記でリストアップした通り、プロジェクトの正味の作業「作業実施」工程を中心として、どんな作業を行うのかを決める「計画」工程が先行し、「管理」が並行して「作業実施」を支える形となります。

「作業実施」の内容や規模、工程を問わず、このセットは変わりません。

特徴は、この場合の「準備」と「管理」での実施内容が、プロジェクト全体を対象としているという点です。

また、計画で重要なことは、プロジェクトの作業の内容が全て完全に明確になっていることよりも、作業全体に必要な工数の規模が８割方把握できていることです。

「６人でできると思っていたが１人足りなかった。」は調整の範囲と言えますが、「３人でできると思っていたが、８人必要だった」は、計画全体の見直しになります。

また、プロジェクトの実施可否を左右するような技術的な要素は、少なくともリストアップして、解決の目途を立てておかなければなりません。

例えば、何かのイベントを行う際に、すべての発注が済んでから「会場が取れなかった。」というような致命的なミスはあってはなりません。

作業ルーチンの各工程への適用

作業の基本ルーチンを、１つの作業工程に当てはめてみましょう。

以下、適用のイメージです。

【準備】

【実施】

【管理】

プロジェクト全体に当てはめた場合と同じく、作業本体を「準備」が先行し、「管理」が並行しています。

違なるのは、それぞれ、この工程にスコープを当てた「準備」であり、「管理」であるという点です。

工程にスコープを当てた「準備」では、工程の完了条件と、すべての作業が洗い出されていないといけません。

また、工程にスコープを当てた「管理」では、その工程に合った進捗の計測方法で計測・報告されます。

なぜなら、工程が違えば、成果の質も違うからです。決め事をするフェーズと、生産物を作るフェーズ、検査をするフェーズでは当然、進捗や品質の測り方が異なってきます。

その上で、工程の遅れやトラブルがプロジェクトの進捗全体に関わる恐れがある場合は、プロジェクト全体の管理にエスカレーションする必要があります。

例を挙げましょう。

製品のテストを「テスト１」「テスト２」に分けて、下記のようにそれぞれの工程の役割を決めたとします。

（工程の役割）

「テスト２」工程で性能検証をしているときに、性能に関わる欠陥を発見してしまった場合、運転に制約に設けるのか、設計変更を行うのか、等を判断しなければなりません。

この場合、ひとまずこのフェーズので吸収できる程度の改修で済むのか、それとは別に、新たな工程か、別のプロジェクトを立ち上げる必要があるかもしれません。

問題の検出と、規模の判断。全体管理への引き渡しが、この工程の「管理」の役割です。

作業ルーチンの各作業への適用

次に、作業の基本ルーチンを、１つの作業に当てはめてみましょう。

【準備】

【実施】

【管理】

これまでプロジェクト全体、プロジェクトの工程に当てはめた場合と同じく、作業本体を「準備」が先行し、「管理」が並行しています。

大まかにいえば、

・その作業で誰が何を行うかが明確に決まっている
・その作業に必要な前作業が終わっている
・その作業に必要な材料や環境の調達が整っている
・その作業の生産物と、完了基準が明確に決まっている

という状況で作業を開始し、作業作業終了後は、

・作業の成果物が所定の場所に残る
・作業の記録が所定の場所に残る
・作業の結果が進捗管理ツールに反映される

状況になっているということです。

管理可能なプロジェクト

次に、プロジェクトを管理するための準備をしていきましょう。
プロジェクトは、計画が終わった段階から、プロジェクトの完了までの間、一貫して「期間内に終わりそうであること」を保証し続け、実際に期限到来時に完了しなければなりません。

ダメなプロジェクト管理では、下記のようなやり取りがあります。

（期中報告）：「進んでいます」⇒「進んでいます」⇒「進んでいます」⇒「進んでいます」

（期限到来）：「終わっていません」

このプロジェクト管理の何がダメなのか。もうお分かりいただけていると思います、

期中の進捗報告で達成度を数値で表現していません。

完了基準、作業、生産物、決定を要する課題、遅れているのであれば、どのくらい遅れいているのか？、等

プロジェクトの対象物、人間の活動を管理に乗せるためには、活動や成果、問題点などを全て数値に置き換える必要があります。

例えば、進捗報告であれば、以下のようになります。

「期間経過５５％に対して、進捗率６０％。現時点で問題ありませんが、次の作業に未決定事項が４点ありますが、調整できるメンバーた足りないため、２週後には遅れが発生します。」

どういった対象をどのような数値に置き換えていくかは、作業の性質によって異なります。

例えば、上記の例、「進捗率：６０％ 」を実際の指標で表すと以下のようになります。

※ファンクションポイント、ストーリーポイントは、作成するものや作業に機能数、難易度、作業点数などをそれぞれ点数化して合算した指標です。

プロジェクトの要素を数値化して初めて、進み具合を評価することができるのです。

また、いずれの指標を使用する場合でも、作業時間との比較ができると評価の際に非常に便利です。作業コストは、作業者のレベルと掛け合わせることで金銭に換算することもできます。

時間や金銭に置き換ることができれば、異なるプロジェクトの比較を行ったり、プロジェクトの内容を知らない人が客観的にプロジェクトを評価することもできます。

以下は、数値化したプロジェクトを消化していくイメージです。

また、プロジェクトは数値として計測可能であると同時に、「進捗率１００％」イコール「完了」でなければなりません。

「達成率１００％だけど、いろいろ作業が残ってる。。」

「達成率１００％だけど、動かない。。」

といったことのないよう、実際の作業や生産物をきちんと数値化できるようになりましょう。

実際の作業や生産物の状況と、それを表す数値が一致して初めて、正確な判断を行うことができるのです。

プロジェクトの事後処理

プロジェクトの目標達成は、作業の完了であったり、製造物の完成であったり、イベントの開催であったりします。

しかし、プロジェクトの目標達成のみをプロジェクトの作業とみなすと、後で同様のプロジェクトを実施する場合や、過去のプロジェクトのバージョンアッププロジェクトを実施する際、困ったことが発生します。

「前回どうやったのか、全然記録が残っていない。」

「既存のシステムの仕様書がなく、中がどう動いているのか、分からなくて改修できない。」

といったことがないよう、事後作業工程を設けて情報を保全しましょう。

（事後作業で実施すべき内容）

イベントスタッフや、プログラマー、特定の技能工など、プロジェクトの終盤になると人自体、いなくなる場合があります。

プロジェクト実地中から、情報の保全を心がけ、事後作業で確実なものとします。

さて、ここで矛盾が発生します。

つい前の項でプロジェクトの数値把握した上で１００％が完了となるようにすべきと書きました。

しかし、先程事後作業で挙げたような内容も実施する必要はがありますし、そもそも、目標達成後でなければできない作業もあるでしょう。

「感謝状の送付」や「領収書の整理」（事後作業）が終わるまで、「イベント開催」（主たる作業）が１００％にならないのは、違和感があります。

というよなことでは、逆に管理が煩雑になってしまいます。

ですので、プロジェクトの主たる目的が達成されるまでの工程と、事後作業や、必須でない作業の工程は分けて管理するようにしましょう。

こうすることで、プロジェクトの主たる目的の達成基準を常に「指標＝１００％」に保つことができます。

・・・⇒「製造工程：１００％」⇒「品質工程１００％」⇒「納品工程１００％」＝（目標達成）⇒「事後作業０％」

といった具合です。

「家に帰るまでが遠足だからなー。」という鉄板ネタがありますが、これは、学校側が主催する「遠足」プロジェクトは学校での解散までが１００％。

その後、生徒主体の「帰宅」という事後作業がある、ととらえることもできます。

当然、事後作業は解散後でないと開始できませんし、どちらも１００％にならなければいけませんよね。

プロジェクトの評価

プロジェクトの作業が一通り終わった段階で、必要に応じて今回のプロジェクトの評価を行いましょう。

プロジェクトの評価には次の２つの対象があります。

それぞれの対象について、評価すべき内容を簡単に整理しておきます。

今回のプロジェクトの評価

プロジェクト改善活動のための評価

問題点が整理できたら、優先順位を付けて、改善活動を行いましょう。

改善活動を実施する際のフレームワークは様々考案されています。用途に合わせて、活用していきましょう。

（代表的な改善手法）

ＰＤＣＡ

Plan（計画）・Do（結果）・Check（評価）・Action（改善）の4工程を１サイクルとして課題や問題点の改善を行う手法。

ＫＰＴ

プロジェクトの終わりにあたり、良かったこと（Keep）・改善が必要なこと（Problem）・次に取り組むこと（Try）の３つの取り組みを
リストアップし、次のプロジェクトに役立てていく手法。

まとめ