こんにちは。研究開発部でエンジニアをしている新卒入社1年目の西原です。
11/5 (金) に弊社主催で開催した「Sansan Builders Stage 2021」のセッションの中から研究開発部のメンバーが発表した次の2件をご紹介します。
- 研究開発組織のマネジメント
- R&DにおけるTerraformとAnsibleを活用したInfrastructure as Codeへの取り組み
研究開発組織のマネジメント
研究開発部部長の西場は『研究開発組織のマネジメント』というタイトルで発表しました。
彼は前職でPdMや事業責任者をする中で様々な専門家と一つの目標を目指し実現していくことに魅力を感じ、マネージャーに専念することを決めたそうです。 現在部長を務めている研究開発部も様々な専門家から構成されています。この組織が目指す成果とそれをどのように大きくするのかという発表内容になっています。
研究開発部の成果
研究開発部の成果は次の2軸からなる4象限で表現することができます。
- 「短期」と「長期」
- 「プロダクトの成長」と「技術力の向上」
プロジェクトがこの4象限のどこに配置され、どの成果に結びつくのかを意識することが重要です。 一般に短期的なプロダクトの成長は緊急性が高いため注目されやすく、長期的な技術力の向上は後回しになることが比較的多いです。 しかし、研究開発部という組織の特性上、長期的な技術力の向上にも意識を向けなければなりません。 私たちは長期的な技術力を向上させるために次の3つのことを実現しようとしています。
- ボトムアップであること
- 大きなチャレンジをし続けること
- 10年で100倍規模になること
ボトムアップ
研究開発の業務に置いてメンバーの専門性やスキルを発揮しやすく、自ら考え行動しやすくなるようにボトムアップな組織を目指しています。 一方で、「意思決定が遅くなる」「メンバーの能力に依存する」「大きな施策がしづらい」などのデメリットもあります。 このようなデメリットを解消するために以下の施策を実施しています。
- フラットな組織
- サイロ化を防ぎ、各方面への透明性をあげる
- スモールチーム
- 権限委譲ができるサイズまでチームを小さくする
- メンバーを育成しやすくする
- OKRの適切な運用
- 重要な意思決定において双方が同意できる状態にする
- 部として大きな目標を掲げ、各スモールチームが協力してアラインする
大きなチャレンジを続ける
OKRは大きなチャレンジをするためにも活用しています。 OKRを「コミットするOKR」と「野心的なOKR」の2つに分けて運用しています。 具体的に短期的なプロダクトの成長などはコミットするOKR、長期的な技術力の向上などは野心的なOKRとして扱っています。 研究開発部として技術力で競争優位性を得るには長期的な観点で技術に投資する必要があり、他社のサービスよりも精度が良いものを作るために野心的なOKRを明示的に定めています。
10年で100倍規模
10年で100倍規模の組織を目指しています。5年で10倍になることをマイルストーンとして設定しており、これを2回達成することで10年で100倍を達成しようと考えています。 設定したマイルストーンをもう少し具体的にすると、5年間で人数を3倍にして生産性も3倍にすることで10倍の組織規模を達成できそうです。
リーダーの育成
組織の人数を3倍にするにはリーダーの人数も3倍必要になります。 人数を増やすには採用と育成の2パターンがありますがここでは育成の取り組みについて紹介します。 育成の基本方針は次の3つです。
- 環境を整える
- 機会を提供する
- コーチング
リーダーは経験を経てできるようになるものだと考えており、その経験ができる環境作りをしています。 特にリーダーの強みを活かすような経験を増やすということを意識しています。 リーダーシップにはさまざまなカタチがあり、テックリードやピープルマネジメント、プロジェクトマネジメントなどそれぞれで求められることが違います。 チームが大きくなるほどリーダーに求められことが多くなり負担も大きくなります。チームを小さくすることでリーダーの負担を減らし、強みを発揮しやすくなります。 また、チームの数が増えるためリーダーとして経験を積めるチャンスを増やすことができるようになります。
生産性を上げる
生産性を上げる目的は最終的な生産量を増やすためです。 生産性を上げるために意識していることは次の2つです。
- ビジネスやプロダクトにとって重要度の高いものから取り組む
- 試行錯誤の回数を増やす
研究開発やデータサイエンス、データ活用ではPDCAサイクルのようにやった結果に対して次の改善点を探すということを継続して行い、試行錯誤を繰り返していきます。 この試行錯誤を効率よくするためにMLOpsやトイルの削減を行い、本質的な業務に集中できるようにします。
コーチング
最後にメンバー育成の一環として取り組んでいるコーチングについて紹介します。 1on1を通して以下のことをやっています。
- 100点満点で満足度を確認
- 前回からの差分を聞きながら言語化を促す
- どのような状態になれば+10点になるか聞く
- 現状と+10点の状態のギャップを埋めるためのアクションプランを複数出してもらう
- アクションプランの中で効果の高いものに対して取り組み時期と達成基準を決める
- 取り組みに対して西場がサポートすることを決める
ここで大事にしているのは言語化です。現状や未来の状態を言語化するのは難しいことですが、 言語化した裏にモチベーションの源泉があったりします。
以上、『研究開発組織のマネジメント』の紹介でした。 私も研究開発部でエンジニアをしていますが、これらの施策の効果を感じています。 スモールチームになったことでチーム内の動向を把握しやすくなり、連携が取りやすくなりました。 シニアなメンバーと密に連携することができるようになり技術的に成長を感じています。
R&DにおけるTerraformとAnsibleを活用したInfrastructure as Codeへの取り組み
研究開発部エンジニアの大澤は『 R&DにおけるTerraformとAnsibleを活用したInfrastructure as Codeへの取り組み』というタイトルで発表をしました。
研究開発部のエンジニアは研究開発部の成果をサービスとして提供するために開発業務を行います。 インフラが絡んだ開発は専門のインフラグループを介すため、その仲介として相談・依頼をしています。 研究開発部としてはある程度自由にインフラを触れることを望んでいましたが、IAM権限を過剰に付与することでセキュリティ上の事故が起こる懸念がありました。 そのため、都度インフラグループに相談・依頼をしていましたが、日に日に研究開発のサービスが増えるのでリードタイムも増加していきました。 大澤の発表ではこのような状況をどのように改善したのか、その取り組みについて紹介しています。
開発業務の課題
先にも書きましたが、研究開発部には「リードタイムの発生」や「都度依頼しなければいけない」といった課題がありました。 対して、インフラグループには「IAM権限拡大への懸念」があり、加えて「EC2インスタンスの手動プロビジョニング」といった問題がありました。
インフラグループは元々Chefというツールを使ってAmazon LinuxのEC2インスタンス作成とプロビジョニングをしていました。 これが秘伝のタレ化しており、研究開発部向けのUbuntu ServerとWindows Serverに対応するのが困難な状況でした。また、Chefを実行するには 対象インスタンスにRubyとGemをインストールする必要がありますが、アプリケーションに不要なパッケージを入れることになります。
ここまでの課題をまとめると以下のようになります。
- 研究開発部とインフラグループの課題
- AWSの権限委譲
- [R&D] AWSリソースをある程度自由に作成したい
- [infra] 任せたいが権限を過剰に渡したくない
- [R&D, infra] コード化できていない
- EC2インスタンスのプロビジョニングを楽にしたい
- [R&D] 自分たちで作成できるようにしたい
- [infra] 自動化したい
- AWSの権限委譲
これらの課題を改善するためにTerraform + IAM Permission BoundaryとAnsibleを導入しました。
Terraform
AWSの権限委譲の問題を解消するためにTerraformを利用しています。 TerraformはHashiCorp社が開発しているオープンソースのIaCツールです。HCLという独自言語で記述され、宣言型の特徴を持っています。 AWS/GCP/Azureなどの各クラウドベンダーがプロバイダという形で対応しています。
チームにTerraformを導入する際には、Terraformを触った経験があるメンバーからキャッチアップすることからはじめました。 最初は依頼することの多かったIAMロールの作成からTerraformで記述するようにしました。 経験のあるメンバーがIAMロールの雛形をTerraform化してくれたので、それを元に作成していきました。 Terraformの記述に慣れてきたら他のAWSリソースもTerraform化していきました。今では基本的にTerraformでリソースを作成しています。
IAMロール/ポリシー作成の権限委譲
IAMロール/ポリシー作成の権限委譲はIAM Permissions Boundaryを利用して行っています。 これはアクセス権限の境界を設定できる機能です。 IAMユーザに対してIAMロール作成権限が付与されても、境界を超えた権限はIAMロールに付与できないようになっています。
Terraformのディレクトリ構成
一つのGitHubリポジトリにサービス単位でモジュール化しています。
各サービスのディレクトリ配下にdev, stg, prod, modulesのディレクトリがあり、各環境ディレクトリ配下にmain.tf、modules配下に各AWSリソースを定義しています。
この構成のメリットは以下のようになっています。
- 各環境でリソースを共通化しつつ、特定の環境のみ設定を変更できる
- 例 本番のみIPアドレス制限をする、監査ログを設定する
- 影響範囲を小さく、素早く変更できる
- モジュールをサービス間で共有しない
- 共通化の罠にハマりにくい
- サービス毎に微妙に異なる設定にしたい場合に条件分岐をしなくて済む
導入してよかったこと
Terraformを導入してよかったことは次の通りです。
- AWSリソースを作成できることでリードタイムの短縮、インフラGの運用負担軽減
- 必要に応じてインフラGをレビュワーに入れることで設定ミスによる事故防止
- AWS環境への変更履歴や意図を後から追跡できる
- 1つのリポジトリに集約できる
- 他のチームが使うサービスや設定が知ることができる
- R&Dが提供しているほとんどのサービスを一覧できる
困ったこと
導入して良かったことばかりでなく、困ったこともありました。 Terraformはアップデートが早いサービスだと思いますが、 AWSプロバイダが最新アップデートに追いついてないことがあったり、バグ修正のプルリクエストがマージされないことがありました。
Ansible
プロビジョニングの問題はAnsibleを利用して解消しました。 AnsibleはRed Hat社が開発しているオープンソースの構成管理ツールです。 エージェントレスの特徴を持っており、SSH、WinRM接続を介して作業を実行します。 また、AWS Systems Manager セッションマネージャでSSHポートが閉じていても実行できます。 各設定はYAML形式で記述します。
Ansibleを使ったプロビジョニング
Ansibleを使ってUbuntu ServerとDeep Learning AMIのインスタンス作成、プロビジョニングを行えるようにしました。
ansible-playbookコマンドを使う際にデフォルトパラメータはグループ変数を用いており、必要に応じてEC2インスタンスタイプやEBSボリュームサイズなどを上書きしています。
サブネットを複数指定する場合は特定のAZに偏らないようにランダムにサブネットを決定しています。
動的インベントリへの対応
Ansibleはインベントリというファイルで実行ホストの接続情報などを管理しています。 デフォルトは静的インベントリというホスト情報をYAMLファイルに直接記述する形で管理しています。 AWSのようなクラウド環境だと常に状況が変化しているため静的インベントリでは管理できません。 そこで動的インベントリを使って管理しています。 動的インベントリはEC2APIやメタデータなどでEC2インスタンスの情報を取得してホストを動的に管理します。
ディレクトリ構成
ディレクトリは大きく「inventory」「playbook」「roles」の3つに分けています。 inventoryディレクトリにはAWS/GCP各環境のグループ変数ファイルとインベントリファイルを格納しています。 playbookディレクトリにはPlaybookと呼ばれる実行サーバに対する作業内容を定義したファイルが格納されています。 実際の作業はPlaybookではなくrolesディレクトリ配下にrole単位で分割しています。こうすることでPlaybookで再利用できるようになっています。
TerraformとAnsibleの使い分け
TerraformとAnsibleをどのように使い分けて構成管理をするか悩むこともあると思います。 それぞれの特徴を把握することが使い分けるヒントになりそうです。 それぞれの特徴は次のようになります。
- Terraform
- IaCツール
- 宣言型
- 記述する順序が実行に影響しない
- 冪等性
- ステートフル
- tfstateファイルで状態管理
- コード上の設定を削除する場合は、Applyした際にtfstateと現状のリソースの差分を見てリソースが削除される
- AWSプロバイダは数日おきにリリースされる
- Ansible
- 構成管理ツール
- 宣言型 + 手続き型
- Ansilbeモジュール単体は宣言型・冪等性が多い
- 上から順に実行されていく *ステートレス
- コード上で設定を削除、実行してもリソースは残る
- リソースを削除する処理を書く必要がある
- AWSモジュールの開発が遅く、サポートされていないサービスが多い
これらの特徴からTerraformはクラウドのインフラのコード化、Ansibleはサーバのセットアップ、サーバ内の処理に向いているように思えます。
以上、『R&DにおけるTerraformとAnsibleを活用したInfrastructure as Codeへの取り組み』についての紹介でした。 私も業務でインフラに触れる機会がありますが、構成がコード化されていると色々と楽に感じます。 サービスがどのようなリソースを使っているか把握しやすくなり、何かあれば変更ログを追えるようになっています。 似たような構成のサービスを構築する際には参考にしたり使いまわしたりできるので効率良く開発することができます。
まとめ
本記事では、Sansan Builders Stage 2021 で発表されたセッションの中から、研究開発部2名のセッションをピックアップしてご紹介しました。 『研究開発組織のマネジメント』編の取り組みで紹介したように研究開発部はさらに大きくなろうとしています。 組織の成果を大きくするために研究員・エンジニアともに本質的な業務に集中できるようMLOpsやIaCの取り組みをやっており、その一部を紹介させていただきました。
Sansan Builders Stage 2021では今回紹介したセッションの他にも、魅力的な発表が多数ありました。そちらのレポートも本ブログで公開されているので、ぜひご覧ください！
