アカウント名:
パスワード:
これ付け加えてくれませんかね･･･
ですよねぇ…。つまりは「ゴール」が見えてない。だから要求もあっちへふらふら、こっちへふらふらして、挙げ句の果てに使えない（ゴールにたどり着けてない）システムができあがり、顧客には不満がたまる。買い手側（顧客）がシステムを理解していない・要求をまとめられないのならば、売り手側（システム屋、PM）が上手にゴールを設定してあげられれば良いんでしょうけど、それもできない下手くそなシステム屋やPMがいっぱいいるのも事実。
顧客が「今のままで満足です」と言うとか言わないとかあるけど、そこで「あぁ、これだったら欲しいな」「お、その切り口なら改善できるかも」「目の付け所が○○だねぇ」と顧客が言うようなものを見つけるのが営業さんでしょ。システム屋やPMだって、ゴールさえ明確になってたら、顧客のふらつく要求を「それは本題ではないですね」と判断する（場合によっては切り捨てる）基準ができるしね。それを、クラウドとか○×経営とか本質とは別のキャッチーだけど訳のわからないことで煙に巻いて顧客をだますようなことをするから、結局ゴール不明のプロジェクトが見切り発車をし、営業もSEもPMも、そして顧客までもが全員しなくて良い苦労をした挙げ句に不満をためる羽目になるわけで。
MS-DOSベースの売り上げ管理システムが諸々の事情でWindowsベースになるときこれまでのままでいい。つーか、これまでのままがいい、という話を営業の人に伝えたところ、余計なもんばかり付け加えながら残して欲しい部分をばっさり削ったもんが出来てきたことがあるなあ。営業とPGが別とかWindowsベースかつDelphiを使わないとなにもできないPGばかりだった、とか、のちのちの会話でそういう裏は見えてきたけど、そのシステムを使う現場はそんな「事情」なんて知ったこっちゃないからね。避難轟々だった。
苦労してつくりあげたであろうシステムが、日々「ばっかじゃねーのこれ！」と毒づかれながら使われている、という事実にもうちょっと敏感になって欲しいもんだよ。営業から見ればPGのせい。PGにいわせりゃ営業のせい。顧客がどんなに嫌でもその会社を選ぶのは縁故のせい。システム会社の運営者たちは、新技術を追うだのビジネスチャンスだのイノベーション(笑)だの言う前にこのどうしようもない三竦み状態をなんとかしてくれい。
> 営業から見ればPGのせい。PGにいわせりゃ営業のせい。> 顧客がどんなに嫌でもその会社を選ぶのは縁故のせい。> システム会社の運営者たちは、新技術を追うだのビジネスチャンスだのイノベーション(笑)だの言う前に> このどうしようもない三竦み状態をなんとかしてくれい。
し､システム会社の運営者に縁故を何とかされてしまうのですか･･･？
だから、本来なら「業務とはこうあるべき」という経営者の判断があって、それにあわせて業務及びシステムが作られるべきなんだけど、変に現場主義で帳尻あわせするからおかしな事になる。現実的に早期(昭和40年代とか)にオンラインシステムを導入してスピードのあがった会社は多くある。業務システム設計って、もっと大胆にするべきなのに、中途半端が一番悪い。
逆じゃね？業務の内容がすんなりテンプレ化できるなら定番業務アプリ一個開発した会社だけに金が集まる。中小なんてクライアントの要望にきめ細かく対応した開発をしている(と世間では思われている)から生き残れているわけで。
それよりシステム会社の技術力に、顧客が合わせなきゃならないような現状の方が問題。ていうより、道具の使い方を知らない人がつくる道具で世の中回ってしまっていることか。
提案出来ないから要求丸呑みなんじゃんw
必要のない物を必要だと錯覚させるところからスタートしてるから破綻する場合が多いのでは・・・
いや、マジで
別にITプロジェクトに特化した話ではなく、どのようなプロジェクトの開始前にも必要な事項だと思います。我が国では、一般に認識されていないようですが…。
いろいろな所から得た情報をまとめると、こんな感じになるかと。
・欧米のマスターでは、プロジェクト開始前に、 どのような結果を出すか、 上手くいかなかったらどうするか 等、徹底的に計画を吟味する。そのためプロジェクト開始は遅れる。・欧米企業のCEOはマスター・ドクター卒は 当たり前。日本は大卒が多い。・日本のマスターは、プロジェクトの教育を全然していない。日本のプロジェクトは、なんか面白い結果が出そうだ、といった雰囲気でプロジェクトを開始する。
実例として、DNA解析が話題となったとき、日本はDNA関連プロジェクトをすぐに立ち上げて進めたが、結局何も成し遂げていない（このあたり、当の研究者達は最初から分かっていた様だが）。逆にアメリカは、どのような結果を出すべきかを検討し、プロジェクト開始は日本より2年?程度遅れたが、癌関連で成果を出し始めている、と言う話を聞きました。
マスターの教育が出来ていないため、トップダウンのプロジェクトが日本では上手くいって無いように思えます。（しかし、プロジェクト型を定着させるには、人材の流動性やプロジェクトから外れた弱者支援の仕組みも合わせて必要であり、文化的に現在の日本はプロジェクト型は向かないと考えています。）
日本だけ？ も付け加えたいよね。projects failure で検索する方はいっぱいいるみたい。
御客様が何が欲しいのか？何を依頼したのか？それすら解っていないことが多すぎる。
お客様自身も実は漠然としか分かってない場合も往々にしてありますので。それを具体的な形に引き出してあげるのがプロマネや営業のお仕事なのでしょうけどね。
プロマネの理解 → 営業の表現 → …っていうスライドが一時はやりましたね。
アプリが動き始めて考え始める方々もおられます。
×依然に○以前に
担当者にもよるが、そういう客こそ扱いやすいとも言える。
作るほうが作りやすいようなものを提示して、これですよねって押し付けちゃえばいい。
難しいのは、何を作って欲しいかわかっているのに伝えきれない人、理解しきれない人の場合でしょう。
そういう人の場合は、下手な鉄砲方式でいっぱい提示する。その中でマッチしたものを選んでもらう。
乱射するのは最初だけで、作り出したらもう滅多に変えない。
そーゆー人は選んで運用した「後」に文句言うんだよ
というかですね、1の「何が欲しいのか」が定まらないと2での「何が追加なのか」も定まらないんですけどね。もっとも、顧客自身が考えた「ソリューション」なんて当てにならないが、顧客に要望を聞くと要望ではなくその「当てにならないソリューション」を答えることがほとんどだという性質がある。なので顧客の「要望」を鵜呑みにしちゃダメなのだよな。TOCと同様、相手の言い分ではなく相手のおかれた条件を基に考えなきゃならん。そうでないと完璧に要望通りでも使えないブツや、今までと何の違いもない何のメリットもないブツができあがったりするわけで。
漠然と上が無能って愚痴る下と、下が無能って愚痴る上とがせめぎ合っている様子が見て取れます。とりあえず案件とってきた営業が、距離おいてせせら笑う姿も見える・・・
-1.それより優先すべきプロジェクトは存在しないか？
-2.赤字になるのでやりません。
-3. それが失敗した時にキャリアが傷つかないか
-4. 赤でもコネなんで断れません
1->聞かれたことはない、それはこちらで考える質のものでもない。2->OK(決められた資源の元に立てた仕様を守れるなら)3->OK(最初に認められた仕様を変更され無ければ)4->失敗対策用予備プランは無い(複数プランの組み合わせで凌ぐ)5->心当たりが多すぎる#コソコソと匿名の臆病者として投稿
１．そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。何を作るかは、開始した後に決めます。「ぽーとふぉりお」？なにそれ美味しいの？
２．プロジェクトを無事完了するだけの資源が本当にあるか。規模も決まってないので分かりません。（ただし納期と予算だけは決まっています。）
３．定められた期限は本当に達成可能か。規模も決まってないので以下同文。
４．失敗しそうな場合、あるいは他の問題が起こった場合の予備計画はどうなっているか。いざとなれば人を突っ込みます。そりゃもう千人でも二千人でも突っ込みます。
５．プロジェクトに関与する必要のある利害関係者は誰か。そういう社内調整なんかの些事は、全部外注(SIer)に任せてます。それが奴らの仕事なんだから。
＃お、オレの話じゃないぞ。あくまで一般論だからねっ
話持ってこられた段階で平気で納期が過去だったりするよね…
1.～5.は「マネージャが常時把握しておくべき当然の情報」じゃないですかね。はじめる前だけじゃなくて。実際は当初の目標にズルズルと仕様追加していって 3. と 4. が徐々に破綻するパターンばかりでしょう。
6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。
>6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。
進捗管理を台無しにするだけならいいけどね。最初の仕様を根底から覆す「崩壊の一声」の存在というのもあります。#さながら「バ○ス」
どこが「開始」なんでしょうか？
> 2. プロジェクトを無事完了するだけの資源が本当にあるか。> 3. 定められた期限は本当に達成可能か。
この辺りって、開始後の捉え方ですよね。開始前には「自分達はそのプロジェクトにどれだけの資源をつぎ込めるか」「そのプロジェクトはいつまでに成されるべきか」ではないのかな？
なるほどだからお前の管理するプロジェクトはいつもデスマになるのか
やだなぁ、単なるコーダーがプロジェクトを管理するわけないじゃないですか
それって何か違うの？
そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。→未来予想は失敗したが、現状は把握していたようだ。プロジェクトを無事完了するだけの資源が本当にあるか。→傍目には不可能には思えない。定められた期限は本当に達成可能か。→傍目には可能なように思える。失敗しそうな場合、あるいは他の問題が起こった場合の予備計画はどうなっているか。→それは無かったが。プロジェクトに関与する必要のある利害関係者は誰か。→確かに市場は完全に無視していたな。
だからΣプロジェクトは、失敗したのか。
| そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。→未来予想は失敗したが、現状は把握していたようだ。
完全に仕様を満たして納期経費も完全だとしても「プロジェクト成果物が成功裏に使われる」とは無関係な話ですからねえ
ポートフォリオのプロフィットリターン想定が「絵に描いた餅に過ぎた」だけでしょう
After all,always money is everything.ですが（走召糸色木亥火暴）
1.その原発推進政策は現在のエネルギー戦略のどこに位置付けられるのか。推進派が大勢いて原発村を作ってるからやるだけ→化石に燃料が枯渇されるため何らかの代替エネルギーが必要。 当時他に使えるエネルギーがなかった。（過去にさかのぼって今と同レベルの自然エネルギーがあれば少しはかわったでしょうね。）
2.原発政策を無事完了するだけの資源が本当にあるか。安全な原発の設計・製造・運転・維持管理出来る人的資源がありません福島第一原発事故で実証済み→人的資源は教育でどうにでもなると思いますが・・・。 資源ではなく体制がない。といったところではないでしょうか。 （要
そんなゆるい理解だから反原発運動が結果を出せないんだよ。雰囲気や感情でやってないで、もっと勉強して来い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
0.ユーザーが本当に求めるものは何か? (スコア:4, 興味深い)
これ付け加えてくれませんかね･･･
Re:0.ユーザーが本当に求めるものは何か? (スコア:1)
ですよねぇ…。
つまりは「ゴール」が見えてない。
だから要求もあっちへふらふら、こっちへふらふらして、挙げ句の果てに使えない（ゴールにたどり着けてない）システムができあがり、顧客には不満がたまる。
買い手側（顧客）がシステムを理解していない・要求をまとめられないのならば、売り手側（システム屋、PM）が上手にゴールを設定してあげられれば良いんでしょうけど、それもできない下手くそなシステム屋やPMがいっぱいいるのも事実。
顧客が「今のままで満足です」と言うとか言わないとかあるけど、そこで「あぁ、これだったら欲しいな」「お、その切り口なら改善できるかも」「目の付け所が○○だねぇ」と顧客が言うようなものを見つけるのが営業さんでしょ。
システム屋やPMだって、ゴールさえ明確になってたら、顧客のふらつく要求を「それは本題ではないですね」と判断する（場合によっては切り捨てる）基準ができるしね。
それを、クラウドとか○×経営とか本質とは別のキャッチーだけど訳のわからないことで煙に巻いて顧客をだますようなことをするから、結局ゴール不明のプロジェクトが見切り発車をし、営業もSEもPMも、そして顧客までもが全員しなくて良い苦労をした挙げ句に不満をためる羽目になるわけで。
Re: (スコア:0)
MS-DOSベースの売り上げ管理システムが諸々の事情でWindowsベースになるとき
これまでのままでいい。つーか、これまでのままがいい、
という話を営業の人に伝えたところ、余計なもんばかり付け加えながら
残して欲しい部分をばっさり削ったもんが出来てきたことがあるなあ。
営業とPGが別とかWindowsベースかつDelphiを使わないとなにもできないPGばかりだった、
とか、のちのちの会話でそういう裏は見えてきたけど、
そのシステムを使う現場はそんな「事情」なんて知ったこっちゃないからね。避難轟々だった。
苦労してつくりあげたであろうシステムが、日々「ばっかじゃねーのこれ！」と毒づかれながら使われている、という事実に
もうちょっと敏感になって欲しいもんだよ。
営業から見ればPGのせい。PGにいわせりゃ営業のせい。
顧客がどんなに嫌でもその会社を選ぶのは縁故のせい。
システム会社の運営者たちは、新技術を追うだのビジネスチャンスだのイノベーション(笑)だの言う前に
このどうしようもない三竦み状態をなんとかしてくれい。
Re: (スコア:0)
> 営業から見ればPGのせい。PGにいわせりゃ営業のせい。
> 顧客がどんなに嫌でもその会社を選ぶのは縁故のせい。
> システム会社の運営者たちは、新技術を追うだのビジネスチャンスだのイノベーション(笑)だの言う前に
> このどうしようもない三竦み状態をなんとかしてくれい。
し､システム会社の運営者に縁故を何とかされてしまうのですか･･･？
Re: (スコア:0)
だから、本来なら「業務とはこうあるべき」という経営者の判断があって、それにあわせて業務及びシステムが作られるべきなんだけど、変に現場主義で帳尻あわせするからおかしな事になる。
現実的に早期(昭和40年代とか)にオンラインシステムを導入してスピードのあがった会社は多くある。
業務システム設計って、もっと大胆にするべきなのに、中途半端が一番悪い。
Re: (スコア:0)
逆じゃね？業務の内容がすんなりテンプレ化できるなら
定番業務アプリ一個開発した会社だけに金が集まる。
中小なんてクライアントの要望にきめ細かく対応した開発をしている(と世間では思われている)から
生き残れているわけで。
それよりシステム会社の技術力に、顧客が合わせなきゃならないような現状の方が問題。
ていうより、道具の使い方を知らない人がつくる道具で世の中回ってしまっていることか。
Re: (スコア:0)
提案出来ないから要求丸呑みなんじゃんw
Re: (スコア:0)
で終了してしまうのでその問いはNGです。
現状のシステムで満足している客にも、クラウドだ何だと提示して、異次元経営をイメージさせて買いたくさせるのが市場開拓です。
Re: (スコア:0)
必要のない物を必要だと錯覚させるところからスタートしてるから破綻する場合が多いのでは・・・
Re: (スコア:0)
本質的に必要かどうかを言えば、大抵の局面ではＩＴなんて無くてもコト足りますしね。
必要かどうかなんて、価値観の違いでしかありません。
-1.それはそもそも必要か？ (スコア:0)
いや、マジで
ITだけ? (スコア:1)
別にITプロジェクトに特化した話ではなく、どのようなプロジェクトの開始前にも必要な事項だと思います。
我が国では、一般に認識されていないようですが…。
Re:ITだけ? (スコア:2, すばらしい洞察)
いろいろな所から得た情報をまとめると、こんな感じになるかと。
・欧米のマスターでは、プロジェクト開始前に、
どのような結果を出すか、
上手くいかなかったらどうするか
等、徹底的に計画を吟味する。そのためプロジェクト開始は遅れる。
・欧米企業のCEOはマスター・ドクター卒は 当たり前。日本は大卒が多い。
・日本のマスターは、プロジェクトの教育を全然していない。日本のプロジェクトは、なんか面白い結果が出そうだ、といった雰囲気でプロジェクトを開始する。
実例として、DNA解析が話題となったとき、日本はDNA関連プロジェクトをすぐに立ち上げて進めたが、結局何も成し遂げていない（このあたり、当の研究者達は最初から分かっていた様だが）。逆にアメリカは、どのような結果を出すべきかを検討し、プロジェクト開始は日本より2年?程度遅れたが、癌関連で成果を出し始めている、と言う話を聞きました。
マスターの教育が出来ていないため、トップダウンのプロジェクトが日本では上手くいって無いように思えます。
（しかし、プロジェクト型を定着させるには、人材の流動性やプロジェクトから外れた弱者支援の仕組みも合わせて必要であり、文化的に現在の日本はプロジェクト型は向かないと考えています。）
Re: (スコア:0)
日本だけ？ も付け加えたいよね。
projects failure で検索する方はいっぱいいるみたい。
それ依然に (スコア:1)
御客様が何が欲しいのか？何を依頼したのか？それすら解っていないことが多すぎる。
Re:それ依然に (スコア:2)
お客様自身も実は漠然としか分かってない場合も往々にしてありますので。
それを具体的な形に引き出してあげるのがプロマネや営業のお仕事なのでしょうけどね。
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re: (スコア:0)
プロマネの理解 → 営業の表現 → …
っていうスライドが一時はやりましたね。
Re:それ依然に (スコア:1)
御客様が何が欲しいのか？何を依頼したのか？それすら解っていないことが多すぎる。
アプリが動き始めて考え始める方々もおられます。
Re: (スコア:0)
×依然に
○以前に
Re: (スコア:0)
担当者にもよるが、そういう客こそ扱いやすいとも言える。
作るほうが作りやすいようなものを提示して、これですよねって
押し付けちゃえばいい。
難しいのは、何を作って欲しいかわかっているのに伝えきれない人、
理解しきれない人の場合でしょう。
そういう人の場合は、下手な鉄砲方式でいっぱい提示する。
その中でマッチしたものを選んでもらう。
乱射するのは最初だけで、作り出したらもう滅多に変えない。
Re: (スコア:0)
そーゆー人は選んで運用した「後」に文句言うんだよ
Re: (スコア:0)
それを障害としてサポート対象にするのがクズな営業。
問うのは２つだけでいい (スコア:1)
２．追加案件は別途見積もり
これだけでいいはずなんだけど、なんでデスマーチになるんですかね
＃それって開発経験のある営業と、営業経験のある開発が必要になるのから無理なのか
Re:問うのは２つだけでいい (スコア:1)
というかですね、1の「何が欲しいのか」が定まらないと2での「何が追加なのか」も定まらないんですけどね。
もっとも、顧客自身が考えた「ソリューション」なんて当てにならないが、顧客に要望を聞くと要望ではなくその「当てにならないソリューション」を答えることがほとんどだという性質がある。なので顧客の「要望」を鵜呑みにしちゃダメなのだよな。TOCと同様、相手の言い分ではなく相手のおかれた条件を基に考えなきゃならん。そうでないと完璧に要望通りでも使えないブツや、今までと何の違いもない何のメリットもないブツができあがったりするわけで。
ITドカタ (スコア:1)
漠然と上が無能って愚痴る下と、下が無能って愚痴る上とがせめぎ合っている様子が見て取れます。
とりあえず案件とってきた営業が、距離おいてせせら笑う姿も見える・・・
それらより優先されがちな１項目 (スコア:0)
Re: (スコア:0)
-1.それより優先すべきプロジェクトは存在しないか？
Re: (スコア:0)
-2.赤字になるのでやりません。
Re: (スコア:0)
-3. それが失敗した時にキャリアが傷つかないか
Re: (スコア:0)
-4. 赤でもコネなんで断れません
うーんと (スコア:0)
1->聞かれたことはない、それはこちらで考える質のものでもない。
2->OK(決められた資源の元に立てた仕様を守れるなら)
3->OK(最初に認められた仕様を変更され無ければ)
4->失敗対策用予備プランは無い(複数プランの組み合わせで凌ぐ)
5->心当たりが多すぎる
#コソコソと匿名の臆病者として投稿
Re:うーんと (スコア:1)
１．そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。
何を作るかは、開始した後に決めます。
「ぽーとふぉりお」？なにそれ美味しいの？
２．プロジェクトを無事完了するだけの資源が本当にあるか。
規模も決まってないので分かりません。（ただし納期と予算だけは決まっています。）
３．定められた期限は本当に達成可能か。
規模も決まってないので以下同文。
４．失敗しそうな場合、あるいは他の問題が起こった場合の予備計画はどうなっているか。
いざとなれば人を突っ込みます。そりゃもう千人でも二千人でも突っ込みます。
５．プロジェクトに関与する必要のある利害関係者は誰か。
そういう社内調整なんかの些事は、全部外注(SIer)に任せてます。それが奴らの仕事なんだから。
＃お、オレの話じゃないぞ。あくまで一般論だからねっ
Re:うーんと (スコア:2)
まだ世の中に無いものの納期や必要工数が分かるはずがない！
Re: (スコア:0)
話持ってこられた段階で平気で納期が過去だったりするよね…
6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。 (スコア:0)
1.～5.は「マネージャが常時把握しておくべき当然の情報」じゃないですかね。はじめる前だけじゃなくて。
実際は当初の目標にズルズルと仕様追加していって 3. と 4. が徐々に破綻するパターンばかりでしょう。
6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。
Re:6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。 (スコア:1)
>6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。
進捗管理を台無しにするだけならいいけどね。
最初の仕様を根底から覆す「崩壊の一声」の存在というのもあります。
#さながら「バ○ス」
Re:6. 進捗管理を台無しにするような「鶴の一声」の存在があるかどうか。その頻度は。 (スコア:1)
開始前に？ (スコア:0)
どこが「開始」なんでしょうか？
> 2. プロジェクトを無事完了するだけの資源が本当にあるか。
> 3. 定められた期限は本当に達成可能か。
この辺りって、開始後の捉え方ですよね。
開始前には
「自分達はそのプロジェクトにどれだけの資源をつぎ込めるか」
「そのプロジェクトはいつまでに成されるべきか」
ではないのかな？
Re: (スコア:0)
なるほどだからお前の管理するプロジェクトはいつもデスマになるのか
Re: (スコア:0)
やだなぁ、単なるコーダーがプロジェクトを管理するわけないじゃないですか
Re: (スコア:0)
それって何か違うの？
Σ…Σを止めろ (スコア:0)
そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。→未来予想は失敗したが、現状は把握していたようだ。
プロジェクトを無事完了するだけの資源が本当にあるか。→傍目には不可能には思えない。
定められた期限は本当に達成可能か。→傍目には可能なように思える。
失敗しそうな場合、あるいは他の問題が起こった場合の予備計画はどうなっているか。→それは無かったが。
プロジェクトに関与する必要のある利害関係者は誰か。→確かに市場は完全に無視していたな。
だからΣプロジェクトは、失敗したのか。
Re: (スコア:0)
| そのプロジェクトは現在のポートフォリオのどこに位置付けられるのか。→未来予想は失敗したが、現状は把握していたようだ。
完全に仕様を満たして納期経費も完全だとしても「プロジェクト成果物が成功裏に使われる」とは無関係な話ですからねえ
ポートフォリオのプロフィットリターン想定が「絵に描いた餅に過ぎた」だけでしょう
Win Winになれるかな？ (スコア:0)
After all,always money is everything.ですが（走召糸色木亥火暴）
"castigat ridendo mores" "Saxum volutum non obducitur musco"
Re: (スコア:0)
1.その原発推進政策は現在のエネルギー戦略のどこに位置付けられるのか。
推進派が大勢いて原発村を作ってるからやるだけ
→化石に燃料が枯渇されるため何らかの代替エネルギーが必要。
当時他に使えるエネルギーがなかった。（過去にさかのぼって今と同レベルの自然エネルギーがあれば少しはかわったでしょうね。）
2.原発政策を無事完了するだけの資源が本当にあるか。
安全な原発の設計・製造・運転・維持管理出来る人的資源がありません
福島第一原発事故で実証済み
→人的資源は教育でどうにでもなると思いますが・・・。
資源ではなく体制がない。といったところではないでしょうか。
（要
Re: (スコア:0)
自分、原発反対派ですけど、あえて言うなら、
「原発マネーを貰う全ての人ですよ。」
原発が安全か否かはさて置き、動かす事によって利益が計上されるsystemが構築されているんですから。
あの不良品をコンクリートで何度となくかさましし、「もう安全」だと公言。
実際は今でも基準値を越えた放射線が測定され、そこでまだ働いてているんだろうなぁ。
ｸﾜﾊﾞﾗｸﾜﾊﾞﾗ。
これ以上は、臆病者なんで。
Re: (スコア:0)
そんなゆるい理解だから反原発運動が結果を出せないんだよ。
雰囲気や感情でやってないで、もっと勉強して来い。