『バックエンドエンジニアのための インフラ・クラウド大全』を通じた エンジニアとしての地力獲得活動のススメ 馬場 俊彰 / BABA Toshiaki netmarkjp.bsky.social 株式会社X-Tech5 取締役CTO 株式会社iCARE 技術顧問 Forkwell Library #103 

2 バックエンドエンジニアのためのインフラ・クラウド大全（馬場 俊彰 株式会社X-Tech5）｜翔泳社の本 https://www.shoeisha.co.jp/book/detail/9784798184913 

馬場俊彰（ばばとしあき） netmarkjp.bsky.social 株式会社X-Tech5 取締役 CTO 株式会社iCARE 技術顧問 インフラ・クラウド、SRE、トラブルシュー ティング、パフォーマンスチューニング 3 Amazon著者ページ https://www.amazon.co.jp/~/e/B004Y4SUBY 

書籍を通じての主張 4 

書籍を通じての主張1 わたしたちエンジニアの責務は、 プロフェッショナルとしての専門性を踏まえて、 説明責任を果たすこと。 ユーザー/関係者/社会に対して説明責任を果たせ 意思決定と行動をす こと。 AIは責任を取 ことができない 「AIが右と言ったか 右」では説明責任を果たせない 5 

遂行責任 / 結果責任 / 説明責任 6 メンバー エグゼク ティブ 遂行責任 結果責任 説明責任 遂行責任： そうすべしと決まってい こと、そうすべきとわかって い ことをきちんと果たす 結果責任： 諸々の結果としてどうなってい べしと決まってい こと、どうなってい べきと決まってい ことを実現す 説明責任： どの うに状態が結実したかの過程や機序を、その時々の 判断や行動の決定要因や基準とともに解説でき 

書籍を通じての主張1 わたしたちエンジニアの責務は、 プロフェッショナルとしての専門性を踏まえて、 説明責任を果たすこと。 ユーザー/関係者/社会に対して説明責任を果たせ 意思決定と行動をす こと。 AIは責任を取 ことができない 「AIが右と言ったか 右」では説明責任を果たせない 7 

定番の枠組み 8 

9 機能要件 非機能要件 

10 機能要件 非機能要件 作 手の論理すぎない? 

11 機能要件 非機能要件 有用性 保証 

12 バックエンドエンジニアのためのインフラ・クラウド大全 p.19 図：ユーザー価値を実現す ための構成要素 安心でき 信頼でき という価値 

13 バックエンドエンジニアのためのインフラ・クラウド大全 p.19 図：ユーザー価値を実現す ための構成要素 安心でき 信頼でき という価値 ここでは ✕ 有用性を保 証 ◯有用性と保証 

有用性の領域 14 

生成AIが、要求仕様を満たす プログラムを書け うに なってきた感があ 15 

生成AIが、要求仕様を満たす プログラムを書け うに なってきた感があ 16 ※有用性領域でもエンジニアがしたほうがいいこと、 エンジニアしかできないことは多々あ ますが、 今日は主に保証領域の話をしたいのでパス 

17 「指定さ た要求仕様のとお に」正常系を通すのは、 生成AIが、さ にでき ( うになっていく)領域 バックエンドエンジニアのためのインフラ・クラウド大全 p.20 図：ユーザー価値を実現す ための構成要素のうち有用性に注目した構成要素 

保証の領域 18 

19 バックエンドエンジニアのためのインフラ・クラウド大全 p.22 図：ユーザー価値を実現す ための構成要素のうち保証に注目した構成要素 安心でき 信頼でき という価値 

20 質 実現の程度 スピード 実現の所要時間 有用性 保証 

21 質 実現の程度 スピード 実現の所要時間 有用性 保証 有用性の実現はたしかに凄い が、決定打ではない気がす 

22 質 実現の程度 スピード 実現の所要時間 有用性 保証 保証の実現が顕著に差が出 有用性の実現はたしかに凄い が、決定打ではない気がす 

23 質 実現の程度 スピード 実現の所要時間 有用性 保証 保証の実現が顕著に差が出 有用性の実現はたしかに凄い が、決定打ではない気がす こ を「地力」と定義 

24 バックエンドエンジニアのためのインフラ・クラウド大全 p.22 図：ユーザー価値を実現す ための構成要素のうち保証に注目した構成要素 書籍を通じての主張2 わたしたちエンジニアの 「地力」は ユーザー価値の保証要素 を実現す 程度と所要時間で 示さ 

