イベント概要
開催日：2023/7/14 Fri.
開催場所：オンライン or Google渋谷オフィス
アーカイブ動画
タイムラインは上記のリンクから参照ください。
基調講演 and Track1
Track2
サミットに関連するラーニング
興味深かったセッションまとめ
オープニングトーク
オープニングトークでは、Googleの新サービスやGoogle内部のこと、GoogleCloud Platformの概要説明等していました。
その中でも興味深かったのは、GoogleはエンジニアランクをElite, High, Medium, Lowでレイヤーで分割して行動を観察していました。以下がレイヤー別の行動分析です。
| ソフトウェアのデリバリーパフォーマンス指標 | High - 11% | Middle - 69% | Low - 19% |
|---|---|---|---|
|
デプロイ頻度 あなたの取り組む主要なアプリケーションまたはサービスでは、コードを本番環境にデプロイしたりエンドユーザーにリリースしたりする頻度はどれくらいですか？ |
オンデマンド （一日数回） |
週に一度〜月に１度 | 月に一度〜半年に一度 |
|
変更のリードタイム あなたの取り組む主要なアプリケーションまたはサービスでは、変更のリードタイム（コードがコミットされてから本番環境で正常に実行されるまで）はどれくらいですか？ |
1日〜1週間 | 1週間〜１ヶ月 | １ヶ月〜｜半年 |
|
サービス復旧にかかる時間 あなたの取り組む主要なアプリケーションまたはサービスでは、ユーザーに影響を与えるサービスインシデントまたは血管があった場合、一般的にサービスを復旧するのにどれくらい時間がかかりますか？ |
１日未満 | １日〜1週間 | 1週間〜１ヶ月 |
|
変更による失敗率 あなたの取り組む主要なアプリケーションまたはサービスでは、本番環境またはユーザーにリリースされた変更の何%が復旧の必要なサービスレベルの低下（サービスの障害またはその停止につながる事象）をもたらしますか？ |
0~15% | 16~30% | 46~60% |
Source: 2022 State of DevOps Report
https://cloud.google.com/devops/state-of-devops?hl=ja
よくプルリクエストなども細かくしようと言われていますが、その通りで細かくアウトプットすることで変更リスクに耐えることができるのですね。
AI / GenAI系ツール
個人的にあまり馴染みはなかったのですが、Google Cloud Workspaceの中限定で活用できるAIも発表されました！
Track Sessions
まとめ① モダンな業務アプリケーションを内製開発するための手引き
冒頭で、コロナ禍や令和になってから、時代の確実性や連続性が絶たれ、不確実で変化の早い情勢になってきている。AIの登場により、その変化はますます大きいものとなっているとのこと。
その時代の中で、リーン＆アジャイル開発手法はとても重宝されるものである。
しかし、アジャイルで勘違いしていけないものとして、以下の有名な図がある。
アジャイル開発として、大きいものを最終的に目指すのは同じであろうが、細かにカスタムして徐々に大きくしていく手法をとらなければならない。図の上の例でいうと、根本的に設計が間違えていた場合や、要求が変わっても修正するコストが膨大になってしまう。（下手したら手前のスプリントが全滅になってしまう）
内製開発を行うエンジニアに求められるスキル
ビジネス理解
- 自社のビジネスの理解
- 将来を見据えた設計
- 業界知識
- 優先順位付け
etc...
技術スキル
- コーディング
- プロトタイピング
- クラウド知識
- あーきてくティング
etc...
特に素早い開発をするために、GCPは以下のサービスが提供できる
そのほかにも、
- Cloud Build, Cloud Runを用いたCICDパイプラインの構築
- Identify-Aware Proxyを用いたユーザーアクセス制御
- Cloud loggingによるインシデントの検知
などもあげれらていました。
まとめ② Tech Writingで開発効率を上げる
質の高いドキュメントは開発体験を上げる！
はい、間違い無いです。
私もいろいろなプロジェクトで設計が不十分であったり非エンジニアとエンジニア間の知識のギャップにより認識齟齬が発生したりと苦労した思い出があります。
有名かもしれませんが、Googleはドキュメントを書く際に「Tech Writing」と「Design Doc」という方針を持っています。
質の高いドキュメントを作成しているチームは、そうでないチームと比べて開発効率が2.4倍程度高い結果がある
同じプロジェクトではないのでどのようにして計算したか不明瞭なのですが、2.4倍は凄いですね。
今回ここでいう「質の高いドキュメント」は以下のように定義されていました
- 読み手の目的を達成できる
- 正確かつ最新である
- シンプルで読みやすい
- 見つけやすく整理されている
確かに、「見つけやすさ」は蔑ろにされがちかもされません。
経験したプロジェクトでも、「だいたいここにはあるんだろうなぁ」とはわかるものの、開いてみたら200ページ以上もありそこから探すのも一苦労した苦い思い出があります。
Design Docsのメリット
- 設計上の問題を早期に特定できる
- 組織内の設計のコンセンサスを得られる
- 横断的な懸念を確実に考慮できる
- エンジニアの知識を組織内に浸透できる
- 過去の設計や意思決定、その背後にある思考プロセスを記録して後から思い出せる
読者を明確にすること
- 読者を明確に定義する：読者の役割や既存の知識を理解することが重要
- 何を求めてドキュメントを読むか？
- どんな時にドキュメントを読むか？
- 何を知っていて何を知らない？
- どうやってドキュメントを探す？
- 読んだ後にどんなアクションをする？
- ドキュメントの範囲を定義する：何を書いて、何を書いてないかを定義する
- 知識の呪いに注意する：自分が知っていることは相手も知っていると誤解してしまう傾向に注意する
その他、Tech Writingで意識すべきポイント
- 用語は一貫して使用する
- 曖昧な代名詞は避ける
- 受動態は避け、脳動態を優先する
- 曖昧な動詞より具体的な動詞を選ぶ
- 各文を一つのアイディアに集中させる
- 順序が重要な場合は番号付きリストを、順序が関係ない場合は箇条書きリストを使用する
- リスト項目は並列にする
- 番号のついたリスト項目は命令後で始める
- リストや表を適切に紹介する
- 段落の中心点を確立する素晴らしい冒頭文を作成する
- 各段落を１つのトピックに集中させる
- 読者が何を学ぶ必要があるかを判断する
- 文書を読者に合わせる
- 文書の冒頭で、文書の重要なポイントを確立する
Design Docに関する記事
以上です！
今回まとめてないセッションもあるので、気になった方はアーカイブ動画を参照してください。