Googleのエンジニアリング文化とGCPの技術動向
Googleのエンジニアリング文化
Googleのエンジニアは、前提を徹底的に調査する。
・前提を受け入れると何ができるようになるか。
・前提を打破すると何ができるようになるか。
失敗しながら、前提を打破していく ＝ 常識を疑い、常識を打破していく
・データ主義＝データに基づいて、護るべき最低ラインと失敗を許容できるラインを目標設定する
・合理的な文化
・継続的文化＝どのような変化を次に起すかを常に考え続ける
GCPの技術動向
GCP＝Googleのエンジニアが社内で使っているサービスを、社外のエンジニアにも体験してもらいたい。
・Phase1 過去 Google App Engine 2008
アプリケーション開発・動作環境をまるっと提供
・Phage2 現在 個別パーツの提供を開始
まるっとじゃなくて、個別に組み合わせて構築したいという要望が多かった。
・Phase3 未来 Cloud Next 2020 で発表された
GCPを超えたインフラと連携 AWS S3のデータをBigQueryできる。＜Anthosという技術を使って実現可能となる。
その他メモ・感想
Googleのアプリはマイクロサービス化されている。
「常識で考えて無理・・・」で諦めたり迂回するのではなく、常識を超えていくことが、Googleの強さだと感じた。開発に限らず、業種関係なく意識することで自分もGoogleのマインドを身につけられると思う。
大企業でもできる！短期間でプロダクトをリリースするための勘所
スクラムはただの型
・型通りの手法をこなすだけでは、アジャイルな状態にはならい。
・アジャイルを「する」とアジャイルで「いる」は明確に異なる。
MVPを作る
・スコープ（機能）を絞るのが難しい。ステークホルダーへの説明があるから。なぜその機能を削って良いか？を合理的に説明するのが難しい。
・提供したい価値＝サービスコンセプト に直結しないことを削った。
・サービスコンセプトに
直結する機能＝筋肉 必要
直結しない機能＝贅肉 不要
感想
NTTコミュニケーションズのNeWorkは、ZOOMに対抗するために3ヶ月（当初目標2ヶ月）で開発・リリースされたとのこと。エンジニアとして、楽しかっただろうな〜と思った。小さいプロダクトを作りながら、ステークホテルダー（社長や部長、顧客）を巻き込んでいくのは、快感だっただろうなと思った。楽しそうだった。
CTOとして招聘されて1年でDX Criteriaを大幅改善する
DX Criteria とは？
- リードタイム、デプロイ頻度、MTTR（改修時間）、変更失敗率の4つの指標で計る。
- 企業間での指標の圧倒的な差は継続的デリバリやDevOpsへの組織的な投資の差。
- 高速で安全に変更できるのが、エリート組織（＝良い組織）。
参考書籍 LeanとDevOpsの科学
デプロイエンジニアリング
例）before デプロイメントするためにSSH接続してコマンドを手順に沿って実行＞ after マージされたらBotが動いてSlackでポチればデプロイできる
例）before デプロイ前の手動確認項目が多数（それでも最低限のチェック）＞ after Seleniumやアプリのテストビルドでのシナリオテストで自動化
- 1回のデプロイに30分かかっていた＞5分でできるように
- 1人あたりのデプロイ頻度が2〜3倍
- 権限の低い開発者も安全にデプロイできる
- デプロイが面倒なので複数コミットまとめてデプロイというのがなくなった（＝リリースサイクルが短くなった）
まとめ
- ソフトウェア開発組織運営のための「DX Criteria」「LeanとDevOpsの科学」というテンプレを使おう。＞突然CTOになっても大丈夫
- 多くの場合で、デプロイ頻度をKPIにするのが効果的
- 開発者がより高速化つ安全に開発できるための技術はどの会社でも必ず投資すべき
感想
もし自分が企業のCTOになったら、どうやって体系的に自社の技術力をアップしていくか？という方針を得ることができた。CTOになる時は「LeanとDevOpsの科学」を読んでみよう。
デブサミ2021で頻出したキーワード
自動化・アジャイル（SCRUM）・プロダクトマネジメント・DevOps
「テスト〜デプロイを自動化して、アジャイルに高品質なプロダクトを開発する」というのがDev界隈のトレンドであると感じた。
QAの人の登壇が多かった。品質に関して意識が上がってきていると共に、みんな品質向上・確保に苦労していると推測する。
トレンドを感じ取れた良い2日間でした。