SOAP

注: 通信プロトコルについての記事ではない

病院で診察中に医師の記入している電子カルテを除くと、S,O,A,Pという各項目に記入していっているのをみかけた。どこの業界も謎の頭文字好きだよなと思いつつ、なんとなく気になって調べてみた。

SOAPそーぷ)とは、問題指向型診療録(POMR)の一つである。POS(Problem Oriented System:問題志向型医療)の考え方によって得られたデータを内容ごとに分類・整理した上で、下記のようにS、O、A、Pの4つの項目に分けて考える分析手法でもある。

  • S(Subject):主観的データ。患者の話や病歴など。
  • O(Object):客観的データ。身体診察・検査から得られた情報。
  • A(Assessment):上記、SとOの情報の評価。
  • P(Plan):上3者をもとにした治療方針。

引用: https://www.kango-roo.com/word/6876

これを見て医療とITで業界は違えど、同じような思考でやっている仕事もあるなと思った。

ユーザーや運営が困ったときに技術的なサポートをするという仕事をすることがある。たいてい突発的にやってきて、開発をしているエンジニアが交代で対応している。専任のサポートエンジニアがいるわけではなく、対処方法も色々なので、各エンジニアが臨機応変に対応している。

サポートの仕事もユーザーの主観的な情報を聞いたあと、客観的な情報を集めるという作業を行う。例えばユーザーからデータが消えたという情報を得たなら、本当に消えたのかDBを見て確認するというような作業だ。そしてその主観的情報と客観的情報を突き合わせて状況を評価する。そしてその評価をもとに何らかの対応をする。

ユーザーサポートにおける例:

  • S: データが消えた
  • O: DBにはデータがある
  • A: データは消えていない
  • P: ログインしているアカウントをユーザーに確認してもらう

書いてみて思ったが、このSOAPというフレームワークは患者の症状のような主観的にしかわかり得ないが重要な情報を扱うときに有用だ。すべて客観的に情報を把握できるのならば主観的情報は排除できる。重要だが主観的な情報を客観的な情報で補って評価をするというのがこのフレームワークの要点だ。

システムのサポートも、主観的な困っている状況を客観的情報で固めていく手順は似ているので転用できるフレームワークである。サポートの仕事が苦手で困っているエンジニアがいたらこういう思考と手順でやっているんだよと教えてもいいかもしれない。

参考: https://en.wikipedia.org/wiki/SOAP_note