設計について考える機会は必要
SEになって1年半が経とうとしているところで、初めて設計の業務に携わることになった。そこで得た経験を元に、設計とは何だろうか、ということを記事化しつつ振り返りたい。
ITを活用して何かを作るには設計は避けて通ることができないが、プログラミングスクールでも、2020年以降の義務教育でも、設計について学べる可能性は低い。一応自分もプログラミングスクールに行ってたが、設計の話はなかった。(私の余計な一言には取り消し線をする)
※とはいえ、記事化にできるのは自分が学んだ詳細設計の考え方のほんの一部分だろう…
誰が為の設計
お客様(ユーザ)から電卓を実装して欲しいと言われたとする。
電卓といえば0~9のボタン、+,-,×,÷,=のボタン、CとかACとか.とかのボタンが思い浮かぶ。
電卓で画像検索するとわかるが、メーカーや製品によってボタンの配置は異なる。
今回は数値のボタン配置を考えてみよう。
※markdownのテーブルで表現しているため、ヘッダー行が太字になるが意味はない。
電卓案
| 7 | 8 | 9 |
|---|---|---|
| 4 | 5 | 6 |
| 1 | 2 | 3 |
| 0 | 00 |
もしも、ユーザが普段から電卓を使用している人なら上記の配置は使いやすい可能性がある(例外アリ)
ガラパゴス案
もしもユーザが電卓を普段から使わない人だったらどうだろう。しかも計算するときはガラパゴス携帯(ガラケー)で入力して、算出してる人かもしれない。
| 1 | 2 | 3 |
|---|---|---|
| 4 | 5 | 6 |
| 7 | 8 | 9 |
| 00 | 0 |
そんなガラケーマスターなら上記の方が入力は簡単なはずだ。
ロック案
しかし、実際にはユーザはガラケーも電卓も見たことがない方で、下記のような電子ロックを日常的に解除しているという。なんてロックな人なんだ。
| 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|
| 6 | 7 | 8 | 9 | 0 | 00 |
……こんなバカげたことはないと思いたいが、電卓に数字のボタンを配置するだけでもいろんな考え方があって良いはずだ。「誰のために」設計をするのか意識することで、ユーザの使いやすさを考えることが重要である。
大人の都合(納期)
前の章では電卓を例にユーザのために設計した。株式会社電子ロック様は電子ロック案がイケてると返答したので、電子ロックの電卓を実装したら大変喜ばれたし、依頼してよかったと言ってもらえた。
※電子ロックで画像検索するとわかるが、実際には電子ロック解除用のボタン配置も様々である。
翌朝、株式会社電子ロック様が、「累乗」の計算も追加してくれ！と言い出す。
累乗とは下記のような計算のことである。
# 2の4乗(2^4)
2 × 2 × 2 × 2 = 16
例えばG○○gle先生は2の何乗まで計算してくれるかご存知だろうか。
2の1023乗である。多分Javascriptの累乗の仕様と同じだからである。単純な掛け算であっても、あまりにも計算回数が増加すれば、すぐに算出することができなくなってしまうからである。
既に作った電卓は8桁の入力が可能である。エンジニアが本気を出せば99999999の99999999乗まで一瞬で計算できる機能を実装してくれるかもしれない(遠い目)
しかし、1ヶ月以内に納品してくれという。全エンジニアを24時間31日稼働させても実装、テストまで終わらせるのは困難かもしれない。
そこで1ヶ月以内に納品までできるような方法を考えなければならない。
新しいボタン追加案
「^」(ハット)ボタンを追加する。ボタンを新しく追加するため、電卓のどこに追加するかを検討しなければならない。もしも電卓にボタンを追加できる余地(スペース)がないと苦労する可能性がある。今はスペースがあっても追加することで、今後ボタンを追加できなくなるかもしれない。
例えばこのように右端に追加するのは既存のボタン配置に影響はないが、
| × | + | - | ÷ | = | ^ |
|---|
このような配置だと=ボタンの位置をずらすので、ユーザの使用感(既に使い慣れた人がいたらボタンの配置の変更はストレスになる)に影響が出る。
| × | + | - | ÷ | ^ | = |
|---|
×ボタン２度押し案
数値を入力後に「×」を2度押しすると、累乗の計算をしてくれる機能を追加する。電卓のボタン配置は検討しなくて済むが、累乗の計算時にボタンを押す回数が新しいボタンを追加するよりも増加する。
| × | + | - | ÷ | = |
|---|
制限を追加する
この累乗を計算する機能では1桁×2桁、又は2桁×1桁までしか計算できないようにする。つまり9の99乗 or 99の9乗までとする。それ以上の桁数が入力されている場合には全てE(エラー)を表示させる。あんまりイケてない仕様だが、計算処理で電卓が固まったと苦情が来るよりはマシなはずだ。3桁以上の計算は将来実装することになるかもしれないが。
結果
今回はボタン二度押し案が採用された。「×ボタンの二度押し」は既存の機能と競合を起こさない。操作回数は新しいボタンを追加するよりも増えるが、ユーザの使用頻度が高いわけではなかった。
ハットボタンの追加ができるスペースはあったが、今後も機能の追加はあるだろうから、スペースはなるべく残しておきたい。また3桁以上の計算もやるつもりはなかったらしく、制限はあっても問題はなかった。
いかがでしたでしょうか。
今回は「電卓」を使って、誰のために、どんなことを考えて設計するのか、簡単に記事化した。もちろん、この記事に書いてあること全てが正しいわけではない。むしろ現実世界では「ケースバイケース」であることが多いだろう。
ユーザの使い勝手も重要であるが、「実装とテストにかかる期間」や「将来を見据えた機能の拡張」も重要である。そのための適切な機能を考える必要がある(制限をつけることで納期に間に合わせる。新しくボタンを追加すれば将来的にボタンが追加できなくなる等)
ユーザの要望をどのような方法で反映させるか、しっかり検討するすることで、結果的に自分たちとユーザの為になる。
今回は仕様を検討する判断基準として下記を挙げた。
- ユーザが使いやすいか
- 実装、テストを含めて納期に間に合うか
- 既存の機能やデザインにどれほど影響があるか
追記
コメント欄で素晴らしい意見がありました。
二度押し案を採用するかどうかのタイミングで、「三度（以上）押した場合はどう振舞うか」を一緒に設計してしまいたい
考慮漏れでした。ありがとうございます、非常に嬉しい指摘です。
記事を読まれた皆様も、三度目以降の押下時の振る舞いを検討してみてください。
(自分は２つの案しか思いつきませんでした。ユーザに便利そうな方の案が良いと思いますが、納期が迫っていたら、実装が比較的楽そうな方を取りたくなると思います)
大抵の場合、世の中に似たようなものはあるので、UIでも機能でも、そういったものと比較したり、参考にしたりするのは非常に重要であり、基本だったりします。
こちらも非常に嬉しい指摘でした。ありがとうございます。
設計する前に参考になるものを探すのは非常に重要だと思います。
現場では既存の仕様が参考になることが多いですが、他のサービスやソフトウェアから探す場面も多々あると思います。
「これのほうがいいんじゃないか」等のコメント、お待ちしております。