なぜシステムエンジニアの将来性がないのか

最近以下のブログ記事を呼んでいて少し思うところがあったので、本稿では私の経験から日頃感じていることについて書き記しておこうと思います。

freelance

システムエンジニアとしてウォーターフォール開発プロセスを経験して得られたもの

私は約12年、システムエンジニアとして実務キャリアがあります。そして長年、ウォーターフォール開発プロセスを経験してきました。12年のキャリアのうち、約半分の7年ほどをウォーターフォールの開発プロセスにどっぷり漬かっていました。その経験を通して得られたものはたくさんありました。

最初の4年間では大手ベンダに客先常駐スタイルでフリーランスシステムエンジニアとして働いていました。その開発現場では、大手ベンダながら比較的小規模プロジェクトだったことも幸いし、要件定義、基本設計、詳細設計、実装、テスト計画、テスト実施、受け入れテスト実施、リリースまで一通りの開発プロセスを経験することができました。

さらにリリース後の性能評価や運用、啓蒙活動など、営業に近いことも経験できたことはみずからの原点となっています。

あらかじめしっかり計画を立て、その計画に基いて忠実に実行していくというウォーターフォールの基本的な部分を経験できたことに加え、一番大きな経験は、これら開発プロセス全般のすべてを1人で一気通貫で行うということでした。

プロジェクトに参画した新米エンジニアだった頃は、フェーズ毎に違う人が関わり、先輩が設計したものを渡されて実装・テスト工程を担当するという感じでしたが、慣れてくるとすべて1人で任せてもらえたことが一番大きな経験でした。なぜなら、担当フェーズが違うと見えるものも違ってみえるからです。

考えれば当たり前のことですが、立場が違えばさまざまなことが違ってみえるというだけのことですが、これを実感できたことが目線の高さなど、のちに役立つ知見としてみずからの中に残りました。

ウォーターフォールの文脈で語られる「システムエンジニア」の仕事とは

iStock-637367232-min

私自身の経験を振り返ってみると、ウォーターフォールの文脈で語られる「システムエンジニア」の仕事というのは、開発工程でいえば主に要件定義から詳細設計までのいわゆる設計系の工程を担当する仕事だったといえます。

しかしながら私は、この工程に特化したシステムエンジニアという仕事の存在そのものに疑問をもっています。

そもそも、開発工程毎で担当者が違うという仕事の分担の方法論に構造的な問題があるのではないでしょうか。

私のウォーターフォールの経験でも一番大きなものは開発工程を一気通貫で担当する、という点でした。

これは工程を分業していては視野が狭く、局所最適化を行うことばかりが発生してしまいがちであるという問題意識につながります。

アジャイルの文脈ではこれがより鮮明になりました。

実装の問題はかなり複雑でテストコードを書きながら設計を洗練させていくなど、反復的な開発プロセスを行おうとするとウォーターフォールでは限界があるのです。

そもそも実装と設計を分離することなどできるのでしょうか。答えは「No」だと明確に思うに至りました。

よって体験的には私の中ではウォーターフォールの文脈で語られる「システムエンジニア」の仕事など、存在してはいけないのです。

プログラマであり設計者でありテスターであり、時にはアナリストである。そんなトータルな「エンジニア」こそが必要なのでしょう。

システムエンジニアが知っておくべきSIerビジネスの功罪

そもそも、システムエンジニアという職種が存在するのは、日本におけるSIerビジネス、つまり受託開発の文化があるから、だと思っています。

SIerは事業会社からシステム開発を受注することで成立するビジネスですが、これはシステム開発におけるプログラマなどを抱えるリスクを事業会社ではなくSIerが抱えるという点で、事業会社からみれば一定の選択肢としてもつのは当然といえる側面はあると思います。

テックドリブンな文化がない事業会社が優秀なエンジニアを採用するのはかなりハードルが高いです。

しかしSIerが工程毎に担当者を分けるウォーターフォールでの開発組織を採用している場合、そのほとんどが一番価値の高い仕事をしているはずのプログラマが一番給与が低いということが発生しています。

確かにシステムエンジニアが設計した通りにプログラミングをするという建前なので、職能としてシステムエンジニアの方が上位職だ、というのは一定理解できる側面もありますが、そもそもシステムエンジニアの設計がすべて正しいという訳でもありません。

システム開発というモノ作りにおける究極の成果物はプログラマが手を動かしてプログラミングしたソースコードなのです。

結果的にこの事実を捻じ曲げてしまったSIerの開発組織運営の罪は大きいといえるのではないでしょうか。これはSIerのビジネスモデルそのものに矛盾があるといってよいと思います。

要件に近い立場にいる人が一番偉い、というのが、SIerの開発組織のヒエラルキーになっています。(これは一方で正しい側面もありますが後ほど触れます)

事業会社がSIerに外注する害悪

前述したように事業会社にとってリスクヘッジというメリットもありながら、ITが経営に与える影響が高まっている昨今では、むしろ事業会社にとって経営に直結するシステム開発をSIerに外注することの方が、ビジネスの原則である「選択と集中」に矛盾しているのではないでしょうか。

「システム開発などうちのコアコンピタンスではない」という経営者がいたとしたら、いまどきではないちょっと古いビジネス領域を対象としているといえるでしょう。

それでも、多くの企業のIT化が進んでいくでしょう。

