2017年08月24日

なぜ汎用的にする必要があるのか


初めての方はこちらを「はじめに

ここのところ設計の汎用性について色々具体的な例を挙げて述べてきましたが、今回はより大きな視点でそもそも根本的になぜ汎用的にする必要があるのかを考えてみたいと思います。

基本的な原理


基本的な原理としては汎用的になれば組織にとっての資産価値的なものがより高くなるからだと言えると思います。下の概念図で説明してみたいと思います。
53N028_001.jpg

ある組織でソフトウェアをA、B、Cと順番に三つ開発したとします。
図の上側のパターンは特に汎用的な要素は無く開発した場合です。
棒の高さはソフトウェアの機能の高さ(量、質)を表しています。ソフトウェアの規模と考えてもいいかもしれません。AとCは似たような大きさのソフトウェアでBは少し小さなソフトウェアというイメージです。

下側のパターンは部分的に汎用的な作りをした場合です。
Aを開発する時にその一部(斜線部分)を一般的に使える汎用的な部品として作りました。するとBを開発する時にはこの部品を利用てぎるのでBの高さは自動的にこの部品分(赤矢印)かさ上げされる事になります。そしてBの開発自身でもやはりAと同様に一部を汎用的なものにすると、Cの開発時にはAの部品に加えて更にBの部品も利用てぎるので二つの部品分かさ上げされる事になります。

ここで「資産」という表現をした意味は青の矢印を見ると良く分かります。
上では青の矢印は似たような位置を推移しているのに対して、下では時間が経つ程に資産が貯まって上がっていく様子が伺えます。

この様に単純な原理としては汎用的にするという事は組織にとって資産が貯まっていく様なものだと言えます。

現実的な要素


原理としては今述べた通りですが実際には勿論もっと色々と考えなければならない事があります。
その一つは再利用性です。
上の例ではAで汎用的に作った部品(斜線部分)がBでそのまま丸ごと使われる前提で書きました。しかし実際はAで例えばプリンター関連の部品を汎用的なものとして作ったとしてもBでは印刷に関する処理が特に無ければ全然使われることはありません。例え処理があるとしても部品の一部、例えば10%の機能しか使わないならばかさ上げも10%にしかならないという事になります。
また、汎用的と言ってもどの程度汎用的かという問題もあります。
Aで作ってBでは使えたとしてももしかしたらCでは少し機能強化しなければならないかもしれません。勿論Bでいきなり手直しが必要になる可能性もあります。そのあたりは最初に作った時にどれ位汎用的に出来ているかによって変わってくる事になります。

もう一つは汎用的にする為のコストです。
上の例では図の上のAの大きさも図の下のAの大きさも同じものとして書きました。これは暗にAを開発するコスト(パワー)が汎用的にしてもしなくとも変わらない事を意味しています。しかし実際には「設計における汎用性とは」から一貫して述べているように汎用的なものはそもそも検討の段階から時間がかかる可能性があります。ものによっては実際の製造やテストの段階でかなりコストがかかる事になるかもしれません。

併せて考えれば結局以下の様な式で表せるかもしれません。
利得 = 一回の再利用によるコスト減 * 回数 - 汎用的にする分のコスト増

プラス側は掛け算で表しましたが実際は積分ですから見積もるのはなかなか大変そうです。実際にこの式で計算するというよりは汎用的にする場合の利得はどの様な要素で変動するのかを表す概念的な式という事になります。なので汎用的にする場合は頭の中だけとしてもこの式で利得がプラスになるという判断が必要です。

内部的な処理の場合


それでは他のソフトウェアでの利用は無い自ソフトウェア固有の処理の様な場合には特に汎用性は考える必要はないのでしょうか?
そのソフトウェアが一度作ったらその後決してバージョンアップをしないという事ならいいのかもしれません。そうでないならばやはり汎用的に作る事を意識する必要があります。

例えばワープロの様な図形を扱っているソフトウェアを開発したとします。
リリース後に次の様な要望が発生したとします。このソフトウェアでは2Dの図形しか扱っていなかったものの四角形だけどうしても3Dが必要だというものです。要望に対応する為にまずは四角形の処理部分だけを3Dに機能強化しようとしました。ところがそれだと他の図形に対して四角形だけ毛色の違うものになってしまったので図形に関するあらゆる処理の中に"if 四角形"という分岐が山の様に入る事になってしまいます。もし本当にこんな対応の仕方をしてしまったらこの図形処理部分は手を入れる度に腐って行ききっとバグが頻発するようになって最後は機能強化をしたくとも手を入れる事も出来なくなるでしょう。そういう事態を引き起こさない為には図形全体を3D対応するしかありません。勿論四角形だけの小手先の対応に比べればパワーはかかります。それでも将来性を失いたくないのならやるしかありません。

もし最初に作り込む時点で仕様は2Dでも設計としては3Dに耐えられるものにしておけば状況は全く違います。ほとんどパワーがかからずに対応できる事になりますし品質もより安定的です。

この様に内部的なものでも汎用性はやはり将来のコストに大きな影響を及ぼします。

自衛の為に


実は本来この様な問題は企画の問題です。
企画が製品のロードマップとして
○○年 V1 2D版
△△年 V2 3D版
  :
といった見通しを立てられていなければなりません。
しかし仮にこういった立派な企画の存在する組織だとしても企画も神様ではありません。「やらない」と言い切っていた機能を「やっぱりやる」と言わないとは限りません。
少なくとも開発は自衛の為にいつもこの様な汎用的にする意識を持っているべきだと思います。「やらないって言ったじゃないか!」と文句を言って揉めていても意味がありません。所詮は同じ社内なのですから。リリースされるソフトウェアにのみが意味があるのです。
ですからどの部署のどの人間が問題を解決しても良いのです。開発として読める限りの読みを働かして設計をするべきなのです。

一覧


メニュー

関連


なぜログやエラー処理の組み込みは苦労するのか
事例:ブログ投稿システム-出力部構造
設計における汎用性とは


記事を広める



posted by 善 at 18:27 | Comment(0) | 設計 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。