IT (情報技術) 学習記録

主に情報処理技術者試験、オラクルマスター、Linux技術者試験(LPIC)等の、IT系、または電気系の学習記録を中心に。(働き方や世の中も)

【リマインド】しっかりと読んでおきたい日本の労働環境の実態と未来予測


【リマインド】しっかりと読んでおきたい日本の労働環境の実態と未来予測


拝読しているとあるブログ記事からのリンクで、

平成26年労働経済の分析人材力の最大発揮に向けて

という、厚生労働省の統計資料および分析資料の存在を知った。


(厚生労働省)平成26年版労働経済の分析_人材力の最大発揮に向けて

www.mhlw.go.jp


こういった統計に基づく白書・分析資料は、特定の企業や業界や個人の恣意が混入していない、ある意味では最も真実に近い事が書かれている。

無論、単なるデータだけでは読み解けないため、分析結果には特定の思考が入る訳だが、少なくとも国レベルの広い視野に立ったものなので、一定の評価はして良いものだと思う。

ここで注目したい事は、例えば、団塊の世代が75歳を超えてくる2025年までに、どういった職種や業界に人材が不足しているのか、などである。


日本においては、転職という行為はそれだけで高リスクであるという現実


(厚生労働省)第3章職業生涯を通じたキャリア形成

などの資料を読むと、改めて思い知らされる現実として。

日本においては、「最初に就職した職場に定年まで勤める」ということに対して…

  • 自分自身がそうであるという人の割合が非常に高く

  • またその事を肯定的に捉えている人の割合も非常に高く

  • その多数派に属していない人々は完全に一部の上流階層と少なくない非正規労働者などの階層とに分断されている

…という事である。

日本においては、転職という行為はそれだけで高リスクであるという現実が資料からは見えてくる。


こういった資料は、しっかりと読んでおきたい。

そして、そう遠くない激震が走る未来に備えたい。


人は『正しさ』ではなく『わかりやすさ』で判断している…という真実…でもそういう人ばかりになったら国は滅亡するだろう…


人は『正しさ』ではなく『わかりやすさ』で判断している…という真実…でもそういう人ばかりになったら国は滅亡するだろう…


職場で、特に若い人たちに向けて、こういう事を言った。

こういう事実は、昔からあった訳だが、その傾向を強めたのは、『失われた20年』であると思っている。


  • 大企業や中央官庁などがどんどん『管理するだけ』の『丸投げ』傾向を加速させる

  • 実作業の『外注化』が進みノウハウの『空洞化』が進む

  • 一方でコンプライアンスやガバナンスは重視されるため細かい事でも責任者の『許可』が必要となる

  • しかし責任者は専門的な事はまるでわからないし、その部下さえもわからない

  • 詳細で専門的な資料や記録は使えなくなり、説明用の『正確ではない』が『わかりやすい』資料が幅をきかせるようになる


一見良い事のようにも思えるが、実際には分断化を促進しているだけ


今日の表題を図にするなら下記のようになる。


f:id:KF7757:20170819133726g:plain


f:id:KF7757:20170819133739g:plain


f:id:KF7757:20170819133753g:plain


これは確かに世の中のひとつの真実ではある。

……が、全ての人間が『正しさ』ではなく『わかりやすさ』を基準に判断するようになってしまったなら、世の中は回らなくなる

誰かは『正しさ』を見ている

だからこそ、世の中は回っている


『わかりやすさ』をもとめているのが管理者側、『正しさ』を"見てくれている"のは管理される実作業者


これまでは実作業者たちの"真面目さ"、"善意"といったものに頼ってきた。

あるいは『注意義務違反』という曖昧で便利な言葉で『何か問題が生じたらお前が責任を取れ』という脅しに頼ってきた。

そろそろ、それは限界ではないだろうか。


日本における基礎研究の論文の数が少なくなっており、それを危惧する声がある。

そういう事にも繋がる事である。

