ネタ元：翔ソフトウェア (Sho's) Fujiwo の日記
開発をもっと楽にするNAgileの基本思想の第４回が公開されています。こちら。執筆されたFujiwoさんの日記はこちら。
実は、このNAgileの記事、結構いろんな「気づき」があるので毎回楽しみにしてるんですよねー(^^;
今回は「プチ・パラダイムシフト」のお話。 当たり前といえば当たり前の話なんですが、結構、忘れがちであることが多いんですよね。 問題って。
以下、ネタばれなので要注意(^^;
BusinessやProblemに対するSolutionを提供するのが目的なのに、手段が目的に変わっちゃっていないか？という内容の記事です。
実際、テクノロジーは技術者にとって、魅力がいっぱいです。
で、最近ではテクノロジーを提供するメーカー側の露出も多くなり、テクノロジーを提供する側のプレゼンテーション能力も相まって技術者をわくわくさせてくれます。
しかし、本質は本来、エンジニアが目を向けるべきBusiness(業務)でありProblem(問題)です。 これを見失ってしまっては本末転倒です。 我々エンジニアはSolutionを提供するのが目的であり、テクノロジはあくまでその１手段であることは忘れないでいたいものですね(^^;
テクノロジも大切ですが、Solutionを構築するための基礎知識である開発の知識「オブジェクト指向」しかり、「開発プロセス」しかり、「業務分析」しかり、「業務知識」しかり、エンジニアが目を向けるべき場所はたくさんあります。
特に「業務知識」などは大きく変更されることのあまりない（小さな変化はあるかもしれませんが）、経験の生かされるスキルです。 ですが、情報が少ないのか、経験がものを言うのか、非常に長いスパンで習得しなければいけなかったりします。 地味ですが、そこには問題の本質があるように思います。
テクノロジがわくわくするのは、きっと、テクノロジがエンジニアにとってのBusinessやProblemに対するSolutionだからだと思います。 Solutionがテクノロジという形でメーカーから提供されているという構図ですね。 ここが難しいところですが(^^;;;
まどわされることないよう、きちんと自分の「エンジニア筋力」としたいところです(^^)