「坂の上の雲」とプロジェクト
NHKでスペシャルドラマ「坂の上の雲」をやるそうです。そこで、「坂の上の雲」は高校時代に手に取ったけれど、全然おもしろく感じず、2、3巻でやめてしまったので、いま読み直しています。大変おもしろい。
当時、おもしろく感じなかったのはそれだけ子供だったのでしょうね……。
15分ほどしか乗らない地下鉄の往復で読んでいるので、戻りつつ読むからちっとも進まない。しかし、それも楽しみながら、じっくりゆっくりと読んでいます。
「坂の上の雲」は、（日清）日露戦争の話です。そういった歴史物はオチは分かりきっていて、その後も分かっているから、読み途中でもさまざまな考察ができる。
わたしの考察を1つ。「日清・日露戦争に下手に勝ってしまったことが不幸の始まりで、勘違いした挙句に第二次世界大戦であれほどの大敗をすることになった」という流れを、今までよりいっそう理解できてきた。
陸軍の乃木大将は旅順という敵の要塞攻撃を指揮していたのですが、その戦術は、コンクリートで覆われた山（丘ぐらいかな）から大砲と機関銃を撃ってくるロシア軍に対し、銃剣の歩兵が人海戦術で正面突破するという馬鹿げた方針で臨む。日本海軍から、再三、敵要塞の弱点である二百三高地を大砲で攻めるようにという要請があっても、その方針は変わらない。
しかも、乃木大将やその参謀の伊地知少将は、敵弾は絶対に届かない後方に司令部を置き、最前線の惨状を知らない。乃木大将は実戦経験はあるが、それは維新前後の戊辰戦争や西南戦争で、コンクリートの要塞を攻めるような近代戦ではない。伊地知少将に至っては実戦経験はない。
そんなやり方で、10万人の兵士のうち、6万人以上死傷者（戦死者は1万人以上）を出した。
結局、別方面（本陣）を指揮していた児玉大将が乗り込み、敵要塞の弱点である二百三高地を攻める方針をとり、わずか数日で二百三高地を占領することができた。しかし、児玉大将は乃木大将の手柄を横取りする、つまり究極の組織である軍隊の規律を乱すことは陸軍大将としてできず、本人も手柄が欲しかったわけではないので、旅順攻略の手柄を乃木大将のものとすることに苦心する。
結果、乃木大将の手柄となり、現在も乃木大将を祀る乃木神社があるように、乃木大将は神格化されてしまった。
当然のことながら、神となった陸軍大将の戦略・戦術に誰も批判することはできなくなり、旅順と同じ方針が、その後の日本陸軍の基本路線となったといえるでしょう。
つまり、女子供にまで竹槍を持たせるような玉砕人海戦術に結実していく悲劇につながったのです。
さて、現状のシステム開発に置き換えれば、当時の日本陸軍と恐ろしいほど一致すると思うのはわたしだけでしょうか？
違うのは……。イヤもっと恐ろしいのは、プロジェクトは二百三高地を攻めるという方針を取らなくても、デスマーチという人海戦術で一応の終結を見るという点です。
デスマーチになったプロジェクトも、最初から掛かった分の納期と工数（金額）があれば、同じやり方でも終わっていたわけです。つまり、デスマーチとはどういう状態かというと、単純に工数、納期において見積と現実が合わなかっただけで、予定通りきれいに終わったからといって、それが正しい手法とはいえないです。
しかし、デスマーチが終わった後は美談に変わります。予定通り終わればさらに美談で、間違っても愚策と責められることはありません。
どんな会社でも、予定通り終わった、デスマーチを終わらせたということが誰かの功績となるわけで、それが多くの乃木大将という神を生んでしまうことになる。実際、ほとんどのSIerに愚策によって神となった乃木大将が複数存在しています。
システム業界には、実戦経験は旧式のCOBOLのみという大将格もいるし、実戦経験のない大将も参謀も存在する。そして、実戦経験のない人たちのよりどころは、神なのです。そんな神や参謀に育てられ、それが正しいと思ってしまう士卒も多い。結果的にそんなやり方が、社風、社内文化として定着していくことになる。
司馬遼太郎先生が、「それは日本人の癖であり体質である」とおっしゃるとおり、変えようがないのだろうか？
ともかく、わたしは無謀にも、神から連綿とつながる全技術者と対決するために起業した本物の馬鹿だということが、「坂の上の雲」を読んで、いままでよりさらに、強く分かった。
さらに分かったことは、頭の固い乃木大将を変えることは、天皇陛下（SIerにとってはお客様）にお願いするしかないということです。
であれば、わたしの今までの活動は間違っていた。
わたしには業界を変える力など到底ないですから、開発に挑戦するよりも、チューニングという仕事を天皇陛下から与えていただけばよい。天皇陛下のご依頼で、勝因も敗因も分析し直し、天皇陛下のお言葉をもって乃木大将を指弾すればよいわけです。
もちろん、天皇陛下に直接お願いするために起業したのですけれど、わたしも開発にこだわっていた頭の固い馬鹿者だったわけだ！
チューニングの営業などしたことがないので、どうしたら良いのか分からないのですが、弊社は開発よりもパフォーマンスチューニングを中心としたサービスに営業方針を変えていくことにしました。もちろん、いきなりは変えれないけれど……。
具体的には、秘密保持契約を結んだ後、元のソースをご呈示いただいて、診断とチューニングを行います。エンドユーザに限り、初回の診断と、修正可能と判断した場合の一機能の修正までは無料とさせていただきます。
ひどいテーブル設計という、今からは簡単に変えられない手枷足枷をはめられてパフォーマンスが出ないということもあるので、効果をお試しいただいてからご依頼ください、というサービスです。
現在、価格（完全なテスト環境があることなどの条件もありますし）など検討中ですが、ファーストユーザーは特に安くさせていただきます。
実際には、他社が書き換えたソースなどメンテできないといわれるとか、いろんな問題はあるでしょうけれど、そういうときは、わたしがユーザーお抱え（ユーザー様の名刺を持って）コンサルになればいいわけです。
しかし、わたしがお客様の立場に立ってSIerと対決するとしたら……。
入社試験みたいなのではないけれど、スキルチェックの問題をやってもらうことからスタートですね。それで「この程度がでケへンのか！」「原因はあんたがスキルが足らなかったからヤンケ～！！」「この○○○がぁ～！！！」とか大阪弁でいわれたら、SIer側から見たら怖すぎです。わたしも夜道を歩けなくなるから、そこまでの無茶はいわないですけどね（笑）。
実はこういうサービスを始めたいと前から思ってはいたけれど……、全SIerに大喧嘩ふっかけるのと同じだからな～、開発仕事で何とかしたいって逃げてたんだな～。
もし、情報システム部の方がご覧になっていらっしゃったら、最初は無料ですし、セカンドオピニオンとしてご採用していただければ幸いです。
詳しくは、こちらのメールへ ⇒ info@g1sys.co.jp
あるわけないけれど、大手のエンドユーザーから依頼があったら、案外簡単に業界は変わるかもね。
「DBサーバで処理したら、DBサーバの負荷が増える」なんて、「大地は平らだ」って主張するのと同じ、根拠のない宗教ですからね……。ぱっと見は大地は平らですけど、そんな何の根拠もないことを技術者が言うことじゃないし……。
わたしは社長という立場になっても、結局わたしの方針でプロジェクトを運営できたことはほとんどない。それはわたしの能力の低さの証明ですが、乃木大将という神が創りたもうた常識と正反対のことをさせるのは、わたしが社長以上の立場に立たないと、どだい無理な話です。
弊社（わたし）に取っては、夢のような話ですが（大手の）情報システム部の皆様、ぜひよろしくお願いいたします。
コメント
士郎
こんばんわ。
チューニング方面に営業方針を変えていかれるのですが・・・。
DB設計やSQLについてはかなりお詳しいようですので、軌道に乗れば
いいですね。がんばってください。
フワニータ
日本は兵隊(PG？)が真面目すぎるのでは？
無謀なことでも必死の努力で何とかしようとしてしまう。
アメリカの兵隊に竹やりで戦え、などと言っても
「バカか、だったらさっさと降伏するわ」(実際の元アメリカ兵の老人談)
とのことです。
デスマーチになったりすると、あっという間にメンバーがどんどん辞めていってしまうため、デスマーチ自体も少ないようです。
（その分、完全な失敗プロジェクトは増えているのかな？）
がんばりすぎず、自分の能力を大きく越えることはしない。
そうすればスキルの低い人は入ってこれないか、いてもすぐに切られて、業界的にはむしろ良いかもしれない。
ん？結局、解雇制限撤廃すりゃ同じか。。。
放浪者
司馬遼太郎氏が書かれてますが、
有能な将軍（ナポレオンとか韓信とかかな？）とは教育や訓練によって育つものではなく、
ある日突然現れるものだとか。
兵隊や下士官ならともかく
PMやコンサルを教育して育てようというのは、もしかして無駄なのか？
インドリ
>「DBサーバで処理したら、DBサーバの負荷が増える」なんて、「大地は平らだ」って主張するのと同じ、根拠のない宗教ですからね……。ぱっと見は大地は平らですけど、そんな何の根拠もないことを技術者が言うことじゃないし……。
言葉足らずで誤解を与える表現だと思います。
DBサーバで処理すればその分負荷が増えます。
そうではなくて、ここで言いたい事は、
システム全体としてのパフォーマンスが下がるか否かですよね。
これは修正した方がよいかと思います。
そうしないと、くだらない揚げ足取りの餌食になりますよ。
インドリ
少しズレている気がします。
リンク先にも私は同意だと書いていますよ。
私が言いたかったのは、どう考えても「DBサーバーで処理すれば、処理する分だけ負荷が増えるよね」という事です。
0コストと言うのは技術的にあり得ません。
そこを突いて揚げ足を取りにくるSQL嫌いな人々が居るでしょう。
そもそもデータベースで処理しなければいいなんていう馬鹿がいます。
そこで、パフォーマンスが良くなると明言した方がいいと提言したわけです。
今の文章だとDB処理が0コストと主張していると曲解されかねませんよ。
DBを知っている人は意図がわかるので気にしませんが、
SQLを忌避している人々に向けてのメッセージだと言う事を意識しないと駄目なのでは？
コストよりも生産性が増す事を強調しないと馬鹿に揚げ足取られますよ。
そういった人々は曲解による揚げ足取りレベルだけは長けていますから・・・
セロ
楽勝より辛勝の方が評価されやすいのも問題なんでしょうね。
保守等でも事故が無かった場合より、事故を修復した方が評価が高いとか。
新しい評価方法を広めるのは苦労されるとは思います。
陰ながら応援させていただきます。
士郎
>インドリさん
周りにSQLを忌避するエンジニアがいてるんですか？
個人的にはSQLはおもろしくて好きですが・・・。
インドリ
>士郎さん
居ます。何回かそういった人と総合した事があります。
生島さんによるとかなりの数いて、凄く抵抗するらしいです。
今までの連載を読むに非常に苦労なされているようですね。
ちなみに、私自身はSQL好きで、ストアドプロシージャをバリバリ使用する派です。
それに、好き嫌いを抜きにしても、データベースエンジニアリング的に考えて、
データ整合性を保つためにデータベースを積極的に当たり前の事だと思うのですが・・・
しかし、否定したがる人は何癖付けてででも否定します。
その理論が「知らない人が言うもの」だからものすごく酷いものです。
そういった人々を観察すると、どうやら自分が知らない事を学ぶ気がなく、
おまけに自身の保身のためにSQLという技術そのものがおかしい事にしたいらしいです。
SQLに限らずそういう輩は結構いますよ。困ったものです。
例：オブジェクト指向反対派、.NET反対派のVB6使い等
良くある言い訳は、
・新人はSQL分からないはずだから保守性を考えてSQLを極力使わない。←知らないのおまえだろ！SQLぐらい教えろ！
・データベースサーバーに処理をさせること自体がコストだからクライアント側で全てする。←おやおや保守性はどうしたの？これじゃあスパゲッティだよ。
まぁようするに技術的うんぬんよりも自分がサボりたいという自称技術者が居るという事です。
それがまかり通るのが日本です。
日本の経営使者は得てして、情報処理技術を知らないから、サボりたい人達にだまされているのでしょう。
インドリ
おっと間違った
誤：総合した事があります。
正：遭遇した事があります。
毘政
生島社長。
好きです。
自分を雇ってください。
（・ω・）／
士郎
>インドリさん
そんなエンジニアがいるんですか・・。
そういう考えをするエンジニアが今後生き残っていけるとは思えませんが、
一度遭遇してみたいものです。
しかし、「保身のためにSQLという技術がおかしい事にしたいらしい」
という箇所はもはや笑い話ですね（笑）。
Ｓｏｄａ
私が読み間違えてなければ・・・
技術者が言うことじゃないということ・・・
そのままのことがコメントで返されてるような(^^;
http://el.jibun.atmarkit.co.jp/g1sys/2009/02/post-2004.html
こちらのアドレスも張ったほうがよかったのかも(^^;
固定概念って怖いですね。
やっぱり中途半端な知識が固定概念を増長させるんですかねぇ。
チューニングを営業的にアピールするのも難しそうですね。
「新しく何かができるようになった」という新機能はわかりやすいんですけどねぇ。
できていることの速度アップだと、なかなかお金出してもらえない。
より具体的な短縮時間が提示されないと価値が認められにくい。
既に利用しているシステムなわけですから、最低限の速度はでているでしょうし(^^;
やりがいはあるし、現場で使っている人からは喜ばれるんだけどなぁ。
お金出す人が、その価値を認めてくれるかどうかってのは別なんですよねぇ(^^;;;;
はじめまして。新参コラムニストのちょりぽんと申します。
生島さんのコラムは９月から熱心に拝見させて頂いており、最近はデビュー作から順に読ませて頂いております。
残念なことに今の私は生島さんと議論できる造詣を持ち得ませんので、これまでコメントする機会はなかったのですが（笑）
当コラムにある記事の殆どは、社会勉強の一環として自分にインプットされるのみでして、内容を自分の中で分解できるのは数年先になりそうです。
例えば『テーブル設計は実装の後に！』は固定観念のあった私にとってインパクトがありましたが、判断を下す前に、まず次のプロジェクトで試してみようと思っています。そういうことが可能な立場で参画できるのが何時になるのか不明ですが・・・
大袈裟ではなく、生島さんに意見をぶつけられるエンジニアになれるよう精進したいと思っています。
僭越ですが、引き続き良い記事を期待しております。
士郎さん、インドリさん、おはようございます。
微妙なのですね。
インドリさんがおっしゃるような劇場型の発言をされるのは、私以外（私は逆ですが）滅多に見ないけれど、たとえば「HAVINGは使用禁止」「EXISTSは使うな」というコーディング規約がいまだにあったりします。
これを押し付けるのはおかしい。
無限に好きに書いて良いとは言いにくいから、どこかにラインを引くためにコーディング規約は必要ですが、SQLは他の言語に比べて極めて低いところにそのラインを引かれるのは事実です。
毘政さん、おはようございます。
落ち着いたら是非！
今は、金がない……。
しかし、タイトルでもっと釣らないとな～。
「坂の上の雲」では若い子は反応しないみたいで、いつもよりアクセスが低かったような……。
タイトルに「デスマーチ」って入れないといけなかったのね……。
ちょりぽんさん、おはようございます。
話はそれますが、私も特定派遣で働くのが好きでした。
でも、特定派遣ではあるレベル以上の仕事（プロジェクトの大方針を決める部分）は手出しができない、という不満から私は起業したのです。
つまり、「二百三高地を攻めたら良い」と分かっているのに、正面に向かって突撃ラッパ（これが本物のデスマーチ）を吹かれ突っ込んで行くわけですよね。
その正面突破で、撃ち落とされる砲撃を上手に避けるスキルを付けるより……。
ってことが私が起業した理由です。
ちょっと、意地を張りすぎていた。
生活を考えると特定派遣の方が良かったかなと思うけれど、やりがいはあります。
また来てください。
oumi
>実際、ほとんどのSIerに愚策によって神となった乃木大将が複数存在しています。
うまい事いうなぁ。（だいぶ変わってきてはいますが、まだまだ、いますねぇ）
>神なのです。そんな神や参謀に育てられ、それが正しいと思ってしまう士卒も多い。結果的にそんなやり方が、社風、社内文化として定着していくことになる。
これもうまいなぁ。
>司馬遼太郎先生が、「それは日本人の癖であり体質である」とおっしゃるとおり、変えようがないのだろうか？
大半の日本人はそうなんだろうと思います。
なればこそ、外国育ち・外国の血を取り入れないと・・単一種は何れ滅びるので。
なんだか、久しぶりに面白いなぁと思って読みました。
>弊社は開発よりもパフォーマンスチューニングを中心としたサービスに営業方針を変えていくことにしました
こういう話を聞くと色々妄想が浮かんできて楽しいですね。
WEBベースで「SQLステートメントいくつまでなら、無料で判定・変更します」的な感じで、顧客の引き込みやCM行うなんて手もありそうですね。貴社のプロモーションの１方法としてってことですが。
PASS-Jが終了したこともありますから、これに代わる何かを貴社でやるっていうのも、良いかもしれません。
C#=>VB.NETコンバーターのように、某DB => 某DB などのコード コンバータを公開されると、これもプロモーションとしてはよさそうです。グローバルでいけますし。
妄想は続く・・・
技術力があって、フットワークも軽い会社ってのはうらやましい。
士郎
>生島さん
私も生島さんのような考え方が好きですよ。
毘政さんと一緒にぜひ雇ってください！（笑）
さて、HAVINGやEXISTSが禁止のプロジェクトがあるなんてはじめて知りました。
どっちも重要ですが、そういう場合はどういう対応されたのですか？
私には理由が思いつきませんが、なぜ禁止なんでしょうか？？
EarlGrey
おすすめエンジニアライフのタイトルが、
『司馬遼太郎から学ぶデスマーチ』
とあったので釣られてきました、Earlgreyです。
さすが文字書きの本職。キャッチを心得てる(笑
ところで、SE側に限らずお客さんの側でも、結構な偏見というか、
こだわりを持っている方もいらっしゃるようで。
システム開発の事情をある程度知っている方に多いように見受けます。
私の担当のシステムで、JavaとOracleRACをセットで使っていますが、
Javaアプリケーションサーバ側は、リソースが悲鳴を上げているのに、
OracleRAC側はまったく使われてなかったりします。
説得を半ば諦め気味な私にも責任があるんですが。
宗教と言わないまでも、こだわりを乗り越えるのはなかなか･･･(汗
エントリーポート
生島さん、お久しぶりです。
一度、コメントさせていただいたエントリーポートです。
>毘政さんと一緒にぜひ雇ってください！（笑）
ぜひ、私も！
>HAVINGやEXISTSが禁止のプロジェクトがあるなんてはじめて知りました
OTNの掲示板の過去ログでは、結構
ネタにあがってました。（2004年ぐらい？）
HAVINGは、まだなんとかなるとしても、
EXISTS はつらいですね。
IN とかでごまかすとか・・・。
oumiさん、おはようございます。
イロイロと考えると、SIerの硬直の仕方は、本当に日本陸軍に近いですね。
恐ろしいです。
> WEBベースで「SQLステートメントいくつまでなら、無料で判定・変更します」的な感じで、
> 顧客の引き込みやCM行うなんて手もありそうですね。貴社のプロモーションの１方法と
> してってことですが。
なかなか、CMまでは厳しいけれど、SQLステートメントだけじゃなくグルグルも直さないといけないので、ステップ数かな（笑）
EarlGreyさん、おはようございます。
お客様でこだわる人は、ほとんどSIer（COBOLer）上がりの情報システム部ですから、これもまた困った人たちですね。
COBOLerから見ても、Javaなどはアルゴリズムがあるだけ、ギリギリ理解可能でも、アルゴリズムのないSQLはいやがります。
簡単なのですけどね……。
士郎さん、エントリーポートさん、おはようございます。
宝くじでも当たったら、入っていただけるのですけれど、今は本当にお金がないのです。
しかし、こんなブラックな会社のどこが……。
それはさておき、妙なコーディング規約ができるのは、インドリさんのような言い方をする人はないけれど、基本的には自分ができる範囲でやって欲しいというのが本音でしょう。
JOIN禁止とかも昔ありましたし、今でも、JOINを申請式にしているところもありますよ。
そんな馬鹿げた人海戦術でも、馬鹿みたいに工数を積み上げれば終わるのは終わるのです。そして馬鹿げた神と、馬鹿げたコーディング規約が定着してしまったりね……。
日本を代表するSIerのVBの案件で、「GOTOはOK」、「配列はやめて」ってのも数年前まであったらしいし世の中広いな～。
はじめまして。
論旨は賛成で、考察は特に同意ですが、こういった本もあるのでご紹介しておきます。http://www.amazon.co.jp/gp/reader/4569666051/
ごく稀に「坂の上の雲の乃木大将による旅順攻略戦」のようなシチュエーションはあるような気はしますが、噂から派生したフィクションであったり、プロジェクト外部から見た的外れな批判であることが多いのもまた事実だと思います。
個人的に、この業界の生産性の差は、もっと高いレベルで生じていると思う（信じたい？）んですけどね。そこまでのバカはなかなかいないけど、普通にやっちゃうとデスマーチにはまるといったニュアンスで。
でも、変な神様があちらこちらにいるのは、１００％同意ですねぇ...。
私も「坂の上の雲」は大好きなのですが、ちょっと気になったので、ご参考まで。
T-norfさん、おはようございます。
どんな事象でも見方で変わります。
ですから、乃木軍司令部に対する評価も様々なものがあって当然です。
今でも、単純に神と思っている人も大勢いるでしょう。
ただ問題は、明らかな事実として6万人以上の死傷者を出したことです。
「6万人の死傷者が出ても攻略した」か、「6万人も死傷者を出さなくても攻略できた」か、タラレバをいっても仕方がないけれど、検証しなかったことが問題なのです。
7万人が死傷するだろうと見積もっていたのであれば旅順攻略は大成功です。
それが、第二次世界大戦で、全滅の見積の作戦がたくさん立てられた結果につながっているのでは？
コの業界で、全滅前提の見積が多いなと思うのは……。
saki1208
生島さん、こんばんは。
saki1208です。
多分、うちにもたくさんいますよ。乃木大将。
今でもSQLに限らずVBやその他言語の意味不明な縛りはありますよね。過去にも
書きましたがうちではかつて以下の様なのがありましたね。
# 現在は啓蒙活動の末、撤回されていますが...
UNION禁止
副問い合わせ禁止
ビュー禁止
1パッケージ1ファンクション/プロシージャ
すべてのパッケージ内ファンクション/プロシージャに全く同じ処理をするフ
ァンクションが定義されているなどなど...
VBだとステップ数が多すぎて追加しようとしたらコンパイルエラーとかメソッド
ごとコメントにしてあって、数行しか違わないメソッドがもう一つどころか複数
あるなんてのも...
お終いにはいつも「だってわからないから」ですからw
これで飯を食ってる以上、本当はそんな甘えは許されないと思うのですけどねぇ...
saki1208さん、おはようございます。
私が発狂したのは、VBの配列禁止と、SQLのJOIN禁止かな。
悪い冗談としか思えない。
禁止しないとどうしようもないほど、レベルが低いのが集まっていたとも言えるし、親分がどーうしようもなく、大馬鹿ものだったとも言える。
あるプロジェクトを終わらせるのに、集まったメンツでこなすにはそれがベストなのかも知れません。その時点で2週間の遅れを覚悟して教育すれば最終的には帳尻が合うかも知れません。
タラレバでは何とでも言えますから、そのプロジェクトに対してはＯＫだと思います。しかし、検証もなしにそれを社内標準にしてしまうから、乃木大将だと……。
次の果てしないデスマーチに会社ごと突き進んでいるのに気づいて欲しい。
毘政
お勧めの本があります。
日本の敗因―歴史は勝つために学ぶ (講談社プラスアルファ文庫) (文庫)
きっと参考になるかと・・。
お金になるかどうかは、別ですが・・・
自分も、今まで得たオープン系の技術で、就職・転職サービスサイトの構築なんぞを考えています。
今、ポチポチと作成中。
毘政 さん、おはようございます。
ありがとうございます、一度読んでみます。
> 就職・転職サービスサイト
仕事にするには厳しいかな。エンジャパンとかが使っている広告費を知ると、それをアイデアで超えることは……。
こんばんわ。
＞仕事にするには厳しいかな。エンジャパンとかが使っている広告費を知ると、それをアイデアで超えることは……。
いえ、超えようという気では。
少しでも、求職者に有利な情報を提供できればなという試みです。
出来るかどうかは、別問題です。（汗）
それで、
しつこいようですが、先の本を一部分抜粋します。
・資源の再配分を考えないのはいまも同じ
人材を育てるには、もちろんコストがかかる。多大なコストである。
しかし、ここに国の運命がかかっているのである。何が何でも急がなくてはと、コストなど気にせずに、人材の養成に国をあげて取り組んでいたら、「ゼロ戦」の後継機の誕生はもちろん、大東亜戦争のさまざまな局面で、歴史とは大きく異なった展開があったに違いない。
コストがいくら多大であっても、戦争そのものに負けることを考えてみれば、安いものなのだ。
新しいアイデアを出せ。可能なことはすべて試みよ。失敗したっていい。試行錯誤でいいのだ。
優秀な頭脳に向かって、そう号令し、「責任はみんな自分がとる」と断言する指導者がいれば、事態は異なったものになる。それがリーダーの役割である。
戦争責任者とは、そういうものなのだ。
～『日本の敗因・歴史は勝つために学ぶ』 第三章 ヴェンチャーであったゼロ戦 より～
毘政さん、こんばんは。
弊社は、求人サイトではないけれど、B2Bのマッチングサイトなどもやっていましたけれど、年間数千万でも厳しかったですから……。
資源の再配分を考えるのは社会主義で、国が発展する方向を考えるのが資本主義ですね。
日本は世界で最も成功した社会主義国ですが、そろそろ、本当の資本主義にならないといけないな～。
民主党政権では望むべくもないかも……。