セミナー概要

抽象化した機能要件の定義からソリューションを組み立てるアーキテクチャ構築の設計手法を学ぶセミナー「アーキテクチャの基本のき」がBFT道場で開催された。システム設計やソフトウェア設計とアーキテクチャ設計とでは、考え方にどのような違いがあるのだろうか。IBMのDistinguished Engineerの経歴を持つ山下克司氏が解説する。

アーキテクチャとは

アーキテクチャとは一体なんなのだろうか。山下氏は次のように定義する。

「チームの共通の設計用語を定義し、設計の文化を共有すること」

チームにはさまざまな立場の人がいる。ビジネスを回す人、システムを開発する人、システムを運用する人などだ。こうした人たちの関心ごとを、十分に包括的に捉えた設計を目指さなければならない。だからこそ、設計用語を定義し、設計の文化をチーム全体で共有することが重要になってくるのである。ただ機能を設計すればいいということではなく、そのシステムはどのように使われ、今後どのようなライフサイクルになるのか、といったところまで考える必要があるのだ。

こうしたアーキテクチャを設計していくためには、要求の大枠から整え、徐々に詳細化していく「アウトサイド・イン」というアプローチを用いるといいと山下氏は語る。「そのシステムはなぜ必要なのか。そのためには何ができなければいけないのか。そのためにはどのような機能が必要なのか。このように、段階的にブレークダウンしていき、構造化していくという考え方が重要だ」

また、山下氏は、アーキテクチャの主要な視点として次の3つを挙げる。一つ目が「サービスアーキテクチャ（運用＝ビジネス）」だ。サービスが顧客にどのように提供されるのか、何をKPIとするのか、目標をどのくらいにするのかなどを設計する。次が「システムアーキテクチャ（ソフトウェア）」。静的な機能をどのように配置するかなど、ソフトウェア全体がどのように動くかを設計する。そして三つ目が「コンポーネントアーキテクチャ（機能）」だ。ひとつ一つのコンポーネントがどういう機能を果たしていくのか、また、品質や耐久性はどこまで求められるのかなどを設計する。

「こうした全体の設計ができたところで、実際にどういったテクノロジーを使うのかを選定していく。AWSなのか、オンプレミスなのか。AWSならアベイラビリティゾーンを東京にするのか、そのほかの場所も追加するのかなどを決めるのは、最後の工程となる」と山下氏は解説する。

独自の提案力と解決力

こうした全体の流れを把握し、独自の提案力や解決力を身につけていくことは、アーキテクチャ設計者として成長する上で、一つの方向性となるだろう。そのためには次の３つの能力を伸ばす必要があると山下氏は語る。

まず初めが「顧客を知る」能力だ。その顧客の置かれている業界や業務、社会動向なども含めて学ばなければならない。次に求められるのが「課題を探る」能力だ。顧客の持つビジネスの課題を深堀し、それを明らかにしていく。そして最後が「解決策を作る」能力。ここが、実際にアーキテクチャを構築する部分で、全体を抽象化し、先端テクノロジーの知識を活かした解決策を提案することが求められる。アーキテクチャとは、「共通の設計用語を定義すること」だと山下氏は説くが、もし共通言語がない場合、どうなってしまうのだろうか。

このことを説明する有名な絵があるので見てほしい。

「お客さんの要望を聞いた、コンサルタント、営業、プロダクトマネージャーのそれぞれ言っていることがバラバラだと、本当に顧客が求めていることが見えてこない。散々議論した挙句、結局、顧客の本当の要望は木にぶら下げられたタイヤだった、ということが往々にして発生するのだ」

エンジニアは時間を節約するために、すぐに設計図を描きたくなるかもしれない。しかし、そこにシステムの目的が書かれていなければ、共通言語として認識ができず、間違ったシステムを構築してしまうかもしれないのだ。「architecture ≠ 設計図」だと理解する必要がある。「サクラダファミリアは、ガウディの作った優れたアーキテクチャと言えるだろう。100年作り続けられるのは、共通の言語がその設計書に書かれているからだ。みなさんにも長持ちする設計書を書いて欲しいと思う」

既存システムからアーキテクチャを再構築する

ここで自動販売機を例に、アーキテクチャを構築する上で、具体的にどのように考えていけばいいのか練習してみよう。まず、どんな機能が必要なのかを観察する。サンプル展示、選択ボタン、コイン投入口、お釣りの自動認識、商品取り出し口、商品格納、冷蔵保温機、などといった機能が必要だとわかるだろう。

これを、より抽象化して考えると、次のようになる。

  • サンプル展示→商品プレゼン
  • 選択ボタン→ニーズ検知とコンバージェンス
  • コイン投入口＋お釣り自動認識→決済機能
  • 商品取り出し口→商品提供方法
  • 商品格納→提供バッファ
  • 冷蔵保温機→提供状態管理

こうして考えると、また別の側面が見えてくる。商品格納は別の倉庫にあってもいいのではないか。決済機能はコインだけではなく、バーコード決済なども必要なのではないか。商品提供のスピードが遅くてもいいのであれば、一時期話題となったアマゾンダッシュボタンのようなものでも自動販売機として成立するかもしれない。このように抽象化することで、自動販売機がより多面的に見えるようになってくるのだ。

