Software Quality.com

8.19 お知らせのコーナーに"ソフトウェアテストシンポジウム2010北海道 好評受付中! ”を掲載

ホーム
What's new
お知らせ
サイト マップ
Softwareを取り巻く状況
用語解説
要求工学
利用品質/人間中心設計
ソフトウェア品質特性
プロトタイプ
レビュー
マネジメント
Project Management
SW構成管理
books
プロセス改善
独り言・私語
training
reference
当サイトについて
お問い合わせ
★HIT Forum
プロジェクトマネジメント
プロジェクトを成功させる、いや失敗させないために、様々な手法・技法を組み合わせてプロジェクトを舵取りしていくこと、それがプロジェクトマネジメントです。

 

 
リスクに目を向けない組織

プロジェクトのリスクに目を向けない(評価して対策を立てない、終了後に振り返らない)組織はどうなるのでしょうか。
一つの方向性は、無意識のうちにリスクの少ないプロジェクトや業務を選択してしまいがちになることが挙げられます。明確に(明示する形式では)リスクを評価していないにもかかわらず、人間は感覚的にリスクを避けるように行動します。
その結果、リスクの少ないものを選択しがちになる、ということです。
リスクの少ないもの=チャレンジをしなくてすむもの、ですから、新しい能力の開発や技能の向上が得られない状況を自ら作りこんでいる、と言えそうです。
 
もう一つの方向性は、リスクが大きすぎるプロジェクト、一方的に手に負えないプロジェクトを、何の対策もなくいつもどおり受け入れてしまい、大惨事になってしまうことを繰り返すことです。
何年も、いや十数年にもわたり、「前にもこんな大惨事があったよね?」という状況が続きますが、組織としてそれらの大惨事から何かを学ばないわけです。
大惨事に立ち会ったり経験した人たちは、個人的にそのことを覚えているものの、どの時点で何をしたらよいのかまで落とし込んでいないため、結果的にいつもどおりの行動になってしまうか、個人的に対策を立てるものの、周囲との連携には至らないため、結局リスクに翻弄されます。
 
いやはや両極端ですね。
皮肉なものです。
 
プロジェクトの成功とは?

どうなればプロジェクトは成功と言えるのでしょうか。
実際のところプロジェクト成功の”意味(価値)のある”定義を明確に定めている組織はそう多くないと思います。
少なくとも顧客と組織両面に共通の価値であることが必要です。
つまり、社会的な価値や今後の業界発展に対する価値であることが必要ということです。
 
もちろん一律の定義がある訳ではありません。
いろいろな定義があっても構いませんが、例えば「赤字にならないこと」「採算がとれること」、などは組織の一方的な都合であるため意味のある定義とは言えません。
 
一つの事例として開発プロジェクトの成功について調査した結果がありますのでそれを参考にしてください。
ここでは、双方で合意した「品質」「コスト」「期間(納期)」が達成された場合に”成功”と定義しています。
 
 
1994年のレポートですが、2003年頃の日経コンピュータ記事でもほぼ同様の成功の定義と成功率となっています。
QCDすべてを満たしたプロジェクトは全体の3割程度のようです。
この現実をしっかり受け止めてプロジェクトに対応することが必要です。
 
 
プロジェクト進行に基づく分類
プロジェクトの進行に基づき分類すると、以下の通りになります。

見積 計画

進捗管理 

完了判定

評価・フィードバック

 制約条件、規模・難易度などの外的要因と体制・スキルなどの内的要因、想定されるリスクを絡めて、全体でどのくらいの工数・どのくらいの期間で製品を完成できるのかを相互に了解する過程。

一般的には、これらの結果を金額に換算して表現することが多い。

見積もり結果を参考に、作業着手段階やプロジェクト進行上の節目で、以後どのような作業を、誰が、いつまでに行うことでゴールに向かうのかを明確化する過程。

計画した結果の関係者との認識共有を含む。

