アーキテクチャ設計に品質特性を使おう

アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。

このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。

1. 利害関係者にインタビューをして重視しているポイントを聞き出す
2. そのポイントからシステムに求められる品質特性を整理する
3. 整理された品質特性を元に、実際のアーキテクチャの設計を行う
4. 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う

品質特性というのは色々なところで定義がありますが、経産省が公開している「情報システム/ソフトウェアの品質メトリクスセット」というのがよくまとまっているので紹介します。この資料は様々なソフトウェア品質についての資料を統合し、いまの状況に合うように整理したものです。

情報システム／ソフトウェアの品質メトリクスセット（PDF）
情報システム/ソフトウェアの品質メトリクスセット 利用ガイド（PDF）

この資料で定義されている品質特性は以下の通りです。8つの品質特性と、それぞれに副特性が定義されています（細かい説明などは資料を参照ください）。

• 機能適合性
  • 完全性
  • 正確性
  • 適切性
• 性能効率性
  • 時間効率性
  • 資源利用性
  • キャパシティ
• 互換性
  • 共存性
  • 相互運用性
• 使用性
  • 適切度認識性
  • 習得性
  • 運用性
  • ユーザエラー防止性
  • ユーザインタフェースの快美性
  • アクセシビリティ
• 信頼性
  • 成熟性
  • 可用性
  • 障害許容性
  • 回復性
• セキュリティ
  • 機密保持性
  • インテグリティ
  • 否認防止性
  • 責任追跡性
  • 真正性
• 保守性
  • モジュール性
  • 再利用性
  • 解析性
  • 変更性
  • 試験性
• 移植性
  • 順応性
  • 設置性
  • 置換性

これを参照しながら評価する軸を決めていくと抜け漏れなくできると思います。使用性とか保守性とかは抜けがちですよね。

重要なことは上記全てについて検討をすることです。利用ガイドには「全てのメトリクスを利用する必要はありません。情報システム／ソフトウェアの特性に合ったメトリクスを選び、」とはありますが、全ての視点で考えてみるというのも非常に大事です。思いつかないから抜くのではなく、ひねり出すぐらいの心づもりで考えた方が抜け漏れがなくなる気がします。

品質特性を使ったアーキテクチャ評価としてはATAM (Architecture Tradeoff Analysis Method: アーキテクチャトレードオフ分析方法)が有名だと思います。日本語の本としては「実践ソフトウェアアーキテクチャ」ですので、読んでみるのもよいかと。

とはいえ、これは形式的にまとめられているだけなので、本当の実践には様々なアプローチが必要です。こういう具体的なところを書きたいのですが、なかなか文章になりにくく断念しました。勉強会もしにくいし、どうしたらいいんですかね。伝えたいとは思っているのですが...。

エンタープライズから見たImmutable Infrastructure

Immutable InfrastructureとかDisposable ComponentsとかBlue-Green Deploymentが話題になってるみたいで。

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編） － Publickey

詳しくは記事を。「不変のインフラ」つまり、一度動くようになったサーバーには手を触れず、なにか変更が発生したら新たなサーバーを別途構築し、丸ごと入れ替えることでシンプルな管理が可能になるというもの。「インフラ設定を自動化する」という流れとして見ると非常に面白い。

言いかえれば「アプリからインフラまでを一貫して構成管理する」ということになると思います。ソフトウェアの動的な状態を「サービス」という言葉で表現するなら、「サービスの構成管理」といっても良いでしょう。

とはいえ、エンタープライズの人間としてはモジュラリティの管理ができないと、Immutable Infrastructureにも限界があるなと思うわけです。

ある一つのサービスが構成管理されることは良いのですが、そのサービスを利用するサービスとの関係はどうするのですか？と。

単体のサービスを単体としてバージョンアップすることは、言ってしまえばそんなに難しくない。ただ、ソーシャル系はエンタープライズに比べてリリース頻度が多いので、毎回の作業が大変だから自動化するのはよくわかります。

（ちなみにエンタープライズのリリース頻度が少ないのは関係各部署との調整が多いからであって、いわゆる文化の問題ではありません。エンタープライズは安定していることが価値であり、それが社会基盤としての役目です。文化は現象であって原因ではないのです）

でもサービス同士の関係性が強い場合、単体のサービスの変更は周辺のサービスに影響を与えます。そうすると、そこだけ自動化されていてメリットは少ないのです。

じゃ、サービス間に関係性があるもの全部、たとえば企業システム全体を巨大な一つのサービスとすればいいじゃんと言っても、じゃ、取引先はいいんですかとか、言い始めればきりがありません。そもそも、他人様のものですし。

