ここ2回ほど、エンジニアの育成という観点での記事が続いていますが、今回もその流れで「資格」というものについて書いてみたいと思います。毎回この連載は筆者の経験に基づく私見のカタマリですが、今回はそれが特にヒドイことを含んだ上で読んでいただければ幸いです。
「資格否定派」の筆者がアリだと思う資格
公認会計士や弁護士といった、資格がないとそもそも活動できないような業種は別にして、IT系の資格というのは昔から賛否両論あります。
筆者は昔は超資格否定派でした。資格もっていることを逆にマイナスに見ていたくらいです。「レジュメに資格を書くということは、実務面でアピールできることがないからだろう」と思っていたものです。
こう過去形で書くと、「じゃあ今は肯定派なのか？」と思われるかもしれませんが、今も否定派なことには変わりありません。ただ、賛成できるケースもないわけではないな、と思うようにはなりました。どういうケースだと資格は「アリ」だと思えるようになったのか、すぐに思い付くところを挙げると、
だと思います。
まず①についてですが、これはわかりやすく、CiscoやOracleがやっているようなケースです。さすがにメーカが自身でやっているだけあって、上級の資格を取れば「その製品に関する知識」についてはそれなりのものがあるのではないか、と最近では思うようになりました。
上級の、と書くと、じゃあ下級は駄目なのかと言われそうですが、下級でやめるのが駄目だと思います。下級の資格がないと上級に行けないという意味で下級を取っている、いわば発展途上の段階では別に良いと思いますが、下級の資格だけ取ってそこで終わりでは、「その製品に関する知識が豊富」という目的にはそぐわないと思います。履歴書にオラマスシルバーとかCCNAとか書くのは、英検3級とか珠算4級とかを書くようなものじゃないでしょうか。
言いすぎだったらスミマセン。
次に②についてですが、これは資格の目的を正直に言うなら「アリ」だろうと思います。とかく（特に不況のときは）未経験でエンジニアになるというのは狭き門です。筆者はエンジニア出身というか今でも幸か不幸かエンジニアなので、面接する際にも地力や地頭というものを重視して判断しますが、そうでない場合はやはり履歴書や職務経歴書で判断するケース（会社）というのは多いのだと思います。
誰でも最初は未経験なので、この最初の「未経験だけどエンジニアになる」最初の壁は必ず越えなければなりません。
たとえば自分で個人サービスを運営して経験を積むとか、非エンジニア職から入ってエンジニアに転向するといったケースを除くと、未経験にもかかわらず、エンジニア採用に応募するしか手がありません。そういう場合、履歴書、職務経歴書で判断する（でないと判断できない）会社に応募する場合には、資格が多少の武器になるのは否めない事実です。
とにかくなにがなんでもエンジニアになりたい、そのために役に立つことはなんでもする！！という姿勢で資格を取るという発想は、これはこれで正しいのだと思います。そういう一所懸命な努力を否定するのは良くないことですね。
資格と現実の「ギャップ」とは？
とはいえ、上記のような資格が有用なケースもあるとはいえ、筆者は未だに資格否定派であり、またそういう風潮が一般的にもあるのは事実です。これは何故なのでしょうか？
それはひとえに「資格を取ることで身についていることがわかるスキル」と「現場で欲しいスキル」にギャップがあるからだと思います。こうしたギャップにはレベル的（縦方向）なギャップと範囲（横方向）のギャップがあります。
レベル的ギャップとは、「そのくらいの知識はあってあたり前だよー、大事なのはそこから先だよ」といったものです。まあこれでも、前述の②のようなケースでは一助になるものですが、それで必要十分かというと、そうではないわけですね。
範囲のギャップというのは、「そんなこと知ってても使う場所ないよー」というものです。そうすると結局「じゃあその資格持ってるからって、実際何ができるのさ」とか思ってしまうわけです。その上さらに「この資格を書くってことは、この資格が自分のアピールになるからって思ってるんだな。てことはわかってないなー」とまで思ってしまう場合もあります。
もちろん、こういった見方は前述の②に真っ向から反対することはわかって書いています。なんでこんな矛盾が起こるかというと、これはコンテキストが違うからに他なりません。話は逸れますが、「コンテキスト」って便利な言葉ですね。プログラミングの場面ではよく使われますが、もっと一般的に普及しても良いんじゃないかと思います。
話を元に戻すと、即戦力が欲しい場面で「私は経験豊富なエンジニアです」というコンテキストで履歴書や職務経歴書に資格が書いてあるのと、即戦力じゃなくても将来を期待できる人材が欲しいという場面で、「私はまだ経験は不足していますがやる気はありますチャンスをください」というコンテキストで書いてあるのは当然別だということです。
前述の①のようなケースにおけるオラマスのプラチナやCisco CCIEのトリプルなどはまた別として（別なのか？）、一般的に資格を取得するための知識経験というのは、そこそこデキるエンジニアの標準より低いものです。ということは、自分がそのレベルより上に行ったら、もうその時点でその資格は自身のアピールという点では役に立たないということになります。ここが資格の一番の問題点なのではないでしょうか。
つまり、「この資格があるならそりゃあ即戦力で実践でも十分通用するよ」という資格があればいいだけなのではないでしょうか。
「Social Certification」が欲しい！
ここから先、非常に微妙な内容ではありますが、別にLPICが駄目だと言いたいわけではないので、そう含んで読んでください。
たとえば、先月筆者はLinuxでLPICという資格があることを聞きました。LPICについて調べてみると、LPIC-1、LPIC-2、LPIC-3というのがあるようです。そこでLPIC-3の例題を見てみると「これじゃ役に立たねえ」という内容です。まあ、これは縦方向にずれている、つまり「レベルが低い」という問題と、横方向にずれている、つまり「範囲が違う」という問題の両方が含まれています。
横方向は別に対象の違いなので、良い悪いで評価するものではないのでしょう。どうもLPIC-3はイントラというか社内システムを重視しているようなので、Webサービスやソーシャルアプリという観点で戦力になるならないとは基本的にフィールドが違う気がします。ただ世の中の需要でいうと、社内システムよりもWebサービスのほうが需要が多いというか、エンジニアになれるチャンスは多いのではないでしょうか。
縦方向は、これはもう正直「レベルひくいなー」としか言いようがありません。もしかしたら今後LPIC-4とかLPIC-5などが出てくるのかもしれませんが。
だいたい、記憶ベースの試験というのが変です。エンジニアとして重要なのは、覚えていることよりも「いかに短時間で調べられるか」です。経験ある人も多いと思いますが、ミーティング中に覚えていないことを質問されて、「あー、それはですねー」とか言いながら手元のターミナルを叩いて、数秒くらいで答えがわかれば、あたかも「覚えてましたよそれくらい」という感じで回答できるものです。
繰り返しますが、別にLPICそのものが悪いと言っているわけじゃありません。たまたま有名な資格のようなので例として挙げただけで、そもそもLPICはイントラや社内システムを対象とした資格で、LPIC-3がクリアできるレベルまでを判定するのが目的ということであれば、全く問題ないのです。いやほんとに。そうですよ。
ただ、もしこれが「LPIC-3を取れば楽天とかmixiとかGREEのサーバをバリバリ管理できるくらいのレベルになれるんだ！」とか思ってしまうと、それは如何なものかっていう話ですね。いや正直、楽天やmixiは例が極端すぎですが、LPIC-3では一般的に公開するそれなりのサービスを運用するには全然不足です。つまり、コンテキストが重要なわけです。
ということはつまり、前述の①のようなケースはさておいて、一般的なWebサービスなどのシステムを運用するに足るかどうかを判断できるような資格がたまたま今は存在しない、というのが正解のような気がします。
もしそういった資格があれば、別に資格否定派である必要もなく、「おお、○×△のレベル5をもってるってことは、相当期待できるね！！」というやり取りが成立することも十分ありえるでしょう。もちろん、知名度の高い、それなりにスキルを要求されると思われるようなサービスの運用経験がれば、そもそもそんな資格などは要りませんが、それでは今未経験でこれからエンジニアになりたい、という人に道が開けません。
いま最前線で働いているインフラエンジニアの人たちから「こういう問題を出せばいいのに」とか「こういうスキルが判定できるような資格があるといいのに」という意見は、集めれば出てくると思います。そういったものをうまくまとめて、資格と試験で判定できるようにすれば、もっと資格というものが有用になるのではないでしょうか。「Social Certification」と言っていいかもしれません。
最後にちょっとだけ宣伝ですが、ゼロスタートコミュニケーションズでは、現場力を鍛えることを重視したサーバエンジニア向けITスクール「tech camp」を4月から開始しました。さすがに上述のような資格試験をいきなり制定して運営することはまだできませんが、せめて「現場で欲しいと思えるような」スキルを身に付けることを重視した、またわりと珍しいサーバエンジニア特化型スクールです。
要は、いま現場で活躍するエンジニアが「こういう人がいたらいいのに！！」という視点でエンジニアを教育したり、指針を示したりすれば、もっともっとエンジニアへの道というのは拓けていくのだと思います。「tech camp」はそういう流れを作るのに少しでも役に立てたらいいな、と思っています。
ここ3回ほどにわたって、エンジニアになるには、育てるには、というトピックについて記事を書いてきましたが、次回は編集部から期待されている「失敗談」について書いてみたいと思います。