計画に基づき現時点でどの程度進行しているのか、今後の見通しはどうか、問題事項や処置必要性はないのか、など現状把握と近未来予測、および関係者間のプロジェクト進行状況に対する認識共有を行う過程。 プロジェクトフェーズや各種の節目で、それまでの作業が完了し、次の段階に進んでも問題がないかどうかを判定すること。

これまで実施した結果から「うまくいったこと」「悪かったこと」「気になること」を明確化して、以降の作業に役立つ方法、手段、考え方を引き継ぐこと。

うまくいったことは維持~強化、うまくいかなかったことは再発防止や予防処置を実施することが多い。

 


 
プロジェクトマネジメントで最も重要なこと

私が感じているプロジェクトマネジメントで最も重要なこと。それは・・・
プロジェクトマネージャが自らプロジェクトの成功のためにできることは何でもする覚悟で対応すること。
顧客のために、そして自分たちのために、誰がなんて言おうと、他者に依存することなく、自らやれることを徹底的に行うこと。
自分で対応したことが、そして部下に任せたことがたとえうまくいかなくても、たとえ一時的に失敗しても、決してあきらめず、自分の責任として何とかしてやり抜くこと。
うまくいったら協力してくれた人たちに感謝し、失敗したら自分の責任としてその経験を次に生かすこと。
 
 
普段よくある事象から見るプロジェクトマネジメントで大事なこと

プロジェクトマネジメントに限りませんが、日常生活や社会的な事象や出来事の中に組織的な活動として必要な、大事なことがたくさん隠されていると感じています。 
整理することもなく思いつくがままに書き連ねていきます。
 
<前提>
プロジェクトマネジメントは、ある目的をある期日までに達成する(=効果を出す)ための営み”プロジェクト”をできるだけ効率的に成し遂げる思考、行動の集合体です。
相手は様々な価値観を持つ人間ですので、様々な手法やツールを駆使していくことだけでは求める成果を成し遂げられると思えません。むしろ、手法やツールは副次的な要素でしかないと思われます。
 
■先の見えない渋滞や待ち行列に並んだ時にどう感じるか
以前に滝のような大雨が降っているさなかに田舎に帰省したことがありました。
札幌から函館まで普段ならゆっくり走っても昼食の休憩を入れて5~6時間程度で着くのですが、一本道でもあり、大雨の影響でその日は大渋滞。
8時間程度のろのろ走って、通常ならあと30分ほどで着く距離まで来た時でした。
大雨による国道冠水のため通行止め。迂回路を通れ、の指示。まさに今そうなったところでした。
ざっと計算しても、迂回路を行くとまだ1.5時間以上はかかる。しかもこの渋滞でのろのろ状態では、何時間かかるのか想像もできない。まあ倍以上の時間は間違いないだろう。
ラジオは大雨の影響と場所的な問題が重なり、つながりにくく、はっきりと聞こえない。
トイレに出るとずぶ濡れになること必死の滝のような雨。その頃まだ幼稚園や小学校低学年だった子供達も(もちろんわれわれも)精神的に限界に来ていました。
・・・・・・・結果的に札幌を出て11時間後に実家につきました。
12時間以上運転したこともたびたびありますが、未だかつてこの時以上に疲れたことは一度もありません。
精神的にも、肉体的にもボロボロ、二度と運転などしたくない気持ちでした。
------------------- 
さて、この事例はどのような特徴を持っているでしょうか。
 
・地図もあり、現在位置も目的地も道順もすべて明確なのに、いつ着くのか見通しが立たない
・外部の連絡が途絶えており、状況や今後の動向がつかめないし、読めない
・身近な関係者の精神状態や肉体的な疲労もピークに達している
 
プロジェクトでも同じようなことが起きていないでしょうか。
大雨のようにコントロール不能の事象は別にして、コントロール可能なことでさえもコントロールせずにメンバーを上記のような状態に追い込んではいないでしょうか。
このような状況を作らないためのポイントは次回のコメントで整理します。
 
