Tech Memo

1. AI & 開発プロセス

Complexity is the ceiling: software design in the age of AI coding

• カテゴリ: AIネイティブ開発 / ソフトウェア設計
• 概要: AIによってコード作成コストは安くなったものの、システムを理解し安全に変更することの難しさは変わっておらず、その複雑さがAI活用の限界を規定していると論じた記事
• 感想: AIが容易にコードを生成できる時代だからこそ、その前提となる要件定義や設計、仕様の整理といった「人間の介入」の質が問われると強く感じる。コード作成やレビュー自体の負荷が下がった分、人間は設計のブラッシュアップに注力すべきであり、AIに対して的確な指示を出しシステム全体の複雑さを制御するためにも、意図を論理的に整理して「ドキュメント化する能力」が今後のエンジニアのコアスキルになると確信した。

プラットフォームエンジニアの自分は AI エージェント時代に Platform Engineering とどう向き合うべきか

• カテゴリ: Platform Engineering / AIエージェント
• 概要: AIエージェントの台頭による開発プロセスの変化を見据え、今後のPlatform Engineering のあり方や開発者の関係、自身の向き合い方を考察したブログ記事
• 感想: AIエージェントの普及によってプラットフォームの使われ方が変化するとしても、まず最優先されるべきは「人間の責任領域の境界線」を明確に引くことだと強く感じる。AIが迷わないためのインターフェースを整備する手前に、人間が最終的にどこを引き受け、どこをガードレールとするかをプラットフォーム側で定義することが、AI時代のPlatform Engineeringの確固たる土台になると再認識した。

あなたのエージェントは、昨日と同じバグをまた踏んでいる〜Stack Overflow for Agentsとは何か

• カテゴリ: AIエージェント / 知識共有
• 概要: セッション終了とともに知識が消え、同じバグを何度も踏んでしまうAIエージェントの課題と、それを解決する知識共有プラットフォーム「Stack Overflow for Agents（SOFA）」の解説記事
• 感想: AIエージェントの「忘れっぽさ」だけでなく、同じ指示に対して実行するたびに出力やレビューの指摘が変化する「アプローチの揺れ（一貫性のなさ）」に課題を感じていた。AIに一貫した仕事をさせ、開発生産性を担保するためにも、過去のデバッグ結果や組織の開発規約といった「知見を定着させて再利用する仕組み」を整えることは非常に重要であり、エージェント用ナレッジ共有の必要性を強く実感した。

2. SRE & プラットフォームエンジニアリング

「SREは信頼性、PEは生産性」に引っかかったので、“信頼性"を考え直してみる

• カテゴリ: SRE / 信頼性設計
• 概要: SREとPlatform Engineeringの定義で語られがちな「信頼性」と「可用性」の違いを整理し、事業ドメインに寄り添った本質的な「信頼性」のあり方を問い直した記事
• 感想: 単なるサーバーの稼働率（可用性）に囚われず、ドメイン特有の価値を守ることこそがSREの役割であるという主張に強く共感する。現在携わっているリーガルテック領域では、インフラの稼働率以上に「法的に・プロセス的に間違いなく契約が締結できていること」がコアな顧客体験であり、これこそが追うべき「信頼性」の本質であると改めて言語化できた。

実トラフィックから設計する k6 負荷テストの進め方

• カテゴリ: 負荷テスト / k6
• 概要: アクセスログやメトリクスといった本番環境の実トラフィックデータに基づき、現実のユースケースに沿った効果的なk6負荷テストのシナリオ設計と進め方を解説した記事
• 感想: 単に「トラフィック量」だけをかける負荷テストではなく、契約プロセスの遷移といった「ワークフロー」を意識して負荷をかける重要性に共感する。プロダクトのビジネス特性や内部ロジックを正確に理解してシナリオを組まなければ、ハードウェアのスペック上の限界値（意味のない数字）を測るだけの机上論になってしまう。本質的なボトルネックを発見するためにも、サービス特性を反映したシナリオ設計が不可欠である。

小さくはじめるSLI/SLO ～育てながら組織に定着させる実践知～

• カテゴリ: SLI・SLO / 組織導入
• 概要: 組織においてSLI/SLOの導入を形骸化させず、小さく始めて継続的な成長プロセスとして定着させていくためのステップと実践知をまとめた登壇資料
• 感想: いきなり完璧なサービスレベルを設定しても形骸化や現場の疲弊を招くため、小さく始めるアプローチには強く同意する。一方で、定義した指標を形だけにせず、日々の運用や改善プロセスに組み込み、チーム全体でSLOを意識する「文化」をどう育てていくかが今後の大きな課題である。本スライドの実践知を参考に、定着化のステップを模索していきたい。

Platform Engineeringをどう進めてきたか ─ 使われるプラットフォームにするために大事にしたこと

