2012年11月9日金曜日

テストコードを書くとアジャイルのテストのROIは3倍になる

今回は、アジャイル開発におけるテスト手法に関するお話です。
手動テストと自動テストについて、会計的・数学的な観点から比較します。
今回の記事は、定量的な比較をしただけで、主張の内容は、GoogleやFacebookなどの先進的なWeb系企業やオープンソースでは常識であり、特に目新しい主張ではありません。

結論
1年継続するシステムであれば、自動テストのROIは、手動テストの約3倍です。
4ヶ月未満で改修が完全に終了するプロジェクトならば手動テストを行うべきで、4ヶ月以上改修が継続するプロジェクトであれば、自動テストを行うべきです。

前提
1週間に1回のイテレーション
現在割引価値算出のための年率は上場企業平均のROI年率5%
テストケースが作成されている状態で、テストコードを書く工数を手動テストする工数の8倍とする(8倍は弊社実績)

背景
イテレーションをすばやく繰り返すだけの名ばかりアジャイルがSierによって誇大的に喧伝されています。詳細は後述しますが、自動テストなしにきちんとした品質を担保しながらイテレーションを繰り返すことはほとんど不可能に近いです。どこかで手を抜くか、工数を盛るかしないといけません。Sierは人月商売を行っており、手がかかればかかるほど工数が膨らむので、それも後押ししているのかもしれません。また、キーマンズネットの調べによると、 91.5%の企業は自動テストを行っていません(参考)。
昨年までは、私達もそういったSierの1つでした。今年から、上記の反省を踏まえ、自作のVB6用テスティングツールVUnitとjenkinsによる自動テストにより、品質の向上に努めています。

定性的な根拠
プログラムに一部変更を加えた場合、通常は、そのたびに他に影響がないかを確認しなければいけません。変更や修正を繰り返すアジャイル開発では、この確認がイテレーションのたびにかかるので、うまく工夫をしなければ工数が爆発的に増加してしまいます。現実には、手動テストでは、影響範囲を人間がヒューリスティックに判断し、テストの範囲を狭めることで対応しますが、人間の判断なので得てして見落としが発生し、思わぬところに影響が出たりします。もちろん、カプセル化や関数型プログラミングでリスクを低減させることは可能ですが、現実には見落としが発生してしまいがちです。一方、自動テストでは、一度書いたテストは再利用可能であり、一度書いたものであれば全体に対してテストを行うことができます。また、今回の計算式には算入していませんが、自動テストの実行自体も自動化し、定期的にテストを実行することで、バグの検知もすみやかに行うことができ、工数を削減できます。jenkinsの導入も即日可能です。

定量的な根拠(読み飛ばし可)
1イテレーションにつき1つ機能がリリースされ、1イテレーションの間にリリースされたすべての機能をテストするものとする。

また、1つの機能に対して1回の手動テストをすることよる工数をM、1つの機能についてテストコードを開発する工数をT、自動テストによる1回あたりのテストの工数を0、1イテレーションあたりの利率をi、イテレーションの回数をn、テストをすべて手動テストで行った場合の工数の総和をH、テストをすべて自動テストで行った場合の工数の総和をA、割引率をj = 1/i(j≠1)とする。

Hを求める
H = M+2Mj+3Mj^2+...+nMj^(n-1)
jH=      1Mj+2Mj^2+...+(n-1)Mj^(n-1)+nMj^n
H-jH=(M+Mj+Mj^2+...Mj^(n-1))-nMj^n
(M+Mj+Mj^2+...Mj^(n-1))は初項M,公比j,項数nの等比数列の和なので、式を変形して、
(1-j)H=M(1-j^n)/(1-j) - nMj^n
j≠1より、
H=M(1-j^n)/(1-j)^2 - (nMj^n)/(1-j)

Aを求める
A = T+Tj+Tj^2+...+Tj^n
A = T(1-j^n)/(1-j)

HとAに前述の前提の項の値を代入して比較した結果、前述の結論になった。

2012年8月20日月曜日

【画像あり】Webページで表示できる綺麗なグラフ4つ

Webで表示できる美しいグラフを4つ紹介します。
美しいグラフは、ユーザーの興味を惹くことができるため、訴求力が高まります。
また、わかりやすさも向上するため、アプリケーションの使い勝手も向上します。


簡易比較表

無料/有料 グラフの種類 サンプル 複合グラフ
High Charts ×
Google Chart Tools
Raphael.js
ccchart

各々長所と短所があるので、状況に合わせて使い分けてください。
上から順におすすめです。

2012年5月22日火曜日

実際に使った4つのクラウドサービスの比較


EC2、Salesforce、Heroku、Google App Engine(と従来の自前の物理サーバー)の比較をします。それぞれ、実際に触ってみた感想です。 それぞれ使いどころがあるので、状況に応じて使い分けたり組み合わせたりするといいと思います。

簡易比較表


EC2 Salesforce Heroku GAE 自前
イニシャルコスト※ ×
保守・運用費用 ×
ストレージ費用 × ×
自由度 × ×
サーバー設定コスト × ×
冗長性 ×
移植性 × ×
VPN × ×
※純粋なサーバー調達費用

