こんにちは。
この記事は NEXTSCAPE Advent Calendar 2020 の 6 日目の記事です。
最近は、組織(プロジェクトであったり会社の組織であったり、勝手にこっそりやってるチームだったりいろいろ)のマネージャーみたいなことを、やってます。
なので、今回の記事では、プロジェクトマネージメントに携わる人の視点で、開発者や PM の人と対話の中で最近感じていることをツラツラ書いてみようかな。
プロジェクトマネージメント
プロジェクトとは
プロジェクトマネージメントをやる側の立場で今回の記事を書いているので、そもそもプロジェクトマネージメントとはって部分から入ろうと思います。
そうなると、まずは、プロジェクトとはって話ですよね。
プロジェクトは PMBOK(Project Management Body of Knowledge) にて、以下のように定義されています。
プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。
ざっくり言っちゃうと、
プロジェクトは目的があって期限がある活動なのです。
なので、毎日行う定型業務とかは、プロジェクトじゃありません。
必ず、目的と期限があるのです。
IT プロジェクトとは
IT プロジェクトの目的ってなんでしょう？
多分、多くの場合は、何らかのシステムを開発することですね。
では、このなんたらシステムを開発すること自体って、目的となりうるか？
多分、答えは No で、なんらかの目的を達成する手段として、なんたらシステムの開発が必要となることが多いと思います。
ということは、IT プロジェクトはなんらかの目的を有した活動のサブプロジェクトと考えた方がわかりやすいと思います。
で、その目的は、業務改善であったり、ユーザへの新しい価値を提供するなど、もっと広義の目的があるはずです。
この広義の目的があいまいというか、まぁー、あまり理解されてないことがあるので、プロジェクト自体が暗礁に乗り上げちゃっていわゆる失敗プロジェクトを産みだす要因の 1 つになっていると思います。
PMBOK
ぼくは、PMPの資格を有していないので、PMBOK については専門家ではありません。
ここでは、PMBOK の10の知識エリアを書いておこっと。
- 統合マネジメント
- スコープマネジメント
- タイムマネジメント
- コストマネジメント
- 品質マネジメント
- 人的資源マネジメント
- コミュニケーションマネジメント
- リスクマネジメント
- 調達マネジメント
- ステークホルダーマネジメント
このなかで、QCT の管理はだいたいみんな頑張ってるけど、統合マネジメント、スコープマネジメント、リスクマネジメント あたりを、おろそかにしているプロジェクトはちょっと危ないプロジェクトかもしれません。
統合マネジメント
統合マネジメントは、プロジェクトの立ち上げ～終結、そして監視・コントロールの全てのプロセスに関わります。まぁー、プロジェクトが健全に運営されていることのマネジメントですしね。
これをプロジェクトマネージャだけでやるってなると、プロジェクトマネージャの判断ミスがプロジェクトに影響をするので、プロジェクトチームの中でやる必要がありますし、プロジェクトの中に PMO を立てて監視・コントロールを効かせることもあります。
っていいつつ、ぼく自身このマネジメントは感覚でやっちゃってるので、人に教えることって出来ないんですよね～w
スコープマネジメント
スコープマネジメントも、機能要件だけでは不十分ですね。
プロジェクトスコープと、プロダクトスコープの両方を満たす必要があります。
プロダクトスコープの変更は、ウォーターフォールであれば変更管理だし、アジャイル開発であれば、スプリント計画会議でマネジメントする意識でやってます。
ただ、ぶっちゃけプロダクトスコープは、ある程度、開発チームに任せちゃって、プロジェクトスコープを意識してマネジメントしています。
リスクマネジメント
「リスク」って辞書で引くと
1.危険の生じる可能性。危険度。また、結果を予測できる度合い。予想通りにいかない可能性。「リスクを伴う」「リスクの大きい事業」「資産を分散投資してリスクの低減を図る」
2.保険で、損害を受ける可能性。
だそうです。
で、やっぱりこのような意味で捉えている感じで、危険の生じる可能性をリスクとしてとらえてるんだろうなーって思います。
んで、ぼくは、予想のつかないこと = リスクって思ってます。
例えば、人に仕事をお願いすることはリスクの1つです。
理由は、風邪ひいて仕事できないかもしれないし、なんか気分がのらなくて進捗が出ないかもしれないし、逆に、チームがすごく健全でチームワークがよくて、めちゃめちゃ進捗するかもしれないからです。
なので、チームビルディングを頑張って、プラスの効果になるようにリスクをコントロールしていきます。
マイナスの効果のリスクの管理も大切ですけど、プラスのリスクについてもしっかりやっておくことが必要だと思います。
プロジェクトマネジメントで感じていること
PMBOK で定義されていることは非常に多く、プロジェクトに適して必要な部分だけ使いましょうってことになってます。
ただ、その際に、不必要な部分を削るだけじゃなくて、わからない部分も削ちゃってる感じがします。
特に、プロジェクトスコープの作業を削るのはあまりお勧めできないっすねー。
ただ、この部分をやろうとするとどうしてもコストがかかるって思ってる方が多いですが、多分、これは MS 牛尾さんの以下のブログがとても効果的だと感じています。
生産性を高めるための８つの習慣
約3年位前の MS 牛尾さんのブログの記事です。
この記事では、8つの習慣について、牛尾さんとロシェルさんが対談形式で解説している動画がありますので、是非ご覧ください。
以下に、8つの習慣を引用して記載します。
- Be Lazy
- リスクや間違いを快く受け入れる
- 不確実性を受入れる
- サーヴァント・リーダーシップ
- セルフマネジメントチーム
- 従業員への信頼
- 個人の自信
- 階層関係のパワーバランス
なんでこれがプロジェクトマネジメントにも効果があると思っているのか？
なんで、アジャイル開発を取り込むための 8 つの習慣がプロジェクトマネジメントをする上で効果があるかって思う人もいると思うでツラツラと書きたいと思います。
プロジェクトが失敗する多くの場合
ITプロジェクトが失敗する多くの場合は、顧客の要求があいまいでプロダクトスコープの変更が多いということになっています。
で、それはそうかもしれないですが、大きな意味では、顧客の要求があいまいでスコープが変わる可能性があるということは、そのプロダクトのスコープは予想不可能というリスクマネジメントに回すべきものなんだと思います。
※「2.リスクや間違いを快くうけいれる」と「3.不確実性を受け入れる」の習慣に近い感覚で僕はうけいれています。
つまり、リスクマネジメントがちゃんとできてない場合に大きな失敗が起きるといっても過言じゃない。(言い過ぎ化かもだけどｗ)
で、このスコープ変更を受け入れるというのは、プロジェクトとして受け入れるべきであって、コストの変動に対してどうするのか取り決めを決めるなどリスクとして対応をしなければいけないです。
例えば、予算を多めに取っておいてもらうとか、契約の仕方と考えておくとか。
リスクマネジメントを考えるうえで、マイナスのリスクとなる要素はできるだけ早くつぶして、プラスのリスクはのばすことを考えた方がいいです。
となると、コマンド型の組織体制のプロジェクトではリスクを洗い出すのにかかるコストが大きいですし、そのタスクの当事者でないプロジェクトマネージャがリスクを拾いきることなんかできないんですよね。
ってなると、「5.セルフマネジメントチーム」「6.従業員への信頼」「7.個人の自信」あたりが重要になってきて、みんなでチームに貢献する(細かいリスクはここで排除する)ということが大切になります。
もちろん、本当に何も方向づけをしないとチームがプロジェクトの方向性と違うところに飛んでいっちゃうかもしれないので、「4.サーヴァント・リーダーシップ」が、必要になります。
「6.従業員への信頼」を実現するためには、「1.Be Lazy」が必要だと思います。Be Lazyは、さぼれってことを言ってるんじゃなくて、無駄に色んなことをやるなってことかな。
メンバを信頼していれば、メンバの心配しすぎて、これ大丈夫か？あれ大丈夫か？って確認はしなくてもいいでしょ。
ただ、逆に、抑えるところは抑えないといけないので、進捗を測る指標だけ作っておけばいいですよね。
最後に、これらの組織を運営するために必要なのは、プロジェクトマネージャが人間的に偉いってわけじゃないってことです。
プロジェクトマネージャもメンバも、それぞれロールが違うだけで、基本的にはみんな対等の関係だと思います。
もうちょっというと、プロジェクトにかかわるメンバには、顧客もいたり、自社の上司であったり、または、パートナー会社のメンバであったりと色んな人がいると思いますが、そこもロールが違うだけでプロジェクトの中では対等の関係です。
これが、「8.階層関係のパワーバランス」に近い考え方だと思います。
まとめ
と、ここまで書いていて、めっちゃプロジェクトマネジメント好きな人な感じになってますが、基本的に、ぼくはプロジェクトマネジメントは嫌いです。
だって、めんどいし、これ自体をやることは何も生産しないもんｗ
なので、最低限の管理しかしないで済むようにしています。
あと、今の SI 型のビジネスモデルでは、顧客で動いているプロジェクトのサブプロジェクトとして IT 開発プロジェクトが入るので、元のプロジェクトが腐ってると、サブプロジェクト巻き添えを食います。
プロジェクト全体のプロジェクトスコープの作業はサブプロジェクトではどうやってもカバーできないです。
そういう時は、Be Lazy!(これは、本気のオラしらね～)を発動するしかないので、そうなる前にリスクマネージメントと、ステークホルダーマネジメントをやっていくことが必要ですね。
本当に、IT を利用してビジネスを拡大していくんであれば、ユーザ企業側でプロジェクトを立てて、そこのサブプロジェクトに IT 技術サポートみたいな形でプロジェクトに参加することなんだろうけどね～。
※ つまり、いわゆる内製化
出す側は、請負でだしたいよねー。。
おまけ
補足的な記事を書きましたので、よかったらこちらもご覧下さい。
コメント