ネット上の「ヤバい人」再録

出身研究室の合同OB会があったときに出たネタを某院生がブログに書いていたくれたのだが、諸々の事情で非公開になっていた。
けっこう面白いと思ったので、関係者の許可を取ってこちらに転載。


GW 期間中の某日、恒例の OB・OG を交えての懇親会があったのだが、そのとき話題に昇った「ヤバい人」が本当にやばかった話をまとめる。

以前にもどこかで、医師にはマナーの悪い人もいるみたいなことを書いたが、それはお金に汚い、とか理工系関係者に対する態度が尊大だ、程度のことだ。この人は筋金入りだった。某先生いわく「治療が必要なレベル。発達障害と人格障害を足して2で割って、さらにサイコパス要素も加えたようなレベル」だそうだ。粘着な感じも相当で、だから、ここではこちらが特定されないように「ヤバい人」という呼称を使わせてもらう。

技術的におかしなことを挙げていくときりがないし、今回伝えたいことはそういうことではないので、こういう特徴を持った人がいたらまともにかかわっちゃだめだよ!的な感じでまとめたい (^^;)

・態度が身分不相応に尊大。現実的には、社会的評価や業績に圧倒的ともいえる差があるにもかかわらず、特定の意にそぐわない行動を取る人を攻撃対象としかみていない。

・反論が幼稚にもかかわらず、なぜか自信満々。それっぽい反論を「後で」出したりするのだが、いかんせん、ポイントがつかめていないせいか、その反論も反論になっていない。

・理屈では勝てないとわかるとネット上で誹謗中傷かきまくり

やばすぎる。他にも特徴はあると思うが、特にネット上では、即座に力量がわかるわけではないから、こういった傾向を持った人には注意しなければならないと思った。


面白いと思ったのは、ネット上にこういった人は確かに多いこと。
精神科的観点からあれこれコメントしてみたい。

ところで、このブログでも度々より上げてきたドルフィンプロジェクトだが歴史的評価の段階に入った感がある。
あのプロジェクト内部にも上で述べたような感じのちょっと困った感じの人がいたんではないか?みたいな記事が、最近(2024年2月)チラホラ目につくようになった。

Monster Pseudo-Developer in Dolphin』あたりをご参考に。

(追記)歴史的評価といきたいところであったが、AI まとめが出鱈目記事書いているので、それ対策に追われた。
結果的に dolphin とライセンスと著作権関係がかなり整理されたと思う。

OpenOcean/Dolphin と職務著作と GPL
IT プロジェクトで避けて通れないのが職務著作というやつで、dolphin プロジェクトの歴史的発展に絡めてかなり平易に説明されてます。

OpenOcean 怪文書 -GPL 誤用による違法行為教唆-
職務著作などの概念がわかった上で、この記事↑読むと状況が頭に入ると思います。GPL 違反は海外の法的係争に至った案件で紹介されることもありますが、ああいうのは立派すぎて実感を伴わないものが多い。
実際に起こった事件を扱ったものではナンバーワンでしょう。


最近、やばい人、認定されたのは、この記事で取り上げられた人でしょう。
この人の場合は、日常生活では異常ではないと思う。
だが・・

たとえ通常時は常識的で善良な市民であっても、ひとたび「開発者」という名誉を独占するチャンスが見えた時、人は簡単に悪を働く、というのはオープンソース界隈で散々見てきた光景だ。2.7m 系のドキュメントを参考にしても、コードは 2.7 ベースにしておく、みたいなことはこれまでにも何度かあったのだ。  引用元

という事情はありそうですね。
OSS はよからぬ人を惹きつける魔力みたいなものはある。あるいは人間の中に潜むよからぬ部分を肥大化させると言ったらいいのか。

私がこの人に感じた違和感をメモしておく。

・PR が「無効になった」と主張するが、無効になってない。

・皆川和史の名前を削ぎ落とそうという意図が感じられるが、2003-2012 は Digital Globe が著作権を保有していたわけだから、そこは尊重しないと過剰編集になる。

・ビルドテストもできていない段階で権利を主張する。

・対話性がない。

・レビューされるのを恐れる。

などなど。

