社会、経済 競争力強化 マネジメント ビジネス 企業改革 管理手法 CSR コンサルティング IT戦略 IT-ROI 組織・人材 思考法 SLCP 上流工程 方法論 ソフト品質 モデリング、SOA プロジェクト IT基盤 運用管理 内部統制 コミュニケーション  ナレッジ 情報理論 ERP SCM セールス、SFA マーケティング 製造業 流通業 サービス業 ネットビジネス  IT入門 SE ITソリューション ワークスタイル 今週のブックガイドへ

■プロジェクトマネジメント

すりあわせの重要性とその技術を「読み物」で解説
次世代プロジェクトリーダーのためのすりあわせの技術
●山本 修一郎＝著 ●ダイヤモンド社　2009年3月 ●1400円＋税　978-4-478-00799-0
	プロジェクトやビジネスをよりよく遂行し、イノベーションを起こし、大きな価値を生み出すためには「すりあわせ」が必要だ。本書でいうすりあわせとは、新幹線の先端の「丸み」を手作業によって作り出すような職人技術的なものと、調整的な意味とを足したものだ。そのすりあわせの重要性とそれを技術として身に付けるヒントを物語風にまとめる。 よりよいビジネスを創出するために「すりあわせ家」は、“オープン・イノベーション”を意識する必要がある。人や知識を自組織内に「所有」し、そこから生まれる知恵や成果を所有して内部にとどめるクローズド・イノベーションと違い、オープン・イノベーションは、「所有」から「利用」へパラダイムをシフトする。自社の資本の範囲でのみ生み出されたものは、使うことができる範囲も狭まるが、「他者」と組めば相互作用が起き、技術であれシステムであれ、それは大きな広がりとなり、価値は最大化する。 チームメンバーとのすりあわせ、顧客とのすりあわせ、双方のキーとなるのは「顧客要求」の明確化だ。利用者がサービスによって実現したいこと、つまり要求をしっかりとらえていれば、サービスの方向性も明確になり、利用者も「よい」結果が得られる。利用者の満足度は高くなることで、そのサービスを開発したメンバーも顧客からよいフィードバックを得られるため、心地よい「達成感」が得られる、と説く。 ほかに、すりあわせ家に必要なものとして、「価値指向」「顧客指向」「活用指向」「要素分解力と結合」など7つを取り上げる。専門家とのコラボレーションの参考に。（ライター・生井俊）

アジャイルな見積りと計画づくり――価値あるソフトウェアを育てる概念と技法
●マイク・コーン＝著／安井 力、角谷 信太郎＝訳 ●毎日コミュニケーションズ　2009年1月 ●3200円＋税　978-4-8399-2402-7
	アジャイル開発が、アーリーアダプターだけでなく、メインストリームにも受け入れられるようになったことで、アジャイル・プロジェクトにおける見積もりと計画づくりがより一層重要になってきている。本書では、アジャイル開発プロセスで、いかにして目標の不確実性と方法の不確実性の両方を軽減させるかを整理している。 アジャイル・プロジェクトの規模の見積もりには、ストーリーポイントとベロシティを用いる。ストーリーポイントは、ユーザーストーリーやフィーチャ、そのほかの作業の大きさを表わす単位だ。ストーリーポイントの数値は、ストーリー全体の規模を表わすもので、ほとんどのストーリーを1から10の範囲に収めるために、中くらいのストーリーには5ポイントを付ける。この単位を持たせずにプロジェクトを進めるときは「ベロシティ」を導入する。これは、チームの進む速度を表わすものだ。 プロジェクトでは何もかもをやれるだけの時間があることはほとんどないため、「金銭価値」「コスト」「開発を通じて学べる知識の量とその意義」「リスク」という4つの観点からフィーチャの優先順位付けをする。この4つの要素の中でも、第1に考えるのはフィーチャの価値と、そのフィーチャをいますぐに開発するのにかかるコストを比較すること。テーマごとに暫定的な優先度をつけ、その結果、コストに対して最も高い価値を持つテーマから着手すると良い、と説く。 このような価値のための計画づくりやスケジュールの立て方、トラッキングと情報共有のほか、なぜアジャイルな計画づくりがうまくいかないかにも言及する。本書は300ページを超えるが、身近な例を紹介しながら分かりやすく、利用しやすい体裁に仕上がりになっている。（ライター・生井俊）

抜群にプロジェクトを成功させる技術――PMBOKの科学的理解で培う実践力
●桑原 高雄＝著 ●技術評論社　2009年1月 ●2280円＋税　978-4-7741-3716-2
	プロジェクトには1つとして同じものはなく、過去の成功体験だけ頼りにしても、同じ結果は得られない。本書は、そのプロジェクトマネジメントの仕組みを「プロジェクト目標達成メカニズム」として科学的に読み解いていく。これを通じて事実上の世界標準であるPMBOKの背景に隠れ、暗黙の前提となっている理論や原理原則を明らかにする。 現実世界では、計画に含まれる不確実性のため、計画どおりに実行することは困難で、結果的に計画（ベースライン）と実績に差異が生じる。予実差異が生じると、プロジェクトの実態はベースラインから乖離（かいり）し、プロジェクト目標の達成から遠ざかる。そこで、手遅れになる前に実態がベースラインに回帰するように制御することが必要だ。この制御方法をフィードバック制御といい、予測に基づくフィードフォワード制御と組み合わせることで「的中率」が飛躍的に向上する。 また、システム規模を緻密に見積もるためにはIFPUG法（標準的なFP法）を用いるが、その時点で要件が明確になっていて、見積もりに必要な情報が抽出されていることが必要だ。つまり、見積もりのタイミングは、要件定義が終了し基本設計がある程度できている時点で行うべきだが、実際はそれよりも早い段階から見積もり数値を要求される。そのために、提案から要件定義ではFP試算法を、要件定義から基本設計ではFP概算法を、そして基本設計以降はIFPUG法を用い、プロジェクトの進ちょくに合わせて見積もり精度を高めていくべきだ、と解説する。 フィードフォワード制御・フィードバック制御を用いた目標達成メカニズムやソフトウェア開発を紹介するほか、後半ではPMBOKのプロジェクトマネジメント・プロセスについて詳述している。これからプロジェクトマネジメントを学ぶ人だけでなく、人材育成に携わる人にも活用できる内容だ。（ライター・生井俊）

実践「経営プロジェクト」講座――会社の未来づくりに、取り組む人のための実践テキスト
●鈴木 成裕＝著 ●プレジデント社　2008年11月 ●1600円＋税　978-4-8334-1896-6
	プロジェクトをどう設定し、立案をどう進めるか、問題に直面したときにどう対応したらよいのか――。本書はそういった悩みについて、実際の思索と体験に基づいた対策をまとめた、プロジェクト成功への手引きだ。 今日のプロジェクトリーダーシップは、これまで考えられてきたプロジェクトマネジメントとも、日常のラインマネジメントとも異なる。というのは、時代の移り変わりもあって、ぶつかってくる問題の強度や複雑さが異なってきているからだ。これからのプロジェクトリーダーの資質が何かといえば「牽引（けんいん）力」がある人が好ましい、という。牽引力とはいろいろな能力で構成されているもので、例えば「構想力」のような力があると、困難な決定を行うことができる。 多くの会社で問題になっている戦略の不徹底は、戦略ユニット導入を通じて、組織戦略行動力を強化することで大幅に改善される。また、組織ニーズに対応するような教育の刷新という問題は、プロジェクト型研修制度を導入し、現代のニーズに合うよう教育研修を現代化していく。どのような組織を作るにしても、そこに戦略に関心を持ち、プロジェクト推進力を持つ人がいなければ、その組織は無効だと説く。 タイトルに「講座」とあるように、プロジェクト推進にあたって課題になっている部分を拾い読みできるのも特徴。将来の会社をどう作るかを見据えながら、この本を活用すると生き生きとした改革プロジェクトが出来上がるかもしれない。（ライター・生井俊）

