Twitter上のやりとりで、考えさせられたので、考えたことを吐きだしておきます。

製造業、建築業、IT業界(SIer)、テレビ番組制作…
共通していえるのは、

• 業界的に急成長した時期があった
• 労働集約的な業務遂行
• 多重構造になっていて、末端が食えていない現状
• そんな現状に陥ったのは、業界の成長が頭打ちになってから

ということでしょうか。
まず、どうして多重構造ができあがったのか、想像、推測、憶測を重ねてみたいと思います。

多重構造に至るまで

今悪いことになっているといっても、多重構造になったのには、それなりの利点があったからのはずです。
それはどんなものだったのでしょう。

建築、IT

ごく最初のころは、元請けが全部仕事をしていたと思います。
仕事の規模もしれていたので問題なかったんではないでしょうか。
しかし、規模が拡大するにつれ、分業化していったほうが効率がよいということになった。

金の流れの末端に位置する会社にとっては、いろいろと都合がよかったはずです。
それなりに技術を磨いていれば、上流のほうから流れてくる仕事をこなしているだけで、経営がなりたつ。

金の流れの上流にいる会社にとっても、都合がよかった。
仕事とって、マネジメントに徹していれば、利益があがります。
多数の会社に仕事を振ったほうが、自分のところですべてかかえるよりリスクが少ないですしね。

製造業

部品を組み立てる工場というのが一つポイントでしょうか。
ここの問題はふたつにわかれて、組立担当の期間工と、部品工場の上流から下流の問題。
組み立てる人は組み立てに徹していればOK。最初のころは社員がとりくんでいたのでしょうが、雇用の流動性確保のために、期間工を導入した。

部品をつくる側は、多重構造です。在庫のリスクを下流側に追いやることで、組立側には在庫を残さない。
これが、上流側のメリット。

下流側にもメリットがないかと言えばそうでもない。
言われたとおりのものを作る技術があれば、上流から仕事はやってくるんですから。

テレビ番組制作

テレビ番組を作る場合にも金の流れの上流側には社員をかかえなくてすむというメリットがあります。
民放の場合、番組制作費はスポンサーは出しますが、制作費の多くは、人件費に消えていきます。ところが制作会社に1本○万円で投げてしまえば、それ以上のことは気にしなくていいですから。

受ける側にも、最初のころはメリットがあったかな。テレビ番組を作りたいと思う人の受け皿になっていた部分もあるかもしれません。

最初のころはメリットがあったとして、どのように崩壊していくのか、次で見ていきたいと思います。

問題解決のフレームワークとか言われても、ちっともピンとこなかったのですが、「問題を解決する流れ」というのはだいたいこんな感じではないか..というのを考えたので、まとめてみました。

ただし、システムインテグレータ(SIer)勤務で、システム障害の対応だったり、維持管理をしていての問題解決だったりするので背景は相当かたよっているとは思うのですが。

7つのステップ

図は、Xmindで作成しました。

• 問題
• 仮説
• 調査
• 検証
• 解決
• 実行
• 評価

のステップです。

実践すると、たぶんこんな感じ。

• 問題: 夜間バッチ処理が完了すべき時間までに完了しない
• 仮説: どこかのジョブで処理に想定外の時間がかかっているんじゃない?
• 調査: ジョブごとの開始終了時間の取得→時間がかかっているジョブを確認
• 検証: 時間がかかっていることを確認
• 問題: なぜ時間がかかっている?
• 仮説: 非効率なSQLになっていないか?
• 調査: SQLの詳細情報を取得
• 検証: 負荷の高いSQLを確認する
• 解決: 負荷の高いSQL効率のよいものにして、時間短縮をはかる
• 実行: 本番環境へリリースする
• 評価: 処理時間の短縮したか確認する

問題〜検証までが、問題点を明らかにするためのアクションになります。
具体的な「解決」につながるようになるまで、問題〜検証を繰り返します。
検証で仮説が「はずれ」となれば、新たな仮説をたてて、調査〜検証を行います。

重視するポイント

上の7つのうち、システムのお守りをしていて重要だなと感じるのは、

• 仮説
• 調査

です。

特に仮説のほうが重要です。
仮説を上手に立てられると、問題解決までの時間と作業が少なくてすみます。
プログラムが想定どおり動かない原因を解決するにも、目のつけどころが違っていて、いつまでたっても解決できないこともあります。
ピントのずれた調査はいくらやっても徒労です。

