ユーザー企業にITやWebのスペシャリストが育たないのでひどい品質の要求定義が氾濫する
ユーザー企業にITやWebのスペシャリストが育たないのでひどい品質の要求定義が氾濫する
今日、たまたま見かけた記事。わかるなぁ、という話。
タイトルの通り、多くの日本企業および官公庁においては、いわゆる『総合職』的な業務のやり方をする者が権力を得る構造になっている。
『総合職』と言えば聴こえは良いが、要するにゼネラリストである。
こうした者たちは2～3年ごとに異動を繰り返し、様々な場所や部門を渡り歩く。そうした中で『人脈』を築き上げて行き、徐々に出世する。
彼らゼネラリストは、ITシステムの構築やWebの細かい事などは、専ら『外注』する事になる。
ここで問題が生じる。
『要件定義』の問題である。
『要件定義』の責任はユーザー側にある。これが大原則だ。
画面の仕様なども当然それに含まれる。
しかし、彼らはゼネラリストであり、しかも2～3年ごとに居なくなる。
人が替われば言うことも変わる。大規模に新規開発した時には、それなりの開発基準やルールを定めたりするものだが、たいてい、そういったものは引き継がれない。
日本のゼネラリスト偏重志向が、色んな問題を産んでいると思う。
（反論）RE:新人は飲み会は断らない方が良いし、上司に媚びた方がいい。
（反論）RE:新人は飲み会は断らない方が良いし、上司に媚びた方がいい。
少しだけ反論したい。
http://wasara.blog101.fc2.com/blog-entry-3788.html
『あくまでも新卒入社1年目の新人』に限って言うならば、一部は同意見。新人のうちは、飲み会には出席した方が良い事がある。
確かに、飲み会では、昼間の業務時間中には得られない、別の『もう一つの組織』が見えたりする。
但し、別に『出世するためのノウハウ』が聴ける訳ではない。もしも、そういうつもりで飲み会に参加するとなると、ものすごく対費用・対時間的に、効率が悪すぎる。
私の意見を言うならば、飲み会が純粋に楽しめるなら参加した方が良いし、正直、苦手ならば、距離をとっても構わない。但し、上述したように、新卒入社1年目に限るなら、なるべく参加した方が良い事があると思う。飲み会に行くか行かないか、ましてや上司に媚びを売るか売らないかで、出世にはほとんど影響しない。
飲み会で得られる情報とは
上司に限らず、中堅以上のベテラン社員は、新人に対して『昔話』をしたがる。その中には、貴重な情報も確かにある（こともある）。
仕事のやり方とか、様々な話はあると思う。しかし、それは必ずしも現代に合致したものではない場合も多い。業務のやり方など、変化の早い業界なら、数年でガラリと変わってしまう。
ぶっちゃけて言うと。
最も貴重な情報は、過去から連綿と続いている『人間関係』の事情であると思う。
わかりやすい例を言うなら、『先輩・後輩の関係』だ。
仕事ができる、即ち役職に就いている、とは必ずしも言えない。組織内における人事というものは、そこまで単純ではない。（では何が人事を決めているのか、という点については、ここでは敢えて言わない。語りだすとそれだけで数万文字になってしまいそうだから）
自分の配属されたセクションの"部長"が、実はとある"主任"の『直系の後輩』である、などという裏事情があったりする。ここで言う直系とは、組織内の部門の系列のようなものだ。例えば「あの人は入社以来ずっと営業畑で…」などというものだ。
日本企業ではまだまだ『入社年次』というものが重要視される。
その組織で2年目になると、必ずなれるものがある。それが『先輩』という存在である。
特に若い頃に世話になった先輩というものには、いろいろと学ばせてもらう事が多いし、実際、その先輩が一定以上のスキルを持っているなら、役職に関係なく、裏では世話になる事が多く、いつまでも（良い意味で）頭が上がらないものである。
そうした裏事情も知らずに、単に役職だけを見て先輩社員を軽んじたりすると、あまり良い事はないと思う。役職だけを見て媚びるのは、外部の請負企業の人など、そういった関係性の人々だ。外部の人は、裏事情など知らないし、意味もないと思っている。何故なら彼らこそ、人の価値を"権限"のみで判定しているのだから。
ちなみに人事の事情を、ほんの少しだけ言う。どんなに強い決裁権を持っている役職者であっても、組織内の人事への関与権は、また別なのだ。これは、しっかりとした組織を保っている企業や団体ほど、そういう傾向がある。
だから、仮に社長や役員にいくら良い印象を得られようとも（媚を売っても）、出世には全くと言って良いくらい、関係ない。
飲み会に行くのは適度にして、浮いた時間とお金を自分への投資に使う
日本人は欧米人と違って、お酒が飲めない体質、いわゆる下戸も多い。
それに、日本企業の飲み会では、若い女性はセクハラに近い事をされる場合もある。それこそ『媚を売る事を強要される』というカルチャーがある。チヤホヤされるという事は、裏を返せば下に見られているという事だ。それに気づかず、浮かれた状況で二十代を潰してしまう有望な女性社員がなんと多いことか。
一方で、若い男性社員は、『とにかく弾けろ』とばかりにバカをやらされる場合もある。バカ乗りが好きで、それが楽しめる人は良い。しかし、そうでは無いという人も多いはずだ。バカ乗りとまでは行かなくとも、何故か『過剰な自己開示を強要される』というカルチャーがある。苦手な人にとっては勉強になる事よりも、ストレスの方が大きいだろう。
飲み会の付き合いの良し悪し程度では、出世には影響しない。大体、出世する事がその人にとって良い事なのかも、人による。
飲み会は二次会、三次会も含めれば、一夜で一万円以上かかる。時間と体力も消耗する。すべての誘いを受けていたら、週に2回以上、月に10回近くにもなる。
そんな事で消耗するくらいなら、自分への投資に使った方が良い。
私は、若い頃、よく金曜日に翌朝まで上司や先輩に飲みを付き合って、土曜日の朝に帰宅したりしていた。そういう時は、まず貴重な週末は潰れてしまう。そんな事で消耗するくらいなら、勉強でもしておくのだったと思う。
会社外の付き合いも、今では重要なご時世だ。
せっかくの週末は、そういう事に使った方が良い。
ちょっと勢いで反論してみた。
多分、世代が違うとは思う。
私は、就職氷河期の最初期組の世代、とだけ言っておく。
職場復帰して約半年…身を助けるのは『日本語』『OS』『DB』
職場復帰して約半年…身を助けるのは『日本語』『OS』『DB』
職場復帰して約半年。正直、身を助けているのは、以下の三点かと実感している。
よく世間では英語がわからないと最新技術が速く取り込めないとか色々と言われている。それは間違っていない。だが実際の職場で日常的に使用されるのは、日本で働くなら日本語だ。
そして、基本的な『報告・連絡・相談』から『メールによる連絡』、何かトラブルが発生したときに上司や顧客に対して作成する『報告書』の類。これらを“即興”で作成する時に必要なものが一つ目である。
本番環境や開発環境で何かトラブルが発生した場合、その状況に応じてシェルスクリプトやSQL文（たいてい両者は組み合わせる事が多いが）を、“即興”で作成する事が多い。これらが二つ目、三つ目である。
現に、直近の3月末の2週間は、期末処理の障害対応でいろいろとバタバタしていた。そんな中でも、三年間も職場を…と言うよりも仕事自体をしていなかった身でも、少しは役に立てたと思う。
職場復帰に併せて、リハビリも兼ねて、「LPIC」の学習をしたり、同じく「ORACLE MASTER」の学習をしたりしたのは、業務にも直接、役に立ったと思う。
ネットを見ると色んな意見があって、例えば、「LPICなんて所詮は暗記モノだし、あんな試験を合格したなんて言っている人は信用できない」などという人もいる。
それでも、私は、役に立った。
もちろん、上記に挙げた点は表面的なものであって、実際には、その職場の文化、その職場で扱っている業務システムの知識、などといった根底部分がもっとも重要ではある。こうしたものは、一朝一夕に身に付くものではないので、経験を積み上げるしか無い。
でも、そういった根底部分が仮に弱くても、上記の3点があれば、割とそこそこ行けるとも思うのだ。
リワーク施設の担当カウンセラーさんに、『休職期間と同じくらいの長さのリハビリ期間が必要になる』という事を言われた。
それはその通りかと思う。
やはり、トラブル対応などが入ると疲れ方が違う。一時間でも居残りが発生すると疲れ方が違う。
無理は禁物であると感じる。
モデリング表意言語 UML (Unified Modeling Language) とは…本当に言語だろうか
モデリング表意言語 UML (Unified Modeling Language) とは…本当に言語だろうか
UML (Unified Modeling Language) は、ドキュメントの記法の一種であり、良くも悪くも、それ以上でもそれ以下でもない。少なくとも現在の日本における大多数のシステム開発現場においては。
確かにUMLの中の一部の図は、オブジェクト指向の言語や設計を強く意識したものとなっている。しかし、それはあくまでも一部である。（例えば「クラス図」は、その名称からもわかるようにオブジェクト指向を意識した図である。一方で、例えば「ユースケース図」は、あくまでも業務フロー分析のための図であり、オブジェクト指向とは直接的な関係はない）
決してUMLによるドキュメンテーションが即、オブジェクト指向につながる訳ではない。
UMLは確かに2000年代に流行したと思う。
実際に、UML駆動型のCASEツールなども生まれた（UMLをINPUTとして、ソースコードのひな形をOUTPUTするツールなど）。しかし、UMLがそれ自体、直接コンパイルされて実行されるような性質のものではなく、あくまでもドキュメントの一種である事から、他の古来から存在するドキュメントと同じように、メンテナンスの問題（ソースコードとの乖離）を抱える事となった。
日本の、特に官公庁や大企業における基幹業務系システム開発の現場では、UMLの誕生よりずっと昔から、設計書/仕様書の書き方について、独自にではあるが、研究されて来た。
それは確かにオブジェクト指向には必ずしも向いていない、いわゆるプロセス中心指向のものであったとしても、“「業務ロジック」や「システムアーキテクチャー」を書き表し、ユーザーと共有する”、という目的のために研究され、工夫を重ねてきた背景がある。
そこに、適用プロセスを敢えて定義していないUMLを導入しようとしても、効果は限定的となる。
UMLが最も活躍したのは、おそらく「オフショア開発」といった異文化の人々が情報をやりとりする現場である。特に新興国のIT開発の現場では、古来からのドキュメントの蓄積などはなく、UMLがそのまま標準として利用できただろう。
しかし、そもそもオフショア開発自体が日本の業務システム開発で成功しているかという点は、何とも言い難い。何しろ日本のシステム開発はカスタマイズのカタマリになっているので、オフショアでいくらコストを削減しても、中長期的に見ればシステムの改修（保守：エンハンス）で、かえってコストが増大する結果になっている面もある。
オフショア開発とは異なるが、主として中小企業向けの「作りっぱなしの業務システム」においても、ユーザー企業側に成果物標準などが存在しない状況の中では、UMLはよりどころになる。
現実的な位置づけとしては、ドキュメントの基礎素養の一つとして理解しておく必要がある事は確かとして、実際には他のドキュメント体系とも複合させつつ、うまく利用して行くものと言えるだろう。
ここで言う他のドキュメント体系とは、例えるなら、上流工程向けの「Mind-SA」などである。
2017年現在において、UMLに関する認定試験は、下記の2種類がある。
UMTP/Japan 特定非営利活動法人UMLモデリング推進協議会
OMG認定UML技術者資格試験プログラム OCUP / OCUP2
私はUMTPの方を8年前にLevel2(L2)まで取得したが、認定試験としては少々苦戦しているようにも思える。UML単独ですべてをやろうとする部分に無理が生じているのかもしれない…。
情報処理技術者試験の副読本に最適『暗号技術入門 第3版 秘密の国のアリス』(著:結城浩)
情報処理技術者試験の副読本に最適『暗号技術入門 第3版 秘密の国のアリス』(著:結城浩)
情報セキュリティ関連を学習している人にとっては、名著としてかなり有名な書籍である。
かくいう私も、昨年、遅ればせながら拝読した。
上記のリンク先でも私が述べているように、純粋に、日本語として、文章として、書物として、読む価値が高い。
巷に多く氾濫している、急造された自己啓発本などに比べ、はるかに内容が『構造化』されて、適度に『凝集化』されていると思う。
なので、価格以上の価値を感じる事ができる。
内容は「暗号技術」に関する入門的なものだが、暗号技術自体が数学的な話を避けて通れない。そのため、最低限ではあるが数学的な記述もある。それが、とても美しい。そう、美しい文章なのである。
文学的な美しさとは少し違う。構造的/工学的な美しさを感じさせる。
情報処理技術者試験の内容において、情報セキュリティ分野が強化されて数年が経った。いまや基本情報技術者試験(FE)や、応用情報技術者試験(AP)においても、暗号技術の理解は必須と言って良い。今年からは情報セキュリティスペシャリスト試験(SC)が、情報処理安全確保支援士試験(SC)に変わっている。
その意味でも、本書は一読の価値がある。
おそらく、いきなり情報処理の教科書で、「共通鍵暗号」、「公開鍵暗号」等の説明文を読んでも、なかなか理解できないという人は多いのではないだろうか。
教科書を読む前にこの本を読んでおくと、かなり理解に差が出ると思う。
この本に関しては、内容について、敢えてほとんど触れずに紹介した。
数少ない、必読の本である。
基本情報技術者試験(FE)の午後の選択など何を選んでも良い…あえて言うならとっつきにくい分野の方がロジックは簡単だ
基本情報技術者試験(FE)の午後の選択など何を選んでも良い…あえて言うならとっつきにくい分野の方がロジックは簡単だ
かつては『第二種情報処理技術者試験』と言われていたプログラマー向けの国家試験は、昔はけっこう合格するのが難しく、10年がかりで合格するという人も居たし、何度か受験して不合格になって、そのまま受験（合格）を諦めるという人も多かった。
（第二種の頃の合格率はだいたい15パーセントに届くかどうかだった。現在の基本情報の合格率は25パーセント前後だから、10パーセントは合格率が上がっている事になる）
今のIT企業の管理職世代には、実は若い頃に第二種試験を取得しようとして挫折した苦い思い出を胸に秘めている人も多いかもしれない。名称が基本情報に変更されて、合格率が上がったとしても、その「基本情報」という名称故に、「いまさら恥ずかしくて受験できない」などという変なプライドがますます強くなってしまい、勉強や受験をするモチベーションが下がってしまうのだ。
そういう訳で、基本情報は若いうちに受験する方が良い。（無論、実はベテランでも本来なら受験すべきであるが）
午後のアルゴリズムの選択問題は、言語を何にするかについて、いろいろな情報がネット上には錯綜しているように思う。
まぁ、表計算だけは異質だという意見はもっともであるが…。
私に言わせれば、事前の勉強がし易いもの、もしくは業務で経験があるもの、というものを素直に選べば良い。
『文系の未経験者はこれを選べ』とか、『COBOLなんか役に立たないから選ぶな』とか、『アセンブラが簡単だとの説は頭がおかしな意見だ』とか、いろんな“知ったか”さんたちが言っている。
そんなものを盲信すべきではない。
ただ、昔から言われている事には、えてしてとっつきにくい分野（例えば仮想アセンブリ言語のCASLなど）の方が、問題自体は簡単だという説がある。これは、ある程度は説得力がある説ではある。
もっと言うと、特にアセンブラでは、問題を難しくする事自体が難しい。ごくごく基本的な命令しか持たないアセンブラの世界では、純粋なアルゴリズムの基礎といった単純な問題しか作れないからである。
もしも私がこれから勉強を始める初学者にすすめるなら、アセンブラかもしれない。試験に合格し易いとか、そういうことではなく、コンピュータの動作原理を学ぶには、仮想であってもアセンブラは良い教材となるためである。
試験日まであと20日あまり。今回受験する人は頑張って欲しい。
（ちなみに、私は旧第二種を受けたときはCASLを選んだ。その後に、インテル8086系アセンブラを学習するための良い導入にもなったし、良い経験になったと今でも思っている）
IPA発行の無料ドキュメントにも実は良いモノがある
IPA発行の無料ドキュメントも実は良いモノがある
日本のソフトウェア分野(IT)の競争力の強化を目的とした『国の機関』として、2004年に設立されたのが、独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称：IPA）である。
経済産業省（昔の通商産業省）に代わって、情報処理技術者試験の運営をやっている事や、『IPAフォント』等を無償配布している事などで知られている。
IPAというと国の機関という事もあり、斜に構えてしまう人も居るかもしれない。しかし、地味であるが、けっこう良質なドキュメントを無償で公開している。
有名なところでは、毎年、『情報セキュリティ10大脅威』というドキュメントを公開しており、昨今の情報セキュリティに関する情勢がわかる。それに、この内容から『情報セキュリティスペシャリスト試験』の問題も出る事がある。
また、システム開発の、いわゆる上流工程に関する問題を、ずっと指摘している。
個人的には、下記のドキュメントは読む価値があると思う。
（ソフトウェア高信頼化センター（SEC）刊行の各種ドキュメントの中より）
※下の2つは最近発行されたばかりの最新版で、ダウンロードする際に簡単なアンケートに答える必要がある。（2017年3月時点）
これらを読むと、めまぐるしく変化していると思われているIT業界における、本質的な問題/課題は、10年経っても（おそらく20年経っても）変わっていない、という事実がわかる。
"変わるもの"、"変わらないもの"、を見極める事が重要だと、常々思っているが、こうしたドキュメントも参考になるのではないだろうか。
本当は、上記のドキュメントのタイトルにもある通り、まさにユーザー側（官公庁/企業）の経営者や管理者、そして要件定義に責任を持つべき、業務システム担当者に、読んで欲しい内容である。
彼らがこの内容を理解していない状況が、日本のIT業界を悪くしているのだと思う。
情報処理技術者試験などのIT資格の意義とIT基礎知識の重要性
1.思いのほか拡散されたツイートの内容
以前、下記のようなツイートをしたら、思いのほか拡散されて、正直びっくりした。
プログラミング言語は何を勉強すべき？というよくあるアンケートがあるけど、大抵メディアに踊らされてる内容だと感じる。
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2016年12月11日
それなりに長くSI企業でいろいろ見てきた私として、真実（に近いと思える）事を書いて貼っておきますよ。（あくまでも基幹業務システム系の世界ですが） pic.twitter.com/pFAtHhf9fm
『プログラミング言語は何を勉強すべき？』と言いながら、実はそれ以外の事の方が重要だ、という内容になっていて、ちょっと外した内容であるのにも関わらず、けっこう拡散されてしまった。
拡散が多いと、反論もそれなりに来るのが普通だが、このツイートには反論がほとんど来なかった。（少しは来たが、3～4件程度だった）
反論が来ない事が、必ずしも肯定的とは限らない。しかし、目くじらを立てて反発する事が無いくらいには、それなりに響いた内容だったのかもしれない。
2.IT基礎知識が問われる場面の例
バッチ処理の多重化の検討
これは実際に、最近、私が後輩のPLから分析を依頼された事だ。
とあるJavaで構成されたバッチ処理が、目標の時間帯までに終了しない場合が出ており、多重化で効果があるかどうかを分析/検討して欲しいとの事だった。
ここで重要な事は、そのバッチ処理が、CPU処理で時間を消費しているのか、ディスクI/Oで時間を消費しているのか、という点である。
ディスクI/Oでかなりの時間を消費しているような処理であれば、処理の多重化の効果が大きい。何故ならば、コンピュータ処理の中で、ディスクI/O処理は、『とてつもなく遅い』（数百倍～千倍は遅い）ので、その処理中はCPUやメモリは遊休状態にあるからだ。
CPU処理が大半を占めている（CPU使用率がずっと高いままの）状況であれば、処理を多重化しても、その効果は小さい。
但し、CPU使用率が高くとも、多重化処理自体は可能である。CPUの論理コア数とアプリケーションの多重化の可否には直接的な関連は無い。また、Javaアプリケーションの場合、JavaVMやJITコンパイラの処理も同時に動いている事も頭には入れておく必要がある。
シェルスクリプト内におけるif文とtestコマンド
昨年まで、傷病を理由に三年間も仕事を休んでいた。その復帰直後には、簡単なシェルスクリプトを組んだり、テスト環境を整備したりといった仕事をやった。
シェル関連には経験豊富な先輩社員に、自分が書いたスクリプトを見てもらった。そのときに、if文の評価箇所でtestコマンドを使っているのを見たその先輩が、「このtestというコマンドは何？」という反応をした。同席していた他の若手メンバーから、「よくifで使われる"[“と同じ意味ですよ。”[“は実はコマンドなんですよ」という説明をされ、「知らなかった」と驚いていた。
3.日頃の業務だけでは知識が偏る
上記の2つの例が、上手い例になっているかは自信がないが、1つ目の例は、基本情報技術者試験レベルの基礎知識が問われる場面であり、2つ目の例は、Linux技術者認定試験(LPIC)レベル1程度の基礎知識が問われる場面である。
よく言われる事に、『試験をいくら合格したからといって仕事ができる事にはならない』という主張がある。それは真実だ。
人間の業務は様々な要素が絡んでいる。とても画一的な試験だけで、その能力が測れる訳がない。
しかし、その業務の前提にあるはずの『基礎知識』の有無について、IT資格試験はひとつの判断材料になり得ると思う。
仕事をしている時、他の人に、『こんな事は基礎知識じゃないか』と、ツッコミを入れたくなった経験はないだろうか。
これは試験勉強をしてみて改めて思う事だが、『日頃の業務だけでは知識が偏る』、『日頃の業務で使っている知識は案外せまいものである』という事実である。
上記の例では、2つ目の例がまさにそうである。長年UNIXシェルを使う仕事をしてきた先輩でも、if文に使われている"[“コマンドの真の意味を知らなかった。
それですぐに困る事はないだろうが、場面が異なれば恥をかく可能性もあっただろう。
4.他の人の事はされおき、日々是精進で勉強
試験勉強にはモチベーションが欠かせない。個人的には、左門至峰さんの著書を読むと、やる気になってくる。
私は、もう一度、基礎固めから学習のやり直しをしようとしている。
何せ、私達の世代は、もしかすると一生働き詰めになるかもしれないのだ。
謙虚さを忘れずに、でも、自らは向上心を忘れずに。
ORACLE MASTER 再受験のススメ - 今では管理職になっているご同輩諸君へ (Qiitaより再掲/一部修正)
ORACLE MASTER 再受験のススメ - 今では管理職になっているご同輩諸君へ (Qiitaより再掲/一部修正) -
1.歴史 (主にORACLE7あたりまで)
Oracle Database の認定試験制度である ORACLE MASTER は、日本オラクル社が発祥であり、1997年9月から開始された。
この記事の執筆時点で20年目という事になる。変化の激しいIT業界においては、実に息の長い制度であると言える。
日本オラクル社が発祥という事に驚かれる人もいるかもしれないが、内容的にはきわめて日本人好みのものである。実務経験はなかなか試験では測れないが、知識ベースなら測ることができる。そして受験勉強のように"勉強した成果が評価されるという文化"を好むのは、いかにも日本的である。
もっとも、どんな分野であれ、最初は知識を増やす事から始めるという方向性は、別に間違ってはいない。それだけが正解ではないというだけだ。
特にデータベース関連の知識というものは、他のIT系の知識体系よりも、遥かに“長持ち”する。これは“ビジネスロジック等は時代とともに激しく変遷する"が、"取り扱うデータそのものは不変性が高い"という性質も関係している。
この認定試験制度が生まれた当時(1997年)の Oracle Database バージョンは ORACLE7 である(同年に ORACLE8 が登場したが)。例えば、現在では当たり前になっているデータベーストリガー機能が初めて実装されたバージョンが ORACLE7 である。1992年-1997年という比較的長い期間、最新であったこのバージョンが、当時のRDBの世界に与えた影響は大きい。
日本では、1990年代に大企業を中心に、企業の情報システムが、メインフレーム中心のクローズ系システムから、UNIX系サーバーを中心としたオープン系システムに移行(ダウンサイジング)された。その時期とも重なり、ORACLE7 はかなり導入されたはずである。(ちなみにこの時代にはクライアントには積極的にWindows95系が採用された。Web系モデル以前の、いわゆるクライアント・サーバーモデルが主流であった)
2.歴史 (ORACLE8 / 8i / 9i / 10g / 11g / 12c 現在)
そのような中で ORACLE MASTER は人気を博した。
ITベンダーでは、現にデータベースの知識を持つものが不足し、各社でオラクルマスターを受験する事が推奨された。筆者も1999年にORACLE7の試験を受けた身である。
ORACLE8 から ORACLE9i までは比較的バージョンアップが速く、ORACLE MASTER 制度自体も大きな変化があった。 (Oracleの呼び名も、ORACLE8、ORACLE8i、ORACLE9iと変遷する)
ORACLE9i の途中までの ORACLE MASTER は以下のような3段構成だった。
- ORACLE MASTER Silver : 「SQL入門」、「ORACLE入門」の2科目からなる Oracle Database の入門的な位置づけ
ORACLE MASTER Gold : Oracle DBA として充分な知識を有する専門的な位置づけ
ORACLE MASTER Platinum : Oracle DBA エキスパートとしての位置づけ
それが、ORACLE9i の途中から、上位に Platinum 下位に Silver Fellow (Bronze) が追加され、基本4段構成になった。(実際には他にももっと上の専門分野試験も増えた)
- ORACLE MASTER Bronze : 「SQL基礎」、「DBA基礎」の2科目からなる Oracle Database DBA としての基本知識の認定 (入門レベルではなくなった)
- ORACLE MASTER Silver : Oracle DBA として業務を一通り実施できるアソシエイトの認定
- ORACLE MASTER Gold : Oracle DBA として業務をリードできるプロフェッショナルの認定
- ORACLE MASTER Platinum : Oracle DBA としてトップレベルのエキスパートの認定(実技試験有り)
上述に「下位に」と書いたが、それは内容を知らない者から見たイメージである。
内容的には旧制度の「Silver」が、新制度の「Bronze」に該当するので、全体的な難易度がUPした事になる。
しかも、OracleのバージョンがUPするに従って新機能が増えて、必要な知識量も増加する傾向があるため、同一ランクであっても、バージョンがUPするごとに基本的な難易度も上がっている。
例えば、ORACLE7の「Silver」対策用の参考書「ORACLE MASTER ハンドブック Silver編」(リックテレコム刊)は、2科目をカバーして382ページになっているのに対して、Oracle12cの「Bronze」"SQL基礎の1科目分のみ"の対策用の参考書「オラクルマスターステディガイド Bronze 12c SQL基礎」(SBクリエイティブ刊)は、それだけで554ページにもなっている。
ページ数だけで単純比較は無論できない訳だが、必要な知識量が増えている事は間違いない。
これはあくまでも私感ではあるが、旧制度で「Gold」まで合格した人でも、新制度の「Bronze」に合格するためにはかなりの学習が必要だろう。(Bronze という最下位のイメージだけで舐めてかかると、まず合格できないだろう。人事の者にはわかるまいが…)
3. 変わっているもの、変わっていないもの、…の見極めができるか
筆者は、いわゆる「就職氷河期」、「失われた20年」の初期に社会に出た世代であるが、多くの同年代はリーダー職やマネージャー職といった管理職に就いている。この世代は、ORACLE といえば ORACLE7 や ORACLE8 といった世代であり、ORACLE MASTER を受けた事があるといっても、ほとんどが旧制度の内容であると思われる。 「UNDO表領域」の事を「ロールバック・セグメント」と言ってしまう世代である。
古い用語が出てしまう等はまだまだかわいい方で、20年近くも前に学習したSQLや、RDBアーキテクチャーの知識が今でも通用すると思っていたり、下手をするとオラクルマスターの制度が変わった事を知らなかったり、今でも「ORACLE」の知識を持っていれば安泰だと思っていたりする。(矛盾するが…)
現実には、WebサーバーOSのシェアは Linux が圧倒的となり、そのバックエンドで利用されるRDBMSも MySQL 等のOSSが急激にシェアを拡大している。 すでに ORACLE だけの知識では通用しない時代になってきている。
しかしながら、ORACLE MASTER は今年で20年目を迎え、今後も当分は受験者は減らないだろう。SQLの基礎知識やRDBアーキテクチャーについて、広く通用し得る認定試験制度は、他にないからだ。
IBM が、オラクルマスターを追い越せとばかりに、IBM国際認定制度「DB2グローバルマスター」という制度を積極的に打ち出していた時期があり、筆者もそれを受けた身ではあるが、なかなか広まらなかった(…という認識をしている)。 LPI-JAPAN が、OSS-DB 認定試験制度(実際の内容はPostgreSQL)を展開中であり、今後に期待しているが、情報量では ORACLE にまだまだ勝てていないだろう。
それに、ここには記さないが、ORACLE のアーキテクチャーのかなりの部分は、過去のバージョンから受け継がれているものである。 基幹系システムの心臓部分では、まだまだ ORACLE が利用されている。
今では仕事以外の時間にはろくに学習もしないというリーダー職やマネージャー職の同世代諸君には、もう一度、学習をしていただき、何よりも『何が変わって、何が変わらないのか』という点を見極める、『技術の目利き』を養っていただきたいと思う。
4.今回の観点
Oracle の近年の動向や、Sun(Java)や、MySQLを買収したり、Oracle Database の料金制度が色々変化したりと、様々な観点、意見が世の中にはある。
今回は、あくまでも"同世代の人々にもう一度、学習を促したい"という主旨のみで記載した。決して Oracle の回し者ではないので、そこは理解していただきたい。
5.関係リンク
ORACLE MASTER 再受験のススメ - 今では管理職になっているご同輩諸君へ -
6.終わりに…
IT系の認定資格試験については、その価値について、賛否両論がある。
結局のところ、活かすも、活かさないも、本人の取組姿勢次第という事に尽きる。
ORACLE MASTER を例に挙げても、ただ単に合格すれば良いのであれば、ひたすら参考書や問題集を解くという方法で、Silverあたりまでは行けるだろう。
本質は、その過程で、体系的に学ぶという部分であると個人的には考える。
資格の部分は点の知識でしかない。その点を学習する過程で、いかに線や面の知識を得られるか、である。
若手にCOBOLを教える事は可哀想か
若手にCOBOLを教える事は可哀想か
『これからのIT業界を担ってゆく若手をコボラーにするのは可哀想だ』という意見がある。現実に、某巨大コンピュータメーカー本体に入社したものの、配属先が金融機関システムのプロジェクトで、新しい技術とは無縁の世界では働くのが嫌なので会社を辞めたという記事が、昨年にも話題になった。
私の意見としては、せっかく高い競争率を突破して入ったであろう巨大メーカー本体の社員という身分を、そんなに簡単に捨ててしまって、なんとまあ、もったいない事か、と思った。
率直に言うとね……。
価値観は人それぞれなので、こればかりは仕方が無い。でも、そんなに簡単に辞めるなら、替わりに自分がメーカーの社員になりたかった、という人は大勢いるだろう。
そういう人は、何故メーカー社員になりたいのだろうか。
日本を代表する巨大コンピュータメーカー本体の社員ともなれば、嫌が上でも、若いうちから関連企業のベテラン社員や、言葉は悪いがいわゆる下請けパートナー企業のエンジニアを統率するような位置での仕事になってくる。
（はじめのうちは、それこそ金融機関システムならCOBOLプログラマーとして出発するかもしれないが、数年もすればそういう立場になってくる）
確かに地道にプログラマーとして腕を磨いて行きたい、という方向とは異なって来るだろう。しかし、これは現実的な問題として、『いちプログラマーにはいつでもなれる』が、『巨大メーカー社員としてプロジェクトを率いる立場にはなりたくてもなれない』という、業界の構造問題がある。
プロジェクトを率いるという事は、『要件定義』といった顧客側責任の業務にも深く関与するという事だ。そして、システムには業務アプリケーション領域だけではなく、インフラ領域も必要となる。メーカー系社員なら、インフラ系の領域に道を見出す事も可能だ。
（それが、たとえクローズド環境の特殊なインフラ機能であったとしても、業務アプリケーションの土台となる基盤には何が必要なのか等、多くの知見があるだろう）
COBOLが死滅すると言われて何年が経過するか知っているだろうか。
私が知る範囲でも、30年も前からずっと言われ続けてきた。
そしてこの30年間で、たしかにペースの増減はあるだろうが、毎年COBOLプログラム資産は増加し続けている。
これは私見であるが、COBOLエンジニアは、金融機関の業務システムのような、『業務知識とセットで』育成されてきた感が強い。
そうしたCOBOLエンジニアは、今では人手不足で、現場は大変だという。
価値観は様々であるが、シンプルにこう考える事もできる。
『人手不足』という事は、その領域の知識やスキルセットは『飯の種になる』
福祉や介護系の人材不足の状況等を見るに、一概に人手不足の領域が良いとは言えない部分もあるけれど……。
少なくともこれだけは言える。
プログラミング言語の習得といった問題は、実は些細な問題で、IT業界でエンジニアとして長く活躍して行きたいならば、顧客側の業務要件定義の領域と、システム側のOSやデータベースといった基礎知識の領域を、バランス良く持っている事が重要である。
果たして『新しい技術』のうち、本当に『新しい』のは、どれなのか。
実は、大昔に流行した概念が、言葉を変えて再来しただけかもしれない。
変わるもの、変わらないもの。
これらの見極めが重要なのである。
