リスク管理

ソフトウェア品質の12の属性

凪瀬 — Tue, 03 Feb 2009 08:36:00 GMT

システム開発において「品質の向上」という標語がしばしば掲げられますが、「品質の属性」については無頓着なケースが多いのではないでしょうか。

ひとくちに品質といっても多様な属性があります。顧客と品質の話で揉めたことはありませんか？品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。

Karl E. Wiegers氏が著書「ソフトウェア要求」で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。

可用性	availability	動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。
効率性	efficiency	同じ処理性能を出すのにどのぐらいのハードウェアのスペックが必要か。
柔軟性	flexibility	機能拡張への柔軟性。順次拡張していくアジャイル開発を可能にするためにはある程度の柔軟性を備えた設計にする必要がある。
完全性	integrity	データが正確で完全であること。改ざんなどされておらず、正しく動作すること。情報セキュリティの目標事項のひとつとして挙げられる。
相互接続性	interoperability	他システムとのデータ連携の容易さ。
保守性	maintainability	バグの修正や仕様変更の容易性。
移植性	portability	ある稼働環境から、別の稼働環境へ移行させるために要する工数など。 JavaなどにみられるVM方式など高レイヤでの稼働システムは移植性が高いとも言える。
信頼性	reliability	特定の期間、故障なしでソフトウェアを実行できる可能性。
再利用性	reusability	プログラムコードの再利用性。オブジェクト指向などによるモジュール化によって高めることができる。もっとも、日本だとソースコードが納品先の所有になる契約となることが多くライセンスの問題で再利用性が低い。
堅牢性	robustness	耐障害性。異常データなどの入力に対する耐性。
試験性	testability	テストのしやすさ。
使用性	usability	ユーザビリティ。使いやすさ。

これらは多くのプロジェクトに共通する属性ですが、もちろんこれで全てと言うわけではなく特定ジャンルではさらに追加の品質属性を考慮する必要が出てきます。同じ本から引用すると「組み込みシステムに重要な品質属性としてはさらに安全性、導入容易性、サービス能力があります。スケータビリティは、インターネットアプリケーションに重要なもう一つの属性です。」ということになるでしょう。

これらの品質属性は、すべてを同時に上げることができません。トレードオフが発生するのです。

品質属性のトレードオフ

これら品質の属性は、相互に作用し合っています。ある属性を高めれば他の属性も高まる、あるいは低くなるということがおきます。以下の表は左側の属性を上げた場合に上側のどの属性が高く、あるいは低くなるかを表しています。（追記：引用元「ソフトウェア要求」228ページ）

	可用性	効率性	柔軟性	完全性	相互接続性	保守性	移植性	信頼性	再利用性	堅牢性	試験性	使用性
可用性								＋		＋
効率性			－		－	－	－	－		－	－	－
柔軟性		－		－		＋	＋	＋			＋
完全性		－			－				－		－	－
相互接続性		－	＋	－			＋
保守性	＋	－	＋					＋			＋
移植性		－	＋		＋	－			＋		＋	－
信頼性	＋	－	＋			＋				＋	＋	＋
再利用性		－	＋	－	＋	＋	＋	－			＋
堅牢性	＋	－						＋				＋
試験性	＋	－	＋			＋		＋				＋
使用性		－								＋	－

まずは品質には属性があることを顧客に伝えましょう。そして属性にトレードオフが発生することを理解してもらいましょう。

ソフトウェア工学と品質属性

ソフトウェア工学の数々の成果はこれらの品質属性にどう影響を与えたのでしょうか？

構造化プログラミング

試験性 - 適切なモジュール分割は試験性を高めます。より高めるにはステートレスな機能を意識的に分割することです。ステートレスな関数は引数と戻り値によって容易にテストでき、自動テストなどによる自動化も行いやすくなります。
再利用性 - 構造化によりある程度、再利用性が高まりました。

契約に基づくプログラミング

完全性・堅牢性 - モジュール間での「契約に基づくプログラミング」のほつれに対して適切にエラー処理を施すことで完全性・堅牢性を高めることができます。

オブジェクト指向

