Pairsを支え続ける開発組織『BI / SRE / QA / CTO Office』チームの技術横断の考え方・動き方
この記事は、eureka Engineer Advent Calendar 2017 25日目の記事です。
24日目はCEO石橋の「エンジニアのキャリア設計で重要な3つのポイント」でした。
はじめに
こんにちは、CTOのkaneshinです。CTOに就任してから、早いもので一年が経過しました。CTOとして、マッチングサービスのPairsが保有している大量のデータをどのように活かしていくかを常に考えていますが、この大量のデータは存在しているだけでは全く使い物になりません。
大量のデータより前に、データで『何がしたいのか』という目的を明確にし、それに対して適切なアプローチのできる開発組織でなければ目的を達成することができません。これらは長期的に、開発組織として、事業戦略からエンジニアリングへ落とし込み、適切なタイミングでアップデートすることが重要になります。
ただ、これらを技術的に実行するチームは恒常的に必要であり、それらのチームは技術的に事業部の各チームと連携することと、活用するための基盤整備を推進しなければ、適切なアプローチ以前の問題として『大量のデータを保有しているが、何も成し得ることができない』状態になってしまいます。
さて、この記事では、上記のような課題にも対応のできる、エウレカの技術的に横断しなければならないチームが、どのような開発組織戦略のもとに構成されているかをお話しします。
※ 『開発組織 ≠ 企業組織』です。
技術横断チームの体制
概略図
コーポレートや事業部には様々なチームが存在しており、それぞれのミッションのもとチームとして行動をしています。技術横断チームはそれらを支え続ける位置として、チームが構成されています。
事業部の下層にある BI / SRE / QA チーム
BIチーム：分析チーム
BIとは、Business Intelligenceの略で、事業部の各チームの施策に対して分析をサポートするのはもちろん、事業に対する課題を自らが見つけ出し、それを全体の事業戦略に組み込んでいくことがミッションとして定義もされています。
重要なのは、事業部の各チームはそれぞれの施策を自分たちのチーム内で分析をすることができるのがエウレカの強みになります。最初の分析のサポートはもちろん行いますが、現場で意思決定を行なうのが一番最速です。この意思決定に対して、明確な決定ができないデータであるなら、そのデータ基盤を整備しなければならないし、分析手法が確立されていないような施策ならばBIのアナリストが積極的に話し合いを行います。
これらを達成するために、エウレカのBIに必要なスキルとして:
- ビジネス：事業が持つビジネスモデルとセンターピンとその仕組みを理解し、要所を適切に判断できる
- 分析：定性・定量・ドメインナレッジを駆使して課題に対する仮説と分析手法、次の打ち手を適切に提案することができる
- 技術：分析要件に合わせて、適切にデータを抽出・活用することができる
を定義し、それらの領域をどれだけ専門性を持っているかによって、エウレカが定義するBIとしてのキャリアが変わってきます。
この画像は、BIチームの責任者である鉄本が丸の内アナリティクスで登壇したときに、これらの話をさせて頂きました。
BIチームは、他にもコーポレート側のファイナンスとも連携をしています。
SREチーム：インフラとかとかチーム（様々）
SREチームはエウレカ全体のインフラに対して責務を持っています。具体的な動き方はSREチーム責任者の恩田が「SREチームのミッションを体現するシステム設計思想」の記事を書いているので、ぜひ読んでみてください。
様々な企業が、事業部横断プロジェクトをどのように捌くかが難しいと思いますが、横断プロジェクトは技術的に広範囲のことをやることがあるため、エウレカではSREチームが横断プロジェクトに対して責務を持つ場面が多々あります。
SREチームはインフラ関連（それこそ、Site Reliability Engineering）を責務としてもつことが多いですが、事業のために、広範囲に動くSREチームの敏捷性は非常に高いです。
QAチーム：品質保証チーム
QAとは、Quality Assurance（品質保証）の略です。私は、元々前職で品質保証を担当していたこともあって、品質保証には熱い想いを持っています。
『QA』というと、『マニュアルテストを行なうこと』と思われがちですが、全く違います。QAとは、Quality Assuranceとして、品質を保証することや、品質の確約をしてくれる部隊であると定義されています。
ただし、品質を必ずしも”確約”するわけではないのも事実です:
Quality assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers; which ISO 9000 defines as “part of quality management focused on providing confidence that quality requirements will be fulfilled”.[1] This defect prevention in quality assurance differs subtly from defect detection and rejection in quality control, and has been referred to as a shift left as it focuses on quality earlier in the process.
ISO9000/9001にある品質マネジメントとして、品質を確約するよいうよりか、どちらかというと、欠陥を見つけ出してリリースをさせない部隊である。これはつまり、リリースをOKを認定する必要十分条件を満たしていないことにつながっています。
品質保証は会社のフェーズによってかなり役割が変わってきますが、エウレカではこれらを責務として持っています。
最下層に存在する CTO Office チーム
CTO Officeは最下層に位置しており、BI / SRE / QAよりも下層に位置するような構成で考えています。エウレカのCTO Officeの持つ責務はかなり広い領域を担っており:
- 情報システム (MIS)
- コーポレートセキュリティ
- エンジニア採用・技術広報
また、エウレカの全チームに対して、バックアップすることも責務としてもっており、例えば、バックオフィスと連携して複雑なプロセスを効率化しています。
また、エウレカでは自己組織化したチームを目指しており、それのために開発チームの開発支援としてCTO Officeから支援に入ることもあります。
エウレカ版 強いチーム作りで実践した学びについて from Narichika Kajihara
CTO Officeの責任者の梶原が何度かイベントに登壇しており、エウレカの自己組織化へ向けた動きを話しているので、ぜひご覧ください。
技術横断チームとして、持っておくべき考え方・動き方
さて、今まではエウレカの各チームの責務の話しでしたが、これらのチームが『事業部と連携して動く』ために考えとして持っておくべきポイントです。
Pairsの全体に対して効果を出し続けるアウトプットをする
例えば、CEO石橋が『明日からUSにPairs進出するから！』と言ってきても慌てずにナレッジの水平展開が可能なアウトプットを常に出し続けていなければなりません。国が違うから制約が発生するような設計にはせず、常に汎用的な目線での設計や基盤の整備が必要ですし、事業戦略も全てを理解した上で長期目線での構築を常々続けるべきです。
ただし、『走りながら考える』ことも非常に重要です。これはエウレカの行動規範にもあるのですが、言わば、巧遅は拙速に如かずとして、大規模な基盤構成を考えて、半年掛けた大プロジェクトをやるよりか、2週間ほどでとにかく結果を出せるならそちらをチョイスするのが事業としては非常に重要であることもあります。
このように、結果が見え辛いものもあるため、バランスのよい取捨選択と、常にレバレッジが効く箇所にコミットをするのを優先します。
チームは誰でも横断可能なメンバーが配属されているべきである
横断チーム内で特定のチームに専属となる人は作らない。なぜならば、タスクやナレッジの属人化を防ぐために、チームがもつタスクは横断チームとして全て管理し、透明性を持ったタスク運用が必要にすべきです。そして、トラックナンバー1（トラックに轢かれても大丈夫な人数）を作らない。そのためにはペアワークをすることなども手段として使うべきであると考えています。
透明性の保持
そして、横断チームに取り巻く課題として、とにかく事業部やコーポレート側から依頼されるタスクが非常に多いです。これらは中期的に解決しなければならない課題となりますが、まずはナレッジの集積などが重要です。
また、データ基盤などが分析基盤として稼働できていなければ、長期的に人的工数を使い続けることになるのは、結局、BIなどの横断チームになるため、これらを防がなければいけません。
そのためには、事業部側のチームに対して横断チームが持つリリースプランニングを四半期に限らず、半期分は透明性の上、明示し、横断チームがどのようなミッションを持って、チームのタスクを実行しているのかを開示する必要があります。
これらは、横断チームに文脈ではないですが、エウレカの組織という点から実施していることです。事業部側のあるチームのスクラムマスターを担う川端が「エウレカという組織で、スクラムがチームに起こした変化」を書いているので、ぜひ。
やらない理由を明確にする
やる理由は決まることが多いが、やらない理由は決まっていないことがあります。このようなことも常に決めておくことによって、とにかく意思決定を迅速にすることができますし、不必要なレポーティングもなくなります。
横断チームはとかく様々なタスクを持っているため、このようなことも明確しておくことが非常に効率化へと繋がります。
おわりに
2017年、エウレカが辿ってきた開発組織としての横断チームの定義や動き方をまとめてみました。横断チームはただ単に定義しただけでは、タスクに飲み込まれて忙殺される可能性があります。
そうなってしまうと、本来求めていた結果を出せずに疲弊してしまうため、事業戦略に基づいたミッションのもと、各チームが構成されていきます。
2018年では、より事業と技術を密接に絡ませていくことと、エウレカが保持している大量のアセットを活用するのが鍵となると考えているため、より一層、事業戦略が120%、200%くらい達成できるような開発組織を思い描いて創り上げていければと思います。
2017年のAdvent Calendarは終わりですが、開発組織のことや技術的なことを一度お聞きしてみたい方は金子にコンタクト頂ければ時間を見つけてお話できますのでぜひ！
