へるもすにっき

某所でSEをしながら、個人でAndroidアプリを作ったりしてます。


テーマ:
今後は気を付けたいって考えたから、メモとして記録。


開発者がどんなに仕様を考慮しても、実際に業務で利用している人しか思いつかないことがある。
そして、設計段階でどんなに打ち合わせをしても、絶対に後から

・思っていたフローと違っていた
・プロトタイプの画面見たら、やっぱり分かりにくかった(打ち合わせで画面イメージは見せてる)

といった仕様変更が出てくる。

設計段階の打ち合わせでプログラムを知らない人たちから、仕様を聞き出すってのがそもそもキツイのかもしれない。
プログラマは論理的に考えて、実装後の業務フローとかを意識した状態で仕様をイメージできるけど
普通の人は何となくでしか想像しないし、仕様変更の辛さを知らないから「やっぱよく考えたら使い難いから○○は直して」とかテスト段階に平気で言ってくる。

アジャイルとかプロトタイプとかが生まれたのはこういった開発側の不満からなのかもしれない。


厳密に言うとアジャイルじゃないんだけど、もう少し柔軟にするために

・設計は簡素に、プログラムが書ける最低限のレベルで要件をヒアリングする
・とりあえず設計通りに実装して全機能作る
・テストケースを作る前に利用者に使ってもらう
→これが一番重要で、テストフェーズの前で実装を9割終わらせることを目指すべき
(どう頑張っても1割くらいの仕様変更は出る、諦める)
ここで要件定義、設計時に生まれるイメージのズレを修正する
・設計書を修正する(提出物ではないなら後でも良い)
・テストケースを実装、設計(修正したなら使う)から作る
・テスト、リリース

といった感じで進めると良いはず。次案件で試す。



まとめ

・要件定義時点の設計は絶対に利用者のイメージと異なる
・利用者にはモノを見せた方が早い
・テストフェーズ前の仕様変更なら辛くない(錯乱)



余談

利用者様の意見全部聞いてたらプログラマが死ぬ^^
でも全く聞かないと開発者の自己満足で終わるし。
IT業界の残業はこういう利用者・開発者間のイメージのズレの所為。
早い段階でズレを埋めることが出来れば、残業も減る・・・と思う。
んで、埋めることが出来るのはPL、PMだけ。プログラマに利用者視点を要求するのは間違い。
AD
コメント(0)  |  リブログ(0)
同じテーマ 「日常」 の記事

テーマ:
【内容】
・トップ画面にヘルプ追加
・ライブラリアップデート
・全曲リピート機能追加

【メモ】
サポートライブラリ更新したら、また文字の色が戻った(白目)


---
Googleも迷走してるのか?公式アナウンスが無い箇所が変わってたりしてて混乱するわ
AppCompatDelegateは新しいアプリの方で使おう。


使ってみてね!!

→NicoPod(ニコニコ動画プレイヤー)
AD
コメント(0)  |  リブログ(0)

テーマ:
【内容】
キャッシュ上限UP
画像表示処理見直し
サポートライブラリのアプデ

【メモ】
サポートライブラリ更新したら文字の色が黒に戻ってワロタ
あれだけ膨大だとGoogleも管理大変なんだろうなあ
俺もサポートライブラリのプロジェクト関わってみたいわー
---
シャッフル再生は最初は予定になかったから、ちょっと組み込むのに手間取りそう
全曲リピートは次で実装しちゃおうかねー

ダウンロードよろ!バグ報告もよろ!
広告クリックもよr(ry

→NicoPod(ニコニコ動画プレイヤー)
AD
コメント(0)  |  リブログ(0)

AD

Amebaおすすめキーワード

Ameba人気のブログ

Amebaトピックス

ランキング

  • 総合
  • 新登場
  • 急上昇
  • トレンド

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。