オフショア開発に失敗する方法――中国オフショアのリスク管理
●幸地 司＝著 ●ソフト・リサーチ・センター　2008年9月 ●2800円＋税　978-4-88373-267-8
	ソフトウェア技術者の社会的な地位が高い中国やインド、ベトナムといった新興国とは対照的に日本では成り手の少なさもあって、IT高度人材の不足が指摘されている。顧客からの開発費削減の圧力を受け、下流工程の海外委託が加速していることもあり、本書ではオフショア開発の問題解決に直結するマネジメントの知識体系をまとめる。 日本企業のオフショア開発には、中国を見下す姿勢や丸投げする態度など、根強く存在する問題がある。しかし、それらは中国側の品質問題の陰に隠れてしまい、いままでほとんど疑問視されてこなかった。それらを含め、中国側が感じるオフショア開発の問題点は「仕様のまとめ能力不足」「仕様変更の段取りの悪さ」「担当者の技術力不足」「理不尽な条件の押しつけ」の4つに分類される。それを解消するためには、日本型開発アプローチのあいまいさを自覚したうえでの「スケールメリットの追求」と「長期的展望に立った投資」が鍵になる。 外国人ブリッジSEへの指示伝達では、美しい日本語ではなく“伝わる”日本語を書く技術が求められる。日本人技術者の文章がヘタな理由について、著者は「論理的思考力が未熟」なだけでなく「多様性の欠如」を指摘する。後者についていえば「あいまいな文章が氾濫するのは、何も日本人に限ったことではない」という反論も聞くが、オフショア開発で発生する問題解決にはつながらない。日本人が犯しやすい誤りや日本語固有の問題は実在しており、これを素直に認めることが日本人IT技術者の文書作成能力を向上させることにつながる、と説く。 プロジェクトの問題点をあぶり出し、遂行するうえでの留意点、異文化コミュニケーションの基礎理論、そしてオフショア開発を成功に導く行動特性を提示する本書。オフショア開発のノウハウが蓄積されていない企業でも、失敗例を通して成功に近づくヒントが得られそうだ。（ライター・生井俊）

ソフトウェア業における工事進行基準の実務
●岩谷 誠治＝著 ●中央経済社　2008年6月 ●2800円＋税　978-4-502-28580-6
	2007年12月、企業会計基準委員会から「工事契約に関する会計基準」および「工事契約に関する会計基準の適用指針」が公表された。「工事契約」とあるが、この基準の適用範囲には「受注制作のソフトウェア」も含まれる。そこで、ソフトウェア業を対象に新会計基準への対応方法をまとめたのが本書だ。 経営者は、企業経営の指針として会計を用いているが、新しい工事契約会計基準は、会計の使い方を根本から変えるもの。特に、工事進行基準への対応もさることながら、工事損失引当金の計上が規定されたことにより、損失を先送りするような処理は今後認められなくなる。また、プロジェクトマネージャ（PM）や管理職層は、従来の業務プロセスや取引慣行の抜本的な見直しが必要だ。 新会計基準導入にあたって注意すべきポイントは、「会計上の問題ではなく、経営上の問題という認識」「会計システムへの影響の把握」「スタッフの会計知識向上」という3点。自らの業務上の判断が、自社の最終的な財務諸表にどのような影響を与えるかを理解していなければ、精度の高い見積もりや判断作業を任せることは危険だ。このような矛盾した問題を解決するためには、スタッフレベルの会計知識を底上げする施策が求められる、と説く。 工事契約に関する会計基準、工事契約の税務上の扱い、内部統制との関係、導入時の留意点などを簡潔にまとめている。影響範囲を正確に理解できる、経営者やPM向け参考書だ。（ライター・生井俊）

［改訂版］実践！ プロジェクト・マネジメント
●中嶋 秀隆、津曲 公二＝著 ●PHP研究所　2008年5月 ●1300円＋税　978-4-569-69941-7
	ここ数年、プロジェクトマネジメントに関する認知が急速に広まり、ビジネスパーソンの必須スキルになりつつある。本書は2004年のPMBOK「第3版」と、2007年のP2Mの「新版」の新しい動きを踏まえ、プロジェクトを成功へ導くためのヒントをまとめる。 プロジェクト目標を明確にするためには、真のニーズを把握し、そのニーズに合致した最終成果物を決めることがポイントだ。成果物と併せて「完了・成功の判断基準」「スペック・品質基準」「プロジェクトの依頼者やエンドユーザーにもたらす利益」「プロジェクト実施にあたっての絶対条件と相対条件」を盛り込む必要がある。 プロジェクトを「見える化」するときに有効なのが、ガントチャートや負荷ヒストグラムだ。これらで問題点を見える化（ビジュアライズ、可視化）して、解決策を提示すればよい。プロジェクトの参加メンバーは、プロジェクトの成功に貢献し、それによって対価を受け取る立場にある。「困った、困った」というのではなく、問題点を可視化して説明し、ステークホルダーの合意を取り付けることが、プロジェクトマネージャに求められる、と説く。 後半、「スケジュール案」「逆線表」「ヒアリング」「質問力」など、プロジェクト・マネジメント成功のための10のポイントをまとめている。（ライター・生井俊）

ソフトウェアの規模決定、見積り、リスク管理
●ダニエル・D・ガロラス、マイケル・W・エヴァンス＝著／富野壽、荒木貞雄＝監訳 ●共立出版　2008年4月 ●4700円＋税　978-4-320-09751-3
	ソフトウェアの規模決定（サイジング）と見積もりに関するリスクは、多くの失敗プロジェクトの根本原因となっている。本書では、さまざまなソフトウェア規模決定技法におけるコスト・スケジュール・管理・制約から生ずるリスクなどを探究し、よりよい見積もり実施とプロジェクトリスク低減について解説する。 第1章では、ソフトウェアプロジェクトの見積もりはなぜ失敗するのかを紹介する。そこでは、技術課題というよりも粗雑な計画により失敗している現実が浮かび上がる。それを受け、第2章から第4章では、ソフトウェア見積もりのリスク管理に役立つプロセスを示す。「見積もりの範囲と目的を規定する」ことから始まる見積もりのプロセスは、合計10の段階を経て作成されるとよい。 第10章では、リスク管理プロセスを扱う。リスク管理はリスクの識別、評価、監視、軽減のプロセスを実行することで達成され、システム開発、フィールド展開、引き渡し後の保守と支援を通して不測事態への対応を行う。計画と実践が容易にできるリスク管理プロセスとして7つの段階を示し、7段階がその順序で行われる必要はないが、継続的に定期的に実行されることで、ソフトウェアプロジェクトの成功確率が著しく高まる、と説く。 現在広く用いられている規模の見積もり・決定手法を網羅するだけでなく、見積もりにかかわるリスク管理や見積もりの確率の問題にも言及しており、コスト削減をしながら短期間で高品質のソフトウェア開発を求められるプロジェクトに携わるPM／PLにとって役立つだろう。（ライター・生井俊）

情のプロジェクト力学――人を中心に考える最強マネジメント論
●林 衛＝著 ●実業之日本社　2008年4月 ●1500円＋税　978-4-408-41128-6
	IT企業にとって、複雑化するプロジェクトへの対応が大きな課題になっている。複雑なプロジェクトには、高度な技術と技術者が必要で、マネジメントを行うための方法論も重要だ。とはいえ、プロジェクトを進めるのは人であり、プロジェクトの問題を突き詰めると「人の問題」にたどり着く。本書では、プロジェクトマネージャ（PM）をはじめとする「人」にスポットを当て、複雑化するプロジェクトを成功に導くためのヒントを記す。 失敗するプロジェクトは、総じて入り口から間違っていて、プロジェクトの本質を理解していないことにある。プロジェクトでPMがまずすべきことは、「プロジェクトで成功する」というメンバー共通のメンタルモデルを明確にすること。プロジェクトの本質を理解して、プロジェクト成功のメンタルモデルを共有しようというとき、PMの姿勢はメンバーに強く影響する。プロジェクトは価値ある何かを創り出す活動だからこそ、活動自体に価値があると理解することで、「失敗するかも」という考えは無意味だと気付ける。 プロジェクトの進行中に、何らかの方向修正を決断しなければならないとき、PMの勘が働くかどうかがカギになる。PMに必要な勘とは、閃きではなく、「土地勘」のようなものだ。ITプロジェクトの土地勘とは、ITについて明るく、豊富な経験によって育まれた状況判断能力のこと。それを鍛えるためには、理論だった考え方を持って仕事に打ち込み、何度も成功、失敗を繰り返すことでその勘が働くようになる、と説く。 PMのほか、ITアーキテクトについても言及する。また、後半の異文化に学ぶ強い人、組織についてでは、インドを中心に世界の技術者動向を紹介、日本のIT業界の立ち位置について気付きを与えてくれる。（ライター・生井俊）

