自動運転車の時代？甘過ぎる。
整備された平らなアスファルトの道のみを行き来きできるのはごく限られた地域だけで、今時分の様に積雪量が多く日常的に除雪が間に合わない状況になったらもうダメだろう。
都庁がクリスタルタワーの様に見える様な天候では無理に近い。

濃霧のため、★★自動運転車は起動しません★★★

とか天気予報に出ることになるのだろう。
脇道のたった１０ｃｍの新雪でも固く固められた雪の上にシャーシを乗り上げてしまえば立ち往生。
両脇を雪山で固められ車両1台分しか幅が無い道でどうすれ違うことができるだろうか？
デコボコの雪道の不意に妙な方向への車体の滑りにカウンターを当てるのは慣れるまではかなり難しい。
滑っていく方向に進み、滑っていく方向にハンドルを切り、まっすぐになったら、元の方向に戻る。
慣れてしまえば当たり前だが、路面状況や荷重配分などで、全く違う方法で切り抜けることも必要。
そんなプログラミングなんて面倒だし、プログラムのテストは更に面倒でとても無理。
多分、自動運転車の時代が来たら、市内の道は完全舗装、除雪も完璧にクリアしないといけないだろう。
真っ先に必要になるのは自動運転の除雪機だろうね。
それが出来ても周囲の交通整理は人間がやるしかないだろう。（大笑
しかも困惑した状況への対応もやはり人間がやるしかないだろう。（大笑
と云う訳で自動運転車の時代が来たら色々なクレームが地方行政にいっぱい来ることになるだろう。
そのクレームの対応もやはり人間がやるしかないだろう。（大笑
ま、不景気だからそれでも良いのかもしれない。
但し、 完全自動運転車が出来ない訳では無い。
だが、それは呆れるくらい使いこなした後に完成されるものだ。
そう、自動運転車の時代は自動運転車がありきたりになって初めてやってくる。
人間が運転する方が危ないくらいになったらね。
また、自分で自動車を運転するのが面倒とか、オーナーになりたいとは思わない。
そんな流れも必要だろう。
そして、それは着実に進行している。
その最大の難関が『タクシー業界』である。
金持ちだけが自動運転車に乗っている間はいいが、
先の状況からすれば、普及はレンタルカー会社から始まるだろう。

スマホで簡単に貸し出しできますとか何とか。

だが、普及しだしたら先の業界の大反対は避けられないだろう。
何と云っても「余剰人員を取り込み社会に貢献している業界」なのだから。
一方、自動車のオーナーが減れば、ガソリンスタンドもかなり影響が出るだろうし、更にセルフサービスのガソリンスタンドも自動運転車対応をしなければならない大変そうだ。

原発の発電を止めても危険性は無くならない。

だったら勿体ないから再稼働したら？

と云う話が進んでいる。
あの大地震で判ったことは「いつもニュースで流れていた小さい扱いで済んでいた小さな原発の事故」も「手が施しようが無い事態」になってしまうことだった。安全な状態だったら普通に解決できることも、「放射線濃度が高すぎ⇒人手を入れられない⇒何もできない」ということだった。
と云うのも、ロボットアームや全自動機械を使い遠隔操作で安全に作業できる区画は「常時人間が入ったら危ない場所」に限られているのだ。いつも安全な場所（と思っている）ところでそんな機材を使うのは「日頃扱っている普通の機械より扱いにくく、しかも高価と決まっている」ので一般的な観点からも「不経済であり効率的な作業ができる設備」とは云えないから「日頃扱っている普通の機械」を使っているハズだ。普通に考えればね。
そんなところまで汚染されれば容易に「想定外の事態」になってしまい「何もできない」状態に陥ってしまう。これまた普通に考えてもそうなる。
どうしようもなくなり、色々かき集めて、色々やっている訳だ。
だが、その結果は再稼働する原発に反映されているという話は無い。
一応、資料を見直し、大丈夫そうだからOKかな？という話だったり、地層を観れば活断層とか両極端な話ばかりだ。
では、なぜちゃんと議論なり調査なりが出来ないのだろうか？
１．自信が無い。
ちゃんと議論なり調査なりをし大多数が納得できるような議論や施工などを行っても再稼働後にまた「大事故」にならない保障にはならない。あくまでも大多数が納得しただけの話なのだから予想を裏切られることはありうる。しかしその時になって大方の人が「仕方が無い」と納得するとは全く思えない空気が満ちている。
２．原発を放置しても安全ではない。
人の噂も４５日。放置しておくと感心が薄れるが、安全管理意識も薄れていくのは当然の帰結。
３．だったら、とりあえず再稼働してみる方が安心。
またまた「大事故」になったら「不備がありました。」と深々と頭を下げる。
だけでいいじゃないか。
という流れだ。
部外者から見えるのはその程度だ。
それなりに善処した結果なのだろうが・・・
次のオリンピックまでにもう一回やっちまったらアウトだろうな。
忘れてるかもしれないけど、最近は大きな地震って多いんだよね。

