こんにちは！たまには普通にスタートしてみます。中薗と申します_(:3」∠)_
いつも冒頭で一発ネタばかり言っているので、まじめにやると尋常じゃない違和感がありますね！←_(:3」∠)_

さて、長くつづいてきたプロジェクトマネジメントに関する記事も、今回でラストとしたいと思います！
いままでの記事でどんな内容を取りあつかってきたか、ふり返ってみましょう。

■管理がおろそかであれば、プロジェクトはいともたやすく失敗してしまう
プロジェクトの成功率は30％程度であると言われています。
当初計画した納期がどんどんずれこみ、デスマーチとなった経験を持つ方もいるでしょう。
プロジェクトが失敗する原因はいくつもあります。
なかでも多いと言われているのが、プロジェクトの分析ができていないことによる失敗。
そのため、まずはそれが「どのようなプロジェクトであるのか」をクリアにしていく作業が必要となるのです。

■プロジェクトを成功に導くプランとはどのようなものか？
正確なプランを立てることは非常にむずかしい作業です。
実際には、プランと実際のプロジェクトとが乖離してしまうことのほうがはるかに多いように感じます。
なぜなら、新規プロジェクトにおけるプランを策定しようにも、開始段階における成果物や顧客の要件は不確定。
中盤から終盤においてどのような変化がおこるかをすべて見通すことはむずかしいです。
その不確実性を無視してプランを策定してしまうことが、「実効性の高いプラン」を立てられない大きな原因でした。

■「未知事項」と「既知事項」
プロジェクトのプランを作成するさいに、経験則を元にしてプロジェクトを判断するベテラン・マネージャーは、未知事項を既知事項と勘違いしてしまう危険性があります。
一方、経験の浅いマネージャーは、自信の無さから既知事項さえも未知事項であると早合点してしまい、途方にくれてしまいがちです。
そのような問題を解決するためには、プラン策定に入る前にまずプロジェクトの全体像を俯瞰し、プロジェクトの進行にどのような問題や困難がひそんでいるかを見極めることが重要です。

■ひとやすみ
文字ばっかりだと読むのが疲れるので、モルモットの画像でもみて癒されてください。

キュート。キュートすぎる。モルモットは世界を救いますね。
それでは、次いきましょう。

■プロジェクトの分析項目の設定
大事なのは、プランの策定に入る前にまずプロジェクトの全体像を俯瞰すること。
具体的には、次のような情報を集めていきましょう。

1.　プロジェクトの目的
2.　プロジェクトの目標
3.　成果物、中間成果物とその完成基準
4.　主要なマイルストーンを含む概要スケジュール
5.　概要レベルのリスク
6.　どんな前提・仮定があるか
7.　実施上の制約
8.　特殊なリソースの必要性
9.　今後の調査項目
10.　関連するプロジェクト

■各分析項目に関する情報を収集したのち、次に進むべき各ステップ
情報を集めたら、さらに次のステップに進みます。
1～5の順でおこなうとよいでしょう。

1.　収集した情報の確定度合い、可変性、信憑性を評価
2.　欠落している情報を認識
3.　未知項目に対する仮定を検証
4.　定義づけのたたき台をプロジェクト関係者と共有し、洗練させる
5.　定義づけにより整理された情報を実行プランに反映

■WBS（Work Breakdown Structure）を作成する
WBSとはプロジェクトマネジメントで計画を立てるさいに用いられる手法のひとつで、プロジェクト全体を細かい作業に分割した構成図のこと。
これを作成することで、次のようなメリットがありました。

1.　やるべき作業が明確化される
2.　スケジュールを組める
3.　役割を分担できる
4.　工数見積が可能になる
5.　進捗管理が可能になる。

■ひとやすみ・その2
「文章が延々と続くと、じんましんが出そうになる」という方もいると思うので、モルモットの画像でもみて癒されてください。（二度目）

これはあくまで個人的な意見ですが、世界中がモルモットでいっぱいになれば、みんなの心が豊かになって世の中から争いごとはなくなると思うんですよね。

■スケジュールを作成する意義とは？
詳細にスケジュールを組んだところで、プロジェクトはそのとおりには進捗しません。
では、なぜ作成する意義があるのか？
その答えを出すには、「立てたスケジュールはたたき台である」という意識を持つことが必要です。
立てたものをベースとし、スケジュールを構成する各要素の不確実性の度合いを認識します。
また、シミュレーションによって不確実性を解消･軽減するための問題解決をおこなうのです。

■各作業を実施するうえでの、制約や前提上の問題を洗い出す
制約や前提上の問題は頭で漠然と考えてもよく理解ができません。
実際にスケジュールをシミュレーションする過程の中で、初めて客観化できるものです。
変化を先読みし、「この行動を取れば結果はこうなる」という試行錯誤のプロセスを経る。
それをおこなうことで、はじめてコストやリソース、スケジュール上の各制約間の無理・矛盾を客観化することができます。

■おわりに
いかがでしたか？半年以上にわたって続けてきたこのシリーズ。
思い返せばいろんな思い出が

思い出が

思い出が……。

………………………………。

みなさんはこんな大人にならないようにしましょう。
それでは、また次回_(:3」∠)_

【関連記事】
サーバの冗長化について①
サーバの冗長化について②
ロードバランサについて
負荷試験について
プロトコルについて①
OSI参照モデル①
OSI参照モデル②
OSI参照モデル③
プロジェクトマネジメントの手法①
プロジェクトマネジメントの手法②
プロジェクトマネジメントの手法③
プロジェクトマネジメントの手法④
プロジェクトマネジメントの手法⑤
プロジェクトマネジメントの手法⑥
JavaScriptのテストフレームワーク
プロジェクトマネジメントの手法⑦