ベテランエンジニアが語り尽くす 開発エンジニアの仕事内容と将来性

今回から新企画がスタートします！

その名もズバリ「ALH's Job Discription（エーエルエイチズ ジョブディスクリプション)」
最前線で活躍中のエンジニアに、ご自身が担当している職種の面白味や大変さなどを臨場感たっぷりに語っていただきます。

記念すべき第一回のテーマは「開発エンジニア」です。

エンジニアの仕事が気になっている業界未経験の方から、技術領域の幅を広げたい方まで、多くの方の参考になったら嬉しいです。

お話を伺った人

TATSURO
2000年にプログラマー（以下PG）としてIT業界に転職、クライアント先に常駐する形で開発案件に参画。2006年に当時の代表畠山の誘いでALHの前身会社に入社。

システム部立ち上げや面接官、営業同行、Pマーク取得、ISMS取得、受託開発・社内開発、新人研修など幅広く経験し、2011年より主にクライアント相手にシステム開発案件を担当している。

現在のお仕事

職種：割合順にプロジェクトマネージャー（以下PM）、システムエンジニア（以下SE）、PG
業務内容：割合順に要件定義/タスク管理/設計/コーディング/ベンダーコントロール

Salesforce（営業支援ツール）の運用支援や各種システムの開発・導入、顧客開拓や社員研修プランの設置、新規事業を企画する際のアドバイスなど多岐にわたる。

では早速、詳しい内容に入っていきましょう。

開発エンジニアについて知る

まず、開発エンジニアについて簡単に説明しておきますね。

開発エンジニアとは

開発エンジニアは主にコンピューターソフトウェアやアプリケーションの設計、開発、およびメンテナンスに関わる専門家を指します。

活躍できるフィールド

主にBtoBとBtoC２つに分類できます。

BtoB：顧客ベース。クライアントと長く付き合いながら新たな価値を創成していく。

toBではクライアントが本当に実現したい目的が何であるかを追求することが重要です。
相手の要望やこだわりを的確に言語化して引き出すことが求められます。

BtoC：市場ベース。企画から関わる機会が増える。ユーザーの声をダイレクトに聞ける。

toCの場合は自分たちのこだわりを優先するのか、ユーザーの声を取り入れることを優先するか、いずれの方針もあり得ます。

基本的にはこだわりを優先し、ユーザーの声は参考程度にとどめることをおすすめします。
ユーザーの声は玉石混淆ですから、まとまりが無くて当然であり、八方美人な対応がプラスに働く可能性は低いです。

俯瞰的に見て、何がユーザーにとって最適なのかを見極めることが大切です。

開発エンジニアの仕事内容（担当領域）

続いて、皆さんがよく耳にするであろう「上流工程」「下流工程」をふまえて、担当領域について紹介していきます。

＜上流工程＞

工程1：要求定義（情報収集）   

仕事内容：お客様にヒアリングを実施して、この度の依頼に至った背景を把握する。

「何のために」「誰のために」はプロジェクトのコンセプトであり最も重要です。迷ったときの指針になります。

後述しますが、クライアントが自分たちの課題や要望を正しく言語化できていないケースも多いので、技術的知識のある立場として整理しながら聞き出すことが重要です。

工程2：要件定義（情報整理）

仕事内容：ヒアリング内容を分解して目的と目標を見極め、全体計画を立てる。

クライアントの「これを作ってほしい」といった要望を、きちんと咀嚼せずに言葉通りに受け取ってしまうと危険です。

窓口になっている担当者の思い込みや主観ではないか、当初のコンセプトから外れていないかなどを意識しながら、情報を整理します。

工程3：論理設計（外部設計）

仕事内容：クライアントが成果物を想像できる形式で設計書を書く。

この段階の設計書は基本的にはクライアントのための資料です。

クライアントのリテラシーを踏まえて書くものですし、用語集もあった方がよいです。

同じモノ・コトを指すのに人によって呼び方が違うことがよくあり、誤解の元になるので言葉を統一して書く丁寧な仕事を求められます。

工程4：物理設計（内部設計）

仕事内容：開発チームがシステム構築を実現するための具体的な設計書を書く。

内部向け設計書であるため、そのままコーディングに使えるレベルで記載します。

しかし、プログラムと同レベルの精度まで細かく記載する必要はありません。それを書く時間があればコーディングに着手すべきでしょう。

また、粒度が細かいほどメンテナンス工数が増えることにも注意が必要です。