また、現状をおさえるための調査ツールをたくさん知っていることは、調査時間の短縮につながります。

• ネットワークの問題?→ping,traceroute, wireshark, サーバ上のパケットキャプチャーツール
• サーバのリソース?→vmstat、sar、df

などなど。
専門家にたよるにしても、こんなこと調べるための手段はある?といった質問ができると、回答が早いです。

「仮説」と「調査」がうまくなるには、システムがどう動いているか仕組みを知る必要があります。
「解決」について承認を得るスキルというのも顧客に説明する立場として重要に思えます。
しかしながら、しっかりした「仮説」と「調査」に基づいた説明ができれば、顧客が感じる納得感が大きくなると思いますので、結局「仮説」と「調査」が大事かなと考えます。

最後に

コンサルタントの思考の流れというのも、もしかしたら、たいして変わらないのかな..と思いました。
現状を知り、解決策を導くということには変わりませんが、

• 問題点を明らかにするまでのツールが違う
• 「世の中」の仕組みを知らなくてはいけない

というのがポイントなのかもしれません。

［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/

「システムが複雑になったのはビジネスが複雑になったため」とぴしゃりと言う。「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは化石”などと話している人を見ると，ビジネスに携わる技術者として見識を疑う。

トラブルの原因が「使用言語」のせいという人には確かに見識を疑う。まったく同意なんですが。
「ビジネスが複雑になってもシステムはシンプル」という作りになっていなかったのも。
○○区分が横にたくさん並んでいるテーブルが温存されていたら、保守性は低そうだよなぁ。

プロジェクトの要件では，「プログラミングと単体テストを5カ月で終了しなければいけないスケジュールを乗り切るには，これまでのノウハウや人材を生かしきらなければならないと判断した」という。

COBOLしかわからない人を大量に抱えていたら、こうせざるを得ないだろうなと思う。
これまでのノウハウを活かしたということは、新しい知見を入れられていないということかもしれず。

となると、

稲葉取締役は「開発1年・保守10年」と東京海上日動内で伝統的に伝わる「戒めの言葉」（稲葉取締役）を引いた。「システムは開発して終わりではない，いかにそれを高い効率と信頼性を保って保守していくかが欠かせない」

ここが気になる!
どのようにして「高い効率と信頼性を保って保守」しようとしているのか。

当然そのための工夫とか、COBOLでもテストを自動化する仕組みとかいろいろあるんだろうけど。
記事がCOBOLに焦点当てすぎているせいか、表に出ていないですね。

今度チャンスがあれば質問してみたいところです。

「質問のスキル」といってもコーチングで出てくるそれとは違うかも。

現在の会社で働くようになってから6年以上が経過し、今のチームで働くようになって4年半が経過しました。
その間チームに新卒の後輩、他チームから移籍の新メンバーが入ってきたりして、質問をされることも多くなりました。今年に入ってからは質問されまくりです。
質問をする側だったときには、あまり意識したことがなかったのですが、質問される側に立つと回答しやすい、うまい質問のしかたというのはあるんだなぁという思いです。
感じたことをまとめてみます。

質問の内容

SIer勤務の私です。
後輩、もしくは、新しく入ってきたメンバーから寄せられる質問の内容は大きくわけて二つです。

1) 技術的なこと
・Webサーバ(apache)の設定とか、DNSサーバの挙動とか
2) 業務上の判断
・テストケース成否の判断、障害対応内容の判断など

技術的なこと

回答のスタンス

後輩、ことに業務の経験がない新卒で入ってきた人を、ひとりで仕事をできるように仕込むことを目的に回答しています。
なので、直接の答えを与えることはなるべくしません。
後輩ひとりで調べ、回答をひっぱり出せるアクションができるようにすることが目標です。

答えやすい質問

この質問で困るのは、「質問者がどこまでわかっているのかわからない」と適切な答えができないということです。

なので答えやすい質問は、質問者の理解がどれほどであるのか示してくれることです。
a)実現したいことはなにか
b)何を、どう調べたか
(「○○という本を調べた」、「××というキーワードでググった」、「ベンダーに質問した」など)
c)そして現状わからないことはなにか
を踏まえた質問ということになります。

a)のポイントがあいまいであれば、もう少し具体的にすることで求める回答にたどりつけることになるでしょう。
b)のポイントでそもそも調べていなければ、「ググれ」「マニュアル読め」の一言です。
調べているものがよくなければ、ある程度のヒントを出すようにしています。

