【ワレコの未来予想】人工知能がシステム開発すれば失敗しない【ワレコ X】

この記事は約16分で読めます。
スポンサーリンク

近頃、ネットニュースを見ていてシステム開発に失敗したと言う事例を二件見た。

どちらの事例も「動かないコンピュータ」記事で有名な日経BP社のITProの記事に詳しく紹介されている。

一つ目は旭川医大のシステムだ。

開発元のNTT東と裁判で争っている。

日経BPさんのサイトに詳しい解説記事があるが、その冒頭を引用させて頂く。

失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決

電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。

 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。

2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100%の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。

引用元 http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/

あかんがな。

 

もう一つは、京都市のシステム開発の失敗に関する記事で、同じく日経BPさんサイトから引用すると以下の通り。

関係が泥沼化、京都市が7億5000万円請求するもIT企業は支払い拒否

京都市が進めていたシステム刷新の稼働が遅延している件で、京都市とシステム開発を受託したシステムズ(東京・品川)の関係が泥沼化している。

京都市は開発遅延の責任を巡って2017年10月12日、システムズに対して10月27日までに約7億5000万円の損害賠償を支払うことを求めていた。

ところがシステムズはこの支払いに応じなかったことが、日経コンピュータの取材で分かった。京都市とシステムズともに、訴訟に発展する可能性を否定していない。

引用元 http://itpro.nikkeibp.co.jp/atcl/column/14/346926/110201189/

あかんがな。

 

まあ、今の世の中、システム開発には失敗が付き物だ。

この記事では、自称プログラミングの変人のワテが失敗しないシステム開発について、ワテ独自のアイディアを紹介したい。

では、本題に入ろう。

スポンサーリンク
ワテ推薦のプログラミングスクールで学ぶ
スポンサーリンク
スポンサーリンク

システム開発の歴史を見る

メインフレームコンピュータが普及し始めたのが、確か1970代くらいからだと思う。

ワテの知らない時代だ。

参考までに主な大型コンピューターの写真を紹介しよう。

世界初の商用コンピュータ UNIVAC I

