仕様凍結は顧客のために、こう伝えよう

on

プロジェクトをやっていると必ず出てくるお化けの一つが仕様変更ですね。夏に限らないので日本のお化けではなく西洋のお化けでしょうか。そんなお化けの仕様変更はいきなり「仕様変更デース！」と飛び出させないためにも、その前にどれだけ仕様を検討してきたか、お仕様凍結のタイミングを広報してきたか、そして変更管理をゆるゆるでも「ちゃんと手続きやるからね！」という雰囲気を顧客に刷り込んでおくことが大事かと。


そうしたプロセスも大事なのですが、その前に何時までだったら普通に仕様を検討できるか、いつに仕様を凍結するんだという、お化けを封じ込めるお札を貼りまくらないといけないと思うのです。


仕様変更を受け付けられるマイルストーンは何度も言おう
信心は大事です。それば自分のプロジェクトで、プロジェクト推進方針の一つならとても大切です。であれば、それを理解してもらえるように何度も伝えるのがそれを大切だと思っている側の仕事です。


以前担当していたパッケージはソフトウェアを導入後に構成をするのですが、その構成をするときに設定するデータモデルはそこで構成をしてしまうとほとんど融通の利かない娘だったので要件定義から基本設計の半ばのタイミングでデータモデルをフィックスさせないとあとあとの作業に波及してしまうので、そうしたタイミングでデータモデルはそこで実質仕様凍結になるのでした。


もちろん、データモデルを仕様凍結するということは供連れでデータの処理ロジックやらデータのライフサイクルやらまでフィックスさせないと意味がないわけです。なので上流工程はちょー忙しいのですけど、そうした忙しいの中にデータモデルをフィックスさせるという大きなタスクがあるわけです。


それをしないとどうなるかは、プロジェクトマネージャもSEリーダもよくわかっています。フィックスさせないと後工程の時間がジワジワと亡くなって無くなってしまうので優柔不断なふるまいは自分たちのチームの首を自分たちの上流設計を担当した自分とSEリーダで絞めてしまうことになるんですね。だから、「それはやらない、ダメ。絶対！」と思うんですね。で、進捗会議や個別検討の場で何度も刷り込みをします。

「業務フローは今月末までに確定してください。」
「データのライフサイクル表は来週でほぼ確定版とします。」
「データモデルも今月末でフィックスします。」
「このパッケージは一旦構成をしてしまうとデータモデルの変更が出来ません。」
「提案書に記載のとおり、再構成の費用は積んでいませんから御見積もりになります。」


言い難いことのように思えるかもしれませんが、こっちのあとあとの都合もあるのですから言わないといけないです。それに毎回言っていれば、そのうち慣れますから。お互いに「そういうものだ。」と思えるようになったら狙い通りですね。


ところでそのパッケージは構成後「全く何もできないの？」と聞かれればちょっとしたことならできます。それ、つまりフィックスしてもできることはきちんと伝えます。これも大事なことです。ただ、そのちょっとしたこともチリツモで後工程に影響が出るならキャップを掛けておかなければなりませんが、それでもやっぱりハッキリと伝えておきましょう。

  • 仕様凍結は、それを超えるとプロジェクトの納期に影響が出てしまうタイミングの少し前、少なくとも1か月~〜2週間前を目安に公式にアナウンスしましょう。
  • SIerのチームは専門家集団として顧客が望む要件を期日までに実現するように推進しなければならないし、そう進められるように顧客に助言をしなければなりません。


つまり、決して顧客にとって良い人になってはいけない、ということです。