IT (情報技術) 学習記録

主に情報処理技術者試験等の、IT・ICT系、または電気通信系資格の学習記録を中心に。働き方、世の中も。

実行力が伴わないマネジメントは無意味です(前回の続き)


実行力が伴わないマネジメントは無意味(前回の続き)


(現在、電験三種の試験前の追込み時期で、本来はこんな記事を書いている場合では無いのですが、ちょっと現実逃避気味で、短めに書きます。)


  • 綿密なスケジュール(WBS)を立案しましょう

  • 現実的なプロジェクト計画を作成しましょう

  • 現実的な体制表・体制図を作成しましょう


これ自体は否定しません。むしろ正しいです。

ないよりは、ちゃんとした上記の計画があった方が、良いに決まっています。

でも…。

上記『だけ』では、ダメなんです。


上記の計画を、『実行できる人材』『実行できるスキル・能力』が伴う必要があります。

かんたんなことを言っています。

上記の計画を、『実行できる人材』『実行できるスキル・能力』が伴っていないと、

結局、上記の計画が、動きません

結局、上記の計画が、動かずに、すぐに計画倒れになってしまいます


大規模システムをスクラッチで開発するプロジェクトであれば…、

  • 業務仕様をまとめて調整できる顧客サイドのキーマンが必要

  • 顧客サイドの業務仕様をシステム仕様に落とし込める現場リーダーが必要

  • 現場リーダーの意思に基づいて実際のシステムを構築できるエンジニアが必要

(※注)


かんたんなことを言っているつもりです。

そして、当たり前のことを言っているつもりです。


近年、電気工事士などをはじめ、IT系以外の領域の勉強をしています。

そのため、なおさら、IT業界を第三者的に見られると思っているのですが…。

電気の世界なら、電気の素人に電気工事はさせません。

間違った施工をすると、事故・災害・人身事故につながります。

ところが…。

IT系の世界では、けっこう無理なプロジェクトが横行します。


別に否定的な、悲観的なことを強調しているつもりはありません。

あたりまえのことを言っています。

上記(※注)で挙げたような人材が集められなかった場合は、

そのままではプロジェクトは進行できないんです

進行できないならば、進行できるような状況に持っていくほかはないですよね。

つまり、「計画ありき」ではなく、「集められる人材(戦力)」に見合ったプロジェクトにするのです。


あたりまえのことがIT業界では通用しないと思えましたので、現実逃避も兼ねて書かせていただきました。


kf7757.hatenablog.com


「プロジェクトマネジメント」だけでは無意味である理由


「プロジェクトマネジメント」だけでは無意味である理由


経済産業省の外部組織であるIPA・独立行政法人情報処理推進機構が中心となってとりまとめた、ITSS(ITスキルスタンダード)の、バージョン3が公開されてから、8年経過した。

ITSSそのものの成立から合わせると10年以上が経過した現在、それなりに、IT系企業を中心に、それを取り入れた人事制度(日本型のエセ成果主義と融合してしまった感じもあるが)も広まってきたように思える。


私の観測範囲では、あいかわらず「大規模開発プロジェクト」がうまく運営できずに炎上していることを多く見かける。

自身も、巻き込まれることが多い。

炎上プロジェクトが発生するたびに、経営層は決まって「PM力が足りない」「PM力を養成しなければ」と声高に言う。

PMとは、プロジェクトマネジメントのことである。

…まぁ、そういうことを声高に言う経営層は数年ごとに任期を終えて入れ替わっていくわけだが…。


炎上プロジェクトで必ず発生すること


炎上プロジェクトで、まず必ず発生することは、

現場リーダー(PL・SLなど)とプロジェクト運営陣(PM・PMOなど)の対立

…である。

その対立は、必ずしも表面化はしないこともあるが、裏も含めれば必ず発生している。

そしてその対立は、極めて深刻な場合が多い。


問題の根底には、人材不足がある。

開発プロジェクトの要は、現場リーダーである。

実は開発プロジェクトで最も必要とされ、常に不足が言われる存在は、現場リーダーなのである

既存業務、現行システムの知識などが(比較的)豊富であり、その組織での開発経験がある人材が、現場リーダーに登用される。

