なぜ技術ブログを書きまくるのか？　『Developers.IO』のクラスメソッドが教える、エンジニアの成長サイクル

クラスメソッド流、AWSエンジニアの育成方法

佐々木大輔氏：こんばんは、クラスメソッドの佐々木と申します。

弊社、クラスメソッドは、AWS環境をお客様にコンサルティングしたり、構築を提案しつつ、その上でいくつかのソリューションを持っている会社です。モバイルアプリケーションの開発やビッグデータ分析、あるいはECサイト向けのBIツールのサービスを展開しています。

そういった中で、我々がAWSエンジニアを採用したあとに、どのように成長していただいているのか。その育成のためにどのような手段をとっているのかお話しします。よろしくお願いします。

最初に自己紹介です。クラスメソッド株式会社、AWS事業部の部長をやっています、佐々木と申します。

私自身は実は北海道の江別市という、札幌の隣りの市に住んでまして（笑）。今日も出張で来ています。部長なんですが本社にいません。普段は地方オフィスにおります。

私自身はもともとインフラエンジニア出身です。公共機関の基幹ネットワークや大学のコアネットワークの設計・構築を、20年くらいやっています。

ちょっと変わったところでは、日本サッカー協会の公認C級コーチの資格を持っていまして、週末はサッカー少年団の指導をやっています。その関連で、サッカーでは3級審判、フットサルでは4級審判の資格を持っています。

AWSエンジニアをいかに育成するか？

さっそく、AWSエンジニアの育成についてお話します。我々もいろいろな競合、あるいは一緒にお仕事させていただいている会社さまから、自社のAWSエンジニアの採用や育成に困っているという声をお聞きしています。「どうやってAWSのエンジニアを育ててるんですか？」というのは、いろいろな会社様によく聞かれます。

まず「AWSエンジニア」が特別なエンジニアなのかと言われると、我々はそうではないと思っています。というのは、言ってしまえばAWSというのはただのサービスですし、AWSのスキルも特定のサービスに対するただの技術です。なので、AWSエンジニアが特別なスキルを持ったエンジニアだとは思っていないです。エンジニアの一種でしかない、と認識しています。

実際に我々クラスメソッドに入社しているAWSエンジニアの前職としては、私ももともとオンプレミスのネットワークエンジニアでしたし、それ以外にもJavaのアプリケーション開発をしていたメンバーであったり、あるいはプリセールスに特化したメンバーであったり、プロジェクトマネージャーをしていたメンバー、それから運用のオペレーターなど、さまざまな前職があり、もともとAWSを知って入社してきているわけではありません。

入社してからキャッチアップをしてAWSエンジニアになっていったので、AWSエンジニアは難しい職種でもないし、AWSが難しい技術でもないと思っています。

実際にAWS事業部でどのような採用状況についてお話すると、2013年、AWS事業部が立ち上がった当時は10名程度でしたが、そこからきちんと採用が伸びていて、現在は50名ほどの部署になっています。

実際に2013年以降、AWS事業部として離職した人は、5年間で2名ですね。それ以外のメンバーはすべて部に残っているか、あるいは弊社内のほかの部門で活躍をしていただいています。

会社内にはAWSエンジニアの認定資格があり、現在の弊社の数字で言いますと「プロフェッショナル資格」と呼ばれるものが109、それから「アソシエイト」と呼ばれる資格が208ということで、資格数で言うと、会社内で合計300を超えています。

実際にAWS事業部としては基本的に全員がプロを所有ということで、資格を取得してから入社しているメンバーもいます。また、入社する前に資格を持っていなかったとしても、入社してから3ヶ月以内にアソシエイトを全部取ってください、というお話もしています。「半年以内に取ってね」という言い方はするんですが、1年以内にプロフェッショナルの資格を全部取っていただくかたちでエンジニアの育成をしています。

エンジニアの成長サイクル

ここでエンジニアの成長サイクルについて整理させていただきます。我々が考えているエンジニアの成長サイクルはこうのようなサイクル状であると思っています。

