上流工程の問題解決 仕様変更編【後編】

システム構築の現場では，ユーザーと開発者による何回もの打ち合わせを経てシステムを実装しているはず。しかしながら，設計書の段階では目に見えなかったシステムが，工程が進むにつれて形になってくると，ユーザー側で「これは言っていた仕様と違うのでは？」という認識のギャップがよく発生する。 設計書は膨大な量になることが多い。開発者は仕様を凍結する際に，仕様全体を説明しなければならないが，「残された時間が少ないときなどは，設計書をすみずみまで説明するのは難しい。ユーザーにとって業務上インパクトの大きい部分だけを説明することがどうしてもある」（あるベンダーの開発者）。しかも，仕様凍結時に説明していない部分は，それまでの話し合いで合意しているから大丈夫だろうと考える。こうして開発工程が進んでいくと，「言った，言わない」というトラブルが発生しやすい。 小刻みにレビューを受ける こうした問題を完全に防ぐのは難し

[PSV]

「開発費の数％を，リスク分として別に予算化おいてもらう」「その予算をお互いに“見える化”しておく。仕様変更の会議のたびに，予備の予算の減り具合がお互いに分かるので，腹の探り合いにならない。結果としてプ

[chieko3]

［仕事］［要件定義］

[h_sabakan]

後日,じっくりと読む.