初めて登壇した話

初めて登壇した話 saka @gaplant_tr5

自己紹介 ● ● ● 経歴(10年広告関連のエンジニアリングしてたが、2022年でそれを辞めた) ○ SES ○ 2015 広告プラットフォーム事業会社(広告システム開発) ○ 2019 メディアマネタイズ(広告システム運用) ○ 2022 今の会社に転職(ここからインフラメイン) 好きな言語 ○ Scala 今使ってるクラウド ○ GoogleCloud

今年を振り返って ● 登壇の実績を解除しました(オンライン(2月) & オフライン(いまここ)) ○ ○ ● オンラインの方 ■ きっかけ ● インフラ担当をするようになって担当者からお誘いを受けた ■ 内容 ● GAEからCloudRunへの移行のプロジェクトの中間報告 (振り返り) ● Innovators Live Japan 【現場の本音】App Engine から Cloud Run に移行してみた ● https://tech.visasq.com/2023/07/10/132209 ■ 感想 ● 転職と同じで一度登壇するとハードル下がるので一回やってみましょう と言う話ここで話そうと思った。 「自分じゃなくてもできることは自分でやらない」様に軌道修正中 ○ ○ ○ 裏返すと自分しかできない(自分がやることで付加価値をつけられる )ことだけを自分でやるように 元々アプリ畑なので自分がやるよりももっと経験のある人にやってもらったほうが良い 大事なのはチーム全体としてサービス品質を落とさずに改善を続けること

• https://cloudonair.withgoogle.com/events/innovators-live-jp?tab=serverless_containers&expand=module:serverless_containers_top
• https://tech.visasq.com/2023/07/10/132209

やれなかったこと・やるはずだったこと(来年やること) ● 個人的な目標 ○ ● 二年くらいほぼインフラ(terraform+α)しか触ってないので、コーディングを思い出したい。 「価値を考えることをまず考える」を広めていきたい（まずは社内で） ○ 作るコスト + 運用するコスト + 改善しやすさのコスト < 書いたコードが生み出す価値 が守れているかを作る前・運用している中でも常に考えたい。 ■ この論理はあくまで事業会社の話。(SIerだと小さく始めるのは予算等の都合でハードル高そうなので) ● 作るコスト ○ 小さく始めずに何でも盛り込みすぎていないか？ ● 運用するコスト ○ 必要最低限のものは揃っているか？(機能が足りずに誰かに負担をかけ「続けて」いないか？) => 期間限定の運用負荷は仕方ないと調整済みならOK ○ ノーコードツールなどでエンジニア管理外のツールが大きくなりすぎていないか？ ● 改善しやすさのコスト ○ 変にこだわった作りになっていて改修コストが高止まりにならないか？ ● コードが生み出す価値 ○ 売上増・コスト減・エンジニア・サービス運用者QOLの増加など、それぞれ意味があり、フェーズ によって優先度が変わる

やれなかったこと・やるはずだったこと(来年やること)(2) ● 作るコスト + 運用するコスト + 改善しやすさのコスト < 書いたコードが生み出す価 値 考えたい理由(背景) ■ ■ ■ ■ インフラに軸足を移して、コスト面の意識がより強くなった & 昔所属してた会社でもそんな事を言ってたなと思 い出した ● それなりの価値しかでないものはこだわりすぎなくてもいいのでは？ コードを書かずに解決できるならそれが一番 ● 必要だとしても小さくはじめる ● 依頼者側ときちんと話をして、「本当に欲しい物」が見つかるまで動かない(作ったけど使われないを避 ける) 初手対応したとき(作った時)は正解でも事業が成長すると正解じゃなくなる ● 使わない(価値が出てない)ものは思い切って消す ● 必要度が上がっているもの・価値のある改善ポイントはより良く改善 ● 定期的な見直しが大事(式年遷宮推奨。でもやりきりましょう) 機能改善したいのがたまにしか無いが、妙にコードが読みづらいと改修のハードルが上がる ● YAGNI原則で行きましょう ● easy(内部構造が複雑になりがち) < simple(やりたいことを蒸留しましょう) ○ モノによってはベタ書きを許容する

最後に一句 そのコード 存在する価値 でてますか？