業務上の判断

回答のスタンス

こちらの質問では、自分自身でどうアクションすべきか考えるようにするのが目標になります。
しかし、判断基準にチーム内でぶれが出ることは、お客さんからみて、ぶれが出ることになるので避けなくてはいけません。
新メンバーで入ってきた人と、元からいるメンバーで判断の基準がなるべくぶれないようにすることが目的です。

答えやすい質問

判断を求めるときには、Yes, Noで回答できる質問にすることです。

「○○というテストケースで、接続先のシステムの応答が××という結果になったが、仕様書には▲▲という記述があり、OKとしてよいと考える。OKとしてよいか?」
というように
a) 今ある事実
c) 判断の根拠
b) 判断結果
を示してもらえれば、Yes,Noで回答が可能です。

「どうしたらよいでしょう?」に対しては「どうしたらよいと思う?」と質問返しすることにしています。
自分で考えることが大事だと考えるからです。

質問を記録する

質問されることが多くなってから、誰からどんな質問をされたか、記録するようにしました。
「同じような質問をしてくるんじゃない!」という意味をこめて、チームのメンバーにも公開しています。
自分が他の人に質問したことも同様にまとめています。

記録しているうちに、これは外部に示す仕様書に記述が必要ではないか、とか、マニュアルでまとめる事項ではないか、とか考えるようになり、チームで仕事をするために必要なアウトプットというものも見えてきたような気がします。

まとめ

質問のスキルを、質問の内容をふたつにわけた観点から、考えてみましたが、さらにまとめることができそうです。
それは、「質問者が思考の過程を示す」ということです。
もちろん、そういう質問が出てくる背景には、「質問される側が思考の過程を残していない」という問題があるように思います。
思考の過程を残していくという意味でも、質問の内容を記録しておく価値があると考えて、活動を続けています。

でも、思考の過程が残っている設計書なんか、見たこともないや。

システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却 ビジネス-次世代ＩＴ産業論考（浜口友一）:IT-PLUS
http://it.nikkei.co.jp/business/column/hamaguchi_it.aspx?n=MMIT2z000025072008

そしてよく考えてみると、ソフトウエアは製造工場で同じ形の製品を繰り返し大量生産するようなものとは違い、製品設計それ自体が生産物であり、２つと同じものを作ることはない。果たして、このような工場型の方式が向いているのかどうかという疑問もわいてくる。

だって、「生産」と「開発」は違うもん。

よく引き合いに出される自動車で言えば、工場でやっている「生産」というのは「同じものをたくさん製造する」ことでしょう。
「同じもの」つまり「製品」のコンセプトを決め、設計に落としていくことは、「開発」というのではないでしょうか?

そういう意味では、OSやパッケージベンダは自動車会社の「開発」に近い工程が回せているのかもしれません。コンセプトを決めるのは自分たちですからね。で「製造」はCD-ROMとライセンス文書のコピー。

SIというのは、顧客にコンセプトを決めてもらって「開発」に入るんだから、自動車産業のしかも「製造」をまねっこできないのは自明なんじゃないのか?
自動車の「開発」がどのように進められているのかは、参考になるかもしれませんが。

開発生産性が低い方が収入が多いって変だよね – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080723/1216790705

実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。

「開発の生産性」と言われると、ちょっと違和感を覚えてしまうのはこのせいだったか。

フローチャート関連の議論のあと、システムエンジニアってなんだろうと考えていて、ふと思い出した塩野七生氏の文。
分業についてです。

『ルネサンスとは何であったのか』(文庫版 P.87)

また、当時の工房が、美を追求することならば何でも引き受けるというシステムであったのも、フィレンツェ人の気質に合っていたのだと思う。絵画や彫刻にかぎらず、祭りに使われる旗から御婦人方の衣装や宝飾品、机上の置物から大建造物と、図面を引いたりデザインを考えたり金銀や銅を溶解したりと、あらゆる種類の仕事が工房では行なわれていたのです。その仕事の進め方も、専門ごとに分れていたのではない。見習い期間中はとくに、必要となればどこにも手助けに行かされる。絵具の調合をしていたと思ったら、金属を溶く火の前でふいごを手にしているという具合です。
(中略)
そして、何でもやれねばならなかった工房という学校で学んだ後に独立し、それ以後は得意な分野で才能の花を咲かせるのが、フィレンツェの芸術家の生涯のコースだった。

