「プロジェクトマネジメント」を知ると幸せになれるかも
こんにちは。青木です。
これは、NEXTSCAPE クラウドインテグレーション事業本部 Advent Calendar 2018 - Qiitaの12/10のエントリです。
一年ぶりのブログ更新です！
今年の登壇
今年は、下記のような登壇を行いました。
「実践ドメイン駆動設計」 から理解するDDD
www.slideshare.net
モデリングフォーラムで登壇したもので、CodeZineで連載してきた内容を1つのスライドにまとめてみました。
HoloLensアプリ設計パターン
www.slideshare.net
HoloLensの設計について紹介してみました。
あとは、Azure Event GridについてACE等でLTしました。
このような設計、開発、技術といったテーマでの発表が多かった私ですが、開発手法や技術要素を極めるだけでは、プロジェクトを成功させることは難しいと感じています。
知っていて損はない「プロジェクトマネジメント」
最近の役割はプロジェクトマネージャだったり、プリセールスが多いです（ときにアーキテクト、スクラムマスター、プロダクトオーナー、セールス）。 プロジェクトマネジメントはリーダーだけが実行するものと思われるかもしれませんが、プロジェクトを成功させるためには、少しでも多くのエンジニア（プログラマ）も知っておくと良いと感じています。
学ぶことが難しい「プロジェクトマネジメント」
ネクストスケープではPMBOKの研修を社員が受けることになっているので、比較的学びやすい環境ではあります。
それでも、実業務の役割と乖離（自分の役割がプロジェクトマネージャでないとき、興味を持ちにくい）していることも多いため、PMBOKを学ぶことは容易ではありません。
そのような場合は、開発者の文化に根ざしたアジャイルの方法論からプロジェクトマネジメントを理解していくと興味を持ちやすいです。
アジャイル手法「XP（eXtreme Programing）」によるマネジメント
私自身もプログラムをたくさん書いていた頃に、XP（エクストリーム・プログラミング）というアジャイル手法に出会い、プロジェクトマネジメントの片鱗を学びました。
いくつかをピックアップします。
最も基本となる「４つの変数」
ソフトウェア開発には以下の四つの変数が存在します。
- コスト
- 時間
- 品質
- スコープ
特にスコープは一番管理するべき重要なものです。
この4つの変数には相互関係があります。例えば、スコープが増えると時間とコストが増え、品質が下がります。
この4つの変数を常に意識し、共通の認識を持つことが重要です。
「車の運転を学ぶ」ことに例えられるプロジェクト管理
XPでは、ソフトウェア開発の管理に必要なことを「車の運転を学ぶ」という「メタファー（比喩）」にて紹介しています。
突然車が車道を離れ、砂に乗り上げたとき、ふと我に返った。 母はゆっくりと車を車道に戻した。それから実際に運転を教えてくれた。
「運転は車を正しい方向に進ませればいいってものじゃないの。常に注意を払い、こっちへ少しあっちへ少しと修正するものなの｡」
これがXPのパラダイムである。直っ直ぐで平坦ではないのだ。物事が完壁に進んでいるように見えても、道から眼を逸らさない。 ～中略～。要求は変化する。設計は変化する。ビジネスは変化する。テクノロジは変化する。チームは変化する。チームのメンバは変化する。変化自体は問題ではない。変化は起こりうるものだ。問題は変化が起きたときに対処できないことだ。
自動車のハンドル操作と同じく、ソフトウェア開発においても、大きな修正を数回行うのではなく、小さな修正を数多くすることが重要となります。
監視とコントロールを適切に行うことで、道から外れたというフィードバックを得て、4つの変数の調整を行います。
アジャイル手法を整理した「アジャイルサムライ」
アジャイル手法をまとめた概念を学ぶには書籍「アジャイルサムライ」がおすすめです。
- 作者:Jonathan Rasmusson
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
プロジェクトの計画書「インセプションデッキ」
アジャイルサムライは効果的なプラクティスが凝縮された良い本ですが、その中でも、インセプションデッキがおすすめです。
インセプションデッキはプロジェクト立ち上げ時に作成するドキュメントです。
プロジェクトの背景、目的、優先度などを10枚のスライドで記述することで、学びます。
www.slideshare.net
上図スライドでは、ノートに解説を書いていますので、簡単にインセプションデッキを作れます。
インセプションデッキを書くことで、プロジェクトマネジメントに必要なポイントを見える化することができます。
個人的にはゴールを合意することが最も重要だと考えています。
顧客との会話に使いやすい「PMBOK（ピンボック）」
とはいえ、アジャイルの用語は開発者に近い場合も多いため、顧客との会話が成り立ちにくいことがあります。 その点PMBOKでは、IT関係者には認知されている用語が多いため、顧客と共通認識を得やすくなります。
プロジェクトマネジメントの指針「PMBOK」とは
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者:Project Management Institute
- 発売日: 2018/01/01
- メディア: ペーパーバック
プロジェクトマネジメント知識体系ガイド「PMBOK（ピンボック）」（Project Management Body of Knowledge）とは、1987年に米国プロジェクトマネジメント協会（PMI）から発刊された世界中のプロジェクトマネジメントから得られた知見や実務慣行を収集した指針です。
- 作者:鈴木安而
- 発売日: 2018/03/23
- メディア: 単行本
現在、第6版まで発刊されています。この6版からは、ウォータフォールだけではなく、アジャイルによるプロジェクトマネジメントについても多く触れられるようになりました。
うろ覚えしておけば良い「10個の知識エリア」
PMBOKのすべてを覚えることは大変ですので、まずは「10個の知識エリア」という分類があることだけ覚えておけば良いでしょう。 自分の担当しているプロジェクトに問題があった場合、どの知識エリアを掘り下げて、整理するべきかわかればOKです。
| 名称 | 説明 |
|---|---|
| 統合マネジメント | 活動の特定、定義、結合、統一、調整等を行うために必要なプロセス |
| スコープ・マネジメント | 作業の範囲を明確にするとともに、作業の遺漏や余剰を防御 |
| スケジュール・マネジメント | 所定の時間で完了するようにマネジメント |
| コスト・マネジメント | 承認済みの予算内で完了するための、計画、見積り、予算化、資金調達、財源確保 |
| 品質マネジメント | 品質要求事項の計画、コントロール、組織の品質方針 |
| 資源マネジメント | 人的資源、物的資源を特定、管理 |
| コミュニケーション・マネジメント | 情報ニーズが効果的な活動を通して充足 |
| リスク・マネジメント | 影響を与える可能性があるリスクをコントロール |
| 調達マネジメント | チームの外部から購入または取得 |
| ステークホルダー・マネジメント | 影響の強い個人やグループを特定し管理 |
詳細を知りたい場合には、先に紹介した書籍や下記のリンクを読んでみるといいでしょう。
ITの現場で発生している課題を打開することは容易ではありません。
このような困ったシチュエーションでは、自分の経験から課題や問題点を整理したくなると思います。
しかし、あえてPMBOKというプロジェクトマネジメントの基礎知識を整理したバイブルを参考にしたほうが「どの視点が漏れているのだろうか」「どのように意識合わせをすれば良いのか」「なにがうまく行っていないのだろうか」という点が明確になるメリットがあります。
ぜひ活用してみてください。
さいごに
これまでプロジェクトマネジメントを学ぶことをおすすめしてきました。
なお、プロジェクトマネージャーのスキルを学ぶには時間がかかります。
理由としては、机上で学んだ知識に加えて、周りの人を動かすだけの経験や自信といったバックボーンが必要になるためです。
しかし、時間はかかるものの、ある程度の努力を続ければ、確実に成果を出すことができます。
チームメンバー間で「このリスク対策は、軽減させる、それとも回避させる？」とか「ステークホルダーのXXさんの権力と関心度は高い？低い？」とかいった会話ができるようになるので、プロジェクトをスムーズに推進できるようになります。
これらにより、失敗プロジェクトを減らせます。
「プロジェクトマネジメント」は、自分自身とチームメンバーが幸せになれる「費用対効果の高い知識」といえるでしょう。
さいごのさいごに
ここまで話してきてなんですが、個人が獲得する技術スキルというものは、本当に地道で、真剣な努力（情熱）がいるものだと感じています。
それゆえにプログラミング、デザイン、CGモデリング、アーキテクチャ設計、英語、など一朝一夕で成長できないスキルこそ非常に大きな価値があります。
上記の記事の最後に書いていますが、
「プログラミングとは芸術です。（中略） つまり、あなたは毎日小さな奇跡を起こしながら作業を進めるのです。これは大変な仕事です。」
というフレーズに尽きるのではないかと思います。
開発者という芸術家の方に、プロジェクトマネジメントという「買い手の意見を聞いて変えてくださいよー」とか「絵のことをもっと説明してくださいよー」とかお願いするのは無粋な気もするのですが、それでも、ソフトウェア開発は顧客を含めたチームで作り上げる芸術ですので、プロジェクトマネジメントという共通のフレームワークを知ることで、みんながもっと幸せになれるんではないかなぁと思ったりしています。
以上、徒然ですが、読んで頂きましてありがとうございました。自分自身のコア技術というものを改めて見つめ直したいと思う今日この頃です。
