新型コロナウイルスに関係する内容の可能性がある記事です。
新型コロナウイルス感染症については、必ず1次情報として 厚生労働省 首相官邸 のウェブサイトなど公的機関で発表されている発生状況やQ&A、相談窓口の情報もご確認ください。※非常時のため、すべての関連記事に本注意書きを一時的に出しています。
見出し画像

2020-03-09 業界を変えた大規模サービスの技術選定 #techplay0309

2020/03/09 に開催された 業界を変えた大規模サービスの技術選定 のイベントレポートです。

●イベント概要
「技術選定」の本質はどこにあるのでしょう。
流行っている技術?数年後も廃れる可能性が少ない技術?今の組織にあった手法?コストパフォーマンス?

それぞれの目的に応じた、その時最適だと思う技術選定をし続けながら、エンジニアの開発運用は続きます。

世の中に大きなインパクトを与えたサービスの技術選定はどんな意思決定を繰り返しているのか。
今回はそんな、私たちの生活に影響を与えた大規模サービスで技術選定をしている方たちお呼びして登壇形式でイベントを開催します。
技術選定は、ビジネスと組織の未来を考えることでもあります。一緒に未来を考えませんか?


■株式会社マネーフォワード 中出 匠哉さん

スクリーンショット 2020-03-09 19.37.33

●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を共有

スクリーンショット 2020-03-09 19.48.49

・2013〜2016
  スピード重視
  さらにクラウド会計がDBを共有

スクリーンショット 2020-03-09 19.49.11

・2016〜2018
  共有データを分割
  アグリAPIでアクセス
  アグリDBを分割

スクリーンショット 2020-03-09 19.49.40

  アグリDBをスケールアウト

スクリーンショット 2020-03-09 19.50.13

・2018〜
  マイクロサービス化を進めている
  認証基盤、課金基盤、配信基盤

スクリーンショット 2020-03-09 19.50.34

●道のりのまとめ
・生き残ることに必死
  リリーススピード優先
  ランニングコストを抑えることも重要
・共有DBのキャパシティ課題
  シャーディングで根本解決
・マイクロサービス化
  疎結合に
・これから
  DB共有をなくす
  EKS移行

●考え方
・組織が小さいうちは技術を共通化
・組織が拡大したら増やすべき
  流行り廃りへのリスクヘッジ
  変化していくことへの慣れ
・マイクロサービス化
  人数拡大に合わせてやらねばならない
  設計難易度は高いのは覚悟の上
  インフラをプロダクトチームへ
  担当のドメイン領域を狭めて、ライフサイクル全体に関わる
・クラウドインフラは高価
  インフラエンジニアの効率化だけではコスパが悪い
  プロダクトチームのアジリティーを上げられるか
  docker, k8sを前提に

●マイクロサービス移行の例
・共有ライブラリをリプレイス
  かんたんにやれた
    画像、PDF処理
    ruby + gem -> golang
  境界線を引きやすい
  ステートレス
  上げっぱなしで大丈夫

・共有ライブラリをリプレイス
  DLLやjarのみで提供されているもの
  連携先の事情で使わざるを得ないもの

・サービス関連系の共有DBリプレイス
  SSO基盤
    個別に実装を考えなくて良い
  アグリゲーションデータ共有基盤
    入出金履歴、残高情報など
    トランザクションの分割が難しい

・家計簿サービスの課金ロジックを切り出し
  複雑でメンテしにくい
  影響が大きい
  サブスク管理、課金状態管理を境界に

●マイクロサービスのメリット
・新しい最適な技術を採用しやすい
・開発チームを分割しやすい
・再利用性が高まる


■ラクスル株式会社 二串 信弘さん

スクリーンショット 2020-03-09 20.03.08

●自己紹介
・ラクスル事業本部
・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、集客・広告
  認証、決済、データチェック、印刷出稿

スクリーンショット 2020-03-09 20.19.53

●システム刷新
・システムに柔軟性を持たせ、経営戦略の選択肢が増えている状態にする
  言語やフレームワークではなく、どう分割するか
  技術的な不確実性、再負債化リスクを排除
・スタートアップは時間もお金も限られている
  どうしたらプロダクトをもっと使ってもらえるか
  どうしたら定着させられるか

●現場解像度を上げてチーム全員でプロダクトビジョンを描く
・現場に行って何が起きているのかの解像度を上げる
・どのように解決するのかを全員で創り上げる
・1,2週単位でスプリントを回していく

スクリーンショット 2020-03-09 20.25.51


・ラクスルは産業の課題をプロダクトで解決する会社
・エンジニアはパワーのかけ方を意識し事業成長を支えよ
・事業特性を理解することがバリューを発揮する近道


■株式会社ビズリーチ 外山 英幸さん

