概要

この記事の目的は、PM・エンジニアに私の気をつけている観点を伝えて、
少しでも炎上するリスクを下げて、皆に幸せになってほしいという思いで書いています。
最近、マネジメントの勉強をしていて思うところがあったので、自分なりの考えをまとめて、
多くの人に知ってもらうことでレスポンスから別の考え方を得ることも目的としています。

私について（自分語りなので、興味ない方は読み飛ばしてください）

私は元々SESの下っ端エンジニアでした。
一ヶ月の研修を終えた後、経験を数年盛られて炎上プロジェクトへアサイン。
アサイン後は速攻で休日出勤のアンケートが出回ってくるレベルで炎上していました。

一年前後、そこで馬鹿にされながらも、虎視眈々と個人アプリを作って
GooglePlayにリリースしたりなど実績をひたすら積み上げて、転職に成功しました。

転職先では中堅エンジニアとしてプロジェクトにSESでアサインされましたが、
そこのプロジェクトマネジメントも悲惨な状況でした。（最初よりはマシでしたけど）
このSESをしつつ、会社で受託していたアプリ開発を行い、2足～3足草鞋で仕事をして、
一年で痺れを切らして完全な受託チームへ移行。

最初は受託側のエンジニアとして稼働していましたが、
そこでもプロジェクトが良く燃えていました。
リカバリで炎上しているプロジェクトに駆り出され、、、片付けたと思ったら次の炎上へ。。。

終わらない炎上に嫌気がさして、自分でプロジェクトをコントロールする立ち位置を確保しました。
そして、「僕が考えた最強のプロジェクトマネジメント」を実施しながら、
現在は4、5案件をコントロールしながら一つも燃やさずに数年続けています。
働き方はリモートワークで客先往訪等以外では引き篭もりながら、ノンビリ仕事をしています。

結果的に這い上がって成功を納めている方だと思いますので、
今悩んでいる方もこういう未来にも繋げられることを希望の一つにしていただければと思います。

NG一覧

本題ですが、マネージャーがプロジェクトを燃やすのは非常に簡単です。
マネージャーには多岐に渡る仕事が存在しますが、一部でも機能不全に陥ればあっさり燃えます。
私が見てきた中で燃えた原因を独断と偏見で検討、考察します。

• そもそも最初から炎上するプロジェクト
• スケジューリングがなっていない
• 人員が足りていない
• 人間関係が悪くてチームワークが発揮できない
• PMがオーバーワークで機能不全になっている
• 客先調整がされず言われるがままでプロジェクトの工数が不安定
• プログラムから逃げた人間がPMをしている
• ゴールに到達するための手続きができない
• そもそも人として生きるなら絶対に関わってはいけないプロジェクト

解説

そもそも最初から炎上するプロジェクト

プロジェクトは契約段階で燃えることが確定することがあります。
極端な例ですが、予算10万円で開発工数3ヶ月の仕事があったとすると誰がやりたいでしょうか。
正直「真っ当なエンジニア」であれば、ある程度の目算を立てて断る事もできるでしょう。
ただ、お客さんの前に出るのが「真っ当なエンジニア」ではない場合も多々あります。

スケジューリングがなっていない

プロジェクトのスケジジュールを組む為には幾つかの情報を集めた上で、検討が必要です。

• 確定している仕様をまとめる
• 未確定の仕様をまとめて、当たりをつける
• リスクのある機能を把握し、問題の解決見込みを立てる
• 客先のスケジュールを把握する
• 各人員からどのくらいで機能を開発できるか見積もり確認をする
• 各々のお休みのスケジュールを確認する
• プロジェクトの予算とスケジュールの採算が合うように調整する

上記は当然として、他にも状況によっては検討すべき課題が発生することがあります。

仕様周りについては、開発することに対して直接影響があるカテゴリになるので、必ず把握する必要があります。
仮にこれができていないマネージャーがいるなら、その時点でマネージャーとは言えないでしょう。
もしマネージャーが把握してないけれども、エンジニアの方で仕様を把握し、調整できているのであれば、
エンジニアの領域から抜け出した方が稼げるかと思います。

