そのボタンを押したら何が起きるのですか？～アーキテクチャは利害関係者のコミュニケーション手段

「実践ソフトウェアアーキテクチャ」を読んでいたら、アーキテクチャと利害関係者、特に要求を出すユーザとの関係について、興味深い挿話があった。
ソフトウェアアーキテクチャについて再考してみる。

【ストーリー】

政府支援のITプロジェクトは、スケジュール遅延・予算超過で問題となっていた。
政府は過去の怠慢を何とかしようとして、マラソンのような長時間のプロジェクトレビューが始まったが、ユーザでもありプロジェクトを管理する政府の代表者たちは疲れきっていた。

とある午後、議題は、システムのソフトウェアアーキテクチャ。
若いアーキテクトが威勢良く登場して、巨大なシステムのソフトウェアアーキテクチャが、信頼性や可用性、効率性などの要求をいかに満たしているかを説明し始めた。

アーキテクトは、四角や線の表記法で描かれた図で、システム実行時にどんなソフトウェア要素が動くか、つまり、データフロー、メッセージパッシング、プロセス同期について、理路整然と説明した。
その記法はアーキテクトが作ったものだが、中身の詰まったプレゼンテーションだった。

「障害が発生した場合は、、、」とアーキテクトはレーザーポイントを使って説明し始めていた。
突然、
「そのモード選択ボタンを押すと何が起きますか？」
と聴衆の一人が質問した。
彼は、そのシステムのユーザコミュニティを代表する政府出席者だった。

「もう一度、ご質問を」とアーキテクトは聞き返す。
「あなたがそのボタンを押すと何が起こりますか？」とユーザ代表者は尋ねた。

「えーと、それはこのデバイスドライバのイベントをキックし、、、」とアーキテクトは続けて、
「イベントを判断し、モード選択ならば、表示板に信号を点灯させ、そのイベントを処理するオブジェクトへ信号を送ります。」
と答えた。

「いいえ、私は、システムは何をするのか、と聞いたのです」とユーザ代表者は遮った。
「表示をリセットするのですか？　システムの再構成中にこのイベントが発生したら何が起こるのですか？」

アーキテクトは少し驚いて動揺して、レーザポインタを落とした。
アーキテクチャについての質問ではなかったが、アーキテクトである彼は、要求に精通していたので、答えを知っていた。
「コマンドラインが設定モードであれば、表示はリセットされます」と彼は答えた。
「そうでなければ、エラーメッセージが制御用コンソールに表示されますが、信号は無視されます」と続けた。

「私の質問は」とユーザ代表者は言った。
「あなたの図を見ると、表示用コンソールは信号をターゲット位置のモジュールへ送っているように見えます。」
別の参加者が質問した。
「何が起きるのですか？」

「システムを再構築する間、本当にユーザにモード情報を取得させたいと思っているのですか！」
と更に別の参加者が尋ねた。

そして、それに続く45分間、ユーザ代表者を含む参加者は、様々な難解な状況において、システムの正しい振る舞い(つまり仕様)は何か、について討論し続けた。

この討論はアーキテクチャに関するものではなかったが、アーキテクチャが論争に火を付け、アーキテクトや開発者以外の利害関係者(つまりユーザ)のコミュニケーションの基盤となった。

実は、ユーザはアーキテクチャ説明の前に延々と、機能、操作、ユーザインターフェイス、品質に関して説明を聞かされていた。
ユーザは皆、もう帰りたいと思っていたはずだ。

だが、アーキテクチャに関するスライドが、ユーザに何を理解していないのかを自覚させた、と。

【1】アーキテクチャは開発者だけでなく、要求を出すユーザにも役立つ

「実践ソフトウェアアーキテクチャ」の上記のストーリーが興味深いのは、アーキテクチャという設計者と開発者にしか関係しないと思われる内部書類が実は、要求を掘り起こすものだったという事実だ。
つまり、新しい方法でシステムをみる観点が考えを刺激し、新たな疑問を表面化させた。

ユーザは、システムがどのように機能するのか、という観点よりも、システムが何をするのか、をいつも興味を持つ。
アーキテクトは、ユーザがアクセスできる最初の専門家であるため、ユーザはためらうこともなく、質問を浴びせかけただけ。

公的システムなのだから当然、要求仕様書はあったろうが、アーキテクチャが実装と仕様と要求をつなぐミッシングリングになっていた。

何故実装に手間取るのか、何故この機能は実装できないのか、という理由は、アーキテクチャの仕様に由来すると言っていいから。

【2】アーキテクトは、設計する人ではなく、調停者である

「実践ソフトウェアアーキテクチャ」はソフトウェアプロダクトラインの解説本なのだが、この本を書いた佐々木さんが以前、SEA関西で講演された時があり、印象に残った内容がある。

それは、ソフトウェアプロダクトラインが定義するアーキテクトの役割は、設計者だけではなく、顧客や開発者、そして会社の上司に当たる管理者へ、システムとアーキテクチャを説明することだった。

つまり、アーキテクトは調停者なのだ、と。

「実践ソフトウェアアーキテクチャ」の上記の話では、アーキテクトがユーザに対して、要求とシステムの仕様が一致しているのか、矛盾していないか、という討論になった。

普通は、アーキテクトは開発者へ、こういうフレームワークを使って、こういう仕様とこういうコーディングルールで書いてくれ、と説明し指示するだろう。
アーキテクトから管理者へは、このアーキテクチャで実装すると、これだけのコストがかかりますが、その後の運用保守では楽になります、品質も保証されます、のように回答するだろう。

アーキテクトは、アーキテクチャという抽象概念、つまり設計思想によって、ユーザ・開発者・管理者へ3通りの観点で、システムを翻訳し直す技術力と政治力を必要とする。
つまり、アーキテクトはシステムの説明責任を負う最終責任者であると言える。

「実践ソフトウェアアーキテクチャ」の上記のストーリーの話題は、信頼性という品質に関わるもの。
アーキテクチャの話は、その根本を辿ると、品質特性に位置づけることができる。
例えば、効率性、使用性のような外部特性だったり、保守性、移植性、可読性のような内部特性だったり。

ソフトウェアプロダクトラインの話を聞くと、必ず、品質と再利用の話になるが、その理由は、アーキテクチャと品質が密接に関わっているからだろう。

品質という眼に見えないもの、そして利害関係者の認識がなかなか一致しないものを対象とするのが、システム屋の仕事。

品質について、もっと考えてみたい。