モチベーションがあって学習があって、アウトプットがあって評価がある。1個ずつご説明すると、モチベーションについては「成長したい」「技術を身に付けたい」という気持ちですね。「なぜ成長したいのか」というところは、人それぞれ理由があると思います。

例えば、自分が技術を身に付けたい、あるいは技術を身に付けてエンジニアとして成長することで認められたい、という承認欲求であったり。ほかには、自分が優れたエンジニアになりたい、という顕示欲。あるいは金銭欲というのは、賃金の話ですね。高いスキルを身に付けて、しっかりとお給料をもらいたい。

それから不安・恐れというのもあると思っています。「しっかり技術を身に付けていかないと仕事がなくなるのではないか？」あるいは「時代に取り残されるのではないか？」という不安・恐れもあると思います。

私の個人的な経験では、5年前この会社に転職したときに、1番大きくあったのはこの「不安・恐れ」でした。もともとオンプレミスのエンジニアで、それこそ何千万円もするようなハードウェアを使って、データベースサーバーを作ったり、ネットワークの構築をずっとやっていたんですが、当時はちょうどAWSの東京リージョンができた時で、クラウドが日本でも非常にブームになっていて、定着してきていました。その中で「このままオンプレミスで、僕はエンジニアとして生きていけるんだろうか？」という不安から、弊社に転職しました。

身につく学習とはなにか？

こうしたモチベーションの次は、学習です。昔であれば本や雑誌などの紙媒体を使うことが非常に多かったかと思いますが、現在はインターネット上で記事も非常に数多く出ています。

例えばAWSのオフィシャルでは、AWSのスキルを身に付けるための動画や、AWSの技術者が講演した際のスライドなどがインターネット上で公開されてます。現在は気軽に、手軽に技術の習得ができる時代になったと思います。

もちろんセミナー・イベントも日本国内でさまざまなものが開催されていますし、東京はとくに勉強会文化が非常に盛んなので、今でも数多く勉強会が開催されていますし、無料のものが多いので非常に参加しやすいと思います。

ですが、やはり一番大事なのは手を動かして実践をすることだと思います。「習うより慣れよ」というのはよく聞く言葉かと思うんですが、自分でただ学習するだけではなくて、実際に手を動かして、動くものを作ってみる。あるいは使ってみることによって、慣れることが1番の学習の近道であると思います。

アウトプットする重要性

そして今度は、学習したものに対してアウトプットがあると思っています。弊社もエンジニアには「アウトプットが非常に重要だ」という話をよくしています。なぜアウトプットが重要かと言うと、学習というのは身に付けただけでは評価されるものではないからです。

勉強して知識を身に付けたところで、それが他人に見えるかたちでアウトプットされなければ、本当にそのスキルを持っているのかわかりません。それがわからないと承認欲求・自己顕示欲も満たされませんし、会社も「勉強しました」と言われても「あぁそうか」で終わってしまいますよね。

勉強したことをしっかりとアウトプットする。例えば仕事であったり、あるいは会社内で勉強会をやって同僚に対してその技術を共有するでもいいです。アウトプットがないと、会社や上司からすると評価ができません。そして、評価できないとお給料が上がらないので金銭欲も満たされない、という流れになると思います。

なのでアウトプットというのは、その技術を身に付けていることを他者に認識していただくための行為です。これがあって初めて評価されるものになると思います。

アウトプットすれば評価され、モチベーションに繋がる

次に評価です。アウトプットして、その技術を身に付けたことでどのような評価が発生するかと言うと、社内外で他者に頼られるようになる。「この技術についてはこいつが知ってるので聞こう」、あるいはなにかお仕事があったときに、その仕事ができるかどうかわからない人に急に言うのではなくて、既にアウトプットがある人に「あなたはこの技術を持っているのでこの仕事を任せたい」と仕事が渡せるようになります。

さらにそこで利益に貢献することで業務上の成果として、いわゆる会社としての評価、人事考課につながります。

