みなさん、こんにちは。第一開発事業部に所属している江端と申します。
この記事ではアイレットで実施されたプロジェクトマネジメント研修について紹介させていただいています。
私自身のアウトプットとして、またアイレットで大切にしていることをお伝えできればと思っています。
プロジェクトの成功を左右する『立ち上げプロセス』
PMBOKで定義されている最初のプロセスが「立ち上げ」です。このフェーズではプロジェクト憲章（いわゆるプロジェクトの概要書）の作成とステークホルダーの特定を行います。
プロジェクト憲章の例
私自身、提案書として作成した経験はありますが、ステークホルダーリストの作成はまともにやったことがありませんでした。
見落としがちな『利害関係者』
ステークホルダーとは「出資者」や「利害関係者」「係争物受寄者」といったビジネスや組織や政策などに影響を与えることができる人々やグループ(引用：weblio国語辞典)のことです。ITの開発現場ではチームメンバーは勿論のこと、お客様やその先のエンドユーザーが代表的なステークホルダーですが、そのほかにも、官公庁や業界団体などもプロジェクトの成果に影響を与える重要なステークホルダーになり得ます。（過去に法改正によりプロジェクトの途中で仕様変更を余儀なくされた経験があります。💦）
このステークホルダーの特定が漏れていると、PMの仕事であるステークホルダーとの調整に大きな影響が出てきてしまうことがあります。
一番ボリュームが多い『計画プロセス』
PMBOKで定義されている2番目プロセスが「計画」です。このプロセスには全ての知識エリアでやることがあります。
5つのプロセスと10の知識エリア
今回演習でおこなったのは、スコープマネジメントのWBSの作成、スケジュール・マネジメントのプレシデンス・ダイアグラムの作成とガントチャートの作成です。
プロジェクトの全体像を『見える化』するWBS
WBSとはWork Breakdown Structureの略で、プロジェクトの成果物及び作業をより小さな要素（作業＋成果物）に分解してマネジメントしやすく視覚化する手法です。また、WBSの要素は階層構造で表し、下層の要素が全て完了すれば、その上位の要素が完了したと定義し、全ての要素を漏れなく洗い出します。逆をいうとWBSに表していないことはスコープの範囲外であるということになります。
WBSの例
プロジェクトの現場では要件定義でやること、作ることに注目しがちですが、やらないこと（スコープの範囲外であること）を定義するのも非常に重要です。私もいくつものプロジェクトで経験がありますし、自分自身もそうなのですが、お客様というのは（いい意味で）わがままで、やりたいことや実現したいことは無限に出てきます。
しかし、プロジェクトには必ず期限や予算がありますので、「お客様の『やりたいこと』を全て受け入れるのではなく、何が最も本質的な課題解決につながるのかを共に考え、『やらないこと』を明確にすることで、プロジェクトの成功確率を上げる。このコミュニケーションこそが、アイレットのPMに求められるスキルです。
今回の研修ではこの後で作成するプレシデンス・ダイアグラムやガントチャートを作成するために、大きな模造紙を用意して、一つ一つの要素を付箋に書き、貼り付けていきました。昨今はリモートワークが多くチームメンバーが物理的に１カ所に集まることが難しい場合がありますが、みんなであぁでもない、こうでもないと意見を出し合う場合はデジタルでやるよりも、アナログの方が便利ですね。
プレシデンス・ダイアグラムを作る
WBSの作成が終わったら、プレシデンス・ダイアグラム(PDM)の作成です。このPDMの目的はスケジュールで一番余裕がない工程を繋ぎ合わせたクリティカルパスを洗い出すことです。
ITエンジニアの方であれば、基本情報技術者試験などでみかけたことがある人は多いのではないでしょうか？先ほど作成したWBSの各要素を完了するには、時間が必要です。1時間で終わるものもあれば、１週間かかるものもあります。また、プロジェクトメンバーが複数いる場合、並列でできる作業はないか、プロジェクトメンバーのスキルや専門性を考慮しながら、各要素に対して作業担当者を割り振るかと思います。そして、要素同士には依存関係があり、前工程の作業が完了しないと後工程に着手ができないものがあります。
このときにクリティカルパスがより短くなるようにスケジュール組むのがPMの腕の見せ所です。
プレシデンス・ダイアグラムの例
このクリティカルパス上にある要素の時間を足し上げたものが最短でプロジェクトを終わらせることができる時間です。
ガントチャート
先ほど紹介したWBSとPDMを元に具体的な日付を入れてスケジュールに落とし込んだのがガントチャートです。この要素の数とバーの長さでプロジェクトの大きさとトータル期間がわかります。
各チーム毎にガントチャートを作成して、研修に参加した全員に対して発表を行いました。全く同じプロジェクトなのに、洗い出した要素の数も違いましたし、一番早く終わるチームと一番長くかかるチームでは4週間の差が出ました。他チームの発表を聞いて、自分たちのチームでは抜けていた要素があったり、このように表現するともっと見やすいのかと発見があったり、とても有意義なグループワークになりました。
『備えあれば憂いなし』プロジェクトのリスクを特定する
どんなに素晴らしい計画をしても、計画通りにいかないのがプロジェクトです。（笑） プロジェクトの成功に大きな影響を与える物事を予め想定しておくことがリスク・マネジメントです。
リスクというと悪い事ばかりをイメージするかと思いますが、リスクとは基準からのブレやズレのことであり、良い事もリスクに含まれます。但し、ITのプロジェクトに関しては良い事のリスクはほぼないため、考えなくて良いと講師の先生もおっしゃっていました。私も激しく同意します。
ウォーターフォール型のプロジェクトで必ずと言っていいほど出てくるリスクは先ほども出てきましたが、お客様からの要望や仕様の追加・変更です。これは決して悪いことではなく、お客様も真剣に取り組んでいる証拠だと思います。これは多くの人が経験したことがあるのではないでしょうか。
私は性格上、断ることが苦手でお客様の要望を何でも受け入れてしまおうとした時期もありました。しかし、それでは工数はかさむし、納期は遅延するし、誰も喜ばない結果になることが往々にしてあります。なので、予めリスクを特定して対策や回避策を考えておくことは重要です。
リスクの発生確率と影響度の4象限
研修では時間の都合上、スコープ・マネジメント、スケジュール・マネジメント、リスク・マネジメントしかできませんでしたが、模擬プロジェクトという実践形式で演習を行いました。
今まで携わってきたプロジェクトで、できていた事、できていなかった事を思い出しながら、楽しく進めることができました。
さて、次回で最後の記事になりますが、研修２日目に行った実行と監視・コントロールのプロセスの研修について共有できればと思います。
簡単30秒