「システム開発などうちのコアコンピタンスではない」を実際に言葉に出してみて、少しでも違和感を感じ、システムを外注しているのであれば今すぐにでも内製化を進めることを検討した方がよいレベルだといってもいいすぎではないと思っています。

内製する事業会社にはシステムエンジニアは存在しない

昨今ではwebベンチャー企業などを中心に事業会社でエンジニアを自社で抱えながら内製している企業が増えています。

そもそも、このように開発を内製する企業には、ウォーターフォールやSIerの文脈で存在するようなシステムエンジニアという職種は存在しません。

なぜなら、エンジニア全員が基本的には一気通貫で開発プロセスを担当するからです。分業は工程毎ではなく、サービス単位、KPI単位、機能単位、チケット単位などです。設計だけを担当するシステムエンジニアという立て分けはありません。

フリーランスで実績や経験を積みたい方は、弊社のエージェントが無料でご相談を受け付けておりますのでぜひお気軽にこちらからご登録ください!

事業会社がエンジニアを使って内製する大きなメリット

事業会社が内製する大きなメリットは「要件に近い立場に手を動かすエンジニア(プログラマ)がいる」という点です。

私の経験でも前述した通り、ウォーターフォールでも全工程を経験すると視野が広がり目線が高くなりました。これは要件をもっている人のそばにいるとシステムで解決すべき、さまざまな課題がみえるからというのが一番大きい気がしています。プログラマが要件から遠い位置にいるウォーターフォールでは限界があります。

手を実際に動かすプログラマが要件とともにあるとき、よい設計やよい実装が生まれ、それがよい品質を生み出す、というのが実感値なのです。

SIerは開発領域を移行すべき

shutterstock_562533253

こうみていくとSIerって存在価値がない、SIerにいるのにどうするのか?という話が出てくるのではないでしょうか。私はSIerはこれから受託開発というビジネスを縮小していき代わりに「エンジニア教育」「事業会社の内製支援」「BtoB支援ツール開発」あたりのビジネスに転換していくべきだと思っています。

エンジニア教育はこれから間違いなく必要でしょう。

エンジニア不足はずっといわれており、これからもずっと続くと思います。ジュニアクラスのエンジニアやビジネスサイドでエンジニアに転職したいという方も増えてきています。

エンジニア教育は元々SIerが得意とするところなのでこれまで社内で培ったノウハウが活かせると思います。

テックドリブンな世の中の流れに危機感をもっている事業会社の経営者も増えています。私の元に届くスカウトや相談などでも、「現在は外注しているシステムを内製に切り替えたい」という類の話を以前よりよく耳にするようになりました。この流れを支援して欲しいニーズは一定あるので、SIerはこれまでシステム開発を行っているので内製支援という切り口でコンサルティングを行うというのはありかもしれません。

ただしウォーターフォールではダメでアジャイルの内製支援を行う必要があります。

内製はシステム運用まで面倒をみる必要があるので瑕疵担保期間だけ保守をすればよいという感覚ではコード品質は保てません。アジャイルプロセスにしてリファクタリングを定期的にしていくようコンサルできなければならないと思います。

最後にBtoB支援ツールを開発する事業会社になる、というのも可能性としてありそうです。

SIerはそのビジネスの性質上、BtoBビジネスを行っており、普段から企業のニーズを聞く立場にあります。これらのニーズを包括的にシステムで解決するプラットフォームを開発し市場に受け入れられれば、もはやSIerではなく事業会社といえるでしょう。

この場合も自社開発なので開発プロセスはアジャイルに移行することは必須です。

システムエンジニアというキャリアを脱却しよう

いかがでしたでしょうか?

ここまでみてきた話を働く人に置き換えてみると、もはやシステムエンジニアという職種で働くことには限界がきているといってもいいすぎではないと思います。

むしろシステムエンジニアという文脈で働き続けると、SIerの受託開発ビジネスに意図せず加担することになるので害悪ですらあるのではないかとさえ思われます。

危機感を感じた方は是非今すぐにでもこのような危機感を社内で共有してください。

その反応が微妙なら、正直内製している事業会社に今すぐ転職することをオススメします。

転職やフリーへの転向を検討中の方、ITプロパートナーズが無料でご相談に乗らせていただきます。まずはお気軽にご登録ください!週2日から働ける案件や高額案件、スキルを存分に活かせる案件など豊富にご紹介できます!

bn04

もし、今あなたが

・フリーランスになるか悩んでる
・自分に合った案件があるのか不安
・そもそも何から始めればいいのか分からない

などお困りであれば、ぜひ弊社ITプロパートナーズのサポート内容を確認してみてください!

登録後、専属エージェントに無料相談もできますよ!

※週2日 / 30万〜のフリーランス案件を紹介中です
※ご経験やご希望によっては案件を紹介できない場合がございますのでご了承ください。


よく見られてる関連案件

b80c977483d024c14549510e194361fe 2_anken 3_anken
The following two tabs change content below.

tchikuba

フリーを経てwebプログラマ。Ruby on Rails, Python, CoffeeScript, TDD, BDD, Lean, Agile, スモールビジネス, 機械学習, 人工知能, 投資, FX, 酒, 歌など。エンジニア出身の起業家になってもっとエンジニアを幸せにしたい。
freelance