クラスメソッドでは、このモチベーション、学習、アウトプット、評価というサイクルを生むために、技術ブログを使っています。『Developers.IO』という技術ブログですね。こちらにいる方、読んだことありますか……？

（会場挙手）

ありがとうございます。技術ブログがエンジニアの育成にとっても非常に重要なツールになっています。先ほどの流れと同じようにご説明すると、まずモチベーションですね。

弊社では同僚、部長、社長含めて全社員が積極的にブログを書いています。隣りに座っている人間、あるいは自分の直属の上司もブログを書いています。このブログを書くことで同僚からも認められますし、ブログの記事がTwitterやFacebookなどのSNSで共有されたり、はてなブックマークに登録をされるなど、そこでフィードバックとしてコメントをいただくことで、読者からも認められます。

もちろん弊社では、ブログを書くことを業務上の成果としても評価していますので、このブログを書くこと自体が評価につながるモチベーションになっています。

不安・恐れという観点では、「ブログを書かないと認められない」。これは会社としてはブログの本数が少ないからといって減点をすることはありませんが、周りの人間がたくさん書いてると、「俺、書いてなくて大丈夫か？」という気持ちになる、という部分で不安・恐れが発生する場合もあります。

エンジニアはどうやって学習している？

次に学習ついてですが、先ほどお話しましたとおり、AWSの公式情報が非常にたくさんあります。リリースノートも英語のものから、最近では日本語翻訳も非常にスピードが早くなりましたので、AWSの公式情報でも非常に早く情報を吸収できます。

リリースノート、それから動画、スライド、オンラインセミナーもあります。AWSはBlack Beltというオンラインセミナーを積極的にやっているので、そこから簡単に学習ができる状態です。

もちろん同僚のブログを見ることでそこからさらに刺激を得たり、そこから学ぶこともあります。

先ほど「手を動かしてやってみる」というお話もしましたが、弊社の技術ブログは基本的に「やってみる系のブログ」と言ってます。ただリリースノートを読んだりドキュメントを読んで学んだことをブログにするだけではなく、自分で実際に手を動かして触ってみた結果をブログにする、ということを重要視しています。

この学習した結果が、ブログというかたちでアウトプットされる。そして、書いたブログはパブリックに露出されますし、SNSにもシェアされるので、アウトプットがどんどんと拡散していく状態になります。

ブログを評価する仕組み

そして評価です。もちろんブログを書くというモチベーションを持って学習し、アウトプットするところに対して、会社としてはきちんと評価をします。

どのように評価をしているかと言うと、1つは本数という指標です。弊社では月4本エンジニアがブログを書くことを推奨しています。これは罰則はないので、書けていないからといって減点をすることはありません。逆に書いてるからといって加点をすることもありませんが、月4本を推奨していますし、10本書く人は高評価ということで「ブログのプロ」と呼ばれることがあります（笑）。その月は「10本書いたからプロになったね」というようなことを社内で言われたりします。

あとはSNSのシェア数ですね。弊社のブログ上ではSNSでのシェアが増えるとポイントに加算されて、そのポイントが貯まった記事についてはポイントが個人に付与されるので、ランク形式で個人がどのくらいブログを書いているのか、書いたブログがどのくらいSNSでシェアされているのかが可視化されるようになっています。シェア数が多いと一目でわかるリボンが付与されているので、人気のあるブログがわかるようになっています。

あとはSNS、はてなブックマーク、コメントによるフィードバックで高評価されると自己顕示欲・承認欲求が満たされます。私も比較的ブログを書いてるほうなんですが、それがSNSで拡散されて「すごく良い記事だよ」と言ってもらえると非常にうれしいし、次にブログを書くためのモチベーションにつながります。

もちろん厳しいツッコミをもらうこともあります。弊社のブログは公開前の社内レビューがないので、エンジニアが書きたいときに書きたいことを書く。そして、誰もチェックせずリリースされます。もちろんエンジニアとしてもたまには間違うこともあるので、厳しいツッコミいただくこともありますが、それ自体が次の学習につながるので、また次のモチベーションになると思います。