柔軟性・保守性 - オブジェクト指向によって動的なフローチャートになるプログラムを容易に制御できるようになりました（ポリモフィズム）。これを活用することで、既存箇所に手を入れることなく追加のクラスを作成するだけでの拡張が可能になります。
再利用性 - 構造化プログラミングよりさらに再利用性を高めることができます。ポリモフィズムを活用したプログラミングは再利用性の点でも優れています。

VM技術、仮想化技術

移植性 - Javaの標榜する"Write once, run anywhere"は究極の移植性と言えます。現在のJava開発は主にWindows機上で行われており、そのままUnix系のOSで稼働する本番機で動作させるようなことが行われています。携帯電話におけるJavaMEの採用もこの点を活用してのことです。

O/Rマッピング

移植性 - O/RマッピングもDBを特定製品に縛らないという意味で移植性を高める効果があります。

DIコンテナ

柔軟性・保守性 - DIコンテナによる設計は柔軟性・保守性を高めます。
試験性 - DIコンテナによる疎結合は試験性をより高めます。DBなどを伴うシステムですら、スタブによって自動テスト化することが容易になりました。

ここでは目立つ特徴をピックアップしましたが、もちろん品質属性への影響はここに挙げただけにはとどまりません。各種パラダイムを眺める際に、品質属性への影響と言う点でみつめるとまた違ったものが見えてくるかもしれません。

アスペクト指向の概念

凪瀬 — Tue, 25 Mar 2008 10:33:00 GMT

アスペクト指向(AOP : Aspect-oriented programming)はオブジェクト指向(OOP : object-oriented programming)とは直行的な概念で、相補的なものですが、2008年現在、未だ広く普及しているパラダイムではなく、その機能を取り込んだ言語もあるものの（Javaの拡張であるAspectJ、Rubyの拡張であるAspectRなど）普及しているとは言えない状況です。

近年ではDIコンテナの普及で、AOPを部分的に利用できるようになりました。オブジェクト指向言語の普及前に、例えば言語としてのオブジェクト指向をサポートしないC言語で、オブジェクト指向の概念を表現する工夫がなされたと聞きます。 DIコンテナによる部分的なAOPサポートは、言語機能としてAOPがサポートされた言語が普及する「夜明け」に対して、「前夜」の趣を感じさせるものです。

アスペクト指向が解決しようとしていること

アスペクト指向の解説書でアスペクト（横断的関心事と呼ばれる。後述）の例として、よくロギングが挙げられます。が、正直な話、私はあまりこの例でピンときませんでした。

横断的関心事とはどういう事象でしょうか？

オブジェクト指向では複数のクラスに跨って存在してしまう機能性ということですが、どういうものがあるのでしょうか？

私がシステム設計をしてきた中で、「あぁ、これが概念としてのアスペクトなのだな」と思ったことは

SQL injection対策
XSS対策の出力文字エスケープ
OS command injection対策
バッファオーバーラン防止のためのバウンダリチェック
例外処理

といったことです。開発でこれらの対策に頭を悩ませている方は多いのではないでしょうか？

これらの事象は、「すべての該当箇所に対して、一律の対応を行う必要がある」という点です。これこそが、概念としてのアスペクト、横断的関心事なのです。

こうした、XXに全部YYをする、というのは自然言語で表現すると１文にも関わらず、プログラム言語的には該当箇所を検索して１つずつ虱潰しにコードクローンを挿入する必要があります。アスペクト指向が解決しようとしているのは、まさにこの部分なのです。

アスペクト指向の概念で重要なのはこのアスペクトという抽象概念を捉える事。そして、どういったターゲットにウィービング（weaving : 縫い付けるの意。アスペクトを適用させること）させるのかということです。ウィービングできるポイントをジョインポイントと呼んだりします。端的には、メソッドが呼ばれる前、および呼ばれた後などをジョインポイントとすることが多いですね。

どのように実装するか

DIコンテナでは部分的にAOPが利用できると述べました。 DIコンテナはオブジェクトの生成をDIコンテナが管理します。このDIコンテナに管理されたオブジェクトに対してGoFのProxyパターンを利用してAOPを実現しています。

これはOOP的な環境で疑似的にAOPを実現するためのひとつの答えです。

あるクラスのインスタンス生成が制御されうるなら、その段階でProxyを挟むことで、そのクラスの特定のメソッドの前後に処理を一律に差し挟むことができます。

