3/3「企業に必要とされているインフラ技術とこれから」GMOペパボ株式会社 山下 和彦 × さくらインターネット研究所 松本 亮介

1/3「企業に必要とされているインフラ技術とこれから」GMOペパボ株式会社 山下 和彦

2/3「企業に必要とされているインフラ技術とこれから」GMOペパボ株式会社 山下 和彦

山下 和彦（GMOペパボ株式会社）

技術部 技術基盤チーム シニア・プリンシパル エンジニア

https://twitter.com/pyama86

松本 亮介（さくらインターネット株式会社）

さくらインターネット研究所の上級研究員、京都大学博士(情報学)、複数社の技術顧問。インターネット技術に関するミドルウェアからOS辺りの研究開発やエンジニアリング、組織整備や組織文化醸成、EM、PdMも専門。2018年 Forkwell技術顧問就任。

https://twitter.com/matsumotory

Q&A

Q：インフラエンジニアが書けるコードの基準はどれくらいですか？アプリケーションエンジニアと遜色ないレベルの質ですか？

山下：インフラエンジニアやアプリケーションエンジニアでも、ライフサイクルが長いコードであれば、テスト実装できるか、コードのライフサイクルを守れるような書き方をできるかの観点だと、あまり変わらないと思います。

まつもとりー：ライフサイクルとは、具体的にどういうものですか？

山下：ライフサイクルは、コードの生きる時間という概念です。昔だと、Chef や Puppet、Ansible で、インフラのコードを書いていました。同じ VM に対してアプライすることが多かったと思いますが、当時は初回の登壇者である mizzy さんが作った Serverspec などで、インフラのある状態をテストを書いて実行する作り方が主流だったと思います。またインフラのコードもライフサイクルが長かったです。

一方で昨今だと、コンテナベースになってきているので、ライフサイクルが短くなってきています。全部 Serverspec でコンテナのテストを書くのは、要件に対してファットだと思います。ライフサイクルに対して正しい実装ができるかの考え方でいくと、アプリケーションエンジニアも3日ぐらいしか動かないアプリケーションに対してテストを書くのは要件に対してファットだと思います。

動作確認として書くにはいいですが、カバレッジ100%を目指すような書き方はしないと思うので、コードに対して正しく書けるレベル感でいえば同じだと思います。

Q：インフラエンジニアのキャリア形成についてのご意見をお聞きしたいです。

山下：キャリアモデルを見つけることですね。模倣の話と近いですが、この人すごいな、こういう人になりたいなと感じる人のカンファレンスやイベントに行ってみてください。その人が普段やってることや人となりが見えてくるので、モデルケースにして取り組んでいくのがいいと思います。

まつもとりー：自分が対象にしている領域で、すごいなと感じる人の言動を真似するのがいいんですよね。最初は真似から入るのが大事ですね。

Q：IaCは製品やサービスが乱立していて、覇権が見えにくい状態にあると思います。この先の保守性を考えると、何を組み合わせていくのが鉄板でしょうか？

山下：ツールで考えると、自分がコントリビュートすることで、コントロールできるか。ソースコードが理解できるか、から始まり、自分で何とかできるかは大事にしています。

まつもとりー：自分でやりたいことがあったときに、それがオープンソースとして受け入れられて、新しく機能追加されて、デフォルトにできる。オープンソースによっては1週間あげても反応してくれないときもあるので、反応は大事かもしれません。

山下：ライフサイクルに近い話ですが、すぐ捨てられるような使い方をするのがいいです。未来はわからないので、コントロールできることを増やしていく考え方のほうがいいと思います。

まつもとりー：第1回でお話してくれた mizzy さんが、このテーマに近いことを研究していくと話していたので、模倣の話に近いかもしれませんが、第1人者がこの先を見据えてやろうとしてることを見ていくのがいいと思います。

Q：インフラエンジニアは、今までコードを書いてこなかった人も多いと思います。言語など、どこから始めるのがいいでしょうか？

山下：自分の隣にいる人や自分を幸せにするツールがおすすめです。僕が最初に作ったのは、Webエンジニアになりたてのときにコマンドを打つことが多くて、そのときに、Linux のエイリアスコマンドを YAML などで登録できたら便利だと思い、エイリアスマネージャーのようなツールを Ruby で書いたのが始まりでした。

僕くらいしか使ってないツールでしたが、そういったものを書くことで、人のコードを見て学んだりしますし、動いたら感動するので、自分の小さい課題を解決するツールを作るのがいいと思います。

まつもとりー： Ruby を選んだ理由はありますか？

山下：当時、所属してた企業が、Ruby を第1,2言語ぐらいに使っている企業だったこともありますし、Ruby の書き味が好きだったので、使っていました。

まつもとりー：周りにも Ruby が得意な人がいた影響はありましたか？

山下：たしかにありますね。

まつもとりー：真似しやすかったり、すぐ役に立ちそうなことは書いてみて、わからないところは調べたり聞いたりしながらやっていくのがいいですね。

Q：山下さんにとって勉強を続けることは楽しいですか。なぜ楽しくなってきたかについて教えてください。

山下：成功体験を積み重ねられてるからだと思います。Tech の分野では自分が必要だと思うものを勉強し、組織にインストールして、それが評価されるサイクルを回しています。僕はこのサイクルが楽しいです。

ここ1,2年は毎日英語を1,2時間。週で10時間くらい勉強していますが、Tech 系の記事や海外ドラマを見たときに、どんどん自分が理解している実感があるんですよね。これは Tech の勉強と違う喜びがあります。自分のなかで小さい成功体験をうまく作れているから、楽しいと感じています。

まつもとりー：その考え方は社会人になってからですか？

山下：社会人になってからです。最初の上司はライバル心をむき出しにしてくる人で、その人と競っているうちに楽しいと思うようになりました。当時はわからないことばかりでしたが、段々とわかってくる感覚が芽生えてきたのが楽しいと思った理由です。

Q：オンプレで行うコンテナのメリット、デメリットは何が想像できますか？

山下：まずはオンプレかどうかの判断が必要ですが、事業規模や通信量など変数によって決まるので、その部分は置いておきます。

オンプレは、そのまま使うと物理サーバーを1台まるまる好きにセットアップできるので、チューニングの幅が広がったり、リソースを有効活用できたり、あとはネットワークを含めて技術的な取り組みができるのはメリットだと思います。

コンテナはただのプロセスなので、そのプロセスを動かす場所をオンプレでやっても、一気に100台増やすことはできせん。一方でマネージドサービスだとお金はかかりますが、一気に100台増やすことも可能なので、その点はメリットでもありデメリットでもあると思います。

まつもとりー：どのあたりを目的にしているかは関連するかもしれないですね。サービスを作って、リリースして、楽にメンテしていきたいのであれば、オンプレから使う必要があるのかは議論の余地があると思います。逆にコンテナのプラットフォームサービスを提供するのであれば、オンプレで作ることもあるので、目的によって変わると思います。