目的：
首都高速道路の更新問題を知る。
数十年先のことは考えない咎めを知る。
情報システムでも同じことが起きていることを知る。
モノを作るときに、保守や更新のことを考えて作るべきことを知る。
両者について、あるべき建て替え・更新方法を考える。
ねらい：
情報システムの「順次再構築」方式を研究いただく。
「順次再構築」方式を実現していただく。
ーーーーーーーーーーーーーーーーーーーーーーーーー
首都高速道路の建て替えが問題になっています。
１９６２年から開通が始まった首都高速道路は、
総延長３０１キロのうち４０年以上経過した部分が３割あり、
劣化が進んでいるのです。
コンクリートの寿命は７０年らしいのですが、
高速道路のように荷重が大きなトラックが高速で走れば、
４０年でも寿命になるようです。
首都高速道路会社の調査研究委員会では
建て替え（大規模更新）や大規模補修の選択条件や
工事の実施方法を検討しています。
一方、国土交通省の有識者会議では、
一部分ですが地下化を提言しています（９／１９）。
前者の委員会は、
発想の原点が今の道路の更新となっていて、
検討の選択肢が限られています。
こちらは、１２月に答申案が出る予定です。
建て替えはたいへんです。
同じ場所で建て替えるのなら、
長期間交通止めにしなければなりません。
地下化の利点は現在の交通と関係なしに工事ができる点と
都心部の景観の改善です。
ただし、コストは何割増しのようです。
先日、大学の運動部同期ＯＢ会で、
日本橋川クルーズと称するツアーに参加してきました。
渡し船程度の船で、日本橋川から隅田川に少し出る
あたりを1時間半ほど乗るのです。
ところが、そのコースの大半が高速道路の下です。
日が差さないし非常に目ざわりです。
東京オリンピックの時に、
用地買収その他間に合わないということで、
川の上に作ってしまったようです。
他国では、首都の中に
このような高速道を作っている例はないそうです。
早急に地下化か廃止をすべきと思いました。
次は、地下に掘るにしても、
その次の更新期にどうするかを考えておく必要があります。
５０年先のことは、またその時に考えればよい、
では無責任でしょう。
そもそも、今の高速道路を初めに作ったときに、
５０年先にどうするかを考えて作っていないようです。
しかし、これから作るものは、
次の更新がやりやすい方法をとるべきです。
地下なら、別の穴を掘るのでしょう。
別の穴ができたら前の穴は潰すのです。
穴だって、一挙に短期間で掘れるわけではないので、
少しずつ既存のトンネルに繋いでいけるような継ぎ手部分を
あらかじめ用意しておくことが必要です。
そのために、多少カーブが多くて走りにくくなっても
やむを得ないと考えなければなりません。
（専門家はそのくらいのことは考えているでしょうが？）
以下も素人の上野案です。
地上の高架なら、
１０メートルくらいのコンポーネントを作り、
これを既存道路の撤去する部分に置き替えて、
既存道路に繋げていけるような方式を開発します。
10メートルくらいのコンポーネントは、
どこかで作成して、超大型クレーンで吊り上げてセットします。
この方法だと、
交通止めはごく僅かの期間で済みます。
そのための大型クレーンは特注で作っても引き合うでしょう。
そのくらいの気持ちで取り組むべきですね。
そういう方法をとる、ということが決まれば、
専門家なら、もっと良い案を考えられるでしょう。
ノーベル賞と同じでアイデアを出すことが重要です。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
情報システムのソフトウェアについても
まったく同じようなことが言えます。
情報システムの場合、
法人の基本業務用のシステムは平均１４年使っています。
その結果、初期開発とその後の改修（保守）の比率は
1対4になっています。
改修（保守）のコストの方が高いのです。
多くの企業の現在のシステムは、１０数年前くらいから、
レガシーと言われる古いホストコンピュータのシステムから
クライアントサーバシステムやＷｅｂのシステムに更新しました。
多くのシステムは、そろそろ更新の時期が来ているのですが、
全面更新ができないでいます。
その理由は、一挙に多額の投資ができないのと、
長年の改修で複雑になっているシステムを
問題なく更新する自信がないからです。
更新を先延ばしにしているために、
予想外の障害が起きたり、
改修に手間暇がかかったりする負担を続けているのです。
そこで、一挙に作り直すのはなく、
少しずつ作り直す「順次再構築」方式に期待が集まっています。
（「順次再構築」という言い方は、上野の言葉ですが、
ほぼ同じコンセプトは、他の方も主張しています）
「順次再構築」方式は、こういう方法です。
まず、再構築対象となる全体のシステムを
机上で小さい単位（コンポーネント）の組立て構成に設計します。
その上で、そのコンポーネントを一つずつ、
順番に作り替えて、作り替えた新しい部分を
古い部分に繋げていきます。
この方式は、継ぎ手の部分を両端に作らなければならないので、
一気に通しで作成するよりも、余計な開発が必要です。
しかし、一旦でき上がった後は、
何らかの理由で変更したいこと（改修）が発生した場合は、
その部分だけを検討すればよく、
全体への影響をを見る必要はありません。
このための技術は（ＭＤＭやＳＯＡなど）、
別の目的ででき上がっていますので、
その技術を使用すれば、
このコンポーネント入れ替え方式は実現可能です。
要約すると、こうなります。
開発の際には、一気に通しで作った方が、
工数が少なく安くできます。
コンポーネント継ぎ手方式は、
改修の際に、全体への影響が少なく、
多くの場合、そのコンポーネント部分だけを見ればよいので、
効率的で、かつ間違いが起きません。
また、何らかの理由で、ある部分を交換したい場合も
容易に可能です。
先に述べましたように、
今や改修の工数・コストの方が４倍も大きいのですから
改修がやりやすい構造の方が、
ライフサイクルコストがはるかに安くなります。
しかし、これまでは、
後で発生する改修のことを考慮しないで、
開発の際に都合のよいように設計しています。
こんな全体観のない方法がまかり通っているのです。
この状況は日本だけでなく、欧米でも同じことのようです。
米国ＩＥＥＥが刊行している
ＳＷＥＢＯＫ（ソフトウェアエンジニアリングの基礎知識体系）
の第３版（今年刊行予定）でも、
開発の際に、保守（Ｍａｉｎｔｅｎａｎｃｅ）のことを考慮しない問題点
が指摘されています。
今後は、
次の改修や作り替え（再構築）がやりやすい方法で
開発しましょう！！
0 件のコメント:
コメントを投稿