こう
- 「非機能要件として、
何を 決めて おきますか」 - 「機能は
できているのに、 お客さんから 『遅い』と 言われました。 どこで 防げましたか」 - 「どの
くらい 止まらずに 動けば よいかは、 どう 決めますか」
面接官が
- 言われた
機能を 作るだけでなく、 ビジネスに 要る 品質まで 一緒に 決められるか - 性能、
可用性、 セキュリティ、 拡張性、 運用、 費用を 漏れなく 挙げられるか - 「速く」ではなく、
確かめられる 数字で 決めるべきだと 分かっているか - 高い
目標ほど 費用が かかる、という 引き換えを 相手に示せるか
短い答え
- 性能、
可用性、 セキュリティ、 拡張性、 運用と 保守、 費用の 6 つを、 作り 始める 前に 決めます。 - 機能と
違って 目に 見えに くいので、 決めて おかないと、 出した あとで 「遅い」 「落ちた」と 揉める 原因に なるからです。 - ただし目標を
高く する ほど 費用と 手間が 増えるので、 ビジネスに どこまで 要るかを 相手と 決めます。
少し
決めて
非機能要件は、
- 性能画面の
応答時間、 同時に 使う 人の 数、 ピーク時の量 - 可用性どれだけ止まらずに
動くか (稼働率)、 止まったら 何時間で 戻すか (復旧時間)、 データを どこまで 戻せればよいか - セキュリティ誰が
何を 見られるか、 個人情報の 扱い、 記録 (ログ) を どれだけ残すか - 拡張性利用者や
量が 増えた とき、 どこまで 今の 作りで耐えるか - 運用と保守 監視、
障害の 連絡の 流れ、 更新の 頻度、 誰が 面倒を見るか - 費用毎月の
サーバー代や 外部 サービスの 料金を、 どこまで払えるか
確かめられる形にする
「速くしてほしい」では、
YAML
performance:
list_page: "N 秒以内"
availability:
monthly_uptime: "要相談"
recovery_time: "N 時間以内"
cost:
monthly_budget: "上限を決める"数字は
トレードオフ
稼働率を
よく
- 機能だけ聞いて終わる
性能や 可用性を 決めないと、 作り直しや 揉め事のもとになります - 「なるべく速く」
「止まらないように」と書く 測れないので、 達成したかを 誰も 判断できません - 全部を
最高の 水準にする 費用と 手間が 跳ね 上がります。 画面や 機能ごとに 重さを変えます
深掘りの問い
- 「稼働率と
復旧時間は、 どう 決めますか」 止まった ときに ビジネスが どれだけ困るかを 相手に 聞き、 それに 見合う 費用と 並べて 決める、と答えます - 「決めた
目標を 守れているかは、 どう 確かめますか」 応答時間や エラーの 割合を 計測し続け、 目標を 下回ったら 知らせが 届くように する、と答えます - 「お客さんが
費用を 出せないと 言ったら」 目標を 下げる 所と、 下げられない 所 (決済、 個人情報) を 分けて 提案する、と答えます