私は告白する必要があると感じている。私はSENDソフトウェアとサービスのベンダーであるため、SEND標準がどのように定義され、実装されるべきかについて強いバイアスがかかっていることを認める必要がある。
ここ数回の投稿で、私たちはSEND基準がいかに柔軟であるか、あるいは「主観的」であるかについて議論してきた。私の口調からお気づきかもしれないが、私はそのような柔軟性を特に嫌っている。 私はそれを隠そうとしてきましたが、残念ながら私自身のバイアスが透けて見えてしまいます。
ベンダーであることがどのようにそのバイアスを駆り立てるかを説明するために、このような柔軟な基準を持つことの長所と短所を少し見てみようと思う。
長所
柔軟性は、SEND基準をより簡単に採用できるようにするためのものであった。データの収集方法や報告方法は千差万別であるため、SEND基準はデータに対して何を期待するかについて、あまり杓子定規であるわけにはいかなかった。研究結果に関連する特定のデータまたはメタデータがあれば、それを記載する場所があるが、もしそれが記載されていなければ、それも構わないというように、十分に緩やかである必要があった。
これは、この特定の情報を把握しているか否かにかかわらず、すべての組織がSENDを受け入れることができるという利点がある。同じ原則が、タイミング変数にも当てはまる。調査データを見てみると、もしカレンダー上の日付しかないのであれば、それはそれでよい。日付と時刻があれば、それも問題ない。しかし、代わりに試験日の数字があるだけなら、それも同じように受け入れられます。あるタイミング情報を入力するだけで、足りないものは気にしなくてよい。
このアプローチを取るということは、より幅広い研究や収集方法を可能にする、はるかに包括的な基準を持つということである。
それは素晴らしいことでしょう？で、何が問題なんだ？
短所
SENDデータセットを消費する多くの組織にとって、研究間の一貫性の欠如は様々な問題をもたらす。明らかなのは、研究間の分析の妨げになることである。データがこれほど異なって表示される場合、どのようにして2つの類似した研究を比較できるのだろうか？これは、このようなツールを開発しようとする者にとって共通の課題である。変数が一貫した方法で入力されることに依存できない場合は難しい。例として、先週、私たちはNominalラベルについて議論していました。Nominalラベルは、日数または週数を含むことができるだけでなく、タイムポイント情報、カテゴリー情報、またはスケジュール情報を含むことができる変数です。これらはすべて許容される使い方ですが、データを消費するツールにとってはどうなのでしょうか？
もう一つの難点は、各組織がこの規格を独自に解釈していることだ。そのため、さまざまな組織に合わせてさまざまな方法でSENDを作成・利用するためのツールを作る必要がある、地味なベンダーにとっては難しい状況になっている。というわけで、私のバイアスが強く働いているのは明らかだ。オプションも柔軟性もない。
私はこの投稿を、ベンダーとして、SENDが非常に柔軟であることを許可することに対して、隠しきれない偏見を持っているという告白から始めた。ツールの開発者にとってはるかに楽になるだけでなく、私はSENDがより制限的であることによって業界全体が恩恵を受けると考えている。賛成でも反対でも、あなたの意見を聞かせてほしい。メールはいつものアドレスinstem までinstem
次回まで
マルク
