日本人と欧米人ではコーディングの判読性についての考えが違うようです。自分のキャリアパスや人生目標に向かって転職するハードルが低いのは米国ですが、米国でのソースコードは判読性を高めて、属人性を極力減らしています。一方、日本ではどうでしょうか？そもそも、難しく論理を組み立てがちであり、自分自身しか判読できなソースコードに優位性を抱いている方はまだまだ、少なくないはずです。私が何十年も前に学校を卒業して初めて開発の現場に就いた時は、判読難解なコードを書くことが優秀であるとされてきました。当時はハードウエアのリソースが限られてきたので、一定のパフォーマンスを上げる為にはハードウエアやプログラミング言語の特性を熟知して、コード量が少なくてパフォーマンスに優れたコードを書くことが鉄則でした。当然、この様なソースコードは特別な振舞を要求される機能は難解になります。経験が浅いエンジニアにとってはどれもが難解・判読不能になります。時代とともに運用・動作環境のリソースは広大になってきましたが、その当時の価値観（判読不能な、難しいコードを書くのが優秀）だけが進化しないまま残念なことになっていると感じています。
可読性が高ければ潜在的バグが無くなる
社会環境やビジネス環境の変化によって利用者の要望や価値観が変わってきます。これによて影響を受けるのがITサービスです。そのサービス一つ一つにはプログラム、即ちソースコードがあり、それを要求に従ってメンテナンスする作業が必ず発生します。
この作業は対するソースコードが判読しやすければ、開発者でなくとも保守作業ができます。ところが、属人性が高く癖のあるコードであったなら、開発者自身が保守することになります。我々が開発したソースコードで実現したサービスはEOL（End of Life)の定義・宣言が全くありませんので、未来永劫使い続けるという事だって起こりうるのです。そうすると、属人性が高いソースコードを書けば書くほど、過去の自分の実績の奴隷となってしまいます。ですから、可読性が高いソースコードを書くように努力しなければなりません。
しかしながら、可読性を高めようと思って行動しても各自の癖は否めません。それを是正するのがコーディングルール（コーディング作法）（以下：ルールと記載）が必要となります。
このルールの基本は現場で作成するのが一番ですが、全ての領域を均等にカバーできているかは、そのチームの経験値によって変わりますので、本やネット上に公開されているものを参考にしてルールを決めることをお勧めします。
このルールを決める一つの観点として、そのルールがどんな事に有効であるかを明確にしておくと更に各人のスキルが均一化されます。
ルールとして明確にしたいポイントは以下になります。
- 命名
- 可読性（保守性への貢献）
- 品質・安全性
- 性能・効率
この様に明確にルール化するということは、製造業に例えると製造技術の一つとなります。同じものを作っても、製造技術の出来不出来で生産性・品質に大きな差が出てきます。製造業ではQC活動の中にもこのような取り組みを入れて、日々改善しています。
同じ要求を開発する際に、このルールがあるチームと無いチームでは結果的に品質と生産性への差が出てきます。
アジャイルチームでは常にこのルールを意識し、レトロスペクティブ（振り返り）で改善するテーマの一つにすることをお勧めします。