こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
シリコンバレーのスタートアップ、Launchable。
今回は日本から活躍するエンジニアたちのお話を デブサミ2024ベストスピーカーに入賞したセッションを含む2本をお届けします！
会の様子
講演1〜非同期開発体制を支えるドキュメント文化〜
最初にKonboiさんから話がありました。
なぜドキュメントを大切にしているのか？
まず、組織的な話として、日本とアメリカで活動しているため時差の問題があるという話が挙がっていました。
また、ドキュメントにすると生成AI系のツールに頼ることができたりして、苦手意識がある英語に対するサポートが手厚い点も理由の一つだということです。
また、ドキュメント自体のメリットとして、
- (メンテナンスは必要ではあるが)一度書いてしまいさえすれば半永久的に使える
- 書くプロセスを通してより深く考えられることができる
- フィードバックが深く平等にできる
というのもドキュメントを大切にしている理由だという話がありました。
どんなドキュメントを運用しているのか？
最初にProject Proposalが挙げられていました。
Project Proposalは、新しい機能を提案するときに作るもので、誰がいつ提案して誰が担当していつ終わったのか？というのが記載されているそうです。職種に関係なく書くものであり、MTG途中で議論が始まって論点が不明瞭になってきたタイミングで書かれることが多いそうです。
本文は、
- なぜプロジェクトをやるのか(エンジニア以外が読めるものを想定)
- 先行事例(関連資料や類似プロジェクトなど)
- 専門的な言葉を使って開発チーム向けな解像度高い説明
- 具体的にどのように進めるのかの詳細
で構成されているということでした。
次にDACIが挙げられていました。
こちらは、比較的重要な意思決定をする際に書くドキュメントだそうで、意思決定する人も決まっているような状況で書くということです。(ただし意思決定者以外もコメントするのは自由)
項目としては、
- 影響度
- 誰が進めるのか
- 承認者
- 作業者
- 承認者ではない関係者
- 関連データ
- 進める背景
- 代替案
- 実行するためのTODO
が書かれているそうです。
次にPostmortemが挙げられていました。
こちらは障害が起こった際に書くようなドキュメントで、いつインシデントが起きてどういう対応をしていつ対応完了したのか？というのを記載するそうです。
また、インシデント対応完了後には、犯人探しにならないように注意しつつ、再発防止策や対応にあたってよかったことなども記載するそうです。
最後にCS Investigation Logが挙げられていました。
こちらはCSに対して情報を共有する目的+ナレッジシェアの目的で情報を記載しているそうです。
どう運用しているのか？
Launchableでは、オンボーディングでもドキュメントを書いたり、Rocket Fuel Day*1でハードルが低いドキュメントを書く機会が多かったりと、普段からドキュメントに慣れ親しめるような工夫をしているということでした。
また、ドキュメントを置く場所は部門ごとにConfluenceのスペースを分け、古いドキュメントはアーカイブに移動するなどといった取り組みをされているそうです。
ドキュメントはドキュメントごとにフォーマットが決まっているので、書く人も書きやすく読む人も読みやすいということです。
これに加えてFBに関しても30%/60%/90%*2でFBすることを型として定義し、コメントの中でも意見と提案と委任をはっきり分けることで対応が必須のコメントなのかできれば対応したほうが良いコメントなのかがはっきり分かるようにしているそうです。
講演2〜Flight of a Decade:10年間の旅路と再会〜
続いてYoshioriさんから、2014年にベストスピーカー章を取った際の続きに関する発表がありました。
何を決断したのかではなく何を考えて決断したのか
Yoshioriさんは、何を決断したのではなく何を考えたことが重要だと考えているという話がありました。
例えば2016年当時に色々と大変な状況で人事部長を引き受けた際、大変な状況で人事部長をしたという決断よりも、岩田さんの「よくなるチャンスがあるのに当事者にならないのはもったいない」*3という言葉に感銘を受けて決断したというのが重要だと考えているそうです。
発表の前提
ジュニアエンジニアやシニアエンジニア、スタッフエンジニアといった用語やグレードはGoogleのラダーをイメージして話をしているということでした。
視座/視野/視点
「経営視点が欲しい」「技術だけではなくサービス視点を」...といった視座/視野/視点*4といった話が自分のなかで附に落ちたそうです。
視座が違う経営層と現場では同じ方向を見ても見えるものがぜんぜん違うのが至極当然なので、フィードバックをするときに「もっと長期的視点をもて」「サービスの価値を考えろ」といったアドバイスをするのではなく、まずは見えている姿を説明することが重要だということです。
仕事の振られ方
まず、実装レベルで振られるのか、課題から振られるのか？がジュニアエンジニアとシニアエンジニアとの違いが挙げられるということでした。
一方で、スタッフエンジニアやプリンシパルエンジニアに関しては、グレードが上がってくると他の人が解決できなかった問題が上がってくるので、ジュニアエンジニアやシニアエンジニアと異なり正解がないため、仕事の進め方や意思決定をするポイントがはっきり変わってくるということです。
そのため、「前言っていたことと違う」と「情報増えたんだからそりゃあ違うでしょ。前のやり方に固執されても...」のようなギャップが注意しないと出てくるそうで、情報が増えたスタッフエンジニアやプリンシパルエンジニアは、次やること以上に「もうやらないと決めたこと」を言わないといけないと感じているそうです。
なお、決定力を減らすためにジョブスやオバマの真似をしてYoshioriさんもTシャツや美容室などの決定をしないようにしたそうですが、特に何も効果はなかったそうです笑(ただし日常業務の決定が決定疲れになっているんだろうなというのは分かった)
自身の影響力
ジュニアエンジニアは自分と自分の周り、シニアエンジニアはジュニアエンジニアより広い範囲(シニアエンジニアの周り+ジュニアエンジニアへの影響)の影響が求められるようになるということでした。
一方でシニアエンジニア以降になると、下方向ではなく上方向への影響力が追加されるということでした。(プリンシパルエンジニアになると全社的な影響が求められる)
例えばハッカソン開催の事例であれば、最初は影響範囲を全社に持って、その後に影響力の上方向(CTOへの説明)/下方向(周りの参加者への説明)を意識するといったことが事例として挙げられるそうです。
決断とチャレンジ
わざわざ時間を割いてこのような発表を聞いたりしている人は相対的に他の人よりも仕事が上手な可能性が高いものの、仕事が上手いだけに失敗しない仕事を選んではいないかが気になっているという話がありました。
Yoshioriさんは、GoogleがRailsのアップグレード話(バージョンごとにアップグレードするのではなくメインブランチの最新コミットを持ってくるローリングアップデートをしている話)を聞いた時、挑戦的な仕事の重要性を実感したそうです。
そうした経験があった後は、挑戦機会を探すとともに、仕事をふるときも挑戦的な仕事を挑戦的な仕事であることをはっきり話したうえで相手に渡すことを意識して仕事をするようになったということでした。
ここまでのまとめ
話したことは特別なことではなくどの会社にも書いてあるようなことですが、実際に経験したことで言える話をしたということでした。
物語の主人公で居続ける
時間の都合上、途中で話が物理的に(Google Meetが切れて)終わってしまいました...笑
会全体を通した感想
ドキュメント運用に関しては取り組みをかなり具体的に話してもらえた上に、文化や仕組みが洗練されている様子が伺えて学びになる点が多かったです。
Yoshioriさんの話は、ソフトスキル的な要素がありながらも、Yoshioriさんが実際にやってきた経験とリンクさせてYoshioriさんから出てくる言葉で話をしてくれていたので、よく聞く言葉に対する解釈の視点が増えて、こちらも非常に学びになりました。