本当にこの国は滅亡に向かっているように思える。


IT業界の実態と属人化のメリット(良い点)をあえて考えてみる


IT業界の実態と属人化のメリットをあえて考えてみる


誤解しないで欲しいのは、私が『属人化』を賛美するつもりは、決してないという事である。

私は、現場仕事も、システム開発の現場実態も、何も経験したことがないくせに、したり顔で「属人化は悪だ」、「属人化は排除しなければ社員が不幸になる」と、言っている管理者や経営者が、あまりにも多くいる事が、許せないだけだ。

役員の椅子に座って現場を知らないアナタ。

絶対、わかって言ってないだろう。


kf7757.hatenablog.com


どんな事柄にも、良い点と、悪い点があるものだ。

どんな事柄にも、だ。


IT業界の実態の例としてある企業の業務システムのトラブル対応を考えてみる


f:id:KF7757:20170812150154g:plain


上図に示したように、ある企業の業務システムにおいて、夜間バッチ処理が、予期せぬDB障害で異常終了してしまった。

夜間はシステムの内容は何も知らない運用部門(しかも派遣で集めた人員)しかおらず、連絡を受けた担当SEも何も判断できず…

バッチ処理はそのまま停止したままにして、DB環境についてはサーバーのセットダウン・アップによる再起動で様子を見る。詳細な対応はSEメンバーが出社する翌朝以降に対応する」

…という、最低限の措置を取った。

よくありそうな話である。


手を動かさないステークホルダー(例えば顧客とか)が多いと現場はコミュニケーションに忙殺され回らなくなる


夜間のうちに連絡が取れたSEメンバーの何名かは、朝8時前には出社して、情報収集から始める。

上図にも示したが、運用開始以降、十数年間、一度も発生した事がない場所だった。

そもそも、そのサブシステムについて、何をしているシステムなのか、どういう処理をしているのか、といった基本的な事を、ほとんどのメンバーが知らなかった。

かねてからの人員削減の波や、現場を無視した人事ローテーション等によって、そういった既存システムに関する知識を持った人は年々居なくなって行くのである。

システム保守チームのリーダーは、それでも発生した状況を整理し、他のシステムや、何より"顧客の業務影響"を"早急に"把握して、顧客に伝えなければならない。

こういう状況では、各処理ごとに存在するシステムの設計書などは、あまり役には立たない。

もっと全体像を捉えなければならないからである。


DB障害はすぐには原因はわからないが、再起動で問題なく動作している事は確認できた。

DBから返されたメッセージを見ると、いきなりDBサーバープロセスがダウンしてしまったようだった。

ひとまず、DB障害の原因追究は、DBインフラの部隊に後でログを送付して、必要ならばメーカーにも送付してもらっての対応となるだろう。

取り急ぎでは、AP側のバッチ処理の復旧が優先となる。

朝イチの電話で、顧客側の担当者に、リーダーから昨夜からの状況を伝える。

「DBのプロセスが落ちた」と言っても、まったくの素人である顧客にはなかなか伝わらない。

「データやAP側の問題ではない」という事を強調し、まずはリカバリを急ぐ事になった。


そこに、たった一名ではあったが、このサブシステムを十数年前に開発した時、メンバーとして関わった事があるAさんが出社した。

Aさんがトラブル対応に首をつっこみ、「ここの処理からバッチ処理を昨夜時間として流し直せばうまくいくはずだ」という見解と、そもそも「ここの処理が何をしているか」、「業務にどのような影響があるのか」を、ざっくりではあったが、リーダーに伝えられた。

開発から十数年も経過しているため、詳細な部分までは記憶が定かではなかったり、そもそも、彼が知らないうちに保守改良等で仕様が変更されている可能性はあった。

だが、大まかでも「何をしているシステムか」、「どんな業務影響がありえるのか」を、把握できる事は大きい

