汎用機(メインフレーム)と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系の分野の勉強もしようと思っている。
（関連記事）
私には自動車が運転できない
実際、電気の勉強ということで、中学の理科から勉強しなおしている。
例えば、こういった世界について。
（フレミングの左手の法則）：モーターの原理
けっこう、やってみるとかなり忘れている。それに奥が深い。
やはりアウトプットは大切だ
磁界の向きと「右ネジの法則」があれば、「フレミングの法則」は左手も右手も不要ではないだろうか、などと思って、実際に絵に描いてみると、なかなか難しい事に気がつく。
やはりアウトプットしてみるのが大切だと感じる。
世の中では、学歴といえば「大学の入学歴」のみを指し、非大卒などは眼中にも入れられないようであるが、こうした工業高校や高等専門学校で学ぶことの方が、普通科の勉強よりも面白いと感じる。
多様性とは何だろうか。
IT業界の本当の問題はユーザーとベンダーとの距離にある
IT業界の本当の問題はユーザーとベンダーとの距離にある
（関連リンク）
「訴えてやる！」の前に読む IT訴訟 徹底解説（42）：
こんなことも知らないんですか？ ベンダーって勉強不足ですね
正しい要件定義のためには、ベンダーにも業務知識が必要
システム開発の上流工程に向く人と向かない人…（単なるグチ）
(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う
ソフトウェア開発でくりかえされる「競争発注」の愚行
最近、敢えてリンクは貼らないが、『日本には文系システムエンジニアなる存在が居てそれらが業界の問題である』とか、『欧米ではソフトウェアエンジニアには文系ではなれないしもっと高待遇である』とか、そういった論調を目にする。
いわんとするところはわからないでもない。
しかし、日本の商慣習や文化的な背景なども踏まえると、そういう問題ではないと思う。
無論、中小IT企業の一部にはびこっている『ろくな経験もない新人を経歴詐称して客先に送り込む』というビジネスモデルはすぐにでも抹殺されるべきだが…。
学歴が、理系だとか文系だとか、そんな事は『思考停止』した結論ではないか。
社会人になってからだって、努力して伸びる人も居るし、その逆も然りである。
何でも学歴に論点を収束させるのは、それこそアタマが悪い。
本当の問題は下記のような事である。
人月単価契約が横行しているため、個人や組織の固有スキルや業務知識などによる『生産性の差』『品質の差』がまったく評価されていない
ユーザー側が要件定義を軽視するために事前見積もりによる請負契約のリスクが高すぎる
システム開発は、建築業界に似た構造を持ってはいるものの、実際の仕事は建築業界と同じようには進められない。
もしも『作業量』に対してしか対価を払えないのなら、見積もりではなく作業結果を見てから払う契約にしなければ…。
（生産性や品質は絶対に人や組織によって差が出る。おそらく驚くほどの差として。）
そして生産性や品質の差にはしっかりと報いなければならない。
日本にだって、各業種/各業界ごとに、キーパーソンとなっている、ある意味でスーパーエンジニアと呼んでも良いような人が居る。
こういう人たちを正しく評価せず、単なる"業者"扱いして買い叩き、使い潰して来たことが、日本のIT業界の本当の問題であり、闇なのである。
本当のコア人材（人財）が育成されるには10年単位の時間が必要
とある地方の公共事業体の業務システムにおいて、その発注のやり方で、格差が出ている事例を最近知った。
一方では、その分野のスペシャリストと呼べるベテランリーダーが、人数も少ないシステム開発/保守の現場を支えている。そこではシステム開発者側の方がユーザー業務に詳しい事もあるらしく、システム開発者側が主導権を握れている。しかし、そのベテランリーダーの後進が育たない事がリスクとなっている。
他方では、競争発注（競争入札）によって複数のITベンダーに同一部門のシステムが切り取られ、保守体制もバラバラになっているという。
まぁ、どちらの事例でも、ユーザー側自らがシステム開発/保守はやっていないという点は同じだ。
欧米と比較するならば、ユーザー側自身のシステム開発への関与度合いだろう。
以前にも書いたが、ユーザーはシステムになんて興味が無く、システム開発者の多くはユーザー業務に興味が無い。
IT業界の若手はユーザー業務知識には無関心だが…それで良いのかな？ - IT (情報技術) 学習記録
これでは、要件定義なんてやる人が居なくなるだろう。
ずさんな要件定義を行って困るのは、ユーザー側でも、システム開発者側でも、どちらも『現業』『現場』の人間である。
アウトプットする良い機会になるなら休日に家でだってやる
アウトプットする良い機会になるなら休日に家でだってやる
近年では情報セキュリティの観点や、企業情報管理の観点、更には労働時間の観点からも、自宅での仕事は厳禁とされている。
まぁ、労働時間の観点は多分にポーズが入っているようであるが、情報セキュリティと企業情報管理の観点は本当に厳しくなった。
いまの若い人には信じられないかもしれないが、15年くらい前なら、家にUSBメモリ（当時は128MBとか256MBとかという容量だった！）やフロッピーディスクに仕事の資料を入れて持ち帰り、休日に仕事をするなんて誰もがやっていた。
いま考えてみると、良い時代だったのか悪い時代だったのか…。
ここで「悪い時代だった」と、何故断定しないのか、不思議に思うかもしれない。
家での仕事は「悪いこと」だと、何故断定しないのか。
確かに、やりたくもない仕事を、サービス残業ならぬサービス休日労働として、疲弊しながらやるのは、悪でしかないだろう。
現にそういう類の労働も経験がある。あれはモチベーションがまったく出なくて、本当に疲れるだけだった。
しかし、である。
昨年、三年間という長い休みを明けて現職に復帰した私としては、違う視点も持っている。
例えば、昨日の記事に書いたような、何かしらの発表（プレゼンテーション）用の資料作成。
これも、もちろん仕事には違いないので、本当はいまのご時世では「家でやってはいけないこと」ではある。
そうなのだが、現実問題、平日は本業で忙しく、なかなかまとまった時間も取れない状況だ。
プレゼン資料などは、内容にもよるが、基本的には、自分の頭のなかにある情報だけでほとんどを作り上げる。
ならば、勉強の延長線上ととらえ、自分の頭の中の知識のみで、自宅のPCのLibreOfficeなどのソフトを使って作成する分には、構わないのではないだろうか。
事実、プレゼン資料を作成するといったアウトプット作業は、自分にとってはとても勉強になることなのである。
メタスキルをどんどん高めて行きたい
先日、拝読した以下のブログ記事がとても良記事であると思った。
fromdusktildawn.hatenablog.com
この内容は本当にそうだなぁ、と同感するとともに、自分も若い人には負けないような存在でいたいと、改めて思った次第である。
無論、この記事内容と、私が休日作業をする事は、直接には何の関連もない。
重要なことは、日々勉強するといった姿勢のことである。
自己啓発もほどほどに…。それは確かに気をつけないといけない。
プレゼンはパワポ派？…私はPDF派
プレゼンはパワポ派？…私はPDF派
弊職場では、定期的に部門内部での発表会が行われている。私は昨年の途中まで休職していて浦島太郎状態であったが、どうやら休んでいる間にエライ人が決めた習慣であるようだった。
今年度は早くも業務繁忙などの事情もあり、なかなか発表者の立候補者が出ず、担当マネージャが困っているとのことだった。他人事のように聴いていたら、何故か私もプレゼンをする羽目になってしまった。
そういったことは若手の皆さんに「ヨロシク」していたのだが、たまには若くない者も何かを示さなければならないようである。
私はどうにもパワポが苦手
トヨタ式のやり方だと、「何事もペーパー1枚にまとめろ」というそうである。
個人的にはそれは同感であるし、大賛成である。
とにかく概要をA3用紙一枚にまとめる。
これ大切。
いままでも顧客やお偉方に対して何かを説明するときには、そういうやり方でやってきた。
しかし、現代は何でもかんでもパワポのご時世である。
電子紙芝居だ。
紙芝居ならまだ良いが、人によってはアニメーション機能をふんだんに使う。それだけは勘弁してくれと言いたい。
実は電子紙芝居は、パワーポイントだけのお家芸ではない。もちろん、マイクロソフト社製以外のオフィスソフトもそうであるが、何よりソフトを選ばないのがPDFである。
PDFでもAdobe Readerで電子紙芝居ができる。
私はアニメーションはいっさい使わないので、PDFで事足りる。
PDFならば、LibreOfficeでも充分なものが作れるので、こっちが良いな…。
アナウンサーが「星の赤ちゃん」「赤ちゃん星」と言うたびに残念な気持ちになる
アナウンサーが「星の赤ちゃん」「赤ちゃん星」と言うたびに残念な気持ちになる
（関連リンク）
アルマが鮮明にとらえた、巨大赤ちゃん星の産声
http://www.astroarts.co.jp/article/hl/a/9175_orion_kl?utm_source=dlvr.it&utm_medium=twitter
今日も単なるグチである。
地球から約1400光年の距離にあるとされるオリオン座の領域に、誕生したばかりと思われる、大質量恒星になりつつあるであろう現象を、世界で初めて電波望遠鏡でとらえた、というニュースがあった。
TVニュースでは昨夜から今朝にかけて、某国営放送のニュースにおいても取り上げられた。
アナウンサーは「星の赤ちゃん」「赤ちゃん星」という言葉を何度も使っていた。
そして、最後には男性キャスターから女性アナウンサーに渡されて、「宇宙のロマンですね」という言葉で締めくくられた。
「恒星」という言葉は一度も使われず
「赤ちゃん星」という言葉に違和感がある。
言いたいことは無論わかる。
しかし、無生物の、しかも巨大なスケールの恒星に「赤ちゃん」というのは、個人的にはしっくり来ない。
そして何よりも、「恒星」という単語はいっさい使わず、例えばこの記事の冒頭に私が書いたような表現もされなかった。
確かに一般向けのニュースにおいて、『専門用語』を多用するのは良くない。それはわかる。
でも、「恒星」は専門用語なのだろうか。
義務教育で習うレベルではないのだろうか。
特に「理系」分野の事を避ける風潮があるのでは？
これは特に何の論拠もない、ただの憶測に過ぎないのだが、感覚的には、特に「理系」分野の言葉や話題を殊更に避ける風潮があるような気がする。
そして今回のようにニュースとして取り上げるとなると、視聴者を『何も知らない』『無知』であると仮定した表現が使われる。
しかし、本当に一般の視聴者は、そこまで無知なのだろうか。
惑星
衛星
恒星
太陽系
銀河系
これらの言葉の意味や、スケール感を、本当にわかっていないのだろうか…。
宇宙は別に「ロマン」でも何でもない
私は個人的には、宇宙とロマンチックを関係付ける事は好まない。
何故なら、たいていの場合、宇宙を「ロマンチックですねー」という人に限って、天文学の基礎を知らなかったりする傾向があるように思えるからである。（多分に偏見を含んでいるとは思うが）
キャスターやアナウンサーは、それこそたいそうな高学歴な人々であると聞いている。
まさか彼らの認識ですら、「恒星」を専門用語と扱うレベルとは思いたくはない。
君たちは、わかっていて、敢えてそんな表現を使っているんだよね？
宇宙は宇宙。いま我々が居る場所も宇宙の一部である。
今回のニュースは、1400光年の彼方の事象だったが。
そもそも1光年よりもはるかに小さいスケールの太陽系であっても、それが人間にとって、どれほど大きなスケールなのか。
人類はまだ月に何度か到達しただけであり、火星にすら今世紀中には行けないのである。
