プロジェクトあるあるシリーズインデックス
タカハマです。
私の経験をもとに書いてきたプロジェクトあるあるシリーズですが、それぞれのあるあるがどんなものかは開いてみないと分かりませんでした。
それに、自分も「あのネタ書いたのはどこだっけ？」と探すのがたいへんだったりすることもあり、今回インデックスを作成しました。
noteは残念ながら表を埋め込むことができないので、テキストの羅列になります。
どの回で何のあるあるを書いているかこちらでざっと把握できます。またリンクもはっておきました。
どうぞご活用くださいませ。
＃＃＃＃＃ インデックスここから ＃＃＃＃＃
1:
タスク日数にマージンを持たせると、なぜかエンジニアはきっちり使い切る
2:
お客様と最終合意した要件は、開発が始まってからほぼ間違いなく面倒な方向に変更される
3:
プロマネは、「自分の工数25%」というイリュージョンによって火傷を負う
4:
あぶれたエンジニアの仕事をプロマネが巻き取りだしたら、プロジェクトは回らなくなる
5:
一番重要なイベントの日が「仏滅」に当たってしまったときプロマネは日程がずらせないか抵抗を試みる
6:
議論をする会議に参加するお客様が10名からどれだけ増えても、発言する人はだいたい2,3名程度である
7:
課題の優先度がお客様の指示でことごとく「高」にされ、すべての課題対応が共倒れになっていく
8:
合意したスコープ内かどうか判断が微妙な追加要件は、90%スコープ内にねじ込まれ、10%はスコープ外と認定される。どちらであっても追加費用は出てこない。
9:
「私PMPもってます」とやたら強調してくるプロマネに限って、プロジェクトをコントロールできない
10:
Excelで作成したスケジュール管理表の見栄えをよくすればするほど、プロジェクト開始後の更新の破綻が早まる
11:
アジャイルを、どんなプロジェクトにも適用可能な万能手法だと思っている顧客が少なからずいる
12:
ベテランのプロマネは、キックオフが明日のプロジェクトを突然渡され、状況がわからないまま突入するような痺れる経験をしている
13:
成果物をお客様に引き渡し後、トラブルが絶えないためプロジェクトチームメンバーが何年も張り付くことになる
14:
アサインされるプロマネにお酒が強いことを条件として求めるお客様がいる
15:
予約の都合で、急遽役員会議室のような広くて豪華なスペースで定例会議を行うと、緊張していつもの調子が出ない
16:
プロマネが存在せず、案件担当の長年の経験と勘によって成功してしまうプロジェクトが存在する
17:
契約にかかる期間の考慮が抜け、プロジェクトの最初からつまづく
18:
概算スケジュールを1か月30日で計算した結果、年末年始やゴールデンウィークトラップに引っかかる
19:
まれに自分の常識のはるか上を行くスーパーマンがお客様側に登場し、厄介な課題を尋常じゃない速度で解決していく
20:
ジュニアを脱皮し自信持ってきたくらいのエンジニアが、早いタイミングで「進捗率80%」と報告するタスクには魔物が潜んでいることがある
21:
プロジェクトの難局を乗り切るとき、プロには発想できないアイデアがお客様からでてくることがある
23:
プロジェクトの難局を乗り切るとき、プロはとんでもない力技を見せることがある
24:
プロジェクト前半時点でスケジュールが腹に落ちていないプロマネは、プロジェクトをコントロールする気がない
25:
中央省庁関連プロジェクトで提出する書き物は、日本語にとりわけ厳しい
26:
中央省庁関連プロジェクトをやっていると、働き方改革の真反対にいるのはあなた達でしょと突っ込みたくなる
27:
プロジェクトで割り当てられた稼働時間が足りなくなってきたら、プロマネは他のプロジェクトで余った稼働時間で帳尻を合わせがち
28:
社員の稼働コストをプロジェクトのコストと別会計にしていると、社員は問題解決のためにいくらでも残業時間を使おうとする
29:
お客様の要望にトリッキーな設計・設定で対応した結果、運用チームからめちゃくちゃ怒られる
30:
ほとんどのプロジェクトにおいて、プロマネは「コストの裁量権」と「リソースの裁量権」の両輪を持たせてもらえない
31:
拡大コピーして壁にでっかく張り付けたプロジェクトスケジュール表は、1か月たたないうちにただの壁紙と化す
32:
ドキュメントのネーミングルールを甘く見ていた結果、成果物提出の段階で泣きを見る
33:
対応したくないお客様の要件に対し「技術的には可能です」とエンジニアに答えさせてしまった時点で、プロマネとしては負けである
34:
ドキュメントレビューの依頼目的と人選をミスると、レビューラビリンスにはまりこんでしまう
35:
要件定義・基本設計・詳細設計の範囲の線引きは、プロジェクトによって変わる
36:
普段から冷静で温厚なプロマネであればあるほど、ここ一番でブチ切れたときの効果が絶大である
37:
リスク管理をきちんとやるプロジェクトはそこまで多くない
38:
プラスのリスクを管理するプロジェクトは、ほぼ見かけない
39:
経験豊富なプロマネは、なんだかんだ「自分の中で」リスク管理をしている
40:
プロジェクトの中で「WBS」という言葉が出たとき、頭の中に浮かぶのは「ワールドビジネスサテライト」である
41:
お客様の持っているメンテナンス用ネットワークがひどすぎて全く予定通りに作業が進まない
42:
課題管理表でカテゴリ分類しても、結局「その他」の課題が一番多くなる
43:
「プロジェクト憲章」という名前の文書を見たことがある人は少ない
44:
上層部がマイクロマネジメントしているプロジェクトはプロジェクトメンバーが無駄に疲弊する
45:
プロマネとプロジェクトメンバーとの距離の取り方は、プロマネによって全く異なる
46:
プロジェクト用メーリングリストを用意していても絶対個別でしかメールしてこないメンバーがいる
47:
「ひとりプロジェクト」という謎のプロジェクトが存在する。そして、それは人身御供にされたのだ、と後からわかる
48:
プロマネ自身の考えるプロジェクト成功が、組織から見ると全く逆になることがある
49:
イケてるプロマネは、進捗ミーティングを予定時間より早く終わらせられる人が多い
50:
プロマネが暇そうに見えるのはプロジェクトが順調であるということを理解してくれない人達がいる
51:
自分が経験してきたことのない別分野システム構築に対して、９割のエンジニアはできれば避けたいと思い、１割のエンジニアは挑戦しようと考える。この傾向は年齢上昇とともに強くなる
52:
アクションアイテム管理や課題管理をメールのみで完結させるプロマネが存在する
53:
エンジニア出身のプロマネは、お客様とのミーティングでエンジニアをさえぎって技術を語りだすことがある
54:
海外受注生産の入荷日を制作日数スケジュールに組み込むも、輸送にかかる日数を考慮してなかったことに直前で気付く
55:
小さなプロジェクトにもかかわらず、必要以上のプロジェクト管理をしようとするプロマネがいる
56:
プロマネが作成したスケジュール管理表は、他のプロマネにとっては管理しにくいことがある
57:
プロジェクト初期、お客様の5割は議事録を読まない。後半に進むにつれ、その割合は８割に達する
59:
キックオフ時、メール本文にテキストベタ打ちされたタスクと日付を「スケジュール管理表」として提示するプロマネがいる
60:
人知を超えた何かが作用してるとしか思えないようなトラブルが続くプロジェクトがある
61:
キックオフミーティングでプロジェクト計画に納得してもらえず、キックオフ不成立に終わることがある
62:
プロジェクトをうまく回せるプロマネは、事前のすり合わせと根回しがうまい
63:
プロジェクトをうまく回せるプロマネは、他人への頼り方がじつに上手である
64:
プロジェクト期間中、休みをとった日に限って必ずトラブルが発生する不運なプロマネがいる
65:
スケジュール遅延した中、チームメンバーがパンパンで稼働している状態で増員をしても根本の解決にならないことが多い
66:
メンタルが壊れそうな過酷なプロジェクトであっても、一人だけでも味方がいるだけで救われる
67:
何社かが関わるプロジェクトで、なぜか同じ立ち位置のはずの他の会社も含めた全体プロジェクト管理をやらされている
68:
作業現場が地方になればなるほど、プロマネの現地に顔を出す頻度が重要視される
69:
穏健に見えてここ一番で威圧感をチラッと見せる居合の達人のようなエグゼクティブがステコミに登場するとすべての流れが「御意」となる
71:
プロマネがミーティングの仕切りをエンジニアに丸投げする理由は、1割がプロマネ候補の育成のためである。9割はそのエンジニアより仕切る能力がないためである
72:
イケてるプロマネは、エンジニアの難解な説明をお客様に理解できる言葉に翻訳して補足してくれる
73:
プロジェクトの予算を積算した結果その額が何千万をこえる高額になるとわかったとき、思わず「百万円でいいから俺にくれ」と思ってしまう
74:
有志が集まって実施するボランティアベースの社内プロジェクトはだいたい途中で立ち消える
75:
会社の部門クラスの大きな宴会の幹事としてうまく仕切れる人は、プロマネの素養をもっている
76:
プロジェクト関連ファイルの保管場所を徹底しなかった結果、どこになにがあるかわからなくなる
77:
経験少ないプロマネがアサインされたプロジェクトには「育ててやるか」という気概をもつベテランエンジニアをアサインしてバランスが調整される
78:
システム入れ替えを成功させるお客様は、利用者への事前の浸透活動が秀逸である
79:
良い仕事をするプロマネは、えてしてエンジニアから嫌がられる
80:
現場で思わぬ機材トラブルが発生したとき、プロマネ自ら調達に走ることだってある
81:
エンジニアが軽微にとらえ、誰にも報告していない問題が後に大勢を巻き込む大炎上問題に発展することがある
82:
プロジェクトスケジュールを積み上げで作成すると、だいたいお客様の希望納期より長くなる
83:
たたき上げのエンジニアは、高いグレードで中途入社したエンジニアのスキルが見合っていないと判断したら恐ろしく冷たくなる
84:
プロジェクトをうまく回せるプロマネは、人との距離の取り方がうまい
85:
会社の偉い方々は、大規模か注目されたプロジェクトの実績でプロマネの実力を評価する。結果、地力のあるプロマネが流出していく
86:
エンジニア出身のプロマネは、深刻なトラブル現場に居合わせると、なんだかんだエンジニア魂が燃え上がることがある
87:
現場作業の発生するプロジェクトでは、想定していない窮地を現場の作業員の職人技によって乗り切ることがある
88:
チーム内にプロジェクト管理を意識する人が存在しない大型案件は、間違いなく炎上する
89:
標準化の名のもとに作成されたスケジュール表のテンプレートは、誰にも使われない遺物となってしまう
90:
プロジェクトの成果物を明確にしておらず、最終段階で想定していないドキュメントを大量に作成するはめになる
91:
体調不良で離脱するメンバーが続出するプロジェクトは、説明できない何かが影響しているとしか思えない場合がある
92:
大企業の通信ネットワークインフラを担当する社員数は驚くほど少ない。ネットワークの安定稼働はその人達の涙ぐましい努力で成り立っている
93:
評価の高いプロマネであっても、上司が変わると評価がガラっと変わる
94:
総務部には、電話設備を何十年もの間ひとりで担当している主がいる。IP電話システムに切り替えるプロジェクトでは、この主にいちばん気をつかう
95:
お客様からの追加要望に対し、理解したという意味で「わかりました」と答えたら、要望を了承したと受け取られてしまい後にもめる
96:
プロジェクト途中で離脱したエンジニアが、お客様から知らないうちに直接受けていたサブマリン依頼によって大騒ぎになることがある
97:
プロジェクトメンバーを恐怖によってコントロールするプロマネが存在する
98:
「プロジェクトマネージャー」という仕事は世間から見たらマイナーな仕事である
99:
純粋にプロマネのキャリアを積んできた人は、エンジニアあがりのプロマネよりもチームメンバーに冷酷な判断を下す
100:
「プロジェクト振り返り」の実施をもってプロマネの仕事は終結することを多くの人は知らない
101:
イケてるプロマネは、ぼんやりとしたタスクや課題を整理し、方向性を明確にできる
102：
失敗するプロジェクトでは、最初に計画されたスケジュールを忠実に守る事に固執しすぎる
103:
定常業務部門はプロジェクトによるイレギュラーな対応をネガティブに受けとめ、積極的には協力しないことが多い
104:
エンジニアの「作業負荷がかかるので面倒な設計・設定を避けたい」という回答はお客様に論破され破綻する
105:
プロ意識の薄いプロジェクトメンバーは、モチベーションを高めてもらわなければパフォーマンスが上がらない
106:
「任せる」ことの意味を「プロジェクト管理も含めてなにもかも丸投げする」事と思い込んでいるプロマネがいる
107:
プロジェクトに入ってからプリセールス時の「営業口約束トラップ」がさく裂する
108:
イケてるプロマネは、エンジニアの資料をお客様目線から指摘できる
109:
お客様とのトラブル時「あの会議で言った」と主張する内容に限って議事録に書かれていない
110:
お客様との打ち合わせ頻度を間違えるとプロジェクトがまわらなくなる
111:
プロジェクト開始時にスコープを突き詰めても絶対ポテンヒットが出る
＃＃＃＃＃ インデックスここまで ＃＃＃＃＃
それではまた！
日々感謝 m(_ _)m