詳細な部分は、それこそピンポイントで設計書やプログラムを調べれば良い事なのである。


上記のような点を、ひとまず文書としてまとめて、顧客側や運用部隊などのステークホルダー(関係者)に伝える必要があった。

しかし、リーダーの電話は鳴りっぱなしである。

障害が発生したシステムの顧客部門の担当者はもちろんだが、データ連携先の顧客部門が、非常にうるさい。

バッチ処理を再処理すると言うが、それで上手く行く『保証』はあるのか」

…などと言っている。

今回はインフラ障害(DB障害)なのだ。

これまで十数年間も落ちたことがない場所で、プログラムの入れ替えもしていない。

状況からは、「データやAP側」が原因である可能性は低い。

なので、DBが正常に動いているのなら、再処理で上手く行く可能性が高い。

…といった、常識的な事が顧客側担当者には、なかなか伝わらない。…というか、顧客側も担当者が納得できないのではなく、後ろでその上司がギャーギャー言っているのだろう。


ステークホルダーへの状況説明のメールは、けっきょく、リーダーではなく、Aさんが直接書くことになった。

リーダーは、いろいろな作業をするメンバーへの指示や、ステークホルダーからの連絡対応に忙殺されてしまい、とてもAさんから情報を聞き取って理解し、それを文書化する、という行為は不可能だった。

連携先のシステムは特定の時間に起動されるようになっていて、相手側との調整もいろいろ必要となったが、初動が比較的早かったため、トラブルの拡大は防ぐことができた。


ここにAさんが居た場合と居なかった場合とを考えてみる


「ここに現行システムを知っているAさんが居るのがいけない」

経営者たちはしたり顔で言うだろう。

彼のような者が居るから、こうしたトラブル時にも、彼に仕事が振られ、けっきょく、ますます属人化が進行してしまう、と。

彼のような者が居なければ、イヤでも知識を持たないメンバーが、現存するドキュメントやプログラムなどを調べるなどして、何とか対応し、結果として、知識が拡散される、と。


その考え方は、まったく現場のメンバーの苦労をわかっていない。

自分が何も知らない、昔の誰かが開発したシステムについて、顧客側からは「君たちはシステム屋なんだから知っていて当たり前だろう」と言う目で見られながら、トラブル対応というような『時間に追われる』作業を強いられる。

これが、どれほどの強大なストレス源となるか。

それが、まったくわかっていない。

まぁ、こうした仕事が、システム保守というものではあるのだが、こういう状況ばかりが続くと、本当に心が折れる

こういう無茶振りの仕事にも、向き不向きがあるので、どんなに均等に割り振ろうとしても無理が出る。

そうなると、小さな属人化が発生し始める。

そして、属人化の負のスパイラルが発生して、知識を途中まで溜め込んだメンバーが辞めてしまったりする。


そして、更にわかっていない事は、ドキュメントやプログラムを調べれば、有識者よりも時間はかかるだろうが、同じような成果を出せるはず、という幻想だ。

ここで、管理者や経営者が想定する「時間はかかるだろう」というのは、せいぜい1日~2日だ

違う。まるでわかっていない。

上記の、Aさんがリーダーに示したような見解を、知らないメンバーがドキュメントやプログラムから導き出すには、何週間も、もしかすると何ヶ月もかかる


「障害が発生してしまいましたが、開発したときの有識者は既に離散しておりまして、申し訳ありませんが、復旧(解決とまでは言っていない)には1ヶ月のお時間が必要です」


このように顧客に言って良いというならば、そうしようではないか。

これが言える管理者や経営者が居るのか? …ということである。


仮に。

仮にそう言えたとしても。

何週間も、何ヶ月もの間、トラブル対応という異常な仕事をやり続ける事は、どんな人間にも無理なのだ。

絶対に心身ともに壊れてしまう。


大切なことは、如何にして、「属人化の負のスパラル」を最小限に抑えるか、である。