つまり、エンタープライズの場合は、単体をきちんと管理するというだけではなくて、単体同士の関係性や全体としての整合性という別の次元をきちんと管理する必要性がある。

そうなるとエンタープライズからみたときにImmutable Infrastructureに投資するメリットって何だろうなと思います。

いつも通りの話です。Immutable Infrastructureは有益な概念ですが銀の弾丸じゃない。

エンタープライズでは「システム全体におけるサービス間の変化の差異をどのように管理するか」というテーマを考えないといけません。モジュラリティ管理ですね。

Immutable Infrastructureのような概念の登場は本当にワクワクしますが、それをさらに応用して、よりスピード感のあるエンタープライズシステムを構築するにはどうしたらいいか、まだまだ考えるべきことは多いのです。

アーキテクトと要求もしくは技術について[追記あり]

2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。

前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。

要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出来ません。4つの要素が調和してこそ、はじめて良いサービスにつながるのです。特定の要素に縛られすぎずに視野を広げて、各要素を整合させることこそが重要でしょう。

ここ最近は、どちらかというとDevOpsやアトラシアンの話をすることが多かったので、改めてアーキテクト／アーキテクチャの話がきちんとできたので非常に楽しかったです。お誘いただいた皆様、ありがとうございました。

それぞれのイベントでの気づきをメモ程度に。

要求開発アライアンスでは質問をきっかけに懇親会で「いかに変化し続ける要求に対応すべきか」という話になりました。おそらく４つの要素だけでは難しくて、もっと高レベルな意味での「利害関係者間での目的の共有や信頼関係」というようなことが必要になるかと思います。

どんなに優れた人間でも予言者ではありません。未来は常に不確定です。よってプロジェクトを進めるなかでは様々な不測の事態が発生するわけですが、それには「対処し続ける」という事でしかゴールに近づけません。これは、決して1人では出来ないのです。顧客、仲間、その他大勢の人の協力なしに乗り切る事はできません。こうした、泥臭いというか、非常に人間臭いことがITサービスの提供には欠かせないものでしょう。

ただ、まぁ、これだけを取り出して「みんなの信頼が大事だ」と声高に叫んでも事態が改善されるわけではありません。地道な積み重ねをしながら、利害関係者が真摯に話し合っていくしかないのです。それぞれの現場で、それぞれの姿で少しでも良くしていこうとする努力が続けられたらなと思います。

一方でEnterprise ☓ HTML5 Web Application Conferenceでは散々UI/UXをdisりました。現状のUI/UX論というのは所詮インタラクティブなホームページをデザインする域を出ておらず、非常に感性にまかされており、エンジニアリングと呼べるような状況ではないと考えています。そもそも、IAにしても、あるいはRESTfulにしても「静的な情報」の取り扱いをメインにしており、エンタープライズで必要な業務アプリケーションをデザインするには不足感が強い。だからこそ、ユーザーテストを中心に据えるという原始的な手法に頼るしかないのです（これがダメということではありません）。

とはいえ、こういう限界点さえ分かっていれば過去の積み重ねを学ぶことは大事です。ウェブに接続される動的なアプリケーションというのは発展途上であり、まだまだ多くの可能性を持っています。今年はウェアラブルデバイスの数も増えますし、IoT（Internet of Things/もののインターネット）というバズワードも広がってきていますし、試すべき事がなくなることはしばらくはありません。こちらも現場での努力を続け、その結果を共有しながら前に進んでいければと思います。

というわけで、これからも引き続き宜しくお願いいたします。資料は以下で。
※2014/3/4追記　Youtubeで講演記録が見れます。
※2014/4/3追記　CodeIQ MAGAZINEさんで「エンタープライズの課題解決を考える「Enterprise x HTML5 Conference 2014」レポート（おやつ問題解説付き） #html5biz」として、講演録を書いていただきました。ほぼ書き起こし状態なのでご覧下さい。

エンタープライズの

アーキテクチャの発掘に見る要求変化の発見 - 要求開発アライアンス2014年2月定例会 from yusuke suzuki

JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference 2014 from yusuke suzuki

ymsr君のこと

＃ymsr との最後の会話はJJUG CCCの後の打ち上げで「席の周りの女子がかわいい」という話だった。

