プロジェクトとは　（はじめに）

■ プロジェクトの本質は、やってみないと分からないという不確実性にあり、終始不確実性に支配されています！
・・・ 不確実性のない仕事はプロジェクトではないので、プロジェクトとして立ち上げる必要はありません。

✥ プロジェクト とは、・・・　“難しいものだ！“
・やったことがないことを、
・何が起こるか分からないのに計画して、
・予定通りのモノ（コト）を、期限までにつくる（終わらせる）こと

*　「新しい技術」や「不安定な要求」、「スケジュールの制約」などの 不確実性の源泉となるものが、“プロジェクトの価値”　を生み出すのです

また、それが収益性の高いビジネスにつながるのですが、当然リスクを克服していかなければなりません。

*　不確実性を乗りこなすには、
・プロジェクト開始時に、目的と目標、全体プロセスを明らかにして、それらをもとに、計画を立てることで　⇒　不確実性を小さくする
・リスクの顕在化や想定外のトラブル、大幅な見積り超過などに備えて、予め対策を打っておく　⇒　「予定と実績のズレ」や「リスク」が現実になっても、影響を最小限に抑えられる
・不確実性を徐々に減らしていく　～　やってみなければ分からないことは、早めにやってみれば良い　⇒　分かったことをうまく捕えて、計画やスケジュールに反映する

当然、予定と実績を比較して計画に反映させていく進捗管理（監視と制御）がある

☞　【Ｎの流儀（極意）】　＠NAMBU2017　　H0807d

□プロジェクトの本質は“不確実性”にあり
＊ プロジェクトはリスクとの戦いであり、リスク管理の重要性を認識する必要がある
・・・　リスク管理とは、影響を最小限に抑える手を打っておくこととも言えます。

＊ 繰返しのない仕事である「プロジェクト」は、“計画が全て”です・・・「段取り八分」

・プロジェクトは 「不確実性があり、難しいもの」と認識することがポイント！
だから、うまくやれば ”価値（利益）を生み出せる”　面白いビジネスになるのです。　nambu

○プロジェクトの特徴である独自性の存在そのものが、 “リスクが存在する“ということだ
プロジェクトは、「特定の目的・目標を、期限内に、予算範囲内で、達成するための独自の活動（組織）であり、基本的には “初めてヤル” 活動 」です。
未経験（初めて）の活動には、当然それに伴うリスクが必ず存在するものです。
☞ このリスクの存在を明らかにして、どのように対処するかが、プロジェクトマネジメント”成功の鍵”となります！

○未然防止は、まさに「リスクマネジメント」
ＰＭ（プロジェクトマネージャ）の仕事は、起きてしまった問題に対応して解決することではありません。
常に（毎日）、問題が起きないように未然防止策の立案と実行に努めていることが、まさに仕事をしていることです。
～　必要なものは　⇒　火種(ひだね)のニオイを嗅(か)ぐ　“力量(りきりょう)”　！

○ほころびを繕うことも、未然防止に
メンバーの士気が下がってきた時やその兆候を感じた時など、常に気をつけていることが大事なこと。
顧客や部外者との関係や、開発環境の不備や障害にも注意しなければなりません。

※プロジェクトマネジメントには、近代的な手法を理解し習熟することが欠かせませんが、現場の経験でしか身につかないマネジメント能力が多いことも事実です。
また、プロジェクトで直面する問題・課題・リスクはそれぞれの場合で異なり、経験で培われた判断力・指導力・実行力が要求されます。
これらは、経験知・暗黙知（ディープスマート）と言われるもので、「創造のプロセス」にも通じるところだろう　（Ｎ）
【参考】 茂木健一郎が解く 先輩南部陽一郎のひらめき ～「ほがらかな探究」より

 

■プロジェクト成功の条件

・納期（期限内に）
・コスト（予算金額内で）
・技術（期待レベルの技術成果の元で）
また、資源を有効活用し、顧客が満足する状態で完了することとも言えます。

 

