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

レビュー内容

O’REILLY書籍の『プロジェクト・マネジャーが知るべき97のこと』（97 Things Every Project Manager Should Know）を読んだ。
その内容には、PMとして基礎的なタスクだが異なる切り口で重要性を再認識させてくれるものや、王道の進め方を拠り所としているために陥りがちな罠といった、身に染みるものがあった。今の自分にとって学びがあった項目を記述する。今後、自分がもう少し成長してから読んだとすれば、また別の記載内容がそのときの自分に刺さるんだろうな。

#05 複雑よりもシンプルな方が良い

自分のアプリに新しい機能を追加するのは簡単だろうか？
設計、実装は知らず知らずのうちにシンプルになるわけではない。

#06 負債を支払う

完璧なコードは書けなくとも、基準に十分適合したコードを書く場合を、「技術的負債」であると考える。

#08　シンプルにいこう

要件をシンプルなツリー構造をイメージして書く。マインドマップのように。

#09　あなたは特別ではない

NIH（Not Invented Here）症候群に狂わされるな。

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

要件リストではなくユーザーストーリーの作成を行え。

#12　優れた開発者を見つけるには

世の中がアジャイル開発に向かうにつれて、ソフトスキルの重要性が増している。
プロジェクト制約を受け入れながらも、優れた製品を作ろうと、うまくバランスを取れる技術者かどうか？

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

完璧とは、取り去るものがなくなったときである。

#17　要求と仕様

プログラマでない人によって作られた、厳格だけれども脆弱な仕様によって縛られるべきではない。
作ろうとしているもの（what）とその作り方（how）を分けよ。

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

あなたは質問の仕方を学ばなければならない。

#22　開発者を活かす

最善のことは邪魔をしないこと。

#23　巧妙なコードはメンテナンス困難

コーディング実務や成果物を改善する革新的な手段として、開発者に自由を与える。
ソフトウェアコンポーネントとシステムメタデータの「結合の喪失」を避ける。

#24　人的要因を管理する

人はストレスがあると、積極的な問題解決行動ではなく、過去の行動に後戻りしようとするものだ。

#27　見積もって見積もって見積もる

見積りの本当の説明責任とは、見積りを当てることではない。見積りが外れそうになったらすぐに警鐘を鳴らすことである。実際にどうだったかなど、くだらないことだ。

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

各イテレーションには、ハックをリファクタリングするという活動も含むべき。
ソフトウェア業界の現場では、高品質で約束通りのリリースを着実に納品するためにできることがたくさんある。

#31　顧客からの声

財布を握っている人たちから話を聞くことは役立つ。今や先端技術が簡単に使えるようになった。テクノロジーを投入する前に、顧客がうまく扱えるかどうか考えよう。

#32　物事を正しくとらえる

物事を正しくとらえるということは、最高のソリューションを探すということであり、ユーザーが正しいと感じることを探すのではない。

#34　60/60ルール

ライフサイクルコストの60%はメンテナンスによるもの。全メンテナンス時間の30%が製品を理解することに費やされる。私たちのソフトウェアは変更可能なように設計されなくてはならない。

#44　方法論を崇拝しない

結局のところ、あなたの良識以上に重要で順守すべきだと思えるプロジェクトマネジメント本や方法論などは存在しない。
もっと軽いやり方が適しているプロセスはどれなのか？

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

有用なソフトウェア製品を作ることが私たちのゴールではない。メンバーが助け合い、潜在力を発揮できる環境を作る必要がある。

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

3つの制約の基本概念は、3つの頂点に時間、スコープ、コストというラベルをつけた正三角形になる。中央のスペースがプロジェクトの品質を表す。

#50　ロードマップを作ろう

ステークホルダーにとって、どのフィーチャーが重要なのか？現実的なタイムフレーム（通常は3か月ごと）でまとめたフィーチャーリストに、各フィーチャーに関するビジネス価値を書いておく。

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

ステークホルダーと一緒にスコープ記述書を定期的に見直すのはよいことだ。

#56　「自前主義」に陥るな

医者やパイロットは「並の」プラクティスを容認しない。
プロジェクトマネジメント知識体系とは一般的に「すぐれた」プラクティスだと見なされているスキル、ツール、テクニックのことである。

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

バイパーウェアとは、延々と語られているけれども、実際には一度も実現されたことのないソフトウェアのこと。
早く成功することは遅く成功するよりも百倍よいことにすぎないが、早く失敗することは遅く失敗するよりも百万倍もよいことだ。
アジャイル開発者は「今」テストを書いている。テストは重要だ。今すぐやるくらいに重要だ。

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

ソフトウェアは変更可能である。誤った考えに見切りをつけられれば、ソフトウェアの柔軟性をありのままに享受することができる。

#64　インテグレーションポイントを知る

