仕様策定時に意識している「判断軸」

この記事は BABY JOB Advent Calendar 2025 の 5 日目の記事です。

✨✨✨✨✨✨✨✨✨✨✨✨✨✨
🌲 みなさん、メリークリスマス！🌲
　　🦌🦌🦌🦌🦌🦌🦌🦌🦌🛷
✨✨✨✨✨✨✨✨✨✨✨✨✨✨

BABY JOB のY-Kanohです。

〜エンジニアリングの本質は「問題解決」である〜

ということで、今回は問題を解決するための "仕様" を考えるときに、私がいつも考えていることを言語化して、アドベントカレンダーの記事とします。

仕様を決めるときには判断軸が必要

ひとつの課題を解決するためにソフトウェアが取れる仕様の選択肢は、無限にあります。
無数にあるアイディアの中からより使いやすい仕様を採用する仕様を選択し続ける必要があり、そこには "ブレない判断軸" が不可欠です。

私の場合、今までの経験則からいくつかの軸を持っており、普段の仕事でもこれに基づいて仕様を決定しています。なかなか言語化するタイミングがなかったので、今回はその判断軸についていくつか紹介してみます。

• その挙動に"一貫性"はあるか？
• 不要な情報を表示していないか？
• 作り手の"都合"を押し付けていないか？
• 必要以上に複雑化していないか？
• 誰かの"損"になっていないか？
• 表示した情報は消しづらい

その挙動に"一貫性"はあるか？

明確な理由がない限り、仕様には一貫性が求められます。
例えば、「条件Aのときはデータを表示するが、条件Bのときは表示しない」という仕様があったとします。このとき、ユーザは「なぜ条件Bのときは表示されないのだろう？」と疑問を抱いてしまいます。 あるいは、条件と表示のパターンに気づかず、「思ったようにデータが表示されない（バグだ！）」とストレスを感じさせてしまう可能性の方が高いかもしれません。

ユーザには、本来必要なことのみに注目してもらうのが理想です。仕様の不整合に注意が向いてしまった時点で、そのソフトウェアを利用する際の認知負荷が増えてしまっていると考えて問題ないでしょう。

ただし、ユーザにとっても納得感のあるルールであれば話は別です。 冒頭の例で言えば、「条件Bの時はデータが表示できなくなる明確な理由」がユーザに伝わるのであれば、大きな問題にはなりません。

不要な情報を表示していないか？

画面に情報を詰め込みすぎるのは、親切ではありません。 私たちエンジニアはつい「念のため」と情報を出したくなりますが、情報過多はユーザを迷わせるだけです。"表示しない"という引き算の美学を持つことも、エンジニアの大切なスキルだと考えています。

我々はPCやスマホの画面を見慣れているため、情報量の多い画面から必要な情報を探し出す技術に長けてしまっています。しかし、一般のユーザ全員がそうとは限りません。

「まあなくてもいいけど、使える情報だし表示しておこう」と考えた時には特に注意が必要です。 情報が増えることは、画面の見づらさにつながります。不用意に情報を増やすことで、使いづらさを助長していないか考えるべきです。

必要以上に複雑化していないか？

前述の「不要な情報を表示していないか？」にも通じますが、仕様を必要以上に複雑化するのも良くありません。
ユーザは、作り手が思っている以上にシステムを細部まで見てくれないものです。
これは当たり前のことですが、普段同じシステムに向き合い続けているエンジニアほど見落としがちな事実です。

よくあるのが、最初の仕様はシンプルだったが、検討を進めるうちに様々なイレギュラーパターンが出てきて仕様がどんどん複雑になってしまうパターンです。
この場合、一度立ち止まり、ユーザがこの仕様をどのように感じるかを考え直した上で、必要に応じて考え直しを提案するべきでしょう。

実現したい仕組みのために仕様を複雑にしてしまうと、ユーザはエンジニアが期待するほどその仕様を理解してくれません。 仕様は可能な限りシンプルに保つ必要があります。

作り手の「都合」を押し付けていないか？

「技術的に難しいから、ここは妥協しよう」 そう思った瞬間、危険信号です。ミドルウェアの仕様も、実装工数の都合も、画面の向こうのユーザには一切関係のない話だからです。

たしかに、デザインの制約や使用している技術的制約によって、理想の仕様が実現しづらいことは多々あります。 しかし、これらの事情をユーザは理解してくれません。理解されない以上、「開発都合の不自然さ」はプロとして安易に許容すべきではありません。 そこはユーザ体験を優先したいところです。

誰かの「損」になっていないか？

稀に、機能追加によって既存ユーザに不利益を及ぼす場合があります。

とくに、サービスに"有料ユーザ"や"有料オプション"がある場合は注意が必要です。仕様を考えるうちに、意図せず有料ユーザのアドバンテージを損なってしまうケースがあるからです。 新しい情報を表示する場合、既存ユーザにとって不都合はないか？ 有料ユーザの特権を侵害していないか？ などを改めて確認する必要があります。

表示した情報は消しづらい

機能を追加するのは簡単ですが、削除するのはそう簡単ではありません。 なぜなら、一度公開してしまえば、少なからず「その情報を見ていたユーザ」が存在することになり、削除によって彼らの体験を損ねてしまうからです。

もちろん、余計な情報を表示し続けるくらいなら削除した方が良いでしょう。 しかし、「消す」という行為は「表示する」行為以上にユーザ感情へネガティブな影響を与えかねません。

だからこそ、新しい情報を表示するときには、「後から削除が発生しないか」「本当にその情報を表示するべきか」を一呼吸置いて考えてから決断しましょう。

最後に

私が仕様策定時に意識している "判断軸" をご紹介しました。

もちろん、これら全てを常に完璧に満たすことは困難です。ビジネス要件や納期との兼ね合いで、苦渋の決断を迫られることもあります。 しかし、迷ったときに立ち返れる"軸"を持っておくことで、チームでの議論がスムーズになったり、不要な手戻りを防いだりすることができます。

結局のところ、これらはすべて 「ユーザにとって使いやすいか？」「ユーザの利益になっているか？」 という問いに集約されます。「そんなことわかっているよ」と言われるかもしれませんが、意外とユーザの目線に立って考えることは難しいことだったりします。
そのため、上記のようにいくつかの判断軸を持っておくと役に立つでしょう。