ITプロジェクトを失敗させる方法――失敗要因分析と成功への鍵
●中村 文彦＝著 ●ソフト・リサーチ・センター　2008年1月 ●1900円＋税　978-4-88373-253-1
	ITプロジェクトの失敗は、プロジェクトマネージャの能力だけでなく、さまざまな要因が複雑に絡み合っている。本書では、プロジェクトの失敗をあらゆる観点から分析。具体的な事例を交えながら、失敗の発生要因を考察する。 ユーザー企業が果たす役割の中では「超上流」が最も重要だ。そこでの失敗要因としては、経営者の関与の弱さ、ユーザー側のとりまとめ役の不在、あらゆる技術スキルの不足などが挙げられる。一方、ベンダ企業の失敗要因は、自分の言動が与える影響力を経営者が理解していないこと、問題の先送り、間違った顧客志向、そしてリスクに対するレビューが行われていないことなどにある。 成功への鍵とするためには、ユーザー企業が無理な契約条件をベンダに強要しないこと、組織改革プロジェクトを実施することが必要。ベンダ企業は、受注審査に関するルールと手順を定める、「提案・受注プロジェクト」を立ち上げる、そしてこのプロジェクトにたずさわる者は、責任が重大であると認識することが重要だ、という。 本書は、事例が豊富で読みながら「なぜ失敗するのか」を疑似体験することができる。そこから気付きが生まれれば、プロジェクトを成功へ導く確度もずいぶん違うものになるだろう。（ライター・生井俊）

ソフトウェアプロジェクトの救済入門――危機的状況に陥ったプロジェクトを救う実践的アプローチ
●エドウィン・M・ベナタン=著／富野 壽・荒木 貞雄=共訳 ●構造計画研究所　2008年1月 ●2700円＋税　978-4-320-09750-6
	ソフトウェアプロジェクトが重大なトラブルに見舞われたとき、開発組織は「プロジェクトをどのように実行すべきだったか」を振り返るべきだ。本書では、そのときに役立つのはPMIやISOなどの業界標準的なアプローチではないという観点から、「何とか助けてくれ！」となったプロジェクトを軌道に戻すための「10段階の救済」を示す。 ソフトウェアプロジェクトの破局とは、ちょうど列車が自分に向かってくる状況に似ている。列車が来るのは見れば分かるし、適切な手段を用いれば、危機が訪れることは相当早期に知ることができる。同じように、ソフトウェアプロジェクトでも、スケジュールと予算の警告、ソフトウェア品質に関して問題リストや顧客満足度の警告を設定することで予測可能だ。それだけではなく、これらの客観的な尺度に加えて、「常識」と「主観的配慮」で補完していく必要がある。 先進的ソフトウェア開発プロセスを成功裏に用いている組織では、早期警告システム（EWS）の要素すべて、あるいはほとんどが存在する。その構成要素とは、「開発データの収集」「定期的なプロジェクトステータスのレビュー」「警告の発動」「是正行動の開始」「フォローアップ活動」の5つだ。本書では、EWSのすべての要素は、最初は非常に単純でよいが、専門家の助けを得て導入すること。そして、それらを次第に拡張し、洗練されたものにするとよい、と解説する。 トラブルの段階に応じて各章を読めば理解できる構成になっており、火消しだけでなく、プロジェクト終了後に再発防止につなげるための「事後検討」についても扱う。各章のまとめを拾い読みするだけでも多くの気付きがある。（ライター・生井俊）

プロジェクトは、なぜ円滑に進まないのか
●メアリー・グレース・ダフィー=著／大上 二三雄=監訳／松村 哲哉、上坂 伸一=共訳 ●ファーストプレス　2007年12月 ●800円＋税　978-4-903241-67-8
	プロジェクトマネジメントは、包括的かつ緻密な計画づくりが要求されると同時に、不測の事態に対処するための柔軟性も持ち合わせている必要があるなど、矛盾に満ちている。本書ではプロジェクトマネージャの強みを伸ばし、足りないスキルを補完して、明確で整った道をたどるためのアドバイスと、プロジェクト管理に役立つツールを提供する。 　プロジェクトの利害関係者を特定できたら、実際に会い、どのような成果を求めているかなど意志を確認しておくことが後々参考になる。この段階で必ずやっておくべきことは、利害関係者が期待していることを総合して、実現可能な、一貫性のある目標にまとめることだ。プロジェクトの途中で利害関係者が変わり、プロジェクトの方向性見直しにつながるような決断を行うときは、新しい利害関係者だけでなく、すべての関係者を含めて考えることが大切になる。 　プロジェクトの成功は、どの程度目標を達成できたかで決まる。最初に目標をきちんと確認しておけば、最終的にどの程度達成できたかもはっきりするはずだからだ。目標を設定するときは、「SMART」の5項目を確認する。SMARTとは、「具体的か（Specific）」「計測可能か（Measurable）」「行動を表す言葉を使うか（Action-oriented）」「現実的か（Realistic）」「納期は明確か（Time-limited）」の頭文字で、それに加え「クオリティ」「組織作り」「コミュニケーション」「リスク」の4点に注意する必要がある、という。 　新書サイズの本書は、プロジェクトの運営方法や問題への上手な対応方法などが、実にコンパクトにまとめられている。ムダを極力省いた内容で、30分くらいあれば全体が読み切れる点が良い。（ライター・生井俊）

新版 P2Mプロジェクト＆プログラムマネジメント標準ガイドブック
●日本プロジェクトマネジメント協会=企画／P2Mガイドブック改訂委員会=編著 ●日本能率協会マネジメントセンター　2007年12月 ●3800円＋税　978-4-8207-4469-6
	プロセスを重視し、事前に明らかになっている期待成果を実現することに主眼が置く従来型PM標準に対し、「外部環境の変化を意識したうえで、複雑な使命に問題解決の道を開き、事業価値を向上する」発想にあるのがP2Mだ。この新版では、P2Mについてより理解しやすい形に変え、時代の経過に合わせた内容への充実を図っている。 　本書のテーマとなるプログラムは、戦略の意図を全体使命を介して可視化し、そのステークホルダーに戦略の実現に向けた参画を促すものだ。この過程では必要な経営資源が吟味され、効率的・効果的に投入されなければならず、環境の変動を柔軟に吸収して成果を獲得することが要求される。「プログラムマネジメント」は、これらを含めてすべてを対象とし、戦略実践の役割を果たすと同時に、次の戦略策定に大きな影響を与えることとなる。 　企業にとってプロジェクトの選択は投資そのものであり、投資以上の価値を生むプロジェクトの選択が重要だ。正しいプロジェクトの選択を行うためには、企業価値創造の方向性を示した企業ビジョン、それを実現するための具体的な企業戦略が示されなくてはならない。つまり、ビジョンと戦略がプロジェクト選定における基準になり得る、と解説する。 　4部で構成されるこのガイドは、特に「個別マネジメント」に多くのページを割き、さまざまな局面で活用できるよう工夫を凝らしている。PMS資格取得目的だけでなく、プロジェクトマネジメント実践者のための手引きとしても有用だろう。（ライター・生井俊）

プロジェクト・マネジャーの人間術
●スティーブン・W・フランネス、ジンジャー・レヴィン著／PMI東京支部、吉沢 正文=監訳 ●アイテック　2007年11月 ●2000円＋税　978-4-87268-672-2
	「人間に関する問題」はプロジェクトで最もやっかいなものだ。とはいえ、従来のアプローチでは、プロジェクトは技術的な欠陥から失敗しても、「人」の問題は失敗の原因にならなかった。本書では、この「人」に着目し、プロジェクト・マネージャ（PM）が果たさなければならない「人」としての役割と、コンフリクトを解消する戦略についてまとめる。 　PMがリーダーシップを発揮するためには、「リーダー」「マネージャ」「ファシリテーター」「メンター」の4つの役割を果たさなければならない。これらの4つの役割は、それぞれが異なるカテゴリに属するものではなく、仕事の中で同時に果たす必要がある。PMは、これらの機能における強みや弱みを直視し、改善が必要な役割については専門家としての能力開発を積極的に行うべきだとする。 　また、プロジェクトでは立場の異なる多数のステークホルダーがかかわるため、コンフリクトは避けられない。プロジェクトチームを円滑に運営するには、コンフリクトを解決することが必要だが、前向きにとらえて処理することにより、固定概念からの脱却などを促すような効果が期待できる、と説く。 　後半では、PMのストレス・マネジメントや、作業場所での暴力などチームを襲う緊急事態での対処、支援方法にも言及するなどユニークな構成。経験が浅いままPMになった方は参考になるだろう。（ライター・生井俊）

