晴読雨読＠エンジニアライフ

プロジェクト・マネジャーが知るべき97のこと  神庭弘年（監修）、Barbee Davis （編集）、 笹井 崇司 （翻訳） オライリージャパン 2011年11月 ISBN-10: 4873115108 ISBN-13: 978-4873115108 1995円（税込）

■世界はきのこに満ちている

　「○○が知るべき97のこと」シリーズの第3弾が出た。本書は、プロジェクト・マネージャ（以下PM）向けのエッセイを97本（日本版は＋11本）を収録している。

　第2弾『プログラマが知るべき97のこと』は、プログラマ向けのエッセイが収録されている名著だった（以前に書評を執筆したので、ぜひご覧いただきたい）。

　『プログラマが知るべき97のこと』は通称「きのこ本」として親しまれている。ちなみに第1弾は『ソフトウェアアーキテクトが知るべき97のこと』。これはもう「きのこ本シリーズ」とでも呼ぶべきだろう。

■きのこ本が築く、きのこの山

　「きのこ本シリーズ」は、それぞれの分野で活躍する人物の手によるエッセイを97本（+α）収録するものだ。いろいろなキャリアを積んできたベテランが、プロジェクトで経験してきたことを短く印象的なエッセイにまとめている。

　「いろいろなキャリア」に根ざして書かれたコラムはどれも味わい深く、時には執筆者同士がそれぞれ違う主張をぶつけ合うことだってある。それが「きのこ本シリーズ」の魅力の1つでもある。

　ところが、本書は過去2冊と比べて明らかに「主張の衝突」が少ない。これはどういうことなのだろう。

■PMの問題領域、それは「人」

　本書を最初から読んでいくと、「プロジェクトを進める際によくある落とし穴」「気を付けるべきポイント」「よりよい行い」といったことを書いたコラムが並んでいる。アジャイルな開発手法を少しでも学んだ／経験したことがある人にとっては「あるある」の連続だろう。

• 顧客／ユーザーを巻き込む
• シンプルを心がける
• 問題を小さく分割する
• 優秀なチームを編成する
• チームで責任を果たす
• 変化を受け入れる
• コミュニケーションをとる

　読みながら分かったのは、「PMの問題領域は人間である」ということだ。

　考えてみれば当たり前なのだが、ソフトウェア開発においてもっとも難しいのは、設計でもプログラミングでもデバッグでもなく「合意すること」なのである。

　ユーザーは「自分たちが何を必要としているか」を分かっていない。顧客は予算を出し渋り、期間を圧縮したがる。開発者は移り気で扱いづらい。そしてみんな人間なので、エゴや怠惰さ、自己顕示欲や怠惰さを備えている。

　ソフトウェア開発プロジェクトでは、こういった「人間の厄介さ」が集約するハブとして「PM」というポジションがあるのだ。

　それであれば、本書に「主張の衝突」が少ないことにも納得がいく。人間関係の問題とは、「すでに解決策が分かっており、そしてそれを実践するのが困難」なものだからだ。

　ミーティングがつい長くなってしまう問題、複数のステークホルダーが違うことを言い出す問題、チームに問題児が紛れ込んでしまう問題、納期が遅れてしまう問題。いずれも、ソフトウェア開発が産業として興る前から存在し、そしてきっと、今後も存在する問題なのだろう。

■プロジェクト・マネージャとしてこの先生きのこるには

　ソフトウェア開発にかかわらず、プロジェクトをマネジメントするには「人」が最も大きな問題になるのだろう。そういう視点で本書を読みなおすと、PMという立場に置かれた時の心構えを準備できるだろう。

　目次を見てみよう。いずれも、ソフトウェア開発に関するエッセイとは思えないような見出しだ。

• 05「複雑よりもシンプルな方がいい」
• 14「大きさが重要」
• 27「見積もって見積もって見積もる」
• 37「自らに誠実であれ」
• 39「変化のための道筋を描く」
• 69「コミュニケーションが重要」
• 82「みんなが聞きたいことはなんですか？」

　だが、PMが扱う問題領域は、まさにこうした解決法を必要としている。現場で問題に立ち向かうには、かつて問題に立ち向かった諸先輩の声をよく聞き、よく咀嚼（そしゃく）し、そして

