IT (情報技術) 学習記録-もしくは中高年(就職氷河期世代)の生き方-

IT系,または,電気通信系資格の学習記録を中心に。もしくは中高年(就職氷河期世代)の生き方,働き方,世の中。中高年の転職の現実。

プレゼンはパワポ派?…私は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光年よりもはるかに小さいスケールの太陽系であっても、それが人間にとって、どれほど大きなスケールなのか。

人類はまだ月に何度か到達しただけであり、火星にすら今世紀中には行けないのである。


必要な野心と不要な野心


必要な野心と不要な野心


先に書いたグチの続きのようなものであるので、そのつもりでお読みいただきたい。(手前味噌的な部分も大目に見ていただきたい)

(関連過去記事)


kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com


業界大手IT企業SEにしては野心がないと思った件


うちの職場などよりも10倍以上もの従業員数を誇り、業界では知らない人は居ないような大手IT企業に、今回は上流工程である要件定義段階から参入してもらっている訳である。

手前味噌という表現が合っているか自信がないのだが。言ってしまうと…。

今回、大規模改修を行うユーザー企業の業務システムは、非常に特殊で、まず類似システムはほとんど世の中には存在しないと言い切れるものである。しかし、その業務領域はユーザー企業にとっては基幹部分に深くまで刺さっているものであり、業務が消え去ることも、システムが使われなくなる事も想定し難い。

つまり、パッケージ化によるスクラッチシステムの廃棄や、事業自体が売却の憂き目を見るといった事はなく、その業務やシステムを一度でも知悉するまでに至れば、ユーザー企業がそのシステムを改修する度毎に、その仕事を高確率で受託することができる。

こういった部類のシステムの大規模改修プロジェクトに、上流工程から参加できるものなら多少の無理があっても参加してみたいとそう思うITエンジニアやIT企業は多いのでは無いかと思う。

(こんな事を言ってしまうので、手前味噌という表現を使った)


しかし、今回の相手先のリーダー(大手IT企業社員)は、どうにも反応が薄い。

そのリーダーについてきている他メンバー(実はその大手IT企業社員ではなく下請けの方)の方が、よっぽど食いつきが良い。

いままで、他のITベンダーが独占していた業務領域を奪取できるチャンスだと思うのだが、そういう姿勢は感じられない。あくまでも受け身で「成果物のイメージを教えてください」とくりかえすのみである。

一言で言うならば、『野心が無い』

こういった野心ならば、必要な気がするのだが…。どうなのだろうか…。


不要な野心もある


同じ『野心』でも、まったくもって邪魔な、不要な部類の野心もある。

狭い意味での、『出世欲』などがそれにあたる。

承認欲求と自己肯定を周囲に撒き散らしながら、組織内での自分の序列を少しでも上昇させたいと腐心するような『野心』は、結果としては、陰で誰かを犠牲にする事が多いと思う。


出世というものは目標であってはならないのではないか。

良い仕事であったり、良い貢献であったり、そういった事の「結果」のひとつとして、出世というものがあるのではないだろうか。

…そんな風に思うのである。


客先に『何をどんな風に作れば良いですか』と訊くのは上流工程SEとしては敗北宣言なのか…どうかな…


客先に『何をどんな風に作れば良いですか』と訊くのは上流工程SEとしては敗北宣言なのか…どうかな…


(関連過去記事)

システム開発の上流工程に向く人と向かない人…(単なるグチ)』

システム開発の上流工程に向く人と向かない人…(単なるグチ) - IT (情報技術) 学習記録