小規模なプロジェクトであれば、現場リーダーだけでプロジェクト運営も可能だ。

その組織での開発経験を積むことで、自然と、プロジェクトマネジメントの能力も磨かれる。


しかし、大規模プロジェクトになると、現場リーダーだけでプロジェクト運営を行うことが不可能になってくる。

そこで、PMOなどのプロジェクト運営を主に担う者が必要となる。

プロジェクト運営を主に担う者。

この役割に適した人材は、奇しくも、現場リーダーの要件とかなり重なってしまう

だが、実際には、ただでさえ担い手が少ない現場リーダーの要件を満たすような人材が、あえてプロジェクト運営に回されることは非常に少ない

そのため、現場ではない場所(組織外・中途採用者など)から、埋め合わせをしようということが発生する。


こうして登用されたプロジェクト運営を主に担う者。(PMOなど)

当然ながら、その組織での開発経験は無いという者も多い。

その者自身に、スキル上の問題があるという訳ではない。

だが、その組織での開発経験がなく、開発対象の業務やシステムに対する知識もない。

こうした状況で、いきなりプロジェクト運営を主に担うと、必ず、現場リーダーと対立状態になってしまう

つまり、こうした登用のしかたが、そもそも間違っているのである。


よほどのスーパーマン、いろんなプロジェクトを渡り歩き、問題解決のために辣腕を発揮してきた、というような人材ならば、別かもしれない。

しかし、実際にはそのようなスーパーマンはほとんどいない。

スーパーマンではないことが悪いことではない。


職種「プロジェクトマネジメント」にエントリレベルが存在しない理由


ITSSの定義上、職種「プロジェクトマネジメント」にレベル1~2は存在しない。

レベル1~2は、エントリーレベルとされている。

職種「プロジェクトマネジメント」は最低レベルでもレベル3と定義されている。

組織によっては、職種「プロジェクトマネジメント」はレベル4から開始という組織も多いと思われる。


これは、開発現場に当てはめて考えるならば、最低でも現場の主担当として業務をそれなりに経験した人、可能であれば現場リーダーを経験した人が、やっとスタートラインに立てる職種だということである。

開発や保守の経験を主担当としてリーダーになるまで積む中で…

  • 対象業務知識の蓄積

  • 対象システム知識の蓄積

  • 汎用ITスキルの蓄積

  • プロジェクト管理・マネジメントスキルの蓄積

…が行われる。

その中で、特にプロジェクトマネジメント系の業務に向いている、と組織も認知し、本人も自覚する場合に、はじめてプロジェクトマネジメント職種への転換が行われる。

ここで重要なことは、上記でいうところの1番目と2番目の要素である。

当該組織・当該企業固有の業務やシステムの知識も十分に知っているという点が重要となる。

つまり、「PM力」のみを伸ばす、とか、「PM力」のみの人材、というものは、そもそも存在し得ない。


「PM力が足りない」「PM力を養成しなければ」ではなく、

「現場リーダーが足りない」「現場リーダーを養成しなければ」

という方が正しい。

無論、現場リーダーこそ、最も養成や確保が困難な存在であることは、上述した通りなのだが…。


ITエンジニアの世界は参入障壁がとても低い


ITエンジニアの世界は参入障壁がとても低い


ITエンジニアの世界は参入障壁がとても低い。

これは事実だ。

良くも、悪くも、である。

私が勤務している組織は、まったくたいした組織ではないので恐縮だが、毎年の新入社員の半数は非情報系(非IT系)の学校卒業者だ。

いわゆる「文系」の学生も3割くらいはいる。

それ自体、悪いことではない。単に事実を言っているだけである。


新入社員研修は、約3ヶ月。

その期間で、情報工学系の学生が経験したものと同じ学習は、当然ながら不可能だ。

うちの組織の場合、統合開発環境を使用したプログラム開発を、一通り実施するようである。

具体的には、Eclipse系の環境で、Java言語による開発がメインだ。

その他には、ネットワーク系や、データベース系の基礎も……やるのかな……。

……やっていてほしいが、その期間で、「本当の基礎」はできないだろうと思う。

SQLの触りくらいはやるのだろう。


何が言いたいのかと言うと、上記の新入社員研修では……