• 16「さあ、プラクティスを投げ捨てよう」

　自分の現場でこの先生きのこるには、自分の現場に合ったマネジメントを、自分の手で編み出す必要があるのだ。

（『Wife Hacks ～仕事と家族とコミュニティと～』
コラムニスト　kwappa）

Being Geek　ギークであり続けるためのキャリア戦略 Michael Lopp （著） 夏目大 (翻訳) オライリージャパン 2011年6月 ISBN-10: 4873114993 ISBN-13: 978-4873114996 2415円（税込）

■ギークであり続けるためのキャリア論

　私は、今年転職して4月から新しい会社で働いています。刺激的な毎日を過ごすことができ、転職は正解だと思っています。しかし、現状に満足しているせいか、将来の自分の姿を思い描けなくなっていることに気付きました。

　そんな折に本書を知り、今後のキャリアプランを考えるきっかけにしようと思いました。

■4テーマ、40章という幅広い内容

　本書は、エンジニアのキャリア戦略にまつわるさまざまな内容を扱っています。テーマは大きく分けて4つ、「キャリアの形成」「マネジメント」「日々の仕事に必要なスキル」「変化」という構成です。

　各テーマはさらに細かい章に分かれていて、全40章とかなりのボリュームです。エンジニアがマネージャに転身する場合の注意点や心掛けたいこと、転職、コミュニケーションのコツなど、まさに｢キャリア形成｣に関わることは幅広く網羅しています。

　とはいえ、各章はそれほど長くないため、気軽に読めます。気になる章、自分にとって必要だと思う章から読み進められるのも、本書の良いところだと思います。

　これだけの量を扱っているので、エンジニアなら何かしら気になる章があると思います。私の場合、40章のうちで気になった章、役に立つと思った章が10章もありました。

• キャリアのための行動（第1章）

• 大切なことは3つ（第2章）

• 転職にあたって考えるべきこと（第3章）

• 企業文化（第8章）

• 不可能を可能に（第13章）

• トリクルリスト（第24章）

• 無意味なこと（第28章）

• 転職先の選択（第35章）

• マネージャとコミュニケーション（第37章）

• 不安な将来（第40章）

　特に、今の仕事において役立ったのは「マネージャとコミュニケーション」（第37章）でした。エンジニアとしての仕事を買われてマネージャに昇進した人がいるとします。しかし、エンジニアの仕事とマネージャの仕事は質がまったく異なるため、エンジニアとして優れていたとしても、マネージャの仕事がうまくできるとは限りません。37章では、マネージャに昇進するエンジニアが持つべき心構えをまとめています。

• 部内、部外の人たちとのコミュニケーションの「ハブ」になる必要がある

• ある人から聴いた話を別の人にする場合、そのまま伝えるのではなく、伝える人に合わせて「抽象化」と「フィルタリング」が必要になる

• 同様に、部署ごとに違う「方言」を自由に操れる必要がある

• 自分が見た「混沌としたドラマ（錯綜する情報）」を要約して部下に伝える

• 変化球（予測不能な事態）にも冷静に対応する

• NOというときははっきりNOという。YESの場合も同様

• 自分がしてきた仕事、自分が学んだ事を部下が行えるようにする（スケーリング）

　現在、私自身がプロジェクトマネージャに近い仕事を求められているため、37章のエッセンスは今後の仕事を進めていく上でとても参考になりました。

■キャリアに対する漠然とした不安がある人のために

　また、最終章「不安な将来」も印象に残りました。今の仕事には満足していますが、それでも「将来のキャリアについて考えないと……」と不安に思うことが何度かあったためです。

　おそらく多くの人が感じたことがあるであろう、「転職したい」と漠然と思う理由について、著者は「データが多すぎるから」と分析しています。

　共に働く人々の人となり、チームや会社の文化、人が集まるところでの駆け引き――こうした膨大なデータに囲まれながら人は仕事をしていると、人は「転職したいなあ」と考えるのだそうです。一方、人の脳は自分の価値観に合わせて重要だと思うものを選び出し、解釈を加えます。そのため、自分にとって心地よい意見ばかりを抽出して「この会社は自分にとって居心地がいいんだ」と思ってしまう場合もあります。

