あれ、どうやったっけ

(要求される知識量大目の)ツッコミ系テキストサイト風blog。文が安定するまで書き直しあるからメンゴ。

32年越しの「Σプロジェクト」反省会を開催します

長くて読めんわ1行で言えよ

通産省は「業務アプリのソース差し出せ」とSIerに迫ったので、SIerはハード売りの話にすり替えた。

今北産業

  • 通産省は当時の技術水準では実現不可能かつクソ短納期のプロジェクトを開始した
  • オカミがIT分かる技術者を飼ってないうえに外部の人の意見ガン無視キメたので誰も止められなかった
  • SIerが旧通産省「コード提供せい」プランにキレて、しくじりに付け込みハード売りのハイエナをキメた

飼ってるという表現は不穏当ですが、僕大阪民国人なのでご勘弁

注意

マジメに論じる系の奴なので、敬称は全て略とします。

日経コンピュータ 1990/2/12号のコピーがあるんだよね(ゲス顔)

コピー枚数は法律の範囲に収まりました。Σプロジェクトの記事はコピーして持ってますけど何か?

f:id:osaka_zumai:20171228005855j:plain

f:id:osaka_zumai:20171228005913j:plain

f:id:osaka_zumai:20171228005926j:plain

Σ計画(別名「Σプロジェクト」or「シグマ計画」)について少々

1985年に「1990年に開発者が25万人不足する」という予想(「ソフトウェアクライシス」)への対応として、(旧)通産省は「業務系アプリ開発を自動化するアプリ」開発計画を始動。

コードネーム、Σプロジェクト

当初のプランは以下の通り。

  1. 業務系アプリ開発の工業化を目指し要件定義~保守管理まで全てを自動化する「Σツール」を開発する
  2. プラットフォームは「SystemV」系OS(理由は不明、AT&Tの名前が貼りついているせいか)
  3. OSと開発自動化ツールを乗せるためのハードウェア要件の制定
  4. コードを置く「Σセンター」を用意、コードはそこにアップロードされ、別会社も流用できる

なお4番についてはOSSの草分け的存在たる岸田孝一の発案によります。SourceForgeとかGithubを先取りしようとしたもので、悪し様には言えませんが……まあ「業務系アプリのコード」になるのと、Σセンター接続への専用線のコストが高すぎたのとで殆ど利用はされませんでした。

また岸田としては「ASCIIが開発した日本語対応BSD」を高評価していたのでBSD推しではあったようです。ASCIIってあのカドカワと合体したとか、昔ファミ通持ってたアスキーですよ? 彼らは「出版業務の効率化」としてTeXに手を入れたり、自社でイロイロカスタマイズしたりと技術が分かるハッカー出版社だったのです。今だと「トラ技」とか「インターフェース」あたりくらいしか近しいところないですね。

ま、続けましょう。

「Σツール」という何かにクソースの臭いがする……

Σツールというのがクセモノです。これを現代風に言いなおします

  • Redmineのようなプロジェクト管理ツール
  • Rationalっぽい要件定義とか業務モデリング関連ツール
  • GeneXusのようなコードジェネレータ + Githubみたいなのからコードスニペットをギってモリモリとコードジェネレート
  • SI Object BrowserのようなDB関連ツール
  • Subversionのような版管理システム(Gitではないでしょう)
  • Lint系ツール
  • VisualStudioのようなIDEやデバッガ

あたり全てを2年でコードコンプリートするということです。この時点ですごくヤバい案件に見えませんか? 

実際の所ほとんど実現されませんでした

うまくいくわけないだろヴァーカ。

日経コンピュータ 1990/2/12号」P78によらば「アンダーセンコンサルティングの評価」として

Σツールがカバーする範囲はI/O設計、データ分析の一部、コード生成、プロジェクト管理の4項目。
業務分析や機能構造化といった上流工程、テスト支援や成果物管理のような工程はカバーしていない
ことが分かる。

とあります。これって相当頑張ったって話じゃないですかね? ただ、上流工程や下流工程を完全にカバーできていない上、そもそもターゲットが広すぎるのです。マンパワーとかそういうレベルじゃない。

世界一スコープクリープした案件ということですから。