スクリーンショット 2020-03-09 20.30.58

●BizReach
・今年で10周年
・ビジョナル株式会社のホールディングス制に
・1400名+
  エンジニアは300くらい
・サービス
  BIZREACH
  BIZREACH キャリトレ
  CAMPUS
  HRMOS

●技術選定とは?
・対象による差
  アーキテクチャ、マネージドサービス、
  開発言語、angularのライブラリ
  など様々
・事業フェーズによる差
  創業 / マネタイズ / 急成長 / 成熟

スクリーンショット 2020-03-09 20.37.02

・創業フェーズ
  事業づくりは仲間づくり
    エンジニアを集めやすい は一つの観点
  定量的な判断基準は必要
    ググれば色々
・急成長 / 成熟フェーズ
  技術選定の難易度は上がる

●ROIの証明
・費用対効果、投資対効果
  このジャンルでの価値の証明は難しい
  とくに非エンジニア向けは難しい
  リファクタリングって直接ビジネスに響かない

●Why - What - Howで考える
・成長企業でよくある技術選定のタイミング
  EOLのリスク
  フロントでよくある保守性
  運用・保守でよくある監視対応
  新技術のキャッチアップ

スクリーンショット 2020-03-09 20.41.19

・やることが決まっていれば Howは困らない
  複数の課題を抱えていることが多い
  課題の優先順位に悩む

●Return = Whyが解消された場合の効果
  サポートが受けられる
  開発スピードが上がる
  深夜対応や休日出勤が減る
  新しいアイデアを創出できる
・やはり優先順はつけづらい

●最強の対抗馬
・売上やユーザー満足度が向上する〇〇機能

●役割や社風によって判断基準が変わってくる
・組織、プロダクト、チーム
・トップダウンなのかボトムアップなのか

スクリーンショット 2020-03-09 20.44.43

●成長し続けるための技術選定
・課題の可視化
  事象と課題を可視化、カテゴライズ
  積み上がる一方なので定期的な棚卸し
・課題の評価
  緊急性、重要度などで3段階に分ける
・解決方法の検討
  ボトムアップで解決案を誰でも出せることが理想
  複数の課題を解決できるように

スクリーンショット 2020-03-09 20.47.43

・優先順位判断
  対象の時間軸と効果が異なる
  時間軸が短い売上向上などが優先されがち

スクリーンショット 2020-03-09 20.48.19

  判断するためのアプローチ
    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

スクリーンショット 2020-03-09 20.58.32

●プロダクトチームに権限を移譲すると管理が難しくなるのでは?
 一貫性がなくなってしまうとか?
・中出さん
  難しくなった感じはしない
  判断基準に、みんながやりたい、適したものを選ぶ、があるから
  そんなにずれたものは出てこない

●後からjoinしたエンジニアにわかりやすくするためには?
・二串さん
  年が経つにつれて難しくなっていく
  オンボーディングに力を入れている
  ペアプロ、モブプロ。ベロシティが落ちることは許容
・外山さん
  毎月 10〜20名中途入社
  同月入社を同期と呼ぶ
  同期での飲み会なども会社でサポート
  事業をまたいだ同期のつながりもつくっている

●技術選定で、マネジメント層が果たす役割は?
・二串さん
  「プロダクトの課題」ではなく
  経営に「我々の課題」と認識してもらう
・中出さん
  チャレンジだと感じたら、全力で後押しする
・外山さん
  現場の声を拾って、代弁する
  マネージャーも開発メンバーと一緒に考える


■感想

実体験を聞いて

・事業フェーズに応じて優先する観点を切り替える
・時系列、対象の広さ深さで増える観点に合わせて、チームと役割を変化
・事業の変化速度に合わなくなったら、組織に合わせてプロダクトを分割

に改めて納得できました!

・技術はビジネス課題を解決する手段
・ビジネスが十分に複雑なので、技術はシンプルに使う
・現場に寄り添い、チーム全員でビジネス課題を解消する
・ビジネスドメインのコンテキスト境界に沿ったチームとプロダクト
・プロダクトライフサイクルをチームが担う

以前から「理想だな」と考えていたこれらを、すでにラクスルさんが実現されている様で、お話を聞いていてワクワクしました!

登壇者の皆さん、運営の皆さん、ありがとうございました!


この記事が参加している募集

イベントレポ

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
note.user.nickname || note.user.urlname

いつも応援していただいている皆さん支えられています。

うれしいです!シェアしてもらえるとありがたいです!
24
プロセスのデザイナー兼エンジニア https://suwa-sh.github.io/profile/

こちらでもピックアップされています

イベントレポート
イベントレポート
  • 94本

各分野の最新情報と事例、熱量を体感しに参加しているイベントのレポート

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。