CMMIモデルではじめるプロセス改善実践ガイド
●臼井 孝雄、橋本 隆成=著 ●日刊工業新聞社　2007年9月 ●2500円＋税　978-4-526-05939-1
	プロセス改善活動は、組織の改善活動戦略や文化、開発する製品などを考慮し、各組織にフィットするように「テーラリング」していくことが大切だ。本書は、テーラリングを自らが実施できるよう、CMMIによるプロセス改善活動をまとめる。 　第3章では、ソフトウェア開発プロジェクトを例に、よくある失敗を取り上げる。例えば、担当者の作業計画が不明瞭で、進ちょくが定量的に測れていないケース。これは、CMMIモデルと比較すると「プロジェクトの計画策定」と「プロジェクトの監視と制御」の2つのプロセス領域と関連する。この問題を解消するためには、担当者のタスクを1週間単位に分け与え、0／1（できた、できない）で進ちょくを管理してはどうか、と指針を示す。 　第4章では、プロセス改善を段階的に進めるための体制作りから現状把握・実行・評価までを扱う。体制作りでは、プロセス改善の目標を明確にするだけでなく、事業目標を達成するためとはいえ「プロジェクトが楽になる」ことを優先するといい。そのためには、現有のリソースで、現在の納期で、プロジェクトをうまく回すために何をすべきかを考えるのがカギになる、と説く。 　第3章以降はボトムアップがテーマになっているが、第1章、第2章ではトップダウンでCMMIを活用した改善活動を取り上げる。また、事例と分析、それに対するTIPSのように構成された章もあり、プロセス改善について理解が深まるだけでなく、「逆引き」のような使い方ができ便利だ。（ライター・生井俊）

アジャイルレトロスペクティブズ――強いチームを育てる「ふりかえり」の手引き
●Esther Derby、Diana Larsen=著／角 征典=訳 ●オーム社　2007年9月 ●2400円＋税　978-4-274-06698-6
	仕事が一段落したあとに、チームメンバーが集まり、チームのやり方やチームワークを点検し、改善する特別なミーティング「レトロスペクティブ」。これは、チーム全体の学習を可能にし、変化の媒体として振る舞い、アクションを引き起こすものだ。本書では、レトロスペクティブの活動を5ステージに分け、具体的な手法を紹介する。 　レトロスペクティブのファシリテーターは、「1.場を設定する」「2.データを収集する」「3.アイディアを出す」「4.何をすべきかを決定する」「5.レトロスペクティブを終了する」という、明確な構成に従う。1つ目の「場を設定する」ことで、参加者はこれから行う作業に意識を集中することができ、チームが目標を再確認することにも役立つ。そこでは、グループで考え、一緒に学んでいく「全員参加」が肝になるため、部屋にいる全員に一言二言口を開いてもらう。 　データがないと、チームは何を変更し、何を改善すればいいか推測するしかない。そこで、2つ目の「データを収集する」アクティビティを実施する。5人以下の小さなグループに分け、記憶に残ったり、個人的に意味があったり、重要だったりするイベントを付せん紙に書き出していく。このタイムラインアクティビティでは、感情やイベント、職務によって付せん紙を色分けする手法もある。これらの作業により、イテレーション、リリース、プロジェクトの最中に起きたことをみんなの共通理解とすることができる、と説く。 　基本的なレトロスペクティブの構成から、計画・設計・リードといったプロセスを分かりやすくまとめている。個別の手法も紹介しており、終了時点ではなくとも、チームワークの点検、改善に活用できる。（ライター・生井俊）

失敗事例から学ぶ ERP導入プロジェクト“最適解”
●齋藤 滋春=著 ●アスキー　2007年9月 ●1890円＋税　978-4-7561-5001-1
ERP導入プロジェクト失敗の法則	システム構築のプロジェクトでは、情シスが「期限を守る」ことに執着しがちだ。期限を守るのは良いのだが、そのことだけに目を奪われていると、もっと重要なことを見落とすことがある。本書では、その重要なこととは何かを、ERP導入の失敗事例を通して伝えている。 　「統合型」「業務横断型」といわれるERPだけに、これを導入することは「レガシーをすべて捨て、すべての業務をERPでカバーすること」だと、ERPの初心者は勘違いしがちだ。ERPパッケージには向き、不向きがあり、1つ1つ見極めていけばいい。とはいえ、ERPの知識が十分でなければ判断が難しいため、そこはシステムインテグレータやコンサルタントなどの専門家の力を借りて、最適なアプリケーションの組み合わせをアレンジしてもらうのが望ましい。コンサルティング・フィーだけでもかなりの負担となるが、それが最終的な導入の成果を大きく左右する。 　カットオーバー後も、外部へ運用保守を丸投げし、組織自体のジリ貧化が進み、情シスの意欲が失われていくケースがある。システムインテグレータの「全部こちらでやりますから」との言葉を真に受けるのではなく、たとえシステムの運用管理をアウトソースするにしても、パッケージを開発したベンダのトレーニングを社員に受けさせるなどし、社内にその製品のノウハウを持つ人間を確保しておくことが必要だ。そうしないと、外部に完全に頼り切りになってしまい、コントロールができない「負のスパイラル」に陥ることになる、という。 　導入ばかりに目がいきがちだが、保守運用から教育まで踏み込み、後半で情シスのあり方を提言している。この本を参考に、一度、自社の状況を振り返ってみるといいだろう。（ライター・生井俊）

問題プロジェクトの火消し術――究極のプロジェクト・コントロール
●長尾 清一=著 ●日経BP社　2007年7月 ●2000円＋税　978-4-8222-6211-2
	IT業界ではPMBOKなどのPM知識理解の広がりもあって、現場のPMスキルは徐々に向上してきているが、プロジェクトの失敗率は低下していない。それだけに、プロジェクトをいかに失敗させないかというスキルの体得と並行して、いったん悪化したプロジェクトのさらなる悪化を食い止め、失敗しないようにするスキルの強化が求められている。本書では、そのリカバリ・マネジメント手法を取り上げる。 　リカバリーが失敗に終わる要因の1つは、起動タイミングの遅れにある。このタイミングを外さないためには、「おやっ」といった予兆を感じ取り、悪化の連鎖を断ち切る介入が必要になる。その診断の基本は、管理指標としてのプラン（ベースライン）と実際の進ちょく率、コストとバリアンス分析、発生リスクの追跡、変更・手戻りの回数や頻度、問題に対するアクションの取られ方やその効果などをまず追跡することだ。 　リカバリ・プランで重要なのは、いかに実効性を高めるかにあり、そのためには表面化している現象の下に隠れている本質的な問題を抽出し、その原因を特定する。ベテランにありがちな「過去の経験から簡単に問題の本質をズバッと見抜いて対処できるはず」と調査を始めると、短絡的な思いつきによる「間違った犯人探し」になるリスクもあるため、仮説検証型で臨むべきだ、と説く。 　火を噴くプロジェクトに対して、社内の支援と承認を得るための手法もまとめられ、火消しに至る一連の流れを把握できる。ベンダのみならず、ユーザーの情シス担当者にも一読をオススメしたい。（ライター・生井俊）

TSPガイドブック：リーダー編
●ワッツ・S・ハンフリー=著／秋山 義博=監訳／JASPIC TSP研究会=訳 ●翔泳社 2007年1月 ●3600円＋税　978-4-7981-1290-9
	チームソフトウェアプロセス（TSP）は、その名が示すとおり、ソフトウェア開発チームをガイドする手法だ。この概念とガイダンスの多くは、あらゆる種類の開発チームに適応できる。本書では、チームとリーダーシップの側面において、TSPがどう役立つのかを紹介する。 　自立的なチームを構築し、リードし、動機づけるのに役立つTSPは、チーム編成、チームの立ち上げ、進行中のチームの運営と、大きく3つの部分から成り立っている。そのTSP立ち上げプロセスには、「1.製品ゴールとビジネスゴールの確立」から「9.マネジメントレビュー開催」まで、9つのミーティングがある。ミーティング1と9では、チームとマネジメントがミーティングをするが、その他のミーティングは、チームがコーチと一緒に作業をし、外部からのオブザーバーは入れないことがポイントとなる。 　計画が不正確になったり、変化する問題に対処するために、TSPチームは、「動的計画法」を利用する。このときチームメンバーは、これまで割り当てられた仕事から学んだことを反映して計画を調整する。そうすることで、チームは変化を計画に確実に反映できるようになり、チームの作業をきちんとガイドするようになる、という。 　平易な文章で書かれ、示唆に富んだ豊富な事例により、チームやリーダーシップの在り方についての理解を深めることができる。プロジェクトマネージャには欠かせない1冊だろう。（ライター・生井俊）

