実行力が伴わないマネジメントは無意味です(前回の続き)
実行力が伴わないマネジメントは無意味(前回の続き)
(現在、電験三種の試験前の追込み時期で、本来はこんな記事を書いている場合では無いのですが、ちょっと現実逃避気味で、短めに書きます。)
綿密なスケジュール(WBS)を立案しましょう
現実的なプロジェクト計画を作成しましょう
現実的な体制表・体制図を作成しましょう
これ自体は否定しません。むしろ正しいです。
ないよりは、ちゃんとした上記の計画があった方が、良いに決まっています。
でも…。
上記『だけ』では、ダメなんです。
上記の計画を、『実行できる人材』『実行できるスキル・能力』が伴う必要があります。
かんたんなことを言っています。
上記の計画を、『実行できる人材』『実行できるスキル・能力』が伴っていないと、
結局、上記の計画が、動きません。
結局、上記の計画が、動かずに、すぐに計画倒れになってしまいます。
大規模システムをスクラッチで開発するプロジェクトであれば…、
業務仕様をまとめて調整できる顧客サイドのキーマンが必要
顧客サイドの業務仕様をシステム仕様に落とし込める現場リーダーが必要
現場リーダーの意思に基づいて実際のシステムを構築できるエンジニアが必要
(※注)
かんたんなことを言っているつもりです。
そして、当たり前のことを言っているつもりです。
近年、電気工事士などをはじめ、IT系以外の領域の勉強をしています。
そのため、なおさら、IT業界を第三者的に見られると思っているのですが…。
電気の世界なら、電気の素人に電気工事はさせません。
間違った施工をすると、事故・災害・人身事故につながります。
ところが…。
IT系の世界では、けっこう無理なプロジェクトが横行します。
別に否定的な、悲観的なことを強調しているつもりはありません。
あたりまえのことを言っています。
上記(※注)で挙げたような人材が集められなかった場合は、
そのままではプロジェクトは進行できないんです。
進行できないならば、進行できるような状況に持っていくほかはないですよね。
つまり、「計画ありき」ではなく、「集められる人材(戦力)」に見合ったプロジェクトにするのです。
あたりまえのことがIT業界では通用しないと思えましたので、現実逃避も兼ねて書かせていただきました。
「プロジェクトマネジメント」だけでは無意味である理由
「プロジェクトマネジメント」だけでは無意味である理由
経済産業省の外部組織である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はもうすぐなくなる」
......と言った言説は、的を射ていない。
私が情報系の学生時代だった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はいまでも大量に稼働していて社会を支えている」のである。
【国家試験】電験三種(第3種電気主任技術者試験)の難易度
【国家試験】電験三種(第3種電気主任技術者試験)の難易度
電験三種はただいま学習中ですが、自分が今までに受験してきたさまざまな資格試験の中でも、最も難しいレベルだと改めて思います。
特に思い知る部分としては、過去問題をただ単に反復練習するだけでは、決して合格できないというところです。(無論、過去問の反復練習は必須なのですが)
問題の出題者の意図を掴んだ理解をしないと難しいような問題になっているところです。
かと言って、第二種電気工事士などが「簡単」と言う気もありません。
電気工事士もしっかり数ヶ月間、学習しないと合格できません。当たり前ですが。
特に電気系の「ズブの素人」からだと、数ヶ月は必要です。
ただし、電気工事士は、「電気工事士として最低限これだけは絶対に押さえておきなさい」という知識や技能をチェックする試験です。
逆に言えば、その要点さえ押さえておけば、合格するように設計されています。
電験三種は、明らかに違います。
問題が本当に考え抜かれていて、前述のように、「深い理解」があるかを見てきます。 そして「落とし」に来ています。
10人中1人くらいの合格で良いとされている試験です。
10人中9人は不合格で良いという試験です。
(以下は、自分が実際に受験したり学習したりして、ある程度の実感が持てるもののみを挙げています。電験二種などはまだ学習経験がないので挙げていません)
数字が大きい方が難易度が高いという意味です。
【電気系】
第二種電気工事士(筆記試験):20
第二種電気工事士(技能試験):30
第二種電気工事士トータル:50
第一種電気工事士(筆記試験):40
第一種電気工事士(技能試験):60
第一種電気工事士トータル:100
【通信系(有線系)】
電気通信工事担任者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ならわかります」などと言い出したら、それはニセモノだとわかってしまう。
回り道に見えるかもしれないけれど、応用分野をしっかり理解したいと思うなら、基礎分野から学習しないといけない。
第一種電気工事士合格証書GET!
第一種電気工事士合格証書GET!
「第一種電気工事士」の合格証書が届いた。
「第二種電気工事士」が一般電気工作物(低圧)の工事のみであるのに対して、「第一種電気工事士」は自家用電気工作物(高圧)の工事も対象になる。
正式な免状を得るには、五年間の実務経験が必要となる。
試験合格だけでは第一種の免状は得られない。そのため、この試験を受ける価値を見いだせないという人もいるようである。
だが、高圧受電設備などの高圧電気の勉強という意味では、第二種とは別物であるため、勉強する意義は大いにある。
電験三種(第三種電気主任技術者試験)を目指すうえでは、第二種からいきなり行くよりも、良い通過点になると思う。
電験と電工では、試験の難易度も範囲もレベルが違いすぎるので、電工から順番に受けるのは意味がないという人もいるようだが、私の意見は違う。
けっこう電験の講習会に電気の知識ゼロの状態でやってくる人がいる。
さすがに知識ゼロからいきなり電験はつらいはずである。(せめて電工や他の電気通信系の資格を経たほうが良いとは個人的には思う)
ちなみに、「認定電気工事従事者」の資格を得るのに、この「第一種電気工事士」の合格だけで申請できる。
「第二種電気工事士」、「電験」を保有する人が同じ認定を得るには、所定の講習を修了する必要がある。
とりあえず、今年は電験を頑張ろうと思う。
資格/試験 取得一覧 (2018年まで)
資格/試験 取得一覧 (2018年まで)
SEQ.取得年 資格/試験名称
01 1991年 情報処理能力認定試験A級
02 1991年 第二種情報処理技術者試験 (国家試験)
03 1995年 第一種情報処理技術者試験 (国家試験)
04 1995年 パーソナルコンピュータ利用技術認定試験4級
05 1995年 パーソナルコンピュータ利用技術認定試験3級
06 1997年 パーソナルコンピュータ利用技術認定試験2級
07 2000年 ORACLE MASTER Silver 7/8 共通 (旧制度)
08 2003年 IBM DB2グローバルマスター・エンジニア
09 2003年 IBM DB2グローバルマスター・エキスパート(管理)
10 2004年 UMLモデリング技能認定試験レベル1 (UMTP L1)
11 2008年 Cosminexus認定アプリケーション・エンジニア
12 2008年 Cosminexus認定プラットフォーム・エンジニア
13 2008年 Cosminexus認定アプリケーション・スペシャリスト
14 2008年 Cosminexus認定プラットフォーム・スペシャリスト
15 2009年 UMLモデリング技能認定試験レベル2 (UMTP L2)
17 2017年 ORACLE MASTER Bronze Database 11g
18 2017年 ORACLE MASTER Silver Database 11g (Oracle Certified Associate)
19 2017年 無線従事者 第三級陸上特殊無線技士 (国家試験,国家資格)
20 2017年 無線従事者 航空特殊無線技士 (国家試験,国家資格)
23 2018年 無線従事者 第一級陸上特殊無線技士 (国家試験,国家資格)
24 2018年 第二種電気工事士 (国家試験,国家資格)
(第一種電気工事士は、筆記試験/技能試験すべて受験した。結果待ち)
世間では「電気工事士」は決して難関資格として扱われていないのだけれど、やはり筆記試験だけではなく技能試験があるため、合格するには相当の苦労はあると思う。
「電験3種」は、はっきり言って、他の資格と比べるとものすごい難関資格だ。
いわゆる「士業」系の国家資格に匹敵もしくは凌駕する難易度だとも思う。
(試験内容自体の特出した難易度という意味では、無線従事者の「第一級陸上無線技術士」(上記の「一陸特」ではない「一陸技」の方)なども相当に難関だが、電験に比べるとマイナーだからなぁ…)
IT系・情報系には、厳密な意味での「資格試験」は存在しない。
あくまでも知識やスキルを「認定」するだけで、他の電気系・通信系のような法律に定められた「業務独占資格」ではないからだ。
そのことが、「情報処理技術者試験」自体や、合格者の地位向上につながらず、『こんな試験合格していても仕事には関係ない』という声がまかり通ることにもつながっている。
IT系・情報系に真の意味での「資格」できれば「国家資格」が誕生することを願いたい。
IT系の人は、なぜか自分のことをさかんに「エンジニア」と呼称するが、世の中には非IT系にも「エンジニア」「技術者」がたくさんいる。
非IT系の勉強をすると、本当にそれがわかる。
本当に勉強は大切だと思う。
まさかの電験三種科目合格…来年度に向けて始動!
まさかの電験三種科目合格…来年度に向けて始動!
昨年より、通信関連(有線/無線)の国家資格に挑戦しはじめ、今年は電気系の国家資格にも挑戦している。
これまでに取得した国家資格には以下のようなものがある。
現在、第一種電気工事士には挑戦中である。
そして、実は、準備不足も甚だしいものだったが、「電験三種」(第三種電気主任技術者試験)も、受けるだけは受けた。
電験3種に合格するためには1000時間もの学習が必要だという声もあり、とても合格するとは思えなかった。
現に、受験してみて、付け焼き刃ではとてもかなわないと実感した。
受験した感触では4科目全滅だと思っていた。…なので、自己採点もしなかった。
(法規だけは直前に集中的に勉強したが、本当に付け焼き刃ではかなわないことを実感した)
先日、試験センターから試験結果通知が届いた。
そうしたら…。
「理論」のみ科目合格。
まさかの科目合格である。
しかも、最も計算問題が多い「理論」
これは、合格できるかもしれないチャンスと捉えるべきだろう。
来年度は本気で狙わなければ……!
昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかも…
電験の「理論」科目は、多くの受験生の前に立ちはだかる壁である。
電験3種は、選択形式とはいえ、「5択問題」である。
4択問題と5択問題との難易度の差は、受験してみればわかる。
昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかもしれない。
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業界も昔に比べて実は衰退しているのかもしれない。
資格試験の価値
資格試験の価値
昨日、「第一種電気工事士」の筆記試験を受験してきた。
平成30年度なので、平成最後の電気工事士試験となると思われる。
私は本業が情報システム開発/保守(SE)なので、電気系は実務経験が無い。
それでも、将来的なこともいろいろ考えて、本業以外の分野を積極的に勉強している。
先日、免状を取得できた「第二種電気工事士」の受験は、本当にたいへんだった。
電気工事士の試験の本領は何と言っても二次試験にあたる「技能試験」である。
実際に強電の世界で必要最低限、身に染み込ませて知っておかないといけないような注意点を、技能試験を取得する過程で、「身体で覚えさせる」というしくみになっている。
本当に、この資格試験のしくみはよくできていると思う。
過去問で対策ができる試験にも充分に価値はある
昨日受験した「第一種電気工事士」の筆記試験への対策では、自分ながら、そうとう猛勉強した。
直前にはもっぱら過去問題の繰り返しになる。
電気工事士の筆記試験は、過去10年間の問題をやりこんでおけば、まず合格できる内容である。
過去問で対策できる試験を、受験もしないのに侮る言説があるが、それは違うと思う。
当然のことだが、どのような試験でも、「一夜漬け」または「ほとんど無勉強」で合格できるものなど無い。
(仮にそのような試験が存在するとしたら、その資格試験には本当に価値が無い。(いわゆる民間の資格商法などの試験はこういうものだろうが…))
どのような試験でも、事前にしっかり対策を行った場合、つまり勉強をした場合にのみ、合格の目が出てくる。
過去問題で対策可能な試験が低く見られがちだが、過去問を解く、または覚えるにしても、前提知識は必要なのである。
人間の頭脳は機械とは異なる。前提知識もなく問題集の丸暗記など、やろうとしてもそうそうできるものではない。
それに、資格を与える側の思惑として、敢えて同じような問題を繰り返し出すという点もある。
上記の電気工事士筆記試験に関しては、「電気のことを深く知る」ことよりも、「現場技術者として絶対に把握しておかなければならない注意点を押さえる」ことを重要視していると思える。
強電の工事の世界では、設備や工事の取扱を間違えると人命に関わるためである。
故に過去問で対策できる資格にも一定の価値はある。
無論、例えば電気主任技術者試験(電験)など、過去問では歯が立たない、真の理解度が求められる資格試験もあるし、それには、より一層の高い価値がある。
情報系(IT系)の試験のほとんどが単なる知識認定であることが悲しい
資格資格と言っても、情報処理技術者試験のような国家試験でも、民間のオラクルマスターでも、実のところ、「その資格を持っていないと業務ができないという強制力が無い」ので、本当の意味では「資格」とは言えない。
この事実が、試験自体の様々な点での価値低下、試験内容や質の低下、現場エンジニアたちの試験離れの悪循環につながっていると思われる。(注1)
この事実が歯がゆいし、悲しいと思う。
前述した電気系の「資格」は、本当の「資格」なので、その免状を保有していないと業務ができない。
そして、そういう背景もあるためか、資格取得までに必要となる学習プロセスがしっかり根付いていて、電気工事士などは頭でというよりも身体に染み込ませるような「しくみ」になっている。
一方で、IT系は、下手をすると、ずぶの素人が「私は経験豊かなシステムエンジニアです」と名乗っても、それが本当かどうかチェックするしくみがない。(注2)
現に、経歴を詐称することが、中小IT企業の派遣の世界では常態化している面もある。
書店に並んでいる本や、インターネットにおいて、「少しでもプログラミングができれば即エンジニアと名乗れる」と書かれている風潮も、そういった背景と無関係ではないだろう。
IT系と電気系とでは、仕事内容も何もかも異なるので、一様に比較はできないが、本当に歯がゆい現実である。
(注1)それでもIT系の試験は人気自体はあり、毎年何万人も受験している。IT系の仕事自体、参入しやすい側面があるからだろう。
(注2)ここでやはり「参考」となるのは職歴以外では「国家試験」「公的試験」の合格歴だと思う。
「怒り」の感情を否定するな!
「怒り」の感情を否定するな!
書店をめぐるのが昔から好きである。
近年はオンラインで書籍を購入することが増えたが、オンラインでも書籍を検索するのが好きである。
近年、売れている本を見るに、ある傾向が見える。
(1)感情的にならないようにしよう
(2)怒らないようにしよう
(3)アホと戦って時間を無駄にしないようにしよう
人間の「喜怒哀楽」のうち、特に「怒」の部分を抑えたほうが良いという風潮にあふれている。
自分の感情を下手に抑え込むと病んでしまうこともある
私は、下記の言葉があまり好きではない。
「怒ったら負け」
確かに、理性を失って、怒りの感情に支配されてしまうと、いろいろと良くない。
それはそう思う。
しかし、一方で、
タイミングよく「怒れない」ことで損をする
という経験を、いままでしてきた。
そして、そういう人をたくさん見てきた。
「怒り」の感情をいけないものだと思い込み、自己嫌悪や、自己肯定感の否定につながってしまうこともある。
「怒り」の感情は、そんなにいけないものなのだろうか。
「怒り」の感情は、喜怒哀楽といった人間の感情の基本的なものである。
「腹が立ったら怒って良い」
「腹が立ったら怒って良い」
本当にそう思う。
自分の心に発生する感情にウソをついてはいけない。
- 作者: 和田秀樹
- 出版社/メーカー: 新講社
- 発売日: 2011/03/07
- メディア: 単行本
- 購入: 1人 クリック: 1回
- この商品を含むブログ (1件) を見る
腹が立ったら怒りなさい (WIDE SHINSHO182)(新講社ワイド新書)
- 作者: 和田秀樹
- 出版社/メーカー: 新講社
- 発売日: 2012/12/21
- メディア: 単行本
- この商品を含むブログ (1件) を見る
企業システムの真髄はバッチ処理にあり!
企業システムの真髄はバッチ処理にあり!
「基幹系業務システムの真髄」は夜間などにユーザーから見えないところ(バックエンド)で稼働しているバッチ処理にある。
銀行や保険会社などの金融機関における様々なお金の計算もバッチ処理で行われている。
製造業における生産数と在庫数と売上数の帳尻合わせもバッチ処理で行われている。
公的機関の様々な受付業務からはじまる工程管理の整合を取る処理やシステム間連けいもバッチ処理で行われている。
官公庁における戸籍などの個人情報のマスター化もバッチ処理で行われている。
あらゆる企業の毎月の経理精算や給与支払いもバッチ処理で行われている。
上に挙げたのはほんの一例にすぎない。
どれも非常に地味な印象を受ける処理である。
まず華やかな印象はない。クリエイティブな印象もまったくない。
しかし、これらのシステム処理が、ある日突然、停止したり、消えてなくなってしまったりすると、その企業そのものの活動のみならず、広く社会一般にまで悪影響を与えてしまう。
そういったシステムこそが「基幹系システム」なのであり、「プラント型IT」なのである。
Web系などの人の目につく部分(フロントエンド)のシステムは、「ツール系IT」であり、まるごとどこからか買ってきて入れ替えても、その企業の存続には影響しない。
しかし、バックエンドシステムのような「プラント型IT」は、その企業の競争力を生み出している業務そのものと一体化している。
そのため、簡単によそから買ってきて入れ替えることはできない。
そして、その「プラント型IT」の更に根幹部分を担っているのが、バッチ処理なのである。
例えばamazonなどにおいて、「バッチ処理」に関する書籍を検索してみても、ひっかかるのはほとんどが「Windows(MS-DOS)コマンドプロンプトにおけるバッチファイル」に関する書籍ばかりである。
こんな情勢では、世の中の若手のITエンジニアにとって、上記のようなバッチ処理の設計が、縁遠いものとなってしまっているという点も、肯ける部分がある。
睡眠時に脳がフル稼働しているのと同じく社会のバックグラウンドではバッチ処理がフル稼働している
近年の脳科学において、記憶の定着に、睡眠が重要な役割を果たしていることがわかってきた。
世の中のバッチ処理も、脳における睡眠と同じような存在なのである。
やがて迫りくる様々な基幹系システムのブラックボックス化
情報系の学校の授業や、IT企業の新人研修において、画面を持たないバックエンド処理であるバッチ処理について、ろくに教えないということが当たり前になって、かなり経過した。
「プログラミングは楽しい」ということばかりを、ネットや書籍では喧伝しようとしている。
それを否定するつもりはない。
しかし、一方では、社会を支えている地味なシステムが、人知れずバッチ処理として動いている。
「クリエイティブ」とか、「楽しさ」とか、そういった感覚とは、およそ無縁のシステムである。
こういったシステムの担い手も、本当ならば、育成しなければならない。
だが、多くの人々は、バッチ処理システムの存在すら知らないのである。
情報システムは、工業製品としての色合いも強く持っている。
しかしながら、何故かIT産業の有名人たちは、その事実から目を背けている。
やがて、社会を裏側で支えている基幹系システムの保守という地味な仕事の担い手が、圧倒的に足らなくなる時代がやってくるだろう。
そのときになって、後悔しても、すでに遅いのだ。
第二種電気工事士に合格はかなりうれしい
第二種電気工事士に合格はかなりうれしい
この5月から7月のプライベート時間のかなりを費やして受験した「第二種電気工事士」(筆記/技能)。
正式な合格通知が届いた。
正直、ものすごくうれしい。そしてホッとした。
この試験の本質は技能試験(実技)にある。
強電の仕事で最低限知らなければならない必須知識が技能試験の対策をやることで身につく。
そういう「しくみ」になっている。
うまいことできていると思う。
これで、一応、「IT」「弱電(無線通信)」「弱電(有線通信)」「強電」の4分野について国家資格を有したことになる。
(ITは、国家資格(免許)というより国家認定に過ぎないことは以前に書いたとおり)
もっとも、それぞれの資格の中では最高位ではないのだけれど…。(昔のものもあるし…)
この中で、実技試験が課せられているのは、強電の電気工事士だけである。
強電の世界では知識が無いことが人命に関わるためである。
技能試験は専門家に習ったほうが良い
合格率のデータだけを見ると、第二種電気工事士は、さして難しい試験ではないように思えてしまう。
現に昨年の私は、そう思ってしまった。それで不合格だったわけだが…。
しかし、工事作業を本業としているような人や、電気工学科などで実習をしたことがある人ではない限り、独学で挑戦するのはおすすめしない。
普通のド素人が、独学で突破できる試験ではない。
電気工事の基本単位作業を、頭で考えることなく「身体で覚えている」くらいのレベルに持っていかないと、なかなか合格は難しい。
なぜなら、本番での試験の時間がとても短いからだ。
専門家である講師に実習を教えてもらうことで、お手本を生で見ることができるし、本当に基本中の基本の疑問も聞くことができる。
電気工事士もそうだが、電気関係の知識では、本当に独学よりも先生に教わるほうが良いことを実感している。
ただし、まったくの無知識状態で先生に教わるのは、非効率である。
新人研修でも、教えたことのほとんどが残らない。
それは、まったくの下地がない状態では、いくら知識を頭に入れようとしても入らないからである。
その意味では、電気工事士の技能試験対策については、私は、あえて2回以上の講習を受けることをおすすめしたい。
1回めの講習で、電気工事士の基本的な作業を体験し、頭に回路を作る。
2回めの講習で、一度できた回路に改めて知識(体で覚える知識も含む)を、再度頭に入れる。
ほっとしたのは、「これで第一種電気工事士にもチャレンジできる」と思ったからでもある。
第一種にも挑戦するつもりでいる。