そして、トラブル対応などといった、属人的な知識が必要、かつ、活用される場では、思いっきり属人化された知識を活かすのだ。

そういった対応の中で、属人化したメンバーに、ある程度機転の効く若手をつけるなど、育成面での工夫はどんどん行うべきだ。


kf7757.hatenablog.com

kf7757.hatenablog.com


IT業界の実態と業務に深く潜るべきか否かの様々な見方


IT業界の実態と業務に深く潜るべきか否かの様々な見方


このブログをお読みいただいている方には、多少なりとも私の考え方の傾向をつかんでおられると思う。

私は、過去の記事で何度か言ってきたように、純粋に「IT汎用スキル」だけで勝負しようとすると、いまのIT業界は、本当に技術者へのリスペクトがなく、技術者を消耗品のように扱うため、結果として『過当競争』に追い込む。

それから逃れるには、「IT汎用スキル」"だけ"で勝負するのではなく、特定分野の「業務やシステム固有の知識」"も"併せて保持して行くことで、希少価値を高める事が重要であると考えている。

しかし、無論の事、同じ事を、まったく異なる側面から見ることもできる。最近、それをとても強く感じた記事を拝読したので、ここに紹介したい。


新人SEが同じ場所で常駐を続けると蝉になる

fumisan.hatenadiary.com


上記の記事に対して、私は下記のようなブックマークコメントを付けた。


この、紹介した記事内容自体には、特に反論の要素はない。確かにそうだな、と思った。

現に、私の観測範囲でも、新卒一年目から20年以上も、客先常駐で派遣されてきて、自社よりも客先での人間関係の方が広く深くなり、それこそ客先SEリーダーなどから「うちに移籍すれば良いのに」と言われることも多かったものの、様々な事情があって、いまでもそのユーザー企業のシステム再開発の有識者として、常駐型で働いているという人を知っている。

(この方は、会社は違えども新卒年度が私と一緒だったので、いろいろと共に成長してきたという思いはある)

また別の方は、長く独立系ITベンダー側の技術者として、時には常駐したり、時には請負先リーダーをやったりしていたが、ユーザー系の元請IT企業に移籍された。それも実例として知っている。


IT業界の実態を図にしてみた


IT業界の実態を、簡単な図にしてみた。普通は上にユーザー企業があって、下に下請けベンダーがあるような、ピラミッド型で表現されることが多いが、上下関係みたいで嫌なので、関係を横にしてみた。


f:id:KF7757:20170805104848g:plain


この図を見ていただければわかると思うが、何だかんだと言っても、いちばんの問題は、この図の中間部分に居座っている会社の存在なのである。

上の例で言うならば、GHシステムの人間が、GHシステムの人間として元請けから発注を受けるとか、もしくは、容易に元請企業に転籍できるとか、そういう構造になっていない点が、まずもって問題である。

もちろん、これは、上記の紹介記事で言われる「サイロ化」されたユーザー側に近寄る方向なので、これが全て良いわけではない。

しかし、「サイロ化」の現場に入ることが、なぜ危険と言われるか。それは、「サイロ化」自体の問題ではなく、発注元(上記の図で言うと中間に位置している企業や、元請け企業)の都合で「いつでも切られる状態に置かれたまま」であることが、最も技術者を不幸にしている訳である。


技術者をリスペクトしない国、日本


バブル崩壊から20数年。

日本はすっかり、技術者(エンジニア)をリスペクトしない国と化してしまった。

本当に先進国から後進国に、どんどん下へ下へと向かっているのだと思う。


(関連過去記事)

kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com


汎用機(メインフレーム)とCOBOLのシステムが使われ続ける理由


汎用機(メインフレーム)とCOBOLのシステムが使われ続ける理由


以下のようなニュースが目に止まった。


IBMメインフレーム、「15年に一度の大型アップデート」

itpro.nikkeibp.co.jp


