皆さんが知っているシステムエンジニア像、それって少し違うかも？
おっすー。ガッチョです。
今回はシステムエンジニア像（システムエンジニアの本質）と仕事内容についてです。
システムエンジニアは今も人気な職業の一つなため、就職・転職してみたいと思う方も多いようですが、実際にどういう仕事をしている人なのかピンとこない方もいますよね。
私もシステムエンジニアとして働く道を選んだときは、パソコンとにらめっこしながら仕事をしている人という大雑把なイメージしかありませんでした。
しかし、10年以上システムエンジニアとして働いてきた中で振り返ってみた時、システムエンジニアが本当にやるべきことは「顧客が抱える課題を解決する人」ということでした。
そこで、この記事ではそのシステムエンジニアの本質と仕事内容について、私なりに気付いた点を解説します。
これを読めば、皆さんも求められているシステムエンジニアの解像度が上がること間違いなしです。
システムエンジニアは「顧客が抱える課題を解決する人」
いきなり結論からになりますが、システムエンジニアは、「顧客が抱える課題を解決する人」です。
いつの時代も絶えることのない悩み。それを解決できる人。かっこいいですね。
では、どうして読んで字のごとく「システム」を「開発する人（エンジニア）」ではないのでしょうか。
答えは、「システムを開発する」だけであればプログラマ（PG）にもできるからです。
例えば、とある顧客のECサイトのシステムを開発するとします。
その際、プログラマとシステムエンジニアに求められる仕事は以下のような違いがあります。
- プログラマ：システムエンジニアがつくった設計書を元に、「IDとパスワードを入力して認証後、ログインできる」「商品をカートに入れること購入でき、クレジットカードで決済する」等の処理や機能を開発し、テストを行う。
- システムエンジニア：顧客と会話をしながら「見やすさ・使いやすさが第一のシステムにしてほしい」「多少レスポンスが悪くてもセキュリティは万全にしてほしい」といった抱えている課題を洗い出し、設計への落とし込みを行う。その後、プログラマがつくった処理や機能で当初の課題が解決できているかを最終的に確認する。
どうでしょう？考えていたより、やるべき範囲が違うことに気付くでしょうか。
決定的な違いは、プログラマが処理や機能といったシステムの中核を開発する人なのに対し、システムエンジニアはそのシステムの開発に必要な情報を整理したり、出来上がったシステムの妥当性と課題が解決されるかを確認する人、というところになります。
実際問題として、これらを厳密に線引きをすることは難しいですが、システムエンジニアの本質が「顧客が抱える課題を解決する人」であることに変わりはありません。
ところで、実際のシステム開発現場では以下のような場面によく出くわします。
- 「上司先輩から言われたことをそのまま対応する」
- 「顧客の予算の都合上、止む無く対応が見送りになる」
もちろん、それが最適解であることもあります。しかし、それを鵜呑みにするのではなく一度立ち止まって考えてみてください。その判断は、本当に顧客の課題解決に繋がりますか？
年次を重ね、社会の荒波に揉まれると、思考停止になりがちです。それが楽だからです。
この記事を読んでいただいた皆さんには、「顧客が抱える課題を解決する」という本質を念頭に仕事に臨んでいただけると、本当の意味でのシステムエンジニアになれるはずです。
システムエンジニアは開発対象によって3種類に大別される
では、システムエンジニアの本質がわかったところで、どんな職種があるのかを見てみましょう。
一口にシステムエンジニアと言っても職種は多数ありますので、ここでは「開発対象が何か？」という視点で、3種類に分類してみました。
- インフラ系エンジニア
- アプリケーション系エンジニア
- Web系エンジニア
経験を積んでからキャリアパスを変更することも可能ですが、どれを目指すかを予め知っておくことで、自分が描く理想のシステムエンジニアに遠回りせずにたどり着くことできます。
新卒で就職した際、理想の自分像を少しでも具体的に描けていれば、もっと早く今の自分になれたのかな･･･と思うことがあります。
インフラ系エンジニア
1つ目はインフラ系エンジニア
です。
サーバやネットワーク等、現代のシステムに欠かせないインフラ（基盤）周りを構築する人たちのことで、縁の下の力持ちです。
地味なイメージを持たれがちな一方で、システムの根幹となるインフラを整備する仕事はなくてはならない存在と言えます。
「設定事が好き！」「物理的な媒体で作業することにやりがいを感じる！」といった方にオススメの職種です。
アプリケーション系エンジニア
2つ目はアプリケーション系エンジニア
です。
1つ目のインフラ系（ハードウェア）と対比してアプリケーション系（ソフトウェア）のエンジニアとも言え、パソコンだけでなくスマートフォンのアプリ開発等も行います。
「スマホアプリを開発したい！」「システムと言えばアプリケーションだ！」という方に向いています。
Web系エンジニア
3つ目はWeb系エンジニア
です。
2つ目のアプリケーション系と同じくソフトウェアを開発するところは類似していますが、Webシステムのクライアイント側（フロントエンド）やサーバ側（バックエンド）を開発する人たちのことを、特にWeb系エンジニアと言うこともあります。
「目に見えて触れてもらえる画面をつくりたい！」「データベースへのアクセスや性能に興味がある！」というような方にはもってこいの職種ですね。
以上が開発対象により分類した3種類のシステムエンジニアです。
他にも、近年話題となっているデータ分析により意思決定を補助するアナリティクスエンジニアや、AIの研究・適用を目指すAIエンジニアなどもあります。
これらも全て本質的にはシステムエンジニアですが、必要となる技術要素と開発スキルが異なってきますので、覚えておきましょう。
必要なスキル等は改めて別の機会に書くつもりです。
システムエンジニアの仕事領域
続いて、システムエンジニアの業務内容も見てみます。
一般的なウォーターフォール型（上から下へ水が流れるように作業工程が進んでいく開発手法）のシステム開発では、以下のような工程に沿って業務を行います。
- 要件定義
- 設計
- 開発
- テスト
- 運用・保守
なぜこれが一般的かというと、前工程の作業結果（アウトプット）が次工程の作業前提（インプット）になることが直感的にわかりやすい点や、計画が立てやすく管理もしやすい点です。
ウォーターフォールや工程の詳しい説明は他のサイトに多数ありますので、そこは省いて私なりの言葉で一つ一つの工程を詳しく説明していきます。
ここでは、工程（特に要件定義と設計）の説明をするために、具体例として顧客先に導入されている現行のWebアプリケーションの機能を変更をすることで、エンドユーザの満足度を向上させたいとします。
要件定義（システム化要件定義、非機能要件定義、etc…）
顧客と共に課題を洗い出し、システムとしてどのような機能を実現するか、会話しながら合意形成する工程のことです。
上流工程の中でも最上部に位置し、水の流れで言えば水栓にあたります。
「エンドユーザの満足を向上させたい」という要望に対し、現状はどうか？どのような機能が必要か？どのような前提・制約条件があるか？等をヒアリングしながら詰めることになります。
ここから出てくるものが間違っていると、以降の工程で作るものは全て間違ったまま進みます。超大事なところです。が、相対するのが人間で始まり人間で終わるので、超難しいところです。
少なくとも、コミュニケーション力は必須となります。
設計（基本設計、外部設計、内部設計、プログラミング設計、etc…）
要件定義で抽出された内容を、開発工程のインプットになるよう設計書として文字起こしをする工程です。
例えば、要件定義で「現行のシステムでは契約者の情報が各ページに散在しており、わかりづらいため一箇所に集約したい」という要望が抽出できたとして、その情報だけで開発していくのは並大抵のことではありません。
そのため、「このページには〇〇と□□の情報を集約する、データは△△というデータベースから取ってくる」といったように、よりシステマチックな文章にすることがこの工程の目的となります。
実際には設計工程も細分化されていたりしますが、いずれにせよ重要なのは誰が見ても開発する内容が一意になっている設計書を作成する工程であることです。
開発（コーディング、製造、etc…）
設計工程でアウトプットされる設計書を元にプログラミングを行い、処理を完成させモジュール化する（一塊の機能をつくる）工程です。
上記のとおり、主にプログラマの領域であることが多いです。が、設計書を読み解くには記載内容が曖昧だったり、反対に難解だったり、なんなら欠落していたりするので、システムエンジニアはそのヘルプに対応する必要があります。
極論、設計が完璧であればそういったやり取りも不要になりそうですが、そんなシステム、そんな設計書には出会うことはまずないでしょう。
そのため、プログラミング能力はともかく、意外とコミュニケーション力も求められます。
経験が浅いうちは、プログラマとしてコーディングすることが多いです。
コーディングしながら「設計書ってこう書くんだー」とか、打ち合わせを見ながら「顧客の〇〇さんはこういう人なんだー」とか、思いを巡らすのです。
テスト（単体テスト、結合テスト、システムテスト、etc…）
開発が完了したから、いざ納品だ！･･･というわけにはいきません。
人間が開発したものなので、バグ（予期しない動きをすること、欠陥）が混入しています。
処理の期待結果を考え、そのとおりに動くかを検証し、動かなかった場合に解消するのがテスト工程です。
ここでシステムエンジニアに要求されるのは、システムが要件定義どおりに動くかどうかです。
ありがちなのは、「これは普通に考えてこう動くだろう」と思い込む（確証バイアスが働く）ことによって、本来検出すべきバグが見つからないことです。
開発担当者は、何か問題が起こったときに、設計や実装内容に関心をもちます。しかし、自分がつくったものは正しいはずという「確証バイアス」が働くため、設計や実装のミスを見つけにくい傾向があります。
引用：ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説
そのため、開発担当者がテストも担当する場合、自らの確証バイアスをとり除いてテストしなければなりません。
システム開発のテスト工程に限らず、普段の生活の中でも先入観が誤った結果を導出しかねないことには、注意が必要ですね。
システムの品質をどこで担保するのか？という議論は絶えませんが、私はテストだと考えています。
なぜなら、設計や開発工程で誤った記載やプログラミングをゼロにするのは現実的ではないためです。そんなことできたら、誰も苦労しないですよね。
但し、テストありきで前工程を蔑ろにし、テストこそ全能である！みたいな考え方は、リスクが大きいのですべきではありません。
正確な設計と開発、抜け漏れの無いテスト、この塩梅を決めるがシステムエンジニアの腕の見せ所なのです。
運用・保守
完成したシステムを顧客に納品・リリースして終わりではなく、本番稼働した後の緊急改修や追加で機能改修したいという要望が出たりします。
これらをシステム開発の一環として対応していくことになるのが、運用・保守工程です。
要件定義からテストまでの期間感と比べて、運用・保守工程は長くなりがちです。
そのため、保守対応をする傍らでシステムエンジニアは顧客の業務理解だけでなく、顧客との信頼関係をより一層深めておくと、今後の役に立ちます。
以上が工程の説明となります。
改めてまとめると、一般的なシステム開発の流れは以下のとおりになります。
- 要件定義（何を作りたいかを顧客と定義）
- 設計（どうやって・どのようにシステムを作るかを設計）
- 開発（設計に従ってシステムを開発）
- テスト（開発したシステムが正しく動くか確認）
- 運用・保守（システムの運用と保守）
さて、ここまで見てくださった中で勘が良い方は気づいているかと思います。
そう、あらゆる工程において、システムエンジニアにはコミュニケーション力が必須です。
言い換えれば、コミュニケーション力がない人はシステムエンジニアには向いていません。そのくらいはっきりと言える部分です。
しかし、落胆する必要はありません。コミュニケーション力は天性の才能ではなく、いくらでも伸ばすことが可能です。
仕事の中で伸ばすも良し、日々の生活の中で意識するも良し、鍛錬を怠らないでいきましょう！
この仕事に携わる前は絶望的な人見知りでしたが、今では初対面の方とも普通に話すことができます。そんな私がどうやって人見知りを克服したのか？
それは当時の先輩が私を顧客打ち合わせに毎回連れていき、人見知りしてる場合じゃないくらい話をさせる教育をしたからです。今となってはいい思い出ですね･･･。
まとめ
システムエンジニアの本質は、顧客が抱える課題を解決することです。プログラミングをしてシステムを開発するだけが仕事の本質ではありません。
そんなシステムエンジニアの職種は「インフラ系エンジニア」「アプリケーション系エンジニア」「Web系エンジニア」の3つに大別することができます。
本質的には全てシステムエンジニアではありますが、異なる技術要素とスキルが必要になってきます。
いずれの職種も実際の業務内容は多岐に渡りますが、どの工程でもコミュニケーション力は必須と言えるでしょう。
システムエンジニアを目指す人は、技術力だけに目が行きがちですが、コミュニケーション力も鍛えていくことをオススメします。
コメント