DIコンテナではコンテナがクラスの生成を管理するためにそれが可能でした。そうではない場合でも、Factory Method、Abstract Factory、Builder などといった生成にまつわる GoFデザインパターンと組み合わせることで、一律にProxyを噛ませることができます。

また、ウィービング対象となるオブジェクトが特定の箇所を必ず通過するようなケースでは、そこでトラップしてProxyを噛ませるような方法論も考えることができます。 ServletでのRequest#setAttribute()のような場所をイメージするとよいでしょう。

実行時による動的なウィービングでなくとも、コンパイル時に機械的に処理を差し挟むような方法論も考えられます。

Java SE 5.0からはアノテーションが使えるようになりました。これにより、こうした機械的な処理が断然しやすくなった点も見逃せません。コンパイル時にジョインポイントを自動生成するような仕掛けを作ることで概念としてのAOPを実装することができるわけです。

アスペクト指向の問題点

アスペクトというものが横から入り込んでくるわけですから、OOPのソースコードを見ただけでは実行時の動作がわかりません。そう言った意味でプログラムが複雑化する危険性をはらんでいます。また、アスペクト同士の干渉が起こることもあり、アスペクトの適応順序によって挙動が変わることもあります。

また、アスペクト指向でウィービングの対象をどう管理するかも疑問が多い。「全ての」の適用範囲はどこまでなのか。あるいは、特定の範囲だけに適用したいこともあるでしょう。現行のDIコンテナでのAOPではメソッド名のマッチングによって特定の名称のメソッドの前後に適用、といったことができますがこれが酷く気持ち悪い。

gattaislime氏のアスペクト指向の問題点では

　要するに、現在の典型的なアスペクト指向では、アスペクトを織り込むオブジェクトがホワイトボックスであることを要求するか、逆にアスペクト自体がオブジェクトの実装を規定するか、ということになってしまい、結果としてアスペクトが単なる暗黙的多重TemplateMethodに成り下がっているのではないかと感じてしまうのだ。

　このような暗黙のTemplateMethodは非常に厄介で、ソースコードをそのまま追っても処理の流れがつかみにくく、最悪の場合ソースコード全体をメソッド名や属性名でgrepして、関連するすべてのアスペクトを洗い出さなければならない。

と指摘しています。

ウィービング対象は集合論的に抽出されるわけで(つまり、SQLのWhere句のようなイメージ)Javaなどの強い型付け言語でなされる型の安全性のような安心感がまったくない。

しかし、集合論というとジェネリクスも集合論ですが、型の安全性を確保できている（参考:ジェネリクスと代入と落とし穴）わけで、ウィービングのための型のようなシステムが必要なのではないかと思う次第。

はてながCAPTCHAの費用対効果で見落としていること

凪瀬 — Mon, 10 Mar 2008 18:27:00 GMT

私のはてなのCAPTCHAは簡単に破れるというエントリが高木浩光氏のblog で再度取り上げられた関係で、アクセスが増えているのでこれを機会に補足しておきます。

私の該当エントリはCAPTCHAとは何なのかという話と、 Radium Software Developmentのエントリ「Breaking CAPTCHAs with NNs」を紹介してCAPTCHAの強度で重要なのは文字の分割をしにくくすることだと述べました。

そして、はてなのCAPTCHAは画像処理をかじった人間であれば小一時間で破るプログラムが作れる程度に弱いことを実証しました。画像処理に重きを置いた技術記事という位置づけですね。

経済的な観点での考察はしていませんでしたから、費用対効果という観点で再度見つめてみたいと思います。

費用対効果についての諸意見

さて、はてなブックマークで付いていたコメントには以下のようなものがありました。

荒らし対策目的の場合は、荒らされたときに次の改善バージョンに切り替えればいい話。
実用レベルでは十分役に立ってる。導入後にスパムは消えた。
CAPTCHAは実装がアレでも「ある」というだけでspammer避けになるものだと……費用対効果の問題で。
かといってすぐにそれをやる人がいるとは限らない、というお話。
強度の低いセキュリティでも効果がある間は改良は不要。でも将来的にはどうにかしたいよね，ってレベルかな
たしかにここまでやる気がないのならもう素直にノイズ無しでもあまり違わない気もするよね。
スパム対策として使っているのならある程度スパムプログラムがはじけてそこそこの効果があれば十分だと思うよ。
OCR…というか、機械に文字を読み取らせる技術について知識がないとCAPTCHA意味無し。だがライトスパマー（？）を弾けるならそれで十分か。
費用対効果ってこともあるから、破られてから対処するぐらいで良さそうだけどなぁ…
この程度のCAPTCHA破りは許容してるんだと思ってた。完全じゃなくても単純なボットが実用レベルで防げれば十分と考えられるし、そういう運営側の判断もよくある。

