初日はエウレカCTOの @kaneshin が担当します。
普段はPairsの事業戦略に基いて事業成長の阻害要因にならないように技術をどのように活用していくことや技術的負債をどのように返済していくのかの技術戦略と、Pairsに溢れるマッチングデータをどのように蓄積して活用していくのかといったデータ戦略をチームの責任者と議論しながら策定しています。他にも、Go言語のイベントやゴリゴリと開発をすることもあります。
エウレカで運営、開発をしているPairsは日本・台湾・韓国に展開しており、3カ国累計会員数も800万人を超えています。日本、アジアのデーティング市場はまだまだ拡大中なため、事業上の戦略を達成すべく、全社員が連携してデーティング市場を成長させています。
Pairs事業が急成長するにつれて、それを支えているコーポレート部門も守りの面でやらなければならないことが増えておりプロセスの整備や改善が急務になっています。また、Match Groupの資産を活用したコーポレート部門のプロセス強化も並行して進行しています。
さて、本日のこの記事では、Pairs事業の成長を支えているエウレカの事業部門とコーポレート部門のプロセス基盤とプロセスオートメーションについてお話します。
事業と組織の成長を阻害しないプロセス基盤
事業部門やコーポレート部門のプロセス改善について、今までも技術面から支援していましたが組織として「守るべきところをしっかりと守る」ことをしなければ、事業成長を阻害する要因となってしまいます。
この「守る」というアクションは「攻め」以上に難しいもので、「どのタイミングで守るべきなのか、むしろ、今は攻めるべきでなのか」といった具合に、攻守の選択は常に頭の中で考えておく必要があります。
エウレカは2018年の前期まで様々なことを「攻め」としていろいろなことを検証し、非常に良い効果も出ていました。しかし、手広く検証をした結果、使っていないサービスや細かくサービスを使いすぎることによる断片化が多く発生し、それに伴い煩雑化するプロセスが徐々に目立ちつつありました。これらを包括的に解消するため、10月からプロセス基盤としてオートメーションのインフラ構築から開発とプロセス整備を行っています。
組織戦略と管理のトレードオフ
まず、何が問題なのか。ここはエウレカが持つ “Keep Small” というポリシーから落とし込んだ戦略を持っています。
“Keep Small” のポリシーの上で “KISS = Keep It Short and Simple” を達成するには会社として管理するものを正しく管理しなければなりません。しかし、しっかりとした管理体制を取ってしまうと事業成長の阻害要因になる可能性があります。このようなトレードオフは必ず発生してしまいますが、阻害要因を最小限に抑えるのが非常に大事なことになります。
管理とは「マネジメント」と「コントロール」
管理には、正常にマネジメントされた管理状態にするための “Doing the right things” と、それと併せてコントロールされた管理状態にするための “Doing the things right” の二つの側面があります。
マネジメント: Doing the right things
- 物事を正しい状態にする
- 定義、ルール
コントロール: Doing the things right
- 物事を正しく実行する
- 制御、統制
管理となると、この二つが事業や組織の成長に対してメインのトレードオフとして発生します。これらを意識しないで済むよう技術でプロセスの自動化を図っています。
プロセスの統括的連携の基盤
トレードオフを意識しないようプロセスを技術で隠蔽することによって、Confidentiality（機密性）, Integrity（完全性）, Availability（可用性）といった情報セキュリティとしても大事なCIAを満たせていければと思い、エウレカではプロセス自動化のインフラを下記のように構築しています。
完全に構築が完了しているわけではありませんが、インフラ管理面ではTerraformで再現性を持ちつつ、利用者となるエウレカのメンバーは一元集約された場所に情報を入力するだけで利用できるサービスの招待を実現することと社内ツールを提供する基盤を実現しようとしています。利用者も開発者も両方ともプロセスを意識しないで済む環境を提供するために、例となる問題を少し挙げてお話します。
Case1 - 責務の大きい１つのアプリケーション問題
— 「ひとつのことをうまくやれ」
私の登壇を聞いている人はよく聞いているフレーズになると思いますが、UNIX哲学を踏まえた設計はシンプルにな構造であり、また、協働的なプログラムになります。
このようなプロセス基盤となる社内ツールを提供するときは、外部サービスが増えることと削減することを踏まえて、記録されたDBからアップデートするストリームに乗せるためのインジェストのみを提供するアプリケーションを前段に置くことで可用性が高まります。謂わば、プロセス整理の入力I/Fを担うアプリケーションです。入力も出力も同じようなアプリケーションにしてしまうと開発コストが高くなってしまうため、それを予防します。
Case2 - エンジニアのデプロイ環境問題
社内利用のGCPやAWSを触る機会が少ないエンジニアにとって、自分で開発した社内向けツールのアプリケーションやBotをどこにデプロイして稼働させるかが問題になると思います。エウレカではSREチームに依頼すれば構築しますが、規模の大きい会社だと依頼をしてから構築してもらうまでに時間を要することもあるかもしれません。そうなると、「依頼をするくらいなら自分のマシン上で動かしてしまうか」となってしまい、可用性が低いアプリケーションとなってしまう可能性があります。
エウレカでは依頼をするのが手っ取り早い状態なので、それを解消するためにDockerfileが用意されたリポジトリかコンテナを GitHub → Cloud Source Repositories → Cloud Build → Container Registry → Deploy のパイプラインを整えています。これによって、自分が開発したアプリケーションやBotをデプロイできる共通基盤を提供します。
Cloud Buildはcloud-buildersを用いれば下記のように簡単に利用できます。
Case3 - サービスのアカウントID管理問題
企業に属しているエンジニアでも、GitHubやQiitaなどでは個人アカウントを使っている人は多くいると思います。会社として、会社のメールアドレスから発行したアカウントを使ってもらうのを強制すれば管理は楽になりますが、エンジニアの個人ブランディングも重要なこのご時世にアカウントを別々で持たせる意義は少ないですし、アカウントを二つ以上持つことが情報セキュリティのCIAを保つのが難しいこともあります。
これらを解消するために、例えばGitHubのエウレカチームに招待してもらうために開発しているのが、台帳システムへアカウントIDを入力してもらうフィールドを用意し、そこに入力されたことをトリガーとして処理を走らせるようにします。このように、全て台帳に紐付かせてサービス利用までサポートすれば確実に管理もできますし、尚且、利用者側はサービスに招待してもらうことを問い合わせることもなくなります。
また、これで一番うれしいのは、多種多様なアカウントIDを覚える手間がなくなることです。例えば、エウレカには Kentaro Takahashi というAPIチームの責任者がいるのですが、アカウント名が @takochuu なため、本人と結びつきにくい問題があります。
Case4 - SSO未対応とアクセスコントロール問題
エウレカではID管理としてG Suiteアカウントを用いたSSOを是としていますが、SAMLやOAuthに対応していないサービスに対して制約があるため、そのようなサービスでは各自でパスワードを設定しています。また、様々なアクセスコントロールもしているためその管理コストも多く発生しています。
それらを解決するためにMatch GroupがIDaaSのOktaを導入しているため、SSOもOktaの管理画面から各自で対応可能であることと対応のアクセスコントロールの管理コストを下げ、そしてアカウントのロックアウトもG Suiteとの連携も含めて、今以上に広く容易に可能になるため、エウレカでもその資産活用をすすめています。
Oktaで一番実現したいこととしては、各種サーバーへのログインアクセスコントロールによる管理コスト軽減が見込めるので、随時そちらも対応ができればと思っています。
組織課題を技術で解決し、事業にフォーカス
おわりになりますが、2018年にエウレカがPairsの事業成長を支えるために攻めてきたことを2019年に向けて守ることをお伝えしました。これは、ただ単に守るのではなく「攻めの守り」として、より一層、事業成長を阻害しない組織体制としていくことと、常にオペレーションに忙殺されないように事業も組織も成長基盤を築いていくのは中長期の目線で重要なことです。これをなおざりにすることは事業と組織の衰退に繋がると言っても過言ではありません。
組織課題としてWhyを熟考する
プロセス基盤を整えている上で一番重要なことは「なぜやるのか」をエウレカという会社に一番フィットした形で提供する意図の明確化が非常に重要です。例えばGoogle社の成功事例を持ってきたとしても、それはGoogleという会社のサイズだからこそ成功した事例です。成功や失敗を参考にしつつも、それを是とせずに自分たちの会社にフィットさせるために「なぜやるのか」を中長期目線で立案します。
— “ Start With Why” by Simon Sinek
おわりに
2019年に気持ちよくスタートダッシュ出来るよう、残りの営業日でとにかく改善出来る点と来年に活かせるように技術で支えていくことと、エンジニアの多いTech Companyとしては組織・経営課題となり得るものは技術で継続的に解決していきます。
結果として、エウレカに関わる全ての方が何不自由なく気持ちよく仕事のできる環境が用意できればエンジニア冥利に尽きるものです。
