アプリSEの仕事内容というと、「システムを設計する人」「プログラマーをまとめる人」といったイメージを持つ人もいるかもしれません。
私もアプリSEとして仕事をしていましたが、実際に担当していた範囲はかなり広く、設計や管理だけをしていたわけではありませんでした。
顧客の要望を確認し、基本設計・詳細設計を行い、自分で実装することもありました。その後にはテスト、本番作業、障害対応、レビュー、引き継ぎなどもあります。
また、仕事内容は案件によって同じではありません。
少人数の案件では自分自身も開発担当に入ることが多い一方、大人数の案件では、設計や管理、関係者との調整が中心になりました。
この記事では、私がアプリSEとして実際に経験した仕事と、案件規模によって役割がどのように変わったのかを紹介します。
厚生労働省の職業情報提供サイト「job tag」でも、システムエンジニア（受託開発）の仕事として、顧客へのヒアリング、要件定義、設計、開発工程の管理、テスト、導入後の保守・管理など幅広い業務が紹介されています。また、大規模なシステム開発では複数のSEで分担し、中規模・小規模では一人のSEが担当する場合も多いと説明されています。
厚生労働省 job tag「システムエンジニア（受託開発）」
顧客の要望を確認して、何を作るのか具体化する
システム開発では、最初から顧客の要望が具体的な仕様になっているとは限りません。
私も顧客と話しながら、現在のシステムを確認し、どこが使いにくいのか、何を変更したいのかを詰めていました。
必要に応じて既存資料を確認したり、PowerPointで現行と変更後を比較したり、Webブラウザで見られる程度のモックを作ったりすることもありました。
この部分については、SEは顧客の曖昧な要望をどう詰める？現行確認とモックを使った実務経験で詳しく紹介しています。
基本設計と詳細設計を行う
顧客との認識が固まってくると、基本設計や詳細設計を行います。
私が経験した基本設計では、顧客が読んでも理解できる表現を意識し、業務フローなども含めて整理していました。
詳細設計では、実際に実装できるよう、内部的な情報や設定まで具体化していきます。
私自身の感覚では、作業量は詳細設計の方が多くなりやすい一方、難しさを感じるのは基本設計でした。
基本設計と詳細設計については、基本設計と詳細設計の違いとは？元アプリSEが実務経験から解説で詳しく紹介しています。
アプリSEでも自分で実装することがあった
私は設計や管理だけでなく、自分で実装することもありました。
特に、周囲の処理まで理解していないと作りにくい箇所は、自分で開発を担当することがありました。
その中で大変だったものの一つが、エラーハンドリングをまとめる部分です。
正常に処理された場合だけでなく、どこでエラーが発生しても、
- エラーを検知する
- 必要な通報を行う
- エラー内容をメールで通知する
- 問題が起きた部分を切り離す
- 他の処理まで止めないようにする
といったことを考えていました。
このような処理では、エラーが発生した箇所だけを見ればよいわけではありません。
切り離したときに他の処理がどう動くのか、どこまで影響するのかまで把握する必要がありました。
そのため私には、正常系の処理を作るより、周囲への影響まで考えながらエラー時の動きをまとめる部分の方が難しいと感じることもありました。
実装後はテストで動作を確認する
実装後には、単体テスト、結合テスト、総合テストなどを行いました。
単体テストでは一つの動作を一つのテスト項目として分け、結合テストでは他システムとの接続、総合テストではシステム全体の動きを確認していました。
それぞれで注意する内容も異なります。
私は特に、結合テストでは接続先が本番機になっていないかを確認し、総合テストでは本番相当のデータを使う場合にもマスキングを行うなど、工程に応じて確認する内容を変えていました。
単体テスト仕様書については、単体テスト仕様書の書き方で意識したことで紹介しています。
結合テストについては、結合テストで気をつけていたことで詳しく紹介しています。
本番稼働後まで関わることがあった
テストが終われば、本番環境へのリリースや本番作業があります。
私は本番作業の前にチェックリストを用意し、可能な範囲で検証環境を使って事前確認していました。
本番作業については、本番作業でミスを減らすために意識していたことで詳しく紹介しています。
そして、本番稼働した後に障害が起これば、その対応も仕事になります。
私が初めて障害対応をしたときはかなり緊張しました。
復旧した後には、原因を調べ、再発防止を考え、修正箇所と同じような作りになっている場所が他にないか確認することもありました。
障害対応については、システム障害対応は復旧で終わらないで詳しく紹介しています。
案件規模によって実装・設計・管理の比重が変わった
私の経験では、アプリSEの仕事内容は案件規模によってかなり変わりました。
少人数案件では自分も開発担当に入ることが多かった
少人数の案件では、私自身も開発担当に入ることが多くありました。
設計だけを担当するのではなく、自分で実装し、その後のテストまで担当する形です。
担当範囲が広いため、自分で手を動かす時間も多くなりました。
大人数案件では管理や調整が中心になった
一方、大人数の案件では、自分で実装するよりも、設計や管理の比重がかなり高くなりました。
WBSを使って各メンバーの進捗を確認し、遅延や仕様変更があれば、その内容に合わせて各メンバーの予定やWBSを変更することもありました。
実装担当者から不明点や質問が出れば対応し、作成された内容について確認や指摘も行います。
さらに、自社メンバーだけでなく、関係会社の進捗も確認する必要がありました。
人数が多くなると、管理だけでもかなりの時間を使うため、自分自身が実装まで担当する余裕はほとんどありませんでした。
特にきつかったのは遅延が他の会社まで影響することだった
大人数案件の管理で、私が特にきついと感じたのは遅延時の調整です。
自分の担当範囲だけで完結する問題であれば、自分たちの予定を調整すれば済む場合もあります。
しかし、複数の会社やチームが関係していると、一つの遅延が別の担当箇所にも影響します。
遅延が発生すると、関係会社と状況を確認し、どこまで影響するのかを整理したうえで、自分たちのWBSも見直す必要があります。
経験が浅い頃は、この影響範囲の広がりが精神的にもかなりきつく感じられました。
ただ、こうした調整を何度も経験するうちに、少しずつ慣れていきました。
私自身は、大人数案件になるほど、技術力だけでなく、対人調整や進捗管理の力が必要になると感じていました。
レビューや引き継ぎなど、人の作業を見る仕事もあった
経験を重ねるにつれて、自分で成果物を作るだけでなく、人が作ったものを見る仕事も増えました。
新人の頃は私自身がレビューで指摘される側でしたが、その後は後輩の成果物を確認する側になることもありました。
レビューについては、SEのレビューでは何を見られる？で詳しく紹介しています。
引き継ぎでは、資料を作って説明するだけでなく、後任に実際の作業をしてもらい、私は後ろから確認する形を取ることもありました。
引き継ぎについては、SEの引き継ぎで意識していたことで詳しく紹介しています。
まとめ：アプリSEは案件規模によって仕事内容の比重が変わった
私がアプリSEとして経験した仕事は、設計だけでも、プログラミングだけでもありませんでした。
顧客との要望確認から、設計、実装、テスト、本番作業、障害対応まで関わり、レビューや引き継ぎを担当することもありました。
特に大きかったのが、案件規模による違いです。
少人数案件では自分自身も開発担当として手を動かすことが多い一方、大人数案件では設計やWBSによる進捗管理、質問対応、関係会社との調整などが中心になりました。
私の場合、案件が大きくなるほど、技術だけでなく対人スキルや調整力を求められる場面が増えていきました。
すべてのアプリSEが同じ働き方をするわけではありませんが、仕事内容を一つに決めつけるより、案件の規模や体制、立場によって担当範囲や仕事の比重が変わる職種として見る方が、実際の仕事をイメージしやすいと思います。