『(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う』

(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う - IT (情報技術) 学習記録


UMLユースケース図なり、Mind-SAなり、様々な、"ユーザー側とシステム開発者側との間での『意思疎通』のためのツール"が開発されてきた訳であるが…。

それらは、基本的には、あくまでも『"最低限"これだけは決めて文書に残しましょうね。お互いのために』というものに過ぎない。

現にUMLユースケース図などは、大雑把すぎる骨組みだけしか定義しておらず、中身は各々で工夫してね、である。

システム開発工程の、設計以降のドキュメントのフォーマットを細かく規定している企業があるが、それも目的としては、『どんなに業務知識や経験に差がある人がやって来ても、"最低限"この情報だけは決めて記載しましょうね』という事を規定する事で、品質のバラツキを抑えるためにある。

もちろん、大規模システムの場合は、記述レベルを『統一する』こと自体が、品質につながる側面もある。しかし、ルール上で規定するのは『最低限』の側なのである。低い方に統一する方向になってしまう。


それを踏まえた時、特に上流工程においては、『何を作ればよいですか』『どんなイメージの成果物を作れば良いですか』と、顧客側に訊く事は、どういう意味になるのだろうか…。

確かに、作業のマネジメントの観点からは、『誰が』『いつまでに』『何を』『どんな内容で』作成するか、キッチリ確定しながら進めたい。

確かにそれはそうだろう。

しかし、そもそも、上流工程とは『何を』『どんな内容で』これから作って行くか、それ自体を決める作業なのではないだろうか。

従って、ユーザー側とシステム開発者側とで、膝突き合わせて、『お互いの意見を主張し合いながら』進めていくものなのではないだろうか。


こう考えた時に、自分の主張をするシステム開発者が、何と少ない事か。

もっとも、これは開発者側だけの問題ではない。

主張などせずに、言われた通りのモノを作れば良い、という愚かなユーザー側がはびこっている事も問題である。

要件定義の前段階である要求整理すらまともにできないと言うのに。


とりあえず、そうは言っても進めないと…。

今回も結局はグチになってしまったな…。

(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う


(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う


2007年の記事なので、ちょうど10年前の「@IT」さんの連載記事である。

土曜日に私が「単なるグチ」として書いた記事と、内容が関係するようにも思え、かつ、私としては響くものがあったので、ここで紹介したい。


(土曜日に私が「単なるグチ」として書いた記事)

システム開発の上流工程に向く人と向かない人…(単なるグチ) - IT (情報技術) 学習記録


『転職失敗・成功の分かれ道(31):上流工程にいきたいなら新幹線に乗り換えろ』

転職失敗・成功の分かれ道(31):上流工程にいきたいなら新幹線に乗り換えろ - @IT


なかなか厳しい内容かもしれないが、そうだよなぁ、と思った次第。


私には自動車が運転できない


私には自動車が運転できない


運転するための技能も持ち合わせていない。道路交通法の基本的な部分にも疎い。

何故なら、そのための訓練を受けていないから。

従って、国家資格である「第一種運転免許」(いわゆる普通自動車運転免許)を持っていない

能力も持っていないし、そのための資格も持っていない。

だから、私には自動車が運転できない。


運転したかったら免許を取れば良いじゃないか、という何気ない言葉


世界でも類を見ないほどの、最高レベルの鉄道技術が普及している日本であっても、自動車運転免許の保有率は、相当に高い。

警察庁の統計情報を確認すると、障害を持っていない人であれば、ほとんどの人が、とりあえず免許だけは持っている、という状況なのがわかる。


子供時代には、将来はバイクを運転してみたいと思った時期もあった。しかし、生まれつき目が非常に悪い方で、矯正視力でもせいぜい「0.5」程度に留まってしまう事から、運転免許はあきらめた。



上記にも書いたように、自動車運転免許は、「第一種運転免許」という、立派な国家資格である

企業の求人広告に、「要普通免許」と書かれたものが何と多いことか

多くの人が当たり前のように保有しているためか、その資格の大きさに気付いていない人が多くいるように思える。

「免許持ってないんですよね」と言うと、「免許くらい取れば良いじゃないか」と何気なく言われるくらいには…。


持たざる者だからこそあこがれる「免許」としての資格


情報処理技術者試験をはじめとするIT系の資格試験は、実は単なる認定資格にすぎない。自動車運転免許のような、「それを保有していないと行為が許されない」という強力な「免許」としての資格ではない。

今年から、情報セキュリティスペシャリスト試験(SC)が、情報処理安全確保支援士(登録セキスペ)という別の試験に変わり、IPAはこれを「名称独占資格」だと売り込んでいる訳であるが、しょせんは「名乗るのに登録が必要」というだけであり、IT業界の反応は冷ややかである。

情報処理安全確保支援士(登録セキスペ)として登録したからといって得られるメリットは、あくまでもその名称を独占的に名乗れるというだけである。登録することで発生する義務や維持費用なども考慮に入れると、むしろデメリットの方が大きいとさえ思える。

現に、業界大手IT企業の対応は鈍い。


今年度は、思うところもあって、非IT系の分野の勉強をはじめたいと思っている。

そこで目指したいのは、「業務独占資格」や「必置資格」の分野である。

くだらないと思われても良い。

自動車運転免許すら持っていない私にとっては、それがどんなに些細な資格であっても、あこがれなのである

例えば「第二種電気工事士」とか、例えば「危険物取扱者乙種4類」とか。(あくまでも例だが)

持たざる者だからこそあこがれる「免許」としての資格だ。


10年後には絶対に来るであろう、我々就職氷河期世代(日本版ロスト・ジェネレーション)が社会から閉め出され、過当に競争せざるを得なくなる時代に向けて。

kf7757.hatenablog.com


システム開発の上流工程に向く人と向かない人…(単なるグチ)


システム開発の上流工程に向く人と向かない人…(単なるグチ)


今回の記事は要するに単なるグチにすぎないので、そのおつもりで軽く受け流していただきたい。

ちょっとばかり、最近、思うことがあったので、特に整理せずに書いてみたい。


1.(仮定)とある航空業界の航空路管理システムというものがあったとする

いわゆる特定業界/業種のユーザー企業の、基幹系業務システムを考える。

ここでは仮に、とある航空業界のとある空港の業務システムがあると仮定する。(実際にはそのようなシステムはないだろうし、私はそもそも航空業界には属していない)


【システムの概要】

とある空港における、特定の複数本のランウェイ(滑走路)と、その前後の工程を意識した、特定の航空機材(航空機)のたどる航空路の管理・表示を行う。

主要機能のひとつに、航空機材の状況予測を計算表示するというものがある。

【今回のユーザーの要望】

上記の状況予測のための専用の計算仕様を全面的に変更したい。

計算の大まかな考え方はできているが、それを現行システムにどのように当てはめたら良いかは、ユーザー側もわかっていない。


2.ユーザー企業の業界の常識

例えば、順不同に挙げても、下記のような常識が存在する。

  • 航空機は自力ではバックできない

  • ランウェイの両端に書かれている数字には特定の意味があり、ランウェイの呼び方もその数字が用いられる(つまり同一のランウェイでも呼び方が2つ存在する)

  • 離陸、着陸を、どの方向に向かって行うか、またはどのランウェイを使用するかは、その時の風向きによって常に変化する

  • 航空路の工程には、例えば空港から半径9km以内からは、タワー管制域になるなど、複数の工程が存在する

  • 空港のスポットとランウェイ、またはその他の格納庫などへの移動(タキシング)のルートは、パターンがいくつもあり、状況によって常に変化する

  • 管制官の許可なくランウェイをタキシングで横切る事はできない

  • ディパーチャー用の航空路、アライバル用の航空路が、それぞれ存在する

……などなど。

実際には、他にも大量の、専門知識が無いとわからないような常識も存在する。(上記にも少しだけ専門用語を混ぜてみたが、これらの用語も業界にとっては専門用語でも何でもなく、当たり前の用語である、と仮定する)


業界にとって、これらは「常識」の範疇であるため、わざわざそれらを丁寧に知らない人向けに解説したドキュメントがあるわけではない。


3.その業務システムに熟知している者は自分以外にはほとんどいない

そもそもユーザー企業側や、私の所属組織の、人材育成面の欠陥かもしれないが、そのシステムの中身をいろいろ知っている者は、今となっては自分のみという状況にある。

以前の記事でも書いたが、ユーザー企業側は、いわゆる中央官庁などと同じで、どんどん官僚化が進んでいる。


kf7757.hatenablog.com


また、どうやら私の所属組織の中から新たな人材も投入できないらしい。

最上流工程の要件定義のうちだけなら、まだ自分ひとりだけでも何とかなるかもしれないが、実際にシステムを再設計/プログラム修正/テストの作業を行う場合、とても一人では回せなくなる。

そのため、上流工程から、いわゆる協力会社に入ってもらう事にした。

協力会社は、IT業界では有名な大手IT企業となった。(はっきり言って私の所属組織などよりはるかに立派な会社である)

なお、今回の業界や、特定の業務システムに対する経験値は、あまり高くはない。


4.意識の差による平行線

名のしれた大手IT企業だと言う事もあり、一緒に仕事をして行くパートナーとしての協力会社メンバーには、けっこう期待は大きかった。

投入してくれるSE(システムエンジニア)も、いわゆる上流工程の経験を持つSEだろうと思った。

自分で言うのも何であるが、この仕事は、人によって、もしくは会社によっては、「お金を払ってでも経験したい仕事」であると思っている。

下記の記事でも書いたが、特定業界の特定システムの知識とは、実はそれくらい貴重なのである。


kf7757.hatenablog.com

kf7757.hatenablog.com


しかし、一緒に検討を進めて行くうちに、意識の差がある事に気がついた。


【私の意識】
  • いまやっている作業は上流工程(要件定義)であるが、ユーザー側からの強い牽引力は全く期待できない。しかし、これは見方を変えれば、我々システム開発者側が主導して、アーキテクチャー設計を含めて提案できる状況である

  • まだ基本設計でも無い要件定義の段階なので、作成する資料は100点の完成版である必要はなく、60点のたたき台である。それを検討の場でブラッシュアップして行くのが良い

  • ユーザー側の担当者は、システム的な「ファイルの図形」「フロー図」などを見てもピンと来ない種類の人達である。従って、システムの全体像をざっくりと把握できるような(俯瞰的な)概要資料が必要となる

  • 上記の概要資料は、システム改訂を行う我々にとっても今後有用になる。何故なら、それが書けないとシステムテスト計画が作成できないからである

  • システムの調査作業にはいろいろな方法があるが、今回の場合は、どの部分を改定しなければいけないかが、大まかにはわかっている。従って、その部分を起点として、業務目線で影響調査を行って欲しい

  • システムの設計書などのドキュメントには業界の常識を前提とした記述が多い。自分もその常識の中に居る人間なので、素朴にわからない用語や概念などがあればどんどん質問して欲しい(もちろん、現行システムのドキュメント一式は全てお渡しする)

【大手IT企業メンバーの意識】
  • ユーザー側の要望事項が全ての出発点である。(システム開発者側からどんどん提案して良いという事を言うと驚かれる)

  • 次回の検討会までに作成すべき資料の内容は、いまの打ち合わせの中で詳細まで確定しないといけない。そうしないと作業にムダが生じる

  • 概要資料を作りたいという言葉の意味はわかるが、それを作成するにはシステムを隅々まで調査しなければならず、時間が非常にかかってしまう

  • システム概念図のような資料は自分たちなりに作成して来ているが、それでも「ユーザー側にはピンと来ない」と言われると、もはや何を作成して良いかわからない

  • 今回変更となる画面項目などのキーワードを起点として、grep検索などを行い、ボトムアップ的な影響調査がどうしてもメインになってしまう

  • 例えば「宿題」でも良いので、「次回までにこれを調べて来てくれ」といったような具体的な指示が欲しい。それがあると作業が楽である


断っておくと、私は協力会社の方を否定するつもりはない。

おそらく、言っている内容は間違いではない。

ただ単に、意識の差がある。

それだけだろう。


5.ユーザー側はシステムには全く興味がないし、システム開発者(ITエンジニア)の多くはユーザー業務には全く興味がない

官僚気質が強い大企業や、中央官庁などのシステム担当者と話をするとよくわかるのだが、彼らは、システムの事など全くといって良いほど興味がない

中には、自作PCが好きなどという人も居るが、PCの世界と、システム開発の世界は、また別である。

興味がないという事も、無理からぬ事である。

システムの話は業務のいっかんでついでに覚えられるほど、生易しいものではない。従って、覚えるとなると、相当に頑張らないといけない訳であるが、そこまでして、本業ではない分野を覚えたとしても、2~3年で定期異動になってしまう事を考えると、意義が見いだせないのである。

あまつさえ、システム開発/保守は、アウトソーシングしてしまっている。現場からの問い合わせ業務さえもヘルプデスクとして外注している現状がある。

一方で、本業の業務面はどうかと言うと、これもまた、先に別の記事で書いた通り、支社/支店などの「現場側」に知識が集約される形になり、定期異動でコロコロと部署異動をするため、深い知識はなかなか身に付かないという事になる。


システム開発者の方は、良く言われているように、一般的には、

ユーザー企業 > 大手IT企業 > 中小IT企業 > 中小IT企業 (1例)

…などといった、多重請負構造の中で、どうしても末端近くに位置するエンジニアのユーザー企業に対する帰属意識は希薄となり、それに伴ってユーザー企業の業務への興味も薄れていく傾向がある。

先の別記事にも書いた通り、ユーザー企業の特定分野/特定業務システムの知識を買われて、ユーザー企業や、そこに近いIT企業に誘われて転職する事例もあるのだが…。

しかし、こういった情報は、内容の性質的にも、秘密裏に行われているので、なかなか一般には知られていないのが現状である。


上記のような、「システムには知識も興味もないユーザー側」と、「ユーザー側の業務には興味がないシステム開発者」との、仲立ちをうまく行える人材が、実は最も不足している。

一般的には知られていないが、こういう人材が本当はとても貴重。

花形と思われる「インフラエンジニア」は、実は世の中には数多く居る。そのため、過当競争になっているのである。


6.大手IT企業の人といえども上流工程はなかなか難しいのかな?

上述したような、「システムの事など知らないし興味もない」という人と打ち合わせを数多くすれば、「システム概念図」などのシステム屋がよく作成する資料が、いかに相手に『響かない』かが、わかるだろう。

システム屋から見て、ユーザー業務側の専門資料が非常に難解であるのと同じように、例えば入出力設計書などの、システム屋からすればユーザーにレビューしてもらう対象ドキュメントであっても、それがユーザー側から見れば非常に難解なのである。

例えば元請けIT企業でユーザー側と直接折衝をしている人が居るとして、そういった人は、プログラミングなどは体制的にやらない訳であり、そういった人を小馬鹿にするエンジニアも多くいるが…。

前項で書いたような、ユーザー側とシステム開発者との間を仲立ちする役目を担っているのであれば、それは価値のある仕事であると思える。(一方で、それすらも放棄し、下請けに丸投げしているようなら、たしかに小馬鹿にされても致し方ない)

この役割は、おそらく経験しないと、わからない。

どんなに大手のIT企業のエンジニアだとて、そういった経験がないと、わからないのだろう。


さて…。

上記のような思いを強く思った5月の私なのである。

本当にどうしようかな。


(注1)上記に挙げた業界や業務システムは本当にこの場だけの架空の例です。

(注2)私は航空業界とはいっさい関係ありませんし、専門家でもありません。細かいツッコミもあるかもしれませんが、暖かな目で見てください。


「終身雇用はもう古い」に対する反論…「給料の年功序列」をやめれば良いだけ


「終身雇用はもう古い」に対する反論…「給料の年功序列」をやめれば良いだけ


様々なところで言われている「いまの時代には終身雇用なんて合わない」「終身雇用なんてもう古い」という言説に違和感を覚える。

この言説は、多分に労働者側ではなく、使用者側、つまり経営者側の都合を含んでいる。

終身雇用(正社員など)に関する規制を緩和したところで、得をするのは労働者側ではなく、圧倒的に経営者側であると思える。

就職氷河期世代:日本版ロスト・ジェネレーションに、一応含まれている世代である私から見てもそう思える。(但し、この失われた世代に対しては、別途、救済する制度は必要であると考える)


「終身雇用」だからといって「給料を年功序列にする」必要はない


「終身雇用は維持できない」という言説には、必ずと言って良いくらい「年功序列が維持できない」という論理がセットになっている。これが不思議でならない。

ここで言う「年功序列」は、つまり「給料が」という意味合いが強い。

多くの労働組合は、一般的な家庭における「生計モデル」と、それに見合った「賃金カーブの維持」を主張してきた。20歳代で結婚して、30歳前後で第一子を授かって、40歳代に子どもの教育費などがピークになって、という「生計モデル」である。

この生計モデルは、私の世代からすると、もう古いと言わざるをえない。良い悪いは別にして、このモデルは既に崩壊してしまっているのだ。

崩壊している生計モデルを論拠とした、「賃金カーブ」の維持は、確かに時代に合っていないと感じる。

しかし、その事が、「正社員の規制が古い」とか、「終身雇用はもう維持できない」という考えに発展、飛躍する事が、正直、理解できない。

けっきょく、右肩上がりの「賃金カーブ」だけ見直せば良い話ではないのか。


使用者側と労働者側との合意が軽視されている現代


かつての昭和中期時代の高度成長時代のような、「サラリーマンは気楽な稼業」という幻想は、確かにもう古すぎてお話にならない。

いつまでたっても成長しようとしないような問題社員が居る場合には、しっかりと評価を行った上で、処遇を落とすなどの措置は当然、行われるべきである。そしてその状態が一定期間、改善が見込まれない場合には、退職をしてもらう。企業だって営利団体なのだから、その点は当然である。

これは過去の終身雇用が主流だった時代でもあった事である。ただし、いきなり労働者側の都合や言い分を無視して、使用者側の独裁で行われるのではなく、できるだけ話し合いを重ねた上で、お互いに合意した退職を目指す。

いまの時代、この点が軽視されている場合が多いことが問題なのである。

その「お互いの合意という点が軽視される状況」がはびこっているのが、いわゆる「非正規雇用」の世界や、形式上は「正社員」であっても実質的には「人月商売による派遣」もしくは「偽装請負」が横行している世界である。

このような世界には「使用者側の利益」しか存在しない。

しかし、それは使用者側にとっても「短期的な視点での利益」でしかなく、「中長期的な視点での利益」では、むしろマイナスなのではないだろうか。


「終身雇用」だからこそ中長期的な人材育成が可能


長い職業人としての経歴を積む中では、時には研修を受けたり、すぐには結果が出ない勉強期間も必要である。

そういった個人としての中長期的な成長を考える場合、終身雇用の考え方は利点が多いと思える。

個人としての成長を促すことで、企業としても中長期的には競争力が増加する。


「終身雇用」という言葉が悪ければ他の言葉でも良い


重要なことは、

  • (基本的には)自分から転職を望まない限り長く働ける職場

  • 中長期的な成長を配慮してくれる職場

  • 育児や介護などといったライフステージ変化にも配慮してくれる職場

…が、制度的に確保される事である。


「旧態依然の終身雇用にしがみついている人々が、非正規雇用の職を奪っている」という言説によって、労働者同士の対立を煽るのは、ブラックな使用者側の狡猾な洗脳なので、それに騙されてはいけない。

「時代に合わない年功的な賃金体系」がある故に、「あの中高年社員はろくにパフォーマンスを上げていないのに高い給料をもらっている」などという不公平感が出てくるのである。

パフォーマンスが悪くなれば、待遇も下げるのは当然の事である。

ただし、順当に経験値を積み上げてきた中高年社員であれば、必ず特定の強みを持っていたり、莫大な経験値のみで大抵の判断ができるため、頭の力をより創造的な面に使ったりできるようになっているものである。

そういった価値は、やはり評価されるべきであるし、日本においては、『失われた20年』によって、取り返しがつかないほど、喪失してしまった真の労働力なのである。

「知ったかぶり」からはじめよう


「知ったかぶり」からはじめよう


はじめは誰もが初心者・初学者である。学問でも仕事のとある領域でも。

人は何者かのフリをする事からはじめ、そうする事で、その何者かに近い存在になって行く。

何かの専門家になりたいと思うなら、その専門家のフリからはじめれば良いのである。


一応、普通の職業人として20年程度、様々な人を見てきたが、何年たっても「その道の専門家」にならない人、「その道の専門家」として周囲からも一目置かれる人、両方いる事がわかってきた。

ここで断っておく事は、必ずしも専門家になる事がすべて良い事である、とは言い切れないという事である。人には「向き不向き」がある。「ゼネラリスト」も世の中には必要であると思う。

その上で、私は個人的には、専門性を高めたいし、これからの世の中に強いのは専門性を高めたスペシャリストであろうと思っている。これはここでも何度か主張してきた事である。


「わからない」と言っているうちは「わからない」


日本人は控えめな方が好まれる。そう思っている人も多いようである。

しかし、仕事において、必要以上に謙遜して「自分はよくわかっていないんですが」と言うことは、マイナスでしかない気がする。

例えは悪いかもしれないが、よく「仕事はできる人に集中する」と言われている。

情報や知識も、実は同じである。たくさん持っている人に、より多く集まってくる。

「わかっていない人」よりも、「わかっている人」に、より多くの情報が集まる。


自分はこの分野をよくわかっていない。よく知らない。

謙虚に自分自身の中で思う事は大切であるが、それが過ぎると、自分に対する言い訳になってしまう。

確かに100点満点の知識はない。でも、60点位の知識はあるかもしれない。

こういう場合、まだまだ100点ではないから「自分はよくわからない」と思い、人にもそのように言うか、もしくは、60点くらいは知っているので「自分はまずまず知っている方だ」と思い、そのように振る舞うか。

実は、100点満点の人など世の中にはほとんど居ない。

従って、前者では、いつまでたっても「自分はよくわからない」と言い続ける。一方、後者は「自分はまずまず知っている」と思い、そのように振る舞う事によって、自然とその知識をさらに高めていく。


「はったり」をそのままにしない


専門家のフリをするという事は、時には「はったり」をしてしまう事もある。

ここで重要な事は、せっかく打った「はったり」をそのままにしない、という事である。

「はったり」を打つ。そうすると、その後、自分の中では、「あのはったりは正しかっただろうか」と必死に思いが駆け巡る。

なお、知識がゼロの人には「はったり」は使えない。知識がけっこうあるからこそ、できる事でもあるのだ。

従って、「はったり」は割と当たっている事が多い。しかし、自信が無い。そこで、上記のように、「はったりは正しかったか」を後でしっかりと検証する。

検証することで、その知識は定着する。


こう言う私も、最近、仕事疲れで勉強が進まない。フリばかりしていないで、早く本当に知識を付けなくてはと思う次第である。

【速報】5月24日(水曜日)のネット界隈で気になった話題をツイートでまとめてみた


【速報】5月24日(水曜日)のネット界隈で気になった話題をツイートでまとめてみた





プログラミング的な思考を身につけるのなら、数学の復習も大切のような気がする


プログラミング的な思考を身につけるのなら、数学の復習も大切のような気がする


最近、休日には、どちらかと言うとIT系ではない分野の本やWebページを良く見ている。

ズバリ言うと、数学である。

普段の業務では日本語力しか鍛えていない感があり、中学生、高校生レベルはもちろん、下手をすると小学生レベルの算数も、問題が解けるかあやしい状態にある。

そのような状況で、改めて数学の書物を読むと、かなり新鮮な気分である。

特に対数(log何とかというやつ)などの考え方は、今になって改めて読んだり聞いたりすると、論理的な思考の展開とはこういう事なのか、と感嘆する。コンピュータや電子卓上計算機が存在しなかった昔に、こんな概念を考えるなんて天才かよ、とも思う。


以前、とある識者が、こんな事を言っていた。

「プログラミング教育の義務化」という言葉だけがひとり歩きしているが、その真の意味は「プログラミング」のみを義務化するのではなく、「プログラミング的な思考」の教育を義務化するという意味だ。


という事であれば、いきなりプログラミングという話ではなく、まずは数学の授業をもっと面白く、脱落者が出ないように工夫して、数学的な思考力を高めるという方策も有りなのではないか、とも思える。

まぁ、単に、私がいま、数学の復習をしているから、そんな気分になっているだけなのかもしれないが。


数学を何のために復習しているのか


思うところがあり、「電気数学」を勉強しはじめている。

自分が知っている専門領域を少しでもズレると、こんなにも基本的な事がわからない、難しいのだ、と驚愕する思いである。

コレは短期的に何かを収穫するための勉強というよりは、中長期的な事を考えている。

以前の記事にも書いたが、あと10年もすると、私が属する世代はどんどん職場から閉め出され、大競争時代になるだろう。(職場から閉め出されても年金がもらえる訳はなく、また働かないといけなくなるだろう)

その時に、たぶん、ありきたりなSEの経験なんて、評価されないような予感がする。

…まぁ、そんな思いだけはある。


こんな本が欲しいのでポチった

理系人のための関数電卓パーフェクトガイド〔改訂第一版〕 (とりい書房の“負けてたまるか”シリーズ) 遠藤雅守 (著)

https://www.amazon.co.jp/dp/4863340753/ref=cm_sw_r_tw_dp_x_Kusizb3ES26SSwww.amazon.co.jp

この本は「なか身検索」や口コミを見ると良書のようなのに、既に絶版になっている模様。

何故なのか。

精神障害者福祉手帳というものがあるのだが取得した方が良いのかどうか…


精神障害者福祉手帳というものがあるのだが取得した方が良いのかどうか…


来年度(平成30年度:2018年度)から、精神障害者雇用の義務化という法律が施行されるらしい。(実際には「義務」というほどの事ではないらしいが、障害者雇用率のカウントに精神障害者が正式に加えられるようだ)

それがあるせいなのかどうなのか。

先日、職場の保健師さんから、手帳を考えたことがあるか、と訊かれた。

考えたことがまったくないわけではないが、私の場合、確かに数回、長期に会社を休んでしまう事があり、その最も長いものが昨年までの三年間という期間だった訳であるが、正直、自分が『障害者』なのかと自問すると、どうなのか、と思う。

それに、私の場合は、申請が通ったとしても3級だろう。

精神の障害者手帳3級は、別に年金が出るわけでもなく、ほんの少し公共交通やサービスが割安になったりするだけである。


果たして身を守るものになりえるのか


手帳を持つことのデメリットは、私としては、職場などの人事情報に「精神障害者」として記録が残ることだと考える。

それは、身を守る盾になってくれる場合もあるかもしれないが、かえって不利な扱いを受ける可能性も捨てきれないと思える。

組織は、結局のところ、過去から連綿と引き継がれてきた人事情報で判断するものなのだから。


メリットは、多分に経済的な面であると思える。些細な事だが携帯電話料金なども割安になるらしい。

そして、上にも書いたが、やはり身を守る盾になりうるか。

これに尽きる。


自分は精神障害者なのかという根源的な問い


あとは、根源的な問いである。


(今回の記事は、書こうか否か、正直迷いましたが、率直に書きました)

いま話題の経済産業省若手官僚作成資料を読んで…我々団塊ジュニア世代は見逃しストライクアウト世代か…


いま話題の経済産業省若手官僚作成資料を読んで…我々団塊ジュニア世代は見逃しストライクアウト世代か…


経済産業省若手官僚が作成した「不安な個人、立ちすくむ国家 ~モデル無き時代をどう前向きに生き抜くか~」という資料がネット上で話題となっている模様である。

http://www.meti.go.jp/committee/summary/eic0009/pdf/020_02_00.pdfwww.meti.go.jp


どうやら、書かれたのは1980年代生まれ中心の若手官僚であるようで、そうすると、現在30歳を少し超えたくらいの者たちだろうか。

経済産業省に入省して10年前後というエリートさんたちである。


団塊ジュニア世代は「見逃しストライクアウト」であったようだが…


この資料の最後から2ページ目の64ページを引用して貼り付けます。


f:id:KF7757:20170520104501j:plain


この表現を見るに、我々団塊ジュニア世代は、既に見逃しストライクでアウトになっているようだ。

一応、解説しておくと、この「見逃し三振」という表現は、スポーツの野球に例えられている。

野球で「三振」はアウトとなる。


まだまだストライクアウト(過去形)にしてほしくはない


ストライクアウト(過去形)にしないでいただきたい。

40歳代の就職氷河期ロスト・ジェネレーション)の最先頭世代を、過去のものとしないでいただきたい。

いま30歳の君らからすれば、既に過去なのかもしれないが、多分に君たちの世代のモデルケースになり得る世代である。

頼むよ。

労働時間はやっぱり重要だと思う


労働時間はやっぱり重要だと思う


最近、職場を通じて、とある外資コンサルタントが開催している、業務時間が終わってから参加するタイプのセミナーの話を耳にした。

そのコンサルタント曰く、『その時間でも参加するような人はやる気があるので、そういう形式を続けている』とのこと。

直接、そのコンサルの人から聞いた訳ではない。だから文脈もわからない。

それでも、上記のような言葉として、私の耳に入ってきた訳である。


「業務時間が終わってから(夜)でも参加する人」を、「やる気がある人」と評価する、という事は、厳密に言えば、必ずしも「業務時間が終わってから(夜)は参加しない人」を、「やる気がない人」と評価している、とは限らない。

それはわかったうえで。

それでも、「業務時間が終わってから(夜)は参加しない人」を、「やる気がない人」と評価しているのではないか、と疑いたくなる言葉ではある。

仮に、その疑いがある程度当たっていたとするならば、その外資コンサルタントの考え方も、いまの社会には合わない、古い考えだなぁ、と思った。


「楽しければ長時間でも耐えられる」というのは間違い


以前、とあるエンタメ系の企業の経営者が、「ホワイトカラーの仕事は時間で測るものじゃない」とネット上で発言をして、炎上した。


創造的な仕事を、集中してやる場合は、アドレナリンが出てきて、楽しい。そういう時には「労働時間」という概念で規制する事はマイナスである。


こういう言い分である。

しかし、これは危険な考えである。

下手をすると「ブラックな職場」を作ることになる。


アドレナリンが出ているという事は、脳内麻薬が出ているという事である。

一時的に栄養ドリンク剤で気力を奮い立たせているのに似ている。

無論、ひたすらツライ仕事よりも、何らかの創造性がある楽しいと思える仕事の方が、ストレスは感じにくいとは思う。

しかし「ツライ」「楽しい」に関係なく、人間の心身は疲弊する。

だからこそ、これだけ「残業を減らさなければ」という声があがっているのである。

「楽しければ長時間でも耐えられる」と言っている人は、たまたま自分の心や身体の限界まで頑張ったことがない人であると思う。

人間はしょせん生物なので、心や身体には限界がある。


ちゃんとした企業(比較的大企業に多いが)では、管理職や裁量労働制の社員であっても、「総労働時間の管理」を行うように指導している。

それは、管理職や裁量労働制の社員でも、長時間労働が心身の健康を損ねる傾向がある事には変わらないという統計を持っているからである。


どんなに素晴らしい内容のセミナーであったとしても、業務時間が終わってからの、かなり疲れている状態で受けるというのもどうなのだろうか。その程度の事で「やる気」を測ってほしくはないものである。

近年の基本情報技術者試験の参考書から消えたモノたち…(データ表現・ファイル編成形式など)


近年の基本情報技術者試験の参考書から消えたモノたち…(データ表現・ファイル編成形式など)


シラバスには記載があるのに、事実上出題されないと判断されている情報がある。 (複数の最新参考書を確認したが記載がない)


数値の表現における2進化10進法(BCD

10進数のデータを、10進数の考え方のまま内部で保持して、CPUやメモリといった最下層レイヤでも10進数のまま演算を行うというもの。

汎用機(メインフレーム)の世界では今でも使用されている。

メリットは、基本的に『数字』(つまり文字コード)で表現されている外部との入出力データを、『2進数に変換する』という危険を敢えて冒さずに内部処理を行う事で、金額データに対する利息計算などの「誤差を許容できない」世界で、より安全に処理ができるという点。

システム的なメリットというよりも、人間系による処理内容の「検証」の容易さなどといった、社会的なメリットの方が大きい。


ファイル編成の種類

オープン系プラットフォーム(UNIX/Linux系、Windows系)における「ファイル」は、最下層レイヤでは、それぞれのOSが採用している「ファイルシステム」の種類に依存した形式で作成される。しかし、ファイルシステムの違いをOS側が吸収してくれるため、どのOSにおいてもファイルの扱いはほぼ同じであり、ファイルの作成や更新は、アプリケーション側から随時システムコールを行う事で実行される。DBMSなどの特殊なアプリケーション以外は、事前にカタログを行う必要はなく、ファイルの種類を宣言する必要もない。(バイトストリーム)


汎用機(メインフレーム)の世界においては、一般的に下記のようなファイルの種類があった。

  1. 順編成ファイル(SAM:シーケンシャル・アクセス・メソッド)

  2. 索引付き順編成ファイル(ISAM:インデックス・シーケンシャル・アクセス・メソッド)

  3. 区分編成ファイル

  4. 多重索引付き順編成ファイル(MSAM:マルチプルインデックス・シーケンシャル・アクセス・メソッド)

  5. 仮想記憶編成ファイル(VSAM:バーチャル・ストレージ・アクセス・メソッド)

基本的に汎用機やオフコン文明のOSにおいては、ファイルは作成前に必ず「領域の確保」を行う必要がある。(カタログ)

1.のSAMファイルは、最も単純なデータファイルとして使用される。2.ISAM、4.MSAM、5.VSAMなどは、何れもSAMファイルの発展系であり、順アクセス以外の、キー値指定によるダイレクトアクセスが可能となっている。但し、DBMSのような「ロールバック機構」はないため、更新前の状態に戻すには、バックアップから復旧が必要となる。

3.の区分編成ファイルは、UNIX/Windows系におけるディレクトリ(フォルダ)を1階層だけ内蔵しているようなファイルである。中はメンバーという更に細かいデータとして区分されており、各々のメンバー内に、プログラムソース、プログラムオブジェクト、プログラムロードモジュール等を格納する。

区分編成ファイル内のメンバー情報を保持している部分を、TOCと呼んでいる。

なお、汎用機系においては、IBM/MVS系、およびその互換機(富士通FACOM、日立HITACなど)のOSが大きなシェアを獲得していた事から、IBM系の概念がそのまま使われている。IBM用語でいうと、上述した「ファイル」は、「データ・セット」という用語になっている。


SAMファイルとかは、いまでも言葉としてはよく使われているイメージがある。

プライバシーポリシー/お問い合わせ