左)松本先生/右)弊社・森屋

左)松本先生/右)弊社・森屋

孫悟空とソフトウェアアーキテクト

公益財団法人 京都高度技術研究所 名誉顧問 工学博士
元京都大学教授 松本 吉弘
2014年1月

株式会社アークウェイの創立10周年を記念して

「アークウェイ社10周年おめでとうございます.私が森屋さんにお会いした時に、当時人気のあったテレビ番組の『行列のできる法律相談所』にかけて、『行列のできるソフトウェア設計事務所』を作ってはどうだろうかと提案しました.それから10年の間でかなりの形が出来てきていることを大変嬉しく思います.今後ともより一層のご発展をお祈りしています.」

以前、森屋さんとソフトウェア開発・保守の土台になっている原理・原則とはなんだろうかという疑問及びそれの応用についてディスカッションを行いましたので、ここではその概要をご紹介します.

1.原理・原則
子供の頃、親しんだ孫悟空の寓話で、如意棒を使って觔斗雲(きんとうん)を呼び寄せ、それに乗って無限空間の果てまで飛んでいったと思っていた孫悟空が、落ち着いて周りを見回すと、それは出発したときと同じお釈迦様の手のひらの上であった.お釈迦様の手のひらの中を動き回っていたに過ぎなかったということに気付いたという話があります.

ソフトウェアアーキテクトの皆さんは、觔斗雲に乗って一歩でも遠くへ、速く飛んで行きたいと思っていませんか?ちょっとで良いから、自分の仕事を真に支えてくれているテクノロジ(御釈迦様の掌と指)は何かを、考えてみてくれませんか?それは、ごく少数の、基本的な原理・原則ではないでしょうか?私がアーキテクトの皆さんのご賛同を得たいことは、アーキテクトそれぞれが、自分の生計を立てているドメインの真底にある原理・原則に早く気づき、それを体で実現できる能力をもつことが必要ではないか?ということです.

2.原理・原則の学習
私事をお話しすることは恐縮ですが、これまでの私を支えているのは、昭和30年代(1960年の前後)に、アリゾナ州フェニックスで受けたGE社の訓練です.アセンブラ言語でアプリケーション、小さな実時間OS、コンパイラを書いて、自分でデバッグ・テスト実行して、教官に採点してもらうという訓練です.徹夜が何か月か続きました.このおかげで、どんな新しいテクノロジが俎上に乗っても、この年齢(82歳)になっても容易になじむことができます.私は、1970年代に東芝で大規模なソフトウェア工場を立ち上げ、ソフトウェアエンジニアリング環境を開発・実用化しましたが、アメリカのBarry Boehm氏などがそれを見に来て、現在の「ソフトウェアプロダクトライン」という構想を1980年代にSEI/CMU (Software Engineering Institute/Carnegie-Mellon University) で完成させました.SEI/CMUでその担い手になったKyo Kang 氏は、1980年の中ごろ、私がミシガン大学の大学院で指導した学生のひとりでした.原理・原則の学習には、書店に溢れている平積み本やウェブサイトを読み、セミナ、会議に出席することも必要ですが、もっと身近なところに学習の種があるように思います.

最近でも森屋さんとお会いすると、必ず現在の顧客対応のもとになっている原理・原則について議論しています.

3.事業を立ち上げるための原理・原則の発見
アークウェイ社を創設された森屋英治氏と初めてお会いしたのは、2000年代に入ってからです.当時、アークウェイ社は、四谷4丁目の大木戸門の近くのマンションにありましたが、何回か、お邪魔して、エンタプライズ情報システム開発・保守の真底にある原理・原則を一緒に研究・探索しました.

出発点になったのは、ソフトウェア構成要素と、その相互間の依存性でした.エクセルの行項目および列項目を、エクセルマクロを使って階層化し、そのエクセルの上に、エンタープライズアプリケーションのdesign structure matrix を描くことができないか、を研究しました.この結果、生まれた概念が、図1に示す、アプリケーション開発・保守の基本フローです.この図において機能別振る舞い記述からインタプリタで生成したコードをシミュレータで動作させて確認するようになっていますが、この作業を繰り返し行うことで詳細化が行われていきます.この流れをアークウェイ社ではジグザグ開発と呼び実践の場で活用しているとのことです.

図1 機能要求と非機能要求から始める開発・保守基本フロー