業務上の評価ということで、先ほど「減点・加点しないよ」というお話をしたんですが、3ヶ月に1回、ブログの本数とSNSのシェア数とビュー数が多い人に対して表彰をしています。やはり継続的にアウトプットをしているとこういった場面で表彰される機会も増えるので、社内でも「この人はたくさんブログを書いてるんだ」「この人はすごく高いスキルを持ってるんだ」と認められ、評価にもつながります。もちろん上司からも、技術ブログを書いてアウトプットが多いことが高い信頼につながります。

技術ブログは継続あるのみ

なので我々は、技術ブログはエンジニア育成に最適なので、ぜひほかの会社さんにもやっていただきたいと思っているんですが、やはりいろいろな会社様から「技術ブログは難しい」と言われます。「立ち上げたものの社員が書いてくれないんですよね」というケースはよくお聞きしていて、「クラスメソッドさん、なんでこんなにみんな書いてくれてるんですか？」と聞かれます。

これに関しては、もうひたすら書き続けるしかないと思っています。最初は当然無名なので、アクセスやSNSシェアは少なくても仕方がないんですが、コンテンツの量が増えることで検索からの流入も増えますし、SNSにシェアされる機会も増えます。本数が少ないときに「アクセスがないんだよね」って悩んでもしょうがないので、ひたすら書き続けるしかありません。

それと「どうすればエンジニアメンバーがブログを書いてくれますか？」ということに関して言うと、一番早いのはトップダウンだと思っています。つまり、偉い人が一番書くのが重要だと思っています。我々の場合は社長です。弊社の技術ブログも、もともとはうちの社長が「技術ブログやろうぜ！」と言ってはじめたんですが、誰も書いてくれなくて、1年～2年、社長だけがずっと書き続ける時期がありました。

その結果、周りのみんなが見かねて、「しょうがねぇな、書いてやろうぜ」と言ってみんなで書くようになった結果、現在では1週間にだいたい50本、月に250本の技術ブログが出るようになりました。

私も部長職になって、ブログの本数が減ってはいるんですが、一応「月4本」は今のところ死守しています。たまに10本くらい書くときもあります。やはりみんなに「ブログ足りないな、書けよ」って言うだけだと……「なに言ってんだコイツ」と思われるじゃないですか（笑）。

なので、やはり僕みたいな役職に就いている立場の人間も自分で積極的に書かないと、みんな書いてくれないと思います。

大切なのは「コアスキル」を身につけること

ということで、AWSエンジニアの育成がどのようなサイクルで行われるのかお話ししてきましたが、実際にAWSのエンジニアを育成する中で、1番重要なのは結局のところ、「コアスキル」だと思っています。

コアスキルというのは、AWSのスキルが1番重要なのではなくて、エンジニアとしての基本スキルです。そこはオンプレミスでもクラウドでも変わらないと思っています。例えばネットワークやJavaの知識は、オンプレ／クラウド関係ないですよね。サーバーに対する基本的な知識も変わらないと思います。

なので、このコアスキルをしっかり身に付けているかどうかが1番重要なことだと思います。コアスキルがあって初めてAWSのスキルが身に付くので、このコアスキルが1番重要だと思っています。

例えばインフラ面では、今でこそAWSはいろいろなサービスがあるのでインフラとだけは言い切れませんが、主にネットワーク方面についてはオンプレのインフラとクラウドのインフラは大きく変わらないと思っています。当然ネットワークの知識やサーバーに関する知識も必要ですし、一般的なアプリケーション……例えばセッション管理などの部分でもインフラの知識は、オンプレと同様に必要であると思います。ネットワーク、プロトコル、ハードウェアなどですね。

サービスについても、もちろん基礎知識は必要だと思っています。AWSを使うことが目的ではなくて、AWS上で情報システムを動かすことが目的であって、AWSはインフラとして選んだ手段でしかありません。