データがどう流れているかを視覚的に表現した図を用意する。連結点（インテグレーションポイント）を明記しておこう。システムがお互いに依存していることを説明したドキュメントがあると役に立つ。

#70　プロジェクトは解決策の追求である

スコープを成果物にまで細分化したWBSを作るとき、チームメンバーやスポンサー、その他ステークホルダーも参加させよう。チームがプロジェクトマネジャーに異議を申し立て、チームメンバーが進んで共通の意見をまとめるべきだ。

#71　鍵は人間にある

成功はチームメンバーの姿勢と適性にかかっている。リーダーシップに関する本を貪欲に嫁。
CRAMモデルによると、モチベーションは検討すべき最後の問題である。

#72　ドキュメントは手段であり目的ではない

計画について誤解している組織では、プロジェクト・マネジャーに重要な「最高の価値を実現できたか？」という質問をしない。

#73　アーンドバリューとベロシティは共存できるか

ベロシティという用語において、開発者は自分自身、そして先週選んだ仕事と比較されるだけ。

#76　よいスポンサー、悪いスポンサー、ひどいスポンサー

ひとつの解は代理のスポンサーを見つけること。あるいは影響力のある人に対して、仲裁に入るよう頼んでもよい。
弱いスポンサーであれば、何が期待されているのかを教えることで、その役割が果たせていないことを自覚してもらえるかもしれない。

#77　約束以上にすべきか、約束以下にすべきか

フィーチャーの分類では顧客は何もかも「高」にしてしまう。
予備費は懐にしまってあり、開発の最終段階になっても予備費が残っていればプロジェクト・マネジャーはその蓄えを開放することもできる。

#80　プロセスについて教える

私はクライアントに向かってこう言う。もし見積りを間違えたときには、お金を使い果たしてしまう前にあなたに知らせると。

#81　ステータスという間違った考え

「完了」を定義するのは顧客であり、ステータスレポートではない。チームの報告が完璧であるように見えても、私たちは間違ったプロジェクト進捗を見ているのではないか？

#82　みんなが聞きたいことは何ですか？

どんなテクノロジーを利用するにしても、あなたが聞き手に売り込むのはアイデア。スライドやレーザー光線ショーではない。聞き手にとってなぜそれが重要なのかという質問に立ち返ろう。

#84　ステークホルダーをずっと参加させる

需要なステークホルダー全員のニーズをうまく調整する。ステークホルダーにアイデアを求め、彼らからのインプットを活用せよ。

#88　私たちはスーパーヒーローではありません

どの分類に当てはまるだろうか、と考えてはいけない。すぐれたプロジェクト・マネジャーには柔軟性が必要だ。最も効果的に対処するために、自分の安全地帯から踏み出せなくてはならない。

#92　ステータスレポートは開発者に嫌がられ、マネジャーに愛される

計画にはないけれども役立つ貢献をした人にはコーヒーショップのラテクーポンを。その仕事が「全体像」にどう関係しているか、直接的なつながりを与えよう。
重要なことは、あなたが第三者の視点から、ステータスレポートを書きあげるというタスクを見ているかを確認すること。

#94　ビジョンを共有する

みんな成功したいし、貢献を誇りに思っている。どれだけプロジェクトをさぼろうとしているように見えたとしても。
ビジョンを共有せよ。それによって、ほとんどの人は実際にはチームの課題を解決しようと力を合わせて取り組んでいる仲間だということがわかるだろう。

日本人版 #01　自分に対する約束をどう守るか

個人の動機付けの方法は、時間割に従う、憧れのモデルのつもり、ライバルへの意識、他人のためにやる、座右の銘を携帯するなど。

日本人版 #03　「正しい判断」にこだわるな

プロジェクトでは致命的な欠陥がない選択を心がけよ。さもないと、プロジェクトの完成に大きなリスク要因となる。複数の一長一短の案が残れば、あとはどの案でもたいした違いはない。

日本人版 #05　プロジェクトによる人材育成

プロジェクトの目的を大きく理解しそれを獲得しようとすれば得られるものも大きくなる。プロジェクト・マネジャーたるもの、「人の育成」を自分の目標に入れてほしいものだ。

日本人版 #06　「しなければならないこと」と「できること」

「しなければならないこと」への「責任感」とは裏腹に、実際に起こる事態は「できること」（実績）に従って展開していき、期待がはずれることになる。
「しなければならないこと」が手の届くところにあるかどうか、判断せよ。

日本人版 #08　人を従えるのか、人が従うのか

リーダーの優秀さは、実作業をする人たちによってゆらぐため、リーダー自身では作り出すことができない。
最近のプロジェクトは、付加価値の高い、経営戦略に近いところで、早い段階での創造的な思考が強く要求される。どんな状況にも有効な定型的なリーダーシップ・スタイルはない。