最低でもDB定義書はもちろん、PGが複数いる場合はコーディング規約（エンジニアやプログラマーが複数人で同一のタスクやプロジェクトを行う際に、ソースコードについて定めたルールのこと）を用意した方がよいでしょう。

＜下流工程＞

工程5：実装・単体テスト       

仕事内容：システムを動かすプログラムをコーディングする。

コーディング規約を厳守し、コードレビューで厳密にチェックします。

限界まで短縮したコードを自己満足で書くべきではありません。

自分が途中まで書いたコードを他の方が引き継いだり、一度書き上げたものを他の方が修正したりすることがよくあります。ですので、誰でも続きが書けるような状態にしておくことを心がけましょう。

開発メンバーは1人かもしれないし100人の分担かもしれません。ソースコードはGitなどのバージョン管理ソフトでマージします。バージョン管理を使わない新規のプロジェクトは今や存在しないといってよいでしょう。うっかり同じ場所を直してしまうと衝突（コンフリクト）が発生します。この場合はどちらかが目視で修正し、再度マージ作業を行います。

狙い通りの動きをするかどうか、この段階で細かく確認をしないと次に進めません。

工程6：結合テスト・システムテスト   

仕事内容：実際の運用に耐えられる品質かどうかテストする。モジュール同士の結合をテストし、続いてシステムテストではクライアントの業務が滞りなくできることを確認する。

「何を確認したいのか」「どういう手順で」「何をもってOKとみなすか」を意識してテスト項目を作ります。

どうせ大丈夫だろうという姿勢でテストをしてはいけません。

「絶対にバグを見つけてやる」「粗探しをしてやる」という強い気持ちで臨みます。

単体テストがホワイトボックステスト（内部設計通りに作っているか）なら、結合テストはブラックボックステスト（外部設計通りに作っているか）です。結合テストとシステムテストは作った本人以外で実施します。

工程7：リリース・教育     

仕事内容：システムをユーザーに公開し、場合によっては利用方法をレクチャーする。

ついに公開の時です。指差し確認をしながら行うくらいが丁度よいです。失敗したときの切り戻し手順も準備しておきましょう。

その後はクライアントに使用方法や注意事項をレクチャーしていきます。

マニュアルが必要になるかどうかはクライアント次第です。コストカットのために自分たちで作るところも多いです。

要件定義では"やること"だけでなく"やらないこと“を記載すべきですが、マニュアルを作るか否かについても明記しておかないともめる原因になります。
相手によっては「当然作ってもらえるものだと思っていた」などのように余計なトラブルに発展することもあるので、要件定義の段階ですり合わせしておきましょう。

ちなみに、残念ながらエンドユーザーはあまりマニュアルを読んでくれないので、管理者向けのマニュアルを充実させるほうがよいこともあります。

工程8：運用保守 

仕事内容：業務が止まらないようシステムを監視・メンテナンスする。

本工程は行わないこともあります。あるいは年に一回、もしくはマスターデータの差し替えなど時々やるだけのことも。

今はオンプレ（サーバー機器などのハードウェアを施設内に設置して運用する）からクラウドになりログも勝手に取得して、何かあれば知らせてくれるので必要性がさがってきたとも言えます。

現に私も運用保守を自動化するRPAなどを使っている案件を多数経験しています。しかし、すべてを自動化することはできないし、そもそも自動化の設定をするのは人間です。

コントロールする人のニーズはなくなりません。

ここまで上流と下流をわけて説明しましたが、小規模案件であればフルスタックエンジニア１人で十分なこともあります。

開発エンジニアに必要な４つの適性

続いて、開発エンジニアに必要だと思われる４つの適性について、私の独断と偏見をもとにお伝えします。

割り切れる（最初から100点を目指さない）

時間や予算が決まっているので、こだわりすぎてはいけません。

mustの部分を確実に死守して、wantの部分は妥協というか、「第二フェーズでやりましょう」と提案するなど、割り切る姿勢が必要です。

行動できる（口より手を動かして形にできる）

いわゆるDoPDCAですね。まずやってみてから計画する。

Pの後のDoは目標に到達するためのDoですが、最初のDoはＰのため、計画のためのDoです。まずやってみる、行動してみる姿勢が重要です。

手を動かしてみないとその先が見えてきませんから。

整理できる（事実と意見を区別できる）

クライアントの話を何でもかんでも真に受けないことです。

担当者一個人の意見なのか、会社としての結論なのか不明瞭なことも多いです。

言われたことをそのまま鵜呑みにしてしまうと作っても使わない・使えないという事態が起きます。

