第17回業務システムをオープンソースで作ること

「チームみらい」の人の発言(削除済み)が元で、自治体の開発したソフトウェアをオープンソースにするという話であれやこれや賑っています。

例によってここでは特定の思想信条や政治勢力に対してどうこう言うつもりはありません(それが気になる人は個人のTwitterでも見てください)。ただ、肯定するコメントも否定するコメントも、ちょっと解像度が低いな(婉曲表現)と思うことが少なからずあるので、リアルな話を書いてみようと思います。

もちろん中心となるサンプル数は1程度でしかありませんが(「1」でもないんですが)、世界の全てのサンプルを集めても両手で余るくらいの事例数しかない世界です。「サンプル数」となるのは成功事例だけというバイアスがかかりますが、死んだ子の歳を数えてもしょうがありません。また成功事例について詳しく話を聞くとその「1」を参考にしたものが多いのだという話らしいので、それなりに普遍性はあると言っても良いのではないかと思います。

背景

自治体システムについて、しばしば「オープンソース化」が銀の弾丸として語られます。

これはどうも「解像度の低い人達(婉曲表現)」にとっては魅力的でかつドヤれる主張らしく、定期的に上がって来る話題のようです。それについては個人ブログの方でも取り上げています。

「それはもうやった」

ここでも触れていますが、主張する人の立て付けとして、

自治体システムはだいたい同じ(ゴールは法律で決まっている)なのにそれぞれが開発していて効率が悪い
どこかで標準パッケージ的なものを作れば、同じものをあちこちで開発しなくて済む
それをオープンソースにすれば、改良のフィードバックが期待できるので、メンテ工数も減る

というのがあります。これは、元の「チームみらい」の人の主張もだいたい同じだったと思います。消されているのであらためての確認のしようがありませんが。

この主張は「ITコンサル」な人達からすれば噴飯もののようで、Twitterでもその筋から「何もわかっちゃいない」的な主張が流れて来ています。

もちろんどちらの主張にも一理も二理もあるのですが、どちらの主張も「解像度が低い」としか言いようのない側面もあります。何しろ日本でマトモにやった例は1例しかないわけですから。

オープンソースのことをよく知らない人がオープンソースに抱く幻想は、結局は幻想に過ぎません。またその「幻想」を否定する人達の主張も、やっぱり幻想… と言うか、我田引水の主張に過ぎません。

現実の問題としてとらえると、「オープンソースで解決することと、オープンソースで解決しないことの間には、無数の解決はしないけど改善されるものがある」わけです。

nano bananaの作です

そこで発生するであろう問題も、オープンソース固有の問題もあればそうでないものもあります。

日本医師会が「Project ORCA」でやったこと

かれこれ四半世紀使われている日本医師会のレセコン。これが私がここで主張する話のベースとなります。

色々背景の事情はありますが、結局のところ

医事会計システムはだいたい同じ(ゴールは法律で決まっている)
ベンダーがいくつもあって囲い込まれているし高い
ブラックボックスなのでデータの活用ができない

という、前節で述べた「自治体システム」と同じような環境にあり、それを「オープンソース」で解決したものです。

レセコンとは

医療業界の外の人には「レセコン」と言われてもピンと来ないと思うので、軽く説明しておきます。

日本の医療費は「保険制度」によって支払われています。毎月いくらかの保険料を払うことで、受診した時に支払う金額の7割ほどを「保険」が払ってくれます。額がどうだ率がどうだといった話はここではスコープ外なのでしません。ただ、そういったシステムだということです。

「医療費」がそういった仕組みになっている関係上、それを支払う「組織(保険者)」が存在しています。医療機関は「この患者にはこれだけの医療をしました」という文書をその組織に送り、「7割」を支払ってもらいます(3割は患者自身の負担)。

国や自治体が直接やっているわけではありませんが、原則として国民全員が加入することになっている「保険」ですから、公明正大に行う必要がありますし公平でなければなりません。

そのため、標準化された「医療カタログ」の中から「どれをいくらやりました」という文書を定められた形式の文書として提出する必要があります。もちろん「どれをいくら」についての妥当性についても検証可能になっている必要があります。この文書を通称「レセプト」と呼びます。

この事務手続きはとても面倒臭いものなので、かなり古くからコンピュータ化されていました。これをレセコンと呼びます。要するに医療費の会計を行い、レセプトを発行するための専用コンピュータがレセコンです。

かつては手作業で行われることもありましたが、今はほぼ全ての医療機関でコンピュータ化されています(実はこの辺の話も無関係ではありません)。つまり、ほぼ全ての医療機関にレセコンという名のコンピュータがあります。