*「コンピュータの本当の動作原理」

*「コンピュータ・アーキテクチャ

*「OS(オペレーティング・システム)の基礎」

……といった、本当の基礎部分は、やらないのである。

正しく言えば、その期間では「できない」。


どのような分野であっても言えることだが、「本当の基礎」が、最も難しく、学習に時間を要する。

そして、「本当の基礎」を学習しても、学習しなくても、実際の仕事を遂行するだけであれば、目に見えるほど差が出ない。

コストパフォーマンスが最悪なのである。


プログラム開発などは、まさにその典型だ。

良いプログラミングを行うためには、できるだけたくさんコーディングすることが良いとされている。

それはそれで正しい。

だから、みんな「コーディングしたい」と言う。


それでも現状に満足せずに学習してほしい


一例を挙げよう。

私の先輩に、非IT系出身で、技術系の自己学習に否定的だった人がいる。

ある案件で、プログラムの実行形式ファイルはあるが、ソースプログラムが消えてしまっている状況があった。

その先輩は、「逆アセンブルで復活できないか」と言ってきた。

私が、「いくら逆アセンブルや逆コンパイルができたとしても、ソースが元通りに復元できることはありません。ましてや、コメントなどは全く復元できません」と言ったところ、それが納得できない様子だった。

コンパイルのしくみ、アセンブルのしくみなどの基礎知識がまったくないためである。


IT系の仕事に就くことだけで、満足しないでほしい。

ひどい場合だと、「Hello world!」という表示ができたことで、そのプログラミング言語を習得した気分になっている者もいる。

IT系の仕事に就くことだけなら、なんの資格も要らない。

その意味では、参入障壁は低い。

しかし、その後が、とても大切なのである。


IT系の求人情報などを見ると……

  • 経験したプログラム言語は何か

  • 経験した環境(汎用系、オープン系、Web系など)

  • 経験したプロジェクト規模は何名だったか

……といった、本質的ではない項目が目立つ。

重要なのは、そんなことではないのだが……。

あらためて、まだまだ人材開発の面で、発展途上で未熟な業界だなぁ、と思う。


COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)


COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)


まず、結論から先に言うと、

  • COBOLというプログラミング言語が悪いわけでも不備があるわけでもない

  • むしろ、優れた後方互換性によって、数十年も前のプログラムが現在でも稼働しているという特徴がある

  • 一周回ってCOBOL技術者が不足してしまったため、かえって高価値になってきている

  • COBOLで書かれたプログラムが、現在でも社会インフラを支える大企業・官公庁システムにおいて、数千万ステップから数億ステップは稼働しているし、この状況がすぐに変化することはない

したがって、

COBOLは若手が覚えるべきではない」

とか、

COBOLはもうすぐなくなる」

......と言った言説は、的を射ていない。


私が情報系の学生時代だった25年以上も前から、「COBOL」なんて古い言語はなくなるから、「C言語」を学習すべきだ、と言われていた。

(当時はJavaはまだ生まれたばかりで浸透しておらず、オブジェクト指向も同様に浸透していない時代だった)

学校の講師の普通にそんなことをいう有様だった。

当然、世間を何も知らない学生でしかない私は、それを真に受ける。「そうかぁ、COBOLなんて使われなくなるんだ」

だから、当時は珍しかった「C言語」「アセンブラ」を学習できる専攻コースに進んだ。

(確かに、学生時代に「C言語」「アセンブラ」といった低レベル言語系を学習できたのは、自分にとっては財産だったと思っている)

※ここでいう低レベル言語系とは「機械に近い」という意味である。

私が就職した当時は、折も悪くバブル景気が崩壊した直後で、「就職氷河期」に入ってすぐだった。

そんな中、いま勤務しているユーザー系のシステム会社に入った。

新入社員研修で、みっちり仕込まれたのが、COBOL、および、それに関係するドキュメントの作成だった。

採用面接のときに、「C言語アセンブラをやってきました」とアピールしたのに、いわゆる汎用機系の研修に回されたことは、当時、とてもショックで、「会社を辞めよう」かと本気で思った。


紆余曲折もあったが、その後、実際の稼働中のシステム保守や、いくつもの大規模な新規システム開発に携わった。

