ある種の制約は自由を増やす

いつも読ませていただいている、まつもとゆきひろさんの日記でITproの“Rubyに学ぶ「Ruby on Railsの正体」”が紹介されていました。

いわゆるフレームワークは、良く出てくるパターンを簡単に記述できるようにしたものです。Ruby on Railsの特徴はさらにに一歩推し進めて、制約を与えることでより簡単に記述できるようにしたものです。本文中の表現でいうと「Railsを使いこなすということはRailsの支配を受け入れることである」と言うことになります。

まつもとゆきひろさんは、これを的確な指摘であるとして

ある種の制約は自由を増やす傾向がある。ある種の自由は人間の負担を増す傾向がある。

と述べられています。この文章を読んで、「まさにそのとおり」と思いました。

ソフトウェア工学の初期においては、構造化プログラミングはスパゲティプログラムによる混乱からプログラマに自由を与えました。オブジェクト指向言語も何でもできるC++に制約を与えて、Javaの安心してプログラミングできる自由な世界が作られました。VBに代表されるコンポーネントベースのプログラミングも、コンポーネントという制約を与えることで複雑な機能の組み合わせが自由になりました。

Ruby on Railsについては、まだあまりよく知らないのですが、ソフトウェア工学の流れに沿った新しい自由を構築するものなのでしょう(SEA関西SPINでもRuby on Railsの講演が計画されているようなので楽しみにしています)。

ところで、このお話をプロセスにあてはめる時、ウォーターフォールの方が制約をたくさん与えるのだからより自由だ、などと言うのは詭弁です。ウォーターフォールの制約にしろ、XPのプラクティスにしろ、毎回考えていると負担になることを制約としてまとめることで、プロジェクトの戦略的な実施や、状況の把握、バグの地獄からの解放という自由を与えるものだからです。とにかく制約すればよいのではなく、「ある種の制約」とよべるような開発者の創造性を高める制約でないといけないと思います。