【コラム|プロセス改善】オープンな開発プロセスのススメ

こんにちは。本日はRemix 07 でしたが、皆様ご参加いただけましたでしょうか？ Silverlight 関連の熱ーい話題もあったようでさぞかし盛り上がったことでしょう・・・。そうです、私は参加してませんでした。というか、参加するつもりでワクワクしていたのですが・・・締切に追われ、参加することができませんでした orz

ところで、会社や部門によっては標準の開発プロセスを規定しているところももちろん多くあります。また、それと同じかそれ以上に、開発プロセスを規定していない、プロジェクトの裁量に任せているなどという会社や部門も多くあります。

標準の開発プロセスの是非については、今回はフォーカスは充てるつもりはありませんが、プロジェクトの形態の多様化、そして技術やビジネスの進化から、標準プロセスが現状にそぐわないものになってきてしまう危険性を誰しも感じるのではないでしょうか。「その開発プロセスって時代遅れじゃない？」、「え？それはメインフレーム時代の・・・」などなど。

開発プロセスは、理想を言えば標準化されるべきです。ただし、それだけでは不十分で、プロジェクトやその契約形態、技術形態に応じてカスタマイズ（テーラリングという言葉の方が私は好きですが）することを前提とすべきです。

要するに、会社や部門で標準として順守すべきところと、個別に最適化するところが明確になっている必要があるといえます。

そこで重要になってくるのが、開発プロセスのオープン性です。オープン性といっても開発プロセスのドキュメントをどこかの社内 Web サイトやファイリングで共有し閲覧可能にしましょうよ・・・という話ではありません。開発プロセスが公開されているのは至極当たり前の話です（もちろん、適切なアクセス権限は必要です）。

そうではなく、標準の開発プロセスの 『今』 をオープンにすべきというのが今回のテーマです。開発プロセスで、改訂しようとしているのはどういったことなのか、その背景にはどういったものがあるのか、それにより自分たちのプロジェクトにどのような影響があるのか、、、といったことは興味が尽きないはずです。逆にそういったことがガラス張りでないと、安心して開発プロセスを適用することができないですよね。いつ変わるかわからない、どう変わるかわからない、どういう方針なのかわからないでは。

また、プロジェクトでのプラクティスを標準の開発プロセスに盛り込むことも重要です。同様に現存している標準の開発プロセスの課題や不具合を指摘し、改訂を依頼することも重要です。そうした開発プロセスの変更に関する一連のプロセスを公開し、適切にアクセスできるようにすること・・・それもオープン化です。

# 余談ですが、「プロセスの変更管理」については、以前に別のブログに書いたことがあります（＾＾） ご興味のある方は探してみてください。そのうち、こちらにもそういったことも書きたいと思います。

特定の標準化グループ（プロセス改善チーム（PI Team）、SEPG）だけが決めているという開発プロセスではなく、利害関係者全員が作り上げていく、そういった開発プロセスが今、求められていると感じます。

ながさわ

Comments

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

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

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