【リマインド】しっかりと読んでおきたい日本の労働環境の実態と未来予測
【リマインド】しっかりと読んでおきたい日本の労働環境の実態と未来予測
拝読しているとあるブログ記事からのリンクで、
という、厚生労働省の統計資料および分析資料の存在を知った。
(厚生労働省)平成26年版労働経済の分析_人材力の最大発揮に向けて
こういった統計に基づく白書・分析資料は、特定の企業や業界や個人の恣意が混入していない、ある意味では最も真実に近い事が書かれている。
無論、単なるデータだけでは読み解けないため、分析結果には特定の思考が入る訳だが、少なくとも国レベルの広い視野に立ったものなので、一定の評価はして良いものだと思う。
ここで注目したい事は、例えば、団塊の世代が７５歳を超えてくる２０２５年までに、どういった職種や業界に人材が不足しているのか、などである。
日本においては、転職という行為はそれだけで高リスクであるという現実
などの資料を読むと、改めて思い知らされる現実として。
日本においては、「最初に就職した職場に定年まで勤める」ということに対して…
自分自身がそうであるという人の割合が非常に高く
またその事を肯定的に捉えている人の割合も非常に高く
その多数派に属していない人々は完全に一部の上流階層と少なくない非正規労働者などの階層とに分断されている
…という事である。
日本においては、転職という行為はそれだけで高リスクであるという現実が資料からは見えてくる。
こういった資料は、しっかりと読んでおきたい。
そして、そう遠くない激震が走る未来に備えたい。
人は『正しさ』ではなく『わかりやすさ』で判断している…という真実…でもそういう人ばかりになったら国は滅亡するだろう…
人は『正しさ』ではなく『わかりやすさ』で判断している…という真実…でもそういう人ばかりになったら国は滅亡するだろう…
職場で、特に若い人たちに向けて、こういう事を言った。
こういう事実は、昔からあった訳だが、その傾向を強めたのは、『失われた20年』であると思っている。
大企業や中央官庁などがどんどん『管理するだけ』の『丸投げ』傾向を加速させる
実作業の『外注化』が進みノウハウの『空洞化』が進む
一方でコンプライアンスやガバナンスは重視されるため細かい事でも責任者の『許可』が必要となる
しかし責任者は専門的な事はまるでわからないし、その部下さえもわからない
詳細で専門的な資料や記録は使えなくなり、説明用の『正確ではない』が『わかりやすい』資料が幅をきかせるようになる
一見良い事のようにも思えるが、実際には分断化を促進しているだけ
今日の表題を図にするなら下記のようになる。
これは確かに世の中のひとつの真実ではある。
……が、全ての人間が『正しさ』ではなく『わかりやすさ』を基準に判断するようになってしまったなら、世の中は回らなくなる。
誰かは『正しさ』を見ている。
だからこそ、世の中は回っている。
『わかりやすさ』をもとめているのが管理者側、『正しさ』を"見てくれている"のは管理される実作業者
これまでは実作業者たちの"真面目さ"、"善意"といったものに頼ってきた。
あるいは『注意義務違反』という曖昧で便利な言葉で『何か問題が生じたらお前が責任を取れ』という脅しに頼ってきた。
そろそろ、それは限界ではないだろうか。
日本における基礎研究の論文の数が少なくなっており、それを危惧する声がある。
そういう事にも繋がる事である。
本当にこの国は滅亡に向かっているように思える。
IT業界の実態と属人化のメリット(良い点)をあえて考えてみる
IT業界の実態と属人化のメリットをあえて考えてみる
誤解しないで欲しいのは、私が『属人化』を賛美するつもりは、決してないという事である。
私は、現場仕事も、システム開発の現場実態も、何も経験したことがないくせに、したり顔で「属人化は悪だ」、「属人化は排除しなければ社員が不幸になる」と、言っている管理者や経営者が、あまりにも多くいる事が、許せないだけだ。
役員の椅子に座って現場を知らないアナタ。
絶対、わかって言ってないだろう。
どんな事柄にも、良い点と、悪い点があるものだ。
どんな事柄にも、だ。
IT業界の実態の例としてある企業の業務システムのトラブル対応を考えてみる
上図に示したように、ある企業の業務システムにおいて、夜間バッチ処理が、予期せぬDB障害で異常終了してしまった。
夜間はシステムの内容は何も知らない運用部門（しかも派遣で集めた人員）しかおらず、連絡を受けた担当SEも何も判断できず…
「バッチ処理はそのまま停止したままにして、DB環境についてはサーバーのセットダウン・アップによる再起動で様子を見る。詳細な対応はSEメンバーが出社する翌朝以降に対応する」
…という、最低限の措置を取った。
よくありそうな話である。
手を動かさないステークホルダー(例えば顧客とか)が多いと現場はコミュニケーションに忙殺され回らなくなる
夜間のうちに連絡が取れたSEメンバーの何名かは、朝8時前には出社して、情報収集から始める。
上図にも示したが、運用開始以降、十数年間、一度も発生した事がない場所だった。
そもそも、そのサブシステムについて、何をしているシステムなのか、どういう処理をしているのか、といった基本的な事を、ほとんどのメンバーが知らなかった。
かねてからの人員削減の波や、現場を無視した人事ローテーション等によって、そういった既存システムに関する知識を持った人は年々居なくなって行くのである。
システム保守チームのリーダーは、それでも発生した状況を整理し、他のシステムや、何より"顧客の業務影響"を"早急に"把握して、顧客に伝えなければならない。
こういう状況では、各処理ごとに存在するシステムの設計書などは、あまり役には立たない。
もっと全体像を捉えなければならないからである。
DB障害はすぐには原因はわからないが、再起動で問題なく動作している事は確認できた。
DBから返されたメッセージを見ると、いきなりDBサーバープロセスがダウンしてしまったようだった。
ひとまず、DB障害の原因追究は、DBインフラの部隊に後でログを送付して、必要ならばメーカーにも送付してもらっての対応となるだろう。
取り急ぎでは、AP側のバッチ処理の復旧が優先となる。
朝イチの電話で、顧客側の担当者に、リーダーから昨夜からの状況を伝える。
「DBのプロセスが落ちた」と言っても、まったくの素人である顧客にはなかなか伝わらない。
「データやAP側の問題ではない」という事を強調し、まずはリカバリを急ぐ事になった。
そこに、たった一名ではあったが、このサブシステムを十数年前に開発した時、メンバーとして関わった事があるAさんが出社した。
Aさんがトラブル対応に首をつっこみ、「ここの処理からバッチ処理を昨夜時間として流し直せばうまくいくはずだ」という見解と、そもそも「ここの処理が何をしているか」、「業務にどのような影響があるのか」を、ざっくりではあったが、リーダーに伝えられた。
開発から十数年も経過しているため、詳細な部分までは記憶が定かではなかったり、そもそも、彼が知らないうちに保守改良等で仕様が変更されている可能性はあった。
だが、大まかでも「何をしているシステムか」、「どんな業務影響がありえるのか」を、把握できる事は大きい。
詳細な部分は、それこそピンポイントで設計書やプログラムを調べれば良い事なのである。
上記のような点を、ひとまず文書としてまとめて、顧客側や運用部隊などのステークホルダー（関係者）に伝える必要があった。
しかし、リーダーの電話は鳴りっぱなしである。
障害が発生したシステムの顧客部門の担当者はもちろんだが、データ連携先の顧客部門が、非常にうるさい。
「バッチ処理を再処理すると言うが、それで上手く行く『保証』はあるのか」
…などと言っている。
今回はインフラ障害（DB障害）なのだ。
これまで十数年間も落ちたことがない場所で、プログラムの入れ替えもしていない。
状況からは、「データやAP側」が原因である可能性は低い。
なので、DBが正常に動いているのなら、再処理で上手く行く可能性が高い。
…といった、常識的な事が顧客側担当者には、なかなか伝わらない。…というか、顧客側も担当者が納得できないのではなく、後ろでその上司がギャーギャー言っているのだろう。
ステークホルダーへの状況説明のメールは、けっきょく、リーダーではなく、Aさんが直接書くことになった。
リーダーは、いろいろな作業をするメンバーへの指示や、ステークホルダーからの連絡対応に忙殺されてしまい、とてもAさんから情報を聞き取って理解し、それを文書化する、という行為は不可能だった。
連携先のシステムは特定の時間に起動されるようになっていて、相手側との調整もいろいろ必要となったが、初動が比較的早かったため、トラブルの拡大は防ぐことができた。
ここにAさんが居た場合と居なかった場合とを考えてみる
「ここに現行システムを知っているAさんが居るのがいけない」
経営者たちはしたり顔で言うだろう。
彼のような者が居るから、こうしたトラブル時にも、彼に仕事が振られ、けっきょく、ますます属人化が進行してしまう、と。
彼のような者が居なければ、イヤでも知識を持たないメンバーが、現存するドキュメントやプログラムなどを調べるなどして、何とか対応し、結果として、知識が拡散される、と。
その考え方は、まったく現場のメンバーの苦労をわかっていない。
自分が何も知らない、昔の誰かが開発したシステムについて、顧客側からは「君たちはシステム屋なんだから知っていて当たり前だろう」と言う目で見られながら、トラブル対応というような『時間に追われる』作業を強いられる。
これが、どれほどの強大なストレス源となるか。
それが、まったくわかっていない。
まぁ、こうした仕事が、システム保守というものではあるのだが、こういう状況ばかりが続くと、本当に心が折れる。
こういう無茶振りの仕事にも、向き不向きがあるので、どんなに均等に割り振ろうとしても無理が出る。
そうなると、小さな属人化が発生し始める。
そして、属人化の負のスパイラルが発生して、知識を途中まで溜め込んだメンバーが辞めてしまったりする。
そして、更にわかっていない事は、ドキュメントやプログラムを調べれば、有識者よりも時間はかかるだろうが、同じような成果を出せるはず、という幻想だ。
ここで、管理者や経営者が想定する「時間はかかるだろう」というのは、せいぜい１日～２日だ。
違う。まるでわかっていない。
上記の、Aさんがリーダーに示したような見解を、知らないメンバーがドキュメントやプログラムから導き出すには、何週間も、もしかすると何ヶ月もかかる。
「障害が発生してしまいましたが、開発したときの有識者は既に離散しておりまして、申し訳ありませんが、復旧（解決とまでは言っていない）には１ヶ月のお時間が必要です」
このように顧客に言って良いというならば、そうしようではないか。
これが言える管理者や経営者が居るのか？ …ということである。
仮に。
仮にそう言えたとしても。
何週間も、何ヶ月もの間、トラブル対応という異常な仕事をやり続ける事は、どんな人間にも無理なのだ。
絶対に心身ともに壊れてしまう。
大切なことは、如何にして、「属人化の負のスパラル」を最小限に抑えるか、である。
そして、トラブル対応などといった、属人的な知識が必要、かつ、活用される場では、思いっきり属人化された知識を活かすのだ。
そういった対応の中で、属人化したメンバーに、ある程度機転の効く若手をつけるなど、育成面での工夫はどんどん行うべきだ。
IT業界の実態と業務に深く潜るべきか否かの様々な見方
IT業界の実態と業務に深く潜るべきか否かの様々な見方
このブログをお読みいただいている方には、多少なりとも私の考え方の傾向をつかんでおられると思う。
私は、過去の記事で何度か言ってきたように、純粋に「IT汎用スキル」だけで勝負しようとすると、いまのIT業界は、本当に技術者へのリスペクトがなく、技術者を消耗品のように扱うため、結果として『過当競争』に追い込む。
それから逃れるには、「IT汎用スキル」"だけ"で勝負するのではなく、特定分野の「業務やシステム固有の知識」"も"併せて保持して行くことで、希少価値を高める事が重要であると考えている。
しかし、無論の事、同じ事を、まったく異なる側面から見ることもできる。最近、それをとても強く感じた記事を拝読したので、ここに紹介したい。
新人SEが同じ場所で常駐を続けると蝉になる
上記の記事に対して、私は下記のようなブックマークコメントを付けた。
全く別の見方をすれば、様々な現場をホッパーし続け汎用ITスキルのみでの『過当競争』で安く買い叩かれるという例もある。サイロ化するならしたでそこの知識を誰にも負けないくらいにしてユーザ側に移籍する例もある / “新人SEが同じ場所…” https://t.co/CgkkuSX1sx
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2017年8月3日
この、紹介した記事内容自体には、特に反論の要素はない。確かにそうだな、と思った。
現に、私の観測範囲でも、新卒一年目から20年以上も、客先常駐で派遣されてきて、自社よりも客先での人間関係の方が広く深くなり、それこそ客先SEリーダーなどから「うちに移籍すれば良いのに」と言われることも多かったものの、様々な事情があって、いまでもそのユーザー企業のシステム再開発の有識者として、常駐型で働いているという人を知っている。
（この方は、会社は違えども新卒年度が私と一緒だったので、いろいろと共に成長してきたという思いはある）
また別の方は、長く独立系ITベンダー側の技術者として、時には常駐したり、時には請負先リーダーをやったりしていたが、ユーザー系の元請IT企業に移籍された。それも実例として知っている。
IT業界の実態を図にしてみた
IT業界の実態を、簡単な図にしてみた。普通は上にユーザー企業があって、下に下請けベンダーがあるような、ピラミッド型で表現されることが多いが、上下関係みたいで嫌なので、関係を横にしてみた。
この図を見ていただければわかると思うが、何だかんだと言っても、いちばんの問題は、この図の中間部分に居座っている会社の存在なのである。
上の例で言うならば、GHシステムの人間が、GHシステムの人間として元請けから発注を受けるとか、もしくは、容易に元請企業に転籍できるとか、そういう構造になっていない点が、まずもって問題である。
もちろん、これは、上記の紹介記事で言われる「サイロ化」されたユーザー側に近寄る方向なので、これが全て良いわけではない。
しかし、「サイロ化」の現場に入ることが、なぜ危険と言われるか。それは、「サイロ化」自体の問題ではなく、発注元（上記の図で言うと中間に位置している企業や、元請け企業）の都合で「いつでも切られる状態に置かれたまま」であることが、最も技術者を不幸にしている訳である。
技術者をリスペクトしない国、日本
バブル崩壊から20数年。
日本はすっかり、技術者（エンジニア）をリスペクトしない国と化してしまった。
本当に先進国から後進国に、どんどん下へ下へと向かっているのだと思う。
（関連過去記事）
汎用機(メインフレーム)とCOBOLのシステムが使われ続ける理由
汎用機(メインフレーム)とCOBOLのシステムが使われ続ける理由
以下のようなニュースが目に止まった。
特にIBMに愛着がある訳ではないが、コンピュータの世界も、ダイバーシティ（多様性）という事で、汎用機（メインフレーム）文明が衰退してしまうのは個人的には避けて欲しい。
いまや、Webサーバーを中心としたサーバー分野においては、多くの商用UNIXがLinux系に置き替えられている。DBサーバーなどのバックエンド側は企業などの秘密領域なので確かな情報はないが、Linux系が浸透しているのは確実だろう。
しかし、DBやバッチ処理用のバックエンド環境を中心に、いまだに汎用機（メインフレーム）環境は使われ続けている。
よく言われるのが、1970年代くらいから積極的に業務をIT化してきた中央官庁や大企業の基幹系業務システム。とりわけ、銀行などの金融業界では、汎用機（メインフレーム）環境は根強い人気がある。
考えられる理由は以下の通りである。
＜理由＞
1970年代～1990年代にかけて開発され、現在も稼働しているCOBOL系業務プログラムが膨大にある。おそらく都市銀行1行につき数千万行はいまだに存在する
COBOLコンパイラー、汎用機OS、専用ハードウェアの組み合わせにおいて、I/O最適化、メモリ内命令最適化が行われ、高速／高並列処理が可能である。特にバッチ処理でその能力を発揮する（UNIX系とJavaVMの処理系ではなかなか勝てない部分）
二進化十進法（BCD,Binary Coded Decimal）と、COBOL独特のデータ表現（ゾーン10進、パック10進）、COBOLの仮想小数点データ定義法により、『誤差がない』固定小数点の大桁数計算が可能である
固定小数点の大桁数計算については、Javaにも「BigDecimal」という型が存在する事が知られているが、Javaのお作法では、いちいち「new」によってオブジェクト化する事になる。
COBOLは、高級言語である割には、データに対しては低レベルでのアクセスを強要する言語である。C言語のようにビット単位での処理は不得意だが、バイト単位以上ならばC言語並みに低レベルなアクセスが可能であり、むしろそれを強要する。
入出力データの抽象化ができず、常に物理的なバイトイメージをプログラマーが持っていないと誤った処理を書いてしまう。（エンディアンの違いも意識しないといけない）
データの扱いもきわめて物理的で、JavaよりもC言語に近い。
それでいて、入出力データ内の「文字としての数字」は、意識的に「ASCII to BINARY変換」をしなくても計算に使用できる。
汎用機とCOBOLのシステムの大多数は今後も稼働し続けるだろう
汎用機（メインフレーム）環境の話であるはずが、COBOLの話になってしまった。
しかし、それくらい、両者には密接な関係がある。
世の中のシステムにオープン化の波が来た頃から、「COBOLはなくなる」と言われ続けて、30年近くが経過しているが、いまだにCOBOLの新たなプログラム資産は増加している。
（そしてCOBOLという言語が登場してからは既に60年近く経過しようとしている。OS誕生よりも前からある言語である）
金融機関などの大型システムにおいても、Javaで組み直すプロジェクトが発生したりして話題になっているが、全体的には、いまCOBOLで作られている領域を、まったく異なるプラットフォームと言語で置き換えるような事は、進まないだろう。そこまでのコストを投入するだけのメリットが出ないからである。
開発言語などにこだわるよりも、OSやDBのしくみなどのプラットフォーム系を勉強する方が、いろいろ応用がきく。
COBOLプログラマーは業界ではいろいろとバカにされるが、気にすることはない。
COBOLの学習コストが低いのは事実である。他の言語をひとつでも経験したことがあれば、まず短期間のうちに理解できるだろう。
それに、言語仕様よりも、むしろプラットフォーム系の理解の方が大変であり、重要である。（こういう事を言うと反論者が一定数居るのだが…）
COBOLプログラマーは単なるプログラマーとしてではなく、業務要件からの理解を求められるエンジニアの場合が多い。
業務面から、システムのデータ面までを熟知している技術者は少ないので、特にユーザー側の官僚化が進行した現代では、ますます重要性は増すかもしれない。
ただし、いわゆる？悪い意味での「staticおじさん」にはならないように気をつける必要はあるだろう。
関連過去記事
少し古い記事ですが、二進化十進法（BCD,Binary Coded Decimal）などの、データ表現についての解説記事
コンピュータにおける「データ表現」の基礎（第3回） | 日経 xTECH（クロステック）
コンピュータにおける「データ表現」の基礎---目次 | 日経 xTECH（クロステック）
『属人化は悪だ』としたり顔で言っている経営者への伝言
『属人化は悪だ』としたり顔で言っている経営者への伝言
まず、属人化は悪だ、属人化はなくさなければならない、と、『自らのシステム開発現場での経験を基にして』、主張しているのであれば、何も反論はしない。その通りだと同意しよう。
しかし、私が思うに、特に大企業や大手クラスのIT企業の、ほとんどの経営者たちは、『自らの経験から』は、言っていない。
何故ならば、もともとはシステム開発とは異なる畑が出身の人たちばかりだからだ。
『属人化は悪である』という事は、本で読んだか、近しい部下や後輩から植え付けられた知識にすぎない。自らの経験から産まれた経験知ではないのであれば、それは役には立つまい。
『属人化が理想の姿ではない事』は言われなくてもわかっている
属人化が理想の姿ではない事は、この業界の中に居る者は誰でもわかっている。リーダーやマネージャーを経験したことがあるなら、なおさら、それはわかっている。
私の短い社会人経験からだけで言っても、20年は前から言われてきた事なのだ。
つまり、改めて言われるまでもなく、属人化が理想とは異なる事は、皆わかっている。
それなのに、である。
経営者からの問題提起として、
属人化の排除
人事ローテーションの促進
などと言われると、本当に、がっかりする。
あなた方には見えていないのだろうか？
いま、多くのユーザー企業、特に大企業において発生している、『属人化』よりもはるかにおそろしい事態を。
『属人化』よりもはるかにおそろしい事態『空洞化』が進行している
おそろしい事態。
それは、『空洞化』だ。
大企業の本社側の人間が官僚化し、『定期人事異動』によって、コロコロと入れ替わる。
そこには、もはや、ノウハウを蓄積するという機能は完全に失われている。人事異動のたびにその部署に蓄えられつつあった知識は消え失せる。"リセット"だ。
そのような状態でも業務が回っているのは、優れた仕組みやルールがあるからではない。
単に、実作業のほとんどを現場側や委託先企業に、『丸投げ』しているからだ。
『空洞化』に至ればもはや回復はない
一度、『空洞化』状態に陥ってしまったなら、その状態から自力での回復はない。
ドキュメント化を高める事自体は良い事だろう。しかし、それでも、『ドキュメントを探し出す能力』や『ドキュメントを読み解く能力』は、絶対に必要なのだ。
素人をいきなり連れてきてどうにかなるような甘い世界であるはずがない。
現場側や委託先の誰かが『属人化』状態であってでも、知識を持っていてくれるならまだ良い。
そうした人が知識とともに他に移ってしまい、永久にノウハウが失われるという最悪の事態が、現場では発生しているのだ。
理想ではないが『属人化』から少しずつでも"継承"をして有識者を増やすのが善策
『属人化』が問題視されるのは、その人数が少ないからだ。
一人しか居ない。それが問題なのだ。
ならば、一人を二人に、二人を四人に増やせば良いのだ。
知識・ノウハウを"継承"して行く活動しかない。早道などはないのだ。
それを地道にやろうとしている現場のマネージャーやリーダーを無視して、下手に人事ローテーションなどやってみろ。
全てが台無しになる。
だから、付け焼き刃の知識だけで、『属人化は悪だ』などとしたり顔で言うな。
“人を『人財』であると思い、大切に扱う。”
あなた達が、まだ現場で"課長"や"部長"などの管理職であった20数年前。
人を『交換可能な部品』として扱い始めた事で、『失われた20年』が始まってしまったのだ。
それを自覚し、反省し、単なる浅い知識だけで、『属人化は悪だ』などとしたり顔で言うな。
バブル崩壊は1991年から始まった……就職氷河期世代(日本版ロスト・ジェネレーション)は忘れない
バブル崩壊は1991年から始まった……就職氷河期世代(日本版ロスト・ジェネレーション)は忘れない
今回の記事は、記事というよりも記事の紹介。リンクの覚書のようなものに終始している事をお断りしておく。
最近、唐突に気付いたのだが、「バブル崩壊」「就職氷河期世代」「失われた10年」「失われた20年」「ロスト・ジェネレーション」などと言っても、今の20代の若手には通じない用語になっている。
私の認識では、バブル崩壊は1991年頃である。そしてその影響が就職戦線に一気に来たのは、1993年新卒の世代からである。
考えてみれば、もう25年も昔のことなのだ。今の新人が生まれる前ではないか。
しかし、今日の読売新聞の社会保障(26面)には、下記のようなタイトルの記事が並んでいる。
「いまさら何を言っているんだ」と言いたくなる記事ではあるが、これが全国紙の真面目な社会保障面の記事なのである。
1993年に20歳前後だった世代は、いまでは45歳前後になっている。
1993年時に高校卒業で社会に出た人は、43歳くらい。
1993年時に短大・専門学校卒業で社会に出た人は、45歳くらい。
1993年時に大学卒業で社会に出た人は、47歳くらい。
いま、いわゆる「ひきこもり」や「ニート」の高齢化が問題視されながらも、「39歳以下しか対象としてみなさない」というバカみたいな行政側のずさんな実態調査もあって、いまだにその深刻度が正確には把握されずにいる。
それがまさにいまの40代であり、25年前の「バブル崩壊」時期に社会に出てきた「就職氷河期世代」の先頭世代なのである。
下記の記事でも書いたが、バブル崩壊前までの20年間は、経済成長時代であるにも関わらず、大学進学率は30パーセントに届かない（20パーセント台）で、大きな変化はなかった。
それが、バブル崩壊後の大不況時に、一気に上昇に転じた。だが、それは、それまで言われてきた『一億総中流社会』を破壊する、『格差社会』への扉のひとつだった。
恨みも込めて記憶しておきたい作られた時代
戦後のベビーブーム時に生まれた、「第一次ベビーブーム世代」は、いわゆる「団塊の世代」である。この世代は「逃げ切り世代」と揶揄されている。まともな公的年金などの社会保障をギリギリ受け取ることができる最後の世代だと思われるからである。
今から10年位前、団塊の世代の一斉退職によって「2007年問題」が発生すると言われた。しかし、結果としては、この世代の多くはいまだに影響力のある職場に残っていたり、業務のIT化などの影響でそれほど大きなインパクトにはならなかった。
そう。多くの企業のトップや中小企業の創業者などは、いまだに後継せずに、現役でいる。従って、本当に問題が表面化するのは、おそらく団塊の世代が全て75歳以上になるであろう、2025年くらいなのである。
日本の経済成長時代は、上記の団塊の世代と、その後続の世代によって、良きにしろ悪しきにしろ、形成されたのだろう。
一方で、「第二次ベビーブーム世代」という世代も存在する。これが、ちょうど「就職氷河期世代」の先頭世代と同じなのである。
人数が多いという事は、それだけ政治的な発言力もあると思われるが、「第一次ベビーブーマー」向けには様々な制度が味方をしたが、「第二次ベビーブーマー」向けにはその反対の事が起こった。
1990年代からの「失われた20年」は、特定の世代を特に犠牲にした、作られた時代であったのではないだろうか。恨みも込めて記憶しておきたい。
ダイヤモンド書籍オンライン 今知っておきたい、90年代のバブル崩壊物語 3分で学びなおす日本経済史 第4回 株価暴落から山一・拓銀・長銀の破綻まで （著：蔭山克秀）
いま政府が画策している「残業代ゼロ法案」が施行されると本当に日本は先進国ではなくなるだろう
最後に、「残業代ゼロ法案」に関係する記事を紹介する。
世代論とは少し方向性が異なるように見えるが、実はそうではない。
「労働者派遣法」がどんどん規制緩和の方向に進んで、いつの間にか「派遣社員」が、昔の「高度な技能を提供してくれるお客さま」ではなく、「単なる雇用の調整弁」として扱われるようになったのと同じように、「残業代」という労働時間のブレーキを「規制緩和」しようとされている。
「成果型労働」「成果で評価する」という誤報が止まらない 佐々木亮 弁護士・ブラック企業被害対策弁護団代表
この「残業代ゼロ法案」が施行されると本当に日本は先進国ではなくなるだろう。
「アウトプット」の重要性と「生徒でいるうちは先生を超えられない」説
「アウトプット」の重要性と「生徒でいるうちは先生を超えられない」説
「アウトプットする趣味」は大切にした方がいい。ゲームや動画鑑賞、さらには読書もそうだけど、インプットするだけの趣味はほどほどに。インプットしたらそれをアウトプットする趣味も欲しい。そして、アウトプットする趣味は、忙しいからといってないがしろにしてはいけない。
— ひらめきメモ (@shh7) 2017年7月16日
これ、本当にそう思う。
理由は「脳の記憶のメカニズム」と関係がある。
誰かに教えられたり、何かを読んで勉強する時点では、その情報や知識は、まだ「自分の知識」として脳に定着していない。
一方で、誰かに自ら教えたり、文書として自分なりにまとめたり（ブログでも良い）する時点で、はじめて「自分の知識」として脳に定着するのである。
生徒は先生よりも上手くはならない説
これは、前述の理論で説明がつく。
最近、拝読した記事の中に、下記のような言葉があった。
「バイトや仕事よりもブログで稼ぐ」ことを学生や若者が主張するようになったのは、「絶望」のせいかもしれない。 - いつか電池がきれるまで
僕は、若者がキラキラとした自分の夢を語ってサロンに集客するようなブログは、基本的に「お金に困っている人から、『こうすれば稼げますよ』と教えるという名目でさらに小銭を巻き上げる『貧困ビジネス』」だと思っています。
人にものを教わるときに気をつけたいのは、ほとんどの場合、生徒は先生より上手くはならない、ということなんですよね。
だから、教えてもらうのだとしたら、「教えたがっている人」にではなく、「自分もこうなりたいと思える人」に付いたほうがいい。
大部分の「ブログ指南」をしている人たちと、その信者たちをみると「えっ？こんな現時点ですでに救いようのないブログの劣化コピーをつくってどうするの？」って思うよ。
これも、本当にそう思う。
この記事全体の主旨についての言及は避けるが、上記の引用の中の、「生徒は先生より上手くはならない」の部分は、本当にそうだと思う。
ブログを書くことの意義もある
上記のような事を踏まえると、ブログを書くという行為にも、意義が見いだせるのではないだろうか。
そんなことを思う次第。
2TBプラッタのハードディスクドライブ(HDD)が主流になりつつあるのか(SSDはいまだに信用できない件)
2TBプラッタのハードディスクドライブ(HDD)が主流になりつつあるのか(SSDはいまだに信用できない件)
プラッタというのは、磁気ディスクの円盤の事である。私の認識では、両面が主流になったり片面が主流になったり（物理的なサーボ情報の記録の方式がいろいろあった）したが、近年は、両面記録方式が主流だと思う。
1枚2面の磁気ディスクを、1枚のプラッタと呼び、両面に、その先端に磁気ヘッドが付いたアーム（アクチュエーター）がある。
アクチュエーターは、1秒間に約100回程度の速度で動くことができる。これは非常に高速に思えるかもしれないが、コンピュータの処理の中では『きわめて低速』な動作である。
このアクチュエーターが動いて、磁気ディスクの目的のトラックまで移動する時間の事を『シーク時間』という。
シークした後、目的の読み取り位置（セクター）に磁気ディスク自体が回転してくるまでの待ち時間の事を『回転待ち時間』という。
この電子的ではない、機械的な動作こそが、ハードディスクドライブ(HDD)の、速度面でのボトルネックであり、また最も故障しやすい部分でもある。
「2TBプラッタ」という事は、1枚2面の記録容量が2TB (2000GB) という事である。
つい最近までは、「1.33TB」「1TB」クラスのプラッタが主流だと思っていたのだが、HDDの世界も容量がどんどん増加しているという事のようである。
弊職場の自席には未だに10年以上前の Core 2 Duo クラスの HDD容量が100GB少々というPCが存在し稼働中である
たぶん、普通のIT企業にはありえない光景だとは思うが、弊職場の自席には未だに10年以上前の Core 2 Duo クラスの HDD容量が100GB少々というPCが存在し稼働中である。
無論、メイン機としては使っていないが、TeraTerm端末としてならば、よく使う。
昨年の夏まで、約3年もの期間、休職して職場を離れてしまっていた訳であるが、休む前に使っていたPCを、そのまま使用しているのである。
流石にバッテリーは消耗しきってしまい機能しない。しかし、HDDは未だに使用に耐えている。かなり乱暴に使っているつもりではあるのだが…。
10年以上も前から使っているので、その当時にローカルHDDに保存したファイルなどが、いまだに読み出せる。
なんでも2020年にはHDDよりもSSDの方が多くなるらしいけど
SSD(Solid State Drive：ソリッド・ステート・ドライブ)が、一般的に使用されるようになって久しい。
しかし、ウチの職場では、皆古いPCを使い倒しているためか、まったく一般的になっていない。
先日、自宅のPCを交換したときにも、SSDにする気にはならなかった。
高いという点も確かにある。しかし、いちばんの理由は、いまだに長期間のデータ保存の実績がない、という点が大きい。
SSDとは、原理的にはUSBメモリーと同様の、「フラッシュメモリーストレージ」である。
フラッシュメモリーのうち、BIOSやファームウェアに使用されている「NOR」型ではなく、書き込み速度が高速化でき、集積度が上げられる「NAND」型がSSDには使用される。
フラッシュメモリーの良い点は、もう広く知れ渡っているのでここには記載しないが、やはり気になるのは、悪い点の方である。
既にデータが書き込まれている領域を直接書き換える事ができない（Trimコマンドで対応）
まったくアクセス（通電）しない状態で放置すると、いつの間にかデータが「蒸発」してしまう
温度や湿度などといった使用環境にも左右されるが、フラッシュメモリーには、上記のような、仕組み上の欠点が存在する。
特に「寿命」と「データの蒸発」という問題は、技術的なパラダイム変化が欲しいようなレベルの問題だと思う。
ちなみに、某メーカーの資料によると、SSDの種類（SLC,MLC,TLC）ごとの寿命とデータ書き込み回数は以下の通り。
また、TLCでは、置かれている環境にもよるようだが、まったくアクセスしない状態で放置すると、約6ヶ月くらいでデータが消えてしまう可能性があるらしい。
SSDに関しては、もう少し長期利用した場合の実績データを集めたいところである。
派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要（Oracleの読み取り一貫性に関して思う事）
派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要（Oracleの読み取り一貫性に関して思う事）
職場内向けの資料なのでここには上げられないが、今日は少し思うところがあって、創設20年を迎えているオラクルマスター試験の変遷や、データベース・ソフトウェアとしての Oracle Database について、自分なりに考えた。
まぁ、現在においては、世界で最も利用されているDBMSは、OSSのMySQLであるという事実はある。（それもOracle社が持ってしまっているが）
しかし、ことにエンタープライズ分野の、特に大規模システムでは、Oracle Real Application Clusters(Oracle RAC) 等で可用性に優れているオラクルDBが、あいかわらず強い。
「同時実行制御」のほんのわずかな違い（リード：先行分野）が明暗を分けた
1992年（平成4年）に公開された「Oracle 7」において、「分散トランザクション」「パラレルクエリー」「データベーストリガー」といった、大規模OLTPシステムには欠かせない基本機能を、Oracle は持っていた。
そして「同時実行制御」の考え方において、IBMのDB2のような「ロック」による解決を行わなかった。
「読み取り一貫性」を当初から導入していたのである。
これがオラクルの生命線だった。
あるトランザクションが終わるまで、そのトランザクションが更新しているレコードは、他のトランザクションからは「一貫して」"更新前"として見える事を保証する。
これが、「読み取り一貫性」である。
オラクルを普段から使用している人にとっては、「何を当たり前な事を」と思うだろう。そう。オラクルでは、これが「当たり前」なのであった。
更新する前にUNDO表領域（昔風に言うとロールバックセグメント）にレコードデータを退避して、それを他のトランザクションには見せる。
このことから、単なる読み込みであれば、ロックという概念すら必要はない。
これが、例えば同じように大規模システム向けのIBM DB2 だと、話は違ってくる。
更新するレコードは「ロック」することで書き込みも読み込みも矛盾を起こさないようにする。
非常に単純な仕様で、明解ではある。
単純で明解ではあったが、「同時実行性」の面で、オラクルに少しだけ先行（リード）を許した。
だが、それが致命的な差になってしまうのである。
「読み取り一貫性」はいまで言う「イノベーション」だったのか
「読み取り一貫性」はいまで言う「イノベーション」だったのかというと、そこまで大げさな機能ではなかったはずである。
「同時実行性」を、少しだけ向上させるための、ひとつの「工夫」にすぎなかったのだろう。
同じ「工夫」を、2017年である現在やったとしても、誰も見向きもしない事だろう。
1980年代～1990年代初頭という、RDBの黎明期にやったからこそ、ものすごい大きな「差」となっている。
技術とは、得てしてこういうものなのだなぁ…。
技術の不変性・普遍性について …そしてこれからの日本について
技術の不変性・普遍性について …そしてこれからの日本について
誤解のないように言っておくと、良くネットなどで目にする『この分野を極めていれば一生安泰だ』とか『この資格を持っていればお金に困らない』とか、そんな事は、もはや幻想だ。
そんな事はない。うそだ。
ありえない。
最近、話題となった下記の記事にもあるように、もはや日本は先進国家ではないのだ。
www.from-estonia-with-love.net
少子高齢化が世界で最も速く進み、年金だけで生活する事など、大多数の人はできなくなるだろう。
つまり、生涯現役で労働しないと生きて行けない社会になろうとしているのだ。
まだ社会制度がその現実についてきていないのだが……。
IT業界における技術の不変性・普遍性について
前項で述べたことを肝に銘じて、お読みいただきたい。
決して、『これだけやっていれば』などという甘い世界は、既に存在しない。
それでも、技術の不変性・普遍性については、下図のような傾向はあると思われる。
これも誤解のないように言っておくと、右方向のデータリソースに近づく方向の中には、単なる『IT汎用スキル』としてのデータベース知識だけではなく、その中に格納される、具体的な業務データそのものの知識や、それらを適正にデータモデリングする知識が含まれてくる。
つまり、「純IT技術としてのDB知識にだけ興味を持ち、ユーザー側の業務知識やデータ知識などに興味はない」などという姿勢では、通用しないという事である。
業務システム系とWeb系とでは、カルチャーが異なる部分も多いようであるが、Web系では既に『技術の早期陳腐化』『過当競争』が発生している。
（関連過去記事）
なお、あいかわらず不人気でかわいそうなCOBOLであるが、私の観測範囲では、まだまだ全然、現役で稼働中である。（新規開発もある）
日本のこれからについて
経済産業省あたりでは、東京オリンピックが開催される2020年までに、セキュリティ人材を含むIT人材が数十万人も不足する、などと言っている。
私はそれに対しては、少し疑問を持っている。セキュリティ人材は確かに必要だろうが、セキュリティ特化型の人材だけが増加しても、たぶんダメなのだ。
セキュリティというものは、それだけで何かを生み出す性質のものではない。あくまでもITインフラを支えるひとつの領域なのであり、それ単体で語られるものではないと思う。
「セキュリティだけ」とか、「IT汎用スキルだけ」とか、そういった特化型の人材は、よほど先鋭的でズバ抜けたモノを持っていなければ、淘汰されて行くのではないだろうか。
私は、IT系よりも、もっと人材が不足しそうな領域に心当たりがある。
『電気』『設備管理』などといった、インフラ系の分野である。
日本は、急速に少子高齢化が進み、そうなるとこれまで都市部にニョキニョキと建てられてきたマンションやビル、商業施設などが、一気に空家問題に突き当たるのである。
これらの建物や設備の管理をする人材が、圧倒的に不足することだろう。
私はいまでも、東京オリンピック開催には反対である。
日本には、既にそのようなお祭り騒ぎをしている余裕はない。
オリンピックに1兆円を費やすのならば、それを就職氷河期世代や、現在の非正規労働者たちの雇用問題に投入したほうが、よほど日本は延命されるだろうと思っている。
…まぁ、そういう訳で、私もオラクルマスターの勉強とか、電気関係の勉強とか、進めていかないとなぁ…。
悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
IT業界、ソフトウェア開発業界において、古典的な名著がある。
IBMが世界で覇権を握ったメインフレームシステムとそのオペレーティングシステム、OS/360を開発した、フレデリック・ブルックスという人が書いた、『人月の神話』である。
日本では、初版が1977年に出版されている。
以降、40年間にも亘って、「ソフトウェア工学のバイブル」と呼ばれている。
この呼ばれ方には、「誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである」という皮肉も含まれているようである。
『ブルックスの法則』として、最も有名な言葉は、おそらく下記の言葉であろう。
遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
私は昨年、現職に復帰する前には、三年間もの間、心身の不調により休職してしまっていた。
その休職する直前に関わっていた顧客側の責任者（権限者）が、とにかく暴君であった。
システム開発者側として、きわめて現実的で、かつ、それでも最短期間で完了させるスケジュールを提出した時、たびたび「なんでこんなに期間がかかるんだ！」と騒がれた。
その部下である顧客側の担当者は上司の言いなりなので、話にならない。
仕方なく、無理のあるスケジュールで進める事になる。
しかし、それでも結局は、顧客側の仕様調整が甘かったりして、手戻りが発生し、当初に私が提示したスケジュールと同じか、それよりも遅く進行する事が常であった。
パッケージを導入し、業務もそれに合わせるような割り切りをするならまだしも、基幹系業務システムの開発などにおいて、「短納期化」なんていうものは、ただ単にやるべき作業を省くだけであり、後工程にツケが回って、結局は余計に期間がかかるだけで終わってしまうのである。
悪いスケジュールの引き方、良いスケジュールの引き方 その例
ここでは敢えて、「悪いスケジュールの引き方」と、「普通のスケジュールの引き方」と言い換えよう。
下の2つのスケジュールを観て欲しい。
ある程度のシステム開発プロジェクトを経験すると、皆、わかることだと思うが、実際には、モノを作ったり書いたりしている時間に比較して、検討したり情報共有したりレビューしたり、といった対人コミュニケーションの方にも、同程度、もしくはそれ以上の時間が必要とされるのである。
もちろん、顧客とのレビューなどの調整にも、時間がかかる。
これが、案外、見過ごされがちなのである。
プロジェクトが炎上したときに欲しいものとは
様々な理由により、プロジェクトが炎上か、それに近い状態に陥ってしまった時。
もしも神様から、「『お金、人、時間』のどれか一つだけ与えてやる」と言われたら、何を選択するだろうか。
たいていの場合は、『時間』と答えるのではないだろうか。
現場の人間にとっては『お金』などどうでも良いのだし、『人』をその段階で投入されても、かえって迷惑なのは、前述した『ブルックスの法則』のとおりである。
疲弊しきった現場に必要とされるのは、一息休むための『時間』、休んだ後に課題を一つずつ整理するための『時間』、建て直すための『時間』なのである。
一度、炎上してしまい、ガタガタになってしまったプロジェクトは、立て直しするのにも、相当の時間がかかる。
数カ月、もしくは一年単位の時間が必要な場合もある。
そのくらいの十分な『時間』が確保されて、はじめて『新たな人員を補強しよう』という話ができるようになる。
エライ人には、これがわからんのである。
「失われた20年」で本当に失われたものとは……これは現在でも失われ続けており「失われた30年」というものも現実味を帯びている
「失われた20年」で本当に失われたものとは……これは現在でも失われ続けており「失われた30年」というものも現実味を帯びている
今日は東京都議会選挙の投票日であるが、やはり投票率は低迷するのであろうか。
日本は2008年をピークに人口が減少に転じ、ついに人口減少社会に入っている訳であるが、東京の人口だけはまだ増加している。（それでも2020年あたりまでがピークで、その後は急速に少子高齢化が進むとも言われているが）
いまや1300万人という、日本の全人口の1割もの人が東京に居るという事になる。東京の政策の失敗は国政にも大いに影響するだろう。
日本は、1990年頃のバブル崩壊まで、だましだまし経済成長を続けてきた社会であった。
しかし、国策としてバブル景気を発生させ、そして、国策としてそれを崩壊させた事で、ついに日本の経済成長、および経済大国としての実体はなくなった。
その後に訪れた低迷期が「失われた20年」と呼ばれている。
「一億総中流」と言われた社会構造は崩壊し、格差社会が浸透していった。
IT業界においても、1990年代は、景気こそ良いように見えたが、実のところ、情報システムの「オープン化」の名の下に、「ITに関心も興味もないユーザー企業」が、「短期的な利潤のみを追い求めるITベンダー」との利害の一致を見せ、以下の事がどんどん進行していった。
ユーザー企業が自社の情報システムの再構築や開発を上流工程から外部に丸投げ
ITベンダーは多重請負構造を構築して大規模案件を受けまくり、オープン化の名の下にシステムを食い荒らす
そんな状況が、いわゆるITバブル崩壊と言われた2000年代初頭まで続けられた訳である。
残るもの 残らないもの 貴重なもの そうでないもの
上図のように、大きなものを作ったりする場合、システム開発を例にすると、
(1) 基本思想、システム化の目的、考え方、アーキテクチャー
(2) システム化詳細設計、デザイン、実装、プログラム
(3) システムの利用ガイド、手順書、運用資料
…といった、3つのカテゴリーに分解できる。
内容の質という観点から、(1)の方が付加価値は高いし、できる人が少なく貴重である。
ITに無関心なユーザー側経営者ととにかく短期的な売上を得たいITベンダーとの利害の一致が生み出した大安売り
かつては、いまではすっかり聞かなくなったが、上記で言う（1）にあたるような、いまで言う「上流工程」を専門的に行う者として、SA（システム・アナリスト）という存在が居た。
起こったことは、IT技術者が「SA単価」では契約できなくなった。（無論、この単価契約という制度自体にも問題はあるが）
システム化の基本仕様や要求仕様の作成はユーザー側企業の情報システム部でやるから、ITベンダーには決められたそれらに基づいて粛々とシステムを開発すれば良い （実際には、自社業務もろくに知らない、システム開発の経験もない素人が作った「使えない基本設計書」があるのみ）
ITベンダー側も外注化が進んで空洞化しており、とにかく案件を安く受けまくる
ユーザー側企業とは最も距離が遠い下請け企業の技術者が、上記の（2）を実施するためには結局（1）の部分が必要となり、（1）も含めて不完全なものを開発する （もちろん安い単価で）
（1）が不完全な状態で出来上がったシステムが使いやすい訳もなく、炎上案件となる
…という事が、くりかえされた。
近年になって、「丸投げはいけない」とか、「自社の重要なノウハウの流出はマズイ」とか言われるようになったが、あまりにも遅すぎる。
20年間以上も、上記のような状況を作り上げてきたのに、それが簡単に戻せる訳もない。
いまになって、自社の基幹業務の知識を自社内の誰も持っておらず、そのためにシステムの維持すらできなくなって、開発当時の技術者を探し求めても、その人は既に業界を去ってしまっていた、などという事が本当に起こっている。
自業自得である。
真の意味での『同一労働同一賃金』とは何かを考えてそれを実現しなければ日本は滅亡するだろう
前にも言ったのだが、日本型の『終身雇用』自体がダメなのではない。賃金の単純な『年功序列』がダメなのだ。『終身雇用』という名の"無期限の雇用形態"はむしろ生活不安を減少させ生産性を向上させる。つまり必要なのだ。何故こんな簡単な事がわからないのかな？ 有期契約の不安定な雇用が問題。
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2017年7月1日
真の意味での『同一労働同一賃金』とは何か。
それは、仕事の価値を正しく評価して、それに見合う処遇を行うということである。
ただ単に時給を上昇させれば良いという問題ではない。
よく「正社員は簡単には辞めさせられないので、コスト増となり、非正規雇用しか増やせない」という理論を聞くが、それはどうなのだろう。
社員のパフォーマンスが出ないのは、本人だけではなく、仕事を任せる管理職の責任でもある。要するに、その人の「使い方」がうまくないだけではないだろうか。
場合によっては、処遇を落としても良いと思う。
以前にも何度か書いたが、「その仕事をお金を払ってでもやってみたいと思っている人は世の中にはたくさん居る」のである。
正当な理由で処遇を落とされたり、仕事を外されたりしたのであれば、受け入れてみるしかない。
そして、自社とか委託とかに関わらず、真の意味で付加価値の高い仕事をしている人を、正当に評価し、処遇し、リスペクトする文化を醸成しなければならない。
近年、日本を代表するような巨大メーカーが経営不振になり身売りされたり、中国にどんどん技術が流出して、かつてとは立場が逆になりつつあるとか、そんな話がニュースになっているが…。
それは結局のところ、貴重な知識やスキルを保有していて本来は大切に処遇しなければならなかった「人財」を、まったく大切には扱わず低い労働条件で使い倒してきた事の、ツケが回ってきたというだけなのである。
このままでは人口減少、少子高齢化、労働人口現象などと相まって、本当に日本は滅亡してしまう事だろう。
昔はなかった言葉「文系エンジニア」「文系プログラマ」…この言い方やめないか？
昔はなかった言葉「文系エンジニア」「文系プログラマ」…この言い方やめないか？
新入社員たちが最初の新人研修を終えて、現場に配属される季節になった。会社や組織にもよるが、この7月から配属というところも多いのではないだろうか。
ウチの職場は、様々な理由により、そんなには人気も無いし、採用人数も少ない。
近年では、4月の入社式の日に、新入社員たちのコメントが全社向けのイントラネットに掲載される。誠に恥ずかしい風習である。
私が新人だった20数年前には、当然ながらイントラネットもなかったので、そのような恥ずかしいモノはなかった。
さて、その新入社員たちのコメントの内容であるが、まぁ、空気を読んだ内容、読まない内容、様々である。
その中で、気になるワードがある。「『文系』ですが頑張ります」などというものである。
近年、「文系エンジニア」や「文系プログラマ」という言葉をネット上で目にする機会が多い感じがする。
文脈的には、どちらかと言うと否定的なニュアンスで使われている。
曰く、『文系（大学）卒業で、エンジニア、プログラマになれるのは日本くらいだ』
曰く、『海外ではコンピュータ・サイエンスを学んだ上でないとプログラマにはなれない』
曰く、『日本では本当に優秀な理系（大学）卒業者は、プログラマなどにはならない』
曰く、『日本では安い単価で素人をプログラマに仕立て上げて現場に送り出す悪徳商売が横行している』
全否定はしない。
しかし、たちの悪いマスメディアのように、ごく一部分をフォーカスしているだけで、それをあたかも社会全体にも言えるかのように誇張するのも、違う気がする。
そもそも「文系人間」「理系人間」などという種類分けに意味があるのか？
普通科高校における、科目選択としての「文系コース」「理系コース」が、その人間の性質まで決めるのだろうか。
では、商業高校に進んだ人はどちらなのだろうか。文系だろうか。
では、工業高校に進んだ人はどちらなのだろうか。理系だろうか。
実のところ、近年の風潮からして、『学歴』とは、あくまでも『大学の入学歴』の事を指す。
そうなると、商業高校、工業高校、高等専門学校などに進んだ人は、『学歴そのものが無い』という事になる。
十代半ばにおける進路選択で、その人の人生は確定か。
「文系」「理系」および「学歴なし」が確定か。
バカバカしい。本当にバカバカしい話である。
社会人になってみてはじめて勉強の意義がわかってそれから努力する人もいる
どのような職業であったとしても、実際にやってみないことには、自分に向いているかどうかはわからない。
日本型の新卒一括採用は、確かに批判もあるし、その時点にしかチャンスがないという歪んだ採用実態は、改善する必要があるとは思う。
しかし、まったく社会経験がなく『真っ白』な状態のまま採用する事で、その人の本当の適正は、実際の仕事の中でゆっくり育成するという、決して悪いだけではない点もある。
学生時代に選択した科目が「文系」であったとしても、エンジニアやプログラマといった技術職の方が向いているとわかったり、もしくは、本人の努力で同期の「理系」たちに追いつき、追い抜いていく場合だって多い。
まぁ、入社時のコメントで出身大学の名前をわざわざ言う人には、正直、苦笑を禁じ得ないけれど…。
中学の理科から勉強しなおしている
中学の理科から勉強しなおしている
以前にも何度か書いたように、今年は非IT系の分野の勉強もしようと思っている。
（関連記事）
私には自動車が運転できない
実際、電気の勉強ということで、中学の理科から勉強しなおしている。
例えば、こういった世界について。
（フレミングの左手の法則）：モーターの原理
けっこう、やってみるとかなり忘れている。それに奥が深い。
やはりアウトプットは大切だ
磁界の向きと「右ネジの法則」があれば、「フレミングの法則」は左手も右手も不要ではないだろうか、などと思って、実際に絵に描いてみると、なかなか難しい事に気がつく。
やはりアウトプットしてみるのが大切だと感じる。
世の中では、学歴といえば「大学の入学歴」のみを指し、非大卒などは眼中にも入れられないようであるが、こうした工業高校や高等専門学校で学ぶことの方が、普通科の勉強よりも面白いと感じる。
多様性とは何だろうか。