特にIBMに愛着がある訳ではないが、コンピュータの世界も、ダイバーシティ(多様性)という事で、汎用機(メインフレーム)文明が衰退してしまうのは個人的には避けて欲しい。

いまや、Webサーバーを中心としたサーバー分野においては、多くの商用UNIXLinux系に置き替えられている。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おじさん」にはならないように気をつける必要はあるだろう。


関連過去記事

kf7757.hatenablog.com


少し古い記事ですが、二進化十進法(BCD,Binary Coded Decimal)などの、データ表現についての解説記事

1週間で学ぶIT基礎の基礎 - コンピュータにおける「データ表現」の基礎(第3回):ITpro

1週間で学ぶIT基礎の基礎 - コンピュータにおける「データ表現」の基礎---目次:ITpro


『属人化は悪だ』としたり顔で言っている経営者への伝言


『属人化は悪だ』としたり顔で言っている経営者への伝言


まず、属人化は悪だ、属人化はなくさなければならない、と、『自らのシステム開発現場での経験を基にして』、主張しているのであれば、何も反論はしない。その通りだと同意しよう。

しかし、私が思うに、特に大企業や大手クラスのIT企業の、ほとんどの経営者たちは、『自らの経験から』は、言っていない。

何故ならば、もともとはシステム開発とは異なる畑が出身の人たちばかりだからだ。

『属人化は悪である』という事は、本で読んだか、近しい部下や後輩から植え付けられた知識にすぎない。自らの経験から産まれた経験知ではないのであれば、それは役には立つまい。


『属人化が理想の姿ではない事』は言われなくてもわかっている


属人化が理想の姿ではない事は、この業界の中に居る者は誰でもわかっている。リーダーやマネージャーを経験したことがあるなら、なおさら、それはわかっている。

私の短い社会人経験からだけで言っても、20年は前から言われてきた事なのだ。

つまり、改めて言われるまでもなく、属人化が理想とは異なる事は、皆わかっている。

それなのに、である。

経営者からの問題提起として、

などと言われると、本当に、がっかりする。

あなた方には見えていないのだろうか?

いま、多くのユーザー企業、特に大企業において発生している、『属人化』よりもはるかにおそろしい事態を。


『属人化』よりもはるかにおそろしい事態『空洞化』が進行している


おそろしい事態。

それは、『空洞化』だ。

大企業の本社側の人間が官僚化し、『定期人事異動』によって、コロコロと入れ替わる。

そこには、もはや、ノウハウを蓄積するという機能は完全に失われている。人事異動のたびにその部署に蓄えられつつあった知識は消え失せる。"リセット"だ。

そのような状態でも業務が回っているのは、優れた仕組みやルールがあるからではない。

単に、実作業のほとんどを現場側や委託先企業に、『丸投げ』しているからだ。


『空洞化』に至ればもはや回復はない


一度、『空洞化』状態に陥ってしまったなら、その状態から自力での回復はない。

ドキュメント化を高める事自体は良い事だろう。しかし、それでも、『ドキュメントを探し出す能力』や『ドキュメントを読み解く能力』は、絶対に必要なのだ。

素人をいきなり連れてきてどうにかなるような甘い世界であるはずがない。

現場側や委託先の誰かが『属人化』状態であってでも、知識を持っていてくれるならまだ良い。

そうした人が知識とともに他に移ってしまい、永久にノウハウが失われるという最悪の事態が、現場では発生しているのだ。


理想ではないが『属人化』から少しずつでも"継承"をして有識者を増やすのが善策


『属人化』が問題視されるのは、その人数が少ないからだ。

一人しか居ない。それが問題なのだ。

ならば、一人を二人に、二人を四人に増やせば良いのだ。

知識・ノウハウを"継承"して行く活動しかない。早道などはないのだ。

それを地道にやろうとしている現場のマネージャーやリーダーを無視して、下手に人事ローテーションなどやってみろ。