ITエンジニアのためのチームリーダーシップ実践講座
●上村 有子=著 ●ソフトバンク クリエイティブ　2006年10月 ●1900円＋税　4-7973-3587-4
	情熱的なチームでなく、何の変哲のないチームであっても、チームワークのよい職場には何か不思議な魔力が潜んでいる。その魔力とは、チームリーダーの仕掛けであり、本書ではリーダーシップに役立つツールや考え方を紹介する。 　組織の中で変化を起こすためには、人が身動きがとれないほど活動を制限するのではなく、決められた範囲内で自由に活動することが大切だ。ぶつかり、跳ね返り、形や性質が変わることで、熱やエネルギーが発生し、全体に何らかの変化が期待できる。その中でリーダーは進むべき方向を指し示す役割を担い、「守り」のマネージャと違って、「攻め」のイメージを持つべきだと説く（Chapter 1）。 　メンバー間の意思疎通をよくするためには、ホウレンソウ（報告・連絡・相談）から、会話の内容・伝達方法・タイミングをチェックし、問題があればそれを指摘していく。そうすることで、メンバーが持つ「コミュニケーションが苦手」といった思い込みとは関係なく、十分漏れのない情報交換ができるようになる。また、1対1では相手に合ったアプローチ方法を利用するといいが、チーム内では「論理思考」が有効となる。それを共通のルールとすると合意形成が容易になる（Chapter 3）。 　ほかに、リーダーとして自己を知るための方法、ファシリテートスキルの身に付け方、活性化を維持するためのテクニックを紹介。事例にとらわれず、客観的な内容に仕上げている点が好感が持てる。チームの活性化を目論むリーダーにオススメしたい。（ライター・生井俊）

マネジメント改革の工程表
●岸良 裕司=著 ●中経出版　2006年10月 ●1600円＋税　4-8061-2526-1
	サバ取りとバッファの管理でプロジェクトを成功に導く方法として、2006年3月22日付けの本欄で紹介した『目標を突破する実践プロジェクトマネジメント──あなたのプロジェクトは必ず成功する』の続編が登場。TOC（制約理論）のプロジェクトマネジメント理論であるクリティカルチェーンPM（CCPM）をベースにし、工程表の中に「常識を実践するためのメカニズム」を埋め込む手法を解説する。 　成功しているプロジェクトマネージャが例外なく重要視するのは、プロジェクト関係者の目標のすり合わせだという。目標を3つに分けてすり合わせする「ODSC」という方法を使うと効果的だ。「O」はObjectives（目標）、「D」はDeliverables（成果物）、「SC」はSuccess Criteria（成功）の略で、この3つの議論が終わりODSCができたら、プロジェクトリーダーがみんなの前で読み返す。そこで「これがやれたら最高だ」というようになったら、みんなで情報共有できただけでなく、チームの士気も大いに盛り上がる（Part4）。 　改革の工程表をひくためには、「科学的段取り八分」を利用するといい。人は、「10時の電車に乗る」となると切符を買う時間や家を出る時間のように、目標を後ろから確認して計画を練る。工程表をひくときも、ODSCを見据えながら、「その直前は何をすべきか」を問いながらプロジェクトの最初まで戻っていくと、目標達成のための段取り議論が自然にできると説く（Part5）。 　本文は極力専門用語を排除し、カラーで見やすく構成されている。また、コラムに用意する「成功の極意」も見逃せない内容。前著と合わせて読むと理解が深まるだけでなく、より成功に近づくようなイメージトレーニングができる好著。まだ読まれていない方は2冊セットでそろえてみてはいかがだろうか。（ライター・生井俊）

アート・オブ・プロジェクトマネジメント──マイクロソフトで培われた実践手法
●スコット・バークン=著／村上 雅章=訳 ●オライリー・ジャパン　2006年9月 ●3200円＋税　4-87311-299-0
	マイクロソフトでIE、Windows、MSNなどのプロジェクトチームを率いてきた筆者が、その経験を基にプロジェクトの組織方法、スケジュールの管理方法を中心に「計画」「スキル」「マネジメント」の3部16章構成でまとめる。 　1章でプロジェクトマネジメントの歴史を振り返り、2章でスケジュールの目的を説く。スケジュールは、「いつものごとが完了するか」だけでなく、「チーム全体における個人の成果物の位置付けを理解させ、各メンバーの協調を促進させる」「進ちょくを管理し、作業を管理可能な塊に分割するツールをチームに与える」という目的がある。スケジュールが持つ力を引き出せるかどうかは、マネジメントやプロジェクト推進用のツールとして使う人の手に委ねられていることを理解しておく必要がある。 　12章では、リーダーシップ論を展開する。信頼は表明により培われるが、効果的な表明の要素として「表明を行う人はきちんとした意志を持って行う」「表明は気軽に行わず、関連作業、リソース、スケジュールを慎重に考慮する」「何を、誰が、いつ行うかについて関係者と合意できている」「表明はオープンにされ、広く内外に公表されること」など、6点を挙げる。また、矛盾した振る舞いにより簡単に信頼が失われることを忘れてはならない。 　筆者の経験したプロジェクト事例が豊富に盛り込まれ、プロジェクトマネージャはもちろん、現場のスタッフでも読み物として十分楽しめることだろう。（ライター・生井俊）

プロジェクトマネジメント プリンシプル──変革の時代を生き抜くための人と組織の挑戦
●プロジェクトマネジメント協会=編／PMI東京支部=監訳 ●アイテック　2006年9月 ●3500円＋税　4-87268-567-9
	プロジェクトマネジメント（PM）の関連図書が多数出版されているが、そのほとんどが方法論を解説している。本書はPMの原点に立ち戻って「プリンシプル」を扱い、PMBOKガイドブック第3版を補完するものだ。 　内容は「プロジェクトの組織化」「プロジェクト・マネジャーの役割と責任」「プロジェクトのチーム形成」「コンフリクト・マネジメント」「交渉と契約」「契約マネジメント」の6部で構成される。それぞれのテーマについて、その必要性と定義を紹介し、引用文献と参考文献をまとめている。 　コンフリクト・マネジメントを例に挙げると、従来は基本的に悪いことと見られ、マネージャは隠したりもみ消そうとする傾向があった背景を説明。最近では、それは避けられないものであり、変化の自然な結果だと見なされ、うまくマネジメントすることでマネージャにとっても有益な場合がある。そして、このコンフリクトを生む9つの先行条件を踏まえることで、プロジェクト・マネージャが破壊的結果を避け、逆にメリットになるよう導き出すことができる、という。 　学術的な引用を主体とし、図表をできるだけ盛り込む工夫が見られるなど、PMBOKをより活用したいマネージャに向いている。（ライター・生井俊）

システム開発 火事場プロジェクトの法則──どうすればデスマーチをなくせるか？
●山崎 敏=著 ●技術評論社　2006年10月 ●1680円＋税　4-7741-2881-3
	IT業界の現場では、残業、徹夜は当たり前という風潮がある。デスマーチと呼ばれる死ぬほど過酷な労働環境が、IT業界に限らず、一般企業のIT部門でも発症してきている。SEを14年経験した筆者が、その悩みや苦しみから解放されるための法則をまとめる。 　火事場のプロジェクトでは、本質的なことが欠けていて、それらは「バードビュー」「コミュニケーション」「エモーション」「フィードバック」に分類される。前半は、それぞれについて、個人はどうか、会社はどうかをチェックし、体質を改善するための解決案を提示している。 　後半は、デスマーチが起こる背景やそこから逃れる方法を紹介する。人海戦術によるコスト増大やコミュニケーションの難しさ、効率の悪化に気付かずにいるのがデスマーチの一因となるが、顧客との話し合いの強化やルールを変えることによりその状態から抜け出すことができる。また、仕事に対する考え方を変えることが、自分や周りの価値を高めることにつながると説く。 　巻末の付録として、全体最適や人の能力を引き出すために役立つビジネス書をまとめる。いまの状況を打破したいSE向け。（ライター・生井俊）

