aslead Agile のチーム「オキザリス」にて参加してきました。
個人的な感想も含め感じ取ったことを書いています。
発表者1
Zucksの南大津さん
こんな経験ありませんか？
アプリケーション開発とインフラ運用をそれぞれ専門の別チームが行っている。
- 開発を進めるのに運用チームの対応待ち
- アプリの特性や変更点を把握していないと適切な監視が難しい
↓
専門化された役割を持っていることにより効率的なソフトウェア開発ができていない？
→フルサイクル開発者が１つの解決方法になるかもしれない
フルサイクル開発者とは
2018年Netflix
ソフトウェアサイクルのすべてを一人の開発者が担う
デプロイパイプラインやモニタリングツール等を使って負荷を下げる
コミュニケーションコストやボトルネックを削減
→顧客に迅速に価値を届ける
フルスタックエンジニアとの違い
- フルスタックエンジニア
- 技術領域にフォーカス
- 幅広い技術領域
- フルサイクル開発者
- 価値を迅速に提供することにフォーカス
- そのため、ソフトウェアライフサイクルのすべてを担当sるう
Zucksにおけるエンジニアリング
大事にしていること
- 圧倒的スピードで価値を届ける
- 変化の激しい業界
- 時間がかかると必要なものの形が変わる
- 本当に必要なものを見極める
- ビジネスサイドから支持されたものをただ作る、というスタイルではない
- エンジニアが事業背景や課題を理解
- 最強の裁量を与える
- 技術選定や付与する権限
- すべてを自分自身で進めていけるように
- 失敗から学ぶ
- 失敗を恐れ挑戦しないことはリスク
- 失敗から得た学びを次に活かす
- 致命的な失敗は避けるような工夫はする
Zucksとフルサイクル開発者
大事にしていることをより良い形で満たそうとした結果フルサイクル開発者と同様に形になった
フルサイクル開発者、という単語が先行していたわけではない
フルサイクル開発者のプラクティス
当事者と直接対話する
- 課題を感じている当事者に直接話しを聞き、背景や課題感を理解する
- 実際の作業を横から観察したりもする
- 当事者も本当に欲しい物がわかっていないことがある。
- 一緒に本質を捉えた解決策を考える
- 解決できるなら開発をしなくてもいい
小さく試して小さく失敗する
- 顧客に価値を届けるスピード感
- 手戻りを小さく
- 早くフィードバックを得ることでサイクルも早くなる
- 進捗も実感しやすい
- 失敗から学ぶ
- 失敗しないことより元に戻せることを重視する
- レビュアーに負担を書けない
- 失敗には気付けるようにする
- 必要ならモニタリングの仕組みも合わせて整備する
適度な自動化
- 繰り返しやることは必要に応じて自動化
- テストやデプロイはCIサービス
- ローカル環境構築はDocker化
- タスクランナーとしてMakefile
- ソフトウェアライフサイクルを早く回せるようになる
- 自動化＝コード化されている
- ドキュメント代わりに
- 完璧な自動化を目的にはしない
- ソフトウェアライフサイクル全体をみて効果的なところを自動化
全員admin
- 開発者全員がAWSの管理者権限を持っている
- 他の外部サービスも同様
- 依頼が不要となり、オーナーシップを持ちやすくなる
- 権限のせいで視野を狭めさせない
- 自分の権限でできることにフォーカスしてしまうことにつながる
- 事故防止の工夫
- 最低限の制限をかける
- 削除保護の有効化
- MFA必須化（CLI含む）
- モニタリングする
- サービスメトリクス
- コスト
- 不審なAPIコール
- 復旧しやすい環境
- インフラのコード化
- サーバレスの活用
- 最低限の制限をかける
- 初日リリース
- 配属初日にリリースをする
- 新卒入社も中途入社も
- 顧客に価値を届ける体験
- 環境が整備されている状態を保つ
- 誰でも１日以内に価値が届けられる環境
- 詰まったことがあれば記録しておく解決していく
- 配属初日にリリースをする
南大津さんまとめ
必ずしもベストプラクティスではないが
- フルサイクル開発者として、圧倒的スピードで価値を提供
- 新しいメンバーでも配属初日からプラクティスを実践してもらう文化
- 本質を追い求めていくことが大事
=========================================================================================[]
=========================================================================================[]
発表者２
メルカリ 古澤さん
フルサイクル開発と組織のエッセンス
レコメンデーションチーム所属
今日の話
ターゲット：フルサイクル開発の導入を検討している会社のリーダー
ゴール：効果的なフルサイクル開発を進めていくための組織的な土台を理解する
フルサイクル開発
Time to value（アイディアが実際にプロダクションで動くまでの時間）を最短する
ポイント
- チームが全開発工程に責任を持つ
- フィードバックと学習の効率化
開発チームがドメインの権限と責任を持つことでよりスピーディーにリリース
フルサイクル開発実現の困難：開発者のスキル問題
今回は組織体制をどうやって構築していくかにフォーカスする。
Q:チームがすべての開発工程に関する適切なスキルを持てば、フルサイクル開発はワークするか？
A:組織的な土台が必要
そもそも会社組織は中央集権的
フルサイクル開発はチーム起点で物事を進めていくチーム中心型組織となる。
チーム中心型組織とと中央集権型組織はときにコンフリクトする
→フルサイクル開発チームと会社組織の共存共栄を目指す。
共存共栄に向けて：組織間の信頼関係構築で権限を移譲
チームスキル・マインドセット、チームアイディアを高め、それを会社組織との共通認識とする
特にアイディアに関して、認識のズレを発見して齟齬を解消し続ける必要がある。
- 認識のズレを見つける
- 情報の収集：1on1、社内チャットのコメント
- 認識齟齬を解消し続ける
- コミュニケーションの場を設定：1on1、ドキュメント作成
↓
フルサイクル開発チームがやっていることが会社の価値と合致する。
→共通認識の形成を通して、より自由な開発を実現
アイディアの確実性を高める：経験主義的アプローチ
-
アイディアの良し悪しは実際にプロダクションで検証されるまでわからない
-
初期のチームアイディアが実際に勝ちがあるかは不確実性が高い
-
経験主義的なアプローと
-
定性データの活用
-
定量データの活用
UX Research
PMやデザイナーと共に調査計画を作成し、モックなどを元に実際にユーザへのインタビューを通して評価する
お客様の声
CSチームが提供しているダッシュボードから顧客の声を確認
オンライン実験：実験デザインドキュメント
実験設計の統一フォーマットを元にいjっけん設計を行い、仮説や検証方法をクリアにして実験の質を高める
- 学びの最大化
- 学びの蓄積・参照
- 実験品質の担保
KPIモニタリング
担当している昨日や関連数r昨日などの長期的なトレンドを確認するために、
ダッシュボードを作成し異常がないかをモニタリングしている
- 異常検知
- 関連機能含めた状態把握
- レコメンド⇔検索
チームアイディアを高めることでフルサイクル開発が加速する
変わったこと
- リリースコントロールはチームが行う
- 以前はPMのみが保持
- 承認ボトルネックの解消
- バックログの優先度はチームが決める
- 以前はPOが決定
- チームが優先度を決定
- 関係性が出来上がっているので、POとチームメンバーがやりたいことが一致する
- 意思決定のスピードが上がる
開発のライフサイクルが加速して学びも価値も得られた
フルサイクル開を導入したい人へ
内容は必ずしも一般的ではないかもしれない
- スキル的背景
- 社内で一定程度スキルが有るメンバーが集まってチームが発足
- 組織的背景
- 会社組織との信頼を構築するまでに半年～１年位
フルサイクル開発どこから始めたらいい？
- 組織感での共通認識形成
- チームアイディアの確実性を高める
古澤さんまとめ
- フルサイクル開発導入のため組織的土台を作る
- チームアイディアのブラッシュアップをしていく
発表者３
みらい翻訳 山口さん
「さぁ、フルサイクル開発をはじめよう」
フルサイクル開発との出会い
ある社内ミーティングで「今日から皆さん、フルサイクルエンジニアです」
どうやら「フルサイクル開発」というものがあるらしい
フルサイクル開発とは
一番気になっていたこと
- フルスタック：技術レイヤーの上からしたまでカバー
- フルサイクル：ソフトウェア開発ライフサイクル全体
ちょっと待て、それは無理
教えて偉い人
Netflixによると「フルサイクル開発者はソフトウェアライフサイクルのすべての分野において知識があり、効果的であることが期待される」
→個人でフルサイクルを担う必要はない。重要なのはチームでフルサイクルを回せること。
みらい翻訳はなぜフルサイクル開発をしようとしたのか
ここ２年ほどで急速にサービスが売れるようになった
フィードバックも多くいただけるようになった
↓
要望・フィードバックを元に開発を加速させたい
現場：DevとOpsの分断
リリースをインフラチームに依頼していた。
- 通信キャリア並みのガチ品質を求める文化
- ガチガチのマニュアル手順による作業
- 。。。
求めるスピード感とのギャップが大きすぎる
問題解決のためにはじめたこと
- リリースを開発チームに移管
- SREちーむを結成
リリースまでの期間：１ヶ月→最短１週間程度
リリースのハードルが下がった。
さて改善はできた、が
Devがリリースをする状態になっただけ
今取り組み始めている課題
- DevとQAの分断
- Dev-QAの依頼関係によるQA長期化
- 伝達コスト
- 手戻りが大きい
- 取り組み：開発プロセスにQAを融合
- QAメンバーを開発チームの一員に
- 開発初期からE2E自動化
- 伝達コストと手戻りのリスク逓減
- Dev-QAの依頼関係によるQA長期化
- 開発チームの負担増大
- りりーすばかりやってる
- 手作業、確認作業が多い
- 共有リソースに起因したリリース順序の調整、変更の取り込み
- ビジネスとDevのリリース日程調整が難航
- 取り組み
- モノリシックアーキテクチャの刷新、マイクロサービス化
- デプロイとリリースの分離
- Feature Flagsの仕組みを使いデプロイをリリース日の前に実施可能にする
- りりーすばかりやってる
- 最上流と最下流へのアプローチ
- PdMとサポートがチーム外にいる
- PdMチームが別に存在し複数開発チームを兼務
- 開発とサポートの情報格差による回答速度、コミュニケーションコスト
- 取り組み
- 開発チーム内にPdMを配置
- 自律的なチームを構築
- エンジニアも企画・要件定義を行う
- 開発チーム内でサポート対応も行う？
- サポート担当をチームの一員にして連携強化
- 開発チーム内にPdMを配置
- PdMとサポートがチーム外にいる
どうすればフルサイクル開発になるのか？
各課題はフルサイクル開発を意識しなくても直面するものでは？
業務／昨日スコープを明確にするのは大事
Netflixと同じレベルでやろうとしなくてもよい
考え方を理解した上でチームに合ったフルサイクル開発の形を作っていければよい
感想
- 指示されたものをつくるだけでなく、課題の本質に目を向けて解決策を考えるというのは大切な意識だと思いました。
- 経験主義的なアプローチや、「早く小さく失敗する」というのはスクラムと相性が良さそうな進め方だと思いました。
- 未経験な領域でも少しずつ失敗を繰り返しながらできることを増やしていきたいと前向きになれるような発表でした。