全てが台無しになる。


だから、付け焼き刃の知識だけで、『属人化は悪だ』などとしたり顔で言うな。

“人を『人財』であると思い、大切に扱う。”

あなた達が、まだ現場で"課長"や"部長"などの管理職であった20数年前。

人を『交換可能な部品』として扱い始めた事で、『失われた20年』が始まってしまったのだ。

それを自覚し、反省し、単なる浅い知識だけで、『属人化は悪だ』などとしたり顔で言うな。


kf7757.hatenablog.com


バブル崩壊は1991年から始まった……就職氷河期世代(日本版ロスト・ジェネレーション)は忘れない


バブル崩壊は1991年から始まった……就職氷河期世代(日本版ロスト・ジェネレーション)は忘れない


今回の記事は、記事というよりも記事の紹介。リンクの覚書のようなものに終始している事をお断りしておく。

最近、唐突に気付いたのだが、「バブル崩壊」「就職氷河期世代」「失われた10年」「失われた20年」「ロスト・ジェネレーション」などと言っても、今の20代の若手には通じない用語になっている。

私の認識では、バブル崩壊は1991年頃である。そしてその影響が就職戦線に一気に来たのは、1993年新卒の世代からである。

考えてみれば、もう25年も昔のことなのだ。今の新人が生まれる前ではないか。


