最近の開発では、フレームワークの存在は欠かせないものですが、多くの設定ファイルを書く必要があります。
これは、フレームワークというものが、さまざまなニーズに対して柔軟に対応するという考えのもとに存在しており、このような柔軟性を確保するために、アプリケーションのさまざまな設定を外部のファイルに記載する手法をとっているためです。

Javaの代表的なWebアプリケーションフレームワークである、Strutsもアプリケーションのさまざまな設定を外部のファイルに記載することにより、柔軟性を実現しています。

しかし、ある程度の規模の開発だと設定ファイルが肥大化し、管理が大変になってきます。複数人の開発者が同一ファイルをメンテするケースも増え、それぞれの修正分をマージする作業で、人為的ミスが発生してしまうことも多々あります。開発者の一部が社外にいる場合などは、さらに厳しくなります。
このように、設定ファイルの管理が開発作業の負担となってしまうケースがしばしばあります。

これらの問題の解決策として、最近ポピュラーなのが規約重視の考え方です。規約重視の考え方とは、「規約に従っていれば設定ファイルがなくてもフレームワーク側が自動的に処理してくれる」というのがそのコンセプトで、Railsの「Convention over Configuration（設定より規約）」のスローガンがもっとも有名です。

例えば、サーバーサイドJavaの開発では、画面をJSPで実装し、その画面のアクション毎にクラスを用意します。そのアクション単位のクラスと画面を設定ファイルで関連付けする形式が一般的です。規約重視の開発では、ある規約に従ってコーディングすることにより、設定ファイルによる関連付けの記述を省略するのです。（ここではボタンの名前とクラス名をあわせることで実現します。）

規約重視の開発を行う上で重要なことは、その規約が開発者にとって受け入れやすい自然なものでなければいけません。その規約が複雑すぎて、覚えるのに苦労するようでは、かえって開発の負担となります。

規約重視の考え方のポイントは、「規約に従っていればフレームワーク側が自動的に処理してくれる」ことです。
しかし、逆にどこでどんな処理が行われているかがわかりにくく、初めて触れた人は、「狐に鼻をつままれたような感じ」を受けることが多々あります。
（実際に当社の新人も皆、毎年、必ず同じことを言います。）

そこで、規約に関するドキュメントの存在は欠かせないものになってきます。また、サンプルとなるリファレンスプログラムの存在も重要です。
これらのことを、開発の事前作業として行うことを負担に思う方もおられるかもしれません。
当社でも、数年前から規約重視の考えを導入し開発を行っていますが、問題となるのはドキュメントが整備されていないことによる、プロジェクトへの新規メンバ導入時の教育コストでした。しかし、そのコストを除けば効果は絶大でした。開発をほとんど行ったことのない新入社員や、お客様のシステム部の方であっても簡単に開発を行えたという実績があります。
※たまたまその仕事では、お客様のシステム部の方もシステムの一部を開発しました。

ドキュメントを準備することで、プロジェクトに参加する人間に対する教育の手間を省ければ、結果的に、開発工数はかなり削減できます。
また、規約を重視していれば、当然のことながらプログラムコードが一定の形式で統一されます。よって、誰が書いても同様なコードが出来上がるので、後々メンテも行いやすくなります。

「全て、自分の手で実装するけど、コードの一貫性を保つために規約も守れ」といわれて、作業を行うよりも「規約を守れば自分も楽を出来る」というメリットを認識した上で規約を守るほうが、開発者のモチベーションも違ってくると思います。

さて、ここで「おやっ？」と思う方もいるかもしれません。
この規約重視の考え方だと一見、フレームワークのコンセプトである、さまざまなニーズに対して柔軟に対応するという考え方を否定してしまっているように思えるかもしれません。

しかし、それは違います。
あくまでも、規約に従って省略する部分は、アプリケーションを作るうえで定型的な部分だけです。実際の業務的なロジックや、画面の細かい制御などは、柔軟に対応できるようにしておきます。さらに、規約により省略している部分も、設定ファイルに記述を追加すれば変更することも可能にしておきます。
このようにして、イレギュラーなパターンに対しても対応可能にしておけば、フレームワークのコンセプトである、さまざまなニーズに対して柔軟に対応するという考え方を実現できます。

前述したようにフレームワークが勝手に処理を行うため、内部でどのように動作しているかわからず、不安だという理由で規約重視の開発方法を嫌う方もおられるかもしれません。
しかし、これも前述しましたが、プログラムは、人の手で書かなければ書かないほどミスが減るのだから、できるだけ人の手でプログラムを書く部分を減らしたほうがよいでしょう。私が好きなSeaser2(Javaのフレームワーク)の生みの親である ひが　やすお氏 も、「いろいろな産業が人での作業がからコンピュータによる自動化に移っているのだから、ソフトウェアの開発も同じことが言えるのではないか」と言っているように、お客さんのためにやってきたことを、自分たち自身のためにも積極的に行うべきだと思います。