技術・デザイン

OSSコミュニティ活動が
技術的成長と事業貢献につながる

~Keynote登壇から技術書執筆まで広げた1年間~

インターネット産業の変化にあわせて様々な事業を提供している当社では、多様な技術領域において若手エンジニアが日々活躍しています。FEATUReSでは彼らの活躍を連載形式でご紹介します。

第5回目は、当社のアドテクノロジー分野におけるサービス開発を行うエンジニアの横断組織「アドテクスタジオ」に所属し、インフラエンジニアを担当する入社3年目の青山 真也です。

技術書「Kubernetes完全ガイド」(インプレス)の執筆や、OSSコミュニティでの活動、年間15回を超える登壇など、社外での活動を通じて、自身の技術向上に繋げている青山。それが結果的に会社への貢献に繋がると話します。青山の考える、エンジニアとしての知見を深め方、ぜひご覧ください。

Profile

  • 青山 真也 (アオヤマ マサヤ)
    株式会社サイバーエージェント アドテク本部 Strategic Infrastructure Agency

    2016年入社。OpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームをゼロから構築し、国内カンファレンスでのKeynoteに登壇。その後、世界で2番目にCertified Kubernetes Application Developer、138番目にCertified Kubernetes Administratorの認定資格を取得。現在はKubernetesやOpenStackなどOSSへのコントリビュート活動をはじめ、CNCF公式のCloud Native Meetup TokyoのOrganizerやJapan Container Daysの運営などコミュニティ活動にも従事している。
    Twitter ID:@amsy810

新卒1年目にOSSコミュニティでの
活動をはじめてみた

ー 計544ページにわたるKubernetesの技術書を1人で書いたそうですが、どのくらいの時間を費やしましたか?

Kubernetes完全ガイド」の執筆には半年以上かかりました。文字数は約30万字程度で図画は288枚、よくある質問とその回答を199件入れています。体系的かつ網羅的に解説しつつ図やサンプルを多くし、入門から本番利用までを意識して書きました。

ふりかえってみると、楽しかったのもあり土日も平日も夜中まで原稿を書いていました。執筆はMarkDownとRe:VIEWで書いていてページの仕上がりはPDFで確認していたのですが、実際に書籍が送られてきた時は、その重量に感動しました。そして本日、無事に書店発売日を迎えられてホッとしています。レビューに関わってくれた社内外のエンジニアの皆さんには感謝しかありません。

ー 技術書の執筆は仕事をしながら書けるものでしょうか。

サイバーエージェントは業務時間内の技術調査や学習について細かく言われるカルチャーではないですが、自分の中では執筆活動は日々の業務とは完全に別で考えていたので、業務時間外のみに執筆していました。

今年の4月からは、これまでのカンファレンス登壇やOSSへのコントリビュートの成果が認められ、サイバーエージェントの技術執行役員である佐藤真人さんの直接配属となり、登壇活動やコミュニティ活動を明確に事業成果として評価してもらえるようになりました。そのため、その頃からは1日何時間と決めて、業務時間中にも執筆していきました。

この「Kubernetes完全ガイド」の執筆も、これまでのコミュニティ活動の延長線上でインプレスさんに声をかけてもらった話なので、技術書執筆も含めてコミュニティ活動が会社にも評価されることはすごく嬉しいですし、感謝しています。

ー 外部でのコミュニティ活動はいつから始めたのですか?

きっかけとなったのは新卒1年目にあたる2016年の12月くらいに登壇した「Okinawa Open Days 2016」です。「OpenStack 環境における Container as a Service の提供と課題」というテーマで発表しました。もともとは別の人だけが発表する予定でしたが、追加で枠を頂けることになり、私も登壇することになったという経緯でした。初めての大きめな登壇でしたが、当時としては先端事例を紹介できたので、周囲の反響もよく、色々な方と交流することができました。

