成功は、その時の状況とあなたの行動が一致したときに得られるものであり、殆どの場合、普遍的なものではありません。
例えば、わが国は戦後の荒廃から目覚ましい経済発展を遂げてきましたが、これとて、時代の背景や、手段や政策が上手く作用したことの結果であって、その方法が何時までも通用するものではないことは、いまさら言うまでもないことです。
１９８０年代に既に行き詰まりが見えたにも関わらず、やり方を変えなかった為に、バブルの崩壊で大きな怪我をしてしまった。対米貿易黒字を減らすために、内需の拡大を要請されたとき、この国は「公共投資」しか考え付かなかった。それは、この国にとって最大の成果を上げてきた方法だったのです。
上手くやってきたことを否定することは容易では在りません。余程、しっかりした見識が無ければ、なかなか実現しないことです。
ソフトウェアの開発においても同じようなことが言えます。確かに、今回は或る方法を試みて上手く行ったかも知れませんが、何時までもその方法に拠るわけにはいかないのです。
時代の要請は変わります。技術も、そこに居る人も変わります。開発の環境やツールも変わります。
１５人で５台しかない端末をやり繰りしなければならなかった状況から、各自に１台の端末が割り当てられたにも関わらず、やり方は今までと殆ど変わらないと言うわけには行かないでしょう。
さらに、今日ではチームは勿論のこと、組織全体がネットワークで繋がれ、情報が即時に伝達されるようになったにも関わらず、相変わらず、情報が届けられるのを待っているのでは話になりません。
アセンブラに始まったプログラム言語も、色々な言語が使われるようになり、最近ではビジュアル化された言語？も出現しています。そのような状況で、今までと同じような設計書の書き方では、効率が悪くて仕方が在りません。
これからのエンジニアは、変化を敏感に感じ取りながら、「よし、こんどはこの方法でやってみよう」という取り組みが必要になります。そのとき、ポイントになるのは、今までのやり方を否定できるかどうかです。
特に、上手く行った方法の場合は、そこから抜け出せなくなる危険があります。幸いにも、ソフトウェア開発で、今まで「上手く行った」といえるような状況は少ないかも知れませんが、それでも、詳細スケジューリングなどの取り組みで、それなりの効果を上げている組織や個人はいます。彼らも、今後、それを越えることが出来なければ、そこで止まることになります。
エンジニアであろうとなかろうと、人間として幸福であろうとすれば、自らの可能性を求める必要があります。エンジニアであれば尚更です。そのことが、よりよい貢献に繋がるのですから。
そしてそのためには、時には上手くやってきたことを捨てて、新しい方法に挑戦することです。
［「Index of SE の為の講座」
］
［］