一人の人間が把握できない程の大規模なシステムを作るためには、「問題の構造」を抽象化を行うことが重要なことは、システムエンジニアリング（その４）で説明した通りだ。付け加えるなら、大規模なシステムだけでなく小規模なシステムでも「問題の構造の抽象化」は有効な手段である。

さて、「問題の構造の抽象化」は、次の二つの側面を持つ。

（１）問題の構造化

　システムを分割し、問題の構造を構築する。

（２）評価

　「問題の構造」を評価する。

この内、（１）は、本来、システム内に存在する問題を拾い上げ、それらの関連を考慮することだ。しかし、詳細な「問題の構造」は、具体的な機器構成の検討を必要とする場合がある。

（２）は、「問題の構造」を評価するのだが、数値化するのが望ましい。この「評価」の結果を用いて、システム設計をコントロールするのだ。

如何にも「システム設計」らしい「機器構成の検討」は面白そうなので、一般的に、（１）を優先してやってしまう傾向になる。しかし、「問題の構造の抽象化」の最終的な目的である「評価」を理解せずに「機器構成の検討」を行うと無駄になることが多い。無駄どころか、マイナスの結果になることすらある。

ここは、はやる気持ちを抑えて、まずは「評価」について検討しよう。

さて、「評価」だが、システムエンジニアリング（その３）に登場した「バランスの悪い桶」を再登場させ、これを使って説明しよう。

まず、やってはいけない事は、「一部の要素のみを評価の対象にすること」である。

当たり前のようだが、陥り易い間違いだ。例えば、自動車なら「エンジンのパワーのみ」とか「サスペンションの形式のみ」に注目することだ。図の「桶」の例では、最も短いＢの板の長さを評価の対象とすることになる。

確かに、Ｂの板の長さを長くすると、それに桶に入る水の量は比例して増える。だが、それは、Ｂの板がＤの板の長さになるまでの間の話であり、それを超えると効果が無くなる。にも拘らず、「Ｂの板の長さのみを評価の対象」とした場合は、延々とＢの長さを長くし続けようと改良を加え、他の板よりも遥かに長くなり、さらにバランスの悪い桶になるというのは、既にシステムエンジニアリング（その３）で説明した通りだ。

次に陥りがちな間違いは、「速ければ速いほど良い」とか「大きければ大きいほど良い」と言った節操の無い「評価」だ。

「桶」の例なら、「桶の中に入る水の量」のみで評価する事だ。この場合、「桶の量」をドンドン増やすように改良が続けられ、やがて、桶は家よりも山よりも何よりも大きくなって行く。本来、この桶が何の目的で使われるかを明確にしておかないと、とんでもない大きさに桶が成長してしまう。例えば、この「桶」は、人が運ぶものだとすると、桶が重くなり過ぎ、人が運べないほどになると全く意味をなさないものになってしまう。

最初に、「桶」が、どのような使われ方をするのかをイメージすることが大事だ。

この図のように、家の外にある井戸から家まで水を運ぶための「桶」を考えよう。

実際に「桶を使う人」＝「ユーザー」から、何が望みかを聞く。

「毎日、水を運ぶので、できるだけ多い量の水を井戸から家に運びたい。」

これが「ユーザー」の望み、堅い言葉で言うと、「要求」である。

陥り易い間違いが、「要求をスペックで置き換える」ことだ。

例えば、「ＸＸリットルの水の入る桶」と言う言い方が、「スペック」である。またまた、車の例えで言えば、「６人家族でキャンピングを楽しみたい」が「要求」で、「２５００ｃｃ級のミニバン」が「スペック」である。

次に、「運べる水の量」を検討する。まず、「水を含めた桶の質量」と「一日当たりの運べる回数」の関係を調べる。実際に使う人＝「ユーザー」に桶と同じ形状の色々な重りを運んでもらい、図の右上のようなグラフが得る。重すぎると運べないし、重さがゼロでも、ある程度以上の回数を運ぶことができない。だから、グラフのように右下がりのグラフになる（直線になるかどうかは極めて怪しい）。

