根拠の無い期限を先に決めてしまうのは止めましょう
締め切りを延ばせないのは本当なのでしょうか
システムエンジニアの仕事をしていると、大抵の方が、プロジェクトが遅延して炎上しているにも関わらず、「どんな状況においても、期限は延長する事ができない。がんばって終わらせよう。」みたいな状況に出くわすことがあると思います。私も会社員時代は、プロジェクトマネージャの立場で「未解決課題が山積みでも期限を伸ばせない」というセリフを言ってしまった事があります。プロジェクトメンバからすると、いい迷惑だったと思います。そんな地獄に巻き込むなというのが本音でしょう。
ところで、「期限が先に決まっているから伸ばせない」というのはどこまで本当なのでしょうか。大体は以下のような理由に当てはまるのではないでしょうか。
・自分の保身が大事：顧客や上司が期限を先に決めてしまっており、延期の申し出をすると自分が降格のリスクがあるので、調整しようとしない
・企業のイメージを下げたくない：世の中に○月○日に公表してしまっており、延期のお知らせなんかすると自社の信頼感が失われる
・延長した費用を捻出できない：自社の関係部門や同じプロジェクトに参画している他社も期間延長に巻き込んでしまい、延長期間分の人件費用を捻出できない。もしくは追加費用の請求が面倒である
・そもそも期間の見積ができない：大きいプロジェクトにはありがちですが、プロジェクトの全容が見えないので、全体を見通した作業項目の洗い出し、順序の組み立て、作業ボリュームを洗い出す事ができるスキルを持った人がプロジェクトに参画していないので、延長したあるべき期間が誰にもわからない
上記のことは大抵がプロジェクトマネージャの責任範疇で、自社や顧客へ説得できないとか、高スキルな人材を確保できないとかを、プロジェクトマネージャの力不足で片付けられてしまいがちです。
でも、ちょっと待ってください。プロジェクトマネージャって、何でも難題を解決できるようなスーパーマンみたいな人ばかりではないですよ？決められた期限でリリースできるといった確証が得られないのに、新サービスを告知してしまう顧客側にも問題があったりしませんか？
『そもそも期間の見積ができない』というのも、作業の洗い出しや見積検討を人任せにしているようなことはありませんか？私も２０代の頃は無茶な仕事をさせられながら文句ばっかり言ってましたが、そもそも自分で期間の交渉をしておらず、先輩や上司任せにしていたような気がしており、反省するところがいくつもあります。
他人が決めたスケジュールに対して、自分が納得して仕事をするというプロセスを省略したがために、無意識に精神衛生を阻害するような不幸な仕事の仕方をしていたのでしょう。
予期せぬトラブルで期限の延長の依頼とお詫び行脚へ
最近耳にしたWEBプロジェクトで機種依存によるトラブルがあり、『○月○日に修正版アプリをリリースします。』と数十顧客に対してアナウンスしたのですが、開発ベンダーの改修作業が予定通り進捗せず、予定通りの期日でリリースができなくなりました。そこで依頼元は『１週間延期してリリースします。申し訳ございません』といった内容をまた数十顧客に対して再アナウンスしました。
しかし、その『１週間』とやらは問題となっている事象に対して、調査⇒技術検証⇒設計修正⇒アプリ改修⇒テスト実施⇒受入といった大まかな作業の流れに対して、どれくらい期間と人が必要なのかを計算してはじき出した数字ではないのです。単に依頼元が早くリリースしたいから１週間あれば何とかできるだろうという根拠のない見込みなのです。本来は調査と技術検証を行い、改修方針が見えてから開発と試験の見積もりをバッファを考慮してリリース時期を決定するべきなのです。調査と技術検証の見積は、調査方針をいくつか出し、実機確認する環境が整えられれば、どれくらい期間が要するかは算出できやすくなります。ここでは仮説と検証を繰り返し行うフェーズなので確認ポイントを設定して、状況確認ができるフェーズを設けられれば、停滞することはないと思います。焦る気持ちは分かりますが、『この修正で直せる』という勝ち目が見えてからアナウンスするということを実施してほしいというのが重要なところです。
昔の基幹系開発プロジェクトでは数ヶ月毎の定期リリースというのが決まっており、そのなかでどのような案件をリリース対象とするのかという仕事を経験したことがあります。これも期間だけが決定しており、その中で人員規模と期間に収まる案件の仕事をチョイスするというスタイルです。仕事がいくらでもあるような環境であれば、システムインテグレータ企業にとっては人員の調整がしやすく、美味しい案件なのかもしれません。一昔前では通用するスピード感かもしれませんが、２週間で終わるような案件も数ヶ月先まで眠らせることとなるのは、顧客の機会損失となっているかもしれません。じっくり腰をすえてウォータフォールで進める案件とフットワーク軽くトライ＆エラーを繰り返すアジャイルで進める案件も
一緒くたに定期リリースという縛りを設けるのは、非効率だなと感じておりました。
予定通り進められなくなったら計画を見直すだけです
仕事は予期していないトラブルに見舞われるものです。エンジニアの仕事では予定通り進められるような仕事はほとんどないかもしれません。そこを見越して休日や平日の時間外以外のバッファを設けてスケジュールを引けるかがポイントです。顧客が早くしたいからといって、キチキチのスケジュールを作成し、予定通り進められなければ、残業や休日出勤してリカバリしますというスタンスは今後誰もついてこれなくなるでしょう。残業や休日出勤なんて、仕事が大好きな人だけ勝手にやってくださいというスタンスでいいと思います。無理して作ったシステムなんて大概ボロボロで品質が悪く、結局不具合が解消しきるまで、数ヶ月かかるなんてよく聞く話です。
遅延が発生したら、人員増加をしてリカバリするという方法が今のプロジェクトでも良く取られる方法ですが、うまくいったプロジェクトを聞いた事がありません。結局はリリース判定でＮＧとなり、期間延長や機能制限してリリースするという結果にしかなりません。
予定どおりできないとわかった時点で、仕事の範囲はそのままで期限を延ばす調整をするのか、期限をそのままで仕事を減らすかのどちらかしかありません。人を追加で投入するとしても、その人が仕事ができるまでの教育コストがかかるため、教えている間は今までの人が仕事できる時間を確保できないため、さらに期限が伸びてしまう結果になりますね。
期限が延びても最小限の調整ごとで済むようにしていきたいですね。