この記事について
11/10(金)、渋谷ストリーム5F にある Google 渋谷オフィスにて、オフィスツアー+セッションに参加させていただきました!
当日のレポートを23新卒を代表してまとめましたので、ぜひ最後までご覧ください!
オフィスツアー
Google 社員の方々の案内のもと、社内の見学をさせていただきました。
卓球場、楽器を演奏できるミュージックルームなど、社員が楽しく、リラックスして働くことができる環境が整っているんだな、と感じました!
↓社内にキッチンがあり、料理教室が開催されているのは驚きでした?
こんなユニークなものもありました。その名も「Gboard 物理手書きバージョン」。
(Google に詳しい方ならご存知かもしれませんが)これは Google から毎年4月1日のエイプリルフールに発表されるキーボードです!こちらは2018年のエイプリルフールに発表されたもののようでした。
裏側にどんな技術が使われているのだろう、、と気になり調べていると、どうやら機械学習の技術が使われていたようでした。気になる方は Gboard 物理手書きバージョンの舞台裏を見てみてください!
みんな、興味津々!
オフィスツアー終了後、セミナールームに移動し、パートナーエンジニアの Yusuke さんと、Sho さんから Session のお時間をいただきました。
セミナー会場の様子。おしゃれなフルーツウォーターやお茶、コーヒーを準備していただきました
各セッションのサマリーを下記にまとめました。
Session1 “技術ブログを書くことがあなたにもたらす様々なメリットを1時間で”
セッションのタイトルの通り、技術ブログを書くことのメリットについて、Yusuke さんからレクチャーをいただきました。
- 技術ブログの執筆→対自分・対自社・対社外の3つの側面からメリットがある
- 対自分→自身の知識の整理・テックライティング力の向上
- 対自社→営業資料・顧客への説明資料になる・社内のナレッジ蓄積
- 対社外→技術力の裏付け
- 記事を書く3つのコツ
- 記事の切り出し方に着目→速報・連載系の記事は目を惹きやすい
- キャッチーなタイトルをつける
- 「(サービス名)について」という平凡なものではなく→「分かる!(サービス名)」という具合で工夫を入れてみるのも一つの手
- 記事を書き始める前に、記事の結論とその目的を整理しておく→その後内容を考えるのが、途中で頓挫しないコツ(「書くのが疲れてしまった」となって後半になるにつれて投げやりになってしまうのがよくあるパターン)
- よく言われる「結論を先に話せ」というやつと考え方は似ている
- 同期で Advent Calender やってみるのもいい試み
- こんな感じ で Google Cloud Japan もやっているそう
技術的なアウトプットは大事、とぼんやりとは理解していましたが、改めて話を聞いてみて、整理してみると「こんなにもメリットがあるのか」、と思いましたし、アウトプットをどんどんしていくしかないなという気持ちになりました?
また、Session1 の中で、iret.media タイトルチャレンジ!!と題して、タイトルを考える力を鍛えるワークも行ないました。
Google Cloud 関連以外でもいいので、iret.media に投稿するならどんなタイトルで記事を載せるか、23卒36名で考えました!
みんな、センスのあるタイトルばかりですごいなと感じました!私はなかなかセンスのあるタイトルを考えるのが苦手なので、これから勉強していかないと、と思いました✍️
【23卒が考えた iret.media 投稿記事のタイトル案の一部↓】
Session2 “Google のソフトウェアエンジニアリング”
Google のソフトウェアエンジニアリング(英語版は無料公開)
に基づき、Google のソフトウェアエンジニアリングにおける考え方について Sho さんからレクチャーをいただきました。レクチャーの内容を、【組織文化】【ソフトウェア開発を進める上での6つのポイント】という観点からまとめてみました。
【組織文化】
—「心理的安全性」はソフトウェア開発がうまくいくための根本。
- 謙虚・信頼・尊敬の気持ちを持って、心理的安全性の高い組織作りをすることが大事
- 謙虚・・・自身が全知全能ではないことを認識する=「無知の知」
- 尊敬・・・一緒に仕事している人を尊敬する
- 信頼・・・時には他者を信頼して仕事を任せる
- 「誰のせいなのか」を追求し「人」を責めるのではなく、「上手くいっていない事象(何が)」に目を向けて指摘を行なったり、言動やプロジェクトを振り返ることが必要
- それを体現したものが、ポストモーテム
- →失敗を次に繋げるために肝要
【ソフトウェア開発を進める上での6つのポイント】
— チームリーダー・プロセス・コードレビュー・ドキュメンテーション・テスト・CI/CD
(※6つの観点について、私の中で大事だと思った前半4つについてまとめました。)
- チームリーダー
- 管理しすぎない、時にはメンバーを信頼して仕事を任せる
- 馴れ合いではなく、メンバーにとっての良き先生かつメンターになることが大事 =言うべきところは言いつつも、相談に乗れる関係性になっておく
- プロセス
- 保守性の高いコードベース(システムを構成する上でのプログラム全体)を維持していくためには、ルールが不可欠。ただルールは時間の経過とともに変わっていくものである
- →ルールはシステム(エラーチェッカー・コードフォーマッターなど)で自動化することで、一貫性のあるコードを維持することができる
- コードレビュー
- コードレビューは主観的な判断ではなく、コードベースの一貫性が担保できているか、と言う客観的な目線から行なわれるべき
- 「正しい・正しくない」を確認するだけでなく、開発者間でのナレッジ共有の場にもする
- ドキュメンテーション
- Google では、ドキュメンテーションが開発タスクの一つとして扱われている(コードの一部として扱っている)
- ドキュメンテーションでは忘れられがちだが、5W を忘れずに書くのが大事
- 「誰」が読むのか(Who)=対「自分」に向けてではなく、それを読む読者を想定して書く
- 「何」を(What)
- 「いつ」(When)
- 「どこ」にあるのか(Where)
- 「なぜ」これをやるのか(Why)
Session2 では、「ドキュメンテーション」の項が特に印象に残りました。
開発=プログラミングと考えてしまいがちですが、それと同等にドキュメント整備を行なうことが属人化や、手戻りを防ぐために重要だと感じさせられましたし、日々の業務で意識しなければと思いました。
Session を受けて考えたこと
Session を通して、「文化」「仕組み」が細部まで浸透しているからこそ、Google は一流企業と言われている所以だと感じました。
Session2 でお話し頂いたいた Sho さんも仰っていましたが、「Google の文化が全て自社にマッチするわけではないが、参考になる部分はあるはず。」と感じています。
また、今回の Session での学びを踏まえて、
「案件で使っている技術を使って自分なりの視点でアウトプットする」
「今置かれた立場でどう行動したら案件の方々がよりスムーズに業務を進められるかを考える」
「どうドキュメンテーションを行なったら漏れなく他の方にナレッジの共有・情報の引き継ぎができるかを考える」
「自グループ・案件内でのメンバー間の心理的安全性をより高めるために何か企画する」、、などなど
一年目という立場で技術に乏しい身ではありますが、できることはたくさんあるなと思いました。学びを学びのままで終わらせず、しっかりと行動で示していきたいと思いました!
最後に
人事責任者の石田さん、新卒育成グループの方々、Session でお話しいただいた Google の Yusuke さん、Sho さん、当日オフィスの案内を担当してくださった Yoshinori さん、Go さんをはじめとした様々な方々のご尽力があり、オフィスツアーという、貴重な体験をさせていただくことができました。ありがとうございました?♂️