○プロジェクトマネジメントの活動

・企画
・リスク測定
・資源の見積り
・ＷＢＳ（Work Breakdown Structure）の作成　～“計画”が全て！
・（人的・物的）資源の確保
・費用の見積
・チームメンバーへの作業の割り振り
・進捗管理　～実行されなければ意味がない！
・目的に沿った方向性の維持　＝　“監視と制御”
・結果の分析

○監視と制御（コントロール）・プロセス　～広い意味での“進捗管理”のこと
…　チェックと是正をまとめて監視プロセスと言われる
・計画のずれを把握
・計画の修正活動
・利害関係者からの変化項目の受理と評価
・必要に応じたスケジュール変更
・必要に応じた資源量の変更調整

☞　ＰＭ規約としてのガイドライン概要（例）
☞　開発プロセス改善ポイントのガイドライン概要（例）　Ｎ

■計画の重要性
・・・　計画の良し悪しでコストの大半が決まる

・計画があれば、無駄な時間を費やさなくてすむ
・計画があるから、是正が出来る
・手段/方法が変われば、コストは大きく変わる

 

■プロジェクトにおけるトラブルや危機の（例）　・・・　リスクが現実となる時

(1) スケジュール遅延
・進捗が可視化されておらず、管理できていない
・上位工程の遅れに引きずられることも多い
特に要件定義～“業務仕様” に着目すること、基本設計が重要

☞　プロジェクト管理は要件定義（業務仕様）から　Ｎ　　　【Ｎの流儀】

・プロセス（ＷＢＳ作業、工程）は絶対に省かない　・・・必ず品質の劣化として現れる！
(2) 仕様変更/追加
・変更管理ルール/ガイドラインが守られていない（無い場合は論外だが・・・）
特に、最終テストが完了した後での仕様変更は厳禁！　…　致命傷になることもあるので要注意
・顧客の勝手な要求だったり、ＳＥが要件を理解できていないことが多い
・要件定義を正確に記述しておき、不要な仕様変更を未然に防ぐ
・原点となる業務要件/スコープ/プロジェクト方針/契約内容に戻る
(3) オーバーフロー（作業量/工数オーバー）、士気低下
・早急に対策をうつ　・・・遅くなれば遅くなるほど傷が広がる
(4) メンバーの交代、人材不足（貢献できない要員）
・安易な新規メンバー投入は極力しない方が良い　…　大きなリスク
(5) 利害関係者（ステークホルダー）のコミットメント
・文書化されているか　・・・あとで、言ったとか言わないとかの問題にならないように
(6) ＷＢＳの不備
・モレや未定となっている仕様が放置されたまま、開発が進んでいく
(7) 開発環境の不備　・・・テストの段階になって、やっと気が付いたりすることがないように
(8) システム性能が出ない、サービスレベルが守れない
・事前の検証が必ず実施されているか　・・・　デッドロック問題などにも要注意
(9) データ移行は最難関 　…　甘く見ないこと！　（N）
・ベテランＳＥ（業務に詳しい）が関与・投入されているか
現状のシステム/業務を詳細まで理解できていないと、稼働にたどり着けずに大へんなことになる

 

【附録】

□ＩＴプロジェクト失敗の理由（原因） ・・・　一般的に言われていることだが