UNIVAC-I-BRL61-0977.jpg
写真 世界初の商用コンピュータは1951年のUNIVAC I (パブリック・ドメイン, Link

ユニバックと言うらしい。でっかい磁気テープがあるなあ。

ベクトル型スーパーコンピュータ Cray-1

Cray-1-deutsches-museum.jpg

写真 ベクトル型スーパーコンピュータ Cray-1 

(By Clemens PFEIFFER – 投稿者自身による作品, CC 表示 2.5, Link

知らない人が見たら、ホテルのロビーなどに置いてある椅子やがな。

この椅子が物凄く高かったらしい。

1975年、クロック80MHzでピーク性能160MFLOPSのCray-1が発表された。反響は大きく、ローレンスリバモア国立研究所とロスアラモス国立研究所が第一号機(SN-1)の争奪戦を繰り広げたほどである。

結局、後者が勝ち、半年後の1976年に第一号機が納入された。クレイ・リサーチ社の公式の最初の顧客はアメリカ大気研究センター(NCAR)であり、1977年7月に886万ドルを支払い(790万ドルが本体、100万ドルがディスクの代金である)、3号機を入手した。NCARのマシンは1989年1月まで使用された[2]。

引用元 Cray-1のWikipedia

1977年の886万ドルは今の貨幣価値で幾らかな?

1ドル360円の時代なら、31億8千9百6十万円

1ドル100円くらいの現代なら、8億8千6百万円

いずれにしても高い。

Cray-1とワテ自作パソコンCore i7 4770Kの性能比較

  クロック ピーク性能 RAM 消費電力 重量

Cray-1

(1977)

80MHz 160MFLOPS 1Mワード 115kW 5.5トン

ワテ自作パソコン

Core i7 4770K

(2013)

3.5GHz 177 GFLOPS (*1) 32GB 500Wくらい 10キロ

表 Cray-1とワテ自作パソコンの性能比較

(*1) https://www.pugetsystems.com/labs/hpc/Haswell-Floating-Point-Performance-493/

まあ、ピーク性能差でワテ自作パコンはCray-1の約1000倍、消費電力は230分の1、重量は500分の1くらい。

メモリー量は32000倍だ。価格だと 32億円/20万円=16000倍か。

36年でこんなに進化するのか。

そんな高性能パソコンをネットサーフィンで怪しい動画を見るとか、怪しい掲示板を見るとか、そんな用途にしか使わないのは勿体ない。

さて、そんなワテの個人的な事情は皆さんも興味ないと思うので、本題に戻ろう。

 

1970年代や80年代は、上記のような大型コンピューター(メインフレームなどとも言う)を使ってシステム開発をやっていた。

使用する言語は、COBOLとかFORTRANだ。

それが1990年代に入るとオープンシステムと言うのに取って代わる。

 

オープンシステムの時代 1990~

ワテの理解では、オープンシステム(Open System、オープン系)とは、UNIXオペレーティングシステムを使ったコンピュータでシステムを組む事だ。

かつ、一台のコンピュータで処理するのではなてく複数のコンピュータを組み合わせて処理を行う、所謂クライアントサーバーシステムとか言う事例も多い。

分散システムとも言う。

大型コンピューターの場合だと、ハードウェア価格だけで数十億円もした訳だが、それがオープンシステムになるとハードウェア価格は10分の1かそれ以下くらいになるだろう。

でも、IT企業としては、オープンシステムを採用したシステム開発を、大型コンピューターシステムの10分の1の価格で受注してしまうと赤字になるだろうし、システム開発の手間の殆どはソフトウェアの開発だから、オープンシステムにしたからと言って、安く出来る訳では無い。

分散処理は欠陥システム

と言う事で、オープンシステムによる分散処理が普及して行くのだが、ワテに言わせればそれは欠陥システムと言っても良いだろう。

何故かと言うと、東京本社にサーバーが有って、各都道府県の営業所にクライアントマシンを多数配置するようなクライアントサーバー型の分散システムにしたとすると、管理が大変だ。

「南大東島営業所のUNIXマシンが起動しない!」

なんて言うトラブルが東京本社に連絡が有っても、南大東島営業所にはUNIXエンジニアはいない。南大東島の島内を探せばUNIXに詳しい人も居るかもしれないが、そんな余裕はない。かと言って東京本社から今から出発しても飛行機で何時間も掛る。

ちなみに、Googleマップの経路探索では、計算不能だった。

「羽田、〒144-0043 東京都大田区」 から 「南大東村、沖縄県島尻郡」 までのルートを計算できませんでした

と言う事で、1990年~2000年頃に、IT企業に煽てられて(おだてられて)メインフレームシステムをクライアントサーバーの分散システムなんかに置き換えた企業は、面倒なシステムを売りつけられたもんだとワテは思う。ある意味、被害者か。

その後の2000年代以降は、IT企業はお客さんに対してクライアントサーバーシステムは管理が大変だから、データセンターに設置したLINUX系の大型システムを使う一元管理システムを売り込む訳だ。

今まで分散していて管理が大変だったクライアントサーバーシステムを、LINUXの大型サーバーに集約する。

それだったら、昔のままのメインフレームの一元管理システムで十分だったわけだが。

まあIT企業としても、商売だから何かを売らなければやっていけない。世の中、そう言うもんか。

さて、そんなどうでもよい話題はさて置き、本題に戻ろう。

システム開発の大部分は要件定義とデータベースの設計

まあ、ワテの場合、この分野の専門家では無いので、あくまでワテの個人的意見であるが、システム開発をする場合には、お客さんの要望を聞き取ってどんなシステムを希望しているのかを明確にする作業が重要だ。

一般に「要件定義」と言われている作業だ。

家を建てる場合に、大工さんにこんな間取りで、窓はこの辺りに開けて、風呂場はここで、トイレはここ。二階建てで木造で総額2000万円(建物のみ)でお願いします。

そんな感じで、顧客の希望している内容を具体化して書面で整理する作業だ。

銀行とか役所のシステムなら、端末を操作する人が見る画面のデザインなどもこの要件定義書で明確にしておく。

そのようにして完成した要件定義書を元にソフトウェアの開発が始まる。

その中の細々とした作業はここでは言及しないが、重要なのはデータベースの設計だろう。

つまり、会社でも役所でも、業務で使っている膨大な帳票がある。あるいは、現行システム上で保管されている膨大なデータもある。

要件定義書では、それらを新システムに移行するに当たり、今後利用するデータの種類や、分類方法も決める。データベースの正規化とか言うやつか。

まあ要するに、無駄なデータ構造を排除して、必要最小限でスッキリしたデータの管理を行う作業だ(ちょっと違うか?)。まあ、そんな感じ。

システム開発の手法に関するお勧めサイト

システム開発の手法に関しては、たまたま見付けたこのサイトが詳しい。

IPA 独立行政法人 情報処理推進機構

発注者ビューガイドラインの公開

発注者ビューガイドラインの公開:IPA 独立行政法人 情報処理推進機構
$secondCategoryInfo.description

 

ところが、システム開発は良く失敗する。

なぜか?

システム開発に失敗する理由

まあ、それは簡単で、途中で仕様を変更してくれと言う要求が出て来ると収拾が付かなくなるからだ。

旭川医大の場合、日経BPの記事によると以下の通り。

だがプロジェクトの開始直後から、現場の医師から追加開発の要望が相次いだという。2009年3月の会議では、同医大の医師が「現行システムの機能が提供されないと現場の混乱につながり、認められない」と発言し、他の医師も賛同。同医大は数百件の追加開発をNTT東に要望した。

 2009年7月、NTT東が625項目の追加開発要望を受け入れたうえで仕様を凍結し、システムの本番稼働を当初予定の2009年9月から2010年1月に延期することで両者は合意した。

 だが、仕様凍結後も追加の要望は止まらず、旭川医大はさらに171項目の開発を要望したという。

引用元 http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/

あかんがな。

数百件もの仕様変更を受け入れていたら、必ずと言っても良いくらいシステム開発は遅れるか失敗するだろう。

この場合、NTT東が医大側の仕様変更を受け入れたのが問題なのか、仕様が十分固まらないまま開発を進めたのかどっちが悪いのかはワテには分からない。

家を建てるなら仕様変更は出来なくはない

まあ、家を建てる場合なら、仕様が固まっていても、工事が始まってから多少の仕様変更は可能だ。

窓の位置を変えるとかサイズを大きくするとか。

4畳半の部屋を二つ作る予定だったが、一つにして9畳の部屋にするとか。

でも、2階建てで作る予定だったのを3階建てにしてくれと言うような大掛かりな仕様変更は難しいかもしれない。

でもやれば出来なくは無いだろう。

つまりまあ、家を建てる場合には、目で見て手で作業するから、現場で現物合わせで加工して仕様を変えるなんていう荒業も出来なくは無いのだ。

それと、例えば二階の部屋の窓の大きさを少々変更したくらいでは、一階の風呂場の施工に影響が出るなんて事は殆ど有り得ない。

コンピュータのシステム開発は仕様変更が困難

しかしながら、コンピュータのシステム開発ではそれは難しい。

一番の理由は、作っているシステムが目に見えないからだ。

作っているシステムの実体は、コンピュータに入力されたソフトウェアなので、それはデジタルデータ。完成して稼働させれば画面に各種の操作パネルが表示されるが、そのパネルを操作して正しく稼働しているかどうかなんて、目で見て分かるようなレベルの問題では無い。

建物なら、風呂にお湯を入れて水漏れしていないかなど、現場で素人が確認しても目で見て分かる。

でもシステム開発では、コンピュータの中を覗いて見ても、正しくシステムが動いているのかなどは全く分からない。

住民票発行システムの画面のレイアウト仕様を、要件定義では以下のように決めたとする。

[姓]

ワレコ

[名]

太郎

[生年月日]

平成10年10月10日

[現住所]

ワレコ県ワレコ市

 

【印刷ボタン】

でもここに、追加の項目として、[年齢]とか[本籍地]の項目を追加してくれって言われても、簡単ではない。なぜならそれらのデータをどこかから持って来る必要がある。

具体的にはデータベースから検索して引っ張って来る。その為にはデータベースを検索するSQL文を変更しなくてはならない。

さらに、もし、追加依頼が来た項目が[本籍地]くらいなら、それはデータベースのどこかにあるデータだが、データベースのテーブルに新規にカラムを追加する必要がある新規のデータなら、益々影響は大きい。

その影響の範囲がどこまで及ぶのかが、システム開発では視覚的に分り辛いのが最大の問題だろう。

まあ、システム開発では要件定義が終わった後は仕様変更はしないのが鉄則ではあるが、現実的には、開発を進めているうちに見落としていた項目などがあり、仕様を変更したいと言う要望は出るだろう。

なので、極力そう言う仕様変更が出ないようにプロジェクトを進めるのがIT企業のシステムエンジニアの人の腕の見せ所だと思う。そう言う人をプロジェクトマネージャーと言うのかな。

さて、システム開発に限らず、後で変更したい事は日常生活でも良くある。

Windowsのゴミ箱の反対の注文追加箱みたいなのを作れよ

アマゾンで幾つかの商品を注文して確定させたのだが、前々から買おうと思ていた品物を注文するのをウッカリ忘れていた。そんな経験は誰でも有るだろう。

Windowsやマックの利用者ならウッカリして必要なファイルやフォルダを削除してもゴミ箱に入るのでそこから復元出来る。

それの逆のイメージで、ショッピングサイトで注文を確定しても、一定時間以内なら(例えば3時間以内)、さらに追加で注文が可能とか。

まあ、翌日配達みたいなスピーディーなサービスには向かないが、注文して1週間後くらいに届けば十分と言う品物も多いだろう。そんな注文なら、注文確定してから一日くらいは追加注文が可能な猶予期間があると嬉しい。

名付けて、

注文ウッカリ忘れ救済システム – 24時間以内なら間に合います!

みたいなの。是非、世の中のネットショップで採用して欲しい。その時には、アイディア使用料頂きます!www

さて、本題に戻ろう。

つまり、ワテが予測するシステム開発の未来像だ。

ワテが予測するシステム開発の未来像だ

人工知能を活用すれば、システム開発の手法は激変すると思う。

最近の人工知能は囲碁の世界チャンピョンに勝つくらいに実用性も高くなっている。

とは言ってもGoogleが総力を結集して開発しているシステムなので、誰でも自由に使える訳ではないが。

でも、今後、コンピュータ性能が向上すると同時に、AIソフトウェアも進化して、人工知能プログラムは益々世の中に普及すると思う。

要件定義に人工知能を使う

例えば、現行の市役所システムの画面をテレビカメラで常時撮影する。

その画像を人工知能に認識させる。

液晶ディスプレイやブラウン管の画面に表示されるのは、殆どの場合文字データだけだから、高解像度で撮影すればその中の文字を認識するくらい簡単だ。

そして、人工知能は、毎日毎日、市役所で各種の帳票を発行するための操作画面を見続ける。

そのようにして、

どの帳票発行画面ではどんなデータが利用されていて、

どのデータとどのデータは同一画面に表示されるとか、

操作する人は、どんなデータを入力しているのかとか(例えば人名の入力が多いなど)、

兎に角、沢山の事を人工知能は学習する。

さらに、その人工知能に、今後こんなデータも追加で扱いたいなどと教える。

例えば、マイナンバーが新たに導入されたが、それは現行システムでは扱っていないので、新システムではマイナンバーの項目も追加したいなど。

それらの膨大な学習データを元に、人工知能は現行システムで使われているデータを洗い出し、その関連性を分析して、かつ、新規に追加すべきデータもミックスして、それらを完璧に正規化したデータベースのテーブルを自動生成する!

まあ、ワテの勝手な推測では、現在のレベルの人工知能技術を組み合わせれば、技術的には十分可能だと思う。

どこかの優秀な大学の人工知能研究をしている情報処理系研究室で、数億円くらいの予算があれば、試作品レベルのものは作れるのでは無いだろうか?

名付けるなら、

人工知能による全自動システム開発のシステム

今までの人海戦術のシステム開発の時代の終焉だ。

システムエンジニア大量失業時代の到来⁉

もしそんなシステムが開発されると、日本だけでなく世界中のシステムエンジニアが大量失業の時代がやってくるだろう。

ワテの予想では、2020年頃には実用化されるんでは無いだろうか?

人工知能システムなので、仕様変更も全く問題無く自由自在に可能だ。

学習時間は一ケ月も見ておけば十分だろう。

会社でも役所でも一ケ月作業すれば、月末にはどんな処理があるなども分るし。

あるいは、念のために一年の期間を人工知能の学習時間に割り当てれば、月末だけでなく、夏休み、ゴールデンウイーク、年末年始、年度末などの通常業務とは異なる時期では、どんな追加業務が発生するかなども学習出来るし。

人工知能は疲れを知らないから、追加で1000件でも1000万件でも仕様変更を要求しても、なんら苦情も言わずに、その仕様に沿った完璧なデータ構造を作り出し、かつ、操作画面のレイアウトも自動生成。

まさに、神様仏様人工知能様!

なので、従来は数年掛かりだった大規模システム開発が、人工知能システムによる開発では、学習期間に一年、システムの自動生成には数時間、そして新システムはあっけなく完成‼

かつ、人工知能システムは失敗しない。

自動生成された新システムのテストを人手で数か月掛けて行い、問題が無ければ新システムとして公開する。

その時点で少々の仕様変更を人工知能に依頼しても、問題無く対処してくれて数時間掛けて再計算すれば、その仕様が反映されたシステムが自動生成される。

どう?

みずほ銀行システムは4000億円も掛かったらしいが、4000億円も使ったら、ワテが予測しているそんな人工知能システムを開発を十分に出来ると思うんだが。

そうなると、システムエンジニアの人は、大量失業するのか?

まあ、それはワテには分からない。

 

ところで、ここまで書いていて、ふと思った。

人工知能が人工知能を開発するアイディアはどう?

現状では、人工知能を開発しているのは人間のプログラマーだろう。

でも、その作業を人工知能に任せる。

つまり、人工知能を開発出来る人工知能を人間が作るアイディアはどうだろうか?

最初の人工知能は人間が作る。

その一代目人工知能があまり賢くなくても、その人工知能が開発した二代目人工知能は少し賢くなる。

そうやって誕生した二代目人工知能が三代目人工知能を開発する。

そうやって、n→無限大 に行くと、全知全能の神の領域の人工知能が誕生するぞ!

ファインマンのマイクロマシンの人工知能版だな。

ワレコ予想と呼んでくれ。

まとめ

自称プログラミングの変人のワテによるシステム開発の歴史、失敗する原因、そして、人工知能を活用したシステム開発の新手法について紹介した。

人工知能に毎日毎日、現行システムの画面を見せ続けたら、どんどん学習して、そして自動で新システムを生成してくれる。

正に夢のようなシステムが、ワテの予想では数年以内に実用化レベルに到達するだろうと思う。

でも、高度に発達した人工知能も個性を持つかもしれないので、毎日毎日帳票画面を見せ続けたら、嫌になっちゃって、海に飛び込んで逃げるかも知れない。

まさにおよげ人工知能くん状態だ!

以上、ワテの驚愕の未来予想図だ。

スポンサーリンク
ワテ推薦のプログラミングスクールで学ぶ
コメント募集

この記事に関して何か質問とか補足など有りましたら、このページ下部にあるコメント欄からお知らせ下さい。

アイデアコラム
スポンサーリンク
warekoをフォローする
スポンサーリンク
われこ われこ

コメント