書評：「アプリ開発チームのためのプロジェクトマネジメント」 稲山文孝・著

「アプリ開発チームのためのプロジェクトマネジメント ～チーム駆動開発でいこう！～」　稲山文孝・著
（Amazon.com）

なかなか面白い本である。著者の稲山文孝氏は大手SIerの（株）エクサで、プロジェクト監査・推進部門におられるベテランで、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」にもしばしば顔を出される。PM手法の展開と普及に熱心な方で、だからIT業界向けに本書を執筆されたのだろう。

世の書店にはPM関係書はすでにかなり充棟しており、拙著「世界を動かすプロジェクトマネジメントの教科書」もその末席につらなっている訳だ。だが、その多くは米国発「グローバル標準」であるPMBOK GuideⓇの解説を中心にしている。

一方、PM本の主要な読者層はIT業界人であり、PM関連団体・学会のイベントなどに行ってもたいてい参加者の8割方はIT業界だ。だが、日本のIT業界人、とくにSIerの求めるものと、米国PMBOK Guideが与える記述との間にはギャップがありすぎて、正直戸惑っている人も少なくないと思う。本書は、そのギャップを埋めようとする数少ない本の一つだろう。

本書はストーリー的な構成になっている。元々、プロジェクト・マネジメントはフェーズが進むごとに違う道具立てが必要なので、小説的な構成に向く。おまけに、図表だけでなくイラストが多い。イラストは、かわいいキャラ（全員女性）である。ちょっとラノベ風テイストともいえる。こういう本は、わたしにはとてもかけない。すごいなあ。

登場人物は4人。主人公は「ボク」こと、新入社員のシンコちゃんである。彼女を含むプロジェクト・チームは3人（他にインフラ関係のチームがパートタイムで支援することになっているが、本には登場しない）。まず、プロマネのレダさん。レダといえばギリシャ神話に登場する美女なので、後で双子の卵でも産むのか、と思ったのだがそうでもない（笑）。どうやら「リーダー」なのでレダさんという名前らしい。

もう一人は技術リーダのアキさんで、こちらの名前はアーキテクトだからアキさんなのだろう。ということは、主人公は新人の子だからシンコなのかな（登場人物の名前というのは、意外と書き手にとって悩ましいものなのである）。そして4人目は、プロジェクトを後見人ふうに見守る、優しい「先生」。先生というのは、社内研修の講師やレビューアーを務めるからで、まあPMOのメンバーとも思われる。

取り組むプロジェクトの設定は、流通業向けWeb開発である。それも、ウォーターフォールではなくアジャイル風だ。ソフト開発だけで、ハード構築は入らない（らしい）。契約形態は準委任。期間は6ヶ月間で、2ヶ月単位のイテレーションを3回、まわす計画である。

本書の解説の最大の長所は、プロジェクトを回していくために必要な知識を、4つの知識層に区分していることだ。4つとは以下の通りである(p.107)：

(1) マインドセット層
・運営ルール、朝会、対人関係能力、概念化能力など
(2) ツール＆テクニック層
・チケットシステム、カンバン、構成管理ツール、開発環境
・テスト実行ツール、エビデンス整理ツールなど
(3) システム開発手法層
・ウォーターフォール／反復／（アジャイル）スクラム／XP
(4) プロジェクトマネジメント管理層
・プロジェクト計画書、各種管理要領
・PMBOK/PRINE2/P2M

ちなみに、わたしがこのサイトで使ってきた区分では、プロマネの仕事の領域は下記のようになる：
A 「固有技術」の領域
- これは、ソフト開発では、ソフトウェア工学に相当する。プラント分野では化学工学とか機械工学、建設プロジェクトなら建築学や土木工学など。
B 「管理技術」の領域
（管理技術は、さらに二種類に区分できる）
- ハード・スキルとしての「マネジメント・テクノロジー」（WBS, CPM, EVMSなど）
- ソフト・スキルとしての「OS」層 （計画重視、言葉を大切に、契約責任制など）
両者の対応関係を整理してみると図のようになる。用語や概念は異なるが、マッピング可能になっている。

従来のIT分野のPM論の問題は、この４つの層がごっちゃに議論されがちだったことにあったのではないか。つまりアジャイルかウォーターフォールか、チケットシステムやカンバンは有効か、朝会は是か非か、プロジェクト計画書づくりに意味はあるのか、等々。これらは（互いに関係はあるが）別のレイヤーに属することだ。とくに、開発方法論はソフトウェア工学に直結している。