もし通産省内に技術が分かる人がおり、かつ、その人に発言権があったとすれば「国産コードジェネレータで止めよう」で収まってたと思われます。これは「COBOL」に限った場合は当時の技術水準でも実現可能なことでしたし、大手電機メーカーが「自社の汎用機専用コードジェネレータ」として実現していたことです。

ですから、まあ(当時既に電機大手が作っていた)コードジェネレータの共通化を図るプロジェクトとして立て直し、OSとか全部捨てがベターだったかな、と。JSRとかPEPとかPOSIXのようなものですね。

もし本当に「ソフトウェア開発の工業化」を目的とするなら、ひとまずのオチは「どの汎用機でも動くコードジェネレータ」に絞ったはずです。

どうも通産省の内部にITが分かる人はいなかったか、いたとしても発言権がなかったので続行したのです。

それって旧日本陸軍の失敗と同じや

過去にも技術論軽視でムチャやってしくじった実例はあるんですよ? 旧日本陸軍の「一式戦『隼』」。

技術分かってない人がしくじった例を出すのが目的なので興味ない人は飛ばしてね。

「二式戦『鍾馗』」は「普通のパイロットでもアンチP-51に最適」と分かっていたとか 「二式複座戦『屠龍』」にナナメ銃付けたのが夜戦でB-29落とすのに著効と分かっていたのに、ベテランでないとP-51落とすのが困難な「隼」を作りまくらせたのです。総生産数は「隼」5751機、「鍾馗」1227機。

鍾馗」は高度10000mまでの上昇速度にやや難ありらしく、インターセプター用途というか「アンチP-51」がメインになるかと。安定してB-29を高高度で迎撃できる可能性があったのは唯一「五式戦」だけでしょうかね。

一応補足すると、夜戦では爆撃機が単独で飛び、護衛機のP-51「マスタング」は付かない場合が殆ど。どうやら接触事故防止のようですが詳細は承知してません。とにかく当時は 双発複座の重い「屠龍」でもB-29にコンタクトし斜銃ぶっぱして落とせたのです。夜戦限定ですが。

日本陸軍にガチの技術者がいたら、鍾馗と五式戦を主軸とし、夜戦スペシャルで「機体上部に、ナナメ上に銃身向けた屠龍」に張ったはずです。疾風はラインの関係上湧いてくると思いますが……。

日本の官僚組織には技術屋がどうにも存在しえない理由があるようなのです。だから技術勝負になるとボロ負けなんです。

理由としてはおそらく……「技術的な実務経験はないけど知ったかぶり満開君」が常に発生するということでしょうか。

知ったかぶり君の実現性のないプラン、エライ人には説得力があるように聞こえます。なぜって、エライ人も知らないから。ちょうど知識水準が一致ってなったら話題弾みませんか? ですから知ったかぶり君の意見は上層部に通りやすいのです。

少なくとも通産省の場合はソレでダメになりました。ですんで、過去の航空機の例に関しても似たようなことが起こって、隼増産なんてことになったものと思われます。

もし官僚機構内に本当の技術屋がもしいたとしたら、「ケチ付けるだけのどうしようもない奴」と疎まれて退職か僻地かとおもいますがね。霞が関に戻れることは二度とないでしょう。Σの場合は外部のアドバイザー + 通産省の担当ですから、通産省の中の人が飛ばされる形にはなったかもしれませんね。

なお、軍事面に関しては兵頭二十八「日本の防衛力再考」「陸軍機械化兵器」「日本海軍の爆弾」「地獄のX島で米軍と戦い、あくまで持久する方法」を参照されてください。戦前の陸海軍の総括は既に完了しています。

予後の話をしようか

Σに関しては、岸田がブチ切れて喧嘩別れするくらいに「ハードの外販」の話にしてしまいました。例えば不治痛みたいなSIerがな

結局できたのは「Σワークステーション」とショボいツールだけなのです。一応コードジェネレーションはできたそうですが……複数名の当事者曰く「クソ遅くて使い物にならない」という評価ですね。で、Σワークステーションを地方に売る、と。

一応Σ計画は「採算出すプロジェクト」とされてましたのでね。三セクの類ですよ。ですが失敗です。

失敗の具合は下記の「(コ)業界の掟」と「From Kangaroo Court:Camino A Los Vulgo」をご参照ください。

