GREE Tech Conference 2022に登壇します
お久しぶりです、mkurokiです。
2022年10月25日にGREE Tech Conference 2022が開催されます。場所は東京ミッドタウン・カンファレンスです。当日会場に来られない方に向けて YouTube Liveによるオンライン配信も実施します。
で、今回なんと僕も登壇させていただく事になりました。タイトルは「事業環境の変化に対応するインフラ組織 その取り組みと現状」ということで、インフラ組織を取り巻く事業環境や周辺組織の変遷、またテクノロジーの変化にどう対応してきたかということをお話できればと思います。
みなさんの中でも、事業が成長していく中で、組織構成として開発組織の中にインフラチームが同居しているか、もしくはインフラは共通部門として独立した組織となっているか、といった変化のフェーズが訪れる経験をされている方もいるのではないかと思います。そういった変化の中での課題解決の一助になれば幸いです。
ご参加いただける方はconnpassからのお申込みが必要ですので、ぜひお早めにご登録お願いします。
いやーしかし、こんな規模のイベントでの登壇は多分初めてなので緊張していますが、がんばります。それではよろしくお願いしますー！
Grafana Cloud で無料でお手軽外形監視を試した
はじめに：外形監視してますか？
こんにちは、mkurokiです
突然ですが、WebサイトやWebサービスの外形監視、してますか？
（参考：外形監視とは）
サービスが動いている環境の外側から包括的な監視ができるという点や、サービスが動いているクラウド側での大規模障害の際の検知など、外形監視を入れておくとなにかと便利なこともありますよね。
今回は、Grafana の SaaS である Grafana Cloud の Freeプランを活用して、無料で外形監視ができるよという話を聞いたので、個人サイトに導入してお手軽に試してみました。
ちなみに、Freeプランで試せる内容としては下記のようです
- 10,000 series for Prometheus or Graphite metrics
- 50 GB of logs
- 50 GB of traces
- 14 days retention for metrics, logs and traces
- Access for up to 3 team members
個人サイトで試すには十分な内容かなということで、手っ取り早く使ってみることにします。
導入手順
内容的にはこちらの公式ドキュメントに記載のあるものです。
Synthetic Monitoring という機能を使って、外形監視を導入していきます。
アカウント登録して Grafana Cloud のホームにログインするとこんな画面です
赤丸で囲んだ「Set up Synthetic Monitoring」をクリックして次に進みます。
Synthetic Monitoring のトップ的な画面に遷移します。ここから Synthetic Monitoring の設定に進んでいきます。
赤丸で囲んだ「Initialize the plugin」をクリックして次に進みます。
今回はサイトの外形監視ということで、Monitor your entire website の欄から
赤丸で囲んだ「Create a check」をクリックして次に進みます。
赤丸で囲んだ「New Check」をクリックして次に進みます。
ここで、監視先や監視方法の項目を入力していきます。
「Job name」に適当にこの監視の名前を付け、「Target」に監視対象となるサイトのURLを入力します。
「Probe options」内の「Prove locations」では、どこから監視をするかを選ぶことができます。いくつか好みで選択するとよいかと思います。
例えばサイトが動いているサーバーが日本にあるなら、Prove locations で日本とアメリカを選択すると、日本からのレスポンスタイムとアメリカからのレスポンスタイムにこれだけ差がある、といったことも見ることができます。
入力が終わったら「Save」をクリックして保存します。
これで監視設定の作成が完了し、監視が始まりました。
赤丸で囲んだ「View dashboard」をクリックすると、ダッシュボードが開きます。
最初はデータが無いので何も表示されませんが、時間が経つと徐々にデータが取得され、ダッシュボード上に様々な値が表示されていきます。
デフォルトでいい感じのダッシュボードが仕上がるので、ありがたいですね。
おわりに
ということで、無料の範囲でお手軽に外形監視ができるようになりました。
とはいえ、このままだと通知の設定がされていないので、サイトが落ちたとしても気づくことができません（ダッシュボードを眺めていれば気づくでしょうが）。
次はアラート通知の設定をやってまた記事を書きたいと思います！たぶん。
ビデオ会議の音声を快適にするTips集
はじめに
こんにちは、mkurokiです。
リモートワークをされている方は、zoomやmeet等でのビデオ会議を利用する機会が多いかと思いますが、音声のトラブルで困った経験をされたことがある方も多いのではないでしょうか。
例えば、ノイズが多くて聞き取りづらい・音が小さい・発言していない人のマイクが雑音を拾っている……などなど。
ビデオ会議中の映像はどう映っているかが確認できますが、「音声が相手にどう届いているか」の確認はなかなかそうもいかないのが難しいところですよね。
こういったトラブルの中には、ビデオ会議ツールのちょっとした設定や確認で回避できるものもありそうです。少しでもトラブルを減らして快適にビデオ会議を行うためのTipsをまとめます。参考になれば幸いです。
※本記事内では、zoomやmeetなどのオンラインビデオ会議ツールを利用した会議を「ビデオ会議」と呼称します
ビデオ会議の音声を快適にするTips集
ヘッドホンかイヤホンを使用する
ヘッドホンもしくはイヤホンを利用することで、スピーカーからの音をマイクが拾ってしまうようなノイズを防げます。
スピーカーからの音をマイクが拾ってそれをループしてしまうと、最悪ハウリングという現象が起きてしまい、キーンといった感じの、耳障りで大音量のノイズが発生します。これもヘッドホンやイヤホンの使用で避けることができます。
また、Zoomやmeetなどではおそらく、スピーカーからの音声がある程度出ている間は、マイクからの音声入力を抑制するような挙動があるっぽく、場合によっては自分が喋っている声が一時的に全く相手には届いていないという状態になることがあります。
複数人で喋っていて発言タイミングが重なると、時折相手の声がこちらに届かなくなってしまう瞬間があるのはおそらくこのためです。これらのトラブルを避けるためにも、可能な限りヘッドホンやイヤホンを使用すると良いです。
音声入力状態を常に確認する
音声が入力されているかどうかの状態を確認することは重要です。なぜかというと
- 意図せず音が出ている状態になっていないか
- 意図せず音が出ていない状態になっていないか
を確認することで、自分の伝えたい声がちゃんと相手に伝わっているかどうかを確認することができるからです。
どのように確認するのかというと、ビデオ会議ツール内の音声入力状況を表すアイコンの様子を見ることで確認ができます。
Zoomの場合、下記のアイコンの様子で音声入力状態を確認できます。
音声が入力されていない状態は下記
音声が入力されている状態は下記
meetの場合、下記のアイコンの様子で音声入力状態を確認できます。
音声が入力されていない状態は下記
音声が入力されている状態は下記
自分が喋っているのに画面上では音声が入っていない、もしくは逆に喋っていないのに画面上では音声が入っている、といった意図しない状況を避けるためにも、上記のアイコンを確認しておくと良いかと思います。意図せず音が出ているようならミュートにしましょう。
（意外と、環境音や吐息などを意図せずマイクが拾ってしまって、相手に届いていることがあります。）
余談ですが、Zoomではデフォルト設定だと上記の音声入力アイコンがしばらくすると消えてしまうので、常に画面に出しておくための設定として、「オーディオ設定」から
「ミーティングコントロールを常に表示する」をチェックしておくと、常に確認ができます。
ノイズ除去をONにする
Zoomやmeetのノイズ除去機能はかなり優秀なので、この機能を使うことで、エアコンの音だったり、周辺の環境音だったりといった、乗せたくない音を乗せないことができます。基本的にはONにしておくのが良いと思います。
Zoomだと「オーディオ設定」から、ここ
meetだと「設定」画面から、ここ
ただし限界はあるというか、さすがに喋ってる隣で救急車が走ってたり、電車が走ってたりするとどうにもできませんので、そういった場合はおとなしく騒音が収まるのをみんなで待ちましょう。
音声テストで自分の出している音を確認する
ここまでのTipsを実施した上で、では自分の声がどう届いているかというのは普通に使っていると確認できないのですが、音声テスト機能を使うことでどのような声が相手に届いているかを確認する事もできます。
meetでは残念ながらそういった機能がなさそうなので、可能な限りmeetでの利用状況と環境を揃えた上で、Zoomの音声テスト機能を用いて確認しておくと良さそうです。
確認手順はこちら。
音が悪いなと感じるようでしたら、マイクの別途購入を検討してみても良いかもしれません。
おわりに
ということで、ビデオ会議の音声を快適にするTips集をお届けしました。
2022年、快適なビデオ会議ライフが送れますように！
Google Cloud 認定資格 Professional Cloud Architect をオンライン受験で取得した
こんばんは mkurokiです。
先日、Google Cloud 認定資格の Associate Cloud Engineer が期限切れになったため、せっかくだから上位資格で更新するかと思い、Professional Cloud Architect を受験して合格しました！
ので、その時の話を書いてみたいと思います。
今回は自宅から「遠隔監視オンライン試験」で受験しました。いい時代になりましたね。
どんな資格なのか
Google Cloud 認定資格の1つで、下位の Associate Cloud Engineer と比べてより実務的で高度な内容だと思われます。
推奨される経験：業界経験が 3 年以上（GCP を使用したソリューションの設計と管理の経験 1 年以上を含む） らしいです
受験料は $200 でした。
詳しくはこちら
https://cloud.google.com/certification/cloud-architect/?hl=ja
なぜ取得したか
これはまぁ、Associate Cloud Engineer が期限切れになったので……というところで、せっかくなので上位のものを取っておくか、というくらいですね。
どのように勉強したか
GCPは日頃から業務である程度触っているのと、GCPのアップデート情報などは日頃から目を通しているのと、Associate Cloud Engineer は以前取得していたのでその時の知識はあり……といった前提知識もありつつ、復習と対策を兼ねて資格取得のためにやったこととしては、下記の3点です
- Coursera 受講した
Preparing for the Google Cloud Professional Cloud Architect Exam 日本語版 のコースを一通り受けました。これはまぁさらっと流した程度です。
この試験に挑戦する上で基本となる考え方や試験対策が学べて良かったと思います。
コース内でも触れられていましたが、試験に使われるケーススタディを理解しておくと、試験問題を理解しやすくなると思います。
- 本を読んだ
Google Cloud Platform エンタープライズ設計ガイド
- 作者: 遠山陽介,深津康行,中庄谷哲平,小島仁志
- 出版社/メーカー: 日経BP
- 発売日: 2018/05/17
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Associate Cloud Engineer のときにも読んで役に立っていたこちらの本を再度読み返しました。こちらもさらっと。
- 模擬試験を受けた
公式で提供されている模擬試験を受けて、わからなかったところを調べて覚えました。模擬試験自体はボリュームが少ないので、先のCourseraの模擬試験と合わせてinputに使った感じです。
というくらいで、正直そんなに大したことはやっていなかったのですが、試験を受けて思ったのは「もう少し勉強しておけばよかった……」でしたね。。
やっておいたほうが良さそうだったこと
udemy の模擬試験は100問のボリュームがあるため、これをやった上でわからないところを調べて覚えておくと、かなり試験範囲をカバーすることができそうな気がしました。
www.udemy.comまぁこちらはやってないのでなんとも言えませんが、やっておけばよかったなとは思います。この記事を書いた時点では ￥2,400 ですがたまにセールもしているようです。
試験当日
自宅から、「遠隔監視オンライン試験」で受験しました。
オンライン受験で必要になることは公式でまとめられています
遠隔監視オンライン試験 - Google Cloud 認定資格 ヘルプ
リンク先の動画に詳しいのですが、受験する部屋に人が入らないこと、余計なものがないこと、PCのカメラや手鏡・スマートフォンなどを用いて部屋の中に不正がないことなどを確認することになります。準備をしておくと良いでしょう。僕は身分証明書はパスポートを用い、部屋は布団が敷いてあるだけの寝室の隅のローテーブルにノートPCを置いて受験しました。
試験が始まって、今回も「後で見直す」のチェックが大半の問題付いてしまう事態になりましたが、まぁいつものことですね。
なかなか自信のない回答もたくさん残りつつ、今回は10分くらい時間が余りました。
提出して、その場で結果が表示されます。暫定合格でした。オンラインテストでは不正がないかの検証のために？一週間ほど審査が入ってから後日正式な合格通知が来るようです。
正答率とかは開示されないので、どのくらい正解できていたのかは闇の中ですね。
そして合格通知
翌週（土日挟みつつ5日後くらい）に、メールで正式な合格通知が届きました。
合格の記念にノベルティがもらえるのですが、Associate Cloud Engineer のときより少し記念品が豪華な気がしますね。タイミングの問題かな？ ベタですがパーカーをもらおうかと思います。
最後に
まぁ若干準備不足感はありつつ、どうにか合格できてよかったです。次はAWSのSAAが切れたらSAPかな〜。
Kubernetes完全ガイド（第2版）を読んだので感想とか
はじめに
こんにちは、mkurokiです。 タイトルの通りですが、Kubernetes完全ガイド（第2版）を読んだので、勉強になったポイントや参考になったポイント、感想などを章ごとにまとめて書いてみたいと思います。
最初にこれだけは書いておきますが、めっちゃいい本でした！
第1章 Dockerの復習と「Hello, Kubernetes」
Dockerの基本が復習という形で書いてある。Dockerの仕組みやビルドの方法、各種ベースイメージの違いなども解説されている。基本を忘れてしまったら読み返したい。
第2章 なぜKubernetesが必要なのか？
k8sの概要として歴史と特徴が書かれている。 k8sを使うと何ができるのか：コードでの管理、オートスケーリング、スケジューリング、リソース管理、ロードバランシング、データの管理 etc… k8sに対応した連携システム・ミドルウェアの紹介も。
第3章 Kubernetes環境の選択肢
どのようなプラットフォームでk8sを利用する選択肢があるのか：
- ローカルk8s：Minikube等。手元のマシン上で気軽に試せる
- k8s構築ツール：kubeadm等。ツールを利用して任意の環境に構築
- マネージドk8sサービス：GKE,EKS等。パブリッククラウド上で提供される
ローカルk8sは本番環境には適さない。
また、少なくともステージングとプロダクションでは同じ環境で揃えられるようにしておくとよい。
その他、k8sのサービスレベル目標（SLO）が満たせるクラスタの上限構成や、ブラウザ上で手軽に試せる k8s プレイグラウンドの紹介も。
第4章 APIリソースと kubectl
k8sの基礎、リソースとAPIリファレンス、kubectlの使い方など。
createではなくapplyを使う理由、アノテーションとラベルの解説、ログやデバッグなども含めオペレーションの基礎が詰まっている。
第5章 Workloads APIs カテゴリ
クラスタ上にコンテナを起動させる各種リソース（Pod,ReplicaSet,DaemonSet等）の解説。ReplicaSetはDeployment経由で使うのを推奨。k8sを運用する上では基本となるリソースの使い分け方で、内容もなかなかボリューミィ。
なお、この章で妙に印象的だったのがPodのDNS設定（spec.dnsPolicy）。
PodのDNS問い合わせの挙動を定義するのだが、デフォルトだと設定値「ClusterFirst」となるのに対し、それとは別で「Default」という値も設定できる。
Defaultはデフォルトの値ではないので注意が必要（ぐるぐる目）というなんとも不思議な設定値……。
第6章 Service APIsカテゴリ
ServiceリソースはPodのサービスディスカバリやL4バランシングを提供している：ClusterIPやLoadBalancer等。
似ているがIngressはL7を提供するサービス：クラスタ外のGCLB等を使う物と、クラスタ内にデプロイするNginx Ingressがある。
第7章 Config & Storage APIsカテゴリ
環境変数を利用した設定、機密情報を読み込むためのSecretリソース、key-valueで設定情報を保存しておくConfigMapリソースなど各種の利用方法。
PersistentVolumeClaimを使った永続化ボリュームの要求方法と、ディスクの拡張・subPathなどの紹介も。
第8章 Cluster APIsカテゴリとMetadata APIsカテゴリ
短い章で、ほぼ両カテゴリの概要の紹介とNodeリソース、Namespaceリソースの紹介。他の項目については次章以降で後述するということが書かれている。
第9章 リソース管理とオートスケーリング
Podの最低Requestsと上限Limitsを適切に設定すること、それによるQoS Classの適用、LimitRangeとResourceQuotaによる制限。
オートスケーリングの方法としてクラスタ自体のCluster AutoscalerとPodのHorizontal/Vertical Autoscalerの選択肢が紹介されている。
第10章 ヘルスチェックとコンテナのライフサイクル
Liveness Probe、Readiness Probe、Startup Probe の 3種類のヘルスチェックの種類と、それぞれに用意されているexec/httpGet/tcpSocketのヘルスチェック手法。
コンテナ起動時と終了時のスクリプト実行、initContainers、終了処理のタイミングなど。
第11章 メンテナンスとノードの停止
ノードを停止するためスケジューリング対象から除外するkubectl cordonコマンド、ノード上で実行中のPodを排出するdrain処理、PodDisruptionBudgetによる制御などの紹介。
Podを気軽に再起動できるようにしておくとメンテナンスの省力化に繋がる。
第12章 高度で柔軟なスケジューリング
Podの配置先Nodeを決定するために柔軟なスケジューリングが可能。
特定のノード上だけで/除外して実行する、特定のPodがいる/いないドメイン上で実行する、など。
実践的には、Nodeに付与したラベルとの組み合わせで、GPU使用とか本番環境とかの指定ができそう。
故障中ラベルを付けるとかも、かなり実際の運用で使われそうな内容で、なるほどーとなった。
第13章 セキュリティ
正直この章はふんわりとした理解……必要になったらまた読み返したい。 UserAccount と ServiceAccount の違い、RBAC、ClusterRole と ClusterRoleBinding、ネットワークに制限をかける手法、kubesecによるSecretリソースの暗号化の手法など。
第14章 マニフェストの汎用化を行うオープンソースソフトウェア
システムが大規模化したときの管理を助けてくれる代表的なツール、HelmとKustomizeの紹介。
Helmはk8sのパッケージマネージャ。chartとしてパッケージのinstall情報を管理してくれる。
Kustomizeはテンプレートから環境別にフィールドを上書きして、productionやstaging環境ごとにレプリカ数やCPU/memoryなどのリソースを変更するといったことが実現できる。
Ksonnetは今は開発が停止しているので使わないほうが良さそう。
第15章 モニタリング
DatadogとPrometheusの使い分け。
Datadogはノード上でDaemonsetで起動（もしくはサイドカー）、アラーティングも。余談だけどダッシュボードかっこいいなこれ。
Prometheusではマシンを用意すれば課金要素なし、Pull型なのでExporter経由でデータ取得したり。可視化はGrafana経由で。
第16章 コンテナログの集約
アプリケーションのログは基本的には標準（エラー）出力に出すべき、安定保存にはFluentdがおすすめ。転送先は各クラウドのマネージドサービス利用など。Fluent Bit もある。
もしくはDatadog Logs、Grafana Loki なども。集約して利便性を高めることが大事。
第17章 Kubernetes環境でのCI/CD
実運用では手動でのkubectl実行は可能な限り避けるべきで、そのためにGitOps、自動CI/CDの仕組みが必要。
- CIツール：TektonやKaniko等、チェックにはKubeval、Conftest、Open Policy Agent/Gatekeeper等
- CDツール：ArgoCD：KustomizeやHelmのマニフェストも扱えるため完成度が高い
開発環境を整えるツールとしてTelepresense、Skaffoldなど。
このへんの、Kubernetes周辺のエコシステムはほんとに進化が早そうなところ。各システムの公式ドキュメント要チェック。
改めて手動オペレーションの排除は大事……。
第18章 マイクロサービスアーキテクチャとサービスメッシュ
k8sはマイクロサービスアーキテクチャと相性が良い。そのモニタリングのためにサービスメッシュがある。
代表的なプロダクトIstioではPodにサイドカーとしてEnvoyプロキシを埋め込み、トラフィックコントロール、通信の暗号化などが可能に。
第19章 Kubernetesのアーキテクチャを知る
k8sを構成するetcd,kube-apiserverなどの説明。独自のリソースを追加して拡張もできるようになっている。
本の内容から逸れて余談（僕の見解）だが、このあたりはkubernetes the hard wayをやるとわりかし理解が深まるような気がする。
第20章 Kubernetesとこれから
CNCFによる開発と標準化、k8s上に展開するXaaSやKnativeなど周辺のエコシステム、動作確認のためのtestbedなどの紹介。
付録・あとがき
最後に、逆引き的にめちゃめちゃ便利な付録のFAQと、あとがき。
あとがきも短いながら沁みる内容となっていた。内容は是非キミの目で確かめてほしい（
まとめ
というわけでめっっっちゃ時間かかってしまった（2ヶ月ちょいかかった）けど読了！しかしこれで終わりではなく、触りながらまた読み返して理解を深めることになるだろうなぁ。
しかし流石はというかKubernetes完全ガイド、完全にガイドしていくぞという気概のようなものを読んでいて感じます。看板に偽りなし感。Kubernetesの入り口として、とてもよいものだと思いました。
なお、この記事は Twitter に書き溜めておいた章ごとのメモをまとめただけというものなのでたいへん楽でした。 読むのに時間がかかりそうな本は、少しずつでも読んで得た内容を記録しておくと思い出しやすくて良いかもしれません。
36歳父親のエンジニアが転職をして気づいたこと
こんにちは、mkurokiです。
はじめに
実は今年転職をしまして、ゲームインフラという領域は変わらないのですが、勤める会社が変わりました。
転職をするのは3回目、新卒で入った会社から数えて4社目になります。
// Job Hopper とまではいかないかと思いますが、まぁまぁの転職回数になってきましたね。
36歳で転職をした共働き父親エンジニア/マネージャーという立場から、このタイミングで転職をするとどんな事が起こるのか、転職によって気づいたことなどを書いてみたいと思います。
もし似たような境遇で転職を考えている方の参考になりましたら幸いです。
※ 広義のソフトウェアエンジニアという意味で「エンジニア」という単語を使っています。
なぜ転職をしたか
転職の目的としては
- 一度マネージャーからプレイヤーに戻り、技術的な領域を伸ばしたい
というところです。僕は前職で4年ほどインフラチームのマネージャーを務めていましたが、一旦ある程度マネージャーとしてやれることはやれたかなと感じ、一段落したところで、これから先の自分のキャリアをどう積んでいくかを考えました。
おそらく最終的にはマネージャー方向に進むことにはなるかなと思いつつ、そこへ進んでいくための基礎力の一つとして、現状は技術力が手薄になっているな、と感じました。
そして、技術力が手薄になっている部分を補強したいと感じ、実際に手を動かすプレイヤーとして再度経験を積みたいと考えました。 （機会があれば、マネージャーとしてチャレンジした内容もどこかで記事にまとめてみたいです）
前職の会社では、残念ながらプレイヤーに戻ることはできませんでしたので チャレンジを含めて受け入れてくれた今の会社には感謝しています。
内定を頂いた会社はいくつかありましたが、楽しくゲーム作りのお手伝いができそうな会社、という点で魅力的でしたので今の会社を選びました。
また、たまたま知り合いで転職先の会社のOBの方もいましたので、この会社がどんな雰囲気なのか、自分にフィットしそうか、アドバイスを頂くこともできました。
人とのつながりがあると色々といいことがあるなぁと実感した次第です。
転職をしてみて
転職で大きく変化したこと
そして、その転職でどんな変化があったかというと、大きくは2つです。
- マネージャーからプレイヤーになった
- 中堅規模の会社から、より大きな規模の会社になった
といった変化がありました。まぁ当然勤務地なども変わってはいますが、細かいところは割愛。
余談ですが前職の最後は5月末最終出社という時期で、緊急事態宣言の真っ最中。ほぼ100%リモートワークで勤務していました。
最終出社日だけは、荷物などもありましたので物理的に出社しましたが、まぁ当然というかこのご時世のため送別会などはありませんでした。寂しい〜。
転職先での初出社は7月1日、入社後すぐにリモート比率高めでの勤務が始まりました。
36歳父で転職をして気づいたこと
若い頃の転職と比べると、家庭があり、子どもがあり、持ち家があり と 様々な面で転職が大変になってきているところがあるなぁという気がしました。
生活水準を変えないようにと考えると、給与を下げるという選択もしづらいですしね。
逆に言うと、家庭や子どもがいても働きやすい環境の会社であれば転職のハードルが下がりますので、ミドル層の中途採用を増やしたい企業には、こういった施策がプラスになるのではないかと思います。
以下、36歳の転職で感じたこと・気づいたことを箇条書きで書きます。
有休日数がどかっと減るのでがなかなかカツカツ
子どものいる家庭は、子の体調不良や、保育園の面談などで平日の休みが発生しがちですが 転職前なら潤沢にあった有給休暇が転職のタイミングでガッツリ減るので、結構カツカツになるなぁということがありました。
前職では「なんかあったら有休いっぱいあるし」で安心を得られていた部分は結構あったのかもなぁと気づきましたね。
有休復活まであとnヶ月で、残り日数があと何日だから、だいたい一月あたりx日か……みたいな計算を久しぶりにした気がします。
まぁでも、リモートワークと柔軟な働き方のおかげで、大したことのない用事（郵便物を出すとか、荷物を受け取るとか）で有休を使うことが減っているのでなんとかなっているかなと思います。
看護休暇みたいな制度もあるので助かってますし、そんなに心配はしていません。
逆に言うとこういった制度や働き方が充実した企業でなかったら、ちょっと辛かったかもしれません。
採用前に調べて/聞いておくとよさそうです。
リモートでの on boarding 大変
これはなかなか各社どこも苦労されているところではないかと思いますが、リモートでの on boarding は、やはりけっこう大変だったなと感じます。
リアルでの飲み会などもなかなか開催できず、オフィスに行ってもほとんどのチームメンバーは在宅なので、結局いまだに直接顔を合わせたことのないチームメンバーも結構います。
そんな中で信頼関係を築いて（ちゃんと信頼関係を築けているかはあまり自信がありませんが）一緒に仕事をする同僚としてチームに入っていく関係性を作っていくのは、なかなか大変でしたし結構時間もかかったかなと感じています。
コミュニケーションを増やすためにやってよかったことはいくつかあるのですが、その筆頭として、Slackの個人times channelを作ったことが個人的にはだいぶプラスに働いた気がします。
times channelで僕がアホなことを言っても、暖かく接してくれている同僚のみなさんのおかげでなんとかやっていけております。
マネージャーからエンジニアに戻るの結構大変
これはもうひとえに僕の実力不足のせいですが、コーディングや手を動かす場面、また業務上の技術的な問題解決にかなり時間がかかったり苦労したりしています。
転職先はそれなりに大きな企業でもあり、長年運用されてきたシステムもあり、ドメイン知識が必要な場面も多々あるのですが、そこも不足している上に技術的な力も足りてないので、まぁやっぱりある程度覚悟はしていましたが大変ですね。
これについては難易度の高くなさそうな課題から担当させてもらったり、プロジェクトに入る際に、インフラサイドのProject Managerに近い立場で入らせてもらい、得意分野を活かしながら技術を吸収させてもらうことでなんとかなっています。
理解のあるマネージャーや技術リーダーに感謝です。
家庭にもリソースを割かねばならない
こちらは僕の在宅勤務の環境上のこともありますが、定時を回ったあたりになると、家の中のload averageが上がり始め、子の夕飯風呂歯磨き寝かしつけみたいなタスクがわんさか出現します。
「これはワイも1coreとして稼働せねば処理が詰まってしまう！」みたいな状況が発生し始めるので、「残業をいっぱいしてどうにかする」みたいな手法が少々取りづらい環境になっています。
幸いにもフレキシブルな働き方ができる雇用条件になっていますので、一旦離席して子の風呂上がりを受け取り、保湿クリームを塗り、服を着せ、髪を乾かし、絵本を読み、妻にパスして業務に戻る、みたいなことも可能なので、そういったやり方もたまにしています。
共働きなのでできる限り妻の家事育児の負担量を減らしたいのですが、まぁ平日離席してのタスクは流石に上記くらいが限界なので、退勤後に洗濯をしたり、朝の保育園送りをするのとあとは土日の家事育児ボリュームを上げて、バランスを取ることを目指しています（それでもトータルはやっぱり妻の負担分がでかい）。
なるべく業務時間中の効率を上げるようがんばります。
健康を維持するの大事
現在37歳の僕は完全に中年男性目前なのでうっかりすると体重が増え、中性脂肪が増え、LDLコレステロールが増え、健康診断の結果に黄色信号が発生します。
健康を維持しないと質の高い労働を維持することもできず、ひいては家庭を維持する事もできませんので、体重を含めた健康管理も重要です。
転職後、なかなか運動や筋トレに時間を割くリズムが掴めず、体重は増加傾向にありました。
これはなんとかせねばと思い、まずは「運動をするぞ」という決断をせずとも運動ができる仕組みづくりから（決断はコストが高い）ということで、下記のようなルーチンを設定してみました。
というゆるい目標を設定してなんとか体重を押し留めています。土日は子どもと遊ぶところにパワーを持っていかれるので設定なしです。
もうちょい続けて、長期的なスパンで1ヶ月1kgくらい減ればええやろ、という感じにしたいです。
中長期的な目標を考えるのも大事そう
転職後に初めての目標設定を行う際、改めて今後どのような成長をしていきたいか、どんなキャリアを積みたいかを考えました。
やはりある程度のロードマップというか、マイルストンを設定してあと何年後にこうなっていたい、なのでそれまでの目標をこう設定する みたいな努力の方向性の定義をするのは有効そうだと思いました。
まぁありふれたやり方ではありますが、意識はしておきたいなという感じです。
おわりに
36歳父親のエンジニアが転職をして気づいたことはそんな感じです。読んでいただいてありがとうございました。
似たような境遇の方がどれくらいいるのかはわかりませんが、SDGsの目標を意識せざるを得ない社会になっていく流れはあるかと思いますので、家庭と仕事どちらも継続的な成長をするためにどういったアプローチができそうかを考えることは有用なことのような気がしています。
いい人生になるように少しでも前に進みたいですね。
「Webエンジニアのための監視システム実装ガイド」を読んだ
表題の書籍を読みましたので、本の紹介や感想などを書いてみたいと思います。
どんなことが書いてあるのか
- 現代のWebシステムに必要な監視のシステムについて、概要から選定・導入の方法や運用まで、「監視」に必要な情報が一通り揃っています
- 一冊通して読むことで、実践的・現代的な監視システムの全貌を把握することができると思います
以下、チャプターごとの内容を少し紹介
チャプター1：監視テクノロジの動向
- 少し前のスタイルの監視から現代に至るまでの、監視システムがどのように移り変わってきたかの変遷を知ることができます
チャプター2：監視テクノロジの概要
- どのような手法やツールを用いて監視をするかが書かれています
チャプター3：監視テクノロジの基礎
- 前述の概要について、構成要素の基礎技術が解説されています
チャプター4：監視テクノロジの導入
- どのように監視を始めるのか、またどのように監視ツールを選定するのか等が解説されています
チャプター5：監視テクノロジの実装
- 特に重要な監視項目などの具体例や、監視対象別のTipsなどが書かれています
チャプター6：インシデント対応実践編
- インシデント対応の実践において、基礎知識や心構え、ふりかえりの方法などが書かれています
チャプター7：監視構成例
読んでみての感想など
- 現代的な監視とはどういうものか、どのように実装されるのかについて幅広く知識を得ることができる本だと思いました。特に現場目線というか、MSPの会社で鍛え上げられまくった貴重なノウハウが詰まっていると思います
- さすがに、細かなミドルウェアや言語ごとの詳細な監視パラメータなどまで網羅はされていませんが（ページ数がいくらあっても足りない）、参考になる情報やリンクなどでのフォローも手厚く書かれているため、それをもとに調べていく事もでき、困らなさそうです
- 古くからの監視システムの知識を現代向けにアップデートしたい方向けにも、入門 監視と同様、おすすめできると思います
というわけで、「Webエンジニアのための監視システム実装ガイド」を読んでみて でした。システムをどう監視していくかというところは、単純な正解がないことも多いので悩ましい場面もあるかと思いますが、悩んだ際に指標になる内容が多かったように感じます。監視で悩んだらまた読み返してみたいと思います！