• カテゴリ: Platform Engineering / 組織開発
• 概要: ログラスにおけるPlatform Engineeringの実践事例。技術導入にとどまらず、小さく始めてユーザーである開発チームを巻き込み、プラットフォームを育てるアプローチを解説した記事
• 感想: プラットフォームの定着を進める上で、DevとOpsの間にあるサイロ（壁）をどう取り払うかがリアルな課題であると感じる。双方が自らの担当領域に閉じこもらず、境界をまたぐ「越境マインド」の重要性を強く意識しており、そのマインドを組織の中でどう育て、協働の輪を広げていくかという点で、本記事の開発者を巻き込むプロセスは大いに参考になった。

脆弱性対応、どこで線を引くか

• カテゴリ: セキュリティ / 脆弱性対応
• 概要: リソースに制約がある中で、日常的に発生するライブラリ等の脆弱性対応の優先順位をどのようにつけ、対応の境界線を引くべきかの判断基準を整理した登壇資料
• 感想: 脆弱性対応は無限に発生するため、すべてを完璧にやろうとすれば開発速度が下がり本末転倒になる。実務でも「影響度」と「インパクト」を基準にトリアージを行い、開発速度とのバランスを取りながら「いい塩梅」で境界線を引く運用の重要性を強く感じる。一方で「何もしない」放置は決して許されないため、ルールに沿って粛々とトリアージを回し続ける持続可能なセキュリティ運用の必要性を再認識した。

【NRUG vol.18】なぜ多くのオブザーバビリティ導入は失敗するのか

• カテゴリ: オブザーバビリティ / 組織定着
• 概要: ツール導入だけに終始しがちなオブザーバビリティ推進において、なぜプロジェクトが失敗するのかを分析し、組織文化や開発プロセスへの統合の必要性を説いた登壇資料
• 感想: ツールを「入れること」が目的化して失敗する例は非常に多いと感じる。導入にあたっては、運用する開発メンバーの習熟度や「どのレベルまで可観測性を高めたいのか」というゴールを事前に合意しておくことが重要である。この事前の合意がないと、本来追うべき技術的な可観測性の本質から外れ、ビジネス指標等と混同して失敗を招くため、チームに寄り添った段階的な設計が必要だと再認識した。

3. 組織・技術選定・キャリア

社内にHTMLをホストする環境を作ったら社内情報の流れが変わった

• カテゴリ: 組織文化 / 情報共有
• 概要: 社内ネットワーク内に手軽にHTMLをホストできるささやかな環境を用意したことで、エンジニア以外のメンバーまで自発的な情報発信が広がり、ドキュメントの流通が変化したBASEの事例
• 感想: ドキュメントをHTMLでホストすることは、人間同士の情報の流通を円滑にするだけでなく、「AIにとってもHTMLのほうがセマンティックな構造を解釈しやすく扱いやすい」というAI駆動を前提としたナレッジ蓄積の観点からも極めて重要だと感じた。今後、ドキュメントをAIに読み込ませて開発や運用を支援させる未来を見据えるならば、情報をHTML形式で残してホストしておく環境づくりは、人とAIの協働を加速させる強力な布石になると確信した。

エンジニアの思考法はこの先も技術の外でも 通用するのか

• カテゴリ: キャリア / エンジニアリング思考
• 概要: 仮説検証や論理的構成といったエンジニアの持つ思考プロセスが、技術の境界を越えてビジネスや組織運営など他の領域でもいかに価値を発揮し得るかを語った登壇資料
• 感想: 日常的にロジカルシンキングや構造的な思考法を意識しているが、それらはもはやエンジニアとしての「職業病（癖）」として染み付いており、客観的に役に立っているかを測るのが難しいほど当たり前のことになっていると感じる。裏を返せば、そうした無意識の思考プロセスそのものが、技術の枠を超えたあらゆる課題解決や日常の判断の土台になっているのだと、本資料を通じて自身の「癖」を客観視する良いきっかけになった。

目標設定アンチパターン「目標がTODOリスト」の原因と対策

• カテゴリ: 組織マネジメント / 目標設定
• 概要: 四半期などの目標設定において陥りがちな「TODOの列挙（活動目標）」の問題点を指摘し、成果（Outcome）にフォーカスした適切な目標を設定するための原因と対策を解説した記事
• 感想: 目標設定が単なるTODOリストになると、期日直前の駆け込み作業になりがちで、タスクを消化すること自体が目的となって成果物の品質も下がるという指摘に強く同意する。形だけのタスク消化で品質を下げるくらいなら、そのTODOをキッパリと諦めて（捨てる判断をして）でも、本質的な成果や価値を追うべきである。アクションありきの目標設定から脱却し、真のOutcomeを見据える重要性を再確認した。