費用対効果としては十分じゃないの、という意見が多数。
また、高木浩光氏は以下のように発言しています。

もちろん、技術的にそうだという話をするのはいいのだが、これを見て、「これじゃ全然だめ」だの、「はてな、なんとかしろ」だのとぬかすバカが出てきて困る。まだ荒らされてもいないのに、わざわざイタチごっこの手を自ら先に進めることもあるまい。やられたら次の手に進められるよう準備しておけばいいだけの話だ。荒らし対策の話は、脆弱性対策の話とは異なる。荒らしはしょせん程度問題であるし、取り返しのつかない被害が即座に出るわけでもない

費用対効果を考える際のポイント

私の該当エントリでは技術的な話題に終始していたので、費用対効果といった経済的な観点での考察は特に行っていませんでした。

高木浩光氏の発言にもあるとおり、脆弱性などに比べれば緊急性は薄い。この話題で費用対効果を考える際にポイントとなるのは、

現状でのスパマー避けの効果
現状のCAPTCHAを破る労力
CAPTCHAを修正する費用

といったところでしょうか。

スパマー避けの効果について、はてなのjkondo氏がスパムとの闘いというエントリで以下のように語っています。

まず、スパムコメントですが、これは特定の条件に適合したコメントをスパムとして自動判定して書き込めない措置を取ったり、ゲストがコメントを書くときには画像認証を行うようにしました。（この画像認証については、機械的に識別が可能だという話が先日上がっていましたが、現時点では大きな効果を上げています。効果が無くなればまた改善をします）

このことからもスパマー避けとして、成果は上がっているのでしょう。（私の別エントリの CAPTCHAとスパマーも参照のこと。ほとんどのスパマーはスクリプトキディと思われる）

確かに、はてな側は後出しジャンケンのようなもので、破られてから対策すればいいわけですし、スパマー側としてはCAPTCHA破りをしたところで、対策されるまでの短い期間しか使えません。

しかし、このCAPTCHAを破る労力と言えば、私が実証したとおり、小一時間程度なわけです。つまり、十分に「元が取れる」程度には軽微な労力なのですね。ですから、いつ何時にスパマーがアタックを始めてもおかしくはないという状況で、負の不確定要素、ネガティブリスクとなっているわけです。

そして、修正費用。
これがネガティブリスクの多寡に比べて高価なのであれば、先送りするという判断は正しい。もっともあのCAPTCHAを直すのに技術者をひとり、1週間使わせれば十分でしょうから月給100万の技術者を使ったとしても25万もかければ修正できる。

このことから、はてなは

「ある日突然SPAMまみれになった際に対策をする費用」 × 「その発生率」＜「修正にかかるコスト(25万以下と推定)」

と判断したということになります。

私が指揮する立場にあれば即座に修正をしますね。上記式だけでも修正するのに十分な理由ですが、 「我々はCAPTCHAのなんたるかなんて全く解っていませんよ」 という張り紙をしてブランド力を貶めている状況は耐えがたい。

技術力に対する評価はプライスレス。
はてなはユーザはどうせ技術なんて分んないんだから適当でいいんだよ、という姿勢なのかもしれませんね。

掲示板のマナーの感覚の違いはどこからくるのか

凪瀬 — Wed, 06 Feb 2008 16:52:00 GMT

質問者と回答者のマナーについてで掲示板でのマナーについてまとめていますが、こちらではその意味を考えてみたいと思います。

人の集まるところ、マナーは自然と生まれます。「情けは人の為ならず」とも言いますが、マナーを守ることは自分自身の利益となります。マナーを守らないと、結局のところ自分の望む結果を得られないことが多い。掲示板の利用マナーというのは、自分を含めた掲示板を扱う人全員が利益を最大にするためにあるわけです。

情報の共有の場と捉えるか、否か

