がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

伸びない人の特徴＆伸びるための勉強方法草案

親方

割とあちこちで書かれてる気はするんだけど、ざっくりまとめてみる。


1. クォリティを浅い部分でしか認識していない
「認識しやすい」クォリティ部分でだめなケースはまぁ論外として(正常系が動いてない：露骨にバグがある)。
「セキュリティ的に問題がある」「メンテナンス性が悪い」など、目に見えにくい部分でのクォリティで、割と露骨に差がでます。
具体的には「今問題が出ていないんだからいいじゃないですか」。ハインリッヒの法則とかヒヤリハットとかって単語を、二度と忘れられなくなるまで調べつくしてください。
あなたが見つけ出し潰し尽くすべきは「１件の重大な事故」ではありません。「300件の(危うく大惨事になる)傷害のない災害」なんです。
まずはその300件を「認識することが出来る」程度のスキルと知識と経験をつみましょう。


2. 速度を意識していない
同一機能、同一クォリティである以上「早く組みあがるほうがよりよい」のはごく当たり前な事です。
あなたが「まごうことなく世界最速で設計＆コーディング＆テストが出来る」という確証がないかぎり、あるいはあってもなお(百尺竿頭進一歩)、「今よりももっと早くするためには？」という問いを、常に自らに投げかけてください。
最低でも「一般的なエンジニアの10倍」程度の速度は、努力すりゃ出ますから。


3. 無知であることを認識していない
あなたがいまやっている解法よりも「より素晴らしい解法」が存在する可能性が、当然ながらあります。
「森羅万象のすべてを知り尽くした」のでない限り、新しく学ぶべきことなど、比喩でもなんでもなく「山のように」あるはずです。
学習は、それをやめたときから「退化」しはじめるんです。


総じて「今のままでいい」って発言が出た瞬間に「ダメだな」って思うです。なにがいいのかまったく理解ができない。
別に「毎日進歩する」必要はないので(毎日だと、マジで疲弊します(苦笑) )。毎月程度の頻度で、ゆっくりと歩んでいきましょう。


で、お勧めの学習方法。
・月に１冊以上：慣れたら週に１冊以上、技術本を読む
・月に１冊以上：慣れたら週に１冊以上、技術以外の本を読む
・作る。とにかく作る。手を動かしてコードを書く。週に１度〜月に１度以上は何かを組み上げましょう。小さいものでもよいので。
・３ヶ月に一度、自問自答。「この３ヶ月で新しく身に着けた知識/スキルは、なに？」
・６ヶ月〜１年に一度、自問自答。「自分が今持っている知識は、やり方は、本当に最適解？ よりよいものがあるんじゃない？ 間違ってるんじゃない？」


これを年単位でやってれば、何もやってない人とは多分「かなりの差」が付くのではなかろうか、と思います。

「出来上がっているチーム」という幻想

親方 memo

http://d.hatena.ne.jp/gallu/20110327/p3
の続き。マネジメント考察にむけての準備。


んと…多分「進むべき前を見据えてまっすぐに進むマネージャ」と「足元を見据えてじっくりと育てるマネージャ」っていう極があって。
…共存不可能ではないんだけど、マネージャの能力的に「キャパシティオーバー」なケースが少なからずあって。
その場合、一般的に「経営層付近に受けのよい、まっすぐ進むマネージャ」系が増える。


で…


その場合「スキル的にも人材配置的にもコミュニケーション的にも雰囲気的にも」仕上がっているチーム、が前提になる。なんでかってぇと「育てている暇も余力もない」のであれば、当然のごとく「成熟した個体＋完成したチーム」がないと困るから。
で…現実問題の結果として「スキルが足りない」「なんか配置した場所で能力を発揮してくれない(よく「チームの和を乱す」とか表現される)」「必要な情報をちゃんと報告してくれない(「報告しにくい場」が形成されていることについては言及されない)」「なんか雰囲気が悪かったりやる気がなかったりモチベーションが低かったりする」という理由でメンバーを入れ替えだして。
ただ、その状況で「よいチームが出来上がる」まで入れ替えを続けるのは、果たしてどうなんだろう？ とは思う。