また、「水を含めた桶の質量」と「一回に桶で運べる水の量」は左下のグラフになる。

「桶の効率」を

（桶の効率）＝（桶に入る水の量）÷｛（桶自体の重さ）＋（桶に入る水の量）｝

とすると、グラフの赤い線は、「バランスの悪い桶」の長さがバラバラのような「効率の悪い桶」であり、グラフの青い線は、板の長さが一定で無駄な部分が無い「効率の良い桶」だ。

「１日に運べる水の総量」は、右下のグラフになる。このグラフは、先の二つのグラフを掛け合わせたものだ。グラフの中央部の山の頂点が、最も「１日に運べる水の総量」が多いところだ。同じ山の頂点でも、赤い線より青い線の方が、量が多い。つまり、「効率の良い桶」が良いことになる。

このように右下のグラフの頂点を目指すように「評価」することが良いことが分る。

すなわち、

・「桶の効率を良くする」

・「その上で、１日に運べる水の総量を最大にする桶の大きさにする」

に、ブレークダウンできる。

ところが、上記のようなブレークダウンをすると、間違った最適化を行う可能性が出てくる。

図の左上の「バランスの悪い桶」は、先の「ブレークダウン」で評価して、改良すると、右上のようになる。これは一見すると、正しい改良のように見える。

ところが、「一部の板の長さを長いままにし、それに別の板を通す」ことで、右下のように「持ちやすい桶」になる。こうすると、「桶の効率」は、むしろ悪化するが、持ちやすいので、「一日当たりの運べる回数」は増え、最終的に「１日に運べる水の総量」は増える可能性もある。

単純に「桶の効率」だけを追求すると、右下のような「持ちやすい桶」を見付ける事はできない。このように、右上への最適化を近視眼的な「局所最適化」と言い、右下への最適化を「大局的最適化」と言う。「評価」をあまりにも抽象化し過ぎて、本質を見失うと「局所最適化」に陥り、「大局的最適化」ができない事が多い。

「評価」は、「要求」の本質に合わせて、柔軟に変化させる必要がある。最近のシステムエンジニアリングでは、このように「実どのような使われ方をするのか」だけではなく、「故障したとき、どうやって修理するか」「不要になった時、どう廃棄するか」までをイメージすることが、重要だと言われている。

ところで、ユーザーの要求が

「毎日、水を運ぶので、できるだけ多い量の水を井戸から家に運びたい。」

の場合、図の右下のような「持ちやすい桶」が最適設計であろうか？

私は、そうは思わない。

「毎日、できるだけ多い量の水を井戸から家に運びたいのなら、井戸から家までホースか管を引いて、ポンプで水を汲み上げた方が良い」と提言するだろう（電気が使えれば、電動ポンプで、そうでなければ、足踏み式ポンプで）。

「そんなのインチキだ。」と言われそうだが、ユーザーの要求を分析すれば、ポンプの方が良いに決まっている。仮に「桶作りの専門家」であっても、「桶以外の解決方法」があれば、提言できなければ、本物の「システムエンジニア」ではない。「桶」はあくまで手段であり、目的ではない。誰かが言ったが、「宇宙で書き物をしたければ、スペースペンを開発するより鉛筆を使った方が早い」のだ。

今回の最後の陥りやすい間違いは、「手段を目的化する」だ。

注意

ブログのコンテンツの内、「告知」など時期よって情報価値が無くなるのは除いてある。また、コンテンツに付いたコメントは書き込み者に著作権があるものと判断し、ここに持ってきていないので、コメントを見るときは、元々のブログコンテンツを参照してもらいたい。

その他、ブログ発表後、コメントなどの内容を反映するなど、内容を変更しているものもあるので、注意してほしい。