レセコンの諸問題

このように、いろんな人が都合よく働くためのシステムとしてレセコンがあったわけですが、それゆえに様々な問題がありました。

診療報酬改訂が毎年あるので、利用者(医療機関)は提供者(ベンダー)の言いなりになるしかない
囲い込みが激しくリプレースが困難で、利用者は提供者の言いなりになるしかない
データの流用等ができないので、利用者は提供者の言いなりになるしかない
ITスキルの勾配が大きいので、利用者は提供者の言いなりになるしかない

ということで、要するに「利用者(医療機関)は提供者(ベンダー)の言いなりになるしかない」という状況がありました。

これはある意味しょうがないことです。

診療報酬改訂は医療機関にとっては「賃上げ」みたいなものですから毎年あって欲しいものです。また、医療技術は進歩し続けていますから、「新しい医療」も保険で支払える(保険適用と言います)ようになって欲しいものです。他方、支払う保険の方は少しでも安くしたいですから、お約束的になった診療内容や薬だと「これはもういいだろう」的に下げたりします。

囲い込みがあるのはクラウドの時代の現代であっても同じこと。ベンダーにはベンダーの商売の都合があります。ユーザーは一度身につけた操作を変えたくありません。

データの流用ができないのは、元々そんなことを考えて作ってなかったということがありますし、下手に流用できたらリプレースのデータ移行に使われてしまうかも知れません。データ流用には技術サポートがつきもので… とか考えれば、ベンダーにとっては良いことは何一つありません。

ITスキルの勾配があるのは当たり前のことですね。中にはスキルの高い医師も少なからずいますが、結局のところオタクの域を出る人は多くはありません。ことシステムの話になれば、素直に聞くしかありません。

日本医師会がやったこと

日本医師会は会員からこういった不平を耳にして、決断をします。それは

日本医師会としてオープンソースのレセコンを作る

ということです(厳密にはちょっと違いますが)。

「日本医師会として」作れば、診療報酬改訂は「日本医師会」という単一のベンダーが頑張れば済みます。

またオープンソースにすれば囲い込みのしようがありません。

データの流用も「やる気の問題」になります。自分でできなくても、「出入りの業者」にさせることができます。囲い込まれていると「出入りの業者」も制限されますが、オープンになればどこでも良くなりますからね。

ここまでは、無邪気に「オープンソースでやれば解決」と主張する人達の主張と同じです。しかし、実際にやり始めると、これだけでは問題解決しないことがわかります。

いや、正確に言えばそれは最初からわかっていて、「そこがビジネス」と勘づいた人がいました。それが

サポート体制を構築する

ということです。これが「ITスキルの問題」を解決する手段です。

オープンソースにすれば、原理的には誰でも勝手に使うことができます。でも、それができるのは一定以上のスキルのある人だけです。そうなると、「日本医師会の会員の不平」は解決できません。「会員」の不平を解決するには、ITスキルの問題を解決しなければなりません。そこでサポート体制を構築したわけです。

権利関係

当然ですが、当該ソフトウェアを日本医師会あるいはそのシンクタンクである日本医師会総合研究機構(日医総研)が作ったわけではありません。一応私はそこの「研究員」という肩書をもらいましたが、それはあくまでも「政治」です。直接的に開発したのは、私を始めとする開発者です。

「自治体のオープンソース」という話の時にしばしば「自治体にそんなシステムを作る力なぞない」とか言われますが、べつに「自分」でやる必要はありません。「外注」してしまえば自分達のソフトウェアです。著作者人格権は放棄できませんが(牽制)、不行使契約を結んでしまえば実質的には開発依頼をした人が著作権者です。

ついでに歴史的な余談を加えるなら、この「そんなシステムを作る力なぞない」というのは、当時の医師会に対してもありました。また、「反対派」の医師会員の中にもそういった主張がありました。様々な人達が様々な立場で「作れるわけない」と主張してました。しばしば言っていますが、それは私もそうでした。

また当時は「日本医師会が公式レセコンを作る」ということ自体が、諸々のベンダーに対する反逆行為とされていて、「どうせどこかの裏切り者がコードを横流ししただろう」的な話がありました。この辺は本当にドロドロした世界で、我々は基本的に「死んだフリ」をすることが求められていました。誰がどんな体制で開発しているかは、医師会執行部の中でも秘密だったようです。

政治的な駆け引きの話は面白いのですが割愛するとして、ここで「オープンソース」が威力を発揮します。つまり、「コード横流し疑惑」に対して、フルスクラッチで書いたコードが提示できるわけですから、文句のつけようがありません。もちろんレセコン自体を開発したメンバーは当然レセコン開発の経験者でしたけどね。

