目的

ある会社に、プログラムを組むときにトリッキーなコードを書きまくる、A さんがいる。
彼の技術は非常に高い。彼にとってプログラムとは芸術であり、いかに格好良くプログラムを仕上げるかが重要なのだ。

また、平凡なプログラムを書く、B さんがいる。
彼の技術に特出したものはない。彼にとってプログラムとは目的を達成するための手段の１つであり、目的さえ達成出来るのであればプログラムなど書かなくてもいいさえと思っている。

まあ、ちょっとあからさま過ぎだけれど、このとき、この２人のどちらの方が「すごい」かを考えてみる。

判断の指針となるのはいろいろあるけれど、今は「どちらの方が会社の役に立つか」ということで考えてみる。

A さんは高い技術を持っている。彼にとってプログラムの技術を磨くことが全てなのだ。
ああ素晴らしい向上心だ。しかし、技術を磨くことは会社にとって何の意味もない。
何の意味もないとはどういうことか。技術を磨くことによって会社に大きく貢献出来るのではないだろうか。

違う。多くの場合、会社にとってプログラマの役割とは、指定したアプリケーションをバグ無く、出来る限り早く、そして保守しやすいように開発してもらうことだ。
それさえ達成出来るのであれば、デザインパターンを使っているかとか、オブジェクト指向で書いているかとか、ハンガリー記法を守ってるかとか、英文法を間違えていないかとか、プログラムが美しいかとか、そういった技術云々はどうでもいいのだ。
重要なのは、いかにして「指定されたアプリケーションをバグ無く、出来る限り早く、そして保守しやすいように開発するか」だけであり、この条件を満たすのであれば、何をしようが構わないのだ。
ただ単に、デザインパターンを使ったり、オブジェクト指向で作ったりするとその目的が達成出来る可能性が高いというだけであり、それに固執する必要などは無い。

そういった意味では、B さんの考えは間違っていない。

会社に求められているのは、「指定したアプリケーションをバグ無く、出来る限り早く、そして保守しやすいように開発してもらうこと」だけであり、この条件を満たすのであれば（満たせるのであれば）、構造化プログラミングだろうが意味を持たない変数を使おうが goto 文を使おうが構わない。

ありとあらゆる場合において、「常に目的を見据える」というのは重要だと思う。

例えば「常識」。
常識と呼ばれるようになったものには、ちゃんと根拠と目的があるのだ。
それを、「常識だから遵守しなければならない」と思ってはいないだろうか。
違うのだ。常識を守るというのは手段だ。考えるべきなのは、その常識を守ることによって本当にそれで目的が達成されるのだろうかということだ。

例えば「大きな声で挨拶をする」というのは常識の範疇だろう。この常識の目的は恐らく「相手の気分を良くする」ということだ。
確かに、大きな声で挨拶をされるのは、小さな声で挨拶されるより気分が良いことが多い。
だが、大きな声が苦手な人だっているだろう。そういう人を嫌悪する人だっているかもしれない。
「大きな声で挨拶をする」ということが、必ずしも「相手の気分を良くする」という訳ではないのだ。
もっと問題なのが、「大きな声で挨拶をするということが常識なのだから、その常識を嫌がる相手が悪い」という考えだ。「大きな声で挨拶をする」という手段が、いつの間にか目的へと変化し、本来の「相手の気分を良くする」という目的を食いつぶしてしまっているのだ。

意識して周りを見てみると、そういう話がゴロゴロ転がっている。
人に勉強を教えているのに、その人が全く勉強についてきていないのに「自分が教えてやっている」という悦な状態に入ってしまって、結局何も教えていないとか、会社をうまく運営するために社内規則を作ったのに、あまりにも遵守しようとしすぎて、逆に社内の雰囲気を悪くし、結局うまく運営出来ないとかはよくある話だろう。

常に目的を見据えること、それが重要だと思う。