チームもまたひとつの「システム(系)」である以上、定期的なメンテナンスが不可欠なんだ。PDCAとか言ってもよいよ？


うん、少しまとまってきた。

ふと気づいた言葉尻

親方 一言

ある事象に対する可否を。


「＊＊は出来る」「＊＊は出来ない」って話をする人と。
「＊＊はやる」「＊＊はやらない」って話をする人と。
二種類いることに気づいた。


んと…「神と本音は細部に宿る」ので、噛み砕いて。


loop 出来パターン
「＊＊は出来ますね。やりましょう。」「＊＊、やっぱり出来なかった。出来ると思ったんだけどなぁ」
pool


loop やパターン
「＊＊をやろう。」「＊＊、出来なかったなぁ orz なんで出来なかったんだろう？ 次はやるぞ！！」
pool


やっぱり見え隠れしている、成長とか克服とかトレーニングとか教育とか、そーゆー、一連の「なにか」。

設計の学習方法草案

親方 memo

ふとこないだ気づいたのですが。
んと…


今までに、大小あわせて、多分600〜700以上、くらいのシステムの設計をしてるです。設計してるってことは「DBどうやって切って大まかにこんなコード書いて」くらいまでは妄想してるです。
100弱(多分60〜80)くらいは、実際に実装をしているです。つまり「設計では見えなかった、実装タイミングで気づくミステイク」を、それくらい見ているです。


多分、この量があるから、ある程度までの要望に対しては「あぁあのときのこれが使えるなぁ」という、引き出しの多さにつながっているような気がするです。


んで。


まぁ10数年くらいかけて「毎週１案件以上、お客様からヒアリングしてお見積もり」し続けていればそれくらいの経験はつめるわけなのですが(理論的には、週１で10年やって520経験ほど)。
そこまでヒアリングし続けるのも、若干しんどい部分や時間的に厳しい部分などもあろうかと思うので。


…ドリルにしてみたらどうだろう？ と。
おいちゃん的にも、よい備忘録になるし。


っちゅわけで、うまいこと時間を捻出して「設計ドリル」作ってみようかなぁ、と思ってるです。
興味がある方いらっさいましたら「はよ作れや」「なにちんたらしてんねん」などの生暖かいご声援をいただければと思いますｗ

ちょっと気になるので突っ込んでみる

その他技術

元ネタ
典型的PHPerの13の悪癖
http://anlyznews.blogspot.com/2011/03/phper13.html


これの元ネタの「典型的PHPerの13の悪癖 http://anond.hatelabo.jp/20110329150439 」のほうも見ていたんだけど…ちょっと気になったので、突っ込み。
いつもながら当然ながら、以下、すべて「私見」です。


序文。
…おいちゃんは、はたしてPHPerなのだらうか？
仮説１：Yes
最近扱っている(っつか書いている)言語としては、PHPが一番多い。したがってこの瞬間という時間軸において、PHPerであると考えられる。
仮説２：No
PHPerとは「PHP言語のみを扱うプログラマ」のことである(要出典)。C、C++、Perl、Java、C#、VB、JavaScript、ActionScript、Objective-C、COBOL については少なくとも業務経験があり、それ以外にもZ80aアセンブラ、N88-BASIC、ファミリーベーシック、ruby、Python、Smalltalk、LISP、Haskell、なでしこ、Brainfackなどについて、多少なり経験があるようなてめーが「単一言語を扱う」とかってピュアな世界に踏み込んでくるんぢゃねぇ。


…なんていうどうでもいい考察で頭をならしつつ。start。

1. パスワード認証sshでサーバーにログインし、vimやemacsで開発をする。
PHPerは、生産性が低く、セキュリティ的に問題のある開発環境を愛用しているケースが多々ある。セキュリティ向上の為にはsshは公開鍵認証で使うべきだし、生産性向上のためには、一般的にはローカルに開発環境を用意して、Eclipse/PDT等の統合開発環境を使うべきであろう。