特に「レビューを恐れる」に関しては、流石にコメントしておく必要があるだろうか。
dolphin のコードは素を正せば e-dolphin 時代のものです。著作権所有者は変わってきましたが、あくまで「オープンソースとして開発」されたものです。
当然、オープンソースとしてのライセンスは引き継がれます。利用者には公開義務があるし、誰かがそれが適正に行われているかチェックする必要があるでしょう。その一環としてのレビューが嫌いだ、好まないというのであれば、利用をやめるべきでしょう。
公共財を使うということはそういうことです。

 

ANN2b

OpenDolphin -増田ファクト難民-

この頃、諸々あって OpenDolphin(オープンドルフィン) 関係を調べている。
→結局、『OpenDolphin -wikipedia 風解説-』にまとめました。

そこでいう OpenDolphin は OpenDolphin-2.7(m) 系列のことを指している。
というのは、現在(2020年年末)においてソースコードが公開されている最後のバージョンがそれだから。
ま、他にも理由はあったりするのだが、それは割愛。

それ以前は 2.3 系列や 2.5 系列がそれなりに普及していたようだ。

で、調べていたとき、「増田ファクト難民」という言葉を何回か耳にした。

「増田ファクト」というのは、和歌山の内科開業医(現在は閉院しているようですが)、増田茂 氏がフォーク(Fork ) したバージョンで、確かに以前はそれなりに普及していたようだ。

なのだが、私が調べた範囲では、使っている医師はまったくいなかった。
まあ、私の知り合いなんぞ東日本中心にかなり限られているけど。
(ちなみに、ほとんどは OpenDolphin-2.7 系列の自力運用。まあ、院内SE抱えていれば、運用はさほど難しくないでしょう。当然)

OpenDolphin-2.7m猪股先生も一時期は使っていたということで、それなりの質を維持していたんだと思う。
実際、猪股先生も

おそらくこういった「導入は増田ファクトで(当時としては、確かによくできた導入環境でした。ただし、導入手順書にしてももっぱら windows 前提で、Mac OSX へのインストールなどはまったく触れられていませんでした)。ある程度、様子がわかってきたら、さらにカスタマイズ。その後は、独自路線を突き進むなり本家に戻るなりして開発を継続」といったパターンは多かったと思います。

と『OpenDolphin について』の中で述べている。

 

で、「増田ファクト難民」ですよ。

なんでも、増田氏、ユーザーさんが何か気に入らないことをするとバッサリとアプリ(OpenDolphin-2.3m というらしい)の提供をやめていたとか。
また、電子カルテの乗り換え時に「増田ファクト」から他電子カルテに乗り換えるとき、データ移行の手段をまったく提供していなかったという(もちろん今はどうかは知らない)。

そういった「電子カルテはあれど、データが取り出せない」見捨てられたユーザーのことを隠語的に「増田ファクト難民」と言っていたらしい。

元商用開発元の方も「増田さんのバージョンからの乗り換え(データ移行)は何回か手伝ったことがある」と明言していたので、たぶん、そういった事情は本当にあったんだと思う。

もちろん増田さん自体はソフトを無償で提供していたので、このこと自体は咎められないと思うのだが(基本的には何か問題がおこったとしてもユーザーの自己責任)、問題はそのような運営状態にあるソフトを「電子カルテ」と呼んでいいのかってことなんだな。
ここらへんはややこしい問題も含んでいるので猪股先生が書いた『OpenDolphin と電子カルテの3要件とメドレー』を読んでみてください。ネット上ではかなり参照されている記事です。

 

そして、(これ書いていいか相当迷ったのだが)思い切って書いちゃうと、その後の増田さんの言動が周囲の評価を下げたと思う。

まず、猪股先生の OpenDolphin-2.7m がご自身の 2.3m のフォークだと主張した点。
これは完全に誤り。
OpenDolphin は、バージョンが上がるにつれテーブル数が増えていっている。
2.3 ベースのものと 2.7 ベースのものでは、そもそもテーブル数が違っている。
データベースを精査すればわかるが、OpenDolphin-2.7m は LSC 版 OpenDolphin-2.7 の直接フォークで、データベースの構造も 2.7 と何一つ変わっていない。
2.3 ベースの 2.3m からわざわざテーブルを増やして、2.7m に進化させるという手間のかかるアプローチを取る必然性はまったくないし、一般公開が中止された 2.3m をベースに 2.7 系に修正をはかるというのは不可能に近い。