出会いは10年ぐらいまえ、優秀で身体のでかいエンジニアだった。職場は机と机の間隔が狭くて、彼ともう一人のでかい男が背中合わせに座っていると隙間がなくなってしまい「通路がnullだ」とか意味不明なことで爆笑してた。
それから彼が本格的に一緒のチームになり、java-jaという悪ふざけの立ち上げに付き合い、赤毛やダンサーも入ってきて、とても不思議な空間だった。
残念ながら彼らの実力を活かしきる仕事が用意できず、どっかのカフェの喫煙室で赤毛と2人して転職するって言われたときは、ちょっと安心した。
その後は、あまりにツブヤキが多くてtwitterのフォローは止めたけど、彼はずっと横目に見ている存在だった。

訃報を聞いたとき、あいつらならやりかねんと関係者のSNSを見たけど、みんながザワザワしているを見て悪ふざけじゃないと確信した。あまりのあっけなさに声が出なかった。同世代の死は何度目かだけど、どいつもこいつもあっけない。ただ、いなくなる。なんなんだまったく。

山城君は、みんなと出会う事で自由になっていったように思う。元々、彼は正直で純粋で思いを持っていて、それをどんどん自由に出すようになった。java-ja自体、そこに参加する人たちが相互にノリあっていって自由になる場だった。何をしても何を言っても死ぬわけじゃないから楽しもうって。

でも、そんなやつが死ぬんだから世の中ってわからないですよね。

弔いの形はいろいろだけど、彼については「語り」が良さそうなので書いておきます。これで許して。さようなら。

SIにおけるアジャイルとかウォーターフォールとか

取材を受けないとブログを書けないのは問題ですが、@ITの「特集：DevOpsで変わる情シスの未来」というのの第5回で「DevOpsというバズワードに流されないために」という話をさせていただいたので紹介を。

特集：DevOpsで変わる情シスの未来（5）：DevOpsというバズワードに流されないために (1/4) - ＠IT

弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。

というあたりがポイントかと思います。

「顧客の求めることには永遠にたどり着けない」という現実と「手法としてのプロジェクトマネジメントには明確なゴールが必要」という現実があって、その落としどころとして「小さく繰り返しゴールを定める」というアジャイル開発方法論が生まれました。

これ自体は素晴らしいアイデアですが、一方で「アジャイルでは繰り返し可能な土台があるかというのが成否を分ける」という現実も生まれました。保守フェーズにおいてアジャイルが有効なのは、この土台がしっかりしているためだというのは言うまでもありません。

SIにおいては保守フェーズだけではなくて新規開発もありますから、どうしても土台がない状況がありえます。そういった場合には「共通の土台を作るまでは迷うことなく進める」というのが必要となります。その場合には60点とか80点を取れるようなところまでゴールを定めることが重要であり、そのうえではウォーターフォール的な進め方が効率的です。

繰り返し言っていますが、ウォーターフォールでもアジャイルでも、別に名前なんかどっちでも良くて、

アジャイルやDevOpsを「開発プロセスの話」とか「運用のツールの自動化の話」といったように解釈せず、企画、開発、運用、フィードバックという一連のサイクル加速へのビジネスニーズがある、という背景に目を向け、そのためにDevOpsやアジャイルという手法が大事だと考えることが大切です。手法ばかりを見て矮小化して捉えてしまうことなく、トレンドの裏側にある本質的なことは何かを見据えることで、これらの言葉をあらためて理解できるのではないでしょうか。

ということで、ひとつよろしく。

アジャイルがビジネス価値を作るわけじゃない - 改めて開発手法としてのアジャイル

"アジャイル"は単なる開発手法というだけでなく、その出自からして「ビジネス価値にコミットする」というような意味を含んでいるように思います。なので「アジャイルだけがビジネス価値を作ることができる」、その逆として「ウォーターフォールではビジネス価値を作れない」というような言い方が出てしまう場合があります。

もちろん「ビジネス価値を作ること」と「ソフトウェアを作ること」は無関係ではありませんが、それがすべてではありません。ビジネス価値にとって重要なのは「どういうソフトウェアを作るか」ということであって「どうソフトウェアを作るか」ではないからです。

というわけで、改めてアジャイルやウォーターフォールを純粋な開発手法として整理したいと思います。

from Choices by Caleb Roenigk

基本は計画、実行、調整
ソフトウェア開発に限らず、プロジェクトマネジメントの基本は「計画し、実行し、調整する」です。プロジェクトマネジメントには必ず計画があり、それを実行します。そして実行しながら計画とのズレを把握し、調整を行います。完璧に計画通りなら調整というプロセスは不要ですが、世の中そうはうまくいきません。だから、計画だけではなく、調整が重要なのです。