　ですが、人が成長するためには「混乱」「葛藤」が必要だと、著者は説きます。時には失敗することや、自分に異議を唱える人が近くいること、毎週なにかを学ぶことが大事なのだそうです。

　私はこの章を読んで、自分1人だけが悩んでいるのではない、「不安を感じるのは誰でもあることなんだ」と安心することができました。

■実践的なアドバイスを求める人のために

　他にも、興味深いアドバイスがいくつもありました。企業文化を知ること、企業文化の変化に合わせた行動を取ることの重要性（第8章）や、「トリクルリスト」という、ToDoリストとは違った長期的なタスクリストの作り方（第24章）などがある一方で、「時には何もせず、何も生み出さず、何も生産的なことは考えないという時間が必要」（第28章）というメッセージがあったりと、大変興味深いです。

　また、実際に「転職をしよう」と決意した人は、第3章や第35章を読むとよいでしょう。

　転職をする前に、「なぜ転職をしたいのか」をもう一度考えなおすこと、実際に転職をする際に重視すべき基準が述べられています。

　本書は、「技術者たるもの、こうあるべきだ」という自己啓発的な要素は薄いかもしれませんが、日頃の心構えやキャリアに対する考え方というよりも、より実践的な面で非常に勉強なる本です。

■どんなキャリアプランにも必要な「コミュニケーション」

　本書を読んでいて、「コミュニケーションがいかに大切なものか」をつくづく実感しました。マネージャになる、エンジニアとしてスペシャリストを目指す、どんなキャリアを築くにしても、キャリアアップを図るには、仕事の成果を充分に評価してもらうことが必要です。そのためには上司とのコミュニケーションがポイントになってきます（本書ではさまざまな性格の上司とどう仕事していくべきかについても書かれていて、参考になります）。

　自分のキャリアを自分が思うように築き、かつ相応に評価してもらうためにも、コミュニケーション力を身に付ける必要性を改めて感じました。

（『It’s Party Time!』 コラムニスト　あずk）

統合型プロジェクト管理のススメ 梅田 弘之（著） 翔泳社 2010年8月 ISBN-10: 4798122467 ISBN-13: 978-4798122465 2520円（税込）

　なぜ、赤字プロジェクト、失敗プロジェクトはなくならないのでしょうか？

　これまで、システムインテグレーションの現場は、知識やノウハウの伝承についてさまざまな取り組みが行ってきました。それにもかかわらず、満足のいくレベルでプロジェクトを管理できない……。私自身、「これは何かが欠落しているからではないか？」と感じていたため、本書を手に取りました。

■経験に基づいた具体的な「プロジェクト管理」ノウハウを知る

　本書は、PMBOKの知識エリアと合致した章立てで、非常に体系的です。初学者にも分かりやすいように用語の補足やイラスト・図による解説などが充実しており、「プロジェクト管理」を初めて勉強する人が読んでも、十分に理解できるでしょう。

• スコープ管理とWBS
• コスト管理
• タイム管理（スケジュール作成と進捗管理）
• 品質管理
• 要員管理
• 調達管理
• リスク管理
• コミュニケーション管理

　本書の重要なポイントは、「筆者の経験に基づいた具体的なノウハウを紹介していること」「そのため、現場での実践をイメージしやすいこと」です。

　少ないながらもプロジェクト管理の経験がある私にとっては、過去に困った点や難しいと感じた場面と比較し、自身の活動を振り返る機会にもなりました。

■精神論、属人的なプロジェクト管理からの脱却

　「これまでのプロジェクト管理の取り組みは“精神論”主体で、“属人的”アプローチだった」――筆者は本書でこう主張しています。

　どれだけ方法論をうたい、レビューを厳しくしてみても、プロジェクト管理を実行する主体がプロジェクトマネージャという人間である以上、ある程度は個人の能力に依存してしまいます。そこで、標準化やツールの整備が重要になってきます。

　世の中には、プロジェクト管理を補助するためのさまざまなツールがあります。ツールを購入しなくてもいいように、多くの組織ではExcelやWordなどのテンプレートなどを導入していることでしょう。

