受託・自社サービス問わず、Webアプリケーションの画面開発をする際、設計書（仕様書）を書かないチームはボチボチある気がしている。issueに実装内容が少し書いてある（XX部分を作る〜みたいな感じ）ことはあるが、設計書はない。ワイヤーフレームを参照しながら画面を起こしていく、みたいなイメージ。1
新規開発時はまだ良い。仕様はその場で確認できる。問題はすでにアプリケーションの運用が始まった後。このような場合「開発メンバーは既に抜けてしまったので開発時の仕様や設計思想がない」状態になりがち。2 この状態で機能改修や追加・不具合対応をするのがめちゃくちゃつらい。
なぜつらいのか？
1. 正しい状態（＝画面仕様）を調べるコストが高い
「このパラメータはここに表示される」という画面の正しい状態がわからないと、機能追加・修正後にデグレードしていないかを確認できない。そのため作業前に「正しい状態」を調べてからタスクに取り掛かる、という手間が発生する。下手すると半日潰れたりする。「正しい状態」が残っていないのはコストがかかる。
単体テストはないの？と思うかもしれない。大体こういうプロジェクト、かつフロントエンド領域だとテストコードがないことの方が多い。また、何やかんやでリリース前に画面を操作してテストしがち。結局「正しい状態」は把握する必要がある。3
2. 不要な実装が放置されがち
仕様変更で不要になったコード「っぽい」ものを見つけたとき、本当に不要なのか判断できない。1の「正しい状態を調べる」余裕があれば良いが、余裕はないので後回しにされがち。フロントエンドだとコード量が増えるとコンテンツ配信コストが上がり、パフォーマンスにも影響が出てくる。不要コードはなるべく削りたい。でも不要か判断できない…。という悪循環になる。4
3. 仕様がわからないのでリファクタリングできない
コンポーネントの作りやfunctionsの処理、もっと改善できないだろうか？と考えるのは運用中のプロダクトに関わる面白さの1つだと思う。ただし、これは仕様がわかっているときに限られる。設計書がないので仕様がわからない。わからないので「デグレードが怖いから触らないでおこう」という気持ちが勝り、他のタスクをこなすようになりがち。コードはどんどん腐っていくので気づいたときには「手が出ない」となる。
画面設計書 / 仕様書がないととにかく運用負荷が高くてつらい。画面（フロントエンド）開発する人も設計書を書いて欲しいなあと思う今日このごろであった。5