かなり昔から業務に情報システムを組み込んできたユーザー企業だったので、COBOLプログラム資産はかなりの物量があった。

そして、保守にしても開発にしても、プロジェクト規模が大規模化する傾向があった。

プロジェクトが大規模ということは、ユーザー企業の業務特性や習慣など、まったく知らないプログラマーが短期間に大量に集められ、システムを構築せざるを得ない、ということである。

(日本的なIT業界の多重請負構造の是非などはここでは言及しないが)

また、開発が終わると長い保守フェーズに入るわけだが、保守としてプログラムを修正する人は、開発当時の人とは違う。

これが当たり前の世界。


こういう状況にあって、COBOLは、以下のようなメリットをもたらしてくれた。

  • 記述や表現が「不自由」であるため、かえって人によるクセが出にくく、誰が組んでも設計さえちゃんとしていれば、同じようなプログラムソースコードになる

  • データ項目ANK名などの管理がしっかりできていれば、後日、第三者がプログラムを追跡したり、検索したりすることが容易である

  • 記述や表現は「不自由」だが、1バイト以上の文字データや数値データの扱いは、きわめて低レベルにできる(逆に言うとプログラマーが実データを低レベルに意識しないと書けない)

  • 上記の特性があるため、「見積もり」の誤差が出にくい


特に一番目のメリットについては、昨今、COBOLではないモダン言語による大規模開発プロジェクトでは、フレームワークで吸収しようとして、それがうまく行かず、炎上しているのを、けっこう見かける。

趣味で書くプログラムではなく、仕事でつくるプログラムであり、使うのは自分ではなく、ユーザー企業(のユーザー)である。

そこに対して、「COBOLの仕事は楽しくない」「クリエイティブじゃない」とかいう意見は、まぁ、わからなくもないが…。

でも、それは個人の「仕事」に対するスタンスの問題もあるので、それが即「COBOLの仕事は若手にはやらせるな」というのは、暴論だと思う。

私は、システム開発保守の仕事で30年近い経験がある訳だが、このような「COBOLの仕事は若手にやらせるな」などという暴論を目にすると、本気でIT業界から去りたくなる。

本質的ではない、バカみたいな暴論が、まかり通ると、その業界の現場で働く人のモチベーションが低下する。


私は近年、IT系以外にも軸足を持ちたくて、電気系・通信系の学習をしている。

例えば電気系の世界で、「あそこの会社は誘導モーターを使っているから行きたくない」などという技術者がいるだろうか。

まぁ、ホテルだとか商業施設だとかは、電気系以外にもボイラー設備があるから、そこの設備管理はやりたくない、とか、そういうことはあるようだが…。


冒頭でもいったように、いまだに大企業・官公庁を中心に、金融、電気・ガスなどの公共事業といった、社会を支える重要なシステムは、COBOLで書かれたプログラムで稼働している。

この事実を無視、もしくは、歪んだ目で見て、開発現場の経験もない「日○コンピュータ」などの記者さんが、「COBOLの仕事は若手にやらせるな」などと書くことによって、経験のある自分でもモチベーションが下がるのだから、経験のない若手が「COBOL」の案件に関係する会社や部署に行かされたら、辞めよう、という気持ちになるのも無理はない。

COBOLとは、良い面、悪い面、含めて、どういう言語なのか。または、適用プロジェクトによって価値はどう変わるのか。

そういったことを、自分の経験としてとらえたうえで、「COBOL案件はお断り」と言うなら、全然問題ない。

問題なのは、経験もないのに、まことしやかに上記のような言説を吹聴する輩である。


ちゃんとした経験を持つ人であれば、たとえ個人的には「COBOL案件はお断り」であるとしても、決して他人にそれを強要することはないだろう。


俗に言う「コボラー」とは、COBOLを知っている人のことを指すのではない。

COBOLしかやったことがないし、それ以外知らないので、わかりません」

という、勉強をしない人のことを指す。


「勉強をしない人」が、嫌われるのは当然のこと。

それこそ、COBOLとはなんの関連もない。

他の言語の技術者だって同じである。


また、一方で、ユーザー企業から重宝されているCOBOL技術者もいる。