前述の「日経コンピュータ」によらば、P89で「中野正考 通産省電子政策課長」がΣ計画立て直しのため、Σを中国とかウルグアイに売るとか言ってたんですが、残念ですがSonyの「NEWSワークステーション」により完全に爆死してます。

「仕様書駆動開発」やりてえ需要の権化 = Σ計画

恐らくですが、通産省は「ソフト開発の完全自動化」「コーダー死ね」「日本語で書かれた仕様書大好き」に取りつかれていたのです。

そうなった理由は幾つかあり得ます。

  • ソフト開発の規模が膨らんできたのでコーダーを雇うコストがバカにならない
  • というかコーダーの技術論分からんから日本語でしゃべれ
  • (当時からその名前であった)SEの人たちとやり取りするだけで完結してくれるツールが必要

現代にもつながる何かが旧通産省の内部には合ったのかもしれません。この辺は推論ですが……現代でも超高速開発なんてのがもてはやされたり不治痛がみずほ案件でInterDevelop(仕様書からコード吐くツール)持ち出した、みずほがOK出したなんて辺りを鑑みると、そのような推論も可能だと思います。

仕様書駆動開発がやりたかったんですよ、旧通産省の彼らは。

具体的には「業務システムのための上流工程入門」(渡辺幸三、日本実業出版社、2003)がP21で代弁してくれています(表示の都合で適宜改行入れてます)。

最終的には「詳細設計」と「プログラミング」が統合されると考えられています。
つまり、プログラマが基本設計の内容を規定の様式にしたがって詳細化するだけで、
コードをほとんど意識することなしにシステムができあがる体制が将来的には実現されるでしょう。

「コードなんかいらない、仕様書書いたらコードをゲロしろ」です。

なぜ? お前らの言うことなんか分からないし分かりたくもないから日本語でしゃべれ。

彼らは技術論が分からないし、そんな人員を用意もしたくなかったんでしょう。きっと今でもそうです。

あるいは、IBMが始めたビジネスモデルを維持しようとしたか。キーパンチャ + プログラマ(or SE)の話に戻したかったのかもしれません。

今のところ業務系のビジネスモデルは「世界一厳しい瑕疵担保条項に対する元請けのリスクテイク + 下請けが発狂する」という形で成功しています。未来にもこれは続くでしょう。だって業務系のビジネスモデルは約50年ほど請負スタイルなんだよ? もう、永続すると予想したほうが正しいです。

なんにせよ「設計と製造(コーディング)の分離」をやりたかったんでしょう、旧通産省の彼らは。

「おいSIerソースコードうpれ」 → SIerブチ切れてハイエナモード開始

Σ計画実施の他の理由には「メインフレーマーのコードをソフトハウスに移転する形で、ソフトウェア開発効率の向上をやっていきたい」とかもあるそうです。「岸田孝一、Σを語る」より引用します。

こんなふうになってくると、そもそもΣが技術移転を狙いとして構想されたプロジェクトだったと
いうことが、なかなか思い出せなくなるほどです。もっとも、通産官僚の頭のなかでは、それほど
矛盾はないのかもしれません。何回か議論していてわかったのですが、彼らは、メインフレーマーの
ソフト部門こそが日本の情報産業の中核であり、そこに蓄積された"すぐれた技術"をまだ"脆弱な"
ソフトウェア・ハウスに移転することが必要だと、かたくなに信じているのですから。 

技術移転の方法は

  • メインフレーマーがΣセンターにコードをアップロードする
  • 下請けがそのコードをダウンロードして、コードジェネレータのテンプレとする
  • コードジェネレータとテンプレと仕様書によりアプリができる

ということですね。

日本語の仕様書を書き、コードジェネレータに食わせたらコードができる。そして、ジェネレータのテンプレは「メインフレーマー」が供給する。ソースコード置き場は「Σセンター」。それが旧通産省が実現したかったことの全て。

ソースコードをタダでうpってソフトハウス養うSIerなんていたんですかね? だからSIer的にはメインフレームワークステーション外販の話にするしかなかったのでしょう。

1992年の論文により「コーディングは設計だ」と指摘されている

残念ですが、コーディングはそれ自体がファイナル設計です。

