羽岡哲郎ブログ

ソフトウェアやハードウェア開発では，開発生産性を上げるためのさまざまなツールが導入されている．開発者自身が自らツールを作ってしまうことも良くある．そこで必要となるのは，そのツールがどれだけの価値を持っているか，評価することである．高価なツールを購入しても，そのインパクトが価格に見合うものでなかったとしたら，損失にしかならない．また，ツールを自作する場合でも，その作成にかかるコスト以上の効果がなければ，無駄な投資だ． 生産性を上げるために導入したツールの価値とはどのように測るべきか？ それは，「生産性の向上（単位＝円）」で測られるべきだ．たとえば，時間単価5,000円の開発者の作業を100時間短縮するツールは，500,000円の価値がある，という計算になる．このツールが繰り返し使われるならば，その価値はさらに高まる． 将来の生産性向上分を現在の価値として計算するには，割引キャッシュフロー計算の方法で，将来発生すると考えられる利得（生産性向上）の総計を現在価値に割り引いて求める． この計算のためには，金利，および，ツールが将来使われる確率を推定した上で，割引率の推定を行わねばならないが，この推定は困難を極める．将来どの程度利用されるかは，不確定性が高く，ほとんど誰にも予想できないからだ．基本的には，過去の実績から統計量をとることと，大きめの割引率を用いることで，ざっくりと計算するしかないだろう． ここまで，生産性の向上を通貨単位で測れることを暗黙の前提としてきたが，実際は，生産性の向上を測ることはかなり難しい．予測するのはもっと難しい．それでも，何も評価が無いよりはマシなのだ．いろんなツール，たとえば Kindle を導入することによって，どれだけ無駄な時間を減らすことができたか．そういう身近なところで評価してみるのも面白い．

IPAの「非ウォーターフォール型開発に関する調査」という文書を読んでいて，ソフトウェア開発の生産性に関する興味深い結果を見つけた．アジャイル型開発（非ウォーターフォール型開発の一種）によって，生産性が向上したにもかかわらず，開発コストはさほど削減されていない，という結果が出ているのだ． 下のグラフを見てほしい．生産性も，Time-to-Marketの加速も，ソフトウェア不具合の削減も，半数以上で10%以上の改善ができているにもかかわらず，10%以上のコスト低減が実現されているところは30%ほどにとどまっている． 出所：情報処理推進機構「非ウォーターフォール型開発に関する調査」より抜粋． 生産性は，ソフトウェア開発によって生み出されるソフトウェア価値を，開発工数で割ったものである． 生産性　＝　ソフトウェア価値　÷　開発工数 もし，ソフトウェア価値が変わらないものとすれば，生産性の向上は開発工数の減少を意味し，それは，開発コストの減少につながるはずだ．なぜなら，特別な開発ツールへの投資をしない限り，開発コストは開発工数に比例するからだ．しかし，調査結果はこれに反する．いったい，どうなっているのだろうか？ コストが減らない理由は，「ソフトウェア価値も増加している」としか考えられない．ソフトウェア価値は，すなわち，ソフトウェア品質である．生産性は高まったのだが，要求されるソフトウェア価値（品質）が上昇しているため，開発工数はさほど減っていないのだ．そのため，開発コストも減らない． この推測を支持する情報がもうひとつある．それは，「ソフトウェア不具合の削減」である．不具合が減るということは，品質が高まるということである．つまり，ソフトウェア価値を高めるために，開発工数がつぎ込まれている，と考えられるのだ． ここに，日本のソフトウェア開発の慣習が見えてくる．日本のソフトウェア開発の特徴のひとつに，「品質に関して明確な取り決めを行わない」というものがある．ユーザー側が，期限ぎりぎりまで，品質向上（機能追加や不具合修正）を求めるのである．つまり，開発側が，品質に対して，無制限の責任を負う習慣があるのだ． 生産性の向上を，開発コストの削減につなげるためには，この習慣を断ち切る必要がある．完成品の品質基準を明確に記述し，それ以上の品質改善は別契約...

ソフトウェア開発やハードウェア開発の現場では，よくコードレビューが行われるようになってきた．その目的は，まだ完全でない状態のコードを読むことによって，なるべく早い段階で問題点を取り除くことだ． そのようなコードレビューについて調べていると，森崎修司氏がとても有益な情報を発信されていることを知ったので，いくつかここにリストアップしておく． @IT連載「ソフトウェアレビュー入門」 IBM技術文書「コードレビューの道具、使っていますか？