大企業や官公庁で情報システム化が進んだ当時、「業務をシステムに落とせる人」が、大活躍した。

その当時、いまでいう超上流工程である「要件定義」「検討」から話ができて、それを設計書やプログラムにまで落とし込みができるスーパープログラマーがたくさんいた。

その時の開発言語もまた、COBOLだったため、現在、大企業や官公庁で稼働しているCOBOLプログラムには、「業務をシステム化した」ロジックが大量に含まれている。

いま現在、COBOL技術者に望まれているのは、単なるプログラミングができるという側面ではなく、COBOLプログラムに大量に含まれている業務ロジックを正しく扱える能力ということでもある。


COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)

くりかえして言うが、「COBOLなんてなくなるので勉強する価値はない」という誤った言説は「25年以上前」からずっと言われ続けてきたが、現実には、「COBOLはいまでも大量に稼働していて社会を支えている」のである。


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


【国家試験】電験三種(第3種電気主任技術者試験)の難易度


【国家試験】電験三種(第3種電気主任技術者試験)の難易度


  電験三種はただいま学習中ですが、自分が今までに受験してきたさまざまな資格試験の中でも、最も難しいレベルだと改めて思います。

特に思い知る部分としては、過去問題をただ単に反復練習するだけでは、決して合格できないというところです。(無論、過去問の反復練習は必須なのですが)

問題の出題者の意図を掴んだ理解をしないと難しいような問題になっているところです。

かと言って、第二種電気工事士などが「簡単」と言う気もありません。

電気工事士もしっかり数ヶ月間、学習しないと合格できません。当たり前ですが。

特に電気系の「ズブの素人」からだと、数ヶ月は必要です。

ただし、電気工事士は、「電気工事士として最低限これだけは絶対に押さえておきなさい」という知識や技能をチェックする試験です。

逆に言えば、その要点さえ押さえておけば、合格するように設計されています。

電験三種は、明らかに違います。

問題が本当に考え抜かれていて、前述のように、「深い理解」があるかを見てきます。 そして「落とし」に来ています。

10人中1人くらいの合格で良いとされている試験です。

10人中9人は不合格で良いという試験です。

(以下は、自分が実際に受験したり学習したりして、ある程度の実感が持てるもののみを挙げています。電験二種などはまだ学習経験がないので挙げていません)


数字が大きい方が難易度が高いという意味です。


【電気系】

第二種電気工事士(筆記試験):20

第二種電気工事士(技能試験):30

第二種電気工事士トータル:50

第一種電気工事士(筆記試験):40

第一種電気工事士(技能試験):60

第一種電気工事士トータル:100

電験三種(第3種電気主任技術者):1000


【通信系(有線系)】

電気通信工事担任者3種:30

電気通信工事担任者1種:120

電気通信工事担任者総合種:150

電気通信主任技術者:750


【通信系(無線系)】

第一級陸上特殊無線技士:180

第二級陸上無線技術士:500

第一級陸上無線技術士:1000


【IT情報系】(参考)

基本情報技術者試験:250

応用情報技術者試験:400

高度区分情報処理技術者試験:500〜800


ちなみに私の所属する企業体では、電験三種は非常に低く見られています。

IoT、5Gなどの新技術領域にとっても、基礎である電気技術を広く知っていることを示す資格なのに、残念なことです。


「5G」「IoT」「AI」などと言う前に、基礎理論となる「電気工学」「電子工学」「無線工学」を勉強しよう!


「5G」「IoT」「AI」などと言う前に、基礎理論となる「電気工学」「電子工学」「無線工学」を勉強しよう!


今年に入って、私は仕事の忙しさもあるが、何より、「電験三種」(第三種電気主任技術者試験)の勉強に時間を使っている。

(このブログもそれがあって更新が滞り気味になってしまった)

電験三種の試験範囲は本当に広範囲にわたっている。

電気工事士試験とは比較にならない。

電験三種の範囲をすべて人に教えられるくらいに知っている人なら、確かに誰からも一目置かれるだろう。


ウチの親などは全く無知なので、私が先日合格した「第一種電気工事士」のほうが、「電験三種」よりも上だと思ったようだ。

頭についている「一種」「三種」という数字から、そう思うのだろう。