図1 機能要求と非機能要求から始める開発・保守基本フロー
•機能要求の静的構造は、ユーザエクスペリエンス/ビジネス/制御/データまたはサービスという層 (tiers) に分離され、そのなかに包含されるコンポーネント間の静的依存性および動的協働は、フィーチャダイアグラム、ディシジョンテーブル、スクリプト言語、データモデルなどによって記述されます.
•非機能要求からは、目的ドメインに適合するアプリケーション・アーキテクチャおよびアーキテクチャ部品が生成されます.
•工場内開発・保守支援環境で、まず、機能別振る舞い記述が、アーキテクチャおよびアーキテクチャ部品とインタプリタによってバインドされ、テスティング環境と連結して、テストされます.
•テストが顧客の満足を十分満たしたことが確認されれば、すべてのコードがコンパイルされ、プラットホームおよび計算システムハードウェアに実装されます.

上記の流れはイテレーションにより繰り返し実施されます.上で述べたアーキテクチャについて、もう少し詳しく説明します.アプリケーション・アーキテクチャは、共通部(固定部)と可変部に分けて管理できます.通常、ソフトウェアファクトリのなかでは、複数のプロジェクトが並行して開発・保守プロセスを実施しています.同じアプリケーションドメインをターゲットにしているプロジェクトは、同じ、アーキテクチャ共通部を使用できます.アーキテクチャ共通部には、そのプロジェクトに適合するアーキテクチャ可変部を選択して組合せます.アーキテクチャ可変部は、可変部パターンとアーキテクチャ部品から構成されます.パターンおよび部品は、プログラミングコードの集合体で、プロダクトラインで管理されています.図2に、アーキテクチャにおける共通部と可変部に関する概念を図示してあります.

図2 アーキテクチャにおける共通部と可変部

図2 アーキテクチャにおける共通部と可変部
この図は1つのアプリケーション ドメインを表していますが、アークウェイ社は様々なドメインの顧客にアーキテクチャを提供するため、この図を複数束ねた形態になります.ドメインが共通であれば複数のアプリケーションで共通部が再利用でき、資産として保守の対象となります.

4.アーキテクト組織
最後に、アーキテクト・チームの編成と、チーム間のコミュニケーションについて説明します.アーキテクト・チーム相互間の対話空間をセル(cell) と呼びます. アーキテクト・セルは、プロジェクト始動から、製品棄却に至るまでの全ライフサイクルをカバーする必要があります.アーキテクト・セルには、垂直と水平があり、格子 (grids) を形成します.水平セルの一例を、図3で示してあります.水平アーキテクト・セルは、製品ライフサイクルを横断して維持しなければなりません.水平セルを構成するアーキテクトは、固定した特定の人材であることを前提としません.ハードウェア生産セルと同じように、ガイド、部品、ツール、成果物リポジトリおよびペルソナの集合体です.その時点でのロール(役割)とスキルによって割り当てられたアーキテクトが、水平セルのなかに入ります.

図3 アーキテクト・セルグリッド

図3 アーキテクト・セルグリッド
垂直セルは、プロジェクト始動から製品棄却に至るライフサイクル上で決められるベースライン上で、水平セル相互間で行われる対話、業務・改善計画および構成管理を実現するために設ける物理的または仮想的スペースです.最近の航空機事故が源になって、航空機搭載ソフトウェア開発・保守プロセスでは、図3に示したようなセル・グリッドモデルが、定常的に採用されていることが紹介されています(出典: 2011 17th IEEE Pacific Rim International Symposium on Dependable Computing; 表題: Dependability Improvement for Critical Digital Systems; 著者: Herbert Hecht; 所属: SoHaR Incorporated, Culver City, California, USA).

このことは、森屋さんが主張されている、アーキテクト組織に近いと思われます.アークウェイ社ではアーキテクト組織がアーキテクチャ及びパターンの選択及び保守を行い、資産として管理していくとともに、資産にはユーザーマニュアル、アーキテクチャ ガイド、トレーニングが含まれており、新しいメンバーに対してアーキテクチャ資産が活用できる仕組みを作っています.

5.むすび
以上、述べたことには大きな落とし穴があることに気づかれた方はいないでしょうか?そうなのです.運用に入ってから垂直アーキテクト・セルで決定した変更を、運用中のシステムにランタイムに実装できなければ価値がないのです.ヨーロッパでは、運用に入ってからの機能要求の追加・変更を、情報システムを止めないで、ロード、バインド、統合する研究が進んでいます.私にも、スウェーデン、スペインの大学研究者から声がかかりました.スマートシティ/スマートホームのソフトウェアシステムでは、このことは、必須事項だというのです.このことができるようになると、開発時点では想定外であった環境変化に対して、情報システムを適時に適応させることが可能になります.現在、スウェーデン、スペインの大学研究者とメールを通して、様々な視点から議論をしています.アークウェイ社でも将来は実行時適応の技術が採用されるようになると思います.興味のある方、お申し出があれば、この議論のサークルに喜んでご招待します.