- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
三流技術者のmoiが三流プロジェクトマネージャとして働いた記録
{{outline}}
!!! はじめに
三流技術者のmoiが、三流プロジェクトマネージャになり、盛大に失敗した記録である。
失敗して、プロジェクトマネジメントに目覚め、どうすれば良かったのか、色々調べた。
細かなところは、(ばれて怒られないように) 改変およびぼかして書いている。
!!! プロジェクトマネージャになった
とある製品のソフトウェア開発の責任者となった。
実担当であり、その部分に全責任のある、いわゆるプレイングマネージャである。
といっても、当初は私一人である。
自分で仕様を作り、スケジュールを立て、プログラムを書いていた。
!!! なんちゃってプロジェクトマネジメント
未だかつて、正式なプロジェクトマネジメントの教育を受けたことがない。
いきおい、プロジェクトマネジメント「っぽい」ものをやることになる。
*作業を列挙し、Excelに入力する
*さらに分けられそうな作業内容に分割し、Excelに入力する
*その作業に必要そうな工数は「こんなもんかな？」という値をExcelに入力する
*作業の開始日、終了日をExcelに入力し、条件付き書式でガントチャートっぽいものが表示されるようにする
Excelしつこかったら申し訳ない。
こうして作ったスケジュールが遅れても、人も増えない、機能も削らないので、期限が延びる、、だけだった、、今までは。
!!! 納期が決まった
ものがまだ完成していないのに、納期が決まった。
大騒ぎ。
よく巷で?月?日発売・上映とか打てるのは、プロジェクトマネジメントがしっかりしているから。
ウチが出来るわけない。
!!! 派遣を入れた
自分一人で間に合わないことが確定した。
会社で初めて派遣社員を受け入れることに。
ところで、派遣社員には若干期待していた。
派遣社員はソフト開発だけを専門に行っている、だから技術は何でもやる自分たちに比べ、格段に上だろうと。
結局、普通だった。
いや、もしかして、派遣の使い方が未熟だったのか。
とはいえ、やはりソフト開発に工数を投入できたのは大きかった。
!!! そろそろプロジェクト完了だが、、
なんだかんだで2年遅れたプロジェクトだった。
しかし、結局なんでこんなに滅茶苦茶だったのだろう、と今思う。
もしかして、プロジェクトマネジメントがしっかりしていれば、こんなことにならずに済んだのではないか？
というのが、プロジェクトマネジメントに目覚めたきっかけである。
!!! プロジェクトマネジメントとは
そもそも、プロジェクトマネジメントとは何か？
「プロジェクト」を「マネジメントする」だろう。
では、プロジェクトとは何か？
物の本を読むと、
*「1回きりの、不確定要素のある活動」
らしい。
ではマネジメントは、
*「何とかする」
らしい。
すると、「プロジェクトマネジメント」とは「1回きりの、不確定要素のある活動を、何とかする」となる。
「何とかする」って何だ？
それは、
* 「あらかじめ決めたQCDを満足させる」
だそうな。
そしてQCDとは、
* Q: Quality。品質・機能
* C: Cost。費用
* D: Delivery。納期
の略である。
つまり、「プロジェクトマネジメント」とは
*「1回きりの、不確定要素のある活動を、あらかじめ決めたQCDを満足させるように実施する」
ということである。
!!! プロジェクトマネジメントの方法
プロジェクトマネジメント、イコール、プロジェクトのQCDを守る方法だが、どうすれば良いのか？
理想的には、次のように出来れば、QCDは守られる。
+ やるべき事を全て列挙する
+ やるべき事にかかる時間と費用を完璧に予測する
+ やるべき事を (予測したとおりに) 実施する
、、、当然、そんな素晴らしい状態で終わることはない。
+ やるべき事を見落としている
+ やるべき事にかかる時間と費用を楽観的に予測する
+ やるべき事を実施するが、予測を大幅に超えてしまう
通常は、上記の少なくとも1つ、あるいは全部が発生するだろう。
!! やるべき事の列挙
まずは、やるべき事を1つ1つ漏らさず列挙する必要がある。
やるべき事がリストされていない場合、それだけで時間 (工数) と費用が予測と大きく変わる可能性がある。
これを行うために有名なのが、WBS (Wordk Breakdown Structure) である。
ある作業Aがあるとき、作業AはA1、A2、A3という作業から構成されていて、さらに作業A1はA1.1、A1.2、A1.3、、、から構成されて、、、というあれである。
これを細かくすれば、作業を漏れなく特定できる。
作業の工数予測よりずいぶん簡単、、、なわけはない。
やるべき事はなぜやるべきなのか？
それはプロジェクトオーナーから、要求されているからだ。
もし、本当は要求されるべき事が抜けていたら？納期に間に合わない。
もし、必要ない事が要求されていたら？作業が無駄になる。
プロジェクトの失敗で一番多いのは、「やるべき事の設定が上手くいかない」ことにある。
本当にやるべき事が分かっていない。
だから、やるべき事が後から後から増えていく。
最初に決めたやるべき事は、本当にやるべき事なのか吟味せず、やるべき事や機能が多いほど良いことになり、そのまま残る。
やるべき事を正しく設定するにはどうすれば良いか？
残念ながら、それが分かれば苦労はない。
ただし、プロジェクトマネジメントの本でこんな方法が出ていた。
+ 後から、やりたいことをWBSに追加しない、と宣言する
+ やりたい事をどんなことでも出してもらうようにする
+ その中から、20%だけ採用する
(続く 2015.09.21)
{{include_html amazon_match}}
{{adsence}}
