2020-03-09 業界を変えた大規模サービスの技術選定 ＃techplay0309
2020/03/09 に開催された 業界を変えた大規模サービスの技術選定 のイベントレポートです。
●イベント概要
「技術選定」の本質はどこにあるのでしょう。
流行っている技術？数年後も廃れる可能性が少ない技術？今の組織にあった手法？コストパフォーマンス？
それぞれの目的に応じた、その時最適だと思う技術選定をし続けながら、エンジニアの開発運用は続きます。
世の中に大きなインパクトを与えたサービスの技術選定はどんな意思決定を繰り返しているのか。
今回はそんな、私たちの生活に影響を与えた大規模サービスで技術選定をしている方たちお呼びして登壇形式でイベントを開催します。
技術選定は、ビジネスと組織の未来を考えることでもあります。一緒に未来を考えませんか？
■株式会社マネーフォワード 中出 匠哉さん
●Money Forward
・691名
開発に関わるのは 40%程度
・vision
お金を前へ。
人生をもっと前へ。
・4ドメインで事業展開
Money Forward Business
Money Forward Home
Money Forward X
Money Forward Finance
・統合されたバックオフィス
マネーフォワードcloud
STREAMED
Manageboard
・マネーフォワード ME
キャッシュレスのブームで利用者数が増えている
キャッシュレスで決済すれば自動で家計簿データが蓄積
年間 ¥24,450 の節約を体感
・毎年のように新しいサービスをリリース
●技術選定の前提
・20+のプロダクト
様々なステージのサービス
・各プロダクトにPO、PdM、エンジニア、デザイナが存在
・インフラは横串
・すべてプロダクトチームが決定
アーキテクチャ、利用技術、開発プロセス
●技術選定の特徴
・Railsが中心
ゼロから立ち上げる場合、railsが強い
卜部さん松田さんがいる安心感
・バックエンド
rails, java, golang
・インフラ
AWS, GCP、さくらなど
●マネーフォワードMEの道のり
・ユーザのデータボリュームが大きい
入出金履歴
資産履歴の推移
利用していない時間でもデータが増える
・ユーザをまたいで利用できるユーザはほとんどない
キャッシュが効きにくい
・ARPUが安い
フリーミアム
月額 ¥500
ストック型モデル
データ保存コストが重要
・ピークはわかりやすい
昼休み
給料日
・当初の技術選定
メンバーの知見の多いJavaで始めた
インターンのアドバイスでrailsへ
AWS→さくら
生きるためにバーンレートを下げる必要があった
・〜2013
スピード重視
railsとアグリゲーションがDBを共有
・2013〜2016
スピード重視
さらにクラウド会計がDBを共有
・2016〜2018
共有データを分割
アグリAPIでアクセス
アグリDBを分割
アグリDBをスケールアウト
・2018〜
マイクロサービス化を進めている
認証基盤、課金基盤、配信基盤
●道のりのまとめ
・生き残ることに必死
リリーススピード優先
ランニングコストを抑えることも重要
・共有DBのキャパシティ課題
シャーディングで根本解決
・マイクロサービス化
疎結合に
・これから
DB共有をなくす
EKS移行
●考え方
・組織が小さいうちは技術を共通化
・組織が拡大したら増やすべき
流行り廃りへのリスクヘッジ
変化していくことへの慣れ
・マイクロサービス化
人数拡大に合わせてやらねばならない
設計難易度は高いのは覚悟の上
インフラをプロダクトチームへ
担当のドメイン領域を狭めて、ライフサイクル全体に関わる
・クラウドインフラは高価
インフラエンジニアの効率化だけではコスパが悪い
プロダクトチームのアジリティーを上げられるか
docker, k8sを前提に
●マイクロサービス移行の例
・共有ライブラリをリプレイス
かんたんにやれた
画像、PDF処理
ruby + gem -> golang
境界線を引きやすい
ステートレス
上げっぱなしで大丈夫
・共有ライブラリをリプレイス
DLLやjarのみで提供されているもの
連携先の事情で使わざるを得ないもの
・サービス関連系の共有DBリプレイス
SSO基盤
個別に実装を考えなくて良い
アグリゲーションデータ共有基盤
入出金履歴、残高情報など
トランザクションの分割が難しい
・家計簿サービスの課金ロジックを切り出し
複雑でメンテしにくい
影響が大きい
サブスク管理、課金状態管理を境界に
●マイクロサービスのメリット
・新しい最適な技術を採用しやすい
・開発チームを分割しやすい
・再利用性が高まる
■ラクスル株式会社 二串 信弘さん
●自己紹介
・ラクスル事業本部
・Head of Engineering
事業部のCTOのような役割
●テーマ
・技術選定は会社を知ることから始めよ
●ラクスル
・vision
仕組みを変えれば、世界はもっと良くなる
・伝統的な産業にテクノロジーを持ち込み
産業構造を変え、21世紀型へアップデート
自社で製造、販売する構造
-> 製造とECのシェアリングプラットフォーム
・サービス
ラクスル: 印刷
ハコベル: 物流
●技術スタック
・server side
PHP -> rails、一部でgolang
・front
vue.js
・infra
AWS, GCP, Azure
●技術の位置づけ
・DeNA時代はすごいエンジニアが集まっていた
運用を堅実に頑張ってます！より
新しいもの作りました！が評価される文化
・ラクスルの技術力は高いが
他のテックカンパニーと一緒？
・ビジネス開発が非常に得意な会社
伝統的な産業の課題をITの力で解消
・技術は究極的には手段
プロダクト価値を最大化させ事業を成功させることこそ目的
・現戦力で成果を最大化させる
コスト
学習コスト、開発人数など
成果量
売上、品質、モチベーション、離職など
・問題を複雑にしすぎない
ビジネスが複雑なので技術はシンプルに
後から入った人が理解できるか
・インフラ環境
EC2メインで、一部ECSやEKS
本番をコンテナ化は時々盛り上がるが、本格導入していない
開発では色々使っている
サービスの数が少ないので、chefなど
・サービスアーキテクチャ
マイクロサービスはオーバーエンジニアリング
モノリスとマイクロの中間
ビジネスドメインでシステムを分割
印刷EC、集客・広告
認証、決済、データチェック、印刷出稿
●システム刷新
・システムに柔軟性を持たせ、経営戦略の選択肢が増えている状態にする
言語やフレームワークではなく、どう分割するか
技術的な不確実性、再負債化リスクを排除
・スタートアップは時間もお金も限られている
どうしたらプロダクトをもっと使ってもらえるか
どうしたら定着させられるか
●現場解像度を上げてチーム全員でプロダクトビジョンを描く
・現場に行って何が起きているのかの解像度を上げる
・どのように解決するのかを全員で創り上げる
・1,2週単位でスプリントを回していく
・ラクスルは産業の課題をプロダクトで解決する会社
・エンジニアはパワーのかけ方を意識し事業成長を支えよ
・事業特性を理解することがバリューを発揮する近道
■株式会社ビズリーチ 外山 英幸さん
●BizReach
・今年で10周年
・ビジョナル株式会社のホールディングス制に
・1400名+
エンジニアは300くらい
・サービス
BIZREACH
BIZREACH キャリトレ
CAMPUS
HRMOS
●技術選定とは？
・対象による差
アーキテクチャ、マネージドサービス、
開発言語、angularのライブラリ
など様々
・事業フェーズによる差
創業 / マネタイズ / 急成長 / 成熟
・創業フェーズ
事業づくりは仲間づくり
エンジニアを集めやすい は一つの観点
定量的な判断基準は必要
ググれば色々
・急成長 / 成熟フェーズ
技術選定の難易度は上がる
●ROIの証明
・費用対効果、投資対効果
このジャンルでの価値の証明は難しい
とくに非エンジニア向けは難しい
リファクタリングって直接ビジネスに響かない
●Why - What - Howで考える
・成長企業でよくある技術選定のタイミング
EOLのリスク
フロントでよくある保守性
運用・保守でよくある監視対応
新技術のキャッチアップ
・やることが決まっていれば Howは困らない
複数の課題を抱えていることが多い
課題の優先順位に悩む
●Return = Whyが解消された場合の効果
サポートが受けられる
開発スピードが上がる
深夜対応や休日出勤が減る
新しいアイデアを創出できる
・やはり優先順はつけづらい
●最強の対抗馬
・売上やユーザー満足度が向上する〇〇機能
●役割や社風によって判断基準が変わってくる
・組織、プロダクト、チーム
・トップダウンなのかボトムアップなのか
●成長し続けるための技術選定
・課題の可視化
事象と課題を可視化、カテゴライズ
積み上がる一方なので定期的な棚卸し
・課題の評価
緊急性、重要度などで3段階に分ける
・解決方法の検討
ボトムアップで解決案を誰でも出せることが理想
複数の課題を解決できるように
・優先順位判断
対象の時間軸と効果が異なる
時間軸が短い売上向上などが優先されがち
判断するためのアプローチ
1. 時間の20%を固定で投資
2. チームの責任範囲を分ける
グロース、DevOps、基盤、SRE
3. P/L，生産性、組織の責任の役割を分ける
PdM、EM、テックリード
4. 判断基準を言語化、定量化
誰でも同じ判断ができるように
5. 万能なPOが判断
いるかも知れないけど誰でもできるわけではない
ビジョナルでは1〜4までを実施している
・プロダクト戦略への追加
・経営層の理解
規模が大きな選定は、コストも期間も長くなる
ロードマップに含めて、経営を巻き込む
●大規模な技術選定の事例
・AWS Summitで話してきました
・縦から横へ
マイクロサービス化
internalなAPIなので gRPCになりそう
Kotlin、DB分割、インフラ改善
これから大きな戦いになる
・生産性の向上
疎結合、運用自動化など
P/Lを重視しがち
途中から生産性や組織に切り替わる
・役割分担
一人で全ては難しい
CTO, PO/CPO/VPoP, VPoE
・AI室
P/Lを追う組織と、研究は相性が悪い
切り出した
■QA
●プロダクトチームに権限を移譲すると管理が難しくなるのでは？
一貫性がなくなってしまうとか？
・中出さん
難しくなった感じはしない
判断基準に、みんながやりたい、適したものを選ぶ、があるから
そんなにずれたものは出てこない
●後からjoinしたエンジニアにわかりやすくするためには？
・二串さん
年が経つにつれて難しくなっていく
オンボーディングに力を入れている
ペアプロ、モブプロ。ベロシティが落ちることは許容
・外山さん
毎月 10〜20名中途入社
同月入社を同期と呼ぶ
同期での飲み会なども会社でサポート
事業をまたいだ同期のつながりもつくっている
●技術選定で、マネジメント層が果たす役割は？
・二串さん
「プロダクトの課題」ではなく
経営に「我々の課題」と認識してもらう
・中出さん
チャレンジだと感じたら、全力で後押しする
・外山さん
現場の声を拾って、代弁する
マネージャーも開発メンバーと一緒に考える
■感想
実体験を聞いて
・事業フェーズに応じて優先する観点を切り替える
・時系列、対象の広さ深さで増える観点に合わせて、チームと役割を変化
・事業の変化速度に合わなくなったら、組織に合わせてプロダクトを分割
に改めて納得できました！
・技術はビジネス課題を解決する手段
・ビジネスが十分に複雑なので、技術はシンプルに使う
・現場に寄り添い、チーム全員でビジネス課題を解消する
・ビジネスドメインのコンテキスト境界に沿ったチームとプロダクト
・プロダクトライフサイクルをチームが担う
以前から「理想だな」と考えていたこれらを、すでにラクスルさんが実現されている様で、お話を聞いていてワクワクしました！
登壇者の皆さん、運営の皆さん、ありがとうございました！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。