　しかし、このようなツールがあったとして、「個人の取り組みのバラツキ」は解決できるのでしょうか？ 筆者の意見でもあり、私自身の感覚でもあるのですが、実際には思ったほどの効果を上げられていません。

　何かが足りない……そう、組織としての管理能力を担保するためには、「自動的・強制的にプロジェクトを見える化する仕組み」が必要なのです。WordやExcelといった局所的なツールを準備するだけでは結局、うまくいかない、これが筆者の主張です。

■解決案としての「管理プロセスの強制」

　では、「自動化・強制化」はどう進めればいいのでしょうか。ここで重要なのが、ITです。筆者は、ERPのようにプロセスも含めてパッケージベースでプロジェクト管理を実施する方法を提示しています。

　人間はどうしても手を抜いてしまうし、ミスや抜け漏れだってあります。ある程度は強制しないと、精度や効率は上がりません。一方、現場の人間は諸手を挙げて賛同……というわけにはいかないでしょう。実際は「ただでさえ忙しいのに、管理のために時間が取られるなんて！」というのが通常の反応だと思います。

　そのため、IT技術の力を借りて、管理に必要な情報を手間をかけずに集められるようなパッケージを実現しなければなりませんが、ここで少し考え方を変えてみる必要はありそうです。

　エンジニアの中でも進捗管理の利点を理解している人が増えていますし、エンジニア自身が自分の行程を可視化できるなら、仕事しやすくなります。そのため、プロセスを強制するプロジェクト管理方法は思ったほどの抵抗はないかもしれない、と私は予想しています。

　その点、本書は具体的なツールを例に挙げて説明しているため、現場で働くエンジニアの立場で読んでみても、納得感がありました。

■管理の「型」を通じて、エンジニア自身のスキルも向上させる

　プロセスを強制して、ツールを統一するメリットは、「管理の容易さ」だけではありません。これは、「スキルアップ」にもかなり効果があるのではないでしょうか。

　プロジェクト管理能力を向上させるために、私はこれまで2つの方法で取り組んできました。

　（1） PMBOKなどの体系的な管理領域を机上で学ぶ

　（2） 現場での経験を振り返る、ツールを整備する

　基本的な取り組みとして、（1）のようにPMBOKを読んでみたり、研修を受講してみたりするのはいいでしょう。ただし、それだけでは実際のプロジェクトではお手上げです。

　（2）はより実践に即しています。ケーススタディ形式の研修を受講してみる方法も、（2）に分類できるでしょう。その結果、どれくらいプロジェクト管理能力がついたのか……正直なところ、あまりよく分かりません。このままでは、「プロジェクト管理は経験が重要」という精神論、根性論に陥ってしまい、根本的な解決になりません。

　本書は、上記の2つの方法に加えて、もう1つの方法を紹介しています。それは、「パッケージを使用して学ぶ」という方法です。ここでいうパッケージとは、プロジェクト管理用のアプリケーションです。

　これは、言われてみると納得感がありました。なぜなら、プロジェクト管理は仕組みとツールが合わさって、初めて効果が出るからです。私の経験上、頭でっかちな方法論や知識だけだと現場では通用しなかったし、ツールといってもしょせんExcelやWordで作ったものの寄せ集めで、統一感も網羅感もありませんでした（管理パッケージを使用していなかっただけではありますが）。

　きちんとプロジェクト管理用に機能を備えたツールを通じて、手を動かしながらスキルアップしていく――これは確かに効果が高そうです。何事も習うより慣れろ、です。

　個人的に、何かを始める時に“型”を知ることは、上達のためにとても重要だと考えています。その点では、PMBOKもプロジェクト管理の型を提供しているわけですが、これは実体のない抽象的なものにすぎません。目に見えて、強制力もある“型”があれば、学習にはもってこいです。そう、筋力養成ギブスのようなものです。2～3回ほど、プロジェクト開始から終わりまでの手順を流してみれば、プロジェクト管理・進行の型を、はっきりとした形で体感できます。

　もし、新人教育の時から同じ型を使って研修やOJTを進めていけば、新人がやがてリーダーやプロジェクトマネージャになっても、同じ要領で仕事ができるので、相当に効率的です。従来に比べて、教育する側としても効率的にノウハウを伝授できるのではないでしょうか。