まず、掲示板を何のためのシステムと捉えるかでマナーが自然と変わってきます。これは掲示板オーナーが方針を決めるものでしょうが、技術系の掲示板では「掲示板は情報共有の場」という考えが広く浸透しているように思います。

技術系の掲示板をあまり使ったことのない方の発言などから 「質問に対して誰かがボランティアで答えてくれる斡旋所」のように捉えていることが伺えます。このように捉えた場合、「情報共有の場」としての利用とはマナーが異なり、 その意識の違いがマナー云々のやり取りを繰り返し発生させる一因となっていると思われますね。

解答者斡旋所と捉えると、質問者個人が問題解決できればそれでよいことになります。よく引き合いに出されるマルチポストの例を考えてみると、情報の分散といったデメリットは考慮しなくてよくなるため、問題とはならない。
斡旋所として問題となるのは、マルチポストによって他の場所で解決したにもかかわらず、その報告がなされなかったために、回答者が無駄な労力を費やしてしまったケースなどでしょう。
そうなるとマルチポストそのものを避けようとまでする必要はなく、「解決の報告を怠らないこと」をマナーとすることで十分という考えが合理的です。

しかし、「情報共有の場」とした場合、マルチポストは情報の集積の妨げになる上、共有の場を個人の問題解決という利己のために私するように見えることから、激しく非難されることとなります。
そのような利用者がいるとコミュニティが崩壊するという危機感から排除しようとするわけです。これは排除する理由に相応の合理性がある。

いかんせん「情報共有の場」という考え方を理解してもらうには相応の苦労があります。新規参入者にその概念をいちいち教えるのもまた結構な労力です。

マルチポストなどは「結果的に答えを得られないよ」という利害に根ざした説明でとりあえずの納得をさせてやめさせる方法が楽ではありますが、「情報共有」という概念を解さない限り、マルチポスト以外の形でコミュニティに害のある行動を行いかねない。

「斡旋所」と捉えているなら少なくとも無償で答えを貰えたことに礼を言うことは自然なマナーとして受け入れられることでしょう。
しかし、コミュニティを「答えを略奪するための狩場」と捉えていると最悪で、答えが得られれば礼なんぞ言う必要もないと考えても不思議はありませんし、答えを得るために形だけでもへつらって機嫌を取っておけ、という思想にもなりうる。

そのコミュニティの利用者の大半は、心地よくてそのコミュニティにいるでしょうから、コミュニティが崩壊しないように努力することでしょう。
その際にマナーといったものが生まれ来るのでしょうが、どのような思想でコミュニティを捉えているユーザがいるのか。そのあたりを考えると、具体的な対処が見えてくるかもしれません。

アジャイル開発の見積もりとリスク

凪瀬 — Mon, 04 Feb 2008 18:53:00 GMT

ここ３年ぐらい同一案件のアジャイル的な開発をやっているのですが、見積もりについて経験則がまとまってきたので整理してみたいと思います。

まず、前提として以下のような作業を請け負っています。

顧客の要望を聞いて要件開発を行う
要件を元にシステムの設計を行う
設計を元にプログラムの製造を行う
テストを行う
運用時に発生した障害の調査

開発は１期のスパンが２か月～３か月程度で、開発した機能のリリースを行いながら順次機能拡張していくといった感じになります。

作業の見積もりはその作業の種別により分類されます。建築での比喩で表現すれば、大きく分けると設計図面を引く前と引いた後です。これに加え、突発的な飛び込み作業があるので、以下の３つに分類しています。

設計図面を引くまでの作業
引いた図面をもとに開発する作業
突発的に発生する作業

そして、それぞれの作業ごとに不確定要素（リスク）が存在します。

設計図面を引くまでの作業

要件開発の部分では、時間をかければ時間をかけただけ、作るべきモノの設計書(図面と比ゆしたもの)が増えます。顧客側のいいなりに作業しているとえらく時間を取られる可能性があります。その部分がリスクと言えばリスクでしょう。

しかし、どうせ図面を大量に用意したところで投入人数が決まっているなら１期の開発で消化できる量が決まっていますから、定量に達したところで開発側主導で中断するべきです。具体的にはシステムの設計の過程で、ある程度確度の高い見積もりができますから、積算して定量に達したらそれ以上の設計には着手しないで次回送りにします。