本格的に活動し始めたのは、2017年10月くらいからなのでまだ1年くらいです。「Kubernetes Meetup Tokyo」や「Docker Meetup Tokyo」など様々な勉強会に参加し、登壇経験を増やしていきました。ここ半年はクローズドのものを含め、大小合わせて18件ほどお話する機会をいただきました。中でも国内カンファレンスでKeynote(基調講演)を話せたのは非常に貴重な経験でした。

また最近ではOrganizer側にもまわり、「Cloud Native Meetup Tokyo」を立ち上げました。日本初のCNCF公式Meetupとして認定されたときは、嬉しかったです。毎回150人程度集まって頂き、Cloud Nativeなプロダクトについて共有しあえるのは参加していただける皆様のおかげです。

ー 会社に属していると、社内の技術やコミュニケーションに閉じてしまいがちですが、OSSコミュニティに貢献することのモチベーションはどこにありますか?

例えば私ともう1人で開発したAKEというコンテナ基盤ですが、技術的に評価することができる人がチーム内に大勢いるわけではなりません。というのも、サイバーエージェントは多種多様な事業に対して様々なエンジニアが携わっていますが、それぞれが専門とする技術は異なります。

自分達が開発したプラットフォーム基盤の技術的な価値はどこにあるのか、目指している技術的方向性はトレンドの向かう先と合っているのか。それを会社で測るのではなく、技術コミュニティに求めたほうが、技術的にフラットな意見が得られます。私がMeetupやカンファレンスで登壇したりするモチベーションのひとつはそこにあります。

OSSコミュニティでの活動を
技術的な評価につなげるには

ー 事業やプロダクトに対して技術的に貢献すれば評価されますが、OSSコミュニティでの活動は事業への貢献が間接的です。会社へはどのような影響があると思いますか?

まず個人的な考えとして、コミュニティ活動をするエンジニアが増え、自身で発信することにより、会社の技術ブランディングにつながると考えています。真に「技術のサイバーエージェント」を体現できる様になりたいと思っています。また、技術ブランディングの向上は採用にも影響するので「採用には全力を尽くす」と掲げているサイバーエージェントのミッションステートメントにも合致します。

また、OSSに対するバグ修正や機能追加は、結果的にそのOSSを利用するプロダクトの品質を高めます。また、普段からOSSを使わせて貰っていますし、何かあったときにはSlackやGitHub Issueで助けてもらったりしている分、少しでもコミュニティに恩返しもしたいですね。

その他にも、コミュニティ活動をしていると、新しい情報や知見など、得られるものたくさんあります。技術的な知見を社内に還元することができることも会社のためになると考えています。

ー そういった活動をどのように会社の評価につなげていますか?

例えば私は新卒1年目の時に外部での活動をしはじめましたが、最初から活動の全てを直接的に評価してもらうのは難しいと思います。

OSSへの貢献も、まずはドキュメントの修正や小さいバグの修正などから始めて、実績を増やすことでそのOSSやコミュニティへの理解を深めていきました。現在はKubernetes OrganizationのいちプロジェクトでReviewerとしても活動しています。

コミュニティ活動という面でも同様です。仕事に導入したノウハウをMeetupなどで発表することでコミュニティでも信頼してもらうことができます。逆にMeetupで得た知見を社内にフィードバックし続けることで社内での理解も増えていきます。そういう信頼関係の積み重ねが大事なのは何でも同じではないでしょうか。

今回「Kubernetes完全ガイド」の執筆に声がかかったのも、そういった活動の延長線上にあると思っています。

ー 事業とは具体的にどのように関わるのでしょうか

私はKubernetesに多少早い段階から関わってきたので、いまアドテクスタジオで採用されているGKEやAKEを使った開発において、大部分の技術的な課題を解決することができます。新規に導入する際のサポートだけでなく、プロダクトの設計段階からアーキテクチャを考案したりもします。社内におけるコンテナ技術の導入時に正しい形で利用されることが、私の社内での役割でもあります。

コミュニティ活動での実績を増やし、同時に社内へ還元していく。採用につながるなど間接的なことでも良いので事業に貢献していくと、エンジニア以外にも理解者が増えるので、いつか事業の方向性と合致するタイミングが来ます。

