オープンソースにおける開発方法

まとめ

では、本連載の内容をまとめます。

システムを体系的に構築するために、構造化技法、オブジェクト指向、といったような開発方法論が広まりました。これら開発方法論に従って開発を進めることにより、システム開発は、それまでの職人技の世界からエンジニアリングの世界へと一歩近づきました。開発方法論とは、開発者が従うものであり、そういう意味では、開発者が主役と言えます。

システムが大規模化するにつれて、開発方法論があってもシステム構築を進めていくのが困難になってきます。そこで、システム開発をどのように進めるか、という観点である開発プロセスの必要性が高まってきました。開発プロセスは開発の進め方がポイントになるので、プロジェクトの管理者が主役と言ってよいでしょう。

初期の（重量級の）開発プロセスでは、システム開発を管理することに重点を置いていました。重量級の開発プロセスの代表は、ウォーターフォール・モデルであり、その後、いくつかの改良型も生み出されています。システムが多様化すると、それまでの重量級の開発プロセスではうまくいかないケースが多く報告されるようになり、「アジャイル」という考え方が提唱されました。

重量級の開発プロセスとアジャイルな開発プロセスとは、排他的なものではなく、また、どちらが優れているというようなものでもありません。プロジェクトやシステムの特性により、使い分けることが重要です。さらに言うと、それらのエッセンスを抽出し、プロジェクトごとに混ぜこぜにカスタマイズして「いいとこ取り」を実践することが、プロジェクト成功への近道ではないでしょうか。

オープンソースの世界では、早くから「アジャイル」的な考え方がありました。それが、バザール方式です。バザール方式では、ある局面においては、バザール方式以外の一般的な開発方法（伽藍方式）よりも、大きな成果を上げることが可能とも言われます。もちろん、オープンソース開発と（いわゆる）職業開発とを同列に論じることはできませんが、このバザール方式のエッセンスがアジャイルな開発プロセスに見て取れることからもわかる通り、バザール方式のやり方や考え方を、開発プロセスに取り入れようという動きは有効であると考えられます。このことから、オープンソースソフトウエアのメリットは、成果物であるソフトウエアのみではなく、開発プロセスなどにまで波及していると言えるのではないでしょうか。

システム開発の現場では

システム開発の現場では、プロジェクトの成功率が5割とも3割とも言われています。また、皆さんも、開発現場がデスマーチになっている話や開発メンバーが精神的に厳しい立場に置かれている話など、開発現場の暗い話をよく聞くのではないでしょうか。まだまだ工学的にも未熟だと言われるシステム開発の分野ですので、開発現場にいろいろな種類の「シワ寄せ」が来ているのは否定できません。また、プロジェクト関係者（実際に開発を行っている開発者も含みます）のシステム開発に対する理解が浅い、ということが「シワ寄せ」に拍車をかけている場合もあるでしょう。

しかし、この現状を「未熟だから仕方がない」と一言で片づけることはできません。作らなければならないシステムがあれば、プロジェクトは始まり、開発を進めなければなりません。プロジェクトが動き出すと、プロジェクト関係者が一丸となってゴールに向かわなければプロジェクトは成功しません。

プロジェクトを成功に導くためには、現場の開発メンバーが、「開発手法とはどんなものか」「開発プロセスの目的は何か」など、システム開発について理解し、必要であれば、ほかの関係者に理解してもらわなければなりません。プロジェクトが失敗する一因としては、まだまだシステム開発に対する理解が不足している現状があるように思います。

システム開発に対する理解を高めるのは、現状、個々のプロジェクトでの活動が現実的です。このような各プロジェクトにおける地道な動きが、ゆくゆくは、システム開発の成功率を上げ、システム開発現場を楽しくする1つの足がかりになると筆者は信じています。また、本連載が少しでもその役に立つのであれば、本望であります。