しかし、今日の読売新聞の社会保障(26面)には、下記のようなタイトルの記事が並んでいる。

  • 中高年ひきこもり 支援手薄 進む高齢化…対象は若者中心

  • 正社員と非正規社員はどう違うの?(ニャるほど!社会保障

「いまさら何を言っているんだ」と言いたくなる記事ではあるが、これが全国紙の真面目な社会保障面の記事なのである。


1993年に20歳前後だった世代は、いまでは45歳前後になっている。

1993年時に高校卒業で社会に出た人は、43歳くらい。

1993年時に短大・専門学校卒業で社会に出た人は、45歳くらい。

1993年時に大学卒業で社会に出た人は、47歳くらい。

いま、いわゆる「ひきこもり」や「ニート」の高齢化が問題視されながらも、「39歳以下しか対象としてみなさない」というバカみたいな行政側のずさんな実態調査もあって、いまだにその深刻度が正確には把握されずにいる。

それがまさにいまの40代であり、25年前の「バブル崩壊」時期に社会に出てきた「就職氷河期世代」の先頭世代なのである。


下記の記事でも書いたが、バブル崩壊前までの20年間は、経済成長時代であるにも関わらず、大学進学率は30パーセントに届かない(20パーセント台)で、大きな変化はなかった。

それが、バブル崩壊後の大不況時に、一気に上昇に転じた。だが、それは、それまで言われてきた『一億総中流社会』を破壊する、『格差社会』への扉のひとつだった。

kf7757.hatenablog.com


恨みも込めて記憶しておきたい作られた時代


戦後のベビーブーム時に生まれた、「第一次ベビーブーム世代」は、いわゆる「団塊の世代」である。この世代は「逃げ切り世代」と揶揄されている。まともな公的年金などの社会保障をギリギリ受け取ることができる最後の世代だと思われるからである。

今から10年位前、団塊の世代の一斉退職によって「2007年問題」が発生すると言われた。しかし、結果としては、この世代の多くはいまだに影響力のある職場に残っていたり、業務のIT化などの影響でそれほど大きなインパクトにはならなかった。

そう。多くの企業のトップや中小企業の創業者などは、いまだに後継せずに、現役でいる。従って、本当に問題が表面化するのは、おそらく団塊の世代が全て75歳以上になるであろう、2025年くらいなのである。

日本の経済成長時代は、上記の団塊の世代と、その後続の世代によって、良きにしろ悪しきにしろ、形成されたのだろう。


一方で、「第二次ベビーブーム世代」という世代も存在する。これが、ちょうど「就職氷河期世代」の先頭世代と同じなのである。

人数が多いという事は、それだけ政治的な発言力もあると思われるが、「第一次ベビーブーマー」向けには様々な制度が味方をしたが、「第二次ベビーブーマー」向けにはその反対の事が起こった。

1990年代からの「失われた20年」は、特定の世代を特に犠牲にした、作られた時代であったのではないだろうか。恨みも込めて記憶しておきたい。


ダイヤモンド書籍オンライン 今知っておきたい、90年代のバブル崩壊物語 3分で学びなおす日本経済史 第4回 株価暴落から山一・拓銀長銀の破綻まで (著:蔭山克秀)

diamond.jp


kf7757.hatenablog.com

kf7757.hatenablog.com


いま政府が画策している「残業代ゼロ法案」が施行されると本当に日本は先進国ではなくなるだろう


最後に、「残業代ゼロ法案」に関係する記事を紹介する。

世代論とは少し方向性が異なるように見えるが、実はそうではない。

「労働者派遣法」がどんどん規制緩和の方向に進んで、いつの間にか「派遣社員」が、昔の「高度な技能を提供してくれるお客さま」ではなく、「単なる雇用の調整弁」として扱われるようになったのと同じように、「残業代」という労働時間のブレーキを「規制緩和」しようとされている。


「成果型労働」「成果で評価する」という誤報が止まらない 佐々木亮 弁護士・ブラック企業被害対策弁護団代表

news.yahoo.co.jp


この「残業代ゼロ法案」が施行されると本当に日本は先進国ではなくなるだろう。


「アウトプット」の重要性と「生徒でいるうちは先生を超えられない」説


「アウトプット」の重要性と「生徒でいるうちは先生を超えられない」説



これ、本当にそう思う。

理由は「脳の記憶のメカニズム」と関係がある。

誰かに教えられたり、何かを読んで勉強する時点では、その情報や知識は、まだ「自分の知識」として脳に定着していない。

一方で、誰かに自ら教えたり、文書として自分なりにまとめたり(ブログでも良い)する時点で、はじめて「自分の知識」として脳に定着するのである。


生徒は先生よりも上手くはならない説


これは、前述の理論で説明がつく。

最近、拝読した記事の中に、下記のような言葉があった。


「バイトや仕事よりもブログで稼ぐ」ことを学生や若者が主張するようになったのは、「絶望」のせいかもしれない。 - いつか電池がきれるまで


 僕は、若者がキラキラとした自分の夢を語ってサロンに集客するようなブログは、基本的に「お金に困っている人から、『こうすれば稼げますよ』と教えるという名目でさらに小銭を巻き上げる『貧困ビジネス』」だと思っています。

 人にものを教わるときに気をつけたいのは、ほとんどの場合、生徒は先生より上手くはならない、ということなんですよね。

 だから、教えてもらうのだとしたら、「教えたがっている人」にではなく、「自分もこうなりたいと思える人」に付いたほうがいい。

 大部分の「ブログ指南」をしている人たちと、その信者たちをみると「えっ?こんな現時点ですでに救いようのないブログの劣化コピーをつくってどうするの?」って思うよ。


これも、本当にそう思う。

この記事全体の主旨についての言及は避けるが、上記の引用の中の、「生徒は先生より上手くはならない」の部分は、本当にそうだと思う。


ブログを書くことの意義もある


上記のような事を踏まえると、ブログを書くという行為にも、意義が見いだせるのではないだろうか。

そんなことを思う次第。


2TBプラッタのハードディスクドライブ(HDD)が主流になりつつあるのか(SSDはいまだに信用できない件)


2TBプラッタのハードディスクドライブ(HDD)が主流になりつつあるのか(SSDはいまだに信用できない件)


www.itmedia.co.jp


プラッタというのは、磁気ディスクの円盤の事である。私の認識では、両面が主流になったり片面が主流になったり(物理的なサーボ情報の記録の方式がいろいろあった)したが、近年は、両面記録方式が主流だと思う。

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コマンドで対応)

  • 書き込み回数に限界がある(SLC:10万回程度、MLC:5千~1万回程度、TLC:1千~5千回程度)

  • まったくアクセス(通電)しない状態で放置すると、いつの間にかデータが「蒸発」してしまう

