■ 1. 概要
- 発表者はTimeeのプラットフォームエンジニアリングチームに所属する徳富博
- Aurora MySQLを使用するサービスの急成長で顕在化した7つの罠とその対処法を紹介する
- 急成長の文脈として以下の3点が挙げられる
- アクセス数の急増によりボトルネックが顕在化
- データ量の急増によりクエリ処理速度が低下しインデックス設計の重要性が増大
- 開発者増加によりMigration頻度が増加しALTER TABLEのロック影響が無視できなくなった
■ 2. 罠①: DDL実行時の落とし穴
- メタデータロック（MDL）に関する誤解:
- 「オンラインDDLならロックはゼロ」という誤解が存在する
- アルゴリズムに関わらずMDLは必ず発生する
- ALGORITHM=COPYは開始から完了まで排他MDLを継続保持しDMLが完全にブロックされる
- ALGORITHM=INPLACEは初期化・実行・最終フェーズの3段階でMDLを取得する
- ALGORITHM=INSTANTは最終フェーズ（commit table definition phase）でのみ排他MDLを取得する
- MDL待機の発生フロー:
- DMLが共有MDLを取得した状態でALTER TABLEが排他MDLを要求し待機する
- 後続のSELECT/UPDATEが共有MDLを取れずキューに詰まる
- アクセス数が多いプロダクトではこれが大きな問題になる
- Aurora固有の挙動:
- Vanilla MySQLではMDL待ちがレプリカ側に溜まり待機する
- Aurora MySQLではDDL反映がクラスターボリューム共有によりほぼ即時反映される
- Auroraリードレプリカでは実行中のクエリが強制終了（Lost connection）される
- MDL待ちは溜まらないが単発エラーが発生する
- Aurora lost connectionへの対応:
- Rails 7.1から導入された自動リトライ機能を活用する
- lost connectionエラー発生時に一定回数クエリを自動リトライするよう設定する
- ALTER完了後にリトライが成功しアプリ側にはリカバリされる
- 外部キー制約追加時の注意（COPYアルゴリズム強制）:
- foreign_key_checks=1（デフォルト）のまま外部キーを追加するとCOPYアルゴリズムが強制される
- COPYアルゴリズムではテーブル全コピーの間INSERT/UPDATE/DELETEが完全停止する
- migration実行前にSET SESSION foreign_key_checks=0を実行することでINPLACEになりDMLを止めずにオンライン実行できる
- ただしforeign_key_checks=0は整合性チェックをスキップするため実行前にデータ整合性を確認する
- 外部キー追加時の参照先テーブルへのSロック:
- COPYアルゴリズムでは既存データを新テーブルへコピーする際に参照先テーブルの整合性チェックが走る
- InnoDBはその間参照先テーブルにSロック（共有ロック）をかけ続ける
- 親テーブルへのUPDATE/INSERT/DELETEはXロックが必要なためSロックと競合しタイムアウトが発生する
- foreign_key_checks=0でINPLACEにすることで子テーブルのCOPYが走らず参照先テーブルへのSロックも発生しない
■ 3. 罠②: Drop Table中にMDLによるデッドロックが大量発生
- MySQLのレイヤー構造の理解:
- MySQLサーバーレイヤー（SQL Layer）がメタデータロック（MDL）を管理する
- InnoDBストレージレイヤーが行ロック・ギャップロック・ネクストキーロックを管理する
- 一般的にイメージするデッドロックはストレージレイヤーのものだが今回のデッドロックはサーバーレイヤーのもの
- SHOW ENGINE INNODB STATUSに出ないデッドロック:
- MDL（メタデータロック）はサーバーレイヤーで管理されInnoDBロックモニターの対象外
- SHOW ENGINE INNODB STATUSやinnodb_print_all_deadlocksには出力されない
- Datadog/CloudWatchにも何も出ない
- Performance Schemaのmetadata_locksテーブルで確認可能
- MDLデッドロックの発生メカニズム（DROP TABLE + FK）:
- セッション①がordersテーブルをSELECTし共有MDLを保持する
- セッション②がFKを持つ子テーブルcustomers_ordersをDROP TABLEしようとする
- DROP TABLEはcustomers_orders・customers・ordersの排他MDLを順次要求する
- ordersの排他MDLはセッション①の共有MDLが邪魔し待機する
- セッション①がcustomersをSELECTしようとするがセッション②がcustomersの排他MDLを保持中
- セッション①はcustomers待ち・セッション②はorders待ちとなり相互待機（デッドロック）が発生する
- 再発防止策:
- DROP TABLE前に外部キー制約を先に削除することで排他MDLの競合対象を最小化する
- Migration前に本番環境で参照先テーブルへのDMLが走っていないことを確認してから実行する
■ 4. 罠③: Auroraの場合レプリカの重いクエリがWriterに影響する
- 問題の概要:
- Redashによる数時間の集計クエリがReader上で実行されていた
- AuroraはWriter/Reader間でクラスターボリューム（Undoログ）を共有する
- Readerで長時間トランザクションが実行されるとUndoログがパージできなくなる
- 古い行バージョンが蓄積しRollbackSegmentHistoryListLengthが増大する
- 共有ボリュームを通じてWriter側のクエリ劣化が発生する
- 対策（トランザクション分離レベルの活用）:
- 集計クエリには分離レベルをREAD COMMITTEDに設定することでUndoの肥大化を抑制できる
- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED を実行してから集計クエリを実行する
- REPEATABLE READ（デフォルト）はNon-repeatable readとPhantom readを防ぐがUndoログ蓄積が多い
- READ COMMITTEDはNon-repeatable readとPhantom readが起きうるがUndoログ蓄積が少ない
- 集計系はリアルタイム整合性より安定稼働が重要でREAD COMMITTEDで十分なケースがほとんど
■ 5. 罠④: 同時リクエストによるデッドロック
- パターン①: ギャップロックデッドロック:
- ギャップロック（Gap Lock）はインデックス上の「レコードとレコードの間の隙間」に対してかかるロック
- SELECT FOR UPDATEでレコードが存在しない場合その検索範囲に他トランザクションがINSERTできないよう封鎖する
- Gap Lock同士は競合しないため複数トランザクションが同じギャップにGap Lockを取れてしまう
- INSERTはGap Lockと競合するためお互いのGap Lockに阻まれた状態で相互ブロックが生まれやすい
- 発生シナリオ: TxAとTxBが同時に「email3を検索してなければINSERT」を実行する
- 両者がGap Lockを取得後INSERTを試みると相手のGap Lockに阻まれ相互待機（デッドロック）が発生する
- 対策①: INSERT IGNOREまたはINSERT ON DUPLICATE KEY UPDATEを使い1クエリで完結させGap Lockを取らないようにする
- 対策②: FOR UPDATEをやめ存在確認のみなら共有ロックまたはロックなしにしXロックが本当に必要かを設計から見直す
- パターン②: S→X昇格デッドロック:
- SロックはSELECT LOCK IN SHARE MODEで取得し他のSロックとは競合しない
- XロックはSELECT FOR UPDATE/UPDATE/DELETEで取得し全てのロックと競合する
- SロックをXロックに昇格しようとすると相手のSロックが邪魔になり相互ブロックが発生する
- 発生シナリオ: TxAとTxBがFKを持つ子テーブルにINSERT後親テーブルをUPDATEする
- FK INSERTでInnoDBが親テーブルの参照行にSロックを自動取得する（S同士は競合しないので両方成功）
- その後UPDATEでXロックが必要となるが相手のSロックが邪魔で待機する
- TxAはTxBのSロック待ち・TxBはTxAのSロック待ちとなりデッドロックが発生する
- 対策①: UPDATEを先に実行することで先にXロックを取得し後続のFK INSERTのSロック取得を同一TX内のXで成功させる
- 対策②: INSERT前にSELECT FOR UPDATEで先にXロックを取得し順番待ちにすることで相互ブロックを回避する
■ 6. 罠⑤: 意外に広いロック範囲
- パターン①: UPDATEでテーブル全体がロックされる:
- インデックスなしのUPDATEではテーブル全体をスキャンし全行に排他ネクストキーロックがかかる
- 本来1ユーザーだけ更新したいのにテーブル全体がロックされ他トランザクションのINSERT/UPDATE/DELETEがほぼ停止する
- 対策: 適切なインデックスを追加することでロック範囲を劇的に狭める
- パターン②: 外部キー制約で親テーブルにSロックが伝播する:
- group_usersにINSERT/DELETEするとInnoDBが参照整合性チェックのため参照先の親行にSロック（共有ロック）を自動取得する
- バルク処理が大量のSロックを保持し続けると退会・更新系APIのXロック取得がブロックされる
- 対策: バルク処理を小さいバッチ（例: 100件ごと）に分割して途中でCOMMITしSロックの保持時間を短縮する
■ 7. 罠⑥: 急成長でじわじわ悪化するスロークエリ
- 問題の構造:
- リリース直後はデータ数が少なくフルスキャンでも数msで問題なし
- 数ヶ月後にデータが数百万件に増加し同じクエリが数秒に悪化する
- 急成長期にそのエンドポイントへのアクセスも急増し処理が詰まりはじめる
- 最終的にタイムアウト多発・接続枯渇・DB負荷急上昇という障害に至る
- データ量の増加×アクセス数の増加が「無害だったクエリ」を障害の引き金にする
- 気づきにくい理由:
- リリース時のレビューでは少量データでテストしており問題が見えない
- データ増加は緩やかなため劣化が少しずつ進み気づくのが遅れる
- コード変更なしで突然遅くなるため原因特定に時間がかかる
- AIコードレビューでもクエリの実行計画までチェックできない
- Datadog Database Monitoringによる改善体制:
- 発見〜改善のフローは「トレースで検知 → 実行計画を確認 → AIが仮説を提示 → チームが修正」
- スロークエリの検出: 実行時間・頻度でランキングし問題クエリを一目で特定できる
- 実行計画の可視化: EXPLAINの結果をUIで視覚的に確認しFull Scan/非効率な結合を検知する
- AIによる改善提案: 実行計画をもとに適切なインデックス構成をAIが自動提案する
- チームの自律改善: SREを介さず各開発チームが自分たちのクエリを改善できる
■ 8. 罠⑦: データ増加でBuffer Poolが足りなくなる
- InnoDB Buffer Poolとは:
- テーブルのデータページ・インデックスページをメモリにキャッシュする領域
- クエリ実行時MySQLはまずBuffer Poolを確認しヒットすればメモリから返す
- ミスすればストレージから読み込みBuffer Poolに保存する（Read I/O発生）
- AuroraではBuffer Poolサイズ = DBInstanceClassMemory × 3/4で自動計算される
- 急成長期に起きること:
- データ量の増加によりワーキングセットがBuffer Poolを超えはじめる
- 一度読み込んだデータが追い出され次のクエリでまたストレージから読み直す
- インデックスの増加によりBuffer Poolを消費しインデックス自体もページとしてキャッシュされるため無計画な追加は逆効果になりうる
- 結果として毎クエリでストレージから読み直しが発生しRead I/Oが急増しクエリが急激に遅くなる
- 監視すべきメトリック:
- Buffer Pool Hit Ratio: キャッシュヒット率でここが下がるとストレージ読み取りが急増する
- Read IOPS/Read Latency: Buffer Poolミスが増えると連動して悪化する
- Buffer Pool使用率: 100%張り付きはワーキングセットがBuffer Poolに収まりきれていないサイン
- チューニングのアプローチ:
- インスタンスサイズアップ
- パラメータチューニングでbuffer poolサイズを増やす
- 不要なインデックスを削除する
■ 9. まとめ: どう向き合うか
- レイヤーを意識する:
- サーバーレイヤー（MDL）なのかInnoDB（行ロック）なのかで観測方法・対策が全く異なる
- 「どのレイヤーで起きているか」を最初に問う習慣を持つ
- 仕組みを理解してから運用する:
- 「InnoDBバッファプール」「MVCC/Undoログ」「メタデータロック」の概念を知っているだけでトラブルシューティングの精度が格段に上がる
- 高トラフィックは「通常では起きない」競合を日常化する:
- 理論上起きにくい競合もリクエスト数が増えれば確率論的に必ず発生する
- 設計段階から競合を想定したロック設計・インデックス設計を行う
- 改善を積み重ねる:
- 単発の対応で終わらせずポストモーテム→再現実験→予防策→モニタリング追加のサイクルを回す
- Aurora運用知識そのものがプロダクトの継続性に直結する
■ 1. 現代マネジメントの根底にある「軍事的世界観」
- 「戦略」「戦術」「VUCA」など日常的なビジネス用語の多くは軍事用語が起源
- 目標設定・フィードバック・人材育成研修などのマネジメント手法も戦争の文脈で発展
- 軍事的マネジメントの目標は個人を視野狭窄な歯車（ボット）にすること
- 上層部の計画を末端まで正確にインストールし効率よく遂行させる手法が現代マネジメント理論のベース
■ 2. キャリア観の「地動説的」転換
- かつては会社への滅私奉公・理不尽な異動への耐性が標準的な価値観
- 現代は「自分の人生をどうハッピーにするか」という個人の問いが根底にある
- 会社は個人の人生の構成要素の一つに過ぎないという価値観へと転換
- 旧来の「危機感を煽る」手法は現代では離職を招くだけ
- 人材流動性が高まり恐怖や危機感による統率が不可能になっている
■ 3. 「冒険的世界観」へのパラダイムシフト
- あらゆるマーケットが飽和し「何を作れば正解か」が誰にも分からない時代
- トップダウンの命令で人を機械のように動かす軍事的世界観は限界を迎えている
- これからは働くメンバーの「好奇心」や「内発的動機」を資源とした組織づくりが求められる
- 会社の事業成長と個人のキャリア・やりがいの異なるベクトルをすり合わせシナジーに変えることが現代EMの役割
■ 4. 冒険的な組織になるための四つのアプローチ
- 【1】SMARTの呪縛を解きALIVEで意味付ける（目標のマネジメント）:
- SMARTの法則（Specific・Measurable・Time-bound等）は管理側には有効だが被評価者の内発的動機を高めない
- ALIVEの法則（Adaptive・Learningful・Interesting・Visionary・Experimental）で内発的動機を引き出すバランスをとる
- EMの役割は目標そのものをALIVEに変えることではなく目標をALIVEなものとして解釈できるよう「意味付け」すること
- 変化が激しい時代には「Adaptive」が特に有効でキャリアへの汎用性を対話で紐付けるとよい
- 前期の振り返りでメンバーの「興味の芽生え」をヒアリングし次期目標にストーリーテリングで紐付けることが重要
- 【2】メンバーと自分の「興味の偏り」をメタ認知する（興味のマネジメント）:
- 変化が激しい時代に「3年後どうなりたいか」と聞いても「特にない」という反応が返るのがリアル
- 将来目標ではなく「現在進行形で何を面白いと思っているか」という興味を育成の手掛かりにすることが現代的
- 好奇心（瞬発的・散漫な感情）と興味（好奇心が特定対象に定着・深化した状態）は異なる
- 散漫な好奇心を興味として定着させる技術の有無が問われる「興味格差の時代」になる
- 成果を出してEMになった人は「事」への関心が強く「人」への関心が薄いため「マネジメントが罰ゲーム」と感じやすい
- 「事」寄りのEMは人間のメカニズムを工学的・システム的に捉え直すことで「人」への技術的な興味が芽生えることがある
- それでも困難な場合は「人に興味があるメンバー」を右腕として連携マネジメントを行う方法がある
- 【3】オープンクエスチョンがメンバーの主体性を削ぐ（会議のマネジメント）:
- 人間の主体性・創造性が発揮される最小単位は「目の前の選択肢から選ぶこと」や「対象に点数をつけること」
- 真っ白な状態からオープンクエスチョンに答えるには高い主体性と創造性が必要
- 会議では「100点満点で何点か数字だけ書いてください」と問いかけることで全員の参加を促せる
- 数字が出揃った後に「なぜその点数か」「あと何点上げるには何が必要か」と深掘りすることで具体的な意見が引き出せる
- 1on1でも同様に「A・B・Cのうち一番面白かったのはどれ」と過去の案件から選ばせることで主体性が引き出せる
- 選択肢から選んだ理由こそがメンバーのやりたいことや今後増やしたい仕事の種
- 【4】風土に流されず独自の価値基準を意図的に作る（文化のマネジメント）:
- 風土（Climate）はチームが感じる雰囲気であり文化（Culture）はその組織固有の「価値基準」
- 価値基準とは「AよりもBを大事にするという判断の集合体」
- EMが「自分のチームは何を一番大事にするか」という価値基準を定めメンバーに意図的に刷り込み続けることが必要
- 重視したい価値観を日常のルールや習慣に組み込み体現しているメンバーを称賛することでカルチャーが醸成される
- チームの価値基準をEMが意図的に構築することがメンバーの判断の迷いをなくし自律的なチームの土台となる
■ 5. 「半径5メートル」から冒険をはじめる
- 現代のEMがマネジメントに苦戦するのは個人のスキル問題ではなく軍事的マネジメント手法と現代の価値観のズレが原因
- 組織全体を変えることは難しくても自チームの「半径5メートル」であれば今すぐ変えられることは多い
- メンバーの小さな好奇心に目を向け問いの投げかけ方を変えることが次の時代のマネジメントへの第一歩
■ 1. 見積もりが難しい理由
- 見積もりは未経験・未確定の事柄を数値化する行為であり本質的に精度が低い
- 人は無意識に最良シナリオを基準とする楽観バイアスを持つ
- 「早くしてほしい」という圧力に根拠なく応じるとバッファのない計画が生まれ破綻時にエンジニアが責任を問われる
- 見積もりは「予測であって約束ではない」とステークホルダーと共有することがPMの重要な役割
■ 2. 代表的な見積もり手法
- ストーリーポイント:
- スクラム開発で使用し工数を時間ではなく複雑さ・不確実性の相対値で表現する
- フィボナッチ数列（1・2・3・5・8・13・21）を使用する
- チームのスプリント消化ポイント数（ベロシティ）を計測しスケジュール予測精度を向上させる
- プランニングポーカーで全員が同時にカードを出すことで認識齟齬を検出し議論する
- 三点見積もり（PERT見積もり）:
- 楽観値・最頻値・悲観値の3シナリオから期待値を算出する
- 計算式は「（楽観値 + 4×最頻値 + 悲観値）÷ 6」
- リスクを織り込んだ結果が得られるためステークホルダー説明やスケジュール表作成に適する
- 類推見積もり:
- 過去の類似タスク実績をもとに見積もる
- 見積もりと実績の継続記録が精度向上の前提となる
■ 3. バッファとスコープ管理
- バッファは水増しではなく仕様認識齟齬・外部API変更・レビュー修正など想定外事象へのリスク対策
- MoSCoW法で要件をMust have・Should have・Could have・Won't haveの4分類に整理する
- プロジェクト開始時にステークホルダーと分類を合意しておくことで圧縮要求に対してスコープ取捨選択で応じられる
- 圧縮要求への対応方針:
- スコープ削減交渉として「工数削減は困難だが特定機能をフェーズ2に回すことで納期短縮できる」と提示する
- リスク明示として「短縮にはレビュー簡略化が必要であり品質リスクが上昇する」と許容可否を確認する
■ 4. 見積もり精度を上げるコツ
- タスクを1〜2日以内の小単位に分解することで不確実性を低下させる
- 見積もり後に実際の工数を記録しスプリント振り返りで差分を分析して次回精度を向上させる
- プロジェクト開始時に不確実性の高いタスクを早期特定しスパイク（調査タスク）を先行して実施する
■ 5. 手法の使い分け
- ストーリーポイント: スクラムなどイテレーション開発・チームベロシティ管理に向く
- 三点見積もり: 納期重視・ステークホルダー説明が必要な場面に向く
- 類推見積もり: 過去実績あり・素早く概算を出したい場面に向く
- 見積もりは「当てるものではなく不確実性を管理するためのツール」であり外れることを前提にバッファを持ち実績記録で精度を継続改善することがPMに求められる
■ 1. 概要・目的
- 本資料はNick Tune著「Architecture Modernization」の組織論に関する章を中心に解説した講演資料
- モダナイゼーションを技術ではなく組織の視点で説明し明日からの行動に繋げることを目的とする
- 対象読者はモダナイゼーションに迫られたビジネスリーダーと会話をするエンジニア・モダナイゼーションに知見をつけたいエンジニア・エンジニアとの折衝を行うビジネス職
■ 2. モダナイゼーションと「組織」の問題（第1・2章）
- モダナイゼーションの障壁は技術の問題ではなく組織の問題である
- マイクロサービスに移行したのにデプロイは遅くなった
- 技術的負債の返済を始めたが半年で元の優先度に戻った
- 新アーキテクチャを設計したがチーム間の調整コストが爆発した
- モダナイゼーションが必要な理由は変化が必ず起きて競争優位性を保てなくなるため
- 業界の変化（新規参入・新製品・既存市場）
- 自社組織と外部技術の変化（メンバー離脱・技術シフト）
- 国内・世界情勢の変化（法律・関税・調達コスト増加）
- モダナイゼーションの定義は技術の刷新だけではなく技術・組織・文化の変革である
- 目指すのは「持続可能な高速フロー」
- アイデアから本番環境への迅速かつ安全なデリバリー
- 複数年にわたって維持できる能力
- コンウェイの法則によりソフトウェアの高速なフローを実現するには組織構造が密接に関係する
- システムを設計する組織はその組織のコミュニケーション構造をコピーした設計を生み出す（Melvyn Conway 1968）
- コンウェイの法則の力を無視してアーキテクチャを考え出そうとするとミスマッチが生じ多くの摩擦と問題が生じる（Martin Fowler）
- コンウェイの法則が裏目に出た事例（旅行会社）
- マーケティングIT部門とIT部門（プラットフォーム）が断絶していた
- プラットフォームAPIの信頼性が低くてもマーケティングIT側が責任を押し付けられた
- 技術的回避策（プラットフォームのデータ同期機能の構築）を選んだ結果として同期維持に認知負荷の大部分が消費された
- 教訓：ソフトウェアアーキテクチャが組織のコミュニケーション機能不全を反映してしまった
- 組織の準備確認として5つの問いを経営層に投げかける必要がある
- ビジネスリーダーは新機能開発の速度を落とす覚悟があるか
- レガシーシステムの変更が複雑で時間がかかることを理解しているか
- 予期せぬ事態が発生し大幅な遅延やコスト増加が生じた場合どう反応するか
- 予算の仕組み・作業の優先順位付けを変えチームに権限委譲する準備があるか
- 学習とスキルアップに十分な時間と資金を投資する意思があるか
- 経営層との合意形成には技術用語をビジネス言語に翻訳することが必要
- 技術的負債 → 機会損失コスト（競合は2週間で出せるものが自社は3ヶ月）
- リファクタリング → 市場投入速度の改善（新機能の開発に本来の3倍の時間がかかっている）
- アーキテクチャ刷新 → 事業継続性のリスク低減（現行システムを理解する人が2名のみ）
- 合意形成の実践アプローチは3つのステップで構成される
- ステップ1：現状を可視化する（DORAメトリクスによるデリバリー速度の定量化・障害対応コストの集計・技術的負債による機会損失の列挙）
- ステップ2：小さく始めて信頼を得る（いきなり全面刷新を提案せず3〜6ヶ月で成果が見えるパイロットを提案・成果をビジネス指標で報告）
- ステップ3：継続的にコミットメントを維持する（定期的な進捗報告をビジネス言語で行い・割り込みによる影響を可視化し数字で示す）
■ 3. モダナイゼーションに必要な組織の姿（第11・13章）
- チームトポロジー（Matthew Skelton & Manuel Pais 2019年）はソシオテクニカルなアプローチ
- 組織とソフトウェアの設計を同時に最適化する体系的なアプローチ
- 目的はチームの自律性と高速なフローの実現
- 4つのチームタイプと3つのインタラクションモードで構成される
- ソシオテクニカルとは社会システム（人間・組織）と技術システムを別々のものではなく相互依存し合う一つのシステムとして捉える概念
- 5つの基本原則
- 持続可能な高速フロー：速度と品質はトレードオフではない
- 小規模で長期的なチーム：5〜9人の安定したグループ
- チームファーストの考え方：人は「リソース」ではない
- You build it you run it：開発から運用まで一貫した責任
- 認知負荷の最小化：チームが扱える範囲に責任を制限
- 原則の実践（フローとチーム）
- 持続可能な高速フロー：高パフォーマンスチームは1日に複数回デプロイしダウンタイムも少なく回復も迅速（DORAの4つのキーメトリクスで自組織の現在地を測定可能）
- 小規模で長期的なチーム・チームファースト：5〜9人で信頼を維持しすべての作業は個人ではなくチームに向けられ目標設定と評価もチーム単位でチームはなるべく解散をしない
- 原則の実践（責任と認知負荷）
- You build it you run it：運用性を考慮した機能開発が自然に行われ他チームとのデプロイ調整が不要になりフローが大幅に高速化（7digitalの実例では各チームが毎朝ダッシュボードで確認し運用しないチームでは見たことがない良い品質が達成できている）
- 認知負荷の最小化：認知負荷には課題内在性（軽減困難）・課題外在性（削減すべき）・学習関連（増やしたい）の3種類があり高い兆候は過度のコンテキストスイッチとデリバリーペースの低下であり対処法はサブドメインが大きすぎる場合に複数の小さなサブドメインに分割すること
- 4つのチームタイプ
- ストリームアラインドチーム：バリューストリームに端から端まで責任を持つ（組織の大多数）
- プラットフォームチーム：ストリームアラインドチームの認知負荷を軽減する共有機能を提供
- コンプリケイテッドサブシステムチーム：高度な専門知識を要する複雑なサブシステムを担当
- イネーブリングチーム：新しい技術やプラクティスの習得を支援（終了条件あり）
- 内部開発者プラットフォーム（IDP）のポイント
- プラットフォームチームの役割はストリームアラインドチームの認知負荷を軽減すること
- セルフサービスで利用でき開発者体験（DX）が優れていることが重要
- 「薄いプラットフォーム」から始めチームの実際のニーズに基づいて段階的に成長させる
- 既存のクラウド（Google Cloud・AWS・Azureなど）を組織構造に合わせてカスタマイズして利用する
- 3つのインタラクションモード
- コラボレーション：2チームが密接に協力して共通目標を達成（認知負荷：高い）
- X-as-a-Service：明確に定義されたサービスを提供しinterfaceに従い利用（認知負荷：低い）
- ファシリテーティング：一方が他方のスキルアップや目標達成を支援（認知負荷：中程度）
- ポイント：コラボレーションは有用だが認知負荷コストが高くメリットが正当化できなければXaaSに切り替えるべき（チームの疎結合）
- チームトポロジーの設計は一度設計して終わりではなく継続的な見極めが必要
- 進化が必要なサイン：過度のコラボレーション（ドメイン境界が最適でない）・過度のコンテキストスイッチ（認知負荷が高すぎる）・デリバリーのペースが遅くなっている・過度なデリバリー調整（境界と変化が整合していない）
- 数年ごとの大規模な組織再編ではなく絶えず見極めて進化できる組織を構築すべきである
■ 4. モダナイゼーションを推進する組織（第15章）
- AMET（アーキテクチャモダナイゼーションイネーブリングチーム）の定義
- モダナイゼーションの慣性の力に立ち向かう一時的なチーム
- ワークショップ開催・コーチング・優先度の維持を通じてモダナイゼーションを推進
- 最終的にAMET自体が不要になる状態を目指す（一時的な足場）
- AMETではないもの：全モダナイゼーション作業を担う「モダナイゼーションチーム」・すべてのアーキテクチャを設計する「中央集権的アーキテクトチーム」
- AMETが解決する6つの課題
- 着手できない・分析麻痺 → モダナイゼーションを始動させる
- 他業務との競合で進捗が遅れる → 高い勢いを維持する
- 設計の知識・経験不足 → よりよい設計を支援する
- 従来手法への後戻り → 持続可能な変化を促進する
- 関係者がモダナイゼーションの価値を理解できない → ビジョンを周知し続ける
- ある分野の学びが他で活かされない → 学びを共有・展開する
- AMETの活動プロセス（3〜6ヶ月で始動し役割を終えたら外す）
- ヒアリングとマッピングのツアーで問題とモダナイゼーションの機会を発見
- キックスターターワークショップ（数日間対面）でビジョンの認識を合わせる
- 3〜6ヶ月以内で成果を出す具体的な行動計画を策定
- AMETの関与度は時間とともに低下し最終的に組織自身がモダナイゼーションを主導する
- 意思決定と方向性を主導
- ファシリテートから見学に後退
- 1対1コーチングでリーダーの能力を確認
- リーダー自身が主導・AMET解散
- 意思決定の分散にはアーキテクチャアドバイスプロセスを適用する
- 誰でもアーキテクチャに関する決定を下せるが影響を受ける人々と専門家に事前に相談することが条件
- ADR（Architecture Decision Records）で議論と決定を記録する
- 原則と社内版テクノロジーレーダーを意思決定の指針にする
- 週1回1時間のアーキテクチャ相談フォーラムを開催する
■ 5. モダナイゼーションを根付かせる組織（第17章）
- モダナイゼーションの成否は学習にかかっている
- モダナイゼーションが野心的であるほど学習への投資がより必要
- 継続的に「進化」を続ける必要がある
- 多くの新スキルの習得には数ヶ月を要する
- 計画・予算の段階で学習コストを考慮しないと将来の問題になる
- 学習の始め方は種をまき育てること
- 読書会のような小さな種から始める
- 同僚から尊敬されているインフルエンサーに権限を与え「トレーナー養成」方式でスキルを伝播
- 小さな成功体験を積み重ねる
- 主な学習手法
- コミュニティ・オブ・プラクティス（CoP）：共通の関心を持つ人々の定期的な集まり
- バイトサイズアーキテクチャセッション：月2回・45〜60分でチーム間の知識を広め集団的理解を深める
- メンタリングプログラム：明示的なプログラムとして確立し人事評価と同等に扱う
- モブ/ペアプログラミング：実践を通じた最も効果的な学習
- 社内テックカンファレンス：年1〜2回の知識伝播と一体感の創出
- 事例：PayFit（フランス/HRテックユニコーン/約1000人）
- エンジニアリングディレクターがDDD読書会を開始（隔週）しスタッフエンジニアと数名のマネージャから他のメンバーを巻き込んだ
- 2年かけて成長し経営陣を通し全社的な「単一の給与計算ドメインに対して」ドメインディスカバリーとモダナイゼーションを実施
- 「給与期間」を「6人が7つの異なる意味で使う」状態を解消
- 事例：Infor（CloudSuite）（アメリカ/Eコマース/約20人）
- アーキテクチャ変更の前にまず技術的卓越性の構築に注力
- Samman Methodで学習文化を育成しボトムアップでコアドメインを特定
- 逆コンウェイ操作（理想のアーキテクチャに基づきチームを組成）を段階的に適用
- Samman Method（Emily Bacheによる）
- ラーニングアワー（Learning Hours）：日々の業務から意図的に切り離された短時間（通常1時間程度）の集中学習セッションでコードカタなどを使い安全な環境で新しい技術や概念を練習する
- アンサンブルワーキング（Ensemble Working）：ラーニングアワーで学んだ技術を実際のプロダクションコードに適用していく実践プロセスでチーム全員（3〜6人程度）が一つの画面を共有し協力してコードを書くモブプログラミング形式
- 学習を組織のDNAに組み込む実践ポイント
- 学習活動は通常の勤務時間内に組み込み他の業務と同等に扱う
- メンバーのメンタリングを追加業務ではなく人事評価で同等の重要度として扱う
- 経営陣や上位層が学習を奨励していると感じさせる環境をつくる
- 7digitalの事例：月に2日間の学習時間・毎週数時間の議論タイム（CTOが強く奨励）によりすべてのチームが毎日プロダクションにデプロイし入社初日にデプロイしバグは昼食前に解決
- 学習文化のアンチパターン（優秀な人材の流出につながる）
- CTOがカンファレンス参加費を半額しか出さない
- チーフアーキテクトがカンファレンスを公然とバカにする
- メンタリングを追加業務として課しつつ同じ作業量を期待する
- 変革を技術的なものだけと考え合意形成なしに進める
- 逆コンウェイ操作を現在のシステム制約を無視して適用しようとする
■ 6. AI Agent時代の組織を考える
- 2025年以降Coding AI Agentが急速に発展
- Claude Code・GitHub Copilot・Gemini CLI Agent mode・Devin・Cursor Agentなど
- コード生成だけでなく調査・設計・テスト・リファクタリングまで一貫して実行
- 「エンジニア1人あたりの生産性」の前提が変わりつつある
- AI Agentでも変わらないもの：モダナイゼーションの本質的な難しさはコードではなくコンテキストにある
- ドメイン知識のヒアリング：「給与期間」を6人が7つの意味で使う問題はAIでは解決できない
- 組織間のコミュニケーション：部門の断絶・責任の押し付け合いは人間の課題
- ビジネスコンテキストの理解と意思決定：何をモダナイズすべきか・優先順位は何か
- AI Agentで加速できること
- 現状の可視化：レガシーコードの構造分析・依存関係の整理・ドキュメント生成
- PoCの高速作成：新アーキテクチャの検証用プロトタイプを数時間で構築
- 移行の自動化：コードの機械的なリファクタリング・テストの自動生成
- 学習の加速：コードベースの説明・ペアプログラミングの相手としての活用
- ポイント：AI Agentは「手を動かす速度」を上げるが「正しい方向」を決めるのは組織であり効率の良い「作業環境」を作るのも組織
- AI Agentを入れただけでは変わらないことが調査で示されている
- チームレベルでは改善あり（タスク完了数+21%・マージされたPR数+98%・1日あたりのPR処理数+47%）
- 組織レベルでは改善なし（全社スループート有意な相関なし・DORA指標改善なし・品質KPI改善なし）
- PRレビュー時間+91%・バグ発生率+9%という下流のボトルネックが価値を吸収（Faros AI 2025・10,000名以上の開発者テレメトリ分析）
- AI Agentを武器にするための組織の条件
- AI Agentの効果は組織の成熟度に比例する
- ドメイン知識が属人的 → Agentに正しい指示が出せず的外れな成果物が量産される
- チーム間にコミュニケーション不全 → Agentが生成したコードが他チームの前提と矛盾する
- 学習文化がない → Agentの使い方がチーム間で共有されず効果にばらつき
- ドメイン知識が共有されている → Agentに的確な指示を出せ高品質な成果物が得られる
- チームの自律性が高い → Agentを活用した素早い意思決定と実装が可能になる
- 本書の組織論を実践することがAI Agent時代の競争優位に繋がる
- AI Agent導入を経営層に伝える際のビジネスインパクト
- AI Agentを導入したい → モダナイゼーションの投資対効果を数倍に高められる
- 開発者の生産性が上がる → 新機能の市場投入を現在の半分の期間で実現できる
- 注意：Agentの導入にもコストがかかる（ライセンス・ガバナンス整備・学習時間）のでパート1で述べた合意形成のアプローチが必要
■ 7. まとめ：明日からできること
- 持続可能な高速フロー（ゴール）を実現する全体構造
- 土台：リーダーシップのコミットメント
- 必要な組織の姿（チームトポロジー）：5つの原則・4つのチームタイプ・3つのインタラクション
- 推進する組織（AMET）：始動・勢いの維持・段階的縮小
- 根付かせる組織（学習文化）：種をまく・CoP/メンタリング・DNAに組み込む
- 個人・複数人として明日からできること
- 読書会を始める（1冊・2人から）
- バイトサイズアーキテクチャセッションを試す（月2回・45分）
- 自チームの認知負荷を振り返る
- チームとして明日からできること
- DORAメトリクスで現在地を測定する
- チームの自律性レベルを確認する（ロードマップの決定権はあるか）
- You build it you run itを始める（小さく・1つのサービスから）
- 組織として明日からできること
- リーダー層に5つの問いを投げかける
- AMET的な役割を検討する
- 学習を通常業務と同等に扱う制度を設計する
■ 1. LSPの歴史的背景と意義
- LiskovとWingの1994年論文で行動的型付けとして定式化された概念
- 事前条件・事後条件・不変条件を含む振る舞いの保存を要求
- マーチンは1996年にC++のパブリック継承を律する原則として説明
- 当時の再利用は抽象基底クラスと継承が主役であったため有用な実務原則だった
- LSPが有効だったのは継承中心の設計世界という前提が存在したためであり普遍原則ではない
■ 2. LSPが継承前提の原則であった理由
- 長方形と正方形の問題の本質:
- 数学の包含関係を可変オブジェクトに移植したことが誤りであり正方形が悪いわけではない
- ソフトウェア設計は分類学ではなく契約の設計:
- 設計で問うべきは「同じ仲間か」でなく「同じ契約で扱えるか」
- 共通の操作がなければ親型は不要であり共通の操作があるならそこだけを抽象化すれば足りる
- 古いOOP教育のAnimal-Dog-Catのような例が抽象化の誤解を招く:
- 抽象化の入口が逆向きとなり役に立たない巨大な親クラスが生まれる
■ 3. 現代言語における継承の扱い
- Java:
- sealed classとsealed interfaceでpermitsにより継承できるクラスを明示制限
- ライブラリのクライアントが任意の新種をぶら下げることを防ぐ設計方針
- Kotlin:
- 委譲パターンを実装継承の良い代替として明言しbyによる委譲を言語機能としてサポート
- シールドクラスとシールドインタフェースで直接の下位型をコンパイル時に既知にし外部からの拡張を防ぐ
- C#:
- sealedで他クラスからの継承を禁止
- デフォルトインタフェースメソッドで既存インタフェースを壊さずに拡張する仕組みを提供
- 継承を持つ現代言語でもLSP問題が発生しやすい野放し継承を推奨していない
■ 4. LSPが吸収された先
- ISP（インタフェース分離原則）:
- 利用者が必要とする操作だけを小さく切り出すことで長方形と正方形のような破綻が入口で消える
- DIPと委譲:
- 依存方向を抽象へ向け実装の再利用を継承でなく委譲で行うことで下位型が親の可変状態を持ち回らずに済む
- 委譲中心設計では親の意味を壊しにくい構造になる
- 型検査と閉じた階層:
- TypeScriptの構造的型付けが名前でなく形で互換性を判定
- JavaやKotlinのsealedが階層の増殖を閉じる
- テスト:
- 契約テストや回帰テストとして利用者側の期待を書き代替可能性を確かめる
■ 5. LSPをSOLIDに残し続けることの問題
- 初学者がAnimal継承の例から入ることで設計の最初の問いが「親クラス名は何か」になる
- 抽象化が契約の設計でなく分類の命名にすり替わる
- 実際には半分以上の派生先でアンサポートになる巨大な基底クラスが生まれる
- 「継承を正しく使えば世界をきれいに表現できる」という幻想が延命される
- LSP違反以前の問題として継承構図そのものを最初に作ってしまうことが問題
■ 6. LSPが残る限定的な場所
- 有効な文脈:
- 継承ベースのAPIや古いフレームワーク
- 基底クラス参照で差し替えを前提にしたライブラリ設計
- JavaやC#の標準ライブラリ・既存の業務システム・GUIフレームワーク
- 現在のLSPの位置づけ:
- 「万人向けの基礎教養」でなく「ある設計条件で再登場する専門注意事項」
- SRPやISPのように毎日意識する原則とは性格が異なる
■ 7. まとめ
- LSPはもともと行動的型付けとして生まれ継承中心だった1990年代に有用な実務原則だった
- 現代は継承あり言語でもシールドクラス・委譲・デフォルトインタフェースメソッドでLSP問題を言語機能側で吸収した
- 置換可能性はISP・DIP+委譲・型検査と閉じた階層・テストへと分散吸収された
- LSPは理論として尊重すべきだが現代の一般的な設計においてSOLIDの独立した柱として常設する必要はない
- 継承中心時代の歴史的文脈とともに位置づけ直し必要な場面でだけ取り出して使うほうが筋が通っている
LLMの台頭により、品質の高いコードレビューをできる人は今後いなくなる、ちゃんとソフトウェア設計を理解している人は今後いなくなる、などなどは長期的には正なのかもしれないが（それも若干懐疑的ではある）、それで良いとなるかというとそうでは無いと思ってて、結局資本力等のパワーがある組織はその辺わかってる人材を獲得することで競争力とするのだろうし、「どうせいなくなるのだから知識がなくても良い」と楽観視（悲観視かもしれない）するのは短絡的なんではないかと思いますね
■ 1. 概要
- Goプロジェクトにクリーンアーキテクチャをそのまま適用するとinterfaceが過剰に増殖する問題が生じる
- 問題の本質はinterfaceの個数ではなく「大きすぎるinterface」と「Goの言語特性を活かせていない設計」にある
- Go的思想に則った再設計により問題を解消できる
■ 2. Goの思想との3つのズレ
- 提供側でinterfaceを定義している:
- Go公式Wikiは「interfaceは利用側のパッケージで定義すべき」と推奨している
- 提供側での定義はGoのイディオムに反する
- interfaceが太すぎる:
- Rob Pikeの言葉「The bigger the interface, the weaker the abstraction」に反し1つのRepositoryに5〜8メソッドが存在する
- 抽象化の粒度が大きすぎるため再利用性と柔軟性が低下する
- Preemptive Interfaceが残存している:
- 実装が1つしか存在しないinterfaceはGoコミュニティではアンチパターンとされる
- 不必要な抽象化がコードの複雑性を増大させる
■ 3. 4つの処方箋
- Input Portの廃止:
usecase/port/input/ディレクトリを削除する- Handler層のみでinterfaceを定義しGoの暗黙的interface満足を活用する
- Output Portの選別保持:
- 複数のInteractorが共有する外部サービス連携はOutput Portとして維持する
- 単一Interactorにしか使われないものは廃止対象とする
- RepositoryをReader/Writerに分離:
- 単一の太いinterfaceを読み取り用と書き込み用に分割する
- 各Interactorは必要な操作にのみ依存する設計とする
- ディレクトリ構成の整理:
port/input/を廃止し出力ポートのみ残す- ディレクトリ構造を簡潔に保つ
■ 4. よくある疑問への回答
- 依存性注入の方法:
- structを直接渡すだけでimplicit interfaceにより要件が自動的に満たされる
- 明示的なinterface指定は不要
- interfaceが散らばる懸念:
- private interfaceは利用箇所の直近で定義されるため実運用では管理上の問題になりにくい
- 小規模プロジェクトへの適用可否:
- CRUD中心のアプリケーションではこの複雑な設計は不要との見解が示されている
■ 1. 概要
- リレーショナルデータベースにおける「リレーション（Relation）」と「リレーションシップ（Relationship）」の混同・誤用に対する注意喚起
- E.F. Coddが1970年に定義した用語の正確な意味を踏まえ技術的な精度を高めることを目的とした解説
■ 2. 用語の定義
- リレーション（Relation）:
- ある時点における全行を含む単一のテーブルのこと
- E.F. Coddが1970年の論文で定義した概念
- リレーションシップ（Relationship）:
- 2つのリレーション間の関連・結びつきのこと
- 「2人のfriendの間にfriendshipがあるように2つのrelationの間にrelationshipがある」という類比で説明される
■ 3. 誤用が生じる原因
- 翻訳上の問題:
- 「リレーショナルモデル」を日本語で「関係モデル」と訳すとRelationとRelationshipのどちらを指すかが不明瞭になる
- 日本語語彙の不足:
- 両概念を自然に区別できる日本語の語彙が存在しない
- ソフトウェアの誤用:
- 旧バージョンのMicrosoft Accessがテーブル間の関連を「リレーション」と表記していた（正しくは「リレーションシップ」）
■ 4. 正確な用語使用の重要性
- 個々の誤用は些細に見えることがあるがCoddの基礎的な研究を尊重し誤りを避けることが技術的議論の精度向上につながる
■ 1. Goとの出会いと初期評価の変遷
- 松木氏がGoを意識し始めたのはGo 1.0リリース直後の2012年頃
- きっかけは面白法人カヤック在籍時に同僚のtypester氏（村瀬大輔氏）が「次はGoが来る」と推薦したこと
- 当時カヤックではPerlからの移行先言語を模索していた
- 最初の印象は「かったるい言語」であり動的型付け言語に慣れた身には型定義や制約が面倒に感じた
- 評価が一変したのははてな転職後のサーバー監視サービス「Mackerel」開発への参加
- Mackerelのエージェントはメモリ消費を最小限に抑える必要があり数メガバイト程度で動作するGoが採用された
- コンパイルでシングルバイナリが出力されるため依存ライブラリを気にせずユーザー環境への配布が容易
- この「用途に対する圧倒的な適合性」を目の当たりにしてGoへの評価が一変した
■ 2. Goの開発者体験と静的型付け言語としての強み
- 言語標準でフォーマッターや依存管理などツールチェーンが整備されており環境構築に時間を割かず開発に集中できる
- 開発規模が大きくなるほど型の存在が安心感につながる
- 「ビルドが通ればある程度正しく動く」という信頼感が長期運用において重要
- JavaやScalaと比較した最大の強みはビルド速度とランタイムの軽量さ
- JVMベースの言語はコンテナ技術やマイクロサービス化の流れで起動フットプリントが問題になる
- Goは静的型付け言語でありながらビルドが一瞬で終わり「書いては動かす」サイクルを高速に回せる
- このリズムはスクリプト言語に近く動的言語出身のエンジニアがストレスなく移行できる要因となった
■ 3. インフラ領域からWebバックエンドへの普及拡大
- 初期のGoは並行処理を活かしたマイクロサービスやシステム記述言語用途で採用されインフラ領域から浸透した
- HashiCorpがRubyからGoへシフトしConsulやTerraformといった重要インフラツールをGoで開発した
- DockerとKubernetesがGoで開発されたことがエンジニアコミュニティに決定的なインパクトを与えた
- Webアプリケーションバックエンド開発のメインストリームへの普及は松木氏本人にとっても意外だった
- 当初は「コアとなる複雑なシステムは表現力の高い言語で構築しGoは周辺ツールに使う」構成が最適と考えていた
- 現在はバックエンドのすべてをGoで開発する企業も珍しくなくこの適用範囲の広がりは想定以上
■ 4. Go普及の背景にある言語設計の優位性
- 10年前はGoとScalaが新進気鋭のサーバーサイド言語として二強の時代があった
- Scalaは表現力が高い一方で高度な抽象化が難解さにもつながりチーム全体での保守が多くの組織にとって予想以上に困難だった
- 2010年代前半のWeb業界には静的型付け言語への回帰を求める渇望があった
- 求められていたのは「文法がシンプルでコンパイルが速く安全に書ける型付き言語」であった
- Goは機能が少ない分誰が書いても似たようなコードになりやすく学習コストが低い
- この乗り換えやすさと実用的な型安全性のバランスがWeb開発現場の課題にフィットした
■ 5. 「Less is More」の設計哲学
- Goの設計思想の根底には「一つの目的を達成する方法は一つ（または少数）に限定されるべき」という考え方がある
- 複数の構文やライブラリが存在するとコードスタイルがバラバラになり読み手の負担が増す
- ライブラリ設計においても機能のオーバーラップを避け単一責任の原則が徹底されている
- 「全部入りの巨大フレームワーク」よりも小さな道具を組み合わせる文化
- これはUNIX哲学そのものであり設計者のKen ThompsonやRob Pikeが培ってきた「シンプルさを保つ規律」が反映されている
■ 6. エラーハンドリングの設計
- Goは例外処理機構を持たず戻り値としてエラーを返す仕様
- 最も画期的な点は関数が多値（複数の値）を返せる設計
- C言語では関数は一つの値しか返せず処理結果とエラー情報を扱うためにポインタ渡しが必要だった
- Goでは「戻り値の最後にエラー型を置く」というシンプルなルールで解決した
- Result型やパターンマッチといった関数型言語的エッセンスの導入には慎重な判断が下された
- それらの導入は表現力を上げる一方で言語仕様の複雑化・コンパイル時間の肥大化・学習コスト増大のリスクがある
- 誰が書いても「退屈でつまらないコード」になるよう強制することでチーム開発の可読性と高速ビルドを守っている
■ 7. 長期運用における優位性とAI時代との親和性
- Goの最大の利点は「ゆっくりと着実に進化している」点
- 標準ライブラリや言語機能への追加は厳選されており非互換変更によるコード書き直しが発生しない
- 5年間Goに触れていなかったエンジニアでも現在のGoコードを違和感なく読み書きできる
- Googleという巨大企業が自社開発でGoを使い続けていることがOSSとしての持続可能性を保証する
- Goは「生成AI時代に最も親和性が高い言語」の一つと松木氏は考えている
- gofmtによるコードフォーマットの統一を初期から強制した結果AIが出力するGoコードは品質が安定しブレが少ない
- Goが大切にしてきた可読性はAIが書いたコードを人間がレビューする際にも役立つ
- 学習コストと運用負担の低さおよびAIとの高い親和性からエンジニアの道具箱に入れる価値がある言語である
■ 1. 本稿の概要と分析範囲
- AIによって既存ソフトウェアとほぼ同じ機能を再実装しライセンスを変更する「ライセンスウォッシュ」とも評され得る行為の是非が本稿の主題
- 対象事案はPythonの文字エンコーディング検出ライブラリchardetにおいて2026年3月に起きたAI支援による再実装とGNU LGPLからMITライセンスへの変更
- 分析の対象はリリースノート・再実装プラン・イシューその他の公開ファイルの外形に限定しソースコード全体の実質的類似性の精密比較は行わない
- 本稿は確定的な法的結論ではなく公開資料から見える範囲での法的・実務的な整理である
■ 2. chardetで実際に起きたこと
- chardetはPythonの文字エンコーディング検出ライブラリであり2006年の1.0がMozilla系の実装をPython 2に移植したものであり原作者はMark Pilgrim（以下Mark）
- 2026年2月22日に6.0.0がリリースされ依然としてGNU LGPLが適用されていた
- 2026年3月2日に7.0.0がリリースされ「Ground-up MIT-licensed rewrite of chardet. Same package name same public API」と説明されGNU LGPLからMITライセンスへ切り替えられた
- 2026年3月4日には7.0.1が通常のバグ修正・改善リリースとして公開され7.x系は継続的な開発として位置づけられている
- 現在のメンテナーDan Blanchard（以下Dan）の主張は「同じpublic APIを持つ別実装を一から作ったのだからMITライセンスとして扱える」というもの
- 2026年3月4日にMarkがイシューを立て自らをchardetの原作者と名乗ったうえでrelicenseする権利はなくGNU LGPLへの明示的違反であると主張した
- Markはこれをclean room implementationではないと述べ元のライセンスへ戻すよう求めた
- イシューは2026年3月9日時点でOpenのままでありAssigneeもMilestoneも付いていない
■ 3. 問題点の整理
- 本件の中心的論点は著作権侵害であり7.0.0が旧chardetのderivative work（派生物）に該当するかが核心的争点
- 著作権侵害以外にLGPLを契約と捉えた場合の契約違反やコモンロー上の商標権・不正競争の観点での主張も考え得る
- 7.0.0が旧著作物の複製でも翻案でもない独立実装であればLGPLの拘束をどこまで及ぼせるかは難しくなる
- 複製または翻案が認められればLGPLは一気に重く効いてくる
■ 4. 依拠性から見た評価
- 著作権侵害成立の検討にあたっては日本法では「依拠性」と「類似性」米国法では「access copying substantial similarity protectable expression」が核心的判断軸となる
- 米国法では17 U.S.C. §102(b)によりソフトウェアのアイデア・手順・プロセス・システム・操作方法そのものは保護対象外であり保護されるのは表現のみ
- 依拠性についてはMark側の主張がかなり筋が通っている:
- rewrite planのTask 3においてchardet 6.0.0のcharsets.pyをauthoritative reference（権威ある参照）として使う指示が明記されている
- scripts/utils.pyではtests/dataを旧プロジェクトのtest-dataリポジトリからshallow cloneする仕組みが採用されている
- test-dataリポジトリのREADMEにはライセンスの問題が発生する可能性を認識した記述があり再実装側がライセンス問題を意識していたことが示される
- Dan自身は「古いソースツリーにアクセスできない空のリポジトリから作業を開始しClaudeにはLGPL/GPLライセンスのコードをベースに一切作業を行わないよう指示した」と述べているがrewrite plan側で旧版を参照している以上依拠がないとは言い難い
- AIのトレーニングデータとして旧chardetが含まれていた可能性があり慶應大学の奥邨教授が指摘する「二段の依拠」という観点からもクリーンルーム実装が成り立たないという考え方がある
- 公開資料だけでも旧プロジェクトへの接触と参照は確認でき強い意味でのクリーンルーム実装と呼ぶことは困難
■ 5. 類似性から見た評価
- 米国法における著作権侵害判断では保護される表現の取り込みが必要であり単にプログラムの論理構造や機能が似ているだけでは侵害とはならない
- Computer Associates v. AltaiのAFCテスト（抽象化・濾過・比較テスト）によれば保護されない要素を先に除いた上で類似性を判断する
- rewrite planで参照が指示された旧6.0.0のcharsets.pyはCharsetデータクラスにname is_multi_byte encoding_era language_filterを持つメタデータ表であり新7.0.0のregistry.pyはEncodingInfoにera is_multibyte python_codec languagesなどを持つより拡張された構造になっている
- charsets.pyの多くはメタデータの表であり事実に近い性質のものであるが選択・分類・割当に創造性が認められれば類似性判断が成立する余地はある
- Dan側はJPlagを使用した分析により7.0.0と過去バージョンの最大類似度は1.29%であり他バージョン間の43%から93%と比較して定量的には類似性が低いと報告している
- コード全体の類似性評価では独立実装と受け取ることが可能であるが著作権上はごく一部の保護される表現の取り込みでも侵害が成立し得る点に留意が必要
- 保護される表現の取り込みの程度については公開資料のみでの判断には限界があり法的な観点からの専門的なコード比較分析が必要
■ 6. 結論 - 法的評価
- 公開資料からの暫定評価として本件は「独立実装と断言するには苦しいが直ちに著作権侵害と断定するには足りない」事案
- Mark側に有利な材料:
- rewrite planで旧charsets.pyをauthoritative referenceとして使う指示があることはクリーンルーム実装の主張を弱める
- 少なくともaccessおよび依拠性に近い事情についてはMark側の主張の方が説得力がある
- Dan側の反論として有効な材料:
- charsets.pyは6.0.0系リリースにてDanが新規作成・整備したファイルでありDan自身の著作物と主張し得る
- 旧版参照は機能互換やデータ整合のための参照に過ぎず保護される表現の取り込みを意味しないという反論が可能
- 再実装において保護される表現は含まれていないという反論もできる
- ただしcharsets.pyが旧著作物に依拠したderivative workであればDanに認められるのは新規付加部分に限られ既存権利者の権利を消すことはできない
- 仮に著作権侵害が全面否定されてもLGPL 2.1の受諾を前提とした契約論での争点も残り得る
- Artifex v. HancomやSFC v. VizioなどGPL/LGPLをめぐる法的争点事例が参照される
- 明確に言えることは今回の再実装は強い意味でのクリーンルーム実装とは言い難いということであり法的確定判断には専門的分析が必要
■ 7. 結論 - コミュニティ運営および倫理面の評価
- 同じリポジトリ名・頒布経路を維持できることと旧プロジェクトの実装全体を自己の判断だけで再ライセンスできることは別問題
- 仮に法廷で著作権侵害が認められなかった場合でも同じ機能を持つ全く異なるソフトウェアを同名の同一プロジェクトのアップデートとして扱うことの妥当性が自動的に正当化されるわけではない
- Markの異議表明後も7.0.1が継続リリースされており現時点ではMarkの主張が受け入れられないまま新系統がプロジェクトの後継を名乗って走っている状態
- AIによる全面的な再実装を行い内部アーキテクチャも完全に変えライセンスまでコピーレフトからパーミッシブへ変更するのであれば別のツールとしてリリースすべきであった
- どうしても同じプロジェクト名を維持するなら少なくとも元のライセンスへ戻す方向が混乱を最小化する選択であった
■ 8. AI再実装に関する今後の論点と提言
- AIによる再実装はこれから激増すると考えられるが既存のプロジェクトを同名のままアップデートとしてリリースすることの適否はその事実とは別問題
- コピーレフトからパーミッシブへの変更が歓迎される側面があるとしてもオープンソースから非オープンソースへの再実装も同じ手法で可能になることへの認識が必要
- AIによる全面的な再実装は原則として別ツールとして扱うべきであり人間による継続的開発物とAIによる別実装を同じプロジェクトの同じリリース系統の下で混ぜるべきではない
- AIによる全面的な再実装を既存プロジェクトの後継としてリリースする場合には以下の情報を公開時点で明示する説明責任がある:
- コードの来歴
- 参照した旧資産の範囲
- ライセンス変更の根拠
- 旧権利者との関係
- 互換性と非互換性の範囲
■ 1. AIコーディングツールとAI Slopの問題
- AIコーディングツールは急速に進歩し利便性が高い
- OSS界隈ではAI Slop（AIが生成する低品質なコードやテキスト）が問題となっている
- チームではSlopが人数分だけ増幅され レビューとリワークがチーム全体に波及する
- AIコーディングのメリットを上回る生産性の低下を招く
■ 2. コードの責任と所有権
- LLMがコードを生成しても コミットに名前が刻まれるのは人間である
- 深夜の障害対応で呼び出されるのも人間であり「AIが書いたから」は通用しない
- AIは7〜8割のコードを書けるがプロダクション品質に仕上げるのは人間の仕事である
■ 3. コンテキストの共有とドキュメントの役割変化
- 良いコードには設計の選択理由や棄却した選択肢のコンテキスト共有が必要である
- 従来のコンテキスト共有:
- 隣のシニアエンジニアとの会話やコードレビューで行われていた
- ドキュメントは書かれても読まれないことが多くコンテキストの本体は人の頭の中にあった
- AIへのコンテキスト提供の要件:
- AIには雑談ができないためコンテキストを言語化して書くことが必須である
- AIが必要とするのはコードそのものには書けない設計の選択理由・制約・前提である
- コンテキストウィンドウの制限があるためドキュメントは適切なサイズに整理する必要がある
- 長すぎるドキュメントが読みづらいのは人間も同じであり簡潔さの要件は両者に共通する
- AIの登場によってドキュメントはオーバーヘッドではなく開発のスループットを決める重要な要素となった
■ 4. チームで守るべき原則
- 判断は人間がする:
- AIの提案をそのままコミットしない
- オンコールで呼ばれたとき1000行の変更を説明できる状態を保つ
- コードの品質は時に低くセキュリティ境界（認証・認可・入力検証）はAIが見落としやすい
- 人間が読めるドキュメントを優先して書く:
- 設計意図・制約・決定理由を人間の言葉で記す
- ドキュメントは人とAIが共有するコンテキストである
- AIだけが読む専用ファイル（CLAUDE.mdなど）はあくまで補助であり本体ではない
- 人間向けのドキュメントを充実させればAIへの指示は自然と最小化される
- AIへの指示は「発見できないことだけ」書く:
- コードを読めばわかることを繰り返す必要はない
- AIが繰り返し失敗したこと・プロジェクト固有の制約・ツール選択の理由など「コードベースの外にある知識」だけを補助的に書く
■ 5. まとめ
- コードの責任を取るのは人間である
- 判断は自分で下しコンテキストを言語化し人間が読めるドキュメントに投資する
- AI専用の指示はいずれ陳腐化するが人間のために書いたドキュメントの価値は残る
■ 6. 参照・エビデンス
- 責任の原則:
- Simon Willison（2025-12-18）: コンピュータはアカウンタビリティを持てないためhuman in the loopとしての判断が人間の仕事である
- Matteo Collina（Node.js TSC Chair・Fastify作者 2026-01-18）: コードを出荷するとき名前がついており AIで速く動けても自分の判断を外注することはできない
- Birgitta Böckeler（Thoughtworks Distinguished Engineer 2025-07-09）: 深夜にオンコールで呼ばれるのは人間であり LLMはコンパイラではなく推論器であり使用は常にリスクアセスメントである
- AGENTS.md・コンテキストファイルの実証研究:
- Gloaguen et al.（ETH Zurich 2026-02-12）: 138リポジトリ・5694件のPRを対象とした実証研究。LLM生成のコンテキストファイルはエージェント性能を2〜3%低下させ 開発者が書いても4%改善に留まる一方コストは20%以上増加。不要な要件がタスクを困難にするため人間が書くファイルは最小限の要件のみ記述すべきと結論づけた
- Vercel Engineering（2026-01）: 発見できない知識だけを書いた圧縮インデックスが100%のpass rateを達成
- Upsun Developer Center（2026-02）: CLAUDE.mdは.gitignoreのように扱い エッジケースを発見するたびに育て不要になれば刈り込む
- コミュニティの議論:
- Hacker News（Evaluating AGENTS.md 2026 76ポイント・36コメント）: 論文著者のnielstron本人がスレッドに参加。モデルがセッション開始時にREADMEとCONTRIBUTING.mdを自動でインジェストすべきという提案に著者が賛同。ユーザーpamelafoxがエージェントが失敗したときだけAGENTS.mdに追加し変更を戻して再実行して改善を確認するという実践的な運用法を共有した
- Hacker News（Compressed Agents.md 2026 72ポイント・34コメント）: SkillsよりAGENTS.mdが有効な理由はエージェントが取得するかどうかを判断する必要のない確実な文脈提供にあるという議論が展開された
- ドキュメント・仕様駆動開発:
- GitHub Blog（2025-11）: 2500以上のリポジトリ分析。成功するコンテキストファイルの共通点は「具体的なコマンド・明確な境界・コードで示すスタイル例」である
- Addy Osmani（Google Chrome 2026-01）: 仕様はwhatとwhyに集中すべきであり 巨大な仕様を一度に渡してもコンテキストウィンドウとattention budgetが邪魔をする
- Thoughtworks（2025-12）: 仕様はGateではなくエージェントがリアルタイムで消費し行動するための会話であり 従来のデザインドキュメントと異なり仕様が実際に使われるようになった点が決定的な違いである
■ 1. 結論
- AIが生成したコードのレビューを継続するかを議論する段階はすでに終わった
- 品質を維持したままコードレビューを大幅に削減し続けるよう開発プロセス全体を改善する必要がある
- レビューを軽量化し他の手段に置き換えた組織は品質自体も高くなっていく可能性が高い
- いち早くその状態に到達した組織が大きく飛躍し遅れた組織は淘汰されていく
■ 2. コードレビュー削減が必要な3つの根拠
- 今後コードレビュワーは育てられない:
- コードレビュワーの育成方法としてコードを書いて経験を積む以外の道は確立されていない
- 現行レビュワーと同程度にコードを書く時間を今後確保することはほぼ不可能
- 現在のレビュワーと同程度のコードレビュー能力を持つ人材を今後育てることは難しい
- AIはレビュワーを物量で圧倒する:
- 生成AIの速度は現時点で限界ではなく今後さらに高速化することが確実
- 現時点でもAIが生成するコードの物量に人間のレビューは押され気味であり今後さらに生成量が増加する
- 人間中心のレビューを続けるにはAIによる生成量にブレーキをかける必要がある
- 人間中心のレビューを続ける組織は淘汰される:
- レビューをしない・もしくは軽量なレビューで同等の品質を保てる組織が作れた場合その組織はレビューを続ける組織を淘汰する
- レビュー軽量化による品質維持の実現は十分に可能という手ごたえがある
■ 3. コードレビュー削減に必要な3つの要素
- 高品質なコードを生成できるコンテキストを開発・維持する開発プロセス:
- AIが高品質なコードを生成できる状態を作ることがレビュー軽量化の大前提
- 品質の高い入力コンテキストが重要な要素の一つ
- サービスの性質によってアプローチは異なり単一の形に収束することはない
- 比較的高い頻度で改善が求められるサービスと社会インフラに近いサービスとではまったく異なるアプローチになる
- ビジネス要件の可視化からソフトウェアの手前までを文書化しその文書化自体もAIが支援する形が想定される
- 生成AIの文書化能力はすでに多くの人間の能力を超えており旧来より高いレベルで均質な文書化をすでに実現できている
- 高品質なコードを生成できるハーネス:
- 同じコンテキストを与えてもAIが生成するコードの品質はハーネスの品質に大きく依存する
- ハーネスにはClaude CodeやCodex CLIのような汎用ツールだけでなくプロダクト固有のアーキテクチャやアプリケーションフレームワークも含まれる
- lintや静的解析ツールもコード品質を保証するためのハーネスの一部
- 高品質なローコードプラットフォームがハーネス兼サンドボックスとして機能する可能性がある
- コードより高いレイヤーの評価基準で品質を評価・保証するプロセス:
- コードレビューのような低レイヤーの評価からより高いレイヤーの評価基準への移行が重要
- コンテキスト自体をインプットとしてコード生成とは別プロセスで評価システム自体もAIが生成することが想定される
- 言語化された領域の評価はすぐに人よりAIの方が高い精度でできるようになると予測される
- 最終的に人が評価するのは要求もしくは最上位要件への適合度のみになる可能性があり言語化されていない領域が中心になる可能性もある
- lintや静的解析のような自動化されたコード品質保証プロセスによって人がレビューしていた部分を置き換えていくことが重要
- レビューという考え方自体がプロセスから消えるわけではなく自動化された形で継続する
■ 1. 発表の概要
- KyashのVPoE @konifarが2026年EMConf JPで発表したセッション
- マネージャーに役割が変わった際に提案レベルを上げるための方法を解説
- メンバーから管理職への転換後も提案レベル自体はリセットされず継続して高められる
■ 2. 提案のレベル定義
- レベル0「どうすればいいですか」:
- 提案ではなく指摘で止まっている状態
- 気づきはあるが解決策の選択肢を出せていない
- レベル1「どれにしましょうか」:
- 複数の案を整理して提示できる状態
- 実施スケジュールやリカバリプランなどPros/Consをまとめて伝える
- レベル2「自分はこれがいいと思います」:
- 選択肢の提示に加えて自分の意見と判断根拠を添えられる状態
- 評価軸を設け意思決定に必要な材料を集め思想をのせて伝える
- レベル3「これでいいですか」:
- 複数の立場の意見を考慮したうえで意思決定を促している状態
- 意思決定者が「いいと思う」「じゃあそれで」と短いやりとりで決定できる
■ 3. マネージャーにおける提案の難しさの要因
- 関わる範囲の広がり:
- 横は他部署縦は経営と関わる範囲が拡大し考慮すべき変数が増加
- 「何をどこまで考えて提案すればいいかわからない」「どこで誰と話せばいいかわからない」状態になりやすい
- 考える時間軸の広がり:
- 1年以上先を想像して正解に近づけ続けていく仕事に変わる
- 「そもそも何を提案すればいいかわからない」「不確実すぎて自信が持てない」状態になりやすい
- 取りうる選択肢の広がり:
- 正社員や業務委託の採用を含め組織体制や予算も調整しうるレバーになる
- 「どこまで選択肢を広げて考えるべきかわからない」「どこまで踏み込んで考えていいかわからない」状態になりやすい
■ 4. 適応の方針：理解と覚悟
- 役割と意思決定プロセスの理解:
- 自チームと他チームの役割目標価値観を把握する
- 物事を決め遂行されていくプロセスを理解する
- 決めてやりきる覚悟:
- 正解に近づき続けるマインドセットを持つ
- 宣言と報告軌道修正のリズムを確立する
■ 5. 組織理解のための4つのTips
- 組織図:
- 組織図と職務権限規程を知ることでどこが何の役割を担っているかが見えてくる
- 各チームのマネージャーへの1on1申し込みや食事などで直接把握するのが効率的
- 目標:
- 事業計画や各チームの目標を知ることで価値観や考慮すべきことが見えてくる
- 事業計画を経営や上長にわかるまで聞き隣接チームの目標をマネージャーに確認する
- 会議体:
- 協議と意思決定の会議体の設計を知ることでどこで誰と何を話すべきかが見えてくる
- 他マネージャーのカレンダー確認やアジェンダのAIサマリなどで把握する
- 予算:
- 予算の全体感と決定プロセスを知ることでコントロールできる選択肢が見えてくる
- 予算の考え方や決定プロセスを経理チームや経営メンバーに直接聞く
■ 6. 理解不足による失敗事例
- 失敗例①（2022年頃）組織状態を見て経営への提言:
- 当時はエンジニア含むプロダクト開発組織の立て直しが急務で経営のコミットメントが必須だと考えていた
- 当時の経営目標とのアラインや意思決定プロセスを理解しておらずただ意見をぶつけただけの提案レベル0の状態だった
- 今なら経営目標を確認してそこに到達するための建付けで整理し意思決定前の会議体で起案して組織としての意思決定をリードする
- 失敗例②（2023年頃）インフラコストの削減:
- 会社年間予算における自チームの固定費変動費を全く意識していなかった
- 2023年に250万円/月のコスト削減を実施したが予算全体を理解できていなかったためもっと早く実施できた可能性がある
- 意思決定プロセスも理解できておらず今は定例ミーティングを活用してこのような提案を気軽に上げられる環境にある
- 失敗例③（2025年頃）AIコーディングエージェントの予算確保:
- 予算を理解し意識するようになったことで本当に意義のある予算のかけ方を考えすぎた
- やってみないとわからないものに対して過度に費用対効果の説明準備をしていた
- 経営チームや経理は「予算は少なくすればいいものではない」「お試し期間と振り返りを前提に別途継続判断しましょう」とすぐに前進させてくれた
- 提案レベル2の準備に過剰な時間をかけてしまった原因は予算の意思決定プロセスへの理解不足
■ 7. マインドセットの変え方
- いきなり高い提案レベルを目指さない:
- これまでより不確実で正解のない課題に取り組んでいる事実を認識する
- 範囲時間軸選択肢が広がっているため一人ですべて考慮した提案を出せないのは当然
- レベル0から3のどこまで考えて話を持っていくかの引き出しを増やすことが大事
- 振り返りと軌道修正を前提とした提案をする:
- 正解がない提案と意思決定が増えるため振り返りと軌道修正のプロセスが重要
- 期間と振り返りタイミングやレポーティング方法もセットで提案することで提案レベル2以上がしやすくなる
- 軌道修正の話を伝えないと「後戻りのできない未来永劫にわたる意思決定」として議論されてしまう危険性がある
■ 8. 提案レベルを上げる実践方法
- 一人でいきなり高いレベルを目指さず巻き込んで意思決定するためにレベルを使いわける
- 範囲時間軸選択肢の広がりによる変化を自覚する
- 組織図目標会議体予算から組織の役割と意思決定プロセスを把握する
- 最初に持っていく提案レベルを状況に応じて使いわける
- 一発の提案でスパッと決まらない課題が多いため自己体験と他者の提案を観察する疑似体験を重ねていく
■ 1. 登壇者プロフィール
- 氏名: 曽根 壮大（41歳）
- 所属:
- Have Fun Tech LLC 代表社員
- 株式会社リンケージ CTO 兼 COO
- 著書: 「失敗から学ぶ RDBの正しい歩き方」
- 経歴: 警察官 → 派遣社員 → 社内SE → インフラエンジニア → Webエンジニア → フルスタックエンジニア → CTO（第1期）→ Customer Reliability Engineer → CTO（第2期）→ 独立 → CTO（第3期）→ COO & CTO
■ 2. 失敗できる意思決定
- 意思決定の本質:
- 意思決定に正解はなく 自分で正解にするしかない
- 失敗と成功は二項対立ではなく地続きの世界である
- 正解に近づく仮説を検証して最終的にゴールにたどり着くことが重要
- 意思決定の難しさ:
- ビジネスモデル・要件・法律・技術的制約・組織の状態はすべて変化する
- 継続した成長が求められる中でチャンスは何度も与えられるわけではない
- 致命傷だけは避ける必要がある
- 判断と決断の違い:
- 判断: 情報を集めれば理屈で答えが出せる
- 決断: 情報が揃わない中で答えを出さなければならない
- リーダーがやらなければならないのは決断である
- 標準化による仕組み化:
- インプット・スループット・アウトプットの各ステップを標準化することで決断を判断に変えられる
- 具体的には作業のマニュアル化や受け入れ基準のガイドライン策定が該当する
- 失敗できる意思決定のコツ:
- 失敗できる状態にすることで決断が可能になる
- 素早くアクションして失敗のフィードバックを受け取ることで新しい決断ができる
- 決断のステップ:
- 決断するために必要な条件を整理する
- 決断が難しい場合は素早く始め小さく失敗できるように考える
- 失敗が難しい場合は社内外も含めて多くの知見を集める
- それでも難しい場合は結論をできるだけ先伸ばす
- 仮説検証で重要な3要素:
- 失敗しても致命傷にならない: やり直せる・代替がある・失うリスクに対して許容できる（ビッグバンリプレースはリスクが高く段階的な置き換えやカナリアリリースを検討する）
- 失敗から学ぶことができる: 仮説が観測可能である・結果に対して客観的に分析・判断が可能（「流行っている」は仮説として弱くサンクコストが高くなると失敗を認めづらくなる）
- すぐ試せる: 結果が素早く出る・実行までの投資リソースが少ない・実行後の影響範囲が明確（大きな変化は合意形成に時間がかかり結果が出るまでも時間がかかる）
- 後に変更可能な技術選定の例:
- コンテナ: 実行環境の依存をコンテナで分離することで実行環境を変更できる
- REST: インターフェースの先はバックエンドの分割やフロントの差し替えが可能
- イミュータブルなデータとCQRSアーキテクチャ: 更新と参照の責務を分けつつ変化に追従できる
- 認証と認可の分離: SSOでまとめることで社内システムのIdPを活用できる
■ 3. ゆっくり考えて素早く実行する
- 基本原則:
- 失敗したプロジェクトの共通点は「すばやく考えゆっくり動く」こと（BIG THINGS引用）
- 成功したプロジェクトはいずれも「ゆっくり考えすばやく動く」を徹底している
- プロジェクト期間が長くなるほどブラックスワンが飛び込んでくるリスクが増大する
- 計画と実行の対比:
- 素早く考えてゆっくり実行: 計画（短）→ 実行（長）= 外部起因の影響を受けやすい
- ゆっくり考えて素早く実行: 計画（長）→ 実行（短）= 外部起因の影響が少ない
- 実行フェーズでのブラックスワン発生時の見直しはハイコストだが計画段階での見直しはローコスト
- ゆっくり考えるとは:
- 実行前の計画段階で仮説検証を行いリスクを事前に排除すること
- 参照クラス予測法の活用: 類似事例を参照し複数のデータを元に予測し悲観的に考える（ファットテール分布を想定）
- 反証に耐えられない仮説は基本的にリスクが高い
- ロードマップを分解して大きなリスクを防ぎ小さな成果の積み重ねでゴールになる計画を立てる
- 素早く実行するとは:
- 最初から想定通りに行くわけではなくフィードバックを受け取ったら素早く変化に合わせる
- 「初めて」を極力減らす: 技術の研究・検証とプロダクト開発を同時に行わず別々のプロジェクトにする
- 小さな成果物はコントロールしやすい（WBSは作業分解のTODOリストではなく小さな成果物の定義）
- アジャイルはハンドルであってアクセルではない（素早くフィードバックを獲得して変化に対応する）
- 学習ループ:
- シングルループ: 実行結果をもとに行動を変える
- ダブルループ: 結果から前提を変えて根本から変更する
- 素早く実行するために必要な技術:
- テスト・オブザーバビリティ・CI/CDはコアコンピタンスである
- マイクロサービスは小さく実行するためのhowの一つに過ぎずモノリスなシステムでも交換可能であれば良い
■ 4. Simple is Beautiful
- SimpleとEasyの違い:
- 「難しい」には「理解できないから難しい」（知識を積めば解決できる）と「構造に無理があるから難しい」（根本的な改善が必要）の2種類がある
- この違いを理解しないとEasyとSimpleの違いが見抜けない
- SimpleとEasyは両立する
- Small is beautiful（UNIX哲学）:
- 小さなプログラムはわかりやすい
- 小さなプログラムは保守しやすい
- 小さなプログラムはシステムリソースに優しい
- 小さなプログラムは他のツールと組み合わせやすい
- シンプルであることの利点:
- 小さくシンプルな方が仮説検証しやすい（変数は少ないほうが仮説検証しやすく原則はOne change at a time）
- 最小構成のWBSがマイルストーンになる
- 小さなリリースの積み重ねが大きなプロダクトになっていく
- 意思決定との関係:
- 意思決定の選択に悩んだら小さくてシンプルになる選択肢を選ぶ
- ゆっくり考えることと意思決定できないことは違う
- 仮説を意思決定して実行するために小さくシンプルになるまで考えること
■ 5. おわりに
- 「ゆっくり考える」チェックリスト:
- 5Wをしっかりと整理する（WhyとWhatが方向性を決める・ユーザー/業務の「困りごと」は具体的か・撤退条件は明確か）
- リスクは何か
- 先行事例は何と比較したか
- データは反証に耐えることができるか
- 確証バイアスへの注意:
- 仮説を補強する情報ばかり集めると確証バイアスに陥り誤った意思決定につながる
- WhyやWhatを検証するときは反証（falsification）を必ず考える
- 例: Why「売上を伸ばす」What「新規顧客を増やす」に対する反証は「売上が伸びないのは顧客単価の低下が主因では？」「新規顧客は増えても解約が悪化していないか？」
- 組織と個人の意思決定:
- 組織は意思決定しない
- 意思決定は人がする
- 他人が決めないなら自分が決めるしかない
- 本気の失敗の価値:
- 本気の失敗をすることで失敗が好きになる
- 昨日の自分に誇れる今日の自分になることが重要
勤務先のファイルサーバーに強制的にシャットダウンさせるプログラムを組み込むなどしたとして、大阪府警サイバー犯罪捜査課は3月5日、偽計業務妨害容疑などで滋賀県長浜市の元IT会社社員の男（38）を逮捕したと発表した。容疑を認め「社長に対する不満と復讐（ふくしゅう）心からやった。社員のセキュリティ意識の低さを知らしめたかった」と供述しているという。
逮捕容疑は2025年8月、大阪市内のIT会社のファイルサーバに、ランサムウェアに感染したと誤信させる偽の警告画面を表示させたり、起動から3時間後に自動でシャットダウンするプログラムを組み込んだりして業務を妨害したとしている。
同課によると、男は当時、この会社のシステム担当者で、後に自主的に退職していた。会社は業務を停止して原因調査などを余儀なくされ、データ復旧の委託料などで少なくとも約2000万円の被害が生じたという。自身の業務用パソコンを使ったとみられ、府警が詳しい経緯を調べている。
■ 1. 概要と著者の立場
- 著者は22歳の高卒エンジニアであり「動的型付け言語が嫌い」と明言
- Jupyter NotebookやGoogle Colabのようなセル単位実行環境では動的型付けにメリットがあると認める
- 一般的なプロダクト開発においては動的型付けは「過去のもの」と主張
■ 2. 型システムの歴史的変遷
- 1970〜1990年代（静的型付け期）:
- C・Javaが代表言語
- メモリ制約と実行速度重視の背景から静的型付けが必須
- 2000〜2010年代（動的型付け期）:
- Ruby・PHP・JavaScript・Pythonが代表言語
- Web普及とアジャイル開発による開発速度重視で動的型付けが流行
- 2010年代後半〜現在（漸進的型付け・静的回帰期）:
- TypeScript・Go・Rustが代表言語
- ツールの進化・システムの大規模化・保守性重視により静的型へ回帰
■ 3. 動的型付け言語が淘汰されるべき4つの理由
- 保守性の限界:
- 複数開発者による長期保守において型情報の欠如が深刻な技術的負債を生成
- 結果として開発速度が低下する
- ツールの進化による優位性の逆転:
- 動的型付けの「手軽さ」という優位性はすでに失われている
- コード補完: 動的型は推測ベースであるのに対し静的型は正確な型情報に基づく
- リファクタリング: 動的型は手動確認が必要であるのに対し静的型は安全な自動化が可能
- エラー検出: 動的型は実行時であるのに対し静的型はコンパイル時に検出可能
- ドキュメント性: 動的型はコメント依存であるのに対し静的型は型が仕様書として機能する
- AIとの相性:
- AIコーディングアシスタントは型情報が豊富なほど精度が高まる
- 厳密な型システムがAIによる自律的エラー検出を可能にする
- 動的型付けではテストとデバッグの手作業が増加する
- オブジェクト指向との相性:
- 型注釈なき動的型付けでOOPを採用するとコードの複雑性が増加する
- 型のないオブジェクトは単なる「データの塊」であり静的にプロパティを把握できない
- 著者はOOPの本質を「構造を明確にすること」と定義する
■ 4. 動的型付けが再評価されうる将来シナリオ
- AIが型定義不要な高度なコード生成能力を獲得する場合
- インタプリタのオーバーヘッドが無視できるレベルにまで低下する場合
- AIがリアルタイムでコードを生成する動的システムが主流化する場合
■ 5. 結論
- 動的型付け言語の完全な消滅は予想しない
- 中規模以上のプロダクト開発で型のない言語を新規採用する合理的理由はほぼ存在しないと主張
- Python利用時は型ヒント（Type Hints）の積極的活用を推奨
- 型はコードの仕様書であり保守性向上のための重要なドキュメントと位置づける
■ 1. 概要
- Claude Codeを用いて13〜15言語で「簡易git」を実装し生成時間とコストを比較した実験的調査
- 著者はYusuke Endoh（遠藤祐介）氏
- 動的型付け言語が静的型付け言語と比較して速く低コストであるという結果が得られた
■ 2. 実験方法
- 使用モデル:
- Claude Opus 4.6 (high effort)
- タスク構成:
- v1: init / add / commit / log の基本4機能を実装
- v2: status / diff / checkout / reset の追加4機能を実装
- 試行回数:
- 各言語20回 × 2タスク × 15言語 = 計600回実行
- 対象言語:
- 動的型付け: Python / Ruby / JavaScript / Perl / Lua
- 型検査付き動的言語: Python+mypy / Ruby+Steep
- 静的型付け: TypeScript / Go / Rust / C / Java
- 関数型: Scheme / OCaml / Haskell
■ 3. 実験結果
- 上位3言語（最速・最安）:
- Ruby: 73.1秒 / $0.36
- Python: 74.6秒 / $0.38
- JavaScript: 81.1秒 / $0.39
- 静的型付け言語の結果:
- Go: $0.50
- Java: $0.50
- Rust: $0.54
- 上位3言語と比較して1.4〜2.6倍の時間・コストを要した
- 標準偏差も大きくばらつきが増加した
- 最低パフォーマンス:
- Ruby+Steep: 186.6秒 / $0.84 で最も遅く高コスト
- テスト失敗数:
- 600回中3回（Rust 2回 / Haskell 1回）のみ失敗
- コード行数:
- OCaml: 216行
- Ruby: 219行
- Haskell: 224行
- 行数が少ない言語が必ずしも速く安いとは限らない（OCaml・Haskellは行数少ないが時間・コストは高め）
■ 4. 考察と結論
- 速度・コスト差の要因:
- 型システムの有無による制約の差
- 言語ごとのコード簡潔性の差
- 言語固有の複雑な仕様の影響
- AIの学習データ量の差
- 型システムとバグ防止:
- 静的型付けでもテスト失敗は発生しており型システムが必ずしも失敗を防ぐわけではない
- 著者の戦略提案:
- 初期段階ではRuby / Python / JavaScriptの採用が向いている
- 規模拡大時に静的型付け言語へ段階移行する戦略が現実的
- AIエージェントは言語移植に強いため段階的な言語シフトが実現可能
リモートワークからの出社回帰でも「出社させたがるのはマネージャーの怠慢」っていう極論をぶちあげるエンジニアの人が多かったです（日本ですごく代表的な「とあるエンジニア」も公式インタビューで語ってて頭いたくなりました）。
実態はといえば、シリコンバレーでも出社回帰の流れはあったし、MSRの研究でもリモワには多くの副作用があることが既に示されてたんですよね。この辺は出社回帰についていえば相当の合理性があるって話。
ただ、それより何より、管理職の人に対して「お前は普段仕事してない」と言わんばかりの言い草は単純に相手を見下していて、失礼きわまりないんですよね。
あのときに「管理職は仕事してない」と大合唱してた人たちは覚えてますが、本当に人としての礼節を欠く人たちだなって思いました。
公正取引委員会は、マイクロソフト・コーポレーション（法人番号8700150090374）、日本マイクロソフト株式会社（法人番号2010401092245）及びMicrosoft Ireland Operations Limited（以下、これら３社を併せて「マイクロソフト・コーポレーションら」という。）による独占禁止法違反被疑行為について審査を開始しました。この審査の一環として、本日、第三者からの情報・意見を募集することとしました。
本件情報・意見の募集は、当委員会が令和４年６月に公表した「デジタル化等社会経済の変化に対応した競争政策の積極的な推進に向けて ―アドボカシーとエンフォースメントの連携・強化―」に基づき、個別事件の審査の初期段階において実施するものです。
なお、当委員会が本件審査を開始したこと及び本件情報・意見募集を行うことは、独占禁止法に違反する行為が存在することを意味するものではありません。
■ 1. 概要と目的
- 背景: 要求・仕様・設計・テストケースの定義は人によって異なり統一されていない
- 目的: 理論に裏付けられた統一的で明確な定義を提示し成果物の品質向上とコミュニケーションエラーの削減を図る
- 目的: 成果物を機械的に処理可能にすることで少ない労力で目的を達成できるようにする
- 理論的基盤: Jackson の要求の考え方・Hoare の CSP の安定失敗モデル・Meyer の DbC の定義を実務向けにアレンジしたもの
■ 2. 基礎概念
- イベント:
- 状態遷移の引き金となるもの
- UIイベント・時間経過・通信・内部イベントτ の4種類がある
- 内部イベント:
- 状態機械の外から観測できず発生を制御できない特別なイベント
- タイムアウトやシステム内の通信のような隠蔽されたイベントをτで表現する
- 同期イベント:
- 複数の状態機械が1つのイベントで同時に状態遷移する場合のイベント
- τは同期イベントにはできない
- 典型例はクライアントとサーバー間の通信・ユーザーとシステム間のUI操作
- 並行合成:
- 2つの状態機械と同期イベントの集合から1つの大きな状態機械を作る操作
- 同期イベントの場合は両方の状態機械が同時に遷移できる場合のみ遷移可能
- 非同期イベントの場合は一方のみが遷移できれば遷移可能
- トレース:
- 初期状態から連続的に遷移可能なイベントの列のうちτを取り除いたもの
- 状態機械が出せるすべてのトレースを集めた集合をトレース集合という
- 安定状態:
- その状態からτで遷移できない状態
- 失敗:
- 安定状態に至るトレースとその安定状態で拒否されるイベントの集合の組
- 状態機械のもつすべての失敗を集めた集合を失敗集合という
■ 3. 詳細化の連鎖
- 上流の成果物から下流にいくにしたがって実装するシステムの姿は徐々に明らかになる
- 機能要求では振る舞いの一部分だけ定義する
- 仕様では機能要求で言及されていなかった部分の振る舞いを定義し実装に自由度を残す
- 実装では許された自由度の範囲内で正常系・異常系の振る舞いを定義する
- 詳細化の順序: 機能要求 → トップレベル仕様 → コンポーネント仕様 → コンポーネント実装
- 非機能要求は遷移にかかる時間や使用性などの定量指標によって実装を制約する
■ 4. 機能要求
- 定義: 失敗集合やトレース集合の満たすべき性質の定義
- 悪い失敗:
- 失敗集合に含まれていてはいけない失敗
- あるトレースの後に実行できるイベントを定めることに相当する
- 失敗集合に悪い失敗が含まれなければいいことを起こせることをいえる
- 悪いトレース:
- トレース集合に含まれていてはいけないトレース
- 悪いトレースがトレース集合に含まれなければ悪いことが起こらないことをいえる
- 機能要求の時点では言及されていないトレースや失敗がどうなっているかはわからない
- 情報セキュリティの性質のうち安全性に関するものは非機能要求ではなく機能要求に含まれる
■ 5. 非機能要求
- 定義: 量的な指標でしか記述できない性質（真偽で決定できない）の定義
- 遷移にかかる時間・使用性などが該当する
- 使用性の例: 主要なユーザーストーリーの達成に必要なUIイベント数や視線の動きの総量
■ 6. トップレベルの仕様
- 定義: トレース集合と失敗集合の組（安定失敗方式）
- 状態機械で構成することが一般的であり直接書き下すことは困難
- 仕様の時点では実装に自由度を残す非決定性が残っている以外は振る舞いがわかる
- 状態機械の記法:
- 状態には状態変数を記述する
- 遷移には「イベント [ガード] / 事後条件」の3つを記述する（ガードは真なら省略可）
- ガード: 状態遷移できる条件でイベントと遷移前の状態変数を参照できる
- 事後条件: 状態遷移前後の状態変数の関係を定義し遷移後の状態変数には ' をつける
- 画面表示を伴う場合は各状態における画面の画像を返す関数（画面表示の条件）が加わる
- シーケンス図による代替: QCDの面で状態機械が許容できない場合にシーケンス図で記述することがあるがトレース集合を誤解するリスクがある
■ 7. 機能要求と仕様の関係
- トップレベル仕様の失敗集合とトレース集合は機能要求を満たさなければならない
- 満たすべき条件1: 悪い失敗が失敗集合に含まれていない
- 満たすべき条件2: 悪いトレースがトレース集合に含まれていない
- 機能要求を満たす仕様は複数存在し最も優れたものを選ぶことが仕様記述の本質
- 選択基準1: 非機能要求を高く満たすこと
- 選択基準2: 実装コストの安い実装を採用できるように自由度が高いこと
- 仕様インスペクション: 仕様のトレース集合に悪いトレースや悪い失敗が含まれないことを確認する
■ 8. 設計
- 定義: トップレベルの仕様を人間の理解しやすい小さな状態機械（コンポーネント仕様）に分解する作業およびその成果物
- 設計の時点でもトレースは実装に自由度を残してよいが仕様で許容された自由度を超えてはならない
- コンポーネント仕様がトップレベル仕様を満たす条件:
- 並行合成後のコンポーネント仕様のトレース集合 ⊆ 仕様のトレース集合
- 並行合成後のコンポーネント仕様の失敗集合 ⊆ 仕様の失敗集合
- 仕様を満たす設計は複数存在し将来にわたっての経済性が最も高いものを選ぶことが設計の本質
■ 9. API設計書
- 定義: コンポーネント間の同期イベントの形式とリクエストとレスポンスの関係をシグネチャと事前条件と事後条件の組で定義したもの
- コンポーネント仕様の部分的な別表現であり状態遷移図から機械的に導出できる
- 事前条件: APIに規定の振る舞いを期待していい入力と通信前の状態の条件（満たされない場合の振る舞いは問われない）
- 事後条件: リクエストとレスポンスの間の関係とAPI実行前後の状態の間の関係
■ 10. 実装
- 定義: トップレベルの仕様またはコンポーネント仕様を満たす実行可能な状態機械またはそれを作成する作業
- 仕様またはコンポーネント仕様の許した自由度の中で振る舞いを1つ選ぶ（疑似乱数生成器等による非決定性は許容）
- コンポーネント実装がコンポーネント仕様を満たす条件:
- コンポーネント実装のトレース集合 ⊆ コンポーネント仕様のトレース集合
- コンポーネント実装の失敗集合 ⊆ コンポーネント仕様の失敗集合
- 実装からは遷移にかかる時間や計算機資源にかかる負荷などの統計データを得られ非機能要求を満たさなければならない
■ 11. テストケースと検証
- テストケースの定義: トレースと期待結果の組
- 悪い失敗のサンプルに対する期待結果は受理
- 悪いトレースのサンプルに対する期待結果は拒否
- トレース集合や失敗集合は巨大でありすべての要素を調べきることはできない
- 検証の本質: 与えられたリソースと時間の制約の中で最もリスクを下げられるサンプルを選ぶこと
- 探索的テスト: 実装のトレース集合のサンプルがすべて仕様のトレース集合に入ることを確認するテスト（計画主導のテストケースとは対偶の関係）
■ 12. 成果物間の論理的保証
- 機能要求をトップレベル仕様が満たしかつ並行合成したコンポーネント仕様がトップレベル仕様を満たせば並行合成したコンポーネント仕様は機能要求を満たす
- 並行合成したコンポーネント仕様がトップレベル仕様を満たしかつすべてのコンポーネント実装がそれぞれのコンポーネント仕様を満たせば並行合成したコンポーネント実装もトップレベル仕様を満たす
■ 1. 概要
- テーマ: SaaS領域におけるデータ品質向上の取り組みとその段階的実装戦略
■ 2. データ環境
- DWHにはGoogle BigQueryを採用
- 内製ETLフレームワークによりデータ処理を実施
- One Big Tableフォーマットのデータマートを約50個提供
■ 3. 課題
- テスト不足によりバグが偶発的にしか発見されない状況
- レガシーなロジックが継続使用されることによる品質低下
- ドキュメントの欠落により保守性が低下
■ 4. 導入ツール
- dbt:
- トランスフォーム処理とテスト管理に使用
- Elementary:
- dbtネイティブの観測可能性サービス
- テスト失敗時にSlack通知を送信
- UIによるモニタリング機能を提供
■ 5. 段階的テスト実装戦略
- Phase1（クリティカルエラーテスト）:
- 重複チェックにより同一データの重複を検出
- Nullチェックにより必須項目の欠損を検出
- 値確認により基本的な異常値を検出
- Phase2（整合性テストとサービスデータ変更検知）:
- ビジネスロジック観点でカラム間の矛盾を検出
- 例として「解約フラグが立てばステータスは解約」といった業務ルールを検証
- 複数カラムの合計が特定カラムと一致するかを確認するカスタムテストを開発
- 複雑な条件に対応するためカスタムテストを独自開発
- Phase3（ディメンショナルモデリング）:
- レイヤー別アーキテクチャへの移行を目指して進行中
- 保守性の向上を目的とした構造改善
■ 6. 実装結果
- 49マートに対してテストを実施
- 合計3,076個のテストを構築
- 120件の不具合を検知
- 既存データの潜在的な問題を可視化
■ 1. 背景と課題
- データ分析SQLは事前に定義された正解が存在しないためテストが困難
- テスト観点が標準化されておらず品質が担当者の経験に依存する
- エラーなく実行されるサイレントバグ（NULL計算による欠損等）が発生しやすい
- データ整合性確認のレビューに多大な工数を要する
■ 2. 頻出するバグパターン
- NULL/Unique仕様の乖離:
- データ仕様と実態の不一致により計算結果が欠損する
- Fan-out（レコード増幅）:
- 結合時のキー重複により集計値が意図せず増幅する
- 複雑ロジックのブラックボックス化:
- Window関数など複雑な処理において実装ミスが見落とされやすい
■ 3. 解決策
- ツール開発:
- Google Colab上で動作するデータプロファイリングツールを開発
- CTEの統計情報（NULL数・ユニーク数）を自動算出する機能を搭載
- 実テーブル一括作成機能により中間データを可視化し複雑ロジックを検証可能にする
- プロセスの標準化:
- テスト観点を必須（MUST）と推奨（WANT）に分類する
- 体系的な品質保証体制を構築し観点の属人化を解消する
■ 4. 導入効果
- 品質保証のベースラインが向上する
- 手戻りが削減される
- レビュー工数が大幅に削減される
■ 1. Claude Code Agent Teamsの概要
- 複数のAIエージェントが協調して複雑な問題を解決する新プレビュー機能
- 2026年2月5日にClaude Opus 4.6とともにリリース
- 従来のサブエージェント方式から大きく転換した設計となっている
■ 2. アーキテクチャ
- Team Lead（メインエージェント）が複数のTeammateを統括する構成
- 共有タスクリストは
~/.claude/tasks/[チーム名]に保存される- エージェントはリーダーへの一方的な報告ではなく、ピアツーピアの直接通信により自律的に連携する
■ 3. 有効化方法
- 環境変数による有効化:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claudeを実行する- 設定ファイルによる有効化:
~/.claude/settings.jsonのenvキーにCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1"を追加する■ 4. 主な制限事項
- 管理の複雑さ:
- 明確な指示とフィードバックループ（リンティング・テスト・レビュー）の整備が必須となる
- トークンコストの高さ:
- プランモードで通常の約7倍のトークンを消費する
- SonnetやHaikuモデルの活用や不要なMCPサーバーの最小化により軽減可能
- 巻き戻し・再開機能の欠如:
- 通常のClaude Codeとは異なり、以前の状態への巻き戻しやセッションの再開ができない
■ 5. 表示モード
- in-process:
- Shift+↑/↓でTeammateを切り替える単一画面インターフェース
- tmux:
- Tmuxのインストールが必要な分割ペイン表示
- auto:
- 環境を自動検出するデフォルトモード
■ 6. 主な活用場面
- フロントエンド・バックエンドにまたがる大規模リファクタリング
- 複数実装を並行して進める新機能開発
- 多角的な視点によるコードレビューおよびバグ調査
■ 7. 成功のポイント
- 人間が直接マイクロマネジメントするのではなく「明確な方向性・厳格な制約・フィードバックメカニズムの確立」がAgent Teams活用の成否を左右する
■ 1. プロジェクト概要と体制
- Airペイの新機能「オンライン決済」（2025年3月リリース）に向けた分析用データマートの開発プロジェクト
- リクルートが設計・要件定義を担いニジボックスが実装を担当
- 開発フェーズ:
- 第1フェーズ: 4名体制で最低限の分析が可能なデータマートを構築
- 第2フェーズ: 岩井・村上の2名でディメンショナルモデリングによるリファクタリングを実施
- 役割分担:
- 岩井（リクルート）: プロジェクト管理・スケジューリング・ステークホルダー折衝・データマートのモデル設計
- 村上（ニジボックス）: 実装担当
- 林田（ニジボックス）: 村上のバックアップ
■ 2. データマート新設の背景
- 既存のAirペイのデータマートは2015年のリリース以来 複雑化した処理を抱えており解消作業を進めている状況
- オンライン決済とAirペイ（対面決済）は決済の仕組みが異なる
- オンライン決済には「支払いリンク発行→送信→ID登録→決済」というファネルが存在
- 取得するデータの量とバリエーションが対面決済と異なる
- 社内の担当チームも分かれているためデータマートを分ける判断をした
- データレイクのローデータ活用には高度なドメイン知識とデータ加工技術が必要
- ビジネスサイドのメンバーが自律的にデータ分析・モニタリングできる基盤が必要
- 分析者によって結果が異なるリスク（ロジックの違いや母集団のズレ）を排除する必要がある
■ 3. 採用技術と手法
- ディメンショナルモデリング:
- データを「ファクト（計測対象）」と「ディメンション（計測軸）」に分離するモデリング手法
- システム開発における責務の分離をデータ開発に適用する考え方
- 処理を段階的に切り分けた実装が可能になる
- dbt（data build tool）:
- モジュール単位でSQLを記述しロジックを積み上げる形で開発可能
- テストが書きやすく処理の所在が一目瞭然になる
- 従来の内製ジョブ基盤による巨大クエリに比べ開発効率性とメンテナンス性が向上
- 品質管理:
- データの整合性テストを入念に実施
- データ異常を検知するテストをリリースと同時に稼働
- データ環境・提供するデータ自体をプロダクトと位置付けている
■ 4. ビジネスサイドとの折衝
- AirペイのKPI分析軸をある程度トレースできたため要件のすり合わせは比較的スムーズ
- エンジニア側の厳密さとビジネス活用上の許容範囲に若干の温度差があった
- 例: 加盟店のアクティブ・非アクティブ定義をKPIモニタリングの観点から協議して決定
- セキュリティ・ガバナンス上の問題がない限りビジネスサイドの意向を優先する方針
■ 5. チームコミュニケーションと協業体制
- リクルートとニジボックスはグループ会社として垣根なく協業する体制を構築
- チーム内コミュニケーションの工夫:
- メンバーの発言にスピーディーに反応する
- 実装上の懸念点や要望を積極的に出しやすい雰囲気を意図的に作る
- 設計に対するメンバーからのフィードバックを積極的に採用
- Slackでの作業ログ・思考プロセスの共有が詰まりポイントの可視化に貢献
- メンションなしにつぶやきを拾い疑問を解消する仕組みが機能
- 同様の課題を抱えるメンバーにとっても参照可能な情報資産となる
- マネジメント側の取り組み:
- コミュニケーションが苦手なメンバーには個別フォローを行うとともにリクルート側にも受け入れ準備を依頼
- プロジェクトの方向性とユーザーニーズをメンバーにしっかり共有
■ 6. キャリア成長と今後の展望
- 村上の成長実績:
- 初めてディメンショナルモデリングとdbtを習得
- 新規開発からリファクタリングまで一貫して関与することでデータ設計と品質への意識が向上
- 今後の目標:
- 村上: 設計工程も自己完結できるスキルの習得
- 村上: dbtの社内研修準備と社内エンジニアへの知識共有
- ニジボックスのキャリア環境:
- リクルートグループとして垣根なく協業できる環境がスキル・キャリア成長の強みとなる
- 未経験の技術・業務に挑戦しやすい文化とマネジメント体制を整備
■ 1. AIXによる雇用構造の変化
- パレートの法則（2:8の法則）の前提が崩壊する
- AIX以前は8割の人材も定型業務・サポートとして組織維持に必要だった
- AIXの時代にはAIが8割の人材の仕事をすべて代替する
- 人間の能力もAIにより拡張されるため必要人数がさらに減少する
- 組織は極限までスリム化される
- 残るのは「AIを使いこなして意思決定できる少数の人間」のみ
- 必要な人員は2割から2%以下になる可能性がある
- 肉体労働もAI搭載の人型ロボットが代替する
- 残る人間は農地所有の資本家・AI企業経営者・ごく一握りのプロフェッショナル
- 雇用の消滅はすでに起きている現実である
- Duolingo CEOのメールに象徴されるように世界中の企業が同じ決断を下しつつある
■ 2. 若手が育つ機会の喪失
- 現在のAIは大卒の若手社員レベルの知能を持つ
- プレゼン資料作成・データ集計分析・議事録作成・リサーチ等を人間と同等以上のクオリティでこなす
- 24時間365日稼働し文句を言わない
- 経営者にとって若手を雇わないことに合理性がある
- AIが若手社員と同じ仕事をこなすため新規採用の必要がない
- 若手はこれまで「下積み仕事」を通じてスキルを習得してきた
- 若手弁護士は判例リサーチを通じ法的思考プロセスや訴訟戦略を学んだ
- 若手コンサルタントはデータ分析という下積みを通じ問題解決スキルを習得した
- 若手デザイナーはアシスタントとしてラフを清書しながら「暗黙知」を体得した
- 一見退屈な単純作業はプロフェッショナルになるための「学びのはしご」であった
- AIXはこの「はしごの1段目」を消滅させる
■ 3. バイブコーディングと個人の生産性爆発
- 著者自身も人を雇う選択肢が極端に減っている
- 以前はサービス実装のためエンジニアを採用していたが今はAI1つで完結する
- バイブコーディング（Vibe Coding）という新しい開発スタイルが鍵となる
- 厳密な設計図を書かずに「こんな感じの機能が欲しい」というバイブスをAIに投げてコードを生成させる手法
- AIが書いたコードは使い捨てでよくエラーもAIに修正させる
- 人間は指揮者のようにAIへ指示を出すだけで動くアプリケーションが完成する
- AIと1人で100人分以上の生産性を発揮できる
- 100名のエンジニアを雇っても100倍のパフォーマンスにはならない
- コミュニケーションコストにより50倍のパフォーマンスすら難しい場合がある
- 適切な指示を出せる1人+AIで100人以上の生産性が実現する
- 若手エンジニアの居場所が消える
- かつて若手に任せていた「簡単な機能の実装」がAIの方が早く正確にこなせる
- 中途半端なスキルの若手を雇うことはコストではなくスピードを落とすリスクになった
■ 4. ベテランという概念の消滅と社会的混乱
- 現在のベテランが優秀なのは若手時代の「下積み」経験があるから
- 若手期に機会を奪われた現世代はどうやって将来のベテランになるかという問題が生じる
- AIの進化が進めば「ベテラン」という概念自体が不要になる
- 人間が経験を積んで成長する必要すらなくなる可能性がある
- AIがすべてを完結させるなら仕事自体が人間社会から消滅する
- 会社や組織そのものがなくなる可能性もある
- 従来の人材育成システムとAIの効率性が衝突し社会的摩擦が生じる
- 労働の8割がAIに置き換わる過程で社会のあちこちで激しい摩擦が起きる可能性がある
- 混乱の先にどのような社会の形が待っているかは明確でない
OSSは書き捨て御免が本来のはずで（そもそも「無償」とはそういうことである）、いつから開発者が持続性に責任持たなきゃならなくなったのかな……と不思議に思っている。実際に社会がOSSで動くような力学はあるけど開発者が飽きたら終了、という出口は常にあった方がよい。
気持ちはすごくよくわかるのですが、既にインフラになってしまったようなタイプのものについて誰が後をみるのかというのは考えないといけない気はしています（無償労働に寄ってたつインフラは不健全なのは倫理としてわかる一方で、マクロにみたときに難しいなとも）
それを考えるのはインフラとして依存している側の責任であり、個々の開発者ではない、という話でしょうね
ただ、それはそれで他人事にするのはどうなのかなと感じもします。私たちは既に知らないところで膨大な他人の無償労働に「依存してしまっている」のであって。
開発者側に責任はない＝OSSライセンスに同意した以上責任を追求してはいけない、という契約上の話と、個人的な誠実性の話は分けて考えないとおかしくなると思います。
そこはおっしゃる通りですが、契約上責任を追求してはいけないということはその通りでも、同調圧力というか社会的圧力は厳然として存在するわけで、個人的な誠実性というよりそこを問題にしたい感じですね。
私個人としては責任を追求するべきでないと思いますが、それとは無関係に「社会はパワーバランスでしか動かない」という事実があるわけで。
後者の論理で動く人が開発者に「無償であることに同意しないなら貴方がたがこのソフトウェアを使用する権利はない」と言われたらどうするんでしょうね。
予想としては、そんな論理知ったことか。もう社会はそれで動いてるでしょ？あたりでしょうか（表現としてはもうちょっとマイルドに「とはいっても、今それでもう回ってるんでは？」的に言うでしょうけど）。
力を背景にすれば論理なんて無力というか、逆に責任を（過度に）要求してくるなら、それを逆手に取る法廷闘争とか色々手段は考えられる気はしますが。
そういう高圧的な会社は逆に身を滅ぼすでしょうねぇ
それはともかく、寛容ライセンスの受託者責任は結論の出なかった裁判は1件(Turip Trading v Bitcoin Association)知っていますが、他に何かあるかしら…
■ 1. 背景と前提
- システム業界においてSIerの存在感が低下し自社プロダクト開発に携わるエンジニアの割合が増加している
- 自社開発であっても工数見積もりの問題は依然として多くのエンジニアを悩ませている
- 本稿は自社プロダクトをアジャイルで開発するシチュエーションを前提とする
■ 2. 見積もりをなくすという主張
- 最善の見積もり手法は見積もりをしないことである
- 自社プロダクト開発では作業粒度を小さくできるため「できた時が完成」方式が有効である
- 見積もり自体が困難である以上見積もりをなくすことと比較する価値がある
■ 3. 見積もりをなくすための手法
- 作業単位をなるべく細かくする
- 管理者がある程度の作業量とリスクを判断できるようにする
- 結果で判断する
- チーム全体のスループットを定量的に測る
- できないものはできないと認め諦める
■ 4. 見積もりをなくすことによるメリット
- 見積もりにかかる時間がなくなる
- 余計なバッファを積まなくて良くなる
- 積んだバッファを無駄に消費しなくて良くなる
- リスクの顕在化が早くなる
- 結果に注目し正しい評価ができるようになる
- 全体的に開発がスピードアップしスループットが向上する
■ 5. 管理者の役割
- 管理者の仕事は経営陣や上司からの「見積もりしろ」という圧力をはねつけることである
- チームのパフォーマンスを最大化するために必要な措置をとることがマネージャーの責務である
- 現代のビジネスではスループットと柔軟性をもって組織の価値を判断することが求められる
■ 6. 締切が絶対である場合の対応
- 締切がマストなタスクには締切の設定とともに内容の取捨選択を行う
- 予算・品質・納期の三要素を同時に全て満たすことはできない
- 納期が絶対である場合は予算と品質で調整するしかない
- 締切から逆算する
- リスク評価を最速で行う
- バックアッププランを可能な限り用意する
- 人員配置や補給など最善を尽くす
■ 1. 営業主導による炎上の起点
- 受託開発の見積もりは画面数等を元にした経験則に基づき正確性を欠く
- 30%OFFの受注は人件費の30%削減として現場に押し付けられる
- 客は定価相当のシステムを購入したと認識するが実際には7割分の提供となる
- 差額は「現場の頑張り」で補うことを前提としており炎上の構造的起点となる
■ 2. 増員による悪化
- 人員不足によりスケジュールが遅延し客からの圧力が生じる
- SIerは遅延が発生すると迅速に増員を決定する傾向がある
- 炎上中のプロジェクトへの増員は以下のコストを発生させ状況を悪化させる:
- 新規人員への教育コスト
- タスク再配分コスト
- 人員管理コスト
■ 3. 顧客との関係崩壊
- SI側の進め方が崩壊すると顧客との信頼関係も失われる
- 発注範囲の境界線が不明確になりカジュアルな仕様変更要求が発生する
- SIerはシステム開発のプロとして顧客の意思決定を先回りしてコントロールすべき存在である
- 多くのSIerにはこの思想が欠如しており顧客主導の主従関係が形成される
- 日本のSI業界ではこの構造が数十年にわたり定常化している
■ 4. プロジェクトマネジメントと品質管理の崩壊
- スコープマネジメントの欠如がリリース時の品質評価を実質不可能にする
- 各工程のスケジュール遅延により前工程終了前に次工程が開始される状況（五月雨）が生じる
- しわ寄せはテスト工程に集中し品質が崩壊する
- 典型的な炎上案件では以下の5つの崩壊が連鎖的に発生する:
- 体制の崩壊
- 顧客との信頼関係の崩壊
- スケジュールの崩壊
- テスト工程の崩壊
- 品質の崩壊
■ 5. 炎上後の構造的帰結
- 現場担当者の一部が鬱になる
- 案件終了後に燃え尽き症候群（デスマーチロス）が発生する
- 会社は現場の疲弊をよそに価格交渉を開始する:
- 超過した人件費を「赤字」として顧客に折半を要求する
- スコープ管理不足を棚上げし仕様変更を根拠としてオプション費用を請求する
- SIerの人件費は「売値」で積算されるため粗利率50%程度のマージンが乗っており折半でも原価回収が可能
- リリース後の運用保守契約は5年から10年続く場合があり開発費用と同等以上の収益源となる
- 近年は大規模SI案件の減少と労働環境改善の動きにより典型的な炎上案件は減少傾向にある
■ 1. コンピュータプログラミングはAI時代においても有望なキャリアである
- プログラミングの本質はコンピュータを用いた問題解決と複雑性の制御の2点であり、これらのスキルの価値はAIの登場によっても変わらない
- 現在のプログラマー就職市場は厳しいが、これは一時的な状況であり循環的な市場変動の一部である
■ 2. ジュニアプログラマーはAIにコードを生成させるべきでない
- AIがコードを生成できるとしても、自分でコードを書かなければコードを読む能力が養われない
- コードを読めなければ「魔法使いの弟子の罠」に陥り、理解も制御もできないシステムを生み出す危険がある
- コードを書く経験が、ソフトウェアアーキテクチャの直感を育む唯一の手段である
■ 3. AIへのコード生成依存はアセンブリから高水準言語への移行とは異なる
- コンパイラは決定論的だが現在のLLMは非決定論的であり、同じプロンプトに対して同一の結果が保証されない
- 高水準言語は偶発的複雑性を排除したが、LLMが生成するコードは不適切なアプローチや近道によって偶発的複雑性を増加させることがある
■ 4. AIは優秀なティーチングアシスタントとして機能する
- AIはコード生成ツールとしてではなく、概念や技術の理解を深めるパートナーとして活用すべきである
- 学習中に「詰まる」問題、特にツールチェーンなどの環境に起因する偶発的複雑性の解消に有効である
- 筆者はAIをTAとして機能させるためのAGENTS.mdファイルを学生に提供している
■ 5. AIによるプログラミングの変化と今後重要性が増すスキル
- コミュニケーション能力:
- LLMおよび人間との明確な文章による思考・伝達能力の重要性が増す
- 読書や記事執筆などがこのスキルの向上に寄与する
- ビジネス理解:
- プログラマーがビジネスや業務上の実問題を深く理解する能力の価値が高まる
- AIの活用によりプログラマーはコア業務を維持しつつ現実問題の理解に時間を割けるようになる
- ソフトウェアアーキテクチャ:
- 大規模システムを効果的に設計し複雑性を制御する能力の重要性が増す
- アーキテクチャのスキルは小規模なコードを書く経験の積み重ねによって習得されるものであり、AI依存による経験不足は将来のアーキテクト能力の低下につながる
- LLMの効果的な活用:
- 既存コードの分析・理解、大規模プロジェクトの思考整理、小規模コードの生成、正規表現やCSSなど書きたくないコードの生成、デモや探索的コードの生成、テストの提案といった用途に限定して使用する
- フルソリューションの生成やAPIの設計にLLMを使用すべきでない
■ 6. 就職活動における実践的なアドバイス
- オンライン求人サイトはほぼ効果がなく、特にジュニアには宝くじ的な存在である
- 「4つのF」として家族・友人・友人の家族といった個人的なコネクションを活用すべきである
- 100人以上の企業にはほぼ必ず何らかの開発部門が存在しており、コネのある企業への就職は競争優位をもたらす
- コスタコ社員の親を持つ学生の例のように、非IT企業でもプログラミングスキルは大きな強みになる
■ 1. はじめに
- システム障害対応では「影響範囲の調査」「原因の特定」「復旧対策の実施」という一般論は広く知られているが実践的な指針は少ない
- 実際の困難は部分的にしか見えない流動的な状況下で錯綜する情報を元に優先順位を判断することにある
- 『システム障害対応の教科書』はシステム障害の検知から原因調査・復旧対応までの基本的な動作と現場マネジメントをまとめたものである
- 本稿では同書をベースに著者の経験を交えた5つの勘所を解説する
■ 2. 旗振り（インシデントコマンダー）を決める
- 旗振りとはシステム障害対応チームのリーダー（インシデントコマンダー）のこと
- 主な役割:
- 体制構築: 対応メンバーを集め役割をアサインする
- 兵站: メンバーのシフト・食事・宿泊を割り振る
- 情報の一元化: 原因解析・仮説検証・復旧対策の状況を集める
- コミュニケーションのハブ: 顧客や関連チームと連携する
- 旗振りはまず障害の対応方針（システム復旧優先かデータ汚染阻止優先か等）を決定する
- 状況の変化に応じて優先度の再考も必要となる
- 旗振り不在の場合:
- 全員がボールに集まる「ちびっこサッカー」状態となる
- 場当たり的な対応となり情報は断片的なまま集まるが解決に結びつかない
- 情報錯綜により作業が重複しデータ破壊などの二次被害が発生する
- 対応できる人に作業が集中し長期対応でその人が消耗・破綻するリスクがある
- 旗振りと作業者は必ず分離する:
- 2つの役割を兼任させると作業ミスや連絡漏れなどの二次被害リスクが高まる
- 通常は「分かる人」「できる人」が作業者となるため上司が旗振りを担うことが多い
■ 3. メンバーの健康維持のための宿を確保する
- システム障害の最大の特徴は「いつ終わるか分からないこと」である
- ヤバそうなトラブルと感じた時点でまず宿泊手段の確保を検討する:
- 会社泊か近隣宿泊施設かを判断する
- 誰が泊まり誰を帰すかを決める
- メンバーの休息サイクルを最初に設計しない場合:
- 限界まで働いてから場当たり的な休息となる
- 連泊連勤が続くとパフォーマンスが著しく低下し体調不良者が続出する
- 復旧後に退職者が出るリスクがある
- システム障害の終息時期は予測困難である:
- 原因が判明しても復旧方法（データパッチ・ロールバック・プロセス再起動等）はさらに検討が必要
- 業務担当との調整や上層部の判断も必要となる
- 大きなトラブルと感じた時点で長期戦を覚悟し宿を予約する:
- 空振りしても問題ない（重要なのはメンバーの体調とチームのパフォーマンス）
- ホテルが確保できない場合はスパ銭利用の当番表を作成するなど代替手段を講じる
- 「まだイケます」と申し出るメンバーも強制的に休ませる
- システム障害時のリーダーの最大の役割はメンバーをどうやって休ませるかである
■ 4. War Roomをつくり情報を集約・可視化する
- War Roomとはそこに行けば最新情報と状況が把握できる会議室（物理・ウェブ・ハイブリッド）のこと
- ホワイトボードはフロー型とストック型の2種類を用意する:
- フロー型: 時系列の一覧表
- 発生事象・影響調査・解析状況を時系列で記録する
- 「いつ」「どこで」「何が」「どこの情報か」を記載する
- 記録は消さずに継続し満杯になったら別ボードを用意する
- ストック型: 現在の最新状況のまとめ
- 発生事象と影響・解析状況と直接原因（事実/仮説の区別含む）・復旧対処の準備と状況を記載する
- 復旧リミットや復旧作業に伴う業務影響も記載する
- 未確定事項もその旨を明記する
- 更新時は右上に日時を書いて画像として保存する
- 途中参加・交代メンバーはこのボードで状況を把握する
- ホワイトボード周辺にはシステム全体図・連絡体制図・当番表を揃えておく
- 情報更新タイミングをボードに明示し非同期でも情報が届く仕組みを作る
- ホワイトボードはチームの盾としての機能を持つ:
- 「どうなっているのか」と怒鳴り込む人にはストック型ボードを見せることで説明に代える
- 無茶な要求や暴言はフロー型ボードにそのまま記録し後の責任問題への証拠とする
- ウェブ会議の場合は全てレコーディングしておく
- ホワイトボードは「人から問題を切り離す装置」として機能する:
- 問題はホワイトボード上（当事者間）にあるという形にすることで経営層と現場の対立姿勢を和らげる
■ 5. 陥りがちな罠を見極め二次被害を避ける
- システム障害の解析・復旧において二次被害は普通に発生するものとして認識する
- 二次被害が発生しやすい理由:
- 緊急・重要な状況でリソース・時間・情報が不足している
- 普段しない作業を慣れていないメンバーが実施する場合がある
- 通常は複数人でやるリスクのある作業をひとりで実施せざるを得ない場合がある
- 疲労困憊した状態での作業となる
- 二次被害の具体例:
- 手順書のサーバ名誤り（IPアドレスとホスト名の食い違い）による無関係サーバのシャットダウン
- 削除対象確認漏れによるシステム領域の全消去
- 再実行禁止バッチ処理の誤実行によるデータ件数倍増と容量圧迫
- 連携先システムでの確認漏れ
- 対策:
- 危険な作業は複数人でチェックする
- リモートで画面共有しながら実施する
■ 6. 責任転嫁のための犯人探しをやめさせる
- 犯人探しは障害対処中・ポストモーテム中を問わず必ず発生する:
- 組織が大きくなるほど役職が上になるほど発生しやすい
- 犯人探しの背景:
- 不確実な状況下での恐怖を誰かへの責任転嫁によって解消しようとする心理的行動である
- 犯人探しの悪影響:
- 報告遅延・情報隠蔽が起きる
- 解明が遅れ根本解決に至らない小手先の対処となる
- 一時的な小康状態の後にさらに大きな事故が発生するリスクがある
- 犯人探しへの対処法:
- 原因調査の主語を「人」から「プロセス」に変える
- 「誰が設定を変えたか」ではなく「いつどの手順に則って変更したか」と問う
- 変更理由・背景・承認プロセスの欠陥を明らかにする
- 問題はミスした「人」ではなくミスを防げなかった「プロセス」にあると強調する
- 感情的になっている人から現場エンジニアを全力で守る
- 怒りを人ではなく別の何か（ぬいぐるみ等）にぶつけることで責任所在を「誰か」から「何か」に転換する
■ 7. おわりに
- システム障害における現場マネジメントの要点:
- 旗振りを決め体制を構築する
- 兵站に目配りしてWar Roomをつくる
- 二次被害に注意しながら解析・復旧を進める
- 犯人探しを厳に慎む
- より具体的・網羅的な情報は『システム障害対応の教科書』を参照
- いま余裕のある状況で「連絡体制図」を更新しておくことを推奨する:
- 電話番号・メアドだけでなくメーリングリスト・SlackやTeamsアカウント名・担当窓口も最新状態に保つ
あるSES会社の経営者？が「SESで入ってた人がAIで置き換えるとか言われて退場になった」「これからは資格などで付加価値を付けていかないとダメな時代が」みたいな話書いてたんだけど
「AIで置き換えられるような人」が「資格取ったぐらいでどうにかなると思ってる」なら全然状況理解してないよなぁって思うんですが違いますかねぇ
「資格を持ってるだけの素人さん」って要らない気がするんだけどなぁ...
いい加減スキル/経験不足を資格で水増しするの止めません？
■ 1. カリフォルニア州AB 1043（デジタル年齢保証法）の概要
- 2025年10月にニューサム知事が署名し2027年1月1日に施行予定
- すべてのOSプロバイダーにアカウント作成時の年齢確認を義務付ける
- 義務内容:
- アカウント設定時にユーザーの生年月日または年齢の入力インターフェースを提供すること
- アプリ開発者の要求に応じてリアルタイムAPIでユーザーの年齢区分を共有すること
- 年齢区分:
- 13歳未満
- 13歳以上16歳未満
- 16歳以上18歳未満
- 18歳以上
- アプリ開発者はダウンロード・起動時に年齢シグナルを取得しコンテンツ制限を行う義務を負う
- 罰金:
- 過失の場合は子ども1人あたり最大2,500ドル（約39万円）
- 故意の場合は子ども1人あたり最大7,500ドル（約117万円）
- 執行権はカリフォルニア州司法長官のみが持つ
- 顔認証やID提出は求めず生年月日の入力のみを要求する
■ 2. 各OSへの影響
- Windows・macOS・iOS・Android:
- すでにアカウント作成時に生年月日の入力を求める仕組みを持つため事実上の準拠状態にある
- Linuxディストリビューション:
- 多くのディストリビューションはアカウントという概念を持たない
- Ubuntu・Fedoraのインストール時はユーザー名とパスワードのみ設定しアプリストア連携APIも存在しない
- 法律への対応が困難である
- SteamOS:
- Steam Deck上で動作するOSとして法律の文言上例外にはならない可能性がある
- オープンソースの構造上の問題:
- ユーザーが自由に改変できるため特定バージョンへの強制が困難である
- カリフォルニア州による強制執行は事実上不可能との指摘がある
■ 3. OSの対応
- MidnightBSD（BSD系OS）:
- 2027年1月1日をもってカリフォルニア州居住者のデスクトップ利用を禁止するライセンス変更を実施
- 小規模オープンソースプロジェクトにとって年齢確認システムの構築はリソース面のみならず罰金リスクが存亡に関わると判断した
- DB48X（HP 48電卓用オープンソースOS）:
- 同様にカリフォルニア州居住者の利用を制限する措置を取ったとの報告がある
■ 4. 他州への波及
- コロラド州SB26-051（コンピューティングデバイスにおける年齢証明）:
- 上院委員会を全会一致で通過し本会議に送付済み
- 内容はAB 1043とほぼ同一で施行は2028年1月を予定する
- 米国全体の状況:
- 2025年6月の米最高裁判決（FSC対パクストン）がテキサス州の年齢確認法を支持し各州の立法が加速した
- EFFによれば米国の約半数の州が何らかの年齢確認義務を導入済みである
■ 5. プライバシーと実効性への懸念
- EFFの見解:
- 年齢確認義務化の潮流に対して明確な反対を表明している
- あらゆる年齢確認システムはその本質において監視システムであると警告している
- フロリダ州では年齢確認法施行後にVPN検索が1,150%増加し回避行動が生じただけだったと分析する
- 実効性の問題:
- 生年月日の入力だけによる年齢確認は未成年者が虚偽の生年月日を入力するだけで突破可能である
- プライバシーリスク:
- OSレベルでの年齢データ収集とAPIを通じたアプリ開発者への共有はデバイスとアカウントへの紐付けを生み出す
- 将来的により厳格な本人確認制度の土台として機能しうる構造を持つ
- コロラド州提案者はプライバシー重視の枠組みと説明するが匿名性の終わりにつながりかねないとの懸念がある
- 問題の本質:
- OSという最も根本的なレイヤーで個人情報の収集を義務化する発想が子どもの安全という名目のもとほとんど議論されずに進んでいる
■ 1. エージェント時代の開発現状
- Anthropicの2026年レポートによるとGitHubパブリックコミットの4%がすでにClaude Codeによるものとなっている
- 年末には20%超に達することが見込まれている
- Coding Agentの普及により開発手法とチーム構造が根本的に変化しつつある
■ 2. 開発スループットの上限
- Claude Code Max x20とChatGPT Proを活用することで1日約300コミット・6万行の開発を達成している
- サービスのレート制限が物理的な上限として機能し開発速度の天井となっている
■ 3. プロジェクトの「難度」を決める要因
- コーディング速度だけでなく以下の要因が開発速度を左右する:
- 要件の明確さ
- タスクの独立性
- テスト自動化の可否
- 承認ワークフローの設計
■ 4. ボトルネックの実態
- 最大のボトルネックはコーディング能力ではなく人間の認知にある
- 主要な課題として以下の3点が挙げられる:
- タスク割り当ての遅延
- レビューの積み残し
- Agentからの頻繁な割り込みへの対応
■ 5. 理想的なチーム構成
- アイデア出しリード（要件定義担当）1名
- ランナー（Agentを統括するメイン開発者）1名
- 専門別レビュアー（アーキテクチャ・UX・セキュリティ）複数名
- 上記構成がCoding Agent活用時の最適チームモデルとして提唱されている
■ 6. ドキュメント戦略
- 説明的なドキュメントは最小限に抑える方針を採る
- 維持すべきドキュメントは以下に限定する:
- CLAUDE.mdファイル
- アーキテクチャ決定記録（ADR）
- ADRは設計の根拠を記録することを目的とする
■ 7. 完全自動化の現状評価
- コンテキストウィンドウの制限が依然として課題として残る
- アーキテクチャ判断においては人間の判断が不可欠である
- 上記の理由から完全自動化の実現は現時点では時期尚早と判断される
■ 1. 抽象的フィードバックが引き起こす問題
- 「言語化が足りない」という言葉は診断名にはなるが処方箋にはならない
- 改善すべき内容が分解されていないと努力の方向が曖昧になる
- 「言語化」という一語で済ませると以下の区別が失われる:
- 会議で論点を整理する力
- 要件を文章で定義する力
- 相手の理解度に合わせて言い換える力
- 抽象語は会話を速くする便利な言葉だが自己理解を遅くする副作用がある
- 読書量・語彙・話し方など全て正しそうに見えながら全てがずれた状態になる
■ 2. 筆者の経験と転機
- 新卒時に「コミュニケーション能力が足りない」と指摘されたが何を改善すべきか分からず迷走した
- 努力の手応えが残らない苦しい時期を経験した
- 転機はトラブル対応時の顧客向けメール作成:
- 事実・原因・影響範囲・今後の対応を順番に整理
- 相手の不安を先回りして文面に盛り込む
- 誤解を防ぐため主語と時系列を揃える
- 上司から「理路整然として分かりやすい」と評価を受け自己理解が深まった
- 弱点は「コミュニケーション全般」ではなく「瞬発的な口頭コミュニケーション」のみと判明
- リアルタイム会話と非同期テキストは別競技であり得意不得意が分かれる
- 「コミュ力がない」のではなく「コミュ力を分けていない」だけだった
■ 3. 抽象語の分解方法
- 能力名ではなく「場面×行動×成果」で捉えることが重要
- 「コミュニケーション力」の場面別の内訳:
- 朝会での口頭報告: 結論先出しと時間管理
- 障害対応の報告: 時系列整理と影響範囲の明確化
- レビューコメント: 指摘の根拠を短く伝える力
- 「言語化力」の場面別の内訳:
- 要件定義: 曖昧な要望を仕様に落とす具体化
- 振り返り: 事実と解釈を分離する整理力
- 提案資料: 論点を絞り意思決定に必要な情報だけを置く構成力
■ 4. 得意が再現される条件の探索
- アウトプットの形は言語（会話・文章）に限らない
- コードの可読性・アーキテクチャ設計・開発フローの整備もコミュニケーションの一形態
- 本質は「いかに再現可能な価値を出せるか」にある
- 苦手を消すより先に得意が再現される条件を見つけることが優先
- 口頭が弱くても文章・コード・情報の構造化で確実に価値を届ける手段はある
- 自己理解と解像度の高さがこれからの時代を生き残るための最大の強みとなる
1万回転を作ってました。
1万回転はサーバー用でした。といってもPC用と本質的な違いはない
モーター以外の部品はほぼ一緒です。
ただしヘッドや円盤などの品質条件が厳しく、加速試験の条件がキビシイです。
なぜならサーバーのメーカーは速さや安定性を求め、そこにお金を出したからです。
でもPCメーカーは安さと容量を求めました。パソコン市場では大容量がウケるからです。
それに、技術の進化は、かえって回転数を求めない方向に向かいました。
同じディスク面積でも、半年ごとに容量が増えて行きます。
ということはデータの密度が高くなり、時間あたり読み出せるデータ量も増えるということ。
現世代の1万回転は、次かその次の7200回転に追いつかれます。
(実際は色々な要素があるけれど、速さの実感に効くのはスループットです)
モーターという部品の特性という要素もあったかも知れません。
ヘッドやディスクは半導体に近く、ムーアの法則に近い性能向上がありました。
でもモーターはまさに機械なので、指数関数的な性能向上はしません。
部品ほぼニデックだったので、毎年性能を倍にする意味がなかったのかも知れませんが。
■ 1. 定例ミーティングの基本的な捉え方
- 定例ミーティングは「必要悪」であり 同期的に人の予定を拘束するためコストが非常に高い
- 意思決定や合意形成の効果は大きいためゼロにはできないが 少なければ少ないほどパフォーマンスは向上する
- マネージャーはミーティングが増えやすい立場にあり カレンダーが埋まるほど予定調整がパズル化し 定例を増やす方向に自然と働く
■ 2. 定例ミーティングが増える理由
- 予定調整コストの高さ:
- 都度全員の空き時間を探すのが困難なため 「毎週固定」という判断が合理的に選ばれやすい
- 情報共有への不安と同調圧力:
- 主催者側に「呼ばないと後で揉める」「共有漏れを防ぎたい」という心理が働き 議事録共有で十分な人にまで招待が及ぶ
- 参加者側にもFOMO(取り残される不安)や「断ると角が立つ」という同調圧力があり とりあえず出席が増加する
- 参加者が増えると内職する可能性が上がるという研究結果もある
- 意思決定責任の分散と過度な合意形成:
- 「みんなで集まって決めた」という状態を作るために会議が設定される
- 事前根回しや全員の納得を重視しすぎると 「顔合わせ」や「儀式」としての定例が増殖する
■ 3. 定例ミーティングを減らすべき理由
- 合理性を積み重ねた結果カレンダーが定例だらけになり 本来やりたい仕事や集中して考える時間が削られる
- チームの生産性は集中時間の確保に大きく左右されるため 定例は少ないほうが望ましい
■ 4. 定例ミーティングをなくす方法
- 最初から終了日を決める:
- 定例設定時に必ず終了日時を入れ エンドレスや長期間の定例を作らない
- Google CalendarやOutlookでは終了日の設定が容易であるため 新規定例作成時に必ず設定する
- 終了しても誰も困らないまま消える定例はそもそも不要だったと判断できる
- 節目で定例を一度全部消す:
- 年末年始や期の変わり目など区切りの良いタイミングで全定例を削除する
- 必要な定例は結局再設定されるため 再設定されないものはなくても回るということ
- 「一度やめてみる」は継続の惰性を断ち切るのに有効
■ 5. なくしきれない場合のコスト削減策
- 頻度を下げる:
- ミーティング終了時に「本当に毎週必要か」を参加者同士で振り返る
- 毎週から隔週に変えるだけで 5人・1時間の定例なら年間約120時間の集中時間が回収できる
- 参加人数を絞る:
- 参加者を増やすのは容易だが減らすのは心理的に難しい
- SlackやTeamsで次回以降の参加をオプトイン方式にし「参加したい人だけリアクション」とすることで自然に人数を絞り込める
■ 6. まとめ
- 定例が増えるのは予定確保や調整コストだけでなく 情報共有への不安や責任分散の力学も重なるため
- 放置すると集中時間が失われるため 以下の3点を意識することで一定の効果が得られる:
- 定例には終了日時を入れる
- 節目でいったん全部やめる
- 頻度と参加人数を見直す
■ 1. 問題提起と結論
- CQRS/ESで読み書きDBを分けた場合に古いデータを読む可能性があるという疑問が学習者の間で生じやすい
- 結論：整合性はコマンド側モデルで守る
- クエリ側DBは整合性の判断に使用しない
■ 2. よくある誤解と実際の動き
- よくある誤解:
- 書き込みDBは書き込み専用
- 読み取りDBは読み取り専用
- 両者は完全に分離されている
- 実際の構成:
- コマンド側DB（イベントストア）：イベントの保存および集約の状態構成
- クエリ側DB（投影済みビュー）：検索・一覧・分析用
- コマンド実行時の流れ:
- 対象集約のイベントをイベントストアから読み込む
- イベントをリプレイして現在のステートを構成する
- そのステートに対してビジネスルールを適用する
- 問題なければ新しいイベントを保存する
- 単一集約の詳細表示画面ではコマンド側のステートを直接取得するのが一般的
■ 3. 整合性を守る2つの仕組み
- 楽観的バージョンチェック:
- イベントストアは集約ごとに最新バージョン（イベントの最新ID）を持つ
- コマンドに参照時点のバージョン（ExpectedVersion）を含める
- 保存時にExpectedVersionと実際のバージョンが異なれば競合エラーとする
- ポイント付与のようなケースでは冪等性キー（TransactionId）を使う方法もある
- 型による状態制約:
- 状態を型で表現し不正な操作を型レベルで防ぐ
- 例：AvailableRoomとFullRoomを別の型として定義し満員の部屋には入室メソッド自体が存在しない設計にする
- 削除フラグのような実行時チェックに依存する必要がなくなる
■ 4. アクターモデルによる同時実行制御
- 1つの集約に対して1つの実行単位（アクター）を持つ
- コマンドはメッセージとして順番に処理され1つのコマンドが完了するまで次は実行されない
- 分散環境でもどのサーバーにリソースがあるかを意識せずに適切なサーバーへルーティングされる
■ 5. パフォーマンス対策
- アクターによるステートのメモリ保持:
- コマンド実行後もアクターはしばらくメモリに残る
- 同じ集約への次のコマンド実行時にメモリ上のステートを再利用しイベントストアへの読み込みを省略できる
- スナップショットによる高速化:
- 一定期間アクセスがない場合はアクターをメモリから解放しステートをスナップショットとして保存する
- 次回呼び出し時はスナップショットから復元しその後に追加されたイベントのみリプレイする
- アクターモデルとスナップショットの組み合わせによりパフォーマンスの問題は実用上ほとんど発生しない
■ 6. クエリ側DBの役割と使い分け
- クエリ側DBが使われるケース:
- 複数集約をまたいだ一覧表示
- 検索・並び替え
- 集計・分析
- レポーティング
- 一覧画面と詳細画面の使い分け:
- 一覧画面：クエリ側DB（投影済みビュー）を使用し結果整合性（多少の遅延あり）
- 詳細画面：コマンド側（イベントストア）を使用し強整合性（常に最新）
- 「一覧は古いが詳細は正しい」という現象はCQRS/ESの意図された動作であり不具合ではない
■ 7. 用語の整理
- 「読み込みDB/書き込みDB」という表現は混乱を招きやすい
- より適切な整理:
- コマンド側DB（イベントストア）：単一集約の状態構成・整合性チェック・ビジネスルールの適用
- クエリ側DB：複数集約のビュー・検索と一覧と分析・結果整合性を許容する用途
- 「読み書きDBの完全分離」ではなく「コマンド側とクエリ側の役割分担」として捉えるとCQRS/ESの設計が理解しやすくなる
■ 1. Rich Hickeyとその思想的背景
- Clojureの作者でありソフトウェアの複雑性を深く洞察する思想家
- 音楽活動の経験から時間・構造・制約の概念をソフトウェアに応用
- コンサルタントとして多数の複雑なシステムを観察し「人間は自分が作る複雑性に対して非常に限られた存在だ」という確信を得た
- 主張の重心は言語仕様よりも「ものの見方」にある
- Simple Made Easy (2011)はその集大成であり他の講演(Are We There Yet? / Hammock-Driven Development / The Language of the System)にも共通テーマが現れる
■ 2. SimpleとEasyの違い
- SimpleとEasyは全く別の軸にある概念:
- Simple: 構造的に「絡んでいない」状態であり分離・一方向・明確な境界・独立した要素を持つ客観的な概念
- Easy: 慣れている・すぐ理解できる・すぐ使えるといった人間の主観による心理的・技能的な距離の概念
- ソフトウェアでこの2つが混同されることが複雑性の主な原因
- Simpleは「構造の状態」でありEasyは「人間の経験」である
■ 3. 複雑性の正体：Entanglement（絡み合い）
- Complexityは多機能や難易度ではなく構造的なEntanglement（絡み合い）を指す
- Hickeyは"complect"という古語を復活させ複雑性の正体を定義:
- 本来分離されるべき責務が混ざる
- データとロジックが密につながる
- 依存が循環し片方を変えるともう片方が壊れる
- Entanglementは指数関数的に増大し気づいた頃には解けなくなる
■ 4. Simple優先の設計原則
- 核心は「Simple first then easy」（Simpleを優先しEasyを後から足す）
- Easyを先に選ぶと短期的には速いが構造的コストが蓄積する
- Simple優先の設計は変化に強く長期的な開発速度を維持できる
- Simpleを基準にしておけばEasyのツールやフレームワークを後から安全に追加できる
- Simpleの条件:
- 分離されていること
- 依存が単純であること
- 一方向であること
- 解釈の余地が少ないこと
■ 5. 事例によるSimpleとEasyの比較
- レゴブロック（Simpleの象徴）:
- ピースが明確に分離されている
- 接続ルールが単純で例外がほとんどない
- 構造そのものがSimpleであるため壊れにくく変更しやすい
- UNIX（Simpleの好例）:
- 各コマンドが単機能で責務が明確
- 小さく副作用が少なく結合が一方向で組み合わせに強い
- Simpleを積み上げることで高い生産性を実現
- Spring Boot（EasyだがSimpleではない例）:
- アノテーションで暗黙的に依存が増える
- 自動設定が巨大で見通しにくい
- Easyが強いがゆえに構造が把握しづらくEntanglementを招きやすい
- GraphQL（Easyが強いと境界が曖昧になる例）:
- 巨大クエリが複数のドメインを横断する
- スキーマの結合関係がフロント都合で増えていく
- 型や責務の境界が曖昧になりやすくSimpleから遠ざかる
- AIコード生成（「Easyの暴走」の例）:
- 局所的に賢い抽象化を入れ責務境界を曖昧にする
- 仕様の曖昧さを埋めるために余計な意味付けや判断を自動追加する
- 動くコードを優先し構造の純度（Simple）より即時性（Easy）を強化する傾向がある
- Easyの暴走を止める役割は依然として人間が担う必要がある
■ 6. AI時代におけるSimple Made Easyの読み直し
- AIはEasyを極端に強化したがEntanglementも同じ速度で増殖させる
- AI時代においてもSimpleのステップを意識的に先に挟む順番は変わらない:
- まず境界を決める
- 責務を分離する
- 依存の方向を整える
- その上でAIに実装を任せる
- AIはSimpleに書く作業自体も得意であり人間がSimpleの基準を示せばそれに従って実装できる
- AIは自発的にSimpleを選ばないが指示すればその通りに動く
- AI時代に人間の価値となる「Simpleを選ぶ能力」:
- 何をどこで分けるべきか
- 境界をどこに置くべきか
- 結合をどこまで許容するか
- どうすれば絡まりを避けられるか
- AIの性能が上がるほどSimpleを軸にできる開発者・チームが強くなる
- Simpleはただの美学ではなくプロダクトの持続性を決定する基盤そのもの
■ 7. Simpleを守るための9つの問い
- Complectを見抜く問い:
- 「この2つは本当に一緒にすべきか」（関連と結合は違い一緒にしなくても動くなら分けたままにする）
- 「この変更の影響範囲を即答できるか」（即答できないならどこかで絡まっているEntanglementの兆候）
- 「片方を変えたらもう片方は壊れるか」（壊れるなら絡んでおり将来の変更コストが積み上がっている）
- Easyの誘惑に気づく問い:
- 「これは慣れているから選んでいないか」（慣れや経験で選んでいるなら一度立ち止まって構造を見る）
- 「1週間後の自分はこれを理解できるか」（今だけのEasyに最適化していないかを問う）
- 「短期の速さと長期の速さどちらを取っているか」（Easyは短期で速くSimpleは長期で速い）
- Simpleに立ち返る問い:
- 「これを分けたら何が楽になるか」（分割の目的を言語化できないなら分けない）
- 「この抽象化がなくても動くか」（なくても動くなら今は不要であり3箇所以上で使うまで抽象化を遅らせる）
- 「この賢さは本当に必要か」（愚直でも読める方が長期的には強くAIが生成する賢いコードほど将来の自分を苦しめる）
■ 1. 概要
- シニアエンジニアが実践するトラブルシューティング・切り分けの思考パターンを9つに整理したもの
- 調査力の差は経験や知識量だけでなく「不確実性を1つずつ削り落とすプロセスの徹底」にある
■ 2. 調査・切り分けの思考パターン
- まず全体を見る:
- いきなり一点を疑わず全体像を把握する
- 局所ではなく構造を見る
- 見る前に予測する:
- ログやコードを開く前に「おそらくここだろう」を言語化する
- 仮説なしに掘り始めると異常を見逃しやすいため観測は仮説とセットで行う
- 外から内へ絞る:
- 全体→サービス境界→コンポーネント→コードの順に見る
- いきなりコードを読み始めずスコープを段階的に狭める
- 計測してから動く:
- 「遅そう」「怪しそう」という体感で修正しない
- APMやダッシュボードで実測してから手を動かし数値で判断する
- 変化点を探す:
- 「昨日まで正常だった」場合はデプロイ・設定変更・トラフィック・依存サービス更新などの変化を探す
- 状態ではなく変化を見る
- 1つずつ変える:
- 複数の改善を同時に入れない
- 影響を限定し即時に戻せる形で小さく変更して検証する
- 調査ログを残す:
- 何を見て・何を考え・なぜそう判断したかを記録する
- 仮説と結果をセットで残し思考の履歴を共有資産にする
- 境界条件を叩く:
- 「正常か異常か」だけでなく「どこまでなら正常か」を探る
- 前提が破綻する条件を意図的に試し暗黙の前提をあぶり出す
- 再現手順を最小化する:
- 複雑な手順のまま調査せず「これさえあれば再現する」最小構成を見つける
- 不要なコードや依存関係を削ぎ落としノイズを排除する
■ 1. 問題提起：技術ヒエラルキーという構造的偏見
- 著者はC#・Python・クラウドAPI・AIエージェントといったモダン技術とExcel/VBAによる現場改善の両方を実践している
- 技術の内容（何を実現したか）ではなく技術の種類（何を使ったか）でエンジニアの価値が判断されるという不合理なヒエラルキーが存在する
- 現場の改善が「属人化」と一蹴される問題と管理側に善意の改善が「負債」として降りかかる問題という非対称な衝突が生じている
■ 2. 目に見えない技術ヒエラルキーの実態
- クラウド・分散DB・Rustは「高尚」とされ使用者が高度なエンジニアとみなされる一方でExcelやVBAは「古臭い非エンジニアの道具」として軽視される
- バージョン管理や課題管理システムで適切に管理されたExcel/VBAの運用体制でさえ管理部門やベンダーから「管理できていない」と決めつけられる事例がある
- VBAコードのみのgit管理提案のようにドメイン知識を欠いた実情から乖離した提案がなされることがある
- ChatGPTやGeminiなどのAIも技術コミュニティの学習データに反映された偏見を回答に含む場合がある
- 評価対象の内容を詳細に吟味する時間・労力が不足するため外形的情報のみで判断される偏見は人間社会の一般的な現象でもある
■ 3. 偏見の心理的背景：ドメイン恐怖症
- 医療や法律と異なり情報処理技術には名称独占も業務独占も存在せず誰でもエンジニアを名乗れる
- ドメイン知識と技術力を併せ持つ現場の人材はDX推進において情報処理専門家より圧倒的に有利な立場にある
- 情報システムの提供・管理側はトラブル時に現場固有のドメイン知識の理解を要求されがちであり強い心理的負荷（ドメイン恐怖症）を抱えやすい
- この構造が「専門性の境界を明確にしたい」「自分たちだけが使う技術を高く位置づけたい」という防衛的動機を生み技術コミュニティへの発信内容にも反映される
■ 4. 管理部門の立場：統制と持続可能性の確保
- 管理部門の役割はシステム提供による業務向上だけでなくセキュリティとガバナンスの維持にも及ぶ
- 特定部門にのみ技術的特権を与えることは組織全体の統制上不可能であり現場の不満を抑えざるを得ない構造がある
- 技術力の高い現場人材への業務依存が生じた場合その人材の離脱後に業務継続が困難になり管理部門への要求が高まる
- 現場改善による要求水準の引き上げは管理部門のドメイン知識不足とリソース制約から対応が極めて困難である
- 上記の理由により現場の業務改善は「属人化リスク」または「シャドーIT」として捉えられ部門間関係が悪化する
■ 5. 現場部門の立場：業務改善と属人化解消の実態
- 現場がExcelなど利用可能な技術を選ぶのは管理部門に禁止されにくく持続可能性が最も高いためである
- 現場開発が発生する根本原因は公式システムが業務要件を満たさず改修要求が費用対効果を理由に却下されてきたことにある
- 業務課題の解決リソースを現場が自発的に投入するのは未解決の被害が自部門に直接降りかかるからであり合理的な判断である
- 自部門内でPDCAサイクルが回り始めると部門間・組織間の交渉調整プロセスが不要になり改善速度が桁違いに向上する
- 管理部門が「属人化」と一言で片付けることで現場には不満と管理部門への不信感が蓄積する
- 皮肉にも現場の技術活用の目的は「業務の属人化解消」であることが多く管理側の言う「技術の属人化」とは指す意味が異なる
■ 6. 技術の種類を決めるのは技術力ではなく立ち位置
- Excel/VBAは現場部門で使える技術の代表格であり管理部門から統制リスクとして扱われやすい
- クラウドや分散DBやRustは情報処理専門家のみが扱う技術であるため習得が望ましいものとして高尚に映る
- FileMaker・Kintone・Google SpreadsheetとGASなども現場技術の選択肢となりうる
- 技術の種類が偏るのは現場で使える技術がそもそも限定されているためであり技術力とは無関係である
- 著者は両方の技術領域を経験したことで技術間の壁が技術力ではなく立場の違いに起因すると結論づけている
■ 7. 部門間の反発を協力に変えるための提言
- ハイブリッドな立ち位置の公認:
- 現場の技術人材に管理部門への兼務や技術アドバイザーとしての公的役割を付与する
- これにより現場は管理側の統制意図を理解し管理側は現場のドメイン知識へのアクセス経路を得る
- 技術の種類ではなく解決の質で評価する:
- 「Excelだからダメだ」という技術種別によるマウントを廃し業務継続性への貢献度を共通評価基準とする
- 管理部門はExcelの「禁止」ではなく安全かつ非属人化された運用方法（コード共有・ドキュメント化支援）を提示すべきである
- 技術はドメイン（業務）を救うために存在し管理はその救済を持続させるために存在するという共通目的を出発点とする
- 各立場が抱える「理不尽」を相互に認め合うことが技術ヒエラルキーという虚構を崩す第一歩となる
■ 1. 問題提起
- ソフトウェア設計論（SOLID原則・DRY・YAGNI・OOP/FP・TDD/DDDなど）が絶対的な真理として語られる光景に違和感を覚える
- これらを「コンピュータサイエンス」「アルゴリズム」として権威付けし批判を封じる風潮が存在する
- 「事実」と「規範」という性質の異なる知識に同じ「科学」のラベルを貼ることに対してエンジニアとしての危機感を持つ
- この混同は現場から考える力を奪い設計論を批判不可能な信仰へと変質させる
■ 2. 事実と規範の二領域
- 従うしかない事実の領域:
- 停止性問題の決定不能性（任意のプログラムの停止判定は不可能という証明済みの事実）
- CAP定理・FLP不可能性といった分散システムの制約
- クイックソートの計算量オーダー（平均O(n log n)・最悪O(n²)）
- 光速を超えた情報伝達の不可能性やネットワーク帯域の物理的上限
- これらはエンジニアの努力や美しいコードでは覆せない制約である
- 取捨選択して調整すべき規範の領域:
- SOLID原則・デザインパターン・RESTfulといった設計思想が該当する
- 自然法則でも数学的定理でもなく観測された事実ですらない
- 人間にとって扱いやすいシステムを作るために先人が編み出した知恵・ベストプラクティスである
- 採用すべきか否かはチームのスキルセットやシステムの寿命など文脈によって常に正解が変わる
■ 3. カリキュラムへの包含は分類の根拠にならない
- 「CS学部のカリキュラムに含まれるからCS」という反論への反駁:
- 問題にすべきは「基礎か実用か」ではなく「事実か規範か」という分類である
- 実用的な分野の中にもこの二層は存在する
- OSを例にした分類:
- スケジューリングアルゴリズムの数理や待ち行列の理論はサイエンスの側面が強い
- UNIXのファイルシステム設計思想やモノリシック/マイクロカーネルの議論はトレードオフの中で最適解を探るエンジニアリングである
- 倫理の例示による論証:
- 理学・工学カリキュラムには「科学技術者の倫理」が必修として含まれる
- しかし倫理はカリキュラムに含まれても「科学」とは呼ばれない
- 同様に教科書に掲載されるという理由だけで性質の異なるものを「サイエンス」と呼ぶのは乱暴である
- ソフトウェア工学の実証的アプローチ（開発プロセスのデータ収集と統計的傾向の把握）は科学的と言えるが現場で語られるSOLIDなどの原則は統計的事実ですらなく経験則に基づく規範に過ぎない
■ 4. 物理法則と設計戦略の混同
- 「DRYやSOLIDはメモリ領域の管理破綻を防ぐための工学原則であり絶縁原則と同様」という主張への反駁:
- 電子回路の絶縁破壊は観測された物理法則であり人間の意図と無関係に発生する自然現象である
- DRY原則の違反はメモリ領域の管理を常に破綻させるわけではない
- コンパイラの最適化を用いた反証:
- 近代的なコンパイラはインライン展開（DRYの逆であるコード複製）を最適化として頻繁に行う
- もしDRY違反がメモリ破壊をもたらすならコンパイラの最適化時点でバイナリがクラッシュするはずだが現実にはそうならない
- DRYやSOLIDはコードの管理・構造理解を容易にするための人間のための規範である
- メモリ安全性を担保するのはGCやRustの借用チェッカーといった言語処理系の仕組みであってソースコード設計の美しさではない
- 物理的破壊は壊れるか否かの二元論であるのに対しDRY違反による認知負荷は保守しやすいか否かというグラデーションの議論であり混同はエンジニアリング的解像度の低さの表れである
■ 5. 権威付けによる指導は怠慢である
- 「初心者に作法を守らせるために科学的権威で指導することは教育的配慮」という意見への反対:
- 設計が必要な理由・適用しない場合の実害（保守コスト増大・認知負荷上昇）を説明せず権威を借りて従わせるのは指導側の「説明の怠慢」である
- 権威付けによる指導の結果:
- 目的が蔑ろにされ「従うこと自体」が目的化する
- 文脈が変わっても思考停止して万能薬のようにルール遵守を強制するカーゴカルトが生まれる
- 「DRYの違反は物理的な破壊と等しい」と本気で信じるエンジニアが実際に存在することは教育的方便として行われた偽りの権威付けが現場で絶対的信仰として定着した実例である
- 初学者が型を身につける「守」の段階を否定するわけではないが指導者が理由を説明せず虚偽の権威でマウントを取ることは教育ではなくただの怠慢である
■ 6. 工学の本質としての抽象化
- 設計原則や規範を重視する理由はエンジニアリングの本質が「よい抽象化を模索すること」にあるからである
- 共通化と抽象化の違い:
- 共通化: 「AとBは似ているからまとめる」というボトムアップな整理整頓に過ぎない
- 共通化の問題: 文脈が異なるものを無理やりまとめると片方の仕様変更にもう片方が引きずられる密結合なシステムが生まれる
- 抽象化: 複雑な事実の上に人間が扱いやすい「都合のよいモデル」の層をトップダウンに設計すること
- TCPプロトコルを用いた抽象化の例示:
- ネットワーク上のパケットは消失し順序も入れ替わるという逆らいようのない事実がある
- TCPを被せることでデータが信頼性をもって順序通りに届くという抽象化されたモデルをアプリケーション層に提供する
- パケットロスという事実の上にストリームという扱いやすいモデルを提供することがエンジニアリングである
- SOLIDやDRYはこのような抽象化を成立させるための発見的な道具であり観測された事実そのものではない
- どの詳細を隠蔽してどの自由度を残すかという境界線の引き方は科学的裏付けだけでなくエンジニアの意思決定とトレードオフに委ねられる
- 絶対的な唯一の正解はなく人間の美意識やチームの文化に依存するアートやデザインに近い側面があるため自然科学と同列に扱うことには無理がある
■ 7. まとめ
- 「サイエンス」のラベルを貼ることで主張を客観的事実に見せかけ反論を封じることは誠実ではない
- 科学者の仕事が「変えられない事実」を解き明かすことであるのに対しエンジニアの仕事は「変えられる設計」を調整して現実の問題を解決することである
- 規範や原則を科学と偽ることはエンジニアリングの本分を放棄することに等しい
- CSの原則として正しいからと思考停止するのではなくサイエンスという制約条件のもとで設計原則の物差しをどう使いこなすかその文脈とトレードオフを語ることがプロフェッショナルとしての工学的な態度である
■ 1. 論旨の核心
- 記事の中心主張は「事実（is）と規範（ought）を同じ『科学』というラベルで括ることは誤りであり危険である」という点にある
- 哲学におけるヒュームの「is-ought問題」（自然主義的誤謬）に対応する知識論として正当な問題提起である
■ 2. 論理的に強い部分
- 事実と規範の二分法:
- 停止性問題・CAP定理・計算量オーダーといった「証明または観測された制約」と SOLID・DRYのような「人間の認知都合から導かれたベストプラクティス」を区別する視点は哲学的に堅実である
- 前者は反証不可能な定理であり後者は文脈依存の経験則であるという分類は概ね正確である
- コンパイラのインライン展開による反証:
- 「DRY違反はメモリを破壊する」という主張に対しコンパイラが最適化としてコード複製（DRYの逆）を行っても問題が起きないという具体的な反例を提示している
- 論理的に有効な反証であり論証の精度が高い
- 倫理のアナロジー:
- 「カリキュラムに含まれるから科学」という反論に対し「倫理も必修カリキュラムに含まれるが科学とは呼ばない」という例示は端的かつ有効である
■ 3. 論理的に弱い部分・留意点
- ストローマン論法の傾向:
- 「DRY違反は絶縁破壊と等しい」という主張を議論の代表例として使用することで反論者全体を極端な立場として描いてしまっている
- 「SOLIDは経験的に有効性が示されている」といったより一般的な反論には十分に答えていない
- 二分法の過剰な単純化:
- 「事実 vs 規範」の境界は実際には曖昧なグラデーションである
- サイクロマティック複雑度とバグ率の相関（実証的研究あり）・テストカバレッジと保守コストの関係（統計データが存在する）・チーム規模とモジュール境界の関係（Conwayの法則など）といった「観測から導かれた傾向」は記事の二分法に収まりきらない
- 「規範は人間の都合に過ぎない」の過剰な相対化:
- 設計原則を「人間側の都合に過ぎない」と述べることは認知科学的知見に基づいた設計論の妥当性を軽視するリスクがある
- 「都合」であっても人間の認知特性や計算機の動作原理に根ざした合理性を持つものは多い
- 教育的権威付けへの批判の一面性:
- 初心者への指導で「まず型を守らせる」アプローチを全面的に「怠慢」と断じているが学習理論上は「先に規則を内面化し後で理由を学ぶ」プロセスが有効な場面も存在する
- この批判は正当な側面を持つものの教育的文脈の複雑さを十分に扱えていない
■ 4. 総合評価
- 核心論旨の妥当性: 高い（is-ought問題として正当）
- 具体的反証の精度: 高い（コンパイラ例は有効）
- 反論への対応の網羅性: 中程度（極端例への反証に偏る）
- 二分法の精度: やや粗い（グレーゾーンを扱えていない）
- 結論の一貫性: 高い
■ 5. 結論
- 記事の主張する「規範を科学と偽ることの危険性」は知識論として正当であり実務的にも重要な問題提起である
- 事実と規範の二分法を過度に単純化している点および最も極端な反論を論駁の対象としている点で論証の網羅性に限界がある
- 主張の方向性は妥当だが設計原則の実証的根拠に関する議論を避けていることが論証の弱点となっている
時間t=1/48000×1200(s)
距離d=4×a(mm)
速度v=4×a×48000/1200(mm/s)
…が、4×a×48000は非常に大きな数になる可能性がある。コンピュータが扱える数は65535までなので、まぁ無理だ。
だから48000/1200×4×aにしてやる必要がある。
やってられない。
■ 1. EAVとは何か
- EAV（Entity-Attribute-Value）はデータを「何が（Entity）」「どんな属性を持ち（Attribute）」「その値は何か（Value）」の3要素で表現するデータモデル
- 通常のRDB設計では属性をカラムとして定義するが、EAVでは属性を「行」として表現する
- 属性の追加はattributesテーブルへのINSERT1件で完結し、DDL変更が不要
■ 2. EAVがアンチパターンとされる理由
- SQLの複雑化:
- 通常なら単純なSELECTで済むクエリが、属性ごとにJOINを要する複雑なものになる
- データ型制約の欠如:
- value列がTEXTやVARCHARになりがちで、RDBMSの型安全性が失われる
- 外部キー制約の使用不可:
- 汎用的なvalue列ではFOREIGN KEYによる参照整合性の維持が困難
- パフォーマンス劣化:
- エンティティ1件あたり属性の数だけ行が生まれ、行数が爆発的に増加する
■ 3. EAV採用の判断基準
- 採用を検討すべき条件:
- 属性の数が数千〜数十万規模で、事前に確定できない場合
- 属性の追加・変更がビジネス要件として頻繁に発生する場合
- ほとんどのエンティティが属性の一部しか持たないスパースなデータの場合
- 避けるべきケース:
- 属性が数十個以下で固定されている場合
- 複雑な集計やレポーティングが主要なユースケースの場合
- チームにEAVの運用経験がない場合
- 代替案として検討すべき技術:
- JSONBカラム（PostgreSQL）
- ドキュメントDB（MongoDB等）
- ワイドテーブル＋パーティショニング
■ 4. 事例1: 財務諸表プロジェクト（Speeda）
- 背景:
- 複数企業グループ・複数会計基準・複数国をまたぐ数十万件の勘定科目を管理
- 勘定科目をカラムとして設計するとRDBMSのカラム上限に抵触し、かつALTER TABLE運用が非現実的
- EAVの適用:
- 勘定科目そのものをAttribute、企業をEntityとして扱い、金額をValueで表現
- 新規勘定科目の追加はINSERT1件で完結し、DDL変更・アプリ改修が不要
- スパースなデータに対してNULLを持たずに必要な行だけを格納できる
- 時間軸の組み込み（period_id）:
- EAVテーブルにperiod_idカラムを追加し、主キーを（entity_id, attribute_id, period_id）の3カラム構成に変更
- 財務諸表データを「誰の・何が・いつの・いくら」という4次元のデータキューブとして表現
- 期間はすべてのデータに共通する固定軸として扱い、EAVの動的な属性部分と分離
- インデックス設計:
- アクセスパターンを事前に洗い出し、逆算した複合インデックスを設計
- 数十億件規模でも実用的なレスポンスタイムを実現
- パフォーマンス問題の本質は行数ではなくアクセスパターンを無視したインデックス設計にある
- 考慮点:
- マイグレーション管理: 属性マスタの変更もシードデータとしてバージョン管理に含め環境間の一貫性を維持
- ORM非対応: EAVの読み書きを抽象化するリポジトリ層を独自実装し、アプリ側のコードからEAVの存在を隠蔽
■ 5. 事例2: ID管理プロジェクト（YESOD）
- 背景:
- 人・組織・会社・オフィス・プロジェクトという複数種類のEntityとその関係性を管理
- Entity間の関係性（所属・アサイン・勤務地等）を通常設計で表現すると中間テーブルが増殖し、要件変化のたびにDDL変更が発生
- ReferenceIdの導入:
- EAVテーブルにreference_idカラムを追加し、entitiesテーブルへの外部キーとして定義
- プリミティブな値はvalue列、Entity間の関係性はreference_id列で使い分け
- 外部キー制約によりRDBMSの仕組みの中で参照整合性を保証
- 新たな関係性の追加はattributesテーブルへのINSERT1件で完結
- Entityの拡張性:
- entitiesテーブルにentity_typeカラムを持たせるだけでEntity種類を追加可能
- 要件が流動的なプロジェクトでのテーブル構造変更なしの拡張が実現
- バイナリ格納と型安全なシリアライズ（Kotlin）:
- value列をBYTEA型として定義し、すべての値をシリアライズしたバイナリで格納
- Kotlinのsealed interfaceでAttributeValueの型を定義し、data_typeに基づくシリアライザを一箇所に集約
- コンパイル時にwhen式の網羅性チェックで型の不整合を検出
- TEXT型と比べて数値精度の劣化がなく、「とりあえず文字列で入れておく」運用上の怠慢を設計で防止
■ 6. まとめ
- EAVがアンチパターンとされる主因は、不適切な条件下での採用の歴史にある
- 属性が動的で大量・データがスパース・スキーマ変更を最小化したい条件が揃う場合はEAVが合理的な設計選択になる
- EAVの弱点（型安全性・参照整合性・パフォーマンス）はそれぞれ実践的な工夫で対処可能
- 型安全性: バイナリ格納＋言語側のシリアライズ機構
- 参照整合性: reference_idによる外部キー制約
- パフォーマンス: アクセスパターンを逆算した複合インデックス設計
- EAVの弱点を正しく理解した上で補完策とセットで採用することが重要
■ 1. 職務経歴書における課題とSTAR法の限界
- エンジニアは自分以外の職務経歴書を見る機会がなく自分の経歴書の品質を評価しにくい
- エージェントはエンジニアの技術の詳細を把握しにくいため一人ひとりの強みに合わせたアドバイスが困難
- STAR法は出来事の報告には有効だが周囲の状況と自分の役割が分けられておらず能力の証明には不十分
- ミドルエンジニア以上では意思決定の思考プロセスが重要だがSTAR法はやった事実を記載しやすいフォーマットになっている
- 思考がブラックボックス化し候補者が「運が良かっただけの人」や「指示待ちの優秀な作業者」に映るリスクがある
■ 2. シーキューブモデルの構造
- エンジニアの経験を客観的な責任と主観的な判断の構造として整理するフレームワーク
- 3つの視点（縦軸）と3つの項目（横軸）からなる3×3の表で経験を捉える
- 横軸の構成:
- 課題 → 役割・行動 → 結果（原因から結果への時間の流れ）
- 縦軸の構成:
- 上段: 周囲の客観（Context）
- 中段: 自分の客観（Capacity）
- 下段: 自分の主観（Choice）
- 「シーキューブ」の名称は3つのCと3×3の表に由来する
■ 3. 各観点の定義と記載ルール
- 周囲の客観（Context）:
- 自分が関与する前から存在していた課題や状況
- 解釈を含めず事実のみを記載
- 自分がいなくても成立する組織・プロダクト全体の前提環境
- 自分の客観（Capacity）:
- 全体の中で自分に割り当てられた役割・責務・公式な立ち位置と権限
- 周囲からのミッションや役割を記載し周囲と自分の関係を明確化
- 自分の主観（Choice）:
- 課題をどう捉え何を本質と判断しどこに介入したかという意思決定の領域
- 時間や思考が存在する唯一の層
- 行動の理由となった事象や判断を記載
- 記載ルール:
- 周囲の客観には解釈を書かない
- 自分の客観には判断を書かない
- 自分の主観にのみ自分の考えを書く
■ 4. 職務経歴書への活用効果
- 3×3の表は重要な要素を漏らさないための分析・整理ツールであり全内容を文章に詰め込む必要はない
- シーキューブモデルを使うことで以下の3点を混同せずに説明可能:
- 周囲の課題と期待・状況（どこまでが前提条件だったか）
- その中で自分が担っていた役割（どこからが本人の裁量だったか）
- そこで下した判断とその判断が作った状態（判断が結果にどう結びついているか）
- 「言われたことを実装した人」と「構造に責任を持って判断した人」の違いが自然に表現される
- 特にシニアエンジニア以上が自分の価値を誤解なく伝えるためのツールとなる
■ 5. STAR法との関係
- シーキューブモデルはSTAR法を否定するものではなく経験を手早く共有するためのプラクティスとして有効
- STAR法は判断や責任の構造を評価する場面では客観的情報と主観的情報の整理が困難で表現が不足することがある
- シーキューブモデルは前提となる状況・客観的な自分への期待・主観的な意思決定をもれなく整理するフレームワーク
- 元々の期待よりどれだけ大きいことができたかの比較表現が可能になる
■ 1. GitHubをメモ帳として活用するアウトプット観
- GitHubはポートフォリオではなく「巨大なメモ帳」として捉える
- 未完成・中途半端なコードでも公開する理由:
- 後で自分が検索できるようにするため
- 過去の活動の記録として残すため
- 自分の本棚を公開する感覚に近い
- 「人に見せる」ではなく「自分のために置く」という認識がアウトプットのハードルを下げる
- OSSを完成品ではなく「対話のきっかけ」として捉える:
- 公開することでプルリクエストなどのフィードバックが得られる
- 完璧にしてから出すのではなく出すからこそ完成に近づく
■ 2. 「便利なものを作ったら負け」という哲学
- アウトプットの原動力は実用性ではなく「驚き」と知的好奇心
- Vimスクリプトでの機械学習・動画再生など一見無意味な活動を好む
- 代表作emmet-vimも「Vimでもできるぞという見せびらかし」から生まれた遊び心が起点
- 役に立たねばという先入観を捨て興味本位の遊びを許容することがユニークなプロダクトを生む土壌となる
■ 3. 遊びを通じた技術的成長
- 「遊びこそが最高の学習法」をサッカーのリフティングに例える:
- リフティングはサッカーの上手さを保証しないがボールタッチの基礎能力を高める
- 遊びの中での実践が基礎能力を確実に向上させる
- 非効率な「縛りプレイ」を自分に課す学習法:
- Pythonで済む機械学習モデルをC言語やVim scriptで書き直す
- わざと負担をかけることでブラックボックスの仕組みを理解する
- 仕事上あり得ない技術的挑戦が未知のトラブル解決の地力となる
- 成長を目的にせず面白がって遊んでいたら勝手に成長していたというアプローチが第一線に立ち続ける理由
■ 4. AI時代における人間のアウトプットの価値
- AIはすでに「簡単なWebサービスを数日で作れる」レベルの実力を持つ
- AIへの過度な依存への懸念:
- AIばかり使うとプログラミングが下手になる可能性
- リハビリとして四則演算のアセンブラコンパイラを自作するなど基礎力の維持を重視
- 効率・実用性ではAIに勝てないが「面白そうだから作る」「仕組みを知りたいから書く」という人間の根源的欲求はAIに代替不可
- AI時代の人間のスタンス:
- 仕事ではAIを使って効率化する
- 余暇・OSS活動では義務感なく「みんなが驚きそうなもの」を自分のために作る
- 便利なものはAIが量産するからこそ人間は堂々と「無駄に見える遊びや驚き」を追求すべき
Bun v1.3.8の大きな新機能が、Markdownパーサーの搭載です。
BunはZig言語で開発されており、このMarkdownパーサーはC言語で実装された高速なMarkdownパーサー「MD4C」をZig言語に移植したものだと説明されています。
BunのMarkdownパーサーは、主に以下の3つの機能を備えています。
MarkdownからHTMLへのレンダリング
[...]
GitHub Flavored Markdonwの対応
GitHubがMarkdownを拡張した「GitHub Flavored Markdonw拡張」にもデフォルトで対応。テーブル、取り消し線（~~deleted~~）、タスクリスト（ - [x] done）、自動リンク（Permissive autolinks）が利用可能です。また、wikilinks、latexMath、headingIds、autolinkHeadingsも利用可能となっています。
Reactコンポーネントとして利用可能なフラグメントの生成
MarkdownからReactコンポーネントとして利用可能なReactフラグメントを生成。
■ 1. オンボーディング高速化の概要
- 転職・異動のたびに「立ち上がりが早い」と評価される筆者が自身の取り組みを言語化したもの
- オンボーディングの速さはエンジニアとしての評価・チームからの信頼に直結する
- 「情報」「人」「組織」「自分」の4軸を意識して行動する
■ 2. 情報収集の仕組みを作る
- ドキュメントのAI活用:
- 専用GitHubリポジトリを作成し社内ドキュメントをまとめてAI（ClaudeまたはCursor）から参照できる環境を構築する
- リポジトリはアーキテクチャ設計書・API仕様書・運用手順書・議事録などの分類で管理する
- 会社のポリシーや組織規約の範囲内で実施する
- 過去ログの精読:
- GoogleドライブやSlackの過去ログをすべて読む
- Slackの過去ログにはドキュメント化されていない暗黙知（設計の背景・過去の障害・各メンバーの専門領域）が含まれる
- システム全体像の把握:
- 最初の1週間でシステム全体の構造を頭に入れる（細部は後回しでよい）
- 自分で図を描き先輩に確認することで理解の正確性を担保する
■ 3. 人との関係を築く
- 積極的な質問:
- 質問しない新人は「何を考えているかわからない」存在と映る
- 質問により自分の理解度の提示・相手への教える機会の提供・コミュニケーションの創出が可能になる
- AIやGoogleでは得られない社内知識は人に聞くことでのみINPUT可能
- キーパーソンマップの作成:
- 最初の2週間でインフラ・ドメイン知識・フロントエンド・過去の経緯など分野ごとのキーパーソンを把握する
- マップがあることで問題解決のスピードが向上する
- 助けを求める姿勢:
- 経験10年のベテランでも新環境では新人であり変なプライドを持たない
- 「助けてもらう」ことを前提に動くことで周囲も協力しやすくなる
■ 4. 組織を理解する
- 業務フローの把握:
- PRのレビューフロー・デプロイの頻度とタイミング・会議体の種類と目的・承認権限の所在を理解する
- 技術的に正しくても進め方が合っていなければ指摘される
- マネージャーの視点の理解:
- 今期のチーム目標・チームが抱える課題・上層部からの要求を把握する
- 1on1の機会があれば直接確認することも有効
- 組織課題の早期把握:
- 組織が困っている点・改善したい点を早めに把握することで自分の貢献領域が見えてくる
■ 5. 自分の立ち位置を見つける
- 足りていない領域の探索:
- チームを観察し「誰もやりたがらない仕事」「手が回っていない領域」を見つける
- 貢献領域の見極め:
- 自分の強みとチームのニーズが重なる部分を探す
- 最初の1ヶ月を観察期間とし2ヶ月目から貢献できる領域で成果を出しにいく
自前のPCサーバーやVPSなど、OSだけが用意されているような環境でインターネットアプリケーションを構築する場合、webサーバーやデータベースサーバーなど1つ1つインストールし管理するのは手間がかかります。そこでDockerを利用してアプリケーションと必要な構成を全て自動的に構築できるDokployが公開されています。
語弊があるタイトルだけど、外資系どころか海外でIT企業で働く場合でもそう、俺大学出てからずっとITエンジニア一本でジョブホッパーやってるけど。
ここ３～４年でどこも外資系ITで「日本人のエンジニアで35才以上って時点でちょっと難色を示すね」っていう通念みたいなものがどの会社でもあって、一種「あるあるネタ」になっててちょっと興味深かったので、
この辺の事情、何故かXやはてなで書いてるやつごく少数しかいなかったので、今後若い日本人ITエンジニアとかの参考になるんじゃないかなと思って書き残しておきたい。
先に言っておくとだけど必ずしも35歳以上は絶対取らん、というわけではない。実際俺も35歳以上なわけだし。外資系で活躍してる日本人エンジニアは海千山千のツワモノが多いから35以上～50代当たり前ではあるし
ただある種の偏見(まあ一面真実なわけなんだが)というか、法則の様なものがやっぱり体感的に俺も、外資系で通用してる日本人エンジニア達や外人や経営層にもみんなあるみたいで、一種の「マーフィーの法則」みたいになってる。
■ ① 海外から見た日本の35歳以上のエンジニアを採用しづらい理由「技術的バックボーンの文化からして他責思想が染みついてるから」
これが一番の理由で、一番面白かったところ。
俺は口にはしないくらいの分別はあるとはいえ、気持ちの理解はできるけども、欧米中はもちろん、イスラエル、韓国、インド、東南アジアのIT新興国のエンジニアも皆本気で不思議がっている
「彼らはなんで、いつまでも金子勇とTRONは無理解な政府と、外国に潰されたって言い続けてるんですか？」って、確かにね、Winnyなんか出てた頃なんかまだブラウン管のPC残ってたような時代の事だから、今の若いエンジニアからすればもう理解不能の領域だよね、あの他責思想は。
前の外資ITにいたとき、そこの上司がアメリカの人だったんだけど、「TRONって世界中で使われて普及国産OSだから、端的に言って成功してると思うし、潰されたとか全然そんなことないのに、何であんなに他責思想なんだろうね、日本人エンジニアって」と酒の席で不思議がってたのをよく覚えてる。
「Winnyって、もう20年前の技術でしょ？20年前のパソコンなんて、僕は"シュタインズゲート"でしか見たことないよ」、「そんな昔の事いつまでも引きずってるから世界観からして技術のキャッチアップが偏っちゃってるところあるよね」って後輩の中国人・韓国人エンジニアが突っ込んでたのとも、ちょっと苦笑してしまった。
上司だったアメリカ人も「例えば、イギリス人のITエンジニアがアラン・チューリングは政府に潰されたせいでIT技術はアメリカに奪われたのだ！なんて言ってる人、いる？いないでしょ？いたら頭がおかしい人としか思われないよ」と滅茶苦茶辛辣なツッコミをしていた。
言われてみれば確かにそうだな、と思う。外資で働いてる日本人エンジニアって、俺含めてそういう部分は内心思うところはあるんだけど、口に出したりいつまでも気にしてる人全くいないんだよね。俺お金が稼げるからって理由で特に愛着とかないし。
でも、そういう「こだわりが強い(他責思想の)日本人エンジニア」は外資に挑戦してくることは腐るほど見て来たけど、みんな物にならずに去っていってるから(後述すると一部はハマって活躍できる人たちもいる)、採用コストも含めてその時点で難色を示すっていう「マーフィーの法則の亜種」みたいなのができちゃってて、
しかもこれ、例に挙げたのが前の会社ってだけで、ここ３～４年でどこもみんな似たような認識の話が出てるっていう話。
■ ② 特定のアニメ・サブカル分野が好きな奴は要注意
これも採用・人事考査に響くほどの謎の法則性があるんだよね。具体的な作品名は上げないけど、まぁ所謂「異世界で転生してやり直すとか、悪い女貴族に生まれ変わって…みたいなのがいっぱい書かれてるジャンルの某web小説系」が好きって日本人エンジニア、伏字にすると「●●●系」って奴。
コミュニケーション取ってる中でこの話題が出た時点で、周りの空気がピキって緊張感で凍り付く程割とみんな「あっ…(察し」ってなってしまうくらい、「使えない」というよりコンプライアンス・コミュニケーション的に問題ある「問題児」的な日本人エンジニアは圧倒的にこれが多かった。圧倒的というより、100％そうだった。
というか①に該当しなくとも「②」が発覚した段階で、空を見上げて「Oh…my god…」とみんななってしまうくらいのレベルだった。
正直「①」で上げた様な他責思想気味の人たちでも、もうテック大好き！ってくらいな人たちはこだわりが強いだけで、スキルセットがハマったらかなりうまく外資でも活躍できる可能性があるし、実際そういう人も結構いるんだよね、特にAI系とビッグデータ操れる人材は重宝されてるし。
でもこの「某アニメ分野が好きな」エンジニアって時点で、今までそんな奴一人もいなかった。マジで鍛えれば使えるとかマネジメントでどうこうなるって領域超えたレベルの、酷い奴は対人トラブルまで起こすレベルで、まぁ言葉悪いが「外れガチャ」しかいない。
これ、前の会社どころか、前々、今の会社でも同じような法則性で見てる外人や経営層が多くて、ちょっと笑っちゃった。外資で働いてる人らはてな含めて多いはずなのに、この辺のあるあるネタ出ないの割と不思議だと常々思う。
①と②がそろってるやつの率が圧倒的に35才から上で比率が異常に高かったから、なんか外資系でもそういう法則性みたいなのが流れちゃってるんだろうな、と個人的には思ってる。
まぁ逆に言えば、①と②の傾向がないエンジニアがそれだけ日本でも若手では増えてるから、「日本人のエンジニアだから」って取らないなんてことは全くないんだけども、
これから外資で働いてみたいっていう日本人エンジニアがいたら、①と②には注意してマインドセット変えた方がいいと思うよね、っていう老婆心ながら言いたいかな。
個人的な観測範囲でと前提するが特に②はヤバい、酒でべろんべろんになってたって絶対口が裂けてもいっちゃいけないレベル
しかしまぁどうしてもアニメ以外にコミュニケーションが取れないなら、外人ウケする奴がいい、結構外資は経験値高いんで外人も日本人も上司は40～50代プレイヤー多いから、鉄板は80～90年代のOVA系とか(攻殻とか銀英伝とか、あとGIジョーとかG1トランスフォーマーとか)はまぁ無難かな、って感じ。
■ 1. 記事の概要
- バグ修正のプロセスをReact/React Routerのスクロールバグを実例として体系的に解説した記事
- AIも人間のエンジニアも再現手順なしで修正を試みるという同様の誤りを犯す傾向がある
■ 2. Step 0: 再現手順なしでの修正の失敗
- ClaudeにスクロールバグのFix指示を出したが繰り返し誤った修正を提案した
- useEffectの条件変更やスムーススクロールからインスタントスクロールへの変更などを試みたが効果はなかった
- バグが修正されたかを検証する手段がないことが根本的な失敗の原因
■ 3. Step 1: 再現手順（Repro）の確立
- Reproとはバグが確実に再現できる操作手順であり「何をするか」「期待動作」「実際の動作」の3要素で構成される
- 毎回確実にバグが再現できるReproは信頼性の高い検証を可能にする
- 再現率が低い場合はネットワークのモック化など不確実性の排除が必要
- Claudeはスクリーンを視覚的に確認できないため視覚的なRepro（スクロールのジッター）は有効に機能しない
- 元のReproが使用できない場合は別の形式のReproへの変換で対処可能
■ 4. Step 2: 再現手順の絞り込み
- 別のReproへの変換には新しいReproが元のバグと無関係である可能性というリスクが伴う
- 視覚的なジッターの代わりにスクロール位置の数値変化を測定するReproに変換した
- ボタンクリック前後のdocumentのスクロール位置を計測
- 位置に変化がない状態を「バグあり」として定義
- 新しいReproの有効性を「バグが解消した状態でも正しく機能するか」で必ず検証する
- ネットワークコールをコメントアウトするとスクロール位置に変化が生じることで確認
- コメントイン・コメントアウトを繰り返して因果関係を検証することが望ましい
- 新しいReproが元の問題と完全に一致しなくても関連性が認められれば継続する価値がある
■ 5. Step 3: コードの段階的削除による問題の絞り込み
- 新ブランチを作成し以下のワークフローを繰り返す
- Reproを実行してバグの存在を確認
- 関連コードから何か一部を削除（コンポーネント・イベントハンドラ・条件・スタイル・importなど）
- Reproを再実行してバグの継続を確認
- バグが継続する場合はその変更をコミット
- バグが消えた場合は解消要因の仮説を記録しリセット後により小さな単位で再試行
- Claudeは途中から独自仮説を立ててその検証に特化したテストケースを作成し始めた
- 仮説を立てて検証すること自体は問題ない
- 仮説検証が失敗した場合はバグが再現するチェックポイントに戻り削除を継続することが不可欠
- 「整礎再帰（well-founded recursion）」の概念と同様に常に確実な前進が保証される必要がある
- Fibonacci関数のバグ例（fib(n)がfib(n)を呼び出す無限再帰）を整礎でない再帰の例として示す
- Lean言語ではnが小さくならない再帰をコンパイル時に型エラーとして検出できる
- Reproの削減も同様に常にReproが「小さくなっている」ことを確認しながら進める必要がある
- このプロセスを繰り返すことで最終的には削除できるものがなくなり根本原因が浮かび上がる
■ 6. Step 4: 根本原因の特定
- Step 3のプロセスにより問題が単一ファイルに絞り込まれた
- ファイルをルーターの外に移動すると正常に動作しルーター内に戻すと再び破損した
- トップレベルルートでは動作しルートレイアウト内のネストで破損することが判明した
- 根本原因はReact RouterのScrollRestorationコンポーネントのバグ
- 本来はルート変更時のみ起動すべきところ全てのrevalidation時に起動するバグが存在していた
- アクション経由のネットワークコールがrevalidationを発生させScrollRestorationが起動した
- ScrollRestorationがscrollIntoView実行中に干渉しジッターを引き起こしていた
- 古いバージョンのReact Routerを使用していたことが問題の前提条件
- この手法はFacebookのReactツリーの半分を削除してバグを50行のコードまで絞り込んだ事例でも有効だった
■ 1. 背景と課題
- 組織拡大に伴う意思決定のボトルネック:
- 開発タスクは回るが予算や採用などの経営判断はCTOに集中
- 承認待ちの発生により組織運営の停滞が発生
- 2019年頃のプロダクトチーム拡大期に課題が顕在化
■ 2. 経営チームという解決策
- 仕組みの概要:
- CTOが担っていた責務を複数チームに分割
- 各チームへ意思決定に必要な裁量を委譲
- 特定個人の承認待ちを回避し素早い意思決定を実現
- リーダー職と経営タスクの分離:
- リーダーにならずとも経営タスクへの参加を可能に
- 柔軟な参加と離脱を実現
- 個人の状況に応じた関わり方を許容
■ 3. 権限委譲の方法
- 全権委譲の方針:
- 段階的ではなく担当領域全てを委譲
- 採用チームなら採用領域全て、コンピテンシーチームなら評価基準全てを担当
- サポート体制:
- 初期は領域を知る人物が伴走
- 一定期間後にチームへ完全移行
- 迷った際の相談体制を維持
- 全権委譲の意図:
- 部分的委譲では全体感の把握が困難
- ボトルネック解消の実効性確保
■ 4. 経営チームの構成と運営
- 経営と運営の分離:
- 経営チームは「何をやるか」の設計と意思決定を担当
- 日々の実務オペレーションは担当外
- 本業である開発への影響を最小化
- チーム構成:
- 現在13チームが存在（承認、採用、新卒採用、ブランディング、コンピテンシー、kickoff-techforum、メンタルヘルス、360FB & 個人OKR、オンボーディング、構造化面接、原則、ブルー、戦略担当）
- 各チーム2〜4人のメンバーで構成
- 状況に応じて新設や統廃合を実施
- メンバーの流動性:
- 6〜12カ月に平均1〜2回のシャッフル
- 別チームへの移動や開発集中のための離脱が可能
- 掛け持ちやスカウトも許容
- 経営チーム活動は週2時間までを目安に設定
■ 5. エンジニアが兼任する理由
- 組織文化との整合性:
- ユーザベースの「34の約束」における「自己規律」の重視
- 自分たちで考え判断し行動する文化
- XPの価値観:
- 現場に近い人間による意思決定
- 小さく試してフィードバックを素早く回す考え方
- 実態に即した判断:
- 開発現場のコンテキストを深く理解した上での判断が可能
- エンジニアの実情に即した無理のない意思決定を実現
■ 6. エンジニア個人へのメリット
- 小さく始めるトレーニング:
- 正解不明な状況での意思決定力を養成
- フィードバックサイクルを速く回す考え方は開発と共通
- より高い不確実性下での判断訓練の機会
- 視座と意識の変化:
- 組織全体を考える時間の確保
- 違和感への対処意識の向上
- チームや組織全体にプラスとなる振る舞いへの意識醸成
■ 7. 事例1: 採用チーム
- 課題:
- 指名受託率の低下
- 採用基準のメンバー間でのブレ
- 解決策としてのドラフトコーチ導入:
- 組織理解が深く経験豊富なメンバーがコーチ役を担当
- 指名判断前の必須相談プロセスを追加
- 成果:
- 判断基準の学習機会の提供
- 言語化プロセスによる情報整理と判断の明確化
- メンバーの心理的負担軽減と質の向上
- 当事者としての関与:
- 課題発見から改善実施までを自ら担当
- 仕組みとしての課題解決によるやりがい
■ 8. 事例2: 構造化面接チーム
- 目的:
- 面接評価のブレ軽減
- 構造化面接アプローチの導入
- 段階的導入戦略:
- 正社員面接への導入決定
- 一次面接のみでの実施
- ひとつの設問に限定
- スピード重視の意思決定:
- 小さくリリースして早期フィードバック取得
- 定例ミーティングでの背景説明と質疑応答
- 意思決定の透明性確保:
- 背景共有による納得感の醸成
- 建設的な提案を引き出す効果
■ 9. カオスCTOによる実証
- 取り組み内容:
- 2025年1〜3月の3カ月間CTOが経営業務から離脱
- CTO業務は原則として他メンバーへ委譲
- 必須業務のみCTOが対応
- 結果:
- メンバーの反応は落ち着いており大きな問題なく進行
- 採用活動や評価基準改定などが自律的に実施
- 組織のボトルネック可視化の負荷テストとして機能
- 組織強度の実証:
- 経営チームによる自律的な経営タスク遂行を確認
■ 10. 自己組織化の追求
- 自由と責任の考え方:
- 技術選定やプロジェクト進め方への大きな裁量（自由）の付与
- 成果創出と組織健全性維持という責任とセット
- 経営チーム参加の位置付け:
- やらされる仕事ではなく自由を守るための活動
- エンジニアとしての責任を果たす重要な取り組み
- 自己組織化の定義:
- 自らの手で組織ボトルネックを解消
- 最高のパフォーマンスを発揮できる環境の自律的構築
■ 1. 背景と概要
- PostgreSQLはChatGPTやOpenAIのAPIなどの中核製品を支える最も重要な基盤データシステムの一つである
- ユーザーベースが急速に拡大するにつれてデータベースへの要求も指数関数的に増加している
- この1年でPostgreSQLの負荷は10倍以上増加しており現在も急速に増え続けている
- PostgreSQLはこれまで考えられていたよりもはるかに大きな読み取り中心のワークロードを確実にサポートできるように拡張できる
- 単一のプライマリAzure PostgreSQLフレキシブルサーバーインスタンスと世界中の複数のリージョンに分散された約50のリードレプリカを使用して大規模なグローバルトラフィックをサポートしている
- 厳密な最適化と確固たるエンジニアリングを通じて8億人のユーザー向けに毎秒数百万件のクエリをサポートするに至った
■ 2. 当初の設計の欠陥と課題
- ChatGPTの公開後トラフィックはこれまでにない速度で増加した
- アプリケーション層とPostgreSQLデータベース層の両方で広範な最適化を迅速に実装した
- インスタンスサイズを増やしてスケールアップしさらにリードレプリカを追加してスケールアウトした
- 単一のプライマリアーキテクチャがOpenAIの規模の要求を満たすことができるというのは驚くべきことである
- 実際にこれを実現するのは簡単ではない
- Postgresの過負荷によるSEVを複数確認しておりその多くは同じパターンに従っている:
- 上流の問題がデータベース負荷の急激な増加を引き起こす
- キャッシュ層の障害による広範なキャッシュミス
- CPUを飽和させる高コストなマルチウェイ結合の急増
- 新機能リリースに伴う書き込み集中
- リソース使用率が上昇するとクエリの遅延が増加しリクエストがタイムアウトし始める
- 再試行によって負荷がさらに増大し悪循環を引き起こす
- ChatGPTとAPIサービス全体の性能を低下させる可能性がある
- PostgreSQLは読み込みが多いワークロードに対してはスケーラビリティが高い
- 書き込みトラフィックが多い時期には依然として課題がある:
- PostgreSQLのマルチバージョン同時実行制御（MVCC）の実装によるもので書き込みが多いワークロードに対しては効率が低下する
- クエリがタプルや単一のフィールドを更新する際には新しいバージョンを作成するために行全体がコピーされる
- 書き込み負荷が高い状況下では深刻な書き込み増幅を引き起こす
- クエリが最新のデータを取得するために複数のタプルバージョンをスキャンしなければならないため読み取り増幅も増大する
- MVCCはさらにテーブルやインデックスの肥大化インデックスメンテナンスのオーバーヘッド増加複雑なautovacuumのチューニングといった課題をもたらす
■ 3. 全体的な戦略
- 書き込み負荷を軽減するためシャード化可能な書き込み集約型ワークロードをAzure Cosmos DBなどのシャード化システムへ移行し続けている
- アプリケーションロジックを最適化し不要な書き込みを最小限に抑えている
- 現行のPostgreSQLデプロイメントへの新規テーブル追加は許可していない
- 新しいワークロードはデフォルトでシャードシステムに設定される
- インフラが進化してきたにもかかわらずPostgreSQLはシャーディングされず単一のプライマリインスタンスがすべての書き込みを処理している
- 主な理由:
- 既存のアプリケーションのワークロードをシャーディングすることは非常に複雑で時間がかかる
- 数百のアプリケーションエンドポイントの変更が必要となる
- 数か月場合によっては数年かかる可能性がある
- ワークロードは主に読み取り中心であり広範な最適化を実装している
- 現在のアーキテクチャでも継続的なトラフィック増加を支えるのに十分な余力がある
- 将来的にPostgreSQLのシャーディングを行う可能性を排除しているわけではない
- 現在および今後の成長に対して十分な余裕があるため短期的な優先事項ではない
■ 4. プライマリの負荷軽減
- 課題:
- ライターが1つのみのため単一プライマリ構成では書き込みを拡張できない
- 書き込みの急増が発生するとプライマリノードが瞬時に過負荷状態となる
- ChatGPTやAPIなどのサービスに影響を及ぼす
- 解決策:
- 書き込みの急増に対応できる十分な容量を確保するためプライマリノードへの負荷を可能な限り最小化する
- 読み取りトラフィックは可能な限りレプリカにオフロードする
- 一部の読み取りクエリは書き込みトランザクションの一部であるためプライマリに残す必要がある
- それらについては効率性を確保し低速のクエリを回避することに注力する
- 書き込みトラフィックに関してはシャード化可能で書き込み負荷の高いワークロードをAzure CosmosDBなどのシャード化されたシステムに移行した
- シャーディングが難しいのに書き込み量が多いワークロードは移行に時間がかかりそのプロセスは現在も進行中である
- 書き込み負荷を減らすためにアプリケーションを積極的に最適化した
- 冗長な書き込みを引き起こしていたアプリケーションのバグを修正した
- 適切な場合には遅延書き込みを導入してトラフィックの急増を緩和した
- テーブルフィールドをバックフィルする際には過剰な書き込み負荷を防ぐために厳格なレート制限を設けている
■ 5. クエリの最適化
- 課題:
- PostgreSQLでコストのかかるクエリをいくつか特定した
- 過去にはこれらのクエリの処理量が急増すると大量のCPUリソースを消費した
- ChatGPTとAPIリクエストの両方の速度が低下していた
- 解決策:
- 多くのテーブルを結合するような高コストなクエリが少数存在するだけでサービス全体のパフォーマンスが著しく低下したり最悪の場合は停止することがある
- PostgreSQLクエリを継続的に最適化し効率を確保して一般的なオンライントランザクション処理（OLTP）のアンチパターンを回避する必要がある
- 12個のテーブルを結合する非常にコストのかかるクエリを特定した
- このクエリの急増が過去に重大度の高いSEVの原因となっていた
- 可能な限り複雑なマルチテーブル結合は避けるべきである
- 結合が必要な場合はクエリを分解することを検討し複雑な結合ロジックは代わりにアプリケーション層へ移すようにした
- これらの問題のあるクエリの多くはオブジェクトリレーショナルマッピング（ORM）フレームワークによって生成される
- 生成されたSQLを注意深く確認し期待通りに動作することを確認することが重要である
- PostgreSQLでは長時間アイドル状態のクエリが見つかることも一般的である
- idle_in_transaction_session_timeoutのようなタイムアウトを設定することはautovacuumのブロックを防ぐために不可欠である
■ 6. 単一障害点の軽減
- 課題:
- 読み取りレプリカがダウンした場合でもトラフィックは他のレプリカにルーティングされる
- 単一のライターに依存するということは単一障害点が存在することを意味する
- そのライターがダウンするとサービス全体が影響を受ける
- 解決策:
- 最も重要なリクエストには読み取りクエリのみが関係する
- プライマリにおける単一障害点を軽減するためにこれらの読み取りをライターからレプリカにオフロードした
- プライマリがダウンした場合でもこれらのリクエストが引き続き処理されるようにした
- 書き込み操作は引き続き失敗するが影響は軽減されている
- 読み取りは利用可能なままのためSEV0ではなくなる
- プライマリの障害を軽減するためにプライマリは高可用性（HA）モードでホットスタンバイと共に運用している
- ホットスタンバイは常に同期されているレプリカでいつでもトラフィックの処理を引き継ぐ準備ができている
- プライマリがダウンしたりメンテナンスのためにオフラインにする必要がある場合はスタンバイをすぐに昇格させてダウンタイムを最小限に抑えることができる
- Azure PostgreSQLチームは非常に高い負荷がかかってもこれらのフェイルオーバーの安全性と信頼性を確保するために多大な努力を払ってきた
- リードレプリカの障害に対処するため各リージョンに十分な余裕を持たせて複数のレプリカを配置している
- 単一のレプリカ障害がリージョン全体の障害につながらないようにしている
■ 7. ワークロードの分離
- 課題:
- PostgreSQLインスタンスにおいて特定のリクエストがリソースを過剰に消費する状況が頻繁に発生する
- 同じインスタンス上で実行されている他のワークロードのパフォーマンスが低下する可能性がある
- 新しい機能の導入によりPostgreSQLのCPUを多く消費する非効率なクエリが発生し他の重要な機能のリクエストが遅くなることがある
- 解決策:
- ノイジーネイバー問題を緩和するためワークロードを専有インスタンスに分離する
- リソース集約的なリクエストの急増が他のトラフィックに影響しないようにする
- リクエストを低優先度と高優先度の層に分けそれぞれを別のインスタンスに振り分ける
- 優先度の低いワークロードがリソースを大量に消費する状態になっても優先度の高いリクエストのパフォーマンスが低下することはない
- 異なる製品やサービス間でも同様の戦略を適用する
- ある製品での活動が別の製品のパフォーマンスや信頼性に影響を与えないようにしている
■ 8. 接続プール
- 課題:
- 各インスタンスには最大接続数制限（Azure PostgreSQLでは5000）がある
- 接続が不足したりアイドル状態の接続が過剰に蓄積したりしやすい状況である
- 過去には接続ストームにより利用可能な接続が全て枯渇する事象が発生した
- 解決策:
- データベース接続をプールするためにプロキシレイヤーとしてPgBouncerを導入した
- ステートメントまたはトランザクションプールモードで実行することで接続を効率的に再利用できアクティブなクライアント接続数を大幅に削減できる
- 接続設定の遅延も短縮されベンチマークでは平均接続時間が50ミリ秒から5ミリ秒に低下した
- リージョン間の接続やリクエストはコストがかかるためプロキシクライアントレプリカを同一リージョンに配置している
- ネットワークオーバーヘッドと接続使用時間を最小限に抑えている
- PgBouncerは慎重に設定する必要がある
- アイドルタイムアウトのような設定は接続の枯渇を防ぐために非常に重要である
- 各リードレプリカは複数のPgBouncerポッドを実行する独自のKubernetesデプロイメントを保持している
- 同じKubernetesサービスの背後で複数のKubernetesデプロイメントを実行しポッド間でトラフィックの負荷を分散する
■ 9. キャッシュ
- 課題:
- キャッシュミスの急増によりPostgreSQLデータベースの読み取りが急増しCPUが飽和状態になりユーザーリクエストが遅くなる可能性がある
- 解決策:
- PostgreSQLへの読み込み負荷を軽減するためにキャッシュ層を使用して大部分の読み込みトラフィックを処理する
- キャッシュヒット率が予期せず低下した場合キャッシュミスが急増することで大量のリクエストがPostgreSQLに直接押し寄せることがある
- データベースの読み取りが急増するとかなりのリソースを消費しサービスの速度が低下する
- キャッシュミス集中時の過負荷を防ぐため特定のキーでミスした読み取りプロセスがPostgreSQLからデータを取得するのは1つだけとなるようキャッシュロック（およびリース）機構を実装している
- 複数のリクエストが同一キャッシュキーでミスした場合1つのリクエストのみがロックを取得しデータ取得とキャッシュ再構築を実行する
- 他のすべてのリクエストはPostgreSQLに一斉にアクセスするのではなくキャッシュが更新されるのを待つ
- これにより冗長なデータベースの読み取りが大幅に減少し連鎖的な負荷の急増からシステムを保護する
■ 10. リードレプリカの拡張
- 課題:
- プライマリはすべてのリードレプリカにログ先行書き込み（WAL）データを書き込む
- レプリカ数が増加するにつれてプライマリはより多くのインスタンスにWALを送信する必要がある
- ネットワーク帯域幅とCPUの両方に負荷がかかる
- これによりレプリカの遅延がより高く不安定になりシステムを信頼性高く拡張することが難しくなる
- 解決策:
- 遅延を最小限に抑えるため複数の地理的リージョンにわたり約50のリードレプリカを運用している
- 現在のアーキテクチャではプライマリはすべてのレプリカにWALをストリーミングする必要がある
- 現時点では非常に大規模なインスタンスタイプと高ネットワーク帯域幅で適切に拡張できる
- プライマリに過負荷をかけずにレプリカを無期限に追加し続けることはできない
- この問題を解決するためにAzure PostgreSQLチームと協力して中間レプリカがWALを下流レプリカに中継するカスケードレプリケーションを導入している
- このアプローチによりプライマリに負担をかけずに潜在的に100以上のレプリカに拡張できる
- しかしこれにより運用上の複雑さが増し特にフェイルオーバー管理において顕著になる
- この機能はまだテスト中である
- 本番環境に展開する前に堅牢性と安全なフェイルオーバーが可能であることを確認予定である
■ 11. レート制限
- 課題:
- 特定のエンドポイントでの突然のトラフィック急増高コストなクエリの急増またはリトライストームにより重要なリソースが急速に枯渇する
- CPU、I/O、接続などのリソースが枯渇し広範囲にわたるサービスの劣化を引き起こすことがある
- 解決策:
- 突然のトラフィックの急増によってデータベースインスタンスが過負荷になり連鎖的な障害が発生するのを防ぐためアプリケーションコネクションプーラープロキシクエリの複数のレイヤーにわたってレート制限を実装した
- リトライ間隔が短すぎるとリトライストームを引き起こす可能性があるためこれを避けることも極めて重要である
- レート制限をサポートし必要に応じて特定のクエリダイジェストを完全にブロックできるようORMレイヤーを強化した
- この的を絞った負荷遮断により高コストなクエリの急増から迅速に復旧することができる
■ 12. スキーマ管理
- 課題:
- 列の型変更といった小さなスキーマ変更でもテーブル全体の書き換えを引き起こす可能性がある
- スキーマ変更は慎重に適用し軽量な操作に限定するとともにテーブル全体を書き換える変更は避ける必要がある
- 解決策:
- 特定の列の追加や削除などテーブル全体の書き換えを引き起こさない軽量なスキーマ変更のみを許可する
- スキーマ変更には厳格に5秒のタイムアウトを設けている
- インデックスの作成と削除は同時に行うことができる
- スキーマの変更は既存のテーブルに限定されている
- 新機能に追加のテーブルが必要な場合それらはPostgreSQLではなくAzure CosmosDBなどの代替シャーディングシステムに配置する必要がある
- テーブルフィールドをバックフィルする際には書き込みの急増を防ぐために厳格なレート制限を適用する
- このプロセスは時には1週間以上かかることがあるが安定性を確保し本番環境への影響を避けることができる
■ 13. 結果と今後の道筋
- 達成した成果:
- 適切な設計と最適化によりAzure PostgreSQLが最大規模の本番ワークロードに対応できるよう拡張できることを実証した
- PostgreSQLは読み込み中心のワークロードで数百万QPSを処理している
- ChatGPTやAPIプラットフォームなどOpenAIの最も重要な製品を支えている
- レプリケーション遅延をほぼゼロに保ちながら約50のリードレプリカを追加した
- 地理的に分散したリージョン間で低遅延の読み取りを維持している
- 将来の成長を支える十分なキャパシティの余裕を確保した
- 遅延を最小限に抑えながら信頼性を向上させる形で機能している
- 本番環境ではクライアント側のレイテンシの99パーセンタイルを常に2桁ミリ秒台前半で維持している
- 99.999%の可用性を実現している
- 過去12か月間で発生したPostgreSQLの重大障害（SEV-0）は1件のみであった（ChatGPT ImageGenのバイラルローンチ時に発生し1週間で1億人以上の新規ユーザーが登録し書き込みトラフィックが10倍以上に急増した）
- 今後の取り組み:
- PostgreSQLがこれまで当社を支えてくれたことには満足している
- 将来の成長に向けて十分な運営余力を確保できるよう引き続きその限界に挑戦していく
- 既にシャード可能な書き込み集約型ワークロードはCosmosDBなどのシャード化されたシステムへ移行済みである
- 残っている書き込み負荷の高いワークロードはシャーディングがより難しいためPostgreSQLのプライマリからの書き込みをさらに軽減すべくそれらについても積極的に移行を進めている
- Azureと協力してカスケードレプリケーションを有効化しより多くのリードレプリカを安全に拡張できるようにしている
- インフラストラクチャの需要が拡大し続けるにつれてシャード化されたPostgreSQLや代替の分散システムなどさらなる拡張のための追加のアプローチを模索し続けていく
SSL/TLSプロトコルを実装したオープンソースライブラリ「OpenSSL」が、1月27日にアップデートされた。複数の脆弱性が修正されているので注意が必要だ。
今回のリリースで修正された脆弱性は、以下の12件（括弧内は深刻度の評価）。
- CVE-2025-11187：PBMAC1パラメーターの不適切な検証が原因でコードが実行される。v3.6 / v3.5 / v3.4系統のみに影響（Moderate）
- CVE-2025-15467：CMS AuthEnvelopedDataメッセージの解析でスタックバッファオーバーフローが発生し、DoSやリモートコード実行が引き起こされる。v3.6 / v3.5 / v3.4 / v3.3 / v3.0系統のみに影響（High）
- CVE-2025-15468：不明な暗号スイートを受信するとDoSが発生する。v3.6 / v3.5 / v3.4 / v3.3系統のみに影響（Low）
- CVE-2025-15469：ワンショット署名アルゴリズムを使用する際の整合性ギャップ。v3.6系統のみに影響。v3.6 / v3.5系統のみに影響（Low）
- CVE-2025-66199：証明書の圧縮を使用するTLS 1.3接続でサービスの低下やリソース枯渇（DoS）が引き起こされる。v3.6 / v3.5 / v3.4 / v3.3系統のみに影響（Low）
- CVE-2025-68160：BIO_f_linebufferの範囲外書き込みによるDoS（Low）
- CVE-2025-69418：低レベルの OCB 関数呼び出しによるデータの読み取りや改竄。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）
- CVE-2025-69419：PKCS12_get_friendlyname()におけるUTF-8変換の範囲外書き込みによりDoSなどが発生する。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）
- CVE-2025-69420：TimeStamp Response検証コードの型混乱によるDoS。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）
- CVE-2025-69421：PKCS12_item_decrypt_d2i_ex関数におけるNULLポインター参照によるDoS（Low）
- CVE-2026-22795：PKCS#12ファイルの処理で発生するNULLポインター参照によるDoS。v3.6 / v3.5 / v3.4 / v3.3 / v3.0 / v1.1系統のみに影響（Low）
- CVE-2026-22796：PKCS7_digest_from_attributes()関数における型混乱によるDoS（Low）
開発チームは、以下のバージョンへのアップデートを推奨している。
- 3.6.1
- 3.5.5
- 3.4.4
- 3.3.6
- 3.0.19
■ 1. Faciloの事業とプロダクトの現状
- Faciloは不動産仲介における煩雑な業務や顧客とのコミュニケーションを一元化可視化するSaaSを提供している
- 不動産仲介というマーケットは非常に複雑である:
- 複数の関係者が絡む
- 取引が同時並行で進む
- 営業担当者は物件情報をPDF化してメールやLINEで送り内見調整の電話をする
- プロダクト導入により業務が改善され仲介営業としての自信がついたという声がある
- 毎朝仕事を始めるときにOutlookと一緒にFaciloを立ち上げる光景が当たり前になりつつある
- 業務に深く根付いてきている手応えを感じている
■ 2. マルチプロダクト戦略への転換
- 資金調達の際に思い描いていたプロダクトは二つのみであった:
- Facilo物件購入クラウド（祖業で一番最初に作ったプロダクト）
- Facilo物件売却クラウド（購入と表裏一体の売却を支援）
- 当初は長らく一点突破型で走ってきた
- 現在はFacilo賃貸仲介クラウドとFacilo事業用クラウドが加わり4つのプロダクトを擁するマルチプロダクトなプラットフォームビジネスになっている
- マルチプロダクト戦略を最初から戦略として目的化したことは一度もない
- スタートアップとしてはやるべきことを絞るべきだという考え方がありマルチプロダクトに対してはアンチパターンという捉え方であった
- 現在はマルチプロダクト化に振り切っている:
- 物件購入クラウドの導入が進み顧客との接点が増えた
- このペインも解けるかもしれないという課題の解像度が一気に上がってきた
- 顧客課題の詳細:
- 不動産仲介の会社は売買と賃貸の両方を手がけているケースが多い
- 売買の二つのプロダクトのコンセプトや技術力を評価されながらもドメインがずれている賃貸には対応できなかった
- 賃貸でも使いたいという声をたくさんいただき賃貸仲介クラウドをリリースした
- 店舗やビルやオフィスといった事業用の不動産でもプロダクトを使いたいという声をいただき事業用クラウドが生まれた
- 現場の声に対応していった結果である
- フェーズの推移:
- フェーズ1:物件購入クラウドに集中する一点突破の期間
- フェーズ2:顧客の声に沿ってマルチプロダクト化していった期間
- フェーズ3:より戦略的にプロダクト間をつなげて複合的な課題を解決していく構想
- 段階を経てマルチプロダクト戦略になっていったがそれはあくまでも手段である
■ 3. マルチプロダクト化を支える技術的準備
- CTOの梅林はいつかはマルチプロダクトになっていくんだろうなという思いが創業時からあった:
- バーティカルSaaSにとってマルチプロダクト戦略でいろいろなプロダクトを作っていくことはベストプラクティスである
- プロダクトが増えるタイミングで人構成運用が一気に複雑化しがちである
- そこに耐えられる共通の型を先につくっておく必要がある
- もしそうなったときに開発スピードが落ちる構成だけは絶対に避けたいとずっと考えてきた
- Ruby on Railsというフレームワークを選んだ理由:
- 誰が触っても同じ構造ですぐに次を作れることを重視した
- 創業時としては最適な技術選定であった
- Railsのメリット:
- 普通の会社ではオンボーディングした新しいエンジニアが最初にリリースをするまでには早くても1週間程度かかる
- Faciloではライトなチケットであればオンボーディング初日にリリースができるくらい手軽である
- ローカル開発環境のセットアップが非常に単純化されている
- インフラもシンプルに保たれている
■ 4. シングルデータベース設計
- 教科書的な設計であればプロダクトごとにデータベースを構築するのが当たり前である
- Faciloではデータベースは一つである:
- 物理的にはシングルデータベースクラスタで複数のプロダクトを運用している
- 論理的にネームスペースをプロダクトごとに分けている
- スケーリング戦略:
- データベースはまず縦にスケールさせる戦略を取っている
- 10年前20年前のインフラであれば一つのサイズを大きくするにも一定の限界があったため横にスケールさせる戦略しか取れなかった
- 現在のデータベースの性能は昔に比べてはるかにアップしている
- サイズ自体を限界まで大きくしたいと考えている
- BtoBのサービスがメインで数千万ユーザーを相手にするような大規模なBtoCサービスとは前提が異なる
- 保守運用体制:
- この人じゃないと管理できないというような属人化しやすい専門の人を作らないようにしたい
- FaciloにはSREもいない
- エンジニア全員にインフラやCI/CDパイプラインの流れを理解してほしいと考えている
- ソフトウェア開発とSREというように組織を分けてインフラ側がバックエンドエンジニアがインフラのことを何も気にせずに触れるような環境を作ったよとやってしまうとブラックボックス化してしまう
- バックエンドエンジニアがインフラのことを常に理解しその上でいかに監視コストを減らしていくかを考えるべきである
■ 5. 外部キー制約と削除フラグを設けない設計
- Faciloでは外部キー制約を設けていない
- 重視しているのは認知コストを下げることとスケールしにくい書き込み処理をできるだけ早くすることである
- 銀行のシステムのように整合性が非常に大切なドメインであればトランザクションをしっかり組みデータベースの整合性を厳密に管理すべきである
- 削除フラグの問題:
- とりあえず入れてしまうとこのテーブルには削除フラグがあるかこのクエリでは考慮が必要かといった判断があらゆる場所で発生する
- 開発時の認知コストがどんどん上がってしまう
- Faciloの場合はそもそもなぜ削除フラグが必要なのかから考える:
- 誤操作から復元したいのであればまず誤操作が起きにくいUXにする
- それでも誤操作が起きるとしたら年に何件なのかその確率と設計の複雑さのトレードオフで考える
- 実は削除フラグではなく更新履歴として違うものをつくるべきかもしれない
- 問題の本質を常に考えながら設計が開発効率に与える影響を吟味している
- 復元が必要なケースについても今のAI時代はCloudWatchのログをAIエージェントにgrepさせることで人力でも十分対応できる
■ 6. ベストプラクティスを前提にしない設計思想
- 組織設計にしろデータベース設計にしろ教科書的にはアンチパターンとされる手法を選択している
- ベストプラクティス自体は過去の経験や教科書を通して一通り学んできた
- Faciloのビジネスや規模を前提に考えると本当にそこまで必要なのかを毎回問い直している
- 教科書的には正しいとされる構成でも運用や組織まで含めて見るとかえって複雑さを招くこともある
- 過去の大きな組織での経験:
- インフラが強く抽象化され過ぎていて裏側で何が起きているのか分からないことに強い違和感を持った
- 本来は開発しやすくなるはずの仕組みなのに実際にはインフラエンジニアへの問い合わせが増え承認フローもどんどん複雑になっていく
- 開発側も運用側も幸せになっていないのではないかと思った
- インフラとアプリケーションは密接に結びついている:
- バックエンドエンジニア自身がインフラを理解し自分の操作とシステムの挙動が結びつく手触り感を持った方が自然である
- 技術選定の判断:
- 一見すると何も知らないエンジニアが作った構成に見えるかもしれない
- ベストプラクティスとしてある分散構成やハイパフォーマンスなシステム構築をすぐに候補から外したわけではない
- Redisを使えばキャッシュやセッション管理やキューなどを高い性能で処理できる
- その性能がオーバーエンジニアリングではないのかと期待されるスループット量から逆算しどの程度ちゃんと作るべきなのかを常に見極めている
- そうした判断の積み重ねがシステムと組織のスケーラビリティを支えるシンプルさにつながっている
- 組織設計への適用:
- エンジニア職種が20人程度という今の規模であれば横断組織を作るよりもチームを小さく保ち全員が同じ設計思想を共有している方がスピードを落とさずに済む
- エンジニアだけで100人200人を超えたり世界中で分散して開発を進めているような組織であれば縦割りにしたり横断組織を作ったりする必要がある
- 組織構造のベストプラクティスも理解しているがそれがどんな規模の企業での前提で語られているのかを見た上で現在のFaciloにとって本当に必要かどうかを見ている
■ 7. カルチャーとしての手触り感
- 会社として大事にしていることとエンジニア組織の考え方がきれいにリンクしている
- 二つの重要な要素:
- 手段と目的を逆転させないこと:
- 目的はクライアント企業の課題解決や事業成長である
- そのためにプロダクトがあり技術がある
- この順番を組織全体で共有している
- モノ作りが好きでそのプロダクトを通してお客さまやその接点となるカスタマーサクセスやセールスにありがとうと言ってもらえる手触り感が好きというカルチャーが会社全体に共通している
- 定石を理解した上であえて型を外すという姿勢:
- 一見するとセオリーから外れているように見える部分も基礎を押さえた上で事業や組織にとって最適だと考えて選んでいる
- エンジニアに限らずセールスやカスタマーサクセスなど全職種に共通する考え方である
- 型を破る判断基準:
- 常に型を破ることが目的ではない
- アプリケーションのコード自体はRailsのレールに乗って定石通りに作る
- インフラやDB設計はビジネスの速度を優先してあえて定石を外す
- どこは定石通りに作りどこであえて外すかを常に見極めている
- Railsの良さを生かせる場面ではあえてサーバサイドレンダリングを採用しフレームワークの王道から外れない使い方をしている
- よりインタラクティブな体験が求められる部分ではReactを使ったSPA構成を選ぶこともある
- 全てを最新技術で固めるのではなく標準的な作りで十分なところはシンプルにという方針で敬遠されがちなStimulusも普通に使っている
- 型から外れること自体を目的にしてしまうとそれもまた手段の目的化になる
- 急成長を支える開発スピード:
- セールスやCSが現場接点の中でいただいた要望やフィードバックは1営業日以内にSlackのフォームから投稿するルールにしている
- プロダクトマネージャーがチケット化してエンジニアにつなぐサイクルを通して週に10件から20件の機能をリリースしてきた
- お客さまから見たことのないスピードで対応してもらえていると高く評価されている
■ 8. 全社的なAI活用の展開
- 2024年12月にChatGPT Proを全エンジニアに配布した:
- 当時シリコンバレーに住んでいた梅林が生成AIに対応しないといけないと危機感を抱いた
- 梅林がコードを書いたら負けと宣言し生成AIだけで開発する期間を2カ月ほど設けた
- エンジニアにAIはまだ微妙でしょという意識があるとAIの能力を過小評価したままコードを書き続けてしまいAIフレンドリーになれない
- AIをしっかり信頼し一度エディタを捨ててみようと提案して開発してもらった
- AI自体の進化もあるがみんながAIをどう活用すべきかを真剣に考えるようになり開発組織においてはAIが相棒のようになってきた
- 2025年2月に標準ツールとして全エンジニアにDevinアカウントを作成し段階的に全社員へ活用範囲を広げた
- 最初は試行錯誤であったがこの数カ月で実運用に耐えるレベルまで安定してきた
- 組織としてのAI活用の3段階:
- 第1段階:エンジニアの開発での活用:
- 各自が最適な使い方を見出した
- 開発生産性は体感で3倍ほどに向上した
- 第2段階:PdM業務への展開:
- エンジニアがPdMでも自然言語で安全に開発できる環境を整えた
- PdM自身が自分でできるかどうかを判断し軽微な修正であれば自ら実装からデプロイまで行うようになっている
- 第3段階:セールスやCSへの展開:
- 仕様確認や簡単な分析をSlack上で自然言語で尋ねると即座に返ってくる仕組みを整えた
- エンジニアへの問い合わせが減り現場のスピードが大きく向上している
- 単なる効率化ではなく業務の進め方や役割そのものが変わる変革レベルの変化を感じている
■ 9. AI時代のエンジニアの価値
- ゼロからこういうものを作りたいという程度ならばDevinに依頼すれば作れる
- 要求を満たす複数の解法の中からそれぞれの善し悪しについても何度も尋ねて往復を重ねればたどり着けるがこうしたプロセス自体が大きなロスになる
- エンジニア相手であれば往復の回数は絶対に減る
- 今までの技術の蓄積や知識を使っていかに最少のラリーで最適なものを導けるかがエンジニアに求められていく
- CEO市川自身もDevinを使ってハンズオンで開発するようになっている:
- エンジニアがどれだけ複雑で高度なことをさまざまなプレッシャーの中でやってくれているのかよく分かるようになった
- 広い視野を持って依存関係なども意識しながら課題を解いてくれている
- PdMがハンズオンで開発できるようになってエンジニア不要論者になっているかというとむしろ逆でエンジニアの価値を再認識した感覚がある
■ 10. Faciloのエンジニアにとっての魅力
- 不動産仲介という分野が扱う住まいはあらゆる人の人生の根幹である
- 人口減少で多くの市場が縮小する中でも中古不動産流通など成長分野があり、なおかつデジタル化の余地が大きい希有なマーケットである
- そんな市場に向かい合いながらプロダクトを通してやりがいや手触り感を得られるのはエンジニアにとっても大きな魅力である
- CTOとしていかにエンジニアが快適にプロダクトの開発にコミットできるかということだけを常に考えている
- その考え方は無駄なコミュニケーションを省き必要なコミュニケーションをしっかり取るという組織のあり方やインフラの思想にも表れている
- AI時代になり技術選定そのものの重要性は相対的に下がってきている
- Faciloではその前提に立った上でAIの活用にフルベットしている
- 他社と比べても非常に高い割合で活用しており今後はエンジニアの人材戦略においてもAIを使いこなせるかどうかが重要な指標になると考えている
- Faciloではより先進的なAIの活用方法を学べる