ITアーキテクトのお仕事~システム方式設計~

こんにちは。サービスデリバリーセンター(SDC)のあおやまです。

昨年度まではプロジェクトの技術サポートや開発プロセスの改善活動なと裏方仕事をやっていたのですが、今年度は久しぶりに現場部門に戻ってきて現場プロジェクトに参画しています。

私のプロジェクトでの役割はITアーキテクトになります。
プロジェクトにおいて技術面でプロジェクトをリードする立場です。プロジェクト開始時点でのシステムの全体設計から始まり、アプリケーションの開発方法やテストの実施方法の検討まで多岐にわたります。必要に応じて自分自身の手を動かして主要なフレームワーク・共通機能部分の開発、技術検証も行います。

今回はそのタスクの中で重要な「システム方式設計」についてお話したいと思います。

※「システム方式設計」は共通フレーム(SLCP-JCF)で定義されていますが、当ブログの内容は私の経験則および実践に基づいて書いていますので内容が異なっている部分があります。あらかじめご了承ください。

システム方式設計とは

「システム方式設計」は、主にシステム要件定義から基本設計(外部設計)工程において行います。
目的は、要件定義で抽出したユーザ要件を実際にシステムに落とし込む為に、ハードウェア/ソフトウェア構成などのインフラおよびアプリケーション・アーキテクチャなどシステムのフレーム(骨子)となるシステム構成・方式を決めることです。

ここで決定したシステム構成・方式に基づいて今後インフラ担当やアプリケーション担当は作業を進めて行きますので非常に重要なタスクです。ここでの設計に誤りがあると後々の工程で大きな技術課題がでてきたり、性能が出なかったりとスケジュールが大幅に遅延する要因となり、最悪システムがまともに動かないリスクがあります。

このように影響範囲が大きいためシステム方式設計はITアーキテクトだけで決められることはありません。お客様であったり、既存システムのシステム運用担当、プロジェクトのインフラ担当・アプリケーション担当などとあらゆる責任者と相談しながら、検討および決定していく必要があります。

設計する主な内容は以下の通りとなります。

ハードウェア/ソフトウェア構成

システムが稼働するハードウェア/ソフトウェア構成を決定します。この作業はデータセンタに配備する「オンプレミス」なのか、AWS(Amazon Web Services)などの「クラウド」なのかによって大きく変わります。

オンプレミスの場合は、既存システムの絡みがあったりして、あまりどうこう言えず殆ど決まっていることが多いです。自由度が低くインフラ/ソフトウェアの構成を決定するというよりは、システムの前提/制約を明確化するという作業になります。

クラウドである場合は、ハードウェア構成ではなく、システムが稼働する環境をIaaS(Infrastructure as a Service)にするのか?PasS(Platform as a Service)にするのか?Dockerを利用するのか?などを決めます。またシステムで利用する各種ミドルウェアを自前でインストールして使用するのか?SaaS(Software as a Service)を利用するのか?などを決定します。
構成などは比較的自由に決められる場合が多く、それに付随して検討することも多くなります。ただ各クラウドベンダーからアプリケーションの形態に応じた推奨構成がでていますのでそれをベースに検討します。上記のオンプレミスとクラウドのハイブリッドなどやプライベートクラウドもあります。

そもそもオンプレミスなのかクラウド(クラウドベンダ含む)なのかはお客様の事情でプロジェクト開始時点で決まっていること多いです。特に指定がない、弊社お任せの場合はクラウド一択でAWSまたはMicrosoft Azureが多いです。

アプリケーションアーキテクチャの決定

システムに乗せるアプリケーションアーキテクチャを決定します。
アプリケーションの形態がWebアプリなのか、スマホアプリなのかはプロジェクト開始時点でお客様要件としてだいたい決まっているので、それらの開発言語をどうするか?開発フレームワークをどうするか?などを検討します。

またWebアプリだとしても、Javaの世界ですと昔はとりあえずアプリケーションサーバに乗せるだけだったのですが、最近はマイクロサービス・アーキテクチャやサーバレス・アーキテクチャなどアプリケーションの形態も様々になってきています。機能要件、非機能要件に応じて決定します。

