巻頭言：SRE NEXT 2023のプロポーザルを作る時に考えていたこと

著者：しょっさん
目次

今回の巻頭言は、もうそろそろSRE NEXT 2024が開催されるということで、私がSRE NEXT 2023のプロポーザルを作る時に考えていたアレコレについて書いてみたいと思います。

プロポーザルを考える前に考えたいこと

カンファレンスで登壇するには、まずプロポーザルを提出し、それが採択されることが前提となります。大きな舞台での登壇も緊張しますし精神的に高いハードルですが、そもそものプロポーザルというハードルも高いものでございます。

SREsにとってはSRE NEXTが代表格となっているカンファレンスですが、2023開催時のプロポーザルの採択倍率は 4.6倍 となっており、簡単には通らない壁となっています。（2024は更に倍率上がっていそう・・・）

なので、喋りたいことを喋るためにも色々と考えておくべきことはあります。

カンファレンスが掲げている指針に沿っているか？

SRE NEXTではスタッフブログにて、毎回テーマを掲げていらっしゃっています。

SRE NEXT 2022, 2023では SRE DIVERSITY として、様々な業種・領域でのSREプラクティスの実践をもとに多様なSREの普及を目指していました。

本年のSRE NEXT 2024では Beyond Next として、「Site Reliability Engineer という職種にとらわれない」、「SRE 本にあったプラクティスにとらわれない」 を新たに視点として取り入れたテーマにされていました。

つまりは、カンファレンスとして大切にしている価値観があるので、そこに準拠しているプロポーザルは自ずと通りやすくなるのだろうと考えられます。

大前提として、

  • Site Reliability Engineering に関すること
  • 実際に遭遇した問題を解決した内容であること

が募集している内容なので、まずは自分が発表したいことが 現場で遭遇し、解決したこと かどうか？が考えたいことですね。個人の趣味としてやったことや、こういう風なことを考えています（実践してないけど）のようなプロポーザルはテーマに沿っておらず、通すのは厳しそうです。

逆に、SREという職種にとらわれない・SRE本にあったプラクティスにとらわれないという２つの観点から、例えば「SRE × QA/Sec」のような他職種の方にもSREという考え方を広め、実践したというプロポーザルや、SRE本には載っていないが〇〇で紹介されていた目新しいプラクティスを導入したら良い感じになったという内容はより通りやすいような感じがしますね。

このことから、もう一つ考えたいことは 自分が今までやってきた活動でテーマに沿うものはないか？ ですね。
あなたが取るに足らないと思っている内容でも、聴く人によっては貴重な気付きの機会であったり、実践の礎になる可能性は大いにあります。是非、プロポーザルを送るというタイミングを期に、今までの棚卸しを行いテーマに沿ったプロポーザルの種となる経験を探し出してみてください。

対象とする方、聴いた人が得られるものを挙げる

さて、棚卸しした結果いくつかの「喋れそうかな？」といったネタは見つかることでしょう。この中から更にプロポーザルへと昇華するために、 どのような方に向けた内容になりそうか ・ セッションを聴いた人はどのようなものが得られそうか を考える必要があります。

SRE NEXTではCFPの際にスタッフブログでこのあたりを詳しく書かれていらっしゃいます。今年だと以下のような感じですね。

この発表を聞いた参加者が何を持ち帰れるかを、100文字以内でアピールしてください。この情報は、採否を判断するための情報として、スタッフのみが閲覧します。

例えば、あなたはどのような聴衆を想定しているか、あなたの講演を聞いた人はどんなアクションを始めたくなるか、あなたの講演を聞いた人の記憶に一番残るものはなにか、といったことを考えてみてください。

サラッと書かれておりますが、ここはかなり重要だと個人的には思っていて、発表の詳細に書いたことが採択をされる方にとっては「で、結局これ何を伝えたいの？」と思われてしまうかもしれません。
その時に、この対象とする人や得られるもの、どんなネクストアクションを促すことができるか？のこの文章がしっかり書けていれば、より採択する方に伝えたいことが理解されるでしょう。

私は去年通したプロポーザルでは以下のようなことを書いていました。

対象者にとって、SREを始めるための気付きを得てもらいたいと考えています。
また、対象外の方にとっても取り組んだことや失敗したことを聞いて、これからのSRE活動の参考にしていただけることを期待します。

100文字なので多くはかけませんが、「これは対象とならない方にとっても有益な内容ですよ」ということをアピールしたくて書きました。
こういった伝えたいことの補助線を引くのにうってつけの項目なので、是非びっちりと書くのをオススメします。

過去の傾向を探る

さて、ここまではプロポーザルの内容を考える前に大事にしたいことを書きましたが、少し視点を変えて 過去のセッションの傾向を探る といったこともやってみると良いかもしれません。

去年の時点で試しにやってみたのですが、セッションの傾向としては過去このような内訳でした。

2020

  • SRE組織について：6
  • SLI/SLO：1
  • 信頼性向上の取り組み：3
  • 運用：6
  • 監視：5
  • セキュリティ：1
  • DevOps：2

2022

  • SRE組織について：13
  • SLI/SLO：4
  • 信頼性向上の取り組み：4
  • 運用：6
  • 監視：4
  • セキュリティ：2
  • 特異な問題解決：5

ザザッと見て振り分けたので間違ってるよというのもあるかもしれませんが、概ねこのような感じの構成でした。2020→2022でSRE組織についての発表が増えたので、今年はさらに競争率高そうだな〜とかセキュリティ分野はそんなに数がないので狙い目かもしれないな、みたいな発見があるので一度どんな内容のセッションがあったのかを分析してみることをやってみると良いかもしれません。