Javaでのシステム開発は手の施しようが無い。
そう思うようになった。
詳しくは書かないけど、
今回も

完成品しか眼中にないシロモノだった。

思うに『物造り日本』が前世期の歴史になってしまい

完璧なものが出来ているなら単体のテストはサラっと動くハズ。

そこで手間取ると云うことは、製造（色々なファイル）段階の品質が悪い。

と思う

消費者指向のシステムエンジニア

が数多くいるのだろう。
少し違うかもしれないけど

コアゲーマーなシステムエンジニア

と云った方が意味が通じるかもしれない。
※プレイするけど製品は作らないという意味。
※ボクはライト系ゲーマーです。
※そう云う背景もあってゲーム開発には今も一切係わっていません。
こうなってくると、

今はソースを書いたら負けです！

としか言いようが無い。
ソフトウェア開発で「同じ内容の仕様書」を見て「考えながら同じソースを書く」ことはまず起きません。
なぜなら、同じものならファイルをコピーするだけでいくらでも量産できるからです。
ですから、ソフトウェア開発は試作品を作るのと同じです。
試作品ですから、その設計書を読み、パーツを作り、組み立て、塗装してみたら

クズだった！

となることがあっても当然です。
※普通、考えた時はイケルと思ったけどなぁ～な結果を量産品で出さないための試作品ですからね。
そして、特注品な訳ですから、その経験が生きるのはクズのリテイクを泣きながらやっている時だけです。他に応用が効く訳もありません。ただ用心深くなり人を見れば疑い出すだけです。
生産性を高めると云われているワークフレ－ムも判りやすく且つ品の良い言葉を選べば、
優秀な自己流プログラミングは他人に読める訳がない法則（※特にJavaScript）
に従っていて大抵はクズなのです。
すれっからしのStrutsの良さは、注意書きのストックがいっぱいあるということであり、扱いやすい訳ではありません。
※それでも新しい（怪しい）ワークフレームよりはマシかもしれません。
その最左翼と云える『jQueryの人気に便乗して開発中のNode.js』は今どうでしょうか？
いつになってもＶｅｒ．１.0が出ることがないような気もします。
なんとなく懐かしいザナドゥ・プロジェクトなんかも思い出しちゃいますね。※結局、自然消滅。
閑話休題。
で、その仕様書なりフレームワークなりの意味するところを一番理解した時がやってくるのはシステム開発終了。つまり最後まで試行錯誤が続くわけですね。
まとめると

システム開発

のはずが

• システムを構成するワークフレーム

 

• 開発手法

 

• 開発ツール

 

• 品質管理

 

等などの

 

『実証実験』

に成り下がってしまうのです。

• サーバーの余力があれば云いたい放題！

 

• サーバーの余力が無くなれば禁則事項の乱発！

 
という話はどこでも聞く話です。

貧層なホストを

 

なんとか使っていたＣＯＢＯＬ時代より

 

寒い時代になったものだ

 
 
と云ってよろしいのではないでしょうか。（濠泣
 
それらの顛末から得た教訓は、
Ａ　と　Ｂ　を組み合わせると、必ず両方の悪い点が露呈する。
例えば、すれっからしのStrutsは、XMLをジョブ制御に見立てて色々なリソースを実行する仕組みですが、デバッグは実機でよろしく！となっています。勿論Eclipseでデバッグできるような仕組みがある場合もありますが、無い時もあります。
では、実機が存在しないのにどうテストするの？と云えば、

完璧ならちょっとテストすればOKだよね？