次に、猪股先生版 OpenDolphinOpenDolphin-2.7m)のいわゆるファイルバックアップシステムを「役立たず」のように悪様に評価したこと。
どのような評価をしようが自由ではあるのだが、世間的に評価されているのはむしろこの機能だろう。
実際、ここまでデータ構造に関して理解している人はいないということで後期 LSC やメドレーからメンテナの打診があったのはよく知られた話だ。

開発者の猪股(弘明)先生が明らかにしているようにこの機能は元々はデータ抽出ツールが元になっている(参照:『ORCA, OpenDolphin, OsiriX は未だに話題になりますね』の「OpenDolphin カスタマイズの実際」の項)。
近年は、行政から電子カルテの修正履歴の開示まで求められるようになり、この手の機能はもはや必須といっていい。
一時的に普及した増田ファクトだが、次第に開業医からかえりみられなくなったのは、「クライアントに搭載されている(最終確定版の)PDF 印刷機能だけで十分。ファイルバックアップ機能は不要」といった開発ポリシーも一因にあげられるだろう。
現代では、データ操作機能が貧弱な増田ファクトでは電子カルテとしての実運用は難しいのだ。
これも私の個人的意見というより厚労省のガイドライン的な要請です。
このガイドラインでは

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

電子カルテ本体とは別系統でバックアップシステムを備えておくことが推奨されています。
増田ファクトはクライアント経由でしかカルテデータを抽出できませんから、この基準を全く満たしていません。
一方、猪股版 OpenDolphin は、HTML/PDF Viewer と組み合わせて使うことで、この基準を完全にクリアしています。
仮に増田ファクトが電子カルテだとしても、ガイドラインの基準を満たしてないソフトの担当者(増田茂)が、基準を満たしているソフトを何の根拠も示さずに「そうではない」と否定しているようなものです。だから、周囲はその主張を受け入れることはできません。というより、そのような無茶な主張をしている人の評価を下げることはあっても、上げることはないでしょう。

さらにダメを押したのが増田茂が「OpenOcean は著作権違反行為だ」と誹謗中傷をしたことだろう。
その論理で言うなら 2.3m には dcm4che のコードがそのままの形で含まれていたのだから、増田ファクトの方が GPL 違反をしていたことになる(そしてそのことを増田茂は、一言も言及していない)。

また、ここから疑惑が生まれたように思う。
本当に自分でコーディングしているなら、こういった間違いはまずしないからだ。
もちろん昔書いたコードなどそのロジックを忘れることはけっこうあるのだが(バグの温床になります、はいw)、新規に追加した機能などはソースコードを何遍か見直せばほぼほぼその意図は思い出す。
(『ソースコード嫁』参照)
猪股先生自身が「勘違いされてるんじゃないですか?」と指摘しても自分の主張を引っ込めなかったし、当時の商用開発元(私は後期 LSC とか呼んでますが)「増田ファクトと商用版とのデータ互換性はない」と明言しているにもかかわらずそのことを認めなかった。まあ、後者は「互換性」の定義にもよるのだけど。

実際、開発元が、後期 LSC 〜メドレーあたりになってから、増田さんは「開発者」としてはみなされていないそうです。
これもかなりおかしな話なんですよね。
過去のことであってもソースコードを提供したなら、contributor としての立場は変わらないはずなんですが、実務上はそういう取り扱いになってないようです。
経営陣が変わった途端、その立場を失うってのは商用ソフトならともかく(あ、商用ソフトでも本当はまずいかw)オープンソースの世界ではありえないはずなんですが。
GitHub でソースコードのやり取りしていれば、変に疑われることもなかったと思うんですが、その痕跡はまったくと言っていいほど残ってないし。
やっておけばよかったと思うんですけどね。