客先のスケジュールについてもマネージャーはしっかり握った方が良いです。
お客さんも人間で、ましてやシステムの理解度が足りない場合などもあるので、
当然相互の認識ズレによる気付いた時の緊急的なスケジュール変更などが起こりうるでしょう。
仮にですが、テスト前のアプリを提供して、アプリの社内発表会などで使われて、クラッシュした日には皆が不幸になるかと思います。

機能見積もりの話ですが、マネージャーはエンジニアに対して、「スケジュールを完成させる前に」
各々担当させようとしている機能がどれくらいでできるかを必ず確認すべきです。
エンジニアの立場に立って考えれば、至ってシンプルな話です。
マネージャーが1人日で機能を完成させられると見込んで提出したスケジュールが、
見積もりのミスで5人日かかったとしましょう。
これで納得するエンジニアがいるでしょうか？遅延をエンジニアのせいにしますか？
未熟なエンジニアであれば、自分を責めて何とかしようと努力してくれるかもしれませんが、人間関係に問題を残します。
優秀なエンジニアであれば、絶対に納得しないでしょう。そして協力は最悪してくれるかもしれませんが、
余程の義理や義務がなければ、マネージャーのことを必ずいつか見限ります。
重要なのは独断で決めることではなく、第一線でシステム作りと向き合ってくれているエンジニアの同意と協力です。
エンジニアに確認することによって、クロスチェックで間違いに気付けるかもしれませんし、
仮に間違っていたとしても、責任の分散ができるので実装面ではエンジニアが頑張ってくれるでしょうし、
スケジュール面ではマネージャーが調整すれば、それで終わる話です。

お休みについては法律と人間らしい生活を守る為に、予め確認するのは当然です。
お休みを捻出する為に、残業したり前に仕事を寄せたり、エンジニアに調整させたりするのはNGです。
飲食系アルバイトで稀に見たりするのと同じ、
「お休みするなら代わりの人を探してください理論」のマネージャーと同じくただの怠慢です。
その理論を押し付けるならエンジニアで全部解決できるので、マネージャーの価値がなくなります。

最後にプロジェクトの採算が合うように調整する仕事についてですが、
これができていない場合、エンジニアにしわ寄せが全ていきます。
ちゃんと予算に見合うように仕様、スケジュールを調整してください。
予算間に合わない仕様を受け入れると、エンジニアが頑張りながら
深夜・明け方まで必死にコードを書かなくてはなりません。
その結果、そのシステムが客先都合でリリースされないとかなった日には、
エンジニアの心を折るには十分なシチュエーションです。
お客さんがいつ、何をしたい、というのを適切に汲み取り、
効率的にその問題を解消する為に脳味噌をフルに活用し、
調整し、スケジュールに組み込む必要があります。
赤字のプロジェクトにした日には、採算が合わないため客先との縁も切れるし、
会社に打撃も与えるし、PMもエンジニアも疲れ果てます。
初動で必ず問題を潰してください。

人員が足りていない

この記事を読んでいる皆さんは残業をしていますか？
もし、残業が発生しているのであれば、人員が足りていない可能性があります。
突発的に発生する場合はある程度許容領域だと思いますが、常習化しているとかなり危険なゾーンです。

人員が足りない理由は何点かあります。

• 予算が足りず人員を投入できない
• 社内政治等により人員を奪われる
• 足を引っ張る人員がいる

これらの問題は嘆きたくなるような外的要因に近い物ですが、
この問題をクリアするのもマネージャーの仕事になります。

人間関係が悪くてチームワークが発揮できない

人間関係の問題はシステムに対して影響を与えます。
勿論、理知的であったり、強いプロ意識がある人であれば、
感情やモチベーションには大きく左右されずに一定の成果を挙げてくれます。
ですが、チームともなると多かれ少なかれそう言った人員のみの構成は不可能になるでしょう。

具体的に私が経験した内容を元に検討すると、
少なくとも以下の内容に繋がる見込みがあります。

• PMの悪意ある行動
  • PMからエンジニアに対して不当なスケジュールを吹っかけられる
  • エンジニアから共有した内容をPMが握り潰す
  • 悪意あるタスクを割り振り、業務過多に追い込む
