プロジェクト・マネジャーが知るべき 97 のこと

きのこ本 友の会

プロジェクト・マネジャーが知るべき 97 のこと

% 2020-05-09

【01】できるだけ早期にユーザーを巻き込む

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　これまでのソフトウェア開発は、ユーザー要求を確認したら、あとは秘密のベールに隠れてコーディングとテストを進めるというものでした。どうせユーザーは、私たちがやっていることなんて理解していません。プロジェクトの終盤、マジシャンの魔法の布をさっと取り除けば、ユーザーは出来上がったもののすばらしさに「おおー」とか「わあ」とか感嘆の声を上げるはずです。ところが残念ながら、ほとんどの場合、そうではありません。「あぁ、君たちがよくやっていたのは知ってるよ。でも本当に望んでいたのはね……」と言うのです。

　プロジェクトを成功させる秘訣は、何か見せられるものができたらすぐにユーザーを巻き込むことです。プロジェクト完了後に問題が見つかるよりも、開発の初期に問題が見つかる方が、はるかによいことだからです。

　スケジュールが進むにつれ、変更のコストはどんどん高くなっていきます。さらに改善しようとプログラムを直して再びテストする時間も、まわりにある関連コードとのインテグレーションをテストする時間も、プロジェクトを大幅に遅らせます。また、変更があまりに大きすぎて、変更管理委員会（Change Control Board）の承認プロセスを通さなくてはならなくなると、時間もコストも危機にさらされます。

　たとえ非常に些細な問題に対する実装上の判断であり、ソフトウェア開発者とプロジェクト・マネジャーにとっては完全に筋が通っていたとしても、ソフトウェアを実際に利用している現場では大変なことになっているかもしれません。

　私は発注ソフトウェアの再設計に 500 万ドルもかけた巨大な研修会社を知っています。これまでのシステムでは、アイテム番号が各製品に対応しており、ある論理的な方法で番号が付けられていました。例えば、4125 は学生用マニュアル、4225 は学生練習用の付属ディスク、4325 は講師用マニュアル、4425 は販促用の講座概要といった具合にです。4x25 という一連のアイテムはすべて、同一画面で注文できるようになっていました。

　世界 140 か所にいる運営コーディネータは 1 日に何度も同じ教材を発注するので、すぐにそのアイテム番号を覚えてしまいます。学生用マニュアルの番号を覚えると、調べなくてもすぐに他の関連するアイテムの番号も入力できるようになりました。おかげで彼らはすばやく注文することができました。

　このソフトウェアを再設計するにあたり、担当したプロジェクトチームは、実際の現場で使われていた発注プロセスについて考慮するのを忘れてしまいました。新しい設計では、アイテム間の論理的な関係が失われてしまったのです。以前は 4125 だった学生用マニュアルは 6358 になりました。そして学生練習用の付属ディスクは 8872 に、同じクラスの講師用マニュアルは 3392 になりました。

　ユーザーは新しいアイテム番号を調べないといけなくなり、また、以前の番号と発注システムのことを忘れなくてはなりませんでした。しかも、関連するアイテムは別のページになってしまいました。

　運営コーディネータは、それはもう激怒しました。発注に時間がかかるようになってしまったのですから。結局やり直して、そのプロジェクトは決められた時間とコストをはるかにオーバーしてしまいました。

　プロジェクト・マネジャーとして、あなたはユーザーとソフトウェア開発者が早期にかつ頻繁に話し合えるようにしなくてはなりません。

【02】モグラたたき開発を避けよう

ベンカト・スブラマニアム（Venkat Subramaniam）

アメリカ、コロラド州ブルームフィールド

　ソフトウェアプロジェクト・マネジャーは早く納品するための様々なプレッシャーに直面しています。とりわけ時間は重要です。どうすればすばやく仕事を片付けられるのでしょうか？

　チームにバーニーとロブという 2 人のプログラマがいるとしましょう。2 人とも有能で、同程度のドメイン知識を持ち合わせており、言語スキルも同じくらいです。開発を進めるうちに、あなたはロブよりもバーニーの方がすばやく機能実装を終えていることに気づきました。

　バーニーがコードをすばやく仕上げることに専念している一方、ロブはコードのリファクタリングに時間をかけていました。ロブの方が変数や関数にうまく名前を付けていました。コードが動くようになっても、ロブはコードをもっと小さな部品に分割しました。それから、コードの各部品が意図通りに動いていることを確かめるため、テスト仕様を書いていました。そしてある程度満足がいったところで、ロブはその機能のコーディングが完了したと宣言していたのです。

　ところが、こういった細かいことについて、あなたは何も知らなかったとしましょう。機能が完了したと宣言するスピードだけを見れば、明らかにバーニーの方がすぐれているとは思いませんか？

　数週間後、顧客に新しい機能をデモすることになりました。いつも通り、顧客は完成した機能を気に入ってくれましたが、今回はいくつか変更と改善を依頼されました。そこで、あなたは開発者にコードを変更するよう依頼しました。

　やがて、新たに改善した機能を顧客のもとに持っていきました。顧客はロブが実装した機能を試して、その変更に満足してくれました。

　ところが残念なことに、顧客はバーニーが実装した機能におかしなところを見つけました。新しい機能についてはうまくプログラムできていたのですが、以前はうまく動いていたのに動かなくなったところがいくつか見つかったのです。顧客はこれらを欠陥だと見なしました。あなたはバーニーに修正を依頼します。そうして、顧客はもう一度その機能をテストしました。今度はまた別のところでおかしなことが起こりました。どうやら何かが壊れているようです。一体何が起こっているのでしょうか？

　あなたに子どもがいるなら、どんなことが起こっているのかわかるはずです。バーニーはモグラたたきのようなものを作っているのです。モグラたたきはゲームの一種です。子どもたちは木製のハンマーを手にして、ランダムに顔をのぞかせるモグラをたたきます。モグラが次にどこから顔をのぞかせるのかわからないので、子どもたちは喜びます。しかし、あちこちランダムに壊れたコードが顔をのぞかせるようなアプリケーションを修正するのは、少しも楽しいことではありません。それはあなたをイライラさせ、今後どうなるか予測もできません。そして、製品開発を遅らせます。バーニーは最初にダッシュしましたが、間違った方向に走ってしまったのです。

　ロブは最初は遅いように見えたのですが、実際には質の高いコードを書いていたのです。彼のペースは持続可能なものでした。最初からコードの品質が高かったので、動作可能なまま、すばやく変更することができました。しかも、最初に書いておいたテスト仕様のおかげで、新しいコードが他の部分と互換性を保てているか、すぐにフィードバックを得ることができました。

　機能実装にかかった時間を計測するときには、最初にその機能を書き上げるのにかかった時間だけを考慮してはいけません。コードの強化、修正、改善にかかった時間も加えてください。品質の高いコードとテストを書くのには時間がかかります。これは短期的には損失に見えますが、長期的には利益をもたらします。

　とにかくスピードがあればよいのか、持続可能な進歩を得たいのか、自分自身に問いかけましょう。

【03】ローカライゼーションのせいで締め切りに遅れる

パベル・シムサ（Pavel Simsa）PMP

アメリカ、ワシントン州ベルビュー

　どういったローカライゼーションのせいで締め切りに遅れるのでしょうか？　答えは「どんなローカライゼーションでも起こり得る」です。英語以外の言語でリリースされる製品を開発している場合、プロジェクトには新たなリスクと制約が多数加わっています。

　技術的なものもあれば自明なものもあります。例えば製品を日本語でリリースするなら、適切なフォントをサポートする必要があります。もしそれができていないと、たとえ英語版は完全に動作しても、日本語版はうまく動作しないでしょう。しかし、フォントの互換性はあなたが管理しているわけではありません。あなたとあなたのチームは、さまざまな注意事項があることを事前に認識し、コーディングに入る前に十分検討しておく必要があります。自分たちの開発プラクティスがそうした問題を取り除く国際的標準に準拠しているか確認しましょう。

　ローカライズ版が必要になるだけで、あなたが下せる判断とそのタイミングは制約されます。通常ローカライゼーション（日本語、スウェーデン語、ドイツ語など）は、ある一定の遅延をもって英語版の開発と並行して実施されます。その遅延は数日や数週間、場合によっては数か月になることもあります。しかし、どこかの時点で、ローカライズ版の翻訳が英語版に「追いつく」必要があります。

　テストやレビューでは、以下を確認しておく必要があります。

英語版にあるものが適切に翻訳されていること

翻訳されたものが正確に英語版と一致していること

翻訳版が完全に機能すること

　ここで問題があります。これら 3 つのポイントは、英語版が完成して出荷判定された後に、テストされるかもしれません。ところが、ローカライズ版のテストとレビューをしているうちに、英語版を変更しないと解決困難な問題が少なくとも 1 つは見つかるものなのです。

　英語版に対する土壇場の変更が、たとえ文章の言い換えなど（数秒のコーディングで済むような）比較的単純でリスクの低いものであっても、それを実装してすべてのローカライズ版を再テストするためには、数日はかかってしまうことを認識しておきましょう。

　これは数千ドルもの余計なコストをもたらします。翻訳作業を外部委託しているなら、なおさらです。経験の浅いソフトウェア開発プロジェクト・マネジャーがよくやる間違いは単純です。英語版に対する予期せぬ変更の影響と重大さを、甘く見てしまっているのです。

　これを避けるために、あなたができることは大きく 2 つあります。

スケジュールの最後に「ローカライゼーション・バッファ」という予備期間を用意しておきましょう。スケジュールの最後というのは、プロジェクト全体のスケジュールにおける、英語版作業の事実上の締め切りを意味しています。目標とする最終日以後に必要になった変更は、非常に明確かつ厳格な基準を満たさない限り、スケジュールに追加してはいけません。また、英語版を変更するたびにローカライズ版も忘れずに変更する必要があります。

機能の品質管理は、英文の品質レビューとは別に行われるよう、タスクを並べてください。すべての英文を校正用の表にコピーしてレビューするといったことは、簡単に実現できます。こうすることで製品を実際に動かしてテストするうちに不明瞭な言葉遣いを見つけるのではなく、英文の品質レビューにおいて事前に問題を発見できます。これによって必要な変更が早期にできるようになり、ほかのローカライズ版で変更し直す必要はなくなるでしょう。

【04】プロジェクト・オーナーは強力なプロジェクトサポーター

武谷 美世子（Miyoko Takeya）PMP

日本、東京都

　プロジェクトの失敗というのはアメリカの企業だけの問題ではありません。以前、日本の代表的な IT 関連雑誌が実施した調査結果によると、「品質」、「コスト」、「納期」の 3 つの評価基準で測定した場合、日本の企業が取り組んだプロジェクトの 75% 以上が失敗と見なされるそうです。

　日本もほかの多くの国と同様、各評価基準における失敗の一番の理由は、不十分な要件定義です。失敗リスクの高いのは、業務分析が不十分な場合で、ソフトウェア開発等の情報システムプロジェクトについて言えば、業務分析能力が低い場合、成功の可能性は低くなります。このことは、ソフトウェア開発プロジェクトでは、真の要件を見つけ、特定し、定義するのが、成功のために必須であることを示しています。

　システム規模や複雑度にもよりますが、要件定義は大変難しいことがあるにもかかわらず、顧客やプロジェクト・スポンサー、企業幹部といったプロジェクト・オーナーは、プロジェクト・マネジャーにソフトウェアの要件定義を任せきりにすることもあります。中には、ソフトウェア開発プロジェクトの特性についての理解が低く、自分たちの期待は何か、何を必要としているのか、明確なアドバイスや定義に関与する必要はないと思っているオーナーもいます。

　一方、プロジェクト・マネジャー自身は、ヒアリング等で洗い出されたプロジェクト要件に対し、選択し優先順位の決定を行うまでの権限を持っていないことも多く、調整するための時間も限られています。要件定義にかかわるグループが沢山あり、それぞれが持つ完成したソフトウェアへの期待にズレや対立がある場合、プロジェクト・マネジャーは、プロジェクト要件の選択や優先順位づけにさらに苦慮することになります。

　様々で相反する可能性のある要求から、真に必要なプロジェクト要件を選択し最終決定する権限は、プロジェクト・オーナーにあります。プロジェクト・マネジャーは、要件定義のフェーズの中で、プロジェクト・オーナーと共に、このプロジェクトにより何を行いたいのかにつき、真剣かつ具体的に検討しておかないと、必要な機能が不足したり、使われない機能に時間やコストが費やされるなどし、プロジェクトの成功を危うくすることになります。

　プロジェクト・オーナーには、どのようにソフトウェア開発をするというのではなく、そのプロジェクトの真の目的や狙い、必要となる要件につき、正しくプロジェクト・マネジャーに伝えてもらうことが必要です。その上で、プロジェクト・マネジャーは、プロジェクト・オーナーの要求に合致した品質・コスト・納期を満たすよう、プロジェクト組織を編成し計画を立案し、プロジェクトを実施できるようになります。すなわち、プロジェクト・マネジャーは、プロジェクト・オーナーが、強力なプロジェクト・サポーターであることを認識し、プロジェクト・オーナーの持つ力を活用することが肝要です。

　プロジェクト・マネジャーは、確かな要件定義をすることにより、費用対効果、プロジェクト目標、プロジェクト成果の明確な関係づけができることを、プロジェクト・オーナーには十分理解してもらう必要があります。さもないと、そのプロジェクトは、プロジェクト・オーナーが期待する満足のいく結果を生み出せないでしょう。

　プロジェクトの失敗は、プロジェクト・オーナー自身を最も傷つけます。なぜなら、彼らはそのプロジェクトのために資金を提供し、そのソフトウェアを使って投資を回収することを期待していたのですから。プロジェクト成功のために、プロジェクト・オーナーの力を最大限活用することは、プロジェクト・マネジャーの義務であり、責任であると言えます。

【05】複雑よりもシンプルな方がいい

スコット・デイビス（Scott Davis）

アメリカ、コロラド州ブルームフィールド

　私に言わせれば、電子レンジには「1 分加熱」というボタンが 1 つあれば十分です。コーヒー用の水を沸かすときには、そのボタンを 3 回押します。クラッカーにのせるチーズを溶かすときには、ボタンを 1 回押します。小麦粉のトルティーヤを温めるときには、「1 分加熱」ボタンを 1 回押してから 15 秒後にドアを開けます。

　このワンボタン電子レンジが、商品企画委員会をパスしたことはあるのでしょうか？　おそらくないでしょうね。今の電子レンジの（決して使われることのない）機能を見れば、委員会がシンプルなものより複雑なものを好んでいることがわかります。もちろん、彼らはその「複雑さ」を「機能豊富」という言い回しで隠したのでしょう。しかし、いたずらに複雑な製品を作ることを目標にして作り始める人などいません。複雑さは知らず知らずのうちについてくるのです。

　1 枚の冷凍ピザを温めたいとしましょう。メーカーの取扱説明書によると、まず「メニュー」ボタンを押さなくてはなりません。すると今度は「スピード調理」と「再加熱」というオプションが現れました。（うーん、おそらく「再加熱」でしょうね。お腹がすいているので、スピードの早い方がよいのですが）

　「再加熱」を選ぶと、今度は「飲み物」、「パスタ」、「ピザ」、「料理皿」、「ソース」、「スープ」というオプションが現れました。さて、どれでしょう？（ピザの上にはソースがのっているのですが、ここでは「ピザ」を選ぶことにします）。すると今度は「惣菜 / 生もの」か「冷凍」です。（実際にはどちらでもありません。これは宅配ピザの残り物なのです。おそらく「惣菜 / 生もの」を選ぶのでしょう。）すると今度は「1 枚」、「2 枚」、「3 枚」、「4 枚」ですって？　この質問があとどれくらい続くのか、私には見当もつきません。そこで私は「キャンセル」を押して、「1 分加熱」ボタンを押すことにします。

　この話はソフトウェア開発とどんな関係があるのでしょうか？　私に言わせれば、ワンボタン機能があるのは Amazon だけです。つまり「1-Click 購入」です。確かに初回は住所とクレジットカード番号を入力する必要がありますが、以後はマウスを 1 回クリックするだけで衝動買いできるのです。

　一般的に、ソフトウェアは複雑な問題を解決してくれるものです。ここで問題になるのは、本来の複雑さをどれくらいエンドユーザーに強いるかです。あなたのソフトウェアは複雑さの増幅器になっていませんか？　一般的に、すばらしいソフトウェアというのは複雑さを吸収してくれるものです。問題をユーザーに伝えるのではなく、ユーザーの身代りとなって問題の矢面に立つのです。

　ソフトウェアプロジェクト・マネジャーとして、あなたは複雑さを吸収しようとしていますか？　それとも、複雑さの増幅器になっていますか？　最高のプロジェクト・マネジャーは、あらゆるところ（プログラマ、エンドユーザー、マネジメント）に存在する複雑さを吸収します。決してそれを増幅することはありません。エンドユーザーは一見して矛盾のある要求をするものです。プロジェクト・マネジャーの仕事は、そうした矛盾のある要求の整理を手伝うことです。やみくもに要求を開発者に伝えることが仕事なのではありません。開発者は難解な技術的理由を挙げて、要求を満たせないことを説明するものです。プロジェクト・マネジャーの仕事は、その複雑さを言い換えて（吸収して）、エンドユーザーに別の選択肢を選ばせるのに役立つ情報を提供することです。

　あなたのアプリケーションはどれくらい簡単に使えますか？　アプリケーションに新しい機能を追加するのはどれくらい簡単ですか？　新しい機能を要求するのはどれくらい簡単ですか？　バグレポートはどうですか？　新しいバージョンの展開はどうですか？　不具合のあるバージョンを元に戻すのはどうですか？

　知らず知らずのうちにシンプルになるわけではありません。自分たちで積極的に育てていく必要があります。よく注意していないと、ものごとは複雑になるものなのです。

【06】負債を支払う

ブライアン・スレッテン（Brian Sletten）

アメリア、カリフォルニア州ビバリーヒルズ

　うまく管理できている限り、借入金（負債）は一般市民にとっても、成功している組織にとっても、有用な資金確保手段です。借入金を利用することで、将来の余剰金を借用して、現在の不足分を清算できます。賢く使えば、短期的借入金は現金の増減の凹凸をなだらかにする効果的なツールとなります。しかし使い方を間違うと、時が経つにつれて徐々に負担が大きくなり、やっかいな重荷となります。

　ソフトウェア開発の世界において、時間を借用するということは、やるべきことを何とかやり遂げながら、リスクのあるマイルストーンを達成するのに役立つ戦略です。ワード・カニンガムは、イテレーションの終わりや締め切りに向かいつつ、時間が足らないときに開発者が負担するものとして、「技術的負債」という考えを取り入れました。その時点では、完璧なコードは書けないかもしれませんが、いくぶん手抜きをすれば、開発者は完了基準に「十分適合した」コードなら書けるかもしれません。

　たとえソフトウェアが一時的に不完全な状態になっても、負担した技術的負債が責任をもって管理されているなら、これはまったく理にかなっています。しかし、技術的負債が支払えないでいると、やがてこれは苦痛になってきます。負債を返済せずに将来を担保にして借用し続けると、プロジェクトはさらに危険にさらされていきます。

　技術的負債を支払う一番よい方法は、各イテレーションの終わりにどんな「ローン」を組むか評価することです。開発者に依頼しましょう。やり直したいハックを具体的に特定して、それをやり直すのにどれくらいの時間が必要になりそうか、数値化してもらうのです。今すぐに負債を支払う必要はありませんが、どんな近道をしたのか開発者の頭の中に残っているうちに、今後必要になる修正範囲を調べておくのはよいことです。

　時間を好きなだけ要求するのではなく、コード上で書き直すべき問題が具体的にあるか確認しましょう。これはサボるチャンスではありません。コードベースをきれいにしておくための規律あるアプローチなのです。

　また、コードカバレッジ、カップリング分析、スタイル違反検出といったソフトウェア分析ツールがいろいろと出てきていますが、こうしたツールは負債が生じたところを自動的に特定するのに役立ちます。おそらく専門的な知識はほとんど必要ないはずです。こうして見つけた案件は課題管理システムに投入しておき、将来のイテレーションで実施するようスケジュールを立てましょう。新しいビジネス機能の開発とローンの支払いを盛り込み負荷のバランスをとることによって、顧客の機能要求を満足させながらも、技術的負債が手に負えなくなるのを防ぐことができます。

　ソフトウェアはいろいろな理由から不恰好になっていきます。しかし、ほとんどの責任は、ハックや不十分なドキュメント、不適切な依存関係、近道、意図した設計からの逸脱といったところにあります。開発者が降参してしまい、もう一度最初からやり直す必要があると言うときは、未払いの技術的負債が手に負えなくなったときです。彼らはソフトウェアを「破産同然だ」と宣言する必要性を感じたのです。

　そういう状態に陥る前に、負債を特定してすばやく対処しましょう。そうすることで、頻繁に「最低限の支払い」ができるようになり、次なる混沌を避けることができます。時間がたつにつれ、ソフトウェアがどのように手に負えなくなるのか、なぜコードをきれいにしておくことに投資すべきなのかを、ビジネス関係のステークホルダーに説明するとき、このたとえは驚くほど役に立つでしょう。

【07】スキルでなく素質のある人を加えよう

リチャード・シェリダン（Richard Sheridan）

アメリカ、ミシガン州アナーバー

　かつて私は、この業界の皆さんが雇われたのと同じような見方で人を雇っていました。それは、1 にスキル、2 にスキル、3 にスキルです。しかし、ある採用面接の候補者のひとりが、私に冷水を浴びせました。それで私は変わりました。

　私はチームに新しいヒーローを加えようとしていました。ビルはマイクロソフトで何年もの経験がある人物です。私はビルのレジュメを見て、彼こそはそのポジションにぴったりだと思いました。ビルには関連するスキルすべてに 6 年以上の経験がありました。ふさわしい給料を見い出せれば、話は簡単にまとまりそうでした。

　ビルが面接にやって来ました。私はプロジェクトについて説明し、ビルがこのポジションにぴったりだということを話しました。私はこの話はうまくまとまるものと確信していました。ところが突然、彼はうちには来てくれないように感じました。私は途中で面接をやめて、ビルに尋ねました。「あなたはこのポジションにぴったりなのに、うちには来てくれないような感じがするのだけど。」

　ビルはこう答えました。「リチャードさん、この 6 年間やってきたことと同じことをやりたいなら、私はずっと今のところに居続けます。私はクールで新しい Java プロジェクトがあると聞いてここにやって来たのです。これは私にとって学習して成長するチャンスだと思ったので、ここで働きたいと考えたのです。」

　このとき私は悟りました。「レジュメとスキル」が一致する人を雇うというのは、マネジャーがチームを作る際の最も愚かな方法なのです。

　私とパートナーがハイテク業界にかかわっているのは、常に技術の最先端にいたいためでした。私たちはみな、大学で学んだスキルを再利用するだけの仕事に自分のキャリアを費やすことを望んでいません。私たちがこの業界にかかわっているのは、常に新しい未開拓分野、新しいテクニックや技術の習得にかかわれるためです。

　しかし、どこか途中で、私たちはすっかり間違ってしまいました。従業員の成長に投資するのをやめてしまったのです。フレッシュな新しい素質を求めずに、非常に特殊な、すでに洗練されたスキルを求めていたのです。今では、みんなにこう話しています。もしスキルがぴったり一致するという理由であなたを雇おうとしているように見えたら、その雇い主は実際には「私たちはあなたに投資するつもりはありませんよ」と言っているのだと思いましょうと。

　強いチームを作ろうとしている人へ、私のアドバイスは、スキルではなく素質で雇うことです。アジャイル開発チームのための技術者を雇うとき、どんな素質が必要だと思いますか？　それは幼稚園でうまくやっていくスキルと同じです。

ほかの人とうまくやっていけるか？

みんなと仲良く遊べるか？

遊ぶのをやめるとき、きちんと後片付けできるか？

新しいことにワクワクするか？

学ぶことが好きか？

　スキルを教えることならいくらでもできます。実際のところ、アジャイルチーム環境では、すばやく簡単に技術を習得できます。ところが、仲良く遊ぶ方法を大人に教えるのはほとんど不可能です。

　スキルではなく素質で雇うということは、チーム作りを根本的に変えます。私は新しい未来技術にワクワクして取り組むことに意気揚々としている人たちと一緒に仕事がしたいのです。

【08】シンプルにいこう

クリシュナ・カダリ（Krishna Kadali）

インド、ハイデラバード県コンダプール

　ステークホルダーは必要以上に事態を複雑にするものです。これはソフトウェアプロジェクトでよく見られる失敗の原因のひとつです。チームメンバーはプロジェクトの目的と実際の作業全体を可視化する必要があります。ところがステークホルダーは自分の頭の中で、魔法のようなステップによってプロジェクトを完成させてしまいます。彼らはそれがどんなに複雑であろうとも、最終的な解決策にいとも簡単に到達できると思っているのです。

　ステークホルダーはソフトウェアプロジェクトを画一的で巨大な怪物のようにしてはいけません。そうではなく、コツを心得た多層的なチーム構成として、各層が互いに成熟度を高められるようにすべきです。本当のところ、これ以外に方法はありません。たとえ要件が完全だったとしても、必ず変更は発生します。もしソフトウェアに柔軟性がなく、要件の変更にすばやく適応できないのなら、始まる前からプロジェクトはすでに死んでいます。シンプルにしておくために、次の 2 つのことを心に留めておきましょう。

要件をシンプルにしておくこと。 ビジネスアナリストは頭に浮かんだ具体的な解決策と、ビジネス要求に基づく実際の顧客要求とを混同してしまいがちです。たとえ実際の要件が極めてシンプルなものであっても、ビジネスアナリストとプログラマ / 開発者とのあいだにはコミュニケーション・ギャップが生じます。お互いに相手が何をしているのか、本当のところ理解していないのです。

ビジネスアナリストはシンプルなツリー構造をイメージして要件を書くべきです。ルートにある要件がプロジェクト全体のシンプルな目的になります。親レベルの要件は子レベルの要件へと分岐することができます。それぞれの要件が明瞭になるまで、このプロセスを繰り返します。このアプローチを使って要件を文書化するときには、マインドマップ用のソフトウェアを使うと便利です。要件の一部が明瞭になれば、そこから開発を始めても構いません。

アジャイル開発プロセスにしたがうこと。 要件の一部が特定できれば、開発チームはすぐにプロトタイピングを開始できます。プロトタイプが動くようになると、ステークホルダーはそれをテストして、フィードバックすることができます。顧客のフィードバックは要件が正確であることを確実にしてくれます。また、実際の顧客からビジネスアナリストを経由してプロジェクトチームへと伝えられるうちに、どんなギャップが要件に生じたのかを特定するのにも役立ちます。顧客にプロトタイプを見せることで、開発者がイメージした解決策が、実際に顧客が思い描いていたものと合っているかをチェックすることもできます。

もしギャップがあれば、それを新たな要件として、開発者はプロトタイプをやり直します。このサイクルを繰り返すのです。各サイクルはできるだけ短期間にすべきです。2～3 週間を超えてはいけません。

要件の一部を定義し、記述された要件を満たすプロトタイプを作り、そのフィードバックを得るというサイクルによって、プロジェクトのステークホルダー全員が常に同じ考えを持てるようになります。このようなシンプルなテクニックにきちんとしたがうことによって、すべてのソフトウェアプロジェクトは最終的に成功するはずです。プロジェクトの成功が、顧客の幸せと有用なビジネス機能を提供する動くソフトウェアを提供することだと定義されていれば、なおさらです。

【09】あなたは特別ではない

ジャレッド・リチャードソン（Jared Richardson）

アメリカ、ノースカロライナ州モーリスビル

　母親があなたに言っていたことを覚えていますか？　「あなたは特別よ！　かけがえのない子よ！」　母親のいる子どもは、みんなそう言われていましたよね。この愛情あふれるウソを信じることは、ソフトウェアプロジェクトでよく見られる問題の原因となります。

　私はこれまでいろいろなチームをコーチしてきましたが、プロジェクトメトリクスをどれだけ満たしているかでチームを評価すると、必ず自分たちは「特別」だと信じているチームほど出来が悪いのです。どうやら自分たちは特別だと思っているため、何もかも再発明したくなるようです。「僕らほど使えるソフトウェアを開発してきたチームはないだろうね。少なくとも、僕らが作った方がいいものができるはずだ」彼らはほかの開発者の間違いから学ぶのでなく、自分自身で間違わないと気がすまないのです。何度も何度も何度も。それも会社の経費を使ってです。

　彼らはすでに業界標準になっているソフトウェアやツールがあるのに、膨大な時間を費やして、それらを書き直し、デバッグして、独自のひねりを加えます。その結果、何が起こると思いますか。彼らは決して顧客のプロジェクトを完成できないのです。お金を得るために彼らが売るべきものは何なのでしょう。チームと同じくらい特別な、伝説的で魔法のような製品を書ければよいのですが……。

　この特別な開発チームに話を聞いてみると、既存のビルドシステムでは彼らの「特別な」要件を扱えないと言います。だから、彼らは新しいプロジェクトごとに新しいビルドシステムを書かなければならないと言うのです。既存のオブジェクトデータベース・マッピングツールを再利用するのではなく、自分たちで書くのです。Web アプリケーションフレームワークだって？　僕らはそれも書けるよ。継続的インテグレーション？　調べておこう。テスティングハーネス？　書きますよ。そのなかでも最もムダでがっかりするのは、独自のプログラミング言語を書こうとすることです。

　さて、こういうチームは 1 日をどのように過ごすのでしょう？　十分機能して、しかもフリーで利用できるソフトウェアツールの代わりに、自作のテストされていないコードを使います。そして、そこで発生した問題を、自ら解決するのです。自前のデータベース層を書くときには、よくわからないパフォーマンス上のバグを数日かけて追いかけて、ようやく問題を見つけます。エッジケースまで対応しようと思うと、最終的には既存のツールを学習することはおろか、それを修正するよりもはるかに時間がかかってしまいます。

　「特別」ではない（けれども成功している）チームが既存のツールを利用しているのは、彼らが解決しようとしている問題が難問だからです。彼らには信頼できるツールが必要なのです。それがあれば、自分たちのプロジェクトの問題解決に集中できます。ツールボックスがいっぱいなのに、さらにツールを補充しようとしてはいけません。

　この話は効果的なプロジェクトマネジメントにどんな関係があるのでしょうか？

　プログラマに車輪の再発明をさせてはいけない、ということです。開発者が自分たちのプログラムがどれくらい特別であるか説明しにきたときには、母親が「あなたは特別よ」と言ったのは過大評価だったのかもしれないよ、と指摘してあげましょう。あなたは何が使えるのか熟知しておき、高品質のオープンソースもしくは商用ツールを使うようチームを導きましょう。

　NIH（Not Invented Here、ここで発明したものではない）症候群は、これまで数多くの優秀なチームを狂わせてきました。あなたのチームをそうさせてはいけません。

【10】スクロールから学んだこと

キム・マッコーマック（Kim MacCormack）

アメリカ、バージニア州リーズバーグ

　12 年前のことですが、私のチームはグラフィックデザイン会社の下請けとして、Web アプリケーションを開発するために雇われました。私たちは顧客と直接コンタクトすることを許されていませんでした。要件はすべて顧客から元請けに伝えられ、私たちはそれを時々送られてくるメールで知らされました。

　そうしたメールのなかに、デザイナーが使うべき画面解像度に関するものがありました。以前の標準は 640 × 480 でしたが、新しい調査によると、Web サイトは最大 800 × 600 までの解像度をサポートすべきだと推奨されていました。（現在では、最もよくある画面解像度は 1,024 × 768 です。）元請けは経験豊富なデザイン会社でしたが、顧客向けの公式な要件（私たちは見たことはないですが）には次のように記載されていました。

各ページのレイアウトは横 800 ピクセル、縦 600 ピクセル固定という標準にしたがうこと。

　もし私たちがこの要件を見ていれば、即座にこう訂正したでしょう。「各ページのレイアウトは横 800 ピクセル固定という標準にしたがうこと（800 × 600 までのモニタ解像度をサポートするため）。」　私たちはこれまで Web サイトの仕事を数多くやってきており、一番重要なのは横幅であることを知っていました。ユーザーはブラウザを使うとき、横方向にスクロールすることを嫌います。そこで横幅にあわせて折り返すと、表示は縦長になります。よいかどうかはともかく、私たちは縦方向にスクロールすることは現実的で当然だと思っていました。そのため、私たちはこのことを顧客に伝えませんでした。それほど重要なことだとは思えなかったからです。

　この Web サイトに不慣れな顧客が各ページに用意した内容は、あまりに巨大なものでした。結局、800 × 600 の解像度に設定された 15 インチモニタでは、ほとんどのページが横幅におさまらず折り返され（縦方向に長くなり）、一画面では表示できませんでした。縦方向にスクロールせざるを得なかったのです。

　この巨大なコンテンツを一画面で表示するためには、奇跡を起こす必要がありました。そのことを知って、エンドユーザーでもある顧客は激怒しました。顧客は私たちの元請けであるデザイン会社を非難しました。すると、そのデザイン会社は、私たちへの支払いを拒否したのです。彼らに言わせると、私たちは「要件を記載された通りに満たさなかった」のだそうです。

　この経験から、私はずさんで出来の悪い要件の危険性と、それがどのように使われるのかを学びました。あなたの前提を必ず明記して、仲介役とではなくエンドユーザーとともに要件をレビューし、承認を求めることが重要です。

　幸運なことに、アジャイル開発のプラクティスにしたがうと、こうした問題の一部は軽減されます。開発者と真の顧客のあいだの対面コミュニケーションの重要性を認識することによって、要件リストではなくユーザーストーリーの作成と、顧客に提供するビジネス価値に基づくフィーチャーの優先順位付けとがまとめてできるようになります。そして 1～2 週間のイテレーションプロセスによって、早期の頻繁なフィードバックと顧客の期待を明確にする機会が得られます。

　あれから 12 年、私はこの時とまったく同じような状況に出くわしました。その顧客は 1 ページに大量のコンテンツを表示したいのに、縦方向にスクロールすることを非常に心配していました。幸いなことに、現在のプロジェクトの進め方と過去の経験から学んだ教訓のおかげで、以前のような混乱を引き起こすことはありませんでした。私たちは問題をすばやく解決して、現実的な顧客の期待を設定することができました。

【11】問題にかかるコストを削減する

ランディ・ルーミス（Randy Loomis）PMP

アメリカ、コネチカット州アンドーバー

　私たちの会社では、あるトレーニングソフトウェアを使っていたのですが、すでに 5 回もアップグレードに遅れていました。ソフトウェアはかなり古くなり、ベンダーのサポートも切れた状態になっていました。私たちのプロジェクトの目的は、ベンダーとともにそのトレーニングソフトウェアを最新版にアップグレードし、それが使えるようユーザーを教育することでした。

　私たちは 2 つの SOW（Statement of Work、作業範囲記述書）を定めました。ひとつはユーザートレーニングに関する合意について説明したもので、もうひとつは古いトレーニングソフトウェアをアップグレードするための「上限」コストを記述したものです。データをコピーしたあと、ベンダーは別のところで、データ変換と最初のアップグレードを始めるのに必要なスクリプトの開発およびテストを実施するプロセスを開始しました。

　スクリプトがベンダーのテストをパスすると、ベンダーは私たちの開発環境を移行し、ユーザーテストを実施しました。こうして 5 回のアップグレードそれぞれについて、このプロセスを繰り返しました。テストをしているあいだ、私たちは遭遇した問題を記録しておき、ベンダーがスクリプトを書き直してテストするたびに、それらについて再テストをしました。

　ひとつずつアップグレード作業を進めながらも、私たちはベンダーの作業時間に SOW で定められた請求料率をかけたものが「上限」予算を超えていないか記録しました。アップグレードを進めているうちに、私たちはアプリケーションのアップグレード自体にバグがあることを発見しました。このバグは、アップグレードをインストールするために書いたカスタムスクリプトとは無関係なものでした。私たちはこうした問題も詳細に記録しておきました。画面をプリントして、どこでどのように問題に遭遇したのか、順を追って詳しく説明しておいたのです。

　それから、私たちは本来そのソフトウェアがやるべきことを約束したベンダー保証書を彼らに見せました。ところがベンダーは、ソフトウェアは「仕様通り」に機能していると言い張ったのです。後になって、私たちが遭遇した小さなバグは氷山の一角にすぎず、もっと影響が大きいことがわかりました。アップグレードをしても、ソフトウェアの基本機能に重大な欠陥があることが明らかになったのです。

　ようやくベンダーは、私たちが見つけた問題のいくつかは確かに「仕様通り」ではなく、実際にはバグであったことを認めました。ベンダーは自らの製品を修正するのに要した作業について、「上限」契約にある通り、「上限」を超えた分の費用請求をしませんでした。

　この段階で、私たちは大事な締め切りに間に合わせるため、ソフトウェアをインストールすることだけに注力しました。このときには、もはや見つかった問題が「仕様通り」なのかバグなのかというのは、私たちにとってはどうでもよくなっていました。しかし、後になってわかったことですが、もしここで見つかったバグや問題に対してベンダーの作業時間を具体的に記録していれば、私たちは「上限」契約の総額すらを支払わずに済んだのです。

　ベンダーと契約交渉をするときには、遭遇した個々の問題について、ベンダーの作業時間とプロジェクトチームの作業時間の両方を記録するよう明記しましょう。こうすることにより、問題がプロジェクト作業にまつわるものではなく、ベンダーの製品自体にもともとあったものの場合には、その解決に要した分の費用を抑えることができるでしょう。

【12】すぐれた開発者を見つけるには

ジェームス・グラハム（James Graham）PMP

マルタ、タル-イブラグ

　プロジェクト・マネジャーは、プロジェクトの成功は優秀な開発者がいるかどうかにかかっていることを知っています。どうすれば候補者のなかから、非常にすばらしい成果を上げる人材を見つけられるのでしょうか？

　新しい候補者を面接する前に、あなたのところにいる一番優秀な開発者と相談しましょう。プロジェクトに必要とされる具体的な知識について、再確認しておくのです。どんな開発ライフサイクル、方法論、ツール、専門分野（例えば、防衛産業や医薬品部門）の知識があればよいのでしょうか？　それは「あれば望ましい」のでしょうか、それとも「必須」なのでしょうか？

　候補者の知識を評価しましょう。開発チームの信頼できる代表者を交えた面接と、理論的なテストとを組み合わせるのです。すぐれたソフトウェアエンジニアであれば、「演習問題」にあるシンタックスエラーを即座に苦もなく修正できます。詳細なドキュメントがなくても、一字一句説明しなくても、他人が書いたコードを読んで、そこにある意図をきちんと理解できます。問題のあるプログラムを見せれば、その問題を見つけて、「専門家」向けの言葉と非 IT 分野のステークホルダー向けの言葉の両方を使い分けて、うまく説明できるはずです。

　私たちはみな、開発者を雇うときにはプログラミングスキルが「あればあるほどよい」と思っています。しかし「あればあるほど」というのはどのように定義されるのでしょうか？　たとえ候補者にすばらしい知識があっても、まだそれを効果的に使ったプログラムを書いたことがないかもしれません。最近大学を卒業した人や新たにトレーニングを受けた開発者の場合、きつい現場のプロジェクトに直面すると、授業で習った理論的知識を応用するのに四苦八苦するかもしれません。厳しい締め切りのために解決策を見つけ出す時間が圧迫され、クライアントやほかのステークホルダーから激しいプレッシャーを受けたときには、単なる知識だけでなく経験が必要になります。

　候補者にコードを書くよう頼んで、あなたのチームでレビューしましょう。そのコードを分析して、信頼できる開発者とよく相談しましょう。そうすれば、その人のアプローチやスタイルがあなたのチームに合うかどうかわかるはずです。

　候補者の仕事、同僚、クライアント、ステークホルダーに対する態度をよく観察しましょう。私はかつて「ヘアドライヤー」というあだ名の開発者と仕事をしたことがあります。彼が怒ると、その怒鳴り声でみんなの髪が乾いたという伝説が残っていました。彼はすぐれた開発者でしたが、プロジェクトチームにとっては有害でした。

　世の中がアジャイル開発へと向かうにつれて、部門を超えたコミュニケーションも増え、コミュニケーションスキルや交渉力といった、いわゆるソフトスキルの重要性が増しています。どんな開発者もいつか、別のところから来た人たちと小さなチームで仕事をすることになります。こうして野に放たれたとき、新たにチームの仲間になった人は、あなたのことをどう表現するでしょうか？

　ソフトウェア開発者を雇うときには、以下の単純なガイドラインにしたがいましょう。

開発ライフサイクル、方法論、ツール、業界や分野に関する正しい知識があるかをチェックして選抜する。

現場でその知識を応用できることを実証するためのテストを実施する。

コミュニケーションスキル、ソーシャルスキルについて調査する。

仕事に対してふさわしい態度をとるか調べる。プロジェクト制約を受け入れながらも、すぐれた製品を作ろうと、うまくバランスをとれるかどうか？　時間通りに予算内で「目的にかなう」製品を作り出せるという実績が文書としてあるか？

　どんなに魅力的でスキルのある候補者であっても、必ず発行者のサインの入った信任状があるか確認し、履歴書にある以前の雇い主の項目を調べましょう。いつも注意深く人を雇うよう心掛けることで、将来起こるであろう数々の問題を避けられます。

【13】熟練と並の開発者の生産性

ニール・フォード（Neal Ford）

アメリカ、ジョージア州アトランタ

　さて、初めてソフトウェアプロジェクトにアサインされたプロジェクト・マネジャーのために、開発者のスキルに関する神話のウソを暴いていきましょう。本当にすぐれたソフトウェア開発者は、並の開発者よりもはるかに生産性が高いことを理解しましょう。実際のところ、本当にすぐれた開発者はそうでない開発者よりも、何桁もすぐれているという統計すらあります。1 桁というのは 10 倍ということです。要するに言いたいことは、熟練したプログラマというのは並のプログラマよりも少々すぐれているどころではない、ということです。その違いはとてつもなく大きいのです。

　新たにトレーニングを受けたソフトウェアプロジェクト・マネジャーにとって、このことは製品開発を計画するときにどんな意味があるのでしょう？　マネジャーは、たとえ優秀で才能ある開発者が手に入らなくても、二流の開発者からも何かしら有用なものが得られるものと考えています。これは間違いです。下手な溝掘りでもいつかは溝を掘れるでしょうが、ソフトウェアの開発は溝掘りとは違うのです。

　ソフトウェア開発では、今日プログラムされたものが明日の基盤となります。二流の開発者に基盤を作らせてしまうと、本当にすぐれた開発者は前へ進む前に、後ろへ戻って欠陥を修正しなくてはなりません。二流もしくは並の開発者を雇うと、プロジェクトのベロシティは低下します。実際のところ、すぐれた人を加えるよりもダメな人をチームから外した方が有益なのです。

　このことと、遅延したプロジェクトに人員を追加するとプロジェクトはさらに遅延する、という事実とを合わせて考えてみましょう。そうすれば、ほとんどの企業において、開発がゆっくりとしたペースでしか進まないのはなぜなのか、理解できるはずです。経験の浅いソフトウェアプロジェクト・マネジャーは、たとえば、倉庫係を増員すればするほど、すばやくトラックに荷積みできるのだから、プログラマも追加で雇えば雇うほど、プロジェクトを完了させるのに必要な時間も短縮できるはずだと思うのです。

　しかし、これはうまくいきません。新しい人員をプロジェクトにキャッチアップさせるのには時間がかかりますし、ほかのプログラマの手をわずらわせることにもなります。さらに、チームに人員を追加するたびに、コミュニケーションチャンネルは増えていきます。ベッツィー・スーとビルの 2 名からなるチームでは、チャンネルはひとつです。そこにマイクが加わると、チャンネルは 3 つに増えます。こうしてチャンネル数は指数的に増大し続けるのです。

　チャンネル数の算出式は、 n(n-1)/2 になります。12 名からなるチームには、 12(12-1)/2 のチャンネルがあります。言い換えると、プロジェクト・マネジャーとして管理しなければならない関係が 66 もあるということです。さらにもう 1 名増えると、管理すべきコミュニケーションチャンネルは 78 になります。

　並の開発者とともにソフトウェアを作ることで、プロジェクトの神話のウソが 2 つ暴かれます。ひとつは人員を追加することでプロジェクトを短縮できるという神話、もうひとつは並の開発者に並のペースで並の（バグのある / 仕事以前の）コードを作らせても問題ないという神話です。実際には、並の開発者は全体の生産性の足を引っ張り、プロジェクトを完了させるのに必要以上の時間がかかってしまうのです。

　解決策はあるのでしょうか？　はい、すぐれた開発者に強力なツールを与えましょう。そうすれば、もっと高品質なソフトウェアを、もっとすばやく手に入れることができます。それからもうひとつ、無能な人がいてもプロジェクトには役に立ちません。それどころか、ダメな開発者の面倒まで見なければいけないとなると、職人気質のすぐれた開発者の生産性は低下してしまいます。ソフトウェアは非常に複雑なので、工場の組み立てライン作業のようにはいかないのです。

　もっとすばやいソフトウェア開発があなたの望みですか？　それなら、すばらしいソフトウェア開発者を雇うこと、そして育てることにもっとお金をかけましょう。短期的にも長期的にも、元が取れるはずです。

【14】大きさが重要

アヌパム・クンドゥ（Anupam Kundu）

アメリカ、ニューヨーク州ニューヨーク

　プロジェクトの大きさ、チームの大きさ、成果物の大きさ、チェックリストの大きさ。プロジェクトのあらゆるものが、その大きさに依存しています。大きさによって、ゲームをどうプレイするかのルールが変わってきます。

　プロジェクトが（その大きさや複雑さにおいて）大きくなればなるほど、プロジェクト・マネジャーがプロジェクトを管理可能なモジュールに分割し、これらモジュールの納品責任を有能なメンバーと共有することが重要になってきます。これによって、プロジェクト・マネジャーを含むプロジェクトのキーメンバーは、些細なことにとらわれることなく、プロジェクトの健康状態を調べて、その「全体像」を把握できるようになります。

　分散したプロジェクトは通常のプロジェクトと比べても大きくなりがちです。プロジェクト・マネジャーがその大きさを管理するためにどんな方針をとるかが、実際にプロジェクトの最終結果に大きな影響を及ぼします。「大きい」という言葉からは、さまざまなイメージが頭に浮かびます。8 人で 12 か月かけてやる仕事（小さなベンダー）から、何百人もかけて年間メンテナンス契約を締結してやる仕事（クライアント向けの巨大な IT パートナー）まで、あらゆるものを意味します。

　プロジェクトを適切な大きさに分割した小さなパーツが、どのようにプロジェクト全体の成功を左右するのか、全員が確実に理解するための方法を以下に提案します。

プロジェクトを、独立しながらも管理可能なワークストリームにできるだけたくさん分割すること。

各ワークストリームに納品責任を持つ重要な窓口を少なくとも一名配置すること。

できれば、複数のワークストリームに役割を持つキーメンバーを配置すること。こうすることで「全体像」をチーム間でシェアすることができます。

各ワークストリームの進捗を（何らかのツールを使って）個別に追跡すること。そして、プロジェクト全体の鼓動が感じられるよう、定期的に評価指標と関連付けること。

リスク、課題、前提、各ワークストリームの依存関係をそれぞれ文書化して共有すること。

チームの定例ミーティングを開催して、すべてのワークストリームの状況を共有すること。

プロジェクト全体のロードマップを公表すること。これには個々のワークストリームのリリース計画も含まれます。

オンラインツールを積極的に利用して、ユーザー要求、マイルストーンの更新、バグレポート、レポートスケジュール、リスクを共有すること。

　例えば、バージョンが 3 つ（北米、アジア太平洋、中東）ある Web サイトの構築を任されたとしましょう。あなたは 3 つの異なるワークストリームを作って、それぞれ独立した納品窓口を置くのがよいと判断できます。これら 3 つのサイトはみな、基本的には同じサイトの別バージョンなので（中程度のカスタマイズ）、何名かのキーメンバーを 3 つのワークストリームにまたがるよう配置しましょう。そうしておけば、彼らはサイト全体の整合性を確保しつつ、どのように実装詳細を再利用すればよいか提案できます。

　また、ひとつのプロジェクトに複数のシステムインテグレータがかかわる場合もあるでしょう。各インテグレーションポイント（あるいは関連するものをいくつかまとめたもの）を個別のワークストリームに分割するのが理想的でしょう。こうしておけば、複数の作業を同時に進めることができ、納品期間を短縮できるかもしれません。全体の品質を調整するために、さまざまなチームを毎日のミーティングに参加させましょう。

【15】手順を文書化して、守られているか確かめよう

モンテ・デイビス（Monte Davis）MCSE

アメリカ、ネブラスカ州オマハ

　あるプラットフォームから別のプラットフォームヘメールシステムを移行している最中のことでした。ひとりの女性が結婚した結果、メールシステムがダウンしたのです。

　メールの流れは次のようになっていました。

新しくやって来たメールは新しいメールシステム経由で配送される。

新しいメールシステムで配送可能であれば、新しいシステムにいるユーザーにメールを配送する。配送不能であれば、メールは古いメールシステムへと送られる。

古いシステムにいるユーザーから古いシステムにいるユーザー宛てに送られたメールは、適切なメールボックスへと配送される。しかし、受信者がすでに新しいシステムに移行済みであれば、メールは各ユーザーのために作られた「移行（migrate）」転送アドレスを使って新しいメールシステムに自動転送される。

　ここで、おかしなことが起こりました。「サリー・シングル（single、未婚）」は新しいメールシステムに移行していたため、2 つのメールアドレスを持つことになりました。 sally.single@mycompany.com とその転送アドレス sally.single@migrate.mycompany.com です。古いシステムにいるユーザーから彼女宛てに送られたメールはすべて、「移行」転送アドレスを使って新しいメールシステムに自動転送されます。

　サリーが結婚して、名前を「サリー・シングル」から「サリー・マリッド（married、既婚）」に変えると、メールアドレスも同じように変更されました。しかし、新しいシステムにあるサリーのメールアドレスは変更されたのですが、古いシステムの「移行」転送アドレスを変更するのを忘れてしまいました。その結果、サリーにはその転送アドレスが残ってしまいました。

新しいシステム | 古いシステム
sally.married@mycompany.com | sally.married@mycompany.com
sally.single@mycompany.com | sally.single@mycompany.com
sally.married@migrate.mycompany.com | sally.single@migrate.mycompany.com （変更されていない移行アドレス、結婚後も残ったままになっていた）

　この結果、古いメールシステムにいるユーザーからサリー宛てにメールが送られると、ループが発生してしまいました。1）メールが古いメールシステムで作られ、 sally.single@mycompany.com 宛てに送られます。2）古いメールシステムはサリーのアカウントをチェックして、転送先が sally.single@migrate.mycompany.com に設定されていることを確認して、メールを転送します。3）新しいメールシステムは sally.single@migrate.mycompany.com というメールアドレスを持つ人を探しますが、見つかりません。このアドレスはサリーが結婚したときに変更されたためです。4）そこで新しいメールシステムは、不明な受信者宛てのメールを古いメールシステムへ転送します。5）古いメールシステムは @migrate.mycompany.com の付いたメールをすべて転送することを知っているので、そのメールを新しいメールサーバに転送します。6）これが無限に繰り返されます。

　メールがループするたびに、メールの末尾に会社の法的放棄声明が追加されていきます。法的放棄声明は 100 単語程度にすぎませんが、メッセージが 1 分間に何度もシステム間をループすると、それはどんどん大きくなっていきます。どうやら、サリーは非常に人気者だったようです。あまりに多くのメールがサリー宛てに送られたため、メールの大きさと量のせいで、とうとうメールシステムはダウンしてしまいました。

　教訓：手順を文書化して、それが守られているか確かめましょう。名前変更の手順は文書化されていたのですが、実際には守られていませんでした。もしそれが守られていれば、古いメールサーバにあるサリーのユーザーアカウントは、新しい結婚後の名前を持つ移行メールアドレスに更新されていたはずです。そうすれば、この問題は避けられたでしょう。

【16】さあ、プラクティスを投げ捨てよう

ナレシュ・ジャイン（Naresh Jain）

インド、ムンバイ市マラド

　うまくいっているチームがやっていて、ほかのチームがやっていないことは何でしょう？　うまくいっているチームは定期的に自分たちのプラクティスに疑問を持ち、ムダなものを排除しようとします。ソフトウェアだけでなくプロセスも容赦なくリファクタリングするのです。

　“Il semble que la perfection soit atteinte non quand il n’y a plus rien ? ajouter, mais quand il n’y a plus rien ? retrancher.”　このフランス語の文章はアントワーヌ・ド・サン=テグジュペリから引用したもので「完璧であるということは、付け加えるべきものがなくなったときではなく、取り去るべきものがなくなったときである」という意味です。

　どうしてチームはこの原則を適用しないのでしょう？　どうしてしばらくすると、最終製品の価値がどんどんやせ細っていき、プロセスや副産物がどんどんふくれ上がっていくのでしょう？　どうしてコードの行数が増えているのに、ソフトウェアの有用な機能はどんどん失われていくのでしょう？

　以下に、ソフトウェア開発プロセスにおける「亀裂」を示す指標を挙げます。

コードの行数やムダな機能という観点から、ソフトウェアが膨張する。

ソフトウェアを開発するチームがどんどん大きくなる。

プロセスがどんどん杓子定規で独断的で、融通の利かないものになる。

チームが「計画倒れ（death by planning）」のミーティングを体験する。

ドキュメントやサポートすべき生成物の量が指数的に増える。

顧客テストグループから、新たなバグが絶えず殺到する。

　チームリーダーはプロセスやチェック、監査を増やしてしまいがちです。プロセスをもっと厳格にすることで、問題が解決すると思い込んでいるのです。私の経験から言って、これはプロセスの問題ではありません。プロセスをさらに増やすことは、チームが問題の根本原因を認識することを、さらに難しくしているだけなのです。

　どうしてほとんどのチームは、チームにとって役に立たないプロセスを投げ捨てることを怖がっているのでしょう？　どうしてチームは、使い捨てのプラクティスを追加していくのではなく、思いつく限りの多数のプラクティスから始めようとするのでしょう？

　そもそもこれは、そのプロセスを使っている理由をチームが本当は理解していない印なのかもしれません。あるいは、ソフトウェア開発プロセスを十分理解していない人が、高圧的にチームに方法論を強いているのかもしれません。いずれにせよ、プロジェクトは「砂上の楼閣」になって、今にもくずれて無用なコードの山になるおそれがあります。真の理由を理解せずに何かを変更しようとすると、プロジェクトは価値を高めることなく膨張していき、結局使えないものになるのです。

　私が思うに、すぐれたプロジェクト・マネジャーはチームがうまく機能しているか、健康状態を把握すべきです。プロジェクト・マネジャーは一歩後ろに下がって、チームに課せられたプロセスが、動作するソフトウェアのスループットにどんな影響を及ぼしているのか、評価するべきです。

　聡明なプロジェクト・マネジャーであれば、チームに依頼される可能性のあるアクティビティから取捨選択して、プロジェクトの成功に不可欠なものだけを維持すべきです。過去のプロジェクトから受け継がれたプラクティスを一掃することで、チームの生産性とスループットは短期間で大きく改善するはずです。

　「過ぎたるは及ばざるがごとし」というのは、プロセスに関する非常に重要な哲学なのです。

【17】要求と仕様

アラン・グリーンブラット（Alan Greenblatt）

アメリカ、マサチューセッツ州サドベリー

　すぐれた要求とは、製品のフィーチャーがある既存の問題あるいは潜在的な問題をどのように解決するかを記述したものです。すぐれたフィーチャー（機能と呼ばれることもある）とは、そうした重要な問題を解決するために製品に追加されるものです。要求はセールスによって獲得されたり、ソフトウェアプロジェクト・マネジャーによって作り出されます。

米国外でその製品を売ることはできない（要求）。私たちは国際化と地域サポートを提供する必要がある（フィーチャー）。

ユーザーはごく単純なタスクを完了するのに 5 つのボタンをクリックする必要がある。これだとユーザーはイライラしてタスクを完了できない。私たちはユーザーインターフェイスを単純化して（要求）、同じタスクを完了するのにボタンのクリック数を 2 回以下に減らす必要がある（フィーチャー）。

　これに対して仕様とは、問題がどのように解決されるか、要求がどのように満たされるかを正確に記述したものです。先ほどの例を使うと、次のような仕様がシステムアーキテクトによって書かれることになります。

ポップアップメッセージを含むすべてのテキスト文字列を抽出して、外部リソースバンドルに置く（仕様）

アプリケーションを改良して、画面上に表示されるテキストをすべて、外部リソースバンドルから取得する（仕様）

必要とされるロケール用のリソースバンドルを作ることによって、ローカライゼーションを実現する（仕様）

ボタン 1、2、3 をクリックすることで実現していた機能は、ボタン A の 1 回クリックにまとめる（仕様）

既存のボタン 4、5 の機能は、ボタン B にまとめる（仕様）

　要求と仕様の区別をあいまいにすると、間違った人に判断させることになります。どの機能がユーザーにとって重要なのか、ユーザーに代わってソフトウェア開発者が「判断」してしまったり、コードをどう組み立てるかをプロジェクト・マネジャーが「開発者に教える」ことになります。いずれにせよ、最終的に作られるソフトウェア製品はひどいものになるでしょう。

　開発者は通常、顧客、ユーザー、マーケティング、セールス、パートナーになる可能性のある人たちと会話をしません。彼らはどの新規フィーチャーが一番重要なのか理解しようとしていないのです。それに対して、プロジェクト・マネジャーは通常、熟練した開発者ではありません。彼らはフィーチャーをどう実装するのが一番よいか理解していませんし、未熟な仕様提案がその製品の別のところにどんな影響を及ぼすのかも理解していません。開発者とプロジェクト・マネジャーには、それぞれ特有のスキルセットがあるのです。

　すぐれた要求は、解決しようとしている問題について、また、その問題を解くことが重要である理由について記述したものです。開発プロセスにおいて、プログラマにはもっと柔軟に、もっと効率よく、もっとモチベーションを高くもってもらいましょう。プログラマが問題に集中して徹底的に理解すると、独立した設計判断が下せるようになります。プログラマは自分たちが選び抜いてきた技術によってのみ縛られるべきです。プログラマでない人によって作られた、厳格だけれども脆弱な仕様によって縛られるべきではありません。

　とはいえ、仕様は文書化しておく必要があります。ところが、仕様は変化するものです。あなたは製品開発ライフサイクルの最後になってようやく、この製品がそもそもどう作られるべきだったか理解できるようになったという経験はありませんか？

　あなたが作ろうとしているもの（what）とその作り方（how）を分けておきましょう。そして、それぞれの役割に基づき、きちんとトレーニングを受けたチームメンバーに判断させましょう。

【18】成功はビジネス価値で評価される

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　プロジェクト・マネジャーは、時間、コスト、スコープ、品質基準などの評価基準を満たすことに忙殺されるものです。そのうちプロジェクトは、それ自体が目的となります。そして、こうした評価項目を期待される値で実現できるかによって、私たちは評価されます。

　私たちは、「プロジェクトの成功は組織にもたらすビジネス価値で評価される」という事実に注目する必要があります。もし市販のソフトウェア製品を作っているなら、「成功」の評価要因は明確でしょう。私たちはプロジェクトマネジメントスキルを活用して、製品を市場にすばやく届ける必要があります。競合が同等もしくは優秀な製品を作る前に、顧客ベースの大部分を確保するためです。

　私たちは商品の需要が尽きる前に、市場の過半数を獲得しなくてはなりません。そのためには顧客がインストールしやすく、使い方を学びやすいようなソフトウェアを設計する必要があります。ソフトウェアのメンテナンスやアップデートも容易にできなくてはなりません。

　多くのプロジェクト・マネジャーは、自分の仕事は単にソフトウェアを完成させることだと思っています。しかし、プロジェクトをビジネスニーズに結びつけておかないと、いくらすばらしいソフトウェアを作っても組織の ROI（投資収益率）から見れば失敗に終わるでしょう。

　もしプロジェクトが社内向けであれば、どうやってお金を節約したり稼いだりするのでしょうか？　開発しているソフトウェアをもっと高速にしたり、もっとシンプルにしたり、もっとすぐれたアーキテクチャにすることで、ハードウェアリソースを削減すればよいのでしょうか？　もっとすばやく注文を受け付けて、それを処理し、すぐに納品できるようになれば、もっとお金を稼げるのでしょうか？　メンテナンス要員をほとんど必要としないソフトウェアを作ったり、ヘルプデスクへのコール数を減らすようインフラを変更することで、お金を節約すればよいのでしょうか？

　もしプロジェクトがシステムインテグレータ向けであれば、うまくタスクを並列化したりリソースを平準化することによって、会社にとっての利ざやを増やしたり、顧客から信頼性が高いという信用を得られるのでしょうか？　すぐれた手腕によって多数のプロジェクトをすばやく完成させることで、サプライヤーと同格に認められ、大きなハードウェアディスカウントが得られるのでしょうか？

　プロジェクトを完了させることが会社の利益にどう結びつくのかを明確に理解すれば、チームのモチベーションは高まり、現場で難しい判断をしやすくなります。競合するプロジェクトの中から特定のプロジェクトに投資するという判断が下されたとき、そのプロジェクトはほかの後回しにされたプロジェクトと比べて、どうして重要だと見なされたのでしょうか？

　プロジェクト・マネジャーは通常、こうした重要な質問に対する回答を与えられていません。ですから、プロジェクト・マネジャーであるあなたは、質問の仕方を学ばなければなりません。その回答によっては、時間、お金、品質以外にも、そのプロジェクトに重要な要素があることがわかるかもしれません。その回答がわかれば、それに応じて回避策や代替案を準備できます。また、そのプロジェクトが生まれたビジネス理由に合わせて、どこにコンティンジェンシー（予備積立金）を費やすべきかもわかるでしょう。プロジェクトを成功させるには、プロジェクトのビジネス価値を理解することが重要なのです。

【19】休暇をキャンセルしない

ジョー・ゼネビッチ（Joe Zenevitch）

アメリカ、ニューヨーク州ニューヨーク

　ソフトウェアプロジェクト・マネジャーというのは、きつい職業です。チームで一番目立つポジションであるだけでなく、通常はその役割にある唯一の人物であり、バックアップがいません。そのなかで休暇を計画するのは、なかなか難しいことです。外部コンサルタントであればなおさらです。自分の不在がプロジェクトに悪影響を及ぼすような気がしてしまうのです。

　このリスクを最小限にしようと、新米プロジェクト・マネジャーは休暇をキャンセルします。最悪の場合、最初から休暇をまったく計画しないのです。しかし、私が時間をかけて学んだことは、プロジェクトにつきもののストレスの多い状況から解放されるためには、定期的に休暇を取る必要があるということです。これまでのキャリアで取り損ねた休暇について思い出してみましょう。ひどく不快に思いはしませんでしたか？　あなたが仕事に残ることで、具体的にどんな問題を回避できたのか覚えていますか？

　プロジェクトやそのスケジュールをまったく顧みずに、次回の休暇を計画すべきだと提案しているわけではありません。3 週間ほどのプロジェクトであれば、あなたも待てるでしょう。メジャーリリースの前の週に休暇を取るのは、間違いなく無責任なことです。しかし、あなたが途中で 1～2 週間の休暇を取ったせいで、9 ～12 か月のプロジェクトが大失敗するのであれば、そもそもプロジェクトをうまく管理できていなかったのだと思います。

　もちろん、あなたの不在中を埋めてくれる人を見つけて、訓練しておくことは重要です。あなたの代理は、あなたがやっていた通りにはやれないかもしれませんが、プロジェクトが沈まないよう、正しい方向に進み続けることならできるでしょう。何か大きな問題があれば、あなたが戻るまで保留しておくよう伝えておいても構いません。

　あなたの代理は別のチームのプロジェクト・マネジャーでも構いませんが、自分のチームから選んだ方がよいでしょう。チームメンバーの方がそのプロジェクトのことをよく知っていますし、そのメンバーが指導的役割につくときの試運転にもなります。ビジネスアナリストが一時的に「あなた」の代わりを務めるのがぴったりな組織もあります。ビジネスアナリストは要件についてよく知っています。そして、最初からステークホルダー全員をプロジェクトに参加させていれば（そうすべきですが）、ビジネスアナリストは開発イテレーションの基本的な運用についても知っているはずです。

　アジャイル開発における「自律したチーム」というコンセプトは、重要かつ強力です。このコンセプトでは、プロジェクト・マネジャーはチーム全員がしたがうべき、理解しやすく可視化されたプロセスを整えます。チームがプロセスを取り入れるにつれ、プロジェクト・マネジャーは管理することが減っていき、手助けすることが増えてきます。基本的に、毎日細かいところまで管理するのではなく、障害を取り除いて問題を解決することがあなたの仕事になっていきます。

　順調にいっている自律したチームには、うれしい副産物があります。そのひとつが、プロジェクト・マネジャーが適時休暇を取っても、ほとんど問題がないということです。たとえあなたが数日間不在になっても、プロジェクトは自力で動き続けるのです。

　休暇を予定するときには、リリースのタイミングに当たらないよう必ず確認しましょう。しかし、休暇はきちんと取りましょう。自分がいないとプロジェクトが止まってしまうのではと気にして、休暇をキャンセルしてはいけません。

【20】集中する時間を取る

ジェームス・リー（James Leigh）

カナダ、オンタリオ州トロント

　ソフトウェア開発者は決まって、「ミーティング、デモ、緊急のバグ修正といった割り込みがあったせいで、仕事が終わりませんでした」と報告します。割り込み後に思考の流れを取り戻すのには、20 分程度かかると言われています。つまり、5 分の質問も実際には 25 分のコストになり、10 分の簡単なミーティングも実際には 30 分の潜在的な作業コストになるのです。典型的な知識労働者は 1 日の 28% を割り込みとその復帰に費やしています。このことは過度のフラストレーションとストレスの原因になるおそれがあります。

　この問題を解決するために、割り込みが発生しない時間を 1 日に 2 時間取りましょう（例えば、朝 10 時から昼 12 時まで）。ミーティング、質問、メール、電話などの割り込みを許さない日を用意することで、開発者が 1 日中、全力で仕事に集中できるようにしても構いません。インテルや IBM は金曜日をその日に設定して、それぞれ “zero-email Fridays” や “Think Fridays” と呼んでいます。

　その期間に効率よく仕事をするためには、開発者がプロジェクトにおける上位 2 つの優先事項が何なのか知っておくことも重要です。いくらすぐれた開発者でも、何がプロジェクトに真のビジネス価値をもたらすのかを明確に伝えられなければ、やみくもに推測するしかありません。

　インフォマニア（Infomania、情報過剰で衰弱した状態）は、開発者の生産性にとって大敵であると知られています。開発者がプログラミングをするときには、同時に多くのことを記憶しておく必要があります。変数、クラス構造、API、ユーティリティメソッドといったものからディレクトリ階層まで、覚えておくべきことはさまざまです。割り込みがあると、こうした情報の多くが「スワップアウト」してしまい、それを取り戻すにはかなりの精神エネルギーが必要になります。これは生産性に多大な影響を及ぼします。研究によると、インフォマニアのために、従業員は自分の能力を最大限発揮できず、新しいアイデアを生み出すことに集中できないことがわかっています。

　また、割り込みの種類によって、開発者の思考の流れに及ぼす影響は違ってきます。頭の中でプログラムやデータを活発に循環させたまま、立ち上がったり、トイレに行ったり、コーヒーやサンドイッチをとったり、ホワイトボードに向かう人もいます。実際に体を動かすことは、問題を解決するための新しい手段だと見なせるかもしれません。

　事前に計画されたミーティングは、プログラマにとっては特に問題です。スケジュール通りにやってくるイベントがあることがわかっていると、時間をムダにしてしまうおそれがあるためです。彼らはこう考えます。「30 分もしないうちに割り込まれるのがわかっているのだから、いま仕事を始めても仕方ない」　そして、ミーティング中にすばらしいアイデアが浮かんでも、コンピュータの前に戻るころにはすっかり忘れていたり、陳腐化してしまうかもしれません。

　開発者の生産性は、同時にやるプロジェクトが増えるたびに 50% 以上低下すると言われています。3 つ以上のプロジェクトに取り組んでいる開発者は、ほとんどの場合、ミーティングに出席する時間が飛躍的に増えてしまいます。なぜなら、どうして仕事があまり進展していないのか説明しなくてはならなくなるためです。開発者が複数のプロジェクトに貢献しなければならないときには、別のプロジェクトにスイッチする前に、そのプロジェクトに少なくとも丸 2 日は専念できるようにしましょう。こうすることで、プロジェクトに自分を再投入するのにかかる時間を最小限に抑えることができます。

【21】プロジェクトマネジメントはプロブレムマネジメント

ローリン・アンガー（Lorin Unger）

アメリカ、ニュージャージー州ホーボーケン

　たとえ最高の環境であっても、ソフトウェアプロジェクトのマネジメントという仕事はチャレンジングで複雑なものです。その上、プロジェクト・マネジャーが自分の役割に間違った期待を抱いたせいで、プロジェクトマネジメントをより一層難しくしているのをよく見かけます。

　単純明快に言ってしまうと、プロジェクトマネジメントはプロブレムマネジメントです。そうでなければ、そもそもプロジェクト・マネジャーなど必要ないはずです。ただ実行するよう要請するだけで、すべて（リソース、技術、要件、スケジュールなど）が調整され、何の面倒もなく仕事は順調に完了するはずです。

　ところが現実はそうではありません。だからプロジェクト・マネジャーという役割が存在するのです。リソースは割り当てすぎで、技術とスキルセットはマッチしていません。要求は不明確ですし、スケジュールは現実的ではありません。こうした問題のことを、仕事を邪魔する外部からの力によって引き起こされる迷惑、頭痛のたね、「問題（プロブレム）」だと考えているプロジェクト・マネジャーがよくいます。彼らはこう考えるのです。「あいつらがこれをやってくれていれば、あいつらがもっとよく考えてくれていれば、あいつらがもっと時間を与えてくれていれば、こんな不要な混乱は起こらずに、プロジェクトマネジメントの仕事をどんどん進められたのに。」

　言うまでもなく、こう考えている人はいつもイライラ、ピリピリしていて、怒りっぽくなっています。

　結局のところ、こうした理想と現実の違いや混乱をなくしていくことこそが、プロジェクトマネジメントの仕事なのです。私たちプロジェクト・マネジャーの役割とは、プロジェクトに資金提供する人たちやプロジェクトを遂行するメンバーたちよりも、うまく計画し、明確に考え、すぐれた戦略的ビジョンをもつことです。私たちがここにいるのは、プロジェクトの実行というものは本質的にやっかいな仕事であり、避けられない問題をつぶしたり、回避したり、取るに足らない問題へと解きほぐすために、独特のスキルと気質をもった人が必要とされているためです。

　やっかいなことに、これはプロジェクトを管理することだけに留まりません。「取るに足らない問題へと解きほぐす」必要がある場合もあります。プロジェクトで一番困難なところが「技術」や「スケジュール」にあるのではなく、プロジェクトにかかわる「人」の場合もあります。その「人」というのは、プロジェクトにアサインされたメンバーかもしれませんし、上位の監督委員会に所属している人かもしれません。

　簡単な典型例をいくつか挙げておきましょう。ひねくれた態度をとってプロジェクト・マネジャーの権威を弱体化させる「怒りっぽいメンバー」。たえず心配して落ち着きのない「神経質なステークホルダー」。ステークホルダーやプロジェクト参加者らが、事あるごとにプロジェクトをどう運営すべきか口を出さざるを得ないと感じる「目立たないプロジェクト・マネジャー」などです。

　こうした人間関係にまつわる問題について、どのように管理するのが望ましいかを説明するのは、このエッセイの範囲を超えています。あえて言うと、こうした問題を管理しなければならないのはよくあることで、WBS（Work Breakdown Structure）を理解したり、正確なプロジェクト計画をメンテナンスするのと同様、プロジェクトマネジメント責任のスコープに含まれます。

　こうした状況を業務遂行に対する障害だと考えるのではなく、それこそが自分の仕事の核心なのだと考えることで、仕事はもっと順調かつ穏やかになるでしょう。もちろん、相対的にはですが。

【22】開発者を活かす

ケン・サイプ（Ken Sipe）

アメリカ、ミネソタ州セントチャールズ

　ソフトウェアプロジェクト・マネジャーができる最善のことは、ビジョンを設定し、優先順位を付け、邪魔をしないことです。これからお話するのはティムという人物に関する実話です。

　あるとき私たちは、プロジェクトにもうひとつ別のチームが必要であることがわかりました。そこで欠員があることを公表して、候補者面接を始めました。やがてある人物が候補者リストのトップに浮上しました。

　彼の名前はティム。ティムは候補者のなかでも抜きんでていました。彼を雇うことに決めるのは「考えるまでもない」ように見えました。ところが反対意見が出たのです。私たちの部門で雇った人員はみな、3 つあるプロジェクト・マネジャーのポストを持ち回りで担当する可能性があります。そのプロジェクト・マネジャーのひとりが以前ティムと仕事をしたことがあり、彼にはモチベーションが欠けていると述べたのです。ティムの業務態度について、彼女は「仕事中いつも Web サーフィンをしていて、やる気がないように見えた」と説明しました。

　これは判断の難しい状況でした。雇うかどうかを判断するときには、客観的な面接よりも候補者とプロジェクト・マネジャーの個人的経験に重きが置かれるものです。しかし技術的観点から見ると、ティムのスキルはほかの候補者を大きく上回っていました。反対意見があったにもかかわらず、結局のところ、私たちはティムを雇うことにしました。プロジェクトはアジャイル開発によって運営されており、イテレーションの最初にはミーティングをします。

　このミーティングには大きな目的がいくつかあります。

ストーリーを作成して、ユーザー要求に基づいた優先順位を付けて、お互いに理解する。

ストーリーからそのプロジェクトスコープにおけるチームのビジョンを作成し、適切な受け入れ基準を設定する。

ストーリーをタスクに分解して、タスクを担当する開発者が見積もりをする。

　ミーティングが終わると、これらのタスクはタスクトラッキングシステムに投入されます。タスクトラッキングシステムの重要性については、よく誤解されています。これは開発者がどのタスクに着手しているのかを調べるために使われます。開発者が自分のタスクを早く完了させた場合には、本来アサインされていた開発者がまだ着手していないタスクを「盗んで」（もしくは完了して）先に進んでも構いません。

　やがてティムを雇ったのは大成功だったとわかりました。彼はチームのだれよりも多くのものを生み出したのです。彼の評価が一番はっきりとわかるのは、ほかの開発者から「盗んだ」タスクの数でした。より多くのタスクを完了させたということは、プロジェクトをすばやく完了させるのに貢献したことを意味していました。

　ここで不思議なのは、なぜプロジェクト・マネジャーのひとりがティムを非生産的だと考えたのかです。よく調べていくと、ティムを非難していた人は、過度にコントロールするマネジメントスタイルをとっていることがわかりました。彼女は開発者にタスクを「与える」と、チームの仕事場を離れてミーティングに参加していました。ティムは仕事がはやいので、アサインされたタスクをすぐに仕上げてしまいます。そして、プロジェクトの優先順位や次に着手可能なタスクについて指示がなくなると、ひとり暇にしていたのです。

　ひとりのソフトウェアプロジェクト・マネジャーが決めたものではなく、チーム全員によって周知され、文書化され、管理された、明確なビジョン、明確な受け入れ基準、共有されたプロジェクト優先順位があるとき、すぐれたチームは本当に驚くべきパフォーマンスを発揮します。時としてプロジェクト・マネジャーができる最善のことは、邪魔をしないことです。あなたはティムをうまく扱えますか？

【23】巧妙なコードはメンテナンスが困難

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　開発者は奇跡を求められるものです。現在のプロジェクトのコードを多数のパッチを含んだ時代遅れのレガシーソフトウェアとともに動かすため、開発者は巧妙な方法を見つけなくてはなりません。開発者のスキルと創造力をもってすれば、最終的にその仕事をやり遂げる巧妙なコードが作れるかもしれません。しかし、巧妙なコードはその長さや複雑さのために、将来のメンテナンス問題を引き起こしかねません。

　あなたがソフトウェア開発に不慣れなプロジェクト・マネジャーであれば、ためらわずに開発者に新しい言語や開発ツールを調べさせましょう。開発者に自由を与えるのです。これは開発者のコーディング実務や成果物を改善する革新的な手段になるためです。レガシーなインターフェイスに対して、開発者はもっと高速で、テストやメンテナンスすべきコードが少なくて済むソリューションを設計できるかもしれません。プロジェクトにとって、これは間違いなく有益です。

　現在のコードと同じ機能を大幅に少ないコードで実現できるような、革新的な新しいプログラミング言語もあるかもしれません。こうした言語を利用すると、コードの構造がはるかにシンプルになり、テストしやすく、自己定義可能で、保守すべきものも小さくなり、メンテナンスしやすくなるといった利点があります。

　もちろん、新しい言語やプラットフォームを導入する際には懸念もあります。新しいコードは現在開発中のソフトウェアやアップグレードにとって、本当に解決策になり得るのでしょうか？　これまで投資してきたレガシーなデータベース、ユーザーインターフェイス、サードパーティ製ソフトウェアで使われている既存のソフトウェアとの整合性は、長期にわたってとれるのでしょうか？　チーム内や部門内に、この新しい言語やプラットフォームを使ってソフトウェアを作れる開発者がほかにいるのでしょうか？　その言語の作者から適切な製品サポートを受けられるのでしょうか？　タイムリーにアップデートや改良がなされるのでしょうか？

　たとえあなたがプログラミングに詳しくなくても、プログラマが新しい言語を導入するのを渋ってはいけません。もし新しい言語が C や Java の流れをくむものであれば（あるいは、よくある一般的な処理方法のものであれば）、それを現在のやり方にマージするのはそれほど苦痛ではないでしょう。

　ただし、コードに新たに変更点がある場合には、必ずドキュメント化しておきましょう。そうしておかないと、コードとドキュメントが枝分かれしてしまい、システムを理解するにはコードを見るのが一番、ということになってしまいます。これはソフトウェアコンポーネントとシステムメタデータの「結合の喪失」とも呼ばれます。また、ソフトウェアをメンテナンスする上で不適切なドキュメントがあれば、それを置き換えなくてはなりません。

　プロジェクトチームにいる開発者が革新的になれるよう後押ししましょう。ただし、複雑すぎるほど巧妙であってはいけません。あまりに巧妙にやってしまうと、あとに続く人が苦労します。もしあとに続く開発者がコードを読めなければ、どうやってメンテナンスすればよいのでしょう？　プログラマはみな自らの雇用確保のために巧妙にやろうとしますが、プロジェクト・マネジャーはそこから得られるものはありません。

　巧妙すぎるコードは結局のところ、メンテナンスを困難にします。最終的に、ソフトウェアはメンテナンス不能になり、作り直しのために高くつくことになるでしょう。

【24】人的要素を管理する

ジェームス・グラハム（James Graham）PMP

マルタ、Ta’l-Ibrag

　プロジェクト・マネジャーとして、私たちは細かいスケジュールにこだわりすぎです。チームメンバーを招集して、プロジェクトを脱線させるようなリスク要因を何とか予測しようとします。割り当てられた予算内でプロジェクト成果物を絞り出せるかどうか、計算しようとします。しかし、ここで私たちは、プロジェクトが失敗する一番の原因を見落としたり、無視しています。それは人的要因です。

　エラーから不意の事故や純然たる不履行まで、実行時の人的ミスというのは、過去の行動を繰り返すことに関係している場合がよくあります。前回うまくいったのだから、今回もうまくいくはずだと考えてしまうためです。古いことわざにあるように、「金づちしか持っていない人には、すべての問題がクギに見える」のです。心理学の研究によると、ストレスの影響を受けている人は、過去に成功した経験があるとそのときと同じやり方に頼ってしまい、学習レベルや経験レベルが当時に戻ってしまうそうです。私たちにとって、新しいソフトウェアプロジェクトを引き受ける際のストレスは、非常に大きいものなのです。

　ほとんどのプロジェクトの目的は、新しい製品やサービス、ソリューションを作り出すことでしょう。したがって、過去の行動の繰り返しではなく、気持ちや業務スタイルの機敏さや柔軟さをもって行動することが奨励されるべきです。これまでとは違った新しい課題に直面したとき、古いプロセスにしたがうのは逆効果かもしれません。

　形式的なプロジェクトマネジメント手法に精通したビジネスアナリストについて考えてみましょう。開発者がなぜソフトウェア開発にはアジャイルなアプローチの方が理にかなっているかを説明すれば、彼はおそらく頭では同意してくれるでしょう。しかし、プロジェクトが危険にさらされるような時間的プレッシャーに直面すると、過去にうまくいった経験から、お気に入りのテクニックを使おうとするかもしれません。それが実際にはソフトウェアと関係のない経験であったとしてもです。

　銀行の指導官らの報告によると、数を逆にするのはよくある間違いで、特に従業員が仕事関係もしくは個人的ストレスのために 100% 集中できないときによく発生するそうです。賢明なプロジェクト・マネジャーはこうした人間の性質を熟知しており、こうしたヒューマン・エラー型の不注意がないか、見積もり、予算、その他ドキュメントを注意深くチェックしています。

　プロジェクトチームにとって何がストレスになるのでしょう？　仕事に向かう前に奥さんとケンカしたといった個人的なものかもしれませんし、家庭の財政難なのかもしれません。健康や子どもといった家族の心配事もあるでしょう。

　仕事関係の衝突もストレスを引き起こします。重要なステークホルダーとのミーティングに遅れることや、大事なドキュメントを持ってくるのを忘れるといった、それほど深刻ではないものもあるでしょう。雇用確保の懸念もあれば、プロジェクトの実装やテストが目標通りに完了できないかもという心配もあるでしょう。

　人はストレスがあると、積極的な問題解決行動ではなく、過去の行動に後戻りしようとします。ストレスの兆候に目を光らせて、チームメンバーが過去の行動へ後戻りしないようにすること、それがプロジェクト・マネジャーとしてのあなたの仕事です。チームメンバーと積極的に会話をして、仕事環境を注意深く管理することによって、ストレスの影響を防いだり最小限にすることができるのです。

　私たちは人間ですので、仕事場に感情はつきものです。しかし、ソフトウェアを開発できるのは私たちだけなのです。ですから、人的資源を注意深く育成し、管理しましょう。ほかの資源を監視して保護するのと同じです。

【25】Wiki を使う

エイドリアン・ワイブル（Adrian Wible）

アメリカ、ニューヨーク州ニューヨーク

　Wiki はプロジェクト情報へのアクセスを集中させるのに、すばらしい仕組みを提供してくれます。うまく活用できれば、1 日に何度も更新されて、チームメンバーのデスクトップに常時開かれるようになるはずです。

　プロジェクトの実作業に必要となる貴重な脳細胞をムダ使いしないよう、Wiki に入れておくと便利なページについて紹介しましょう。以下に挙げたものは一般的な例なので、自分のソフトウェアプロジェクトに合わせてカスタマイズしてください。

ステークホルダー：最新のプロジェクト状況、短期的課題、長期的課題、リスク、予算管理、マイルストーン実績などを書く場所を作りましょう。

開発者：QA データベースに接続するためのコネクション文字列といった情報を書いておきましょう。そうすれば同僚のプログラマが手当たり次第にソースコードをあさって、時間をムダにするようなことはなくなります。コーディング標準、ビルドおよびデプロイ手順、よくはまる落とし穴、DI（Dependency Injection）など進んだコーディングテクニックなどに関する情報も共有しましょう。

一般情報：プロジェクト・マネジャーはここに、ヘルプデスクの電話番号、チームの役割と責任、個々のチームメンバーの連絡先といった役立つ情報を書いておくべきです。

チームのカレンダー：ここにはチームのカレンダーを貼っておきましょう。iFrame を使って Google カレンダーを埋め込むというテクニックもあります。

ミーティング議事録：ミーティング議事録を保管しておきましょう。そうすれば、過去のミーティングで話された詳細について、簡単に記憶を呼び起こすことができます。また、将来のミーティングに向けた調査や準備をするために、過去の議事録をすばやく参照することもできます。

ミーティング議題：ステークホルダーが今後の議題をオンラインで提案できる仕組みを提供しましょう。もちろん、プロジェクト・マネジャーの承認、チーム全員への提示、次回のミーティング議題の締め切りにしたがってください。

ビジネスアナリスト：ビジネスアナリストは開発者の仕事場に同席していないことが多いでしょう。ここは複数の場所からアクセスでき、作業中のドキュメントとドメイン成果物をまとめておくのにふさわしい場所です。

テスター：組織によっては、テスト責任をプログラマから分離しているかもしれません。ここはテスターとプログラマ、2 つのチームの情報センターとして機能します。Selenium、QTP、Quality Center といったテスティングツールの使い方などを載せておきましょう。オンラインでバグトラッキング手順を検討、議論し、その最終結論を載せておいてもよいでしょう。

　Wiki を使うときのコツをいくつか挙げておきます。

情報をコピーしてはいけません。情報がほかのところにあるなら、Wiki にコピーするのではなく、その情報へのリンクにしましょう。

情報が古くなっていないかどうか確認するために、適宜更新されているか目を光らせましょう。Wiki にある情報が古いと、みんな使うのをやめてしまいます。

できれば情報をリアルタイムデータ駆動にしてみましょう。実際のプロジェクトデータからチャートやステータスが生成できるような Wiki インターフェイスをもつプロジェクトマネジメントツールを探しましょう。こうしたツールを利用すれば、進行中の作業についてリアルタイムのステータスが得られます。

　また、メール経由で情報を送るとき、特に添付ファイル（ドキュメント、プロジェクト計画、予算情報など）を送るときには、Wiki を使った方がよくないか必ず検討すべきです。

【26】ミッシングリンク

ポール・ワゴナー（Paul Waggoner）MBA、PMP、MCSE、CHP、CHSS

アメリカ、アイオワ州ウォーキー

　ソフトウェアプロジェクト・マネジャーにとって最も難しいチャレンジのひとつは、チームメンバーをタスクとスケジュールにアサインするだけでなく、プロジェクトの作業に「うまく」没頭させることでしょう。日々の業務遂行責任、トラブルシューティング、部門課題への対応、毎日のコミュニケーション対応といった日常業務と、プロジェクトのための時間制約のある業務を完了させることとのあいだで、チームメンバーは板ばさみになっているのです。

　開発者はプロジェクトチームに選抜されると、最初のうちは栄誉なことだと思うかもしれませんし、プロジェクトに参加することで毎日の気晴らしになると感じるかもしれません。しかし、いざとなれば、プロジェクトのタスクよりも担当システムの日々のメンテナンスとサポートの方が自分にとって重要であると率直に認めるかもしれません。

　プロジェクト・マネジャーとして、あなたは自分の仕事を優先しない、あるいは優先できない人をチームから追い出したくなるでしょう。しかし、ほとんどの組織では、対象分野の専門家（SME：Subject Matter Expert）の数は限られており、チームメンバーを変更したり、プロジェクトにもっと専念できる人をアサインすることは事実上不可能かもしれません。

　こうした問題の解決に役立つシンプルな提案をいくつかあげておきましょう。

すべてのマネジメントレベルが、プロジェクトの目標と目的を支持しているか確認しましょう。

専門家（SME）の職務記述書を変更して、「（日常業務以外にも）アサインされた義務を果たす」ではなく「必要に応じて複数のプロジェクトのメンバーとして行動する」と入れておきましょう。

マネジメントと人事にこの変更を重視させましょう。そして、今後の実績評価において、すべての統括者がプロジェクト活動を重視することを確認しましょう。

プロジェクト開始時には、プロジェクト・マネジャー、部門マネジャーもしくは統括者、スポンサー、そのほか重要なステークホルダーたちは、プロジェクトに参加要請したチームメンバーに対して、個人名入りの案内を送るべきです。この手紙やメールには、そのプロジェクトが果たすべき大局的な目的と、各チームメンバーの包括的な責任について説明しておくべきです。

プロジェクトが成功すれば、チームメンバーは正当に評価されることを伝えておきましょう。四半期の実績レビューの評価対象となり、人事にも報告され、記録として残ることも伝えておきましょう。

部門マネジャーの上司は、プロジェクトが組織の目標を達成するために実行されており、日常的な IT タスクよりもはるかに重要であることを明確に伝えるべきです。

エグゼクティブは、プロジェクトのチームメンバーが日常業務から開放されてプロジェクト活動に専念できるよう、部門マネジャーにはっきり要請するべきです。たとえメンバーの定期的なタスクを IT グループの別のメンバーに一時的に押し付けることになったとしてもです。

　プロジェクトにうまく参加できている人は、組織のために「一層の努力」をしていると理解され、表彰され、報酬を与えられるべきです。大なり小なりプロジェクトにうまく参加できている人は、名指しで褒められるべきなのです。アジャイル界でよく言われるように、こうすることで組織の目標と従業員のモチベーションをうまく一致させ、「可能性を広げる技」を正しく見定めるのです。

【27】見積もって見積もって見積もる

リチャード・シェリダン（Richard Sheridan）

アメリカ、ミシガン州アナーバー

　ほとんどのプロジェクトでは、プロジェクトの開始時（最も小さく見積もっているとき）にプロジェクトを見積もらせます。その後、プロジェクトの進行中（開始時の見積もりよりも大きいことがわかっているとき）に、見積もりを再検討することはありません。さらに悪いことに、もとの見積もりを実際の結果と比較して、見積もり技術を磨くということもありません。

　私の組織では慣習として、プロジェクトごとに毎週見積もっています。以前見積もったけれどもまだ作業していないタスクであれば、再度見積もります。なぜこんなことをするのだと思いますか？　これにはいくつか理由があります。

見積もれば見積もるほど、見積もりは改善します。

今の方が以前よりも多くのことを知っており、それが見積もりに役立つことがあります。

思っていたほど知らなかったことがわかり、それが見積もりに役立つこともあります。

新しい技術を取り入れるとき、たいていの場合、初期の見積もりには「不安」が加味されています。新しい技術について学ぶにつれて、その不安は小さくなっていきます。

この世界では、見積もるということは「会話」をたくさんするということです。私たちはグループとして見積もるためです。

　結局のところ、見積もりを改善する一番の方法は、実際にどうだったのかを必ず記録して、チームがどれくらいうまく見積もれたかフィードバックを得ることです。ただし、ひとつだけ警告しておきます。この情報を使ってチームを責めてはいけません。見積もりの本当の説明責任とは、見積もりを当てることではなく、見積もりが外れそうに思ったらすぐに警鐘を鳴らすことなのです。

　見積もりとフィードバックの力を理解してもらうために、単純なゲームを紹介しましょう。サイズを順に大きくした空ビンを 3 つ用意して、ジェリービーンズを入れていっぱいにしましょう。それぞれのビンごとに、いっぱいにするのにジェリービーンズがいくつ必要だったかを記録しておきます。

　見積もりについて学習させたいメンバーを集めて、一番小さいビンのジェリービーンズの数をメンバーに見積もってもらいましょう。私がこれをやるときには、ペアで作業させるようにしています。

　見積もりを考えるために少しだけ時間を与え、それから見積もりを書かせます。データが集まったら、各ペアに見積もりを声に出して読ませ、データを収集します。これらの見積もりをホワイトボードやフリップチャートに書くのです。2 番目のビン、3 番目のビンでも同じことをします。

　最後に、メンバーに対して、「これが見積もりです」と説明し、彼らの協力に感謝して、あなたが立ち去る前に何か質問がないか尋ねましょう。これはいつもよく効きます。必ずだれかが、実際それぞれのビンにいくつジェリービーンズがあったのか尋ねるはずです。そう、彼らは実際にどうだったのか知りたいのです！　しばらくやきもきさせましょう。それから、それがいかにくだらないことかを話すのです。結局のところ、ただのジェリービーンズなのですから。

　さて、あなたは彼らをこうあって欲しいと思う状態へと導きました。それでは、彼らに聞いてみましょう。これまで何回くらいデータを入手し、重要なことについてチームにフィードバックしましたか？　見積もりをバカにして重要ではないとはねつけたことはありませんか？　チームへのフィードバックを見落とすようなことは、もう二度と起こらなくなるでしょう。

【28】PMO の導入：開発者の足並みをそろえる

アンジェロ・ヴァーリ（Angelo Valle）

ブラジル、リオデジャネイロ

　もしあなたがソフトウェア開発者なら、使いやすくて柔軟性のあるフレームワークがあれば、すぐにでも動くソフトウェアを作れるのにと思っていることでしょう。残念なことに、社内部門で標準化されたアプローチをとる方向へと、世の中は進んでいます。これはソフトウェア開発者を除くすべての人にとって朗報です。

　組織構成に関して、最近 PMO（Project Management Office）が盛んに検討されています。これは世界的な現象で、少人数のグループに企業のプロジェクトやプログラムに対する監督と支援をさせるという考え方です。このグループの目的は、ドキュメントやテンプレートに一貫性をもたせ、報告プロセスを標準化し、プロジェクトによるビジネス価値を高める一貫性ある方法を提供することです。

　PMO は知識やノウハウ、部門間調整の拠り所になることを目的としています。また、統一されたポートフォリオマネジメント、プログラムマネジメント、プロジェクトマネジメントのプラクティスを通して、彼らは戦略的ビジネス目標をプロジェクトに属する従業員の行動に関連付けます。これはプロジェクト・マネジャーの雇用確保にとってもよいことです。

　企業内での PMO の機能には次のようなものがあります。

戦略：PMO のメンバーには、組織の戦略計画と足並みをそろえて、プロジェクトの立案、選択、優先順位付けをする機能があります。

指示：PMO のメンバーはガイドライン、標準、テンプレートを定義します。また、プロジェクト・マネジャーが開発チームの目標をうまく達成できるよう、すぐれたプラクティス、ツール、テクニック、ソフトウェアをどのように適用すべきか、評価し選択します。

支援：PMO はチームメンバーとプロジェクト・マネジャーをサポートします。これは、トレーニングクラス、部門共通で使えるテンプレートやドキュメントの調整、配属など人的資源の問題について、プロジェクト・マネジャーと連携するという形で現れます。

　PMO の機能は世界中の企業ごとに異なります。それぞれのビジネスは異なる発達段階にあり、それぞれが異なるプラクティスを使っているためです。したがって、同じ PMO という名前であっても、先ほど説明したリストにある機能をいろいろと組み合わせた責務をもっていたり、ここでは説明していない独特な責務をもっていたりします。

　PMO は適度に標準化されて検証された、ツール、テクニック、ソフトウェアについて、プロジェクトにアドバイスします。そうすることで、不確実性による問題や、安価な / すぐれた / 迅速なプロジェクトを過度に重視することによる問題を軽減します。すぐれた PMO は必要とされるところ、効果のあるところに標準化された方法論を適用します。これには、プロジェクトの特定、データ収集、分析、情報収集、配布、報告、リスクマネジメント、調達、品質、その他ドキュメントやコミュニケーションなどのプロジェクトマネジメント知識が含まれます。

　PMO モデルの導入による経済的成功というテーマは、国際的な会議、セミナー、最近発表された論文などでも注目されています。アカデミックな議論も盛んに行われています。大学での経験を「現実世界」のプラクティスに対応づける必要性が高まっているためです。今日の学生は明日の開発者なのです。

　PMO は広く普及してきています。もしあなたがソフトウェア開発者であれば、積極的に PMO と話し合うべきです。あなたのプロとしてのサクセスストーリーやソフトウェア開発プロセスの独自性について、PMO に伝えましょう。さもないと、あなたのニーズに合わないメソッドやドキュメント、要求、手順を押しつけられることになります。高速で、すぐれた、高品質のソフトウェアはみんなのためになるのです。

【29】労力ではなく結果を評価する

ベンカト・スブラマニアム（Venkat Subramaniam）

アメリカ、コロラド州ブルームフィールド

　ソフトウェア開発には多大な労力が必要です。とはいえ、「300 万行を超えるアプリケーションを開発している」という自慢話を耳にしたら、それだけのコードが本当に必要なのか尋ねてみましょう。

　余計なコードが追加されるのは、たいていの場合、拡張性を考慮しすぎたためです。拡張性は重要ですが、正しくやらないと逆効果になる恐れがあります。プロジェクトを遅延させる原因にもなりかねません。

　プロジェクトスコープ外の余計なコードがあるということは、プロジェクト・マネジャーが余計な時間と余計な労力に見返りを与えているということです。もしプログラマは長時間仕事をするのが当たり前だと思い込んでいるなら、実際にプログラマがそれだけの成果を生み出せているか確かめましょう。

　私は自宅の芝生を青々とさせたくて、毎日の水やりをスプリンクラーに任せています。ところがコロラドでの最初の夏、カエデの木のひとつがすっかり葉を落としていることに気づきました。私は暑くて乾燥しているのが原因だと考え、もっと水をやりました。ところが一向に改善する気配は見られません。専門家に助言を求めると、彼は私にこう尋ねました。「どれくらいの頻度でどれくらいの時間、水をやっていますか？」　私の答えを聞いて彼はこう言いました。「それが問題です！　水をやる頻度と時間を半分に減らしてください。そうすればよくなるでしょう。」

　私は水のやりすぎで木を枯らしてしまうところでした。水やりを少なくすることが、実際には木のためになるのです。それが木の抵抗力をつけ、成長の助けになるのです。アドバイスにしたがってから 2 週間後、木は健康を取り戻し、青々とした葉でいっぱいになりました。

　勤務時間に関して、プログラマはカエデの木のようなものです。プログラマに短いけれども適度な時間と、大雑把に定義されたタスクを少し与えてみましょう。するとプログラマはいきいきと働きます。彼らに大きなタスクの束を与えて、定期的に残業するよう頼んでみましょう。するとプログラマは意気消沈します。しかも既存のコードを書き直して、さらにややこしくしたりするのです。なぜなら彼らには時間があり余っているためです。

　私はみんながどれだけの時間働いているかを重視しているマネジャーの下で働いたことがあります。そのマネジャーは、従業員が実際に生み出すものよりも、土曜日の朝に仕事をしたり晩遅くまで残ったりすることの方が重要だと考えていました。しかし、プログラマが 1 日に 12 時間以上も高い生産性を維持して、効率よく仕事をするというのは、実際のところ不可能なのです。

　別のチームのマネジャーは、従来通り 8 時間の勤務スケジュールを守らせていました。確かに従業員が遅くまで居残る日もありましたが、それはノルマではなく例外でした。従業員は長時間仕事をするよう要求されていないことを知っていましたが、コミットした成果物をスケジュール通りに提供しなければなりませんでした。そのため、チームは注意散漫になることなく仕事に集中し、仕事をうまく優先順位付けして、時間を効果的に活用しました。開発者の能力ではどちらのチームも同程度でしたが、前者の消耗するまで仕事をするチームよりも後者のチームの方が多くのことを成し遂げていました。

　プログラマには、どれだけ仕事をしたかではなく、彼らが実際にやった結果を報告させるようにしましょう。コンピュータの前でどれくらい時間を費やしたかよりも、結果を得ることに関心をもちましょう。あなたは結果指向のマネジャーであり時間指向のマネジャーではないとチームメンバーが実感すれば、彼らも自分たちの勤務時間ではなく、自分たちが達成した結果に注目するようになるでしょう。

【30】プロジェクトの失敗は組織の失敗

ブライアン・スレッテン（Brian Sletten）

アメリカ、カルフォルニア州ビバリーヒルズ

　ソフトウェアプロジェクトがおかしくなると、私たちは必ず開発者を責めたてます。締め切りに間に合わなかったり、成果物に昆虫学者もびっくりするほどバグ（虫）があると、チームには実力と賢明さがなく、必要な生産性あるいはチャレンジ意欲が足らないのではないかと思ってしまいます。チームもそれなりの非難を受けるとしても、ソフトウェアプロジェクトが成功するためには、すべてのステークホルダーが積極的かつ適度にプロジェクトに参加する必要があることを忘れてはいけません。

　全員参加が不可欠です。失敗を回避するためには、だれが、何を、いつ、なぜ作っているのか、あなたは知る必要があります。優先順位にしたがって、慎重にビジネス機能を追加する必要があります。不要とされた要求について、何が問題なのか見つける必要があります。また障害になりそうな人物を見極め、コミュニケーションミスに注意し、大量の仕事に閉口している（しかし情熱あふれる）開発チームをなだめることで、隠れた障害の芽を取り除く必要があるのです。

　ソフトウェアを開発するためには、確かな測定基準、明確なコミュニケーション、ビジネスおよび幹部ステークホルダーの参加が不可欠です。全員がソフトウェアを納品するという活動にかかわり、良い結果であろうと悪い結果であろうと、どちらにも一部責任を負わなくてはなりません。プロジェクト・マネジャーはその結果を測定し、成功と失敗どちらの実績も記録する必要があります。堅実に納品してくれたチームは、また今度もそうしてくれるとステークホルダーから信頼されます。ほとんど納品できなかったチームは、さらなる監督、トレーニング、再編成が必要です。一部のメンバーには出ていってもらう必要もあるでしょう。

　ただし、チームには混乱を整理するための時間を与えましょう。そのままリリースに突き進んでしまうと、Wiki の草分けであるワード・カニンガムが「技術的負債」と呼んだものを負うことになります。これは実際の負債と同様、絶えず責任をもって支払っていかないと、やがて自分たちの手に負えなくなり、いつも返済を気にしなくてはならなくなります。

　各イテレーションには、新しいビジネス機能を追加するだけでなく、否応なくコードに現れるハックをリファクタリングするという活動も含むべきです。これはサボるための免罪符ではありませんし、出来の悪いチームの兆候でもありません。これは単なるプログラミングの現実にすぎません。幹部ステークホルダーからの十分な支援のもと、定期的に解決していかなくてはなりません。

　組織は業界トレンドを把握し、適切なツールを手に入れ、プログラマの仕事にはっきりとした効果のある実装方法を採用することを明言しなければなりません。勤務時間の内外で、開発者が知識を広げることを奨励しましょう。新しいツールをいじったり、トレーニングを受けたり、価値あるカンファレンスに参加したり、本やブログを読んだりすることは、ソフトウェア開発に要求される不断の努力に必要なものです。

　チームランチを開催して、メンバー同士が知識を共有し、新しいアイデアを出し合うことは、メンバーの成長を促す安上がりですばらしい手段です。雇い主に支援されていると感じているソフトウェアエンジニアには忠誠心が芽生え、自ら進んで一層の努力をするものです。要求や技術展望の変化に対応する心構えもできるでしょう。

　ソフトウェア業界の現場では、高品質で約束通りのリリースを着実に納品するためにできることがたくさんあります。継続的に繰り返し成功する機会を高めるために、ソフトウェアを作る組織はあらゆるレベルでプロセスにかかわらなくてはなりません。

【31】顧客からの声

マーティ・スコマル（Marty Skomal）MPA

アメリカ、ネブラスカ州オマハ

　開発者たちやプロジェクト・マネジャーたちから話を聞くのはよいことですが、財布を握っている人から話を聞くのも同じように役立ちます。顧客は私なのですから。

　今やソフトウェアは、低コストで、Web ベースのビジネスを可能にするものとして、非営利部門や政府部門の領域にまで進出しています。これまではあまりに高価で手の込んだ、従業員たちの手に負えないレベルの先端技術が簡単に使えるようになってきました。

　非営利機関や政府機関はぎりぎりの予算でやっており、こうした自動化の可能性に魅せられるでしょうが、そこには罠があります。何もかも手に入れようとすると、結局あなたは何も動くものを得られず、靴箱と 3 × 5 インデックスカードでデータを保管していた日々を懐かしむことになるでしょう。

　ひとつ例を挙げましょう。私が所属する芸術評議会は、紙ベースの助成金申請プロセスをオンラインに移行することを決めました。申請書は評議会に直接提出されて、データベースに登録されることになります。これにより手作業のデータ入力ミスはなくなり、コストは低下し、有権者にとっても不便な発送作業がなくせます。準備中の申請をオンラインでレビューして、提出前に支援することも可能になります。

　ソフトウェア開発者は、助成金申請プロセスをどうすればもっと自動化できるか、あれこれ指摘しました。たとえば、システムに投入する前に適正基準に照らして見込みのある組織を吟味したり、締め切りに間に合っているか確認したり、損益のバランスをとらないと申請書の提出ボタンが有効にならないようにしたり、などです。

　私たちが一番やりたかったのは、単純にデータをインポートし、データの正確さを検証し、申請を受理したことをメールで返すことでした。ところが、私たちは自由に検討するよう言われていたため、あれこれ検討してしまいました。結局いろいろと検討していたことは期限切れで却下されてしまったのです。その結果、システムは柔軟性のないガチガチの要件のもと、サービス重視の視点を失ったものになりました。あきれたことに、締め切りを過ぎると申請はブロックされて、開発者に特別な上書き処理を依頼しない限り、申請を自分のデータベースにインポートすることすらできなくなったのです。

　私たちはもっとシンプルなシステムから着手して、その機能に慣れたころに徐々に複雑にしていくべきでした。必要としていたのは自転車だけだったのに、動かない宇宙船の一部を作ってしまったのです。

　私たちは結局そのシステムを破棄しました。今はベンダーを利用して、もっと機能が少なくて安定したシステムを使っています。私たちは古い手続きに合わせたソフトウェアをスクラッチから作るのではなく、システムに合わせて内部手続きを調整しました。今では、オンライン助成金申請システムを、データベースにデータを入力し、操作するための手段だとみなしています。非常に高度な技術を使っている、やれるにはやれるけれども、扱いにくいガラクタのようなもの、ではありません。

　顧客を道に迷わせないよう、次のことを心掛けましょう。

顧客に計画させ、徐々に構築して、テストを何度も繰り返せるようにすること。

シンプルなタスクを過度に自動化するようアドバイスしたくなるのをこらえること。

ユーザーのニーズを理解することを大事にする開発チームを作ること。

　テクノロジーの道具袋に入っているものをすべて投入する前に、顧客がうまく扱えるかどうか考えましょう。

【32】物事を正しくとらえる

ジェームス・グラハム（James Graham）PMP

マルタ共和国、Ta’l-Ibrag

　ユーザーからビジネス要求を集めていると、こんな言葉をよく耳にしませんか。「システムが遅い」、「アプリケーションは信頼できない、よくクラッシュする」、「必要ないことはやってくれるのに、必要なことはやってくれない」、「メニューがわずらわしい」、「単純なことをやるのにキーを何度も打たなきゃならない」。

　たいていのプロジェクト・マネジャーはここでユーザーに共感します。彼らの苦痛を取り除くようなソリューションを提案して、ユーザーの気分をよくしようとするのです。本人はよかれと思ってやっているのでしょうが、このやり方は本質的に間違っていると思います。それだけでなく、次のプロジェクトが成功する可能性を低くすると思います。

　ビジネス要求を集めるときに大切なことは、カスタム設計のソリューションを提供してエンドユーザーの不満を解消することだという人もいます。これもまた立派な目標であることには同意します。しかし、もしプロジェクト・マネジャーがユーザーの気分をよくしたいことを根拠に、それを最高のソリューションだと判断しているなら、これは致命的な欠陥です。実際のところ、そのマネジャーは先入観なく物事をとらえるよう訓練されていないのかもしれません。

　物事を正しくとらえるということは、最高のソリューションを探すということです。ユーザーが正しいと感じることを探すのではありません。ただし忘れないでください。ユーザーは自らのビジネス領域について深く理解しており、その知識を共有することでプロジェクトにすばらしい貢献ができるのです。では、ユーザーからのインプットをどのように利用するべきなのでしょうか？

　私がロンドンで経営コンサルタントとして仕事をしていたとき、経験豊かな同僚たちが客観性の重要さについてよく私にアドバイスしてくれました。彼らの教えは、専門家は自分がどれだけ賢いか見せたがるものだ、という自明の理に基づいていました。専門家はそのスキルを使って、正しい質問を投げかけ、根本的な問題を明らかにすることに、もっと時間をかけるべきです。あなたが本当の問題を明らかにしない限り、問題を取り除こうとしても表面をなでるだけになるでしょう。

　だれもが、こうした間違いをする恐れがあります。最近、私は大企業向けのマネジメント開発プログラムを設計するよう依頼されました。私の頭をよぎったのは、既存のプログラムを検査するよう指示して、その傷口にすばやく対処すべく駆けつけることでした。そうすれば、ひどい炎症を起こしているところを簡単に治療できることがわかっていました。

　幸運にも、ここで私の自制が効きました。私は 1 時間かけてシニアマネジャーと真の課題が何であるかについて話し合いました。何かがおかしいと言うエンドユーザーの不平だけでなく、ビジネスの問題についても話を聞きました。結局、私はまったく異なるソリューションを提案しました。その方が彼らのニーズに適しており、根本にある問題を解決するものだったのです。

　今度不満のあるユーザーを見つけたら、まずは深呼吸しましょう。そして、日々ふりかかる表面的な症状に対する不満のはけ口になってあげるのです。炎症は実際に起こっているのですから。それから、不満の根本原因が見つかるまで質問を繰り返しましょう。応急処置をすることで、彼らの気分をよくするという誘惑から逃れましょう。プロジェクトの軌道を計画する前に、まず正しい目標に向かっているか確かめることが重要です。

【33】「完了」をどう定義するか

ブライアン・サムボッデン（Brian Sam-Bodden）

アメリカ、アリゾナ州スコッツデール

　成功が何を意味するのか明確な定義がなければ、ソフトウェア開発チームが成功するのは困難です。開発者にとっての成功には、顧客の期待を満たす製品を納品することが必要です。しかし、プロジェクト全体の成功を定義するためには、「プロジェクトを完了する」ことが何を意味するのか、正確な定義がより大きなプロジェクトチームで共有される必要があります。

　プロジェクト全体のスコープをとらえるため、反復型ソフトウェア開発で中心となっている信条が「分割統治」です。プロジェクトは複数の成果物に分割され、それらはさらに作業パッケージに分割されます。そして最終的に、各個人にアサインされるアクティビティへと分割されます。

　1 週間から数週間のイテレーションや作業期間を設けるアジャイルなアプローチを使うと、プロジェクト全体のスコープについて考える必要性を隠すことができます。1 つのイテレーション目標を完了するということは、ユニットテストをパスし、可能ならインテグレーションテストを一部クリアし、実現すると約束したフィーチャーが実際に動作するソフトウェアを作って、ステークホルダーの承認とフィードバックを得るということであると明確に定義できます。

　ここで問題になるのは、マクロレベルにおけるコードとそれに付随するテスト以外にも、プロジェクトレベルではたくさん検討すべきことがあることです。従来のウォーターフォール開発の場合、テストはプロジェクトの最後に追いやられてしまい、それがプロセス上の弱点になっていました。アジャイルなアプローチの場合、開発者はプログラミングとは関係ないアイテムやアクティビティをすべて、ソフトウェアプロジェクトには必要ないと考えて、間違って保留したり却下するおそれがあります。

　これらの中には、新しく作られたコンポーネント / フィーチャーと以前のイテレーションで作られたコンポーネント / フィーチャー間のユニットテストやインテグレーションテストも含まれているかもしれません。こうしたインテグレーションは見落とされがちですが、開発チームにとって根本的な問題を浮き彫りにしてくれます。ソフトウェアの複雑さはコンポーネントの相互接続数に比例します。デモ環境を作り上げるのに必要な時間を無視してはいけません。ユーザーレベル / 受け入れテストスクリプトを書いて、付属ドキュメントを書きましょう。どんなに軽量な開発手法であっても、出荷可能なソフトウェアには、ある程度のドキュメントが必要になります。

　こうしたアイテムを無視しないようにすると、「完了」が意味するマクロな定義は、各イテレーションのフィーチャーセットの完了を積み重ねたものとはかなり違うものになります。そして、イテレーションごとに不足しているアイテムの積み重ねから作られた差分こそが、フィーチャーの実装方法、テスト方法、顧客のとらえ方を変えるのです。

　管理上の問題やビジネス上の問題で、開発者に過度の負担をかけないようにしましょう。私たちが広めなくてはならない基本的な考え方は、イテレーションはソフトウェア開発者だけのためにあるわけではないということです。イテレーションは、もっと広範囲の一般的なプロジェクトメンバーの重要なタスクと連携していなければなりません。ビジネスアナリスト、プロジェクト・マネジャー、テスターは、自分たちのアクティビティと開発者のアクティビティをうまく調整しなければなりません。

　こうした調整に責任を持つ人、それがプロジェクト・マネジャーです。プロジェクト・マネジャーはマクロレベルにおける完了が意味するのか、全体的な定義を理解し、広めなくてはなりません。そして、毎週のイテレーション作業と協調して、コードに無関係なアクティビティも実行しなくてはなりません。「完了」が本当に意味するところを定義するため、プロジェクト・マネジャーは開発チームとほかのステークホルダーたちの間の調停役を果たさなければならないのです。

【34】60/60 ルール

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　私たちはソフトウェア開発がソフトウェアのライフサイクルで一番重要だというふりをよくします。世の中には開発のための方法論があふれています。書籍、雑誌記事、ブログなど、いずれも開発に焦点を当てています。しかし、お金がかかるのは開発だけではありません。

　ソフトウェアシステムにおけるライフサイクルコストの 60% はメンテナンスによるものです。開発にかかるコストは、相対的に 40% にすぎません。もちろん、これは平均での話です。実際のメンテナンスコストは、システムの種類やデプロイ環境によって 40% から 80% まで変動します。メンテナンスコストのうち、平均して 60% がユーザーによる機能強化（要件変更）に、23% が移行アクティビティに、17% がバグ修正に関係しています。

　ライフサイクルコストの 60% がメンテナンスに関係していること、そしてそのメンテナンスの 60% が機能強化に関係しているという事実から、ソフトウェアメンテナンスについてよく言われている「法律」のひとつ、いわゆる 60/60 ルールが生まれました。

　移行アクティビティには、システムを新しいハードウェアやソフトウェア環境に移すことも含まれます。こうした移行もまた、要件変更の 1 つです。そう考えると、興味深い事実に気づきます。メンテナンスアクティビティの 80% は何らかの要件変更に関係しているのです。

　当然ながら、コードを変更するためには、まずコードを理解しなくてはなりません。やるべき変更を理解すること、それがメンテナンスの主たるアクティビティとなります。全メンテナンス時間のだいたい 30% が、既存のソフトウェア製品を理解することに費やされます。これは、要件変更、移行、バグ修正といったメンテナンスすべてに当てはまります。

　他人が書いたコードや自分たちがずっと以前に書いてよく覚えていないコードをメンテナンスするためには、「理解すること」が支払わなければならないコストになります。メンテナンス中は、コードを理解することが、開発中に見られる新たな設計作業の代わりになるのです。

　60/60 ルールはソフトウェア開発だけでなくメンテナンスにも注力しなければならないことを思い出させてくれます。開発アクティビティに注力しすぎると、最高の利益を生み出せないかもしれません。1980 年代初めのベームによる「適切なソフトウェアエンジニアリング規律は欠陥を 75% まで削減できる」という主張は正しいのかもしれません（本当のところ私は疑わしいと思っていますが）。この主張は開発方法論がさかんに議論され、作られた土台となっていました。しかし、それでどうなったでしょうか？

　すぐれた方法論を使うことでバグ（全メンテナンスコストの 17%）は削減できるかもしれませんが、移行、機能強化に要する時間やコストにはまったく対処できていません。メンテナンスコストを削減するためには、コードの理解、新しい要求へのコードの適合、新しい環境へのコード移行などにまつわるコストにも対処する必要があるのです。

　60/60 ルールは、メンテナンス可能なシステムを作ることに全力を注ぐべきだということを示唆しています。私たちのソフトウェアは、変更可能なように設計されなくてはなりません。これによってシステムは新しい要求に直面しても柔軟に対処できるようになります。こうしたシステムを設計することは、ソフトウェアエンジニアリングにおける次の大きな課題の 1 つです。

　私たちは少なくとも、その答えの一部を知っています。Web の各コンポーネントが最後の瞬間に柔軟に結び付けられて動くのと同じように、ソフトウェアコンポーネントもお互いに疎結合である必要があるのです。

【35】我々は敵に出会った。それは我々自身だ

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　『Pogo』という長期連載漫画を描いた漫画家のウォルト・ケリーは、「我々は敵に出会った。それは我々自身だ」という言葉で有名です。ソフトウェア開発プロセスに不慣れなプロジェクト・マネジャーを表現するのに、これほど的確な言葉はほかにないでしょう。ここではあなた自身が「敵」にならないための方法を挙げましょう。

あなたはプロジェクト・マネジャーとして、チームメンバーがタスクを完了するのにかかる時間を適切に見積もることを期待しているでしょう。もし割り当てられた時間をはるかにオーバーしてしまうと、スケジュールに悪影響を及ぼします。プロジェクトにおけるあなたの役割のひとつは、ミーティングを開いてチームのコミュニケーションを促進することです。開発者がコード量を見積もって約束通りに納品することを望んでいるなら、あなたもミーティング時間を見積もって約束通りに実施できることを示す必要があります。

ミーティングが長引いてしまうと、開発者が当てにしていた貴重なプログラミングの時間を、あなたが盗んでしまうことになります。

もしプロジェクトチームが外国語を話しているなら、あなたはレッスンを受け、通訳を用意したいところでしょう。開発者はあなたの母国語を話してはくれません。本を買って、授業を受け、Google を友とし、複雑なことをシンプルに説明してくれる開発者を見つけましょう。チームが取り組むコンセプト、用語、課題について学ばずに、口先だけでプロジェクトを乗り切ることはできません。

あなたはこれまで、トースターや車を作ったり、調合薬を開発したり、高層ビルを建設したりするのに最適な手法を使ってきたでしょう。しかし、ここではそうしたやり方は機能しません。信頼できるメンバーにアジャイル開発について説明してもらいましょう。アジャイル開発というのは新しいものではなく、危険なものでもありません。プロジェクトの終わりに機能する製品を作り上げる絶好の機会を提供してくれるものです。

開発者は職人であり芸術家です。彼らは会計士、弁護士、銀行の窓口とは違ったやり方で働きます。2 人 1 組になっていきいきと話しているときも、彼らは実際には仕事をしているのです。壁に向かってボールを弾ませたり、ホワイトボードに落書きしているときも、彼らはコンピュータの画面をじっと見ていても解けないアーキテクチャ問題の解決策を練っているところなのかもしれません。彼らに居場所を与えましょう。

チームは空き時間も仕事をしています。皆さんは、地元のスーパーのレジ係が交代するのを見たことがあるでしょう。彼女はレジを開いてお金の引き出しを入れ替え、新しいレジ係が仕事できるよう準備をします。しかし、プログラマの場合、仲間と交代して相手がやっていた仕事の続きをそのまま引き継ぐことはできません。メンバーが無我夢中で働いているときには、そっと一人にしておきましょう。ある研究によると、人間は割り込まれると、生産性を取り戻すのに 1 時間以上かかるそうです。

全員がまったく同じプログラミング言語でプログラミングする必要はありません。新しい言語を活用することで、書いて、テストして、サーバに配置して、メンテナンスするべきコード量が少なくなる場合もあります。開発者が仕事に最適なツールを使うことを拒んではいけません。

　ソフトウェア開発の新しい世界に心を開きましょう。そうすれば、あなたは敵ではなくソフトウェア開発チームの味方になれるでしょう。

【36】サイクルで働く

ジェームス・リー（James Leigh）

カナダ、オンタリオ州トロント

　私たちの身体は自然のサイクルに満ちており、その生産性に違いはありません。人間の脳は同時に数時間以上、1 つの問題に集中することはできません。理想的な勤務時間は、90～180 分ごとに休憩して、身体が再び集中するための時間を確保することです。生産性は 90～120 分経つと低下してきます。再び生産性を高めるには、脳に焦点を切り替えさせる必要があります。

　最も効果的なソフトウェアプロジェクトは、開発者が精神的に豊かであることを保証した環境で作られます。しかし、開発者の生産性に寄与することの大部分は、プロジェクト・マネジャーには制御不能なものです。開発者が適切な食事を摂っているか、夜十分睡眠がとれているか、あなたは保証することができません。しかし、頻繁に休憩を促し、栄養指導の機会を提供することで、日中、開発者の生産性が低下しないよう手助けすることなら、あなたにもできるでしょう。開発者は胃袋で動く、という古いことわざは本当なのです。

　また研究によると、プロジェクトは複数のイテレーションに分割すると成功しやすいそうです。目標設定、優先順位付け、フィードバック、リリースを含んだサブプロジェクトを毎週、毎月作ることで、ソフトウェアのバグは削減され、開発者の満足感は高まります。仕事を小さなイテレーションに分割すると、進捗状況を追跡でき、よい結果を知らせる機会も生まれます。またチームの全員に、自分自身と向かい合い、お互いにフィードバックし合い、コミュニケーションを改善する機会を与えてくれます。

　それぞれのサイクルには、計画ステージ、行動ステージ、完了ステージ、報酬ステージを入れておくべきです。アクションアイテムを始める前に、なぜ、いつ、どのように、何を、誰が、といった質問を自分自身あるいはチームに問いかけましょう。なぜこれをやっているのですか？　いつ完了する予定ですか？　どのようにやるつもりですか？　何を達成しようとしているのですか？　チームのだれがそのアイテムに責任を持つのですか？　適切なコミュニケーションと理解があれば、行動ステージは効果的かつ生産的になり、プロジェクト全体の成功に寄与します。

　タスクやアクションアイテムが完了したら、外部からのフィードバックを得ましょう。もしチームメンバーの 1 人か 2 人が仕事を完了したのなら、ほかのチームメンバーにそれをレビューさせましょう（ピアレビュー）。もしチーム全体が仕事を完了したのなら、ほかのステークホルダー（できればエンドユーザー）からフィードバックを得ましょう。サイクルの最後は報酬ステージです。これはチームや個人の健康維持のために重要です。バッテリーを使った後にチャージしなくてはならないのと同様、脳や身体も感謝の言葉や仕事の承認によって報われなくてはなりません。

　あなたはプロジェクト・マネジャーとして、プロジェクトサイクルを通して、全員が計画を理解し、必要とするフィードバックが得られるよう、チームを導かなくてはなりません。さらに、ひとりひとりが計画、実行、完了、報酬というサイクルにしたがわなくてはなりません。マネジャーは、チームメンバー全員が生産性をベストな状態でキープするのに必要な配慮、情報、時間が得られるよう保証しなくてはなりません。そうすることで初めて、あなたのチームは全能力をあげて機能することが保証できるのです。

【37】自らに誠実であれ

ハリー・タッカー（Harry Tucker）

アメリカ、ニュージャージー州マタワン

　飛行機で旅行したことのある人なら、機内のセーフティデモにおいて、まず最初に自分の酸素マスクを着けて、その後、お年寄りや子どものマスクを手伝うように指示されるのを覚えているはずです。もし自分のマスクより先に他人のマスクを着けるのに必死になってしまうと、それがうまくいく前にあなた自身が酸欠になって死んでしまうかもしれません。そうなれば結局全員が死んでしまうのです。自分のマスクをすばやく付けることで、他人の世話に 100% の力を発揮できるようになります。そうすれば最終的に全員が生き残れるのです。

　私は何年も数々のすばらしいプロジェクトが失敗するのを見てきました。たとえ、成功するのに最高の条件がそろっていたとしてもです。

　これからお話しするプロジェクトには以下の条件がそろっていました。

無限の市場潜在力

すぐれた製品

驚くべき能力のある、権限を与えられたチーム

　しかし、プロジェクト・マネジャーは自分自身をコントロールできず、チームの面倒を見られませんでした。いわばチャンスが酸欠で死んでしまい、プロジェクトは失敗してしまったのです。

　チームをマネージする（manage）、あるいは、リードする（lead）ためには（この 2 つには明らかな違いがあります）、プロジェクト・マネジャーは自らを完全にコントロールできている必要があります。自分の個人的目的、ビジョン、ミッションも、個人的な仕事上の目標も、きちんと理解しなくてはなりません。プライベートがしっかりしていれば、マネジャーは自信がもてます。自信がもてないと、マネジャーは日々の苦悩で簡単に吹き飛ばされてしまいます（オフィスの内でも外でも）。たとえ賢明で有能なマネジャーであっても、目の前にあるマネジメントタスクに集中できなくなってしまうのです。

　そうなると、次から次へとさまざまな症状が現れはじめます。

マネジャーは目に見えて注意散漫になり、落ち着きを失っているように感じ始めます。

マネジャーはうまくいっているように思えなくなり、プロジェクトを守るために立ち上がって必要なことをやる意欲がなくなったように感じます。

無防備になったチームは、コミュニケーションの断絶を感じ始めます。

コミュニケーションの断絶は（本来のプロジェクトの基準とは合わない）ずれたタスクを生みます。

ずれたタスクとその状況を正常に戻せないマネジャーは、チームの失望をまねきます。

チームのモラルは失われ、すでに制御不能なプロジェクトはさらに混乱します。

　私は個人的に、毎日、毎週、半年ごとに、自分が人生のどこにいるのかレビューする時間をとっています。毎日および毎週のレビューは、短期的目標について私に思い出させてくれます。半年ごとの瞑想（白紙での計画）は、個人的に、仕事的に、順調に進んでいるかを確認し、長期的目標について評価するよい機会になります。

　私たちの人生は常に意外な出来事に満ちていますが、短期的目標と長期的目標があれば、混乱をやりすごして、個人的な仕事上の進路を再調整することができます。こうした計画があれば、手元にあるタスクにもっと注力できるのです。これにはチームを成功に向かって活気づけるようチームを管理することも含まれます。

　さあ、酸素マスクが落ちてきました。あなたは最初にだれを助けようとしますか？

【38】ミーティングはコードを書かない

ウィリアム・J・ミルズ（William J. Mills）

アメリカ、カリフォルニア州カストロバレー

　生産的なことができる人なのに、ミーティングに捕まってしまうというのは非常によくあることです。しかもそのミーティングは、本来の目的から外れていたり、時間を超過したり、一部の人にだけ意味があるのにチーム全員を部屋に閉じ込めたりするのです。具体的に目的のあるミーティングだけを予定に入れましょう。そして、同席する必要のある人だけを招待リストに入れましょう。ソフトウェアプロジェクト・マネジャーとして、チームミーティングをするときに避けるべきことを以下に挙げます。

おしゃべりをすること：もしミーティングを非公式なプロジェクト関係の情報交換に使っている参加者がいれば、数分前にやってくるか、ミーティングのあとに時間をとるよう指摘しましょう。おしゃべりが終わるまで全員を待たせる余裕などありません。

何も片づけられないこと：事前に明確なアジェンダを配布するようにしましょう。もしチーム全員を集めるなら、話題が全員に関係するものか確かめましょう。

詳細に入りすぎること：発生したリスクや問題、障害を指摘するのはよいことです。しかし、ここは解決策を打ち出す場ではありません。ミーティング後に問題を追及するよう、少人数のグループを作るか、適切なチームメンバーを指名しましょう。

ごく少数のソフトウェアエンジニアが具体的な実装詳細について話しはじめたら、ミーティング後に残るようメモを取らせて、次回のアジェンダに組み入れましょう。

話が脱線すること：現在のミーティングには具体的な目的があるはずです。フォーカスを見失ってはいけません。重要ですが本筋ではないことが持ち上がることもあるでしょう。その場には本質的に関係のない人たちがたくさんいるかもしれませんし、この問題を解決するのに必要なステークホルダーがいないかもしれません。別のミーティングをスケジュールするか、現在のミーティングを終了してから、その新しい問題に対処しましょう。その場にいる必要のない人は、仕事に戻らせることを忘れずに。

時間を超過すること：あなたはプロジェクト・マネジャーとして、チームメンバーが特定のタスクを完了するのにかかる時間を見積もれることを期待しています。もしあなたがミーティングで予定した時間を大幅に超過すれば、スケジュールに害をもたらすでしょう。

ミーティングが多すぎること：もしアジャイルにしたがっているのなら、毎日の短いミーティングが必要です。そうでなければ、あなたの開催するミーティングが、別の方法では集められない情報を吸い上げたり、データを収集しているか確かめましょう。

しつこい参加者を自由にさせること：そのミーティングのリーダーとして、あなたの仕事は、言葉によらない「ストップ」（話している人に手のひらを向ける）と「スマイル」を駆使することです。「十分考慮すべきポイントですが、時間の都合上、先に進まなくてはなりません」（あるいは、「他の人の意見も聞いてみましょう」や「時間があれば後でこの件に戻りましょう」）。

　チームメンバーらはリーダーであるあなたに対して、非生産的なミーティングだとはっきり言えないのかもしれません。したがって、あなた自身のプラクティスを自ら評価して、自ら改善できるようにしましょう。

【39】変化のための道筋を描く

キャシー・マクドゥガル（Kathy MacDougall）

アメリカ、コロラド州エリー

　新しいソフトウェアは仕事のやり方を変えます。これは組織にとってよいことかもしれませんが、そこで仕事をしている人は必ずしも変化を受け入れる準備ができているわけではありません。この現実を認めましょう。新しいソフトウェアを使うよう説得できなかったり、なだめられなかったり、指示できなければ、それは時間とお金の大きなムダになります。

　仕事のやり方を変えさせるときには、ムチ（罰）よりもアメ（報酬）の方がはるかに有効です。たとえ新しいソフトウェアを導入せざるを得なくなったとしても、ユーザーが理解して習得するに値する大きな利益が見い出せなければ、彼らはあらゆる手段を駆使して使わずに済ませようとするでしょう。（1）この変化が関係者にどんな影響を及ぼすのかを理解し、（2）彼らが変化を受け入れられるような変更管理計画を整備するためには、適切なケアが必要になります。

　変化がどんな影響を及ぼすのかを理解するために重要なのは、みんなが現在どのように仕事をしているのか、新しいソフトウェアはそのプロセスをどのように変えるのかを理解することです。そうすれば新しいソフトウェアがユーザーのニーズに合致することを保証でき、ユーザーが新しいシステムを導入する可能性が高まり、最終商品の設計も改善されます。

　変更管理の重要性を過小評価してはいけません。これはプロジェクトの初期にプロジェクト・マネジャーが注力すべきところです。変化がユーザーにどんな影響を及ぼすのか判断するために、まずはソフトウェアプロジェクトにまつわる現在のあらゆる（そのままの）プロセスをドキュメント化しましょう。毎日のタスクを列挙したプロセスフローダイアグラムとデータの入出力を図示しましょう。

　次に、新しいソフトウェアを展開することによって、これらのプロセスがどのように変化するのかをドキュメント化しましょう。新しいソフトウェアのターゲットユーザーと率直に話し、その変化がどのような影響を及ぼすのか議論しましょう。彼らの声に注意深く耳を傾けて、フィーチャー変更の影響とそのコストを評価して、ソフトウェア設計を徐々に整えていきましょう。変化がターゲットユーザーと彼らのマネジメントに受け入れられているか確認してください。ターゲットユーザーのマネジャーを、早期に頻繁に巻き込みましょう。彼らは変化に対する重要な支持者となります。エンドユーザーに切り替えを勧めたり指示したりすることにより、彼らは新しいシステムへの移行を実施もしくは中断できます。彼らは新しいソフトウェア展開に伴う障害を取り除き、不測の問題を解決するための貴重なパートナーなのです。

　変化のための計画を作りましょう。プロジェクト立ち上げ前にやっておく必要のあるトレーニングやチーム作りのためのリストを決めて、ユーザーのスケジュールに組み込んでおきましょう。変更管理計画を作るときには、マネジメントからの支援を仰ぎましょう。少なくとも彼らが、そのコンセプト、実行およびトレーニング方法、スケジュールについて心から賛同していなければなりません。彼らからのアプローチに対する反対意見や警告には、注意深く耳を傾けましょう。

　結局のところ、ユーザーとそのマネジメントはビジネス目標を果たすことに正面から注力し続けることに関心があります。新しいプロセス、ツール、システムへの移行は、彼らの目標達成にとって潜在的脅威になり得ます。きっちり事前に計画しておきましょう。そうすれば、新しいシステムへスムーズに移行でき、賛同と受け入れのための道を開き、長期的な利用の機会を高めることができるでしょう。

【40】IT プログラムの管理

デビッド・ディアス・カスティロ（David Diaz Castillo）MBA、PMP

パナマ、パナマシティ

　複数の関係する技術プロジェクトがより大きな「プログラム」にまとめられることがよくあります。こうした戦略がとられるのは、プロジェクトを費用対効果の高いやり方で完了するため、そして、重複や隙間をなくして組織に戦略的利益をもたらすためです。ただし、個々のプロジェクトが実現しなければならない真のビジネス目標とは何なのか、チームがほかのプロジェクトとどのように連携するのか、プロジェクト・マネジャーがチームメンバーに正しく伝えることが極めて重要になります。またチームメンバーも、具体的なプロジェクト目標の実現が全体のプログラム目標の成否にどのように寄与するのか、理解しなければなりません。

　そのためには重要なタスクがいくつかあります。

単なる独立した価値を超えた、プロジェクトの重要性を高めるようなつながりを見つける。

プログラムに含まれる全プロジェクトで共有される関係、成果物、リスクを定義する。

プログラムが達成しようとしている最終ソリューションにチームメンバー全員が一致協力し続ける。

避けられない問題が現れたとき、プログラムの戦略的目標に合ったソリューションを提案できるよう、ビジネスを理解する。

　プロジェクトをプログラムにまとめるという考え方は中南米ではまだあまり成熟していませんが、私たちは共通のガバナンスポリシーを使ってプログラムを管理するという経験を積んでいるところです。各チームが自分のプロジェクトの仕事だけでなく、プログラム全体の目標に対して明確なビジョンを持つことには、明らかに大きな恩恵があります。

　一番難しいのは、ベンダー、クライアント、スポンサー、その他ステークホルダーから賛同を得ることでしょう。技術プロジェクトをまとめるときには、彼らの関心、要求、ニーズを分析して、それぞれのプロジェクトにとって価値があることを確かめる必要があります。プログラムとしてまとめることで、プロジェクトを単独でやっていたときよりも大きな価値が得られなくてはなりません。

　特に顧客が複数の国にわたるときには、技術を生み出す方法、組織の手続きやプロセスについて、それぞれの顧客がみな異なる考えを持っているでしょう。プログラム目標に対するステークホルダー全員の調整をするためには、国際的に認められたプログラムマネジメントプラクティスへの合意と承認が欠かせません。

　手法をうまくそろえるには、すべてのプロジェクトで使える、共通だけれども柔軟性のあるドキュメントやテンプレートが必要になります。IT プログラムを管理するときには通常、独自の方法論とテンプレートをもったベンダーによる商品やサービス、あるいは、同時進行しているほかのプロジェクトの成果が必要になります。したがって、始める前にどのドキュメントを使うのか、すべての関係者で同意しておく必要があります。

　ここで使われるプロジェクトマネジメント手法はどんなものですか？　もし、方法論、手続き、プロセス、統合された変更管理手順について、個々のプロジェクトチームが同意できなければ、プロジェクトの共同開発は円滑にいかないでしょう。これらを選ぶとき、プロジェクトマネジャーはプロジェクトを効率よく実行しコントロールするのにどのテンプレートやプラクティスが妥当であり有用であるのか、チームに尋ねなくてはなりません。

　共通のプロセスとドキュメント / テンプレートといったツールがそろえば、あなたは技術プロジェクトをひとつのプログラムにまとめることができます。こうすることで、単独のプロジェクトでできることよりも大きな価値を顧客や組織に対して提供できるでしょう。

【41】現実を考慮して計画する

クレイグ・レタベック（Craig Letavec）PMP、PgMP、MSP

アメリカ、オハイオ州ウェインズヴィル

　どれだけ多くのソフトウェアプロジェクトが納期に遅れ、予算を超過し、低品質であるかは驚くばかりです。国際的な認証と成熟度評価を得ていると大々的にうたっているソフトウェア会社ですら、ソフトウェア開発をとりまく非常に不安定な環境をうまく管理するためには、幾多の試練を乗り越えなくてはなりません。

　プロジェクトの開発進捗は絶えず変化します。当初のスケジュールよりも早く進むこともあれば、もちろん遅れることもあります。たいていの場合、プロジェクト・マネジャーはこの変動を、正確かつ精巧なプロジェクトタイムライン（タスク割り当てと締め切り期日をあらかじめ定めたもの）によってコントロールしようとします。しかし、ソフトウェアを作るという動的な性質に対処するために、途中で計画を何度も改訂することになります。

　細部にわたって抜け目なく見積もったプロジェクト計画を策定して実行することは、プロジェクトを成功させるために重要なことなのですが、多くのプロジェクト・マネジャーは計画に「現実時間」を加味するのが有効であることに気づいています。

　クリティカルチェーン法では、ソフトウェア開発ライフサイクルに特有の変動をうまく扱う手段として、「バッファ」という概念を使います。ソフトウェア開発ライフサイクルの各フェーズ（設計、実装、テストなど）に「バッファ時間」や「現実時間」を取り入れてみましょう。

　バッファ時間を使うと、大幅なスケジュール調整をする必要なく、各フェーズに柔軟性をもたせることができます。バッファ時間を各フェーズにおける不確実性だと考えるのです。やり方は非常に簡単です。プロジェクトの各フェーズについて、まずは最善の計画に基づいた期間を検討します。それから、フェーズの最後に一定の割合、例えばフェーズ期間の 10% のバッファを追加するのです。

　例えば 40 日の設計フェーズの場合、最後に 4 日のバッファ時間を追加して、全体で 44 日のフェーズにするのです。実際のところ、このフェーズには 44 日かかるのでしょうか？　おそらくはかからないでしょう。「未使用」時間は繰り越してもよいですし、後方にあるバッファに追加しても構いません。

　経験豊かなプロジェクト・マネジャーならみんな知っているように、プロジェクトの初期は予定通りに進むかもしれませんが、後半になると結局は遅れていくものです。進捗のカーブよりも先手を打っておく方が、ほとんどの場合得策です。

　初めてこのアプローチを試すときには懐疑的な態度をとりましょう。「非生産的」な時間というのは、マネジャーがスケジュールをレビューするときに最初に取り除きたくなるものです。地に足をつけてください。基本的なスケジュールリスク管理を実践しているのだと単純に考えるのです。

　ほかよりもリスクの高いフェーズがあれば、そこにはさらにバッファを追加しておきましょう。代わりに、ほかのバッファを減らしてもよいでしょう。

　最後に、「二重取り」していないことを確かめましょう。二重取りとは、タスクレベルに余分な時間を追加しているのに、フェーズレベルにも余分な時間を追加することを指しています。あなたが未知なものを扱うときに、いつも当たり前のように余分な時間を加味してタスク期間にバッファを追加しているなら、このテクニックはうまく機能しません。

　さあ試してみましょう。うまくいくはずです。

【42】完全な実行という誤った考え

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　頑張れば欠陥の少ないコードが作れるんだと思っていても、恥じる必要はありません。ほとんどの人がそう思っています。しかし残念ながら、それは不可能です。理論的にも不可能なのです。

　プログラムロジックのような任意性の高い論理（任意の論理）は一般的に検証困難であり、完全にテストすることは困難もしくは不可能です。最近、英国の 3 人の研究者が建築関係で使われる「れんが」と「はり」のたとえ話を引用しながら、ソフトウェアは検証困難であることを説明しました。「（ソフトウェアには）十分に予測可能な構成要素がなく、プログラムを構成する要素、文、手続き、オブジェクトなどは予測可能な方法では組み立てられない」ためです。

　ソフトウェアの構成要素は、レゴのようにぴったりかみ合うものではありません。ソフトウェアは非常にさまざまな方法で組み立てられます。したがって、すべての組み合わせを決定することはできません。これはチューリング完全のそこそこ実用的な定義かもしれません。要するにソフトウェアは複雑なのです。

　コードにおける任意の論理を追跡、検証すると聞くと難解に思うかもしれませんが、プログラマの意図を追跡するというもっと単純な作業ならどうでしょう？　確かに私たちはプログラマと話をして、彼らの意図することを尋ねることができます。ところが残念なことに、プログラマの意図というのはコードを書いてから数日のうちに失われてしまいます。要求が変わったり、ドキュメントに矛盾がある場合にはなおさらです。

　またプログラマは、ドキュメントのないコードやドキュメントに間違いのあるコードを残して、別の仕事に取りかかります。そうなると、残されたソースコードだけがプログラマの意図を探る最後かつ唯一の手掛かりとなります。結局のところ、プログラマの意図は、変数名やロジックフロー、たまにあるコメントといった手掛かりから、不完全ながらも判明するだけです。

　おそらくほぼすべての出荷済みのソフトウェア製品には、必ずどこかにバグが残っています。私たちがソフトウェアにバグを入れてしまう理由には、ひどいものもあれば（言語機能についての無知や細部への注意不足など）と正当なもの（矛盾していたり間違って伝えられた要件など）もあります。さらに、バグはソフトウェアの変更理由にもなります。バグが見つかると、そのバグを修正するためにコードをリファクタリングしますが、その過程でまた新たなバグが入ってしまうのです。

　1969 年にメイア・マニー・リーマンは、ソフトウェアがそのライフサイクルにおいて進化することに気づきました。彼はのちに、ソフトウェア開発には複数のフィードバックループが存在し、それらフィードバックループが進化のプロセスに影響を及ぼすことを解明しました。そこには複数の（おそらく矛盾のある）要件や設計判断が入ることも含まれます。

　要件や設計の判断、実装詳細に関するプログラマの理解度は、ほかのフィードバックループにも影響を与えます。すなわち、バグの原因は論理的なプロブラミングエラーとは限らないということです。意見の食い違いからもバグは入り込む可能性があります。

　「完全な実行」という誤った考えとは、細部に十分注意していれば欠陥の少ないコードが作れるという妄想のことです。これが正しければ、私たちはみんな構造化プログラミングの絶大な支持者になっていたでしょう。私たちはそうではありませんし、それには正当な理由があります。進化のいかなる段階においても、ソフトウェアはバグを抱えており、絶えず変化し、不正確なドキュメントがあるものなのです。

　このような見方をすることで、単純かもしれませんが、これまでとは異なるソフトウェアへの取り組みが必要であることがわかります。ソフトウェアの実装、要件、ドキュメントをインクリメンタルにリファクタリングするためのツールやテクニックの開発が求められているのです。

【43】アジャイルなコミュニケーションシステムを導入する

ブライアン・サムボッデン（Brian Sam-Bodden）

アメリカ、アリゾナ州スコッツデール

　失敗したプロジェクトのふりかえりをすると、プロジェクト・マネジャー、チームメンバー、ステークホルダー間のコミュニケーション断絶を非難することに終始するものです。プロジェクト・マネジャーはチームメンバー間のコミュニケーション断絶を軽減し、絶えず効果的にコミュニケーションをとるよう教わります。ところが、プロジェクト・マネジャーはこの責任の重みに過剰に反応してしまうことがあります。必要不可欠なコミュニケーションと、プロジェクトの進行に悪影響を及ぼすノイズだらけのコミュニケーションとを混同してしまうのです。

　こうした問題を解決しようと、ソフトウェア開発の取り組みは柔軟でアジャイルなプロセスへと向かっています。アジャイル開発手法にとって重要なのは、予測不能な変更にチームが効果的に対応して、プロジェクトのフィーチャーを見直し、優先順位づけをやり直せるような、タイムリーなコミュニケーションループが存在することです。

　アジャイルなプロジェクト・マネジャーは、どうやってコミュニケーションを必要不可欠なものだけに絞るのでしょうか？　彼らは毎日の「15 分スタンドアップ」ミーティングを推進しています。このミーティングでは開発者に、前回のミーティングから達成したこと、「今日」達成しようとしていること、それを達成するために想定される障害について説明させます。このスタンドアップミーティングでリスクになるのは、開発者の自己評価だけを頼りにしているところです。これに解決策はあるのでしょうか？　スタンドアップミーティングをさらに効果的にするために、各機能のテスト結果を表示できるようなタスク管理ツールを導入しましょう。実際のコードがどんな状態にあるのか、ツールはウソをつきませんし、テスト結果は開発者の自己評価のよい補強材料にもなります。機能とそれがパスしたテストセットを対応づけたレポートを提示すると、その機能の現状がより正確にわかってよいでしょう。

　例えば、継続的インテグレーションツールの結果を見ると、客観的な進捗状況を知ることができます。こうしたツールを利用することで、スタンドアップミーティングにおけるコミュニケーションを必要不可欠なものだけに減らせます。すなわち、エッジケース、インテグレーション課題、バグや欠陥による障害報告（うまくいけば、タスク管理ツールによって記録済み）および想定外の開発項目といったものだけに絞れるのです。全員が共有してアクセスできるツールを使って開発状況の「証拠開示」をすることによって、開発者はより精度の高いフィードバックを得ることができます。フィーチャーとタスクの間にある見えない関係が早期に見つかることも多々あります。

　同期コミュニケーションは常に非同期コミュニケーションよりも効果的だとよく誤解されていますが、適切な開発ツールと短期の非同期コミュニケーションループを加えると、対面の同期コミュニケーションを効果的に補完することができます。

　一般的なフィードバックには Wiki が使えます。Wiki を使うと、開発の進捗状況に合わせて、プロジェクトのビジョンを簡単に調整していくことができます。また、Wiki のようなシステムを使うことで、情報をタイムリーに入手でき、機能開発の進捗を妨げている技術詳細に関心のないステークホルダーに対しても、ハイレベルなコミュニケーションチャンネルを提供することができます。一方、ソフトウェア開発者は日々の技術的作業をこなしていくうちに、プロジェクト全体に関するビジョンがあいまいになっていきます。Wiki はプロジェクト参加者全員に明確な共有されたビジョンをもたせるのにも効果的な方法となります。

　プロジェクト・マネジャーは、いかにして情報のループを緊密にノイズなく保つかという問題に取り組むことによって、プロジェクトが失敗したときによく非難されるコミュニケーション断絶という問題を避けることができます。プロジェクト・マネジャーに課せられた責任と課題は、プロジェクトのあらゆるレベルにおいてフィードバックループを整備することなのです。

【44】方法論を崇拝しない

ファビオ・テイセイラ・デ・メロ（Fabio Teixeira de Melo）PMP

メキシコ、ベラクルス州コートザコアルコス

　多くのプロジェクト・マネジャーは方法論にしたがうことに注力しすぎです。これはプロジェクトをうまくやり遂げる妨げになります。もし前の職場で何らかの手法を使っていたり、学校で方法論を学んだり、その認定資格を取得したところであれば、教科書に書いてあるすべてのプロセスとドキュメントを厳密に定めて、教えられたのとまったく同じようにやりたくなるかもしれません。しかし、これには次のような危険な落とし穴があります。

必要な労力：参考書に載っているプロセスをすべて完全にやるのは、チームメンバー全員に多大な管理作業を課すことになるかもしれません。あなたはそれに必要な時間と予算見積りについて本当によく検討しましたか？　手順を完璧に整備するのに時間をかけたせいで、プロジェクトがうまくいかなかったというのは、あなたの望みではないはずです。

企業文化との整合：あなたのチームはその特殊なプロセスにどれだけ馴染みがありますか？　チームメンバーをトレーニングする必要はありますか？　トレーニング費用は予算計上されていますか？　みんな関心をもってくれていますか？　あなたが対応する必要のある職務マネジャーや他部門についてはどうでしょうか？　そのプロセスは公式もしくは非公式に定められた会社のプロセスや習慣と矛盾していませんか？　もし矛盾があると、プロジェクトにとってリスクになるおそれがあります。

プロジェクトのフォーカス：プロジェクト・マネジャーにとっての重点項目は、プロジェクトを成功裏に完了することであるべきです。ソフトウェアプロジェクトの場合、これは主にソフトウェアを納品することになるでしょう。あなたが駆使するプロジェクトマネジメント知識はすべて、手段であって目的ではありません。また、あなたのチームは当然のごとく、プロジェクト・マネジャーが重点を置いていることに重点を置きます。もしあなたがプロセスを完全に規定し順守することに重点を置いていれば、それがチームのフォーカスになってしまいます。そうなると、だれがソフトウェアを作るのでしょうか？

仮想的、地理的に分散したチーム：もしチームメンバー全員が同じ場所にいないなら、必須の手続きを設定して強制的に守らせるのは、相当困難になるでしょう。ハードウェアやソフトウェア、その他の技術を、あなたの要求にしたがわせるのは困難あるいは不可能かもしれません。プロジェクトとして必要な製品やサービスを離れたチームに納品させるときには、あまり多くを期待しないようにしましょう。

　結局のところ、あなたの良識以上に重要で順守すべきだと思えるプロジェクトマネジメント本や方法論などは存在しないのです。あなたはまず、製品分析、契約分析、リスク分析のために、主要なステークホルダー（クライアントやスポンサー）とのインタビューをやるべきです。それからプロジェクトマネジメント戦略について検討し選択しましょう。

　自分自身のために「私はこのような方法でプロジェクトを管理するつもりです。なぜなら……」といったドキュメントを書いておきましょう。これは根本的な判断理由が変化したときに、マネジメント戦略を調整するのに役立ちます。プロジェクトのニーズに基づいて、一番重要できちんと実施すべきプロセスは何なのか、もっと軽いやり方が適しているプロセスはどれなのか、判断しましょう。結局のところ、すぐれたプロジェクトマネジメント計画は効果的でシンプルであること、それがすべてなのです。

【45】人的問題にスプレッドシートを持ち込まない

アヌパム・クンドゥ（Anupam Kundu）

アメリカ、ニューヨーク州ニューヨーク

　あなたはこれまでに、プロジェクトにおける自分の仕事を説明するために、一連のアクティビティが書かれたスプレッドシートを見せたことはありますか？　多くの経験豊かなマネジャーがスプレッドシートをプロジェクト管理・監督のための「銀の弾丸」として使おうとしています。

　トムについてお話しましょう。トムはある大企業のオンライン部門の IT 開発アーキテクトです。彼には 4 つ以上のステークホルダーがいました。トムは各ステークホルダーに対する成果物をうまく優先順位づけできていなかったため、結局毎週どこかのステークホルダーをイライラさせたり、がっかりさせていました。トムには果たすべきコミットメントがたくさんあるのに、手元のリソースが少なすぎました。そのためトムはいつも、それによって生じるステークホルダー間の争いの渦中にいました。

　トムと彼のチームは有能な IT アーキテクトなのですが、ステークホルダーの期待をうまく果たすのに必要な時間とスキルセットが足らなかったため、オンライン部門にいる全員に影響を及ぼしていました。何か解決策はあるでしょうか？　訓練を受けたプロジェクト・マネジャーを迎え入れましょう。そして、トムと彼のチームの成果物を、毎週、毎月、あるいは 3 ヶ月ごとに優先順位づけし、一覧表にするのです。

　成果物を優先順位づけすることで、プロジェクト・マネジャーはステークホルダーとの議論をうまく運べるようになります。この優先順位は内部の顧客全員によって評価されます。こうすると、ステークホルダーが期待を正しく抱けるだけでなく、トムと彼のチームもタスクリストを頻繁に更新して、その週の検討課題のうち最も重要なアイテムの開発に集中できるのです。

　こうした計画を効果的にやる秘訣は、各プロジェクトごとの成果物リストにスプレッドシートを使うのをやめることです。その代わりに、プロジェクト・マネジャーがステークホルダーの期待を設定しましょう。トムが自由に使えるリソース（時間、お金、人）を考慮しながら、ステークホルダーも巻き込んで、どのフィーチャーや機能が最も重要 / 価値がある / 収益をもたらすかを優先順位づけするのです。そして各グループは、その週に期待していたことがどれだけうまくいったか、オンライン部門のほかのニーズも考慮しつつ、フィードバックを得るのです。チームの仕事を計画するとき、特に複数のプロジェクトに優先順位をつけなければならないときには、コミュニケーションが最も有効な手段となります。

　おそらくトムのチームには、過去のプロジェクトで、ステークホルダーの誰かとうまくいかなかった経験があるでしょう。このアプローチを使えば「ブラックリスト入りした」チームでも期日までに仕事を完了させることができ、さらに積極的にコミュニケーションをとることによって、過去の傷跡を癒やせるはずです。

　結局のところ、プロジェクトマネジメントとは人を管理すること、そして人がかかわるプロセスを管理することです。チーム内や張り合っている組織間では、人間関係が衝突することがよくあります。考え方、目標、価値、信念、ニーズには多様性があります。これはチームの強みであって、弱みではありません。とはいえ、個人的な衝突や、チーム内のワークフローの優先順位における衝突は避けられないことです。

　たいていの場合、こうした衝突は生産性や効率に対する脅威となります。それをうまく解決することは、現場の関係を強化し、創造力に富んだ変化をうながし、結果を改善します。あらゆる競合を解決するのは、積極的なコミュニケーション、積極的傾聴、思いやりのある理解、効果的な交渉あるいは調停です。熟練したプロジェクト・マネジャーが必要とされています。なぜなら、スプレッドシートでは人的問題を解決できないためです。

【46】ひとつの成果物にひとりの責任者

アラン・グリーンブラット（Alan Greenblatt）

アメリカ、マサチューセッツ州サドベリー

　すべての成果物にはその完成に責任をもつ人が一人いるべきです。各アイテムの完成にだれが責任をもっているのか、プロジェクトに取り組んでいる全員が明確に理解するべきです。そのアイテムの実際の開発には複数の人がかかわっているかもしれませんが、それを時間通りに確実に完成させ、そのアイテムにある技術的問題について理解する最終責任は、ひとりの人に関係づけられているべきです。

　たいていの場合、特に高度に政治的な環境においては、責任は共有されるものです。プロジェクトの開始時で、まだはっきりしないところがあるときは特にそうです。人は派手に目立ち、成功することがわかっているアイテムに責任をもちたがるものです。失敗することが確実にわかっているものに責任をもちたがる人はいません。プロジェクトの開始時に責任が共有されるのは、成果物やそれに伴うリスクが十分理解されていないためです。実際のところ、はっきりしないタスクに力を注いで、責任を負いたいという人などいないのです。

　成果物に非常にうまみがあるため、そのアイテムに責任を負いたいという人が最終的に複数現れるときもあります。このような場合、マネジメントは波風を立てたくないので、ほかの人が怒らないよう、だれかひとりに明確に責任を割り当てないで済ませようとします。しかしこれは、将来もっと大きな問題になるよう御膳立てをしているようなものです。

　ひとつの成果物にひとりの責任者を置くとよいことがあります。第一に、成果物に関連した問題があると、その最終責任者はチームに早く問題を伝えるようになります。自分に責任があることがわかっているためです。時間的に厳しいとき、自分に責任がないものは他の人がなんとかしてくれると思いがちです。こうして問題は無視されていきます。結局のところ、プロジェクト・マネジャーであるあなたが、そのリスクを抱えることになるのです。

　第二に、プロジェクトの進行中、チームメンバー全員、特に新規参加者が、その問題についてだれに聞けばよいのか、非常に効率よくかつ正確に知ることができます。何か質問があれば、それにふさわしい相手、その話題に関する専門家に質問したいでしょう。もしその専門家が答えられなくても、責任者として何とかして回答を用意してくれるはずです。自分がよく理解していないことに対する回答が必要なときには、自分の時間を費やすべきではありません。

　最後に、プロジェクトは期待通りに完了しないこともあります（よくあることです）。もしだれにも行動（あるいは何もしないこと）に責任がないとすると、あなたは問題を修正できず、グループダイナミクスも損なわれます。問題のあるあいまいな作業について、だれの責任なのかを決めるようなムダな時間ほど、チームのパフォーマンスを損なうものはありません。

　しかし、成果物ごとに責任者を割り当てることを、責任を追及するための手段にしてはいけません。そうではなく、責任をうまく分散するための手段にしましょう。また、成果物が早期に予算以下で（少なくとも期限内に予算内で）できたとき、だれが賞賛を受けるに値するかが明確になります。それはよいことです。

【47】完全な知識という誤った考え

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　私たちはみな心の奥底では、すべてを知っているわけではないことを知っています。うまくいけば、私たちは毎日少しずつ、自分の専門分野や社会、自分自身について学んでいきますが、それでもすべてを知ることは到底不可能です。しかし、学ぶのをやめてしまうと、すぐに落ちこぼれてしまいます。ソフトウェア業界では特にそうです。そうなったら残りの人生、別の職業や他の仕事に弟子入りすればよいと考えているなら、あなたはドードー鳥と同じ運命をたどってしまいます。

　今の私たちの時代、土台としているテクノロジー、テクニック、アイデアはあまりに急速に変化します。私たちは絶えず学ばなくてはなりません。また同様に、私たちは無知にも対応しなければなりません。必要な知識を調査するために、プロジェクトの一部を費やす必要があるのです。それなのに、なぜ私たちは、開発フェーズにおいてプロジェクトに関するすべてを知る必要がある、あるいは、知ることができると偽り続けるのでしょうか？

　ソフトウェア工学の歴史とは、ソフトウェアが品質欠陥によって失敗しないように、注意深く統制された開発工程および保守作業により、プロジェクトをいかにコントロールするか、という試みの歴史でもあります。伝統的な「ウォーターフォール」型などの方法論の多くは、十分な時間と実直な勤勉さがあれば、ソフトウェアプロジェクトは完全に理解可能だと仮定しています。ここでは、たいていの場合、コードを書く前に要件が確定されていることを要求しています。なんてばかばかしいことでしょう！

　開発中にすべてを知ろうと思わずに、後になればすべてがわかると考えることもできます。スパイラルやアジャイルといったソフトウェア開発方法論はそう仮定しています。そこでは「最終的に確認された」要件に基づいてソフトウェアを開発し、納品するために、イテレーティブな開発が重要だと考えています。残念ながら、こうした方法論の支持者にとって、ソフトウェアプロジェクトの納品は開発の区切りにすぎず、完了を意味するものではありません。

　事前の詳細設計によって「合意」されていたとしても、要求は開発中に変化するものです。前もってすべてを知ることは不可能なのです。複数の要求が矛盾していることもよくあります。たとえ情報源がひとつしかなくてもそうなのです。人によって同じ要求が別のものを意味していることもあります。それぞれ解釈が異なるのは、見識や目標、言語が異なるためかもしれません。ソフトウェアプロジェクトを成功させるためには、こうした考え方を受け入れて、さらには喜んで応じなくてはなりません。私たちはすべてを知りませんし、決して知ることもできないでしょう。

　完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。現実には、ソフトウェアプロジェクトのライフサイクルのいかなる時点においても、要求が完全にわかることはありません。分析フェーズ、開発フェーズ、保守フェーズ、システムがレガシーであるときですらそうなのです。

　イテレーションやリファクタリングといったアジャイルテクニックをソフトウェア開発ライフサイクルの保守フェーズにおいて継続的に活用することで、いくつかの懸念は解消されていきます。ソフトウェアがどのように進化するのか、もっと理解することが次のステップになります。このような概念的なツールを手に入れて、それらを日々活用し、規模を問わず無知を受け入れましょう。そうしない限り、私たちには完全な知識という誤った考えの犠牲になり続けるでしょう。

【48】スプリントでなくマラソンのためのチームづくり

ナレシュ・ジャイン（Naresh Jain）

インド、ムンバイ市マラド

　短時間に最速のペース（陸上用語で「スプリント」）で走ると、あなたは燃え尽きてしまいます。マラソンを走るためには規律よく、毎日練習して、持続可能なペースを保たなくてはいけません。ソフトウェアプロジェクトに取り組むときも、一度走っただけで疲れてはいけません。私たちは一定のペースで進み続ける必要があります。持続可能なチームは、スプリントができるのではなく、マラソンを走れるように調整されています。

　有用なソフトウェア製品を作ることが私たちのゴールではありません。チームメンバーがお互いに助け合い、他のチームメンバーが本当の潜在力を発揮できるよう助け、全員が自らの限界を超えることができる環境を作る必要があります。

　ほとんどのチームには、この事実が共有されていません。だれかがこの環境づくりで積極的な役割を果たさなければなりません。たいていの場合、プロジェクト・マネジャーがチームづくりを推進することになります。プロジェクト・マネジャーは持続可能なチームを作ることを目標に掲げるべきです。これはプロジェクトに特別な付加価値を与える一番の手段になるでしょう。

　プロジェクト・マネジャーがチームづくりと個人の成長に注力すると、成果物はおのずと期限内に予算内でうまくでき上がるようになります。また、プロジェクト・マネジャーが同時に複数のプロジェクトを見なくてはならなくなっても、チームは自己組織化しているので、もはやベビーシッターは不要でしょう。

　通常、プロジェクト・マネジャーは日々の消火活動に忙殺されます。そのため戦略的にチームづくりをする時間は実際のところありません。最終的に長期的なチームづくりの計画を立てて取り組むことで、プロジェクト・マネジャーは現在のプロジェクトはもちろん、将来のあらゆる活動においても、マイクロマネジメントを避けることができます。

　私たちはソフトウェアプロジェクトにおけるマネジメントプラクティスのフォーカスを抜本的に変える必要があります。プロジェクト・マネジャーはもっと戦略的な役割を担うのです。戦術的なことはプログラミングチームに任せましょう。チームはプロジェクトを自分のものとして考えるようになり、プロジェクト・マネジャーは物事がプロジェクト全体にとって正しい方向に進んでいるかを確かめる真のファシリテーターや触媒になるのです。

　ジョージ・スミス・パットン将軍はこう言いました。「どんな戦術も眼前の敵には無力だ」　このことは、プロジェクト・マネジャーは今日一日のコーディングやアーキテクチャ判断にかかわるのではなく、チームが予期せぬ変化に対応できるようになるのにもっと時間をかける必要がある、ということを意味しています。自分にはプログラミング経験がないのに、ソフトウェア開発の複雑さをわかっていると、みんなに思い込ませることができると思っているなら、それは愚かなことです。プロジェクト・マネジャーが全然わかっていないということは、みんなにはすぐにばれてしまいます。

　プロジェクト・マネジャーは OS のカーネルのようなものです。カーネルそのものがエンドユーザーのタスクを処理するわけではありませんが、カーネル上にあるアプリケーションによってエンドユーザーのタスクが正しく完了されることを保証します。これと同じように、プロジェクト・マネジャーはチームメンバー間の最適なコラボレーションを保証する真のファシリテーターやコーチになりましょう。そうすれば、マラソンを走れるような自己組織化したチームを作ることができます。高品質なソフトウェアを届けることは、もはや問題にはならないはずです。

【49】プロジェクトマネジメントの三位一体

ポール・ワゴナー（Paul Waggoner）MBA、PMP、MCSE、CHP、CHSS

アメリカ、アイオワ州ウォーキー

　プロジェクト・マネジャーが新しいプロジェクトを開始するときには、各チーム・メンバーが果たすべき役割を定義します。それぞれのスキルが必要不可欠である理由とそれぞれが果たすべき一般的な義務について、ドキュメント化しておきます。しかし、こうしたドキュメントには、プロジェクトライフサイクルにおけるプロジェクト・マネジャーの役割はあまり説明されていません。

　プロジェクト・マネジャーにとって、特に新しいチームと仕事をするときに課題となるのは、方法論に深入りすることなく、30 分でプロジェクトマネジメントの要点を伝えることです。

　最優先事項が割り当てられた作業をこなすことであるような、多忙な組織やチームメンバーと仕事をするとき、プロジェクト・マネジャーとしてのあなたの課題は、チームメンバーがミーティングの効果を損なわないよう、大事なポイントをできるだけ簡潔に伝えることです。そのポイントは「三位一体」と呼ばれ、「3 つの制約」としても知られています。

　この基本概念をチームに導入するため、「3 つの制約」を説明したスライドを準備しましょう。これは 3 つの頂点に時間、コスト、スコープというラベルをつけた正三角形になります。中央にはスペースができますが、これがプロジェクトの品質を表します。この図はプロジェクト作業を幾何学的に表現したもので、三辺のどれか一辺が長くなると、少なくとも三角形のもう一辺もそれに合わせて変更しなければならないことを示しています。また、そうした変更はプロジェクトの品質にも影響を及ぼすことがわかります。

　この「3 つの制約」に含まれる関係は、なぜ最初にスコープを定義することが必要不可欠であり、同時に大きな制約になるのかを説明しています。組織のプロジェクトマネジメント成熟度、あなたが指揮するプロジェクトのタイプ、プロジェクトマネジメントの取り組み成熟度、顧客との過去の経験によって、それぞれ異なる重要ポイントがあるかもしれませんが、以下がカバーできているか確かめましょう。

チームメンバーの個人的参加の重要性。これにはプロジェクト計画の策定支援も含まれます。

プロジェクトのリスク。何がリスクなのか、リスクの識別方法、リスクの回避策、軽減策、対処策の作成および監視方法。

各チームメンバーが完了すべき仕事を定義するために必要となるタスク分割。

タスク割り当て、完了予定日、チーム全体におけるタスクの相互依存性、仕事が完了したか適宜フォローアップして確認するプロジェクト・マネジャーの役割。

起こり得るタスク完了遅延、タスクを時間通りに完了するための障害、障害を取り除くことを支援するプロジェクト・マネジャーの役割。

コミュニケーション計画、チームメンバーのコミュニケーション義務、詳細計画を中心となって調整するプロジェクト・マネジャーの役割。

プロジェクトのステータスミーティングの責務およびスケジュール。

プロジェクト計画を明らかにするときに、プロジェクト・マネジャーとして実行する次ステップの概要。

　すでに「成熟した」プロジェクト指向のビジネス組織である場合を除いて、プロジェクトの開始時に基本的なプロジェクト・マネジャーの考え方について説明することは、チームメンバーが自らに課せられた義務と受けられる支援について十分理解するために極めて重要になります。これにはプロジェクト・マネジャーとしてのあなたの役割を定めることも含まれます。

【50】ロードマップを作ろう

キャシー・マクドゥガル（Kathy MacDougall）

アメリカ、コロラド州エリー

　プロジェクトチームの内外において、すぐれたコミュニケーションがあることはプロジェクト成功の重要な要素となります。あらゆるプロジェクトにとって重要なコミュニケーションツールは、公式のプロジェクトロードマップです。プロジェクト計画は、プロジェクトチームがタスクレベルの変更に対してどう対応するのかを決めるのに役立つものです。これに対してプロジェクトロードマップは、広範囲のステークホルダーたちがハイレベルで起きている変化を理解するためのものです。プロジェクトロードマップは、計画的な変更、具体的な変更のタイムフレーム、そしてこれらの変更がビジネスに与える影響を伝えるのに役立ちます。

　それでは、どのようにしてロードマップを作ればよいのでしょうか？　まず最初に、最上位のステークホルダーからインプットを得ましょう。彼らにとって、どのフィーチャーが重要なのでしょうか？　各フィーチャーの優先順位はどうでしょうか？　ビジネス面から見て、いつまでにどのフィーチャーを用意することが重要なのでしょうか？　顧客の声を集めましょう。それがロードマップのドラフト作りの基礎となります。

　それではロードマップのドラフトを作りましょう。これは現実的なタイムフレーム（通常は 3 か月ごとがよいでしょう）でまとめたハイレベルなフィーチャーリストになります。ロードマップには各フィーチャーに関するビジネス価値（例えば、注文に要する時間を 2 分まで削減する、注文に要するコストを 10 ドルまで削減する）を書いておきます。もしビジネス価値が書けなければ、そのフィーチャーを入れることの妥当性について疑問をもつべきです。つまり、具体的なビジネス価値のないアイテムはロードマップに現れるべきではないのです。そうしたアイテムは投資対効果分析という形で、さらなる精査が必要になります。

　うまくドラフトができたら、プロジェクトにとって重要な幹部スポンサーとステークホルダーからフィードバックを得ましょう。ステークホルダーがさらなる明確化を要求したり、優先順位について懸念を表明したり、ロードマップから漏れているアイテムについて注意喚起できるよう、議論のためのライブフォーラムを用意しましょう。率直な議論をすることによって、プロジェクトに対する理解が得られます。そして、ロードマップがステークホルダーの優先順位に合っていることを確かめることができるのです。彼らから受け取ったインプットにしたがって、ドラフトを調整していきましょう。理想的には、このステップが完了すると、すべての重要なステークホルダーが納得するロードマップができあがります。

　最後に、大きな声でそれを読み上げてください。ロードマップをプロジェクトの Web サイトの目立つところに貼って、ほかのステークホルダーたちにも見せるのです。ロードマップをプロジェクトのための主要なコミュニケーションツールとして使いましょう。プロジェクトが順調に進んでいるか確認するため、3 か月ごとにロードマップをレビューしましょう。何がすでに完了していて、次の 3 か月で何ができるようになるのか、ステークホルダーと話をしましょう。もしプロジェクト遅延のためにロードマップを見直す必要があるなら、ドラフト段階にまで立ち戻って、もう一度やり直してください。そして、新しく改訂した計画を関係者全員に伝えましょう。

　プロジェクトのロードマップを作ることによって、ステークホルダーに発言権を与えるとともに、彼らが期待しているものを自覚させることができます。そして、大事なことを言い残していましたが、ロードマップはあなたのチームがこれまでの 3 か月で何を実現してきたか、他人に伝えるための確実な方法にもなるのです。

【51】プロジェクトスコープ記述書の重要性

キム・ヘルドマン（Kim Heldman）

アメリカ、コロラド州レイクウッド

　プロジェクト計画が堅実なプロジェクトマネジメント方法論の骨格だとすると、プロジェクトスコープ記述書は中枢です。スコープ記述書はプロジェクトのビジョンを詳しく述べたものです。ここには、目標と成果物、プロジェクトの成功がどのように評価されるのかを記述します。

　残念なことに、ほとんどのステークホルダーはスコープ記述書を書くことにあまり関心がありません。それどころか、時間をかけて包括的なスコープ記述書を作っても、ほとんどは署名も乾かないうちに保管して、二度と見ることがないのです。顧客が期待していることが実現できているか確かめるには、プロジェクトを通してスコープ記述書で絶えず確認することが重要です。

　私が自分の顧客によく使う、お気に入りのたとえ話があります。それはリフォームについてです。地下室の仕上げに業者を雇うことを想像してください。あなたはどんなレイアウトにするのか、業者に指示しますか、それとも業者に任せますか？

　確かに業者も部屋をどれくらいの大きさにすべきか、どこに配管があるのかなど、レイアウトについてある程度は考えているでしょう。しかし、あなたはベッドルームが 2 つ、スリークォーターサイズのお風呂、そして娯楽室がほしいと思っているのに、業者がベッドルームが 1 つ、フルサイズのお風呂、そして本格的なバー付きのファミリールームを作ったらどうしますか？　これはあなたが考えていたのとは全然違います。

　スコープ記述書の重要性は、まさにここにあります。スコープ記述書はプロジェクトの青写真です。ここにはプロジェクトの最終製品やサービスの特徴について記述されています。スコープ記述書がなければ、ステークホルダーがベッドルームを 2 つ期待しているのに、あなたは 1 つしか作らないかもしれません。スコープ記述書はステークホルダーの期待を管理するのにも役立ちます。私はこれまでに何度も、プロジェクトの局面で身動きがとれなくなったことがあります。プロトタイプフェーズになって初めて、「ベッドルームが 2 つできると思っていたのに」と言い出すステークホルダーが必ずいるものです。ここでスコープ記述書が助けになります。もちろん、これを武器のように振りかざすのはよくありませんが、プロジェクト開始時に立ち返って、ステークホルダーが合意したことをやさしく思い出させるのには、うってつけの方法です。

　ステークホルダーと一緒にスコープ記述書を定期的に見直すのはよいことです。ステータスミーティングやステアリングコミッティーミーティングといった場を使って、レビューするとよいでしょう。ミーティング 1 回おき、あるいはプロジェクトの大きさとスコープを考慮して適度な間隔で、スコープ記述書にある成果物をレビューする時間をとりましょう。

　もしステータスミーティングを定期的に実施していれば、すでにある程度はできているかもしれません。ステータスミーティングでは通常、この作業期間で実現した作業と次の作業期間で完了する予定の作業について取り上げます。ときには次の作業期間を超えて、プロジェクトで今後実現する予定の重要な成果物について、全員に思い出させる時間をとりましょう。

　プロジェクトスコープ記述書を定期的にレビューすることで、プロジェクトが成功するチャンスは高まり、ステークホルダーの期待とプロジェクトの目標とを絶えず一致させることができるのです。

【52】ビジョンと期待される成果に合わせる

デビッド・ディアス・カスティロ（David Diaz Castillo）MBA、PMP

パナマ、パナマシティ

　ソフトウェア開発プロジェクトは非常に難しいものです。というのもニーズと期待が必ずしも明確ではないためです。そのためプロジェクト・マネジャーの仕事は、以下を確実に実施することになります。

プロジェクトの主たる目的を明確にすること。

なぜこのプロジェクトをやるのか、全員が理解すること。

3 つの P（人（People）、プロセス（Process）、プラットフォーム（Platform））への影響を明確にすること。

ニーズと期待が要求ドキュメントに含まれていること。そして、何がスコープ内で、何がスコープ外かを判断して、チームに伝えること。

　チームメンバーをビジョンと期待される成果に合わせるため、プロジェクト・マネジャーは以下の 3 つの視点を使いこなす必要があります。

ビジネスの視点：どうしてこのプロジェクトが解決策になるのか？　（プロジェクトはどんな問題や機会を解決しようとしているのか、もしくは、組織にどのような価値をもたらすのか？）

SMART の視点：ソフトウェアは何をすべきなのか？　（具体的に（Specific）計測可能で（Measurable）、合意された（Agreed upon）、現実的な（Realistic）機能を時間制約（Time constraint）内で実現する）

主観的な視点：エンドユーザーはシステムに何を期待しているのか？　（開始フェーズで、エンドユーザーの期待と認識を獲得する）

　ポイント 1 ：開発チームとプロジェクト・マネジャーは実装が始まると、組織がプロジェクトに資金提供することにした本来の理由を忘れて、具体的機能やプロジェクトの技術的側面に注目してしまいがちです。チームは必ずしも解決すべき真のビジネス問題を念頭に置いているわけではないため、チームの判断には誤解や落とし穴、エラーが発生するおそれがあります。プロジェクトが組織にもたらすべき利益は、必ずしも最先端の技術や機能にあるとは限りません。こうした落とし穴に陥らないよう、プロジェクト・マネジャーはプロジェクトの目的、前提、制約、リスクを明確にする必要があります。

　ポイント 2：プロジェクトの技術的目標および機能的目標は、スポンサーも含めたチームメンバー全員が理解できるよう、明確でなければなりません。そしてその成果は、最終的にシステムのオーナーの戦略的ビジネス目標と一致している必要があります。

　ポイント 3：プロジェクト・マネジャーはエンドユーザーが何を期待しているか特定しなくてはなりません。彼らはこの新しいアプリケーションが日々の業務をどのように支援することを期待しているのでしょうか？　プロジェクト・マネジャーはエンドユーザーの利益と期待を明確に理解して、それを実現できるよう開発チームに正しく伝えなくてはなりません。これを明確にすることではじめて、プロジェクト・マネジャーはソフトウェア製品の現実的な最終ビジョンに基づいて、エンドユーザーにその長所を正確に伝え、彼らを支援することができるようになります。

　プロジェクトの目的や利点を細部にわたって理解していると、あなたは簡単にその場で的確な判断が下せるようになります。また、ユーザーが何を期待しているのか、システムが何のためにあるのかをプロジェクト・マネジャーが本当に理解していれば、効率よく変更管理提案を評価することができます。これはプロジェクト実行フェーズで間違った指示やズレが発生するのを防ぎます。

　私たちはプロジェクト・マネジャーとして、技術的なプロジェクト要求とプロジェクトが目的とするビジネス価値の両方を十分理解するよう、努力しなくてはなりません。それらを十分理解してようやく、プロジェクトライフサイクルを通じてすぐれたソフトウェアを生み出し、プロとして不確実性を管理する備えができあがるのです。

【53】アリスはもうここにはいない

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　近頃のソフトウェア開発者が議論の的にしているのは、最高のプログラミング言語、最高のシステムアーキテクチャ、最高の OS、最高のプロジェクト方法論といったものです。チームメンバーの「アリス」がもうこの場所にはいないことに、まだだれも気づいていないようです。アリスは今どこにいるのでしょうか？　これはソフトウェア開発計画にどんな影響を及ぼすのでしょうか？

　アリスはインドにいるのかもしれません。そこではみな英語をスペル通りに話すよう訓練されています。言語の障壁にひるむことなく最善の開発機会をアリスに与えるためには、時間的猶予を許したり、筆談を活用するとよいでしょう。

　アリスはアフリカにいるのかもしれません。そこでは技術者不足のため、雇用者にとってはプロジェクトよりも人材の方が重要かもしれません。使える技術に制限があるかもしれないので、24 時間のメール、電話、インターネット接続があることを想定してはいけません。

　アリスは新興国で恵まれた仕事を得ているのかもしれません。もし彼女がカンファレンスコールで即座に応答できていないようなら、あなたの話す言葉が彼女の耳に届くまでに、30 秒の衛星通信遅延があるのかもしれません。あなたも彼女の回答やコメントを聞くのに同じだけの遅延を感じるでしょう。

　日本のチームメンバーと仕事をするときには、意思決定の違いについて学んでおきましょう。日本人は年齢と経験を尊重します。彼らは若いアリスが遠慮なく話すのを、不快に思うかもしれません。また日本のチームメンバーは、ミーティングの議事録を残すのに、事前にコンセンサスをとることを期待するかもしれません。

　複数の離れた場所に複数のアリスがいる場合には、チームを円滑に機能させるために多数の小さな問題を、細心の注意を払って検討しておく必要があります。

アリスが働いているところの労働協約はどうなっていますか？　就業時間に違いはありますか？　残業や休日出勤、早朝出社、食事中や休憩時間中の勤務は可能でしょうか？

アリスのいる国の休日はいつですか？　あなたは全員の都合を考慮して、重要なグループミーティングの予定を立てなければなりません。米国の従業員に、クリスマスの朝に出社するよう頼みたくはないでしょう。

アリスがいる国の会計実務はどうなっていますか？　あなたの勤務報告はそこでの給与サイクルと合っていますか？

予期せぬデータ輸出規制はありませんか？　ヨーロッパにはデータ伝送に厳しい規制を課しているところがあります。あなたがアリスに情報を送れたとしても、アリスはあなたにデータを返せないかもしれません。

顧客サービスの慣習は国ごとに違うかもしれません。もしアリスが顧客と直接会うのであれば、チームのサービス基準や品質基準について彼女が理解しているか確かめておきましょう。

たとえボイスメールがなくてイライラしたとしても、人間がやっていた仕事が自動化によって機械に取られてしまうと感じる新興国があることに配慮しましょう。テクノロジーに関する文化の違いを感じたときには、それを尊重するようにしましょう。

アリスが毎週水曜日の朝 9 時からのミーティングを了承して、アリスがいるところでは真夜中なのに来てくれることを期待していませんか？　チームメンバー全員の意見を尊重して、全員が最も不快の少ないミーティング時間を見つけましょう。あるいは、その不快な時間を持ち回り制にしましょう。

　運がよいことに、私たちは遠隔地にいても、役割に応じたバーチャルなチーム編成をするだけの、すぐれた頭脳と洞察力に富んだ発想を持ち合わせています。この恩恵を尊重して活用しましょう。

監修者からのコメント：本コラムタイトルの原文は“Alice Doesn’t Live Here Anymore” で、1974 年公開マーティン・スコセッシ監督の『アリスの恋』という映画のタイトルを元にしています。平凡な主婦アリスは夫を事故で亡くし、ひとり息子と共に遠い故郷のモンタレーへと旅立つことになります。幼いころからの夢である歌手として日々の糧を得ようとするアリスですが、道中は多難続き。しかしさまざまな人と出会いながら自分の幸せを見つけるという物語です。
オフショア開発などで、地理的に離れたさまざまな国と仕事をすると、文化的な障壁など乗り越えるべき課題が数多く発生します。しかし相手国の文化や慣習を考慮に入れ、きちんと意思の疎通が図れれば、バーチャルなチームは必ずやプロジェクトを成功に導くことができるということを示したコラムです。

【54】契約紛争を避ける

ジョージ・ギルバート（Jorge Gelabert）PMP

アメリカ、コネチカット州ベルリン

　PMP（Project Management Professionals）® を取得しているプロジェクト・マネジャーなら、各種契約について詳しく知っているはずです。そして、どの契約のタイプを使うかは、対象とする製品やサービスはもちろんのこと、自分や売り手が想定するリスクレベルにも依存することを承知しているでしょう。しかし、知ってはいても、必ずしもうまくいくとは限りません。つまり、最善の契約があっても紛争が起こらない保証はない、ということです。

　明確に定義された要求を前提とすることは、衝突が起こるのを避ける確かな方法のひとつです。何が期待されているのかが明確に定義されているということは、何が成果物なのかに双方が合意できているということです。しかし、実際のところプロジェクトマネジメントの世界では、明確に定義された要求が常に存在するとは限りません。顧客からの不可避な変更要求を受け入れて、ビジネスを獲得するために失った利幅は後で取り返せばよいと、安値で仕事を受ける売り手（あなたの営業チーム）もいるかもしれません。プロジェクトに適正な値がつけられ、プロジェクトのスコープについて明確に定義された要求があるときですら、双方が解決しなければならない変更が発生するおそれがあります。結局どんな状況においても、こうした紛争が起こる可能性はあるのです。

　ではプロジェクト・マネジャーはどうすればよいのでしょう？　顧客は味方であって敵ではない、と考えてプロジェクトに取り組みましょう。売り手（あなた）と買い手（顧客）の双方がプロジェクトの成功に力を注いでいれば、たとえ意見の不一致が起こっても、簡単に平和的に解決できます。お互いが自分の関心に注力しすぎると、たとえ小さな意見の不一致であっても大きな紛争へと発展してしまい、プロジェクトは頓挫してしまうでしょう。

　意見の不一致が起こったときには、双方がともに勝者になれるよう解決に取り組んでください。たとえ契約上はあなたの方が正しくても、何とか折り合いをつけるのです。裁判所で自分の正当性を証明したくなるかもしれませんが、裁判で解決するまでのあいだ、両者の関係に対するダメージとプロジェクトの行き詰まりは、プロジェクトの最終的な成功に大きな影響を及ぼします。法的手段に出るしかない状況もあるかもしれませんが、それは最後の手段にすべきです。

　紛争が起こらないようにする一番の方法は、フェアな契約交渉をすることです。例えば、契約にペナルティがあるのなら、ボーナスも入れておきましょう。勝ち負けのチャンスが平等にあると双方が感じる必要があります。たとえ定額契約であったとしても、買い手（顧客）がプロジェクトを完了するよりも中止した方がましだと感じているようであれば、彼らと再交渉した方がよいかもしれません。

　また、話がうますぎると感じる値付けには気をつけましょう。あなたの営業チームがその場に居合わせていないのであれば、そのプロジェクトを完了させるのに何が必要なのか、買い手が十分理解できていないのかもしれません。自分たちが払いすぎだと気がつくと、再交渉しようとするか、さもなくば立ち去ってしまうでしょう。

【55】評価指標に基づいて行動する

ナレシュ・ジャイン（Naresh Jain）

インド、ムンバイ市マラド

　間違ったものを評価すると間違った行動につながることは、よく知られた事実です。マネジャーが間違った指標でソフトウェアチームを監視、評価すると、チームは日々苦しむことになります。

　例えば、マネジャーがどれだけの時間働いたかを評価すると、チームメンバーは長時間働こうとします。研究によると、長時間労働は必ずしもすぐれた結果を生み出すとは限りません。実際のところ、多くの場合、労働品質の低下をもたらします。

　同様に、マネジャーがチームのベロシティ（ある期間内にチームが完了する機能の量）を評価し、それに注目すると、チームは速く仕事を済ませようとします。しかし、チームが重要な / 必要な仕事を選んでいる保証はありません。したがって、これはソフトウェア開発をすばやくバグなしで完了させるという、真のビジネス問題を解決するものではありません。

　マネジャーがどれだけのバグをテスターが報告したかに注目すると、テスターはバグをたくさん報告しようとします。しかし、ビジネスに多大な影響を及ぼす問題について報告しているとは限りません。もし開発者がどれだけバグを申し立てられたかで評価されていると、テスターは開発者の敵になってしまうでしょう。これはチームに不要な緊張をもたらします。

　私の経験から言って、たくさんのソフトウェアをすばやく完了させることは、ソフトウェアの成功を意味するものではありません。ソフトウェアをすばやく開発することはフィードバックをすばやく得るためによいことですが、真の製品づくりには単なる開発スピード以外のものも必要になります。

　私は機能不全に陥っているチームをいくつも見てきましたが、ほとんどのチームが間違った指標でマネジャーから評価されていました。この状況だと、チームは間違った指標に合わせて最適化されてしまいます。プロジェクトの目的やビジョンが理解できていないと、各チームメンバーはばらばらな誤りのある指標に対して成功基準を自己定義し、自己評価するようになります。間違った評価基準というのは有害無益なのです。

　すぐれたプロジェクト・マネジャーは、成功が何を意味するのか、チーム全員が心から理解できるようにします。チーム内に共通のビジョンと共通の理解が築けるようサポートするのです。チームメンバーがお互いにプラスになる状況を作り出すことで、チームのコラボレーションが促進されます。これによりチームメンバーは共通の目標に向かって、一丸となって仕事を進めることができます。何を本当に評価すべきなのか、チーム全体として確認できるようにしましょう。プロジェクト成功の秘訣は、評価基準を成果物としてではなく、目的達成の手段として利用するところにあります。

　同時に 10 個もの異なる指標を評価しようとすると、チームは混乱して集中できなくなるでしょう。同時に評価する指標は 2 つか 3 つに留めるのが効果的です。この 2 つか 3 つの指標は、現在チームを苦しめている問題、もしくは近い将来影響を及ぼすとチームが感じているリスクに基づいて、チーム全員の総意によって決定されるべきです。

　問題が解決されたり、リスクが軽減されるにつれて、チームは古くなった項目を取り除いて、新しい項目を評価基準に追加すべきです。評価基準を定期的に変更していないチームは、大きな問題を抱えることになるでしょう。

　評価しているものが本当に意味のあるものか確かめましょう。そして、プロジェクトの期間中に、それを変更しても構わないことを知っておきましょう。人は評価されるものに基づいて行動します。したがって、正しいものを評価しているか絶えず確かめる必要があるのです。

【56】「自前主義」に陥るな

ポール・ギアンマルヴォ博士（Paul Giammalvo）CDT、CCE、MScPM

インドネシア、ジャカルタ

　プロジェクトマネジメントというのはプロセスの集まりにすぎません。それらが統合されて組み合わさったとき、プロセスの集まりは方法論になります。そして、こうしたプロセス / 方法論はほとんど何にでも応用できます。

プロジェクトマネジメントに関連して、5 つのプロセス群があります。

立ち上げ：プロジェクトの存在を許可あるいは認識するプロセス。

計画：何をする必要があるのか、どのように取り組むのかを特定するプロセス。

実行：結果を得るために、計画フェーズで特定したプロセスを実際に実行するプロセス。

監視コントロール：プロジェクトが計画通りに進捗しているか評価するプロセス。

終結：やったことが期限内に、割り当てられた予算内で、きちんと仕様通りに完了し、その結果、プロジェクトが約束した成果を達成できたのかを特定するプロセス。

　特に IT 分野では、プロジェクトマネジメントについて他のプロジェクトがどんなことをしているのか、ほとんど調べようとしてきませんでした。IT プロジェクトの成功率を高めようと、先進的あるいは成熟した分野の「ベストプラクティス」を適用したり、導入したりする事例はほとんど見かけません。

　ベンチマークとして使うべき分野が 2 つあります。それは医療と民間航空パイロットの分野です。なぜだと思いますか？　医療と民間航空パイロットの分野にはいずれも、サービス提供システムにプロジェクトマネジメントが組み込まれているためです。医者にとって、それは手術や治療であり、パイロットにとって、それは A から B への各フライトです。しかし、IT の観点から見てもっと重要なことは、医療やフライトの成功率は実にうらやましい限りの高さであることです。

　それでは、医者やパイロットは、IT 分野では見られないどんなプラクティスを実践しているのでしょうか？　第一に、意思決定について、医者 / パイロットにはほぼ全権が任されています。その反面、そのポジションにいる人は金銭的にも専門的にも全責任を負うことになります。例えばパイロットの場合、ミスをすると自らの生命すら危険にさらすことになるのです。

　第二に、医者もパイロットも「並の」プラクティスを容認しません。PMI の PMBOK® ガイドでも、プロジェクトマネジメント知識体系とは「一般的に『すぐれた』プラクティスだと見なされている」スキル、ツール、テクニックのことだと述べられています。

　第三に、医療や民間航空の分野で実施されているプロジェクトマネジメントは、単独の方法論ではないということです。確かにプロジェクトマネジメントは存在しており、うまくいっています。その大きな要因は、プロジェクトマネジメントがアセットマネジメント（プロジェクトに提供する組織の資産の割り当ておよび利用に責任のある部門）とオペレーションマネジメント（日々の業務を遂行することで組織に利益をもたらす部門）と十分かつ密接に結びついていることです。組織のリソースを適切に提供するアセットマネジメントと、現実的な期待を抱く内部顧客としてのオペレーションマネジメントがなければ、IT プロジェクトはどんな組織であっても成功しません。

　プロジェクト・マネジャーは IT 分野以外の世界にも目を向けましょう。IT プロジェクトよりもずっと高い成功率を誇る他の分野のプロジェクトマネジメント、特に医療分野と民間航空パイロットの分野でうまくいっているプロジェクトマネジメントについて学ぶ必要があります。

【57】「もうすぐ」よりも「今」を大切に

スコット・デイビス（Scott Davis）

アメリカ、コロラド州ブルームフィールド

　私のお気に入りの言葉に、「大げさな表現は控え目な表現よりも何百万倍もわるい」があります。この言葉のプロジェクトマネジメント版は、「『今』というのは『もうすぐ』よりも何百万倍もよく、『後で』よりも、何億倍もよい」となるでしょう。

　ソフトウェア開発業界にいる人なら、「バイパーウェア」という言葉を聞いたことがあるはずです。バイパーウェアとは、延々と語られてはいるけれども、実際には一度も実現されたことのないソフトウェアのことです。私たちはソフトウェアの開発計画を立案できます。そして、そのソフトウェアが実現する機能について議論できます。しかし、さわって、動かして、やりとりできる現物のソフトウェアの方が、要件を完全に記述したワードのドキュメントよりも何百万倍もすぐれています。

　これはソフトウェアのコードを「今」すぐに書くことを意味しています。あなたが作ったプロトタイプは、今すぐにユーザビリティに関するフィードバックを与えてくれます。パフォーマンスを心配しているのですか？　動くソフトウェアなしに、どうやってパフォーマンスを最適化するのでしょうか？

　アジャイルソフトウェア開発はすばやいイテレーションに注力することで、「もうすぐ」よりも「今」を大切にしています。たいていの場合、イテレーションはわずか 1 ～ 2 週間です。つまり、できるだけすばやくコードを書いてユーザーに届けるのです。もしユーザーが気に入れば、あなたの勝利です。それ以上に重要なことは、もしユーザーが気に入らなくても、早く失敗できるということです。

　早く成功することは遅く成功するよりも百倍よいことにすぎませんが、早く失敗することは遅く失敗するよりも百万倍もよいことなのです。遅く失敗するよりも早く失敗した方が、ソフトウェアを見直して、再調整し、書き直すための時間が与えられます。出荷の 1 週間前に問題が見つかると、もう出荷停止にせざるを得ないでしょう。しかし、初期の段階で失敗したとしても、実際にソフトウェアが動き始める頃には、もうだれもそのことを覚えていないのです。

　たとえ新機能を追加しても、使っているプログラミング言語やフレームワークのせいですぐには公開できないのであれば、あなたが使っているツールには問題があります。コードをコンパイルするのに数秒、数分といったオーダーではなく数時間もかかるのであれば、早期に頻繁にビルドすることはできないでしょう。ソフトウェア開発にこうした不備な点があると、あなたは競争上明らかに不利になります。あなたが毎日使っている有名な Web サイトの多くは、30 分足らずで新機能を公開できるのです。

　アジャイル開発者は、ソフトウェアをすばやく作ることで得た品質のおかげで、業界をリードしています。彼らは自分たちのコードを絶えずテストしています。ソフトウェア開発ライフサイクルの最後になってから、ユニットテストやインテグレーションテストを書いているのでしょうか？　いいえ、そんなことはありません。彼らは「今」テストを書いているのです。テストファーストやテスト駆動開発というのは、ソフトウェア開発のトップ企業の「慣習」です。テストは重要です。今すぐやるくらいに重要なのです。

　ソフトウェアプロジェクトの成功に計画は必要不可欠ではない、というわけではありません。最新のソフトウェアプラクティスやユーザーの期待に基づいて、計画を立案しましょう。ソフトウェアが簡単に、自由に、即座にできるようになったこの時代に、手書きしたコードを細心の注意を払ってパンチカードに転記して、それを靴箱に入れてシステム管理者のもとに運んでいた時代の方法論はもはや通用しません。私たちは今の時代にいるのです。それに合わせてプロセスもうまく調整しなくてはなりません。

【58】スピードこそ命、速ければ速いほどいい？

マット・“ブーン”・ダニエル（Matt “Boom” Daniel）

アメリカ、ペンシルバニア州クーパースバーグ

　「スピードこそ命、速ければ速いほどいい」というのは、戦闘機界隈でよく耳にするスローガンです。思い浮かべてください、聞こえてきませんか。「速くなきゃ！」そうでしょ？　「すさまじいスピードでやらなきゃ！」そうでしょ？　「急接近、即離脱！」そうでしょ？

　戦闘機パイロットの毎日の飛行生活において、スピードが基本的ニーズであることは否定できません。（映画『トップガン』でマーベリックとグースはそう言っていました。だからそうに違いありません。）

　しかし、スピードこそ命で、速ければ速いほどいい、というのは常に正しいのでしょうか？

　昔ながらの一対一のドッグファイトでは、速度を落として旋回半径を最小にすることが生き残るためのひとつの戦術になっています。自機が小さな円を描くよう旋回して敵機に大きな円を描かせることによって、敵機を自機の前方にもってこられれば、絶好の射撃ポジションをとることができます。「相手が描く円の中」に入り込むのです。2 つの機体はこのようなアクションを繰り広げながら、メジャーリーグの速球のように飛行します。これが真の操縦というものです。

　科学的研究によれば、特定の動き、戦術、射撃に関して、過度なスピードよりも適度なスピードの方が有利であることが証明されています。目標にすべきは、最高のスピードではなくて適度なスピードなのです。したがって、特定のニーズや戦術を選ぶと、もはやスピードは重要な評価基準のひとつにすぎなくなります。もっとも重要なことは、そのエネルギー（スピード）をどのように使いたいか、なのです。

　戦闘機パイロットの世界以外について考えてみましょう。危険を冒しながら新しいテクノロジーに参入した最初の会社は、必ず勝利しているでしょうか？　関連する製品やサービスが生き残ることが目標だとすると、せいぜい「たぶん」としか言えないでしょう。

　マーケットで一番最初になること（スピード）は、ビジネス計画には何ら影響を及ぼさないかもしれません。テクノロジーの世界では、先駆者が失敗したり、エネルギー（スピード）を集中させすぎたり、十分なエネルギーマネジメント（ビジネスにとって有益なときにのみ、そのスピードを発揮する）をしなかったために自滅した事例がたくさんあります。

衛星通信：イリジウム（グローバル衛星電話技術）は、簡単で安価な通信システムが一般大衆の手に届くようになったことで、追い抜かれてしまいました。

ビデオデッキ：ベータマックスは VHS よりも先に開発され、最初にマーケットに出たすぐれた製品でした。しかし、それを開発した会社は製品、サービス、副産物のクロスライセンスを拒否したため、結局すたれてしまいました。

PDA：アップルコンピュータのニュートンはマーケットにいち早く出ましたが、結局はパーム社の製品に追い越されてしまいました。

TV-to-Web：WebTV はディスプレイにコンピュータモニタではなくテレビを使った初期の革新的な製品でした。しかし、決してヒットすることはありませんでした。

　自問してみましょう。あなたはプロジェクト・マネジャーとして、リリースのスピードと長期的な妥当性の確保のバランスをどのようにとりますか？　新しいソリューションを陳腐化させないために、どんなツールやプラクティスを活用しますか？

　「スピードこそ命、速ければ速いほどよい」という考え方に注力しますか？　それは強みですか、それとも弱みですか？　あなたの環境において、スピードとは何を意味していますか？　あなたのプロジェクトチームにとって、エネルギーマネジメントとは何を意味していますか？

【59】チームのモラルづくり

デイビッド・ボック（David Bock）

アメリカ、バージニア州レストン

　プロジェクト・マネジャーの大きな役割は、チームのモラルを育てるような仕事環境を作ることです。それに取りかかるときに役立つコツをいくつか紹介しましょう。

チームにプロジェクトの方向性をある程度コントロールさせましょう。チームと頻繁に会話していますか？　定期的にインプットを求めていますか？　だれかが何か提案したり、不満を言ったとき、あなたには積極的に行動して変えていく気がありますか？

チームを「官僚機構」から守りましょう。どんな組織にも共通のルールがあるものです。あなたの仕事のひとつは、状況に応じて共通のルールを適用することです。「状況に応じて」というのは、場合によって、あなたはチームを官僚機構から守ることを意味しています。作業スペースの装飾を禁止するルールが社内通達として発表されたら、あなたはマネジメントに抗議して、ビルがルービックキューブのコレクションを並べておけるよう主張しますか？　たとえあなたが負けたとしても、これはチームのモラルにとっては有益です。

仕事環境を改善する方法を探しましょう。あるとき窓側の作業スペースで仕事をしているエンジニアがいました。しかし、会社の組織図によると、彼は窓側のオフィスを使うことを許可されていませんでした。会社はどのようにこれを解決したと思いますか？　作業スペースは配置替えされて、仕事場にあった窓は塞がれました。すぐれたマネジャーであれば、「家具の秩序」に抗議するよりも、自ら率先して窓を塞いでいたパーティションを動かすでしょう。

チームがチームであることを意識させましょう。毎週のチームミーティングで順繰りに「今週の優秀賞」を設けているチームもあります。ラスはこう言います。「今回はマリーにチームプレイヤー賞を与えたいと思います。彼女は木曜の晩遅くまで仕事をしてくれたためです。ドキュメントを受け取るのは遅くなりましたが、私は彼女の努力に感謝しています。私たちはそのイテレーションを金曜日の朝に完了しました」その翌週、今度はマリーが別のチームメンバーの貢献を認めて、賞を渡します。

ワークライフバランスを尊重しましょう。ときには残業を求めるのもやむを得ませんが、彼らの生活から時間を奪うのであれば、そのお返しをする必要があります。従業員は朝に医者の予約を入れたり、午後に子どもの演奏会に出席するのをためらうべきではありません。締め切りに間に合わせるために、夜遅くまで仕事をしたあとであれば、なおさらです。

原因と結果が、どのようにモラルを形づくるのか理解しましょう。過去のチームであなたや他人をやる気にさせたことを単純に再現しようとしても、重要な要素を見失っている可能性があります。「チームの業務状況を改善するために、私には何ができるのだろうか」と自問しましょう。変化を起こすために実際に行動すると、たいていの場合、モラルは改善していきます。

あなたの行動が目に見えるようにしましょう。あなたもチームの一員です。したがって、チームはあなたがやっている仕事について知っておくべきです。いつも閉ざされたドアの向こうにいるマネジャーは、不信感を抱かれやすいものです。チームの利益のために、オープンに仕事をしているマネジャーには、みんなついてきてくれるものです。

　あなたの組織にもモラルを改善する絶好のチャンスがあるはずです。意識的にチャンスを求めて、うまく活用しましょう。うまくいったら、それを他人と共有しましょう。

【60】プロジェクトはチームワーク次第

レリオ・ヴァレラ（Lelio Varella）

ブラジル、リオデジャネイロ、チジュカ

　プロジェクトは分野横断的な奮闘のかたまりです。非常に多様性に富んだ人たちが総力をあげて、協力して実行するものだと言ってもよいでしょう。各人をスキルと能力にしたがって適切に配置し、連携させることで、チームメンバーは大きな成果を生み出し、ステークホルダーの期待を満足させるのです。IT 関連の開発プロジェクトの場合、例えば次のようなアクティビティやグループに分類できるでしょう。

アクティビティ：ビジネスプロセスレビュー、IT ソリューションおよびサービス定義、製品およびサービス開発、新規プロセスおよびサービスアクティベーション。

グループ：クライアントビジネスエリアチーム、IT 部門チーム、外部サービス・プロバイダチーム。

　アクティビティというのは、異なるグループから個人として参加する作業単位になります。最終的にはベンダーやサービスプロバイダといった外部組織からも参加することになるでしょう。

　グループというのは、さまざまな知識と能力をもった人たちによって作られ、実際にアクティビティを管理したり実行します。各グループのメンバーは通常、各自固有のアクティビティ群にかかわります。

　プロジェクト環境において、効率よく仕事をしてよい結果を生み出すためには、個人が所属する部門や組織に責任を割り当てるのではなく、個人に直接責任を割り当てるべきです。そして、その責任の割り当てをプロジェクト計画に明記しておくべきです。

　個人の能力に応じて、またアクティビティの性質に応じて、個人が同時に複数の役割を果たしても構いません。状況によってはリーダーとして行動し、状況によっては担当者として行動することもあるでしょう。

　プロジェクトの成功に向けた各グループからの参加と貢献はすべて、グループメンバーが達成したアクティビティ全体として評価されます。個人の責任は責任マトリックスとして示されているかもしれませんが、プロジェクトに参加している各グループのアクティビティと全体責任の共通ビジョンも必要になります。

　どんなプロジェクトにも複雑な多様性があるものですが、ソフトウェア開発プロジェクトではそれが顕著に見られます。プロジェクトが成功するかはチームワーク次第ですが、これは 2 つの重要な原則に依存しています。それは委任と責任です。

　委任はプロジェクトの WBS（Work Breakdown Structure）の記載にしたがう必要があります。完了しなくてはならない仕事を分割しましょう。そして、その仕事を適宜完了していくために、割り当てを分割しましょう。本当に大きなプロジェクトを理解し、実行し、管理するためには、これが唯一実行可能な方法になります。

　タスクを委任するためには、各タスクに要求される技術力および管理能力の適切な組み合わせを考慮する必要があります。そして、いったん委任したら干渉してはいけません。あなたはプロジェクト・マネジャーとして監視し、サポートし、結果について尋ねる必要があります。そうすることで、彼らにモチベーションを与え、彼らから尊敬を得て、チームメンバーの「責任能力」を育てるのです。

　「責任能力」にはあらゆる責任を負うことも含まれます。だれかにタスクを委任するときも、タスク割り当てを受け入れるときも、このことを覚えておきましょう。各人のスキルと能力をタスクに釣り合わせましょう。

　リーダーシップ、委任、責任、これらがすべて整うと、これらは互いに支え合います。そうなれば、さらによい結果が得られることはほぼ間違いありません。これがプロジェクトを成功へと導くのです。

【61】チームのために働く

カレン・ギリソン（Karen Gillison）

アメリカ、バージニア州リーズバーグ

　私はアジャイル開発について耳にするずっと前に、これまで出会った中で最高のプロジェクト・マネジャーと仕事をする機会を得ました。今考えてみると、彼はアジャイル開発の原型とも言えるテクニックを駆使していました。彼は自分の仕事をチームのファシリテーターだと考えていました。障害を見つけて取り除き、チームにリソースを提供すること、それが自分の日々の務めだと考えていたのです。彼はチームのベロシティを高めるのに役立つことを日々実践していたのです。

　何時間もかかるようなミーティング、状況をアップデートするのに自分の順番が来るまで睡魔と戦わなくてはならないようなミーティングはありませんでした。ミーティングから抜け出してコードを書きたくなる、そうすれば次回のミーティングに報告すべき進捗があるのに、と思うようなミーティングもありませんでした。そういったミーティングの代わりに、プロジェクトの開始時には、要求からテストまで、さまざまな職務権限をもった人たちを集めたキックオフミーティングが開かれました。プロジェクトのビジョンと理解を共有するために、チーム全員が一堂に集められたのです。以後プロジェクト・マネジャーは数日おきにやって来て、「出入り口」でのステータスミーティングと呼ぶミーティングをやりました。そこでチームメンバーは、何が完了して、何が進行中で、どんな問題があるのか、状況を簡単にアップデートしました。

　このプロジェクト・マネジャーはプロジェクトステータスをはっきりと目に見える形で記録しました。彼はだれがそのタスクを完了しなくてはならないのか、すべての割り当てのマスターとなるリストを作りました。このドキュメントは定期的に更新され、大きくプリントアウトされて出入り口の外に貼られました。全員が見えるところに貼られていたので、チームのコミュニケーションにはもってこいでした。おまけに上位レベルの管理職からも状況が見えるようになり、彼らの好きなときにいつでも自分で最新状況が得られるようになりました。

　「エゴ」について一言注意しておきましょう。私のお気に入りのプロジェクト・マネジャーはできた人で、自制心があり、エゴを避けていました。彼は上司でしたが、職権を乱用したり、思いつきでタスクを変えたり、方針を変更したりはしませんでした。彼の行動がチームの生産性に害を及ぼすことは一度もありませんでした。なぜなら彼の一番の目標は、自分のチームが卓越したチームに進歩するのを助けることだったからです。

　エゴを制することで、彼と彼のチームは、エンドユーザーと上位レベル管理職を満足させて、予算内でかつ時間内にすばらしい成果を上げました。このマネジメントスタイルはとても効果的で、プロジェクトの終わりには、徹夜仕事や怒鳴り声、ストレスといったものはほとんどなくなりました。あまり成熟していない企業だと、こうしたプロジェクト・マネジャーと順調に進んでいるチームは評価されないかもしれません。なぜならどのプロジェクトも簡単なように見えてしまうためです。たとえ認められなくとも、企業とエンドユーザーがお互いを正当に評価することで、チームメンバーには満足感がもたらされます。

　今ではアジャイルアプローチが優れたプロジェクト・マネジャーになるための新しいツールを提供してくれます。アジャイルアプローチについて、よく理解することをおすすめします。たとえ運がわるくて、こうした方法論を採用していない組織で仕事をしていてもです。その場合には、こうしたツールを従来のプロジェクトマネジメントの道具箱に組み入れましょう。プロジェクト・マネジャーの重要な役割のひとつは、チームのベロシティを高めること、そして、生産性を阻害するものがほとんどないチーム環境づくりを目指して努力することだと自覚しましょう。

【62】大きな丸いボールという誤った考え

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　完全に球形で、完全になめらかに作られたボールを想像してみましょう。このボールにある唯一の設計要求は、どこを測定しても直径がぴったり同じであることです。ボールは完全な球になるまで、何度も何度も磨かれます。問題がひとつもなくなれば、作業はすべて終了します。これ以降の変更はありません。それが完全というものです。

　これはあなたがこれまで取り組んできたソフトウェアプロジェクトのように聞こえましたか？　私はそうは思いませんでした。ソフトウェアはこんな風にはいかないのです。

　ソフトウェアはそのライフサイクルを通して絶えず変化するものです。設計判断は初期の要求に基づいてなされる場合が多いですが、新しい要求が出てくると突如としてそれらは制約になります。コードを新しい要求に合わせて改修していくと、設計は乱されて、コードは徐々にメンテナンス不能になっていきます。ボールは丸くなるよう作られましたが、徐々にぼろぼろであざだらけになっていくのです。

　大きな丸いボールという誤った考えとは、ソフトウェアシステムに対する要求は納品後あまり変化しないとか、さらにわるいことに、要件はコントロールできるといった妄想のことです。

　初期のソフトウェア工学の研究者らは、コーディングを始める前に要件が十分理解できていれば、メンテナンス危機は起こらないだろうと考えていました。納品後の要求変更によって起こる問題を取り上げて、それを悪者にする人もいました。要求を固定することで安定したシステムが生み出せると考えていたのです。ユーザーが変更を要求する権利を制限しようとする人もいました（例えば「ユーザーの追加機能を計画してコントロールすることで、変更管理の必要性を減らす」ことは、ジェームズ・マーチンとカーマ・マックルーアが 1983 年に提案した「メンテナンスに対する解決策」のひとつに挙げられていました）。

　残念ながら、このような厳格なコントロールは、ソフトウェアシステムをエンドユーザーにとって使えないものにするという意図せぬ副作用があります。こうした判断は目先の損得勘定に基づいていることが多く、1990 年代におけるユーザーと IT 部門の疎遠をもたらし、機能追加と称した小規模でコピーだらけの部内ソフトウェアシステム開発が続く大きな原因となりました。

　要求は絶えず移り変わるものです。ソフトウェアプロジェクトに対する要求は非常にもっともな、非常に単純な理由で変わります。第一に、ソフトウェアは変更可能である、ということです。ソフトウェアは融通が利きます。一般的にハードウェアを変更するよりもソフトウェアを変更する方が、コストの上ではるかに効果的です。

　第二に、ほとんどのユーザーは競争環境にいます。彼らはお互いに組織同士で競い合っています。必死に競争していると、新たな強みを得ようとシステムで最も融通の利くところに頼ります。ソフトウェアの柔軟性は魅力的なのです。

　もし私たちが大きな丸いボールという誤った考えに見切りをつけられれば、要求を変更するのがもっと楽になり、ソフトウェアの柔軟性をありのままに享受することができます。これは私たちがコントロールできる大きな強みになります。要求は変化します。私たちはコードをメンテナンスする必要があります。設計を乱すような新しい要求を追加する必要があります。これはフィーチャーであって、俗にいうところのバグではないのです。

　私たちは順応性のあるソフトウェアを設計できますが、それは最初から順応性をもった考え方をした場合に限ります。順応性、設計の柔軟性、変更への準備は、どんな新しいソフトウェアプロジェクトにとっても不可欠であるべきです。

【63】危機への対応

ジェームス・グラハム（James Graham）PMP

マルタ、Ta’l-Ibrag

　2009 年 1 月 15 日午後 3 時 3 分、ノースウェスト航空 1549 便はニューヨークのラガーディア空港の滑走路からノースカロライナ州シャーロットへの短いフライトに飛び立ちました。

　5 名のクルーと 150 名の乗客を乗せたチェズレイ・サレンバーガー機長が操縦するエアバス 320 は、ニューヨーク州ブルックリン上空で鳥の群れにぶつかりました。これにより両方のエンジンがひどい損傷を受け、推進力を失ってしまいました。

　管制塔との交信記録のテープを聞くと、2 つのことがわかります。まずサレンバーガー機長は、考えられないことが起こったことを即座に認識しているように聞こえます。これは彼の長年の経験と訓練のおかげでしょう。もうひとつは、同じように管制塔も即座に反応して、押し付けがましくならないよう注意しながら、支援のための選択肢を繰り返し提案しているように聞こえます。

　数分のうちに、サレンバーガー機長はラガーディア空港やニューアーク空港、近くのティータボロ空港でさえも着陸するのは不可能だと考え、ハドソン川に着水することを決めました。大地に着陸できるのなら滑空して川に降りるのも似たようなものだと判断したのでしょうが、このプロの機長はすべての選択肢にあるリスクを比較検討して、乗客全員が安全だと判断したものを選んだのです。

　これは実戦における危機管理のすばらしい事例です。

　航空機のパイロットたちがフライト前に各自の行動について話し合い、チェックリストを使って通常時と異常時の両方に対処していることを知ると乗客も安心するでしょう。つまり、彼らはチームとして、フライト中にとるべき重要な行動について把握しているということです。

　この危機に対応するには、チームとして機能するクルーが必要でした。サレンバーガー機長が航空機を操縦しているあいだ、副操縦士のジェフリー・スカイルズは滑走路に着陸できるようエンジンの再起動を試み、客室乗務員らは乗客が無事に不時着できるよう準備していました。ノースウェストの各クルーは最善の結果が得られるよう自分の役割を果たしたのです。

　ソフトウェアプロジェクトについて考えるときには、次のような状況がチームに当てはまるか検討しましょう。

定期的なチームミーティングがあり、重要なフェーズ（例えばテスト）の前にはその開催頻度が増えること。

適切な対応が書かれたリスク一覧が存在すること。

リスク一覧は定期的に更新されて、常に最新に保たれていること。

チームにおける専門家が適切なレベルになるための訓練を受けていること。

重要な責務について割り当てた危機管理計画があること。

危機管理計画には、明確な内部および外部とのコミュニケーション戦略 / 計画が含まれていること。

　もし答えがすべてイエスであれば、すばらしいことです。安心して寝ていられるでしょう。もしそうでなければ、すぐに検討して計画を立てるのが賢明です。

　危機に対処するためには、まず明確に責任を定めるのがよいでしょう。チェックリストやプロセス、重要なプロジェクトフェーズのための手順を準備しましょう。これは事前にできる作業であり、プロジェクトマネジメント計画とその補助計画に組み込むことで、チーム全員に伝えることができます。

　1549 便の事例は、明確に定義された役割があれば、有能なチームは非常に困難な危機ですらうまく管理できることを教えてくれました。

【64】インテグレーションポイントを知る

モンデ・デイビス（Monte Davis）MCSE

アメリカ、ネブラスカ州オマハ

　システム管理者や開発エンジニア、プロジェクト・マネジャーはシステムインテグレーションに苦しんでいます。新規開発したアプリケーションや新規購入したソフトウェアパッケージ、待望の新機能を搭載したアップグレードなど、それらがどんなに有望なものであっても、そのビジネス価値は既存の社内システムと組み合わせて円滑に動かせるか否かにかかっているのです。

　あなたが経験豊富なプロジェクト・マネジャーだとしても、IT 業界に不慣れであれば、インテグレーションという言葉に惑わされてはいけません。インテグレーションとは、さまざまなソフトウェアプログラムを組み合わせることで、すべてのサブシステムが連携して単独のアプリケーションから得られる以上の機能を提供することを意味しています。例えば、あなたは一度データを入力するだけで、その情報がスムーズに営業担当に伝わり、買掛金と売掛金にも反映され、さらにほかのシステムにも伝わり、利用するインターフェイスが何であっても、従業員がほしい情報を引き出せるようになるのです。

　残念ながら、たいていの場合、ソフトウェアのアップグレードが要求されるとプロジェクト・マネジャーは緊張します。これまでスムーズに動いていた処理に問題が生じるおそれがあるためです。最近、私たちはシステムのひとつをアップグレードすることになっていました。ところがアップグレードの最中、ベンダーは予期せぬエラーに遭遇してしまいました。

　アップグレードは複数のビュー（データベース情報の特定の一部を示すよう事前にプログラムされた画面）で失敗していました。アップグレードを実施した外部ベンダーには、そのビューが何のために使われているかわからなかったので、そのビューを消去してしまいました。その結果、アップグレードはうまく完了したように見えました。

　数日後、このシステムとはまったく別のシステムに、問題が登録されました。ユーザーが先週末アップグレードしたシステムから新しい顧客データが到着するのを確認できなかったためです。あとでわかったことですが、削除したビューは失われた顧客データのソースだったのです。

　アップグレードを完了させるためにソースビューを削除した結果、システム間の同期処理がおかしくなりました。ソースビューが失われているという結論に至るまで、トラブルシューティングに何時間もかかりました。原因が判明してからも 2 つのシステムが再びやりとりできるようにするため、削除したビューを手作業で再生成しなくてはなりませんでした。

　たいていの IT 部門では、各種ハードウェアシステムにおける各種コンポーネントがどうつながっているかを示した図を用意しています。これと同じように、組織にデータがどう流れているかを視覚的に表現すると役に立ちます。アプリケーションのデータが別のプログラムに流れる重要な連結点（インテグレーションポイント）を明記しておきましょう。

　このような場合には、システムがお互いに依存していることを説明したドキュメントがあると役に立ちます。もしそれがあれば、アップグレードを実施するベンダーと最初に会ったときに、彼らとビジネスフロー図を共有できたかもしれません。

　また、ほかのシステムに提供する重要なビューを削除しなくても、最初のアップグレード問題を別の方法で解決できたかもしれません。システムダウンの時間と管理者のストレスを軽減できたかもれません。信念をもって、アップグレードを乗り越えましょう。隠れた問題がシステムに取り込まれることを恐れて暮らす必要はありません。

【65】分散したプロジェクトにおける積極的なコミュニケーション

アヌパム・クンドゥ（Anupam Kundu）

アメリカ、ニューヨーク州ニューヨーク

　分散したプロジェクトではチームメンバーが同じ場所にいない（物理的に一緒にいない）ため、独特の課題を抱えています。以下のような問題がプロジェクトの成功の妨げになるでしょう。

地理的に分散したチーム間の信頼が欠如していること。

コミュニケーションに相当の時間を要すること。

文化の違いのため「ひとつのチーム」という意識が育たないこと。

全体ミーティングにチームメンバーが参加できないこと。

プロジェクトチームとしての一体感が欠如していること。離れた場所にいるチームメンバーは異なる言語を話していたり、異なるプラクティスを実践しているかもしれません。

　分散したプロジェクトをファシリテートするプロジェクト・マネジャーにとって、こうした障害は悪夢になります。もし分散したプロジェクトのマネジメントを任されたら、コミュニケーションに関するリストに以下を加えておくべきです。

地理的に分散したチーム間で、重なる時間を見つけて明記しておきましょう（夏時間のことを忘れてはいけません）。

チームメンバー全員のインスタントメッセージのアドレス（および、メッセージが届くのに最も都合のよい時間）を公開しましょう。

重要なステークホルダーが電話会議を行うための手段（Web や電話）を知っているか確認しましょう。

各チームの休暇情報を集めて、共通カレンダーで共有しましょう。

地理的に分散したチーム間で、毎日のミーティングの予定を公開しましょう。スタンドアップミーティングは座ってやるミーティングよりもすぐれています。だれも長時間立っていたくはないので、出席者はみんな集中します。

チームメンバーの名前と顔写真を公開しましょう。重要な役割についてだれがバックアップの窓口になるのか確認しておきましょう。

プロジェクトの中間生成物（ドキュメント、レポート、テンプレートなど）をチーム間で共有するために、共通の場所を用意しましょう。

　分散したチーム間のコミュニケーションを促進するためには、コミュニケーション戦略の強化に加えて、設備上の問題も解決する必要があります。

すべての場所に高品質のスピーカーフォンを購入しましょう。電話会議のためにチーム間に安定した電話回線を保証することは、仲間意識を作るのに非常に役立ちます。

大きなテーブルのある広々とした部屋に電話を置きましょう。みんながゆったりと座れるように、また、普段とは違う時間のミーティングに参加する人に食事を提供することがあるかもしれないためです。ホワイトボードも用意しておきましょう。そうすれば、電話会議中にすばやくメモをとって、部屋にいる全員で確認することができます。

立ち上げフェーズや QA プロセスなどのために、チームメンバー数名がほかのチームのところへ出張できるよう予算を確保しておきましょう。

プロジェクトダッシュボードを作って（何らかのコラボレーションツールを使って）、問題をやりとりできるようにしましょう。オンラインツールを使ったり、写真共有技術を使うなどして、ダッシュボードのイメージをチーム全体で共有しましょう。

プロジェクトの全体目標とターゲットを、在宅勤務者を含む全員が見られる共通の場所に公開しましょう。

ビジネススポンサーによるプレゼンテーションを設定して、すべての場所にいる重要なチームメンバーにプレゼンテーションに参加するよう求めましょう。

　仮想的に分散したチームも増えてきています。革新的なコミュニケーションテクニックを駆使することで、あなたは成功のチャンスを高めることができるでしょう。

【66】結果を想定して始める

ルイス・E・トーレス（Luis E. Torres）PMP

コスタリカ、アラフエラ、サン・ラファエル

　おめでとうございます。あなたはだれもが希望する夢のようなソフトウェアプロジェクトのプロジェクト・マネジャーになりました。会社の期待はすべてあなたの肩にかかっています。あなたの本能がすぐにでも机に向かってプロジェクトスケジュールのドラフト作りを始めるよう語りかけているんじゃないですか？　プロジェクトを成功させるチャンスを高めるには、まず最初にやるべきことがたくさんあります。そのひとつが「結果を想定して始める」ことです。

　最初に、SOW（Statement of Work、作業範囲記述書）や契約、顧客がほしいものや必要としているものを教えてくれるドキュメントが必要になります。「ほしいもの」と「必要としているもの」の違いを理解しましょう。（私は SUV がほしいのですが、必要としているのは燃費のよい小さな車です）。そうすれば、あなたは両方を組み合わせて、次のような質問に答えやすくなるでしょう。「私たちは何を達成しようとしているのですか？」「顧客にとって、会社にとって、そして私にとって、このプロジェクトを成功させるものは何でしょうか？」「成功を実現するには何が必要なのですか？」

　最後の質問には単なる「適度な利益」のほかにも、いろいろな答えがあります。あなたは顧客にまた自分を採用してほしいでしょうし、プロジェクトのチームメンバーにまた自分と一緒に仕事をしたいと思ってほしいでしょうし、仕事を任せるのに見合った能力を発揮し続けたいでしょう。

　プロジェクト・マネジャーとして成功するために一番大事なことは、適切な態度と適切なピープルマネジメントスキルです。プロジェクトのチームメンバーを集めたキックオフミーティングを開催して、SOW をレビューし、何を実現しなければならないのか共通理解を得ましょう。

　次に、プロジェクトのスコープを定義して、WBS（Work Breakdown Structure）を作りましょう。満たさなくてはならない品質指標を特定しましょう。スケジュールを策定しましょう。どれくらいの資金が必要か計算しましょう。これらスコープ、品質、期間、コストが監視・コントロールすべき基本要素であり、プロジェクト計画の土台となります。

　プロジェクトを管理可能なサイズに分割できたら、プロジェクトの品質要求を満たすために最終成果物がもつべき特性が何であるかを特定しなければなりません。プロジェクト（スコープ）を適切なサイズに分割して、どんな「ルール」（品質）に準拠しなくてはならないかを明らかにすると、プロジェクトを完了するのにどれくらいの時間がかかるか判断しやすくなります。

　プロジェクトを完了するのにどれくらいの時間が必要になるかを見極めるには、個々のタスクの期間、タスク間の依存関係、具体的な制約、利用可能なリソースを決める必要があります。コストは一番最後になります。コストは通常、あなたがやる必要のある仕事と、その仕事を完了するのに必要な時間とリソースの関数で表現されるためです。例えば、あるタスクのためにコンサルタントを雇う場合にも、その人が 1 週間仕事をするよう計画するのと、その人がプロジェクトで 10 か月仕事をするのとでは、コスト負担は同じにはならないでしょう。そして最後に、調達、コミュニケーション、人的資源についても検討しましょう。

　目的を持って始めましょう。そうすれば成功のチャンスははるかに高まります。

【67】約束事が明確なら友情も長続きする

マッテオ・ベッキ（Matteo Becchi）PMP

アメリカ、バージニア州アーリントン

　このエッセイのタイトルは古いイタリアのことわざ “Patti chiari, amicizia lunga”（「約束事が明確なら友情も長続きする」）に由来しています。

　この考え方は、プロジェクトマネジメント原則のさまざまな面に当てはまります。上位の方法論レベルで見ると、このことわざは、スコープ記述、目標と成果物の設定、プロジェクト定義ドキュメントの作成などの背景にある考え方を要約しています。実際のところ、プロジェクトの中間生成物はすべて、プロジェクトチームが成し遂げようとする約束事と目標を事前に提示するためにあります。

　こうした考え方を頭に入れて、プロジェクト全体を俯瞰してみましょう。プロジェクト憲章、スコープ、WBS、スケジュール、コスト見積りから、品質 / 人的資源 / コミュニケーションおよび調達計画まで、PMBOK® ガイドの 9 つの知識領域にわたるプロジェクトライフサイクルの立ち上げフェーズと計画フェーズを見てみましょう。

　それぞれのアクティビティが重要視しているのは、事前に計画することと、同じ考えを持つようステークホルダー全員に計画を伝えることです。これらは、プロジェクトライフサイクルが順調に進むことを保証する基本的な尺度となります。

　次に、ミーティング運営においては、ミーティングガイドラインとチームに期待されることが明確になっているかを確認しましょう。もし明確でなければ、設定して提示しましょう。

具体的なアジェンダと必要な出席者のリストを事前に用意しましょう。すぐれたソフトウェア開発者には高い給料を支払っています。ミーティングのためにコーディングの時間をムダにしていると、すぐに予算をオーバーしてしまいます。

情報を集めたり、外部の専門家と話をしたり、関連する文献や研究報告を読んだり、過去の議事録や社内の記録を調べるなどして、必要に応じて参加者に事前準備させましょう。チームメンバーの準備不足のせいで、エグゼクティブと 2 度目のミーティングを設定することは許されません。

プレゼンテーション準備のために、ノート PC をコンセントにつないだり、プロジェクターを用意したり、オーディオをつないだりする必要があれば、早めにミーティング場所に到着しておきましょう。そうでなくとも数分早めに来て、席を見つけて、コーヒーを入れて、ほかのチームメンバーに挨拶しましょう。

ミーティング中には通信デバイス（ブラックベリー、ノート PC、携帯電話）を使わないという「ポリシー」を決めておきましょう。あなたが話しかけたときにメールを書いたりゲームをしている開発者がいれば、その人はあなたを無視していたということです。

ほかのチームメンバーを尊重しましょう。脇で個別に会話したり、割り込んだり、ほかの人と議論したりするのを控えましょう。

　さらに、顧客やベンダー、下請け業者とは明確な契約を結んでおきましょう。営業が注目するのは、納品される最終製品と組織が受けとる最終価格だけです。変更がどのように要求されて承認されるのか、その料金はどうなるのかといった詳細についても、必ず明記しておきましょう。

　顧客はプロジェクトについて、どれくらいの頻度でどんな形で連絡をとることを期待しているのか、その手順を定めておきましょう。顧客はチームからの質問に答えられますか？　　開発の進行に応じて、顧客はエンドユーザーにソフトウェアの機能をテストさせたがっていますか？

　約束事が明確なら友情も長続きします。これはどんなプロジェクト環境にも当てはまります。

【68】一番うまく見積もれるのはその仕事をする人である

ジョー・ゼネビッチ（Joe Zenevitch）

アメリカ、ニューヨーク州ニューヨーク

　ひとりがすべての作業の見積りをするようなプロジェクトを経験したことがありますか？　うまくいきましたか？　うまくいかなかったんじゃありませんか？ 　このやり方には大きな問題が 3 つあります。

よほど運がよくない限り、開発者と見積りをする人のあいだには、スキルのレベルに差があります。リードアーキテクトがすべての仕事をするのであれば、彼の見積りは正確かもしれませんが、実際に仕事をする開発者のペースはきっと違っているでしょう。

ひとりがチーム全体を見積もると、見誤るリスクがかなり高くなります。見積りに関与する人が多ければ多いほど、見積りは改善されます。

開発者は不完全な見積りを手渡されて、それに合わせなければなりません。こうしたやり方を喜ぶ開発者はまずいないでしょう。

　一番まずいのは、あなたがプロジェクト・マネジャーにはチームに見積りを提示する権限があると思い込んでいることです。あなたもかつては開発者だったので、適切に見積もれると思っているのかもしれません。たとえあなたが積極的に開発に関与していたとしても、よく考えましょう。先ほどのリードアーキテクトの話と同じことが当てはまります。しかも、積極的に開発していた頃から時間がたてばたつほど、あなたの見積りはどんどん間違っていきます。もし自分がよく知らない技術を使っているチームを率いているなら、自分で見積もろうなんて考えてはいけません。

　私たちのプロジェクトではワイドバンド・デルファイ法を使ってグループ見積りをしています。まず最初にビジネスアナリストがフィーチャー要求について説明するところから始まります。開発チームはそれを聞いて、疑問に思ったことをクリアにするための質問を繰り返します。初期見積りの準備ができると、各自カードに見積もった値を書いていきます。全員が書き終えたら、3 つ数えて各自カードを掲げます。

　そうしたら、どれだけ見積もった値が一致しているかを調べます。もし非常に近い見積りが得られていれば、そのなかで控え目な値を選びます。もし見積りに大きな違いがあれば、どうしてそう見積もったのか開発者に尋ねます。そして、さらに議論を重ねて、再度見積りをします。開発者のあいだには、そのフィーチャーを完成させるために何が必要なのか、共通の理解があるため、たいていの場合、見積りはひとつの値にまとまります。

　このやり方は以下のような点で好都合です。

チーム全員が見積りの検討に参加するため、いろいろな見方を全員で共有することができます。たいていチームメンバーは同じ意見にまとまって、すぐに共通の見積りが得られるでしょう。

あとで実際にコーディングを開始するときには、開発者全員がその見積りに至るまでの思考プロセスを知っています。そのため、限られた人しかそのフィーチャーに取りかかれないという状況を減らせます。

チームに見積りを「所有」させることで、反発の機会を減らせます。見積りにはまだ間違いがあるかもしれませんが、チームメンバーはあまり挑戦的な態度をとることなく、協力的に修正した見積りを受け入れてくれるでしょう。

　覚えておきましょう。一番うまく見積もれるのは、その仕事をする人なのです。

【69】コミュニケーションが重要

ゲナディ・ミロノフ（Gennady Mironov）CPM

カナダ、オンタリオ州トロント

　どんな業界のプロジェクト・マネジャーにとっても一番大切な知識は、すぐれたコミュニケーターになる方法です。名前のあとに、いろいろな資格や肩書きのリストが並んでいる人もいるでしょうが、ほかの人とコラボレーションする方法に関する基本的知識がなければ、プロジェクトという仕事をうまく成し遂げることはできません。

　新しいプロジェクトを始めるとき、すぐれたプロジェクト・マネジャーであればステークホルダー全員と直接会うはずです。それがクライアントであれば、なおさらです。プロジェクト・マネジャーはまず自己紹介をして、プロジェクトの目標と重大な懸念について洗いざらい話すべきです。ステークホルダーやクライアント、さらにはプロジェクトチームが国外にいるのでない限り、たとえ不景気であったとしても、直接顔を合わせるのは大きな問題ではないはずです。

　「百聞は一見にしかず」という言葉があります。数百万ドル規模のプロジェクトにいくつも取り組んできた私のマネジメント経験から、クライアントを直接訪問すれば、問題は半日で簡単に片付けられることを学びました。

　あるプロジェクトで、請負業者が必要な無線基地局を提供できないためにスケジュールが遅れるという問題が起こりました。請負業者がこの部分を下請け業者にアウトソースしており、その下請け業者の電力供給システムが遅れたことが原因でした。私は何週間もあちこちに電話をかけ、数え切れない程のメールを送りましたが、問題は解決しませんでした。

　最終的に、私は請負業者に個人的に会いに行き、問題の詳細を説明して、取り得る解決策を提案しました。こうしてようやく、私たちは必要な機材を手に入れることができたのです。たいていの場合、顧客はあなたの味方です。あなたが快く耳を傾けて、妥当な解決策を見つけるのを手伝えば、いつもあなたをサポートしてくれるのです。

　別のプロジェクトでは、非常に短期のスケジュールを要求してきたクライアントがいました。彼らは年末までにその機材の製品サイクルを短縮するよう求めてきたのです。ちょうどできるだけたくさんの受注をこなそうと、全工場が 100% の能力で作業していたときでした。私たちはこれを受け入れることはできませんでした。というのも、通常のプロジェクト期間の半分しか与えられなかったためです。

　このときもまた、私は会社とクライアントとベンダーによる三者ミーティングを開きました。私たちは正直に、最短で最も現実的なスケジュールを提案し、なぜこれ以上短縮できないかを詳しく説明しました。プロジェクトに必要な品数を把握するために特別に用意してあった在庫を使い尽くしたあと、私たちはある程度のリスクを負って、注文確約なしに顧客の注文を受け入れました。

　結局、私たちはプロジェクトをうまく仕上げることができました。しかも非常に厳しいスケジュールの 2 日も前にです。クライアントはとても喜んで、年明け早々、また別の 200 万ドル規模のプロジェクトを提示してくれました。私たちはスケジュール、スコープ、予算、品質要求を満たすことができました。しかもこの場合には、プロジェクトの成果として、組織に特別な利益までもたらすことができました。

　ソフトウェアプロジェクトがうまくいくかは、人と人とのコミュニケーションにかかっているのです。

【70】プロジェクトは解決策の追求である

シンシア・A・バーグ（Cynthia A. Berg）PhD（ABD）、PMP

アメリカ、アリゾナ州グレンデール

　スティーブン・コヴィーはその著書で「結果を想定して始める」と述べています。それでは、最終的な解決策の追求以外に、プロジェクトの結果とは何なのでしょうか？　ソフトウェアプロジェクトの目的を概念化する一番の方法は、WBS（Work Breakdown Structure）を作ることです。WBS はプロジェクトの全体スコープを成果物にまで細分化し、階層的に展開したものです。組織図が会社を部門やさらには作業チームへと分割して示しているのとよく似ています。成果物はさらに小さな構成要素、作業パッケージレベルにまで分割されます。

　WBS を作るときには、チームメンバーやスポンサー、その他ステークホルダーも参加させましょう。そうすることで、プロジェクト作業を明確に定義して、参加者全員のニーズを表現することができます。なぜチームメンバーを参加させると思いますか？　タスクを実際にやるチームメンバー以外に、やるべき作業について詳しい人はいるのでしょうか？　プロジェクト・マネジャーがすべてのプロジェクト作業に関するリストを作れるのは自分だけだと考えているなら、そのプロジェクトは失敗する運命にあります。

　WBS を作るときには、チームはそうしたプロジェクトマネジャーの「いつものやり方」に異議を申し立てることができます。それどころか、何がプロジェクトを構成する作業になるのか、チームメンバーが進んで共通の意見をまとめるべきです。こうしたやり方にすると、チームメンバーはもっと積極的にプロジェクトに参加するようになります。結局のところ、自分が設計にかかわったプロジェクトの方が楽しく仕事ができるのです。

　WBS のアクティビティはどれくらい小さく分割すべきだと思いますか？　これはいじわるな質問です。WBS にはアクティビティは出てきません。なぜなら WBS では作業パッケージレベルまでしか分割されないためです。作業パッケージは部門やグループ、ベンダー、下請業者にアサインされます。彼らは効率よく品質プロセスにしたがって実行するために、作業パッケージをさらに必要なアクティビティやマイルストーンへと分割します。ここで重要なことは、作業パッケージ（最も低レベルにある作業）にアサインされた人が、さらに小さなプロジェクト計画を作り、それをマスタースケジュールに反映させるということです。

　以後、WBS はプロジェクトにおけるあらゆる計画、実行、監視、コントロール機能の中心となります。プロジェクトの内外にいる人たちとの簡単なコミュニケーションツールとしての役割も果たします。WBS をグラフィカルに表現したものがプロジェクトの解決策のイメージになります。イメージが完成すると、ようやく詳細な計画、スケジュール、予算管理が始まります。プロジェクト作業が明確に定義されて初めて、計画、予算、スケジュールが立てられるようになるのです。

　WBS はブレインストーミングのツールとしても非常に役立ちます。プロジェクト全体をグラフィカルに表現することによって、仕事で怠慢なところ、冗長なところ、充実しているところが簡単にわかり、プロジェクトの利用価値を高めやすくします。（プロジェクト内外の）潜在的なリスクを特定するために、WBS を活用しましょう。

　事前に少し時間をとって、すべてのステークホルダーと協力して明確な WBS を用意し、理解し、合意すること、それがプロジェクトの優劣の決め手となるのです。

【71】鍵は人間にある

エイドリアン・ワイブル（Adrian Wible）

アメリカ、ニューヨーク州ニューヨーク

　プロジェクトのチームメンバーはみな、願望、強み、遠慮、弱みをもった人間であるという事実を見落としてはいけません。プロジェクトの成功は、あなたのガントチャートの妙技やプロジェクトトラッキングの腕前よりも、チームメンバーの姿勢と適性にかかっています。遠慮せずにプロジェクトをマネジメントしましょう。でもチームを率いていることを忘れてはいけません。

　私たちの多くはマトリックス環境でプロジェクトを管理しています。そこでは、チームメンバーはプロジェクト・マネジャーと部門マネジャーの両方に業務報告することになります。マトリックス環境の場合、チームのために人材を雇ったり、解雇したり、評価したりする責任はプロジェクト・マネジャーにはありません。だからと言って、チームメンバーの世話や育成の責任を、人事部や組織階層上のマネジャーに丸投げしてはいけません。

　ほとんどのマネジャーは人事処理やその部門の技術的知識によって昇進したのであって、人をやる気にさせる能力によってではありません。あなたのプロジェクトが成功するかどうかは、あなたの指導力にかかっています。リーダーシップに関する本はたくさん出ているので、貪欲に読みましょう。

　チームのだれもが、プロジェクトに貢献し、プロジェクトから学び、プロジェクトを達成したいと思っています。チームメンバーのこうした願望を見つけて掘り下げるのが困難なときもあるでしょう。しかし、それこそが、プロジェクトマネジメントをやりがいと楽しみのあるものにしているのです。

　定期的にチームメンバーと一対一で話し合いましょう。彼らの問題が何なのかを究明し、彼らに意見を求め、プロジェクトに対して発言権を与えましょう。彼らの意見を真剣に受け止めて、行動するのです。

　成長して何をやりたいと思っているのか、チームメンバーに真剣に尋ねましょう。だれもがキャリア願望をもっています。彼らのキャリアを気にかけるメンターになりましょう。これがどんなに強力なことか、あなたはびっくりするはずです。

　チームメンバーに対して直接、率直かつ素直に接しましょう。レビュー時に限らず、定期的にフィードバックしましょう。人に対してではなく、行動に対してフィードバックすることが大切です。マネジメント稼業には問題が山積みです。あなた自身が学びましょう。

　チームメンバーにパフォーマンス上の問題があるときには、CRAM（Constraints, Resources, Aptitude, and Motivation：制約、リソース、適性、モチベーション）モデルを適用してみましょう。プロジェクト・マネジャーはパフォーマンスがわるいのをモチベーションの問題だと診断しがちです。CRAM モデルによると、モチベーションは検討すべき最後の問題だとされています。チームメンバーは効率を妨げるような個人的な事情に悩んでいるのかもしれません。例えば、離婚したり、結婚したり、子どもができたり、依存症と戦っていたりなどです。

　チームメンバーには最大限の貢献をするのに必要なリソースがないのかもしれません。例えば QA テスト環境がなかったり、使えるハードウェアが古かったりなどです。予算制約のために、テスト環境の構築や必要なソフトウェアのライセンス購入が制限されているのかもしれません。あるいは、ドメイン専門家（ビジネスアナリスト、顧客、エンドユーザー）と話せない状況なのかもしれません。

　果たすべき役割に向いていないチームメンバーもいるかもしれません。プロジェクトに必要とされるプログラミング能力がないのかもしれません。もしそうであれば、できれば別の役割を見つけましょう。あるいは、その人の強みが活かせる別のチームを見つけましょう。

　チームメンバーにパフォーマンス上の問題があるとき、モチベーションは最後に考えるべきことです。制約、リソース、適性といった問題を解決してから考慮しましょう。

　リーダーとして、チームを構成する個人とつながりを持ちましょう。あなたはその結果に驚くはずです。

【72】ドキュメントは手段であり目的ではない

パトリック・クア（Patrick Kua）

イギリス、ロンドン

　かつてアイゼンハワー大統領はこう言いました。「計画は役に立たないが、計画することは不可欠だ」。成功しているプロジェクト・マネジャーは、計画を細部にわたり慎重に更新するというオーバーヘッドなしに、いかにして計画することから利益を得るのかを心得ています。彼らはドキュメントを積極的に活用して、有意義な会話を生み出しています。もちろん、ドキュメントはあらゆるコミュニケーション手段を置き換えるものではありませんし、だれかが合意を破ったときに追求する手段でもありません。

　特定の目的を実現する状況において、計画と追跡はプロジェクト・マネジャーにとって不可欠なアクティビティです。たいていの組織は、どれだけ計画に忠実か、どれだけドキュメントを完全に仕上げて、配布し保管したかで、プロジェクト・マネジャーを評価しています。しかし、それは間違いです。

　計画について誤解している組織では、プロジェクト・マネジャーに「どれだけ正確に計画を守ったか」質問します。もっと重要な「要求された期間で最高の価値を実現できたか？」という質問をせずに、こうしたマイクロマネジメントにつながる質問をする企業には気をつけましょう。価値というのは、与えられた予算内で適正な目的を実現することや、顧客を喜ばせること、期待を上回ることによって判断されるべきです。間違った基準にしたがっていると、最終目標が実際に何を目的としていたのか、すぐに忘れてしまいます。

　計画の策定とドキュメントの完成だけに注力すると、進捗や成果を錯覚してしまいます。計画の実行は簡単であり、計画は正確であり、どちらもほとんど問題がないように思えてくるのです。

　プロジェクト・マネジャーがプロジェクトの参加者全員に対して、計画にあるアクティビティとスケジュールを何とかして守らせようとしている光景を何度か見たことがあります。状況の変化を認識したときには、新しい状況に基づいてアクティビティを再計画するようチームを導くことが有効なのですが、彼らはそれを理解していないのです。

　計画とドキュメントには、目標を達成するためにビジネスにとって重要な情報が含まれています。しかし計画とドキュメントだけでは、実際のところ全く役に立ちません。計画とドキュメントが焦点を当てている成果に基づいて行動しようとする人が必要ですし、計画とドキュメントに含まれている情報を知っておくべき関係者に伝えようとする人が必要です。

　したがって、伝えるべき適切なレベルの情報とは何なのか、その情報をプロジェクトの成果に関係するステークホルダーに伝える最善の方法は何なのかを検討することは、どんなときであっても重要になります。重要なデータを伝えるには、ドキュメントは最悪の選択である場合が多いです。最も豊かなコミュニケーションとは、直接顔を合わせることです。

　プロジェクト・マネジャーは、追跡可能性や監査要求を満たすのに必要なオーバーヘッドと、最終的にプロジェクトに価値をもたらすドキュメントに頼らないアクティビティとの間で、微妙なバランスを維持するという難題もこなさなくてはなりません。

　成功しているプロジェクト・マネジャーは、十分に計画して、必要な詳細だけを記録します。そして問題が起こっていることを理解し、新しいニーズや予期せぬニーズのために計画変更が必要な場合があることを認識しています。計画プロセスを経てできたドキュメントは、安定したプロジェクト進行のための手段であって、それ自体が目的ではないことを覚えておきましょう。

【73】アーンドバリューとベロシティは共存できるか

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　ソフトウェア開発者は、アジャイルで柔軟なアプローチが顧客の問題を解決し、ビジネス価値を生み、高品質なフィーチャーを開発するのにベストな方法だと確信を深めています。その一方で、PMO はプロセスばかり作って、非 IT 分野でうまくいっていたという伝統的な手法をプロジェクト・マネジャーに教え続けています。

　これら 2 つの流派（開発者と PMO）の報告を組み合わせて、上位マネジメントが両方のメトリックスの整合性をとる方法はあるのでしょうか？　はい、あります。万全ではありませんが。

　アーンドバリューになじみのない人もいるでしょう。これは毎週、毎月、四半期ごとに、進捗と達成したビジネス価値を数値的に追跡したものです。少々乱暴な言い方かもしれませんが、プロジェクト・マネジャー（および他のステークホルダー）はコスト要因を無視して、要求事項を定義します。そして、プロジェクト作業にかかる作業時間を見積もり、その時間見積りをスケジュールに変換します。

　さて、報告期間を 1 週間として、プロジェクトチームはその週に事前に定義した 40 時間分のタスクを完了できると見積もったとしましょう。金曜日の午後、チームは実際の進捗を報告します。すべてのタスクを 40 時間で完了できていれば、40 時間の価値を稼いだことになります（EV：Earned Value、アーンドバリュー）。これは 40 時間の作業相当の価値だと見積もられ、計画されたものです（PV：Planned Value、計画価値）。EV - PV が SV（Schedule Variance、スケジュール差異）となります。このケースでは、チームのスケジュール差異はゼロになります。

　しかし、もしチームの進捗が遅れるとスケジュールは遅れます。下流工程にいる作業者はそのことを連絡してもらう必要があるかもしれません。もしチームが早く完了したのなら、もともとの見積りが過大だったのかもしれません。資材受け入れや他のプロジェクト参加者は、予想よりも早くタスクに着手する可能性があることを知っておく必要があります。思い出してください。プロジェクトのスコープ（作業）はすでに決まっているのです。

　アジャイルのベロシティという用語は、開発者の生産性を評価したものを意味しています。開発者は先週の作業能率に基づいて（先週完了した作業量を超えないように）見積もった作業量を今週引き受けます。しかしながら、開発者は自分自身、そして先週選んだ仕事と比較されるだけです。長期スケジュールと比較されることはありませんし、他人の作業との関係からスケジュールし直すことはありません。その上、今週のタスクはもっと簡単かもしれませんし、ほとんどバグがないかもしれませんし、プログラマにとってはなじみ深いものかもしれません。

　ソフトウェア開発プロジェクトでは、最終製品の機能は確定しているわけではありません。したがって、実際のベロシティが見積りほど大きくなければ、スコープ（実現するフィーチャーの量）を縮小することもできます。

　マーケット上、製造上、トレーニング上の問題にまみれたソフトウェア開発プロジェクトからの報告をまとめているプロジェクト・マネジャーには、報告基準が必要です。一番シンプルな方法は、IT 部門にソフトウェアに取り組むためのまとまった時間（そして相応の給料）を与えることです。報告では、例えば 5 週分を見せましょう。IT チームがソフトウェアの週次報告をあなたに出すときには、完成したフィーチャーやストーリーも一緒に提出させます。そのあとあなたはそれをタスク名に変換して、報告に追加してください。これで、これらのタスクが計画通り 100% 完了していることを示せます。これによって、従来のスタイルの報告でもアジャイルの進捗を示すことが可能になります。

【74】スコープ変更に慣れよう

パベル・シムサ（Pavel Simsa）PMP

アメリカ、ワシントン州ベルビュー

　ソフトウェア開発プロジェクトとほかのプロジェクトに違いがあるとしたら、スコープ変更の発生がどれだけ不可避かという点でしょう。ほかのプロジェクトでもスコープ変更が決してないわけではありませんが、ソフトウェア開発ほど絶えずスコープが変動する業界はなかなか思いつきません。

　プロジェクトは 3 つの制約に支配されています。すなわち、コスト、時間、スコープです。

コスト：プロジェクトが困難に陥っているときには、さらに資金やリソースを追加投入しても助けになることはまずありません。作業員を 2 倍にすれば、半分の時間で穴は掘れるでしょう。しかし、ソフトウェア開発者を 2 倍にすることでプロジェクトが再び軌道に乗ることを期待するのは、有益どころか有害です。だれがどのコードに取り組むのか、どのようにするべきなのか、大きな混乱を招きます。したがって、コストは現状を維持する必要があります。

時間：プロジェクトには必ず「期日」があります。これはスケジュールに示された納期を意味しているとは限りません。公式にはだれも口には出しませんが、11 月にリリース予定の大規模セキュリティ製品を開発している場合、たとえ納品が 1 月まで延びたとしても、あなたの職はまだ大丈夫でしょう。チームは内心では、本当の「期日」は 2 月の、例えば「新しいリリースが発表される Black Hat セキュリティカンファレンスのとき」だと知っています。納期にはある程度の柔軟性があります。しかし、それもほんのわずかです。時間には制約があるのです。

スコープ：変化し続けるもの、それはスコープです。不思議なことに、スコープは最も柔軟性のある制約のひとつです。特定の顧客向けに構築したり、カスタマイズしたソフトウェアでなく、商用ソフトウェアを開発しているのであれば、なおさらです。理由は単純です。新しいソフトウェア製品のフィーチャーや機能には、「なくてはならない」ものと「あったらいいな」というものの 2 種類があります。通常「あったらいいな」というフィーチャーは「なくてはならない」フィーチャーの数倍以上あるものです。

　幸運なことに、「あったらいいな」というフィーチャーは最も削減しやすいものでもあります。もしあなたが超高層ビルを建設しているなら、プロジェクトの途中で「プロジェクトを再び軌道に乗せるために、アーキテクチャ計画にあった 60 個のストーリーのうち 40 個だけを構築することにしましょう。後で時間があるときに、残りの 20 個を追加すればよいでしょう」とは言えません。

　ソフトウェアの場合、「計画を変更しましょう。リリース 1 では 2 つの OS だけをサポートします。後でもともとサポートする予定だった残り 2 つを追加しましょう」と言うのは、比較的容易です。

　ただし、これは理想的な解決策とは言えません。では、どうすればこれを避けられるのでしょうか？

　正直に言うと、おそらく避けることはできません。これがソフトウェア開発プロジェクトの性質なのです。あなたにできることは、スコープをもっと具体的に計画することです。「あったらいいな」というフィーチャーと他のフィーチャーとの相互関係を最初から特定しておきましょう。相互関係は重要です。「あったらいいな」というフィーチャーを削減するとき、それが「なくてはならない」ものと関係があると、開発アーキテクチャの変更を余儀なくされるおそれがあるためです。

　最初から実行可能なスコープ削減を計画しておくことで、いざというときに何を削減すればよいのか、どうすれば簡単に削減できるのか、適切な判断を下せるでしょう。

【75】既製のソフトウェアを購入するということ

エルナーニ・マルケス・ダ・シルバ（Ernani Marques da Silva）MBA、PMP、PgMP

ブラジル、サンパウロ州マイリポラン

　今や既製のソフトウェアを購入するというのは、よくあることですし効果的でもあります。既製のソフトウェアは実装済みで、テスト済みで、箱から出せばすぐに使える状態にあります。他にも理由があります。既製のソフトウェアを使って開発および実装フェーズにかかる時間を削減することにより、組織は効率を高め、その効果を最適化できるためです。既製のソフトウェアを購入するということは、ソフトウェアを買うだけでなく、ソフトウェアを書いた会社のノウハウも買っているのです。

　もちろん、その組織特有の手続き、ポリシー、レガシーソフトウェア（例えば、会計システム、セキュリティソフトウェアなど）もあるでしょう。したがって、たいていの場合、新しいソフトウェアを会社のポリシーや手続きをサポートするようカスタマイズして、既存のレガシーシステムと統合する必要があります。多くの場合、ベンダーは実際に販売する前にカスタマイゼーションのための知識を手に入れます。

　これは大きな問題になるおそれがあります。綿密な調達プロセスにしたがっていたとしても、新しいソフトウェアの機能（定型処理、データ入力画面、レガシーソフトウェアとの統合など）がビジネス / 製品部門の要求通りに機能するか判断するのは、非常に困難なことです。調達プロセスが完了して、契約を交わし、プロジェクト計画が承認され、実行されても、テストフェーズになってようやく問題が持ち上がることもあります。問題はカスタマイゼーションに関するものかもしれませんし、最悪の場合、デモを見てそのソフトウェアが備えていると思っていた機能に関するものかもしれません。

　契約を交わす前には、以下のステップにしたがうことが非常に重要です。

会社のソフトウェアニーズに関する綿密なチェックリストを用意しましょう。

会社を訪問して、適正評価レポートを用意しましょう。

ベンダー評価レポート、テストケース、テスト計画を用意しましょう。

テストケースが完了していて、ドキュメント化されているか確かめましょう。

契約を交わす前に、テスト計画、テストケースをフォローしておきましょう。

　双方のギャップを埋めるための計画は、双方の会社によって理解され、承認されなくてはなりません。以上のプロセスに注意深くしたがい、ドキュメント化しておきましょう。そうすれば、どのソフトウェアを購入するべきか判断するための明確な情報や、ソフトウェアのカスタマイズに要する時間の見積り、それに使う実際の関連コストを得ることができます。長期的に見て、あなたはお金と時間を節約できるでしょう。

　ベンダーを選定して契約を交わすまで、かなりの時間がかかるように聞こえるかもしれません。実際のところそうなのですが、ソフトウェアがあなたの手元に導入されるのを待つよりも、契約を交すところまでに時間をかける方が望ましいのです。テストをしている最中に、あるいは最悪の場合には、ソフトウェアがエンドユーザーに配布された後に、あまりに多くの非互換性が見つかってしまうと、結局のところコストは跳ね上がります。

　そうならないためにも、既製のソフトウェアの購入を決定するときには、購入前に真のニーズを特定して、選定するソフトウェアの機能や技術詳細を調査することにもっと時間をかけましょう。そのソフトウェアプロバイダになじみがあろうとなかろうと、ソフトウェアが影響の小さなデスクトップアプリケーションであろうと会社の命運を左右する重要なサーバーサイドアプリケーションであろうと、このアプローチを活用しましょう。

【76】よいスポンサー、わるいスポンサー、ひどいスポンサー

ジョージ・ギルバート（Jorge Gelabert）PMP

アメリカ、コネチカット州ベルリン

　どんなプロジェクトにもスポンサーは必要です。スポンサーはプロジェクトを立ち上げる人であり、プロジェクトが成功裏に完了するよう資金提供する責任のある人です。通常それは、組織で地位の高い人であり、プロジェクトを支持し、プロジェクト・マネジャーの手に負えない課題に直面したときには仲裁に入ります。プロジェクトが大きければ大きいほど、強力なスポンサーの存在が重要になってきます。

　私の経験から言って、スポンサーには 3 種類あります。よいスポンサー、わるいスポンサー、ひどいスポンサーです。自分のスポンサーがどのタイプなのか認識し、うまく対応する方法を知っておくことが重要です。

　最悪なのは「ひどい」スポンサーです。通常このタイプのスポンサーは他部門からアサインされます。そのため、プロジェクトが実現するものやその用途に対して、彼らが個人的に投資しているわけではありません。このタイプのスポンサーはプロジェクト・マネジャーの言うことに耳を貸すことなく、自分をプロジェクトにアサインした上司が定めた気まぐれな締め切りにとらわれがちです。そして通常は、傍観者を決め込みます。アサインされるスポンサーは頻繁に変わる可能性があり、継続性がありません。

　このタイプのスポンサーを見つけるのは簡単ですが、その問題に対処するのは簡単なことではありません。プロジェクト・マネジャーはスポンサーと協力して、スポンサーの望みに答えなければなりません。残念ながら、たいていの場合、それはプロジェクトの成功とは一致していません。ひとつの解は、代理のスポンサーを見つけることでしょう。代理のスポンサーとは、プロジェクトの成果物から恩恵を得る人やグループであり、通常はスポンサーが提供してくれる助けを、代わりになって提供してくれるような人やグループのことです。あるいは、影響力のある人に対して、現在のスポンサーとともに自分たちのために仲裁に入るよう頼んでもよいでしょう。これがうまくいくかどうかは、プロジェクト・マネジャーとしてあなたが組織内にどれだけネットワークをもっているかに強く依存します。

　「わるい」スポンサーは、また違った形でプロジェクトを妨げます。彼らはプロジェクト・マネジャーが処理する日々の事柄にも関与してきて、チームメンバーと直接やりとりし、不適切なプロジェクト判断をするおそれがあります。これはプロジェクト・マネジャーの役割を横取りするもので、チームを混乱させることになります。あるいは、弱いスポンサーかもしれません。必要なリソースを提供できなかったり、ほかの業務を抱えこんでいたり、プロジェクトに指針を与える時間がないかもしれません。

　事前にスポンサーの役割と責任を明確に定義することで、「わるい」スポンサーという問題を回避しましょう。出しゃばりなスポンサーの場合、スポンサーの役割に関する「職務記述書」を提示することによって、彼らの振る舞いを変えさせられるかもしれません。弱いスポンサーであれば、何が期待されているのかを教えることで、その役割が果たせていないことを自覚してもらえるかもしれません。もしくはもっとよいスポンサーをアサインしてもらえるかもしれません。

　理想的な状況は「よい」スポンサーがいることです。よいスポンサーは自分の役割と責任を理解して、それに応じた振る舞いをします。よいスポンサーはプロジェクトの支持者であり、リソースを提供し、必要に応じて力を貸し、プロジェクト・マネジャーの判断をサポートします。彼らはプロジェクトの成功に個人的に投資している管理職なのです。

　スポンサーが「よい」、「わるい」、「ひどい」のいずれであろうと、プロジェクトを管理するのと同様、スポンサーを管理するのはプロジェクト・マネジャーの責任です。プロジェクトについてスポンサーに常に詳しく情報を伝えて、必要なときにだけスポンサーを巻き込みましょう。スポンサーにプロジェクトをコントロールさせてはいけません。スポンサーのタイプを認識して、それに応じて備えることを学びましょう。

【77】約束以上にすべきか、約束以下にすべきか

ジョー・ゼネビッチ（Joe Zenevitch）

アメリカ、ニューヨーク州ニューヨーク

　プロジェクトの終わりに、約束していたもの以下しか納品できなければ、あなたはひどいプロジェクト・マネジャーになります。約束していたもの以上を納品できれば、あなたはヒーローになります。実のところ、あなたは約束したのとちょうど同じものを納品するよう努力すべきです。多くてもいけませんし、少なくてもいけません。

　新米のプロジェクト・マネジャーは愛想良く、経営者や顧客にフィーチャーを追加させ続けます。たとえそれによって、チームのキャパシティが小さくなったとしてもです。経営者はプロジェクト・マネジャーが事態を掌握していると信じて、この際だからと新しいフィーチャーをどんどん追加していきます。

　未熟なプロジェクト・マネジャーは弱みを見せることを恐れ、無我夢中に頑張って何とか実現しようとします。しかしプロジェクトの最終日が近づくにつれ、フィーチャーリストを完了できないことが明らかになっていきます。すると仕方なく、フィーチャーを削減していきます。必ずしも最近追加されたフィーチャーが削減されるとは限りません。以前は喜んでいた経営者も、プロジェクトの終了時か、少なくともリリース後には、プロジェクト・マネジャーに懲罰を与えることを考え始めます。

　経験豊富なプロジェクト・マネジャーであれば、最初から断固たる態度をとる必要があることを知っています。彼らは新しいフィーチャーやスコープ変更といったものに抵抗します。ビジネスオーナーに対して「限られた数のフィーチャーしかリリース†には収まりません」とくぎを刺すのです。新たなフィーチャーが出てきたら、将来のリリースに延期するか、計画済みのフィーチャーと入れ替えなければなりません。

　経験豊富なプロジェクト・マネジャーであれば、「高、中、低」というフィーチャーの分類をしません。顧客は何もかも「高」にしてしまうおそれがあるためです。彼らはビジネス価値に基づいたフィーチャーの優先順位リストを好んで使います。すぐれたプロジェクト・マネジャーはビジネスオーナーに対して「遅れが発生した場合に、優先順位リストの下の方にあるフィーチャーは、このリリースでは実現できないかもしれません」とくぎを刺します。こうしたやり方は、ビジネスオーナー、特にフィーチャー同士の衝突について学んでこなかった人にとって、苛立ちの原因となるでしょう。ですが時間がたてば彼らもこうしたプロセスに慣れて、プロジェクトの現実として受け入れるようになります。

　もちろん、経験豊富なプロジェクト・マネジャーであれば、プロジェクトの途中で変更が発生することを想定して、あらかじめ予備費を計画に組み込んでいます。予備費は懐にしまってあり、顧客やチームにすら明かさないこともあります。予備費は貴重なリソースと同様に管理され、抵抗に耐え残ったフィーチャーだけが使うことを許されます。

　このときビジネスオーナーは、最終的に自分の願いを叶えてくれたとプロジェクト・マネジャーに感謝します。開発の最終段階になっても予備費が残っていれば、プロジェクト・マネジャーはその「蓄えを開放」して、新たなフィーチャーをいくつか追加するかもしれません。なぜもっと早くそうしなかったのかと問い詰めるビジネスオーナーもいるでしょうが、たいていは期待していなかった追加フィーチャーが受け取れることを喜んでくれます。

　さて、プロジェクト・マネジャーはリリースを完了しました。チームは約束していたものを実現できました。追加のフィーチャーまで提供できたかもしれません。ビジネスオーナーは喜んでいます。チームも喜んでいます。プロジェクト・マネジャーの評判にも傷はつきません。さあ、リリース完了パーティを始めましょう。

【78】プロジェクト・マネジャーは契約管理者である

ファビオ・テイセイラ・デ・メロ（Fabio Teixeira de Melo）PMP

メキシコ、ベラクルス州コートザコアルコス

　あなたはプロジェクト・マネジャーとして変更管理に責任があります。あなたは要求をドキュメント化し、変更を実行するためのプロセスをまとめます。しかし、変更が起こったことをあなたが知らなければ、どうやって変更を管理できるのでしょうか？

　クライアント側はあなたのチームの担当者と直接コンタンクトを取ることがあります。担当者はクライアントを満足させようと、契約上の義務のことをよく知らずに、追加のトレーニングセッションに合意したり、ソフトウェアを変更したりします。そして、彼はそのことをあなたに伝えるのを忘れたり、手遅れになってから切り出すのです。こうした変更には無害なものもあるでしょうが、問題を引き起こすものもあります。例えば、黙ってソフトウェアのフィーチャーの一部を変更すると、その変更がマニュアルに記載されないままになるおそれがあります。これはマニュアルの書き直しや印刷のやり直しを引き起こし、想定外の時間とコストがかかることになります。

　クライアント側とプロジェクトチームの連絡を禁止したくなるかもしれませんが、それではコミュニケーションが台無しになります。契約には、クライアントがチームメンバーと話をする権利の有無について、通常は記載されていません。それでは、チームメンバーとクライアントが連絡を取るのを、プロジェクト・マネジャーはどうやってコントロールすればよいのでしょうか？

　ドキュメント化されていない変更が実施されないよう、すべてのチームメンバーはスコープや期間、双方の権利と義務を含めた契約について、熟知しておく必要があります。契約上のポイントと今後の変更を全員に通知する仕組みを用意して、全員がクライアントの要求を分析できるようにしておくべきです。そのためには、変更管理とプロセス処理をドキュメント化し、それをチームメンバーに周知させる必要があります。

　チームメンバーに重要な契約事項と変更管理プロセスについて教えるときには、ワークショップが非常に効果的なツールになります。トレーニングのためのワークショップをまず最初に開きましょう。キックオフミーティングのアジェンダに、そのためのセッションを入れておいても構いません。いずれにせよ、プロジェクトのチームメンバー全員がそれについて知っていることを確認しなくてはなりません。

　特に注意が必要なのは、プロバイダ、サプライヤー、下請け業者といった、プロジェクトで仕事をしているサードパーティです。クライアントが彼らにアクセスするのをコントロールするのは困難であり、細心の注意を必要とします。彼らとクライアントとのあいだに独立したビジネス関係があるときもあります。下請け業者がクライアントの要求を受け入れて変更を実施し、元請けであるあなた宛てに請求書が送られるというのは、めずらしい話ではありません。

　こうした問題に対処する一番の方法は、下請け業者とクライアントが直接スコープについて交渉することを避けることです。プロバイダにも呼び掛けて、プロジェクトにかかわる全員に、チームとクライアント双方の契約上の関係について教えるよう提案しましょう。そして、それらを変更管理プロセスに取り入れましょう。

　忘れないでください。プロジェクトの成功は、クライアントの満足が第一です。重要なのは、変更を認めないことではなく、コントロールすることです。そのためにチームメンバーがやるべきことは、潜在的な変更を見つけて、変更管理プロセスを通してプロジェクト・マネジャーであるあなたに伝えることです。そうすれば、あなたはクライアントとの関係をうまくコントロールし、時間とコストを犠牲にすることなく、彼らのニーズを満たせるでしょう。

【79】重要だが緊急ではないこと

アレックス・ミラー（Alex Miller）

アメリカ、ミズーリ州ボールウィン

　個人の生産性に関する名著、スティーブン・コヴィーの“The 7 Habits of Highly Effective People”（和書『7 つの習慣』）では、縦軸を重要度、横軸を緊急度としてアクティビティを分類しています。これには 4 つの組み合わせがあります。

重要でかつ緊急であること：ヴェロキラプトルの襲撃。

重要だが緊急ではないこと：今後の製品戦略の準備、製品上問題のある部分の改良。

重要ではないが緊急であること：砂糖を借りようと電話をかけてくるお隣さん。

重要でも緊急でもないこと：YouTube、Web サーフィン。

　それでは最大限に効率を上げる方法について調べていきましょう。

　最初に、重要でも緊急でもないタスク（4）（「サボること」に分類しても構いません）について考えましょう。これらのアクティビティのほとんどは、単純に落としてしまって構いません。その名の通り、重要ではなく（なぜやるのですか？）、緊急でもありません（だから、きっと待てます）。もし 4 番目に分類されるアクティビティがあなたの会社で必須とされているなら、どうしてやる必要があるのか上司に問うべきです。賢明なマネジャーであれば、人に重要でない作業をさせません。

　重要ではないが緊急であるアクティビティ（3）も削減するよう努力すべきです。ひとつのテクニックは、その発生源に対して、あなたの自由なタイミングで処理できるよう頼むことです。あるいは、邪魔されないように環境を変えることです。電話やメールは通常、その重要度によらず緊急なものとして扱われます。ボイスメールやメールフィルターを使うことによって緊急度を下げましょう。

　重要でかつ緊急であるアクティビティ（1）は通常、発生時に処理しなくてはなりません。しかし、これが発生する原因を解消するための仕組み作り（リスク防止）に取り組むべきです。例えば、もしバグが稼働中のシステムにエラーを引き起こす原因となっているなら、あなたはバグの原因を分析して、バグが二度と発生しないよう品質管理すべきです。重要でかつ緊急であるアクティビティを削減する一番の方法は、それが発生する根本原因を解決するためのフィードバックループを設けることです。

　重要だが緊急ではないアクティビティ（2）は、あなたの仕事の中で最も重要なものです。これこそが、あなたの知識労働が価値を生み出すところです。もしこれらのアクティビティのうち 25% 以上を完了できれば、上司は給料を上げてくれるはずです。

　あなたはプロジェクト・マネジャーとして、重要だが緊急ではないアクティビティにチーム全体の作業を集中させることのできる唯一の立場にいます。意味のないタスク（4）や、ほかのチームからの緊急だが重要ではない要求（3）を減らすことがあなたの仕事なのです。マネジャーとして、あなたはこうした要求に「ノー」と言う権限があります。自分でやるか、代わりにやる人を雇うか、さもなければ、単に「ノー」と言いましょう。

　チームは重要でかつ緊急であるアクティビティ（1）を無視することはできませんが、もしチームが問題の消火活動にすべての時間を費やしているなら、あなたは火事の原因になっている問題を修正する必要があります。すぐには効果が見えないかもしれませんが、時間がたつにつれ、徐々にチームはプロジェクトの成功を左右する、重要だが緊急ではないアクティビティに時間をかけられるようになるでしょう。

【80】プロセスについて教える

リチャード・シェリダン（Richard Sheridan）

アメリカ、ミシガン州アナーバー

　ソフトウェアプロジェクトのプロセスが本当に効果を発揮するためには、すべてのステークホルダーとのあいだに共通理解がなくてはなりません。共通理解を確実に得るための方法のひとつとして、私はプロジェクトにかかわるステークホルダー全員にプロセスを正しく教えるようにしています。ステークホルダーには、プロジェクトのスポンサー、数名の重要と思われるユーザー、プロジェクト・マネジャー、開発者、デザイナー、QA 専門家らが含まれます。彼らを同じクラスに集めて、一緒にプロセスについて講義をするのです。

　私たちはプロジェクトの途中で、プロセスに関する講義をクライアントに受けるよう求めます。なぜだと思いますか？　どうやってチームを効率よく動かしているか、スポンサーにもきちんと理解してほしいためです。私たちは毎週、見積り、計画し、発表するというアジャイルプロセスを導入して、非現実的な期待と戦っています。

　スポンサーは見積りのプラクティスについて学び、見積りの扱い方を知ります（見積りは固定価格ではないのです）。そして、見積りに基づいてスコープを選びビジネス価値と照らし合わせる、というシンプルな計画テクニックについて学びます。彼らを積極的に毎週の「発表会」に参加させることで、早期に誤解が判明するようになります。

　かつて私がプロセスについて教えているとき、見積りに関する説明責任のルールについて説明するため、クラスに出席した 2 人の開発者にこう言いました。「テッド、ケリー、あなた方開発者はたとえ見積りを間違っても会社から罰せられることはありません」　それから出席しているプロジェクト・マネジャーに向かって、「リサ、もし彼らが見積りを間違っても、開発者に無理強いしたり罰したりすべきでないことを理解していますよね」と言いました。それから部屋にいる資金を提供してくれるクライアントに向かって、「さて、ジェン、もし見積りをオーバーしたら、もっとお金を出すことを理解していますよね？」と問いかけました。

　もちろん、この時点では、2 人の開発者は何だかごまかされているように感じ、クライアントはプロジェクトをキャンセルしようかと考えています。そこで私は、見積りに関する説明責任の最後の「ルール」について説明します。「ケリー、テッド、あなた方にやってほしいのは、見積りが間違いそうだと思ったら、すぐにはっきりとプロジェクト・マネジャーに伝えることです。リサ、あなたはプロジェクト・マネジャーとして、彼らとタスクについて議論してください。見積りのあと、タスクのスコープを変えていないことを確かめるのです。もし実際に見積りが間違っていれば、クライアントに電話して、どう対処すべきか尋ねなければなりません。」

　最後に私はクライアントに向かって、「ジェン、これが、この授業からあなたが学ぶことです。見積りをする環境が信頼でき、自分の見積りを満たすことを楽しむ熱心なチームメンバーがいれば、積極的に見積もれば見積もるほど短時間で仕事ができるようになります。しかし、ときには間違いがあることも受け入れなければなりません。もし間違えたときには、お金を使い果たしてしまう前にあなたに知らせます。」

　プロセスについて教えることは、プロジェクト強化に非常に有効な手段です。

【81】ステータスという間違った考え

ウディ・ダーハン（Udi Dahan）

イスラエル、ハイファ

　私は最初のプロジェクトに成功したあと、自信満々で 2 番目のプロジェクトに取りかかりました。これは大きなプロジェクトでした。私の雇用主にとって、はるかに戦略的なプロジェクトで、私はさまざまな専門分野にわたる人たちで構成されるチームを管理することになりました。そこで初めて、私は自分のスキルが役に立たないことを実感しました。非常に興味深いことに、最終的にプロジェクトが失敗した原因は、私がチームのステータスレポートを信頼していたことでした。

　プロジェクトが始まってから 2 か月ほどたったころ、インフラストラクチャチームのリーダーが「私たちが下したアーキテクチャ上の想定のいくつかに根拠がないことがわかりました」と私に打ち明けました。彼は「でも月末までには軌道に戻せます」と私に保証しました。彼の保証と私が用意した予備バッファがあるにもかかわらず、私は何かがおかしいという予感を振り払うことができませんでした。

　月末になって、そのチームリーダーのフォローアップをしました。彼はいかにしてリファクタリングが予定通り完了したか、いかにして開発者が来月の目標を達成することになっているかを私に説明しました。インテグレーションチームのリーダーと話し合ったときに確認すると、彼女の目からもすべてうまくいっているように見えると教えてくれました。モジュールは仕様にしたがっており、それぞれ十分にテストされ、アーキテクチャの各層は最初のインテグレーションに向けて十分に安定していました。

　かなりでこぼこした最初のインテグレーション（たいていの場合がそうですが）とお決まりの QA サイクルの結果、ほとんどすべてのユースケースに重大なバグがあることがわかり、私はかなり驚きました。15 か月のスケジュールのうち 5 か月ほどのところにいましたが、プロジェクト作業の 3 分の 1 が完了するには遠く及びませんでした。

　それでも私は、チームメンバー全員が協力して予定通りに終えてくれるものと信じていました。システム稼動日の 1 か月前には、自分の仕事の少なくとも 95% が完了していると全員が報告しました。しかし、システムを実際に試しているユーザーのひとりを呼んだところ、彼女ははっきりとこう言いました。「いろいろなところに問題があります。これで仕事をするのは耐えられません」　どう考えても、私にはプロジェクトの 95% が完了しているようには聞こえませんでした。

　経験豊富なプロジェクト・マネジャーであるパトリックが、「この窮地からプロジェクトを救う」ために呼ばれました。プロジェクトの救世主（そして今は私のメンターです）であるパトリックは、事態を軌道に戻しながら、ステータスという間違った考えについて私に説明してくれました。「完了」を定義するのは顧客なのです。ステータスレポートではないのです。

　データベースチームは 95% が完了していると報告しましたが、開発したものが実際にユーザーにとって使いものになるかには、何ら関係がありませんでした。たとえステータスレポート上は完璧であるように見えても、私たちは間違ったプロジェクト進捗を見ていたのです。結局のところ、プロジェクトは最初から失敗する運命にあったのです。なぜなら私がプロジェクトの目標をきちんと描けていなかったためです。

　私はようやく、なぜフィーチャーを開発したら、それが顧客視点で価値を高めているかをユーザーに評価してもらう必要があるのか理解しました。そうすることで、プロジェクトのステータスレポートはアーンドバリューレポートに変わり、どれだけ仕事が残っているかを示すだけでなく、生み出されたアーンドバリューの真の割合を示すようになります。

【82】みんなが聞きたいことは何ですか？

マーサ・レガーレ（Martha Legare）MBA、PMP

アメリカ、ジョージア州アトランタ

　プロジェクトのコミュニケーションは、「歩き回ることによるマネジメント」から正式なプレゼンテーションまで、さまざまな形をとります。私はコミュニケーションこそがプロジェクトで一番重要なアクティビティだと考えています。

　プロジェクトの情報を人から人へと伝えるために、一番難しいのに一番よく使われている方法は、正式なプレゼンテーションです。人前で話すのは死や歯医者よりも恐ろしいという調査結果まであります。

　たいていのプレゼンテーションは長すぎで、退屈で、詳細に入り込みすぎています。あなたの最近のプレゼンテーションを調べてみましょう。「パワーポイントによる死」（Death by PowerPoint®）をまねいていないか、確かめてみてください。もし答えが「イエス」であれば、もっと聞き手に伝わるようプレゼンテーションを再設計しましょう。「達成したいことに一番適したプレゼンテーションは何だろうか」と自問しましょう。もし少人数のグループで意見交換したいのであれば、フリップチャートやホワイトボードを使って、関心のあるところや合意がとれたところを記録するというテクニックが役に立ちます。

　もし幹部に具体的なプロジェクトを承認してほしい、もしくは新しいプロジェクトの感触について同意してほしいのなら、マルチメディアスライドショーを使うとよいでしょう。どんなテクノロジーを利用するにしても、あなたが聞き手に売り込むのはアイデアであって、スライドやポスター、レーザー光線ショーではないことを自覚しましょう。

　アイデアを効果的に売り込むためには、左脳の論理と右脳の創造の両方をかみ合わせる必要があります。統計的な証拠を使いましょう、ただし、記憶に残るような形で見せましょう。カラーチャートやグラフを使うとわかりやすいでしょう。箇条書きは少しだけにしましょう。

　箇条書きの背景にあるストーリーを説明するのです。文字を使いすぎて、出席者が自分で読んだあとに、あなたが大声で読み上げるようであってはいけません。

　直接パワーポイントに書き始めるのではなく、事前にホワイトボードや付箋紙を使ってプレゼンテーションを練り上げましょう。付箋紙を使って何時間もブレインストーミングする作業をムダだと思ってはいけません。付箋紙を使うと全体像を見ながらアイデアを簡単に並べ変えることができます。付箋紙を「類似性」のあるグループにまとめて、同じような概念を組み合わせることで、どうやってアイデアを記憶に残るストーリーへとまとめ上げるか考えましょう。常に「中心となるポイントは何なのか」、「聞き手にとってなぜそれが重要なのか」という質問に立ち返りましょう。

　好奇心を喚起したり、思いがけないものを見せたりして、聞き手の関心を引きつけてから、数字が聞き手に伝わるよう具体的に図示しましょう。例えば、ウォールストリートジャーナルのある記事では、会社に多大な損害を与えた企業幹部について、もし 100 ドルの新札を積み重ねると、その損害額はマディソンアベニューにあるオフィスの 92 階に達するほどだと説明しました。これが記憶に残るイメージです。

　疑わしいときには、要点以外のすべてを削除してしまいましょう。詳細な情報を要求されたときのために、あとで読める資料を用意しても構いません。持ち帰り用のドキュメントがあれば、事実がゆがんで伝わることはなくなります。このアプローチを使うと、あなたは要点を簡潔に提示できるようになります。そして、社長がゴルフのスタート時間のためにプレゼンテーションを 30 分から 5 分に縮めるよう要求したときも、その場でうまく要約できるはずです。

【83】モラルの重要性を認識する

デイビッド・ボック（David Bock）

アメリカ、バージニア州レストン

　モラル（やる気）というのは、絶対に必要なもののひとつですが、育てるのも評価するのも難しいものです。モラルの高いチームは時として楽しげにすごい成果をあげますが、モラルの低いチームはそうではありません。モラルの高さは、よりよい職場のためだけでなく、生産性の高いチームのためにも必要です。

　数年前、私はモラルの高いチームと仕事をしたことがあります。当時のオフィスは、職場というよりも友人たちとのコミュニティのようでした。チームの生産性は非常に高いものでした。危機的状況ではさらなる努力を必要とする場合もありましたが、チームメンバーはそうした努力を進んでやってくれました。

　数年後、同じチームを社内のカフェテリアで見かけたのですが、どうも楽しそうには見えませんでした。チームメンバーはお互いに交流しておらず、身振りはぎこちないものでした。近づいてみると、彼らはアイスクリームを片手に、トッピングに「カラフルな粉砂糖でなく、チョコレートのかけら」しかないことに不満を漏らしていました。この変わり様について考えてみましょう。同じチーム、同じプロジェクトなのに、彼らのモラルはすっかり変わっていました。かつては楽しげに残業していたのが、今では無料のアイスクリームにさえ不満を漏らすようになったのです。

　どうしてこんなことになったのでしょう？　チームに新しいマネジャーがやってきて、間違った判断をしていたのです。彼の間違った判断はチームを間違った方向へと導き、必要のない余計な仕事を作り出していました。シニアマネジメントはチーム全体を非難しました。やがてマネジャーが責任を負わなくなると、チームは信頼を失いました。そのプロジェクトは「仕事が増えて、楽しみが減り」、モラルは損なわれました。

　マネジャーは状況を改善しようとしましたが、さらに状況を悪化させることになりました。彼はチームのモラルが高かったとき、ときどきみんなで映画に出かけていたことを思い出しました。そこで「映画の夕べ」を設けました。しかしチームはお互いに交流することに関心がなく、参加者はわずかしかいませんでした。するとマネジャーは「チームに参加」しなかったことをパフォーマンスレビューに記録し始めたのです。これはさらにモラルを低下させる結果になりました。

　この場合、原因はマネジャーにありました。彼の行動は逆効果をもたらしていました。チームが交流しているから、チームのモラルが高いわけではありません。モラルが高いから、みんな進んで交流しようとするのです。

　私はコンサルタントとして、モラルを測定する方法を考えようとしたことがあります。「午後 5:05 と午後 4:55 に駐車場にある車の台数比」や「オフィス 1 平方フィート当たりに見えるディルバートの漫画数」といった測定基準はどうだろうかと、冗談を言っていたものです。しかし、モラルは測定されるものではないと悟りました。モラルこそが評価の結果なのです。私たちはチームの態度を測定しています。モラルはチームのリーダーに対する信頼、チームメイトに対する信頼、物事を成し遂げる自分の能力に対する信頼の尺度なのです。

　ソフトウェアプロジェクト・マネジャーとして、あなたの仕事はモラルの高い職場づくりをすることです。もしチームメンバーがあなたをリーダーとして尊敬し、あなたに話せば結果が変わる思えば、モラルは改善されるでしょう。

　モラルが高くなればなるほど、従業員の満足度も高まり、離職率も低くなり、生産性も高まります。それに、幸せな人たちがそばにいる方がずっと気持ちがいいでしょう。そう思いませんか？

【84】ステークホルダーをずっと参加させる

ルークマン・ラワル（Lukeman Lawal）M.ENG、MNSE、R.ENGR.

ナイジェリア、ラゴス、レッキ

　ステークホルダーとの良好な仕事関係を保つことは、プロジェクトの成果に大きな影響を及ぼす極めて重要なことです。ステークホルダーとは、組織の内外にいるプロジェクトの成功に影響を及ぼす個人やグループ、および、プロジェクトによって影響を受ける人たちのことです。

　プロジェクト・マネジャーはステークホルダー参加計画を作成するべきです。これには、ステークホルダーの特定、その影響度の評価、プロジェクトに対する好感度の評価などが含まれます。この計画を使って、意図的にステークホルダーの支持を確立しましょう。

　ステークホルダーをプロジェクトに早期に参加させて、プロジェクトが完了するまで参加させ続けましょう。彼らのプロジェクトに対するビジネス要求について把握できているか確かめましょう。ほんのわずかな最上位のステークホルダーだけでなく、重要なステークホルダー全員のニーズをうまく調整するよう努力しましょう。

　キーとなるステークホルダーが声の大きなプロジェクト支援者になってくれるよう、彼らのニーズを確認しましょう。また、ステークホルダーにとってもチームにとっても、プロジェクトを成功させるにはどうすればよいのかを見い出すことは非常に大切なことです。

　キーとなるステークホルダーのニーズをプロジェクト計画に反映したら、プロジェクトに必要なリソースを用意することで彼らのコミットメントを示すよう要求しましょう。こうすることで、プロジェクトをやめさせたいと思っている、お金やサービスも提供しない外部のステークホルダーと戦うための投資家団体を得ることができます。

　ステークホルダーマネジメントをうまくやるため、プロジェクトチームに責任者をひとりアサインし、重要なステークホルダーと適度にコミュニケーションをとって、彼らを積極的にプロジェクトに参加させるとよいでしょう。コミュニケーションの頻度、コミュニケーションの内容、コミュニケーション方法を記録しておくために、ステークホルダーコミュニケーション計画を作成して活用しましょう。コンタクトの方法と頻度はステークホルダーごとに違ってくるかもしれません。

　部門間の衝突を最小限にするために、弱小ステークホルダーとも調整のためのミーティングを計画しましょう。ステークホルダー担当は、重要な部門やグループが、きちんとコアチームあるいは拡大プロジェクトチームにリソースとして参加しているかフォローアップしましょう。

　ミーティングのたびに意思決定者とステークホルダーの成功基準をレビューして、矛盾なく調整できていることを確認しましょう。

　この他にもいくつかアドバイスしておきます。

たとえ合意できなくても、ステークホルダーのビジネスニーズを尊重しましょう。

ステークホルダーとの信頼を築くため、取り扱いがデリケートな問題に関する機密性について確認しておきましょう。

プロジェクトを支援するためにステークホルダーと連携しましょう。

ステークホルダーを積極的に意味のある形で参加させましょう。

ステークホルダーにアイデアを求め、彼らからのインプットを活用しましょう。

ステークホルダーに情報を提供し続けましょう。

プロジェクトに積極的なステークホルダーを利用して、できれば目に見える形で投資させましょう。

　失敗や妨害があることを想定して、リスク対応についても検討しておきましょう。道には必ずでこぼこがあります。完璧にしようと自分やステークホルダーにプレッシャーをかけてはいけません。リスクが顕在化したとき（問題が起こったとき）に対処して、そこから教訓を得ればよいのです。二度と同じ問題を起こさないようにすることが大切です。

　ステークホルダーを早期にプロジェクトに参加させて、プロジェクトが完了するまでパートナーとして参加させ続けることは、致命的問題を避けるのに役立ちます。ステークホルダーはプロジェクトマネジメントの詳細を理解していないかもしれませんが、あなたが彼らのビジネス目標を達成する手助けをすることで、彼らはあなたを支持し、チームのすばらしいパフォーマンスを賞賛してくれるでしょう。

【85】計画の価値

デリー・ジンメル（Derry Simmel）PMP、MBA、FLMI

アメリカ、サウスカロライナ州チェイピン

戦いに備えるにあたり、私はいつも計画は役に立たないと思っている。それでも、計画することは不可欠だ。

——ドワイト・デーヴィッド・アイゼンハワー、アメリカ第 34 代大統領

　ジョージ・スミス・パットン将軍の「どんな戦術も眼前の敵には無力だ」という言葉が好きなプロジェクト・マネジャーがいます。彼らはこの言葉を、計画するのは時間のムダだという言い訳にしています。これにはほとんど根拠がありません。こうした姿勢は数多くのプロジェクトを失敗へと追いやってきました。計画することよりも行動を支持するマネジャーは必ずいるものです。行動することは魅力的で、計画することは退屈だからです。

　確かに計画することは退屈かもしれませんが、一連のドキュメントを作ることだけが目的ではありません。アイゼンハワー大統領は、計画するという訓練はプロジェクトについて考えるきっかけになると考えていました。計画セッションはプロジェクトに対する深い理解をもたらします。ここでは、仕事、予算、リソース、リスク、スケジュールなどを考慮します。計画することにより、成功するために何が必要とされているのか、もっとうまく見抜けるようになります。計画は目標が達成可能かどうか、どのように達成可能なのかを理解するのにも役立ちます。完成した計画は、プロジェクトについてコミュニケーションするための貴重な手段にもなるのです。

　計画ドキュメントには議論され、決定されたことを記録しておきます。お固い行動指針を示すためにあるわけではありません。残念ながら、当初の計画はすぐにその価値と妥当性を失うでしょう。初期計画と実行計画の 2 種類があるのはそのためです。

　初期計画の目的は、プロジェクトの進路を定めることにあります。初期計画ではプロジェクト全体を俯瞰しつつ、すべての領域（リスク、時間、品質など）について検討します。そして、プロジェクトの意図を定めて、目標までの妥当な道筋を導き出すのです。新たな情報が得られて状況が変化すると、プロジェクトの進路も変更されます。これは自然なことです。ただし目標を変えることはめったにないことであり、もし変えるのであればくれぐれも慎重にすべきです。

　初期計画を作るためには、プロジェクトについてよく知り、リスクと制約について理解し、成功への道づくりをする必要があります。プロジェクト・マネジャーとして、チームを計画セッションに参加させましょう。初期段階で相互理解を築いておくことは極めて重要です。「敵とのファーストコンタクト（戦闘の開始＝プロジェクト問題との遭遇）」が起きた直後はなおさらです。

　「ファーストコンタクト」は計画してきたことが報われるときです。なぜなら全員が計画を理解しているため、各メンバーは計画の意図に合わせて自主的に対応できるためです。全体の目標と制約を知ることによって、チームはすばやく適切な判断が下せるようになります。これが実行計画を始めるタイミングとなります。

　実行計画プロセスとは、既存の計画をベースとして、新たな現実を反映させるために修正することです。5 月 1 日に開発を始めるよう計画していましたが、6 月 1 日になるまで開始できなかったとしましょう。あなたはどうやって時間の穴埋めをしますか？　5 月に着手可能な他のタスクにリソースをアサインしますか？　もっと時間やお金が必要ですか？　これが実行計画の検討です。計画して、調整して、実行するのです。

　計画するたびに、あなたはプロジェクトについて検討し、周囲と協議します。これらは必要不可欠なアクティビティであり、必ずコスト以上に大きな利益をもたらしてくれるでしょう。

【86】「メッセンジャー」にならない

マット・セコスキ（Matt Secoske）

アメリカ、ネブラスカ州オマハ

　プロジェクト・マネジャーの一番重要な役割のひとつは、いろいろなチームメンバーが遠慮なく話し合えるようファシリテートすることです。残念ながら、私はこれとは逆のことが起こっているプロジェクトをいくつも経験してきました。プロジェクト・マネジャーがコミュニケーションの流れのボトルネックになっていたのです。そうしたプロジェクト・マネジャーは「メッセンジャー」です。チームメンバーからチームメンバーへと、重要な情報をそのまま伝えるだけの配達人です。

　プロジェクトが進行するにつれて組織的に動けるようになるためには、最終的なミッション実現に向けて、情報を水や空気のようにプログラムコードへと提供できるよう成長しなくてはなりません。チームメンバーは絶えず情報交換しなくてはなりません。ところが、ステークホルダーがすべての情報をプロジェクト・マネジャー経由でしか伝えられないとすると、これは決して乗り越えることのできない問題になります。

　プロジェクト・マネジャーは最新の情報を託されても、その情報を受け取るべき開発者全員を正しく理解していないかもしれません。メッセージの送り手はプロジェクト・マネジャーに伝えたことで、自分の義務を果たせたと思っています。あとになってコミュニケーション漏れが見つかっても、メッセージの送り手はすでに新しい課題に取り組んでいて、以前伝えたことを正確には思い出せないかもしれません。プロジェクト・マネジャーが自分では理解できない技術的報告に圧倒されているようだと、プロジェクトにおける情報伝達の司令塔としてはすぐに機能しなくなるでしょう。

　メッセンジャーというよりも、むしろ有害な役割を果たすプロジェクト・マネジャーもいます。そういう悪意はないけれども無知なプロジェクト・マネジャーは「スクランブラー」です。プロジェクトが進むにつれ、プロジェクトを円滑に進めるために必要な非技術的な情報量も増えていきます。開発者はビジネスルールについて知る必要があり、ビジネス推進者は成果物の状態について知る必要があります。他の人たちもスケジュール、コスト、品質基準について、プロジェクトが今どんな状態にあるのか理解する必要があります。

　情報量が増えるにつれて、プロジェクト・マネジャーも全知全能ではないため、間違って伝える可能性が増えてきます。こうしてプロジェクト・マネジャーはスクランブラーになります。例えば、一見するとプロジェクトにほとんど影響を及ぼさないように見えるビジネスルールでも、その真意がわかると実際には大きな障害になるものもあります。そして、そのダメージを修復するためには、コードベースにかなり大きな変更が必要になる場合もあるのです。

　プロジェクト・マネジャーは、適切なときに、適切な話題について話すために、適切なステークホルダーを集める必要があります。このために他部門の人たちの都合のよい時間を見つけるのは大変だと思うかもしれません。実際のところ、あなたはどうしていますか？　プロジェクト・マネジャーは次のように言って、スケジューリング問題を解決しようとします。「シェリー、この件のことだけど、これからボブのところに行って回答をもらってくるよ」　ちょっとした非技術的な質問であれば、これでもうまくいくでしょう。しかし、こうした小さな成功は、気づかぬうちにあなたをメッセンジャーやスクランブラーに変えていくことに注意してください。通訳すると必ず何かが失われます。そして、その影響を収拾しようとすると、必要以上にムダな時間がかかるのです。

　クリアでオープンなコミュニケーションのためのチャンネルを提供し、そこでなされた議論と判断を記録に残すことによって、チームメンバー全員が直接交流を深めることができます。これはプロジェクト・マネジャーがメッセンジャーやスクランブラーになるのを防ぎ、ソフトウェアプロジェクトを前進させる力となります。

【87】成果物を効果的に管理する

エルナーニ・マルケス・ダ・シルバ（Ernani Marques da Silva）MBA、PMP、PgMP

ブラジル、サンパウロ州マイリポラン

　プロジェクトはひとそろいの成果物で構成されます。それが完成すると、製品、サービス、成果すべてが完了することになります。ソフトウェア開発プロジェクトの場合、すべての構成要素を統合することは、適切に機能する最終成果実現のために極めて重要です。もちろん、あなたが作っているソフトウェアの種類によって、その構成要素も変わってきます。成果物は次のように、積極的に計画され、コントロールされ、監視され、管理されるべきです。

成果物を特定する。成果物を特定することで、ソリューション全体のアウトラインを示し、開発や納品されるべき順序を特定し、開発と納品を監視 / コントロールするのに使うべきメトリックスを特定します。計画されたベースラインとメトリックスに対する進捗を、能動的にモニタリングしましょう。
成果物を部分的なコードのかたまりに分割して、それぞれが特定のソフトウェア機能を提供するように作ることが非常に重要です。複雑なプロジェクト / 環境であったり、サードパーティが開発するプロジェクトの場合、これは特に重要になります。最終的に完全な作業パッケージを受け取るまで、ただ待っているだけではいけません。プロジェクトを少しずつ納品するよう調整して、事前に計画されたプロセスにしたがって他のメンバーが開発に取りかかれるよう提供するとよいでしょう。

成果物を監視。作業パッケージ（機能単位のコード群）を構築し、監視し、コントロールする手段を定義したら、次に作業が計画通りに完了しているか確かめるために、能動的に構築フェーズを監視 / コントロールする必要があります。チェックポイント、メトリックス、KPI（Key Performance Indicator、重要業績評価指標）などがチームメンバー全員に共有されている必要があります。
チェックポイントでは、その変動を特定するため、KPI やメトリックスを基準とトレンド分析に対して評価すべきです。これによって、直感や伝聞ではなく、実際のメトリックスに基づいた修正措置をとることができます。

成果物をうまく扱う。想定していた作業ができ上がったら、コードをテストして完了したと判断する前に、一部のユーザーにそれを提供して、要件にしたがっているか確かめましょう。このやり方は問題を特定するのに役立ち、ソフトウェアがユーザー全体に提供される前に修正措置をとることができます。
このアプローチで必要なことは、あらゆる小さな成果物を段階的に用意し、それらを順次まとめて（波が寄せるように）テストする必要があることです。もし、すべてのコードがそろうまで待ってしまうと、未知のエラーや欠陥、想定外の動作に満ちたコードを受け取ることになります。製品 / サービス / 成果はこうした問題を抱えたまま作られていき、その影響は埋もれたまま増殖していきます。この時点になると、動かないコードをすべて修正するのにかかるコストと時間は非常に高くついてしまいます。あなたの会社の環境やベンダーの経験を考慮して、開発に必要とされる複雑さとのバランスをとりながら、このやり方があなたにとってうまくいくかどうか判断しましょう。一般的に、複雑なソリューションや新しい技術、ソリューションに対して、このやり方は非常に役立ちます。

【88】私たちはスーパーヒーローではありません

アンジン・J・ショック・スミス（Angyne J. Schock-Smith）PMP

アメリカ、ニュージャージー州フィリップスバーグ

　あなたが IT 業界にいるプロジェクト・マネジャーであっても、どんな種類のプロジェクトでも管理できるようになりたいのなら、役に立つアドバイスがあります。

　「私たちはプロジェクト・マネジャーであって、スーパーヒーローではありません」　これは私がプロジェクトマネジメントスキルのトレーニングをするときに、最初に紹介するお話です。すぐれたプロジェクト・マネジャーの特徴について話すとき、お気に入りの言葉があります。「でも、ソフトウェアプロジェクト・マネジャーがやるべきことをやる、しかもうまくやるには、スーパーヒーローが必要なのです」　とはいえ、まだトレーニングは始まったばかりなので、いくらか希望をもたせてあげる必要があります。だから、こう言います。「私たち普通の人間でも実際にすぐれたプロジェクト・マネジャーになれる人はいます。どんなテクニックがあるのでしょう？」

私は次の 3 つがあると考えています。

あなたの個人的な強みと弱みを知ること。

あなたのチームの個人的な強みと弱みを知ること。

これらの知識を使って、あなたの弱みを埋めてくれるチームメンバーと補完的な協力関係を築くこと。

　どうすれば個人的な強みと弱みがわかるのでしょうか？

過去に受けたあらゆる適正テストや勤務行動テストのコピーを見てみましょう。

過去の評価データから推定するときには、正直になりましょう。調査を受けたとき、あなたは正直に答えましたか？　「分類」は今でも当てはまりますか？あるいは当時から成長して、変わりましたか？　分類に関連する強みと弱みのうち、どれが一番正確にあなたを表現していますか？

最高のプロジェクト・マネジャーならどの分類に当てはまるだろうか、と考えてはいけません。正解はないのです。すぐれたプロジェクト・マネジャーには柔軟性が必要です。つまり、状況ごとに診断して、最も効果的に対処するために、自分の安全地帯から踏み出せなくてはなりません。

利用可能なデータから、現在の個人的な強みと弱みの一覧を新しく作りましょう。常にそれをわかるようにして、自分自身について学びながら更新していきましょう。

　そうすれば、あとは簡単です。チームを評価するために、強みの一覧を使いましょう。それから、あなたの個人的な弱み一覧にある領域に強みのあるチームメンバーを探しましょう。

　私の場合（もしソーシャルスタイルをご存じであれば）エクスプレッシブ型（活動型）です。弱みは細部への注意です。私にはいつもそれを思い出させてくれるアナリティカル型（分析型）の人が必要なのです！もしあなたが必要以上に他人を喜ばせようとしているなら、あなたが自分自身でムリなくやれるレベル以上に、プロジェクトを力強く推進するのを助けてくれる人が必要になるでしょう。

　あなたの弱みのある領域において、補完的なスキルをもったチームメンバーがいるか確認しましょう。あなたがやっていることを彼らに話す必要はありません。秘密にしておきましょう。チームメンバーはあなたをスーパーヒーローだと思い込んでくれるかもしれませんよ。私はだれにも言っていません。

【89】頻繁に即座にミーティングする

リチャード・シェリダン（Richard Sheridan）

アメリカ、ミシガン州アナーバー

　プロジェクト・マネジャーは、チームにとって苦痛なミーティングを定期的に開催するという間違いをするものです。これは実際のところ、コミュニケーションを減らすという不幸で意図せぬ効果をもたらします。最も恐ろしいミーティングのひとつが、典型的な月曜朝の進捗ミーティングです。そうでなくても月曜日は十分ひどい日なのに。

　もしほとんどのミーティングをなくすべきだということに確信がもてないなら、ひとつ実験をしてみましょう。プロジェクト・マネジャーとして、あなたはミーティングに出てはいけません。そうして信頼できる同僚のひとりに、あなたが欠席したミーティングがどうだったか聞いてみましょう。あなたが不在でも開かれましたか？

　もし上司やプロジェクト・マネジャーが出るときだけミーティングが開かれるようなら、そのミーティングはなくしてしまいましょう。ミーティングから価値が得られないことをチームは教えてくれています。ひとりだけしか価値が得られないようなミーティングを開いてはいけません。

　私の組織では、非生産的なミーティングを廃止して、簡単なチームメンバー間のコミュニケーションパスに置き換えるよう、できる限りのことをやっています。例えば、チームは毎日、一日中、壁も個室もパーティションもドアもない、ひとつの大きな部屋で仕事をします。そのため、だれかに聞きたいことがあると、こう言うだけでいいのです。「ねえ、ジェームズ」　30 秒もしないうちに、実際に移動することなく（あるいはメールをあちこちに送ることなく）、ジェームズと私は必要な情報を交換してそれぞれの仕事に戻れます。

　「ねえ、みんな」と叫ぶだけで簡単に設定できる 60 名の全社ミーティングを想像してみてください。全員が手を止めて返事をします。「やあ、リッチ」

　ミーティングはほんの数分で終わって、全員席を離れることなく仕事に戻れるのです†。

　私たちが出なくてはいけない儀式のようなミーティングには、プロジェクトの進捗をスポンサーに見せる毎週の「発表会」、プロジェクトスコープを承認する毎週の「計画ゲーム」、毎日の「スタンドアップミーティング」、プロジェクトの共通目標に向けて、次週どのように協力していくかをブレインストーミングする毎週の「キックオフミーティング」といったものがあります。しかし、これらのミーティングには参加者を心地良く、楽しくする仕掛けがあります。

　1 週間、毎日のスタンドアップミーティングに挑戦してみて、うまくいくか調べましょう。スタンドアップミーティングを効果的にするために私たちが学んできたことを以下に紹介します。

プロジェクトにかかわる全員を参加させましょう。このミーティングには通常、50 名から 60 名が参加していました。

全員に聞こえるくらい大きな音のアラーム時計で、ミーティングを招集しましょう。機械を使って公平にミーティングを招集することで、はるかに参加しやすくなります。私たちはアラーム時計のついたダーツ盤を使っています。

スピーキングトークンを使いましょう。私たちはプラスチックのバイキングヘルメットを使ってミーティングをコントロールしています。隣りに立っている人にそれを手渡すだけです（座っていることは許されません）。発言権はバイキングヘルメットのトークンを手にしている人にあります。

最近完了したこと、現在取り組んでいること、助けを必要としていることを報告させましょう。実際の助けはミーティングが終わってからにしましょう。

　私たちのスタンドアップミーティングには通常 13 分ほどしかかかりません。13 分で、ミーティングを招集し、全員が集まり、ミーティングが開催され、全員に話す機会を与えて終了し、再び仕事に戻るのです。60 名の意味のあるミーティングを 13 分で終えられる組織はそうはないでしょう。

【90】柔軟性がプロジェクトマネジメントをシンプルにする

クリシュナ・カダリ（Krishna Kadali）M.Tech

インド、ハイデラバード県コンダプール

　宮本武蔵は 17 世紀の有名なサムライで、「ひとつの武器、ひとつの流派に固執してはいけない」という原則を信じていました。このアドバイスはプロジェクトにも当てはまります。ひとつのマネジメント原則、ひとつのソフトウェアツール、ひとつのプログラミング言語といったものに固執しすぎないことは極めて重要です。既存のリソースを柔軟に、さまざまに配置可能だと考えることによってのみ、顧客の問題に対して最高の対応をとることができるのです。

　プロジェクト要求を定義するときには、最初から偏見なしにやりましょう。顧客と話す前に、すでに武器を手にして戦い方を決めていると、あなたのソリューションがベストであることを証明するのは困難です。

　武器を選ぶ前に、顧客の要求をすべて調べましょう。顧客はあなたが提供する新しいソフトウェアを使ってどんな問題を解決しようとしているのですか？　通常、問題はビジネスロジックにあって、現在のソフトウェア資産ではその機能を十分果たせていないことを示しています。次に、組織内にある再利用可能なシステムやリソースについて検討しましょう。既存のシステムの一部をうまく再利用することで、プロジェクトの道のりを短く容易にすることができます。

　再利用可能なものとしては、企業インフラ施設、機器やソフトウェア、商用のデータベース、プログラミングツール、人的資源のスキルなど、さまざまなものが含まれます。

　ソフトウェアやプロジェクト成果物によって満たされるべき顧客要求を、既存リソース中心に分析すると、現在の組織にある基本的リソースが浮き彫りになります。「私たちのユーザーは、XPP34 コールセンターシステムと私たちの企業向け売掛金勘定システムを協調動作させる必要があります。あなたの製品は 4465IL レガシーソフトウェアと統合するか互換性をもつ必要があります」といったことがわかるでしょう。

　あなたがやるべき仕事は、顧客が期待する各種最終パフォーマンスについて、また既存のリソース / ソフトウェア / システムと新しいコードがどんな相互関係をもつべきかについて、顧客に適切な質問をすることです。既存リソース中心のアプローチをとることで、あなたは顧客が将来望んでいる変更のための土台を築けるかもしれません。このように分析することで、最終的にあなたのソフトウェアは新しいリソースの一部となっていくでしょう。これは現在の問題を解決するだけでなく、将来のプロジェクトを実現させ、将来のソフトウェアとやりとりすることにも使えます。

　顧客が何を望んでいるのか、あなたの組織でどんな既存リソースが利用可能なのかがわかると、問題と戦うのに最適な武器を選ぶことができます。実際の開発においては、まず顧客の信頼を得るために、いくつかの重要な要求の実現に注力しましょう。重要な要求を満たすために必要なモジュールとサービスは、プロジェクトの最初に実装しておくべきです。

　ソフトウェア設計のための新しい道をいつでも受け入れられるようにしておくと、絶えず要求が変化しても、気持ちよくプロジェクトに取り組めます。こうした柔軟性をもっていると、プロジェクトマネジメントという難題もシンプルになります。新たな武器と計画を作ることは、あなたの労働時間を楽しく豊かにしてくれるでしょう。

【91】Web が道を示す（今のところは）

デイビッド・ウッド（David Wood）

アメリカ、バージニア州フレデリックスバーグ

　「私たちは先人を手本にしています。私たちは後人の手本になります」　この言葉をスローガンにしたチャリティグループがあります。これは私たちソフトウェア開発者にも関連があります。新しいアーキテクチャ、言語、プラットフォームが有名になるたびに、私たちは「これがあらゆるプログラミング問題に対する解になる」と期待します。ところが、それは今の問題を解決してくれたとしても、明日には新しい課題に直面することになるのです。

　現在、私たちは何十億ものユーザーにまでスケールし、個々の構成要素のエラーに対してロバストに機能するソフトウェアアーキテクチャをひとつだけ知っています。それは Web です。Web は今までのところ、人類によって作られた最も大規模で、最も使われている、最も堅牢な情報検索システムなのです。

　なぜ Web はそんなにうまく機能するのでしょうか？　有名な Apache プロジェクトの創設者であるロイ・フィールディングは、まさにこの疑問について研究しました。フィールディングは初期の Web の理想的なアーキテクチャを評価し、そこからアーキテクチャスタイル要素を抽出しました。

　その結果、この新しいソフトウェアのアーキテクチャスタイルにはみんなが好きになる特性が備わっていることがわかりました。その特性とは、個々の構成要素の変化にも破壊にもロバストであることです。構成要素に分割することで、プログラミング言語などの実装詳細について気にしなくてもよくなりました。ここでは言語に中立なリクエストを交換するために、共通語（母国語が違う人たちでコミュニケーションするための言語）が使われます。これは非常に大きくスケールします。ここにはステートがないのです。

　すべての Web サイトがこうした指針となる原則を利用しているわけではありませんが、これは多くのサイトで利用されています。そして、Web は全体として、この原則を利用しています。しかし、こうした原則もお手本にすぎず、新たな革新的なアーキテクチャの開発が引き続き行われています。

　私たちは Web の成功から重要なことを学べます。おそらく最も重要なのは、今やムーアの法則のおかげで、私たちはシステム設計においてかなりの抽象化ができることです。もはやハードウェアとソフトウェアを非常に効率よく動かすことだけでなく、非常に安定した、非常にロバストな、非常にスケーラブルな、非常に柔軟なシステムを作ることについて考えることができるのです。また、将来の革新のための基礎となることを十分理解することで、現在のアーキテクチャの非効率性までも許容できるようになったのです。

　Web のような分散システムを設計するのは難しいことです。おそらくこれは、私たちそれぞれが個体であるためです。私たちはソフトウェアシステムを、世の中で経験するように中央集権化された、個人が作るものとして扱ってきました。それにもかかわらず、Web という分散システムはそのやり方を私たちに示してくれました。分散システムは概念化するのが難しく、作るのも難しいのですが、それを作るために努力する価値はあります。

　もちろん技術も変化します。アイデアやテクニックも変化します。フィールディングが描いたシンプルな Web は、現代の Web とは異なっています。将来の Web もまた現代の Web とは異なるでしょう。必ずしも Web は道を示すわけではないかもしれませんが、新たなシステムに適応するために重要なことは、システムに柔軟性を作り込んでおくことです。それによって初めて、動作する適応可能なソフトウェアシステムを作れるのです。こうして作られたシステムは、新たに発見された技術やアイデアと統合できるようになっており、後人の手本となるでしょう。

【92】ステータスレポートは開発者に嫌がられ、マネジャーに愛される

パベル・シムサ（Pavel Simsa）PMP

アメリカ、ワシントン州ベルビュー

　私は世界最大のソフトウェア会社で働いていますが、開発者はステータスレポートを嫌がっていると断言できます。開発者にとって自明で冗長な情報を、毎週何時間もかけてレポートに書き下さなくてはならないためです。

　プロジェクト・マネジャーであるあなたにとって、ステータスレポートはプロジェクトの進捗の全体像を把握するために使われ、上位マネジメントに伝えるデータになります。平均すると、プロジェクト・マネジャーは 5 つから 7 つのプロジェクトを同時に指揮しているそうです。あなたとあなたのシニアマネジメントチームは、こうしたプロジェクトデータを収集して伝えるためにステータスレポートを必要としています。

　「あなたが必要とする頻度の」ステータスレポートを送ることに対して、開発者の抵抗を軽減するためのヒントをいくつか紹介しましょう。

なぜこのレポートが他のチームメンバーや他の部門にとって重要なのか、理解できるようにしましょう。ほかのメンバーはチームの進捗に基づいて計画を立てる必要があります。人は仲間を助けるために熱心に働くものです。

プロジェクトの進捗が遅れているようなら、チームが何をしているか把握しましょう。新しいツールや言語を学んでいたのでしょうか？　想定外の問題や課題があったのでしょうか？　ステータスレポートをまとめるときには、ほかの人にもわかるよう、説明を加えておきましょう。

適切に感謝の意を表しましょう。問題や課題を把握できていれば、それほど重要ではない成果が進捗レポートメトリックスのせいで隠れてしまっていないか確認できます。計画にはないけれども役立つ貢献をした人には、近くのコーヒーショップのラテクーポンを提供しましょう。「すばらしいね、ありがとう＜名前＞さん」といったメールを部門全体に送ってもよいでしょう。その仕事が「全体像」にどう関係しているか、直接的なつながりを与えましょう。

開発者が複数いるなら、グループインセンティブを用意しましょう。「1 か月間にわたって毎週金曜日の午後 3 時までに全員からステータスレポートが集まれば、次の金曜の午後は全員帰ってもよろしい」とか「私がグループランチの食事を用意しよう」と言ってみましょう。だれも自分のせいで、チームが報酬を得られなくなることは望みません。

簡単にレポートを書けるようにしてください。テンプレートを用意したり、ステータスを登録するツールを準備してください。全員が理解できるよう、言葉遣いも直すようにしましょう。“lcl check-in to main build lab.” と書いても、副社長にはまず理解できません。あなたはそれを「フィーチャーマイルストーン 2 を達成。プロジェクトは予定通り」と変更しても構いません。

　重要なことは、あなたが第三者の視点から、ステータスレポートを書き上げるというタスクを見ているか確認することです。ステータスレポートは重要です。プロジェクトに何が起こっているのか、全員が知っておく必要があります。シニアマネジメントはマイルストーンを気にしており、ビジネスマネジメントは予算を気にしています。プロジェクト・マネジャーとしてあなたの仕事は、ステークホルダー全員がプロジェクトに何が起こっているのか確認できるようにすることです。そして、あなたの助けなしには、ステークホルダーが全員起こっていることの技術的なニュアンスを分析できるわけではないことを自覚しましょう。

　効果的なステータス入力ツールを見つけて、できるだけ多くのタスクに理解が得られるよう取り組みましょう。あなたはステークホルダー全員のニーズを満たした、総合的なステータスレポート作るための連絡係なのです。

【93】あなたはコントロールしていない

パトリック・クア（Patrick Kua）

イギリス、ロンドン

　私がかつてコーチしていたあるプロジェクトの話をします。プロジェクト・マネジャーは明らかに中央集権的にコントロールすることを望んでいました。彼は「重大な」意思決定をする議論には自分がすべて関与しなければならないという、強迫観念に取りつかれているようでした。毎日のスタンドアップミーティングを積極的に仕切り、プロジェクトのふりかえりでは、彼ひとりで次にだれが話すかを決めているようでした。実際のところ、私がやって来たころまでは、彼のチームはうまくまとまっていました。私はそのプロジェクト・マネジャーがいるところといないところで、どれくらい議論の質に差があるのか興味がありました。

　数名のチームメンバーと一対一で話したところ、彼らはプロジェクト・マネジャーが開くすべてのミーティングが嫌いであることを打ち明けました。早々に終わってほしいと願っていたのです。自分たちの本当の意見は重んじられないので、出席しても時間のムダだと感じていたのです。彼らは話が先へ進むよう、プロジェクト・マネジャーが聞きたがっていることをその通り話したことが何度もあると語ってくれました。解決すべき問題があると、彼らはテクニカル・リードのところに相談しに行きました。テクニカル・リードはもっとオープンな議論を望んでおり、喜んで効率よく問題を解決してくれました。

　私がこのチームから学んだ教訓は、自分が状況をコントロールしているように振る舞うことと、実際にコントロールしていることは同じではないということです。実際のところ、積極的にコントロールしようとすると、逆効果を生むこともあります。経験豊富なよくまとまったチームは、個人的理由からコントロールしようとする人を遠ざけます。そのコントロールがチームにとってほとんど役に立たないのなら、なおさらです。

　プロジェクト・マネジャーは、グループダイナミクスと多様なリーダーシップスタイルを理解しなくてはなりません。プロジェクトが異なれば、チームが異なれば、必要とされるコントロールレベルも異なります。よくまとまったハイパフォーマンスなチームであれば、自分たちにとって助けになることがわかっている場合を除いて、余計なコントロールを不快に思うものです。

　コントロールは「余計なお世話」だと見なされるのです。たとえ口頭では合意していても、ミーティングを離れてしまうと、あなたの意図を十分反映した行動をとらないいかもしれません。しかし、新しく作られたばかりのチームの場合には、コントロールすればするほど、チームに明確な指針を与え、プロジェクトにとって明確な目標を確立できるかもしれません。

　すばらしいプロジェクト・マネジャーは、チームメンバーがそのプロジェクトにどんなスキル、経験、コネクションをもたらすかを理解し、適度なコントロールを発揮します。彼らは、どんなときにコントロールするとチームが最終目標へと向かう助けになるかを知っており、どんなときにコントロールするとチームの進捗を遅らせるのかを知っています。

　このことが特に重要になるのは、非 IT プロジェクト・マネジャーがソフトウェア開発プロジェクトを指揮するよう頼まれたときです。プロジェクトチームは、現場に対する外部からの干渉にイライラし、プロジェクト・マネジャーがプロジェクトにもたらすスキルセットを過小評価するおそれがあります。

　組織のスキル、プロジェクト・マネジャーがプロジェクトを会社の目標と一致させる能力、上位マネジメントと顧客とのコミュニケーションラインのケア、これらのスキルがチームを守り、チームメンバーに自由に仕事をさせるために重要なのです。

【94】ビジョンを共有する

ジャレッド・リチャードソン（Jared Richardson）

アメリカ、ノースカロライナ州モーリスビル

　あなたは愚か者と仕事をしていますか？　あなたのチームメンバーは会社を破産させたいと思っていますか？　そう感じるときもありますが、通常はそんなことはありません。本当はみんな成功したいし、貢献を誇りに思っています。どれだけプロジェクトをサボろうとしているように見えたとしてもです。みな自分が正しいと思うことをしているのですが、何が「正しい」のかは人それぞれなのです。

プロジェクト・マネジャーとして、みんなを協力させるにはどうすればよいのでしょうか？　ほとんどのチームが暗闇のなかで仕事をしているのだということを知るべきです。なぜこのプロジェクトが重要なのか、会社のもっと大きな戦略にどのように関係しているのか、なぜ締め切りが 6 月 17 日なのか、チームのほとんどは知りません。なぜそういう決定がなされたのかを理解していないので、その決定は気まぐれで理不尽なものに見えてしまいます。役に立つ明確な情報が何ひとつないのに、先の見えない状況から何とかして明確なビジョンを作ろうと、全員が苦労します。同じプロジェクトなのに全員がバラバラな最終目標を見ているのは奇妙なことです。

　この霧を晴らすためには、共通の取り組みに関する重要な情報をチームメンバーと共有する必要があります。この 3 週間で市場に出てくるはずの競合製品に対抗するために、このプロジェクトは 6 月中旬に出荷する必要があるということを知らせましょう。このプロジェクトは全世界展開するという大きな企業戦略を満たすものだということ、顧客が既存の古くなったプロダクトラインから得られる利益の減少を立て直すために、このプロジェクトに期待していることを伝えましょう。

　もしあなたが情報共有に慣れていないなら、よく注意しましょう。チームに関する情報のパイプ役として、あなたはチームのモラルづくりにも影響を与えます。あなたが他のグループやマネジャー、自分のチームメンバーについて不満を漏らすと、あなたのその否定的な態度はインフルエンザのようにすぐにチームに広まります。そして、ウイルス感染と同様、何日もチームの勢いを削いでしまうのです。

　毎日ミーティングを開くことは、プロジェクトに関する情報を共有するすばらしい方法です。10 名ほどのチームであれば 10 ～ 20 分ほどで効率よくミーティングできるでしょう。チームに対して、自分の最新進捗と、必要に応じて助けが必要な問題について説明する機会が各自 1 ～ 2 分与えられます。こうした簡単な「スタンドアップ」ミーティングは、プロジェクト・マネジャーがプロジェクトのアップデートを共有するのに最適な場となります。

　毎週（あるいは毎月）のミーティングだと、重要な情報を伝え忘れてしまうおそれがあります。結局のところ、最終的に全員が集まるときには、あなたにとっては古い情報になっているのです。あるいはリスクの共有が遅れたために、防げるはずの問題が大きくなることもあります。また、17 ビットの「致命的な」情報を、ひとつの大きな会話の中に詰め込んで共有しても、チームにはわからなくなるでしょう。

　あなたのチームはもちろん、会社にいる全員が成功したいと思っていることを覚えておきましょう。ビジョンを共有してください。ほかの人にもビジョンを共有するよう頼みましょう。会社をダメにしたがっている愚か者だと思っていた人たちのほとんどは、相互理解することによって、実際にはチームの課題を解決しようと力を合わせて取り組んでいる仲間だということがわかるでしょう。

【95】真の成功にはサポートする組織が必要

シンシア・A・バーグ（Cynthia A. Berg）PhD（ABD）、PMP

アメリカ、アリゾナ州グレンデール

　もし組織がリスク計画、積極的な問題追求、タイムリーな問題解決を避けているようなら、それは企業文化に問題があります。プロジェクト・チームのなかで反対意見を出す人は、トラブルメーカーというレッテルを貼られるのでしょう。もし組織が即座に「問題を報告した人を罰する」ようだと、チームメンバーはやっかいな問題を共有しなくなります。プロジェクトにある問題を隠蔽しがちになるおそれがあります。

　こうした文化環境では、組織全体、個々の従業員、顧客らの不利益に対する取り組みは非難されがちです。プロジェクト・マネジャーの役割は、できるだけ予期せぬ事態が起こらないよう、想定通りにプロジェクト成果を出すことです。早期に危険を指摘してくれる人がいないと、「驚くべき」結果になります。よい意味での驚きというのはめったにありません。むしろ開発者が問題を隠蔽したために、配慮も計画もできず、わるい意味での驚きになるでしょう。

　賢明な企業幹部であれば、開発者が効果的に動けるような姿勢と行動を会社がサポートできるようにします。これには、強い製品やサービスの開発につながる行動をとっているか、人材ポリシーや活性化策を評価することも含まれます。

　こうした企業文化のずれの典型例が、公式にはチームワークを「説き」ながらも、相変わらず個人の貢献に対して見返りを与えている組織です。人間は利口な生き物です。どうすれば自分の利益に一番かなうのかを知っています。上位マネジメントが生産的な行動を促すためには、自らが信じて明言するものと仕事環境として提供するものに一貫性を確立しなくてはなりません。そうすることで、個人と組織の両方が活躍できるようになります。

　非協力的な組織もしくは機能不全の組織にいると思っている人が取るべき手段について、いくつか挙げましょう。

プロジェクトのスコープが理解できるまで、何度も質問しましょう。そうすれば、そのスコープ内で仕事ができます。

有望なチームメンバーやステークホルダーを見つけましょう。可能であればいつも、彼らをブレインストーミング、計画、プロジェクト実行に参加させましょう。

少なくともそのプロジェクトでのアクティビティが完了するまでは、その人がプロジェクトのアップデートや意思決定にすべて参加できるようにしましょう。

常に正直なプロジェクト・マネジャーでありましょう。衝突や不快な議論を避けるために、問題をごまかしたり単純化してはいけません。

組織全体のお手本としたいようなプロジェクトチーム環境を提供しましょう。

　プロジェクト・マネジャーはプロジェクトを客観的にとらえる必要があります。給料を支払ってくれる組織に第一の忠誠を尽くす義務があるため、嫌な役目も果たさなければなりませんが、同時に開発者との信頼関係も築く必要があります。プロジェクトの展望が暗いようなときにも、目先の利いた信念をもったプロジェクト・マネジャーであれば、問題が解決されるまでプロジェクトを中断するよう進言しなくてはなりません。

　私たちはみな新しいソフトウェア開発をサポートするために、まとまりのある戦略をもった組織で仕事をしたいと思っています。しかし残念なことに、その能力レベルは同じ組織でも部門によって大きく違っているかもしれません。より協力的な環境へと向かうことは、全員にとってよいことです。したがって、プロジェクトの優先順位とパフォーマンス報酬とのあいだにある文化的競合を上位マネジメントに警告することは、プロジェクト・マネジャーの役割の一部であるはずです。

【96】ガバナンスを確立する

エルナーニ・マルケス・ダ・シルバ（Ernani Marques da Silva）MBA、PMP、PgMP

ブラジル、サンパウロ州マイリポラン

　プロジェクトではチームメンバーはもちろんのこと、ベンダー、顧客やプロジェクトスポンサー、運用チーム、契約チーム、財務チーム、その他関連ステークホルダーなど、幅広いグループとやりとりします。プロジェクトを多種多様なグループに属する人たちが参加する場だと考えると、さまざまな事態によってプロジェクトが容易に危険にさらされることがわかります。

　IT にバックグラウンドのあるプロジェクト・マネジャーなら、プロジェクトマネジメントの視野をもっと広げる方法を知っておくと役に立つでしょう。

　ガバナンスとは、開発、コミュニケーション、実装を実施するため、またポリシーや手続き、プラクティスなど、プロジェクト運営に伴う活動を監視するために使われるマネジメント手法です。効果的なプロジェクトガバナンスの構造および手続きを整えることは、そのプロジェクトに適した調整、脅威と機会の監視とコントロール、意思決定、プロジェクトパッケージの実現を計画するのに役立ちます。これによって、あなたは適切にリスクを解消し、結果的にプロジェクト要求を満たせるようになります。

　プロジェクトガバナンスを有効に機能させるためには、事前に計画しておく必要があります。関連するアイテムをフレームワークを使って解決しましょう。フレームワークには、ガバナンス目標および目的、構造、原則、プロセス、手続き、標準、コミュニケーション、社内の上下関係、エスカレーション手続き（何を、いつ、どのように、だれが）、ツール、明確に定義され適用される遂行責任と結果責任、評価と評価基準、品質、ミーティングとステアリングコミッティー、監査、監視とコントロールといったものがあります。

　ガバナンスは、環境、部門、業界、企業文化、法律といった要因によって影響を受けることも心に留めておきましょう。例えば、機能型組織の場合、プロジェクト・マネジャーは、ポートフォリオ・マネジャーやプログラム・マネジャーではなく、機能マネジャーに直接報告しているかもしれません。プロジェクト・マネジャーは、すべての仕事がプロジェクトとして整えられたプロジェクト型組織において、一番力を発揮できます。機能型組織の場合、ライン・マネジャーや部門マネジャーに直接報告しても構いませんが、事実上あなたの力は弱まるでしょう。

　そのためガバナンスアーキテクチャを計画し定義するときには、組織階層についても考慮しましょう。プロジェクトの計画目標と目的に合うよう、仕事の状況と進捗に基づいて、必要に応じてガバナンス構造を修正しても構いません。大規模なプロジェクトの場合には、あなたの仕事をもっと大きなプログラムやポートフォリオの目的と目標に合わせましょう。たとえ非常に小さなプロジェクトを管理している場合でも、プロジェクトのガバナンスモデルを作成して適応させていきましょう。

　通常は PMO（Project Management Office）に、プロジェクト関連の手続きやプロセスを定義および管理し、したがうべきテンプレートを作る責任があります。

　プロジェクトボードはプロジェクト目標を確実に達成する責任のある組織体となります。ボードはプロジェクトのリスクやその他の問題を適切に解決するためのサポートをします。ボードの機能には次のようなものがあります。

プロジェクト計画および計画変更を承認すること。

進捗レポートを集めること。

ポリシーや手続き、標準、要求にしたがうことを保証すること。

リスクや問題に対する指針を与えること。

プロジェクトの進捗をレビューすること。

　プロジェクトにおいて、ほかの会社とやりとりがあるのであれば、プロジェクトガバナンスもほかの組織のガバナンス構造と一体的に運用するべきです。

【97】あなたの Web サイトが嫌いな 9.7 の理由

バービー・デイビス（Barbee Davis）MA、PHR、PMP

アメリカ、ネブラスカ州オマハ

　多くの会社はソフトウェア開発と Web 開発に違いがあることを理解していません。そのためソフトウェアプロジェクト・マネジャーやソフトウェア開発者は Web サイトの開発を依頼されます。迷惑な Web サイトのせいで、私（顧客）があなたの会社と仕事をしたくないと思うようになる 9.7 の方法を挙げましょう。

時間をかけてロードされる Flash から始めましょう。ユーザーにスキップさせてはいけません。ページをリフレッシュするときには延々と待たせましょう。そうすれば私（顧客）は反応のよい競合の Web サイトへ行くでしょう。

びっくりするほど大きな音のビデオクリップで私（顧客）を驚かせましょう。私は仕事場にいるかもしれませんし、家にいて、隣の部屋では子どもや旦那が眠っているところかもしれません。サプライズプレゼントを買おうとしているところかもしれません。さらに効果的に嫌われるためには、停止ボタンもなくしてしまいましょう。

バックボタンを禁止しましょう。私（顧客）をこのサイトに導いた検索エンジンに戻れないようにすると、あなたは賢くなったような気になります。しかし、私も何度もひっかかりはしません。二度とあなたのページをクリックしませんし、あなたが売っている製品やサービスを買うこともないでしょう。

目立たないカラースキームを選びましょう。ちょっと暗いグレーの背景にグレーの文字を書くのはユニークですが、だれも読めません。マウスを 1 クリックすれば 25 個もの Web サイトが見つかり、そこでは不自由なく情報を読むことができます。また簡単にカットアンドペーストできない（黒地に白のような）反転は、私（顧客）が将来の購入判断のためのデータを保存できないということを意味しています。

私（顧客）のポータブルデバイスを無視しましょう。私は iPhone や Kindle、ネットブックを携帯しているかもしれません。もしハイスピードでオーバーヘッドの少ないモバイル向け UI を用意していないなら、あなたの会社は私が必要としている会社ではありません。私たちはクライアント / サーバモデルから離れて、空の向こうにある強力なコンピュータ（クラウド）につなげられた古い「ダム端末（表示だけの端末）」へと回帰しているのです。

電話で担当者と連絡をとれる手段を提供してはいけません。私（顧客）が問題を抱えているとき、制限だらけのヘルプにうんざりしながらも Web サポート機能しか使わないと思っているのであれば、それは間違いです。私はコンピュータの電源を切ってしまうでしょう。あなたはサイトが壊れていることを知らなくてすみます。

情報を得るために電話をかけるよう求めましょう。土星へのテレポーテーションといった、これまでにない製品を売るのでない限り、あなたには適正な値付けがわかるはずです。それを私に電話で教えるのです。競合であっても顧客のふりをして電話をかければ情報を得ることができます。あなたは本当の顧客である私を失うでしょう。

顧客をタイプで区別しましょう。法人であれば、古い OS も手に入れられます。でも私は個人ですが、不安定な新しい OS へのアップグレードを強制されるのはごめんです。往復チケットを求めて航空会社のサイトを検索するとき、私は複数都市のフライトをひとつずつ選ぶのが好みなので、同じフライト区間を一覧にして全部見たいのです。

役に立たない検索機能をつけましょう。私はあなたの Web サイトにあるコンテンツを検索したいのです。広報のニュースリリースだけを検索したいのではありません。

ボタンに違うラベルをつけましょう。「続きを読む」ボタンをクリックしてビデオクリップの再生が始まると、私は怒るでしょう。私はプレゼンテーション全体を最後まで見ることなく、テキスト情報にざっと目を通したいのです。

　どうです、効果的でしょう。

日本を中心に活躍するプロジェクト・マネジャーよる知っておくべき 11 のこと

【01】自分に対する約束をどう守るか

冨永 章

東京

　少人数で行う小さなプロジェクトから、社会を変革する大きなプログラムに至るまで、すべての成功の源には、個人が行うプロジェクトがあります。メンバー各人がチームへの約束や期限を守ることで、プロジェクト全体が成り立っています。個々人はそれ以外にもやるべきことをたくさん持っているのが普通です。多くの社会人に質問してきた限りでは、約束を守るために To-Do リストに書き出す習慣をもつ人は、半数以上います。

　ほとんどの人は他人への約束期限をなんとかして守るように努力します。プロジェクトマネジメントのプロフェッショナルなら、なおさら期限を大事に考えるでしょう。また、メンバーを成長させたいという強い動機を持ちます。しかし自分自身のためにやる仕事の期限についてはどうでしょう。無意識のうちに優先度が低くなり、ずるずると遅らせるようなことがありませんか？　その理由の 1 つは、お客様あるいは他人のためにがんばることが、プロフェッショナルの仕事の強い動機付けだからということでしょう。相手の喜ぶ顔を具体的に思い浮かべれば、自然にやる気が湧くものです。それに対し、自分に対する約束はどうすれば守れるのでしょうか。

　ビジョンやゴール、大きな目的を実現するには、小さなマイルストーンを設定しながら、少しずつ達成していく方策がよく知られた PM の定石です。そうすることで大きなゴールに至るやり方は、1960 年代に月ロケットを成功させたアポロ計画でも、個人が成し遂げた偉業でも共通です。プログラムマネジメントの途中に設定したマイルストーンの期限が守れず、だらだらしてしまえばゴールへの確実な達成からは遠ざかっていくでしょう。

　さて、個人が行うプロジェクトやプログラムでも、PM 特有のノウハウは組織のプロジェクトとほぼ同じです。しかし、メンバー間のコミュニケーションやメンバーの動機付けなどについては、個人の場合はあまり関係がありません。実はこういう領域は組織を扱う「マネジメント」一般のノウハウと共通であって PM 特有というわけでもありません。しかし、時間、リスク、コスト（個人ならそのほとんどは時間）、ステークホルダーなどのマネジメント、プログラム、ポートフォリオの調整などは、プロジェクトをやるなら組織でも個人でも共通に特有です。ところが、個人の場合にはさらに必要な領域も見あたるのです。例えば「動機付け」は、普通はメンバーのやる気を引き出すのが目的ですが、個人の場合は他人ではなく自己の動機付けが欠かせません。また、個人が何か挑戦をするには、ある程度の自信が必要です。

　筆者は 10 数名の PM プロフェッショナル仲間と共に、5 年前に個人 PM の研究会を立ち上げました。多くの人に役立つノウハウ確立を目指して研究活動をしています。このプログラムの最近のマイルストーンとして、知識体系を整理しました。そこから引っ張り出せる主な答えを、ここでごく簡単にご紹介しましょう。

目標の構造：いつも大きな目的やゴールを持ち、それを目指して個々のプロジェクト目標を作れば、行き当たりばったりの目標よりも夢の実現、個人の成長、動機付けなどに有益です。明確で適切なゴールを持てば、各目標の目指す方向が揃います。

To-Do リスト：項目ごとの予定・実績時間を記録する習慣を作れば、見積りにも段取りにも役立ちます。短い仕事はまずやってから、後付けであってもリストを更新する習慣にします。自分の今の調子に合う仕事をリストから選べば効率があがります。

やる気の出し方：十選すれば、①目標の明確化、②人に宣言、③時間割に従う、④とにかく行動、⑤憧れのモデルのつもり、⑥ライバルへの意識、⑦他人のためにやる、⑧座右の銘を携帯、⑨自分にかけ声、⑩自分にご褒美、です。

リスクマネジメント：個人の大事な仕事なら、頭の中で何度も進め方をシミュレーションすることで、想定外のことを防ぎやすくなります。これならどこでもできます。とはいえ、リスク対応を決めたらとにかく行動するのが一番です。

プロジェクトの振り返り：せめて 1 分だけは行って一言を記録しましょう。自分に役立つノウハウ集に成長します。また、自分の大仕事のチェックリストになります。さらに、嫌な思い出を反芻する必要がなくなり、前向きの思考に役立ちます。

【02】プロジェクトの目的と成功の条件

芝尾 芳昭 ME、DBA

東京

　プロジェクト・マネジャーとして最も重要なことは「プロジェクトを成功させること」であることは誰もが賛同していただけるかと思いますが、しかしどれほど多くのプロジェクト・マネジャーが自ら担当するプロジェクトの成功の条件を深く考えてプロジェクトに臨むでしょうか？　これまで数多くのプロジェクト・マネジャーを見てきましてが、プロジェクトの成功について深く考えてプロジェクトに臨むプロジェクト・マネジャーは思いの他多くありませんでした。

　これは、プロジェクトの成功を考えていないという意味でなく、プロジェクトの成功とは何をもって成功というのかという成功の定義を深く考えていないという意味です。プロジェクトの成功を正しくとらえるには、第一にプロジェクトの目的そのものを正しく理解する必要があります。なぜなら、プロジェクトの目的をどのようにとらえるかで成功の条件が変わってくるし、条件が変わればプロジェクトとしての動き方も必然的に変わってくることになるからです。

　プロジェクト・マネジャーにプロジェクトの目的を聞くと、多くの場合プロジェクトの納期、コスト、品質を達成することと答えるケースが圧倒的に多いのですが、ときおり顧客満足度を達成すること、新たな技術を習得することなど、通常のプロジェクトの目的とは視点が少し違った目的を聞くこともあります。確かにそれぞれ一般に言われるプロジェクトの目的の 1 つであり、達成目標として設定しやすい項目ではありますが、私はそれで十分とはとても思えません。もう少し深くプロジェクトの意義を考えて目的と成功を定義する必要があると思います。

　そのためには、プロジェクトの存在意義そのものとプロジェクトの本質を知ることが重要だと考えています。では、プロジェクトの本質とは何か？　私はプロジェクトの本質は「投資」であるととらえています。この前提に立つとプロジェクトの見え方が少し違ってくるかもしれませんが、よりプロジェクトの存在意義が明らかになるはずです。「投資」であるプロジェクトは「価値」を獲得するために存在しており、納期、品質、コスト、顧客満足度、技術などはその「価値」の獲得するための 1 つの成果にすぎないということになります。これは、顧客と契約してお金をもうら受注型のプロジェクトであろうと、自ら投資する研究開発型のプロジェクトであろうと企業はそのプロジェクトに人、資材、設備、お金を投入して価値を獲得しようとすることは変わりません。これが、利益追求しない公的プロジェクトにおいても同じことが言えます。「公共投資」を行うことで、住民の生活向上を上げるという「価値」を獲得しているだけで、プロジェクトの本質は何も変わらないのです。

　この価値獲得の視点からプロジェクト・マネジャーの役割を考えると、プロジェクト・マネジャーは与えられたプロジェクトからどれだけ多くの「価値」を引き出すことができるのかということを、常に考え実践しなくてはならないということになります。しかし、この価値の視点を持つには、プロジェクト・マネジャーはマネジメントとして 1 つ上の視点を持つことが不可欠となります。つまり、企業において求めるべき価値は何なのかを理解する必要があるということです。プロジェクトを通して「価値」を作り出すと考えた時、企業で行われるプロジェクトが企業の戦略と無縁であってよいはずはなく、プロジェクトは企業の成長に貢献しなくてはなりません。つまり、プロジェクトは戦略実現の一端を担う必要があり、プロジェクト・マネジャーは企業価値の創出に対してプロジェクトがどのように貢献できるかを考えなくてはならなくなります。プロジェクトの所有者である企業が求めている価値を知り、企業の戦略を知ることが不可欠となりますが、どれほど多くのプロジェクト・マネジャーが企業戦略の観点でプロジェクトの位置づけを理解しているのか疑問です。受注プロジェクトにおいても同様で、受注プロジェクトには顧客が存在しており、その顧客が何らかの企業戦略を実現するためにプロジェクトを起こしたわけで、そのプロジェクトは顧客企業の戦略の一端を担っているはずですが、受注企業は顧客企業の戦略やそのプロジェクトに与えられた期待をどれほど理解しているでしょうか？　顧客満足度という言葉はよく出てきますが、残念ながら表面的な人間関係をベースとした顧客満足度に終始するケースが多く、本来の主旨である顧客の戦略実現に貢献することと理解するケースは少ないように思えます。たとえ、目の前の顧客の意見に反してでも、顧客企業の戦略から考えて顧客企業の価値に貢献しないようなことであれば、あえて反対する勇気も必要であり、それこそがプロジェクトの目的を正しく理解することであり、プロジェクトを成功に導くことだと信じて行動すべきです。

　プロジェクト・マネジャーたるもの、そのプロジェクトのおかれた戦略的な位置づけを正しく理解し、その中でプロジェクトから獲得すべき価値を明確にした上で、プロジェクトの成功に向かってプロジェクトを運営してほしいものです。自分のプロジェクトを企業、顧客、あらゆる側面から客観的に見渡し、成功の意味を考える。そして、その成功を阻害する要因があれば極力排除し、成功のための環境を整える。このプロジェクトが開始する前の目的設定と環境作りこそがプロジェクト・マネジャーがやるべき最重要の仕事だと理解し、活動して頂きたいと思っています。

【03】「正しい判断」にこだわるな

重木 昭信

東京

　プロジェクトを進めていく途中で予期せぬ事態が発生して、その問題にどのように対応するか、プロマネとして判断を求められた経験はないでしょうか。

　例えばトンネルを掘るプロジェクトを進めているときに、とんでもなく固い岩盤に突きあたるとか、湧き水が多くて予定通りに工事を進められないといった事態が発生したら、どうするのか。ルートを変えるのか、工法を変えるのか、対策を終えてから再開するのか、どんな手を打つのかが問題となります。

　こうしたときにプロマネは逃げ出すわけには行きません。重圧に耐えながら「正しい答え」を出すことを、プロジェクト・チームの全員から期待されるわけです。しかし、どれが正しい答えなのか簡単にわかるでしょうか。わからない問題にも答えを出さなければならないのです。「正しい判断」を行うために、どの案が正しいか確認する必要があるのでしょうか。不明な点を調査したり、判断に必要な材料が全部揃ったりするまで検討を続けさせることが必要でしょうか。こうした問題が発生すると、現場での作業は止まってしまい、プロマネの判断待ちとなります。これはプロマネにとって恐ろしいことです。進捗は遅れて、コストはどんどんと膨らみます。その上、プロジェクトの停止期間が長引くと士気の低下が発生します。ですから、判断は可能な限り迅速に行い、現場を停滞させないようにすることが重要です。

　では、判断を急ぐあまり、「正しい判断」でなくてもかまわないのでしょうか。昔からプロマネは「勘と度胸」で判断しろといわれてきました。これではまるで地雷原を、勘と度胸に頼りながら歩いて渡るようなもので、運に見放されないことを祈るのみです。「正しい判断」のために、プロジェクトを長期間止めることはできない。ここにプロマネの最大の悩みがあります。

　この問題は、「誤った判断をしない」というように考え方を切り替えましょう。判断を悩む理由は大きく分けて 2 つあります。1 つは評価項目があいまいなこと、2 つ目は「最も正しい案」を選ぼうと悩むことです。この 2 つを解決すれば、判断の時間は短くできます。

　判断にあたっては、解決案を考える前から、判断のための評価項目を明確にしておくことです。例えば配偶者を複数の候補の中から選ぶとします。評価項目として、収入、スタイル、性格、家庭環境、美形度、などを考えるとします。評価の途中で、「料理上手」などの追加的な情報が出てくるかもしれませんが、当初の評価項目にないものは対象外としないと混乱してしまいます。

　次は「誤った判断をしない」という点です。評価項目について全部の項目で問題ないという人はいません。だからこそ迷うのです。高収入だが家庭環境の条件に合わないとか、美形ではあるが性格が悪かったりします。こうしたときに、順位をつけたり、「最も正しい選択」にこだわったりすると大変です。よく調べるために、全員とデートしてから決めよう、など考えるとさらにどんどんと遅れてしまうわけです。結婚問題ではスタイル抜群など、自分の最も気に入った点を重視して選んでもかまわないのですが、プロジェクトでは、致命的な欠陥がない選択を心がけましょう。どんなに気に入った点が多くても性格の悪い人だけは避けたい、というように、プロジェクトにおける判断では、最も優れた点のある案ではなく、致命的な欠陥の存在しない案を選ぶべきです。というのは、どんなに良いところがあったとしても、致命的な欠陥を持つ案はプロジェクトの完成に大きなリスク要因となるためです。

　こうして致命的な欠陥を有する案を消去法で除いた結果、複数の一長一短の案が残れば、あとはどの案でもたいした違いはないはずです。迷いに迷うような選択であればあるほど、結果的に違いは少ないので、サイコロを振って決めてもかまわないと思います。

　好きなところを見つけて選ぶ「恋愛結婚原理」ではなく、断るべき理由が見つからないので受け入れるという「見合い結婚原理」をプロマネは採用すべきです。

【04】「見積り＝不幸の始まり」にしないために

初田 賢司

東京

　「マネジメントしやすいプロジェクト」とは、どういうプロジェクトでしょうか。私は、スコープやスケジュール、コストのベースラインがしっかり設定されていて、プロジェクト進行中にベースラインからの乖離が発生すれば、それが把握できてコントロールできるプロジェクトだと思います。鍵はベースラインです。ベースラインは、プロジェクトの計画段階で設定されます。ところが、設定するにあたっての制約事項や大枠は、プロジェクトが始まる前に決まっているのです。つまり、見積り段階です。プロジェクト・マネジャーは、どんなことを考えて見積りを行えばよいのでしょうか。

　まず、「何のために見積るか」を考えてみます。見積りの目的は 3 つです。1 つ目は、「注文を取る」、組織内なら「稟議を通す」ことです。見積りの結果、プロジェクトの開始に結びつけることが、第一の目的です。では、単に注文を取りやすい条件で見積ってよいでしょうか？　もちろん、これでよいはずがありません。目的の 2 つ目は、「適切な利益やコストを確保する」ことです。そのためには、見積りで提示する金額や期間が説明できて、納得してもらわなくてはなりません。統計や提唱されている見積りモデルなどのエンジニアリング的なアプローチを駆使して、論理的、合理的に説明できることが求められます。3 つ目は、「プロジェクトを成功に導く基盤を作る」ことです。これがプロジェクト・マネジャーにとって最も重要なことです。ソフトウェアの開発に仕様変更はつきものです。これをコントロールしやすい仕掛け、つまり、ベースラインをしっかり設定できているかどうかがプロジェクトの成否に大きく影響します。例えば、権威のある見積りモデルを使って算出した見積値により、2 つ目の目的である適正なコストが確保できていても、モデルに与えるパラメータが複雑で、プロジェクトの状況変化に応じて算出値の変化を説明できなければベースラインとして機能しているとは言えません。3 つの目的をすべて満たしている見積りが、よい見積りです。

　では、どう見積ればよいでしょうか。まず思い留めて欲しいのが、スコープとコストやスケジュールのベースラインの設定や変更に順序性があることです。スコープのベースラインが変更されたときに、コストやスケジュールのベースラインが変わります。したがって、見積りのときにも、以下のプロセスで作業を行えば、変更に強い見積りができます。

最終成果物で実現する機能を洗い出し、「何を作るか」を明確にする。

最終成果物に備える非機能要件のレベルを検討し、「どれぐらいのパフォーマンス」にするか明確にする。

最終成果物を作るための作業を定義し、「どう作るか」を明確にする。

「どう作るか」をもとに、「いくらかかるか」を明確にする。

　仕様変更があって 1 の作るものが追加されたり、2 の信頼性や性能などパフォーマンスの要件が変わると、3 の作業が追加されて工数が増え、4 の費用も増えます。実際の見積りの手順としては、概算見積りの段階では、1 の「何を作るか」は、あいまいな状態で機能やフィーチャーをブレークダウンしても定義し切れませんので、「どれぐらいの大きさのものを作るか」に置き換え、規模を見積ります。2 の非機能要件は、本来、成果物スコープに含まれるものですが、見積りでは 3 の「どう作るか」と合わせて、工数見積りに反映します。この段階では、WBS でのスコープ定義にも限界がありますので、こういう開発パターン、非機能要件のレベルなら生産性がどれぐらいになるかを想定して工数を算出します。4 では、算出した工数をもとに単価を設定して、売価やコストを見積ります。まとめると、見積りは、規模見積り→工数見積り→コスト見積りという順で整合性が取れていると変更管理もしやすくなります。とりわけ大事なのが、規模見積りです。これが成果物スコープのベースラインとして機能しないと、プロジェクトが混乱する要因となります。もともとの見積りからどう変わったかがわかるように、できる限り定量化して約束します。このときにポイントとなるのが、どういうメトリクスを使って定量化するかです。

非機能要件や実装形態など「どれぐらいのパフォーマンス」や「どう作るか」に左右されないメトリクスを使う。

計測ルールが明確で、ステークホルダー間で見積り結果を共有できるメトリクスを使う。

見積りからプロジェクト完了まで測定値に一貫性があるメトリクスを使う。

　ファンクションポイント法を使えば、上記の 3 つの条件を満たしますが、LOC（Lines of Code）を利用する場合も、機能要件を実現するために数ステップ、今回のプロジェクトは性能の要件が厳しいので数 % 増し、というように細かく約束した方が、要件が変わったときに対応しやすくなります。

　見積りでプロジェクトの命運が決まります。変更要求に対して、変更箇所と責任分担を明確にできる見積りがよい見積りです。

【05】プロジェクトによる人材育成

芝尾 芳昭 ME、DBA

東京

　プロジェクトは結果を問われるものなので、プロジェクト・マネジャーはプロジェクトを成功させようと一所懸命がんばりますが、プロジェクトの成功に人材の育成を意識している人は少ないかと思います。これまで、いろいろな人にプロジェクトの成功の条件を聞いてきましたが、「人材の育成」を成功の条件に挙げている人は 1 割にも満たないものでした。人材の育成がプロジェクトの成功条件に入っていないとなると、プロジェクトは人材育成の視点が欠けたままでプロジェクトは実行されることになり、プロジェクトで人がどれだけ育つかどうかは仕事の内容次第、またはその人の心持ち次第ということになります。しかし、プロジェクトはいろいろなことを学べる場でもあり、その場をうまく活用して人材を育成しない手はありません。その点を意識するかしないかで、プロジェクトから得られるものが大きく違ってくることになります。

　ある外資系の製薬企業企業では、プロジェクトの目的を「薬を作ること」と、「人を育てること」と明確に位置づけていました。実にプロジェクトの本質をとらえており、その企業ではプロジェクトから「薬」という価値と「人の成長」という価値を意識して獲得しようしていたのです。プロジェクトはどのみち企業活動を続ける以上は存在し、やるしかありあません。そうなれば、どうせプロジェクトをやるのであればどれだけプロジェクトからどれだけ価値を獲得できるかが勝負であり、プロジェクトの目的を広くとらえる方がいろいろなものが獲得できるチャンスが増えます。プロジェクトが人材育成の「場」ととらえ活動することにより、人はプロジェクトを通して成長し、人的資産が拡大することで、さらに企業に価値をもたらしくれます。プロジェクトの目的を小さく理解すれば小さい成果しか得られないでしょうが、大きく理解しそれを獲得しようとすれば得られるものも大きくなるということです。

　実際、私もプロジェクトの目的の重要な 1 つにコンサルタントの育成を置いています。コンサルティング会社は人しかいないわけで、人材が育たない限りプロジェクトも受注できないし利益も出せません。プロジェクト活動を通して人材を育成することは企業の戦略に直結しています。プロジェクトで利益を出すことは当たり前のことですので、それ以上に人材育成をプロジェクト・マネジャーの重要なミッションとして与えてプロジェクトを行っています。その結果、コンサルタントの成長は普通の企業に比べて随分早く成長していると思いますし、成長した人材が新たな価値を会社にもたらせてくれています。しかし、単に人の育成が大事だと言っているだけでは念仏と同じで、成果は得られません。そのためには、人材育成の活動そのものをプロジェクト活動に組み込む必要があり、組織としていくつか準備しなくてはなりません。われわれのケースでは、コンサルタントのスキルレベルと達成要件を 5 段階で定義し、その定義に照らし合わせてプロジェクトの最初にプロジェクトにおける役割として達成目標を確認し、プロジェクト・マネジャーはメンバーに何を期待しているかを伝えます。　そして、半年に 1 回は全プロジェクトに対してプロジェクト・メンバーのプロジェクトに対する実践の成果を評価しフィードバックしています。

　全プロジェクトを半年に 1 回フィードバックするため、プロジェクト・マネジャーの負担は少し増えますがプロジェクト・マネジャーにはその重要性を事あるごとに伝えることで、自ら積極的にフィードバックを行ってくれるようになっています。　プロジェクト・メンバーは自分の達成レベルを意識しながらプロジェクトに参画するので、プロジェクトにおいてもより積極的になり早くスキルアップしていきます。

　また半年に 1 回の評価はプロジェクトの個人評価のエビデンスとしても活用し、年に 1 回行うコンサルタントのプロモーション評価の基礎資料にも活用しています。このように、スキルレベルの定義、プロジェクトでの評価、プロモーションにおける評価という仕組みの中でコンサルタントはスキルアップを意識しながら、具体的な個人目標を持ってプロジェクトを行うため、ただ漠然とプロジェクトを忙しく行うことに比べてその意識差の分、早く成長していくことになります。

　しかし、ここで私が強調したいことは個人評価とプロジェクトへの貢献をリンクさせていることではなくて、プロジェクト・マネジャーが全プロジェクト・メンバーに対して半年に 1 回フィードバックを行っているという事実です。フィードバックは組織的に行われ、個人の自己評価、プロジェクト・マネジャー評価、プロジェクト・マネジャーやパートナーが集まった全体評価を行い、個人一人ひとりの成長や課題を客観的に議論し、その評価内容やコメントをすべて公開し個人にフィードバックしていることです。そのために、プロジェクトには直接関係ない時間をプロジェクト・マネジャーやメンバーもいくらか使いますが、それ以上に得られるものがありまます。全員が個人の成長をベースにフェアに評価するので、たとえ厳しい評価でも全員受け入れてくれます。プロモーションはそのフィードバックの延長にしかすぎません。この、ちょっとした組織としての取り組みが個人の成長を早め、会社にとっても大きな価値を作ってくれます。

　プロジェクト・マネジャーといえども会社の組織に一員であり、できる限り会社への貢献を考える必要があると思っています。人の育成は、育成してもらう側だけでなく育成をする側にも喜びを与えることにもなります。プロジェクト・マネジャーたるもの、プロジェクトの成功に「人の育成」を自分の目標に入れプロジェクトを運営してほしいものです。

【06】「しなければならないこと」と「できること」

奥沢 薫 PMP

東京

　プロジェクト・マネジャーは、様々なプレッシャーの下で次々と判断を下していかなければなりません。その際、「しなければならないこと」と「できること」をよく分けて考えることが大切です。

　「しなければならないこと」とは、プロジェクト目標を達成するために「求められること」です。一方、「できること」とは、プロジェクトが「提供できる能力」です。

　ここでは、「しなければならないこと」へのプレシャーが強い場合、「できること」の評価が歪められ、プロジェクト・マネジャーが誤った判断をする状況を考えてみます。

　プロジェクトやプロジェクト・マネジャーが、過去の実績を超える高い目標を目指す場合があります。過去の実績を超える高い目標とは、プロジェクトの規模、期間、品質、未経験の技術、未知のユーザー、経験の乏しい業務などです。つまり、今まで経験をしていない新たな試みです。

　こうした高い目標を目指す背景は様々です。例えば、プロジェクトの成功が一連の事業戦略の重要な成功要素になっている、新たな市場領域を開拓する得がたい機会となる、信頼を失うことができない重要ユーザーの要求である、キャリアアップするためにプロジェクト・マネジャーの力量が試されている、大幅なスケジュール遅延をなんとか回復しなければならない、無理をして値引きしたが赤字は出せないなどです。

　プロジェクトの高い目標は、プロジェクト・マネジャーに強いプレッシャーをかけることになります。こうしたプレッシャーを受けると、プロジェクト・マネジャーの心の中で「できること」が「できるようになる」の願望に避けがたく変化していきます。「できること」に対してこれこれの「対策」をすればこれこれのことが「できるようになる」、というように「～たら」「～れば」が判断の中に忍び込みます。「しなければならないこと」が、「できるかもしれないこと」（期待）になり、「できるはずのこと」（信念）になり、「できること」（確信）に転化していきます。

　例えば、従来の実績だと求められる期間ではしたことがない、ある規模のソフトウェアを開発する場合、開発工程を重ねて期間を短縮したり、やったことがない手法やツールを適用して生産性を高く見込んだりして、「できること」が嵩上げされます。

　しかし、開発工程を重ねることはより緻密な作業計画と進捗管理が求められます。こうしたプロジェクト管理は「できること」だったのでしょうか？　経験のない手法やツールを適用して、生産性を従来の実績以上に上げることは「できること」だったのでしょうか？

　「やったことのないこと」は、「やったことのあること」（実績）と比べ、成果を上げられる確率はかなり下がるはずです。

　「責任感」が強く、人に頼らず、やり遂げようとすることは、優秀なプロジェクト・マネジャーであることの重要な姿勢です。プロジェクト・マネジャーは、優秀であれば優秀であるほど、そのような傾向にあります。また、「しなければならないこと」を認識してそれに応えようとすることは、プロジェクト・マネジャーとして大切な姿勢であり能力でもあります。

　しかし、「しなければならないこと」への「責任感」とは裏腹に、実際に起こる事態は「できること」（実績）に従って展開していくことになります。そして、「できること」の確信が揺らぎ、「できるはずのこと」の信念が崩れ、「できるかもしれない」の期待がはずれることになります。

　今まで「できなかったこと」は余程「画期的なこと」がない限り「できること」にはなりません。そして、「画期的なこと」がうまく行くことは、しばしば運と確率の問題です。したがって、プロジェクトをよくマネジメントするには、「できること」（実績）の重みを十分認識し、「しなければならないこと」が手の届くところにあるかどうかを、心理的なプレッシャーに耐えて、冷静に判断しなければなりません。

【07】まずプロジェクトの「目的」を確認せよ

重木 昭信

東京

　プロマネの第一の使命は、担当したプロジェクトを成功に導くことです。ところが、どのような条件をクリアすれば「成功」といえるのかが、明確となっていないプロジェクトが存在します。これは様々な利害関係者（ステークホルダー）が存在して、それぞれの立場があれば当然のことで、プロジェクトの計画策定時点では、いろいろな目的が複雑に入り込んでいることの方が多いためです。

　コンピュータ・システムを最終的に利用するエンド・ユーザは、時間のかかっていた処理が迅速に行われることや、重複したデータ入力の省力化を重視しているかも知れません。後方の事務処理部門では、これまで手作業によっていた処理が自動化されることで、事務の正確さと稼動減少を求めているかも知れません。開発の窓口を担当している開発部門では新技術の採用を実現してアピールしたいと考えていることもあります。さらに、企業の管理部門ではコストの大幅削減に期待しているかも知れません。

　プロジェクトの計画を認めてもらうためには、多くの甘言が必要かも知れません。特に自分で構築を担当しないコンサルティングなどが計画を担当した場合には、このような「バラ色の夢」が描かれることも少なくありません。プロマネはプロジェクトを成功に導くために、これらの「バラ色の夢」と格闘することになります。プロジェクトの成功の第一歩は、「品質」を守ること、すなわち、Q ＝品質、C ＝コスト、D ＝納期を守ることと教えられます。これはプロジェクトの計画が完璧であるならば、という条件付きの話です。実際のプロジェクトの現場では、実現可能性をきちんと確かめていない絵に描いた餅のようなプロジェクトがたくさんあります。

　プロジェクトというのは、たいていが一品料理なので、毎回違うものを作ります。ですから、やってみないと本当にうまく行くか否かわからないということの方が多いと思います。計画通りに進めることができなくなったときに、費用が増えてもかまわないのか、それとも多少は質を落として対応するのかを悩むこととなります。

　こうしたことは、「バラ色の夢」を全部達成できない場合には、何を優先して考えるのかという優先順位づけの問題です。ところが、一度計画が進み始めて途中の段階で優先順位の話を始めると、なかなか決着がつきにくくなります。大きなプロジェクトで、たくさんの利害関係者がいるときほど決着が難しくなるのは、当然のことといえるでしょう。こうした問題が発生すると、本来はプロジェクトの進行管理を中心に考えるべきプロマネが、やむなく利害関係者の間を飛び回って、その調整を行うのが仕事になってしまうことも少なくありません。そこまで行ってしまうと、もはやプロジェクトの管理どころの話ではなくなってしまいます。

　これらの避けられない問題を回避する最もよい方法は、プロジェクトの「目的」をそのスタート前によく確認して文書化しておくことです。そうして何か問題が生じたときには、その「目的」に照らして、どうするかを判断するのです。多くの目的が定義されて「バラ色の夢」が描かれているときには、必ず、一番の目的を確認することが必要です。「バラ色の夢」でもほとんどの場合には、重要な 1 つの目的を達成することにより、ほかの事柄は派生するものであるというように理解して、目的を絞ることができるはずです。

【08】人を従えるのか、人が従うのか

神庭 弘年

東京

　プロジェクトとは、何が起こるかわからない未経験領域を含んでいて、資源も時間も厳しい制約の下にあります。プロジェクト・マネジャーは、これらを調整し円滑に進むよう判断し、目的を達成する事を職務としますが、これは席を温める間もないほど多忙なものとなります。プロジェクトの目的を理解し、自主的に業務遂行できるメンバーばかりであればプロジェクト・マネジャーはどんなに楽しくプロジェクトを遂行できることでしょうか。

　プロジェクト・マネジャーは、優れたリーダーでもあることを期待されます。リーダーには、フォロワーが不可欠です。フォロワーの行動を通じて、プロジェクトの目的とするものを正しく実現してゆくのです。ですから、リーダーはフォロワーを納得させ同意させるだけではなく、納得の上指示に従ってもらい、実際の行動を通じて結果を出し、プロジェクト目標を実現してゆかなければならないのです。

　有効なリーダーシップ・スタイルとは何でしょう？　指示をきっかけに容易に実行できるのは、手順の決まった作業の場合です。しかし、例えば IT プロジェクトの企画、要件の定義、業務処理仕様の開発、システム基盤への展開などは、非常に高度な専門的検討と推考が不可欠です。「作業にかかれ」では、指示している事にさえならないでしょう。

　リーダーの指示が有効に機能するかどうかは、実作業をする人達（ここではフォロワー）のスキルレベル、チームの一員として成熟度、対象の作業内容についての習熟度などによって、大きくゆらぐものなのです。つまりリーダーの優秀さは、リーダー自身では作り出すことができないと考えてください。

　どんなリーダーシップ・スタイルが有効なのか、という問いには要求している作業内容と担当するフォロワーの条件を明確にする必要があります。それ抜きで、一律に有効なリーダーシップ・スタイルを考える事は、あまり有効とはいえません。

　また、フォロワーの行動を通じて目的を達成するためには、フォロワーが従う権威が必要になりますが、戦場での軍隊の指揮命令といった国家権力による厳しいもの、上司・部下といった職制を通じた強制力によるもの、人望によるもの、専門家としての優れた知見、またそのことへの尊敬によるものまで、非常に多くのバリエーションがあります。先ほど例を挙げた様な、IT プロジェクトの企画、要件の定義といった、フォロワー自身のもっている創造的能力を十分発揮することを要求される場合には、高圧的な作業指示よりも、権限委譲や相互の信頼関係、相談と支援といった自発的な作業者の能力発揮を促すようなスタイルの方が、はるかに有効だと考えられます。メンバー相互に敬意を払うようなチーム風土も大切です。他方、技術レベルがまだ十分な水準にないとか、初心者である場合には、相談にのるというより、具体的で明確な作業指示の方が効果的で有効でしょう。

　プロジェクト・マネジャーは結果責任を果たさなければなりません。最近のソフトウェア・プロジェクトは稼動すればよいという程度の基礎的なプロセス支援を行うようなものはほとんどありません。とうにそのレベルのシステムはできあがってしまっています。もっと付加価値の高い、経営戦略に近いところでプロジェクトが運用され、特に早い段階での創造的な思考が強く要求されるようになっています。

　プロジェクト・マネジャーのリーダーとしての振る舞いはプロジェクトの成果達成の能率に大きな影響を及ぼすものですが、こうすればよいという定型的なスタイルを見つけることは困難です。どんな状況にも有効なリーダーシップ・スタイルはないと言うことに気が付けば、今日のプロジェクトが要求している、プロジェクト・メンバーの自発的で創造的な能力発揮を促すことを、プロジェクト・マネジャーの基本スタイルとし、その軌道修正は、プロジェクト・メンバーの「指示受け取り能力」の成熟度に応じて行う事になると、ご理解いただけるでしょう。

　特に、プロジェクトの立ち上がり時期は、多くの場合、初対面のメンバーでチームを構成するので、プロジェクト・マネジャーはチームワークの醸成をリードして行かなければなりません。この時期は、プロジェクト・ステークホルダーを把握し、プロジェクトの目的や達成基準をメンバーに伝え、チームのムードを作り上げてゆく最も大切な時期です。また、プロジェクトのゴールについて思いを込めて語れるのはこの時期しかありません。

　創造的で相互に助け合えるようなチームを作り上げるには、チームの組織風土の醸成が大きくかかわります。メンバーの技術的能力の向上、目標に対するコミットメント、信頼といった成熟度向上が、プロジェクト・マネジャーにとってどんなに重要な影響を及ぼすのか、深く理解し、それをどのように支援し推進できるかが、鍵となるのです。

　メンバーを従えるのではありません。メンバーがついてきてくれないのではプロジェクト・マネジャーとしての仕事は達成できないのです。

【09】予防的なプロジェクト管理のすすめ

重木 昭信

東京

　プロジェクトである以上、どうしても大勢の人と一緒にチームを組んでの仕事となります。一緒に仕事をやるといっても、多くの場合には、最終的には 1 人で作業を行えるように仕事を分解していきます。最近ではペア・コーディングというような、本当に 2 人で一緒に仕事をするというのもないわけではありませんが、多くの場合には 1 人で仕事をできるように細分化していくわけです。

　例えば、ソフトウェア開発で考えると、仕事を細分化して実行した後に、成果物を統合しながら、設計通りにできあがっているかどうか確認していくのが試験作業となります。1 人で全部を作っているときにはあまり問題になりませんが、大勢で分担をすると、どうしても解釈に差が生じて、試験のときにそれが発見されるということになります。もともと試験作業というのはそうした齟齬を発見して修正するのも目的の 1 つですから、ここでバグが発生することそのものが問題なのではありません。

　しかし、その解釈のブレ幅があまりにも大きかったり、たくさんのバグがあったりすると、全体の修正量が増加して、コストにも納期にも悪影響を及ぼします。そのために、日本では伝統的に「暗黙知の共有」が大事にされてきました。いつも同じメンバーで仕事をすることにより、お互いの個性や仕事の癖も理解しあった上で、以心伝心で大体こんな感じといえばシステムができあがってしまうような作り方です。このやり方をとると、閉鎖されたチーム内では効率的に仕事が進むのですが、新規参入者はうまく仕事ができずに簡単に仲間には入れられないといった問題が生じます。

　一方、欧米で採用されている方法は、暗黙知に頼らずにすべてを形式知に落として情報共有するというもので、新規参入者でも容易にプロジェクトの構成員として受け入れやすい反面、ドキュメントの記述とメンテナンスの負担が大きいという問題点もあります。

　こうした文化の違いは、これまであまり問題が生ずることは少なかったのですが、21 世紀に入り本格的なグローバル化が進み始めると、多くの局面で問題が生じました。今まで日本国内では立派に通用していた仕様書や設計条件書でも、中国やインドに発注したとたんに、日本特有の「行間を読む」ことが期待できずに、問題が発生します。暗黙知ではなく形式知で仕事をすることが求められるのです。

　こうしたことは、外国と一緒に仕事をして目立った形で現れたのですが、これまでの日本国内での仕事でもなかったわけではありません。そこで、これらの問題を解決するために、「予防的」な方法をとるべきではないでしょうか。いくら形式知化するといっても、森羅万象すべてを記述するのは非効率なので、ある程度は暗黙知に依存する部分は残ります。

　暗黙知の形成といっても、これには時間がかかりますし、流動性の高い雇用条件化では成立しにくいものです。そこで「演繹的な暗黙知」の共有が有効です。プロジェクトを進めるにあたっての、目的や判断原理を 10 項目ぐらいに取りまとめて、参加者全員と共有しておきます。そして、後はあらゆる判断局面においてこの判断原理に基づいて判断を積み重ねることとします。共有するのは原理だけなのですが、プロジェクトの参加者が同じ原理で動くことにより、暗黙知の共有と同様の効果があげられるのです。

【10】踏み込めば権限がついてくる

冨永 章

東京

　プロジェクト・マネジャーの大事な役割は、メンバーを成長させることです。いっぽうで PM の役割に就くことは、自分自身にとっても大きく成長するための絶好のチャンスです。ところが、その大チャンスを自ら狭め、縮小してしまうケースがいかに多いことでしょうか。プロジェクトを通じて自分がどう成長できるかは、プロジェクトに取り組む自分自身の姿勢次第であるという点を、ここで説明したいと思います。

　プロジェクトは、一般的に何らかの契約の下で実行されます。そこでは組織や企業の間（多くはお客様やスポンサーと受注者の間）の役割分担、取り組むスコープあるいは SOW（ステートメント・オブ・ワーク）を明確にしなければいけません。プロジェクト・マネジャーは、契約作成に参加すべきですし、少なくともその内容を熟知する必要があります。しかし注意しなければならないことは、まずはその出発点のところで自ら責任を狭めるような行動をとりがちな点です。例えば、作業項目をできるだけ多く相手の責任分担にすることで、何かが起きても責任や損害から逃れられると考える人たちもいます。果たして妥当なことでしょうか？

　そもそも責任分担のしかたは、個々の作業をどちらがやるのが適しているかによって決めるべきものです。役割分担はプロジェクトを確実に成功させるための重要な手段です。例えばモデリングを行う能力が自分側にしかない場合に、お客様に要件のモデル作成を押し付けるのは不適切です。責任逃れのために、相手がそれを確実には行えないかもしれないと知りつつ相手の分担として押し付けるようなことをもしすれば、出発点からのボタンの掛け違いです。それによって起こるプロジェクトの失敗は、双方に対して最大の損害を引き起こします。すべての計画は、プロジェクトを「必ず成功させる」という視点で作ることが肝要です。相手に責任を渡す場合は、相手が確実にその作業項目を遂行できることを確認すべきです。

　さて、スポンサー側にはプロジェクトを行う理由や背景があります。それは企業の戦略や中・長期ビジョンであったり、上位のプログラムであったりします。中・長期的な大ゴール実現へ向け、段階的な目標を定めながら達成していく方策は、組織でも個人でも有効です。そのようなプロジェクトの位置づけと上位のゴールについてプロジェクト・マネジャーが熟知することは、プロジェクト成功に大いに役立ちます。お客様に接するプロフェッショナルのすべてに共通のことですが、相手の立場に十分に踏み込むことが大事なのです。

　例えば、セールス向けのスマートフォン導入プロジェクトがあり、目標は販売訪問件数の 3 割増でした。ところがいくら工夫しても 1 割しか増やせないことが早い段階で判明しました。目標の達成が不可能なので中止すべきでしょうか。いいえ、めざすゴールは販売強化なのです。セールスのヒット率を上げる工夫によって、別の目標設定が可能な点をプロジェクト・マネジャーがスポンサーに提案し、仕事は続行されました。ゴールを熟知しているから解決策や積極的な提案ができ、採用されるのです。プロジェクトが成り立つ基礎には戦略や価値観、別の言葉でいうなら設計思想が存在します。プロジェクト・マネジャーはよく踏み込んでそれを知ることが大切です。もちろんメンバーともそれを共有するのです。お客様はそのような姿勢には特に敏感であり、どこまで相手のためを考えるかによって権限の大小が決まる場合がほとんどです。

　このようにいうと、プロジェクトのスコープを超えてがんばることを勧めるように見えるかもしれませんが、そういうことではありません。プロジェクトのスコープや契約条件を明確にすることは大事な知恵ですが、併せてプロジェクトに対する使命感や責任感を強く持つなら、相手の立場やプロジェクトの背景に踏み込むことは、誰にもごく自然なことなのです。リーダーがメンバーにどう働きかけるかについても同様の法則があります。行動を指示するだけで、メンバーが適切に動くかといえばそうではありません。人は自分の気持ちや意志に基づいて行動します。プロジェクト計画の背景やねらいをメンバーに知らせることや、そのプロジェクトを通じて各メンバーがどう成長するかを共通の価値観として共有することが極めて大切です。そうすればメンバーにやる気と責任感が生まれます。信頼できるメンバーには権限が与えられます。メンバーを成長させるのはプロジェクト・マネジャーの義務と心得ましょう。それが自分の権限をいっそう強くしてくれます。

　もし「責任範囲を極力限り、その中で全力を尽くす」というスタイルになっていると気づいたら、そこから抜け出る努力をしましょう。自分で可能なことであれば、相手のために積極的に責任をもって行動しましょう。それを習慣にすることが大事です。責任にこそ権限がついてくるからです。プロジェクトマネジメントという絶好のチャンスを最大限に生かし、自分自身を大きく成長させましょう。

【11】プロジェクトの条理と不条理

林 衛

日本、インド、中国、シンガポール、アメリカ

　プロジェクト活動は、必ず条理と不条理を含みます。これが、理解できていないリーダーは、条理だけを視野に置き、理想を目指しすぎて、失敗してしまいます。

　プロジェクトとは、人が、判断し、自ら決断し、実施する活動だからです。プロジェクトとは、達成目標を先に決めて、変革を創出する挑戦的で素晴らしい活動なのです。

　リーダーとメンバーが、前向きにいろいろな試みを行い、時には、間違いを引き起こしながらも軌道修正を図り、整えていきます。やがて、問題を克服し成功裏にやり遂げます。間違いや不条理が、問題なのではありません。学習と判断をしないのが問題なのです。強靭な精神ですべてを飲み込み、やり遂げるのです。完璧な計画や準備はありえませんが、できる限りの見通しを立てる努力は、重要です。

　ドラッカーは、1946 年に書いた『企業とは何か——その社会的使命』（ダイヤモンド社）の中で、企業のマネジメントについて次のように述べています。「重要なことは、正しいか、間違いかではない。うまくいくか、いかないかです。マネジメントとは、そのようなものです。」　また、マネジメントの値打ちについて、医療と同じように、うまくいくか、いかないかによって判断しなければならないと言っています。私は、ドラッカーの使う比喩で、医療とマネジメントを比較している点は、分かりやすく納得できる説明だと考えています。ここで言う「経営のマネジメント」を、プロジェクトのマネジメントに置き換えて実態と照らし合わせてみることで、プロジェクトの問題を浮き彫りにできるでしょう。私が、数多く関わってきた IT プロジェクトの現場では、30 年前と変わらず何が正しいか（正しい方法）のために時間が浪費されています。

　まさに知識労働の固まりといえるプロジェクトでは、何がなされるべきかが、第一の、しかも決定的な問題となります。プロジェクト活動では、いかに行うかは、何を行うかの後に来る問題であり、まずは、何がなされるべきかを追求します。それを行うことは、どのような理由（目的の明確化）があり、いかなる結果をもたらすのかについて、真剣に、しかも深く検討しなければなりません。プロジェクトの目的とビジョンを明確にし、責任と役割をアサインします。このことが各メンバーの腹に落ちていなければ成功はおぼつかないでしょう。プロジェクトには、論理的な構造だけではなく精神的な構造が存在します。

　私の見てきた様々なプロジェクトでは、プロジェクトを構成しているメンバーの多くは、いかにプロジェクトを行うかについての手段や技術について好きな人の集まりになりやすいものです。何がなされるべきかに責任を持てる人は少ないでしょう。繰り返し実施される IT や建築、土木などのプロジェクトでは、プロジェクトが、うまくいくための様々な工程と成果物、チェックポイントが方法論として定義されています。上流の要件定義（何を行うべきか）が最も重要な工程であり、次の設計（どのように行うか）以降の工程へとつながっています。しかしながら、何がなされるべきかを知らないマネジメント層が、実際には多くいます。メンバーも何も考えようとしないのが現実です。

　また、ドラッカーは、知識の生産性を上げるためには、結合することを学ばなければいけないと述べています。なぜならば、知っていることより知らないことのほうが多いので、知らざるものの体系化によって、価値を生み出す方法が重要になるということです。知識の結合は、まさに、プロジェクト活動にとって必至です。知識の結合には、問題解決の方法論よりも問題定義の方法論が必須です。知識や情報の分析とともに、問題へどう取り組むかの方法がより重要です。まさに複雑で多様な現代のプロジェクトは、このことで悩んでいるのではないでしょうか。

　私たちが、人生で学んだ様々な事柄は、そのまま、われわれが、苦しみながら取り組んでいるプロジェクトの問題・課題に当てはまっています。人生では、予期せぬことや不条理なことが起こります。同時に、予期せぬ成功や努力が実り喜べるようなことも同時に起こります。多くのプロジェクトが、知っていることよりも知らないことのほうが多いために様々な状況に遭遇するでしょう。

　つまり、プロジェクトの条理、不条理は、プロジェクト活動という性格上当たり前のことなのです。これを是として進めるべきです。決して、何の問題の起こらない、最初の計画したように進むプロジェクトを求めるべきではありません。

　最後に、プロジェクトの生産性向上のために必要なことは、メンバー（知識労働者）自身に、生産性向上の責任を持たせ、自らをマネジメントさせ、自立させることであり、プロジェクト活動中にもイノベーションを継続させることであると私は、考えています。

　私はプロジェクトで大切なことを以下のように考えています。

何が正しいかよりもできるかどうかが問題。

まず第一に問題の定義が、重要。

知識の結合により新たな価値を生み出すこと（衆知を集め価値向上に取り組む）。

生産性向上を、プロジェクトメンバーで生み出し、イノベーションを継続する

　これらが、できるかどうかが、われわれの問題です。

あとがき

底本について

　本書籍は、以下を底本としています（敬称略）。

「プロジェクト・マネジャーが知るべき 97 のこと」

原題「97 Things Every Project Manager Should Know」

Barbee Davis 編

神庭 弘年 監修

笹井 崇司 訳

株式会社オライリー・ジャパン 発行

株式会社オーム社 発売

ISBN978-4-87311-510-8

2016 年 5 月 16 日 初版第 3 刷

　またエッセイの文字起こしには、以下のサイトを参考にさせていただきました。

https://プロジェクトマネジャーが知るべき97のこと.com/

エッセイのライセンス

　各エッセイは、底本と同様 CC-by-3.0-US（表示 3.0 アメリカ合衆国）でライセンスされています。 つまり、各エッセイの著者名を明記することで、自由に転載や改変が可能です。商用利用も可能です。 ライセンスの詳細は以下を参照してください。

https://creativecommons.org/licenses/by/3.0/us/

表紙のライセンス

　表紙に使用している画像は、Wikipedia の「カラカサタケ」の項から借用し、加工しました。 この画像はパブリックドメインです。

https://commons.wikimedia.org/wiki/File:Macrolepiota_procera_2013_G1.jpg

Author: George Chernilevsky

最後に

　本書と同じ内容（epub ファイル）、およびその元となる素材は以下のサイトから入手可能です。

https://github.com/yoshi389111/kinokobooks

　底本に含まれる前書き、監修注、著者の詳細、写真などは、本書には含まれていません。特に監修注は参考となる情報へのリンクが多数含まれています。 これらの情報が読みたい方は、あるいは底本・原本の関係者に敬意を表したい方は、オライリー本の購入を検討すると良いと思います。紙の本も、電子書籍（PDF 版）もあるようです。

　また、転載したエッセイに誤字・脱字などがありましたら、上記 github のページまでご指摘をお願いします。