4.ベンダー依存から脱却するための「グラスボックス」

4.1　 3つの要素と具体的な手法

「グラスボックス」を実現するために大きく3つのポイントがあります。
そして、AIST包括FWはそれらを担保するためにさまざまな標準や成果物を用意しています。

3つのポイントとは、大きくまとめると
(1)やること（プロセス）の標準
(2）作るもの（成果物）の標準
(3）作り方（アーキテクチャ）の標準
を発注者側が持つ（指定する）ことです。

以下、それぞれのポイントについて、解説していきます。

ベンダー毎に異なる進め方を受け入れると、同じ用語（例：基本設計）でも実施する作業が異なっていたり、実施する作業の順番が異なっていたり、私たち発注者側が、どのような作業が行われるか十分に理解できない状態が起こります。

そこで、要件定義や設計開発作業について、「どのタイミングで、どのような作業を実施するのか」を発注者側で標準として決め、これに則って作業を行ってもらうようにします。

これにより、作業範囲に齟齬が生じてトラブルとなるリスクが減るだけでなく、標準に基づいて発注者とベンダーの双方が協力し、プロジェクト計画段階で「どのようにやるか」を具体化することができます。

そうすることで、実効性の高い計画を作成することができるとともに、プロジェクト開始後の進捗管理もしやすくなるというメリットがあります。

AIST包括FWでは、やることの標準（開発プロセスの標準）を「要件分析プロセス定義書」などの各種プロセス定義書や「バッチ開発ガイド」といった各種ガイドラインとして規定しています。

ベンダー毎に異なる形式の成果物を受け入れると、それぞれ作成するドキュメントの種類や内容が異なっていたり、同じ名称のドキュメントでも記載方法や記載の粒度がバラバラになったりして、誰もが同じように解釈できない状態が起こります。

また、ベンダーが標準で作成する成果物には、ベンダーは読み取れるが、発注者が読み取りにくく、正しくレビューすることが困難なものがあります。このため、要求と異なるシステムができあがったり、設計と異なる実装がされたりして、「これじゃ使えない、こんなはずじゃなかった」ということも起こってしまいます。

そこで、「どの（種類の）成果物を、どのような粒度で作るのか」を発注者側で標準として決め、これに則って成果物を作成してもらうようにします。

標準化する成果物の中には、業務の利用シーンと合わせてシステム機能を確認できる業務フロー図やユースケース記述のようなドキュメントを含めておくことで、業務の目的にあったシステムになっているかの確認がしやすくなるというメリットがあります。

さらに、上流のドキュメントと下流のドキュメントの間にトレーサビリティのルールを標準化しておけば、実装がわからなくても業務要件の変更からシステムの影響範囲を特定することが可能となります。

AIST包括FWでは、テンプレートやガイド等によって、システムを設計開発・維持し続けるための成果物の種類・粒度などを規定しています。

どのような機器やミドルウェアなどを使って作り上げていくのかという、システムの作り方（アーキテクチャ）を定めていなければ、システム毎に異なる製品が導入されて統一感のないシステムになったり、特定のベンダーしか扱えない部分ができてしまったりすることが起こります。

また、多くのシステムが必要とする機能は、共通機能化しておかなければ、各システムで開発されて、メンテナンス性が悪く費用も多く発生してしまうことにもなります。

そこで、「どの技術を使い、どのようなルールを守って作るか」を規約や実装により標準化します。
業務アプリケーションは基盤が指定する機器・ミドルウェアで動作するように指定して調達することで、重複した調達や特定製品への依存を防ぐことができるというメリットがあります。

また、システムが共通して利用する機能は共通機能として予め用意し、データ連携についても必ずデータ基盤を経由すること、また、データのオーナーからの連携以外は認めないように統制することで、機能の重複や連携の複雑化を抑止します。

グラスボックス化の3つの要素はいずれも大切ですが、なかでもシステムの性能や拡張性を大きく左右するのが「作り方の標準」です。

次回は、この作り方を確実にガイドする役割を果たす「システム基盤」について、その範囲や構築のための進め方などについて紹介します。