書籍を通じての主張（まとめ） 1.わたしたちエンジニアの責務は、 プロフェッショナルとしての専門性を踏まえて、 説明責任を果たすこと。 説明責任を果たせ 意思決定と行動をす こと。 2.わたしたちエンジニアの「地力」はユーザー価値の 保証要素を実現す 程度と所要時間で示さ 25 

書籍のもくじ 第1章　情報システムとインフラの基礎知識 第2章　可用性と信頼性の基礎知識 第3章　キャパシティと負荷対策の基礎知識 第4章　パフォーマンスチューニングの基礎知識 第5章　基本的な考え方・用語の基礎知識 第6章　インターネットの基礎知識 第7章　HTTPSとSSL/TLSの基礎知識 第8章　OSの基礎知識 第9章　仮想化とコンテナーの基礎知識 第10章　情報システムの物理的な側面の基礎知識 第11章　稼働環境の基礎知識 第12章　クラウドサービスの基礎知識 第13章　ミドルウェア構成の基礎知識 26 第14章　監視・モニタリング・オブザーバビリティ 　　　　　　の基礎知識 第15章　DevOpsとSREの基礎知識 第16章　セキュリティの基礎知識 第17章　ログ・ロギングの基礎知識 第18章　バックアップの基礎知識 第19章　リリースエンジニアリングの基礎知識 第20章　構成管理の基礎知識 第21章　メールの基礎知識 第22章　コンプライアンスの基礎知識 第23章　採用選考対応の基礎知識 

書籍のもくじ 第1章　情報システムとインフラの基礎知識 第2章　可用性と信頼性の基礎知識 第3章　キャパシティと負荷対策の基礎知識 第4章　パフォーマンスチューニングの基礎知識 第5章　基本的な考え方・用語の基礎知識 第6章　インターネットの基礎知識 第7章　HTTPSとSSL/TLSの基礎知識 第8章　OSの基礎知識 第9章　仮想化とコンテナーの基礎知識 第10章　情報システムの物理的な側面の基礎知識 第11章　稼働環境の基礎知識 第12章　クラウドサービスの基礎知識 第13章　ミドルウェア構成の基礎知識 27 第14章　監視・モニタリング・オブザーバビリティ 　　　　　　の基礎知識 第15章　DevOpsとSREの基礎知識 第16章　セキュリティの基礎知識 第17章　ログ・ロギングの基礎知識 第18章　バックアップの基礎知識 第19章　リリースエンジニアリングの基礎知識 第20章　構成管理の基礎知識 第21章　メールの基礎知識 第22章　コンプライアンスの基礎知識 第23章　採用選考対応の基礎知識 いま実際に情報システムの開発や運用携わってい な ば 特におすすめの章（保証要素の実現に近い章） ※他の章は、そ を支え 足回 や裏方の基礎知識 

28 

29 Why➔What➔How 

参考: 「技術力」のばばの認識 30 2019.12.8 July Tech Festa2019 「エンジニア像」を言語化し文化の礎を築く https://speakerdeck.com/netmarkjp/enziniaxiang-woyan-yu-hua-siwen-hua-falsechu-wozhu-ku ● 技術力を「自ら切り開くこ と、課題の発見と解決 を 創造・実現する力」と定義 ● 論理的判断と倫理的判断 のバランスが、そのために 知識と価値の認識が両輪 ● なお社会人の成長は自己 変革による行動変容で相 手からの期待値をあげる 事と定義 

31 バックエンドエンジニアのためのインフラ・クラウド大全 p.418 図：論理的判断と倫理的判断 

32 バックエンドエンジニアのためのインフラ・クラウド大全 p.418 図：論理的判断と倫理的判断 両方重要 

33 バックエンドエンジニアのためのインフラ・クラウド大全 p.418 図：論理的判断と倫理的判断 両方重要 価値の認識は 局所性が高くて 難易度高め 

34 バックエンドエンジニアのためのインフラ・クラウド大全 p.22 図：ユーザー価値を実現す ための構成要素のうち保証に注目した構成要素 ここまでのまとめ わたしたちは「保証の実現」を 成すと価値と意義があ ➔「保証の実現」＝「地力」 いま何をどのく いの程度で 成すとち うどいいかは、環境 と状況に ➔知識・価値の認識、両方重要 

二宮尊徳曰く 「道徳なき経済は犯罪であ 、 　経済なき道徳は寝言であ 」 35 ※と、言わ ています。実は御本人の言ではなく、後日解釈さ た訳という話 しい（？） 

