こんにちは。近藤です。
現在、3つのPJを同時進行で進めているのですが、そのうちの1つが本稼働を迎え一区切りつきました。
結果として稼働が1年2ヶ月ほど遅れた炎上PJだったのですが、今月何とか稼働を迎え一区切りつけることができました。
本PJ は自身としては貴重な経験でしたので、備忘としてまとめます。
＜引き継ぎ＞
このPJは元々別の会社が進めていた案件だったのですが、その会社が途中で撤退してしまったため体制の刷新として私がPM、開発者2名という体制で引き継いだ案件です。
（その中には実は当初メンバーは誰一人いませんし、急な撤退でもあったので引き継ぎもありません。）
メンバー刷新の報告とご挨拶でお客様の事務所に伺った時の空気は非常に重く、既に稼働が半年延びている状態でした。
そういうこともあり、「本当に大丈夫か」という空気がすごく重く、正直なところ逃げ出したい感じでした。（笑）
とはいえ、「任せてください」と言った手前、自分が何とかするしかない状況でした。
まずはお客様に今の状況を正直にお伝えし、信頼関係を築くことを心がけました。
（怒られることを覚悟していましたが、お客様は黙って聞いてくださっていました）
＜開発方針決め＞
まず、どこまで出来ていて何が出来ていないのかを確認する必要がありました。
確認してみると、課題管理表にはお客様テストの指摘内容が残課題として纏められて残されていました。
当初メンバーに確認すると、残課題がクリアになるとPJは完了となるということなので、それを信じて開発計画を立てました。（実はこの判断は誤りだったことが後に判明します）
＜開発着手＞
計画に従い順次課題をクリアして行きましたが、日々新たな課題が出てくるような状況でした。
さらに、運用を十分に考慮した設計になっておらず至るところでハードコーディングをしており、マスタの設定値を変更すると、プログラムをそれに合わせて修正しないと正しく動かない状態になっていることも判明します。
想定していたよりも遥かに状況が悪いということが、案件を引き継いで数ヶ月後に判明しました。
＜方針転換＞
このような状況では、そのまま進めても失敗することが目に見えています。
したがって、工数はかかりますが要件定義をやり直す必要があると判断しました。
とはいえ、稼働最優先という方針もあり、一からやり直すのは現実的ではないので、現状の実装内容と（経験上の）あるべき姿との乖離点を中心に疑問点・問題点を洗い出し、一つ一つお客様に確認することにしました。
この頃はお客様も我々に頼るしかないこともあり、何とか協力して頂くことが出来ました。
＜開発再開＞
改めて要件を確認して課題を明確にしたことで、本稼働までに本当にやらないといけないことが明確になりました。
あとは計画して実行するだけです。
ただし、計画通りに進めるには、前提が崩れるような追加要求が出てこないようにすることが重要です。
したがってお客様には、仕様確定と変更の凍結をお願いし了承を頂きました。
開発側は少し余裕を持たせたスケジュールを組み、これ以上スケジュールが後ろにスライドしないように計画しました。（ただし余裕分は各タスクに載せるのではなく、工程全体のバッファとして計画）
計画立案／実行時にはBrabioという進捗管理ツールを使いお客様を含めたPJ関係者に公開し、リアルタイムでの状況把握ができるようにしました。
週次できちんと状況を共有し、何事も正直に話をするようにしました。ここまでくるとお客様との信頼関係も構築され、同じベクトルを向いてPJを推進していく良い協力体制が築けていました。
＜受入テスト＞
スケジュールに余裕を持たせていたこともあり、想定外の事態もバッファ内で吸収でき予定通り開発を完了しました。
受入テストでも課題は出ましたが、稼働最優先で課題の優先順位をつけながら対応を進めました。
受入テストの課題についても細かく開発メンバーと対応工数を打ち合わせし、スケジュールを順守するように進めました。
受入テストフェーズでは本稼働直前には開発メンバーにはかなり無理をしてもらった部分もあります。
築いた信頼関係を崩すことは最悪の結果につながるので、スケジュール優先で開発メンバーには頑張ってもらいました。（その分私自身も、休みなしでPJ管理や開発支援、顧客対応などを行っていました）
＜本稼働＞
結果として、優先後は低いものは稼働後対応となるものも残りましたが、修正計画の予定通りに本稼働を迎え、今に至っています。
稼働後は、不具合もなく稼働しているということで、一安心しています。
いろいろ書きましたが、私自身が本PJを推進する立場としてうまくいった点と反省点をまとめると、
＜うまくいった点＞
・都合の悪いことも隠さずに正直に情報を共有するように心がけた。
→ 結果、信頼関係を築くことにつながり、良い協力関係を構築できた。
（ただし伝え方は要注意。相手側の立場も考慮して受け入れられるような伝え方を考慮。）
・スケジュールは順守する。（そもそも無理な計画は立てない）
→ 無理な計画を立てても疲弊するだけ。余裕のある計画の方が顧客も安心する。
工数は開発者と相談して。（PMやPLだけでは決めない！）
・しかるべきタイミングで仕様確定・変更の凍結を行い、顧客にも守ってもらう
→ これが出来ていないPJは結構多いと思う。正式な文書としてきちんと残す。（メモではだめ）
・設計の際は、実際に運用で使用されているところをイメージして設計することが大事。
→ 運用をイメージできていない設計は、使い勝手などの面でテスト時に不満が出ることが多い。
お客様に必ず運用の仕方を聞いて理解を深めておくこと（例外的な運用も想定可能な範囲で聞いておく）
＜反省点＞
・現状の把握は多角的に。
→ 一方の立場にのみ立って状況分析しないこと。
同じPJのメンバーでも発注側と受託側では当たり前だが立場や役割が違う。
今回のPJでは、引き継ぎ時に対応残の確認を受託側のメンバーの情報だけで判断してしまい、
後から大きな方針転換を余儀なくされた。（その分工数も余分にかかった）
入会申込
ログイン