定量が定まっているためか、開発主導で中断できるせいなのか、この過程にかかる時間は比較的安定していてそれほど大きなブレはありません。

引いた図面をもとに開発する作業

この過程も、それほど開発工数はブレません。設計の際に洗い出した作業は思いのほか工数を外さないものです。しかし、怖いのは洗い出しに失敗して、見落としていた作業があった場合。この、作業の見落としは工数見積もりのブレの中では特に注意すべきポイントだと思います。

一番大きな痛手となるのは、設計が差し戻しになったケース。とても大きな工数を消耗してしまいます。設計者が用件だけではなくシステムの設計も把握している人材でさえあればこのリスクはかなり低減します。また、顧客との打ち合わせの仕方次第で仕様のどんでんがえしのリスクは軽減されます。

また、技術的なリスクもあります。とくにシステムのコアとなる部分など、高度な部分の開発は、やってみてできなかったというケースがあり、頭数を投入したからと言ってどうにかできるものでもありませんから、締め切りを後ろに伸ばすか、後の工程を短い期間で無茶してやるかという選択になってしまいます。

・作業の見落としがないようにする・技術的に不安がある部分は検証を事前に行っておくようにする

といったところを気をつけるとよいでしょう。

突発的に発生する作業

障害対応が主なものです。こればっかりはいつ出るのかわかったもんじゃありません。保険の考え方を導入して予備工数を積むしかないでしょう。

製造した機能ごとに算出した工数を予備として積んでおきましょう。私の方では

(製造にかかった時間 x 複雑さ係数) / (リリース後経過月数 * 調整係数)

といった算出の仕方をしています。時間経過に伴い、障害の発生率は落ちていくとしています。直前の期でリリースした機能は比較的高い発生率と想定し、古い期にリリースした機能ほど発生率は低くなるととらえています。

基準となるのは製造にかかった工数としています。これは設計や仕様書の策定、テストケースの策定、テストの実施を抜いた、プログラムの製造に関わる作業をてっとり早く定数化する手法です。

FP(ファンクションポイント法)などの規模感を測定する指標を持っているならそれらを利用してもよいでしょう。ただし、ステップ数は規模感の測定に用いるには誤差が大きすぎるのでそのまま使うのはやめたほうがよい。

ここのリスクばかりは本当にコントロールしきれない。一時期に集中的にバグが露呈することもあります。ですが、金融工学に基づく保険の手法に学んで、リスクに対して備えを用意する程度にはあがきましょう。

数学的帰納法で完全なテストを行えるか？

凪瀬 — Thu, 29 Nov 2007 15:00:00 GMT

以前、完全なテストは不可能だという稿を書いたのですが、これに対して反論しているページを見つけたので考察しておきます。

反論の骨子

該当ページの文章が短いので全文引用となってしまいますが、法的な引用の要件を満たせると思うので引用します。

思うに、それは論理学でいうところの帰納法で解決できるのではなかろうか。

完全なテストは不可能だ:
さて、プログラムの話に戻ります。intの引数を2個とる場合、その組み合わせは1600京ほどになるということを先の稿で述べました。そして、バグが「ある」ことを証明する場合、バグの例をひとつ探し出せばよいのに対し、バグが「ない」ことを証明するにはこの1600京のパターンすべてを網羅して検査し、全て正常に動いたということを提示しなければなりません。

数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。というかそうでないものの方が少ないはず。

悪魔の証明、という目の付けどころは悪くないのに。まあ、ちょと前に自分でも取り上げたわけだが。

つまり、帰納法を用いることで全てを演算することなく正しさを証明できるのではないか？という主張ですね。

帰納法とは何か？

まず帰納法とはなんでしょうか。概要を知るにはwikipediaがてっとり早いので該当項目を見て見ましょう。

http://ja.wikipedia.org/wiki/%E5%B8%B0%E7%B4%8D

帰納（きのう、Induction）法とは、個別的・特殊的な事例から一般的・普遍的な規則を見出そうとする推論方法のこと。対義語は演繹法。演繹においては前提が真であれば結論も必然的に真であるが、帰納においては前提が真であるからといって結論が真であることは保証されない。