そもそもとして「IDEって本当に生産性が高いの？」って部分で色々懸念はあるのだけど、「開発環境でセキュリティ的に問題がある」って、なんだろう？
sshの話であるのなら、それは「接続環境」って言わない？ 「パスワード認証 ダメ！ ゼッタイ！！」は、特に違和感もなく賛同するけど。
IDEは…「IDEを使わない開発で相応の腕を磨いたあとで」使うならともかく。見ている限り「いきなりIDEから始める」と、九分九厘「IDEに使われ、振り回されてる」からなぁ。おいちゃんはわりと反対派。
生産性の向上云々いいますが。おいちゃんの開発は、概ね
・PuTTYで公開鍵認証
・SVNはコマンドライン
・vi ＋ コマンドライン
または
・WinSPで公開鍵認証
・SVNは亀さん
・てけとうなテキストエディタ(最近はTeraPadかなぁ。Windows環境で、いいvi系エディタが見つけられてなくて orz)
で、大体５〜10倍くらいの生産性をはじき出してますがなにか？
「IDEを使えば生産性が向上するの！！」なんていう銀の弾丸信仰やめて、「本当にボトルネックになってる場所」を一度、きちんと考察してみたらどないでしょ？

2. SVNなどのバージョン管理システムで、使い方が分からないのでブランチを切った事が無い。
開発ツールの学習に無頓着なPHPerは少なくない。例えば、バージョン管理システムを単なるファイル共有・履歴閲覧システムとして利用しているケースがある。リリースをしてもブランチを切らないプロジェクトは多々見かけるし、驚くべきことにソースコードを巻き戻すときに、履歴を閲覧してプログラマがコードを修正するケースさえある。

ブランチを「なぜ切るのか」をまずちゃんと明確にしてから、じゃないかなぁ？
実際問題、管理とかか引継ぎとかのことを考えると「わざわざ切るメリットも少ないねぇ」ってケースも少なくないので。

3. ウェブしか開発したことが無いのに、ソフトウェア技術全般を語る。
世の中には多種多様なソフトウェアあるので、PHPの常識が通用するとは限らないが、PHPerはPHPの常識に固執するときがある。デスクトップやケータイのアプリケーション、デバイスドライバ、OSやミドルウェアの開発は、ウェブ・アプリケーションの開発とは大きく異なる面もある。また、 Javaや.NETによるウェブ開発は、PHPによるそれとは大きく様相が異なる。

「PHPerはPHPの常識に固執するときがある」は、どの「単一言語er」でも一緒。
で、ほぼまったく同様のことがJavaerにも言えるのだが、彼らにこのことを話すると、大抵、烈火のごとく怒る(いやまぁその辺PHPerも似てるのだけど…PHPerは虐待されることになれてるからｗ)。
んで、真面目な話。例えば「Linuxで動かすdaemon系のブツ」を作る時は、PHPはもってのほかとして、Jaavだって使いたいとは1ミクロンたりとも思わないしなぁ、正直。
「きっちり」いきたいんならC、「ちょっとインテリジェンスなところがあるから効率は多少犠牲」にするならC++、が、おいちゃん的には選択肢の範囲内、かなぁ。

4. RDBは難しいからと言って、簡単なSQLしか、もしくは簡単なSQLも書かない。
RDBは、原則として正規形のテーブル設計で利用するものだ。RDBは、データの寿命がアプリケーションの寿命より長い事が前提となっており（DOA）、アプリケーションにあわせてテーブル設計をしてはいけない。ただし、速度的に問題が出るケースは、結合回数を減らすために正規形を崩すときはある。

そもそもとして「RDB語るなら、ちゃんと"リレーショナルデータベース、という数学(集合論)"を学んでからどうぞ」って思うんですがどうでしょ？
厳密に言うなら「そもそも、RDBに"テーブル"なんてないよ？ あるのはリレーション(関係)だよ？」
RDBは概論としてはさほど難しくないと思うし、そもそも「RDBが難しいから簡単なSQLしか書かない」って、それ、日本語として成り立ってない。

