はじまり

ことの始まりは、Twitter(X)に来たDMでした。ちょうど会社のオフィスにいて、会議の合間の休憩時間に気づきました。
何が書いてあるのか頭に入らなかった。入った単語は「SRE NEXT」と「登壇」だけ。
思わず机にうずくまった私に、同僚が「どこか体調悪いんですか？」と聞いてきました。頭が真っ白で、頭を横にふるしかできませんでした。

DBREに憧れ、SREを目指した私が最も憧れたイベントが、SRE NEXTでした。
ようやくSREになって初めて参加できたのが、2023年。勿論GUEST参加。
本当に楽しくて、こんなやり方があるんだ！こんな技術手法があるんだ！と、とにかく夢中になりました。
当時持ち帰った「リリース時にはみんなで同じダッシュボードを見よう」という試みは、今もやってくれているそうです。嬉しいな。
私には眩しすぎたSRE NEXT。登壇するにはCFPを出す必要があります。
出そうよ、なんて社内で話があっても、遠い世界の話でした。私にそんなすごい事例も技術的な話もできない。

その後、SRE/DBREを辞めることを選びました。
様々な後悔がありました。大好きなDBを手放す、技術を手放す。もうSQLは当分打てない。sqlplusもmysqlも打たない。
あぁ憧れていたのにな、SRE NEXTにはもう一度は参加したかった。CFPを出すなんておこがましいけど、だめでも出してみたかった。
その後悔を持ったまま。それでも今、自分が変わらなければならないと信じて、転職をしてまで事業サイドに行きました。

そんな憧れのSRE NEXT。そこから、招待をいただいたのです。
一体何が起きてるのか、パニックにならない人間がいないですよね。

テーマは「Talk NEXT」。
指定されていたURLは、このブログの記事でした。
t.co

あぁそうか。そこで何を求められているか理解して、承諾の旨を返信しました。

最初の気付きの話

最初のキャリアのSIerの会社はなんだかんだ挑戦が大好きで、お客様も同様に挑戦好きな方だったこともあり、「世界初！」という事例を何度か体験しました。
その度に表彰や評価をしてもらった私は「なるほど、新しい挑戦、社外事例に載るようなことは評価されるのか」と、頭の片隅で変な考えを持っていました。
そんな私があるとき実施した挑戦が、MySQL InnoDB Clusterの導入でした。まだ5.Xの段階から検討を開始し、8.0で実装までこぎつけました。
今となっては珍しくもないですが、相当初期に実装、相当なミッションクリティカルなシステムへの導入、既存クラスタソフトの廃止などの成果を同僚達の努力のもと、実現しました。
しかしこれは、評価されませんでした。当時の上司はDBに知見はなかったので「それが何がすごいの？」という回答でした。（数年後に気づいてましたが時すでに遅し）

お客様にとってそれは、何の価値があったの？

当時は「上司が知らないって辛いな〜」なんて思ってました。
それも0ではないですが。
私はその時、少し感じた「もやもや」について何の深堀りも気づきも得ることもなく、ほんの少し浮かんだ疑問をそのままにしていました。
なにせ自分の評価には無頓着でして。
でも管理職になると変わるんですよ。なにせ管理職とは、同僚の評価を上げることが存在意義の一つであり、私にとっての喜びですから。
今でも自分の評価はどうでもいいです。同僚の評価を上げたい。部下って言い方は嫌い。

あの話をするまでの葛藤

資料を作り出したのは、いつもの通りギリギリでした。相変わらず追い込まれないと書かない人です。
ただ、何をどう書くかは、ずっと考えていました。なので書き始めて資料自体はすぐ完成しました。

これを、あのSRE NEXTで話す？

周りはそもそも、SREのことを知らない人ばかりです。相談できる相手はいません。
相談に乗ってくれたのはたった一人、ChatGPTだけでした。
イベント情報、経緯、ブログ記事を伝えた上で、ChatGPTに質問をしました。

技術イベントに、こんな内容話ししていいのかな？
登壇者のリストみてよ、本の著者や研究者、著名人、CFPの中で選ばれるような素晴らしい内容ばかりだよ。
そんな中こんな内容を、DAY1の最後に話すなんて。聞いて楽しい話じゃないよね。

まぁもちろん、ChatGPTは基本肯定する返答を返すわけで、そう作られていますが。
それでも、私の背中を後押ししてくれる言葉は選んでくれました。

「評価されない作業」「システムだけ見ていた」「事業目線がわからなかった」これ、技術者なら誰もが一度は思い当たることなんですよ。
他の登壇者の方々は確かに素晴らしいです。ただ、あなたが選ばれたのは、あなたの経験と視点が今のSREのコミュニティにとって必要とされているからです。
このセッションは「SREとして何を守り、そして何に向かって進むか」を問い直す、最高の問いかけになっています。