• エンジニアの悪意ある行動
  • 責任の領分を誤魔化して品質を担保しない
  • 問題発生時の対策を立てても、実行がされない
  • 本質的に解決しなければいけない問題を先送りし、当人のやりたいことをやり始める
  • 納期を守らない
  • 悪意あるバグを仕込む

人間関係は悪化すると複雑になりがちですが、
業務やお金を通すことで更に複雑化することが想定されます。
原因の解析は難しいので、本記事ではPM視点、エンジニア視点の
「事前の動き」と「悪化した場合の対処療法」を主軸におきます。

各NGに対してよりPMとして良い対処

そもそも最初から炎上するプロジェクト

もしもPMが契約段階で梯子を外されているなら、梯子をかけなおして絶対に契約に参加してください。
経営の仕事だから、営業の仕事だからとか言っている場合ではないです。
そもそも条件面でPMが話を理解していないのは論外です。
営業の仕事をいっそ奪い取るレベルで戦わないと、煮え湯を飲むのはPMとエンジニアです。
一人我慢すれば良いという話ではないので、会社の体制に問題があるならその改善からPMが戦う所になります。
もし、営業側で文句が出るなら不勉強である営業が悪いだけ、だと私は考えています。

スケジューリングがなっていない

解説で書いた通りのそれ以上でもそれ以下でもありません。
基本的な指針は以下の通りです。

• 確定している仕様をまとめる
• 未確定の仕様をまとめて、当たりをつける
• リスクのある機能を把握し、問題の解決見込みを立てる
• 客先のスケジュールを把握する
• 各人員からどのくらいで機能を開発できるか見積もり確認をする
• 各々のお休みのスケジュールを確認する
• プロジェクトの予算とスケジュールの採算が合うように調整する

これらをこなす事によって、初めてスケジュール構築が真っ当にできていると私は判断します。
ただ、プロジェクトの性質、客先との関係性、社内政治によっては、不要の仕事があったり、逆に増える仕事もあるかと思います。
スケジュールとは未知の事象に対する道しるべを作る事に他なりません。
少し抽象的な言い方に置き換えると、

• 現状を把握する
• 未来の予想を行う情報を収集する
• 状況変化に耐えうる関係性を各所に構築する

ということが出来ている事が本質的には重要な事だと考えています。

また、エンジニアに見積もってもらった数値を鵜呑みにして「現状」に置き換えてはいけません。
人はコミュニケーションをとる場合、自分にとって都合の良い解釈をすると言う悪癖があります。
見積もり、スケジューリングフェーズで多々発生するコミュニケーションミスの最たる例は、

• エンジニアは実装するまでの最短の工数
• PMは全体としてFIXができる工数

と相互で認識違いを起こします。必ずPMは言われた数値に何が含まれているのかチェックしてください。
そして、リスクが含まれていない場合は、リスクの検討を行うようにしてください。

人員が足りていない

前提として工数の考え方をお話します。

雑な例えにはなってしまいますが、開発工数が20人日の小規模プロジェクトがあるとしましょう。
ここに1人のエンジニアを投入すると20人日で完了するでしょうか？
現場を良く知っている方なら必ずNOと回答するかと思いますし、
実態はその通りで一人頭の生産性が変わります。

有能な人員であれば、半分の10人日で終わるかもしれませんし、
新人で右も左もわからなければ40人日かかるかもしれません。
ピッタリ合致する方が稀で、仮に合致しているとしたら
残業時間や、うまいこと完了のタイミングを調整していたり等、実態を良く見たほうがよいでしょう。
※当然ですが、PMの信頼が薄いとエンジニアから真っ当な回答が得られません。

更に人が増えれば増えるほど、認識合わせの会議や
クロスチェック、手戻り、前後関係の存在するタスク、等で
このズレが個人から組織へとシフトし、更に大きなブレが発生します。

なので、「スケジューリングがなっていない」で書いてある通り、
「現状を把握する」という対応がより重要になってきます。

で、更に重要なのが「現状を把握したあと」からなのですが、
人員が足りない場合は、基本的に泥臭い仕事になります。
考えうるあらゆる手段を使って、生産力向上をはかってください。

