UI/UXの罠

お客様の案件に開発支援する際に設計工程から参画する事もあるのだがその際に必ず開発手法を伺いAgileであれば快く受けAgile以外であれば要件定義書の有無について伺う事にしている

「大丈夫です要件定義書はあります」という回答には必ず裏切られるので最近は一切信用していないので
「ASIS TOBE差分分析は出来てますか？」と聞くようにしている
その時点で？？？という案件は参画をお断りしするようにしている

過去の失敗例で「要件定義書はあります」で示す文書は画面遷移図だけだったりする
そもそも要件そのものを理解していないのだ・・・

世の中全てCodingがあれば要件は要らないと誤認している
流行りの初心者向けの技術指導学校はCodingしか教えない所が多い
世間全般に開発工程について理解していないのでこういった学校があるのも頷ける
まあ運のよい？開発者であれば現場で開発工程について教示いただく事もあるだろうが

画面遷移図には画面操作によって遷移する画面の画像DesignがToolを用いて記載されている
そしてこれがUI/UXを主体とした要件定義として世の中では受け入れられている
Agile開発ならばこれでも十分だ・・・然しながらAgile自体が誤認されている様子だ
Agileの話はまた別の機会に

機能要件の中に画面一覧や画面遷移図があるのは良しとしても画面自体に機能はないのだ
この認識がそもそも世間全般に開発工程と合っていない
開発Vendorですら画面遷移図だけで要件定義を終わらせてしまうのだからもう知らない方が圧倒的に多いんじゃないだろうか（笑）

話を画面には機能はないという話に戻してみる
例えば顧客登録画面があったりする顧客情報を登録する画面なのだからこれは当然画面機能だろう？と思うだろう
然しながら顧客情報登録をする機能は別に存在するのだ
画面は機能へ導く振る舞いをするのが役割であり機能そのものは提供していないのだ

Offlineの状態で顧客情報登録をする事はまずない
Onlineの状態で顧客情報登録はされるのが世の中一般的だろう
何故Offlineでは駄目なのだろうか？
顧客情報登録はOnlineを通して遠く離れたDatabase内にある顧客情報を取り扱うDatasource（もしくはTable）にDataを登録するのだ
ではそんな離れた先のDatabaseに誰が情報を登録するのだろうか？
それが顧客情報機能なのでありこれはServerと呼ばれるものが提供する
画面は振る舞いによって利用者が入力した情報をServerが介するI/Fを利用して顧客情報を手渡しているに過ぎない
つまり画面自体に登録機能はないというのはそういう事なのだ

UI/UXの画面遷移図の中に起動時に表示するSplash画面がある
これは起動に要した時間に対してAnimationで遅いと体感させないための手段である
ではSplash画面が表示されている間起動時に何が起きているのか？
UI/UXの殆どは画面遷移のみでその内容を明確には伝えていないしそれこそが要件定義に必要な現行機能要件の要素であるのだ

Native AppやWeb AppでSplash画面が表示される前にClientはServerに対して当該利用者の属性情報取得要求を行っている
Serverからの応答時間が長ければそれだけ待ち時間も長くなるのでSplash画面でこれを胡麻化しているのだ
画面遷移だけではこの利用者属性情報取得機能は分からないのだ

現存するUI/UX作業で不足しているのはこのServer側の考慮なのだ
だから画面遷移だけを要件定義として決着させ次工程の設計や実装作業でServerとの連携処理に気付き迷走してしまうのだ
UI/UXには内部処理が不可欠なのはそのためである

UI/UXを主体として進めている要件定義にはご用心である