ショートカット
ファシリテーター × あり方
コーディングの向こう側
Hello, ANOTHER world!
オブジェクト指向のはなし
プログラミングのはなし
C言語実力診断クイズ
eSkillBooks
コーディングの向こう側
私的「術」講座

「改善」の術 - PART2

因果なものです度

方法と結果の原理

極めて一般的に言うなら、結果は方法に左右されます。そして、ある特定の結果を得るための方法は、だいたい決まっています。たとえば次のように:

  • 決まった薬品を決まった手順で調合すれば、決まった物質ができる
  • 決まった材料を決まった手順で調理すれば、決まった味付けの料理ができる
  • 決まった生活習慣を繰り返せば、ほぼまちがいなく成人病になる
  • 決まった方法で力を入れれば、ぎっくり腰になる可能性が高い

そう考えると、はじめから結果が見えていることというのは意外にたくさんあります。それに気付かないのは、ただ目を背けていたからというだけです。気付いてしまえば、やるべきことは決まっています。

違う結果を求めるなら
少なくとも違う方法を試す必要がある

簡単な理屈ですね。

さて、話を元に戻しましょう。ものごとを改善するためのアプローチとして、次のどちらを採用すべきかというのが問題でした

  • うまくいっている部分がよりうまくいくようにする
  • うまくいっていない部分がうまくいくようにする

ソフトウェア会社が抱えている問題は、多少の違いこそあれ、だいたい似たようなものでしょう。ですから、うまくいっていない部分としてリストアップされる項目がどこの会社でも似ているであろうことは容易に想像できますし、実際にそうだと思います。もし業界の人が全員「うまくいっていない部分を改善する」というアプローチをとったとしたら、あちこちで同じ結果が生まれるでしょう。こんなにおもしろくないことってあるでしょうか!?

そういうわけで、私は次のように結論します:

改善とは、うまくいっている部分をより良くすることである
(・・・少なくともエンジニアにとっては)

これについては異論があるという人がたくさんいそうな気がします。でも、それはそれで結構!このページのタイトルを見てください。ここで紹介しているのはあくまで私の意見です。

まんべんなくやろうなんて、ムシが良すぎます。うまくいっていない部分については、場合によっては切り捨ててしまう方が賢明だと思います(どうせどこかでだれかがうまくやっている可能性が高いので、いまさら頑張っても勝てそうにありません)。

広く浅く VS 狭く深く

得意な部分を集中的に伸ばしていくという方法には、弱点もあります。それは、特定の技術を深く掘り下げるほど、他の分野への適応力を失っていくということです。環境に適応しすぎた種が絶滅するように、技術に特化しすぎたエンジニアは時代の変化によって職を失うことになるでしょう。しかもこの業界では、時代は確実に変化します。数年ごとに常識と非常識が入れ替わるというすさまじい様子を、皆さんも目撃していると思います。

たぶん一般論ならこうです:

特定の技術だけを掘り下げるということは将来の選択肢を自らの手で少なくする行為であり、避けるべきことだ。自分自身はできる限りいろいろな分野の知識を広く浅く学び、特定の分野の知識に長けた人物を必要に応じて仕事上のパートナーに選ぶようにしよう。

しかし、我々はエンジニアですから、特定の技術を伸ばす(=改善する)必要があります。同時に特定の技術だけではいずれ時代遅れになって職を失うこともわかっています。すでに述べた「方法と結果の原理」に従って、またしても方法を変えなければなりません。すなわち、「広く浅い知識も学ぶ」必要があるということです。

「広く浅く」と「狭く深く」を両方とも、しかも意識的にやらなけらばならないなんて、気をつけないと2重人格になりそうです。

前へ

目次へ
問題の順位

(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)