ここまで「抽象化」という言葉を多用してきたが、これは英語の「Abstract」を日本語訳したものだ。しかし山下氏は、この日本語訳のせいで、大事な意味が抜けてしまったと指摘する。「Abstractとは論文などの導入部分で、本文を余すことなく短い文章で表現することを指すが、『抽象化』と言ってしまうと、何かを抜き出して把握すればいいと捉えがちになってしまう。日本人がアーキテクチャ的な思考が苦手なのは、ここに原因があるのではないかと思っている」

ソフトウェアによる抽象化

さまざまなハードウェアの性能がOSから制御可能になったという意味で、Android OSやiOSはエポックメイキングだったと山下氏は語る。

カメラやGPS、モーションセンサーといった多くのハードウェアがスマートフォンには内蔵されている。こういったデバイスを提供するメーカーの自由度を高めるために、ハードウェアアブストラクションレイヤー（HAL）がAndroid上には柔軟な形でセットしてある。「これにより、機能として提供されているモジュールに、ソフトウェアからアクセス可能になる。こうした仕組みを前提としているのがAndroid OSやiOSで、ソフトウェアの世界が広がった最大の理由だろう」

つまり、従来であれば、ハードウェアごとにソフトウェアを開発しなければならなかったが、OS上から直接扱えるようになってきているというのだ。これは、アーキテクチャとして、Hardware Abstraction Layerを定義したことによって実現できたもので、デイバイスの進化をアーキテクチャが支えていることが理解できるだろう。この流れはIoTのプログラミングモデルにも影響を及ぼしてきている。「工場のような現場でも、ソフトウェア主導のアーキテクチャに進化しつつある。Industry4.0ではハードウェアからソフトウェアの世界に置き換わっているのだ。日本の製造系のOTベンダーは置いていかれないように頑張ってほしい」

Operation Modelingの手順

アーキテクチャをアウトサイド・インで構築する際には、二つの側面を考える必要がある。どんな機能があるのかを導き出す「静的側面」と、その機能同士がどういう動作モデルになるかを考える「動的側面」だ。「動的側面には、システム全体のコンテクスト描くことや、ビジネス運用の設計なども含まれており、近年はより重要度が増してきている」と山下氏は説明する。

こうした設計をしていく中で、各分野において作図する必要があるが、その中でも重要なのが「システムコンテキスト図」だ。そのシステムが成り立つためにはどのような要素が必要なのかをまとめていく。「この『システムコンテキスト図』では、システムの境界を定義し、その境界を越える情報のやり取りを識別できるようにする。また、システム境界内で開発チームが制御できる範囲を定義する必要もある」と山下氏。

このとき大事なのは、関係するステークホルダーを漏れなく整理することだ。そのためには、次の４つのステークホルダーを意識するといいと山下氏は説く。一つ目が、ビジネストランザクションの発生源である「顧客」。二つ目がビジネスの成果に関心を持つ、経営企画や社内担当部門である「ビジネスオペレーション」。三つ目が、システムの運用と改善を行う「システムオペレーション」。そして最後が、会計システムなど、連携する必要がある「対外システム」だ。

「このようにシステムコンテキスト図は非常に複雑になりやすい。これら４つのドメインごとに書き分けることもある」と山下氏は説明する。次に、非機能要件の設計について見ていこう。非機能要件とは、性能やセキュリティなど機能以外の実現すべき要件のことだ。山下氏は、主要な非機能要件として「可用性および信頼性」「性能と容量」「運用性」「セキュリティ」の4つを挙げる。

「最近はクラウドを利用することも多く、システムの停止が他責の場合が多い。システムが止まってしまうことを前提に設計することが流行ってきている。クラウドでやるのに、オンプレミスのような可用性を求められたときは、よくよく説明したほうがいいだろう」システムにとって本当に大切なKPIは何かを経営者と握っておき、意味のない高い性能を求められたときには、アーキテクトの観点からそれが不要であることを説明できるスキルが求められる。

コンポーネントを設計する上では、MECE（Mutually Exclusive and Collectively Exhaustive）という考え方が基本となる。「同じ機能を2箇所に作ったりしてはいけない。何か変更があった場合に同じように変更しなければならなくなるからだ。この『MECE（漏れなく、ダブりなく）』の考え方を身につけてほしい」

こうしたコンポーネント動作モデルができたら、関連するステークホルダーの周辺機能を統合し、全体図として包括的に捉えることが重要だ。「UIやUX、セキュリティなどの周辺機能のほうが、ソフトウェアとしては重い場合が往々にしてある。中心機能だけに目を奪われないようなアーキテクチャを作っていくことが大切だ」と山下氏は語った。

アンケート結果紹介

セミナー後のアンケートでは、多くの受講生が「システムアーキテクチャ設計に興味があった」と答えている。そしてその大半が「役に立った」と回答してくれた。しかし、今回は概念的な話も多く、理解が難しかった部分もあったようだ。「実務にどのように生かせるのかイメージしながら聞いた」という受講生もいた。アーキテクチャ設計は、実践経験を積みながら、その勘所を体得していく必要があるのだろう。今回のセミナーがその足がかりとなり、成長のきっかけを掴んでもらえればと思う。

本セミナーは、BFT道場の教育サービスご契約者、受講者であれば誰でも受講できる無料セミナーとして実施した際の内容をレポート化したものだ。
BFT道場では現役のインフラエンジニア講師による実践型IT技術研修を提供している。詳しくはBFT道場をご覧いただきたい。