プログラミングをするときに最低限考えなくてはいけないのは、クライアントの要求を満たしたり、バグがないようにしたりすることです。
このほかにも、ソフトウェアエンジニアはしばしばトレードオフ問題に頭を悩ませます。開発プロジェクトに欠かせない3つの要素を表す「QCD」という言葉を聞いたことがある人も多いでしょう。
- Q：品質（Quality）
- C：コスト（Cost）
- D：納期（Delivery）
これらの3つは、すべて達成してこそプロジェクトの成功といえます。
ところが現実のプロジェクトでは、開発が終盤に近づいてくるとQCDに「調整」が入ることも少なくありません。
3つの目標をすべて達成するには、こうした「調整」をせずに済むようコントロールする必要があります。それには、プロジェクトや成果物の状態がいつ誰が見ても分かるように、見通しのよい状態に保っておくことが大切です。
例えば、以前に自分が関わっていたプロジェクトにバグレポートが届いたと想像してみましょう。現在は新しいプロジェクトで手一杯なので、ほかの誰かが修正作業を担当することになったとします。
このとき、コードがグチャグチャだったら？仕事をするうえで必要なドキュメントが不十分だったら？自分たちがメンテナンスを怠っていたせいで、ほかの人に迷惑がかかってしまうわけです。
もしかするとバグ修正の担当者にとっては、前任者に聞かなければ分からないことだらけかもしれません。その場合は、山ほどの質問を浴びせられることになるでしょう。
メンテナンスに時間を割くのは、なにも将来のためだけではありません。プロジェクトや成果物の状態を整理することで、QDCに影響が出る前にプロジェクトの進行を素早くコントロールできるようになります。分かりやすく、見通しのよい状態を維持できれば、今取り組んでいる仕事もスピードアップするでしょう。
とはいっても、誰が見ても理解できるコードやドキュメントを作っておくことは、決して簡単ではないでしょう（実際とても高度な技術かも？）。
一方で、分かりやすく作るというのは、理解しながら作ることと似ています。まずは自分でよく理解したうえで、誰がみても分かるように工夫しましょう。そうすれば、設計力と実装力も自然と向上していきます。