プロジェクトマネージャ育成法──ITプロジェクトを成功させる人材育成
●佐藤 達男、伊藤 英雄=著 ●日科技連出版社　2006年7月 ●2400円＋税　4-8171-9186-4
	冒頭、「あなたの会社にはプロジェクトマネージャを育成する仕組みはありますか？」と問いかける。OJTと称して現場に人を放り出し、運良く生き残った人をプロジェクトマネージャと呼ぶような状況がいまだにあるからだ。本書は、「成り行き任せではないプロジェクトマネージャ育成」について詳述する。 　これまで、経験偏重で、教育熱心とはいえなかったIT企業だが、PMBOKが浸透し、知識を習得することの重要性が認識されてきた。しかし、PMBOKさえ学習すればプロジェクトマネージャになれるかという点では、その知識学習は必要条件であるが、十分条件ではない。知識は実践を経て、初めて能力として身に付くものである。特に、リスクマネジメントなどは経験が顕著に表れる。 　著者は新しいプロジェクトマネージャ育成の仕組みとして、「PM教習所」を提案する。これは、自動車教習所のように、プロジェクトマネージャに必要な知識と経験を一体化し、段階的に能力の向上を図る育成環境のことだ。特徴としては、インターンシップ型OJTによる実習や、プロジェクトマネージャ候補生が教習に専念する環境、担当教官による教習全般のフォロー、修了判定による達成状況の見極めとフィードバック、そして免許制度という点がある。 　このコンセプトをいかに展開していくかが今後の課題ではあるが、業界全体の底上げにも貢献するこの仕組みを、ぜひ多くの企業で取り組んでほしい。（ライター・生井俊）

プロジェクト・マネジメント 危機からの脱出マニュアル──失敗ケースで学ぶ
●デイビッド・ニクソン＋スージー・シドンズ=著／中嶋 秀隆=訳 ●ダイヤモンド社　2006年7月 ●2200円＋税　4-478-37521-6
	とんでもない事態に陥ったプロジェクトでも打つべき手がある。本書では、プロジェクトが悲惨な結果に終わるケースを「リスク」「経営」「人的資源」などの観点から取り上げ、適切な対処法についてまとめている。 　プロジェクトを失敗させないために、リスク識別、リスク評価（分析）、リスク計画、リスク監視からなるリスク・マネジメントを回すが、その効果が挙がらない場合、この4つのサイクルを1度しかやっていないことが考えられる。プロジェクト失敗の潜在要因を見つけやすくするためにも、最初だけでなく、最後まで全期間を通じ継続する必要がある。 　またリスクを低くくする、うまいプロジェクトの進め方として“決してやってはならないこと”を挙げる。それは「何も対応しない」「白を切る」「プロジェクト・マネジャーを交代させる」「契約を破る」「資源を追加投入する」「下請けを責める」「顧客を責める」の7つで、これらについて、なぜやってしまうのか、なぜ危険なのか、反対に功を奏す場合を認識することで、最前の結果を得るための正しい方策をとることができると説く。 　ほかに、「アポロ13号」などのプロジェクトを振り返りながら、失敗と思われていても成功へ導くことができることを強く印象付けている。平易な内容のため、プロジェクトの勉強会などでも活用したい。（ライター・生井俊）

ハッピィ・エンジニアリング──新しいシステム開発の処方箋
●吉田 智彦=著 ●ソフトバンク クリエイティブ　2006年6月 ●2200円＋税　4-7973-3274-3
	システム開発は、新しい技術を活用したからといって優れたものが作れるわけではなく、新しい方法論を持ち込めば成功するというものでもない。本書では、海外理論や単なるケーススタディではなく、相互理解や自分の使命の明確化、ゴールの共有のための道筋を示している。 　システム開発で「同一のプロジェクトはひとつたりともない」とはいうが、ゼネコンは同じビルではなくても期日にビルを建てられるし、プラント建設も期日にサービスインできるはずだ。同一ではない顧客の問題を解決に導いていくことがシステム開発における命題だが、「ひと山いくら」の開発者を集め、できない理由を並べざるを得ない状況をみると、システム業界は「人手余って人材足らず」という言葉で語られるほど、レベルが低いという結論にいき着く（第2章）。 　公式な会議には、作業の当事者ではない人間も多数出席する。会議の結果として取り入れられる意見は、「正論」ではなく、「声の大きい者の意見」だ。非公式なコミュニケーションの場合、なんらかの問題を発見したものが主導になり、その場その場で作業の当事者同士が詳細を詰めていくことができる。しかし、大きなプロジェクトではメンバー全員への徹底が難しくなる。公式・非公式の長所・短所を見極めてどう使い分けるかが、プロジェクトをスムーズに進めるポイントになる、という（第5章）。 　システム開発にかかわるユーザー企業、SIベンダ、下請けの開発会社という立場を問わず、関心のある項目を実践していくだけでも、プロジェクトが引き締まることだろう。（ライター・生井俊）

研修では教えてくれない 開発現場で必要な24のチカラ
●山野 寛=著 ●翔泳社　2006年3月 ●1800円＋税　4-7981-1034-5
	技術力絶対主義的だと思われがちなシステム開発の現場。そこで、ITエンジニアに期待されるスキルとは、技術力よりも、リスク察知やコミュニケーション能力、マネジメント能力に優れていることだろう。このように、これからのITエンジニアにとって本当に望まれる24の力を紹介する。 　第1章では、プログラム実装・テスト現場で必要な6つの力を取り上げる。コミュニケーション力、リスク対応力のほか、手抜きSEのせいでメチャメチャになったプロジェクトを回想しながら、優先度判断力の重要性を説く。優先度の高いタスクを見失い、容易なタスクにばかり手をつけてしまう手抜きSEの存在は、プロジェクトを「デスマーチ」へ導く原因になると指摘する。 　第4章では、要求分析・要件定義の現場で必要な6つの力を取り上げる。ここでは、「発言できないエンジニアは去れ」と発言力を強調するが、その一方で、お客さまにムダな時間を使わせてしまう過剰な提案を避け、お客さまが決断しやすい提案をしなければならないともいう。 　それぞれの「力」ごとに、現場での教訓とプロマネ視点のまとめがあり、新米SEからプロジェクトマネージャクラスまで、幅広い層で役立つ本に仕上がっている。（ライター・生井俊）

目標を突破する実践プロジェクトマネジメント──あなたのプロジェクトは必ず成功する
●岸良 裕司=著／村上 悟=監修 ●中経出版　2005年12月 ●2300円＋税　4-8061-2331-5
	プロジェクト活動の極めて重要で、かつ主要な業務は「考える」ことである。あいまいでいい加減になりがちな業務の流れの中で、「目的はなにか？」「成果物は何か？」「成功基準はなにか？」「本当にギリギリの納期か？」などの言葉を使い続け、考えることがプロジェクトの成功確率を飛躍的に高めることになる。 　7章構成のPart1では、プロジェクトが遅れる6つの理由を挙げる。その1つは、念のために余裕（サバ）を見ておこうということ。そして、余裕のある工期をもらったことで、最初はゆっくりと始めて、予定日が来るのに合わせて仕事の調整をするなど、予算と時間をあるだけ使ってしまうもの（パーキンソンの法則）。これらの項目はすべて人の心理的な問題行動である。 　そのサバ取りのテクニックをPart2で扱う。現場担当にはサバを読ませない、サバは親方（プロマネ）が管理する、別のタスクを並行するのではなく1つの仕事に集中する、現場でのゼニ勘定を忘れないことなどを納期厳守の鉄則として紹介する。また、工程表を見ながらの「科学的サバ取り段取り」テクニックをまとめている。 　この手の本には珍しくオールカラーで、欄外に用語解説やコラムがあるなど、読みやすく理解が深まる工夫がされている。また、クリティカルチェーン・プロジェクトマネジメント・ソフトの体験版が収録されたCD-ROMが付属する。（ライター・生井俊）

