システムのアジリティ確認の場としてのレビュー
ここでのアジリティ(agility)は変化への追従性という意味です。アジャイル開発と通じるところが多いのですが、一体ではありません。ここではアジリティを次の2つの意味で使って、それを確認する場としてのレビューを紹介します。
1つはシステムを使っていると利用者が増えたりしたときになるべく短時間で追従できることです。スケーラビリティと言っても差し支えないと思います。システムが取り扱うユーザの数やアクセスの数が増えてきて多くのリソースが必要になったときにも問題なく対応できること、同時にリソースが少なくても済むうちは大きなリソースを必要としないことです。夏休みに特に多いといった、特定の時期に限定して大きなリソースが必要となるシステムは、わかりやすい例です。また、クラウドコンピューティングで実現されているようなリソースを短時間で簡単に増減できることはこれに該当します。
もう1つのアジリティは、必要になった機能を簡単に追加できたり、利用者の要望や環境の変化に素早く応じることができるというものです。要望や環境の変化は様々です。「スマフォで見たい」「～機能がほしい」といった要望の場合もありますし、ミドルウェアのバージョンアップ、脆弱性対応によるOSのパッチ当て、法改正等様々な変化が考えられます。これらの変化に素早く対応することでビジネスとして成功できたり、ユーザにより多くの価値を提供できる場合があります。
システムやソフトウェアの評価（期待通りできているか確認する作業）はテストとレビューを組合わせることが多いのですが、上のようなアジリティの実現はアーキテクチャ設計の時点で加味されていないと難しくなります。想定される変化とそれに対応できるかどうかを加味して設計し、レビューで確認します。欠陥の修正の場合には、テストとレビューを組合せることができるので、テストで検出して修正するよりも修正コストが大きくなることがレビューで検出すべき欠陥といえますが、アジリティはテストとの組合せはそれほど効果的ではない場合が多いからです。そのため、システムのアジリティを確認するためにはレビューにおいて具体的に何を確認するかを明確にしておく必要があります。
アジリティという言葉が少し紛らわしいのですが、計画ベースの（ウォータフォールの）開発プロセスであってもアジリティの高いシステムやソフトウェアを作ることはできます。もちろん、アジャイル開発であってもアジリティの低いシステムやソフトウェアとなることもあります。
2013/8/7午後に汐留で開催される富士通LS研セミナーで開発タイプ別のレビューの講演の機会をいただきました。システムのアジリティの確認も含めたレビューも含まれます。タイトルは「レビューの原理・原則と開発タイプ別のアプローチ」です。セミナーの詳細はこちらから。
また、システムやソフトウェアへの要求としてアジリティの高さが挙がる状況が増えてきています。もし、想像がつきにくければ、様々な講演やイベントで事例を通じて具体策を知っていただくのがよいと思います。私が関わっているイベントでは上述のセミナーでの2事例、及び、シンポジウム委員のとりまとめを担当しているソフトウェア品質シンポジウム2013での特別講演があります。特別講演はリクルートテクノジーズ米谷氏の「進化するＩＴ組織と開発スキーム ～リクルートのサービス開発の事例紹介とともに～」です。これ以外にも様々な場で事例紹介されていると思いますので、アジリティを考えるきっかけとされてみてはいかがでしょうか。