ITエンジニアとIT技術について

基本設計

これからのエンジニアは、技術について日々学ぶべき!

みなさま。
WordPressによるブログ投稿第2弾を書いている加賀美(カガミ)です。
みなさま、おはようございます。

さて、前回カガミはITエンジニアが業務知識を学ぶことの大切さをお伝えしました。
このことは今回も覆されることはございません。
ですが、今回はITエンジニアなら誰でも好きであろうと思われる、IT技術を学び続けることの大切さについて書こうと思います。

それではみなさま、本日も最後までよろしくお願いいたしますm(_ _)m

時代の変化と共に明らかに変わった理想のエンジニア像

さて、前回は『プログラムが書けなくても優秀なエンジニア』について書かせて戴きました。
そのようなエンジニアの1形態として、業務知識についてエキスパートであるエンジニアについて書かせて戴きました。
業務知識のエキスパートの存在の大切さ、そのことについては昨今でも変わりはございません。
ですが、前回ご紹介した或る先輩SEの方のようなご意見、「SEは、別にプログラム書けなくても良い」が、今のエンジニアはそのままでは通用しなくなりつつあるのも事実であると感じております。
今回はそのことについて書かせて戴きたいと思います。

では、なぜそのような事態になったのでしょうか?
それは、日々進化するIT技術が、システム開発における要件定義レベルくらいにまで影響を与えるようになったことが挙げられると思います。

例えば、プログラム開発におけるMVVMアーキテクチャパターンについて話しをしますと、もしMVVMアーキテクチャパターンをエンジニアが知っており、プログラム開発でそのパターンを使用すると、従来テスト技術者が画面操作で膨大なテストケースを打鍵していた工数が、その7割くらい(かな?)はViewModelに対する自動化テストで解決できることなどが挙げられます。

どうです、技術を少し知っているだけで従来に比べてこれだけの金額差が生まれるとしたら、すごいと思わないですか?昨今、欧米でも後進国のエンジニアの単価の向上により、インドやら東欧やらにこうした作業をオフショアするというスタイルの限界がささやかれつつあります。

日本は、日本語という言語の壁がこうしたオフショアの実現を困難にしていたため、長らくSI企業は受注について安泰をしておりました。ですが、これからのIT業界は、開発の原価を下げるためには最新の(別にMVVMアーキテクチャパターンは最新でもなんでもございませんが💧)IT技術を駆使して、生産性を爆発的に向上させて解決をする道しか無いのだということであると思います。

このことが、従来のSE像、ITエンジニア像を覆しつつある、ある一定量の流れとしてあるのかなということでございます。

プログラマーの本懐!?将来のキャリアは『システムエンジニア』から『アーキテクト』へ!

私見ですが、昨今のITエンジニアの職業に『〇〇アーキテクト』なる言葉が増えてきていると感じております。この章では、そのことについて簡単に書かせて戴きたいと思います。

まず、従来呼ばれてきた『システムエンジニア』という呼称と、『アーキテクト』はどんな点が異なるのでしょうか?独断的な私見ですが、カガミが肌で感じている事として、仕事内容が『システムエンジニア』は横に広く、『アーキテクト』は縦に深い傾向があると感じております。

具体的に申しますと、『システムエンジニア』は、SCMやERP、CRMや在庫管理など、『複数の処理、またはシステムを連結させるコト』や、『処理に対する<入力>と<出力>に注目するコト』に注力する傾向があるかと思います。つまり、外部仕様やインターフェース、業務フローやデータモデルの作成が主な仕事内容であるということです。入力と出力の間にある『処理内容』については、プログラマーにお願いし、ちゃんと仕様通りに動きさえすれば中身についてはこだわらない傾向があったのだと思います。

一方『アーキテクト』は、それに比べて『処理内容』こそ主たる仕事内容の傾向があるように感じております。

具体的に申し上げますと、先ほど述べた『MVVMアーキテクチャパターン』など、開発においてどのアーキテクチャパターンを採用するかや、担当する仕事がインフラであってもDBのパフォーマンスチューニングについてOSまたはAPレベルの領域まで調査やアドバイスをしたり、大規模システムのフロント構成からアプリケーションレイヤー、OSレイヤー、ミドルウェア、ハードウェアレイヤーおよびサーバーの多層分散システムの構成まで『縦に深く』、対象の構造を考えることなどが挙げられます。

では、なぜこのような事態になったかと言うと、端的に言えばWebサービスの台頭が挙げられると思います。

Webサービスの場合、主な利用者がtoC、カスタマーであるため、規模が1000万~数十億人となり、処理能力についてIT技術の工夫が必須項目となります。また処理のピークが従来のtoBシステムに比べて予測困難です。
例えば、とあるテレビ番組で納豆の特集が組まれていたら、その数時間後に納豆料理のレシピサイトのアクセス数が急激に伸びることなどが挙げられます。
従来のエンタープライズ系システムなら、基幹システムがメインなので会計業務がピークとなる月末月初のアクセス数であるとか、3月末など年度末が忙しくなるなど、ピークについてある一定のリズムがございますがWebサービスの場合まったく異なります。
このことが、インフラとアプリケーション双方の深い知識をアーキテクトに要求させることに拍車をかけるのだと思います。

つまり、前回と同じく『ソフト、ソフト、業務に活かせなければただの自己満』になってしまうという事です。この点は前回と同じですね(^^♪

最後に、こうした傾向を持つアーキテクトという職種を、従来のSI企業はどう取り扱うべきか?についてですが、カガミの私見だとシステム開発における見積金額を算出する責任と役割を持たせれば良いのかな、と感じております。
ようは、発注会社にシステム構築費を提示する際の総原価に責任を持たせるということです。アーキテクトの持つ技術に対するアドバンテージの、腕の見せ所だと思います。

結びに

今回は、SI企業、Web企業をまたがって、今日広く注目を浴びている『アーキテクト』という職種を主に意識して執筆をしてみました。

みなさま、お読み下さりありがとうございます。

アーキテクト、あるいはフルスタックエンジニアとは、まさにエンジニアでないとわからない領域について専門とする職業であり、従来のシステムエンジニアのキャリアと若干異なる傾向があるように感じております。

それは、システムエンジニアなら、経験を直線的にコツコツと積んでゆくキャリアイメージなのですが、アーキテクトの場合、朝三暮四、学んだことに対するスクラップアンドビルドが常に要求されるイメージがあるからです。

ようは、『昨日の常識は今日の非常識』になりやすい傾向があるかと思うのです。
このことを、『ワクワクできるか』が、自身のキャリアをシステムエンジニアにするか、アーキテクトにするかの分かれ道になるかと思います。

最後に、今回のここまでに書いた内容は、あくまで曖昧さが含まれ、多義的な意味合いを持つ『システムエンジニア』と『アーキテクト』という用語に対する1側面について述べたに過ぎないことを申し上げておきます。

ここまでに書いた内容で単純に『システムエンジニアとはこういうものか』とか『アーキテクトとはこういうお仕事をするのか』などと『決めつけ』をしないようにお願い申し上げます。
またアーキテクトももちろん従来のシステムエンジニアと同じく、ユーザーにわかりやく説明をしたり、ユーザーのビジネスについて学んでいく必要があることは念のため申し上げておきます。

それでは、今回は以上となります。
最後までお読み戴きありがとうございました。














みなさまに、今日も良いことありますように!!



タイトルとURLをコピーしました