実務で役立つプロジェクトレビュー──システム開発プロセスを「見える化」する
●菊島 靖弘=著 ●翔泳社　2006年2月 ●2200円＋税　4-7981-1031-0
	「バベルの塔」は、構想を実現する要素技術があったにもかかわらず、言葉というコミュニケーションの道具が機能不全に陥ったために崩壊した。それは構想を実現するもう1つの技術、プロジェクトマネジメントが成り立たなくなってしまったからだ。本書では、システム開発をバベルの塔にしないためにも、人を中心に据えたプロジェクトマネジメント技術の重要性を説く。 　第2章でプロジェクトレビューが持つ機能を「見える化」「情報マネジメント」「スキルサプライ」「リスク管理」「コスト管理」「プロセス管理」「プロダクト品質管理」の7つに分類し紹介する。見える化することで、担当者の抱え込みリスクを排除するほか、プロジェクトレビューを設定、ステークホルダーに参加してもらうことでクロスファンクショナルなチェックを行うなどすることで、要件についてブレが少なくなる。 　第3章でプロジェクトレビュー制度を、第4章でレビュアーの心得をまとめている。システム開発を成功させるためにはアプリケーション（アプリ）オーナーの参加が不可欠だ。21世紀のシステム開発では、アプリオーナーがサプライヤーと共同でシステム開発を推進する。これを明確化するために、アプリオーナー制度を作り、企業に定着させなくてはならない。また、プロジェクトレビューの目的については、業務監査ではないこと、指摘より質問をすることなど、7つの柱を事前に周知徹底しておくことが重要になるという。 　付録には、JUAS（日本情報システム・ユーザー協会）の「エンドユーザーによるビジネス定義の進め方」の資料があり、システム開発の超上流工程におけるプロジェクトレビュードキュメントを整える参考になる。（ライター・生井俊）

新版 PMBOKによるITプロジェクトマネジメント実践法──PMBOKガイド 第3版対応
●佐藤 義男=著 ●ソフト・リサーチ・センター　2005年11月 ●2000円＋税　4-88373-219-3
	本書は「改訂 PMBOKによるITプロジェクトマネジメント実践法」の内容を「PMBOKガイド第3版」に対応、大幅に改訂したもの。プロジェクトの最も上流に当たる提案・見積もりポイントから、PMBOKの解説とプロジェクトへの適応法、成功に導くプロジェクトマネジメント（PM）実践法までを解説する。 　10章構成の鍵になるのが、第5章・第6章。第5章ではPMBOKの特徴や概念、PMプロセスを扱う。「なぜPMBOKなのか」だが、国際知識標準であることや、WBS技法ベースの管理により、作業の欠落・重複を防止できるなど、従来型のシステム開発PMに比べて優位性があることなど、7つの理由を挙げている。また、第6章は「スコープ・マネジメント」「タイム・マネジメント」「コスト・マネジメント」など9つの知識エリアと、システム開発プロジェクトにおける考慮点を100ページ弱を割いて説明する。 　第9章で、PMBOKによるシステム開発PMのチェックポイントを実践例を挙げながら紹介するほか、第10章ではPM成功の条件として体系的なトレーニングの実施やプロジェクトマネージャのキャリアパス化について取り上げる。PMBOKを経営やプロジェクト業務にどのように生かしていくか、参考にするには十分な内容だろう。（ライター・生井俊）

失敗する前に読む プロジェクトマネジメント導入法
●浦 正樹=著 ●翔泳社　2005年9月 ●2480円＋税　4-7981-0986-X
	あなたの会社のプロジェクトはなぜ失敗しているのか。その原因についてあるプロジェクト・メンバーに聞くと、「そもそも計画にムリがあった」と指摘した。なぜ、実現性の低い計画を立て、走らせてしまうのか──。それを解消するプロジェクトマネジメント（PM）導入と組織を変える方法論をまとめている。 　Part2では、現場へのアクションが後手に回ることなく、常に先を読むPM導入の手順とノウハウを紹介する。中でも、「WBSの作成」と「PMプロセスの定義」に多くのページを割く。また、プロジェクトの計画がメンテナンスされない原因の1つに「計画したからには何が何でもやりきろう」とする日本人のDNAが関係していると推測する。 　Part3では、PMを阻害する原因である組織変革のための方法論を扱う。トップの振る舞いの影響は大きいため、導入推進チームの責任者は現場第一線から登用したい。実力者がトップに就くことで、組織やステークホルダーには本気度が伝わってくる。そこで強力なスポンサーシップを発揮してもらうことで、人や組織を変革する成功要因になると説く。 　プロジェクトマネジメント手法を扱う類書は多いが、本書はそのための組織変革にまで言及している。その点は貴重だといえるだろう。（ライター・生井俊）

世界一わかりやすい プロジェクト・マネジメント
●サニー・べーカー、キム・ベーカー、G・マイケル・キャンベル=著／中嶋秀隆、香月秀文=訳 ●総合法令出版　2005年4月 ●2800円＋税　4-89346-899-5
	プロジェクト・マネジメントについて満遍なく、かつ簡潔に扱った実用書。目次も一目で流れが分かるものと、詳細に本文の見出しを記載したものと2種類用意し、すぐに調べたい項目が探せる構成になっている。 　7パート30章と量で圧倒されるが、かなり頻繁に「賢者の言葉」や「プロジェクト用語」などのコラム・解説を織り込みながら、ポイントを絞った解説にとどめている。章の始めには章の流れが、終わりには章のまとめがあり、読み進めるうえで理解が深まる。 　30章ある中で注目したいのが、第3章「ゲームのルール」だ。プロジェクト失敗の7つの原因と、プロジェクト成功の12の黄金律を紹介する。黄金律からいくつか抜粋すると、「成果物について合意を得る」「最良のチームを育てる」といったことから、「できること以上のことをやらない」「変更を躊躇しない」など、当たり前だが何らかのしがらみで実現しづらいことが並ぶ。ほかに、第5章の「ステークホルダーの特定」、第9章の「WBS（作業分解図）」、パート4以降のリーダー論などが実用的だ。 　500ページ弱の厚みのある本だが、ウィットに富んだ文章でぐいぐいと引き寄せるパワーがある。プロジェクト・マネジメントの手法を知るためにも、実際のマネージャが自分の仕事の進め方をチェックするためにも活用できる便利な本だ。オフィスに常備し、必要に応じて見直していくことをオススメする。（ライター・生井俊）

実務で役立つWBS入門
●グレゴリー・T・ホーガン=著、伊藤 衡=監訳 ●翔泳社　2005年3月 ●2200円＋税　4-7981-0849-9
	ワークブレークダウン・ストラクチャ(WBS)は、プロジェクトにおける一連の作業を分解し構造化する手法だ。その目的は作業項目を整理、定義、実行することである。 　第1章「WBS入門」では、WBSの考え方と作成の4つのステップを紹介する。4つのステップとは、最初のステップでプロジェクトの目的を決め、次に顧客に提供するプロダクト、サービス、結果などの成果物を決める。ステップ3では具体的な成果物を漏れなく特定し、ステップ4ではステップ2と3の各項目を計画やコントロールするうえで適切な大きさになるまで分解を続けるもの。 　第2章「基本概念」では、「100パーセント・ルール」を解説する。100パーセント・ルールは、WBSの作成と分解手法の評価において最も重要な指標で、「WBSの次の分解レベル（子ども）は、親要素に属するすべての作業を表す」。これが守られている限り、そのWBSに必要なすべての作業が包括されていることが保証される。 　解説部分は6章立て、約100ページでさっと読める。また、付録の「Q&A」「WBSとWBS辞書のサンプル」が充実しており理解を深めることができる。これまで“みようみまね”で何となくWBSを書いてきた人にオススメしたい。（ライター・生井俊）

覚悟の技術──プロマネが教える成功する人の考え方
●弓場 秀樹=著 ●ソシム社　2004年12月 ●960円＋税　4-88337-423-8
	ご存じのように「赤信号、みんなで渡れば怖くない」というネタがある。「青信号」「赤信号」はGOかSTOPかの決めごとであり、信号の色に関係なくみんなで渡っても危険なときがある。つまり、本来は「安全かどうか」で判断しなくてはいけない。 　本書は、著者がプロジェクトの中で出会った、そのようなノリで行動してしまう人たちを記録・分析し、本質とは何かをまとめたもの。基礎編、職場編、人生編の3章構成で、55のテーマを扱う。「一から考えるVSゼロから考える」「時間をかけて待つVS時間をかけて考える」「夢をもつVS夢に向かう」などのテーマに対し、「さらりーまいんど」「ビジネスまいんど」を提示する。1テーマ3ページで完結し、よくある事例を挙げながら、最後に教訓として「覚悟の技術」を披露する。 　新しい行動に移る決断ができるかどうかを左右するのは、勇気や決断力ではなく「覚悟」だと筆者はまとめる。プロジェクトのみならず、会社の経営手法やしきたりに不満や歪みを感じているマネージャが、新しい仕組みを生み出す上で役立ちそうだ。（ライター・生井俊）