私の場合は、あるタイミングから技術執行役員の佐藤真人さんが直接、社内の仕事と社外の貢献を含めて評価してくれるようになりました。それも突然目に止まったというよりも「こういうことをしたい」とマネージャーと相談していたので、佐藤真人さんと相談して人事案を提案してくれて実現に至りました。

利用する側から提供する側にまわってみる

ー 企業があたりまえのようにOSSを利用する時代で、エンジニアとしてどんなスタンスで向き合うのが良いでしょうか

OSSは商用製品ではないので、OSSを使うという選択をした時点で、OSSコミュニティとの関係を考慮していく必要があると考えています。当然、バグもあるので可能であれば自分たちで修正してアップストリームにプルリクエストを送るのが理想的です。

もちろん、OSSを利用するだけでも良いとは思います。ただ、利用している対価としてバグを見つけたときの修正を提案するとか、困っている人がいれば手を差し伸べたり、質問があれば答えるといったことが大切だと思っています。先程の信頼関係の積み重ねの話ではないですが、誰かにとっての貢献は巡り巡って、いつか自分に帰ってくるからです。私もいつか大きな貢献をしたいです。

ー OSSにコミットすることでエンジニアとして考え方が変わったことはありますか?

OSSを開発している人たちは優秀なので、その人達のアーキテクチャや考え方や概念思想が学べるのは大きいです。

Kubernetesも、元々はGoogle社内で使われていたBorgというソフトウェアのコンセプトが継承されています。もちろんBorgにも源流となるソフトウェアがあったはずです。このようにいろんな分散システムの思想が要素として継承されているので、それを読み解くだけでも技術的に成長できると思っています。

Borgのようなソフトウェアを作った人たちの中に脈々と受け継がれている思想は、遡って簡単に追えるものではないですが、失敗と成功から見出した思想は今、Kubernetesという形で後世に継承されています。Kubernetesは今ではGoogleのGKEやAmazonのEKSに採用され「Kubernetes is becoming the Linux of the cloud」と言われるくらいデファクトスタンダードとなっています。

それに、機能が追加されるといってもいきなり追加されるわけではなく、コミュニティで議論して方向性を決めてから実装されます。その議論はGitHub上で追うことができるので、どうしてこういう実装になったのかを紐解くのもひとつの楽しさでもあります。

ー AWSやGCPといったパブリッククラウドが充実し、サーバサイドエンジニアがマネージドサービスでインフラを見れるような時流の中、インフラエンジニアとしてのありかたをどう考えますか?

その点については私はあまり心配していません。従来どおりのインフラエンジニアとして、基盤の開発もしますし、プロダクトのアーキテクトもやります。仮に世界がパブリッククラウド一色になり、サーバーサイドエンジニアだけで完結する世界になったとしても、私はマネージドサービスを開発する側にまわり、サービスを創るエンジニアとしてありたいと考えています。

ー 自社で開発している基盤やプラットフォームを、GoogleやAmazonなどのプラットフォームが品質的に上回る可能性もありますよね。

それは同時にGoogleやAmazonといった特定のプラットフォームにプロダクトがロックインされる課題もはらんでいます。社内で開発しているAKEはGKEと同じ操作感や品質を目指していますが、Kubernetesのコンセプトからすれば、クラスタがあればどこでも同じ環境で動くのが特徴です。AKEもそのポータビリティ性の高さを重視していて、KubernetesであればGKEでもEKSでもどこでも動かせるように意識しています。

この辺は、Googleの方ともよく話すのですが、事業のフェーズ、ワークロードやデータの種類、金額的コストを踏まえて選択してもらえるのが理想です。いつか実現すればの理想ではありますが、GKEとAKEのハイブリッドで構成してもおもしろいのではないかなと思います。

いちエンジニアとしては、内製や特定のプラットフォームに固執することなく、プロダクトに対してあらゆる選択肢を提供できる立ち位置でありたいと考えています。

オフィシャルSNSアカウントで更新情報発信中
Page Top