どういった種類のプロジェクトであったかは、前弊社のブログに書いているので参考にしてください。

第6回巨大システムを成功させる

標準化

あまり言われてないことですが、ORCAによって様々な「標準化」がされました。

公開はされていても互換性に乏しいデータ体系(たとえば傷病名とコード)は整理され標準化されました。某帝大の権威の先生が何年もやって完成しなかったものですが、某開発者がサクっとやってしまいました。どうやってやったか不思議でしたが、「え？」という感じの解決でした。解決されたことは覚えてますが、詳細は忘れましたｗ

電子カルテとレセコンとを接続するプロトコルも標準化されました。別途開発された電子カルテとレセコンとがデータ交換できるようになりました。今は別のweb APIを使う形式に改められましたが、「最初の実装」ができたことは大きいことです。

そして、その第一のプラットフォームとしてオープンソースのもの(我々の作ったもの)が使われています。

オープンソースは伝搬力が高いだけではなくて、「参考実装」としても使えますから、標準を普及させるためには都合の良い環境です。うまく実装されていてパクりやすいコードがそこにあれば、パクってしまうのはプログラマの美徳です。

また、この標準化の恩恵については、直接ORCAと関係のないソフトウェアも無縁ではありません。中小のカルテメーカーに与えた恩恵は大きかったようです。

サポート体制

ここはORCAのサポート体制を細かく説明する場ではないので、ごくザクっとした話を書いておくと、サポートに関係する「登場人物」は以下のものです

日本医師会本体
運営母体(日本医師会ORCA管理機構株式会社)
認定サポート事業所
一般事業所
コミュニティ

つまり、本来「無保証」とされるオープンソースについて、ある程度の保証をつけるための体制が作られています。

サポートの品質を担保するためにサポート事業者を「認定」するシステムがありますが、オープンでもありますから「それ以外」も存在しています。また、「認定」をするための母体が必要なのでそのための組織が存在しています。

ローカライズやカスタマイズ案件は、「事業所」が行うのが通例です。とは言え毎年のように大きな修正が入るシステムですから、その修正についての意味がわかっていて、どこをいじって良いかいけないかということを把握して、かつシステマティックに行える必要があります。その辺のことがよくわかってないとできません。

「コミュニティ」はもちろん存在し相互扶助の場とはなっていますが、オープンソースにありがち(期待されがち)の「誰でも改良してプルリク出して」というような場ではありません。基本的には「ユーザーコミュニティ」です。

では改良はどうなるかと言えば、「運営母体」が受けつけて、それを開発会社に投げるという体制です。背反する要望の交通整理とか「運営母体」の仕事です。

この体制は名称や組織に変遷はありますが、基本的にはずっと同じです。

まとめ

「医療機関の基幹システム」という性質上、厳密にはオープンソースではありません(OSD準拠のライセンスではありません)。オープンソースライセンスを成立させる必要条件の一つである「無保証」をどうしても許せない人達がいたためです(それがなければGPL相当になるはずでした)。

しかし、できる限りオープンにしつつ、信頼できる基盤を築くということを考えた体制となっています。

個人的にはこの体制がベストであるとは思ってはいません。しかし、システムの規模や期待されること等を考えれば、かなり妥当なところになっていると思っています。

ライセンスがOSD準拠でないのは気に入らないことの一つではありますが、

出資者(日本医師会の会員)を納得させる
基幹業務システムとしての安心感を与える
「IT屋の流儀」を知らない人にもわかってもらう

ことを考えると、「妥協点」としてはしょうがないかなと思っています。

業務システムのオープンソース化の諸問題

業務システムと言えどもソフトウェアですから、オープンソースにすることに何ら制約はありません。オープンソースにすることに勝算のある人はすればいいし、ないと思えばしなければいい。これは他のソフトウェアと同じことです。

とは言え、業務システムには業務システム固有の問題があります。 ORCAの事例をつまみ食いしながら、このあたりの解説をしたいと思います。

どんな環境で生まれるか

一般的なオープンソースソフトウェアは、ある意味「自然発生」します。

「自分の書きやすい言語が欲しいな」と思う人は言語処理系を作りますし、「自分のOSが欲しい」と思う人はOSを書きます。要するに個人的なモチベーションから生まれます。

