初めましてインフラや基盤周りの技術が好きなエンジニアの渡辺です。 今回は私がサービス開発を行う上で心がけていることをお話させて頂きます。 （画像は私の好きな言葉で、ここの過去ブログで使われていた物を再掲させて頂いています）
前提
クックパッドのサービスはクックパッドで整備、運用されている全社共通の開発基盤、インフラ環境上に構築されています。 別に強要されているわけではないのですが、そのレールに乗ることで様々な恩恵を受けることが出来ます。 サービス開発では価値を届ける、検証することにフォーカスしたいのでサービス毎に環境を 1 から構築していては手間が勿体無いです。 そして、セキュリティやバグ等の対応も全社的になるべく共通の環境にすることで環境依存で発生する問題のリスクを分散することが出来ます。
近年は Microservices 化ということで、新しいサービスを立ち上げる環境整備が進んでいます。 Microservices 化の動向については以下のブログが参考になるかもしれませんので興味がある方は是非読んでみてください。
大きな方針としてはサービス開発エンジニアの裁量を増やし、今まで依頼ベースで進めていたことを開発基盤、インフラメンバの力を借りずに作業を進められるようにしています。 ただ権限を渡して「はい、どうぞ」ではなく、使いやすくしたり、ミスが起こらないようにツールや環境を整備してくれています。 依頼ベースでの作業が少なくなれば、サービス開発のスピードも上がります。 開発基盤やインフラメンバがボトルネックにならないように、組織としてスケールする為にも個人的にはとてもいい事だと感じています。
ただ、そこには課題もあると感じています。
課題
モノリシックな Rails アプリケーションで開発していた時代は作業の分業化が進み、サービス開発エンジニアが開発基盤やインフラ環境をきちんと把握出来ているメンバが少なくなっていました。 これはサービス開発にフォーカス出来るようになったことで発生したジレンマであると思います。
また、クックパッドはそれなりの規模のサービスということもあり、開発基盤やインフラ環境は色々複雑化、高度化しているのもキャッチアップが難しくなった理由の一つだと思います。 そしてその環境も日々進化、変化していて前に一度触ったことがあっても、後日また利用しようとした時に既に変わっていて、違う使い方を学ばないといけない場合もあります。
細かくは今回は書きませんが、例としてはどこまでがどう Infrastructor as code で管理されていたかとか、秘匿値の管理が Vault に変わったり、Hako の Cluster の使い分けが増えたり・・・。*1
もう一つは開発基盤はあくまで全社的な共通部分を受け持ってくれるだけで、個別のカスタマイズは自分たちでやる必要があります。 勿論相談すれば助けてくれますし、場合によっては開発をしてくれることもあります。 ただ、上記にも書いた通りスケールする組織になる為には「自分たちで」出来ることが重要だと考えています。
心がけていること
クックパッドは非常に優秀なエンジニアが居るので日々開発されている開発基盤や整備されているインフラ環境は素晴らしいです。 ただ、どんなに素晴らしい物でも価値を提供、発揮出来なければ絵に描いた餅になってしまいます。 そこで重要なのがラストワンマイルだと個人的には考えています。
ラストワンマイルとは
FTTH（Fiber To The Home） とかで使われた言葉で今回の話を表現するのにマッチした言葉だと思っています。 一つの部署（または対象のサービス）であれば知っている人が集中してフォローすればいいですが、課題でも書いた通り日々進化、変化していくので継続的な活動が必要になります。 そして部署が増える度にラストワンマイルを埋める為に必要なコストは増えていきます。 しかし、開発基盤やインフラ環境の価値を正しく余すこと無く開発者（サービス）に伝えるにはこのラストワンマイルを無視することは出来ません。 自分としては以前は開発基盤やインフラの仕事もしていたこともあり、今回の「ラストワンマイルを埋める活動でも貢献出来るのでは」と日々取り組んでいたりします。*2
開発基盤、インフラとして目指している方向性の理解
ラストワンマイルを埋める活動として、単純に日々開発、整備されているツールや環境を把握するだけなく、会社としての技術の方針や技術部やインフラ部の目標、個人の目標を把握することが重要だと考えています。 それは大きな流れとしてどういう方向に進んでいるかを把握していないと、今後廃止されるツールや環境を選んでしまうことがあるからです。 他にも一つひとつの技術やツールだけを見ていると、どういう意図や目的でそれを採用されたのか、使い方としてどういうものが想定されているのかを理解できなくなるからです。
そして我々は組織で働いています。 サービス開発エンジニアだけでなく、開発基盤、インフラメンバも成果を上げて行くことが勿論期待されています。 ある側面では直接的な価値を提供していない縁の下の力持ちの人たちが、どういう方向性で自分のキャリアパスを描こうとしているのか、またどういうことが成果として認められるのかを把握しておくことで、彼らのパフォーマンスをより引き出したり、どういう作業をお願いすると彼らの成果に繋がることが想像できるようになります。そうなることでお互い Win/Win になる方法を考えることが出来るようになると思います。
適切なフィードバックをする
これは自分の経験からなのですが、開発基盤に関して言うと自分達が開発したツールや環境の直接的な利用者で無いことがあります。 そういう状況では、改善点や問題点を把握する為には、利用者からの積極的なフィードバックが非常に重要だと感じています。 *3 例えば、「せっかく作ったツールがサービス開発エンジニアに使われない」という状況の時に、それは使いづらいからなのか？そういうニーズが無いのか？ということを把握出来ないと、どうして良いかが想像の域を出ないからです。 エラーが出ていても「たまにだから良いか」とならず、きちんとフィードバックをすることで改善活動の指針になったり、放っておくと大問題になりかねない事を未然に防げたりもします。 このフィードバックも目指している方向性の理解している上でしないと、「そういう使い方は想定（または推奨）していない」「それは今後こちらの置き換わる予定」ということにもなりかねません。 こういうコミュニケーションが発生する事自体は問題ないのですが、お互いを理解しようとする意識は持っておく方が個人的には良いと思います。
余談ですが、そういう仕組等を理解していると Hako で動いているアプリケーションなら pull request 毎に環境を作って動かせるのではと思い、提案して開発して貰いました。
部としての方針を理解した上で、必要な技術を活用する
ここで言う「部」とは私が属している部のことです。 今期は目標として新しいサービスをスピード感を持って開発して行くことが多くなる部署だったりします。 出来る限りチームメンバにはサービス開発にフォーカスして欲しいと考えたので、整備してくれている最新の環境を利用して開発していくのが最適と判断しました。 そして徐々にサービス開発エンジニアに裁量が与えられる領域が増えていく部分に関しては、積極的に権限移譲を受けられるように活動しています。 依頼ベースでは作業者が不慣れな事による作業ミスのリスクは減らせますが、今期に必要としているスピード感が落ちると考えているからです。
個人としてもなるべく早く、信頼して裁量を任せてもらえるように自らの作業範囲を決めること無く、働く様に心がけています。
使うだけでなく自分でも改善出来るようにコードの理解
運用に乗せたりした後に、改善したいポイントやエラーの原因を把握したくなることがあります。 その時に必要になって調べていては、すぐに修正、対応が必要になった場合に対処が出来なくなってしまいます。 *4 なので個人的にはツールを使う場合に出来る限りコードを読むようにしています。 それはどういう仕組で動いているのかを把握する事と、その特徴を掴む意味でもあります。 また、用意されている拡張ポイント等も知ることが出来るので、自分たち用のカスタマイズする時にも役立ちます。
インフラ環境についても Groupad という社内ツール（blog + wiki）に情報があったりするのでその辺を読んだり、実際の環境や Infrastructure as code で管理されているリポジトリを見たりしています。
実際やってきたこと
サービスレベルや可用性を上げる為や、日々改善されている環境のメリットを享受する為に社内に古くから存在するアプリケーションを Hako アプリケーションとして動くように改修しました。 また、 Codenize.tools を使うにあたって、仕組みや実装を把握する為に私個人でも拙作ですが Applb というのを開発しました。 まだ作ったばかりで荒削りですが、AWS の ELB v2 を Codenize するツールです。 秘匿値の扱いについても権限移譲を受ける為に現在の部で開発しているアプリケーションをまとめて変更しました。
自分たちである程度サービスを運用出来るようになるためには、ログの見方や監視方法の確立、割れ窓を放置しない、自分たちのアプリケーションが利用しているリソース状況の把握等の活動を自ら率先して行っています。
また、自分がラストワンマイルを埋める時に得た知識や考えは、部内で行っている定期勉強会で発表して伝えるようにしています。チームビルディングに関しても色々思うところはあるのですが、また機会があれば書きたいと思います。
最後に
例えるならサービス開発エンジニアは料理人で開発基盤は調理道具を作る人、インフラは水道やガス等を安定供給する人だと思います。 サービス開発エンジニアであれば、求められているまたは目指している料理（＝価値）を届ける為に調理道具やインフラの特性を理解し、ケースバイケースで必要とされている最短、最善または最高な開発が出来るエンジニアになりたいものですね。