1992年の論文「ソフトウェア設計とは何か?」が結論でしょう。 http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

ですから「仕様書駆動開発」は恐らく永遠に失敗に終わるでしょう。要件定義 → 仕様書書く → アプリができる、は有り得ません。

現在に於けるΣの利点は1コだけある

「Σ計画」の「コードジェネレータ」の部分は恐らく実現可能です。まあ開発の効率化程度は可能? くらい。カスタムは要りますがね。

OSSのフリーなコードジェネレータをオカミがカネ出して書かす。

これくらいでしょうか。何分「超高速開発」のツールは1ライセンス100万円とか普通なので。

それで一応SIerのソフト開発効率化にはなるかもしれません。ディープラーニングとかありますから(ソースが一定数揃うなら)それっぽいソースは吐けるかも。今のAIは短編小説書けるレベルですしね。

また、RedHatよろしく自社で鯖立てて「外部にあるソースとかテンプレは置くけど、ウチ独自のはサブスクリプション結んでな」の方向性もあるでしょう。

あるいは自社の宣伝としてソースだのテンプレだのアプリだのはGithubなりに上げて、カスタムは有料(iDempiereとかodooの類)とかですかね。

通信インフラも当時のクッソ高いΣセンター接続専用線なんてもういらんのです。

まあジェネレータで出来るのはMS Accessのアレくらいですが……どうも日本には超高速開発的な需要というか楽々とかWagbyが一定数の需要あるみたいですし。フリーのコードジェネレータは中小企業向けとかの業務アプリ開発やら、業務効率化には有用かもしらんですわ。

「Σ計画」について見直すとしたら、そこだけですよ。

ΣはUnix系OSの普及に寄与したなどの話はありますが、Sony「News」のほうが有意義でした。Σの貢献はないものと考えたほうがいいのではないか、と判断します。

「Σ計画」の失敗を生かすとすれば、(現)IPAなり経産省は業務系アプリ開発用コードジェネレータを未踏にて書かせるべき。業務系アプリの開発効率化には寄与するかも。以上です。

ふりかえり

よかった点

  • 業務効率化のためにコードジェネレータを作ろう! って話を出したくらい?

悪かった点

  • どう考えても当時では開発規模がデカすぎるものを決行したこと
  • SIerに騙されないように分かってる技術者を雇ってないこと
  • 分かっている外部の人間の意見にガン無視キメたこと

いじょ。

もう一つの爆死である「第五世代コンピュータ」について少々

第五世代コンピュータ」を一言でいえば「AWS Lambda」が一番近いモノで、言語はProlog関数の推論・適応を並列でやらすってこと。渕一博のコンセプトはこれでした。

ただ、旧通産省は予算獲得のため、今で言うならディープラーニング機能積んで作業を自動でやるコンピュータの開発」と言いまくった次第です。旧通産省約30年未来のこと、今でようやく実現の目途が立つことを喧伝していたということになります。

これ以上の説明は恐らく必要ないでしょう。オカミの内部にどれだけ技術者が存在しないかが良く分かる事例でしかありません。

ソース不定のあやふやな話

どこかで「Σ計画1年目はエース投入、2年目でボンクラと交代」的な記述をどこかで見た……と思うんですが、今回マジメに探してみたら見つかりませんでした。

各社の汎用機で動くコードジェネレータにも関連する可能性がある話なので、ソース見つかると助かるんですが、ご存知の方いたら連絡寄越しやがれください。

参考リンクとか資料

キチンと調べて書いてある文献は現状これしかありません。せいぜい、Σに関しては80年代の技術書を複数の図書館で探し回ると稀に記述がある程度。

興味があるなら「当時のコードジェネレータ」に関する書籍を探す必要があります。きっとあなたも僕のように既視感を覚えるはずだ。

なお古い雑誌は「歴史ある大学図書館の司書さん」に頼まないと出てきません。僕は立命館の司書さんに引っ張ってもらいました。市立・府立図書館は古くなった雑誌を捨てます。

最悪阪大か京大を覚悟してましたが……何とかなるものですね。

これは単純な広報パンフレットですが「オカミが何をしたかったのか」は書いてあります。注意すべきはIPAの話ということ。現在のIPAではありません。

調査の起点となるリンク集として有意義です。

