たとえばどこかの自治体で、犬の散歩に関してひとつ条例が追加されました。
それは、散歩しているひとの手からリードでつながれた犬の首までの距離を2m以内とすること、といった内容です。
僕はペット用品の開発担当なので、その地域専用に、その条例が許容する最も長い2mのリードを設計しました。
しかし、実際にいろいろな犬につないで、手から犬の首までの距離を測ってみると、ときどき2mにおさまらない犬が出てきてしまいます。
いろいろ調べた結果、犬の首輪のたゆみがリードの長さと犬の首までの長さのあいだに少し隙間をつくってしまっていることが原因だと分かりました。
それで僕は日本で市販されている犬の首輪の規格を調べて、もっとも大きな首輪の半径から、動物学会で報告されている犬種の中でもっとも小さな犬の、成犬の首まわりの半径をひいた長さを、現実的なたゆみの最大長としてリードからひいて再設計することにしました。
そこで、ひとりの開発チームのメンバーがこんなことを言いました。
「自治体に、首までじゃなくて首輪までの距離に変更してもらえばいいじゃないですか」
「それが無理なら取扱説明書の免責事項に首輪までの距離ですと明記すればいいじゃないですか」
今回与えられている開発期間からみれば、間違った意見ではない気もします。
なるほど、そうすれば今回設計した首輪のまま納品までいけそうです。
しかしそれだと、いずれにしても首までの長さが2mにおさまらない犬が出てくることに変わりありません。
技術者は、与えられた課題をいかに技術力で克服するかが命題です。
現在目の前に横たわっている障壁は、まずは回避するよりも技術的に乗り越えられるものかどうかが検討されるべきです。
その課題自体が持つそもそもの現実的妥当性や、乗り越えることによって発生する費用対効果は、より上位の然るべき人間が考えるべきことです。
2mという距離に意味や効果があるのか、またはそこにどのくらいの誤差が許されるのか、といった点は僕たちの扱う仕事ではありません。
しかし、もしチームのメンバーがたゆみのぶんの長さだけでなく、首から口までの長さも引くべきだとか、リードの伸縮率も考慮すべきだと提案をしてきたのなら、僕は高く評価したでしょう。
それは技術によって還元される恩恵の話である可能性があるからです。
いったんペット用品開発の話を終わります。
そのメンバーの発言は僕にこんなことを連想させました。
DB設計で、PKこそひいてあるもののユニークキーや外部キー制約が皆無といったシステムをときどき目にします(実際にこの現場もそうでした)。
制約が多く動かしづらいシステムは、制約をなくしてしまえばいいとか、動きやすいようにまわりの環境や条件を変えればいい、といったものではないはずです。
制約が多いというのは、逆に言えばその制約にひっかかるような不正なデータを検知できるということです。
それはつまり、将来的な運用やメンテナンスを楽にします。
リリース後しばらくして、サービス上ありえないデータがはいってきてしまっていたら、それを顧客にどう提供するのでしょう。そのときにシステムはちゃんと動いてくれるのでしょうか。顧客のクレームの元にならないでしょうか。
なにより、そのあり得ないデータを「なにを正として」修正すればよいのでしょうか。
10件くらいならなんとかなるでしょう。しかし数千数万件となった場合、誰が面倒を見るのでしょう。
メンバーの反応は、納得したもののプライドを傷つけてしまったようで、少し後味の悪い会話となりました。
実現が困難だから自分ではなく外側を変えようというのは、最後の最後まで避けるべき考え方に思えます。
それで仕事をしているのならなおのことです。
プロ意識をもって臨むことの難しさ、もっといえば、それをチーム内で共有することの難しさを感じる出来事でした。
ペット用品の開発の話に戻ります。
僕たちは今、結局リードの伸縮性や犬の口までの距離も計算にいれて再設計に取り組んでいます。
その地域で散歩されている犬が決して2m以上飛び出さない、平和な世界を願って。
p.s. オブジォクト嗜好のカプセル化に関してもそうですね。なんでもパブリックでアクセス権を持たせようとするひとは、ぜひ一度システムの持つべき堅牢性の意味について思いを巡らせて欲しいです。制約を無視したところに自由はないと思うのですが、みなさんいかがでしょうか。