ちなみにウチの会社の人事部も、同じくらいにしか思っていない。電験三種第二種電気工事士が同レベルに社内的にはランキングされている。


愚痴はさておき。

ウチの会社の経営層が、盛んに「DX」(デジタライゼーション)とか、「AI」「IoT」などと言い出している。

そして、そういう領域の研修を受けなさいという。

研修を受けるのは良い。そういう領域について関心を持ち、学習するのも良いだろう。

しかし、「5G」「IoT」「AI」などという領域は、複数の領域が複合した「応用分野」である。

例えば、5Gにしても、ではそれより以前の、第一世代から第四世代までの無線通信システムについて、ちゃんとわかっているのか?……と言いたい。


IT系の分野でも、「データベースの専門家です」という人が、基礎となる「ストレージのしくみ」や「コンピュータの動作原理」を知らず、「SQLならわかります」などと言い出したら、それはニセモノだとわかってしまう。


技術領域マッピング
技術領域マッピング


回り道に見えるかもしれないけれど、応用分野をしっかり理解したいと思うなら、基礎分野から学習しないといけない。


kf7757.hatenablog.com

kf7757.hatenablog.com


第一種電気工事士合格証書GET!


第一種電気工事士合格証書GET!


第一種電気工事士」の合格証書が届いた。

第二種電気工事士」が一般電気工作物(低圧)の工事のみであるのに対して、「第一種電気工事士」は自家用電気工作物(高圧)の工事も対象になる。

正式な免状を得るには、五年間の実務経験が必要となる。

試験合格だけでは第一種の免状は得られない。そのため、この試験を受ける価値を見いだせないという人もいるようである。

だが、高圧受電設備などの高圧電気の勉強という意味では、第二種とは別物であるため、勉強する意義は大いにある。

電験三種(第三種電気主任技術者試験)を目指すうえでは、第二種からいきなり行くよりも、良い通過点になると思う。

電験と電工では、試験の難易度も範囲もレベルが違いすぎるので、電工から順番に受けるのは意味がないという人もいるようだが、私の意見は違う。

けっこう電験の講習会に電気の知識ゼロの状態でやってくる人がいる。

さすがに知識ゼロからいきなり電験はつらいはずである。(せめて電工や他の電気通信系の資格を経たほうが良いとは個人的には思う)

ちなみに、「認定電気工事従事者」の資格を得るのに、この「第一種電気工事士」の合格だけで申請できる。

第二種電気工事士」、「電験」を保有する人が同じ認定を得るには、所定の講習を修了する必要がある。


とりあえず、今年は電験を頑張ろうと思う。


f:id:KF7757:20190121210506g:plain
第一種電気工事士格通


資格/試験 取得一覧 (2018年まで)


資格/試験 取得一覧 (2018年まで)


SEQ.取得年 資格/試験名称



第一種電気工事士は、筆記試験/技能試験すべて受験した。結果待ち)

電験3種:第三種電気主任技術者試験は、科目合格)


世間では「電気工事士」は決して難関資格として扱われていないのだけれど、やはり筆記試験だけではなく技能試験があるため、合格するには相当の苦労はあると思う。

電験3種」は、はっきり言って、他の資格と比べるとものすごい難関資格だ。

いわゆる「士業」系の国家資格に匹敵もしくは凌駕する難易度だとも思う。

(試験内容自体の特出した難易度という意味では、無線従事者の「第一級陸上無線技術士」(上記の「一陸特」ではない「一陸技」の方)なども相当に難関だが、電験に比べるとマイナーだからなぁ…)


IT系・情報系には、厳密な意味での「資格試験」は存在しない。

あくまでも知識やスキルを「認定」するだけで、他の電気系・通信系のような法律に定められた「業務独占資格」ではないからだ。

そのことが、「情報処理技術者試験」自体や、合格者の地位向上につながらず、『こんな試験合格していても仕事には関係ない』という声がまかり通ることにもつながっている。

IT系・情報系に真の意味での「資格」できれば「国家資格」が誕生することを願いたい。

IT系の人は、なぜか自分のことをさかんに「エンジニア」と呼称するが、世の中には非IT系にも「エンジニア」「技術者」がたくさんいる。

