初めてプロジェクトマネジメントに関心を持ったときにすること

ウォーターフォールアジャイル開発などのシステム開発手法に限らず、プロジェクトマネジメントはシステム開発とは切っても切れない縁がある。

プロジェクトの予算を出す側、つまり、プロジェクトオーナーの立場で見ると、切れない縁というよりは、プロジェクトをプロジェクトチームに任せておくと6割以上のプロジェクトで品質、コスト、納期のいずれか若しくは複数で計画通りにならない事態になるので、プロジェクトの状況を知りたくてプロジェクトチームにマネジメントの考え方を取り入れたのがプロジェクトマネジメント、と言っても差し支えないだろう。

エンジニアが仕事を覚え、チームの中で複数人のメンバのリードを担えるようになると大なり小なりのプロジェクトを任されるようになる。エンジニアにこうした機会が訪れると、プロジェクトを上手にやってみたいと思う(エンジニアが出てくるかもしれない)。

最初にシステム開発手法を覚えよう

 プロジェクトマネジメントに関心を持つとPMBOKの本を読めばいいのかと思うかもしれないが、まずは、システム開発手法を覚えよう。

システム開発手法を覚えるといっても、何も難しいことはしなくていい。今やっているプロジェクトで知っていることを書きだすだけでいい。

リーダーとして担当している作業ではどのようなことをしているか、それを図に描いてみよう。ウォーターフォールを採用しているなら、どこの工程から始めて、どの工程までやっているかを描けば良い。アジャイル開発ならどの開発手法でやっているか、それの進め方を図にしてみよう。

簡単でしょう。

計測しているのは何かを描き加えてみよう

描いたシステム開発手法の図に、システム開発の作業の中で計測している情報があればそれを描き加えてみよう。色付きのフリクションがあれば色を変えてみよう。

描き加えた計測している情報が誰に渡しているか情報の行き先を描いておこう。

情報の行き先は、チームないかもしれないし、スクラムマスタかもしれないし、プロジェクトマネージャかもしれない。誰に渡しているかを描ければオーケー。

情報の種類を分類してみよう

 誰かに渡しているシステム開発の情報は、次の3つのどれかに当てはまるだろう。

  • 進捗(スケジュールの計画と実績)
  • コスト(予算と使った費用の実績)
  • 品質(開発しているソフトウェアの出来)

もし、上の3つに当てはまらなければ、それはシステム開発のテーマ(機能)かもしれない。

  • スコープ(始めたときに作るつもりだった機能と実際に作っている機能)

プロジェクトマネジメントでやりたいこと

プロジェクトマネジメントでやりたいことは、進捗、コスト、品質、スコープが計画どどれだけズレているかを計測して、ズレていれば計画を見直すか、計画に近ずけるためにアクションを立てるか、そうした活動の情報を欲しい人に欲しがっているタイミングで渡す(レポーティング)ことだ。

これがプロジェクトマネジメントでやりたいこと。

やりたいことがわかったから

 さて、やっとプロジェクトマネジメントでやりたいことを確かめられた。あとは数多ある市販されているプロジェクトマネジメントの本の中から、気に入った本を読んで、使えそうなところを実践してみよう。

なんのためにプロジェクトマネジメントをしたいかがわかれば何かしら関心を持ってプロジェクトマネジメントを覚え、実践することができるようになるはずだから。

 

 

 

 

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)