5. PHPなどのスクリプト言語しか知らないのに、プログラミング言語の優劣を語る。
PHPは手続き型、もしくはオブジェクト指向型に分類される言語で、世の中にはLispやErlangのような関数型言語も存在する。Perl、 PHP、Python、Rubyを比較しても、オブジェクトが使えるスクリプト言語の範囲は出ないので、狭い範囲の比較にしかならない。

そもそも「何をもって優れてるのか」っていう判断基準が意味不明だしねぇ。

6. PHPの遅さを知らないのに「最近のマシンは速いからプログラミング言語に速度は求められていない」と言い切る。
PHPはビルトインAPIの速度は高速だが、PHPコード自体の実行速度は速くない。他のスクリプト言語と比較しても遅い方だ（Computer Language Benchmarks Game）。CやC++、Javaと比較すると処理によっては100倍以上も遅くなるので、最近の計算機を用いていてもPHPはパフォーマンスに注意しないといけない時がある。

まず「速度が求められていない」は、状況によってはtrueなので、そのあたりは真摯に向かい合うことが必要。
次に、速度以上にもうちょっとみんな「メモリ」を気にしようよ orz
サーバ管理してて、マジできついから orz

7. クソ重いPHPをLightweight Languageと言ってしまう。
LLと言ってPerlやRuby、Python使いも友達だと主張しているように感じるが、LLという形容は不適切だ。PHPの実行速度は遅く、メモリ消費量も少なく無いので、手軽（easygoing）であっても軽量（lightweight）であることはない。LLと言う単語を使うたびに、軽薄な印象を周囲のソフトウェア・エンジニアに与えるかも知れないので注意が必要だ。

そもそもとして、LLの「Lightweight」って「マシンリソースに対する重量」ではなくて「開発者の開発負荷に対する重量」だったのでは？
http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E
> 取り回しに優れ、コードの作成や修正が容易と見なされるプログラミング言語のことを指す
まぁ正直、あんまり興味ないしど〜でもいいっちゃぁど〜でもいいのだが。
おいちゃん的言語きり分けとしては「キッシュ系言語」だしｗ
> LLと言う単語を使うたびに、軽薄な印象を周囲のソフトウェア・エンジニアに与えるかも知れないので
…んな阿呆なエンジニア、いるのだろうか？ いや書いてあるからにはいるんだろうけど……… orz

8. クソ重いPHPで、デザパタとか言い出す。
PHPコードの実行速度は遅いので、その中でも他のプログラミング言語と比較して遅いメソッド呼び出しが増えるGoFデザインパターンは、本質的にはPHPに向かない。一つのソースコードの整理手段としてはあり得るが、無闇にデザインパターンを推奨できるプログラミング言語ではない。

