FEATUReS

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

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

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

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

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

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

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

ー 事業やプロダクトに対して技術的に貢献すれば評価されますが、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のハイブリッドで構成してもおもしろいのではないかなと思います。

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