若手ITエンジニアのためのプロジェクトマネージャへの道 に参加してみた
今回参加したコースは 若手ITエンジニアのためのプロジェクトマネージャへの道 です。
プロジェクトマネージャの研修というと、開発経験を積んだ人が受講するという印象ですが、このコースは、若手ITエンジニアの向けのものです。
つまり、将来のキャリアパスを見据えて、若手のうちからプロジェクトマネージャがやることを学んでおこうというわけです。
このコースでは、そもそもプロジェクトマネジメントとは何か、プロジェクトマネージャとは何をするのか、プロジェクトマネージャになるために何をいつ学ぶのかについて、初歩から解説いただきました。
では、コース内容をレポートします！
もくじ
コース情報
| 前提知識 | プロジェクトマネージャを目指す方 |
|---|---|
| 受講目標 | プロジェクトマネージャになるためのスキル/キャリアパスがわかる |
講師紹介
このコースで登壇されたのは前回の「資格の使い方」でも登壇された 三好 康之 さんです。
資格対策のカリスマながら、ビジネス/マネジメント ( プロジェクトマネジメント 含む) と幅広く研修でき、どんなコースでも高い満足度を獲得
ちなみに、三好さんが翔泳社で書かれている 情報処理教科書プロジェクトマネージャ は、過去になぜか発行部数が受験者数を上回る、ということがあるほど、定番の書籍です。
このコースについて
講師紹介に続き、このコースの狙いを紹介いただきました。
- 新人が受講することが多いコース
- 経験者には簡単すぎるので、その場合は体系化しながら知識の整理を
- マネジメントの勉強として、”いつ”、”何を” するのかを理解する
- プロジェクトとプロジェクトマネージャの定義がわかる
※どうせなら、言葉の “定義” にはこだわる。同じ言葉でも、自分と相手で意味が違うケースが多いから
プロジェクトの進め方
まず、システム開発プロジェクトはどう進められているのか、解説です。
ウォータフォールとアジャイル
まずは定番のウォーターフォールから。
- システム化の方向性
- システム化計画
- 要件定義
- システム設定
- ソフトウェア設計、プログラミング、ソフトウェアテスト
- システムテスト
- 運用テスト
- 運用
- 保守
また、現在はアジャイルでのプロジェクトも増えています。
ここでウォーターフォールとアジャイルの違いをまとめて頂きました。
- ウォーターフォール：プロセスを 1 つ 1 つしっかりこなして次の人に渡す
- 役割分担がしっかりしている
- 大規模プロジェクトに向いている
- 大規模なプロジェクト = 500 人月以上 = 5 億円以上
（JUAS 一般社団法人 日本情報システム・ユーザー協会 の定義）
- 大規模なプロジェクト = 500 人月以上 = 5 億円以上
- アジャイル：「短期間で一気に仕様を考えて、作って、リリース」を繰り返す
- 例えば、スマホアプリ
- 期間がたつと機能や画面が修正･追加されている
- 短サイクルのフィードバックを受けて開発する
- 例えば、スマホアプリ
ウォーターフォールではプロセスごとに担当がいます。一方でアジャイルでは少数で仕様～開発～リリース～改善までやります。そのため、アジャイルではプロジェクトマネジメントよりも、全員が自律的に稼働することが求められます。
ただ、マネジメントとは人を動かすことなので、その観点では、アジャイル開発プロジェクトでも必要です、と三好さんから補足されました。
プロジェクトマネージャ とは？
さて、前段の開発プロジェクトの進め方をもとに、ここからはウォーターフォールでの開発を前提にお話します。
- システム開発と役割
- 情報処理技術者試験の試験区分がとてもわかりやすい
IPA 独立行政法人 情報処理推進機構：試験制度：試験区分一覧より
- 情報処理技術者試験の試験区分がとてもわかりやすい
- プロジェクトマネージャ
- IPA 独立行政法人 情報処理推進機構：制度の概要：プロジェクトマネージャ試験 2. 業務と役割 より
- 情報システム又は組込みシステムのシステム開発プロジェクトの目標を達成するために、責任者として当該プロジェクトを計画、実行、管理する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
- 必要に応じて、個別システム化構想・計画の策定を支援し、策定された個別システム化構想・計画に基づいて、当該プロジェクトをマネジメントする方法をプロジェクト全体計画として作成する。
- 必要となる要員や資源を確保し、プロジェクト組織を定義する。
- スコープ・予算・スケジュール・品質・リスクなどを管理して、プロジェクトを円滑にマネジメントする。進捗状況を把握し、問題や将来見込まれる課題を早期に把握・認識し、適切な対策・対応を実施する。
- プロジェクトのステークホルダに、適宜、プロジェクト全体計画、進捗状況、課題と対応策などを報告し、支援・協力を得て、プロジェクトを円滑にマネジメントする。
- プロジェクトフェーズの区切り及び全体の終了時、又は必要に応じて適宜、プロジェクトの計画と実績を分析・評価し、プロジェクトのその後のマネジメントに反映するとともに、ほかのプロジェクトの参考に資する。
この IPA の説明の通り、プロジェクトマネージャは要件定義からシステムテストまで担当します。ただし、それぞれの作業をするのではなく、作業する人をマネジメントします。
注意したいのが、プロジェクトマネージャをしながらプログラミングもしているという人は、あくまで兼務であり、それぞれの仕事とプロジェクトマネージャとは別物です。テストをするのがプロジェクトマネージャだとか、要件定義するのがプロジェクトマネージャだとか、誤解があることがありますが、それは違うとのことでした。
ちなみに、今回のコースでは文書を受講者に読んでもらい、その間、講師は待つという場面が何度かありました。三好さんがオンサイト（実地開催）の形式でも多用されているテクニックですが、オンライン研修でも、その文書に興味を持ってみることができました。
これは、三好さんが常日頃口にしている…「読めば理解できることを、いちいち説明する必要はないし、そういうものは自分で獲得しに行かないと身につかない」という部分なのでしょう。
プロジェクトマネージャの定義
情報処理技術者試験での定義をもとに、三好さんがプロジェクトマネージャの定義を次のようにまとめました。
- 計画できる人
- 計画的に人を動かせる人
- 人を動かして計画どおりの結果を出せる人
ここで、三好さんからこれから学ぶ上で注意すべき点をお話いただきました。
「我流と応用は違う」
「応用できる人は信頼されるが、我流の人は信頼されない」
- 応用とは、基礎や標準を知ったうえで相手にあわせてアレンジやカスタマイズができること。したがって、次も再現できる期待が持てる
- 我流の人は、再現性がない
- 成功していても次のプロジェクトがうまくいくかわからないので怖い
プロジェクトマネージャをやる上で怖いのは、プロジェクトを成功させられなかった場合で、それが原因となりメンタルを壊しがちです。
また、日本ではマネジメントを学んでいない人がマネジメントをやらされることも多く、それも問題になります。
では、 プロジェクトの成功 とは何でしょうか？
プロジェクトの定義
プロジェクトの成功を定義する前に、そもそもプロジェクトとは何か、定義を確認しましょう。
- 繰返しのない 1 回限りの仕事であること
- 期間が限定 = 「納期」が決まっている ( Delivery )
- 納期はプロジェクトの成功と失敗を決める要因の一つ
- 目標成果が設定されること ( Quality )
- あらかじめ決められた「品質」どおりに作られているか
- 予算が決められていること ( Cost )
- 経営者は、そのシステムを使ってどう利益を上げるかを考えて、「予算」を考える
- 予算という言葉通り、予め算定したコストに収まっているか
Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字をとって、生産管理では QCD と呼ばれるものですね。
この 3 つの基準を満たすと、「プロジェクトが成功した」と定義されます。
何を学ぶのか？
次に、プロジェクトを成功させる術、プロジェクトマネジメントは、何で学べばよいのでしょうか。
三好さんから、プロジェクトマネジメントが学べるものを順番に紹介いただきました。
- PMBOK ® ( Project Management Body of Knowledge )
- プロジェクトマネジメントのノウハウを体系化したもの = 分類、階層化さているもの
- 体系化されてなければ、自分で試行錯誤して、体系化しなくてはならない
- 体系化されていると、学びやすい、覚えやすい
- BoK ( Body of Knowledge ) という言葉そのものが体系化を意味
- 国家試験も認めたもの
- ただし厳密に言うと ISO 21500 に準拠と記載
- ISO 21500 は PMBOK ® に同期している
- 注意したいのは現場ではカスタマイズ（= テーラリング）してね、というところ
- あくまで抽象化されていたもので、具体化できる深い知識が必要
- プロジェクトマネジメントのノウハウを体系化したもの = 分類、階層化さているもの
- 情報処理技術者試験プロジェクトマネージャ
- PMBOK ® はあくまで教科書
- 情報処理技術者試験のプロジェクトマネージャはケーススタディ
- このケーススタディで具体化された深い知識を学ぶ
- 他人の経験
- “他人の失敗経験” から学ぶ
- インターネットで検索できるようになってきている
- 前提知識があるので有象無象の記事から取捨選択できる
- あるレベルを超えると、知りたいことがググっても出てこない = 第一人者になった証
- 自分の経験
- インターネットにはない貴重な経験 = 褒められる失敗
- それが価値になる
なんでもかんでも自分の経験から学ぶのは大変です。他人の失敗体験を学ぶことにより、将来に直面するかもしれないリスクを知り、引き出しを増やすことが重要だと三好さんは強調しました。
三好さんはこれを、有名な格言の「愚者は己の経験に学び、賢者は他人の経験に学ぶ」という言葉で例えました。
さらに意識しておくべきこととして、叱られる失敗と褒められる失敗についても語られました。
- 勉強不足による失敗は “叱られる失敗”
- 教科書に既に書いている失敗は “避けられる失敗”
- 自分しか経験したことのない失敗は貴重。”褒められる失敗”
- 優秀な上司は上記の基準で叱るべきか否かを判断するる
- 優秀でない人はお客さんの顔色しだいで判断する
- そういう人相手だと、こちらも顔色を見なくてはいけない
それを、いつ学ぶのか
では、いつからプロジェクトマネジメントの勉強を始めるのがいいのでしょうか。
スキルアップや知識の獲得はタイミングが全てです。適切なタイミングで学べば、それは使える知識になりますが、タイミングを誤ると…無駄になるとまでは言えませんが、時に不幸になることも。
一般的なキャリアの例で見てみます。
- 入社 1 年目〜 3 年目：プロジェクトメンバー
- マネジメント能力は必要なし
- 3 年目〜 5 年目：チームリーダー
- マネジメント能力はやや必要
- 5 年目から：プロジェクトマネージャ
- マネジメント能力は絶対に必要
マネジメント能力が必要になってから学ぼうとすると、ストレスやプレッシャーが大きく、低評価のもとで、メンタルを壊すことにもつながると三好さんは言います。必要になった段階では遅いというわけです。
- 必要ないときから勉強する。必要ないからこそノーストレス・ノープレッシャーで勉強できる
- 必要になるまでに基礎を勉強しておけば、他人の経験が見える
→ 先輩ＰＭの動きが見えるようになるので、労せずして知識が獲得できるようになります。- 十分な準備期間になる
- 自分の経験に生かせる
なお、必要ないうちから勉強して学んだことは、全部使えなくても問題ないと三好さんは説明しました。
まとめ
このコースは、若手ITエンジニアにプロジェクトマネージャへのスキルアップ、キャリアアップの方法を教えるというものでした。
若手のうちは、マネジメントといっても具体的なイメージやキャリアパス、必要な知識などがわかりづらいかもしれません。
それに対してこのコースは、プロジェクトマネージャとは何か、何を勉強すればいいか、なぜ若手のうちから勉強したほうがいいか、といったことを、わかりやすく説明していました。
自分のキャリアを考えるにあたり、プロジェクトの一メンバーでは意識しない “プロジェクトマネジメント” というスキルについて、理解と目標が明確になったのではないでしょうか。
また、コースの中で、直接は詳細な解説が無かったのですが、参加資料では PMBOK ® の全体像もまとめられていました。受講後にまず取り組む課題が示されているのも、三好さんらしい配慮かも知れませんね。
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。