激甘な見積もりと序盤の進捗管理やったことがないから肌感覚がない刷新メンバーそんなこんなで基幹刷新プロジェクトがキックオフ学んだことトップダウンで始まった基幹刷新プロジェクト東証1部上場の大手で始まった基幹刷新プロジェクトに僕はアサインされた。鶴の一声で始まった案件だったため、現場からの反発がものすごく、「仲良くするには」的な議題が上がることもあったくらい現場はギスギスしていた。20年近くメインフレームのシステムを利用し、情報システム部は脆弱でITゼネコンがあまい汁を吸うという典型的な日本のITの構造になっていた。数年前そんな状況から脱出しようと一度基幹刷新を試みるも失敗してきたという経緯があった。その古傷をえぐり全否定するのだから反発は当然といえば当然なのだが・・・。実績が欲しかったのと、カットオーバー後は継続開発もありドル箱案件になるため、他者の3分の1程度の金額で受注した。これが後々大きなしこりになった。今だから思うが決して赤字でプロジェクトを受けてはいけないし、そもそも値引は良くない。適正な価格で提供しなければ発注サイドも疑心暗鬼になってしまうと思う。激甘な見積もりと序盤の進捗管理そもそも緻密に見積もれないくらいに誰も知らない業務とか埋まっていたりする。プログラムの仕様が間違ってたり、想像だにしない問題が大量に発生するのが基幹刷新なので、工数管理はかなり難しい。いえ、序盤から進捗が悪化した時のリカバリー方針がリスケリスケで問題先送りスタンスだったため、週次MTGの度に負債が積み上がっていくプロジェクトだった。そもそも積み上げられる問題は放置できることが多いのでわざと放置してカットオーバー判定対象から除くことを最初から決めていたのかもしれない。やったことがないから肌感覚がない刷新メンバーテスト工数が圧倒的に短すぎるスケジュールになっていて、エンジニアだったら肌感覚でわかることがPMとかコンサルあがりにはまるでわからないことが多々ありました。開発にかかる時間軸でのコストは開発1:テスト2くらいが妥当なところで、開発の中もざっくり動くレベルが0.2で細かい仕様を実装するのが0.8でパレートの法則に近い。(個人的な見解です)とにかく「テストには開発の倍くらいコストがかかる」というのを覚えておいてもらいたい。バグが発生すれば調査して単体テスト書いて修正してコミットとか作業が多い。テストが楽なコードでなければ調査も大変だし、修正によるデグレが発生するリスクもある。開発500人月のプロジェクトで50人月くらいの内部結合テストは明らかにスケジュールがおかしい!そんなこんなで基幹刷新プロジェクトがキックオフギッスギスしたまま始まったプロジェクト、PM以下はだれも喜んで進めたくないような雰囲気を漂わせながら。学んだことビジョンの共有と目標設定、それをベースにした意思決定の基準について初めに握るか共通の認識を持ち、それを常に意識することが大事だと実感した。いつ終わるか分からないマラソンにはだれも参加しない。はてなブログPro自称フルスタックのフリーエンジニアです。EC・Webメディア・新規事業が得意なので、Webサービスの開発や企画の相談気軽にどうぞ。Webエンジニアのためのテックブログまとめ10倍株(テンバガー)発掘調査ブログフリーランスのエンジニア道リップルXRP投資速報スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。