システム開発には、アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、データベースなど、異なる専門性を持つエンジニアが関わります。
本記事では、その中からアプリケーションエンジニアを取り上げます。
アプリケーションエンジニアは、業務とシステムの間に立ち、曖昧な要望を、誰が実装しても同じ結果になる仕様へ変換する役割を担います。
利用者の業務をどのようにシステムの機能へ落とし込み、設計、プログラミング、テスト、障害対応のどこまでを担当するのかを、SIerにおける開発の実態を踏まえて説明します。
筆者はSIerでアプリケーション開発とアプリケーション基盤を担当し、その後もシステム基盤・データベース側からアプリケーションチームと協働してきました。その経験をもとに、アプリケーションエンジニアの仕事を整理します。
SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。
アプリケーションエンジニアとは
アプリケーションエンジニアは、利用者の業務をシステムの機能として実現する役割を担います。
そのためには、画面や帳票を作るだけでは足りません。顧客がどのような業務を行い、何を判断し、どのようなルールで処理しているのかを理解したうえで、システムで実現できる仕様へ落とし込みます。
銀行の融資審査システムであれば、申込受付、本人確認、信用情報照会、審査、承認、契約といった業務の流れを理解しなければ設計できません。
会計システムでは、勘定科目、仕訳、締め処理、決算処理などの知識が必要です。公共分野では、法律や制度の内容がそのままシステムの判定条件や処理期限へ影響します。
アプリケーションエンジニアには、技術だけでなく、対象となる業務を理解する力が求められます。
主な担当領域
アプリケーションエンジニアの仕事は、大きく次のように分けられます。
業務要件と仕様の整理
- 利用部門へのヒアリング
- 現行業務と業務ルールの整理
- 機能要件の具体化
- 業務フローやユースケースの作成
- 他システムとの責任分界の整理
アプリケーション設計
- 画面、帳票、バッチ、APIの設計
- 入力チェックや業務判定の設計
- エラー処理と再実行方式の設計
- データベースへ登録する情報の整理
- 外部システムとのインターフェース設計
開発とテスト
- プログラム開発
- 単体テスト
- 結合テスト
- テストデータの作成
- 不具合の修正
移行と稼働準備
- データ移行や初期データ登録への対応
- 本番切り替え手順の確認
- 運用手順や利用部門向け資料の作成
- リリース後の動作確認
運用と障害対応
- 障害原因の調査
- 問い合わせへの対応
- 性能問題の切り分け
- 業務変更に伴う機能改修
- 他チームとの仕様調整
アプリケーションエンジニアは、要件を聞いて設計書を作るだけの担当者でも、プログラムを書くことだけに専念する担当者でもありません。
業務上の要望を実装可能な仕様へ変換し、実際に動くことを確認し、稼働後も業務で使い続けられる状態を支えます。
要望をそのままプログラムにはできない
利用部門から示される要望は、最初からシステム仕様として整理されているとは限りません。
たとえば、利用者から次のように言われたとします。
「申請金額が大きい場合は、上司の承認を必要にしたい」
この一文だけでは、プログラムを作れません。
金額がいくら以上なら承認が必要なのか。上司とは直属の上司なのか、所属部署の管理者なのか。代理承認は認めるのか。承認者が不在の場合はどうするのか。申請後に金額が変更された場合、承認を取り直すのか。
承認が却下された場合の状態、申請者への通知方法、承認期限を過ぎた場合の扱い、監査ログへ残す情報も決める必要があります。
アプリケーションエンジニアは、こうした曖昧な部分を利用部門へ確認し、条件、処理、データ、例外を具体化します。
要望を聞き取るだけでは足りません。実際の業務で起こり得るケースを洗い出し、システムが判断できる形まで分解することが設計です。
誰が実装しても同じ結果になる状態まで仕様を具体化して、初めて後続工程へ引き渡せます。
仕様が確定しないまま、リリース日が近づくこともある
公共分野や税・社会保険に関わるシステムでは、法律や制度の改正内容が、そのままシステムの判定条件や計算ロジックになります。厄介なのは、その改正がいつ、どのような内容で確定するのかを、システム側では制御できないことです。
2011年度の税制改正では、国会審議が難航し、施行時期が迫っても法案が成立するかどうか分からない状態が続きました。私が関わっていたシステムでは、改正が成立した場合と成立しなかった場合の2種類のアプリケーションをあらかじめ開発・テストし、どちらでもリリースできる体制を確保したうえで、国会中継を確認しながら待機したことがあります。
こうした状況では、「正しい仕様を一つ決めてから作る」という前提が成り立ちません。複数のシナリオで設計、開発、テストを並行して進め、確定した時点でどちらを本番へ適用するのかを判断し、切り替え手順と当日の体制まで準備しておく必要があります。
仕様の前提が業務や制度とともに動くことを織り込んで計画できるかどうかに、アプリケーションエンジニアの経験が表れます。
設計は画面の見た目を決める作業ではない
アプリケーション設計というと、画面のレイアウトやボタンの配置を決める仕事を想像する人もいます。
画面設計は担当領域の一部です。入力された情報をどのように検証し、どの処理を呼び出し、どのデータを更新し、結果をどこへ返すのかまで考えます。
画面から登録ボタンを押す処理だけでも、次のような設計が必要です。
- 必須項目が入力されているか
- 数値や日付の形式が正しいか
- 利用者に更新権限があるか
- 同じデータがすでに登録されていないか
- 別の利用者が先に更新していないか
- データベースへの登録に失敗した場合はどうするか
- 外部システムとの連携に失敗した場合はどうするか
- 途中まで更新したデータを元へ戻すか
- 利用者へどのようなメッセージを表示するか
- 操作履歴をどこへ記録するか
正常に処理できる場合だけを考えても、業務システムとしては成立しません。
入力ミス、二重実行、通信障害、データベース障害、外部システムの停止などを前提に、処理をどこまで進め、どの状態で止め、どのように再開するのかまで設計します。
画面、帳票、バッチ、APIでは設計の観点が異なる
アプリケーションには、利用者が操作する画面だけでなく、帳票、バッチ、APIなど複数の処理方式があります。
画面では、利用者が入力した内容をその場で確認し、分かりやすいメッセージを返す必要があります。応答時間が長ければ、利用者が再度ボタンを押し、二重登録を引き起こすこともあります。
帳票では、表示項目やレイアウトだけでなく、どの時点のデータを出力するのか、複数ページにまたがる場合に見出しをどう扱うのか、再出力を認めるのかを決めます。
バッチ処理では、処理件数、実行時間帯、先行ジョブとの関係、途中で失敗した場合の再実行単位が重要です。10万件中9万件まで処理した状態で障害が起きたとき、最初からやり直すのか、未処理分から再開するのかを設計します。
APIでは、相手システムへ渡す項目、文字コード、認証方法、タイムアウト、再送、重複受付、エラーコードなどを決めます。送信元では成功と判断していても、受信先では処理に失敗している場合もあります。
処理方式が変われば、設計上の論点も変わります。アプリケーションエンジニアは、それぞれの特性を理解したうえで仕様を組み立てます。
データモデリングにも関わる
業務で扱う情報を整理し、どのようなデータをどの単位で管理するのかを決める作業を、データモデリングと呼びます。
概念モデルや論理モデルは、業務を理解しているアプリケーション側が中心となって作成することが多い領域です。
顧客、契約、申請、承認、請求といった業務上の概念を整理し、それぞれがどのような関係にあるのかを明確にします。
たとえば、契約に複数の申請がひもづくのか、一つの申請から複数の契約が作られる可能性があるのかによって、必要なデータ構造は変わります。
データ構造は、後から変更すると影響が広がります。SQL、画面、バッチ、API、帳票、データ移行、テストまで修正が必要になる場合があります。
アプリケーションエンジニアは、現在の業務だけでなく、将来の機能追加やデータ増加も見据えてデータを整理します。
データベースエンジニアとも連携し、正規化、主キーや外部キー、インデックス、検索や更新の特性、データ量などの観点からレビューを受け、物理設計へつなげます。
DBAが物理設計やレビューでどのように関わるかは、次の記事で解説しています。
プログラミングは重要だが、仕事の一部である
アプリケーションエンジニアにとって、プログラミングは重要な技術です。
自分でコードを書ければ、設計した処理が実装可能なのかを判断しやすくなります。開発者から示された実装上の課題も理解でき、障害が発生したときにはソースコードを追って原因を調査できます。
プログラミングを知らずに、実装を意識した設計を行うのは困難です。
一方、プログラムを書けるだけで、業務システムを設計できるとは限りません。
利用部門の要望を整理し、業務ルールの矛盾や不足を見つけ、他システムとの境界を決め、異常時の処理まで含めて仕様化する力が必要です。
実装工程では、協力会社への委託に加え、AIによるコード生成の利用も進んでいます。ただし、生成されたコードが業務要件を満たしているか、異常時にも正しく動作するか、データの整合性を維持できるかは、自動的には決まりません。
誰が、あるいはどのツールが実装しても同じ結果になるように、条件、例外、入力、出力、データ更新、責任分界を定義する力の価値は、むしろ高まります。
コード生成は実装手段の変化であり、定型的な実装や構文確認を効率化できます。何を作るのかを確定し、結果を検証する責任まで置き換えるものではありません。
アプリケーションエンジニアの価値は、コードを何行書いたかだけでは決まりません。何を作るべきかを定義し、関係者が同じ仕様を理解できる状態を作り、完成した機能が業務で使えることまで確認するところにあります。
SEとプログラマーは職種名だけでは分けられない
重要なのは、担当する工程と責任範囲です。
小規模な開発では、一人が利用部門への確認、設計、プログラミング、テストまで担当することがあります。
大規模な開発では、要件整理や設計を担当する工程と、実装や単体テストを担当する工程を分けることがあります。
設計書に従って処理を実装する担当者は、決められた仕様を正確にコードへ変換する責任を負います。
アプリケーションエンジニアは、その仕様が業務要件を満たしているか、関連機能と矛盾していないか、異常時にも成立するか、運用開始後に使い続けられるかまで考えます。
大規模開発では工程を分担する
大規模なシステム開発では、一人のエンジニアが要件定義からプログラミングまで、すべてを担当するとは限りません。
上流工程では、利用部門へのヒアリング、業務要件の整理、基本設計、他システムとの調整を担当します。
後続工程では、詳細設計、プログラミング、単体テストを複数のチームや協力会社へ分担することがあります。
工程を分ける場合、設計書がチーム間の共通言語になります。
設計書に曖昧な表現があれば、開発者ごとに異なる解釈で実装されます。正常処理しか書かれていなければ、エラー時の動作は実装担当者の判断に委ねられます。
後工程で発生した質問へ回答し、仕様変更があれば影響範囲を判断し、関連する設計書を更新することもアプリケーションエンジニアの仕事です。
設計工程が終わったからといって、実装工程と切り離されるわけではありません。
設計品質は規約とひな形をそろえて保つ
エラー処理の設計は、担当者ごとの判断に委ねてよい領域ではありません。
あるシステムでは、値がNULLの場合に条件分岐から漏れる処理が複数の機能に存在していました。漏れたケースはエラーとして扱われないまま後続へ渡り、処理の異常終了が連続して、業務の処理が流れない事態になりました。原因を調べると、エラーハンドリングの方針がコーディング規約に定義されておらず、設計書にも異常時の動作が書かれていませんでした。見つかった箇所を直すだけでは済みません。同じ作りの処理が他にないか、全機能を横並びで確認することになりました。
修正そのものより、影響範囲の横並び確認に工数がかかります。規約と設計書ひな形に異常時の観点が定義されていれば、実装前のレビューで検出できた問題です。この経験の後、設計書のひな形を見直し、エラーハンドリングの標準方式を規約として定義しました。
小規模な案件ほど、規約や共通部品の整備は後回しになりがちです。エラーハンドリング、ログ出力、トランザクション管理を共通処理やフレームワークとして整えるのは、アプリケーションチームとAP基盤チームがすり合わせて進める領域です。ここへ最初に投資しなければ、実装者ごとにばらばらの作りが生まれ、試験と障害対応で余計な工数を払い続けることになります。
共通エラーハンドリングやログ出力、トランザクション制御の仕組みを整えるのは、主にAP基盤側の役割です。
一方、何を業務エラーとし、どの条件で処理を止め、利用者へどのようなメッセージを返すのかは、アプリケーション側が定義します。
実際の責任分界はプロジェクトごとに異なるため、設計の初期に両チームで確認します。
仕様を決めるだけでなく、設計書、規約、ひな形、共通処理をそろえ、誰が担当しても同じ考え方で実装できる状態を作ることが重要です。
テストでは仕様どおりかだけを確認しない
単体テストでは、プログラムの部品が設計どおりに動くことを確認します。
結合テストでは、画面、バッチ、データベース、外部システムなどを組み合わせ、処理全体が成立することを確認します。
テストで重要なのは、正常に完了するケースだけではありません。
入力値が不正な場合、対象データが存在しない場合、権限がない場合、外部システムが停止している場合、途中でタイムアウトした場合など、異常な条件も確認します。
同じ処理を二回実行した場合にデータが重複しないか、途中で失敗した処理を再実行しても整合性が崩れないかも検証します。
設計上想定していなかった不具合が見つかった場合、単にプログラムを修正するだけでは済みません。
仕様そのものに不足があるのか、他機能にも同じ問題があるのか、運用手順へ影響するのかを確認し、必要に応じて設計へ戻って見直します。
もう一つ見落とされやすいのは、どの工程で、どの環境で、何を確認するのかという、試験そのものの設計です。
単体テストや結合テストの初期段階では、相手側の機能や外部システムが完成していないため、開発者が個人の端末にスタブやドライバを用意して試験することがあります。このとき、スタブがどこまで実際の動きを再現するのか、どの観点をこの工程で確認し、どの観点を後工程へ送るのかが担当者任せになっていると、本来単体や結合の前半で摘出すべき不具合が、後半の結合テストやシステムテストまですり抜けます。
後工程で見つかる不具合ほど、原因の切り分けに関わる範囲が広がり、修正の影響確認にも時間がかかります。
工程ごとの摘出観点を事前に定義し、スタブの粒度と試験環境の前提をチームで揃えることも、アプリケーションエンジニアの仕事です。詳細は次の記事で解説しています。
アプリケーションの仕様は他チームの設計条件になる
アプリケーションの仕様は、アプリケーションチーム内だけで完結しません。
設計した機能がどの程度のデータを処理し、どの時間帯に実行され、どのような頻度でデータベースや外部システムへ接続するのかは、他チームの設計条件になります。
たとえば、大量のデータを夜間バッチで処理する場合、必要なCPUやメモリ、データベースの更新量、ログの出力量、処理時間を共有します。
短時間に多数の利用者がアクセスする場合は、同時接続数やセッションの持ち方、コネクションプールの設定、タイムアウト値などをAP基盤チームと検討します。
外部システムと連携する場合は、通信経路、接続先、認証、暗号化、ファイアウォールの設定をシステム基盤やネットワークの担当者と調整します。
アプリケーション側が処理方式や件数を伝えなければ、他チームは必要なリソースや構成を設計できません。
性能問題はアプリケーションにも原因がある
性能問題が起きると、サーバーやデータベースの能力不足が疑われることがあります。
原因がアプリケーションの処理方式にある場合、CPUやメモリを増やしても根本的な解決にはなりません。
一件ずつデータベースへアクセスする処理、同じ情報を何度も取得する処理、必要以上に広い範囲を検索するSQL、長時間トランザクションを保持する設計などは、データ量が増えたときに性能問題へつながります。
画面上では一回の操作に見えても、内部で何百回もSQLを実行していることがあります。少量のテストデータでは問題がなくても、本番と同じ件数になると急激に遅くなる場合があります。
アプリケーションエンジニアは、業務ロジックを守りながら、SQLの書き換え、処理の一括化、キャッシュの利用、非同期処理への変更、検索条件の見直しなどを検討します。
性能改善は、アプリケーションだけでもデータベースだけでも完結しません。アプリケーションエンジニア、AP基盤エンジニア、データベースエンジニア、システム基盤エンジニアが原因と改善方針を共有する必要があります。
データベース側から見た性能問題の切り分けとDBAの役割は、次の記事で解説しています。
障害対応では業務への影響まで判断する
障害が発生したとき、アプリケーションエンジニアはエラーログやソースコードを確認し、どの処理で何が起きたのかを調査します。
調べるのは技術的な原因だけではありません。
処理が失敗した結果、データが登録されていないのか、一部だけ登録されたのか、外部システムには送信済みなのかを確認します。
システム上の処理結果と、利用者から見える結果が一致しているとは限りません。処理が一部まで進んだ状態で再実行すれば、業務上の重複やデータ不整合につながることがあります。
収納代行に関わるシステムを担当していたとき、収納代行向け帳票を一斉送付するバッチに不具合があり、同じ利用者へ通知が2通発行されたことがありました。送付した人には送付済みの状態が記録される設計でしたが、特定の条件でこの更新が機能していませんでした。深刻だったのは、2通ともシステムが発行した本物の通知だったことです。仕組みを知らない人がそれぞれの通知で支払いをすれば、二重に支払ってしまう可能性がありました。誰に2通送られたのかをデータから特定し、利用部門と対応を協議しました。幸い対象者はまだ支払い前だったため、お詫びの連絡で収束しましたが、支払い後であれば二重支払い分の返金手続きまで必要になっていたはずです。プログラムの修正は、この障害対応の一部にすぎませんでした。
夜間バッチが途中で停止した場合は、どのデータまで処理されたのか、再実行できるのか、後続のバッチを止める必要があるのかを判断します。
業務への影響があれば、利用部門へ状況を説明し、暫定的な運用方法や再処理の手順を決めます。
障害原因の特定、プログラムの修正、データの補正、対象者の特定、利用部門への説明まで含めて対応するところに、アプリケーションエンジニアの責任があります。
業務知識と技術知識の両方が必要
アプリケーションエンジニアには、業務知識と技術知識の両方が必要です。
業務だけを理解していても、要望を実装可能な仕様へ落とし込めません。技術だけを理解していても、利用者が必要としている機能を正しく設計できません。
利用部門が使う言葉と、開発者が理解できる仕様の間をつなぐ役割を担います。
経験を重ねると、担当する業界の業務知識が蓄積されます。金融、公共、製造、流通など、対象分野に詳しいことは大きな専門性になります。
技術面でも、プログラミング言語だけでなく、データベース、API、認証、トランザクション、性能、セキュリティ、運用まで理解する必要があります。
すべてを自分一人で設計するわけではありません。他領域のエンジニアと会話し、必要な情報を渡し、相手から示された制約をアプリケーション設計へ反映できるだけの知識が求められます。
まとめ
アプリケーションエンジニアは、画面やプログラムを作るだけの担当者ではありません。
利用者の業務を理解し、曖昧な要望をシステムで実現できる仕様へ変換し、画面、帳票、バッチ、API、データ、例外処理まで設計します。
大規模な開発では、設計と実装を異なるチームが担当します。誰が実装しても同じ結果になるように、判断条件、異常時の動作、データ更新、他システムとの境界を具体化する必要があります。
プログラミングは重要な技術ですが、仕事の一部です。設計した内容が実装可能であることを確認し、完成した機能が業務で使えることまで責任を持ちます。
アプリケーションの処理量や接続方式は、システム基盤、AP基盤、ネットワーク、データベースの設計条件にもなります。性能問題や障害が発生すれば、業務ロジックを理解している立場として、原因分析と関係チームの調整へ加わります。
業務と技術の間に立ち、曖昧な要望を実装可能な仕様として決める。設計書、規約、ひな形、共通処理をそろえ、誰が実装しても同じ結果になる状態を作る。そして、設計、開発、テスト、稼働後の対応を通じて、業務システムを動かし続ける。そこに、アプリケーションエンジニアの専門性があります。
関連記事
SEは一つの職種ではありません。アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、データベース、プロジェクト管理など、職種ごとの役割の違いは、次の記事で整理しています。
システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか
データベースの設計、性能、バックアップ、障害対応を担うDBAの仕事は、次の記事で解説しています。
データベースエンジニア（DBA）の仕事｜止めない、失わない、遅くさせない
AP基盤、システム基盤・クラウド、ネットワークなどの職種についても、順次個別の記事で解説します。
コメント