使われていない、を知る

この記事について

既存の仕組みを「捨てる」というのは得てして影響が大きく、それを実行するには準備と勇気がいる。

builderscon 2019 で聴講した fujiwara さんの「レガシーサーバーを現代の技術で再構築する」の質疑応答で「再構築にあたり、使われていないものを捨てるときにどのように"使われていない"ことを確認するのか」質問させていただいたことを期に、日頃考えていたり、過去に経験したりといったことを書き出してみたくなった。

builderscon.io

セッションの内容は大変すばらしいものだったので、ぜひスライドや動画を見ていただきたい。スライドのリンクを見つけられなかったので、セッション詳細のページを紹介しておく。

builderscon.io

あまりまとまりがないものになるが、個人のメモだと思ってご容赦いただきたい。

前提

この記事では、主に会社や部署など特定の組織内で利用されているもの。特に Web アプリケーションを対象に扱い、BtoC など組織外の利用者がいるケースは想定していない。

また、以降は対象のアプリケーションや仕組みのことを簡便のために「システム」と呼ぶことにする。

「使われていない」ことを知るために

使われていないという状態は、どのように知ることができるだろう。

現時点で思いつく限りを列挙してみる。

  • アクセスログやデータの作成・更新日時から知る
  • 運用マニュアルなどが存在する場合は、そのドキュメントを参照する
  • 利用者が特定できる場合は、ヒアリングをする
  • 利用者にアンケートを取る
  • 計画的に対象を停止し、利用者からの反応を見る

アクセスログやデータの作成・更新日時から知る

アクセスログやデータから利用情報を知るというのは、ごく一般的かつ、信頼性の高い方法だと思う。

Web アプリケーションという前提においては、期間はさておき何らかの形でアクセスログは残る。

また、データベースやファイルシステムに保存されたデータの量や更新日時などから、どれぐらい回数や量、どの程度の頻度で利用されているかを掴むことができると。

運用マニュアルなどが存在する場合は、そのドキュメントを参照する

特定の組織内で利用するシステムには、マニュアルや業務フローなどのドキュメント類が整備・定義されていることも多い。

それらの情報に触れることができる場合は、ドキュメントから利用シーン、利用頻度などを読み解くこともできる。

ただし、こういったドキュメント類は「使われていない=メンテナンスされない」となるケースも多く、現在そのドキュメントが取り扱うシステムが使われているかどうかの判断材料にはならないことが多いように思う。

利用者が特定できる場合は、ヒアリングをする

組織内でも特定の部署や担当者が利用するシステムで、それが明らかな場合は、ヒアリングを行うことも有用だ。

対象のシステムが扱う業務ドメインについても豊富な知識を持つ担当者にヒアリングができれば、システムがどのように使われているか、またはいつから使われなくなったか、なぜ使われなくなったかなど、前述のふたつの方法では知ることのできない情報を得ることができることが多い。

しかし、相手は人間になるので、ヒアリングをしてもその場で思い出せなかった、言いそびれてしまった、忘れてしまったということは簡単に起こりうるので、前述の方法で得た情報とあわせてヒアリング内容を精査したほうがよい。

利用者にアンケートを取る

組織内でも不特定。というには大げさだが、組織横断的に利用されているシステムでは、利用者が定まらないようなケースもある。

その場合、何らかの方法でアンケートを取ったり、意見を求めたりすることも利用状況を知る方法となる。

これによって、今まで知りえなかったような情報を想定外の利用者から提供してもらえることなどが期待できるが、アンケートのような手法を取ると、アンケートの設問の設計、回収率などの頭を抱えることになるかもしれない。

計画的に対象を停止し、利用者からの反応を見る

これは当日の質問でも登壇者や参加者、質問者である私も思わず笑ってしまった方法ではあるが、現実においてはあながちトンデモな方法と言えなくもないし、むしろ実践的とも言える側面もあると思う。

前述のどのような方法をとっても、実際にシステムを止めてみないとそれが使われているかどうかを真に知ることは難しい。

ただし、この方法は業務フローに大きな影響を与えてしまう可能性を含んでいるため、計画や実施を慎重におこの合う必要がある。

たとえば、以下のような段階を考えることができる。

  • システムの一時停止を告知し、そのスケジュールにあわせてシステムを停止する
  • システムの一時停止を告知せず、システムを短期間停止する

各段階のいずれにおいても、ロールバック(再開)の手順は必ず用意しておく。

また、実施する時間帯は業務にあわせて計画する。

早朝や休日など明らかに利用者が居ない時間帯や日程で実行しても得られる情報は少なくなるし、かといって月末、月初、期末の多忙な時期にシステムの停止をすると、リカバリーが難しい規模の業務停止を引き起こしてしまう可能性もある。

まとめ

個人の経験からいくつかの例を挙げつつ、それぞれの方法について意見を書いてみた。

ここで挙げられなかった方法や、こんな方法を取ったことがある。などがあれば、どんな形でもいいので教えてほしい。

この記事が、誰かにとっての Discover Something New になっていたら嬉しい。

f:id:ariarijp:20190831145157j:plain

あとがき

この記事は builderscon 2019 会場近くのイタリアントマトで書きました。

参加者にランチを提供していただいた、さくらインターネットさん、ごちそうさまでした。