当時の人の意見として、リアルな状況はどうだったのかの説明。

日本に於けるOSSの草分け的存在かつΣ計画を最も良く知る人物による裏話。

正直に言えば「岸田孝一、Σを語る」が総括として最も適切でした。後日岸田はΣと喧嘩別れしてますので、彼のアドバイスは(旧)通産省には聞き入れられなかったことになります。

日米のソフトウェア技術の大きな違いは、米国には国防省(DoD)があり、
日本にはないという社会組織の違いに起因しているのではないでしょうか。

が総括になるかと思います。

別視点では(誤字もあるんですがそのまま引用 + 改行入れ調整、文字コード変換時のミスかと)

 REVIEW:私の目から見ると、あなたは、固定観念の壁にぶつかっているかのように
見受けられます。ソフトウェアが、ハードウェアのおまけである(たとえ現実には有科で
あっても、人々の心のなかでは、いまだに無科である)かぎりにおいては、ソフトウェア
開発技術の重要性は軽視ざれ続ける気がします。この固定観念をひっくり返すにほどのような
戦略が必要だとお考えですか。

KISHIDA:たいへん難しい質間ですね。人間の頭のなかの思考パターンを変えるには、長い時間
が必要でしょう。しかしそうした変化はかならず起こります。Σの例からも明らかにわかるように、
現在、ソフトウェアの開発のポリシーとしては、革の根のボトムアップ型より、むしろトップダウン
的な考え方のほうが優勢ですが、これはプログラマーの文化とは真っ向から対立しています。通産省も
メインフレーマーも1年以内にこのことに気づき、その結果、彼らはΣの方向性を全面的に変えなければ
ならなくなるだろう、私はそう信じています。 

という「IBMが日本で始めた多重請負型ソフト開発ビジネスモデル」 vs 「米国風OSSスタイルモデル」のケンカがΣ計画であった、ともいえるわけですね。残念ですが現時点でも日本の業務系ではソフトはハードのオマケであるということになっています。

その証拠の一例は別記事にも書いた通りなんですが

  • ソフトはハードのオマケだから、安価かつ工業製品グレードの品質でないとダメ
  • 現実はそうなってない(経営者 or ユーザー視点)
  • そうでないから世界一エグイ瑕疵担保条項が付いてくる

ってことになっています。一応自分の説明を言うなら RISC-VとかAI絡みは、1980年代初頭なら電機子会社が扱ってたかもしらん - あれ、どうやったっけ の「昔はIT先進国だったんだよ日本」あたりに書きました。僕の予想では「業務系については」未来永劫そうだと思います。

ソシャゲ―の「基本無料・ゲーム内でガチャ課金」周りを鑑みるに他の分野でも多少は「ソフトは無料が当然」って考えられているのか? って気はしないでもないですが、ありゃ初期のツカミの話でもありますから、別にしたほうがいいですかね。

参考に な ら な か っ た リンク

池田信夫 blog : シグマ計画

もうちょっと突っ込んで調べてもらいたかったかな……まあ茶飲み話程度のようですから敢えては言いませんが一応突っ込ませて?

余談

似たようなことを2chで書いたことあるんですよ。昔の人が知ってないかなと思って。検索で引っかかったら僕です。

コードジェネレータ絡みに興味があったのでその辺聞いてみたら「いや自分間違っとるで、コードジェネレータは一部の自治体とか金融程度でしか使われてなかったで?」という回答でした。あざす。

2017/12/30 余談 update 1

こんなん見つけたんです。

「何故か」の部分は皆さん疑問のようですから、一応最後に強調しようかなと。

通産省SIerに、お前らが持ってる業務系アプリのソースを公開せいと暗に迫ったからですよ。

SIerとしてはブチ切れて滅茶苦茶にするくらいしか手がなかったんです。

あとSystemV絡みについては……推測としては「フリーの(誰にも責任を問えない)」BSDではなく、「責任者がハッキリしているAT&T」の方を選んだせいかも。アレですよ、技術的な意味では「CentOS」でもイケます、とこっちが言っても相手さんが「ケツ持ちが明確なRHELを使ってほしい」とか、そういう奴。

SystemVを選んだ理由を推測するならその程度ですね。今のところソースは見つかっていません。