帰納法は真実を得られません。一部の事例から、全体を推論するのですが、論理の飛躍が含まれます。
例えば、intを引数にとるメソッドに対し、-1,0,1の３つの値を入れた際にうまく動いたからといって、すべての値に対して正しく動作するとは言えませんよね。

帰納法とは3つうまくいったんだから、全部の値でうまくいくはずだという推論ですから、帰納法を用いてメソッドの完全性を求めることはできません。

数学的帰納法という名の演繹法

「数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。」と述べていることから、「帰納法」といっているのは多分、数学的帰納法のことを指しているのではないかと思われます。

さて、数学的帰納法というのは帰納法という名が付いていますが、実際には演繹法（えんえきほう）です。

http://ja.wikipedia.org/wiki/%E6%95%B0%E5%AD%A6%E7%9A%84%E5%B8%B0%E7%B4%8D%E6%B3%95

数学的帰納法（すうがくてききのうほう）とは、有限回の議論で可算無限個の対象に対する命題を証明するための数学の論法である。次のような手順で自然数全体に関する命題 P(n) (n∈N) が真であることを証明する論法である。

P(0) は真である。

任意の自然数 k に対し，P(k) が真であれば，P(k+1) も真である。

よって任意の自然数 n について P(n) は真である。

イメージとしては、2 により次々と次の命題の正しさが伝播されていくことになる。つまり、1 によりまず P(0) は正しく、P(0) と 2 により P(1) は正しく、P(1) と 2 により P(2) は正しく、以下これが果てしなく続いていく。このことによって任意の自然数 n について P(n) が正しいことが保証される。

なお、数学的「帰納法」という名前がつけられているが、数学的帰納法の解法プロセス自体は帰納法ではなく演繹法である。先に述べた、「2 により次々と次の命題の正しさが伝播されてい」った結果証明されていく様子が帰納のように見えるためつけられたにすぎない。

これは、学校で習いましたよね。
数学的帰納法はドミノ倒しに似ています。

あるドミノが倒れたら、次のドミノが倒れるようにしておく
最初のドミノを倒す

このふたつがポイントです。ドミノを倒すことで全ての数を計算するのです。
ですから、「数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある」というのは多分に誤解を含んでいます。数学的帰納法に拠らない証明で成立している定理もありますが、 数学的帰納法で証明されている定理に関して言えば全てを計算しているのです。

ドミノが勝手に倒れてくれるので準備を整えたら無限のかなたまで手間無く一瞬で計算できるだけのことです。

テストに数学的帰納法を適用するには

ブラックボックステストで数学的帰納法を扱う術はありません。あるドミノが倒れたら次のドミノも倒れるという証明ができないからです。
ブラックボックステストでは実行した結果を仕様と照らし合わせて等しいかみる必要があります。実行せずに正しい答えを返すことを証明することは不可能です。

となれば、ホワイトボックステスト的な手法をとらざるを得ません。それはもはや、プログラムのコードが正しく機能することを数学的に証明を導くことに等しい重労働です。

このようなアプローチは形式的検証と呼ばれています。

このアプローチでプログラムの完全な正しさを証明しようとするのであれば、数学者を大量に雇いいれ、幾千もあるメソッドに対してそれぞれ独自の証明を人力で解いていかないといけません。複雑なメソッドの正しさを数学的に証明しようとした場合、それは世紀の難問にも等しい難度を誇ることでしょう。

指摘もとのblogの言葉を借りるならば「帰納法、という目の付けどころは悪くないのに。」といったところでしょうか。

ソフトウェアの保守性はアップサイドリスクである

凪瀬 — Tue, 06 Nov 2007 12:58:00 GMT

ソフトウェアの品質と一口に言っても複数の属性が存在することは先のエントリでも触れましたが、この中の保守性に今回は焦点を当ててみたいと思います。

保守性が活きるかどうかは不確定

保守性というのは端的に言えば修正のしやすさを意味します。仕様変更や追加の際の工数が小さい、その作業過程でのバグの出現数が少ない、といったところです。

さて、この保守性の高さというのは、いざ変更を行おうとする段にならないと効力を発揮しません。
例えば初期のデータ移行のためのバッチとか、そういった「使い捨て」のプログラムでは重要視されません。

つまり、将来発生するかもしれない変更に対して、工数が少なくなるように保守性を高めるということは、アップサイドリスクである、つまり、発生するかどうかが不確かな利益であると言えましょう。