よくあるのはクライアントが使用するシステム内の承認フローですね。二次承認まで必須にしたいと担当者は言うけれど、二次承認者クラスの方は100人規模の組織を管掌していることもあります。

承認必須にすると承認作業に要する工数が膨らみすぎてしまいますよね。承認者の業務量を鑑みたうえでフロー設計するなど、要求定義で必ず握りましょう。

柔軟である（変化や変更に対応できる）

最初に決めた計画通りに進まないこと、一旦戻って作業をやり直すこともあります。メンバーやリーダーが変わることもありえます。

そのため変化に対応できる柔軟性が必要です。

開発エンジニアの仕事を通して身につくスキル

この仕事を通して身につくスキルの一例を紹介していきます。

開発スキル・業界知識・業務知識

当然のことながら、技術的なスキルや業界知識、業務に関する知識はおのずと身についていきます。

コミュニケーションスキル  

聴く、話す、交渉するといった一般的なコミュニケーションスキルです。

下流の場合は「聴く」ばかりになると思われがちですが、理解したことを「話す」、疑問点を「尋ねる」、リスケを「交渉する」など多くのコミュニケーション力を伸ばす機会があります。

要約力（ロジカルシンキング）  

クライアントがあらかじめ整理して話してくれるとは限りません。

むしろ、うまく整理できていないケースの方が多いです。

言われたことをそのままメモするのではなく、自分の言葉で置き換えて「つまりこういう意味で認識合っておりますか？」と言語化する習慣をつけましょう。

経験上「そうそう、そういうことです」と反応が返ってくれば手ごたえありとみています。

調査力

ルーチンワークな作業でもない限り、エンジニアは文字通り「日々」分からない用語との戦いです。時間は有限なので、調査にばかり時間を割くわけにはいきません。

どこで区切りをつけるか見極める必要があります。
自分で一通り調査をしても解決できない場合は、素直に上司か先輩社員などに尋ねてみましょう。

丸一日調べたけどよく分かりませんでした、代案も特にありません、というのが最悪な結果です。

開発エンジニアのキャリアパス

まず、そもそも上流と下流について少しお話します。

上流職を目指すも下流職を極めるもよし。

上流を目指すことが正解とは限りません。

下流をおろそかにした状態で上流を目指しても、周囲から見抜かれます。一人で10人分の働きをする達人プログラマーみたいな人もいるので、そういった人材は大変重宝されますよ。

下流から上流を目指すのはよくあるケースですが、実は上流から下流もあります。これは力不足を感じて出戻るケースや、自分には上流の水は合わないと感じたケースなどです。

そもそもこの二つはつながっているので、働いている立場からするとそこまでわける感覚もないんですよね。自分がどこを深く突き詰めたいかだけです。

海外ではプログラマが要件定義をすることもありますしね。

それではここからはいくつかの具体的なキャリアパスをご紹介します。

開発SE→PM

プロジェクト全体を総括するマネジメントポジションの仕事で、バランス感覚が重要になってきます。

予算やスケジュールの管理、さらにはメンバーのモチベーション管理などあらゆる面でのマネジメント業務を担います。

なお、プロジェクトの実行に対して責任を負うプロジェクトリーダー（以下PL）という役割もありますが、どちらも自薦より他薦の傾向が強いと言ってよいでしょう。

PM／PLを目指すならクライアントの信頼を得ることが重要です。

実績も信頼もない人に任せるのはクライアントとしても不安になりますよね。
信頼を獲得し、一度でもPM／PLを経験しスキルシートに記載できるようになると、その後もPM／PLポジションの仕事を任せてもらいやすくなります。

開発SE→エデュケーション

ある程度経験を積むことで、人に教えるという道も開けてきます。

社内で新入社員向けの研修講師を務めたり、スキル次第では経験者向けの指導を担当したり、さらには外部でスクール講師などを請け負うケースもあります。

ちなみにALHでは、多様なキャリアを提供するために「おかえり人事制度」という制度を設けています。

これは、今いる部署に戻れる前提で、一定期間違う部署での業務を経験できる制度です。この制度を利用し新入社員向けの研修コーチを経験する社員が多いです。

教える立場を経験することで、いずれPLやPMになった時にメンバーを率いていくうえでも役に立つ知見を多く得られます。

開発SE→クラウド（AWS・Azureなど）

クラウドの知識を深めることで、一人でプログラムを作って環境構築→リリースまで一貫して担当できるフルスタックエンジニアです。

