ソフトウェア開発の仕組み化、って？

雑感

ここからちょっと話が外れていきます。

最近のラグザイアの相馬さんのブログに、タイムリー(?)なネタがありました。

システム開発の標準化について(id:j-souma:20071217)

この両方の意見を再考してみると、ソフトウェアを工業製品と考えるか？芸術作品と考えるか？という結果に行き着くような気がします。

ここでいう「標準化」と「仕組み化」はほぼ同一としてとらえます(じゃないと話がすすまない^^;)。ここには、仕組み化の賛成派と反対派、双方の言い分が書かれています。

おおざっぱに言えば、それぞれの意見は以下のように集約できます(ちょっと極端ですが)。

「仕組み化」に賛成の人は「開発者は往々にして主体的に考えたり動いたりしないものである。よって、動かざるを得ない仕組みを作ることで、安定的に成果が得られるようにしなければならない。」となります。いわば「性悪説」。小山社長風に言えば、「うちの社員はもともと落ちこぼればかりだから、『仕組み化』しないと仕事が回らない」ことになります。

「仕組み化」に反対の人は、「ソフトウェアというものは、高度な技術で組み上げられた作品である。開発者たるもの、主体的に考え、開発に挑むべきである。」となります。いわば「性善説」。「事実、反対派の人たちは主体性が強く、問題認識能力が高い人が多いです。」というのは、そういうところにありそうです。

実際に開発に携わっていると、開発者は後者のタイプばかりではないというのが実感です。むしろ、前者のタイプの比率の方がおおいかと。それじゃ、教育することで前者のタイプの開発者を後者のタイプにできるかというと、すべての人がそうなるのは難しそうです。

個人的には、どちらにつく、というわけでもなく、どちらの意見にも頷ける部分があります。開発者はみんなやる気のある人ばかりではなく、できればみんなが主体的に考え、動けるようになってほしい、というジレンマもあります。なんかいい落としどころはないかな、と考えていると、そうか、これは「対立」だということに気づきました。というわけで、この対立の解消図(TOC思考プロセスの「雲」)を作ってみました(完成度は低いかもしれません^^;)。

            ←「安定的に成果を  ←「ソフトウェア開発
                上げる」            を仕組み化する」
「企業が将来
  的に成長し
  続ける」
            ←「よりよいソフト  ←「ソフトウェア開発
                ウェアをつくる」    を仕組み化しない」

読んでみます。

企業が将来的に成長し続けるためには、安定的に成果を上げなければならない。安定的に成果を上げるためには、ソフトウェア開発を仕組み化しなければならない。なぜなら、

  • 特定の人の能力や才能に依存することを避けたい。
  • 大量生産ができない。
  • 安定したサービスにならない。儲からない。

から。

対して、

企業が将来的に成長し続けるためには、よりよいソフトウェアをつくらなければならない。より良いソフトウェアをつくるためには、ソフトウェア開発を仕組み化しない。なぜなら、

  • そもそも人の思考プロセスを標準化することができない。
  • 標準化すると仕事意欲が無くなる。考えることをしたい。
  • 役にたたない標準化プロセスで残業をしたくない。

から。

というわけで、この対立が解消できれば、この対立の一つの解が得られるんではないか、と思います。

私はソフトウェア開発を標準化するという行為はソフトウェア開発においては方向性が違うと考えているわけですが、その理由についてはまた別で述べていくとします。

楽しみにしてます(^^)。