作成者:yasunakaちょっと前に工事進行基準の話に触れましたが、正直なところ、実務的なところがまだよくわかっていません。■赤字プロジェクトの予定見積総原価の見直しはいつ行う?■仕様変更による収益の変更管理はどうすべき?などなど、実際にやってみないとよくわからないことだらけです。仕様変更は、あらかじめバッファというか費用のプールを用意しておいて、期間内で発生する仕様変更をそのプールから取り崩して行う場合が多いと思いますが、その場合でも1件1件きちんと収益管理していくことが求められそうです。現場はその都度正確な見積もりを作って計上し、管理していかなければならないので、これだけで大変なことになると思います。要件のベースライン管理も重要になってきます。どこまで要件の範囲か、ということをきっちり詰めなければならないからです。なってくると、要件に対して実現(実装)方法がいくつか考えられるような場合、お客様にとって一番良い解決方法を探る、ということがやりにくくなったように思えます。やりたいこと=要件に対してその実現(実装)方法は1つではありません。それを要件定義段階で事細かに指定しなかった場合には、たとえ多少難がある場合でも要件を満たしてさえいればそれで押し切ってしまう(お客様からみれば押し切られてしまう)ケースが多くなるのではないでしょうか?結局、システム開発においては準委任契約で行える上流工程の比重が増し、単なる開発工程が圧縮される形になるのかもしれません。この形態が一般化すると、開発工程のオフショア化が一層進展する可能性もあるかもしれません。日本国内では準委任契約の工程のみを行い、開発工程はオフショアで行う、といった感じです。今まではオフショア開発で行う場合、いちいち事細かに要件を定義しなければその通りに作ってくれないという部分があったと思いますが、これからは国内でもそうしなければならなくなる、ということになり、国内での開発メリットが低下することが予想されます。一方で、受託業務ではアジャイル開発はかなり難しくなりそうですね。研究開発的な要素の大きい自社のパッケージ開発のような場合でないとアジャイル的な仕事の進め方はできなくなってしまうのではないでしょうか?いずれにせよ、いろいろとインパクトがありそうですね...コメントは受け付けていません。