対処より予防を

「対応より予防を」というのはプロジェクト管理のTipsである．なにか問題が発生してから対応するコストを考えると，その問題が発生しないように予防するコストのほうがはるかに小さいので、そうならないように予防策を予め考えておきなさい，という戒めだ．

昨日，まさにそれを実感する出来事があった．いま我々が運用しているDialogbookというシステムで，先生は学生・生徒のデータをダウンロードできるようになっている．投稿したメッセージ，ルーブリック（自己評価）のスコアなどである．昨晩，自分が担当しているクラスのデータをダウンロードしたら，なぜか身に覚えのないルーブリック項目（自己評価項目）がダウンロードされている．

もちろん，それらの項目には学生がアクセスできないので，項目があるだけで中身は空（nil）であり，無駄データが大量発生しているという以外はあまり害はないが，どうにも気持ちが悪い．コードを調べてみると，他のクラスが設定したルーブリック項目が作られてしまっていた．全体が1つのプロジェクトであるとはいえ，他の学校で他の先生が設定したルーブリック項目が，断りもなく他の先生向けのデータに紛れ込んでしまうのは，ちと，いや，かなりマズい．

おそらく，バグ発生の経緯はこうだ．

1. ルーブリック項目は先生によって適宜作られるので，学生が自らのマイページで一覧を表示するときに，新しく設定されたルーブリック項目に対応するスコア項目は，足りない項目として，都度，補うという処理が設定されていた．
2. 昨年度のシステムでは，1クラス1アプリということで，アプリケーション全体を1つのクラスが使っていたが，今年度はマルチテナント方式にして，1つのアプリに複数のプロジェクトやクラスを入れられるようにした．
3. そこまではよかったが，ルーブリック項目を補うコードの修正を忘れ，全てのルーブリック項目に対するスコア項目を追加してしまっていた．

最後の箇所を，所属するクラスの先生が設定したものに限る，と変更すればよいだけなので，プログラムの修正は簡単である．プログラムを修正し，問題がないことを動作確認したうえでコミット．ここまでは，さほどの手間ではない．

問題は既にたくさん作られてしまったスコアのデータである．既存のデータを，運用中の他のデータに悪影響が及ばないようにしながら，クリーニングするのは，やや手間がかかる．

そこで，昨晩は以下の手順でデータのメンテナンスを実施した．

1. 処理のアルゴリズム的に，これらの大量発生した無駄データに学生・生徒（はおろか，先生も！）アクセスする手立てがないので，全ての値は nil であることをまず確認した．
2. そのような無駄データを特定する条件を設定し，データベースから抽出したうえで，削除した．

この処理で誰も使わない無駄なデータが削除され，データの全体量を1/5に削減することができた．しかし，実運用中のシステムに対するデータの保守は気を遣うことを痛感した．「対処より予防を」（prevention is better than cure）という概念の大切さも実感した．

この作業を通じて，先生ユーザ向けのスコア項目は不要なのでそのような無駄データも作らない，という潜在的バグを潰せたのは不幸中の幸いといったところ．我々が扱っているような小規模なシステムでこれだもの，みずほ銀行がてんやわんやするのも，まあ，さもありなんという気もしないでもないなあ……