　「ツールが強制されることによる学習促進」は、これまでに考えたことがなかったのですが、プロジェクト管理力を向上するためには、とても有効な取り組みだと感じました。

■まとめ

　プロジェクト管理において、マネージャのスキルが大事であることは間違いありません。ただし、チームとして、組織として、プロジェクトを成功につなげるためには、個人のスキルだけに頼るわけにはいきません。やはり、適切で合理的な手法、具体的なツールの存在が必要不可欠です。

　本書は、最後に「組織全体でのプロジェクト管理」について述べています。複数のプロジェクトをまたがる管理は、「プログラム管理」と呼ばれる領域です。組織としての管理の場合、プロジェクトを横断した一元管理が重要となるため、この部分は参考になりました。

　効率化、改善を個人の工夫に頼っているうちは、うまくいきません。本書を読んだことで、「個人の工夫で乗り切ろう」と頭のどこかで考えていた自分自身を反省する機会もできました。また、本書は充実した知識とコラムも特徴的です。ノウハウ本としてだけではなく、読み物としても楽しめるつくりになっています。

　ぜひ、こんな人に読んで欲しい1冊です。

• プロジェクト管理を精神論でこなそうとする管理者
• プロジェクト管理を開発のオマケのように捉えている技術者・管理者
• 若手エンジニア、これからプロジェクト管理を始める人

　システムインテグレーションの現場では、旧態依然としたプロジェクト管理が横行してしまっていると感じてなりません。ちょっと刺激の強い言葉で書いてしまいましたが、もう一度、組織としての管理力向上につながる取り組みができているかは、考えてみるといいのではないでしょうか。

　また、若手エンジニアやこれから管理を始める人には、「1つの目指す姿」として眺めてもらうと、今後チームをリードする際に役立つと思います。

　自分自身の活動や組織においても、みんなが幸せになれるプロジェクト管理が実現できるようになりたいものです。

リーンソフトウェア開発と組織改革 Mary and Tom Poppendieck（著） 依田光江（翻訳） 依田智夫（監訳） アスキー・メディアワークス 2010年10月 ISBN-10: 4048687417 ISBN-13: 978-4048687416 2940円（税込）

■偉大なリーダーはあらゆるレベルに存在する

　ソフトウェア開発における「リーダー」というと、皆さんはどんな人物を思い浮かべるでしょうか。顧客を喜ばせるようなビジョンが作れる人？ 卓越した専門性を持つ技術リーダー？ 制約（コストや納期）の中でプロジェクトを完遂させる実装の主導者？ たゆまぬ組織改善を行う指導者？ 最前線に立って周囲の人々に大きな影響を与える現場のリーダー？

　どれもが正解ではないでしょうか。というのも、ひとことで「リーダー」といっても、さまざまなフェイズに、さまざまなタイプのリーダーが必要とされるからです。

　「リーン開発」の提唱者、メアリー・ポッペンディーク氏とトム・ポッペンディーク氏は、『リーンソフトウェア開発と組織改革』で、次のように語っています。

　「偉大な企業は組織のあらゆるレベルに偉大なリーダーがいるのだ。さもなければ彼らは偉大な企業になっていなかった」（p.311）

■24のフレームと、6つのリーダー像

　本書は『リーンソフトウエア開発――アジャイル開発を実践する22の方法』『リーン開発の本質――ソフトウエア開発に活かす7つの原則』に続く「リーン開発シリーズ」の第3弾です。リーンの視点から、組織改革と、それを実現するリーダー像について論じているのが特徴です。

　全体の構成として、24のフレームが提示されています。それらは6つの章に分けられており、1章につき4つのフレームを解説されています。各章の最後には、対応するリーダー像が示されており、「どのフレームではどんなリーダーシップが求められるか」が確認できます。

