DX・Web開発・生成AIに関する知見をお届けします。

開発生産性の可視化ツールは、どの製品にするかから考え始めると失敗しやすい領域です。専業SaaS・オブザーバビリティ統合・プラットフォーム内蔵・OSSセルフホスト・サーベイ併用の5タイプ分類、データソース適合や指標定義の透明性など比較の8つの軸、手集計から始めてPoCを経て展開する導入の順序を、製品の機能比較より賞味期限の長い形で整理します。

サイクルタイムとは、開発の作業に着手してから完了するまでの経過時間です。起点の違いによるリードタイムとの使い分け、DORAの変更リードタイムがむしろサイクルタイム寄りであるという定義の揺れ、平均ではなくパーセンタイルで見る測り方、そしてリトルの法則から導かれる「WIPを減らす」という短縮の打ち手までを整理します。

AI駆動開発(AIDD)を理解するために必要な基礎用語30語を、開発スタイル、生成AIとコンテキスト、AIエージェントとツール連携、実行環境、品質とリスク管理の5分類で解説します。SDD、MCP、コンテキストエンジニアリング、ガードレールなど、実務で登場する順に整理した用語集です。

XSS・SQLインジェクション・IDOR・サプライチェーン攻撃など31の攻撃と脆弱性を、ブラウザ・入力・認証・認可・状態・運用の六つの攻撃面に整理し、「信頼境界の設計」として捉え直す総論ガイドです。個別脆弱性の暗記ではなく、設計・開発・運用の各工程に防御を組み込む方法、事業リスクにもとづく優先順位づけ、自社の現在地を確認する15項目までを経営層・開発責任者向けにまとめます。

技術的な完成度と、顧客が購入を決めることの間にはいくつもの条件があります。売れないときに「機能が足りない」と判断して開発を続けると、原因が価格や導線にあっても技術予算だけが減っていきます。売れない理由を相手・課題・価格・導線・タイミングの五つに切り分ける方法、実装前に一人の顧客へ価格付きで確かめる七つの手順、称賛ではなく次の行動で反応を読む基準、検証と販売と利用の段階別に見る指標をまとめました。

案件ごとに認証や決済を選び直すと、設計だけでなく障害対応・更新手順・監査ログまで案件の数だけ分岐します。小さな会社ほど「まず通る道」としての標準スタックを決める価値が上がる理由と、標準に含めるべき十の領域(フレームワーク、認証、決済、メール、ジョブ、ログ、監視、CI/CD、IaC、テスト)、製品名より先に決める選定基準、例外承認の運用、標準の陳腐化への備えを整理します。

開発生産性とは、開発組織が投入した人と時間に対して、どれだけ速く確実に価値のあるソフトウェアを届けられているかを表す概念です。行数計測が失敗する理由、Four Keys、SPACE、DevExの使い分け、測り始める5つの手順、指標を個人評価に使ってはいけない理由までを総論として整理します。

開発者体験(DevEx)とは、ツールやプロセスが開発者の仕事をどれだけ支えているかを表す概念です。フィードバックループ、認知負荷、フロー状態の3要素、経営の関心事になっている理由、サーベイでの測り方と改善の進め方までを整理します。

SPACEフレームワークとは、開発生産性を満足度、パフォーマンス、活動量、協働、フローの5次元で捉える枠組みです。5つの次元の中身、活動量だけを見てはいけない理由、複数次元と主観指標を組み合わせる使い方の3原則、Four KeysやDevExとの関係を整理します。

DORA(DevOps Research and Assessment)とは、Four Keysを生んだGoogle Cloudの研究プログラムです。成り立ちと調査ベースの研究方法、Four Keysとの関係、実務で価値の高い能力カタログ(capabilities)の使い方、AI調査など最近の動向までを整理します。

AIコーディング支援を入れたのに組織のリリース速度が変わらないとき、原因は実装ではなく、その下流のレビュー・仕様決定・承認・デプロイにあることが多くあります。DORAの現行5指標を結果指標、工程ごとの待ち時間を診断指標として切り分け、どの区間で何時間止まっているかを測る方法、症状から詰まりを特定する対応表、よくある五つの誤診断、そして打ち手を選ぶ順序をまとめました。

AIで実装が速くなるほど、何を作るのか、どこまでできたら完了なのかを言語化する工程がボトルネックになります。必要なのは分厚い仕様書を書ける人ではなく、曖昧な要求を実装と検証ができる判断単位へ変換できる人です。仕様を事業・振る舞い・品質と運用の三層に分けて決定者を対応づける方法、受け入れ条件を観察可能な形にする書き方、AIを決定者ではなく査読者として使う分担、そして組織へ型を入れるときの順序を整理します。

MTTRとは、障害発生から復旧までの平均時間を指す指標ですが、Rの解釈が複数あり、DORAは現在この名前を使っていません。定義の揺れ、失敗デプロイの復旧時間への置き換え、平均値が実態を表さない統計上の罠、復旧を速くする打ち手までを整理します。

変更障害率(変更失敗率)とは、本番デプロイのうち直後に障害や緊急対応を引き起こした割合を測るDORAのFour Keys指標です。定義と測り方、速さと品質がトレードオフにならない理由、デプロイ手戻り率との違い、ゼロを目指してはいけない理由までを整理します。

変更のリードタイムとは、コミットから本番デプロイまでの時間を測るDORAのFour Keys指標です。なぜ起点が企画ではなくコミットなのか、レビュー待ちとデプロイ待ちに分解する見方、中央値で測る理由、短縮に取り組む順序までを実務目線で整理します。

デプロイ頻度とは、開発チームが本番環境へどれくらいの頻度でリリースしているかを測るDORAのFour Keys指標です。定義と測り方、頻度が高いほどデプロイが安全になる理由、ランク分け廃止後の正しい比較のしかた、目標化してはいけない理由までを整理します。

「AIが生成したコードの45%に脆弱性がある」というVeracodeの調査結果は、4種類のCWEを対象に設計された80件の関数補完課題に対する、100を超えるモデルの平均失敗率です。実務システムの欠陥率ではありませんが、セキュリティ固有の指示がない条件でLLMが安全な実装を安定して選べないことは示しています。この数字の測定条件と限界を原典で確認したうえで、フレームワークが守れる範囲、正常系テストでは検出できない認可の不備、そしてAI生成コードを本番へ出す前に組み合わせるべき8つの安全策を整理します。

TypeScript 7.0はGo製ネイティブコンパイラへの移行でビルドが約10倍高速化した一方、tsconfigデフォルト値の変更とtarget:es5などレガシーオプションの削除という破壊的変更を含みます。何が壊れるのか、いつアップグレードすべきかを整理します。