このアップサイドリスクは仕様変更があって初めて効力を発揮するものです。そしてその価値は、

修正の発生確率 × 省略できる工数＝保守性の高さの価値

という式で与えられるでしょう。

近年普及したリファクタリングの概念（動きを変えずに保守性を高める手法）は、一般には手を加えることによるバグ発生のダウンサイドリスクばかりが注目されます。
しかし、リファクタリングによって得られるアップサイドリスクと比較して検討されるべきであり、保守性というアップサイドリスクの価値をもっと関心を持って計測する必要があるのではないでしょうか。

リスクについて考える

凪瀬 — Sun, 04 Nov 2007 21:02:00 GMT

Programming SHOT BAR へようこそ。今回はリスクというものについて考えてみたいと思います。

そもそもリスクって何？

日常でもリスクという言葉を使うと思いますが、そもそもどういう意味なのでしょうか？

手ごろなところでWikipediaで調べると「危険に遭う可能性や損をする可能性を意味する概念」とありますね。
基本的には

発生確率×損害の大きさ

といった形で表されます。ここでは「損害」と書きましたが、金融用語では不確かさ、つまり「発生確率」の部分を意味し損得に関わらず「リスク」といいます。
とくに不確かな利益についてはアップサイドリスク、不確かな損害についてはダウンサイドリスクといいます。

行動心理学的に人間は確率を過大評価もしくは過小評価する傾向があります。端的には信じたいものを信じるわけですが、アップサイドリスクは過大に、ダウンサイドリスクは過小にという傾向が強い。例えば、宝くじやギャンブルなどのアップサイドリスクは過大に評価しますし、交通事故などのダウンサイドリスクは過小に評価しがちです。

しかし、このような評価の仕方をしていると取り返しの付かないミスをしてしまいます。例えば賞味期限切れの食材を使っても大丈夫だろう、とかそういう会社の傾くような出来事を行ってしまったりするわけです。これは、発覚する確率を過小に評価したという点と、また、発覚した場合の損害の大きさを過小に評価したというところに愚かさがあるのです。

リスク管理上はどんなに発生確率が低くとも、甚大な被害が発生する場合は避けることが求められます。

システム開発におけるリスクはなんだろう？

さて、システム開発におけるリスクというのはなんでしょうか？
まず、最初に断っておくと、これは全て列挙しきれるような問題ではありません。

こういったものがある、と挙げることはできますが、網羅することは難しいという性質を持っています。
ですから、さまざまな議論の中で少しずつ候補を挙げていき、その評価をしていくしかないと考えています。そういうわけで指摘などあれば遠慮なくお願いします。

とりあえず、議論の叩き台となるように、私が思いついたものを挙げてみました。

難易度によるリスク。開発過程で技術的難易度により開発が完了しない、もしくは納期が延びる可能性
仕様の不確定さによるリスク。仕様変更が発生する、もしくは使用の矛盾が発覚して修正を迫られる可能性
バグの発生によるリスク。バグが発覚して修正を迫られる可能性
担当者が働けなくなるリスク。病気・怪我・その他の理由で労働力が失われる可能性
開発環境に発生する障害。ウィルスの蔓延や、リポジトリのサーバの不具合、停電など。

これらのリスクは「品質」とも関連してきます。品質の向上によりリスクの発生確率を軽減できますし、発生した場合の損害も軽減することができます。

品質ってなんだろう？

さきほどは一口に品質といいましたが、品質にも色々な属性があります。

詳しくは参考リンクでも見てもらったほうがよいでしょう。

ソフトウェアの品質についてはISO 9126-1で定義されています。簡単に列挙すると

機能性
信頼性
使用性
効率性
保守性
移植性

となります。品質の属性は、あちらを立てるとこちらが立たずというところがあり、また、品質向上にかかる費用も青天井といったところですから、現実的にはうまくバランスを取ってどこかで妥協しなくてはなりません。

というわけで、品質の向上というのも複雑なパラメータを伴う数値だけでは捕らえにくい事項なのですが、これらの品質の良し悪しと、逸れに伴うリスクの高低が関連してくるのですからさらに厄介なのです。

といったところで、具体的な事項については次回以降で検討しましょう