複業フリーランスのhillpointです。
SES・客先常駐の仕事していると、デスマーチの気配を察知します。
例えば
・入ったそばから、納期まで時間が無い。
（すでにデスマーチ）
・なにも決まっていない。
（デスマーチの予感）
・ろくな人がいない。
（デスマーチの気配）
こんなの、本来は、プロジェクトマネージャーがどうにかする問題でありますが、プロジェクトマネージャーは、お客や上からの圧力など、様々なプレッシャーにより、どうにもできない、どうにかしたいが時間もない、時間も無いから見て見ぬフリ、といった状況におちいっていることが多々あります。
私、元プロジェクトマネージャーで、デスマーチ案件を生み出したこと、あります。
生み出したことがあるから解る。
SES・客先常駐で、デスマーチの気配を感じた時の対応策、お教えします。
きっと、役に立ちます。
専門用語について
アイコンがついている専門用語は、「知らないと恥ずかしいITエンジニアの用語集」ページに説明を記載しているので、専門用語の意味が解らない場合、リンクをタップして、説明を参照してください。
デスマーチの気配、プロジェクトマネージャーはどう思っているか？
プロジェクトマネージャーだったら、解っているんです。
ああ。これはヤバイ。と。
でも、どうにもできない。
あらゆる対応におわれ、どうにかしたいけど、手もでない。
そんな風に、デスマーチ案件は成長していきます。
また、デスマーチ覚悟でやってることも多々あります。
お客の無茶を解決するために、多額を貰っているということです。
まっとうな規模、工期、体制であれば、忙しくなる時期ぐらいはあっても、デスマーチの気配は漂いません。
プロジェクトマネージャーから見れば、デスマーチ化は必然であることも多いんです。
SES・客先常駐だからできるデスマーチへの対応策
対応を拒否する
正確に言うと、「客観的なデータに基づき、プロジェクトの破綻を伝え、できると判断できる対策が打たれない場合、対応を拒否する。」です。
SES・客先常駐組だから、言えるんです。
まず、プロジェクト管理系は、お客との体裁、コスト、無茶すればいけるみたいな謎の自信により、客観的に判断できていません。
もし、客観的に判断できていれば、デスマーチの気配はありません。
社員やそのプロジェクトの経験が長い人、繋がりが深い人は、仕事が無くなってしまう危険性があるので、強く言えません。
なので、SES・客先常駐組だからこそ、言えるわけです。
そんな物言いしたら、首を切られる・所属会社から怒られる・変な人と思われる？と思うかもしれません。
逆ですね。
この物言いで、プロジェクトがデスマーチを回避出来たなら、とても重要な物言いになります。
つらかったのは、物言いした時だけとなります。
プロジェクトマネージャーやプロジェクト管理系は感謝するでしょう。
そして、あなた方を優秀なメンバーと認識するでしょう。
私、元プロジェクトマネージャーです。
勇気を出して、言ってくれたなら、「そこまで心配をかけていたか。すまなかった。プロジェクトの立て直しに尽力する。」と正直に頭を下げるでしょう。
もし、この物言いをプロジェクトが受け入れなかったら、所属会社には、怒られるかもしれませんが、他の案件へ移動しましょう。
幸いながら、SES・客先常駐の案件は、いくらでもあります。
所属会社から、デスマーチ覚悟で対応を継続しろと言われたら、所属会社を変えましょう。
幸いながら、SES・客先常駐の会社の求人は、いくらでもあります。
対応案件が、プロジェクト崩れ状態で、客観的データも示し、対策を要求しても、取り合ってくれず、所属会社までもが、デスマーチに付き合えと言うなら、転職しましょう。ね。
ただ、SES・客先常駐組が「このままだとヤバイ。」とだけ言っても、誰も取り合ってくれません。
客観的データが重要です。
今時のプロジェクトであれば、品質管理データは採取されているでしょう。
要求仕様に基づく、開発ボリューム量、生産性、バグ密度等。
小さなプロジェクトであれば、採取されていない場合もあるでしょう。
簡単にこんなデータを採取しましょう。
・仕様書のページ数
・仕様書のレビュー指摘数
・プログラムのステップ数
・試験項目数
・プログラムのバグ密度
これらのデータで、簡単に計算して、スケジュールの適合を見せれば良いです。
デスマーチの気配漂うなら、もう破綻しているでしょう。
そのぐらい、経験あるITエンジニアなら、直観的にわかります。
それがデスマーチの気配を感じることですから。
それをデータとして示すわけです。
客観的に淡々とデータで説明し、対応策があるなら、提案してあげましょう。
なお、体制を増強する＝人を追加するという対応策は、注意が必要です。
炎上してからの人員増加は、逆効果ですし、コストも発生します。
素直に、リスケもしくはリリースの分割。
対策は、伸ばす、もしくは、分割する。です。
リスケと言うと、嫌がられるので、フェーズを分けるが現実的で、なんかちょっとかっこいいです。（笑）
対応範囲を制限する
「客観的なデータに基づき、プロジェクトの破綻を伝え、できると判断できる対策が打たれない場合、対応を拒否する。」は、それなりに経験のあるエンジニアでないと、客観的なデータに基づき、プロジェクトの破綻を証明するのが難しいことであります。
ちょっと、できそうにない、データとして証明できそうにないという場合は、「対応範囲を制限する」です。
SES・客先常駐だからと言っても、なんでもかんでも、言う通りにやるというものではありません。
SES契約（システムエンジニアリング契約）は、法律上は、業務請負の一種です。
ゆえに、発注元は、労務管理や指揮命令をしてはいけない等、細かく規則があります。
対応業務については双方協議の上、決定するのは、当たり前の行為であり、なんでもしてしまうと、労働者派遣となり、偽装請負の疑いとなります。
まぁ、小難しいことはさておき、SES・客先常駐組であっても、対応する業務・機能・フェーズを決めてしまうことは可能です。
発注元からは嫌がられるかもしれませんし、所属会社からも、うるさいことを言うなと怒られるかもしれませんが、別に何も悪いことをしているわけではないので、堂々と対応する業務・機能・フェーズをしっかり決め、自身が対応する部分を淡々と進めましょう。
まわりが炎上してても、おれたちは問題無し！という状況を作り出すわけです。
これも、「あいつらだけ楽しやがって」とか、「あのチームは担当量が少ない」とか、言われると心配するかもしれませんが
プロジェクトマネージャーから見たら、逆です。
プロジェクトマネージャーやプロジェクト管理系は、プロジェクトが炎上している中、自分たちの担当業務を正常に進行させるチームを優秀である、管理能力があると捉えます。
となりのチームのバカメンバーだけが、嫉妬しているだけで、ほとんどの人が、「あいつらやるな。」「できるな。」と思っています。
順調に自分の担当業務を進めていると、プロジェクトマネージャーやプロジェクト管理系から炎上しているチームの応援要請が来るでしょう。
余裕があるなら、手伝ってあげるのも良いですが、契約上、手伝う義務はありません。
自分たちの担当業務がまだ終わっていないという理由で断ってしまいましょう。
もし、余裕があり、より成果を上げるなら、手伝うのではなく、機能を奪いに行きましょう。
機能ごと奪う場合、お手伝いといいつつも、担当部を決めて、分割してしまいましょう。
どんな単位でも良いですが、ある部分を取り上げてしまうわけです。
1部で充分です。
余力を持って、機能全体を把握しましょう。
1部分を担当して、機能全体を把握し、機能を担当できるレベルになっておきます。
その後、プロジェクトが収束する場合、SES/客先常駐は、契約終了を迎えていきますが、保守や次フェーズ対応等で、残る人・チームが選択されます。
炎上したチームの評価は低く、手伝ってあげたチームの評価は高いでしょう。
自身のチームのメンバーをより多く残すために、この時、手伝った機能も担当できるというアピールを行い、機能を奪いとれるわけです。
実はデスマーチ案件こそ、ビジネスチャンス
管理職・経営者は、「デスマーチ案件こそ、ビジネスチャンス」と思っています。
あわよくば、炎上してくれと思っています。
これ、本当です。
SES/客先常駐は、どれだけ人を入れれるか？が勝負です。
多ければ多いほど、いいわけです。
炎上すれば、するほど、人を入れれます。
しかし、現場で働くITエンジニアにとっては、デスマーチ案件には関わりたくないですし、炎上してしまうと、体力面だけでなくメンタル面も削られてしまいます。
なので、この「デスマーチ案件こそ、ビジネスチャンス」は、見透かして、毅然なら態度で、無理なもんは無理って言いましょう。
それで、首って言うなら、転職しましょう！
幸いながら、いっぱいありますから。