はじめに
本稿は、デブサミ2020夏(Developers Summit 2020 Summer)のセッションを視聴して学んだことのメモです。
各セッションで学んだこと
C-1 Outcomes over Output: Productivityの高い組織への変革
Enginering組織の生産性を可視化する
これを実現するのは難しい
そもそも生産性とは
お客様が価値を認めて使うもの
究極の計測値としてはKGI(Key Goal Indicator)を上げるもの
Output(作ったもの)よりも Outcome(成果)に目を向けることが重要
プロダクト開発の2つの不確実性
検証と学習のサイクルによって、目的不確実性と方法不確実性を継続的に下げることが重要
目的不確実性を下げる
小刻みなリリースで、お客様に価値があるか検証する
KGIとKPI候補の例
- 利用者数
- 出品数
- 購入数
どの新機能がどの指標に影響を与えたのかが分からないという問題に対して、A/Bテストで一部のお客様に見せて指標がどう変わるか検証する
新機能を一部のお客様に見せた結果、指標が悪化した場合は、その機能はリリースしない
A/Bテストの注意点
- 初頭効果(Primacy Effect)
- なれるまで指標が悪化する
- 新規性効果(Novelty Effect)
- 目新しい機能は特別な理由なく触ってみたくなる
方法不確実性を減らす
デリバリのパフォーマンス指標を使うと良い
- Lead time (for changes)
- Deployment frequency
- MTTR (Mean time to restore)
- Change fail percentage
以下の特徴を持つトイルを洗い出し、解決する
- 手作業
- 繰り返される
- 自動化が可能
- 戦術的、長期的な価値がない
- サービスの成長に比例して増加する
組織の変革のためには、継続的な改善の繰り返しが必要
所感
Output(つくったもの)よりも、Outcome(成果)に目を向けて、効果が大きく見込める部分を改善していくサイクルを回していくと良さそうだと思いました。
A-2 GCP を支える Google のソフトウェア開発環境に見るマイクロサービス設計のヒント
マイクロサービスとクラウドインフラの関係
GCPのコンセプト
- Google社内のソフトウェアエンジニアと同じ技術・環境が使えるというコンセプト
マイクロサービスによるシステム設計には、以下が必要
- アプリケーションデザインの知見
- クラウドインフラの知見
なぜマイクロサービスが必要のか
システムアーキテクチャに求められること
- 変化に追従できることが最も困難で重要
- ソフトウェア開発者・システム運用者の生産性を最大化する
マイクロサービスとは、強調して動作する、小規模で自律的なサービス
変化に追従するための基本原則として、単一責任の原則の考え方が参考になる。
マイクロサービスのメリット
技術異質性
- マイクロサービスごとに異なる技術で開発できる
部分的スケーラビリティ
- 必要な部分だけをスケールさせることができる
耐障害性
- 自律的サービスは、他サービス停止の影響をうけない
デプロイ容易性
- サービス単位でデプロイメントができる
標準化された開発ツール・プロセス
Googleは、すべての業務・システムにマイクロサービスを利用している
単一リポジトリによるソースコードの管理
- すべてのプロジェクトのソースコードを1つのリポジトリに保存
- プロジェクトごとにディレクトリを分けて管理
- リポジトリを分けてバイナリをコピーすると、どのプロジェクトがどのバージョンのバイナリを利用しているかという管理が大変
- 他のプロジェクトの機能を利用したい場合、そのソースコードをインクルードしてビルドしている
- 基本的に、ブランチを持たない開発ツリーでTrunk/Mainlineに直接 新機能をコミットして、リリース時にリリースブランチを分ける
一度のコミットは小さくして軽量なコードレビューを実施している
所感
すべてのマイクロサービスのソースコードを、単一リポジトリで管理しているのは、驚きました。
それをやるには、Trunk/Mainlineに直接 新機能をコミットする際に、しっかりテストが通った状態で、レビューしやすいように小さい変更に分けてコミットする文化が必要だと思いました。
C-4 週一でリリースし続けるための、フロントエンドにおける不確実性との戦い方
将来的な変更容易性を
同じものを同じ目線で認識するためにチーム共通の言語を作る
開発する上で何を優先するかを決める
開発はすべてモブプロ
開発中に最初に打ち合わせて同期した内容からずれてくる
リカバリーが効くタイミングで再度ユースケースを関係者で確認する
クリーンアーキテクチャでいうところのUsecaseを中心に開発する
エラーイベントと改善
ブラウザのエラーで何が起こるか把握する
リリース後に気付くエラーは色々あるので、それらのエラーに対してユーザーに分かるようなエラーを表示するように直していく
所感
モブワーク中心で、チームで意思決定しながら開発していく点は、素晴らしいと思いました。
重要な認識を関係者で共有するために、POも含めてモブワークしている点は、興味深かったです。
あと、皆で向上させたい指標を共有するという意味で、売上も皆で共有している点も良いと思いました。
A-5 Amazon/AWSの安全で自動化されたContinuous Deploymentsへの道
Amazon/AWSのデブロイメントパイプライン
Source => Build => Test => Production という流れ
Testは、複数種類のテスト環境を行っている（Alpha, Beta, Gamma）。後のテスト環境ほど大掛かりな検証を行う。
Productionでの運用環境へのリリースも、段階的に行っている。問題なければリリース範囲を広げていく。問題あればロールバックする。
デプロイが信頼されていれば、メインブランチに変更をマージしたら、開発者はその後のデプロイを気にしなくてよくなる。
デブロイメントパイプラインを信頼するためのアイデア
自動的にメトリクスを監視してロールバックをする
金曜や夕方以降はデプロイを開始しない
コードレビューは、手作業で行う最後のプロセス
プルリクに、テストが含まれているかんど、チェックリストのテンプレートを作っている
AWS CodeDeploy を用いて自動ロールバックを実現している
デブロイプロセスの段階的な改善
最初は、デプロイプロセスのリードタイムの平均は約16日だった
パイロットチームで少数のチームで単一のデブロイモデルを作った
各チームがパイロットチームのデブロイモデルを主体的に採用した(トップダウンの押し付けでなく、ボトムアップ)
所感
パイプラインを信頼できる状態になると、開発者がデブロイを気にしなくてもよくなるため、その分、開発にリソースを集中できるようになると思いました。
B-8 リモートワーク×Employee Experienceでつくる ～with コロナ時代の「Work fun! Management」とは～
Work
どうせやるなら楽しく！
遊びに真剣になれるヤツは仕事も楽しめる！
仕事の目標の評価について、リモートワークでなんとなく見えていた部分は分からなくなってきた
仕事を主体的にやってもらうためのアプローチ
- 本人に合わせた腹落ちする説明
- 本人が決められる
Fun
なぜやるかを自分で決めると、「やりたい」という気持ちになる
そのために目標を設定する
Management
Goalに向かって、中間の目標を達成させていく
目標設定の仕方
- 主題：有意味性を伝え、本人が選択
- 副題：なぜしたいのか、誰をどんな状態にしたいのか、本人の言葉で表現する
- アクションプラン：いつまでに何をするか、論理的かつ実現可能なプラン
- 達成の定義：どのような状態を達成とするのか
運用5箇条
- 目標設定は時間がかかるものである
- 目標設定はいつでも追加・修正してよい
- 達成できたら素晴らしい、できなかった分析する
- 進捗管理をするのではなく、障害を取り除いてあげる
- 節目でFBを得られる機会を必ず設ける
所感
目標設定において、大切なのは仕組みではないと思いました。
マネージャーは、一人ひとりの気持ちと向き合って、その想いを汲み取ってモチベーションを高めさせながら実施することが重要だと思いました。
あと、目標に対しては、進捗管理じゃなくて、障害を取り除いてあげるの大事というのは、大事と思いました。
まとめ
デブサミ2020夏は、とても学びになりました。
ちなみに、私はLT初心者が集まるコミュニティとして「Serverless LT 初心者向け」というコミュニティを運営しています。
Serverless LT 初心者向け - connpass
Twitterでも開発に役立つ情報を発信しています → @kojimadev