読者です 読者をやめる 読者になる 読者になる

考える場所

ココロとカラダ、思考する全部

設計しなかった分のツケが回る

Webアプリケーションの開発をお仕事にしてそこそこ経った。そろそろ所感を述べてもいいころだろう。いちど手を止めてみたい。

バックオフィス側はないがしろにされやすい

バックオフィス側はフロント側と違って、ユーザーの目につかないから雑に取り扱われることが多い。まあそれはそうだろう。社内の事務局担当者が使う画面なのだから、見栄えしなくても問題ない、というかお金を使ってまで気を使うところではない、と考えるのも無理はない。

それが見栄えだけの話ならまだよいのだが、実際にはそうではない。見栄えに気を使わないということから、いつの間にかバックオフィス側にはお金をかけない、という意識になっていく。バックオフィス側だから簡単に済ませよう、少ない画面で済ませよう。といった具合だ。

「これは、今現在の自分自身のためになるから僕はこれが好きだ」という考えで選んでないか気を付けるべきです。

シンプルさの必要性 | eed3si9n

実際のところ、バックオフィス側は簡単にはなっていない。複雑になっているのだ。システム開発でお金を使わないとは人を動かさないということであって、つまり楽に作ってしまいたいということになる。しかし「簡単にする」ことは「楽にする」こととはまったく別のことである。これについては先の参考記事を読んでみてほしい。かなりの人に大きな気づきがあることだろうと思う。

バックオフィス側こそきちんと設計するべき

バックオフィス側でやることと言えば、ユーザーを登録したり、属性を変更したり、何かのデータと関連づけたりするといったことだろう。これをフロント側でなんらかのルールでどのようにかユーザーに見せるということになる。フロント側の設計、いや仕様かな、は慎重になりやすい。見せるべきでないものを見せないというルールはきっちり考える。なにせお客さん側だからと。一方でバックオフィス側は、そのルールに必要なフラグなんかをポチポチできるだけだったりする。

何ヶ月も経てばそんなフラグの意味なんて忘れてしまっている。覚えていない。分からないけど、このフラグはこっちのフラグに依存していて選択を抑止されているようだ。どうしてだっただろう。ああ違うな、DBの値がこのときは無視できるんだった。そんなことをコードを読みながらまた考えなきゃいけないのは、複雑なWebアプリケーションを楽に作ってしまったからなんでしょ。

項目が多いってことは複数の関心事が含まれている可能性が高い

少ない画面数vs少ない項目数 | pilgrim-lifestyle

更新側こそ業務の知識をシステムのかたちとして表現する、ということを考えるようにしたい。運用がどのようになっても対応することができるからと言って、とにかく何でもひとつの画面で済ませようとするのは、短略的過ぎるというものだろう。画面を少なく済ませようとすれば画面あたりの項目数は増える。関心事や意図は複雑に絡まり合って、知っている人だけが知っている状態になる。設計しなかった分の知識は、ユーザーや運用SE預かりになってしまうわけだ。

システムの焼き増しはエンジニアを機械にする

CRUDだけをするようなアプリケーション開発に慣れ過ぎるとエンジニアは設計を忘れてしまう。項目数の多い画面を描いて、画面項目一覧をエクセルで作成することが設計であると勘違いしてしまう。目の前の進捗に囚われると、システムを焼き増しせずにはいられなくなって、エンジニアを機械にしてしまう。まあ、実際のところエンジニアを機械か何かだと思っている人はかなり多いので、この流れを止めるのはなかなか難しい。どこかで変化を強制しなければならないだろう。