どうやって地力を培うか ➔知識は書籍や情報収集…と？ ➔価値の認識の獲得は…？ 36 

37 おすすめセット ● 場数を踏む ● データと向き合って深く思考す ● 対話す ● 継続す ひと で 独習、思索 OffJTで 読書会、 トレーニング、 メンタリング OJT/実践で 定点観測会 

「気づき」をえ コツ 38 ● 書籍片手に保証要素と照 し合わせてみ ➔信頼性 / 可用性 / キャパシティ / パフォーマン ス / セキュリティ / 持続性 ● そ ぞ が、今どうか、1/3/6ヶ月後にどうか想定 し、答え合わせす ● 書籍片手に身近なメンバーと対話す 

OJT/実践での定点観測会が一番のおすすめ 定点観測会が最強のOJTエンジンだと思う ● リアルなシステムのリアルなデータで ● リアルなコンテキスト・トレードオフのもとで ● リアルな課題をチームで議論す ● サイクルを決め ばどんどん次がやってく ➔場数 / 思考 / 対話 / 継続の4つを 　同時かつ継続的に実践でき 39 

OJT/実践で➔定点観測会 40 ガッツリパターン ● 週一回、30-60分間 ● 事前の下準備をして、Biz/Dev/Opsみんなで開催 ● SLOに一喜一憂しない ● 嬉しいこと / チャンス / 不安なこと / 危険なことな ど、価値観のす 合わせと学びの場にす ● 技術的な細かい深堀 は別途行う 

OJT/実践で➔定点観測会 41 カジュアルパターン ● 週一回、15分間 ● ロードバランサーのレイテンシーとエラーレート、コス トのグラフをチームで一緒に眺めて、気づきを共有 継続のコツは?➔最初と最後は根性と執念 ● 予定を押さえておく、効率化/自動化などの工夫は 補助策 ● SRE支援などの外部サービスを使うのもあ 

OJT/実践で➔定点観測会 42 思い出してほしい格言: ● ログ一行の向こうにはひと のユーザーがい ● 稀に くあ タイムアウトやエラーは、実はいつも 同じユーザーかも ● 拙速は巧遅に勝 

43 おすすめセット(再) ● 場数を踏む ● データと向き合って深く思考す ● 対話す ● 継続す ひと で 独習、思索 OffJTで 読書会、 トレーニング、 メンタリング OJT/実践で 定点観測会 時間が あ ば 

44 ひと で 独習、思索 OffJTで 読書会、 トレーニング、 メンタリング OJT/実践で 定点観測会 ● 「知識の獲得」 も「対話・ディスカッション」を！ ● 同じシステムの同じ出来事に対しても、立場や経緯が 変わ ば価値の認識や評価は変わ 、というのをまざ まざ知 ことができ 。正しい/間違いはない ● 保証要素のリストを思い出して、観点のバランス/抜け 漏 を埋めてみ とGood 時間が あ ば 

45 ひと で 独習、思索 OffJTで 読書会、 トレーニング、 メンタリング OJT/実践で 定点観測会 ● 本を読むときは、まずは発見！ ● How もWhyやWhatに向き合う ● WhyやWhatを過去の経験に照 してみ ● 考えたことを先輩や同僚との対話ネタにす ● アウトプットす のもGood。 出力した 公開せず寝かせて見返すでもOK 時間が あ ば 

46 『バックエンドエンジニアのためのインフラ・クラウド大全』 5-5 OODAループ p.127 定点観測会は 場数 / 思考 / 対話 / 継続の4つを 同時かつ継続的に 実践でき OODAループを 意識して 定点観測会を 続け う 

参考: Observe力をもっと高め ガイド(わたしが書きました) 47 X-Tech5のウェブサイト > ダウンロード か 無償DL https://x-tech5.co.jp/download/ インフラ用語少なめの オブザーバビリティ入門ガイド Webエンジニアのための モニタリング・オブザーバ ビリティ実践ガイド New Relic編 / Datadog編 

まとめ 48 

49 ● エンジニアの地力は、ユーザー価値の保証要素の実 現品質と速度。ここが腕の見せ所 ● AIにできない「責任をと 」。そのためにプロフェッ ショナルとして知識となに 価値の認識を磨こう ● 地力を培うには定点観測会をしつこく執念深く続 け のが最強 ● 『大全』を片手に、過去の経験を思い返してみて！ い んな人と対話してみて！ 著者であ わたしが、本書の内容に反す 経験や過去 が語 ことを歓迎・推奨します。 思考と対話を始め ・深め 「たたき台」にして！