はじめに
受託開発（クライアントがオーナーになるシステムの構築依頼を受ける場合）のプロセスの内、アプリケーション基盤領域のITアーキテクト（APアーキテクト）の仕事内容をまとめたもので、所謂SIerの仕事の一断面です。以降、ITアーキテクト（AP）と記載します。
SIer各社における標準的な開発プロセスや役割分担、クライアント意向など様々な要素の影響を受けるため、SIerにおける標準的な仕事内容を示すものではありません。
プロセス概要
受託開発のプロセスの内、ITアーキテクト（AP）のタスクの概要を示します。ここでは受託開発前の案件化のプロセスも含んでいます。
自社の受託開発においてアジャイル開発を採用するケースが増えてきていますが、まだまだウォーターフォール開発が主軸であり、ウォーターフォール型開発をベースにしたプロセスになっています。
SIer各社における標準的な開発プロセスの定義も様々ですし、プロセスの名称だけで共通の認識を持つのは難しいので、経済産業省が公開している「情報システム・モデル取引・契約書」のモデル契約のフェーズ分割と対応付けておきます。
経済産業省が公開している「情報システム・モデル取引・契約書」はこちら。
www.ipa.go.jp
モデル契約の中で使われているフェーズ分割の定義は以下のイメージです。
モデル契約の中で使われているフェーズ分割の定義と本記事内のプロセスを対応付けると次のようになります。
| モデル契約 | 本記事内のプロセスとの対応 |
|---|---|
| 企画プロセス | 案件化／提案 |
| 要件定義プロセス | 要件定義 |
| システム設計（外部設計） | 仕様策定 |
| システム方式設計（内部設計） ソフトウェア設計 プログラミング ソフトウェアテスト |
実装 |
| システム結合 システムテスト 導入・受入支援 |
テスト |
| 運用プロセス | - |
境界が曖昧な設計と実装について補足します。私が参画している開発ではクライアントから開発プロセスおよび契約形態を指定されているケースを除き、規模に依らず内部設計や詳細設計と呼ばれる設計を単独で実施するケースは直近10年では無くなり、設計と実装を並行させたり設計をリバースエンジニアリングで出力するケースに置き換わっていますので、実装とだけ表現しています。
- 仕様策定
どのようなユーザーインターフェイスにするかなど、システムの振る舞いを決めるプロセスです。システムの振る舞い＝外部仕様と表現します。外部仕様には、外部接続のインターフェイス（公開API含む）の定義も含みます。 - 実装
契約上、基本的には内部（詳細）設計とプログラミング（実装）はまとまった請負契約になるので、納品対象に設計書が含まれていてもソースコードと併せて納品する形となり、設計ドキュメントの作成とプログラミングの順序は任意とすることが出来ます。なので、 設計と実装を並行させたり設計をリバースエンジニアリングで出力するといったことが可能になっています。
Unit Testingはここに含みます。
内部設計や詳細設計と呼ばれる設計が単独で実施されなくなってきたのは自社で起こっていることなので一般論ではありませんが、個人的に以下のような理由によるものと考えています。
- フレームワークやライブラリの充実によって、単純なCRUD処理の実装に必要なコードが少なくなった
- フレームワークによって構造が決められ、細かい分割を除いて構造設計が不要になった
- 様々な失敗からアーキテクチャ策定および方式設計が重視されるようになった結果、基本的な処理パターンについては量産できるようにプロセス化された
- 基本的な処理パターンに収まらないものは実装してみないと不明な点が多く、机上で設計の完成を先行させることが非効率になった
体制／役割
比較的規模の大きな開発における体制の例です。
ITアーキテクトは以下のように役割分担されることが多いです。
- ITアーキテクト（ドメイン）
ドメイン知識を持ち、業務分析や機能要件整理、外部仕様策定をリードしつつ、それらの整合性を保ちます。また、Featureチームのリードも担います。 - ITアーキテクト（AP）
非機能要件整理、アプリケーション方式設計、アプリケーション基盤構築、設計／実装標準化を担います。 - ITアーキテクト（インフラ）
非機能要件整理、インフラストラクチャの設計と構築を担います。
ITアーキテクトの役割は分かれますがそれぞれが密接に関わるタスクが多く存在し、それぞれの意思決定によって他に影響を与える場合は合意形成を行います。本来は役割がまとまった方が調整が少なく、役割の間に落ちるボールも無くなりますが、特に規模の大きな開発ではタスクの物量やスキルセットの問題でこのように分担されることが多くなっています。
仕事内容
案件化／提案と要件定義以降に分け、要件定義以降は開発の流れとして紹介します。
案件化／提案
案件化においては、クライアントがシステム化／再構築の企画を進めるにあたって、採用候補に挙がっている技術要素についての勉強会や適用事例の紹介など、クライアント内で合意形成を図ったり、企画化するための活動を支援することが中心になっています。直近のテーマに挙がった技術要素は次の通りです。
- マイクロサービスアーキテクチャ
- OAuth/OIDC
提案においては、クライアントのヒアリングやシステムの構成案検討とその根拠を示す資料作り、プレゼン時の技術回答などを主に担当しています。
開発の流れ
ITアーキテクト（AP）目線の開発の流れの例です。
タスク詳細
非機能要件整理
クライアントへのヒアリングを元に、主にITアーキテクト（インフラ）と共同で実施しています。
整理する内容を以下に例示します。
非機能要求グレードより
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
その他
- ユーザービリティ
- アクセシビリティ
ITアーキテクト（AP）は主に以下の整理に関わっています。
- 性能（処理パターン抽出）
- セキュリティ（リスク分析、セキュアコーディング、データ秘匿化、認証／認可）
- 運用・保守性（ログ）
- ユーザービリティ
- アクセシビリティ
アーキテクチャ策定
主に以下のようなタスクを実施しています。
- システム構成検討（提案時のシステム構成案の精緻化）
- 技術選定（製品、ツール、ライブラリ）
提案時に開発言語やフレームワークはほぼ決定していますが、稀に見直しを行うこともあります。基本的にはそれ以外の製品やツール（CI/CD、エディタ、テスト）や主要なライブラリの選定を行います。製品選定は例えばOCRや帳票製品などがありますが、実績が十分でない製品の選定には実現可能性の検証を伴います。 - アーキテクチャパターン整理
処理方式（システム間連携、オンライン、バッチ、非同期）のパターン洗い出し、処理パターンごとのアーキテクチャ策定。
実績が十分でないものについては、技術検証を行いながら策定していきます。
UIプロトタイプ
デザイン方針を受けて、メニューなどのフレームやフォームなどの個別要素、登録やアップロードの主要な処理パターンから、一括編集など複雑だったり認識ずれが起きそうなリスクの高い要素などをピックアップして行います。これによって、クライアントとおおよそどのようなUIの作りにするか認識を合わせます。UIプロトタイプが無くてもクライアントと認識ずれが起きなさそうな場合は省略されることがあります。実施されるケースは例えば、業務用クライアントアプリケーションをWeb化する案件では、現行システムと新システムの違いが大きいために認識ずれが起きやすく、UIプロトタイプが実施される、といった感じです。
UIプロトタイプの入力となるデザイン方針はUI/UX担当が主導しますが、UIコンポーネントライブラリの選定などの技術選定はITアーキテクト（AP）が担当している都合、実装し易い形になるように、調整を行っています。
設計標準化
- UI設計ガイドライン策定
UIプロトタイプに解説を付けるなどして、UI設計のガイドラインを策定します。これによってデザインガイドラインでは示されない、例えばイベントの発生タイミングなどのUIの振る舞いを機能設計の担当共有しつつ、設計上の規約を示します。 - 設計要素の洗い出し、設計ドキュメント記述ガイドライン策定
標準的な設計要素はありますが、システム特性を考慮してテーラリングを行います。 - 標準化プロセス定義
属性の洗い出しとその定義など、設計情報を集約して整合性をとるためのプロセスを整備します。
そのほかに例えば、監査機能などを共通機能で実現する場合、監査対象のイベントや監査情報として残すデータに関する情報、マスキング対象などを個別の機能設計から集約する方法とそのプロセスを整備します。
AP方式設計
以下のような内容を設計しています。
プロトタイプ開発と併せて技術検証を行いながら設計を進めることが多いです。
- 構造定義（論理構造／物理構造／配置構造）
レイヤー分割／役割定義、ディレクトリ構造、URL構造、モジュール配置 - セキュリティ
- 認証／認可
- 監査
- データ保護
- Webセキュリティ対策
- トランザクション
- 同時実行制御
- リトライ（ポリシー、方式）
- 文字の扱い（文字コード、許可／拒否する文字セット、照合順序）
- 状態管理（サーバー、クライアント）
- データ削除（論理削除／物理削除）
- 例外（業務例外とシステム例外の扱い）
- ログ
- 閉塞
- システム間連携
- オンライン処理（正常系／異常系、アップロード／ダウンロード、一括編集）
- バッチ処理（正常系／異常系）
- 非同期処理（正常系／異常系、通知）
- 帳票出力
- システム間連携
共通機能開発
主に非機能領域の共通機能の開発を担います。機能領域のものは主にITアーキテクト（ドメイン）が開発を担います。
非機能領域の共通機能は例えば、認証／認可やログ、トランザクション管理などで、その内フレームワークやライブラリで不足する機能を実装します。
- バックエンドの共通機能の例
Authn／z Filter／MiddlewareやCustom Annotation、その他DI／Interceptorなどを使った機能 - フロントエンドの共通機能の例
AuthGuardやCustom Validation、その他Hook／Interceptorなどを使った機能
プロトタイプ開発
AP方式設計の結果をプロトタイプ開発で検証します。AP方式設計において必要な技術検証の多くはこのプロトタイプ開発と併せて実施しています。
開発環境構築
開発者のローカル環境および共有の開発／テスト環境の構築を行います。
- ローカル環境向け
エディタやLinter/Formatterなどの設定やビルドスクリプト、テストスクリプトなどを整備 - 共有の開発／テスト環境向け
環境変数や設定ファイル、キーストアなどの準備やCI/CDパイプラインの整備
実装標準化
開発者教育／サポート
テスト準備
開発を担当した共通機能および非機能テストのテストシナリオ／テストケース／テストデータ作成、環境準備（環境変数、設定ファイル）などを行います。
場合によってはテストプログラムの作成やテストツールのシナリオ作成なども実施します。
障害解析／パフォーマンスチューニング
開発を担当した共通機能の障害の解析およびパフォーマンスチューニングを実施するほか、機能面でITアーキテクト（ドメイン）／Featureチームで解決できない問題を担当します。後者は基本的には解析結果や改善案を提示して後はITアーキテクト（ドメイン）／Featureチームに任せることが多いです。
おわりに
SIerのコア事業である受託開発のプロセスの内、APアーキテクトとして仕事してきた内容を棚卸ししてみました。
繰り返しになりますが、SIer各社における標準的な開発プロセスや役割分担、クライアント意向など様々な要素の影響を受けるため、SIerにおける標準的な仕事内容を示すものではありません。