開発プロセス

「開発プロセスってよく分からん」という、ある開発会社社長へ。

開発プロセスとは何か？というと、簡単に言えば下のはてなの解説にある通りでしょう。
http://search.hatena.ne.jp/search?ie=utf8&word=%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9

要は開発の進め方にまつわる色々なものについての考え方のことを「開発プロセス」と呼びます。
おそらく開発プロセスはどの会社にもあります。XPなどのアジャイルやRUP、ウォーターフォールだけが開発プロセスではないはずです。ただそれ以外の多くの場合、以下の3点が問題となっているのではないでしょうか。

1. 明示されているかどうか
2. チームで合意されているかどうか
3. 本当に開発に適しているかどうか

明示されていなければ合意できないとは思いませんが、明示されていた方が合意や対案を出しやすいはずです。チームでの合意は暗黙的でも構わないと思いますが、継続するためには変更を許容した上で、明示的に合意を示した方がやりやすいように思えます。

「本当に開発に適しているかどうか」というのは、開発プロセスの有効性を検証することではありません。自分たちの開発に適するように自分たちの計画や手法を見直すことができるかどうかです。「こうあるべき」という理想より、上手く仕事が進む方法を探せるか、ということが重要な場合が多いはずです。

また、今のところ(おそらく今後も)、万能の道具なんてないので、開発に適した言語や開発環境を選び、カスタマイズしていくように、開発プロセスも選択、カスタマイズする必要があると僕は考えています。ある開発プロセスを導入したとしたら、それは時間とともに能動的・受動的に変化していくはずです。

開発プロセスも変化すると考えると、開発プロセスとメンバーとの関わりも変化していくように思えます。トップダウン的に導入した場合、最初は契約だったり開発規約という形でメンバーと関わります。しかし、次第にチームの文化や各人の習慣になるはずです。例えばソースコードのチェックイン・チェックアウトや、毎朝のミーティング、テストの方法や、成果物の配布方法などなど。

あるいは、メンバーが持ち込んだ習慣や手法が明文化され、チームの文化や開発規約などに反映されていくボトムアップ・アプローチの方が僕は好きですが、メンバーによってはすぐに良い改善案を出せないこともあるでしょう。

どちらのアプローチにせよ「開発プロセスを導入する」と言った場合、IDEのように単に使えば良いものではないので、開発の手法、流れを最適化するように常に意識する、ということがポイントになると思います。

と言うわけで、どんな点を意識するべきかを示してくれた本「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」をお勧めいたします。

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

われわれが何であるかは、われわれが繰り返し何を行ったによって決まるのである。それゆえ、美徳は行いではく、習慣なのである。

この冒頭(p.1)のアリストテレスの言葉が印象的。どのような習慣がソフトウェア開発をより効率的でハッピーなものにしてくれるのか、それを考えるチャンスをくれる本だと思います。