の方針はここでも生きています。
それでもJavaのシステム開発に手を出す理由と云えば・・・
マシなところをまだ知らないだけでは？と思っているからです。
今のところ、ハズレだけですけどね。
いつかは・・・と思いたいですね。
ボクなりの解釈では、JavaScriptにJavaコンパイラを載せれば全て解決できると思っています。
そう、なんでもJavaで書けばいいのです。
ではEclipseは最高？と云えば、そうではありませんね。
無理やり作り上げてる感じでいっぱいです。
ワークスペースはよく壊れますし、最悪の場合は起動すらしないバージョンもあります。
なぜ、そうなってしまったのかは、沢山の人の手で努力と汗で作られたので、思い違いな箇所がやっぱりあるのでしょう。
Javaだけでもそんな感じですから、単純にJavaと何かを組み合わせると、もう途端にダメになります。
Javaソースだけで出来ていればEclipseがあればNot Found Classなどと指摘され実際に動かす前にソースが足りない事も事前に察知できますよね。
誰かがXMLやプロパティファイルからJavaコードをマッピングするアイデアをここに差し込むと、このアイデアが重大な欠陥を呼び起こします。
EclipseがXMLやプロパティファイルに書いた参照クラスが実在しなくてもNot Found Classと指摘してくれないのです。
たったそれだけのことですが、動かしてみないと判らないシロモノに劣化してしまうのです。
そして大抵は動かなくなった場所でプログラムが異常終了。その先どうなるのかは想像するしかありません。オマケに止まった場所から再開できることはまずありません（継続できそうもないので停止したんですから）ので、この先のバグは？１個？１００００個？そんなの判る訳が無いので、見通しなんてただの思い付き、ソコが非常に困ります。
EclipseにはJavaソースのimportsとClassPathを頼りに探索するプラグインが入っており、これが【問題】ビューに色々と悩みを書き込んでくれるのですが、そこにXMLやプロパティファイルで疑似的なクラスパスを実装しても探索不能になるのも当然です。
それでも、独自仕様のXMLに参照クラスを書いても、これを手がかりに探索するプラグインを作り同じ様にNot Found Classと【問題】ビューに書き込めば良いのですが、当然ながら何種類もの設定方法があったりすると、正しいのか間違っているのかTRUE/FALSEで判断するのも難しくその判断のため、独自の設定が別途に必要になったり、その設定ミスが原因でNot Found Classが出ない可能性もあり得ます。
消費者指向のシステムエンジニアは、

完璧なものが出来ているなら単体のテストはサラっと動くハズ。

そこで手間取ると云うことは、製造（色々なファイル）段階の品質が悪い。

どうやっても最後にはここにたどり着いてしまいます。
なぜなら、消費者指向エンジニアですから『無謀な納期、気まぐれな仕様の変更や追加、つまりサプライズハプニングが大好きで、その経過を見学することに生きがいヤリガイを感じているようです。』ですから、プラグイン開発にも『後出し』することになります。
そんな状況でも『どんな無理な要求にも対応し素晴らしいプラグイン』を作りあげたとしも、末端のプログラマーにリリースされるまでの長い期間の間は『いつも機能不全なプラグイン』でしかないのです。
そして、ついに

予算と時間をかけてプラグインを作る

と誰かが一大決心をした場合にはもっと状況が悪化します。
予算と時間をかければリリースは大幅に遅れるのも当然ですよね？
※試作品ですから
もしかすると開発終了後にリリースされるかもしれませんね？
と云う訳で、どんな些細なものでも、

いつも機能不全なプラグイン

しか手に入らない体制であり、
ひたすらソースを目視し直観に頼るしか手が無いのです。
よくよく考えると、

最初から打つ手がないんだね。

Eclipse？
あんなの飾りですよ！
偉い人には判らないのですよ！
でもEclipseが無かったら？
もっと酷いことになることは間違いありません！
JavaDocのバルーン・ヘルプも無く、XMLを何かに読み込ませたり、Javaソースをコンパイルするまで単純な文法エラーすら気が付かないでしょうからね。
そうそう最近は３Dプリンタがありますよね。
どうせ試作品同然のシステム開発なら、仕様書を読み込んでとりあえず３Dプリンタみたいにソースをでっちあげるツールはできないのでしょうか？
実際そういうのもあるのですが、大枠のプロジェクトや大まかなクラスを決め打ちで出すものやBeanに特化したものなど色々です。しかしいずれも、やはり作れない部分があります。残りの部分（多いか少ないかは色々）は、ツールの都合に合わせて、Javaコードや設定ファイルをあちこち張り合わることになります。どう云う訳か色々なツールを組み合わせて一式でっちあげるという流れになることがありません。
そうなると、結局、ツールに合わせて、色々試行錯誤し、考えたりする手間が増えるだけなんです。
なぜそうなってしまうのか？無能なのでしょうか？
ボクは、仕事が無くなるのが嫌なので、ちゃんとしたツールは「使わない」「作らない」「売らない」の3原則を掲げて厳守しているのだろうと思っています。（大笑