制約の設計力

ソフトウェア/システム/サービスを何らかの形で提供する場合、他のソフトウェア/システム/サービスとの境界を設ける必要がある。人とシステムの境界であったり、システムと他のシステムとの境界であったりする。境界は様々で、ユーザインタフェースであったり、通信プロトコルで定義されていたり、（人間系）手作業と自動化の切り分けであったり、契約文面や約款だったりする。

抽象度や方法もバラバラだが、境界には何らかの制約が含まれる。一般には制約を減らしたり、自動化部分を増やすと、ソフトウェア/システム/サービスが複雑になる。自動化のコストが高いため一部を人間系にしている、とか、本来であればより親切で直感的なユーザインタフェースにしたいが、開発コストが足りないので、人間がIDを覚えて、テンキーから入力する等だ。

「おぉ」っと唸らされるソフトウェア/システム/サービスには、境界の線引きが絶妙というものがあるように思う。全ての「おぉ」は線引きの絶妙さから来るのではなく、線引きが絶妙で「おぉ」という意図だ。直感的には「いい落としどころを選んでいる」という感じだと思う。その線引きの絶妙さを本エントリでは「制約の設計力」としている。

ソフトウェア/システム/サービスの実現がラクになりながらも、利用者からは大きな制約にならないというのを考えるのは、よい制約の設計といえる。とてもシンプルな例を挙げると、週1回2時間、システム/サービスを停止してメンテナンスすることにより、ソフトウェア/システム/サービスの実現がラクになる場合に、そのソフトウェア/システム/サービスが使われない時間帯（日曜日のam2:00～4:00）を選ぶことだ。ここでの実現には実装コストだけでなく、継続して運用するコストや検証、テストのコストも含まれる。

本エントリを読まれている方は、これまでにどのような制約を設計されただろうか？「我ながらこの制約はよかった」「この制約はいろんな人に迷惑をかけるだけだった」等、あるのではないだろうか。その制約はどのタイミングで思いついたものだろうか？