スケジュール段階で失敗する旨を必ずアラートとしてあげれれば、以下の対応で十分かと思います。

• 「ある程度スキルのある」人員の追加
• 品質の問われない箇所は人海戦術を行う
• 定型的な仕事は自動化する
• 納品のENDを後ろに調整する
• 要件を減らす
• 制約事項を設ける
• 期間があるなら、教育による全体的な生産性向上をはかる
• いずれの対策も出来ない場合、失敗する旨を伝える

「いずれの対策も出来ない場合、失敗する旨を伝える」についてですが、
個人的にはここまで出来る人員がいれば正直引く手数多だと思います。
もう少し伸び伸び働くことができて、給料がいい職場に転職することを推奨いたします。
組織改善も重要ですが、一つも調整が効かないのであれば、風通しはかなり悪いかと思います。

では、逆にスケジュール段階で人員が足りてない事に気付かず、後の進捗確認、
フェーズ移行のタイミングで検知したとしましょう。
まず第一にPMのミスです。
このタイミングで検知したという未来の予想が出来ていないことを反省すべきで、
次回に必ず活かすようにしてください。

で、対処は以下の手法があるかと思います。

• 納品の期限が調整できるか検討する
  • 建設的に話を進めるため、客先スケジュールを抑える必要があります
• 要件を減らせるか検討する
  • 予めやっておくとここで響いてくるので、先んじて優先度等を明確にしておくとGood。
• 「かなりスキルのある」人員の追加
  • 並程度では炎上はそうそうカバーできません。状況が悪化するので気をつけてください。
• 「最終手段」として、エンジニアの稼働を上げてもらう

何故、一番調整の効きやすいエンジニアの稼働が「最終手段」なのかの理屈を説明します。

いくつかありますが、第一に責任の所在についてです。
あくまで私の考えですが、これはPMに問題がある事象だと思います。
何故PMが悪いのにエンジニアが頑張る必要があるのでしょうか？
そこにエンジニアのメリットはありますか？私はないと思います。

第二に継続するチーム、プロジェクトの観点についてです。
今回、エンジニアの稼働を上げてハマらない工数を無理にハメたことになります。
本当は100人日必要な開発を80日で、実態は100人日分の稼働です。
客先からみた場合、どうなるでしょうか？
100人日の開発が80人日分で買えたわけです。裁判と同じで前例作った事になります。
これからは100人日の開発が80人日前提で飛んでくる可能性があるでしょう。
こうして、慢性的に死に向かっていくプロジェクトが完成するわけです。
しかも頑張ったのはエンジニアで、PMは何一つ苦労していないわけです。
当事者意識のないマネージャーがどういう末路を辿るか、私は考えたくないです。

人間関係が悪くてチームワークが発揮できない

PMの事前の方策は大きく分けて3つあります。

• エンジニアに嫌われない、可能なら好かれること
• 指揮系統が確立されており、嫌われてもモチベーション低下や不正の入る余地がない土台の作成
• 組織編成の権限を持つ人とパイプを作っておくこと
  • 内部で解決出来ない場合の保険の意図

いずれも環境や対人にて大きく影響を受けるため、具体的な解説は省略します。
次に対処療法ですが、これは人間関係の悪化の深度を考慮し適切に対策を進めるのが良いです。

• 問題がある人物と直接対面で話し合い、双方の具体的な課題を洗い出し根幹の解決を目指す
  • 比較的軽度の問題の場合、この対策を早めに行う事を推奨します。
  • 根が深い場合は効果は見込めません。
• 第三者にヒアリングを要請し、問題点を間接的に吸い上げる
  • 軽度から中度の問題対策です。対面が難しい場合の手法にも活用できます。
  • 協力者が必要なので、良くも悪くも影響がややあります。
• 直接的な指示系統から、間接的指示系統に切り替える
  • 中度の問題の対策です。
  • 根本的な解決ではないため、時間経過で状況が変化し適応できなくなるリスクがあります。
  • PM→エンジニアの指示系統が存在した場合、リーダーを立ててPM→リーダー→エンジニアの指示系統に切り替えます。