EC2

つかいどころ:柔軟さが求められるユーザーに近いシステム
EC2の特徴は、自由度の高さとサーバー調達の容易さにあります。OS選択からアプリ設計まですべて自由に行なえます。標準的なLinuxサーバーや構成を使えば、移植性も損ないません。また、サーバー増設の際にも物理サーバーを購入するために奔走する必要はなく、簡単にコピー、立ち上げ、冗長化を行えます。欠点は、自由度ゆえのハードルの高さです。

Salesforce

つかいどころ:他社でも行うような定型業務に近いシステム
パッケージ全般に言えることですが、Salesforceは標準機能をうまくつかいこなすことで、コストパフォーマンスが高くなります。たとえば、アカウント管理やそのセキュリティコントロールなどです。導入の際は、自身の業務が標準的なシステムに落とせるかどうか、一考するといいと思います。一方で、Salesforceを使う際の注意点は、カスタマイズを小さく抑えることです。標準機能にはないような複雑な実装をすると、将来、移植が必要になったときに負の遺産になります。古いシステムの不便さと移植コストのジレンマに陥る企業は少なくありません。そして、システムの移植はつきものです。

Heroku

つかいどころ: エンドユーザー向けの試験的サービスの運営
Herokuの特徴は、スケーラビリティ(冗長性)とアプリ周りの設定の容易さにあります。負荷分散をするときは、サーバーの台数をコマンド一本で調整できます。また、試験的サービスにおいて重要なのが、設定の容易さで、開発コストの1/3〜1/2くらいは設定周りに費やされますが、herokuの場合は設定をほぼ自動的に行ってくれるため、すばやいリリースが可能です。ただし、ストレージ料金が高いので、DBだけEC2に置くなどして、他サービスと組み合わせて対策するといいと思います。

Google App Engine

つかいどころ:エンドユーザー向けの挑戦的なサービス
Google App Engineの特徴は、オートスケールと設定の容易さです。Herokuとよく似ていますが、Google App Engineは、言語がpython(google三大言語のひとつ),Java,Go(Googleが作った新しい言語)に、DBがBigtableに限定されるかわりに、自動でサーバーの処理台数を増減させたり、 設定を容易にできます。キャンペーンサイトなどで急激なアクセス増が期待される場合やアクセス数が読めない場合に有効です。

自前サーバー

つかいどころ:極めて大規模なサービスを自前で運営する場合
物理サーバーの扱いに長けた優れたインフラエンジニアを擁している場合で、かつ大規模なシステムの場合にはいいかもしれません。あるいは、クラウドサービスが社内稟議で通りにくい場合も有効かもしれません。

2012年2月15日水曜日

Gumroadにブックみくらべを2ドルで出品しました

Gumroadという新しい決済サービスについてご紹介します
(クライアントのKさんに情報提供いただきました。ありがとうございます!)
https://gumroad.com/

Gumroadは、簡単な少額決済サービスで、下記のような特徴があります
  1. 手数料が安い(単価の5%+30セント)
  2. 初期設定が簡単(公開まで3分かかりませんでした)
  3. 相手に伝える手段が簡単(URLを伝えるだけ)

早速、ブックみくらべツールの最新版を2$で公開してみました。

公開方法は、下記の動画を参考にしました(49秒)


今後も何か汎用的な社内ツールがありましたら、Gumroadを使って公開してみることにします。

2012年1月26日木曜日

Excel帳票駆動開発用ツール「ブックみくらべ」をリリースしました

前回、テスト駆動開発について少しお話をしました。今回は、Excel帳票駆動開発のためのツール「ブックみくらべ」をリリースしたので、テスト駆動開発との違いに触れながら帳票駆動開発(弊社造語)のお話をします。

ブックみくらべ(ベクターでも公開する予定です)
https://bitbucket.org/mozanitworks/books-difference

テスト駆動開発とは
テストを行うプログラムを先に作成し、そのテストに通るようにプログラムを書く開発手法のことです。
プログラムの修正は、影響範囲を読み切ることが難しく、A、B、Cといった機能があるときに、Aという機能を修正すると、BとやCに想定外のバグが出ることがしばしばあります(参考:バグ修正のための変更の40%が新たなバグを混入させる)。
これを防ぐために、A、B、Cのプログラムに自動で動作確認をするプログラムを書きます。そして、Aを修正したときに、Aを確認するだけでなく、A、B、Cのすべてのプログラムを自動で実行し、他に影響がないことを確認します。

テスト駆動開発とExcel帳票駆動開発の共通点
両者ともに共通することは、自動で確認をするため、修正や変更に強くなることです。