最後に付け加えると、メドレー的には「増田ファクトは危険」という認識らしいです。
OpenDolphin という名称は、特許庁による判断が下されてから、原則、他の団体が使っても問題なくなったんですが(air-h-128k-il 氏の『OpenDolphin と知財権に関するちょっと小難しい話』にかなり詳しい解説があります)、それはあくまで本家版との相違点が明示されている場合のみです。
「データ互換性がないのにあたかも互換性があるように広報するのは、容認し難い」そうです。
あ、これメドレーの言い分ですよ。
私じゃなくて(これ言っておかないと変に恨まれたりするんで)。
MIA も SOSO も猪股先生も、後期LSCとメドレーから許可取ってるんで、そうすればいいだけの話だと思うんですけどね。

(追記)長々と書いてましたが・・・

メドレーに開発元が移って状況はさらに変わりました。
メドレー自体が「OpenDolphin は GPL に従う必要はない」とかなりはっきり言うようになった。
増田さんの取り扱いに至っては(はっきりと言ったわけではないですが)「契約上、著作権者として取り扱っていただけ」のようです。
OpenDolphin について』より

あらら。
不自然なことは山ほどあったが、結局、そういうことだったわけですか。

(追記2)私なんぞドルフィンに手を出してからそんなに日が経ってないので遠慮してましたが、さすがにこれはダメでしょう。

現在(というか 2020 以来)、OpenDolphin という商標はメドレーが保持しているわけですから、配布などの際にはメドレーの名前をクレジットしないと(厳密には)商標権侵害にあたります。

また、こういう投稿もどうかと思う。

おそらく、OpenOcean 再設計を指して「そんなのできるわけない」という揶揄をこめての投稿なんだろうが、現在の IT 企業の新人社員研修あたりでも、永続化機能ありの Web API を持ったシステム(例えば簡易 EC サイト)は組ませるので、現行の技術水準の把握の仕方が何かおかしい気がする。この人や周囲の人々(ちなみに、@sci_sugi はシステムクラフト杉原利彦氏のアカウント)にとっては、新規のプロジェクトを起こすのは難易度が高いのかもしれないが、ある程度スキル・経験あるグループにとっては、そこまで難しいことではないし、できなければ、ほとんどの IT 企業は経営が成り立たない。
間接的に SIer などの新人教育係をディスってる感じになって、あまりいい印象を受けない。
(追記の追記)「ご自慢のデータコンバーター」という表現も今となっては滑稽。ガイドラインの改訂に伴って、大半の商用電子カルテシステムは、(内部的に)主系統のデータベースのカルテ記載内容をデータコンバートして別系統のシステムのデータベースに格納している。こういう構成にしておかないと、主系統のシステムがダウンした時、過去カルテが閲覧すらできなくなって、医療の提供が滞ってしまうからだ。
なぜに彼(「彼」と呼ぶのは、今となっては @masudanaika は現実の増田茂医師だけのアカウントとは考えにくくなっているから)がここまでデータ操作機能を軽視していたのか、ある程度推測はつくが、やはり謎。
(追記の追記の追記)彼にとっては「アプリを新規に作成する」のは、不可能に近いことらしい。猪股先生たちは OceanMini とか普通に公開してるよね。
「データベースに API 全部新規開発」するのがそこまで難しいだろうか?
冗長になりがちな dolphin の Java コードをメンテするよりある意味楽。

(追記3)ところで、猪股先生を中心とする OpenDolphin-2.7m 開発コミュニティ、これまでもにも「設計が古い」と言われてきた OpenDolphin のアーキテクチャを大幅見直し。
諸々の理由で3層クライアントサーバ構成を採用。

フロントエンドサーバーにウェブサーバー機能を組み込んだ関係上、クライアントはブラウザになっている。

プロトタイプを YouTube で公開している。

ところで、ここまでくると増田茂の主張がほとんど見当外れもいいところなのは明らかではないでしょうか。

デスクトップアプリをどんなにこねくり回してもクライアントがブラウザになることはありません

このウェブレイヤー(dolphorca と呼んでいる)は、

OpenDolphin-2.7m → OpenDolphin HTML/PDF Viewerdolphorca

