2019-07-02 Developers Summit 2019 Summer #devsumi
2019/07/02に開催された Developers Summit 2019 Summer のイベントレポートです。
●イベント概要
変化の多い世の中においてアプリケーションを作り続けるにあたり、マイクロサービス、コンテナといった最新テクノロジーの採用が欠かせなくなりました。また、これらのアプリケーション開発を支えるエンジニア組織の活性化にも焦点があたり、各現場においてさまざまな取り組みが行われています。
これらの「テクノロジー」と「人」は別々に語られていいものでしょうか。チームの構造がソフトウェアの構造に反映されるという「コンウェイの法則」にもあるよう、テクノロジーにおける戦略とエンジニア組織の改善は表裏一体といえます。
今回の「Developers Summit 2019 Summer」では、テクノロジー、プロダクト、開発プロセス、エンジニア組織といったさまざまな切り口で、不確実性に向き合えるソフトウェアとエンジニア組織を作っていくための知見が得られる場を目指します。
■愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係
及川 卓也さん [Tably]
●やっていることはコンサルティング
・技術
どんな技術が良いか？
今の作り方が正しいか？
・製品
これは望まれているものか？
・組織
ここには人の問題が介在する
結局はヒト
組織の大きさに合わせて一緒に課題を考えていく
●愛されるプロダクト
・Product Manager Conference
去年のテーマ
愛されるプロダクトを創ろう
・海外でも
リーン開発からMVP
最近 MLP (Minimum Lovable Product) が出てきた
愛されることにどんな価値があるか？
・ALL THINGS MUST PASS
TOWER RECORDSの話
レコードショップ、CDショップ
街のあらゆる場所にあった
レコード -> テープ -> CD
テクノロジーの変化
iPod/iTunes
経験が生まれていった
アナログからデジタルへ
所有から利用、そして体験へ
シェアリング受容の高まり
昔は「いつかはクラウン」だった
お金を持っていることに価値がなくなってきた
●サービス化
・webに対して、購入しなければならないという意識はない
コストを払うことはあるが、全く見えないことはない
・企業からするとMonetizeを考える必要がある
パッケージ製品のころは考える必要がなかった
Googleで初めて体験した
・ビジネスモデル
一括購入
サブスクリプション
アプリ内課金
-> 使われ続けなければならない
当然、ユーザが好きだから使う状況が必要
-> 愛されるプロダクト
・スマホアプリを出しても、AARRRモデルが必要
いろんな手法を組み合わせて離脱率を下げていく
紹介されるには愛される必要がある
●不確かなものを確かにする
・小さなマーケットが多数存在する時代
・マスへの販売は響かない
・仮説検証をすばやく繰り返す
●各フェーズでのフレームワークは見えてきている
・LEAN
資金が枯渇しない様に、物を作らずに仮説を検証したい
・AGILE
設計と実装は一体化している
つくってから分かる事が多い
制御された環境下で、これを繰り返す
・DEVOPS
パッケージプロダクトの場合、RTMで一段落だった
サービスの場合、リリースしてからが始まりの部分がある
リクエストを処理しきれるか？
実際に利用されているか？
-> ここから仮説検証が始まる
理想
開発・運用者 <-> 利用者
従来型
開発・運用者 <-> 中間事業者 <-> 利用者
クラウド
開発・運用者 <-> クラウド <-> 利用者
・フレームワークの導入に懸命になりがち
型を入れるだけでは良くならない
・型ではなく、組織の魂
Microsoftはウォーターフォールだが、これだけ流行っている
Googleはスクラムがスタンダードではなかった
●組織
・プロダクトマネージャーという役割
組織横断的なプロダクトチームを束ねる
MiniCEO
営業、法務、マーケ、広報、サポートなど
ただ、人事権はないので高いビジョンが必要
スタートアップのCEOを考えると、全てを拾い上げる泥臭い作業
・役割分担
プロダクトマネージャー
what, why, whenを決める
エンジニア
how に責任を持ち、アイデアを実現させる
ある意味緊張感のある関係性
・組織構造
プロダクトマネージメント
プロダクトマネージャー
エンジニアリング
エンジニアリングマネージャー
ヒト軸で考える
エンジニア
これらは別のラダー
googleではこれを移動するのは社内転職に近い
・雇用形態
ジョブ型雇用
メンバーシップ型雇用
日本でも徐々にジョブ型雇用が増えてきている
・エンジニアリングマネージャーという役割
自分で技術を突き詰めるのではなく
メンバーの成長から、エンジニアリングで組織に貢献する
・TechLeadという役割
ある程度のレベルになったら
マネージャーを補佐
品質を保証していく
-> マネージャーとリーダーは表裏一体な役割
・職能組織と事業主体組織
どちらでもプロダクトごとにマトリクス型になる
・某ゲーム会社の組織構成
職能ごとの ENG sub MGR が、管理 & 火消し
この人が見れるので評価できる
●ジョブディスクリプション作成のすすめ
・職種（ジョブタイトル）が何をあらやすかを明文化
・トップダウンとボトムアップで、もれなく
●多能工 vs. 単能工 / 担当者を固定するか
・体験することで理解できる
・何らかの形で経験を
●求められること
・事業サイド
仮説検証サイクルをすばやく回す
スケーラブル
・組織サイド
集合離散
スケーラブル
-> スクラップ&リビルド
壊れない -> すぐに復旧できる
クラウド、マネージド、XXX as a Code
属人化を排除していくことが重要
DevOps -> NoOps
サーバレス、PaaS、コンテナ、FaaS
マイクロサービス
スクラップ&リビルド
スケーラビリティ
DevOps/NoOps
柔軟性と規律
好き勝手やっていい では、リビルドできない
ツールチェインの共通化などを考える
●プロダクトマネージャーの認知は高まった
が、調整役で終わってないか
分業制を進めるのではなく
全員がユーザーにどんな価値を提供しているのかを考える
・WAmazing 舘野さん
自分が書いているコードの価値がどこにつながるのかを考えてみよう
使ってくれるユーザにどんな価値を提供するのか
●プロダクト愛
テクノロジーで人の営みを変えていく喜び、パッションが必要
・Chrome、Google日本語入力を開発した
電車に乗っていたら、若者が載ってきて、ラップトップを開くと両方使ってくれていた
うれしい！
プロセス、組織、テクノロジーの三位一体
↓
プロダクト愛
↑
ユーザー
■ヤフーのアプリにおける会社全体での業務効率化について
鎌倉 和弘さん [ヤフー]
●自己紹介
・CTO室アプリ統括部
全社横断
●Yahoo!JAPAN
・サービス 100以上
・ネイティブアプリ 50以上
●開発体制
・構成
サービスごとにチームが分離
多くの権限がサービスに移乗されている
チームの中でどう進めるのかを自由に決められる
開発手法もそれぞれ
人数もそれぞれ
・メリット
サービスごとに柔軟
それぞれの判断で、スピードが早い
・デメリット
ノウハウがサービス内に閉じてしまう
同じ失敗を繰り返す
・他が見えづらい
テストはどのくらい書いている？
OSのサポートはどこまで？
●チーム
・アプリWG
全員兼務のサービス横断チーム
・SDK Core
全員兼務の実装部隊
・黒帯も参加
社内の特定技術のトップレベルの人
設計での相談役
●開発場所
・ペアプロエリア
他のサービスの方や黒帯の方とペア
最初は自分のコードを見られる
ググっている様子を見られるのは恥ずかしい
手戻りが減る
リリース数増加
残業時間 20%減
苦手な人もいる
集中力が必要なので、卓球台を用意してリラックス
●作業時間
・週2h x2回
・1週間の 10%
●お問い合わせページを用意
・部屋数が増えていく
・多人数がいる部屋では、初心者な質問はしづらい
質問内容は技術、ビジネスなんでも
●見える化
・自動で取得できるもの
クラッシュ率、コミット数、OSS
レーティング、サポートOS、アプリサイズ
-> SDK提供側が最低OSバージョンを把握できる
昔は書いてもらっていたが、更新漏れがあったので
●事例1: 車輪の再開発
・共通化したライブラリ
実績がないと導入しづらい
ノウハウが溜まってから使いたい
-> 社内向けに組み込んだものを提供
アップデートSDK、
モック集、ABテストを楽に、
ログイン共通化
-> 新規のコスト削減、ブラッシュアップされ続けていく
●事例2: 期初に設定した予定があるので新技術を導入しづらい
・出たばかりで調査コストがかかる
-> カンファレンス参加者の取りまとめ
誰が参加しているか
現地では密に連絡を取り合う
なぜ現地？
現地のエンジニアにすぐに質問できる
どこよりも早く機能を試せる
-> 1つのサービスでできたら共有
社内勉強会も
-> 他のサービスでも連携してPR
全社横断なので誰かしら知っている人がいるのでスムーズ
●事例3: 主務が優先で後回しになってしまう
・OSSでの還元、最新言語対応など
-> 兼務の時間を利用
AppFeedbackSDK を公開中
■実践 Engineering Manager ～理想のエンジニアチームを目指して～
酒井 篤さん [ミクシィ]
●自己紹介
・2011 ミクシィに中途入社
・2014 家族アルバム「みてね」の開発開始
・2018 みてね事業部開発グループマネージャー 兼 SRE
・マネージャー入門者として考え、実践してきたこと
●みてね
・子供の写真や動画を共有・整理
・家族だけのクローズドなSNS
・ふりかえり機能で子供の成長を感じられる
・利用者数 500万人 を突破！
・FamilyAlbumとして海外展開
今は英語圏
今後はアジア、ヨーロッパでも
●はじめに
・エンジニアリングマネージャーになるまで
5,6人が限界のスクラムチーム
マネージャー不在のフラット
プロダクトの成長とともに組織のスケールが必要になった
ドメイン知識が蓄積されていた
メンバーの安心感にもつながった
・現在の開発組織
18名の開発グループ
ネイティブアプリ / 研究開発 / SRE
・目指すもの
エンジニアの生産性を最大化
目標を大幅に超える成果を創出
メンバーのことを考えると目標を大きく超える必要がある
・考えること
評価、コスト、メンバーの成長、自分のキャリア
-> ストレスを抱えないように最初に決めた
目標を「ひとつずつ」達成していく
できない、わからないことはオープンに
自分が決済可能な予算を確保
少しでも自分でコードを書く
キャリアとして充実したものになるよう努力
●理想のチーム
・管理職全員が、自分が抱えているメンバーの意見を理解している
意識して場を作っている
・課題はエンジニアの責任で解決されるべき、とエンジニア自身が感じている
どうしたら自分で行動していくようになるか
・大きな声に傾きすぎないためのコミュニケーション
PO、経営者の声に思考停止しても進めてしまう
自分の頭で考えて動けるようにコミュニケーション方法をつくっておく
・ボトムアップの効果
自分で考えるようになる
リスクに寛容になる
●学習
・様々な視点での振り返り
振り返りの時間が確保されているか？
率直に議論して、できるだけはやくアクションを起こしていく場
・失敗を冷静に受け入れることができる空気
こうなってしまったときは、こう対処しよう
熱くなりすぎるといろいろな部分を見落としてしまうことも
・学習の効果
失敗を糧にチャレンジが増える
リスクに寛容になる
成長を感じ、充実感が広がる
心理的安全かつ責任の大きいLearning Zone
学習だけ、ボトムアップだけではなく両方が必要
●エンジニアリングマネージャーの役割
・理想のチームを作るために
障害となる事象を事前に予防
会議が多すぎる
決定フローが時間がかかりすぎる
情報が十分にシェアされていない
・とりあえずやれること
チーム運営の最低限のルール
アクション可能なチームと個人の目標
定期的でオープンな振り返り
●チーム運営の最低限のルール
・メンバーを守り、モチベーションを維持する
不要な会議を減らす
改善活動に使って良い時間を決める
議論が発散、対立したときの対処の仕方を決める
・アクション可能なチームと個人の目標
OKRで
自分で考える
マネージャーとの差を埋めていく
-> 自分の存在意義を感じやすい
・定期的でオープンな振り返り
失敗、成功した時、どちらも称賛する
短期的な振り返りを増やして、失敗の影響範囲を小さく
●フレームワークを用いた経験主義のマネジメント
・形だけでしょ？
形から入るのは楽
身につけたらどこでも使える
繰り返していけばうまくなる
振り返りが用意されているフレームワークを採用
・OKR
事業目標に対して、自分が何をすべきか考えられる
期待と責任が明確になり、重要性を感じられる
客観的な指標で振り返りやすくなる
プロダクトの問題はどこか？
どこで貢献したいか？
などの会話が生まれた
・1on1
2週間ごとに全メンバーと
キャリア、内生的なふりかえり
良かったことを伝える
・スクラム開発
スプリントレトロスペクティブが大切う
失敗の規模を小さく
・振り返りのマンネリ化問題
複数を試す
KPT
象、死んだ魚、嘔吐
Airbnb Story
視点を変えることで刺激になる
●チーム独自の学習・ボトムアップ文化
・ふりかえりを繰り返して少しずつ育ててきた
・ユーザーストーリーマッピング
大きな新機能の開発では必ず実施
抽象的な要求が降りてくる
俯瞰的な視野でエンジニアが企画者と一緒にユーザーを考える
優先度、課題、難易度など
エンジニア自身が気づいて行動が起きる
・輪番制のリリースマネジメント
エンジニアが交代でリリースプランニング、マネジメント
QA、マーケとの調整などをエンジニア自身で
自分の活動範囲の影響を認識
・バックログ準備回
スプリント中に必ず1回
エンジニア/CS/プロモなど様々な視点から課題出し
課題に対応するバックログをつくる
エンジニアだからこそ提案できる機能
技術的負債も事業の観点から説明
・プロジェクトチーム制度
エンジニアがプロジェクトを発案、リード
課題のリサーチ、提案〜目標設定、実施まで全ておまかせ
運営することでリーダーシップが生まれる
●まとめ
・大事なこと
汎用的なルール、ルールのもとで物事を考える
常に優先度をつけて行動すればストレスフリー
組織最適ではなくキャリアを楽しむ
あなたのチームは、ボトムアップで動いていますか？
あなたのチームは、学習ができていますか？
■ソフトウェアアーキテクチャの組織力学
広木 大地さん [レクター]
●自己紹介
・2008 ミクシィ入社
・2016 CTOのノウハウを広く世の中に還元する レクターを設立
・エンジニアリング組織論への招待
・EM.FM
●エンジニアリング組織論への招待
・ビジネス書大賞、技術書大賞の2つを受賞したのは発
・エンジニアリングと組織は不可分
●2つのDX
・開発者体験と企業のデジタル化
・一方しか知らないひとが多い
●アーキテクチャという概念は分かりにくい
・ローレンス・レッシグのCODE
権力の一種
ある選択肢を選びやすくする
ある行動が不快になるようにする
・ビヨンドソフトウェアアーキテクチャ
技術的な側面に焦点を合わせた定義と異なり
人間やビジネスに焦点を合わせるもの
人間もビジネスもふくむ
●アーキテクチャは複雑に絡み合う
・プロジェクト
・ビジネスモデル
・組織構造
-> アーキテクチャ
一時しか使わない/継続的価値を与えていく
組織によっても
進め方によっても
・アーキテクチャとは
何かをしやすく/何かをしにくくするもの
社会をとりまく目に見えない力を働かせるもの
●良くすることができる = 交換可能
・選択肢を持つ側
権力
・選択肢を持たない側
依存
・この依存による理不尽がアーキテクチャ
・選択肢を持つほうが強く、持たないほうが弱い
モテる異性との恋愛
かぐや姫
属人化した業務
そんな組織に属しているヒトはいないですよねw
エンジニア求人
tweetしたらランチに誘われたり
●ソフトウェアアーキテクチャでは交換可能性が重要
・自動テスト、デリバリパイプライン、Infra as Code
失敗してもすぐにもとに戻せる
ユニットテスト、API仕様を満たしている限りは交換可能
・プロジェクトマネジメントの複雑性
前後依存性、リソース依存性でクリティカルパスを生む
・依存関係は最初から自明ではない
ソフトウェアは建築と違う
・前後依存性
モックサーバやインタフェース設計
・リソース依存性
教育やフレームワークの導入
●プロジェクトとプロダクトの依存関係は相似形
・モジュールの依存関係とプロジェクトの依存関係が緩やかにつながる
・プロセスが変わってきた
V字モデル
依存が先に決まる
3ヶ月でつくりきりなさい
-> 依存関係が解消できれば実現できる
漸進的なプロセス
抽象構造を後から発見する
railsなどならさっとはじめられるが
後でリファクタしていく
●プロジェクトの変化に連動して抽象構造のパラダイムも変化
・存在論的な抽象(オントロジ)
犬とうさぎは動物
・目的論的な抽象(テレオロジ)
さんまと豚肉はメインディッシュ
・あとで発見していく方法論が増えてきた
ドメイン駆動設計
クリーンアーキテクチャ
DCIアーキテクチャ
・進化的アーキテクチャ = 組織論
継続的なリリースが前提に
●コンウェイの法則
・組織構造 = コミュニケーションの構造 -> システムの構造
・悪い組織構造は悪いシステムを生み出す
ころころ組織構造を変えている会社で良いシステムはつくれない
●ゲシュタルト原則
・どこを仲間だと思うか
地理的、似ている種類
部署で人を呼ぶのは人間の習性
・取引コストによって、会社・組織の境界線が決まる
BFFがDB持っているとか、、、
●逆コンウェイ作戦とマイクロサービシズ
・組織間のコミュニケーションを決める
・合わせたアーキテクチャで進める
●市場変化との関わり
・市場変化が乏しい
持続的イノベーションが差別化
大きくなると対立
・市場変化が激しい
探索的イノベーションが差別化
大きくなるとコントロールしにくい
・古いシステムが負債ではなく
組織が必要な速度で変更できる能力を失うことが負債
・DevLOVE Xの資料にまとまっています
●ビジネス構造とアーキテクチャ
・ペースレイヤリング
自然や文化と流行
変更のペースレイヤリング
変化の少ない部分に依存
・ビジネスのペースレイヤリング
目的より手段の方が変わりやすい
・要求工学とクリーンアーキテクチャのオニオンモデル
内側と外側が反対だけど似ている
・ビジネスの不確実性の波
変化しやすい、しにくいで
周波数をプリズムのように分解できる
分解した変化しやすさの認識の齟齬で技術的負債と呼ばれる
■ティール型組織でサービス立ち上げが成功した話
手塚 卓也さん [スリーシェイク]
●3-shake スリーシェイク
・Sreake
SRE特価コンサル/PF開発支援
・Reckoner
フルマネージドデータ統合サービス
●Reckoner
データ収集、加工/ブレンディング、集計
可視化、外部サービス連携
を統一したプラットフォームで活用
●RechDB
・DBを独自開発
Scheme設計不要
データ構造変更可能
DWHに匹敵するパフォーマンス
●歴史
・2016/11 開発開始
・2018/04 ピボット確定
・2019/09 リリース予定
●ピボット前の組織
・代表
・プロダクトマネージャー
・デザイナー/リードエンジニア/SRE
エンジニア...
-> 縦割りで、自分の仕事しかしない
●問題
・情報が不透明
・マネジメント工数肥大
・意思決定の遅延
-> 全員ロナウド時代
ときにはロールを飛び越えて仕事をしていく必要
●失敗
・企画の失敗
明確なビジョンがなかった
しょっぱいGAができていた
エンジニアが気づけたはず
・技術の失敗
マイクロサービスだった
属人化
・組織の失敗
マネジメントで爆発
-> 収集がつかず
●対策
・Mission再定義
・ティール組織
レッド、アンバー、オレンジ、グリーン、ティール
ロナウド時代はオレンジ
上司の指示は絶対
ティールを目指した
管理者なし
自分たちで進めていく必要
●チーム構成
・相互に関連し会う関係に
プロダクトオーナー/サーバー+フロント
カタリスト
サーバー+SRE
サーバー+フロント
フロント
機械学習
SREセールス/マーケ
●企画が良くなった
・チーム全体で考えるように
・ユーザー視点が根付いた
●技術が良くなった
・ゴールを見据えてアーキテクチャ設計
ビジネスから降りてくるその場しのぎの開発がなくなった
・メンバーの技術力向上
守備範囲が広がる
●チームが良くなった
・メンバーのモチベーション
目指すべきビジョン
タスクの意味がわかる
・意思決定のスピードアップ
●工夫した点
・サポーター制度
得意分野でサポーターになる
困ったらサポーターに相談
相談が必須
・採用活動
チーム全員で採用活動
ほしいピースはチームがわかっている
●今後の課題
・特定の人が頑張り過ぎちゃう問題
性善説が前提
頑張り過ぎちゃう人が出るとバランスが崩れる
・個人の評価問題
評価が不透明になりがち
誰が、どう評価するのか。。。
■SI × Webの総合力で切り拓く新しいエンジニアのキャリアパス
田中 清さん [メドレー]
・2010年代後半からX-Techが広がってきた
社会課題をテクノロジーでより良くする
・エンジニアの「課題を解決する力」が必要
●自己紹介
・SIer、コンサル、大手WEB系
・肩書は増えてきたが、あくまでエンジニア
・SIer時代 22-30
スクラッチの基幹システムやパッケージ
プログラマ -> リーダー -> マネージャ
ブラックな時代
・ITコンサル時代 30-34
IT企画、提案から
言った、言ってない -> 議事録&ハンコ
ハンコ押してない問題
・Web時代 34-39
アバターサービス、ソシャゲ、動画サービスなど
高負荷をいかに捌くか
X-Techが活発化してきたのでBtoBへ
・SI x Web時代 39 - 42+
医療 x ITへ
●問題
・医療費 40兆円+
2025年
・高齢化
自動化が進んでいなかったり
・人手不足
忙しいので人が流れてしまう
●メドレーのサービス
・CLINICS
オンライン診療
遠隔診療のオンライン通院システム
201701リリース
・CLINICSカルテ
オンライン診療と連携
クラウド型カルテ
●2000年移行の流れ
・技術もキャリアも複雑化
次のキャリアをどう選択するか？
・2000 - 2005
基幹システム向けのSI開発がメイン
大規模開発、多様なベンダー
プログラマは下に見られていた
出世するならマネジメント
・2005頃
Web2.0
Ajaxやマッシュアップ
「世界を変えられるのはコードだけ」
・2010年代
クラウドサービス、IaC、コンテナ
X-Tech企業のベンチャーが増えだす
エンジニア不足が慢性化
技術やサービスを組み合わせて「何を為すか」が重要
-> WebテクノロジーとSIの総合力が必要に
●SI系とWeb系の比較
・印象
SI: 固い
Web: 柔軟
・スキルマップ
Technical / Design Skill
Web
Business Skill
SI
Human Skill
->下に行くほど習得に時間はかかるが、伸ばせるはず
●X-Techの特徴
・国が定めた制度やガイドラインを遵守
・連携先の外部システムはレガシー
・関係省庁との関係性も大切
●CLINICSカルテ開発時
・3省3ガイドラインに従う必要がある
プライバシーポリシー
権限管理
認証、通信
バックアップ、リカバリ
日本国法の適用範囲での管理
Azure, AWSはOK、GCPは米国法
・ガイドラインの内容を整理分析し、システム、アプリ設計へ適用が必要
精査に丸3日かかった。。。
●初期構成
・Herokuベースで一部AWS
・日本国宝の適用が及ぶ場所 -> AWSへ
●クライアント認証や津神に関する要件
・AWSでクライアント認証に対応しているLBが無い
独自で立てる
・クライアント認証が必要なのは医療機関のみ
●最近の構成
・NLB + Fargate + ECS
NLB tcp443で素通り Nginxでクライアント認証
・それまでの経緯
API GatewayはSSL/TLS終端しちゃう
ALBもダメだった
●導入しているセキュリティ系AWSサービス（抜粋）
・GuardDuty
AWS全体の脅威検出
機械学習で異常検知
・AWS Config
AWSリソース各種設定の履歴保存、閲覧
ルールによる以上設定の監視
Lambdaでカスタムルールも
●他システム連携など考慮すべきことは多様
・CLINICSカルテはクラウド、でも
医療機関内の閉じたNWの院内システム、機器と連携が必要
連携方式は様々
プロキシ役が大切
-> Goでエージェントプログラムを院内に配置
エージェント管理はAWS IoT
他の電子カルテサービスでも苦労するところ
●電子処方箋の本格運用に向けた実証事業
・処方箋の紙は原本でなければならない制約
・QRコード発行、薬局でアプリから読み込み
●メドレーの組織
・様々なバックグラウンドを持つメンバー
医者 -> メドレーなども
・Product Managerと事業部長の二人三脚
プロダクトはPM
お金は事業部長
・成長するための機械と協力し合う風土
課題に対し共闘する
経験豊富なベテランが多い
施策に応じて全レイヤーを担当
テーマに沿って教え合う
●これからのエンジニアに求められていること
技術を磨き進化させて、それを社会に還元する
がエンジニアの本質的価値
本質を追求することが必要
・SIとWebの両方取り
SIの業務設計能力、課題解決力
Webの技術力、スピード感
自分の書いたコードが社会にどう響くか
・キャリア形成の具体例
自分ごととして捉えられるところから
長期視点でスキルバランスを
他の職種の人たちも同じ課題に立ち向かう仲間
■クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計
和田 夏帆さん [エイトレッド]
●自己紹介
・2006 SIer
・2013 エイトレッド
パッケージ保守
新規サービス
サーバサイドの開発
●エイトレッド
・ATLED Work Platform
ワークフローシステム
マルチテナント型
業務システム基盤として汎用的に
・パートナー企業を介してエンドユーザへ提供
●技術要素
・Java
Jersey
・TypeScript
AngularJS
・MongoDB + MariaDB
・Elasticsearch
・Redis
●マルチテナントのアーキテクチャパターン
・AP
1. 共有する
こちらを採用
Redisでセッション管理
2. 共有しない
・DB
1. サーバで分離
2. サーバ & DBの機能で分離
一部はこちら
3. DBの機能で分離
MongoDBはこちらを採用
4. レコードで分離
●アーキテクチャ概要
・APサーバ
API、バッチ処理
静的コンテンツの配信
コンテナ化
・MongoDB
ほぼすべてのデータ
EC2上に構成
AZを分散
データベース名で分離
シャーディングなし
パターン3 -> 2へ移行予定
・Elasticsearch
全文検索、集計
EC2上に構成
※マネージドを利用しなかった
JVMのクラッシュで苦労
AZを分散
インデックス名で分離
シャーディング利用
・MariaDB
トランザクションが必要な機能のデータ
マネージド
テーブル名で分離
・Redis
セッション管理、キャッシュ
マネージド
セッション分離なし
●リクエストのテナント識別方法
・クライアントからのリクエストがどのテナントのものなのか？
URLドメイン
おすすめはこっち
セッション情報
複数テナント同時ログインがあるならこっち
●パフォーマンス改善
・CloudWatch Logs Insightsで分析
処理時間、クラス名、メソッド名、テナント識別子、リクエスト識別子
・重たいAPI
-> ロードバランサでパスベースルーティング
・特定ユーザによる資源専有
-> 単位時間あたりの呼び出し数制限、アップロード上限など
後から制限するのは大変
■新しい経路が見つかりました
小田中 育生さん [ナビタイムジャパン]
●ナビタイムジャパン
・slackでも使えるようになりました！
・2001年サービス開始
・湯量課金ユーザ 480万人
・月間ユニークユーザ 5,100万人
●プロダクトのリリースはスタート地点
・カイゼンサイクルを回してビジョンに近づいていく
・重要な順に並べたバックログを上から消化していく
・なぜバックログを消化していくか
最短経路だと信じているから
・バックログの優先順位は気づきで変化していく
・ユーザが多い、歴史があるから
お客様からのフィードバックが多い
●カイゼンを阻むもの
・数多くのユーザ
・数多くのステークホルダ
相反する優先順位
コミュニケーションコスト
・あふれるバックログ
優先順位付け自体が高コスト化
・長い歴史
カイゼンがデグレを生む
●そびえ立つバックログ
・ここを整理して見通しをよくする
・みんなでバックログを積む
自分でつくったバックログは消しにくい
-> ルールを設け、定期的に棚卸し
対応不能、不要になったもの
詳細が把握できない
発行から数ヶ月経過
●デグレを引き起こさない環境を作る
・長い歴史があるとユニットテストの導入が高コスト
-> リグレッションテスト環境を用意して水際で対策
●必要なプロセスを解きほぐす
・内部改善は実施しにくい
プロダクトのアウトカムに直結する対策に負けてしまう
-> カイゼンデーで集中する日
●やるべきこと、やりたいことをどう決めていくか？
・二律背反が伴う
・チームの中で意見が割れてしまうことも
-> インセプションデッキでチームの共通認識をつくる
●ユーザーの声と向き合う
・どの声を聴くべきかわからない
カイゼンが空回り
・狩野モデル
当たり前品質、性能品質、魅力品質
-> どの品質につながるかとセットでバックログを積んだ
優先したのは当たり前品質
●潜在ニーズを探ってログを分析
・声を上げてくれる人の声しか届かない
・10分ずらした再探索が多い
ちょっとずらすと直通がヒットしたり
そのまま出すとユーザーの検索と異なる
UIの変更が必要
事業側の部署は忙しい
-> USMで目線と温度感を揃える
ペルソナ、ストーリー、マッピングをビジネス再度と一緒に
共通の課題認識につながって案件化！
■私のプロダクトは会社組織
新井 剛さん [ヴァル研究所・エナジャイル]
●どんな問題があったのか？
・本業
隣の人、隣の部署は何する人ぞ
目標にないからできない
あっちがボール持ってます
・複雑化する世の中、業務の中で壁を乗り越えられない
・いにしえの企業に存在する圧力
・課題から見えてきたもの
変えたいと思っているチェンジ・エージェントはいる
コミュニケーション、期待マネジメント
バックログの優先順位、振り返りが回ってない
●どんなことをやったのか？
・組織開発
ふりかえり、見える化、タスクボードなど
基本的なことをやっていくことが大切
->カイゼンジャーニーに書いてありますw
・カイゼンエバンジェリスト
組織全体のスクラムマスター
開発・バックオフィスでカイゼン
・チームづくりを支援
価値観ババ抜きに 90/160 が参加
全社で 2,793時間 LT短縮
モブワークで効率が 20%以上UP
・WEB+DB PRESS Vol.111 見える化大作戦
●どうやって人を見つけようか？
・社外の方々から
イキイキと働いている
内部からは気づけない
・44期目の縦割りの会社
リベロの役割が重要
チームのメンターとして動いていく
・リベロは様々なところで存在する
SoE/SoRガーディアン
ScrumMaster
SoSo...SM
・直接評価をしないナナメの関係
お互いに心理的安全性
専門職ではむずかしい
・貢献行動ができる人
奉仕貢献に重きを置く人
・キャリアアンカー
40の質問で8分類
10年前と先週でほぼ同じ結果だった
SVがMaxの42！
●私のWHY
・私達が必要なくなったときに一番やりがいを感じる
・社員の夢を実現するのがマネージャー
・他人の幸福の中にこそ、自分の幸福がある
組織を開発していくことが私の仕事
■プロダクトオーナー2.0
市谷 聡啓さん [ギルドワークス・エナジャイル]
●アジャイル開発は2度失敗する
1. アジャイル開発の週間をチームで身につけること
2. 開発チームとプロダクトオーナーの間に生まれる境界線
※アジャイル開発に挑戦するときは3機用意しましょうw
●プロダクトづくりの不吉なにおい
・POが何をしていて、どうやってPBLをつくっているのか
開発チームが知らない
-> スプリントの空振り
●プロダクトオーナーに求められること
・プロダクトがどうあるべきかの牽引
・チームとの協働
・プロジェクトを遂行する
・開発メンバーとの意思疎通
※108コあったw
●理想的なプロダクトオーナー
・都合の良い概念
・ずれたまま進めても 間違ったものを正しくつくる状況
-> 開発チームからPO側への越境
●POの役割をチームで補完
・プロダクトデザイナー型PO中心
ビジネスモデルが手薄
・ビジネス推進型PO中心
デザインが手薄
●伝統のモメンタムがかかりやすい組織といえば、霞が関
-> 経産省のシン・ミラサポ プロジェクト
利用者に伝わっていないのでは？
-> リニューアル
アジャイルに進めたい
・スライドは公開してます
●現実のPOはソフトウェア開発がほぼ初めて
-> プロダクトオーナー代行
仮説検証を実施しているから実現できる
誰よりも想定ユーザーのことを理解している
・正しいものを正しくつくるに書いてます
●プロダクトオーナー代行の遂行と責務
・POも正解を持っているわけではない
・仮説検証を実施、学びをチームで分かち合う
・ドメイン知識の補完はドメインエキスパートに頼る
・実質的には PO代行≒PO
PBLの詳細化と受け入れ
開発チームとPO代行
スプリントレビュー
PO代行が進行
●プロダクトオーナーの民主化
・PO代行は、便宜的な役割
・仮説検証での学びからプロダクトの基準をつくる
-> 学びをチームへ宿す
・ステークホルダーを含めて多様なメンバーが揃っている
これらのメンバーに仮説検証での学びがあったほうが良いものができる
・役割による調整 から 仮説検証の学びから共創へ
ともにつくる
■感想
テクノロジーの進歩とともに変わってきた環境や価値観。それらを追って変化してきたビジネスモデル。ビジネスモデルの変化とともに求められるようになった仮説検証や価値提供のスピード。それを実現するために必要となる組織のあり方や文化。その組織を成り立たせるヒトの考え方や価値観。ヒト同士のつながりがまた新たな流れを生んでいく。どこまでも加速し続けるサイクルの中で試してきた経験をたくさん聞かせていただけました。
・提供する価値へのヒトの思い入れやワクワク感が原動力
・まわりのヒトへの共感と尊重、そこから生まれる文化
・共感は、それを体験しなければむずかしい
・ここから生まれる活動もマクロから見ればシステム
・変化は加速し続けるが、加速度にはレイヤがある
などなどたくさんの共感と学びをいただきました！
登壇者の皆さん、運営の皆さん ありがとうございました！！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。