・顧客からの情報不足　？　・・・　上級ＳＥのコミュニケーション能力や業務知識不足
・要求仕様が不完全　・・・　顧客/開発側両者の能力不足
・要件定義の不備（正確に文書化できていなかったり、合意・承認されていない）
・要求仕様の変更　・・・　顧客/開発側両者の能力不足
・変更管理の不備　・・・　特に、テスト完了後の仕様変更は絶対しない　⇒　部分的に稼働を延期するなども
・経営トップの支援欠如　・・・　顧客指導ができていない
・技術力の不足　・・・　ＰＭ能力（マネジメント力）不足
・計画不備（予算不足、開発側の能力不足、技術習得が間にあわない、トレーニング不足なども）
・開発工数の不足　・・・　見積/計画不備
・非現実的な期待値？のまま開発が進んでいく　・・・　契約時に夢のような甘い言葉は厳禁
・不明瞭な開発目的　・・・　プロジェクト方針/スコープに立ち戻ることも必要
・非現実的な開発期間　・・・　出来ないことは、始まる前にハッキリ言う！
・最新技術への盲信　・・・　初めて導入する技術は、必ず事前検証をしておくこと

 

□システム開発（プロジェクト）の基本と失敗理由【Ｎの流儀】 ・・・　経験知・暗黙知としての紹介

※　システム開発の現状から、プロセス改善を進めるにあたって

〇開発プロジェクト失敗の原因
・プロジェクト管理 ができていない　・・・　計画通りに工程が進捗せずに、納期に間に合わなくなる
・開発プロセス が標準化/ルール化されていない　・・・　やみくもに作っているのでは品質が問題
・業務知識 が足りない/無い　・・・　要件がまとめられない、業務（ｼｽﾃﾑ）が設計出来ない、バグ多発

〇システム開発～現状の問題/課題と背景
※現在のシステム開発（プロセス）の実施状況を、標準ＷＢＳを参考にチェックした結果をもとに進める
そして、ヒアリングと同時に開発ドキュメントの有無も確認し、チェックリストに現状を明記する

(1) プロジェクトは管理されているか　・・・　プロジェクトマネジメントが機能しているか
・ＷＢＳ はあるのか（作られているか）？
ＷＢＳ（WorkBreakdownStructure）：やるべき事の一覧/詳細、計画
（注）　プロジェクト管理されていても、プロジェクトの置かれた状態は一様ではなく、プロジェクトで直面する問題・課題・リスクはそれぞれ異なり、経験で培われた判断力・指導力・実行力が要求されるもの
⇒　プロジェクトはリスクとの戦い　・・・（プロジェクト失敗の原因）
・計画不足（スケジュールリスク） ・・・　ＷＢＳ不備、要員不足
・準備不足（テクニカルリスクetc.） ・・・　無謀な技術的挑戦、ＳＥの能力不足
・予算不足（コストリスク） ・・・　見積～実行予算モレ、開発環境不備

(2) 開発プロセスが標準化・ルール化されているか
・ドキュメント化されているか
・ルール通りに実施されているか（必要に応じてテーラリング）、
・結果が確認・評価されているか
⇒　失敗/不具合（障害）の原因は「プロセス」にある
・何らかの理由でプロセスが省かれた
・取組みが不十分だった
・必要なプロセスを知らなかった

(3) 開発ドキュメントは作られているか
・顧客や開発チーム内での情報伝達/確認重要なもの
⇒　設計書は必ず書く　（省かない、サボらない～）　・・・　システム品質が保証できない
・ドキュメントが無いと、後で「言った言わない」の水掛け論に終わってしまう～社内外ともに
・システム（成果物）を次世代や他システムへ継承していくためにも無くてはならない
・「暗黙の了解」というものは、大切なことが必ず抜け落ちてしまうもの

(4) 設計ＳＥは、必要な「業務知識」を持っているか
・顧客の要求が正しく理解できないと、要件定義が出来ない
～言われるままに設計してしまうと、不良/障害（出戻り開発）が頻発する
・設計したシステムが、ビジネスシステム（業務）として正しく、有効なものになっているか
現状をそのままシステム化するだけとか、使う人の能力を考慮しなかったり、経営者のポリシーに反するものは、拒絶される！
～顧客に業務そのものをコンサルするくらいでないと満足してもらえないのだろう
・利用者は、システムを使って（動かして）みてからでないと、可否判断はしてくれないもの

（注） 業務知識は、プロジェクトの成否にかかわると言っても過言ではない