ソフトウェア開発のコストと結合
こんにちは。ソフトウェア開発を進める上で、コストって結局、どこにかかってるんでしょうね?
そうですね。
今回はですね、Tidy Firstという本に関する議論の記録がありまして、
それをもとに、特に結合っていう考え方に注目して、ソフトウェアコストの本質に迫ってみたいと思います。
はい、よろしくお願いします。
あなたと一緒に、このちょっと深いテーマを探っていきましょう。
この議論でよく出てくるのが、ソフトウェアのコストって、作って終わりじゃなくて、その後の変更のコストが実は大部分で。
ああ、なるほど。
で、その変更コストを難しくしている、その原因の多くが、要素間の結合にあるんじゃないかと。そういう考え方ですね。
はい。資料を見ながら、その辺をちょっと深掘りしてみましょうか。
お願いします。
資料を読むと、確かにソフトウェア開発全体のコストで見ると、最初の開発費ってある程度はかかりますけど、
それよりもリレースした後の変更とか修正とか、そっちの費用の方がずっと大きいぞと。
そうなんですよね。
で、特にこんなにコストかかるの?みたいに、予期せず跳ね上がる原因、その多くが結合にあるんだっていう指摘がありました。
なんか、夜中に踏んづけてしまうレゴのパーツみたいな、そういう例えが出てましたね。
ああ、その例えすごく分かりやすいですよね。
ですよね。問題が起きるまでそこにあるって気づきにくいみたいな。
まさに。見えないところで、将来の変更をどんどん難しくしちゃう要因が進んでると。
うーん。
だから、コストを抑えるには、基本的にはその結合を減らしていく、つまり部品をうまく分離していくってことになるんですね。
はい。分離ですね。
ただ、ここがまた難しくて。
と言いますと?
分離するっていう行為自体にも、やっぱりコストがかかるんですよ。
ああ、そりゃそうか。手間がかかりますもんね。
ええ。だから常にトレードオフの関係にある。
これがソフトウェア設計の難しさの本質の一つと言えるかもしれませんね。
なるほど。その結合を減らす工夫っていうところで、資料だと通信プロトコルの例が上がってましたね。
はいはい、ありましたね。
インターフェース定義言語、IDLとかを使って直接的な依存をなくしましょうみたいな。
ええ。
でも、これを使っても完全に結合がゼロになるわけじゃないんだと。
そうなんですよ。結局インターフェースっていう接点は残りますからね。
うんうん。
で、さらに興味深かったのが、ある種類の変更に対する結合を減らすと、別の種類の変更に対する結合が逆に増えちゃうことがあるっていう主張。
結合と変更のトレードオフ
ああ、そこ議論になりましたね。
え?それってどういうこと?ってちょっと思いました。直感的じゃないですよね。
参加者の中でも、別の種類の変更って具体的に何?みたいに色々解釈が出てました。
はい。
で、最終的にしっくり来たのが、例えば新機能を追加するみたいな機能的な変更と、
あとは使ってるライブラリーをバージョンアップするみたいな技術的な変更、そういう異なる種類の変更を考えると分かりやすいんじゃないかと。
ああ、なるほど。機能追加とライブラリー更新。
そうです。つまり、機能追加をしやすくするために部品をすごく細かく分離したとするじゃないですか。
はい。
そうすると、今度はあるライブラリーを更新しなきゃいけなくなった時に、その影響があちこちの細かい部品に全部及んじゃって修正が大変になるみたいな。
うわあ、ありそう。
なんかこう結合の総量は変わらないみたいな、結合の保存則みたいなものが働いているんじゃないかなっていう話にもなってました。
結合の保存則、それは面白い視点ですね。
だから、闇雲に分離すればいいってもんでもないぞと、そういう警告とも取れますよね。
確かに、良かれと思ってやったことが恨めに出るみたいなのは避けたいですもんね。
本当に。現場のフラストレーションにも繋がりかねませんからね。
一方で、もちろん基本原則として、関連性は高いものはちゃんと集めて、業種度を高めて、関連性のないものは分けるっていうのもそれはそれで大事だよねと確認されてました。
それは大原則ですね。業種度と結合度は表裏一体なので。
で、そういうのを全部踏まえた上で、いよいよ本のタイトルにもなっている、先に整理すべきかタイディーファーストっていう問いかけが出てくるわけですね。
そうなんです。
コスト、収益、さっきの結合、業種度、そういういろいろな要素を天秤にかけて判断しなければいけないんだと。
まさに、その先行整理、タイディングって言いますけど、それは将来の変更コストを下げる可能性はあります。
でも、それが常に最前提とは限らない。
議論の中では整理すること自体が目的になっちゃって、なんていうかプログラマーの自己満足のためにちょっとやりすぎちゃうリスクみたいな話も出てましたね。
なるほど。きれいにしたい欲求みたいな。
そうそう。あくまで次の変更を楽にするっていう目的を見失わないバランス感覚が大事だと。
それともう一つ、ソフトウェアの設計ってコードだけの話じゃないんだっていう視点。
と言いますと。
チーム内のコミュニケーションとか、つまり人間関係にも影響を与えるんだっていう指摘もあって、これも結構、ああ、なるほどなと思いましたね。
深いですね。というわけで、ソフトウェアのコスト、特に結合とどう向き合うかというテーマで見てきました。
エリエ。
コスト管理の鍵はやっぱり結合にあるっぽいんだけど、単純に減らせばOKっていう簡単な話じゃなくて。
そうですね。常に複雑なトレードオフがある。その見極めがすごく重要ってことですね。
ええ、その通りです。そして、ある結合を減らすと別の結合が増えるっていう考え方、これは本当に示唆に飛んでると思います。
はい。もしそれがある程度普遍的な法則なんだとしたらですよ。
私たちはもうちょっと意識的に、どの結合はまあ残しておこう。どの結合が増えるのはまあ許容しようっていう選択をしていかないといけない。
うーん、選択ですか。
ええ。それは短期的な効率だけじゃなくて、もっと長期的に見て、そのシステム自体にとっても、そしてそれを作っているチームにとっても、より健全な選択って何だろうと。
なるほど。
そういう問いにつながっていくと思うんですよね。これを深く考えることが、これからのソフトウェア設計ではますます大事になってくるのかもしれません。
いやー、考えさせられますね。
あなたならどう考えますか。