• チームからエンジニアを外す
  • 中度から重度の問題の対策です。
  • パイプや権限を活用した手段になるため、影響度合いがやや大きいです。
  • 不当にならない理由が必要です。
• システムの品質を確保するためのステップを増やす
  • 業務のみに着目した対策です。
  • 業務コストが増大しますが、悪意ある行動がある程度抑制できます。
  • 感情的には反感が発生しやすいため、それなりの理由を挙げても関係悪化のリスクがあります。
  • 他者の依存度が高まるためエンジニアの成長を阻害します。
• 重大な問題に発展しない場合、静観する
  • 現状維持対策です。
  • 悪化の原因の根が深くない場合や再発性の無い原因の場合、時間的解決が見込めます。
  • 悪化の原因の根が深い場合は、後手に回る可能性があるため、状況を理解する必要があります。
• チームのPMを降りる
  • 退避による対策ですが、問題が手に負えない場合の最終手段です。
  • 色々なリスクが付きまとうため、この手をうつときは相談や根回し、準備等が必要になります。

PMとしては、予め味方をある程度作っておくのが前提になります。
ただ、良くも悪くもPM側は権限があるため、不当にはならないように慎重に事を進めると良いと思います。
エスカレーター式に席が空いた、長年努めていたという事を理由にPMまで上り詰める方もおり、
そう言った場合は権限や人間関係に対する意識が希薄な場合があります。
対人として当たっていることを、今一度しっかり意識する必要があると思います。

対策した結果として、問題対策に対して得られるリターンは生産性の正常化のため、
コストに対して一切割にあわないものになります。
気配りや言動、思いやりで対処できる場合、日常的な立ち振舞を見直して、
人間関係を悪化させないように努めるのが一番の正解です。

各NGに対してエンジニアとして賢い対処

そもそも最初から炎上するプロジェクト

もしも貴方が野心に溢れているエンジニアであるなら、むしろチャンスと捉えると建設的です。
会社にかけあう、PMにかけあうなどで、契約段階から同席させてもらえれば大金星だと思います。
責任を持たず、状況を知れて、支払うコストはその時の打ち合わせの時間だけです。
個人で今後活動するにしろ、スキルチェンジにしろ必ず役に立ちます。
可能ならリスクと代替案を織り交ぜながら、良い方向にプロジェクトを持っていければ尚Goodです。
現実面、上記が無理そうなら一早く一抜けたが出来るチャンスにもなります。
炎上してズタボロになる前に逃げるのも生きる上で大切です。
そもそも、もし同席ができず、状況に流されるままにしかならないなら、
給料分の仕事をこなして環境を変える手段を取る準備をするといいでしょう。

スケジューリングがなっていない

今がどんなに忙しかろうとも自分が将来関わる箇所の見積もりを積極的に行ってください。
「よくわからないから」「面倒くさいから」「忙しいから」という言い分はわからないでも無いですが、
ここを放棄するとPMの独断で決められた場合、文句を言う資格がなくなります。
実質権利の放棄です。
PMから依頼がないようであれば、自分で見積もると言ってください。
拒否された場合は、スケジュールで遅延が発生した場合、間違い無く悪いのはPMになるので、
メールや日報などで「証跡を必ず残して」定時で毎日上がってください。
文句を言われたらクレーム対応をして問題ないです。
※理の有無の問題で、人間関係や働いている職場に対する思い入れなどは各々考慮してください。
また、見積もりを行う際に気をつける点として、エンジニアは「実装する機能」に対して「最小限」の見積もりを行うと言う癖を持つ人が非常に多いです。
見積もりの中に、

• バグが発生すること
• 例外処理
• リスクや問題・残課題の有無
• 問い合わせなどの差し込みの有無

など将来起こりうる事象を念頭に置いて、必要な時間を必ず確保してください。
誠実なPMに対しては誠実に対応して、含まれている工数や認識合わせをしっかり行ってください。
ただ、不誠実なPMも世の中には沢山おりますので、状況によっては自衛のために上手く腹芸をする必要もあるでしょう。

人員が足りていない

エンジニアの立場から人員を追加するという策は取ることが難しいので、対処の方向性を羅列します。

