今回はシステム開発で実施する必要があるアーキテクチャを決める際の観点について語ります。
アーキテクチャを決めるのは大規模システムだけとは限りません。
システム開発をする以上、どんな小さなプロジェクトでもアーキテクチャはあるんです。
動作するＯＳとか、プログラミング言語は何とか、決まってないと先に進めませんよね。
小さいシステムから大きなシステムまで、こんなことを考えておいた方がよい、ということをまとめてみます。
アーキテクチャ決定時の考慮点
アーキテクチャ定義とは
アーキテクチャ定義って言葉をつかいましたが、いろいろな言葉の定義もあるので、ここでは次のことと定義します。
「システムを構成する要素の定義とかその間のつながり、自分のシステムの外部にある環境との関係」
そのシステムでは何をつかうの（ＯＳとかプログラム言語とか、運用のためのソフトウェアとか）
そのシステムはどことつながってるの（外部インターネット環境とか、他のシステムとか）
そのシステムのしくみ（障害発生時の連絡のしくみとか、稼働を制御するしくみとか）
結局、システムまわりの仕組みをどのように作るかのもろもろの定義ですね。
アーキテクチャを決める上で大切なこと（考慮点）
最も大切なことは、お客様の要件にあわせることです。システムを誰がどう使うか、それとあわせてお客様のその他のご要望も満たすかどうかを検討すべきです。
お客様の機能・性能要件に合致すること
・システムを利用するユーザの要件（機能）が満たせるか
・システムの性能をみたせる基盤か（サーバースペックなど）
お客様の納期・費用に合致すること
・システムやアーキテクチャがお客様の予算にあう範囲で構築可能か
・システムが納期内に開発ができるものなのか
当然といえば当然なのですが、結局はお客様にあわせることを忘れてはならないです。
技術をきわめていくと、お客様ではなく要件度外視でやってみたい新規技術を中心で提案してしまうとか、自社製品をもつ会社の場合は要件を満たさなくても自社製品で固めてしまうとか、そのあたりは注意すべきと思います。
上記の２つの条件を満たしたうえで、自社製品や新規技術導入などを検討すべきです。
２の条件については、自社製品をつかうからこそ納期が守れるとか費用を低減できるとか、いわゆる強みにつながる部分はあると思うので、そこはお客様のためになるということで自信をもって提案すべきです。
自社製品がなくとも、既知の技術を適用する場合には技術習得期間が短縮されるうえに、トラブル解決や要員の調達の容易さにもつながってくることも想定されます。
ぜひ、お客様とＷＩＮ－ＷＩＮの関係を築いて欲しいと思います。
アーキテクチャを定義するのに決めておく項目の一覧
アーキテクチャ定義において、具体的に決めておく必要がある項目をあげておきます。
ユーザ要件（インプット）
お客様の要件を明確にしておく必要があります。
【機能要件】
- 画面機能
開発画面数
機能の操作性・複雑性（どんなインターフェースがあるか）
同時利用要件（複数人の同時利用があるか、複数個所、部署、一般公開利用等）
利用場所（モバイル/リモート有無） - バッチ機能
開発本数
スケジューリングタイミング - 帳票・印刷機能
印刷機能有無
特殊印刷有無（専用紙） - 他システム連携/各種アプリ連携/デバイス利用
Office製品等
ファイル入出力
バーコードリーダー
特殊通信等
外部連携先の他システムとそのインターフェース
【非機能・運用要件】
- 性能要件
オンラインレスポンス時間、バッチ処理時間（ピーク時間帯のレスポンスおよび処理時間）
データ容量（最大データ容量、バックアップ容量）
利用ユーザ数（最大利用ユーザ数、同時想定トランザクション数） - セキュリティ要件
クライアントサイド、サーバーサイドそれぞれのセキュリティ要件
セキュリティパッチの最新化有無
侵入防止のレベル（なりすまし防止、外部侵入をどこまで阻止するか等） - 運用要件
稼働時間帯(24時間365日等）
障害復旧時間(3時間以内、翌稼働日でＯＫ等）
信頼性・バックアップ要件
要・不要、信頼性
リカバリー要件（障害時のどのタイミングのデータに戻すか）
拡張要件（将来の発展性）
【プロジェクト要件】
- 予算
人件費
プラットフォーム（設備）費
立上げ以降の想定の保守費
新規構築、再構築・老朽更新 - 納期
リリース時期（複数ある場合は、一斉か順次リリース可能か）
アーキテクチャ定義（アウトプット）
ユーザ要件を確認して整理したら、その実現方式、実装方式の定義にはいります。
機能要件、非機能要件、プロジェクトの要件に対して実現可能かどうかを検討しながら、構成を決定していきます。
【アプリケーションの基本構成】
画面操作性や利用するユーザが必要とする機能を満たすためのアプリケーション構成を検討します。
WEBアプリ、デスクトップアプリ、スマホアプリ、組込み系等
バッチ、オンデマンドバッチ等
【システムの基本構成】
機能・性能の実現性に加え、開発要員の確保、予算・納期なども要考慮です。
つくらずに外部パッケージを利用することも検討します。
ただし、外部パッケージの場合はカスタマイズが必要な場合にはその費用や保守費用、将来の拡張で更に費用がかさみ、結局新規構築の方が費用がかからないなどのケースもあるため、慎重に検討します。
クライアント/サーバーのＯＳ(Linux、Windows、メインフレーム）
開発言語、開発用ソフトウェア、周辺ソフトウェア、周辺機器
プログラミングの言語を何にするか、周辺のソフト（帳票出力等）の定義
あわせて開発で利用環境(OSS利用、製品利用等）
周辺機器（プリンタ、バーコードリーダー装置、バックアップ機器等も定義）
利用データベース
他システム連携用の通信ソフトウェア（必要に応じ）
運用のためのソフトウェア
【システム基本構成の配置】
基本構成を決める際にアーキテクチャとしては配置も検討する必要があります。
近年、自社内に構えずに外部のクラウド(Amazon等)等の利用も増加してるので、その可能性も検討します。
サーバ構成・配置
データベース配置
運用基盤・サーバー
【クライアント・サーバーのスペック】
個々の構成や配置決定後には、要件として定義されたオンライン画面へのトランザクション数やバッチの処理時間に耐えられるサーバーのスペック、台数を検討します。
大規模プロジェクトで品質要件がシビアな場合には、スペックを決定するための性能検証テストも実施します。
プロジェクトの進め方によっては最初にスペック検証はできないため、机上で計算後、実際の機器導入前に検証するためのタスクをくむようにしたほうが、リスクを回避できると思います。
【ユーザの利用前提条件の定義】
システムアーキテクチャを決めていく中で、お客様の要件を満たせないケースが発生する場合もあります。
その場合には、事前にお客様にしっかりとお伝えし、前提条件として合意しておく必要があります。
システムの規模が小さい場合、システムによっては対象となる項目がないものも多々ありますが、今回はこれまでの経験から、考慮したほうがよいと考えられるものを一通り記載しました。
まとめ
最後にまとめておきます。
・アーキテクチャは、お客様第一で定義する
・アーキテクチャを決めるには、機能、非機能、運用の定義をわすれない
ユーザ要件を定義したものに従って、アーキテクチャの各項目を決定していくことが重要です。
今回はここまで。
システム企画・開発へのご支援について
これまでの自分の経験をもとに、システム企画や開発などへのご支援をしております。
ご興味がわいた時には一度ご連絡、ご相談ください。下記にリンクも貼っておきます。