非IT系の勉強をすると、本当にそれがわかる。

本当に勉強は大切だと思う。


kf7757.hatenablog.com


まさかの電験三種科目合格…来年度に向けて始動!


まさかの電験三種科目合格…来年度に向けて始動!


昨年より、通信関連(有線/無線)の国家資格に挑戦しはじめ、今年は電気系の国家資格にも挑戦している。

これまでに取得した国家資格には以下のようなものがある。


現在、第一種電気工事士には挑戦中である。

そして、実は、準備不足も甚だしいものだったが、「電験三種」(第三種電気主任技術者試験)も、受けるだけは受けた。

電験3種に合格するためには1000時間もの学習が必要だという声もあり、とても合格するとは思えなかった。

現に、受験してみて、付け焼き刃ではとてもかなわないと実感した。

受験した感触では4科目全滅だと思っていた。…なので、自己採点もしなかった。

(法規だけは直前に集中的に勉強したが、本当に付け焼き刃ではかなわないことを実感した)


先日、試験センターから試験結果通知が届いた。

そうしたら…。

「理論」のみ科目合格。

まさかの科目合格である。

しかも、最も計算問題が多い「理論」


これは、合格できるかもしれないチャンスと捉えるべきだろう。

来年度は本気で狙わなければ……!


昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかも…


電験の「理論」科目は、多くの受験生の前に立ちはだかる壁である。

電験3種は、選択形式とはいえ、「5択問題」である。

4択問題と5択問題との難易度の差は、受験してみればわかる。

昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかもしれない。


kf7757.hatenablog.com


kf7757.hatenablog.com


ITはITだけでは存立できない


ITはITだけでは存立できない


ITはITだけでは存立できない。ITとはソフトウェアであり、制御系ならばハードウェアが、業務系ならば対象となる業務、それらがあってはじめて存在し得る。

「私はITの専門家です」「私はITエンジニアです」と言いながら、ハードウェアのことや(ハードウェア系に対しては同じ技術系として知らないことは恥じる傾向はあるが……)、ましてや「ユーザー側の業務」には何の関心も持たない者が居る。


プログラミングに固執する者たち


そういう者は、ITをきわめて狭い枠でしか捉えていない。そういう者は、プログラミングだけが真のITであると思い、プログラミングをしない役割の者を否定する。そしてプログラミング力こそが最強であると思い込む。

現実世界には、扱うシステムの規模が大き過ぎて、プロジェクトマネージャー、アナリスト、アーキテクト、DB管理者、プロジェクトリーダー、テストエンジニア、バージョン管理者など、様々な役割分担をしなければ絶対に完成しないシステム開発プロジェクトもある。しかし、そういったプロジェクトに参加した経験もない者や、参加したといっても最下層からしか見たことが無い者ほど、プログラミングだけが真のITであると信じている。(多重請負構造の中の最下層の立場でしか参加したことが無いなら大規模プロジェクトの全貌は絶対に見ることはできない。多重請負構造を積極的に肯定する気はないが……)


体系的な情報工学コンピュータサイエンスの学習を軽視する傾向


日本はユーザー側のITリテラシーが低い。より正確に言うならば日本人は一般的にITリテラシーが低い傾向が強い。リテラシーとは基礎力であり応用力でもある。これだけパーソナルコンピューター(PC)や、スマートフォンなどの情報機器が浸透している時代にありながら、それらの「しくみ」「何ができて何ができないのか」を知悉する者は少数派だ。「しくみ」を理解していない者が多い(理解している者が少ない)という事実は「ITエンジニア」を自称する人々にも言える事実である。

なぜならば、日本では欧米などとは異なり、基礎から情報工学コンピュータサイエンスを専門に学んだという学歴がなくても(いわゆる文系でも)ITエンジニア職には就くことができる。独学や我流でプログラミングなどを学び、経験した者でもそうした職種に就ける。無論、それは悪いことばかりではない。しかし、我流で学んだ自負が強い者ほど、体系的な情報工学コンピュータサイエンスの学習を軽視する傾向がある。

体系的な学習は軽視するが、プログラミング言語や開発環境、新技術の習得には逆にものすごく意欲を見せる。とにかく「自分の市場価値を高めたい」「時代に取り残されないように新技術を追い求めたい」という意欲だけは高い。

