「KISS」が重要

"Keep It Simple, Stupid!"
いやはや、その通りです。今日はこの原則を実感したあるエピソードから得た教訓について書きます。

調べ物一つするにしても、Googleですぐにわかる情報に価値はありません。自分の頭と足で稼いだ情報をチームに提供し、それをさりげなくアピールします。
『受託開発の極意』P126

自分で書いておいて、自分でそれを守らなかったのは拙かったです。
Webシステムの運用方法の変更に伴い、セッション管理に関する仕様変更をしたことがあります。もともとの設計思想はものすごくシンプル。

  • どうせ×ボタンでウインドウを閉じる人は防げないので、凝った二重ログインチェック処理ではなく、「後からログインした人を優先する」方針とする。

というものでした。端末の数が限られており、複数人での利用を想定しないシステムですからこれは理にかなっています。これならセッションタイムアウトを長めにとっても大丈夫。
それをよくある、つまり、

  • 二重ログインチェックを行う。すでにログインしている場合は、後からログインしようとしたユーザーはログインできない。

という仕様に変更しました。さらに「×ボタンを押された場合でも、セッションのクリア処理を行う」という機能を盛り込んだのが複雑さの始まり。詳細は省きますがIE6のバージョンによってはどうもダメな場合があるらしい。*1

完璧を目指すものほど壊れやすい

普通に良い設計を目指したつもりが、結局はその完璧さを求めるがゆえに脆さを埋め込んでしまうことになります。もともと正しく動いていて、しかもシンプルな仕組みを再設計するには、それ相応のコストをかける必要があります。事前検証とテストに時間をかけないといけません。
もちろんonunload、つまり×ボタン周りの処理はGoogleで調べて「いける!」と確信を持って挑んだつもりです。しかし「頭と足で稼いで」なかった。システム要件定義書には「IE6での動作」とある以上、あらゆるIE6のバージョンで正しく動作することは要件です。しかしすべてのバージョンでの事前確認ができなかった時点で、脆さが残ってしまいました。この脆さをカバーするには、さらに複雑さを盛り込む必要がありました。

問題も解決方法もコンテキストに依存する

コンテキストを無視して他から解法を持ってきてもうまくいかない場合があります。コンテキストによくマッチしている解法だからシンプルなのです。誰がみても原則がわかりやすく、ぶれない。状態が少なく仕様を覚えやすい。それを理解せずGoogleから解決策をコピペしてはいけません。一旦自分の中に取り込んでコンテキストの中でベストかどうか検討する手間が必要です。

*1:追記:この後、真の原因はGoogleツールバーのポップアップブロッカーであることが判明しました。