押さえておきたいWebデザイントレンド2011
2011年は、日本においてもスマートフォンとタブレット端末が爆発的に普及した年だったと思います。私自身も、2010年にiPad、2011年にスマートフォンを入手して、これからのWebデザインは、クロスブラウザ対応だけでは凌ぎ切れないという実感が湧いて来ました。もちろん、ECサイトなどであればすでに対応済みのところも多いのですが、企業内で利用する基幹システムにおいても、徐々に必要に迫られてくると思っています。
そういうわけで、今回は2011年現在で「押さえておきたいWebデザイントレンド」と題して、SIを手がけるアーキテクトの視点から、3つのキーワードと参考になりそうなサイトを取り上げてみたいと思います。
カットオーバー後の品質保証
現在私は、数ヶ月前にカットオーバーしたシステムの品質保証というやっかいな仕事に取り組んでいます。。。
まぁよくある話なのですが、納期最優先で気合いと根性によりなんとかカットオーバーして、クリティカルな障害は出ていないものの、ポツポツとしょぼい障害が発生するという状況が続いており、顧客から品質について見直せというクレームが出ているわけです。
ちなみに、アーキテクチャ視点から見たこのシステムは、Java製で、WebフレームワークはStrutsを使用しており、ORマッパーやDI・AOPなどの比較的新しい技術は利用していないため、ゴリゴリの実装になっていました。PLに聞いたところ、新技術を利用することによる技術的問題を抱える余裕がないため、枯れた技術で構成したとのことです。まぁ個人的には、枯れた技術を利用してももっとやりようがあったとは思いますが、後の祭りですね。
とりあえず、MavenやHudsonを導入して、JUnitで単体テストクラスを作って（今はありません）などというタスクになるといいうことで、引き受けたわけですが、提案資料を作っている最中に大きな障害が発生し、ソースレビューだとか機能テストのやり直しだとか、もうちょっと根本的なところから手を付けることになりそうです。
よくよく考えてみると、上記に挙げた単体テストの自動化＆レポート作成などの仕組みは、開発フェーズにおけるプロセス改善として、品質を作り込むための事前予防的なアプローチです。対して、今回の私のミッションは、すでにカットオーバーしているシステムの品質をチェックして、問題があれば直すということで、最初から後手のアプローチになっているわけですね。
とはいえ、顧客に対して、「品質が上がってよかった」もしくは「品質に問題がないことがわかってよかった」のいずれかの納得感を持ってもらわねばなりません。これらを定量的に実感してもらうためには、何らかの品質指標を使うという手もあるのですが、これを可視化するとこちらとしても困るとか、今後もその指標に縛られるから嫌だとか、PM・PLからいちゃもんをつけられたため、工学的な手法も微妙だったりします。
そんなこんなで、内部的な事情も考慮しつつ、障害分析の深掘りから見えてくる傾向と対策により品質チェックをするという方向で提案しようとしています。これで顧客からどんな反応が返ってくるかドキドキですが。。。
■参考リンク
■参考にした文献
単体テスト仕様書の「表紙」
そこそこの規模の開発をやっていれば、単体テスト仕様書の作成は避けては通れないですよね。もちろん、私もこれまで様々なプロジェクトで様々なフォーマット、粒度、考え方で単体テストを実施する機会がありました。つい最近、私が2年ちょっと関わっていたプロジェクトが終わったのですが、最終フェーズで単体テスト仕様書の見直しタスクというものがあり、そのタスク内において、単体テストの実装と仕様書の乖離がないか、そもそも仕様書がなかったりしないかなどを実施していました。
今回このネタを語ってみようと思ったきかっけは下記のCodezineの記事です。
まだ始まったばかりの連載のようなのですが、テスト計画書のアウトラインや第１回の記事を見て、トラジショナルな感じかなという印象と、大規模システムのときに意外と問題となる点についてはやっぱり書いてないなぁという印象を受けました。
(紹介した記事の趣旨は「テンプレートから学ぶ」なので、批判するつもりは毛頭ありません)
そんなわけで、私が経験したプロジェクトの中でこの単体テスト仕様書の「表紙」の問題について、少しご紹介しようと思います。