榊原さん「ITアーキテクチャ設計とITアーキテクトの着眼点」(SQiP研究会特別講義)

あきやま🍠 @akiyama924

本日はSQiP研究会です。午前中の特別講義は、日本アイ・ビーエム（株）の榊原彰さんによる「ITアーキテクチャ設計とITアーキテクトの着眼点」です。さきほど、ツイートのOKをいただいたのでツイートします。

あきやま🍠 @akiyama924

司会は細川さん「元私の上司でした。配属されたときに挨拶したら、翌朝机の上にハードカバーの本をドンッと5冊くらいおいてくれた人です。昨日の午前3時にできあがった資料だそうです（笑）」

あきやま🍠 @akiyama924

榊原さん「今日のお話は、エンタープライズ系の話なので、組込み系の方は置き換えながらきいてください。

あきやま🍠 @akiyama924

榊原さん「大学で経済数学を学びました。数式をプログラムしていたらそちらが面白くなってしまって、IBMに入社しました。

あきやま🍠 @akiyama924

榊原さん「最近は、スマーターシティ事業のCTO、社会をITを使って便利にしようという仕事をしています。

あきやま🍠 @akiyama924

榊原さん「今日の話の内容は、『システムアーキテクチャ構築の原理』、『システムアーキテクチャ構築の実線手法』を読んでいただくと復習できます。

あきやま🍠 @akiyama924

榊原さん「アーキテクチャを作る人をアーキテクトと呼びます。アーキテクチャを構築する活動をアーキテクティングと呼んでいます。元々、建築の言葉ですから、ソフトウェアアーキテクトとか枕詞を付けます。

あきやま🍠 @akiyama924

榊原さん「ソリューション・アーキテクチャは一つのソリューションを提供する際の様々な局面の集合体です。たとえば、ビジネスの切り口ならビジネス・アーキテクチャと呼びます。

あきやま🍠 @akiyama924

榊原さん「ITはハードウェアが必要です。箱、ネットワーク、監視などの攻勢を決める部分をインフラストラクチャ・アーキテクチャと呼びます。

あきやま🍠 @akiyama924

榊原さん「エンタープライズ・アーキテクチャという言葉があります。全社的な見方において、色々なソリューション・アーキテクチャが一つのアーキテクチャガバナンスものもとで整合性を持ってコントロールされている構造・取り組みを言います。

あきやま🍠 @akiyama924

榊原さん「数名のプロジェクトならアーキテクトはいらないかもしません。しかし、プロジェクトの規模が大きくなると、アプリケーションの配置や、ネットワークトポロジー等々の意思決定をする必要が出てきます。それぞれのアーキテクトを統括する人をリードアーキテクトと呼びます。

あきやま🍠 @akiyama924

榊原さん「それぞれのアーキテクチャを崩したり整えたりしながら、総合的な意思決定をする必要があるからです。アプリケーションを上手く動かすためにネットワークトポロジーを一部崩したり、そういったプロジェクト全体のアーキテクチャを統合する人がリードアーキテクトです。

あきやま🍠 @akiyama924

榊原さん「リードアーキテクトは、プロジェクトが終わった後も、システムがきちんと動くことに責任があります。プロジェクトマネージャよりタイムスパンが長いです。

あきやま🍠 @akiyama924

榊原さん「アーキテクチャという言葉に対する共通理解がありません。名刺にアーキテクトと書いていた時代もありますが、お客様に怪訝な顔をされました(笑)。

あきやま🍠 @akiyama924

榊原さん「色々な本を読むと違った書き方をしているので一つだけにしてください。IEEE 1471では、こういう定義です。（続く）

あきやま🍠 @akiyama924

榊原さん「（続き）アーキテクチャ：コンポーネントを統合したシステムの基本的な構成，コンポーネント相互およびコンポーネントと環境間の関係，そしてシステム設計と進化を導く原則　……となっています。

あきやま🍠 @akiyama924

榊原さん「簡単に言うと、分け方とつなぎ方－ー－全体をどう切り分け，部分をどのように関係づけるかーーーです。

あきやま🍠 @akiyama924

榊原さん「システムは何かのミッションを満たすために一つのアーキテクチャを持ちます。アーキテクチャの怪しさがどこからくるかというと、目に見えないことです。だから、アーキテクチャ記述が必要となります。ステークホルダーを認識して、そのしたいことや関心事を根拠づけのために書きます。

あきやま🍠 @akiyama924

榊原さん「ステークホルダーには様々な人がいます。いうことがみんな異なります。そういう人々のコンサーン（関心事や視点）を整理する必要があります。整理する時には共通のルールを持った表現（モデル）を用います。そうすることで文章で書くよりも誤解が無くなりコミュニケーションが高まります。

あきやま🍠 @akiyama924

榊原さん「アーキテクチャは開発の初期段階で考えることがほとんどです。しかし、今は必ずレガシーシステムがあります。便利な反面、設計の制約条件にもなります。

あきやま🍠 @akiyama924

榊原さん「アジャイルでは、ちょっとずつ作ればよいと考える人がいます。しかし、全体に関わるアーキテクチャは（漸進的ではなく）開発の初期段階で決める必要があります。ちょっとずつアーキテクチャを作るなんてありえません。

seki at druby.org @m_seki

@akiyama924 うちはつくるよ

あきやま🍠 @akiyama924

榊原さん「アーキテクトは怖がりの方が良いです。小さなプロトタイプで方式が良いかを検証して進める。少ない情報の中でいかに技術を選択するかが大切です。

あきやま🍠 @akiyama924

@m_seki あら。うちもです。

あきやま🍠 @akiyama924

榊原さん「時系列でみると、分からないことが最初とても多いです。必要な情報を増やすことでリスクを減らしていきます。はじめのころは「判らないことに対するリスク判断」後半は「判ることに基づいたアーキテクチャ上の（設計）意思決定」です。