《日本》
・プロジェクト成功：26.7％
・品質・納期・コストに問題：73.3％
・プロジェクト中止：無し
《米国》
・プロジェクト成功：34％
・品質・納期・コストに問題：51％
・プロジェクト中止：15％
※米国ではプロジェクトの標準化が日本に比べてされている。
※日本ではプロジェクト中止がない。
問題があってもプロジェクトを中止せず、進めてしまう傾向にあるそうです。
いろんな意味で見極めも大切だと感じます。
それにしても、成功の確率は低いですね。
プロジェクト管理はもちろんのこと、普通に社会で暮らしていくにあたり
人とのコミュニケーションは大切です。
コミュニケーションがうまくいかないプロジェクトは成功しないでしょう。
そのコミュニケーションの基本でかつ簡単なことはあいさつではないでしょうか。
実は、私が勤務するビルは毎週月曜日の朝に入口に立って「おはようございます」と
挨拶をしてくれている方がいらっしゃいます。
先月から、私も中に混ぜてもらって一緒に挨拶をはじめました。
最初はチョット恥ずかしい面もあったのですが、慣れてくるとだんだん
すがすがしい気持ちになってきます。
また、元気な声で返事をいただくと朝から気分が良いですね。
今後も無理しないペースで続けていけたらと思っています。
本日は土曜日ですが、弊社では本学講座を開催致し「ビジネスで大切なことは、すべてドラッカーが教えてくれた」（藤屋 伸二氏）をテーマに学びました。
出席いただいたみなさん、有難うございました。
さて、突然ですがプロジェクトという言葉が使われ始めたのはいつ頃からかご存知でしょうか?
そもそも「プロジェクト」という言葉が初めて使われたのは
１９４０年代前半のマンハッタンプロジェクト。
原子力爆弾の製造開発だそうです。
初期の頃のプロジェクトマネージメントは
・コスト
・納期
・品質
の3つに集約されていました。
そして時代が進むにつれてマネージメントの必要性が多種多様化してきたようです。
・スコープ
・リスク
・コミュニケーション
・チームビルディング
・アカウンタビリティ
・自信
・リーダーシップ
・顧客志向性
・顧客説得性
・創造性
・戦略指向性
・リスク管理能力
・バランス感覚
・実行力
・問題解決能力
・自己統制力
・徹底確認力
・現象観察力
・分析思考力
・PMO組織
・問題解決支援
・レビュ
・メンタリング
・教育トレーニング
:
:
:
今回はリスク管理について投稿します。
■リスクマネジメントの目的
リスクとは、プロジェクトにおける「品質、コスト、納期」の目標達成を阻害する問題、この影響を最小化することが目的である
■STEP1 リスクの特定・洗い出し
・プロジェクトで予想されるリスク
要件のレベルの深さ
パフォーマンス/キャパシティー要件
スケジュールの妥当性
作業量とコストの見積
管理経験、要員確保
お客様の特質、参画程度、要求事項
契約条件/完了条件（お客様、外注）
技術適合
移行計画
■STEP2 リスクの定量化
■STEP3 リスク対応策の策定
・優先順位の高いリスク項目から対応策を考える
・対応策の種類として、
回避（リスクを避ける）
軽減（発生確立、影響度を下げる）
受容（何もしない）
ただい、リスクが派生した後の対応策の立案を作成することが重要
■STEP4 リスクのモニタリングコントロール
・リスク対応のアクションプランが作られ、定期的にトラッキングする。
・トラッキングのポイント
①定量化の見直しが必要か
②対応策の見直しが必要か
③新たなリスクの発生につながってないか
急に秋の気配が感じられる今日この頃です。
涼しくなるのは過ごし易くて良いのですが
あの灼熱の日差しが無いと、ちょっと淋しい気もいたします。
さて、前回プロジェクトの失敗の原因を書きましたが
では成功とはどういったことか改めて考えてみました。
システム開発の基本的な流れは
現状分析・要件整理
↓
要件定義
↓
基本設計
↓
詳細設計
↓
プログラム開発
↓
結合テスト、システムテスト、運用テスト、移行･･･
↓
本番･･･
プロジェクトの成功とはひとことでいえばお客様の満足度を得ること。
その為には要件定義の時点でお客様が完成イメージを描けるトギュメント作りが
いかにできるか、トップの経営目線でのシステム提案になっているかが
カギになるかと思います。
そこができれば、後工程はの適正なスケジュール、人員構成のもと
納期・品質・コストをマネージメントしていき、各局面でしっかりレビューを
行っていけば自ずと満足度の高いシステムが構築できていくでしょう。
ポイントとしては
①プロフェッショナルとしての自覚が必要。
②お客様の業務、現状を把握する。
③ＩＴ導入の目的を明確にする。
④目標を具体化する。
⑤コストを考える。
⑥社内コンセンサスの確立
⑦担当者を置く。(担当幹部、実務担当者)
⑧ＩＴ導入はトップダウンの方がうまくいく確立が高い。
毎日、暑い日が続いていますね。
本日は、IBMユーザー研究会九州研のIT研のキックオフでした。
若いメンバーの前でiSUC実行委員OBの小生はiSUCのPRタイムをいただき
宣伝してきました。やはり、若いっていいですねー
さて、プロジェクトを遂行するにあたって問題点をあげてみました。
1.システムの品質問題を招いた主な原因
・社内の開発体制に問題があった。
・要件定義が十分でなかった。
・テストが不十分・移行作業に問題があった。
2.プロジェクトコストの超過を招いた主な原因
・追加の要件作業が発生した。
・追加の設計作業が発生した。
・追加の開発作業が発生した。
※外注への依存度が高いが、外注管理ができていない。
3.プロジェクトの遅れを招いた主な原因
・要件定義が計画より長引いた。
・開発作業が長引いた。
※テスト作業を行う時間が減ってしまう。
4.プロジェクトの開発局面の現状
・開発工程のドキュメントの標準化がなく、各人が自分なりの纏め方になっている。
・設計書は、口頭やメモが多いが、部下への指示に影響を与える。
・テスト仕様書がない為に、経験則のテストになっている。⇒テストが一定ではない。
非常に耳が痛い内容です。ある意味当たり前なのかもしれませんが
ドキュメント管理をきっちり愚直に行う、コミュニケーションをしっかりとる
ことが大切ですね。
先週は第49回IBMユーザーシンポジウム倉敷大会に参加してまいりました。
夜に倉敷に入ったのですが交流会会場のアイビースクエアは屋外で
大変気持ちの良いひと時を過ごせました。
関係者の皆さま、大会大成功おめでとうございます!
さて、只今5/23の22:00になろうかとしていますが、社内には20名位の
スタッフが残って仕事をしております。
我が社では幾つかのプロジェクト開発が佳境に入っており、
ある人は出先から戻ってきて、別のプロジェクトをフォローしています。
以前、会議体の中で、どうすべきかでぶつかっていたメンバーですが
いまはみんなでフォローしていただいています。
プロジェクトの過程の中である時は、葛藤も必要だと改めて感じています。(愚痴はもちろん厳禁ですが・・・)
シンポジウムに話しを戻しますが、
来年の50回大会はここ福岡での開催となります。
実は小生は実行委員として参画いたしますので、ご支援ご協力宜しくお願い致します!!
この業界に携わるようになって25年になります。
マネージメントする立場で、最も印象深いのは
Oracle+VBで2000年代にやったプロジェクトです。
印象深くなった理由は、全部で10名強のメンバーで半年かけて構築したシステムですが
大半が新人やその言語でのシステム開発の経験がほとんどないメンバーだったからです。
本来バランスよく人員体制を組むのが理想なのですが、社内メンバーの空き具合で
そうなってしまいました。
しかし、確かに苦労しましたが、知らない分、純粋でしたし、潜在能力もあったのでしょう
夜中までみんな良く頑張ってくれ、なんとか予定通りサービスインできました。
こういったいわいる、かなり忙しプロジェクトの方が一日の大半を同じ空間で過ごすため
一体感がでる気がします。が、やはりストレス溜まってくるでしょうから定期的なガス抜きは
必要だと感じます。しかし、この時のメンバーはホントガス抜きは好きでしたねー
これがうまくいった一番の秘訣かもしれません。
さて、明日からは倉敷でIBMユーザーシンポジウムに参加してきます。
iSUCのメンバーとも久しぶりに再会できそうなので楽しみにしています。