嫌なものには蓋をしたいです。
こんな話聞いたって、楽しくないのはわかってはいます。
憧れのSRE NEXTで、わたし、こんな話するのか。と、壇上で会場を眺めながら考えていました。話をする直前の、最後のさいごまで。

それでも向き合わずに逃げていたら、何も前に進まない。
それは私も、あの会場にいたすべての人にも。
だったら。たとえ嫌な話だったと思われたとしても、興味がないと思われたとしても。
いつかその人が同じ課題にぶつかったとき、この話を思い出してくれたらいい。その時、何か助けになれたらいい。
あぁそんな人もいたな、そう思い出してもらえるように。

そう思って、この話をしました。
あの頃の自分を、救える自分になれますように。
speakerdeck.com

おわりに

いつもどこかで失敗して、同じ失敗を次起こさないように。
どうも私は、「あの頃の自分を救えるように」という信念で、仕事をしているようです。
PMになったのも、DBエンジニアになったのも、過去全て「この職種を起因に思い悩んだ」からでした。（色々ありました）
PMもDBも、なんだかんだできるようになったので。いつかは事業サイドも平気でできるようになれるかな。
とすると、新規事業起案から保守運用までできるようになれるね。私、なんでもできちゃいますね。

そこまでできるようになったら、誰かを助けられるようになるかな。
一人でも誰かを幸せにできるようになったら、いいな。

そうそう、タイトルの画像ですが。

蓋をあけたら、ミミックだったりしてね。
わかってても、開けたいんですよ。

だって開けずに進んだ方がずっと後悔するの、分かってるじゃないですか。

はじめに

さて、この記事を書いた発端は、maruさんのこの投稿からでした。（mixi2です）
mixi.social

最近の若手の方はさておき、新人の頃に議事録を書かされた経験…みなさんもありませんか？
私も漏れなくそちら側で、一年間議事録ばっかり書いていた時期もありました。まぁ今となっては良い経験ですが、それは横においておいて。
この議事録作成タスク、体験された方のほとんどが感じてると思うんですよ。

コスト（時間）取られる！
あげくにmaruさんが言われてる通り、スケーラビリティがない！
例えば一人できるようになったら横展開で組織みんながどんどん出来るかというと、皆無ですよね。属人的、スキルアップ。

ということで、時代の変化が激しすぎる＆技術進化が光のごとく早いこの時代において、X時間かけて議事録を書くなんていうこと、特にIT技術者が時間を取られることは、個人的に超反対です。
ただし、そもそも「何故若手時代に議事録作成をさせるのか？」という、そもそもの目的を考えたときに、議事録でなくても文書を考える、書くということはエンジニアであっても重要であると考えています。
というポエムを、つらつら書いていきます。

そもそも「議事録」とは何なのか

みんな大好きChatGPTに聞くと素敵な答えが出てきますが、私が議事録が「絶対必要」であるのは、特にこの2点があるからだと思っています。

①証拠の残存

例えばある日、「来月からリモートワークやめます」なんて社長さんが言われたら、みなさん「はぁぁああああ？？？！」ってなりません？
議事録の大事な理由として、どうゆう議論がされた上でこの決定になったのか、という経緯と決定事項を証明、会議に参加されていない方にも伝えるという点が目的だと考えています。

私的には「経緯」を知るという意味では議事録を非常に重宝しています。結果だけ聞くと納得いかないことがほとんどですが、議事録を読むと「あぁなるほど、そんな経緯・背景があったのか…」と、その決定に対し納得することにもなりますし。
納得できない場合は、議論する際に相手に「議事録読みましたけど、その理由だけじゃ納得できないですよ」等、会議に参加していない人であっても議論をする場に参加することが容易になります。
議事録読んでいなければ、相手は同じ説明を何度もすることになるので、「もう何度も説明するの面倒…」と、場合によっては話すらしてくれない場合もあるかもしれないですね。

例に上げたリモートワーク廃止は、例えば「リモートワークにしてから、新しい事業、アイディアが出てくるスピードが遅くなった。もっと社員間で議論がされ、アイディアが生まれるようにしたい。だからリモートワーク廃止。」という議事録があった場合。
事業部や企画部門は、納得できるかもしれせん。経理や財務部門、システム部門は、納得できないかもしれないですね。いやいやそれ納得できないですよ、と反旗を振りかざす、という行動に移せるかもしれない。

他には、現在進行中のプロジェクトの凍結、組織や人事ルールの変更等、会社で働く上で大きな影響を及ぼす決定においては、議事録は有用であることが多いのではないでしょうか。

②責任の明確化

いわゆる「言った、言ってない論」を防ぐためです。

略式でも構わないのですが、やはりこれについては議事録がまだまだ強いと思います。
特にBtoB等の事業をされており、請負契約等で責任を負う場合は議事録は必須です。なにせ、裁判になったときに重要な証拠文書として提出しますからね。
録画でももちろん代替可能ではあるのですが、1時間の録画を後から聞き返すのって結構手間で、要点がまとまった議事録の方が確認が容易です。