一方、ヴェネツィアは
『ルネサンスとは何であったのか』(文庫版 P.88)

画家は絵だけに、建築家は建築だけに専念していたヴェネツィア人とは大きな違いですね
(中略)
ヴェネツィアでは、効率性を重視したから専門化したのではなく、ヴェネツィア派の絵画の台頭が、フィレンツェ派の成功の後を追って成されたという事情によると思います。専門化とは、相当な成果があがった後ではじめて効果を発揮できるシステムだから。

今まさに、システム開発にとっての「専門」の定義が変わるときなんでしょう。
「ホスト」でのシステム開発で大きな成果をあげてしまった反動なのかもしれません。
分業体制とか、作りかたとか、ホストの名残りであることが多いですからね。

ホストでの開発も最初はフィレンツェ式で、みんななんでもやっていたんじゃないかなぁ。

もう一度、フィレンツェのような渾然一体に戻ってみる時期なのかもしれません。そうすればソースコードを書けないような人は淘汰されていくんでしょう。

私自身は思考も指向も、「フィレンツェ式渾然一体型」なんだと思います。
だいたい、専門職と言われるのが好きではありません。なんだよ基盤の専門職って。
製品買って組みあわせるのが基盤か?
システム作るのにやれることはなんでもやるんじゃないの?
データ設計とか担当外だからって口出しちゃだめなの?

やばい、愚痴になってきた。

SIerにおいて、システムをメンテナンスしていくのに必要なドキュメントとはなんだろう。

プログラミングファースト開発の必要性 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080721/1216607451

仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。

まず、対内部 & 対顧客として
このシステムはなにをするためのものか
がわからないと引き継ぎ困難です。
『概要設計』と呼ばれるレベルのものでしょうか。
・機能リストのようなもの
・(他システムとの接続があれば)接続関係図
があるとメンテナンスが容易になります。
(どのシステムに影響があるかわからないと、事前の影響確認とかしてもらえない)

そう考えると、対外的には
・外部システムとの接続仕様(I/F仕様)
は残しておく必要があるかな。外部システムの担当が他社であれば、接続仕様がないと話にならないかもしれません。
Web画面で済むならこれも不要かも。

あと自社内担当分であれば
・内部の機能配置
・プロセス間通信(機能の間でのデータのやりとり)が発生するならその経路
・機能とソースの関連性
を図示しておけば、いじったときの影響を判断することが可能。
テスト年中まわしていれば気付くだろうしね。

障害発生時の動きを示した文書は、エラーメッセージがしっかりしていれば不要。
ただ、H/W障害発生時や停止したときの復旧方法など示した文書、再構築手順は必要か。

コード仕様書などは、「1=会社員」とか「2=公務員」などという内容にしなければ不要そうだ。
(ダイレクトに「会社員」「公務員」とかエントリーしちゃだめなの? こちらのほうが直感的ではあるんだけど)
現状、ホストのデータの持ちかたをひきずったシステムをどうすればいいのか…
外部から飛んでくるデータもこんなんだしなぁ。

フローチャートの議論で、フローチャートなんて、研修や新人を教育するときにしか見たことないです。

参考URL

フローチャートとFizzBuzz問題 – novtan別館
http://d.hatena.ne.jp/NOV1975/20080719/p2

言語なんて何でも一緒（でない場合もある） – ぼくが真実を口にするとほとんど全世界を凍らせる
http://d.hatena.ne.jp/goodbye_bluemonday/20080720/p1

フローチャートの呪い – カレーなる辛口Javaな転職日記
http://d.hatena.ne.jp/JavaBlack/20080719/p1

システムエンジニア不要説 – masayangの日記（ピスト通勤他
http://d.hatena.ne.jp/masayang/20080719/1216511611

COBOLで処理するバッチ系の処理であれば多少、役にたつかな…と思いますが。
フローチャートでわかるのは、ちゃんと段取りを踏んでいるかどうかだけです。

・ファイルオープンする前にマッチング処理開始、データどこから読むんだよ…とか
・おいおいそれじゃ、マッチング元のレコード上書きされているじゃないか
などという事態を未然に防ぐことができます。

もちろんできる人は、こんなばかばかしいことしないと思いますが、経験のない新人なんてこんなレベルなんです。

