アーキテクチャ選定ではメリットとデメリットを考える ではフレームワークやアーキテクチャの選定は合目的でなくてはならない、ということを言いましたが、 「システムの贅肉」という曖昧な概念を説明できていませんでした。

なんとなくイメージはできるんだけど、論理的な定義をうまくあたえれていない…。

骨格 ＝ 要件の大きさ

まず、確認しておくことは、システムの規模そのものの大きさです。 要件定義・要件開発において、スマートになるように要件を決めよう、という話題ですね。

お客さんに「ちょっとここはこうなるようにしてほしい」とか言われたときに気にするのがこの点。 今の設計に無理なく乗るなら軽く「いいですよ」と返せるところですが、その一見小さく見える事象に対応するために 骨格がいびつになるような場合は悩んでしまいますね。

さて、そんな要件開発ですが、絶対値というか、要求される事象の大きさの下限は決まっていて、 目的を達成するために必要な最低限の骨格を作るだけでも、とても大きな骨格になってしまうものもあります。

ネズミかゾウかではなくて、肥満か筋肉質かだろうが言っているのは この骨格の大きさと、プログラミングのまずさからくる贅肉を混同するな、ということですね。

体の大きさ ＝ 実装の大きさ

要件を実装するにあたって、実装手段によってソースコード、つまるところ実装の大きさが異なります。 大雑把にいえばステップ数ですね。 (ステップ数という単位は誤差が酷いのであまり使いたくないですが、プログラムの大きさと正の相関を持つのは事実)

成長の早さ ＝ リリースまでの期間

システムを完成させるまでの期間、というのはゾウなりネズミなりが成人するまでの期間に相当するでしょう。

ゆっくり時間をかけて成長（プログラミング）が進み、完成までに数年の歳月を費やすシステムもあれば、 非常に高速で成長しわずかに数か月で稼働にこぎつけるシステムもあることでしょう。

一般には、小さなシステムの方が、リリースまでの期間は早く、大きなシステムほどリリース時期は遅い。

養育費用 ＝ 開発コスト

成人までの間にどれだけの費用を投入したのかという数値ですね。

成人後の成長 ＝ アジャイル性

アジャイルなシステムというのは成人が早い。割と未熟なうちにリリースしてしまう。 リリース後の成長も大きく、成人してからも代謝が高いのですね。

対してウォーターフォール式のシステム開発などは、成人後にほとんど成長は止まってしまう。 下手をすると成長などまるでなくて、「老後の介護」にばかり手間がかかるということもありえるのです。

代謝を高めるための設計手法と言うのもあります。こうした後の変更がある場合にそれは活きてくる。 でも、いざそのときが来ない限りはそうした設計の良さというのは日の目を見ない。 ソフトウェアの保守性はアップサイドリスクである で言ったのはそういう事情のことなのですね。

寿命 ＝ システムの寿命

システムは改修をしつつ、使われるわけですが、やがて寿命を迎えます。死因はさまざまですが、

• 土台となるOSやミドルウェアが死んだ
• 要求の変更に対応できなくなった

というのが大きいかなと思います。

システムというのは設計時に、いろんな前提条件を加味します。こういう部分は変更が容易なように、この辺は変えなくてもよい、とかいろいろ。 「全部対応できるように」だといくらカネがあっても足りません。

それらの前提が覆ってしまったとき、それがシステムが死ぬべき時だと私は考えます。

贅肉・筋肉 ＝ ？？？

さて、問題となるのがここですね。「実装の質」と言いたいところですが、ひとことに「質」と言っても質にも種類があるので混乱しやすい。

例えば、高い処理効率（パフォーマンス）をたたき出すようなカリカリにチューニングされたソースコードというのは、 変更に対してとても弱い。柔軟性に欠けるわけですね。

逆に抽象化を施し、仕様変更などにも柔軟に対応できるようなコードというのはパフォーマンスで劣る。柔軟だけど速度は遅い。

なので、これらのメリット・デメリットを考えた上で適度なところでバランスする必要があります。赤筋（反応が遅いが持続力がある）と白筋（反応が速いが持続力がない）みたいなもんですね。ハンマー投げの室伏広治氏は白筋が多く、マラソンは苦手だというエピソードもあります。状況を見て合致する「質」を選ばなくてはいけない。

ただ、一見して贅肉と分かるものも中にはあって、

• コードクローン。要するにコピー＆ペーストによって冗長なコードになっている状態
• 構造化がうまくされていない
• データ構造が非効率

といったところはかなり目立つ贅肉ですね。データ構造が悪いと、それを処理するプログラムも煩雑になって贅肉が贅肉を呼ぶ状態。

こうした、明らかな贅肉はそぎ落とすことでコードが数分の一になることがありますが、経験則からして1/10を超えない。 どんだけ贅肉で太らせようとても骨格が支えられないほどには大きくなる前にシステムが破たんするのではないかと思います。 人間の体重も世界記録では700kgぐらいらしく、限界までいっても10倍そこそこのようですね。

体脂肪を落とす効率

システムの贅肉を落とし、体脂肪率を10%にするためのコストと、体脂肪率10%から1%に落とすコスト、1%から0.1%に落とすコストが概ね等しいと思います。(無責任な社会、限定責任な社会から着想)

まぁこれは概念的な話なので数字が正確かというと怪しいのだけども、指数関数的だよね、というのは理解いただきたい。 過度なダイエットは費用ばかりが嵩むので、ほどほどの贅肉は許容せざるをえないというわけです。

とはいえ、このほどほどの贅肉はコードが数分の一に縮むほどの贅肉じゃない。人間だって体脂肪率が0%になることはないでしょう？多少の脂肪に病的に神経質になっても仕方がない。

合目的なアーキテクチャ選定

フレームワークやアーキテクチャの選定は合目的でなくてはならない。そこで取り上げられる評価軸は「小規模 - 大規模」なんて単純な1軸ではないわけです。

• システムの骨格の大きさ ： 要求事項の絶対値
• システムの実装の大きさ ： ソースコードの量
• リリースまでの期間 ： 開発速度
• リリースまでのコスト ： 開発生産性
• リリース後のコスト ： 可変性
• システムの寿命

「時間、品質、料金」のうちから、2つを選択できる、なんてジョークがあるのですが、示唆深いと思いませんか？

これらのうち、何を活かして何に目をつぶるのか、その比率はどの程度にするのかというのが、アーキテクチャ選定で悩む部分です。 小さなシステムは、使い捨てにすることもできる。リリースまでの期間が短くコストも小さいなら、定期的に使い捨てにするという方法論もアリでしょう。 過去のリソースを使いたいからCOBOLで開発というのもコスト・リスクが見合うならあるいはアリでしょう。

コンセプトは前提条件の上に繰り広げられるものです。コンセプトだけ聞くと「ないわー」と思うようなことでも、特定のシチュエーション下では「そうせざるを得ないね」という合理的なものであったりするのです。

目的があってその実現手段としてアーキテクチャを選ぶのですから、アーキテクチャ単体だけを取り上げて安易に良しあしと言ってはいけない。

出来ることなら、技能あるチームで今風のアーキテクチャで今風の設計をするようなシステム開発をやりたいものですね。