• 第1章「システム思考」
• フレーム1：顧客中心
• フレーム2：システムの能力
• フレーム3：開始から終了までのフロー
• フレーム4：ポリシーが生み出すムダ
• 第2章「技術的卓越性」
• フレーム5：本質的複雑性
• フレーム6：構成的な実装による品質
• フレーム7：進化型開発
• フレーム8：深い専門性
• 第3章「確実なデリバリ」
• フレーム9：裏づけのある実績
• フレーム10：ワークフローの平準化
• フレーム11：プル型スケジューリング
• フレーム12：適応制御
• 第4章「たゆまぬ改善」
• フレーム13：完璧を視覚化する
• フレーム14：ベースラインを決める
• フレーム15：問題を顕在化させる
• フレーム16：改善の仕方を学ぶ
• 第5章「人こそすべて」
• フレーム17：知識労働者
• フレーム18：「助け合い」という規範
• フレーム19：相互尊重
• フレーム20：熟練の誇り
• 第6章「連携型リーダー」
• フレーム21：理論から実践へ
• フレーム22：ガバナンス
• フレーム23：団結
• フレーム24：持続可能性

　これらのフレームから導かれるリーダー像とはどんなものでしょうか。第1章では「製品のアイデアにシステム思考を取り入れる『製品チャンピオン、テイク1』」、第2章では「優れたテクノロジの開発に全力で取り組む『高能力・高業績（コンピテンシー）リーダー』」、第3章では「制約、リスク、スケジュールを管理し、実装を主導する『製品チャンピオン、テイク2』」、第4章では「たゆまぬ組織改善に努める『メンターとしてのマネージャー』」、第5章では「現場において人々に影響を与える『前線のリーダー』」の人物像が描かれます。それらを踏まえ、第6章では『あらゆるレベルのリーダー』の人物像がまとめられています。

■結果に着目するのは誤りである

　ところで、本書は技術書なのでしょうか。それともビジネス書？ 恐らくは両方です。例えば第2章「技術的卓越性」では、テスト駆動開発や継続的統合といった手法をソフトウェア工学の歴史の延長上に位置付ける形で解説しています。また、第3章「確実なデリバリ」では、「制約に合わせて活動を設計する」というシステム設計の考え方を、エンパイアステートビルの建築プロジェクトを例にとって解説しています。その一方で、第4章「たゆまぬ改善」や第5章「人こそすべて」において、マネジメントや組織改善といった課題への取り組みについて論じています。

　読み手によって、どの章を面白いと思うかは分かれるのではないでしょうか。そしてそれこそが、その人が「どのタイプのリーダー向きか」を表す鏡として機能します。

　ただし、共通する視点も存在します。その1つが、原書の副題ともなっている“Results Are Not the Point”です。「ベロシティの高い企業」（業界を常にリードしている企業）について、本書では次のように書かれています。

　「ベロシティの高い企業は複雑性にどう対応するかを予測しようとせず、複雑性を学ぶことに集中する」（p.217）

　「ベロシティの高い組織は、予定とのずれを、学習する好機として歓迎し、仕事の複雑性についてもっとよく知ろうとするのだ。ベロシティの高い組織は仕事を終わらせることではなく、仕事を終わらせる方法を学ぶことに重点を置く」（p.217）

　別の章では、知的労働について、次のように書かれています。

　「知的労働では、人と、人が働くシステムなくして成功はありえない。結果が肝心なのではない。人とシステムを育成し、両者の力が合わさって成功を達成できるようになることが肝心なのだ」（p.260）

　組織を改善し、人を育てながら、制約の中で素晴らしい成果を作り上げるのは、並大抵のことではありません。それを可能とするシステムを作り上げるのが、リーダーの仕事なのではないでしょうか。

　本書の最後には、「偉大な企業のあらゆるレベルに見られるリーダーの人物像」がまとめられています。これらを参考にして、偉大なリーダーとして自分のチームや会社を改善させることに、ぜひ挑戦してほしいと思います。

• リーダーは目的を示す
• リーダーはトーンとテンポを決める
• リーダーは人を成長させる
• リーダーは他者が成功するための場所を作る

NASAのチームビルディング チャールズ・J・ペレリン（著） アチーブメント出版 2010年6月 ISBN-10: 4902222892 ISBN-13:978-490222289 2100円（税込み）

■技術者のための本である

　「予算は削減、スケジュールも短縮」「下請けへの圧力」「何か問題があると、すぐにマネージャが入れ替わる」「メンバーは総じてマイペースな職人タイプで、他人との触れ合いを最小限にとどめたい傾向にある」――。

