【コラム|プロセス改善】開発プロセスは作って終わりではない

こんにちは。立て続けに投稿します。子供を寝かしつけたあとに思いつきで、開発プロセスのコンサルタントをしていたときのネタをツラツラっと書きました。かなり書き溜めたかなぁと思いますが、これから小出しに（？）していきたいと思います。

「そのネタは、またの機会に」というフレーズが随所に見受けられますが、そのうちに書きます。もちろん、リクエストいただければそれを先に書いていきますので、ぜひリクエストを（＾＾
# またの機会に。。。といって忘れることも・・・もちろんあるので、「あれはどうした？」とコメントやメールいただけると幸いです（＾＾；

前回に 【コラム|プロセス改善】オープンな開発プロセスのススメ と題して開発プロセスについて触れましたが、開発プロセスは作ったら終わりではありません。むしろ、作成した後が重要になります。「開発プロセスの成果物（一般的には開発プロセス文書ですね）があります。あとは見てください。カスタマイズして使ってください」では誰も使ってくれません。使ってくれたとしても本来の意図と異なる使用をしてしまい、かえって生産性を阻害する危険性もあります。

では開発プロセスを作成した後、やらなければいけないこと・・・それは、おおざっぱに挙げると、周知・教育・人柱です。

多くの関係者に存在、意義、有用性を周知することは非常に重要になります。「え？うちのそんな標準の開発プロセスってあったの？」、「あれ？いつの間にか様変わりしてる」 なんて会話は結構耳にしますよね？
# 周知するためのテクニックもあります。それはまたの機会に。

教育はより重要になってきます。また、関係者全員にたいして同じ教育をするのはさほど意味をなしません。役割に応じて教育をプランし、実施していく計画が必要になります。

人柱・・・は受け狙いで書きましたが、パイロットプロジェクトでの適用により、実用性を検証する、改善点をフィードバックすることで、より現場で使える開発プロセスに成熟していきます。しかしながら、ただ単に「おたく、パイロットに名乗り上げてよ」とか、「パイロットに決定したからよろしく」と言われたらあまり気持ちのいいものではありません。

これもまた、その意義、価値、そして自分たちが開発プロセスをよりよいものにしていくという意欲を掻き立てる動機と支援が重要になってきます。
# そんな動機と支援についてもまだの機会に。

開発プロセスは、作成して終わりではなく、始まりであるともいえるのではないでしょうか。そして、常に改訂していく、その過程をオープンなものとすることが重要になってきます（← 前回の話 ですね）。むしろ、プロセス改善の計画の段階から考慮するのがベストになります。IDEAL モデルなどを調べると参考になると思います。

ながさわ

Comments

• Anonymous
  September 21, 2007
  結局、今週はプロセス改善に関するコラムだけで終わってしまいました。 前回、 【コラム|プロセス改善】開発プロセスの基本要素 で問いかけて終りにしていますが、今回はその回答です。 基本要素である、 役割

• Anonymous
  December 12, 2007
  PingBack from http://blogs.msdn.com/tomohn/pages/MSDNOFF2007.aspx