温度や湿度などといった使用環境にも左右されるが、フラッシュメモリーには、上記のような、仕組み上の欠点が存在する。


特に「寿命」と「データの蒸発」という問題は、技術的なパラダイム変化が欲しいようなレベルの問題だと思う。

ちなみに、某メーカーの資料によると、SSDの種類(SLC,MLC,TLC)ごとの寿命とデータ書き込み回数は以下の通り。

  • SLC:(工業用) 寿命「約10年」書き込み回数「約10万回」

  • MLC:(民生用) 寿命「約5年」書き込み回数「約5千~1万回」

  • TLC:(民生用) 寿命「約1年」書き込み回数「約1千~5千回」

また、TLCでは、置かれている環境にもよるようだが、まったくアクセスしない状態で放置すると、約6ヶ月くらいでデータが消えてしまう可能性があるらしい。


SSDに関しては、もう少し長期利用した場合の実績データを集めたいところである。


派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)


派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)


職場内向けの資料なのでここには上げられないが、今日は少し思うところがあって、創設20年を迎えているオラクルマスター試験の変遷や、データベース・ソフトウェアとしての Oracle Database について、自分なりに考えた。


まぁ、現在においては、世界で最も利用されているDBMSは、OSSMySQLであるという事実はある。(それもOracle社が持ってしまっているが)

しかし、ことにエンタープライズ分野の、特に大規模システムでは、Oracle Real Application Clusters(Oracle RAC) 等で可用性に優れているオラクルDBが、あいかわらず強い。


「同時実行制御」のほんのわずかな違い(リード:先行分野)が明暗を分けた


1992年(平成4年)に公開された「Oracle 7」において、「分散トランザクション」「パラレルクエリー」「データベーストリガー」といった、大規模OLTPシステムには欠かせない基本機能を、Oracle は持っていた。

そして「同時実行制御」の考え方において、IBMDB2のような「ロック」による解決を行わなかった。

「読み取り一貫性」を当初から導入していたのである。

これがオラクルの生命線だった。


あるトランザクションが終わるまで、そのトランザクションが更新しているレコードは、他のトランザクションからは「一貫して」"更新前"として見える事を保証する。


これが、「読み取り一貫性」である。

オラクルを普段から使用している人にとっては、「何を当たり前な事を」と思うだろう。そう。オラクルでは、これが「当たり前」なのであった。

更新する前にUNDO表領域(昔風に言うとロールバックセグメント)にレコードデータを退避して、それを他のトランザクションには見せる。

このことから、単なる読み込みであれば、ロックという概念すら必要はない。

これが、例えば同じように大規模システム向けのIBM DB2 だと、話は違ってくる。

更新するレコードは「ロック」することで書き込みも読み込みも矛盾を起こさないようにする。

非常に単純な仕様で、明解ではある。

単純で明解ではあったが、「同時実行性」の面で、オラクルに少しだけ先行(リード)を許した。

だが、それが致命的な差になってしまうのである。


「読み取り一貫性」はいまで言う「イノベーション」だったのか


「読み取り一貫性」はいまで言う「イノベーション」だったのかというと、そこまで大げさな機能ではなかったはずである。

「同時実行性」を、少しだけ向上させるための、ひとつの「工夫」にすぎなかったのだろう。

同じ「工夫」を、2017年である現在やったとしても、誰も見向きもしない事だろう。

1980年代~1990年代初頭という、RDBの黎明期にやったからこそ、ものすごい大きな「差」となっている。

技術とは、得てしてこういうものなのだなぁ…。