今後は気を付けたいって考えたから、メモとして記録。
開発者がどんなに仕様を考慮しても、実際に業務で利用している人しか思いつかないことがある。
そして、設計段階でどんなに打ち合わせをしても、絶対に後から
・思っていたフローと違っていた
・プロトタイプの画面見たら、やっぱり分かりにくかった（打ち合わせで画面イメージは見せてる）
といった仕様変更が出てくる。
設計段階の打ち合わせでプログラムを知らない人たちから、仕様を聞き出すってのがそもそもキツイのかもしれない。
プログラマは論理的に考えて、実装後の業務フローとかを意識した状態で仕様をイメージできるけど
普通の人は何となくでしか想像しないし、仕様変更の辛さを知らないから「やっぱよく考えたら使い難いから○○は直して」とかテスト段階に平気で言ってくる。
アジャイルとかプロトタイプとかが生まれたのはこういった開発側の不満からなのかもしれない。
厳密に言うとアジャイルじゃないんだけど、もう少し柔軟にするために
・設計は簡素に、プログラムが書ける最低限のレベルで要件をヒアリングする
・とりあえず設計通りに実装して全機能作る
・テストケースを作る前に利用者に使ってもらう
→これが一番重要で、テストフェーズの前で実装を９割終わらせることを目指すべき
（どう頑張っても１割くらいの仕様変更は出る、諦める）
→ここで要件定義、設計時に生まれるイメージのズレを修正する
・設計書を修正する（提出物ではないなら後でも良い）
・テストケースを実装、設計（修正したなら使う）から作る
・テスト、リリース
といった感じで進めると良いはず。次案件で試す。
まとめ
・要件定義時点の設計は絶対に利用者のイメージと異なる
・利用者にはモノを見せた方が早い
・テストフェーズ前の仕様変更なら辛くない（錯乱）
余談
利用者様の意見全部聞いてたらプログラマが死ぬ＾＾
でも全く聞かないと開発者の自己満足で終わるし。
IT業界の残業はこういう利用者・開発者間のイメージのズレの所為。
早い段階でズレを埋めることが出来れば、残業も減る・・・と思う。
んで、埋めることが出来るのはPL、PMだけ。プログラマに利用者視点を要求するのは間違い。
Android専用アプリ公開中！
→ NicoPod - にこぽっど ニコニコ動画音楽プレイヤー
挙動がおかしい点や、不明点などがあればレビューコメントやメールにてご連絡下さい。
アプリ内下部の広告クリックもヨロシク^o^ 開発費に直結してます（）
→ NicoPod - にこぽっど ニコニコ動画音楽プレイヤー
挙動がおかしい点や、不明点などがあればレビューコメントやメールにてご連絡下さい。
アプリ内下部の広告クリックもヨロシク^o^ 開発費に直結してます（）