こちらもおかえり人事制度を利用し、開発事業部の社員が一定期間インフラ事業部で研鑽を積んで、フルスタックエンジニアへの道を開くことができます。

このような制度でもない限り、インフラ未経験の開発エンジニアがいきなりインフラ案件に参画することは難しいので、育成に適した良い制度だと思いますね。

開発エンジニアの働き方

個人の事情やキャリア志向にあわせた多様な働き方ができるのも、開発エンジニアの魅力の一つです。

受託開発企業で働く（ALHはこれに該当）

システム開発を請け負う企業に所属して、開発エンジニアとして働く方法です。

業界問わず、さまざまな案件を担当することができるため、幅広い開発経験を積みたい人におすすめです。

自社開発企業で働く

自社サービスの開発を担当するエンジニアとして働く方法です。

その会社のサービスに愛着のある方や、同じ職場で働き続けたい方におすすめです。

フリーランスで働く場合

受託開発企業や自社開発企業で経験を積んでから独立し、フリーランスとして働いていく方法です。高いスキルや経験が必要とされますが、人によっては会社員時代より年収をアップさせることが可能です。時間や場所に囚われず自由に働くことも可能です。

開発エンジニアに求められる姿勢

少々説教臭い内容も含まれますが、私なりにエンジニアに必要だと思われる姿勢についてまとめてみました。

自らタスクを取りに行く

何をすればプロジェクトに貢献できるか考えつつ自らタスクを取りに行く姿勢が必要です。
指示がこないドタバタした状況もしばしば起こりますが、そんなときはプロジェクトの目的を思い返します。

そうすれば、やるべきことは自ずと見えてきます。

綺麗な足跡を残す

自分が現場を去ってもクライアントとの関係は続いていくことを忘れてはいけません。同僚がバトンタッチで引き継ぐかもしれません。

綺麗な足跡を残すのか、後始末をしてもらうのか、すべて今の立ち振る舞いにかかっていると思って業務にあたる姿勢が大切です。

未経験者は最新情報に惑わされずに軸を固める

未経験者の場合はトレンドのキャッチアップに振り回されず、軸となるスキルセットを身に着けることに集中した方がよいでしょう。

新しい技術が出てきても自分の中に比較対象がなければ何が素晴らしいのか分かりませんから。

ニュースサイトは絞る

情報を収集する段階になったら、ニュースサイトなどは絞ったほうが良いと思います。お気に入りのものを見つけてブックマークするとよいでしょう。

ALHでは注目のニュースが出ると社内SNSで共有されるので、はじめのうちはそれを見ておけば大丈夫です。

ネットニュースやインフルエンサーに惑わされない

ネットではよく、〇〇はオワコンなどの過激なタイトルの批評記事がでますが、鵜呑みにせず話半分に聞いておくリテラシーを持つことも大事です。

エンジニア界隈にもインフルエンサーは多数いますが、彼らの意見はあくまでも一意見です。

技術書籍は消耗品

技術書籍は消耗品ととらえましょう。数年たつと時代遅れになってしまいます。

紙の書籍は持ち運べないので、電子書籍がおすすめです。よほど専門外でもなければ入門編とかは買う必要がないと考えています。ググれば十分かと。私は辞典のようにリファレンス的な書籍を揃えることが多いです。

この仕事のやりがい

自分たちがつくったモノが形になっていく過程は純粋に面白いですよ。

ただ、完成したシステムやサービスにいつまでも愛着があって誇らしく感じる人もいるでしょう。

私の場合飽き性なので、作り上げる過程は好きですが、完成後は余韻に浸るより早く次の作品作りに移行したくなってしまうタイプです。

昔携わったアプリのポスターが駅に貼られているのを見かけると「サービスが続いているなら一定の評価は得られているようだな」とは思いますが、正直今ならもっと良いものが作れたかもと考えてしまいますね。

こればっかりは感じ方は人それぞれですので、自分たちが作り上げたサービスに愛着を持ち続けるのも素晴らしいことだと思います。

第一弾はシステム開発に関する業務に20年以上携わってこられたTATSUROさんにお話しいただきました。

ご自身の経験や主観に基づく内容も多分に含まれていますが、だからこそ、臨場感のある生々しい内容をお届けすることができたのではないでしょうか。

引き続き「ALH's Job Discription」では、中堅～ベテランエンジニアの方々に、ご自身の職業の魅力や面白味、大変なことまで思うままに語っていただきます。

次回もお楽しみに！