とはいえ、狙い目のところに対してアジャストした無理くりな内容をプロポーザルとして送っても通りはしないので、競争率の高そうな分野であれば 他の人とどこで差別化するか？ を考えて、アピールすることも大事でしょう。
このように次のプロポーザルを書くステップで助けになる情報だとは思っているので、個人的にはオススメしています。

プロポーザルを書いてみよう

さて、ここまでで過去の経験からどのような話をプロポーザルとして提出するかは固まってきたはずです。

ここからは実際にプロポーザルをどう書くか？のお話になります。

とにかく量！

「壊れるほど愛しても 1/3も伝わらない」 と歌詞にある通り、どれだけ内容に情熱を詰め込んでも1/3も伝わらない可能性があります。
そのため、もうこれ以上は詳しく書けないよ！ってくらいには 発表内容を詳しく書くのがよい と思っています。

例えば、去年私が出した発表の詳細の項目を見返してみると約2000字の内容となっておりました。（多い） このくらい書かないと採択していただく方にはちゃんと伝えることができないんじゃないか？と思います。運営側からすると、多くのプロポーザルに目を通さないといけないので、あまりにも量が多すぎると逆にサッと読み飛ばされるかもしれませんが、それでも書かずに伝わらないよりかは書いて1/3は伝わった方が良いです。

また、ただ量を書くというだけではなく、キチンと 読み手のことを考える ことはしなければいけません。文章構成や流れを読みやすいものにする、というのは当たり前かもしれませんがちゃんと手を抜かないようにしましょう。
私はブロックごとに集中して読めるように、大テーマ・小テーマといった括りで構成させていただきました。例えば以下のような感じです。

■ 何故新規プロジェクトでSREが必要になったか？

プロジェクトの変遷と共に、チーム内で私がどのような活動を行っていてそこからSREポジションを立ち上げるまでのご説明をさせていただきます。
SREポジションを立ち上げるまでにどのようなことを考え、新規プロジェクトで立ち上げることの注意点・上司の説得まで含めながら説明する予定です。

・何故SREは必要になったか？

プロジェクトが開始してからインフラ・CI/CDを積極的に触る人がおらず、片手間で改善活動を行っていたが「これはもしかしてSREではないか？」と気付きを得た。
オライリーのサイトリライアビリティエンジニアリングを紐解くと、「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。」とあり、まさしく今やっている活動がSREであると確信する。

・SREポジションの立ち上げについて考える

どのようにSREを始めるか？一人で始めることになるので、限られたリソースをどう使うか？マネージメント層の説得材料はどうするか？などを考えた時に参考にした資料などを絡めて紹介。

SREの始め方についてはGoogleの記事を参考にしたことを紹介（https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started?hl=en）

リソースについては、SREが基本的にやっていることをリストアップし、その中からチーム状況を見て優先すべきこと開発チームにお願いできることなどどのように考えていたかを解説。

マネージメント層への説得は、開発チームがまだ少ない中、何故やらないといけないのか？などの用意をしたことをお話します。

このように、どういった流れで話を持っていくのか？最終的にどういった解決法を模索したか？みたいなことを分けて書いていくことをしました。
もしかしたらもっと良い書き方があるかもしれませんが、大事なのは採択担当の方が読まれる 時に読みやすいように書こうといった意識です。 読まれない文章はどれだけ内容に価値があっても無価値になってしまいます。 そうならないためにも、読みやすい文章を目指しましょう。

推敲の鬼になる

プロポーザルをザザっと書いたのがたしか提出の一週間ちょっと前で、そこからは読みにくい文章になっていないか？変な構成になっていないか？などを推敲しまくりました。
「一ヶ月前に書いた自分のコードは他人のコード」のような感じで、 自分が書いた文章も明日には他人が書いた文章のように映ります 。なので、日をおいて文章を読み直すと不思議なことに読みにくさや、不可解な表現などが目につきます。一度、他人の目になった状態で文章をブラッシュアップしていくことは非常に大切です。

これは完全に余談なのですが、宮沢賢治の名作である「銀河鉄道の夜」は 約７年の推敲 を経て、それでもまだ下書きとして遺してあり死後出版されたそうです。
そのように人に読ませる文章を作るということは非常に難しく、多くの推敲をもってやっと完成品として世に出せます。小説などに比べるとプロポーザルはそこまで壮大なものではありませんが、人に読んでいただく文章ではあるので最低限一度は推敲を行い、やる気のある方は時間の許す限り遂行を重ねましょう。

とはいえ情熱駆動

ここまで書いていてなんですが、やっぱり最後には伝えたいことがあるんだ！発表したいことがあるんだ！っていう情熱が全てだと思います。
第一稿はもう情熱のみを注ぎ込んでバーッと書いてしまいましょう。 システマチックに文章の構成がどうのとか、表現がどうのっていうのは全て後に任せましょう。それよりもまずは土台となる文章を情熱をガソリンに書き切ってしまって、そこからは冷静に他者の目になり修正していくことです。まずは情熱駆動でやっていきましょう。

まとめ

ということで、SRE NEXT 2023のプロポーザルを考えたときにどういったことを考えていたか？を書かせていただきました。

プロポーザルに関してはカンファレンス主催者の目線から@tomozohさんも発表されてらっしゃるので、一度読んでみるのをオススメします。

以上、カンファレンスにおけるプロポーザルの作り方のお話でした！