そして開発手法とは「計画、実行、調整をどのような考え方で行うのか」であり、特に重要なのは「いかに計画と実行のズレを発見し、どのように調整するか」ということです。この点に注目してウォーターフォールとアジャイルを比較してみます。

ウォーターフォールは「計画を正として調整」
ウォーターフォールは全体計画を重視し、それを正しいものとしてスケジュールやリソース配置が組み立てられます。よって、実行が開始されると、ズレは計画を基準にして把握され（進捗管理）、タイミングを計って調整（変更管理）していきます。

前提は「計画が正しい」ですが、計画変更をしてはいけないわけではありません。ただ、調整が少ないほど効率は良いのは確かです。調整が多発するような状況になると、基準がブレてしまうためズレの把握が困難になっていきます。いわゆる「進捗が信用できない」という状況です。

このようにウォーターフォールでは計画精度が低いと実行段階での調整が間に合わずプロジェクトが崩壊します。よく聞くのはビジネス要件の決定が曖昧、技術的な検証が曖昧というような場合でしょうか。

逆に、十分に計画精度が高いと効率的で最適化されたプロジェクトが実現できます。そのドメインに十分な知識がある、あるいは、パッケージ導入や法律に定められたような機能のように繰り返し実行してノウハウが蓄積されているなどが考えられます。

アジャイルは「再計画によって調整」
一方アジャイルでは「調整が不要なぐらい計画を小さくし、その次の再計画によって調整を行う」という考え方をします。

まず、計画が小さくなれば計画精度は高まります。1年後ではなく数週間先のことだけを検討するのです。次に、実行しはじめたら調整をせずに「期間の完了後に棚卸を行うことでズレを把握」し、「次の計画に反映することで調整」させます。

ポイントはタイムボックスと呼ばれる「計画の期限が来たら必ず棚卸をする」という点です。これによって強制的に調整を働かせることができます。

ウォーターフォールが適宜調整していくのに比べると、アジャイルの強制調整は乱暴な考え方にも思えますが、実際にプロジェクトで調整が多い場合には効果を発揮します。つまり、調整を定期的なプロセスとして織り込んだわけです。かつ、再計画というのは調整幅が非常に大きく、どんな状況にも柔軟に対応することができます。これはウォーターフォールが計画を変えない前提に立つのとは大きく異なります。

ただし、逆にいえばアジャイルでは全体計画と個別計画の整合性を検証することが困難です。そのため個別計画はうまく行っていても、全体として問題が生じてしまい、崩壊することがあります。

アジャイルで全体と個別のバランスを取るのは職人的です。エンジニアと顧客が十分にコミュニケーションを行い、つねに全体感を共有する必要があります。双方が十分に対象ドメインに詳しければ、もっとも効率的な問題解決方法でしょう。

なので、改善や保守あるいはサービス運営などの「既に全体的な基盤が安定しているが、問題が突発的に発生してしまう」ような状況においては比較的簡単に導入できますし、逆に新規の大型案件のように「安定した基盤もなくコミュニケーションパスが大きくなりすぎる」ような状況では不利になります。

局面に合わせた選択を
こうして考えてみると、多くのプロジェクトが完全にどちらかの状況にあるわけではありません。よく言われるように近年はビジネス環境の変化が激しいため、一見するとアジャイルが適するような状況が多いでしょうが、一方でアジャイルは全体整合性が取りにくいのも事実です。

ビジネス環境の変化は大きいからといって事前の綿密な計画が不要なわけではありません。計画できることは十分に計画して効率的に進め、不明瞭な部分は先行的にトライ＆エラーをしてフィードバックを得ればよいのです。残念ながら絶対的な銀の弾丸は存在せず、敵に応じて弾の詰め替えをするしかないのです（写真はレゴを前に悩む女の子）。

ビジネス価値を作るのは「姿勢」
ビジネス価値を作るのに大事なのは、それを実現しようとするプロジェクトチームの姿勢です。それが開発手法によって決定するわけではありません（もちろん、助けにはなります）。これは請負受託だろうが自社開発だろうが、まったく同じことです。

プロジェクトはアジャイルだから成功するわけでも、ウォーターフォールだから失敗するわけでもありません。「ビジネス価値があるシステムを作りたいからアジャイル」という短絡的な考えに陥り、色々な制約を無視してプロジェクトを進めても成功することはありません。

チームはビジネス価値に貢献するという姿勢を忘れず、そのうえで、局面や状況にあわせた開発手法を選択してください。

ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発