　どこかで聞いたことがあるような話だが、上記はアメリカ航空宇宙局（NASA）の開発プロジェクトに携わるエンジニアや学者の日常である。

　本書の著者は、NASAの天体物理学部門でプロジェクトを指揮してきたマネージャだ。本書にはNASAプロジェクトの話（デスマーチなネタもある）が随所にちりばめられていて、「ああ、NASAのエンジニアも同じようなことで悩んでいるのだなあ……」と、奇妙な親近感が生まれる。

　スペースシャトルでもソフトウェアでも、チームでプロダクトを制作する仕事内容は同じ。それゆえ、「NASAが活用するチームビルディング」手法を紹介する本書は、ITエンジニアにとっても役立つ。「なぜうちのチームはうまくいかないのか」「チーム内の生産性を改善したい」と考えるプロジェクトマネージャ、メンバーにはうってつけだ。

■なぜ、ハッブル宇宙望遠鏡は失敗したのか

　著者が編み出したチームビルディングメソッドの「4‐Dシステム」は、「まれに見る大失敗」プロジェクトから生まれている。 打ち上げ後に主鏡のゆがみが発覚した「ハッブル宇宙望遠鏡」打ち上げプロジェクトだ。

　17億ドルという巨額な投資をして、最高レベルの技術を持つ技術者が作り、検査に検査を重ねたはずなのに、なぜハッブル宇宙望遠鏡のミスは見逃されたのか？

　事故調査委員会は、失敗の理由を「リーダーシップの欠如」であると断定した。調査の結果、NASA側がレンズ制作を担当した下請け業者に高圧的な態度で接していたことが発覚。辟易した下請けの技術者たちは、いわれるがままに動いてしまっていた。チームはまとまりを欠き、皆がスケジュールに追われ、誰かが発見すべきだったミスは看過された。

　どんなに計算が正しくても、どんなに検証を重ねても、人は間違える。

　「80～90％の失敗の原因は、突き詰めると人的ミス、あるいはコミュニケーション不足に起因している」（p.37）

■リーダー＆チームの色は何色か？ 4タイプに分類

　ハッブル打ち上げ計画の責任者であった著者はNASAを辞職し、大学でリーダーシップを教えながらチームビルディング手法である「4-Dシステム」を編み出した。

• How NASA Builds Teams（英語）

　「何事もできるだけシンプルに作られなければならない。しかし、シンプルにしすぎてはならない」というアインシュタインの言葉どおり、「4-Dシステム」は非常にシンプルだ。「直観的＝知覚的」という縦軸と「感情的＝論理的」という横軸で、リーダーシップを4タイプに分類している（自分がどのタイプにいるかは、本書の簡易質問、およびWebサイトで確認できる）。

• 感情的×直観的＝育成型（緑）
• 感情的×知覚的＝受容型（黄）
• 論理的×直観的＝先見型（青）
• 論理的×知覚的＝統率型（オレンジ）

　本書がユニークなのは「チームの規模とプロジェクトの時期によって、求められるリーダーシップの型が違う」と指摘しているところだ。例えば、先見型のリーダーは豊富なアイデアでもってビジョンを示すため、プロジェクトの初期段階や企画に向いている。プロジェクトの仕様が固まってくると、統率型が力を発揮する。受容型や育成型はとにかく人間関係を重視するため、大規模かつ複雑なチームのマネジメントに向いている。

　この4タイプは「チーム全体の文化」にも当てはまる。例えば、技術者のチームでは「アイデアとひらめき重視の先見型」「チームで規律正しく動く統率型」のどちらかになることが多いという。チームと自分のタイプが合致していればうまくいく。

■顧客はどのタイプかを考える

　さらに、著者は「この分類を、顧客側にも当てはめて考えてみよ」と指摘する。例えば、顧客が役所などの「統率型」チームであるとしよう。統率型の顧客と一緒にする場合、正反対のタイプである「育成型」などは相性が悪い。統率型の考え方を理解してミーティングに臨むか、あるいは交渉役を「統率型」に変えた方がよい。

　プロジェクトの失敗は多くの場合、チーム全体のタイプとリーダーのタイプ、あるいはチームと顧客のタイプがうまく合わないときに起こる。

■長くなったのでまとめ