なので、AWSを使ってユーザーにサービスを提供するということが情報システムの基本的な目的であるはずなので、一般的なサービスと同様に情報システムを構成する要素についてのスキルは必要だと思っています。これもOSやミドルウェア、あるいは商用プロダクトなど、ログの一般的な知識ですね。

クラウドだろうとオンプレミスだろうと、ログの監視や可視化しなければならないのは変わりません。こういったところがサービスにおけるコアスキルだと思います。あとはセキュリティ、監視、運用というところですね。

プログラミングの知識は必要

プログラムについても、AWSの場合はすべてAPIで操作できるということもあり、作業の自動化・あるいは効率化の点でプログラムが必要になるケースというのは多いと思います。

これはオンプレミスでも同じだと思いますが、結局自動化するためにプログラムを書かなければいけなかったり、ちょっとしたツールを書かなければならないケースは多いと思います。これはAWSであってもオンプレミスであっても変わらないと思います。

なのでプログラムが一切書けないけれどインフラのエンジニア、あるいはAWSのエンジニアをやるというのはなかなか難しいので、どうしてもプログラムの経験・知識は必要になると思います。

AWSのDevOps系のサービスも増えてますので、プログラム開発がどういったプロセスで行われるのか。一般的なCIツールもそうですし、デプロイ、あるいはリポジトリのようなプログラム開発で通常使われるプロセスについても、知識は持っていたほうが良いと思います。

なのでAWSスキルというのは、結局のところはコアスキルです。基本的な情報システムのスキルに対して、肉付けとしてAWSのスキルがあるものなので、コアスキルを拡張して、対応範囲を拡大するためにAWSスキルを身に付けるものだと思っています。コアスキル・AWSスキルを両方身に付けることで、パブリッククラウド時代でも活躍できるエンジニアになれると思います。

サイクルを回すためには「評価」が重要である

では、実際にAWSスキルをどうやって身に付けるかというと、先ほどからお話ししているとおり、やってみて、触ってみて、アウトプットすることです。単にサイトを読むだけであったり、手を動かさないで勉強するだけでは身に付きません。実際にやってみて、触ってみて、触った結果をなんらかのかたちでアウトプットする。これが重要です。

あとは弊社でエンジニアがやっているように、認定資格を取得することもAWSスキルの習得につながります。もちろん、業務で従事することもそうですね。

なのでAWSスキルの身に付け方は、モチベーションを生み、育て、評価する、ということです。そしてこの中でも、会社として1番重要だと考えているのは、評価だと思っています。

モチベーションはエンジニアの場合は自動的に生まれやすいですし、モチベーションが生まれていれば、学習は自分たちで可能です。ですが、評価のプロセスがないと勉強しただけで終わってしまう。それが評価につながらないと、モチベーションはどんどん下がってしまいます。

サイクルを回すためには、きちんと会社が評価して、次のモチベーションを生まなければなりません。こうした理由から評価が非常に重要なので、我々の会社においてもしっかりとアウトプットした人に対しては、しっかりと評価をする仕組みをきちんと成立させています。

IT業界全体でエンジニア育成を

まとめです。冒頭でお話しましたとおりAWSエンジニアを特別だとは思っていません。あくまでエンジニアなので、AWSはただのスキルの1つです。なのでAWSエンジニアの育成プロセスと、1人のエンジニアとしての育成プロセスをしっかり考えていく必要があると思っていて、我々はそれを、技術ブログを用いてやっている、というかたちです。

とくに重要なのが、モチベーションを生み、育て、評価すること。今お話したとおり、評価というプロセスが会社としては大事です。

IT業界のエンジニアの育成という点で言うと、各会社が個別で考えるより、IT業界全体でエンジニア育成を考えたほうが業界としては健全だと思っています。ほかの会社様にも、「我々がどうやってエンジニアを育成しているのか」という情報は公開したりお伝えしていますので、みなさんもぜひ、エンジニアの育成をみんなで考えていきましょう。というメッセージをお伝えしたいとおもいます。

以上です。ありがとうございました。

（会場拍手）