失敗しないためのプロジェクト再入門（その２）・プロジェクトの構成要素を理解しよう

> 前回の投稿「[失敗しないためのプロジェクト再入門（その１）・そもそも、プロジェクトって何？よくある失敗とは？](https://qiita.com/imamuramasao/items/ada017da1302c38c6a7d)」に引き続きの第２回投稿です。

# プロジェクトの構成要素とは？
![02_component_00_eyecatch.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/518202/0f8a82a0-e0c3-dce3-cce4-8cdd64b7b387.jpeg)

　前項にも挙げた通り、プロジェクトは、目標を達成するものであり、それを保証する手順でなければなりません。
　そのようなプロジェクトを実現するためには、プロジェクトの運用で発生する様々な要素を当てはめていく共通的な概念が必要です。

 この章では、プロジェクト運用の手順の説明に入る前に、プロジェクトの構成要素をおさらいしておきます。

# 目標はプロジェクトのゴール
 プロジェクトに必要な要素、まず１つ目は、プロジェクトの目標です。
 目標は、プロジェクトそのものと言えます。プロジェクトを始める理由であり、プロジェクトで達成されるべきものという意味で、スタートでありゴールでもあると言えます。

 そもそもプロジェクトを始めるのは、何か達成したい目標があるからです。

 それは、いまある問題点の解消かもしれませんし、顧客の要望に対する機能の提供かもしれません。いずれにせよ、目標は明確で、関係者全員に理解されていなければなりません。

 プロジェクトの期間中は、すべての作業も資材もすべてはこの目標のために動きますので、目標があいまいであったり、途中で変わってしまうこおがあれば、大きなロスが発生してしまいます。

 目標が問題の解消であれば、その問題点の原因がなんであるのかを認識し、何をどう変えれば改善するのか、普段から考えておく必要があります。

 目標が顧客の要望に応えることであれば、顧客の本当の望む結果が何であるのか、顧客が気付くためのお手伝いも含めてしっかりと掘り下げておきましょう。

 また、プロジェクトが大規模になり、役割が細分化されるに従い、各参加者の意識はあいまいになります。

 各作業で判断が必要となった場合も、明確な目標がある事が、より正しい決定を行うための助けになります。

> ![02_component_01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/518202/e098bd79-2458-7cf3-443b-400bb1b6e66c.png "（目標は「問題点が解消されること」、手段が「引っ越し」）")

# 要件と条件がインプット
　プロジェクトの目標は、達成可能なものでなければなりません。

　「理想を低く」とか、「簡単じゃなきゃダメ」という意味ではありません。

　目標が「達成可能」とは、目標達成のために何をすればいいかが明確になっていて、かつ、実施不可能な要素を含んでいないということです。

　「予算が足りない」のも、「期間が短すぎる」のも、実施不可能な要素です。大事なのは、プロジェクトの序盤でそれがきちんと把握されているということです。

　そのために、プロジェクト開始時に、まず「要件」と「条件」の洗い出しを行います。

> * 「要件」とは、その目標の達成とは、何ができていればＯＫなのか？という基準のことです。
* 「条件」とは、プロジェクトの内容や実施方法を制約する様々な要素のことです。

　ただ、それぞれの要素が「要件」、「条件」どちらであるかはあいまいな部分があります。

　大事なことは、その要素が、「要件」「条件」いずれかにきちんと挙げられ、プロジェクトに対する重みづけ（重要度・優先度）がされていることです。

　要件と条件の例を挙げましょう。

## 要件
> * 解消すべき問題と優先度&nbsp;･･･（例）渋滞によるコストロス減（必須）
* 実現すべき機能&nbsp;･･･（例）会議室増（現状の２倍）／できれば各階に男女別のトイレ
* 数量目標&nbsp;･･･（例）事故数減：12件/年⇒3件/年、待機時間減：110時間・人/月⇒50時間・人/月

## 条件
> *期限 ･･･ （例）９月末移転完了
* 予算の許容範囲 ･･･ （例）月額賃料は今と同程度、移転費用は2,000万円以内
* 既存との関係 ･･･ （例）今あるものを置き換えるのか、機能を追加して使うのか･･･等
* 制約 ･･･ （例）川崎支店との営業エリア重複を避けるため、港北区・緑区の物件は不可
* 禁止事項 ･･･ （例）顧客情報を含むため、データ移行と資料類の梱包は委託不可

> ![02_component_02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/518202/c3d38534-96b4-b25b-7858-b8d2a1ebdc6d.png "（要件があって初めて、すべき行動が見えてくる）")

　プロジェクトの目標は、リストアップされた要件の形になって初めて作業内容をを決めることができます。

　例えば、賃貸物件を検索（作業）しようと思ったら、「今の所在より国道に近くて、広くて、同価格帯で、改装可能で、１Ｆを搬入口に使えて･･･」といった要件があって初めて「○○地区／○○平米以上／１Ｆor１～２Ｆ／賃料○○円～○○円／駐車場あり･･･」というフィルター条件を作り、検索する事ができます。

　プロジェクトの序盤でしっかりと要件と条件の洗い出しを行い、それが本当に達成したいことなのか、認識合わせを行いましょう。

　要件を満たさないものを違ってしまっても予算と期間は消費してしまうのですから。

# 計画はプロジェクトで一番大事な作業
　プロジェクトは大きく分けて、「計画フェーズ」と「実行フェーズ」の２つの期間に分けることができます。
　プロジェクト開始後、最初に実施する作業が「計画」に関する作業であり、プロジェクト全体の中で最も大事な期間といえます。

　プロジェクトの規模が大きい場合は、必要に応じて「初期調査」「見積作成」「作業リストアップ」「全体設計」「事前ヒアリング」･･･等、計画に関する作業を必要に応じて分割します。

　計画フェーズでは、実際に作業を始める前にプロジェクト完了までに必要な情報を一通り揃えます。

　また、プロジェクト完了までに必要な作業を、明確にすることで初めて、プロジェクトは管理可能になります。

　計画フェーズが終わった時点では、下記のような内容のものが、作成・確認されていなければなりません。

> * プロジェクトの目標
* プロジェクトの要件・条件
* 全体構成／中心となる機能の設計
* 参加メンバー・組織の確認
* プロジェクト管理方法の確認
* プロジェクト管理ツールの確認
* 生産物の確認
* 作業のリストアップ
* 発注資材／人員の把握
* 解決すべき課題・問題点のリストアップ
* 仮スケジュールの作成
* 費用予測
* 効果予測

　単純に言えば、この時点で「できるの？」「ペイするの？」の２つの質問に論理的に回答できればまず問題ないでしょう。

　計画フェーズ完了後、スケジュール・費用対効果予測を材料にして、プロジェクトの実施判断を行います。

　あるいは、顧客のあるプロジェクトであれば、「受注」もしくは「見送り」となります。

> ![02_component_03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/518202/bb9ba3cf-4484-3fb6-3f0e-9858ba6a7354.png "（計画完了時点で見通しができていること）")

　「家は３回建てないと理想の家にならない」と言います、しかしそれはすなわち３軒分の金額で１軒の家を買ったのと同じことです。

　会社の引っ越しプロジェクトで、最良の物件にたどり着くまで引っ越しを繰り返すということはありえません。
　また、顧客のあるプロジェクトで料金を３倍請求することもできません。
　計画のブレ幅が最小限になるようしっかりとした計画を立てられるようになりましょう。

# ルールとツールがあって初めてプロジェクトと言える
　一番最初に、目標さえあれば、目標さえあればプロジェクトと言えると書きました。
　しかし、実際に実際のプロジェクトでそのような運用をすることはまずありえません。

　プロジェクトでは、プロジェクトの作業や成果物が要件を満たし、プロジェクト全体が期間内に終了することをプロジェクトの実施期間中確保し続けなくてはなりません。

　そのために、プロジェクト管理では、管理対象となる作業や課題などを可視化したり、数量的に評価するためのいくつかのツールを使用します。

　プロジェクトを管理するためのツールには以下のようなものがあります。

### （代表的なツール）
> * 組織図
* ワークフローツール
* コミュニケーションツール（メール、チャット、等）
* ガントチャート
* 課題管理表／問題管理表
* 機能一覧
* 作業明細（ＷＢＳ）

　また、プロジェクトを運営していくためには、そのツールの情報を誰がどのように更新、集計し、どのようなレポートラインで報告し、誰が判断し、誰が何に対して責任を持つのか、明確なルールが必要です。

### （ルールの例）
> * リーダーは作業をリスト化する
* 作業者は作業完了時、作業リストにチェック☑を付ける
* リーダーは完了した作業を確認・承認する
* 決定事項・作業内容の変更はリーダーが行い、マネージャーの許可を要する
* マネージャーは、予算と生産物を承認する
* リーダーは進捗をとりまとめ、週１回マネージャーに報告する
* リーダーは顧客窓口を兼務する
* 窓口は、２週間に一度顧客に進捗状況を報告する

　ここまでセットで初めて「プロジェクト管理」です。

　適切な管理ツールを用いて、プロジェクトの状態を把握し、プロジェクトの健康状態を維持しましょう。

　それでは、次の章以降、プロジェクト運営・プロジェクト管理の方法についてもう少し具体的に説明していきましょう。