©KAKEHASHI inc. 生成AIと余白 〜開発スピードが向上した今、何に向き合う？〜 2026年02月12日 もっち(松本 明紘) 2026年の抱負を語ろう！今年コミットしたい生産性向上施策！【D-Plus Tokyo #21】 

株式会社 カケハシ(2023年2月〜現在) ● 新規プロダクト、AI在庫管理 ● バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 自己紹介 

いまのチームのメンバーのPR作成数の変化 SRE活動中心 設計中心 

生成AIにより開発スピードは劇的に変化した ● 生成AIによるコード生成が日常になった ● 以前なら数日かかっていたことが、数時間で形になる 

生成AIがもたらした「余白」を なんとなく機能開発に使っていないか？ 

新規プロダクト開発 ● 生成AIを積極的に活用 ● 最初のプロトタイピングは数時間でできた ○ これまでだと2週間〜3週間程度かかることを想定していたような内容 ● システムアーキテクチャ決定のための技術検証 ○ 実現性の確認をAWSにデプロイするところまで短期間で実施できた ○ 技術的な不確実性を減らすことを早期にできた 

生成AIを使った技術検証を進める中で感じたこと ● 気を抜くと技術的負債がすぐに積み上がってしまう ○ 技術検証なので捨てる前提で進めたのでまだ良かった ○ 生成AIは技術的負債も真似するため、指数関数的に増えていく ● レビュー負担の増加 ○ 少人数の開発チームだとしても無視できない負担 

本当に起きている AI時代のソフトウェア開発を考える（2025/07版） https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition?slide=6 

それを無理やり超えた先にあるもの ユーザーへの 負担の押し付け 

生成AIがもたらした「余白」を 私たちはどう使うべきなのか 

「量」ではなく 「質」を向上させたい 

ラムズフェルドの4象限 既知の既知 理解しているし、自覚もしていること 未知の既知 理解はしているが、自覚できてないこと 既知の未知 存在を認識しているが詳細は不明 未知の未知 自覚も理解もしてないこと 認識している 認識していない 知識 あり 知識 なし 

ラムズフェルドの4象限 既知の既知 理解しているし、自覚もしていること 例： 問題の早期発見のためのテストを正 しく追加できる 未知の既知 理解はしているが、自覚できてないこと 例： テストカバレッジ80％が目標。達成も できる。何のためにやっているか分かっ ていない 既知の未知 存在を認識しているが詳細は不明 例： ユーザー数増加に従ってパフォーマン ステストの必要性が痛感しているけど、ど うやってやれば良いか分からない 未知の未知 自覚も理解もしてないこと 例： そもそもテストが必要だという発想が なく、やり方も知らない 認識している 認識していない 知識 あり 知識 なし 

質を上げる ＝ 未知を減らし既知を増やす 

質を上げる=未知を減らし既知を増やす 既知の既知 理解しているし、自覚もしていること 例： 問題の早期発見のためのテストを正 しく追加できる 未知の既知 理解はしているが、自覚できてないこと 例： テストカバレッジ80％が目標。達成も できる。何のためにやっているか分かっ ていない 既知の未知 存在を認識しているが詳細は不明 例： ユーザー数増加に従ってパフォーマン ステストの必要性が痛感しているけど、ど うやってやれば良いか分からない 未知の未知 自覚も理解もしてないこと 例： そもそもテストが必要だという発想が なく、やり方も知らない 認識している 認識していない 知識 あり 知識 なし ③形式知化 (構造化と仕組 み化) ②実験 ①小さく速く たくさん完了 させる 

そしてそれを 実践し、やり続けること 

①小さく速くたくさん完了させる(1/2) ● プロダクトロードマップ、スプリント単位、 ユーザーストーリー(or タスク)、PRを小さくする ● その時点で分かりたいこと、後回しにしていいことを決めて、 動くソフトウェアで試す ● ふりかえる 動くもの、できたことを確認しながら 小さな完了を繰り返すことで既知が増えていく 

①小さく速くたくさん完了させる(2/2) ● 状況に合わせて実行しやすさと気づきの量が最適にな るように実施 ○ 2週間スプリント ○ スプリントレビュー ○ ふりかえり ○ ときには大胆な方向修正も実施 ● デイリーリファインメント ● ユビキタス言語ふりかえり会 