外部システム連携方式

自システム以外の外部システムとのデータ連携方式について検討します。
スマホアプリや外部向けの小さなWebアプリだと考えなくてもよいのですが、それなりにシステムが大規模になってきますと自システムだけで完結するということはなくなってきますので、他システムとの外部連携が発生します。
データ連携の方法はファイルによるデータ連携なのか?WebAPIによるデータ連携なのか?はたまたメッセージ指向ミドルウェアを利用するのか?を決めていきます。また併せて、プロトコルは何なのか?文字コードはどうするのか?などといったことを検討していきます。

上記の内容はお互いが絡み合っており、どれかひとつを一方的に決めるということはできません。総合的に考えながら方式を検討していきます。

システム方式設計を実施するにあたっての注意点

システム方式設計を進めていく上での注意点について説明します。

パフォーマンス、セキュリティなどの非機能要件を組み込む

パフォーマンス、セキュリティなどの非機能要件をシステムでどう実現するのかを決定する必要があります。
要件定義では「今回のシステムではこういった機能が欲しい」「こういったことができるようようにしたい」といったユーザの機能要件(業務要件)と「システムは24時間365日稼働」「ユーザの操作で1秒以内にレスポンスが返ってくること」といった非機能要件は別々に上げられるため、機能要件および非機能要件をどのようにシステムで実現するのかを検討します。
特に非機能要件については、システム方式設計での検討が漏れていると、かなり後の工程までいかないと問題に気づけないため非常に重要です。

パフォーマンス/キャパシティの検討については、オンプレミスとクラウドで難易度が異なります。
オンプレミスでは自由度が低く問題があったからといってすぐにはハードウェアの増強などは難しいため、このタイミングで厳密に試算する必要があります。それに比べ、クラウドはスケールアップ/スケールアウトが容易なため後工程で問題があってもコストさえかければ解決できることが多く、非機能要件のシステムへの組み込みの難易度を大きく下げたと思います。
ただ一方でクラウドのスケールによる性能解決は一部分であり、インターネット経由だとそもそものネットワークがボトルネックになることもあるので過信は禁物です。

技術リスクを明確にする

システム方式設計では設計をするだけではなく現時点での技術リスクを洗い出すことも重要なポイントです。
あまり実績のないOSSやミドルウェアなど利用する場合、後で想定していなかった大きな問題がでる可能性があります。そのようなリスクに対して、このタイミングで技術調査したり調査計画を立てます。場合によっては実績のある技術で代替することも考えます。

特に注意が必要となるのは最近多いサービスを利用して開発する場合です。クラウド上で開発する場合は便利なサービスが多く準備されているため、ミドルウェアのセットアップが不要となるため開発が効率的に進められる大きなメリットがある一方で、制約があることが多くあとで気づいた場合に大きな問題になることがあります。このような技術リスクを回避するため、クラウドは実際に使うことが容易なため、なるべく実際に使ってみて検証します。

最後に

いかがだったでしょうか?システム方式設計について理解できたでしょうか?

ITアーキテクトには、広い範囲の技術力、コミュニケーション能力、判断力、抽象化能力、経験などが必要であるといわれるのですが、そのことががよく分かるのがシステム方式設計ではないかと思います。

実際のところは一から考える・設計するということはあまりなくて過去のプロジェクト経験から「こういった場合はこうすのがいい」などと、ある程度ベストプラクティスがあります。
ではベストプラクティスがあるので、そのまま全部適用すればいいか?というとそういう訳にもいきません。お客様の要件であったり、前提・制約などはプロジェクト毎に異なりますのでそのまま適用できない場合も往々にあります。

さらにテクノロジが進歩していく中でより良い方法がでてきますので、過去のベストプラクティスだけに囚われず、自分自身も勉強して、より良い方向に改善していく必要があります。
そこがITアーキテクトの腕の見せ所かもしれません。