■普段から愛情を持ってちゃんと見ている人にはかなわない(リスクマネジメントの本質)
私の自宅には「みどりガメ」くんがいます。名前は”ぜにぜに”。
長女の要望で飼うことになったものの、普段のお世話は家にいる妻の仕事になっています。
もともと犬、猫などの生き物が大好きな一家なので、全員ペットへの愛情は大きいのです。
しかし、普段かめの世話をしている妻は、愛情だけでなく、自ら書籍を購入して勉強し、インターネット等で情報収集する、そして目一杯カメに手もかけているので、われわれとはぜにぜにの”見方”が違います。
ちょっとした変化にも鋭く反応し、かめの体調に注意を払っています。
下記は先日の出来事。
 
  妻:「あごの下がちょっと白くなってきてない?」
  われわれ:「そうかなぁ?そう見えないけど。どこかおかしい?」
  妻:「いや、やっぱり変だわ。病院に行ってみる。」
  われわれ:「そこまでしないくてもいいんじゃないかな・・・」
 
結果的に、水カビ病という診断。
放置すれば体の一部が欠けたり、場合によっては命に関わる場合もある病気だったのです。
(みどりガメは性格が温厚だけど病気に弱い特性を持っています)
----------------------
 
この事例で私が気がついたことは、プロジェクトのリスクや問題に早く気がつき、適切に、タイムリーに対応するためには、プロジェクトの詳細を細かく把握し、理解し、何かあれば自分で何とかする覚悟があるかどうかが決め手であるということです。
 
  手が空いたときにちょっとだけ見てみるか・・・
  何かに気がつけば、あるいは誰かが問題だと言えば動けばいいし・・・・
  まあ何とかなるだろう
 
のような腰の引けた対応、覚悟のない他人事のような対応ではまったくダメダメだということです。
これは、どんなに知識や技能がある人であっても(慢心状態では)同じことでしょう。
プロジェクトにどれだけ思い入れがあるかが、プロジェクトを失敗させない(リスクマネジメントの)決め手になるのだと思ったのでした。
 
■すでに知っている思いつきの手段で何をするつもり?(プロジェクトの振り返り)
これまでの様々な問題プロジェクトを分析する機会にたくさん遭遇してきました。
「よい実践事項を継続するために、発生した問題事項を再発させないために何を行うべきか」を把握するためなのですが、いつも例外なく出くわすのは、その場を取り繕う、あるいはやり過ごそうとするリーダや管理者の姿です。
・・・とはいえ、本人達はそのつもりがないのかもしれません。
 
私が行うのは、”よい、悪いは関係なくして、まずはどのような段階で、どんな状況になり、どのような判断や行動がなされたのか(あるいは、なされなかったのか)を事実として把握すること”=過去の事実をありのまま把握することです。
ところが、過去の事実がありのまま把握できていない状態なのにもかかわらず、”今後どうするのがよいのか”を話し始める人、それから”あれが悪かった”と決めつけるような話をする人がほとんどです。
(そんなことは聞いていないし、その時点で考えても意味がないのに)
適切な改善手段=今後どうするのがよいのか?は、現在こういうやり方でこういう結果(成果)になっているんだと腹の底から理解しないかぎり出てこないはずなのに、です。
しかも、その(思いつきの)改善手段は、その人がすでに知っている手段でしかありません。
(知らない手段は出したくても出てきませんからね)
すでに知っているけど使いこなせていない(から、そのような結果になった)手段をいくら出してきても、多くの場合は今後も解決することはありません。
 
この事例に限りませんが、プロジェクトの振り返りでは、事実情報に基づきありのままの状況を把握することが必要です。
その場をしのぐだけの、自分たちの都合に合わせる(プロジェクトの)振り返り結果(だけを確保する振り返り)では、意図的にプロジェクトの成果を高める取り組みにはなりえません。
現状をありのまま把握する、というのは、効果的な改善の大前提です。
 
ちなみに私が分析、振り返りを行う際には、あらかじめ「改善手段はあとで考えましょうね。」と説明しておきます。それでも聞き取り過程で、相手が(聞いてもいないのに)改善手段をしゃべり始めた場合には、「最初にお話ししたとおり、それはあとで一緒に考えましょうね。」と伝えて話を元に戻します。