たとえば、会議の調整をするのに、参加者のスケジュールの空き状況確認しないで
「会議室○○番が空いていたので、×月×日13:00からでお願いします」
などと、いきなり言ってきたら、アホかと。私はその日出張で終日オフィスにおりませぬ。

少なくとも、

1) 必須の出席者を確認
2) 出席者の共通の空き時間を確認
3) 出席者のスケジュールを抑える
4) 会議室の空き状況確認
5) 会議室を抑える
6) メールなどで開催を連絡

ってな段取りを踏むでしょう。
でも、こういう段取りを踏むことができない人もいるんです。
ファイルを開かずにデータを読もうとしたりするんです。

システムエンジニア不要説 – masayangの日記（ピスト通勤他
http://d.hatena.ne.jp/masayang/20080719/1216511611

もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。

ズボンとパンツを履いているのか?と確認するためのツールがフローチャートです。
でも、そういう確認をしなくてはならないレベルの人がいるのも事実です。

※ 「こんなん採用してくるんじゃねー!」という話は置いといて…

こういうところから積みあげていかないと、「コードを書けないシステムエンジニア」を量産するばかりになってしまうことにはならないでしょうか?

10分で作るRailsアプリ アプリケーション編 – masuidrive
http://masuidrive.jp/rails/rails_app.html

しかしながら、フローなんかよりデータレイアウト(DBでのデータの持ちかたとか)を考えないといけないとかな…と考えたりします。

・全レコードをunloadするのが一日の始まりです
・1レコード、何カラムあるんですか?
・E-R図なんてものはないよな…正規化なんて言葉も知らないんだろうな
・なんとか区分やめてください。if分岐が、テスト工数が…
・テーブルレイアウト変わるから移行が大変面倒です。

これはフローの問題ではないよなぁ?

下記2エントリを見て、腑に落ちました。
十年一日のやりかたでいるところに一石を投じることができれば、泥にならずに済むかもしれませんね。自発的な苦労がついてきますが。

泥カンと未来サミットとIT業界の現実 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080717/1216274298

10年泥が嫌ならITお勧めだよ – 雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080717/it

2002年、新卒で入社したとき配属されたプロジェクトでの話です。
IT土方の頂点SIerの迷惑な新人として、社会デビューです。

プロジェクトの概要は以下のとおり。
(新人のときに見えたものなので、全体はまるで見えていないですが)

[全体]
・ホストで動いていた企業内の基幹(企業内会計)システム(旧)を、オープン系(新)に移行して、維持管理削減を目指す
・情報系のシステムを刷新(というかほぼ新規構築)
・移行期間中の基幹系システムの出力は新旧比較

[新・基幹系(筆者所属チーム)]
・新側のシステム開発
・開発言語はCOBOL
・新の本番サーバはUNIXだが、個々のプログラムの開発環境はWindowsのPC上で構築(Unix, WindowsそれぞれをサポートしているCOBOLコンパイラ製品を使用する)

[基幹系移行チーム(プロジェクト途中から筆者所属チーム)]
・旧→新への移行のためのプログラム/フロー/時間割作成
・移行データの洗い替え/検証

私が担当になったのは、移行データの洗い替え/検証の作業でした。

それまでは、指示にしたがって、Unix開発機のセットアップや本番で動く担当プログラムの開発に従事していたのですが、生産性は協力会社のばりばりCOBOLerには劣るし、ただの一作業者っていう感じで一生懸命、詳細設計して、コーディングして、単体テストしてました。

10年泥が嫌ならITお勧めだよ – 雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080717/it

結局10年以上の経験を持つ先輩がいる職場って10年泥なんだよ。経験を積んだ先輩と生産性を比較され、出来が悪いんだから下積みやって追いつけ、となる。

移行データ関連の作業は最初、Unixの本番機とホストでやっていたのですが、プロジェクトでの環境の割り当て優先順位がどうにも低く、検証作業が予定通り進みません。
たくさんの端末で動かして、移行データ関連作業もはやくすませるのに、単体プログラム開発のとき使っていたWindowsのPCを使ってできないか? と上司に相談を受けました。

「UnixのシェルをWindowsのバッチで動かすようにすればいいんですよね? シェルが不足しているところも、現行システムJCLを見て、プログラム含めて同じようなものを作ればいいんですよね?」
「それができる人がいないんだ。やってみる?」
「とりあえずやってみます」

