リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない
森崎さんのBlogを読んで、ソフトウェアもエントロピー増大の法則を避けられないのだなあと思った。
だが、ソフトウェアはハードウェアとは違う特徴がかなりあると思う。
考えたことをメモ書き。
【元ネタ】
ソフトウェア保守の法則(リーマンの法則)、ご存知ですか?:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ
バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ
リーマンの法則とは、上記記事にもある通り、ソフトウェア保守に関する経験則。
元々は5つあるそうだが、「ソフトウェア工学・システム工学ハンドブック―エンピリカルアプローチによる法則とその理論」によれば次の3つにまとめられると言う。
リーマンの第1法則
使われるシステムは変化する。
リーマンの第2法則
進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
システムの進化はフィードバックプロセスによって決まる。
リーマンの第1法則は、よく使われるシステムはVerUpによって変化させられることを示す。
第2法則は、ソフトウェアのVerUpによって、ソフトウェアもエントロピー増大の法則から逃げられないことを示す。
第3法則は、ソフトウェアの変化やVerUpは、ユーザの声やハードウェアなどの環境の変化を取り込むことによってその方針が決まることを示す。
いずれも考えてみればあたり前のことだが、経験則としてまとめることによって、一つの知識として捉えることができる。
上記の3つの法則を読むと、改めてアジャイル開発がその法則をうまく取り込んでいるように思える。
アジャイル開発では「変化を抱擁せよ」の言葉があるように、ソフトウェアの変化を前提として受け入れる。
WF型開発が仕様凍結をキーワードとして、変化しない環境で開発するように持っていくのとは別の発想だ。
そして、ソフトウェアの変化は通常はVerUpによってもたらされる。
VerUpの理由は様々だ。
例えば、WindowsOSのVerUpに対応したり、新しいiPhoneに対応したり、機能を新規追加したり、致命的なバグを修正したり、など。
だが、Googleのバグ予測アルゴリズム: プログラマの思索にも書いたけれど、直近に頻繁に修正しているほどバグが埋め込まれている可能性が高い。
バグ修正のソースが、実は新しいバグを埋め込む危険性は実は非常に高いという事実が経験則として知られている。
Googleはその経験則を元に、バグアルゴリズムを作った点が素晴らしい。
さらに、ソフトウェアのVerUpの方向性を決めるためには、周囲からのフィードバックが大きな条件になる。
ユーザからの要望が高い機能、ユーザが見つけた致命的な障害は修正・反映する方が、ソフトウェアの価値が上がる。
ソフトウェアが動く環境、つまりWindowsOSやiPhoneがVerUpしたならば、それに合わせてVerUpした方がより高速になるし、使い勝手も上がる。
ビジネス環境が突然大きく変化したならば、以前決めたVerUpの機能も見直して、大胆に不要な機能を削って、別の機能を追加したりしたいものだ。
つまり、ソフトウェア開発ではフィードバックプロセスをいかにコントロールして、どの機能拡張や品質改善をソフトウェアに反映していくか、という仕組みがとても重要。
オープンソースソフトウェアの開発では、熱心なユーザの力を利用して、β版として新機能を使ってもらったり、問題の早期発見や問題修復を手伝ってもらう仕組みがある。
それは、ソフトウェア開発の特徴をうまく利用していると思う。
同様に、商用のパッケージ製品やWebサービス、受託開発でも、その仕組みをうまく利用したいものだ。
アジャイル開発では、XPのオンサイト顧客、Scrumのチーム/スクラムマスター/プロダクトーナーという組織体制などのように、ソフトウェア開発の組織体制にも従来のハード製品の開発とは違った仕組みを取り入れようとしているように思える。
色々考えてみる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント