カスタマーサポート（以下、CS）の業務で利用する社内ツールの企画に関わってきた中で、「メモ機能」について考えることが何回かあった。便利に思える半面で、気をつけるべきこともあると感じたことがあったので言語化してみた。
※なお、個人の見解なので観点に漏れなどはあると思う。

定義 : メモ機能とは

ここで「メモ機能」と呼んでいるのは「社内ツールにおいて、特定のデータに紐づけてフリーテキストでメモを残すことができる機能」である。

※なお、社内ツールとは、CSの業務で利用するものから、営業管理など、社内の業務で用いるツールを指す。

例を出してみる。
よくあるケースでいうと、CSで利用するツールで「ユーザーメモ」といった形でユーザーごとにメモを残す機能が用意されていたりする。そこには、CS対応する際の注意点や、過去のキャンペーンの対象であったことなど色々なことが記録されうる。
他の例でいうと、ユーザーなど以外にも、取引やキャンセルなどといった行為それ自体にもメモ機能が用意されることがある。

このメモ機能という概念は、zendeskにも用意されている。お問い合わせ（チケット）にユーザーへの返信とは別に社内向けのメモを残すことができる機能がある。（プライベートコメント、または社内メモと呼ばれる。）

画像引用元 : zendeskヘルプ チケットへのコメントの追加

上記のように、社外のユーザーへは見えないが、業務の観点から社内向けになにか伝えたいことが記録される用途が多い。

何が問題なのか

ではこのメモ機能の何が問題なのか。端的にいうと「利用用途の不確実性から、負債になる可能性が高い」ということかなと考えている。

言い方が難しいのでもう少し具体的に書くと以下のようになる。

フリーテキストという性質上、業務で利用されるうちに様々な情報が入力されるようになりやすい。（ = 利用用途の不確実性）
それにより、本当は異なるシステム仕様のほうが適している情報などもふくめ雑多に情報が格納されるようになってしまいがち。（ = 負債になる）

いかし「雑多に格納される」とあるが、どういう情報が格納されがちで、それがどんな不都合を起こしうるのか。それらについていくつか挙げてみる。

①データ分析に用いる情報

よくあるのが特定の対応をしたユーザーや取引などについて、それと分かる文字列を記録しておき、それを後ほどSQLの文字列検索（LIKE句）で分析に用いたりするパターンだ。

もともとその文字列はデータ抽出のためというより、運用上必要だから残されるものであるが、気づくとデータ抽出のために利用されるようになっていたりする。

しかし、データ分析などに用いることを目的とするなら、こういった情報はフリーテキストとして残されるのは適さない。
理由としては以下のようなことが挙げられる。

・入力する際に表記揺れが発生しやすい
・文字列検索での抽出で、重いクエリになりがち

これは、タグ機能を用意し、データ上管理しやすくするとともに、表記揺れが起きないようにできるにすることがのぞまれる。

②情報変更や対応の履歴の情報

意外とやられがちな気がするのが、何か情報変更をした際に、変更した前の情報等を記録するケースだ。例えば、ユーザーへのサービス内容の変更をする際に変更する前の情報をメモに格納する等。

これは明らかにその変更した情報のログをとっておき、表示できるようにするべきである。そうしないと、人による入力内容の誤りや入力漏れが起きることが容易に想定されるからである。

（おそらく、最初の想定では変更ログは不要と考えたり、そこまで手が回っていないため暫定策としてメモに格納する形になりがちなのだと思われる。）

③ワークフローのように用いられるような情報

ワークフローなどで残されるような、承認の証跡をメモに入れ更新していく形をとるケースをとる形で利用されることもある。

「田中部長承認済み」などといった確認のログみたいに利用されたり、承認の流れを順々とメモを更新して追記していく場合など。

さすがにガッツリ承認フローなどとして利用されることはないにしても確認した形跡の情報記入などがなされるとすると以下のような問題点が起きると考えられる。

・テキストの変更権限をうまく制御しないとメモを改ざんできてしまう
・変更日時のタイムスタンプや、だれによる変更なのかといった情報がシステム的に残せない（メモの編集ログを都度残せば解決するかも）

これはもちろんワークフロー機能を作ったほうが良い。
いつ、だれによって、どんなことが行われたかをシステム的にきちんと残しておいたほうがよい。そして、権限管理が必要であればそれも要件として盛り込まれるべき。

④機密性が高い情報

個人情報や、重要な取引情報など機密性が高い情報が潜り込むようになることもある。つまり、社内ツールを閲覧する人全員に対して見せてはいけなかったり、データベース上でより厳密なセキュリティで管理するべきであるような情報だ。
これは長く放置したあとに正そうと思うと、特に色々な問題を引き起こす。

まず、業務に関わる人がそのメモを見ることを前提とするフローになっていながら、そのうち一部の人（委託先企業の方など）には機密性の高い情報を見せたくないケースである。
新しく閲覧権限をつけられるメモ欄を作り、今後は機密性の高い情報はそちらに格納することはできる。しかし、過去に蓄積されたメモに対しても、全て切り分けをすることは非常に骨が折れる作業となる可能性が高い。

また、データベース上の管理もより高いセキュリティ水準に変更しようとする際も、メモを用いたデータ分析が現場で多々利用されており、変更に踏み切りずらいといったことも考えらえる。

というように…

こうやっていざ一つ一つ考えてみると、割と「そりゃそうだ」と思えることではある。ただ、どれも実際には起きがちであったりする。

なぜ起きがちなのかというと、そもそも何を記録するか不明確であるが、あると使うだろうという目的で、メモ機能を用意しておくことがある。（そしてそれは確かに運用上便利であることが多い。）

また他にも、本来は想定していなかったもののフリーテキストという自由度の高さから、いつの間にか業務の中で上記のような利用がされていたということも多いと思う。

その結果として、冒頭に述べたような「本来は異なる仕様で満たされたほうが良いような情報が入り乱れて入力されてしまう」ことになりやすいのだと思う。

どうすればよいのか

自分にもまだよく分かっていないが、こんな方向があるのではと思っている。

運用の徹底とできることの制限

→ そもそも適さない情報が入らないにようする。
上記のような情報を入力しないようにと業務チームに伝えて徹底しておく。
それだけでなく、最初からあえてできることを制限しておく。
具体的には、データ分析としてメモのテキストを利用できないようなセキュリティ水準にしておいたり、入力可能な文字数上限をあえて少なめにしておく等。

定期的な利用用途確認と別機能への切り出し

→ 適さない情報が入り始めたことをすぐ検知し、別機能に切り出す。
定期的にどんな情報が入力されているかを確認する。
その上で、管理する上でより適した要件があるような情報については、別途機能を切り出してそちらで管理できる状態を目指す。
要は適さない情報が入力され始めても戻りうる（ =手作業で戻って切り分けられる）タイミングで検知して、対応を考える機会をもてることが大事。

とはいえ…

事業のフェーズや他の要件との兼ね合いなどもあるので、メモ機能を実装することが悪いわけではもちろんない。そして、メモ機能はたしかに便利であるし、フリーテキストで残せるようにすることが要件的に適しているケースもあるだろう。

なので、あくまで要件実装の一観点として考えるくらいがちょうどよいのだろう。