システム試験におけるトリアージ

トリアージ（Triage）

人材・資源の制約の著しい災害医療において、最善の救命効果を得るために、多数の傷病者を重症度と緊急性によって分別し、治療の優先度を決定すること。語源はフランス語の「triage（選別）」から来ている。適した和訳は知られていないが、「症度判定」というような意味。なお、一般病院の救急外来での優先度決定も、広義のトリアージである。識別救急（しきべつきゅうきゅう）とも称する。（wikipediaより）

いきなり引用からですが、ＪＲ福知山線の事故などで知られるようになったこの言葉をシステム開発における試験フェーズと絡めてひとつ書いてみようと思います。

システム開発の試験はどれだけ理想的に進めてもちょっとした躓きで混乱や炎上がおこります。
混乱する原因は、「その不具合は何が原因なのか？」が大本です。
大まかにでも原因が特定できていないと、誰が対応すべきか／誰が対応するのが適切か、がわかりません。
最悪、全く知識のない人が調査をすることになって無駄に時間を費やすケースもあります。
原因がわからないから調査するわけですが、調査の適任者を決める為には原因個所がわからないと…　卵が先か？　鶏が先か？　という感じですね＾＾
なので、「大まかな」原因個所の特定が重要になります。
ちなみに、このときの特定は「ＡかＢ」という程度で構わないと筆者は考えています。
無論、「これこれ、こういう風になっているのが原因と思われるので、ＡかＢで問題があるのでは？」という推論が必須です。


「大まかな」原因個所の特定を行わずに、不具合に対処した場合はどうなるでしょうか？
このような場合、難しそうな不具合はリーダーや上級ＳＥなどが担当し、それ以外はなんとなく（件数を頭割りするなど）それぞれのメンバーが担当することが多いと思います。
難しいところは実力のある人が、というのは正しい判断ですが、簡単な不具合に未熟若しくは担当外を担当する人が時間を取られて全体の不具合対応の進捗の足を引っ張ることも多々あります。
進捗が上がってこないとリーダーなどの負荷が増大し、さらに適材適所な不具合修正が出来なくなる悪循環に突入します。
この結果が炎上です。


混乱も炎上も極力避けたいモノですので、不具合の報告を受けた際に何が原因かの切り分けを行うべきです。
その際に便利な考え方が冒頭に書いた「トリアージ」です。


医療の現場だと「命の選別」とまで言われるのですが
（黒タグ：死亡もしくは手当てをしても助からない。　　赤タグ：すぐ手当てが必要。　　黄タグ：すぐにではないが、手当てが必要。　　緑タグ：軽症。
黒タグが付けられた人は今息があっても手当の対象にならない）
システム開発現場では以下の基準での「選別」が考えられます。

　緊急：機能停止または他の機能への影響が大きい不具合。対処は可能な限り早く行う。

　要対応：機能がとりあえず使える、局地的な影響があるような不具合。対処は緊急の次に行う。遅くとも翌日（または２～３日。開発のスピード感に依存）には改修する。

　要検討：機能が問題なく使えるが、何らかの問題があるような不具合。対処は一週間程度のスパンで考えればＯＫ。

　不急：機能が問題なく使え、何らかの軽微な問題があるような不具合。対処は急ぐ必要はないし、運用でのカバーなどで対処不要なケースが多い。

この基準と、大まかな原因特定を組み合わせることで各担当者の分担の最適化と改修予定が立てられます。
要検討や不急の不具合については、比較的時間のある担当外の人が見てもよいわけです。
逆に、緊急や要対応の不具合は原因と思われる個所を担当した人が見ることで迅速な対応が可能になります。
システム開発の場合、黒タグはありませんが（例外として、システムの制約で改修不可能な不具合と言うのがあります。これは黒タグ扱いに近いです）不具合の深刻さと対処期限で切り分けることで全体の進捗が滞らないようにし（他の機能に影響する不具合を放置すると、影響先の機能の試験などが滞るため）、対処期限を守る為に大まかな原因特定で適任の担当者を割り当てることを目指す考え方です。


以上が、システム開発の試験における「トリアージ」の基本的な考えですが、実践する場合はどうなるのか？
こちらについては、筆者の考えがまとまりましたら書いてみようと思います。
とはいえ、経験から出来るようになっていたようなところがあるので難しいのですが＾＾；




横断歩道の真ん中（歩道の上です＾＾；）でマニフェスト配布はやめてほしいなぁ。
結構、通行の邪魔だったりします。
あれじゃ、名前覚えてもマイナスイメージだと思うのだけどなぁ…