DevOps の小説を読んだ感想
今回のお題はDevOpsです｡
よく聞くワードですし､もうITエンジニアには一般化されてるような気がしたんですが自分が本業として取り組むにあたってふんわりとしたイメージしか知らないなあ､ということで導入を兼ねてDevOpsを教えてくれる小説を読みました｡
ストーリーの大筋としてはデスマプロジェクトを指揮することになった主人公が会社のトップともやり合いながら､部門の壁を超えて連携する（DevOpsを構築する）ことで解決する､という流れです｡最近､小説もご無沙汰だったので読んでて面白かったです｡軽い感じでサクッと読めます｡
以下､心に残った点です｡
3つの道と4つの仕事
本書で提示されているDevOpsのコアバリューが3つの道で4つの仕事とは仕事を4象限のマトリクスに分割したもの｡
3つの道で示されている価値観というのは高速に価値提供して､フィードバックループを回し､よく実験してよく学ぶことの3種です｡一般的な価値観ですが､ソフトウェアのリリースを絡めてこれらの価値観を実現しなければならない点がDevOpsの難しいところでもあります｡
一方で4つの仕事とは平たく言うと7つの習慣に出てくる､緊急・重要のマトリクスのような分類の仕事を指したものです｡主人公は開発チームが作ったリリース用のソフトウェアパッケージをリリースするのですが､重要では無い急ぎの仕事や人的に依存したタスクなどで本来やるべき価値を生み出す仕事を全く進められない状態になっていました｡
この状況をDevOps的な部門を超えた連携と工場の生産管理をベースにしたリリース管理を行うことでなんとかしてしまいます｡
この工場の生産管理というのもうまい設定で､DevOpsの原点にはリーンの哲学があるといいます｡リーンとはスタートアップでよく使われる考え方で最小限の機能を提供するプロダクトを顧客に提供し､そのフィードバックを元に方針を少しづつもしくは大きく変えながらサイクルを回して価値を生み出していく考え方です｡リーンのベースはトヨタ生産方式にあり､この書籍ではリーンの概念を飛ばしてDevOpsと工場の生産管理を結びつけて表現しているのが面白いところです｡
devopsの目的
devopsがリーンやトヨタ生産方式を原型にしているとは書いたんですが、その目的は3つの道以外にも開発コストの回収も含まれます。
一回ごとのリリース期間を短期間化して高頻度のリリースサイクルを回すことで一リリースで回収すべきコストが分散される…とされています。開発が長期間化すれば人件費もその分かかるので分かる話です。
開発視点でもビックバンリリースと言われるような変更量の多いリリースはバグが含まれやすく、その原因追跡も変更量の多さから難しくなるとされています。
具体的なデプロイ頻度
これは具体的に書籍にも登場していて一日20回のデプロイを目指すように書かれています。
この1日20回という頻度は個人的にはハードルが非常に高いなーと思いますが、ここはプロダクトの種類やチームによっても異なりそう。
それよりも気になったのはそんな頻繁にデプロイしてたらQA工程が追いつかなくないか？ということ。 これに関しては自動テストで代替したり、フィーチャーフラグを立ててステージングやプロダクションでは機能のオンオフを変更するんだそう。ここも開発チームの特徴が出そうなポイントだと思います。
その他
書籍から離れた話。
devopsの立ち位置
結局devopsがなんなのかというと、ソフトウェア開発（saas）でリーンを実現していくための哲学や方針といったかなり抽象度の高い概念だと思いました。
devopsが掲げる目標を実現する手段としてCICDとかアジャイルとかオブザーバビリティなどがある、感じですね。
devopsは哲学ということでdevopsを学んだだけでは中々devopsの実現は難しいのですが、普段CICDなどを触ったりしてる身からすると「why」が知れたのは収穫でした。
今回は小説でdevopsの触りだけ知ったので、今はリーンスタートアップやトヨタ生産方式などのdevopsの背景的な情報を取得しつつ、SRE領域のdevopsを実現するHOWも学習しています。
2025年5月 AWS JumpStartに参加しました
AWS JumpStartという勉強会イベントに参加したので､内容とか良かったところを記録します｡
Jump Startは今年あと2回あるので興味が湧いた方はぜひ参加してください｡
目的
AWSがほぼ無知なのでキャッチアップしていくため｡軽めの勉強会や初心者向け書籍を読んだが同じような内容ばかりで知識が深まる感じが無かったので､一気に理解を深めるようなものを望んでいた｡
やったこと
2日間で初心者講義用の簡単なアーキテクチャをAWS上に構築するハンズオン〜指定された要件を基にアーキテクチャ図を作成する､といった内容｡
面白いのはハンズオンは基本的にモブプロ｡アーキテクチャ図の作成も個人作成時間を1時間程度用意されていたが､時間経過後は振り分けられたグループ内でコミュニケーションを取りながらアーキテクチャをブラッシュアップさせる方式だった｡仕事する以上に喋っていた気がする｡
1日目
最初に操作になれるためのハンズオンでECSとAmplifyでのデプロイ｡次に､簡単なアーキテクチャとしてネットワーク周り＋Aurora MySql＋ECSのアプリケーションコンテナという構成でDBなどは多少冗長にして構築するハンズオンをおこなった｡
さすがにクラウドがどうこうという段階の説明は一切なく､一安心｡
構築操作に不慣れだったが､モブプロを組んだ方も同じレベル感だったのでわちゃわちゃしながら構築してました｡
2日目
初日の振り返りを兼ねたAWSクイズから始まり､その後はほぼ終日ECサイトに関するアーキテクチャ図作成に取り組んだ｡
アーキテクチャの要件としては数万人規模のECサイトで夕方にピークがあり…と結構わかりやすい｡現実的にはこのあたりの要件の洗い出しこそ難しい部分だったりするからアーキテクトとして面白い部分だけイベントではやった感じなのかなと思う｡
グループ内でもAWSに詳しい人がいたのでグループワークでアーキテクチャを作る際には質問できたりして､非常に勉強になった｡なんとなくサービスを組み合わせてアーキテクチャを構築するって部分の理解が深まった気がした｡
他グループのアーキテクチャを見れる場面が結構あって､なんなら成果発表とかも聞けたのだが､全く違う発想でアーキテクチャを組んでいるグループもあって学びが多かった｡
あと､全編通してAWSの方やBedrockに質問できるので疑問が湧いたら即解消できてこれもありがたかった｡
おわり
今回のAWS JumpStartへの参加を通して､AWSのアーキテクチャの見方や､サービスの組み合わせでアプリケーションをつくるって部分の理解が深まりました｡ 特に後者に関してはこれまでのアプリケーション制作とは決定的に異なる部分になるので気づいたことで今後の理解が早まりそうです｡みなさんもAWSをキャッチアップしていくなら AWS Jump Startをおすすめします｡
「技術書の読書術」の感想
精読と速読を両立できる上手い話があったら知りたいと思って買いました｡久しぶりの技術書以外の書籍｡
いいなと思ったところとしては､一冊を3回読む手法がまず心に残った。
1回目は速読で概要を掴む。この段階で全く話がつかめない場合は自分に対して書籍のレベルが高すぎるので別の本に移る。
2回目でハンズオンしながら精読する。一回目を読んだ際に概要と流れを把握しているので進めやすい。
3回目で自分が詰まった箇所やポイントと思うところをまとめる。アウトプットすることで理解が定着する。
こんな感じに知識を広げるフェーズと深めるフェーズを分けることで読むこと自体もスムーズに進むようにしている｡参考にしたい｡
手を動かすのを初回と別工程にするのでPC触るぞってタイミングで進めていきやすいと思った。
また、読者の数を増やしていく方法として時間制限を設けて読書をするって方法も書いてあって、これも良いやり方だと思った。
30分だけ読む。30分経ったらスパッと一度やめる。ダラダラ読むよりやっぱり集中して進めていけそう。
他にも､エスカレーターで移動してる間に1ページ読むって方法も書いてあった。通勤で1日に4回エスカレーター使うなら1ヶ月で80ページ、半年で480ページになるので侮れない。
他にも英語書籍の読み方とか知見を深めてく読書法みたいなことが書いてあった。本を読む人ほど読書法を知っといて損はないのでおすすめの一冊です。
sidekiqとは何か｡ 概要とか調べたことまとめ
仕事でsidekiqに触れたので調べたことをまとめました｡
sidekiqとは何か？
sidekiqとはバックグラウンドジョブ管理gemです｡
バックグラウンドジョブとは重い処理をバックグラウンド処理してユーザー（クライアント）の処理待ち時間を削減したり、リソースの浮いた時間帯に重い処理を回したりするなどできるようにするもの｡ユーザー体験が良くなると言われています｡
sidekiqはRubyで書かれたマルチスレッド処理でジョブを並列実行する仕組みになっています。1プロセスあたりマルチスレッドかつ､1スレッドが1ジョブを実行します｡デフォルトでは25スレッドが上限となっています。 ジョブがプロセスに依存しないため、メモリにロードしたデータを複数ジョブで流用することができる点で、メモリ効率が競合ライブラリよりも優れているようです｡
また、ジョブ管理はRedis（メモリ）を使用します。
実行フロー
sidekiqはRuby gemとしてRailsプロジェクト（に限りませんが）にインストールして使用します。
起動時はRailsアプリケーションと並行してsidekiqクライアントを bundle exec sidekiq -C sidekiq.yml して起動します。別プロセスでsidekiqは動作し、Railsアプリケーションとは異なる動きでジョブを管理・実行します。
大まかな処理フローは以下の通りです。
- クライアントが重い処理をリクエスト（帳票発行やメール多数送信など）
- Railsアプリケーションは対ユーザーとジョブ管理とで処理を分ける
- ユーザー：処理を受け付けたことをレスポンスする
- ジョブ：Railsアプリケーションからsidekiqに組み込んだジョブクラスを呼び出して非同期ジョブを呼び出し
- sidekiqはRailsアプリケーションからの呼び出しをもとにジョブをキュー（Redis）に登録 ※キュー以外にも時限実行とかもある。
- キューに蓄積されたジョブが順次実行される ※同時実行数はsidekiqで定義できる
- ジョブの順番が来たらあらかじめ定義済みのジョブが実行され、Railsアプリケーションの処理が呼び出される
- ジョブが完了したら終了､もしくは完了しない場合は再実行される
実装
公式のGetting StartedとRails Guideに目を通すと良いと思います｡
Active Jobはジョブ管理gemの抽象化ライブラリなので､使うとジョブ周りの実装が若干楽になるのかな？個人的には素のsidekiqでもシンプルだと思うのでどちらも使いやすいと思います｡
アプリケーション起動時から動作する繰り返しジョブの実装
個人的にやりたかったところがこれです｡アプリケーションを起動した直後から起動している間は一定間隔で実行されるジョブをsidekiqで実装したいな､と｡
ジョブの実装に関しては通常のRailsアプリ､sidekiq使用時と変わりません｡Railsアプリ上に実装し､sidekiqなりActive Jobから処理を叩けるようにしておきます｡
ジョブのスケジューリングはsidekiq-cronというgemを追加で入れて使用します｡繰り返し処理とかを設定できるgemです｡
また､sidekiqのジョブ実行の前段階としてジョブの登録が必須になります｡これをアプリケーション起動時にどうするかというと､sidekiqのジョブ登録はDBに行うので bundle exec rails db:seed をアプリケーション起動前に実行しDBにジョブを登録してからアプリケーションを起動するようにします｡
sidekiqのジョブレコードと､ジョブレコードに対応したsidekiq-cronのスケジューリングレコードをDBに登録するようにします｡
これでアプリケーションを起動すると一定間隔でジョブを実行するようになります｡
生成AIの発展してもエンジニアの仕事はなくならないと思う
生成AIが発展したらエンジニアの仕事が奪われるのではないかって話をよく見かけます｡最近はコード生成を超えてアプリケーション生成みたいなのが出てきてますからなおのこと｡
個人的にはエンジニアの仕事の形が変わるってだけではないのかなーと思っています｡
手工業から機械化が進んだとて､その作業の成果物自体に意味があるのなら仕事は残りました｡人間の役割が変わるだけで成果物を作ること自体は消えないと思います｡なのでどれだけスムーズに自分の役割を変えていけるか､が大事じゃないかなと思います｡
大仰な話じゃないけれど以前自転車パーツの磨き上げをやったことを思い出しました｡自家作業だったので手作業で金属部品を研磨して磨き上げたんですが､非常に時間がかかりました｡実際の生産現場では手作業で研磨することはまずなくて機械で代替えしてるし､なんなら研磨不要で塗装してるケースもある｡人間の手作業じゃなくてもよいという､生成AIみたいな話です｡
これについては､磨き上げの最終的な価値は美麗な外観の提供なので､誰に何を提供するのか理解していれば手作業にこだわって仕事がなくなることも無いと思うのです｡手作業のほうが最終的なクオリティが高くなることはありますし､機械による生産はほどほどのクオリティでとどまりますから､そのへんはどの水準のアウトプットを出していくかで考えは変わるのではないかなと｡誰に何を提供するかが大事で､自分の立ち回りを柔軟にしていけるといいですよね｡
ところで､技術書で有名なオライリーの創立者 オライリーさんがこんな記事を出していました｡
概要としては現在主流のプログラミングも変化の末によるもので､効率化が進んでもエンジニアの仕事は増えてきた｡なので､今回の生成AIもエンジニアの仕事が変わるだけで仕事自体は増えるだろうみたいな｡（自動翻訳を読んでの要約なので適当な部分はご容赦を）
私はオライリーさんに同意ですね｡
学習の「上から」と「下から」
t_wadaさんのポストが良かったので備忘録的にブログにする
書籍『プログラミングRust 第2版』は本当に良かった pic.twitter.com/qhRzNU3kB5
— Takuto Wada (@t_wada) 2025年1月30日
私はt_wadaさんと違って上から技術を学習していくことが多いし､その技術の意義がわかっていた方が理解が捗るというのが理由｡手を動かさないことには若干の危機感は持っていたりする｡
たぶんt_wadaさんは見識が広いから大体ボトムアップで取り組んでも過去の類型に当てはめてその技術を受け止める（理解する）ことができるんじゃないだろうか｡
いずれは私もボトムアップ的に技術をキャッチアップできるようになるのかな？なれるといいなあ｡
学習の方向性を縦軸で捉えることを再認識できたので､冒頭のポストはとてもよかったです｡
学習の周期の話と1月に取り組んだ学び
12月から大体1ヶ月に1個､テーマを決めて深堀りして技術を学ぶことを始めました｡基本的にNotionにまとめていてブログにアウトプットはしていない｡
ブログに書いたりして投稿回数稼いでもいいんだけど､ブログ一記事のボリュームでうまいことまとめられることもできないし､それで時間がかかるのがもったいないのでNotionで「自分が学んだこと」を記録していくイメージで書き出している｡
ちなみに､12月のテーマは「データベース」で､SQLから始めてDB設計の書籍を読んでみて､その後にPostgreSQLの技術書を読んだりした｡おおまかにデータベースの役割や運用､取り扱いとPostgreSQLならではな部分を総ざらいした感じに理解が進んだ｡レプリケーションとか業務で出てくるけどよくわからなかったからね｡進歩してると思う｡
今月はネットワークを集中的に取り組んだ｡OSIってなんだ？ネットワークとか実際よくわかんねーなって思ってたレベルだったのでこちらも理解が進んだ実感がでるところまできた｡
やり方としては､自分でも「いらんかも...」っていうような初級レベルから学習を始めることがよい｡まじで｡その水準で知識に歯抜けがあるとやっぱり上のレイヤの知識が身につかないから｡
ネット上でよく「おすすめの入門書」みたいなのが紹介されてるんだけど､こういうのは実際にその技術のことをよくわかっていない入門以前にはレベルが高すぎることが多い｡レベルに合わない教材は吸収に時間がかかるし､モチベの維持も難しくなるからやめたほうがよい｡
今回のネットワークであれば､Udemyの「ネットワークエンジニアを目指す初心者はここから始めよう！「ゼロから学ぶネットワーク基礎」豊富な図解で徹底解説」をファーストステップの教材にした｡こういうときにUdemyの教材は入門以前の教材も多いのでうってつけだと思う｡個人的に動画+字幕でメモを取りつつわからないところを繰り返し視聴するようにしている｡
1ヶ月で一つの領域というのはともすると少ないかもしれない｡自分でもちょっと思ったりもする｡とはいえ､子育て中だし､英語は並行してほそぼそやってるし､会社の輪読会で違う領域やってるから別にいいじゃんって感じ｡納得させて折り合いをつけるしか無い｡
このあたりはフィヨルドブートキャンプにいた頃に「知らない領域を学ぶ大変さ」を骨身まで思い知らされて今につながっている｡あの頃はプラクティスがどうしようも進めなくなって､質問の回答も意味不明だった末に､理解が足りないことに気づいて腰を据えて学ぶことに気づいた｡今は腰を据えて取り組むことを基準にできているので､そういう意味でもあの頃の経験は良かったんだと思う｡
