デブサミ2020参加メモ Day2
この記事について
イベント参加直後の自分の思い出す用メモとして残しているため、整理できていなくて散らかった内容になっていると思いますが、ご了承ください。
当日の僕のTwitter実況タイムライン twitter.com
1日目の記事 nabless.hatenablog.com
チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜
www.slideshare.net
- 市谷さんのお仕事
- この1,2年、DX支援が増えてる！
プロダクト開発で直面する最大の課題は？
- 不確実性との戦い（組織変革でも不確実性はある）
- わからない中でも前に進むためには？
- 「これだけやればいい」ということはない
- 何を作る？どうやってつくる？絶対的な正解がない
- 意思決定、合意形成が容易でない
- 色んな手法があるが、理解不足や練度不足で成果にならない
- 「これだけやればいい」ということはない
- わからない中でも前に進むためには？
なぜか？
→「傾き」の問題
- 変化に求められる傾きが急すぎる（例えばアジャイルが求める変化）
- 「これまで」が引き寄せる重力を突破できない！
- 「これまで」「新たな」の分断が二項対立世界を作る
- 「これまで」が引き寄せる重力を突破できない！
「これまで」と「新たな」の格差を残り越えるためには
「段階」の概念を取り入れ、滑らかにする
WF と Agileの二項対立が招いたもの
全体性の欠如
- 少しづつ繰り返しながら形作る
- これで全ての粒度の話を解決するには無理がある
段階の設計とは
- 到達したい目的地を見立て、たどり着くために必要な状態を構想する
- 分かったことに基づき、構想自体を変化させる
- 各段階の青写真は、当事者に方向性を与える
段階 = ジャーニー
- チームのジャーニーも丁寧に設計しないと失敗する
- 傾きが急勾配にならないように
- ジャーニーは重なり合う
- 例
- DX、プロダクト、チームのジャーニー
- 例
- 「意志のある進化」を仕組み、その上で変化に適応していくことが必要
どのようにしてジャーニーを運用する？
- リーン・ジャーニー・スタイル
- セットベースで選択肢を広げ、ポイントベースでアウトプットを結実
- 選択肢を広げるため多様性を利用
- 段階の設計によって、経験による学びを踏まえた当事者の意思決定を着実に形に（わからないなりに決め、形に）
- 変化への適応性を確保するため、ミッション、フォーメーション、チームの主義を動的に選択
- 仮説検証にも段階がある
- POの解釈を一方的に伝える
- 仮説キャンバスで外在化、可視化 → 誰でも表明できるようになる
- POの視座をプロダクトの上限（ボトルネック）にしない
- 不確実性に立ち向かうためには、チームや関係者から「考える」ということを奪ってはいけない
- 仮説は、チームみんなが持ってよい
- そのためには練習が必要
- チーム or POをどうやって仮説検証に巻き込むか？
- 仮説検証のゴールデンサークルを確認したあと、段階的に取り組む
固定的な役割を中心とした「調整」から 仮説検証による学びを中心とした「ともに」へ ↓ そのためには、お互いの関係性に意味をみつける
「我々はなぜここにいるのか？」
自分自身のミッションと役割を問い直し続ける必要がある
専門性を磨くことは必要だが、「私の役割はデザイナーです！」「プロジェクトマネージャーです！」と役割をおいていては不確実性の高いプロダクト作りには対応できない。
専門性を捨てろということではない。もっと解像度の高い捉え方をする必要がある。
エンプラアジャイル導入の守破離
エンプラアジャイル導入のよくある失敗のお話
開発体制
- バランスチーム
- デザイナー（ユーザ）
- エンジニア（技術）
- プロダクトマネージャー（ビジネス）
- 一緒になって開発に臨んでる
ペア作業が基本になってるのは面白い
アジャイル導入の際、どんなことが起きやすいのか？
- 導入体験談（実話ベース）
- よくわかんないけど、上から落ちてきて何かはじめることになった
- → 予算がないから本やネットで調べてやってみる
- → 本の通りにやるのって簡単じゃない…
- → いつのまにか期待値が上がりすぎている
- → アジャイルが周囲に理解されない
アジャイル導入のポイント
- 早くはじめる
- 価値が出て社内に信頼されるまでのチームを守るコミットをする
- 失敗を許容できるセットアップではじめ、成熟に合わせて負荷を高める
- 進め方に絶対な解はない
スケールって、1チームでうまく行ったことを単純そのまま適応すれば確実に成功するってものでも無い（チームによって構成も、問題も、考え方も異なる）ので難しいなぁって思ってる
厳しいスコープの定義（優先順位付け）で無事リリース
これはつまり、優先順位付けしたうえで、低いものはスコープ外にするジャッジを行えたってことですよね。 そこが結構難しい組織も多そう。何かコツあるのかな？
完璧な理想に固執せず、戦略的かつ前向きな妥協
時間・予算をどっかんどっかん投入
時間的リソースをどっかんどっかん投入できるのは羨ましいなぁ けどやっぱり、それをできない組織の方が多い疑惑はある
全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、“ルール駆動開発”
ルール駆動開発
- ルール
- 業務ルール
- ビジネスルール
- ビジネスロジック
- 業務ルール
レガシーなシステムのリニューアルで良くやること
- 現行コードの解析
- これをやめるべし！
- Why?
- 現行コードは継ぎ足し継ぎ足し、秘伝のタレ状態（その場しのぎの改修、冗長なコード）
- 不要なゴミコードの山（不要かどうかはコードから不明、ゴミの移行に時間とお金を掛けることに）
- Why?
- これをやめるべし！
知りたいことは業務要件 = 業務ルール
- 業務を知ってる人に聞く
- 全部までは無理、知ってるところを少しだけ
- 誰でも知ってる基本的なルールから
- 業務マニュアルとかあるよね
- ヒアリング内容はDMNで整理すると良いよ！（業務ルールの国際記法）
一連の業務ルールをサービスとして切り出す
- ルールとデータアクセスを分離することで…
- ルールのテストがしやすくなる！
- 改修時の影響範囲が狭まる！
- DB構成の変更影響を受けにくい！
- ルールも、小さく作ってテストを繰り返しながら育てていく
- 誰でも知ってる基本ルール
- 不一致箇所を調査、ルールを追加
正しいルール駆動開発とは…
- システム担当と業務担当が協同で行う
- 現行コードは見ない
- 業務担当が理解できる形で実装
- 幹となるルールから抽出
- テスト、レビューを繰り返しながら品質向上
ルール駆動開発をすることで…
- 現行コードではなく業務ルールからのアプローチで無駄を省く
- 最新ルールが常に可視化される
- スパゲティ化を防ぎメンテナンス性向上
- 実装テストをくりかすことで品質向上
サイン会
チーム・ジャーニー作者の市谷さんにサインを頂いた！ ありがとうございます。
プロダクトを10年運用するチームをつくる
普段Twitterでよく見るだいくしー (@daiksy) | Twitterさんというのを知って衝撃
プロダクトを10年運用する極意
- 動いているシステムに触るな！
システムを更新し続ける前提
- CI/CDの整備（テスト自動化、デプロイ自動化）
- 監視の整備
- DevOpsの構築（開発と運用の融合、SREing）
人が入れ替わることで、人固有のプロダクトに関する知識が失われる。では何をすべきか？
- ①スキルマップ（チームを維持する為に必要なありとあらゆる項目）
- 効果
- スキルバランスの可視化
- リスクを事前に察知できる
- チームから失われた知識に気付ける
- 学習目標の指針になる
- コツ
- 評価に使わない（心理的〜）
- 他チームと比べない（意味が無い）
- 項目の粒度を気にしない（ちゃんと作ると大変）
- 定期メンテする
- 効果
- ②障害対応演習
- ③式年遷宮（システムのスケールや技術的負債の返済のために…）
- 20年に1回、社殿を建て替える
- 宮大工の技術が失われず継承される
- 壊れてから建て替えると昔ながらの姿が失われるが、ある状態で建て替えれば維持できる
- ソフトウェアでは？
- システムの根幹に手を入れるプロジェクトを定期的に入れる
- 20年に1回、社殿を建て替える
プロダクトを10年運用するチームをつくるには…
- スキルマップ
- 障害対応演習
- 式年遷宮
つまり、スキルトランスファーが適切に行われる仕組みが必要
世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
YourFIT365
- 足を3Dスキャンして最適な靴をリコメンド
- 準備期間：2年間に渡る模索
開発に向けて準備を開始
リリース日が決まっていた！（4ヶ月くらいしかない！）が何したら良いか分からん！
- 先ずは、関係者全員集めて話し合った
- ビジョンと優先度を共有でき、全員の目線があった
- 現場の方も、プロダクト作り（デザイナーの選定、デザイン決定、サービス名決定etc）に関与
- 頻繁にデモをしてフィードバックを貰うことをした
- 自分ごとになっていった
- 頻繁にデモをしてフィードバックを貰うことをした
業務とITを同時に検証
- 最小機能でリリースし、日々のフィードバックを毎週リリースして対応
- 当事者にならない人は不要
話の中ではデザイン選定がありましたが、当事者意識を持てるようにするアプローチがきっといくつかあったと思うので、 「こんなことが効果があった！」「みんなノリノリで参加しようとしていた！」とかをもっと聞きたいな
月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？
（スマホ）アプリの品質とは
- UI
- レスポンス
- 不具合
今回は「不具合」にフォーカスしたお話
- 有名アプリの品質って実際…？
- Storeで星1がめちゃくちゃ多い
- トータルも3.Xくらいでそこまで高くはないものもある
アプリ品質が悪いと、継続率に10%以上の差がでる
- 品質はエンジニアだけに任せている
- エンジニアだけの問題ではない！
- クラッシュ率をKPIにすると良いよ
ユーザの4割は、週一回以上アプリのクラッシュを経験
- クラッシュは、ネガティブな影響がたくさんあるよ！
良くあるデータ取得方法
- データを保存しておいて、起動時に送信
- 起動されないケースもある
- クラッシュを直そうにも、情報量が足りなければそこで試合終了
- 起動されないケースもある
有名アプリってどうやって直してるの？
- 品質を正確に把握
- クラッシュ率をKPIとして設定
- 影響範囲の大きいものから着手
- 直りきらないものは、影響を最小限に留める努力を
クラッシュ率比較：「落ちる」レビューを含むか否か
- 含まない：1.5%
- 含む：7%
大規模アプリはどうしてるのか？
- 段階リリースをすることでクラッシュの急激な増加をコントロール
- クラッシュ率1%を超えたらリリースを一旦ストップ
影響範囲を最小限に留めるためには？
- レビュー依頼は、クラッシュ率が高い時は出さない
- 不具合が分かっている場合は事前にアナウンスしておく（お問い合わせや書かれる前に…！）
- （参考）人気アプリのアップデート回数から
- カイゼンサイクルを高速（週1回）で回すことが重要
- （参考）人気アプリのアップデート回数から
品質品質！と言っている会社の開発体制
キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～
岩切さん
- 計画性のないプロジェクトに自分の身を置きたくない！
- マネジメントってどうしたら良いか？を考えるきっかけに
- Q 日本のビジネスサイドの意思決定・変化への対応力が遅すぎない？
- Q チームっていう時の範囲が狭すぎない？
- マネジメントってどうしたら良いか？を考えるきっかけに
同じ釜の飯を食ってる人に対して無関心であって欲しくない
- BizとDevはKPI共有してる？
- ITだらけのビジネスの中では、開発者もどんどんビジネスに口を出すべき
市谷さん
「自分のハンドルは自分で握れ」 その場その場の環境になんとなくで身を任せるのではなく、自分がちょっとでも「良い感じなのでは？」と思った方向に踏み出せ！ 説明し難いけど、生きてる感じがして、きっと楽しいよ！
- きっかけ
- なんとなくでもやっていけそう。…でも、それで良いんだっけ？
- 当時のデブサミに参加し、「圧倒」された
- これはあかんぞ…！
- 当時のデブサミに参加し、「圧倒」された
- なんとなくでもやっていけそう。…でも、それで良いんだっけ？
- デブサミは、自分と世の中とのDiffを撮るための年一回の場所
- 経緯
- 間違ったものを正しくつくる問題があった
- 「何を作るか」は自分ではない誰かが考えるものと思っていた
- 踏み込んでみたら、誰も正解なんて持っていなかった
- 違うやり方が必要なのでは？
- 間違ったものを正しくつくる問題があった
「正しいものを正しくつくる」
- 正解はない。
- 自分自身を駆り立てるための言葉
- 今よりも良い状況にするためには、問いかけて欲しい
- 「自分は何をする人なのか？」
石井さん
事業承継が大問題！！ 実は日本は、家族経営がめっちゃ多い！
- 良いチームで開発したい
- 技術的負債の解消
- チームマネジメント
- 顧客価値
- PL
- 採用
- 評価
- あれ、これ経営を考える必要あるぞ？
黒田さん
Q&Aコーナー
Q マネージャー・経営者に向いてる人ってどんな人？
- 視座を変えれる人（プロダクトとして、組織として…）
- 色んなことを経験できる
- 視座を変えれる人（プロダクトとして、組織として…）
Q 将来実現したいと思っていること
Q 「ともにつくる」組織・環境にするために、一番大切にしていること、意識していることは？（自分の質問）
- （市谷さん）人の時間を思う。これまでの流れとか。尊重する。
- （石井さん）敬意。
- （黒田さん）歴史。後から入っていきなりロジックツリーで…とかは良くないと思う。
- （岩切さん）引き継げる相手を育てること。健康や心理的安全性にも配慮する。
みなさん言葉はすこしずつ違いますが、同じことを大切にしているように思った。 質問させてもらってありがたい。発言してよかった。
