制約こそエンジニアの想像力を生む源泉ではないか

ソフトウェア開発の仕事をしていると顧客の文化やdeliveryする開発元の文化でプロジェクトに様々なルールを持ち込むものです。
金融システムの再構築なんて大規模なプロジェクトになれば、それはもう大変な管理のための管理のルールを持ち込んで、もちろん、システムの特性上、お金の勘定が合わなければシステムとして成り立たないので厳密なルール下で箸の上げ下ろしを教育されるものです。

一方、そう言ったシステム上の特性がなければ、そんな厳格なルールは固定費を果てしなく押し上げるだけなので、微塵にも考えたりしないです。お金かけたくないから。
＃なんとなくやったつもりにしているプロジェクトが多いのではないかと。

ルールとは、人の振る舞いを縛るものです。人の振る舞いを縛ることでそのもとにある目的を達成する。その目的とは、品質管理なら、要求事項の充足に対する主に不足を明らかにして、指し示すことです。
工程作業標準であれば、その工程のdeliverableを作るための段取りを示し、その工程のでモノづくりの箸の上げ下ろしを規定します。コーディング規約なら、コードの書き方や処理のお作法を示し、そのプロジェクトの中で作られるコードの可読性や処理の身なりの躾をします。

こうしたルールが必要なのは誰しも理解できるものだと思うのですが、(実際は、どう思われているのでしょうかね)、少なくとも「ルールなんて面倒だ。」と思う事も事実だと思うんですね。
ルールは、実際自分を含めたエンジニアが何かをしようとするとき、面と向かって立ちはだかりますからね。で、そのルールの存在で実はエンジニアを守ってくれることがあると気づかないエンジニアは舌打ちをするわけです。

ルールはエンジニアを守る
ルールは、そのルールを適用するプロジェクトを守る武器です。そのルールがあり、メンバが順守するからこそ、ルールがプロジェクトのメンバの身代わりになって矢面に立ってくれるのです。

もし、ルールを守っていながらも、間違いがあるのであるのなら、それはその間違いを正せばよいのであって、プロジェクトのメンバ一人ひとりが責められることはないのです。

でも、ルールはエンジニアを守ってくれますが、ルールを守っていれば顧客が期待する課題解決のソリューションとしてリリースできるかと言えばそうではないのも確かです。ルールは振る舞いを型にはめるものであって、その型の上で、どう振付けるかまでは教えてくれません。

制限されても
ルールが縛る振る舞いは、確かに、自由な発想を制限すると言い換えることもできます。実際、何も要件がないなら振る舞いを縛らない方が良いことが多いと思えるかもしれません。でも、それは何も要件がない前提での話であって、今のシステム開発の置かれている環境には、顧客の要件の他に雑多な要件から法対応までの要件が絡み合い複雑な体をしているものです。

それらの絡み合う要件を無視してまで、自由な発想こそ、エンジニアの思考の源泉だなんていう輩がいるとするなら、やりたくないけれどやらなければならないことを忌み嫌うようなエンジニアなんてプロジェクトのメンバのためにリジェクトしなければなりません。

あくまでも、ルールはプロジェクトメンバを守るための武器として使うのですから。

振る舞いを縛るが思考は縛らない
そう言い続けると、どれだけマゾなんだよと言われそうですが、やはり、エンジニアの振る舞いを縛るルールはそのルールが求める目的に照らせば必要なことです。

良くあることですが、ルールがあると窮屈だと文句を言うエンジニアは、ならば、どうしたいのか、と問うとノーアンサーになることが多いのも実際にあることです。そう言ったエンジニアは、もともとの発想のはじまりが人から物を与えられた上での発想になっているからではないかな、と思うのです。

発想が自由なエンジニアであれば、例えどんなルールであろうとも、そのルールがプロジェクトの達成のために合理的な制約となっているなら、(個人的な感情は棚に上げて)、そのルールの意図を汲み取るものです。それができるからこそ、ルールの上でどう振る舞うかに重点を置き、そこに自由な発想とクリエイティブな創造の世界を創り上げられるのです。

ルールは、エンジニア自身の思考を縛ったりしないものですし、すべての振る舞いを縛ることもありません。ルールと言う制約で縛られるからこそできる発想を見つけられるときの喜びを得られるエンジニアという考えの方をしたいものです。