治験バイト情報などを紹介します

治験バイト情報などを紹介します

プロジェクトマネジメント、PMBOKの考え方や失敗例をまとめて見た

プロジェクトマネジメント、PMBOKの考え方や実例

目次

 

こんにちは、今日はITやWEBに携わる人の多くが関わる、または関心があるだろうプロジェクトマネジメントについて情報をまとめて見やんした。研修で得た知識と業務経験を元にした内容をまとめるので、割と体型立てて整理されているはず、と信じています。

f:id:captainpentagon:20180417221850j:plain

 

 

プロジェクトマネジメントとその位置付け

では、早速プロジェクトマネジメントってなんですか?そして、その位置付けつまり重要度たるやどうですの?っていう話をします。まず、プロジェクトマネジメントですけど、業務には非定型業務と定型業務があります。定型業務はいわゆるルーティンワークで、非定型業務は特定の目的がありゴールが定義されているという性質があります。

 

いわゆるこの非定型業務が、プロジェクトというものです。そして、そのプロジェクトのゴールを達成するためにいろいろなことをマネジメントする時に役立つ考え方がプロジェクトマネジメントというものです。

 

一体どんなものをマネジメントするかというと、基本的にはQCDのフレームワークが有効でしょう。つまり、プロジェクトの成果物の品質、成果物を生み出すためのコスト、決まっている納期を必達するということです。

 

f:id:captainpentagon:20180417221931j:plain

 

プロジェクトマネジメントの重要性とその理由

 

プロジェクトマネジメントがどれだけ重要でなぜ重要なのかと言うと、出世していくと誰にでもできる業務ではなくて非定型の業務を任せられる機会が圧倒的に増えます。つまり、これがプロジェクトに当たります。しかも役割もメンバーではなくて、プロジェクトリーダーとしてのアサインが増えるでしょう。

 

筆者の場合も徐々にその機会が増えてきていますし、周りを見てもやはり出世している人の前年度の職務にはそういった機会が与えられています。で、このプロジェクトを成功させるにはプロジェクトマネジメントが大事になってくるわけです。

 

自社サービス型の企業でもそうですし、なおさら受託系の会社ではほぼプロジェクトマネジメントがメインの職務になりますから死活問題でしょう。顧客との交渉だとかコンフリクトをマネジメントしていくことが圧倒的にメインになるので必須の学習対象ではないでしょうか。そういう意味で極めて重要な概念です。ちなみに、高度情報処理技術者試験でもプロジェクトマネージャ試験がもっともニーズが高いとされています。

 

captainpentagon.hatenablog.com

 

PMBOKとは

少し話がそれますが、PMBOK(Project Management Body Of Knowledga)がプロジェクトマネジメントにおける理論だった知識体系とされています。応用情報でも出てくるワードですし、基本的にプロジェクトマネジメントの理論の部分はPMBOKがベースになっているようですね。

 

captainpentagon.hatenablog.com

 

プロジェクトマネジメントの理論の勘所

次はいよいよプロジェクトマネジメントの実際の中身についてです。大枠でいうと、WBS(Work Breakdown Structure)、ネットワーク図、クリティカルパス、リスク洗い出しと対策選定、ステークホルダーマネジメントが大枠になるでしょう。

WBS(Work Breakdown Structure)

これはプロジェクトで必要となるタスクの全体像を構造化する作業です。目的は、進捗の可視化やメンバー全員との認識合わせ、スケジューリングの前提作業というところがメインです。また本質的には、マネジメントの行為としてリソースの確保や納期を遅らせる、品質や要件を落とすということを上位レイヤーや顧客と交渉する際の交渉材料という意味合いが多いです。

 

これがないと、交渉もできませんし、下手すると自分自身がどこまで何をやるのかがわかりません。これはまず作って損はないですし、むしろ作れと言われることが大規模システム開発では多いのではないでしょうかね。これができると、遅れている原因究明や軌道修正が容易ですし、責任の所在も明瞭なのでトラブルも減ります。

ネットワーク図