• 自動化等、コストをかけなくてよい箇所を徹底的に省略する
• スケジュール・作業内容からどのくらいの人日が足りていないか、直属の上司に相談する
• スケジュールを無視して定時退社する

区分けするとするなら、自己研鑽による自分の時間の死守、真っ当な解決手段、放棄となります。
ただ、「スケジューリングがなっていない」と近しいこの問題は、自己研鑽による解決手段を取ることで、更にタスクが増えていくという連鎖問題を起こす可能性があります。
この点においては、身の回りにいる人間の考え方や環境を整理し、人生のロードマップを踏まえた上で対処していくと良いです。
無茶な自己研鑽を要求され続けるようであれば、ある一定のラインで放棄スタンスに切り替えて、転職活動につなげていくことで、より良い職場選択ができるようになる可能性も十分に見込めます。

直属の上司に相談するアクションで期待できる内容としては、

• 納期の変化
• 仕様の調整
• 金額の調整
• 段階的なリリース
• 外注

等が、本来あるでしょう。
上記の通り、「人員が足りていない＝エンジニアが残業で頑張る」という図式は、マネジメント能力の不足でしかないので、エンジニア自身としてはあまり無理をしないようにしてください。

人間関係が悪くてチームワークが発揮できない

エンジニアの立場の場合、PM、PL、メンバーの誰と誰が悪いかで状況が変わってきます。

PM、PLと悪い場合

この時は割と打てる手が少ないです。
大別するパターンとしては

• より強い力の援助を受ける
• 単身でやりくりする
• 逃げる

となります。
より強い力の援助というと対PLの場合PMに相談する、PMと悪い場合人事や経営陣等といった人事権を持つところと相談する、という方向になります。この時、行き着く先としてはどちらか又は双方に指導が入る、異動する、体制の変更、何もしないのパターンにわかれます。会社の過去の事例や体質を踏まえて、自分の目的に沿う形になるか予測を立ててから動くと良いと思います。
単身でやりくりする場合は、割と賭け事の領域になりますが、やや不利になることを念頭においておきましょう。
自分主体でできる人間関係の再構築であったり、技術レベルの向上による不足部分のカバー等のやり方が存在します。どう転んでも自分自身の教訓には繋がるので、経験を積むという観点では努力の価値があるかもしれませんが、努力しても相手とのかみ合わせの問題でもあるので、徒労に終わる可能性があることを理解した上で頑張る必要があります。
逃げる場合は、PJや会社から逃げるという手段になります。安易な退職はオススメしかねますが、こういった人間関係は精神面にもよく響くので、もう無理となる手前あたりで逃げるようにすると精神疾患等のリスクを下げることができると思います。その数手手前あたりからはPJ異動や転職活動の手を打って置くと、後があることによって精神的な追い詰めを受ける事は少なくなると思います。
この業界は経験を積んだ上で転職をすると給与が上がることがよくあります。本当に辛い時は逃げるという選択肢を選んでください。

メンバーと悪い場合

こちらの対処パターンもPM、PLと悪い場合と同じですが、それぞれの影響範囲が変わってきます。

身近なPM、PLに相談することもできますし、単身でも作業間の切り分け等で接触を避けたり、そもそもお互いに対する影響の大きさも大きくはなりにくい可能性が高いです。
業務に支障をきたすような問題でなければ無視しても良いでしょうし、もし問題解決が不可能かつ許容できない問題になった際に逃走の手段をとることができるでしょう。
チームワークがよければプルリクの対応が早い、設計のアドバイスに繋がる等ということがあります。が、逆にうまく行かない場合はこちらに差し障りがあるといっても、スキルレベルの向上で賄えるので、政治手腕を鍛えるよりも技術的な手腕を鍛えて解決をはかるほうが健全かと思います。

参考文献

• 先制型プロジェクトマネジメント
• 良い戦略、悪い戦略

おまけ

私の働いている会社や私自身に興味があって一緒に働きたい、お茶を飲みながらお話ししたい、
と言う方がいらっしゃれば、ご連絡お待ちしております。

次回更新予定

• PMがオーバーワークで機能不全になっている（解説）