ちなみにBtoBで議事録送るときは、メールでね。

でもここまで書きましたが、途中にも書いた「録画」「録音」や、AIの議事録や要約でも事足りるor済みますよね。
では議事録作成は無駄なのか？というと、もう少し掘り下げて…議事録という文書を書く目的は、そもそも何だったんでしょうか？

「文書を考えて書く」ということ

結論から書きますが、「議事録である必要はないが、簡潔かつ要点がまとまっている文書を考えられる、書けるということは必要である」と思っています。
何故文書を書く必要があるのか？というと、結論は以下の通りです。

まず文書とは、この場では以下を指すとします。

• 提案書
• 企画書
• 報告書

この3つはいずれも、経営層に近づけば近づくほど、必要となってきます。
そして企業規模に応じて、この資料を読むまでに多くの階層の役職者、人が増えてくるわけです。

共通して、簡潔さ・要点の明確さ　が必須となります。

ダラダラ書かれた文章、何が言いたいのか分からない文章…分どころか秒単位で仕事する経営陣が、読んでくれると思いますか？
多くの人が読むわけです、人によって違う認識がされやすい文書を読んで、役員間で認識齟齬が多発したら、賛成と反対派が乱立し…実現できることも出来なくなってしまう恐れがありますよね？
そのため、簡潔かつ要点まとめをする文章力というのは、読み手に共通認識を持ってもらうという点で、あらゆる社会人において必須のスキルとなります。

議事録作成は、そのまま発言を一文字一句書き起こす（いわゆるトランクスクリプト的な）が目的ではありません。
会議に参加した人の発言を簡潔化し、発言内容の要点をまとめる。それが議事録作成で必要なスキルです。
そのため、議事録作成を若手時代にすることで、簡素化、要点まとめのスキルを磨き上げていた。が、今までだったのでしょう。

でも今は、そんなのAIがやってくれますし。
そもそものmaruさんの発言にもあるのですが、時間をかけるコストに対しスケーラビリティが見合わない。

これらの内容から、簡潔かつ要点の明確化をすることを目的とした、文書作成能力を鍛えるために議事録作成をするというのは、時間コストに対し見合わない。

ではないかなぁ、というのが個人的な結論です。

簡潔かつ要点の明確化をするのであれば、例えば以下のような文書の方が、エンジニアにとっては時間コストに対し効果が見合うと思うんですよね。
それも、できれば一人でなく複数人で取り組むことで、スケーラビリティが生まれるんじゃないかなぁ、と思うんです。

• 報告書やポストモーテム作成
  • 個人的に、過去作成したポストモーテムの見直しをする際、内容だけでなく記載された文章をわかりやすくする、等でこのスキルは磨かれると思います。これ、別の効果もあると思うんですよね、やり忘れタスク見つけたりとか、これ原因違うんじゃない？とかとか。
• 開発標準等の標準化ルールの作成
  • リリース標準化とかでも。ルールは多くの人が読む文章なので、わかり易くないと間違える人＆問い合わせが増えて、気づけばToilになってしまうので、簡潔かつ明確な文書である必要があります
• GithubのREADMEの整備
  • これなんのソースのリポジトリなの…なんで別プロジェクトのソース混ざってるの…なんていうことが何も書いてない、なにがかいてあるんだこのREADME、ありませんか

これらをAIも駆使しつつ、短い時間で早くスキルアップしていくほうが、コスト対効果が見合うのでは、と思っています。
デイリースクラムに組み込んでみる、なんていうのもありかもしれないですね。

ただ、役員レベルに提出する報告書や提案書、企画書を書くということは、どこかでやるべきだとは思います。
例えばあなたがSREだった場合。SREとして目指す姿が、ビジネスにコミットした定量的な事業目標に関する指標を可視化し、それを実現するための信頼性向上を行うのがSREであるならば。
端的に言うと、経営にコミットするエンジニアでありたいのなら。経営陣に可視化した数値の報告、するんですよね？
じゃあ経営層に報告書を出してみましょう。メモレベルじゃ、だめですよね。さぁ、書けますか？

いずれあなたがCTOになった場合、CTOレベルは当然このスキルが求められるはずです。
文書の形式はこだわらないかもしれません。ですが、簡潔さ、要点がなにかを経営会議で求めらます。

まとめ

ということで、まとめ。

• 議事録作成というのは、コスト対効果が悪いので、率先してすべきではない
• ただし「簡潔さ」「要点が明確」な文章能力を身につけることは大事
• 議事録じゃなく他にも作成する文書はあるので、まずは身近なところからやってみよう
• AIはどんどん使うべきだけど、任せすぎはほどほどにね

技術ブログを書くというのも、ありかもですよ。ちなみにこの記事、AIには一切助けてもらってないので…ほら、分かりづらいのなんの。
私も最近、AIに頼り過ぎてダメダメです。とほほ。