銀の弾丸はないって言ってるじゃないですか

先週会社でデブサミ関西のフィードバックをしようとしてて、その中で他のメンバーに「銀の弾丸はない」って言葉を教えようとしていたところ、休憩スペースに置いてあった「WEB+DB PRESS Vol.107」の表紙が目に入りました。

WEB+DB PRESS Vol.107

銀の弾丸! オブジェクトベース設計

えええ！いまから銀の弾丸ないって言おうとしてるのに！なんて説明しよう・・・ということで読んだところ、いろいろ考えさせられる良い内容でした。内容を要約するとこんなかんじ（手元にはないのでうろ覚えですみません）。

業務システムとかのアプリケーションメニューは、オブジェクトではなく、タスク・プロセスを中心に導線が組まれていることが多い

オブジェクトは、イメージ的には顧客、伝票とか。モデル、とも表現されていたように覚えてます。

タスク・プロセスは、たとえば「客先周りから帰ってきたからそれを報告するぞ」とか「顧客から受注をしたので受注処理をするぞ」とかそういう感じです。

タスク・プロセスベースで組むと、画面数も多くなるし、別の作業を行おうとするとトップページまで行かないといけなくなるので面倒だから、オブジェクトベースで設計しよう

タスク・プロセスベースで組むと、複数の導線の中に「伝票一覧」みたいなものが出てくる。しかもそこで用途や役職などが違うと「ほげほげ用伝票一覧」「ふがふが用伝票一覧」みたいに、全く同一の伝票を表示するのに複数の別の画面を作ることになる。

同じ伝票で違う処理をしようとすると、トップページにもどって「客先周り報告」ではなく「受注処理」のメニューを選択し直さないといけない。

そこでオブジェクトをベースに画面を設計すると、画面量も画面遷移もシンプルになるよ、と。

気づいたメリット

まず作る画面が減りますね。でも、それだけではなくて、APIの設計に影響するかなーと思っています。

RESTful Web APIを業務システムで取り入れようとした時、リソースとしては、先ほど名前の出てきた「顧客」「伝票」とかそういうものになってくると思います。そして、それぞれに必要な操作の枝を洗い出そうとします。

このとき、タスク・プロセスベースだと、先ほど出てきた「ほげほげ用伝票一覧」「ふがふが用伝票一覧」みたいなリクエストをしたくなります。そこで発生してくるのがAPIの種類やパラメータ、ペイロードの折衝ですね。で、そこに費やすエネルギーが不足しているとき、「もうAPIは用途ごと（つまり機能ごと画面ごと）に分けよう」ということで、機能IDや画面名のついたAPIが誕生してきます。

ここで、オブジェクトベースの画面設計になったとき、もちろんリソースの粒度は考えなくてはいけませんが、折衝の必要回数・必要なエネルギーが減ります。「伝票」を使う画面数がそもそも減ることになりますから。

これによって、API設計をもうちょっと少ないエネルギーできれいにできるんじゃないかな〜と思っています。

からのこのツイートでした。

そういえば今月のWEB+DB PRESSはよかった。UIデザインのやつ。
業務システムでRESTが破綻する原因を見たようだった。

— Koji Saiki (@saikou9901) October 31, 2018

気づいたデメリット

アプリ自体の機能からワークフローが減ったということは、そのワークフローの手順を誰が把握するのかというと、それは利用者になります。

「さぁ受注をするためには、まずほげほげを登録して、次にふがふがを申請して・・・」とつぶやきながら、伝票画面を表示して選択してタスク実行、もう一度伝票画面から次の対象を選択してタスク実行、伝票を選択してスイッチ、伝票を選択してスイッチ・・・

これをやれる運用とリテラシーが必要になってきます。

開発を請け負った会社としては成果物がわかりやすく、かっこよさを考えられてよいかもですが、発注する側のコストは、結局運用・教育とかそっちに乗ってくるわけですね。

じゃあどっちがいいの

私個人としては、いろんなところで「システム、ITをユーザのものにしていきたい」という想いがあるので、オブジェクトベースの設計は歓迎されるべきものだと思います。

それに、オブジェクトベースのアプリケーションに対して、さらに外から順番付のアプローチをするという、疎結合的なことも選択肢として可能だと思いますので（手順書、自動化、とかとか）。

さらによくよく考えると「APIから先のアプリケーションがオブジェクトベース、クライアントがワークフロー（タスク・プロセスベース）であるとして、ちゃんと分けて考えて設計・実装すればよくね？」というのもあると思います。こっちの方がミニマルかもですね。

結局

銀の弾丸はない、ということですね。

記事の中にも「ATMとか、一概にオブジェクトベースのUIがいいというわけではないよね」という言葉がありました。ただATMだと「既に自分の口座というオブジェクトを選択した上でここに立っている」という考え方もできるかもですね。