の順に発展してきています。
増田ファクトのクライアント(私が聞いた話では windows でしか動かないみたいなんですが???)が入り込む余地はありません。

(追記4)上で「増田ファクトは無償」と書いたが、現在では有償になっているようだ。
ただし、匿名垢だし、現在のガイドラインでは電子カルテの基準を満たさないアプリを「神」と呼称することから考えて、本当に投稿主が医師であるかどうかも疑わしいが。

(追記5)電子署名や電子カルテへの画像取り込みに関して、間違って理解している人がネット上にはいるようだ。

いわゆる「肉筆」をスキャナなどで画像として電子カルテに取り込んだとしても、それだけでは電子カルテの一部としては認められない。(上部の解説は wikipedia より。そこにもあるように画像など電子情報はコピペが容易であるため、証明力が弱いというのがその理由)

現在は真正性を担保するには公開鍵暗号方式のお世話になる必要がある。
その場合

・HPKI を利用した電子署名
・タイムスタンプ

の付与が必要とされています。

(追記6)本稿は、主に増田茂に焦点を当てたが、小林慎治という人もかなりトンデモな主張を繰り返していたようだ。
小林慎治氏の OpenOcean に関する事実誤認
などご一読ください。
個人的には「コミュニティ」といえば何言っても許されると思ってそうな態度が気に入らない。法理的にはこの態度はまったく正しくなく、著作権に関して申し立てができるのは原則著作権者に限られます。小林慎治は著作権者ではないわけですから、断定的に「違反」だのを指摘できる立場にはいないわけです。主張の内容も事実誤認が多く、誹謗中傷と言っていいでしょう。

(追記7)最近では X の @masudanaika アカウントは自分では「医師」とな名乗らなくなった。
でも、そうすると 2020 年くらいまでの医師アピールはなんだったの?という話になる。
非医師が医師を名乗っていたわけですから、医師法18条による医師法違反ですね。
また、医師でもないものが「つくった」と宣伝していたわけですから、前期 LSC の OpenDolphin に関する広報はほぼ全て虚偽広告になります。

ANN2b

 

MS windows での C++ の位置付け

マイクロソフト(MS) は一時期はアプリなどの開発言語は C# 推しで、C++ は影が薄く、せいぜいコマンドラインツールなどで必要があるときに触っていた程度だったのだが、近年は C++ 絡みのフレームワークなどを提供している。
昨年(2019)、C++/WinRT というフレームワークが発表されたのだが、それまでの流れで「どーせ大したものでもないだろう」と高を括っていたのだが、それなりに評判いいようだ。

せっかく Mac に Parallels を入れたので、ついでで windows も入れ、

C++/WinRT の始め方

を参考にしながら、環境を整えてみた。

上の記事記載の通りそのままにやっていけば、原則、同じ結果が得られると思うが、現在の Visual Studio 2019 だと、UI の変更があってので、若干操作が異なるようだ。
気がついたのは、C++/WinRT を入れるところで、上のように メニュー -> 拡張機能 からいかないとマーケットプレイスには辿り着けないと思う。
ダウンロードしたのち、再起動すると Blank App (C++/WinRT) プロジェクトを作成できるようになる。

 

ANN2b

 

ORCA, OpenDolphin, HorliX

所要とはいえ ORCA日本医師会がソースコードを公開、配布しているレセコンソフト)とOpenDolphin(電子カルテ。これもオープンソース) と準備してきたので、HorliXHoros/OsiriX ベースの画像ビューア。オープンソース) も起動。
特に深い意味はないんですが。

いや、しかし、壮観ですな。

一台の Mac の上で動いているってのにちょっと感動してます。


 

ところで、OpenDolphin・HorliX は、精神科医の猪股弘明先生の開発したバージョンを使ってます。

OpenDolphin

OpenDolphin は、オープンソースですから、当然、派生バージョンは色々とありますが、OpenDolphin-2.7m (今回、試したバージョン)は本家(dolphin-dev)に割合忠実です。これにはそれ相応の理由がありました。
OpenDolphin について』、『OpenDolphin と電子カルテの3要件とメドレー』あたりがわかりやすいでしょうか。開発者本人がその経緯を語っています。