LinusがLinuxを作ったのは、「それがぼくには楽しかったから」なんだと言われています。細かいところは色々あるようですが(件の本にあります)、要するに個人的なモチベーションです。それが成長して今日の姿となりました。大きなソフトウェアですし社会的な影響は大きいものではありますが、それはあくまでも「結果」がそうなだけで、最初は単なる個人的な遊戯です。

しかし、ある程度以上の規模を持つ業務システムの場合はそうではありません。その多くは「業務で必要となった」とか「ビジネスとして」というような理由で作られます。要するに「仕事」です。

レセコンを趣味や遊戯で作る人はいません。会計システムやERPを趣味や遊戯で作る人はいません。 CMSやノートであれば、趣味や遊戯で作る人もいれば業務で作る人もいるでしょう。

Hieronymusは元々はビジネスにするために作り始めたわけではありませんが、「業務上の必要」で作ったものです。私自身の趣味や遊戯で始めたわけではありませんから、私が興味を失なっても続けられるでしょう。しかし、「必要」がなくなってしまえば、いくら興味を失なわなくても放棄されてしまうでしょう。

これはオリジネータに限った話ではありません。

業務システムはその「業務」と関係がなくなれば「どうでもいいもの」になってしまいます。それはエンドユーザであってもコントリビュータであっても同じです。

現実には多くの「オープンソース業務システム」はそれ自体をビジネスにするために始まります。しばしばレビューや紹介を書いている「オープンソースローコードノーコード」はほぼ全てがそうだと言っても過言ではありません。そこにはそこの問題がないわけではないのですが、それは別途エントリを書いている途中です。とにかく重要なのは、

業務システムのオープンソースは自然発生ではなくて仕事

だということです。

コミュニティの性質

コミュニティの性質も、前節で述べたような環境が関係します。

また、理由はさておき開発者と利用者の比率は大きく違います。極めて雑な表現をすれば、

開発者はほぼいない

ようなコミュニティとなります。生まれる理由を考えれば、自主的に参加する人も期待できるものではありませんし、改良や改造をする人は「仕事」です。「仕事」は通常タダではしないものです。さらに言えば、「業務システムのオープンソース」は「他人のビジネス」ですから、他人のビジネスのために無償奉仕をするような馬鹿はいませんね。

これは多くの人がオープンソースに期待する「多数のコントリビュータによる開発」「誰でもプルリク可」「活発なバグ報告 & 修正」といったことによって「ソースを公開したから勝手に改良される」というようなことがないということです。コミュニティ開発者がいないということは、開発リソースがないということに他なりません。何をするにも「胴元」が頑張らなければなりません。

「不具合の発見」に関しては、利用者の数に連れて増えるのですが、「不具合の修正」は行われません。修正に関しては「胴元」が頑張らなければなりません。そして、その「胴元」は多くの場合開発を始めた組織です。

HieronymusのREADME.mdの最後にごく軽い感じで「プルリク待ってますｗ」と書いています。 ChatGPTやGeminiには「もっとアピールしろ」とか言われるのですが、「どうせいねーよ」という気持ちからこういった書き方のままにしてあります。あったらあったで素直に嬉しいですけど、「期待」はできません。弊社はHieronymus自体がビジネスではないんですけどね。

開発者がいないコミュニティですから、ちょっとオープンソースを齧った利用者だと「なんで開発者は出て来ない？」的な不満を漏らします。気持ちはわかるのですが、「いない」のですから出て来ません。「胴元」はうっかりしたことを公言できないですから、話の流れをつかむ努力や誤解があれば解く努力はしますが、開発に関してはだんまりになります。

これは冒頭の話でもあった「オープンソースにすれば改良のフィードバックが期待できるので、メンテ工数も減る」が無理だということにもなります。結局「胴元」がメンテ工数を何とかすることになります。コストダウンは期待できません。「胴元」のビジネスがしょぼければ、技術サポートの類もしょぼくなります。

ここで「胴元」という表現を使っていますが、これは要するにオリジネータの企業です。その「企業」はそのオープンソースで何らかのビジネスを行っているわけなので、利用者を選別します。つまり、「お客」の声はよく聞きますが、勝手に使っている人達はそれなりの扱いをします。「利用者は公平に扱うべき」ですか？じゃあ何のためにお金を払うのでしょう。あくまでもビジネスなのです。開発リソースもビジネス優先になります。それが商道徳と言うものです。

エンドユーザだけのコミュニティとなると、もう言いたい放題です。時には暴走することもあります。ただ、オープンソースですから暴走しても困りません。顧客が暴れてしまうと困りますが、タダで使う人は利用者ではありますが顧客ではありません。

「体制」のこと

ある程度以上の規模のソフトウェアであれば、様々な「体制」が必要になります。