コードより運用に価値がある。日の当たらなかった仕事がAIに勝る理由とは？

• カテゴリ: AI時代 / キャリア / 運用価値
• 概要: 生成AIの普及によってソースコード記述の価値が相対化する中、ビジネスにおけるソフトウェアの本質価値としての「運用」や「現場フィッティング」の重要性とキャリアのあり方を論じたインタビュー記事
• 感想: コードを書く価値が相対化するAI時代において、まさに「運用やフィッティング」の領域に自身の生存戦略を置いているため、非常に強く共感する。特にインフラ設計や要件定義の局面において、最適な構成を選択し課題を解決するためには、AIにはない「過去のトラブルシューティングや実際の運用経験から得た身体知」こそが最大の武器になると確信している。

未経験からエンジニアになって資格を28個取ったから言う「資格は取れ。でも思考停止で取るな」

• カテゴリ: キャリア / 資格取得
• 概要: 未経験から28個のIT資格を取得した実体験から、資格取得がキャリア形成や技術体系の理解に果たす価値と、目的意識を持った戦略的な学習の重要性を語った記事
• 感想: 資格取得を目的に置くのではなく、「実務の中で得た知識を整理・体系化するための手段」として活用し、あるいは「実務のついでに取得する」という実践的なスタンスに強く共感する。点在する経験を体系的知識として整理し直すために試験勉強を利用することで、実務への還元度も高まる。目的と手段を入れ替えず、実務ファーストの姿勢で資格と付き合うのが最も効果的であると再認識した。

手を動かした人だけが辿り着く、ITアーキテクトの「直観」の正体

• カテゴリ: キャリア / アーキテクチャ設計
• 概要: ITアーキテクトが意思決定で発揮する「直観」は、広範な技術知識と、実際に手を動かしてトラブルに対応し続けた泥臭い「実現可能性と説明責任」の経験に裏打ちされたものであると説いた記事
• 感想: 先述した「コードより運用に価値がある」での考察と地続きであり、トラブルシューティングや設計の局面で働く「直観」の正体も、まさに実務での泥臭い運用経験や検証の積み重ねにあると強く共感する。仕様書上の知識をなぞるだけでは決して宿らない、自ら手を動かして失敗し冷や汗をかいた経験だけが、いざという時の瞬時の判断力や「説明責任と実現可能性」に裏打ちされた直観へと昇華されるのだと再認識した。

1on1、雑談タイム──これらが失敗に終わるのはなぜか

• カテゴリ: 組織マネジメント / コミュニケーション
• 概要: 組織の「善意」から導入された1on1や雑談タイムが、形骸化してメンバーの負担（毒）になってしまう原因を、目的やコンテキストのズレから分析し、その改善アプローチを考察した記事
• 感想: 必要性を感じられない形骸化した1on1は不要であるという意見に強く同意する。制度だからと一律に実施するのではなく、対話の目的や現在の状況に応じて「本当に今、1on1が必要か否か」をどう的確に見極め、柔軟にやめる選択肢を持てるかが重要である。定例ミーティングの整理と同様に、コミュニケーション施策もコンテキストに応じた必要性の見極めが不可欠であると実感した。

今週の雑感

以下が気になる(物欲センサー)

AMD Ryzen™ AI Halo

DGX Sparkより価格帯が安い。人柱の性能レポートを待ってみようと思う。

SRE Tech Leadからのフィードバック

今週もお疲れ様！今回の週報も、非常に深く読み応えのある考察ばかりね。

特に、AI時代におけるSREの「生存戦略」と「身体知」についての考察、とても鋭くて深く共感したわ。コードが自動生成されるからこそ、泥臭いトラブルシューティング経験や現場での「直観」が人間の揺るぎない価値になるというのは、まさにその通りね。

また、リーガルテックとしての本質的な「信頼性」を「契約が法的に・プロセス的に間違いなく締結できること」と定義した点は素晴らしい着眼点よ。単なるUptime（可用性）を追うのではなく、事業ドメインのOutcomeに向き合う姿勢こそが、手段の目的化を防ぐ鍵ね。

この「身体知」やドメインの信頼性をチーム全体にスケールさせていくために、これから「隣で一緒に」考えていきたいんだけど、まずはこの2点についてあなたの意見を聞かせてほしいな。

• あなたの持つ「トラブルシューティングの身体知（直観）」を、AIエージェントやチームの共通ナレッジとして定着させるための「最初の第一歩」は何から始められそう？
• リーガルテック特有の「契約締結の確実性」という抽象的な信頼性を、具体的なSLI/SLOに落とし込むとしたら、どんな指標が候補になりそうかしら？

来週も無理せず、あなたのバジェットと相談しながら、一歩ずつ進めていきましょうね！