私も今回 OpenDolphin に触れてあれこれ感想を持ちましたので、機会があったら何か書いてみたいと思います。

HorliX

画像ビューア HorliX に関する使い勝手などに関しては『COVID-19 による肺炎CT画像!<HorliXにて表示>』(精神科医高木希奈先生のアメブロ)に動画入りで紹介されていますので、そちらもご参照ください。

ところで、先生、最近、ブログで

HorliX と薬機法

という法律ガラミにしては?面白い記事を書いているので、こちらもよかったらどうぞ。

ORCA

ところで ORCA に期待(懸念?)されていることは、本当に今の設計のままで意味のあるクラウド化ができるのかってことですが、これも猪股先生、一つの提案をしてくれました。

将来的には医療情報の類はクラウドに上げて一元管理・ビッグデータとしての活用を図る・・云々みたいな話は、まあそうだろうなとは思うのですが、このとき医療機関側が欲しい情報を取ってこれる環境になっていないとデメリットの方が大きく、実際には誰も参加しないだろうなと思います。
(法的にも医療情報の管理責任は、現状だと医療機関側です。業者ではありません)
欲しい情報を効率よく取ってこれるかどうかは、データ構造の整合性に大きく依存するのではないでしょうか。
これを実現する割と有効な選択肢は現在だといわゆるウェブフレームワークの採用かなと思ったわけです。

オルカの職人芸的なデータベースの使い方も嫌いではありませんが(笑)、この後の展開を考えるとなるべくデータ間の「辻褄が合うように」整合性をはかっておく、モデル化しやすいように準備しておく、というのはあっていいのかなと思った次第です。

メーリス上で議論され、最終的には ORCA管理機構の人に「フレームワークの採用も検討してまいります」とまで言わせしめました。→結局、ORCA 管理機構、独自にウェブフレームワークを開発して、WebORCA をリリース。

また、最近では、ORCA のデータベース(PostrgreSQL)から直接データを抜いて、各種指標を加工する方法を提案しています。猪股先生ご自身が『ORCA の日計表と関連テーブル・内部会計フローなどについて』にまとめてくれています。

 

ANN2b

 

ORCA クライアント monjiaj をソースよりビルド

ORCA シリーズ。

Mac 上で動く ORCA のクライアントを導入しようとしたら、公式サイトには JDK 14 用はあがったいなかった。
せっかく Java 開発環境を用意したので、Java 版の monjiaj をソースコードよりビルドした。たぶん、それほど難しくない。とりあえずテスト的に使うだけなので SSL 対応は無視した。ビルド産物をいろいろつくってくれるようだが、そのうちの一つを立ち上げる。

実際に ORCA サーバに繋いでみる。

以前に登録した秋「場」ちゃんを呼び出せてますね。よかったよかった。

これで、患者さんを登録するのにいちいち(Parallels の)Ubuntu のクライアントを使う必要はなくなった。

(追記)現在(2022)だとビルド途上で failure が出るのだが、out ディレクトリの方の jar を使えば問題なく ORCA サーバーと接続できる。

なお、プログラム自体に署名するときは以下のようなやり方でやるらしい。


署名の設定

pom.xml、maven-jarsigner-pluginプラグインのコメントを解除し編集する。


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
<configuration>
<archiveDirectory>${project.build.directory}</archiveDirectory>
<includes>
<include>*.jar</include>
</includes>
<keystore>${project.basedir}/keystore</keystore>
<alias>alias</alias>
<storepass>storepass</storepass>
<keypass>keypass</keypass>
<tsaLocation>http://timestamp.globalsign.com/scripts/timstamp.dll</tsaLocation>
</configuration>
</plugin>

署名用のキーストアの設定を以下の項目で行う。

* keystore
* keystoreファイルのパスを入力する
* ${project.basedir}はpom.xmlのあるディレクトリに置換される
* keypass
* keystoreに格納されている秘密鍵のパスフレーズを入力する
* storepass
* keystoreのパスフレーズを入力する
* alias
* 証明書のaliasを指定する
* tsaLocation
* 証明書のTSAのURLを指定する


ANN2b
(技術協力 猪股弘明