Groningen大学のDan Tofan氏がアーキテクチャ決定の記録と評価のためのオープンソースソフトウェアツール、RGT (Repertory Grid Tool) をソフトウェアアーキテクト向けに提供している。このツールを使うことで、アーキテクトはアーキテクチャ決定理由をうまく文書化でき、あとでふりかえることが可能になる。
複雑なソフトウェアシステムのアーキテクチャを構築するには、数多くの重要な決定を下す必要がある。これらの決定において、アーキテクトはビジネス目標および技術目標を満足させ、機能要件と非機能要件に関するステークホルダの関心を解決する必要がある。さらにアーキテクトは「この決定に際して、実行可能な案について十分検討しただろうか」といった決定プロセスの品質も検討する必要がある。
こうしたアーキテクトを支援しようと、Groningen大学のソフトウェア工学研究者がアーキテクチャ決定をサポートするツールを提供した。このオープンソースツールに関する詳細についてはhttps://github.com/danrg/RGT-tool/wikiを見てほしい。
以下はツールの開発をリードするDan Tofan氏とのQ&Aだ。
InfoQ: あなた自身と研究について、簡単に紹介してもらえますか？
私はソフトウェア開発者です。6年間現場で仕事をしたあと研究者になりました。私の研究目標はソフトウェアアーキテクトの意思決定を改善することです。
InfoQ: RGTの背景にある動機は何ですか？どうやってそれをあなたの活動の全体像に合わせていますか？
アーキテクトにとって、意思決定スキルは重要だと考えています。これはソフトウェア設計のためだけでなく、ほかのステークホルダに適切な根拠を提供するためです。ですから、水泳や料理と同様、意思決定をスキルだと見なせば、次の論理的ステップはこう自問することです。どうすれば自分のアーキテクチャ決定スキルを改善できるのだろうか？と。
意思決定は決定についてのアーキテクチャ知識を記録することとオーバーラップします。知識を記録するには確かな手順が必要です。RGTを使ってアーキテクチャ決定を記録することには、2つの大きな利点があります。アーキテクチャ決定についての知識が保持されること、そしてアーキテクトが意思決定スキルを改善できることです。
InfoQ: RGTについて説明してもらえますか？
RGTのステップは次のようになります。まず決定すべきトピックについて合意します。次に、そのトピックに関する案を述べていきます。それから、似ているけれども3つ目とは違う2つの案をピックアップします。次に、その2つがどう似ていて、どう違うのか説明します。これが関心（RGT用語ではコンストラクト）になります。たとえば、JavaとC#は似ています。「大きなベンダーに支持されている」ためです。これは「コミュニティの支持」をベースとするRubyとは違います。たくさん関心を引き出せたら、次のステップはそれぞれの関心に対して各案をレーティングすることです（通常1から5で）。そして、こうして得られた案、関心、レーティングのマトリックス（もしくはグリッド）を分析します。たとえば階層クラスター分析をして、類似性に基づいて案と関心をグループ化するなどします。最後に、アーキテクトは案や関心、レーティングをアップデートすることで、グリッドを改善していきます。その結果得られたグリッドは、アーキテクトのメンタルモデルを反映します。
全体として、このグリッドとクラスターは決定を説明する圧縮されたドキュメントになります。これはテキストで記述したものと比べて、意思決定のより明確なオーバービューになっています。
InfoQ: RGTの典型的なユースケースは何ですか？
典型的なユースケースは4つから9つの案があるようなアーキテクチャ決定を記録することです。案があまりない場合、RGTはやりすぎでしょう。案がもっとある場合、RGTは時間がかかりすぎるでしょう。
InfoQ: RGTは現場にどんな効果をもたらしますか？
RGTは決定を記録するシステマティックな方法を提供します。また決定に関する新しい洞察を生む手助けをします。RGTはアーキテクトに、その決定についてもっと考えさせます。そして最後に、RGTは決定に関する簡潔なドキュメントを提供します。
ただしRGTにも欠点があります。大きな欠点は、RGTには時間がかかることです。そのため、注意深く検討する必要のある、重要な決定をするときに向いています。ソフトウェアアーキテクトにとって、これはよくある状況かもしれません。アーキテクトとRGTについて議論すると、彼らはよく、課題のようなツールのサポートがない、とよく言います。ですから、私たちはそこを改善しようとしたのです。
InfoQ: このツールのメイン機能は何ですか？
まず、このツールはアーキテクトが個々の決定のグリッド入力を支援します。次にこのツールは、既存のグリッドから始めて、協調的な意思決定まで可能にします。ステークホルダのグループ間の相違を明確にして、グリッドを埋めるのに複数の円を使ってコンセンサスを得ます。
それから、大事なことを言い忘れていました。ツールはオープンソースで（https://github.com/danrg/RGT-tool）http://repertorygridtool.comにデプロイされています。
InfoQ: RGTのユーザからどんなフィードバックを得たいですか？
研究成果が業界に受け入れられるまで、通常はかなり長い年月がかかります。10-15年かかると言う人もいます。対象とするユーザからのフィードバックは、導入までの時間を短くするのに非常に重要です。私は2種類のフィードバックを期待しています。RGTに関するものと、ツールに関するものです。
ですから、私はRGTが彼らの意思決定にどう役立ったのか聞きたいです。
ツールがオープンソースになって以降、私はツールに対する提案、バグレポート、コードへの貢献に関心をもっています。このツールに関する小さなコミュニティを作りたいと思っています。
InfoQ: Grady Booch氏は以前こう言いました「愚か者がツールを使っても、愚か者のままだ」。アーキテクトが実際にRGTを効果的に効率よく利用しているか、どうやって確かめるのですか？
ツールを最大限に活用するには、ポイントが3つあります。第一に、適切なタイミングと場所で、RGTを使っているか確かめましょう。RGTはニッチなテクニックです。あらゆる決定を釘と見なして、RGTをハンマーのようなものとして使ってはいけません。第二に、RGTを学ぶ時間を投資しましょう。第三に、まず過去のアーキテクチャ決定から使ってみて、それから徐々に現在取り組んでいる決定やグループ決定に移りましょう。最後に、経験を共有してください。私もお手伝いしたいと思っています。
InfoQ: RGTやあなたのアプローチについて、次のステップとして何をする予定ですか？
次のステップは、関心について別案を評価するときに、ユーティリティ関数を表現できるようにすることです。 これは現在の基本的なレーティングと比べて、より正確な評価になるでしょう。さらに私はリスクマネジメントの機能を追加したいと考えています。それから、もうひとつのステップは、複合的な決定を実装することです。そこでの案は、より多くの「アトミックな」決定オプションの組み合わせになります。複合的決定は設計空間のより徹底的な調査を可能にし、適切な組み合わせが見落されないようにします。