　自分を知り、チームを知り、相手を知る。そして、そのうえで改善方法を決める。本書のアプローチはシンプルで分かりやすい。「4-Dシステム」の宣伝的な部分がやや目につくが、論理的かつ簡潔な文章でまとまっている。

　余談だが、興味深かったのが「自分の出方次第で相手の反応が変わる」ことを筆者が説明する際の会話だ。相手は、民間の航空宇宙会社に勤める職員である。

　「すべてはコンテクスト次第で、御社の得意先が、あなたの発言や態度をどのように解釈するかが変わるんです」

　「おっしゃる意味が、よく分かりません」

　「たとえば物理の話に置き換えてみましょう。あなたと得意先の人が電子だとします。何が起こりますか？」

　「強い反発作用を示します」

　「そのとおりです。では、あなたが中性子に変わったらどうですか？」

　「反発作用はなくなります……つまり、わたしが変われば関係性も変化するということですね」

　そうか、その例だと分かるのか……。

二次請けマネージャの教科書 松本哲也（著） 技術評論社 2010年6月 ISBN-10:4774142913 ISBN-13:978-4774142913 1659円（税込み）

■「一次請けは技術が分かってない。無理ばかりいってくる」

　システム開発においては、一次請け企業と二次請け企業（場合によっては、さらに三次請け企業、四次請け企業……）が存在する。二次請け企業からすると、一次請け企業には次のようなイメージがあるかもしれない。

• 一次請け企業は無理ばかりいう
• 一次請け企業には技術力がない

　だが、一次請け企業の側に立ってみると、「そもそも顧客から無理な要求をされている」「早い段階では、なかなか二次請け企業にお願いできる仕事の形にならない」から、結果的に二次請け企業に対しても無理をいうことになってしまっているのかもしれない。「技術力のあるメンバーは一次請け企業にも存在するが、プロジェクトの件数に対して足りておらず、技術の分かっていないプロジェクトマネージャが出てきてしまう」のかもしれない。

　では、こうした状況で、二次請け企業のマネージャはどうするべきなのだろうか、というのが本書の主題だ。

■一次請け企業の弱みは、二次請け企業の強みである

　二次請けも一次請けも経験している筆者は、まず「一次請けが二次請けに何を期待しているのか」を説明する。筆者によれば、一次請け企業のマネージャが二次請け企業のマネージャに期待しているのは、決して「指示に従う」「いうことを聞く」ことではない。では何か。「開発の技術」である。二次請けマネージャは、開発のプロフェッショナルでなければならないのだ。

　これに加えて、一次請けマネージャは「管理能力」と「調整能力」を二次請けマネージャに求めている。

　前者は、具体的には「プロジェクトマネジメントのサポート」だ。一次請け企業では、熟練マネージャが案件数に対して少ないため、未熟なマネージャがつくことが往々にしてある。また、一次請けマネージャはジェネラリストであることが多く、専門的な知識が薄い傾向にある。だからこそ、二次請けマネージャはプロジェクトマネジメントのサポートが求められる。

　後者は、要望をそのままこなすのではなく、より良い方法で問題を解決してくれるような「調整」の能力を指す。仕事を依頼する側は、すべての作業に対して細かい配慮ができているわけではない。だから、二次請けマネージャは、作業効率を考慮したスケジュールの作成などが求められる。

　なんだか「一次請けは何もしていない」ように見える（そして、事実そういう企業もあるかもしれない）。だが、逆にいえば、これらは「一次受けではできないこと」であり、「二次請けに求めていること」でもある。「一次請けの弱み」であり、「二次請けの強み」だ。

■一次請け企業とは何なのか

　そもそも「一次請け／二次請け」という構造がよろしくない……という議論は、確かにある。だが現在、二次請け企業のマネージャであるならば、一次請けと協力し、プロジェクトを成功させるためのノウハウを知っておいて損はない。

　本書には、筆者の経験に即したノウハウが詰まっている。そして同時に、そこからは「一次請け企業とは何なのか」「一次請けマネージャは何を考えているのか」が透けて見える。

　いずれ一次請けマネージャになりたいと考えている人や、そもそも多重構造は正しくないと考えている人にとっても、参考になる内容だろう。