②実験(1/2) ● 技術検証 ○ 複数の技術選択肢を全部試す ○ 試しておくことで後の選択肢が増える ● A案B案、両方作って試す ● やったことないことを生成AIに雑にでも良いからやってもらう 調査だけじゃなく、実際に自分たちの環境で動かす・見る・確かめる ”やったことある”、”理解した”を増やす 

②実験(2/2) ● 大きな方式の決定 ○ SES vs WebSocket ○ メッセージブローカー(NATS、Redis) ○ TypeScript、Go ○ OpenTelemetry、Datadogライブラリ ● Phase0での負荷テスト(スケール性の確認) ● 良さそうな開発ツールはとりあえず導入してみる ○ runn, tbls, cspell, pgtap, lefthook 

③形式知化(構造化と仕組み化)(1/2) ● 構造化 ○ モジュール分割、レイヤー分けの考え方のガイドライン ○ テスト方針、ルール ○ 仕様の理解容易性の高いテスト(BDD、Gharkin、AAA) ● 仕組み化 ○ Lint、自動テスト、CI/CD、IaC ○ ログ、メトリクス、オブザーバビリティ、モニタリングの強化 ○ チェック用のツールの作成 ○ ソースコードとの近接性を高めることで形骸化しにくくする ソースコード以外も構造化しメンタルモデルを形成、仕組み化し構造を崩しに くくすることで、既知を増やしていく 

③形式知化(構造化と仕組み化)(2/2) ● ガイドライン ○ DBの設計方針 ○ APIの設計方針 ○ 共通ライブラリ化の方針 ○ エラーハンドリング ○ ログ出力 ○ レイヤー設計、モジュラーモノリスの分割基準 ○ リクエストコンテキスト設計 ○ コーディング規則 ○ テスト方針 ○ GitHub Actionsの構造化設計 ○ ユビキタス言語 ● Lint ○ これまでよりも厳し目のルール設定 ○ 参照関係のチェック ○ ユビキタス言語チェック(チャレンジ中) ● 単体テスト ○ レイヤーごとにテストカバレッジ(C1)の指標化 ● APIテスト ○ Gharkin記法で仕様の理解容易性向上 ● レビューガイドラインの観点 ○ 変更点の優先順位付け ○ 日付の使い方の観点 ○ 依存関係の観点 ○ エラーハンドリング、ロギングの観点 ○ OpenAPI仕様と実装の一致 ○ パフォーマンスチェック ○ コードのわかりやすさチェック ○ SQL最適化チェック ○ TypeScript品質チェック ○ セキュリティチェック 

これまでもやった方が 良いとされていたことを 当たり前にやる 

もう犠牲にしたくない スクラムとデッドライン壊れゆくチームをつなぎとめるもの https://speakerdeck.com/kakehashi/kakehashi-scrum-and-deadlines?slide=25 

これまでよりも小さなフィードバックサイクルをたくさん回す 生成AI (プラン) 生成AI (実行) 小さな ユーザース トーリー (タスク) プラン結果 結果 生成AI (レビュー) ガイドライン 過去のプラ ン結果 ガイドライン レビュー ガイドライン 保存した プラン結果 Lint、単体テ スト、結合テ スト レビュー指摘 とその対応 方法 チームレビュー マージ (デプロイ) Pull Request レビュー指摘 とその対応 方法 完成 レビュー ガイドライン 

あんまりやりたくないなあと思っていること ● 大きな粒度のタスクをまるっと生成AIに任せること ● 大きなプロジェクト計画への回帰 未知の未知を増やすことに 繋がってしまう 

2026年 ソフトウェア開発の 「質」を上げることに使いたい 

大事だとされていることを、「当たり前」にやる年にする ● 生成AIが余白をもたらした今、やらない理由がなく なった ● 後回しにしない ● もっとマインドをアジャイルに 

©KAKEHASHI inc. 生成AIと余白 〜開発スピードが向上した今、何に向き合う？〜 2026年02月12日 もっち(松本 明紘) 2026年の抱負を語ろう！今年コミットしたい生産性向上施策！【D-Plus Tokyo #21】