運用知識ゼロからのレベルアップした成果 （「信頼性」編）
最近の仕事は「運用支援」をやっています。
「運用支援」というのは、システムはあるけれど、運用できていない or 上手くいっていないチームに対して、上手く運用できるように支援する仕事である。
支援する・・・といっても、私自身が運用のプロフェッショナルか？と聞かれれば、「No」と答える。
そもそも、私が過去にいた会社は「Web制作会社」であり、受託開発なので、Webサイトやシステムを構築したら納品して完了なのです。
そのため、運用は完全に・・・とまでは言わないけど、ほぼ対象外。
なので、私自身も「運用」に対して知識を深めつつ、支援というお仕事をしているわけです。
こんな状態でお仕事できるのかな？？なんて、思っていたのですが、やってみると意外とできるもので、不思議に感じています。人は経験が多いと色々と誤魔化すのも上手になるんですかね（笑）
さて、本題に入りましょう。
みなさん「運用ができている or 上手くいっている」とはどういう状態かご存知でしょうか？
なんとなく、必要な手順書が揃っている。とか、運用専門のチームがいる。とか、問い合わせフォームがある。とか、そんなイメージを持たれている方が多いのではないかと思います。私自身もそうでした。
まず、大前提として「運用ができている or 上手くいっている」というには、「〇〇ができているからOK」といえるものではありません。
システムに対して、色々な視点から見た上で「〇〇ができているからOK」となります。
今回は、その視点の一つである「信頼性」から見た「運用ができている or 上手くいっている」状態を書いていきたいと思います。
「信頼性」とはなんでしょうか？
私はこれが結構ややこしくて、苦手なのですが、私はシステムに対する「信頼性」という解釈をしています。
（お客さんが）「システムを信頼している」「システムを頼りにしている」状態という解釈です。
ちなみに「信頼性」は英語で「リライアビリティ」と言います。
「リライアビリティ」といったら、「サイトリライアビリティエンジニアリング（SRE）」じゃないですか？？
SREのお仕事は、システムのダウンタイムを減らして、サービスの可用性を高めたり、開発や運用の担当者間の連携を強化したり、改善や新機能の追加を継続的に行うチームのことです。
なんとなく、SREチームも（お客さんに対して）「システムを信頼している」「システムを頼りにしている」状態にもっていくことが仕事という感じがしませんか？？
話を戻します。
「信頼性」から見た「運用ができている or 上手くいっている」状態とは？
つまり、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態だからこそ、「運用ができている or 上手くいっている」と言えるということです。
では、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態はどのようにして、わかるのでしょうか？
ここで出てくる単語が「SLO」と「SLI」です。
- SLO（Service Level Objective）
サービスレベル目標とも言います。（お客さんが）「システムを信頼している」「システムを頼りにしている」状態になるような箇所に、目標を設定して、サービス品質の維持、改善を行います。
- SLI（Service Level Indicator）
サービスレベル指標とも言います。SLOに対して数値化した指標です。SLOが達成しているのかを判定する値になります。
私も「SLO」と「SLI」という単語をちゃんと理解し始めたのは、この仕事をはじめてからです。
ちなみに、良く耳にする単語は「SLA」ですね。
- SLA（Service Level Agreement）
サービスレベルの（お客さんとの）合意ですね。
これは、提供しているサービスが一定レベルを下回った場合に返金に応じるという約束事が書いてあることが多いです。
「SLA」は、お客さんとの合意のため、お客さんへの報告義務がありますが、「SLO」と「SLI」はお客さんへの報告義務がないというのも大きな違いです。
「SLO」と「SLI」の話に戻ります。
「SLO」の説明で、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態になるような箇所に、目標を設定する。とありました。
どこに設定するのでしょうか？
とりあえず「えいやっ」はダメです。
レスポンス速度を計測する人も多いのですが、toC向けで重い処理やページで無い限り計測する必要は無いと私は思っています。toB向けであれば、なおさらです。
ここでも新しい単語が出てきます。「ユーザージャーニー」です。
- ユーザージャーニー
お客さんがシステムを操作する一連の流れや体験を表したもの。トランザクションのようなものだと言えば伝わるでしょうか？
お客さんがシステムを操作する一連の流れ、つまり、ワークフローがあると思います。
そのワークフローをすべて可視化して、最も重複する場所を特定し、そこに対して「SLO」を設定します。
ワークフローは、画面遷移図からわかることもあれば、システム構成図からわかることもあるかと思います。
他にも、インセプションデッキのトレードオフスライダーで最も優先してきた機能を目標に設定するのも良いかもしれません。
そうすれば、システムのどこが重要な機能であり、お客さんがそのシステムに対して信頼する場所なのかが、特定できるのではないでしょうか？
「SLO」の設定ができてしまえば、あとは、その「SLO」を計測するために必要となる指標。「SLI」を決めていくだけです。「SLI」を決めた箇所には監視をいれましょう！
ここで、注意したい点としては、「SLO」を多く設定しすぎないことです。
理由は以下の通りです。
- データから意思決定する難しさが増える。
- サービスの信頼性の状態を他の人に報告するのがより困難になる（「信頼性をわかいりやすく伝える」というメリットがなくなる）
- 計測が多すぎると統計上の問題がでる。（多重検定問題）同じシステムで異なる計測をしてしまう。
そのため、3 〜 5個程度にすると良いと言われています。
「SLO」と「SLI」について、理解頂けたでしょうか？
「SLI」は、計測が必要なので監視が必要になり、「SLO」を超える様であれば、アラートによる通知が必要になります。
ここからさらに考えなければならないのが、「SLI」以外の監視についてです。
システムが構築したばかりであれば、「SLI」以外でも多く監視し、必要であればアラートを鳴らす必要があると思います。
しかし、システムを構築し終えて安定期に入った時は、はたしてそんなに多くのアラートが必要なのでしょうか？
もう「SLI」だけ監視していれば良いのか？
「運用支援」を始めたばかりの私にはわからない課題、まだまだ「信頼性」という視点から見た運用は奥が深い。。。
2025年の抱負について
2025年の抱負について、書きます。
AtCoderの挑戦の継続と成長
AとBは解けるけど、Cが解けない状態が続いているので、改善を目指したいと思います。
新しい会社では、Pythonを書くことが多いので、書くコードをGoからPythonに変更する。
Cを解ける様になるには、練習しかないとは思いますが、、、、
ためしに、AIで曼荼羅チャートとか作ってみて、実践してみると面白いかもしれない。。。
TerraformとAWSの理解
今後、Terraformを使っていくことになるため、使えるようになること。
あまりちゃんと学んでこなかった運用、監視周りのAWSサービスへの理解が求められるため、こちらも理解して実装できることを目指したいと思います。
とりあえず、以下本は読む。
個人開発やってみる
むちゃくちゃ久しぶりに個人開発をやってみようかと思います。
いつかは子供に向けて自分がどんな仕事をしているのかを伝えるような場面があると思っていて、その時に、さらっとアプリを作って、子供に「こんな仕事をしているんだよー」的なことを伝えられたら良いな。。。
本当にそんな場面がでてくるかはわかりませんが、備えて色々なことをできるようになっておくのに越したことはない。。。
AIキャッチアップ
昨今のAI進化はとんでもないです。
AIをうまく使えないと生き残れそうにないような時代になっているので、AIについて知り、うまく使えるようになりたいと思います。
エンジニアとしての得意分野探し
これも継続。
最後に
今年は、新しい職場でのプレゼンスを高めつつ、楽しく仕事＆技術を身につけられるといいな。。と思います。
今年もがんばるぞっ！！
2024年の振り返りについて
明けまして、おめでとうございます。
2024年の振り返りをしていきます。
『2024年の抱負』記事を見ると、以下を目標に掲げていた様なので、以下を中心に振り返りたいと思います。
- AtCoderへの挑戦を継続
- エンジニアとしての得意分野探し
- マネジメントの整理
AtCoderの継続
なんだかんだで、AtCoderを1年間継続することができました。
とはいえ、AとBは解けるけど、Cが解けない状態が続いており、結果としては個人的に「イマイチやね」な状態が続いております。
たまに、Bも解いていない場合があったりしますが、子供の寝る準備を手伝いながら問題を解いているため、集中力が続かない場合は諦めたりしているので、その結果だと思います。
どうやら、このまま単純に問題を解き続けているだけでは、スコアを上げることはできなさそう。。。というのが、わかったことですね。
やはりキチンと問題と向き合って「振り返り」する必要がありそうです。このあたりは、2025年の目標にしても良さそう。。。
エンジニアとしての得意分野探し
ここは、引き続き悩み中。
個人的には「きれいなコードを書こう」よりも、AWSであったり、IaC周りの方に知識があるため、その結果として「こだわりの強い部分があるなー」と最近感じているので、もうそっちかな、、、と思っている部分はあります。
とはいえ、引き続き継続して色々探すかも（？）
マネジメントの整理
2024年は、（若干の偏りはあるが、、、）マネジメント関連の本をたくさん読みました。
その結果として、「アジャイルやりたい！」「もっと外の世界をみたいぞ！」と、前職を飛び出して、今のクリエーションラインに辿り着いた感じです。
2024年の1月時点では、まさか自分が転職するなんて思ってもいませんでしたね。
仕事について
2024年は、かなり忙しかったと思う。
なぜなら、転職活動に加えて、10月末にリリースを控えた案件を抱えていたからである。
10月末にリリースした案件は、本当は9月末にリリースをする予定だったのだが、お客さんの要望による変更に変更を重ねた結果、時期をズラすこととなった。つまり、案件は炎上したのです。
その結果、転職にも影響して入社時期をズラして貰う等の調整も入った。
案件は炎上しており、どうにもならなくなった結果、私は有給消化をすることなく、10月末の最後の最後まで前職で働き、次の日は転職先に出社するという。。。
（転職先での初日は正直頭の切り替えもできていなかったし、寝不足でしたし、正直辛かった。。。）
ちなみに、前職での私の引き継ぎ先として、フリーのエンジニアの方に色々と引き継ぎをしたのだが、11月には既に自分自身から契約を破棄された様で。。。
ホント「マジカ。。。」が続いた2024年でした。。。
転職して1ヵ月経ったので、振り返り
はじめに
クリエーションラインに転職してから約1ヵ月が経ったので、簡単に振り返りたいと思います。
なお、結構濃い時間を過ごしたと実感している。
初出勤はオフィスにて・・・
実は、前職のリリース前作業が初出勤前日の22時頃まで対応していたため、頭の切り替えが不十分な状態のまま出勤することになった。
その場で、オリエンテーション、PCのセットアップやチームメンバーとの挨拶など、、、色々と作業をしました。
本社が秋葉原に近いので、昼食は秋葉原で焼き肉を奢っていただきました🙏
なんか会社にすごい人が多い
チームメンバーや会社の人の自己紹介で「OSS活動していました」「書籍書いてました」など、なんか色々な意味ですごい人が多い会社だと思いました。
「ぇ、正直、ついていけるかなぁ。。。」と不安に思うところもありますが、すごい人が多いということは、その人から学ぶことも多くあるということなので、（プラス思考で）これから頑張っていこうと思えました。
チーム全員がアジャイルで動いていた
メンバー全員がアジャイルで動くのが当然のような会話になっていて、驚いたのを記憶しています。
私の体に染み込んだウォーターフォールから離れるのには、まだまだ時間が掛かりそうです。。。
仕事に対する書籍購入制度がすごい
今は、お客さんが「システムを納品したけれど、運用がうまくできていない」という課題を解決すべく、どう動いてどう対応すべきか。。。みたいなところを手探りで進めている感じです。
そういう私自身も前職は納品して終わり！みたいな立場の人間だったので、運用周りの知見が無い状態です。
そこで、書籍購入制度を使って以下の書籍を申請したら、すんなり通りました。すごいっ
ちなみに「SREサイトリライアビリティエンジニアリング」は鈍器レベルの分厚さがあり、なかなか全部読み進めていくのは辛いな。。。と思いつつも、必要な知識をすばやく取り入れられる仕組みが会社としてあるので、とても便利だと感じています。
歓迎会を含めたチームビルディング
歓迎会を含めたチームビルディングをオフラインで開催しました。
クリエーションラインは、全国でリモートで仕事をしているのですが、この時はチーム全員がわざわざ本社のオフィスまで足を運んできてくれました。（いやー、めちゃ嬉しいっ！）
チームビルディングでマシュマロチャレンジをやりました。
簡単に言えば、20本のパスタを使って、いかにマシュマロを高く置くことができるか。。。というものです。
これも楽しかったです。
あと、チームメンバーの顔と名前を覚えるのが苦手な私がすぐに顔と名前を覚えることができたので、このチームビルディングは大成功だと感じました。👍
AIすごい
前職では、VSCodeを使っていたのですが、うちの会社ではCursorを使わせてもらっています。
CursorのAIの機能がすばらしく、ホントに便利で、めちゃ活用しています。
ただ、まだ使い始めたばかりなので、どうやって上手にAIに質問すればわからず、、、このあたりは随時学んでいく必要がありそうです。。。。
さいごに
仕事内容も一緒に仕事する人も変わり、色々不安ではあったものの、なんとか新しい会社でもやっていけるかなー。と自信を持つことができた1ヵ月でした。
引き続き、がんばっていこうと思います。
クリエーションライン株式会社に転職しました
この記事を書く前に、転職のインタビュー記事が先に掲載されてしまったので、既にご存知の方もいらっしゃると思いますが、2024-11-01付けで以前の勤務先を退職し、クリエーションライン株式会社（以降、CLと呼びます）に中途入社しました。
転職した経緯について
既にインタビュー記事ですべてを話しているのですが、40歳を迎えて何か新しいことに挑戦しようと思ったのがきっかけです。
「世界一流エンジニアの思考法」という本を読んで、次に挑戦したいことは「アジャイル開発」だな。。。と思いました。
また、その時やっていた案件がウォターフォールで開発を行っていたのですが、長期案件ゆえに、最初の要件定義で決めたことが、ことごとく開発フェーズで変更が発生し、中には既に開発を終えたものがリリースを迎えることなく不要となるようなケースが多発していました。
こうなると、最初の要件定義で決めたことが無駄になり、開発者にとってもモチベーションが上がらず、憤りを感じていました。
個人的には、短期であればウォーターフォールで開発するメリットはあると感じますが、長期や先が見通せない場合はウォーターフォールで開発するメリットはないと感じます。
そのため、「楽しい開発」「柔軟に変更できる開発手法」を身につけたい＆挑戦したい思いから、アジャイル開発できる会社を探して転職することを決意しました。
インタビュー記事について
CLに内定いただいた後、LAPRAS様より「インタビューさせて頂きたい」との連絡があり、承諾しました。
最初の転職から今回の転職について、すべてお話させて頂いていますので、私のように「エンジニアになったけど技術力がつかなくなったな。。。」「アラフォーに近い歳だけど、転職できるかな。。。」みたいな方々にささる記事だと思うので、参考にしていただければ幸いです。
以前の職場について
結局、十分な有休消化はできずに退職となりました。
最後の最後まで、関わっていた案件が鎮火せず、とても忙しかったです。。。
とはいえ、以前の職場に不満はなく、むしろほとんど技術力の無かった私を拾って頂いて感謝しています。
このあたりは、最初の転職の時とだいぶ違いますね。
当時は「技術力がない。やばいっ」「このままだと子育てできない」「上司と考え方が合わない」でしたが、今回は「新しい挑戦をしたいっ」というプラス思考で行動できたのが大きいです。
会長からも「ダメだったら、戻っておいで」と言われたのですが、一旦は精一杯新しい職場で挑戦してみようと思っています。
今後について
まずは当初の目的通り、アジャイル開発の経験を積んでいきます。
そして、自分自身のこれからの経験と過去の経験から、ウォーターフォールとアジャイルのメリット・デメリットを整理し、今もウォーターフォールでしか開発できないような方々に対してアドバイスできるくらいの能力は付けたいと思います。
次に技術。今まではお客様に対して「納品」で完了していましたが、新しい職場では「運用」もやるので、特にクラウド周り運用について、知識と経験を増やしていきたいと思います。
最後に私自身に得意技術や知識が無いので、「私はこれが得意だっ」みたいなものを何か見つけていきたいと思います。
