1. はじめに 実務では、画面設計書が Excel や PowerPoint、Word で管理されていることが多いです。 それ自体は珍しくありませんし、提出物としては都合が良い場面もあります。 ただ、開発の現場で実際に使う設計資料として見ると、つらいことが多いです。 どこが変わったのか差分が追いづらい レビューで変更点に集中しづらい 実装と設計書の同期が崩れやすい コピー運用で古い記述が残る 画面ごとに表現がばらつきやすい その結果、画面設計書が「あるけど信用されない文書」になってしまうことがあります。 自分は最近、画面設計書をもっとドキュメントベース、できれば Markdown ベースで書く文化を浸透させたいと考えています。 今回はその理由を整理してみます。 2. なぜ今の画面設計書運用がつらいのか 画面設計書は、多くの現場で Excel / Word / PowerPoint などの

対象読者 お気に入りのAIツールがある方 SNSなどのAIツール情報に振り回されがちな方 チームへのAIツール導入を推進する立場の方 はじめに GitHub Copilot、Cursor、Devin、Claude Code、Kiro、Jules、Codex CLI...次々と現れる魅力的なAIコーディングツールたち。SNSなどで「開発速度10倍！」「〇〇はゲームチェンジャー！」なんて甘い言葉が囁かれています。 そのツール選定、恋に落ちてるだけかも？ 本記事では、なぜ私たちはツール選定に盲目的になってしまうのか、そしてどうすれば冷静な視点を取り戻せるのか私なりの見解をまとめます。 なぜ盲目になるのか 「付き合いたて」の心理 新しいAIツールに出会い、試しに「Todoアプリを作って」と頼み、わずか数秒で完璧なコードが生成される。「これは開発が変わる！」と興奮して、いてもたってもいられなくなって