そして、どの開発方法をとるかによって、プロマネが重視すべきPM技法の組み合わせが変わってくる。だが、だからといって、プロジェクト・マネジメントが独立した技術領域をもっていることにかわりはない。

逆にPMBOK Guideの様な標準書は、汎用性を重んじるため、固有技術の領域には立ち入らない。しかし、それはプロジェクトマネジメント計画書が固有技術にふれなくてもいい、という意味ではない。逆である。プロジェクトの基本的な手順は、どのような固有技術を適用するかに依存している。橋の建設プロジェクトは、橋梁の工法に依存している。当たり前の話だ。固有技術と管理技術は車の両輪なのである。

ところで、本書のサブタイトルは「チーム駆動開発」である。最初わたしは、「計画駆動開発」への反語なのかと思った。だが著者によると、従来型の「指示と統制」による開発プロジェクトと対比したい、という意図だとのことである。つまり、オーケストラ型ではなくジャズバンド型を目指そう、とのメッセージが込められているのだろう。

もっとも、これはチームの人数にもよると思う。チームがたった3人なら、PMの目がすみずみまで届くし、互いに意見も言いやすい。しかしこれが300人だと、PM一人では見切れない。その結果、中間管理層が増えて、上意下達的になりがちだ。PMBOKはどうしても米国のトップダウン文化を反映して上意下達的だが、規模の大小を無視して、同じプロジェクト・マネジメント手法を使ってはいけないと、わたしは考えている。

本書では、プロジェクトチームの目標と、メンバー個人ごとの目標を立てているのもとても良い。ちなみにシンコちゃんの目標は、「自立した一人前のエンジニアになること」だ。そして、半年後には『高い目標だった』と肯定的にふりかえっているところを見ると、随分と潜在能力の高い新人なのだろう（笑）。

この種の本を書いた者の立場から見て、ストーリー作者が迷ましいのは、「どこまでプロジェクトにトラブルを起こすべきか」である。トラブルは読者を引きつけるサスペンス要素の源だ。プロジェクトがあまり平坦だと、読者はあきてしまう。しかし、問題が大きすぎると、解決方法がウルトラC的になり、リアリティが減ってしまう。おまけに書き手には、自分の登場人物は、あまりひどい目には遭わせたくない、という心理が働く（プロの作家は別かもしれないが）。難しい点である。本書ではプロジェクトは「ある意味異常な」くらい(p.211)うまく進んでいく。ここは著者の優しさなのかもしれない。

本書は文中で引用されている参考図書が多く、非常に幅広い点にも感服した。たとえば、「学習スタイルには、分析型、行動型、そして観察型の三つのタイプがある」という、Marcus Backinghamによる説(p.138-139）。これによると、
- 分析型は事前の学習時間を十分とる
- 行動型は早く未経験の環境に置く
- 観察型は手本になるベテランの傍らで仕事を俯瞰的に見ながら模倣させる
が適切らしい。

また、ふりかえりを、プロジェクト進行中の要所要所でも、また完了時にも行っている点もすばらしい。これは受注型ビジネスではおろそかにされがちだからである。とくに、「ふりかえりはプロジェクトの物事に対して行い、人に対してはしない」(p.213)という注意点も的確だ。ふりかえりには、KPT（ケプト）というチャートで表現する方法を書いている。KPTとは、Keep. Problem, Tryの頭文字で、この三つに分類してまとめるのである。

なお、本書ではアジャイル風開発のプロセスと、それに特有なマネジメント手法を学ぶことができると期待したが、それほどは感じられなかった。

最後に、本書を読んで感じた疑問点を、二つだけあげておきたい。

第一の点は、「プロジェクトマネジメント管理」という用語である。マネジメントと管理では、言葉が重なっていないだろうか？　なんだか個人的にはしっくりこない点であった。

二番目の疑問は、準委任契約なのに、PMのレダさんはなぜ一括請負風のコスト管理やスケジュール管理をしているのか？　であった。準委任契約とは、レストランで、コースはでなくアラカルトで食べるようなものだ。総コストが予算内に入るかどうかは、発注側が責任を持つのが原則ではないか。

この点について著者にたずねたところ、
「アジャイル開発ではプロジェクトの中で開発テーマを決めて、ワークロード内で優先順位の高い機能を実装します。このとき、テーマは予算内で収まるように委託元と委託先で合意しながら選択していくので、（発注側と受注側の）双方でコスト管理をしていると言えます」
とのことであった。

ともあれ、IT分野でのプロジェクト・マネジメント入門書としては、とても親切で分かりやすい本だと思う。初学者のSEの皆さんにおすすめしたい。