テスト駆動開発と帳票駆動開発のちがい
テスト駆動開発は、"プログラム"にまちがいがないかを自動で確認する開発手法です。一方、Excel帳票駆動開発は、"帳票"にまちがいがないかを自動で確認する開発手法です。
テスト駆動開発は、自動で動作を確認するテストプログラムを書きます。これにより、プログラムレベルの堅牢性は増しますが、テストプログラムを書くコストがかかります。
これに対し、帳票駆動開発は、最終的に出力されるExcelの帳票の差分を比較します。現行のプログラムが出力する帳票と修正したプログラムが出力する帳票を自動で差分比較します。比較は、今回のツールを使えば、ワンクリックで終了します。
これにより、差分として出力されなかった部分については動作を保証し、差分として出力された部分を確認すれば、修正の確認が完了します。
Excel帳票駆動開発は、テスト駆動開発に比べて内部の堅牢性は下がりますが、その分遥かに高速にユーザーに見える部分をテストすることができます。

どちらが優れているのか
ナイフとハンマーがその用途によってその利便性が違うように、用途によって変わります。私が前回テスト駆動開発用ツール「VUnit」をリリースし、今回ブックみくらべをリリースしたのは、相互に足りない部分を補うためです。
テスト駆動開発は、たしかに堅牢性が増すのですが、チームやソフトウェアに浸透させるまでに時間がかかります。今あるソフトウェアの規模だと、1年から2年の仕事になると思います。長期的にはこれでも構わないと思うのですが、短期的な面では不満が残ります。そこで、ブックみくらべを作成しました。弊社のソフトウェアはExcelやCSVで帳票を出力する機能がほとんどなので、短期的にもこれで品質向上が望めます。

背景
弊社はとても小さなチームです。今のメインクライアントは、複数のベンダーと契約しています。その多くは、とても大きなベンダーで、通常ではとても太刀打ちができません。
確認作業なども、マンパワーが足りないため、どうにかして効率化する必要があります。効率化の源泉は、先日お話したアジャイル開発と小さなチームならではの小回りです。使えるツール・手法はどんどんスピード感をもって導入・学習し、なければサクっとつくり、改善する。特に、品質保証に関わる効率の向上は、スピードに直結します。確認やバグ修正、それに付随する手戻りが減り、手が空くことで、より人間的な作業に集中し、新しい機能を開発していくことができるからです。

2012年1月20日金曜日

VB6用テスティングツールVUnitをリリースしました

品質向上の一環として、テストツールVUnitを作成・リリースしました。
オープンソースとして公開しています。ライセンスはMIT Licenseです。
https://bitbucket.org/mozanitworks/vunit
VUnitの紹介とともに、弊社の運用体制についても解説します。
    1.VUnitの特徴

    Visual Basic6.0のIDE上で動作し、テスト結果をイミディエイトウィンドウに出力します。
    類似のテストツールVBUnitでは、この機能が有償となっています。


    2.開発体制について

    詳細な要件定義をせずに、まずプロトタイプをすばやくつくります。
    そして、そのプロトタイプを元にお客さんから修正点・要望を引き出し、徐々に完成度を高めます。この手法を採用している理由は、具体的な動くソフトウェアがない状態でエクセルを見ながらミーティングを重ねても、地に足のついた要件になりにくいからです。お客さんにとっても、事前に綿密に要件定義をする必要もなく、ストレスの負荷が低くなります。
    この手法の長所は、柔軟で、スピードがあることです。一方、短所は、開発側からすると、お客さんとの信頼関係を構築する必要があることです。チェックポイントごとに提出する荒削りなソフトウェアに面食らってしまうため、事前に説明が必要になります。

    3.今後の展望

    今回開発したVUnitをもとに、開発途中のソフトウェアでも担保できる品質を可視化していきます。お客さんの安心と実質的なクオリティを上げていく予定です。
    現在使用しているバージョン管理のMercurialとプロジェクト管理ツールのRedmine、今回作成したVUnitを連携させて行く予定です。



    #あとがき
    制作時間1.5日でした。頭の中に設計の構想があったので、それを考えるために手がとまることがなく(普通はこれに一番時間がかかる)、思ったより速くつくることができました。「つくりたいものをつくりたいようにつくる」と、興味が働いて手を動かしていない時間に頭の中で仕様を検討するため、生産性が高くなるような気がしました。

    2011年12月1日木曜日

    【導入編】SalesforceアプリをJavascriptで開発する

    Salesforceアプリの開発について勉強中です。勉強した内容をアウトプットしていきます。間違いがありましたら、フィードバックをください。

    Demo(Chrome専用)




















    (現在開発中。動作にはLeadへのアクセス権限が必要です。chromeの標準表示で動作確認)


    Apexに対するJavascriptの優位

    Apexベースのアプリでは、デプロイするまでデバッグができませんが、jsならchromeのデベロッパツールなどを用いて、即座にデバッグができます。これにより、高い生産性が実現できます。


    Railsに対するJavascriptの優位

    Railsによる開発に対する優位としては、日本語処理の充実度が挙げられます。筆者が試した限りでは、jsを叩いてSalesforceから得られるデータは、日本語の取扱いも特に問題ありませんでしたが、Rails経由で接続して得られるデータは、utf-8のデコードがうまくいきませんでした。Railsについては、機会があれば別に記事を書きます。


    次回以降、実際にデモを作るまでの手順を紹介していきます。
    【次回の予定】JavascriptでSalesforceにoauth接続する