次にネットワーク図です。これは結構初耳が多いかもしれません。端的に言うと、WBSの最下層に当たる作業を、タスクと皆してプロジェクト開始からプロジェクト終了までどんな作業がどういう前後関係を経て行われていくかを記すものです。

 

ポイントは、タスクが同時並行でできるとしても、必ずしもそれらのタスクが依存関係にはないというところですかね。つまり、AとBという作業は同時にできるけど、次の作業のCはAが終わっていればいいので作業Bは余裕がある、みたいなやつです。これは作ってみないと何言っているかわからないかもしれません。後で画像でも貼っておきます。

クリティカルパス

次は、クリティカルパスです。結構有名なワードですよね。何かというと、ネットワーク図におけるもっとも作業工数が長い経路であり、プロジェクトの最速日数になる経路です。これが終わらないとプロジェクトが終わりません。なので、メンバーのアサインなど最新の注意を払う傾向が強いです。応用情報なんかでも頻出の用語でスネ。

 

リスク洗い出しと対策選定

次はリスクマネジメントです。主にやることは、リスクの洗い出しとリスクの優先順位付けと対策選定です。これは結構ロジックの世界です。リスクの洗い出しは、クリティカルパス上で起こりうることをメインに洗い出すといいです。

 

優先順位付けは、発生確度と起きた場合の影響度を評価してその掛け算で優先順位をつけます。その数字が一緒の場合は、基本的には発生確度より影響度を優先することが多いでしょう。起きないかもしれないけど起きたらヤバイ系を潰すということですね。

 

対策は、回避、低減、転嫁、受容というフレームがあります。それぞれ、リスクが起きないようにする、起きる角度を減らす、他のものがリスクをおうようにする、リスクを飲み込むという考え方です。

 

ステークホルダーマネジメント

ここら辺は意外に浸透してないかもしれません。関係者、自分の上司や顧客、メンバーらへんをピックアップして、意思決定のメカニズムつまり人間関係や、人それぞれの癖や留意すべきことをマネジメントする行為です。

 

特に、意思決定権を持つ人が気にすることだったり、どういう人と仲がいいかなどをマネジメントするのが多いかと思います。意外とズル賢いような話ですが、みんなやっているので結構リアルに役立つのではと思います。人間は合理的に見えて、その人の中での合理性で動くので一見合理的でないような判断基準もあるものです。

 

captainpentagon.hatenablog.com

 

プロジェクトマネジメントの実例、自分のケース

はい、ここまで長く書きましたが、僕の実例をば。僕は、大規模プロジェクトを何回かやりましたが、1年前くらいのものが反省としては大きいです。業務提携系の案件でしたが、まず持って初めてすぎてわけがわからなかった!

 

しかし、プロジェクトマネジメントの考え方とその際の経験を生かして同じミスはしないつもりです。振り返ると、失敗したのが、その業務提携のシステム開発で、ステークホルダーのうちどの人がどのシステムでどんな影響を受けるのか?自分の成果物を誰にどのようにいつレビューしてもらうか?この2点だったと思います。

 

前者はそもそもシステム構成図的なものにステークホルダーを書き足せばいい話ですし、後者はヒアリングでもしてレビューの定例をあらかじめ入れればよかったなと。で、これをやる前提はやはりWBSだったろうなと。この反省は大きいです。

 

正直、理論通りにならないのが常ですが、WBS作ってネットワーク図を作ってレビューしてもらってでも品質が悪い場合は、正直レビュワーつまり上司にも責任があると言えます。なぜなら成果物を共有しているわけなので、その時に不足事項を言ってくれるのが上司の役割です。それができててダメなら上司も悪い!と自分を守れます。

 

学生が読んでいたら声を大にして言いたい!自分を守ることは大事だぜ!!そのためにも必要なアウトプットは作って上司の承認をもらうプロセスはしっかりやろう!というのが最後のアドバイスですかね。うん、結構これ役立つような気がするからかけて満足です。

 

他にIT業界で働く皆さんはいかがでしょうか?僕はもう失敗したくないです。