当時の私は、MS-DOS時代から*.batは触ってきているので問題なし。大学の学生用計算機環境はUNIXでしたので、*.shも読み書きできました。JCLは業界入ってからこのプロジェクトで見たのがはじめてでしたが、「だいたい、シェルみたいなものなんですね」と理解して、それほど困ることはありませんでした。

Job Control Language – Wikipedia
http://ja.wikipedia.org/wiki/Job_Control_Language

ただ、「それができる人がいないんだ。」という上司の言葉が信じられずにいたので、周囲の人々の知識なりを探ってみました。

ホストをメンテしてきたお客様のシステム部門では、Unixをわかる人がいない。
Unixのシェルについて詳しいとされていたチームメンバーは、「Windowsの*.batがわからない」とか言う。仕事の契約とか責任分界点のせいで、やるわけにはいかないのかと思っていたのだが、どうやら本当にUnixのシェルのことしかわからないらしい。
で、JCLが読めて、Unixのシェルがそこそこ読み書きできて、Windowsの*.batについてわかる人が私しかいなかった。

つまり、チームのなかではいちばん業界キャリアの浅い私が、オープン系のシステムの知識をいちばん(浅く広くの観点では)持っていて、作業の効率化に貢献できた…ということです。
サンプルテストデータ作るのに、Perlや秀丸マクロ使って生成しているだけで驚かれたことに、驚いていました。
(2002年当時は、SIerの現場ではそれほど浸透してになかったんでしょうか?)

この仕事をこなしてから、プロジェクトでの居心地が格段によくなりました。
本当に小さな小さな世界ですが「JCLとUnixシェルとWindowsバッチがわかる専門家」扱いです。んで、「専門家」とされている部分で、質問されたとき答えられないといけないから、より必死に勉強する、と。
また、仕事の量は減ったものの、今までは仮眠時間に割り当てられていた会議で、無責任に発言ができないので、精神的にしんどくなりました。

泥カンと未来サミットとIT業界の現実 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080717/1216274298

「新しいことに挑戦して道を切り開かなければいけない」

ってことですね。レベルはぜんぜん違いますけど。
これをやらないと、10年下の後輩にも、お客さまの期待にも負けちゃいます。

以上、自分の体験から、10年先輩のやりかたよりも新人のやりかたの方が生産性が高いなんてことがありうるこの業界、開発フェーズについては、泥になりづらいのではないでしょうか。

※ SIerの対顧客窓口(営業とかプロマネも含め)については、どちらかというと「泥」でいくしかない世界だと思っています。もうすこし、考えてみたいとは思います。

私が所属する会社の新人研修では、ロジックやらC言語やらやっているはずなんだけど。

低水準言語での研修 – novtan別館
http://d.hatena.ne.jp/NOV1975/20080714/p2

アセンブラ的なものからCPUが、プログラムが、どう動くのかを想像できるようになって欲しい。

最後は生のコンピュータがどのような動きをしているか、想像できるかにかかっているのと思います。
個人的には、テキストとして見えているデータも結局「2進数」の羅列なんだとわかったときに、世界が開けました。生のコンピュータに近い世界を垣間見た瞬間だと思っています。
結局新人の一年間で、社会人になるまで触れたことのなかったバイナリエディタと、すっかりお友達になれました。

開発環境とかミドルウェアいうのは、生のコンピュータをどんどん隠蔽する製品なんだと思います。
隠蔽はなんのためにしているかと言えば、楽をするためにしている。
生のコンピュータと直接格闘し続けるほど効率の悪いことはありません。
楽に開発できるものがあるんだったら、使いましょうよ。
隠蔽されているおかげで、ある程度の生産性が確保されているわけです。
(今時、アセンブラで組もう!なんて思ったら、人手も足りないだろうし)

でも、トラブルの元が、隠蔽されているところにあったときに対応できないなんて、顧客との窓口としてそれでいいのか。
どうして楽ができるのか、意識しなくていいのか。
一定人数は、生のコンピュータと近いところで戦える人が必要なのではないでしょうか。

新人育成のことに話しを向ければ、私がカリキュラム作ったら、『30日でできる! OS自作入門』を組みこみます。

14日目まで到達すれば、コンピュータと格闘する力は、SIerで働くのに必要な力以上に身につけることができると思います。
でも、ただの苦行と思う人の多さが懸念されて、新人研修ではやってくれないんだろうなぁ。