しかし、これはあまり知られていない事実だとは思うが、業界で有名なインフラエンジニアの多くは、若い頃に地道にしっかりと情報工学の基礎を学習し(学歴が文系であったとしてもその場合は職に就いてから体系的な学習を行い)、泥臭い業務系などのアプリケーション開発を極めた経験を持っているものである。そうした経験の下地があってこそ、経験の中から普遍的な部分を抽出することが可能となり、やがて優秀は真のITエンジニアとして信頼を勝ち取っていったのである。


本当に求められている人材/人財とは


上述したように、日本はユーザー側のITリテラシーが低い。経営者はもちろんのこと、若い担当者もITには疎い。PCなどの使い方には長けている者もいるが、本質的にシステム開発というものの性質には疎い。欧米ではITエンジニアはベンダー側よりもユーザー側の方に多くが所属している。だから、ユーザー自身が業務とシステムとの整合性を考えることができる。しかし、ベンダー側にITエンジニアが偏っている日本では、これが困難となる。

  • ユーザー側はシステム開発には疎く、自分の本業ではないという意識が強い。だから、ベンダー側に要件定義さえも「丸投げ」しようとする。

  • ITエンジニアの多くはユーザー業務には興味がなく、「IT技術力は自信があります」と言いながらも、要件定義に対する提案力が低い。「仕様は正確に言ってもらわないと困ります」「要求仕様通りに作りました」と言い続ける残念なITエンジニアが多くなってしまう。

このような「ユーザー側とITエンジニア側との距離が遠い」ということこそが、日本のIT業界の問題の本質だ。

本当に求められている人材/人財とは、上記の遠くなりがちな「ユーザー側とITエンジニア側との距離」を短くできる人財なのである。

ITはITだけでは存立できない。この言葉の意味がおわかりいただけただろうか。ITというものは常に対象が必要である。制御系なら設備や機械などのハードウェアが存在し、業務系なら個々のユーザー固有の業務が存在する。それらの「対象」への理解が不足している状態では、どんなに純粋なIT技術を学習したとしても活かすことができない。

仮に活かすことができるとしても、それは「与えられた仕様に基づいてプログラミングを行う」といったきわめて限定的な場面にしか活かせない。


何事も「否定」をする者は若輩者


「若いうちはとにかくコードをたくさん書け」「資格なんか価値は無い」と豪語している猛者がよくいる。その意見を全否定する気はないし、頷ける部分もある。

しかし、普通にこのように考えられないだろうか。

  • 情報処理の資格試験などに何百時間も費やしている暇があったらその分コーディングして腕を磨け

 → 情報工学コンピュータサイエンスの学歴などの「基礎知識をしっかりと体系的に学んだ経験がある」という証拠を持っていない者こそ、情報処理技術者試験などの試験は重要であり、そういう試験の合格歴でもって基礎的な知識の有無の第三者に証明をする必要があるのでは?(試験は試験に過ぎずいくら合格したからといって実務能力に直結しないことは皆が知っているし、そこが試験の価値ではない。試験の価値は「第三者への基礎知識の証明」である)

 → それに、いくらコーディングの能力が向上したとしても、前述のような「真に求められる人財」にはなれないですよ? 無論、コーディング能力も重要。本当に優秀な者であれば、プログラミング能力の向上と資格試験の取得とを両立することもできるはずでは?

  • 至高なのはインフラエンジニアなので、業務知識が求められる業務SEなどやめてしまえ

 → 上述したように、本当に実力がある有名なインフラエンジニアは、泥臭い業務系などのアプリケーション開発をたくさん経験しているものである。そうした経験がないと、業務系のSEや、ユーザー側の担当者に対して堂々と意見を言えたりはしないものである。


システム開発において本当に重要な事項などは、えてして何十年も前の開発現場と変わらない部分も多い。

また、時代はくりかえされるという傾向がある。レガシーシステムのインフラのしくみに驚くべき高度な技術が存在していたりするものである。

日本がすでに「技術立国」などではなくなって久しい。

IT業界も昔に比べて実は衰退しているのかもしれない。


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com