なんていうか…見解が違いすぎて(苦笑
そんなに実行速度を重要視するなら「全部CかC++にすればいいのに(でもいやまぁ実際そうなると、今よりは楽園だなぁとは真剣に思う B-p)」。
そもそも、OOPにする時点である程度「実行速度とメモリなどの、ようはマシンリソースを犠牲にしてでもほしい何かがある」んでしょ？

9. クソ重いPHPで、クソ重いフレームワーク（CakePHP、symfony、Zend Framework）にこだわる。
PHPコードの実行速度は遅いので、メソッド呼び出しが増え、実行コード量が肥大するフレームワークは、本質的にはPHPには向かない。ライブラリがセットになっているため生産性が向上し、ソースコードの整理にもなるためフレームワークの採用が一般化しているが、オーバーヘッドも認識しておくべきであろう。

８番と一緒。

10. クソ重いconcrete 5やWordPress、MovableTypeで何でも書き出す、ショッピングサイトも作り出す。
PHPコードの実行速度は遅いので、PHPで書かれたミドルウェアは速度的に問題が出やすい。OpenPNEのパフォーマンスに苦しんだ人は少なく無いはずだ。しかし、なぜかPHPで書かれたミドルウェアは増加の一途であり、そしてそれらを拡張するコードも氾濫している。

あぁ…まぁ「ひどいの」多いよねぇ。とはいえ、別段PHPに限ったことではなくて。例えばJavaで書かれたいくつかのブツで、同じくらい「重くて遅い」のに、散々いやな思いはさせられましたが(苦笑
VBは………それ以前な気もする(苦笑

11. 仕様が曖昧で急激に変化するPHPで、テストファーストとか言い出す。
TDDは有効な開発手法だし、PHPでも用いられている。しかし、PHP自体の仕様が曖昧な面もあり、PHPのバージョンアップで後方互換性が失われるケースが多々ある。PHPは古くからあるビルトイン関数の挙動・仕様が変化することもあり、テスト・ケースを充実させても、将来のバージョンのPHPでは挙動を保証できない。

「PHP自体の仕様が曖昧」については…落ち着いてきた部分もあるけど、でも、まだねぇ(苦笑)。まぁ、厳密には「言語」ではなくて「提供されているライブラリ」だと思うんだけど…そういう意味では、ひとつ疑問。別のほかの言語だってそれなりに「仕様変更」はあるんだけど、実際のところ「言語そのものの仕様変更」の量ってどれくらい違うんだろ？
あと。TDDは「将来のバージョンのPHPでは挙動を保証できない」からこそむしろ重要なんじゃないか、って思う。新幹線だったのが飛行機に「仕様変更」されたとしても、結果的に「大阪に到着できる」んなら、対象クラスは「問題なく動く」っていえるんだし。


12. 勉強会でリファレンスに書いてあるような、分かりきった事を発表する。もしくは理解できていない事、誤った内容を発表する。
特にPHPerに限った話ではないが、試行錯誤でアプリケーションが書けるPHP育ちのプログラマは、何か誤解したまま突っ走しる傾向はあるような気はする。若さなのだと思うが、彼らのPCが赤く無いので大目に見るのは難しい。

普通に面白い話"も"聞けると思う。っつか、上述を言い切るなら、相応の期間の調査とその結果が必要じゃない？
> 試行錯誤でアプリケーションが書けるPHP育ちのプログラマは、何か誤解したまま突っ走しる傾向はあるような気はする
これも別にPHPによらない。他の言語でもまったく一緒だと思う。

13. ブログで自らの無知をさらけ出す。
PHPの事が書いてある分にはそうではないが、独善的で主観的なPHPerのブログは多々あるように感じられる。典型例として、自分が使うツールの重要性や利便性を強調し、必須ツールとしているケースが思い浮かぶが、そういう場合に同種ツールとの比較検証が詳細にされる事はほとんど無い。

これは…Javaerのほうが多く見えるんだけど気のせい？


なんだろ…うん全体的にみて、なんとなく「違和感と嫌悪感」を、山盛りで感じる。
多分、その根幹の一つは、ここ。

叩き上げのPHPプログラマで、PHPを愛してやまない一方で、他のプログラミング言語や開発ツールには興味関心が無い人々が、上にあげられた人物像にあてはまる気がする。道具に愛着を持つ事は良いことだが、視野が狭くなると周囲には煙たがられるので注意が必要だ。

いやべつに「おいちゃんがPHPを愛しているか」ってのはおいといて。
おいちゃんの場合は少なくとも
・他のプログラミング言語を、業務で使う程度のレベルまではやった上で
いくつかの言語については切り捨てているし(具体的にはVBとC#とJava)、
・開発ツールをある程度つかって、検証した上で
使わないっていうかむしろ使えないなぁ、って思ってる(Eclipseとか)。いや「好みにカスタマイズすると」なんとかはなるんだけど、そこまでの労力をはらうメリットが見出せない(苦笑)。
あぁちなみにEclipseを「他人が使う分」には「いいんじゃない？」って思ってる。おいちゃんの肌と思想に合わないだけだから。


…なんだけど、まぁ典型的にはJava屋さんの若いあたりに上述のような話をすると大抵、面白いくらい否定的な反応をしてくれる。
ちなみに「古くからのJava屋さん」で一人「…そうなんだよねぇ昔はメモ帳でもいけるような言語だったのにねぇ」と、しみじみ嘆いてた人がいたなぁ、ってのは余談。


んと…つまり。
「無知を改めましょう」という知識の啓蒙に見えてその実「自分の見解を相手に押し付けようとする」雰囲気が見て取れるのが、あるいは少なくとも「自分が是と思えないものはすべて非なんだ」っていう感覚の押し付けが見て取れるのが、イヤなんだと思う。


という感想。


あんど余談。
………もしかして、これが「竹の花が咲くと襲ってくる」 と言い伝えられている、PHP"dis"er、なのかしらん？ｗ

寿命と年齢とかに果敢に挑んでみる

親方

元ネタ
（翻訳）開発者の寿命について思うことCommentsAdd Star
http://d.hatena.ne.jp/ymotongpoo/20110307/1299499797


なんか興味深かったので。えぇ毎度おなじみな理由ですともさｗ

40歳以上の開発者をどれだけ知ってますか？かなり多くの人が0人と答えるでしょう。では、40歳以上の開発者を1人以上知っていると答えた方にさらに質問。その内何人が素晴らしい開発者ですか？

とりあえずおいちゃんは「アラウンドの要らない」フォーティーである。つまり条件を満たしている(でも20進数なら20代だぞ？ｗ)
「素晴らしい開発者」かどうかは、わからない。そうありたいとは思ってるんだけどな〜。どうなんだろ？
「素晴らしくない」だと会話がここで終了してしまうので、仮定法として「素晴らしいとあるいはいえるのかもしれない」程度に、まろやかに仮定してみるｗ

多くの開発者が数年経つとマネージャになってしまうからです。

ん…基本「全力で回避」ｗ
マネジメントするときは「全力の半分でマネジメント、残り半分で現場作業」を死守します。コードを一ヶ月書かないと禁断症状が出ることが、実験の結果明らかになったのでｗ
とりあえず…こないだ「８人の開発者を抱えた状態で、彼らの設計レビューとソースコードレビューと質問を捌きつつ、他のメンバーの２倍程度の生産性」は確保できていたので、とりあえず「処理を捌ける」程度には、無能なのではないのではなかろうか、と…多分。
もっとも、それくらいは「ちょっと訓練すれば誰にでもできる」ような気もするが。

2つ目の理由として、長い期間開発をしてきた人の多くが知るべき事はもうほとんど知っていると思いはじめて、新しい問題解決方法を学ばなくなったり、開発者コミュニティで他の人が学んでいることを追いかけなくなったりするからです。

あぁそんな腰掛は「ありえない」なぁ(苦笑
どっちかっていうと、学べば学ぶほど「到達地点が遠くに逃げていく」んですが orz

「なんでうまくいってる方法を変える必要があるんだ？」

については…こちらをどんぞ、って感じ。 http://d.hatena.ne.jp/gallu/20100122/p2

一方で実装自体は古くさかったり無駄が多かったりします。この点において、開発者の価値は減り始めて、（どんな理由でも）スキルが時代に追いつけなくなるまで価値は下がりつづけます。

ほのかに微妙。
「古いからよいわけでも悪いわけでも」ない。だから、もし「古臭い」というだけで批判の対象になるのであれば、それはおかしいと思う。
無駄だって場合は問答無用。
ちなみに「新しい」のはとりあえず「危ない」。検証が落ち着いていない可能性があるから。
まぁ技術者たるもの、一定の確率と割合で「人柱になる」のは義務だよね？ｗ
# まぁ「毎度」はいやだから、ある程度「人が使うまで待つ」ことも増えるんだけどさ(苦笑

自分はバカと意識し続ける

っつか。とりあえず「無知ではない」というのであれば、最低限「ITの業界の全ジャンルでTop、ないし少なくとも明らかにTopクラスである」程度は必要条件だと思う(十分条件ではないので念のため)。
ついでにいうと「自力で対象技術を編み出した」と「対象技術を学んで使いこなしている」と「対象技術を使っている」と「対象技術に使われ、ふりまわされている」との間には、それぞれ、分厚い壁があることを忘れずに B-p
んで。
実際問題として、ストレスにならない程度に「自分は低スキルだ」って思ってるほうが、多分伸びはいいんじゃないかなぁ、と。

自分が知っていること考えていることを常に問い続ける

そもそも「本当に知っているのかどうか」すら怪しいんだし B-p


…で、寿命の話は？ｗ


なさそうなので…おいちゃんが自力ででっち上げてみる。
んと………


プログラミングは「年をとった」には出来ない。
この場合の「年をとった」とは、肉体や戸籍上のお話ではなく、精神の部分。つまり「学習意欲が硬直し、腰掛け、己に満足してしまった」ら、その時点で終わり。
なお、成熟/円熟している人の場合、「年をとった」ではなくて「年を重ねた」といいましょう (C)ケイちゃんｗ


なので。「腰掛けて頭が硬直した」ら、そこが寿命。
こんなんでどでしょ？

勘弁してくれ orz

親方

元ネタ
原発がどんなものか知ってほしい（全）
http://www.iam-t.jp/HIRAI/pageall.html
＞＞
29日追記
コメントでいただいたのですが、上記は怪文書の類だそうです。


妖精現実
http://www.faireal.net/dat/d2/d20903.xml
「妖精現実-原発がどんなものか知ってほしい」
＜＜
すみません元ネタとちょっと違う観点から見ております(苦笑

その根本は、余りにも机上の設計ばかりに重点を置いていて、現場の施工、管理を怠ったためです。それが直接の原因ではなくても、このような事故が起きてしまうのです。

原発でも、原子炉の中に針金が入っていたり、配管の中に道具や工具を入れたまま配管をつないでしまったり、いわゆる人が間違える事故、ヒューマンエラーがあまりにも多すぎます。それは現場にブロの職人が少なく、いくら設計が立派でも、設計通りには造られていないからです。机上の設計の議論は、最高の技量を持った職人が施工することが絶対条件です。しかし、原発を造る人がどんな技量を持った人であるのか、現場がどうなっているのかという議論は１度もされたことがありません。

それが十年くらい前から、現場に職人がいなくなりました。全くの素人を経験不問という形で募集しています。素人の人は事故の怖さを知らない、なにが不正工事やら手抜きかも、全く知らないで作業しています。

現場に職人が少なくなってから、素人でも造れるように、工事がマニュアル化されるようになりました。マニュアル化というのは図面を見て作るのではなく、工場である程度組み立てた物を持ってきて、現場で１番と１番、２番と２番というように、ただ積木を積み重ねるようにして合わせていくんです。そうすると、今、自分が何をしているのか、どれほど重要なことをしているのか、全く分からないままに造っていくことになるのです。こういうことも、事故や故障がひんぱんに起こるようになった原因のひとつです。

原発を造る職人がいなくなっても、検査をきっちりやればいいという人がいます。しかし、その検査体制が問題なのです。出来上がったものを見るのが日本の検査ですから、それではダメなのです。検査は施工の過程を見ることが重要なのです。

検査官が溶接なら溶接を、「そうではない。よく見ていなさい。このようにするんだ」と自分でやって見せる技量がないと本当の検査にはなりません。そういう技量の無い検査官にまともな検査が出来るわけがないのです。メーカーや施主の説明を聞き、書類さえ整っていれば合格とする、これが今の官庁検査の実態です。

私自身が二〇年近く、現場の責任者として、働く人にオウムの麻原以上のマインド・コントロール、「洗脳教育」をやって来ました。何人殺したかわかりません。みなさんから現場で働く人は不安に思っていないのかとよく聞かれますが、放射能の危険や被曝のことは一切知らされていませんから、不安だとは大半の人は思っていません。体の具合が悪くなっても、それが原発のせいだとは全然考えもしないのです。作業者全員が毎日被曝をする。それをいかに本人や外部に知られないように処理するかが責任者の仕事です。本人や外部に被曝の問題が漏れるようでは、現場責任者は失格なのです。これが原発の現場です。


えと…えぇもちろん「原子力発電所の酷い状況」としても大切な文章だと思うのですが。
ただ、それと同じくらいに…なぜか既視感ががががが orz