2013年8月24日にグロースエクスパートナーズ主催にて「SIの現場で使えるチケット駆動開発」というセミナーを実施させて頂きました。「チケット駆動開発」の共著者である阪井誠さん（@sakaba37）をお招きしたものです（togetter）。

僕は基調講演で「チケット駆動で加速する、顧客と協業するプロジェクトマネジメント」を話しました。主にプロジェクトマネジメント論の中でチケット駆動の適用箇所について話をしています。

チケット駆動で加速する顧客と協業するプロジェクトマネジメント from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.

僕はアジャイルでもウォーターフォールでもプロジェクトに合ったものを選べばいいと考えています。どちらの手法にもメリットがありデメリットがあります。ただ、どちらの手法にしてもチケット（駆動）は有用なツールです。SIの現場で言えばチケットはウォーターフォールの限界を埋めるのに有効なので、積極的に活用をしていただきたいです。

（以前、「アジャイルがダメだと思う7つの理由」なんてものを書いたので、僕がアジャイル嫌いだと思っている人もいそうですが、まったくそんなことはありません。自社案件でも活用しています。ただ、盲目的にアジャイルが良いわけではない、というメッセージです）

ITS/BTSは進捗管理に使えるのか
さて、個人的に面白かったのは「組織パターン」の訳者である和智さん（@digitalsoul0124）も交えてのパネルディスカッションです。一番盛り上がったのが「ITS/BTSは進捗管理に使えるのか」という話題でした。

僕個人としては「ウォーターフォールのように長期な計画を前提としている場合、進捗管理はWBS/ガントチャートでやるべき」であり、BTSを利用するのは危険だと考えています。

長期的な計画を立てる場合、タスクの総量だけではなく、タスクの前後関係を把握する必要があります。そうしないと「工数的にはOKだけど、日程的にNG」ということが把握できません。ガントチャートはタスク間の関係を時間的な視点を把握することができるのです。

また、予実管理も全体を見通して把握することができます。いわゆる稲妻線ですが、プロジェクト全体の視点から「ここは遅れていてもかまわない」というような判断ができるのは大きなメリットです。

一方で、アジャイルは計画そのものを小さく（数週間）するので、全体の状況が個別の積み上げで判定できます。チーム内でタスク間の前後関係も共有されているからこそ、ガントチャートのようなツールがなくてもうまくいくのです。

ITS/BTSへの期待と現実
ですが、ガントチャートには問題もあります。パネルの中で参加者からは「BTSで進捗管理をすると、個別タスクの報告をチケットを経由してやれるから便利だと思っていた」という声が出ました。ガントチャートはPMが管理しているので進捗報告を受け取るのが面倒なのです。このニーズは非常によくわかりますし、多くのPMが実は期待したいところだと思います。

でも、PMとして考えると「個別の状況は分かるけど、全体の状況が分からない」という事態になる可能性があり、こういった目的での安易なBTS利用は危険だと思います。残念ながらWBS/ガントチャートとBTSを併用するというのが現実的な判断でしょう。

なお、BTSにはガントチャートツールが付いていたりしますが、僕としてはビューアーであり、いわゆる進捗管理のマネジメントツールとしては不足感があると思います。ただ、活用できる場面もあるはずなので、JIRAでいえばリックソフトさんのWBSガントチャート for JIRAなどはチェックされるとよいでしょう。

阪井さんが「チケット駆動コミュニティでも、チケットに作業予定日をいれるのはアンチパターンだという人もいる」と言われていましたが、それほどチケットで日程面での進捗管理をするのは簡単ではないのです。

手段と目的を履き違えてはいけない
そもそも論ですが、WBS/ガントチャートはトップダウンで計画を落とし込んでいく手法であり、ITS/BTSはボトムアップで事象を積み上げていく手法です。PMはこれらの特性を理解したプロジェクトマネジメントに活用していく必要があります。

なので「BTS（Redmine/JIRA）はプロジェクト管理に使える」というような安易な発想はやめましょう。使えないことはないですが、使ったからといって上手くいくわけではありません。手段と目的を履き違えてはいけません。

ここら辺、阪井さんも「チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech - ソフトウェアさかば」というエントリをいただき、またチケット駆動開発のもう一人の共著者であるあきぴーさんもust視聴後に「チケット駆動開発がWF型開発と相性が悪い理由 - プログラマの思索」を書かれています。ぜひ、ご参照ください。

＜講演の動画は公開予定です。公開されたら、ここにリンクを掲載します＞

チケット駆動開発

組織パターン (Object Oriented SELECTION)