AIはまだ早い。
BI/ビッグデータは用語を変えたアナグラム。
IoTはウォッチすべきながら、やはりまだ早い。
本ブログの対象である業務系システムの開発に関連する範囲においては、私は支障となるような技術の変化を感じていません。（インフラは別）
原理原則は同じだからです。
進化は感じます。昔は面倒だったものが、今は随分と楽になったなと思います。
暗記ではなく、理解していれば大丈夫
その時々で学んだこと、その「学び」のやり方が、手段を「暗記」するような身につけ方をしていたのであれば、それは激動に感じてしまうかも知れません。
加えて、昔は一つ一つの要素が煩雑（※）で低速だったので、個々の作業に時間を取られ、１人の担当できる範囲は比較的狭いものでした。しかし今は、ツールの発達・自動化によって、１人で担当できる範囲が広くなりました。これを大変と感じる人はいるかも知れません。
※単純に合理性がないだけのもの、リソース節約のためのもの
・config.sysやautoexec.batを意識しなくて良くなりました。
・ネットワークに繋げるおまじないも、ipアドレス群を指定するだけでよくなりました。DHCPも一般化しました。
・ネットワークが高速化し、コピーを始めて何時間待ち、なんて殆どなくなりました。
・ハードが高速化し、処理を流して何時間待ち、３日待ち、なんて極端に減りました。30枚、50枚のフロッピーを入れ替えて半日かけてインストール、もありません。
・ハードの発達で仮想サーバーの実用性が高まり、初期環境構築が簡素化されました。
・ちょっとしたタイプミス、パラメタミスでサーバー全体が使えなくなるようなリスク要因も激減です。
・サーバーのバックアップツール、ジョブ管理ソフト、サーバー間連携等、各種設定が簡単になりました。
・「相性」とかいう不具合も最近では聞かなくなりました。ドライバに振り回される無駄なコストは過去のものです。
・IISもTomcatも、不思議なエラーが減りました。WebLogic、WebSphereの優位性というのは、結局なんだったのか。
・コンパイルエラーの解決策も、調べやすくなりました。
・double型、float型の呪縛からも解放されてきました。
・ログ出力やログ解析、画面遷移、エラー検知、エラーメッセージ等々、フレームワークや情報によって「悩むコスト」が減りました。
例を挙げだしたら、もっともっと列挙出来そうです。
いずれも、手段も手段です。（手段の中でも末端です）
今は、様々なことがパラメタ指定や、「お任せ」指定で動いてくれます。
余談ですが、自動化の波に抵抗する勢力もいました。
例えば、「システムの提案値なんて信用できん。Oracleの初期化パラメタ（init.ora）は自分で検証しながら手動で設定すべきだ」という人もいました。
システム自動設定が90点として、これを93点に向上させると5万円のコストメリットがあったりした時代。ただ、その対応に人的コストを10万、20万、それ以上と費やす人がいました。頑なに。拘りなのか、好きなのか。
いずれにしても、その本人には『手段と目的の違い』『コスト要因を自然とカウントする』といった感性が育まれていない訳です。手段（軽視はしません）だけに忙殺されやすかった時代、このような技術者は少なからずいました。（今もいますが）
このような技術者が年を重ね、次世代のツールを扱うに際し、過去に暗記した内容では仕事が出来ない、IT技術は変化が激しい、と感じるのかなと思います。
手段も大事、過小評価も過大評価も禁物
手段は軽視しないと書きました。とても大事です。
正しい目的を見据えながら、その目的達成に必要な諸手順、それが手段です。
問題は、目的を見失って手段に没頭してしまうこと、コスト度外視で偏ってしまうことです。
手段が１つ欠けても成り立ちません。
非合理、非効率な手段は、バグを生み、保守コストの増大を招きます。
手段と手段の繋がりを見誤ってもダメです。当たり前ですけど。
上位部署の手段を実現すること・支援することが、下位部署の目的になります。
システムの上流工程で決定した仕様を実現することが、システム開発の目的になります。
例えば外部設計（基本設計の一部とする企業も）で、画面設計をします。
画面設計は、画面レイアウト、画面遷移、画面内の項目定義、イベント別のビジネスロジック、DB/Fileへの出力仕様などが構成要素です。
テクニカルな実装が必要であれば、共通設計、実装設計、実現設計などといったフェーズ／書類で吸収します。
画面レイアウトを作成する手段として、昔はHTML直書き、JSP/ASP直書き、クラサバならVisualStudioなどのIDEでパーツ配置、などをやっていました。
今も同様にやっている企業も多いと思いますが、グラフィカルなデザインツールがどんどん進化しています。
画面遷移を実現する手段として、JSP/Servlet/ASPで場当たり的に仕込んだり、スマートに仕込んだり、Strutsといった少々分かりにくいフレームワークを使ったり、高額なベンダーフレームワークを使ったり、などをやっていました。
今も大きくは変わっていませんが、体験談やサンプルなどの情報が増え、フレームワークはどんどん分かりやすくなり、ノンプログラミングの流れも出来つつあります。
画面内の項目定義を作成する手段として、多くはExcelで手動作成している企業は多かったのではないでしょうか。
これも、今でも大きくは変わっていませんが、有料フレームワークから自動作成してくれる定義書の実用性が上がってきました。（初期は酷すぎた印象です）
イベント別のビジネスロジックを実現する手段は、多岐に亘りました。作ったプログラマーしか分からないような実装も、少なくは無かったのではないでしょうか。
今は、ある程度「簡単なイベント」と「重要なビジネスロジック」を分けて管理することが出来るようになってきました。ビジネスロジックは、画面レイアウトと並んで最重要です。
エンジニアは、（例とした画面実装の範囲では）「この画面で、こんな処理をする」ということに注力できることが理想的だと考えます。ユーザーの興味も、たいていはこの部分です。
DB設計でも、非機能要件でも、バッチ処理の開発でも、パッケージのアドオン開発でも、android/iOSアプリ開発であっても、基本は同じだと思います。（ゲームを作るなら別として、業務システムの領域では。）
繰り返しで恐縮ですが、手段を軽視したりはしません。（してはいけません）
上流工程のＳＥであっても、一度は肌で感じるなど、特徴を見、構成要素を把握し、実担当者の大変さ度合いを自分なりに認識しておくこと等は必要です。
日ごろ上流の仕事をやっていると、基盤寄り、コーディング寄りの内容が苦痛に感じるものです。が、そこは高い給料貰っているんだから（貰うんだから）と、踏ん張って身に付けてください。
手段はハマると楽しく感じる面もありますが、過度に固執してはなりません。（あるいは、上流工程を目指さず、専門家となって多数のシステムに貢献するようなキャリアパスも一つの答えです。）
進化に際し、手段が変わったと認識するのではなく、楽になった（受け身姿勢では改悪されたツールも押し付けられかねません。能動的に、楽になるような手段を掴みとりましょう。）と感じてはいかがでしょうか。
目的を正しく見据え、個々の価値を正しく見定める
馬車でガタガタ揺られて移動していた人が、自動車ですーっと移動できるようになれば、乗客は便益に感謝しますし、運転手は運転技術の習得というハードルを乗り越えれば、やっぱり便益を享受しますよね。
馬車を作っていた人は廃業してしまうかも知れません。でも自動車を作る仕事、道路を整備する仕事など新たな雇用が生まれますね。
馬車の乗客はユーザー、騎手はSE、自動車製造はインフラエンジニアを例えたつもりです。
ITインフラも一定の範囲では「手段がいくらか違う」程度の範疇だとは思いますが、新たな価値創造を伴う新技術も少なくありません。
『実用性を備えた』仮想化、クラスタ、ＤＲ、海外との接続など。
業務系エンジニアは、それらインフラの恩恵を享受させて貰いながら開発しています。
インフラまで業務系SEに片手間でやれと言われたら、新技術を避けながら、全体コントロールしていくしかないですね。
（この記事を書いている途中に、そういえば私も若いころはサーバーの構成考えて、必要性の根回しして、稟議書いて、発注して、セットアップして、からやっていたことを思いしました・・。このような例は稀だとは思ったものの、社内SEならまだありそうなので、念のため。）