ここが違う！ 仕事ができるプロジェクトマネージャー──そのノウハウと育成法
●野間 彰=著 ●日刊工業新聞社　2004年10月 ●1700円＋税　4-526-05365-1
	できるPM（プロジェクトマネージャ）と一般PMとの差はあまりにも大きい。大手システム・インテグレータの調査によると、できるPMが担当したプロジェクトは、トラブルや納期延期が少なく、一般PMに比べ3割以上高い利益率を達成しているという。 　できるPMのノウハウを生かして、できるPMを作り出すのが本書の目的だ。世界的標準である「PMBOK」を活用しながら、ノウハウを体系化・共有・拡充する技術を確立するまでのストーリーを折り込む。 　本文はI〜Vの5章立てで、冒頭のI〜IIIでは第2、第3のできるPMを作るための事例を紹介している。Iでは、PMBOKの「穴」を埋めるための考え方を提示、できるPMのノウハウの標準化や移植についてを中心にまとめている。IIでは、できるPMの鍛え方を制度化することがテーマ。PMを成長させるためには矢面に立たせ、泣かせることが重要という論を展開する。IVでは、ノウハウの体系化法を扱う。ここで、できるPMがもつ「ノウハウ（短い言葉）」とは、方法論の「コンセプト」である、と説いている。 　事例中心で、適宜流れや考え方をまとめた図表があり、PMBOK初心者でも読みやすい。人材育成担当者や優秀なPMのノウハウを水平展開したいと考えているマネージャにお勧めしたい。（ライター・生井俊） 関連記事 有能プロジェクトマネージャ育成術（＠IT情報マネジメント > ITスタッフ）

プロジェクト成功への決め手――構想・企画から商談・契約まで
●井野 弘=著 ●英治出版　2004年12月 ●2000円＋税　4-901234-62-5
	本書は「プロジェクト失敗の根本原因」から「プロジェクト成功への<3つの力>」までを4部8章構成でまとめる。 　外注化モデルには、「システム構想・企画」「システム構築」「運用・改善」の3つの構成要素があり、そこには「発注契約」「発注側のプロジェクト・マネジメント」「検収条件・受け入れ」という3つのモヤモヤがある。ここでいうモヤモヤとは、不明瞭な状態のことで、各要素間のインターフェイスに関する取り決めが不透明なさまを指している。この3つの構成要素を着実に実施し、3つのモヤモヤをいかに明確化し、有利にするかがプロジェクト成功の鍵だ。 　「システム構想・企画」の品質を上げ、受注側と合理的な契約を交わし、「システム構築」を外注化する。それを受けて受注側は「システム構築」をきちんと成功させる。そのために必要なのは、「プロジェクト・マネージャの個人力」「PM組織力」「経営力」の3つの力を強化することだ。受注側・発注側それぞれが果たすべき役割を強く自覚すること、経営者自身が大きな構図でふかんし、リーダーシップを発揮することを求めている。 　図表を多用し、各項目について2〜10ページでまとめているため読みやすい。外注とのコミュニケーション不足に悩むプロジェクト・マネージャやプロジェクト・マネジメントでのリーダーシップの取り方を学びたい人に最適だろう。（ライター・生井俊）

どうすればシステム発注で失敗を防げるか
●田中 徹=著 ●技術評論社　2004年8月 ●1580円＋税　4-7741-2072-3
	情報システム部門に配属になった人や、システムを発注する担当者のためのバイブル。発注前の予備知識から、社内体制の整備、開発会社の見極め、イニシアチブの取り方などの7章構成となっている。 　システム発注に必要なことは「いいシステム会社を見つけること」と、「発注する準備が整っていること」の2つ。システム発注の作業としては、まず、複数の会社から見積もりを取り、適正価格を知り、予算の修正などを行う。システムの規模に応じ、大手の開発会社とソフトウェアハウスを使い分けることも必要だ。 　システムコンサルタントによれば、発注者側の体制の不備がトラブルを引き起こしていることが少なくないという。それを最小限にするためには、発注担当窓口を1人にし、可能な限り権限を委譲してもらうこと。また、開発に関する知識は最低限で構わないが、業務知識の中でも特に、会社独自のデータの流れに精通している必要がある。 　発注の仕方、SEの見分け方、システムコンサルタントの使い方など、開発に沿った必要なことが網羅してあり、入門書として手元に置いておきたい1冊である。（ライター・生井俊）

熊とワルツを──リスクを愉しむプロジェクト管理
●トム・デマルコ、ティモシー・リスター=著、伊豆原 弓=訳 ●日経BP社　2003年12月 ●2200円＋税　ISBN4-8222-8186-8
	著書「ピープルウエア」で知られるデマルコ&リスターの最新刊。ITプロジェクトにおけるリスク管理（おとなのリスク管理）を行うべき理由から、その基本的な考え方と手順について軽妙な語り口で述べていく。 　筆者は、「ソフトウエア開発がリスクをともなうのは、プロジェクトのあらゆる面が不透明だからだ」という。しかし、だからといってどのくらい不透明であるかを知らなくいいことにはならない。本書は、プロジェクトの進ちょく、コスト、利益などの不透明さを扱うやり方やリスク回避・低減の方法、そして具体的なプロセスを述べる。リスク管理の専門書では、おうおうにして込み入った確率計算の数式などが出てくるが、グラフや表、概念図にまとめられており、プロジェクトのリスクを他人に説明・報告する際にも役立つだろう。 　「やればできる式管理」で推進されているプロジェクトの参加者はもちろん、発注先のSIerのリスク管理能力を知りたいと考えている情報システム部門マネージャの方々にお奨めだ。

プロジェクトはなぜ失敗するのか──知っておきたいITプロジェクト成功の鍵
●伊藤 健太郎=著 ●日経BP社　2003年10月 ●1800円＋税　ISBN4-8222-8177-9
	ITプロジェクトの成功・失敗はどこで決まるのか。 　プロジェクトの失敗が分かると、責任の押し付け合いが始まる。そして、プロジェクトマネージャの交代などによって、失敗の経験が次のプロジェクトに生かされないことが多い。プロジェクトは初期段階で仕様の詳細まで固まっているケースが少なく、不確実性が高いものだ。どちらかといえば、失敗する確率が大きいにもかかわらず、こうした事後処理に終わることが多いようだ。 　本書では、「失敗を基準にプロジェクトを考える」視点を持つことで、プロジェクトに対する行動が変わると説いている。プロジェクトを成功に導くために、まず「プロジェクトを実施する目的」と「プロジェクトの成功の状態」を明確にすることが重要になる。その問いへの答えが明確でないと、意志決定で正しい解が導き出せないのだという。 　失敗した前例を分析し、問題点を浮かび上がらせる内容になっており、ここで学ぶべきことは実に多い。例えば、文書化がされていなかったり、悪い情報を隠ぺいしたりといったことでの失敗──。それは、任務遂行に適切な判断材料となる文書があればより適切な判断が下されたかもしれず、情報の隠ぺいが行われずリスクの検討がされていれば、適切な予算処置などが行うことが可能だったかもしれない。 　いま進行しているプロジェクトも、これからスタートするプロジェクトも、プロジェクトを「失敗するもの」として、いま一度この書を参考に見直してみてはいかがだろうか。（ライター：生井俊）

拝見！プロジェクトマネージャの仕事──ITプロジェクトの成否の鍵を握る人々
●金子 則彦ほか=著、金子 則彦=監修 ●技術評論社　2004年1月 ●1880円＋税　ISBN4-7741-1903-2
	ITプロジェクトにおける失敗やミス事例を、ストーリー仕立てで具体的に示し、初級者にも「プロジェクトマネジメントとは何か？」が疑似体験的に理解できる構成になっている。登場人物の性格に由来する失敗ストーリーなどもあり、一般的なPM教科書を補完する内容になっている。対象読者はIT業界のSI会社のプロジェクトマネージャ（予備軍含む）だが、カウンターパートであるユーザー企業側の情報マネージャ、プロジェクトメンバーが読んでも役立つだろう。

各書評にあるボタンをクリックすると、オンライン書店で、その書籍を注文することができます。詳しくはクリックして表示されるページをご覧ください。