ソースをいじるのは原則的にオリジネータの企業の開発者だけとなると、全ての要望を聞くことができません。また仮に十分な開発力があったにしても、要望には背反するのがあったりするので、結局全ての要望は聞けなかったりします。つまり、「要望を聞く」ためには取捨選択という「交通整理」が必要となります。この結果に対して肯定否定共にあるでしょうから、開発元の「公式なステートメント」が必要となります。

ある程度以上の規模の業務ソフトウェアとなると、それなりのサポート体制が求められます。

障害が発生したらどうするか、データが破損したらどうするか、バージョンアップのタイミングはどうするか… オープンソースであることと関係なく、業務システムを運用するにはサポートが必須となります。「責任」を取ってもらうことは契約的に難しくとも、せめて安心感くらいは求めたいところです。「自動車保険」くらいのものは必要です。

これは(規模は別としても)前に挙げたORCAの例と同じようなことが必要であるということです。どのように実装するかはケースバイケースですが、必要であることに違いはありません。また、ビジネスとするならば、それは「胴元の責任」で道筋をつけるのが妥当です。ライセンスには無保証と書いてあるにせよ、そこに保証を加えるとビジネスになります。

まとめ

このように、「業務システムのオープンソース」は、同じオープンソースであっても他のものとは随分と様子が異なります。

ですから、肯定的にも否定的にも、「それ以外のオープンソース」の延長上で見たり考えたりすることはできません。文化がまるで異なりますから、オープンソースにすれば諸問題が解決するということはありません。

「標準化」の恩恵についても、デファクトスタンダード的な地位を持つに至らなければ、やってないのと同じです。つまり、それなりに普及しなければ意味がありません。使われない「標準」は単なる仕様の一つでしかないのです。

そういったことを考えると、オープンソース化は銀の弾丸ではありえません。サポートにしろ改修にしろ、あるいは維持の類であっても、全てはお金の問題になってしまうわけですから、プロプライエタリであってもオープンソースであっても、この辺に関しては何ら異なる部分はありません。

他方、オープンソース化で「するべきこと」ははっきり見えて来ます。プロプライエタリでは「金次第」だったものがオープンソースなら「技術の問題」に落とし込めるかも知れません。そういった意味では「やりやすくなる」とは言えます。特に標準化とかそれによるコードの共有は、物事を随分とわかりやすくしてくれます。銀の弾丸にはならなくても、「かなりマシ」なものにはなれます。

Orcinusのこと

Orcinusは「業務システム積め合わせサーバ」と「サポート」のパッケージです。これをこのような形態で販売するということは、こういったことの経験と反省の結果です。

Orcinusについてここではあまり多くを語ることはしませんが、技術的には「業務システムをオープンソース化」することと「ビジネス」を融合させるための工夫の結果です。

最後に

何度も繰り返すことになりますが、自治体システムの諸問題がオープンソース化だけで解決するわけではありません。そして、それは「自治体システム」に限らず、多くの社会システムや業務システムには共通する「難しさ」です。

いや、さらに主語デカにすれば、オープンソース化だけで解決する問題なぞ、何一つありません。オープンソース化はどのようなものであっても、「銀の弾丸」にはなりえません。また、「業務システム」であれば開発やサポートにかかる費用の問題はプロプライエタリと違いはありません。

ただし、オープンソース化することによって問題解決がしやすくなるものも少なくありません。政治やビジネスの問題だったものが、単純な技術の問題に落とし込める可能性は大です。それは問題解決の唯一の方法ではないにせよ、少なくとも一つの解決策ですし、正しい解決方法の一つにはなります。

そして、そういったものをオープンソース化すること、また利用者自身の(共有の)資産とすることも、単なる「やり方」の問題(契約の問題)に過ぎません。利用者自身が開発できなくても、それは何ら問題ではありません。少なくとも可能にした事例がここにあります。事例があるのであれば「できるかな？じゃねぇよやるんだよ」ということです。

そういったことを考えれば、元々の話にあった「オープンソース化でどーんと解決」もおかしければ、「作れるわけない」がないというのもおかしな話です。解決できるできないという議論は不要で、それでどう解決するかという議論をするべきです。オープンソースにするかどうかは、手段の一つに過ぎません。

なおこのエントリは誰でも読めるように、かつ「怒られ」が発生しないようにかなり抽象度を上げていますので、その転はご了承ください。より具体的な話が聞きたいとか、本気で取り組むつもりがあるとかであれば、ブログエントリとして書くことは私の立場では不可能ですから、個別に相談された方が早いと思います(御理解ください)。