ブログ

  • 「横から失礼します」と「アクセス権リクエスト」の共通点——チャット文化と情報のサイロ化を考える

    最近、仕事のコミュニケーションでずっと感じていた「小さなモヤモヤ」の正体が見えてきた。

    きっかけは、チャットでの「横から失礼します」という一言や、ドキュメントの「アクセス権が限定されている」状況。これらは別々の問題に見えて、実は根っこでつながっているのではないか。

    1. 「横から失礼」という見えない壁

    チャットは本来、オープンな広場のようなものだ。面白い話があれば誰でも混ざればいいし、知恵を出し合えばいい。しかし、そこで「横から失礼します」と一言添えないと入れない感覚。これは、会話を「特定の誰かの所有物」と捉えているからこそ生まれる遠慮だ。

    特に女性や若手がこれを多用するのは、マナーを欠いたと見なされた瞬間に「敵認定」されるリスクを本能的に避けているからかもしれない。心理的安全性が高いはずのチャットツールで、わざわざ「防弾チョッキ」を着て会話をしているような、そんなもどかしさを感じる。

    2. GWSが「ファイルサーバー」化する不幸

    Google Workspace(GWS)を使っているのに、いまだにアクセス権がガチガチに管理され、閲覧するたびに「リクエスト」を送らなければならない。これも「横から失礼」と同じ、「情報の私有化」だ。

    本来、共有ドライブにあるべき情報が「誰かのマイドライブ」から共有されていると、情報の出所がわからなくなり、サイロ化が加速する。システムは「共有」を前提に進化しているのに、使う側のマインドが「許可制」の古いファイルサーバー時代のままなのだ。

    3. 「Ubieのカルチャー」を読んで気づいたこと

    先日、Ubie(ユビー)のカルチャーガイドを読んでいて、理想的な組織のあり方を再認識した。情報の透明性を高め、不必要な儀礼を排除する。そこには「敵認定」のない、本質的な「コト」に向き合う姿勢がある。

    現実はそこまで甘くない。管理側の都合や、無意識の自衛策として「。をつけない」工夫や「絵文字選び」に時間を費やす文化がある。

    4. 私は「いつも通り」で行く

    社会や組織の文化をすぐに変えることはできない。だから私は、こう決めている。

    • 「横から失礼」とは言わない。
    • アクセス権がないなら、どうしても必要な時だけ事務的に申請する。
    • 見れないなら見れないで、今ある手札で勝手にやる。

    「許可」を待って足を止めるより、自分のペースで淡々と仕事を進める。それが、このまどろっこしいデジタル社会を生き抜く、私なりの生存戦略だ。

  • 標準化は、なぜいつも「遅れて」やってくるのか

    ― JPQRと標準型電子カルテ、そして医療の現実解 ―

    夕方、スーパーでゆうちょPayが使えなかった。

    エラーメッセージは「バーコードの有効期限が切れています」

    結局その場では理由が分からず、

    「ゆうちょPayのメンテナンスらしい」という説明で処理されたが、

    後で確認すると、ゆうちょPay側には障害もメンテナンスもなかった。

    実際、別の店舗では普通に使えた。

    SEとして見れば、原因はだいたい想像がつく。

    店舗側のPOS、あるいは決済ゲートウェイの一部不具合。

    特定の決済手段だけが落ちるのは、珍しい話ではない。

    それ自体は、正直どうでもいい。

    問題は技術トラブルそのものではなく、説明のされ方だった。

    「わからない」ではなく「誤った説明」

    現場のスタッフが原因を把握できないのは仕方ない。

    だが、「ゆうちょPayのメンテナンス」と断定的に説明されると話は変わる。

    本当は、こう言えば済んだはずだ。

    「当店側の決済システムで、一部の決済手段が不安定になっている可能性があります」

    この一言が言えない。

    あるいは言わせない運用設計になっている。

    この構造に、強烈な既視感があった。

    JPQRという「正しかったが遅すぎた標準」

    少し前、日本には JPQR という共通QR決済仕様があった。

    経産省主導で、QRコード決済を統一しようという試みだ。

    思想は正しかった。

    むしろ、かなり真っ当だった。

    店舗は1つのQRで複数決済に対応 実装の複雑さを減らす 利用者も現場も迷わない

    だが、結果としてJPQRは主役になれなかった。

    理由は単純だ。

    出てくるのが遅すぎた その時点でPayPayが市場を押さえていた 標準は「正しい」より「早い」が勝つ

    標準化は、後出しした瞬間に負けが決まる。

    そして、医療でも同じ構図が始まっている

    いま医療分野では「標準型電子カルテ」という言葉が踊っている。

    掲げられている理念は美しい。

    ベンダーロックインからの脱却、データ互換性の確保、医療DXの基盤整備、FHIR等を前提とした将来接続性

    思想そのものは、否定しようがない。

    JPQRと同じく、理念は100%正しい。

    だが、SEとして、そして医療情報学会に出席している立場から見ると、

    どうしても引っかかる点がある。

    医療の標準化で、本当に守るべき線

    ここで一つ、はっきり言っておきたい。

    医療の場合、内部DBは各社バラバラでいい。

    これは妥協ではない。

    現実を踏まえた設計判断だ。

    診療科ごとの業務差 施設規模の違い 既存資産(データ・運用・教育コスト) ベンダーごとの思想と強み

    内部DBまで標準化しようとすれば、

    移行コストは爆発し 現場は疲弊し 結局、誰も幸せにならない

    これは、医療情報学会に継続的に出ている人ほど共有している感覚だと思う。

    本当に標準化すべきなのは「その先」

    重要なのは、ここだ。

    内部は自由でいい。

    その先、データの出力先を標準にする。

    つまり、

    内部実装:各社自由 外部表現:厳密に標準 接続点(IF):明確な責任分界

    この考え方は、これまで医療情報分野で積み重ねられてきた、

    HL7 FHIR SSMIX2

    と完全に同じ系譜にある。

    標準とは、

    中を揃えることではなく、外に出すときに迷わないことだ。

    JPQRとの決定的な違いと、同じ失敗

    JPQRは、

    表(QR)を共通化しようとした しかし裏(実装・責務分界)が曖昧だった

    一方、医療で取るべき道は逆だ。

    中は触らない 外に出すところだけ縛る 責任の境界を明確にする

    もしここを誤れば、

    医療でもJPQRと同じ未来が待っている。

    看板だけの標準 実装は各社バラバラ しわ寄せは現場と情シスへ

    決済と医療の決定的な違い

    QR決済なら、使えなければ別の手段に逃げられる。

    医療は逃げられない。

    だからこそ、

    表面上は「進んでいるように見える」 問題は静かに蓄積する 最後に疲弊するのは現場

    これは技術の問題ではない。

    制度設計と標準化の哲学の問題だ。

    おわりに

    技術は嘘をつかない。

    だが、制度はときどき嘘をつく。

    「標準」という言葉は、

    現場を楽にするために使われるべきだ。

    もしそれが、

    現場を黙らせるための言葉になったとき、

    その標準化は、すでに失敗している。

  • 断定するAIと、判断を返してくるAI──戦場型の仕事と、距離の取り方についての記録

    最近、仕事の相談を Gemini と ChatGPT の両方にしてみた。
    同じ内容を投げているのに、返ってくる言葉の質がずいぶん違う。

    Geminiの回答は、正直に言えば「当たっている」と感じることが多かった。
    論点は鋭く、構造も見抜いている。ただ、その分、語り口が強い。
    相手に非がある、問題はそこだ、と断定する。
    読んだ瞬間は少し楽になるが、同時に話が終わってしまう感じもあった。

    一方でChatGPTの返答は、意図的なのか偶然なのか、判断をこちらに返してくる。
    構造は整理するが、結論を奪わない。
    「どう思うか」「どこに立つか」を、最後は自分に委ねてくる。

    どちらが正しい、という話ではない。
    ただ、この違いは、今の自分の状態をよく映している気がした。


    戦場型の仕事ができなくなった理由

    地方から東京に生活拠点を移してから、いわゆる「戦時モード」の仕事ができなくなった。
    地方にいた頃は、トラブル対応や修羅場の仕事も普通にこなしていた。
    若かった、というのもあるだろう。

    ただ振り返ると、当時は条件が違っていた。

    • ステークスホルダーが明確
    • 責任は最終的に上が取る
    • プロジェクトには期限がある
    • 終われば日常に戻れる

    つまり「戦えば終わる」仕事だった。

    今は違う。
    有事が常態化し、戦場が畳まれない。
    勝っても次の戦いが始まる。
    これは短距離走ではなく、終わりのない消耗戦だ。

    その環境で戦場型の仕事を続けられる人もいる。
    むしろ、そういう局面で力を発揮し、評価される人もいる。
    それは否定しない。

    ただ、自分はそこに常駐する兵ではない、という感覚がはっきりしてきた。


    学歴偏重・個性重視世代の戦略

    この違和感を整理していく中で、ある構造にも気づいた。

    彼らの世代は、
    「個性を大事に」「自分らしく」と言われて育っている。
    ただし現実の評価では、

    • 個性 = 他者より突出すること
    • 協調や調整は加点されにくい

    という翻訳がなされてきた。

    この環境では、
    有事対応・火消し・強い決断は、とても分かりやすい成果になる。
    戦場は、自分の価値を証明しやすい場所でもある。

    だから戦場に適応した人は強い。
    ただし、その戦略は「平時を作る」こととは別の能力だ。


    断定するAIと、判断を返すAI

    Geminiの断定的な回答は、
    戦場に立っている人には、とても相性がいいと思う。

    「何が悪いか」「誰が問題か」をはっきり示す。
    迷いを切り落とし、前に進ませる。

    一方でChatGPTは、あえて余白を残す。
    構造は示すが、裁かない。
    判断は人に返す。

    どちらが優れている、という話ではない。
    ただ、

    • 判断を委ねたい人
    • 正解をはっきり欲しい人

    • 自分で考え続けたい人
    • 壊れない距離を探している人

    では、相性が違う。

    今の自分には、後者のほうが危険が少なかった、というだけの話だ。


    記録として残す意味

    この文章は、誰かを説得するためのものではない。
    ビューを稼ぐためのものでもない。

    数年後、また似た戦場に立ったとき、
    「自分はこう考えていた」と思い出すためのログだ。

    AIが成長しているのかどうかよりも、
    人間がどこまで判断を委ね、どこを手放さないか。
    その境界線を考え続けるほうが、今は大事な気がしている。

  • いつものローションのはずが、なぜクリームに?― 一般名処方で起きている、患者が気づきにくい変化 ―

    こんな経験をした人はいないでしょうか。

    いつも処方されていた薬を受け取りに行ったら、
    見た目も使用感も、少し違うものが渡された。

    薬剤師さんに聞くと、
    「成分は同じなので問題ありませんよ」と言われる。

    でも、
    使ってみると、なんとなく違う。

    今回は、
    なぜこういうことが起きるのかを、
    患者の立場から、できるだけ分かりやすく書いてみます。


    「一般名処方」が広がっている

    処方箋では、
    薬の商品名ではなく、成分名(一般名)で処方されることが増えています。

    これは、

    • 医療費を抑えるため
    • 同じ成分なら、後発品(ジェネリック)も使えるようにするため

    といった理由があります。

    制度としては、間違っていません


    でも、名前は同じでも「中身の扱い」が変わった

    問題はここからです。

    たとえば、
    これまで「ローション」として出ていた薬が、

    • ある日から、クリームになった
    • チューブに入った白い薬になった

    ということが起きています。

    患者から見ると、

    「同じ薬のはずなのに、なんで?」

    となります。


    実は「ローション」と「クリーム」は、まとめて扱われるようになった

    最近の制度変更で、

    • ローション
    • クリーム

    が、「乳剤性」という一つのグループとして扱われるようになりました。

    このグループで処方されると、

    • どちらを出しても、制度上はOK
    • 成分も効果も同じ扱い

    になります。


    医師は「ローションのつもり」で処方していることが多い

    ここが、患者には見えないポイントです。

    医師は、

    • これまで通り
    • 画面上も変わらない

    ので、

    「いつも通りローションが出るだろう」

    と思って処方していることが多いです。

    実際、
    電子カルテの見た目はほとんど変わっていません。


    調剤薬局では「出しやすい方」が選ばれる

    処方箋を受け取った調剤薬局では、

    • 在庫が安定している
    • 欠品しにくい
    • 管理しやすい

    という理由から、
    クリームが選ばれることが多いのが実情です。

    これは、
    薬局が悪いわけでも、間違っているわけでもありません。

    制度上、問題ない選択なのです。


    結果、調整役は「患者」になる

    ここで起きていることをまとめると、

    • 医師:ローションのつもり
    • 薬局:合理的にクリームを選択
    • 制度:どちらでもOK

    そして、

    👉 「いつもと違う」と気づくのは患者だけ

    という構図になります。

    患者が何も言わなければ、

    • そのままクリーム
    • 「同じ薬です」と説明されて終わり

    になります。


    患者として、どうすればいいか

    残念ですが、現時点で確実なのはこれです。

    • 薬局で
      「前回と同じローションでお願いします」
      と伝える
    • 診察時に
      「ローションと明記してください」
      と一言お願いする

    制度の変更を、
    患者側が少し知っておく必要があるのが現実です。


    おわりに

    これは、誰かが悪い話ではありません。

    • 制度は合理的
    • 医師も薬剤師もルール通り
    • でも、患者体験だけが置き去りになる

    そんな構造が、今の医療にはあります。

    もし、

    「あれ?いつもと違うな」

    と感じたら、
    それは気のせいではないかもしれません。

    この記録が、
    同じ違和感を感じた人の参考になれば幸いです。

  • 寝酒はなぜダメなのか、CPAPを使って分かったこと

    CPAP治療を始めてから、
    睡眠と体調を少し丁寧に観察するようになった。

    いわゆる「健康に気をつけよう」という話ではなく、
    条件を変えると、体がどう反応するのか
    淡々と見る、という感じだ。

    その中で、はっきりしてきたことの一つが
    お酒との相性だった。


    寝酒は、やはり良くない

    結論から言うと、
    寝酒はやはり良くない

    量が少なくても、種類を選んでも、
    「寝る直前に飲む」という条件が入ると、

    • 再入眠しづらい
    • 夜中に覚醒が増える
    • 朝のスッキリ感が違う

    という形で、体に出る。

    CPAPのデータを見なくても、
    体感として分かるレベルだ。


    量が少なくても、影響は出る

    今回飲んだのは、
    ワインを100mLずつ、赤と白を1杯ずつ。

    世間的には「たいした量ではない」かもしれない。
    でも、睡眠に関して言えば、

    量よりも、種類とタイミングの影響が大きい

    と感じた。

    特にワインは、
    アルコール以外の成分も多く、
    入眠は助けても、後半の睡眠が乱れやすい。


    焼酎・日本酒のほうが、まだ読みやすい

    いろいろ試した結果、
    自分の場合は、

    • 焼酎
    • 日本酒(少量)

    のほうが、体の反応が読みやすい。

    もちろん「たくさん飲める」という意味ではない。
    あくまで、

    • 夕方まで
    • 少量
    • 単一種類

    という条件付きだ。


    ビールは、今はほとんど飲まない

    ビールは、
    炭酸と量の問題もあり、
    今の自分の睡眠には合わなくなった。

    夏の暑い日に少し、
    というくらいがちょうどいい。


    分かったのは「酒をやめろ」ではない

    この話の結論は、
    「酒をやめたほうがいい」という道徳論ではない。

    自分の体にとって、どの条件がどう効くかを知ること

    それだけだ。

    CPAPを使っていると、
    睡眠が「感覚」だけでなく、
    「条件の組み合わせ」として見えてくる。

    それは意外と、
    日常生活を窮屈にするものではなく、
    むしろ自由度を上げてくれる。


    おわりに

    今は、

    • 寝酒はしない
    • 飲むなら早めに、少量
    • 飲んだ日は評価を割り引く

    このくらいの距離感が、ちょうどいい。

    こういう小さな調整の積み重ねが、
    長く治療を続けるコツなのだと思う。

  • 在宅医療と「話が通じない」ストレスについて考えたこと

    CPAPを使っていて、最近ひとつ小さなトラブルがあった。
    ヒーターチューブから温かい空気が来なくなったように感じたのだ。

    設定や使い方の問題ではなさそうだったので、メーカーのコールセンターに問い合わせた。
    返ってきたのは「冬場は室温+数度程度の送気になる」「室温が低ければ冷たく感じるのは仕様」という説明だった。

    それ自体は、間違った説明ではない。
    ただ、私が知りたかったのはそこではなかった。

    問題にしたかったのは
    以前と比べて挙動が変わっているかどうか
    機械的な不具合や劣化の可能性があるのか
    点検や切り分けをどうすればいいのか
    という点だった。

    しかし一次窓口では、
    ・通電をユーザー側で確認する手段はない
    ・点検方法も基本的にはない
    ・判断できなければ交換で様子を見る
    というところまでしか話が進まなかった。

    結果的にはヒーターチューブ交換になり、対応としては妥当な着地だったと思う。
    ただ、その過程で残ったのは、機械トラブルそのものよりも
    「話が通じない」ことへの疲労感だった。


    「話が通じない」ストレスの正体

    この感覚は、特定の人や地域の問題ではないと思っている。
    正体はもっと構造的なものだ。

    • 情報や知識に非対称がある
    • 一方は切り分けをしたい
    • もう一方はフローに沿って対応する

    このズレがあると、
    質問は仕様説明に吸収され、
    「変化」や「違和感」は取り扱われにくくなる。

    これはどの業界でも起きるが、
    医療機器、とくに在宅医療では負担がそのまま患者に返ってくる。


    在宅医療が抱える構造的な問題

    国は在宅医療を推進している。
    病床削減、医療費抑制という文脈では理解できる。

    しかし現実には、

    • 地域で機器を点検・切り分けできる体制は乏しい
    • 一次対応はコールセンターに集約されている
    • 技術的な判断は「交換して様子見」に寄りがち

    つまり
    「場所」だけが在宅化され、
    「支援」や「責任」は在宅化されていない

    結果として、

    • 分からない患者は声を上げられず
    • 分かる患者ほどストレスを抱える

    という歪みが生まれている。


    本来あってほしい姿

    理想論ではなく、必要条件として、

    • 地域単位で対応できる在宅医療機器サポート
    • 機器に詳しい技術者が関与できる仕組み
    • 病院・メーカー・業者の責任分界が見える運用

    があって初めて、
    在宅医療は「安心して任せられる医療」になるはずだ。


    個人の体験から見えたこと

    今回の件で感じたのは、怒りというより徒労感だった。
    機械は交換すれば直るかもしれない。
    でも構造は簡単には直らない。

    在宅医療を推進するなら、
    患者が一人で抱え込まなくていい設計まで含めて考えてほしい。

    そうでなければ、
    「便利になったはずの在宅医療」は、
    静かに患者の負担を増やし続けるだけだと思う。

  • 今日、医療の構造を体で理解した一日

    今日は、ただの通院の日ではなかった。

    朝から夜まで、いくつもの医療機関を行き来しながら、

    「医療はこうやって回っているのか」という構造を、

    頭ではなく、体で理解した一日だった。

    きっかけは、ひとつの疑問だった

    発端は単純だった。

    自分が慢性的に抱えている喉の違和感と、

    血圧の薬(ARB)との関係が、本当に無関係なのか。

    ARBを少し休薬してみると、

    喉の調子がわずかに良くなった気がした。

    一方で、血圧は安定しているものの、上昇傾向も見える。

    「血圧管理は必要だ。でも、薬の相性は考え直す余地があるのではないか」

    この疑問を整理するために、

    今日は耳鼻科と内科、両方を受診することにした。

    大病院の耳鼻科で感じた“壁”

    最初に向かったのは、総合病院の耳鼻咽喉科。

    事前に、経緯をまとめたメモを書いて持参した。

    医師は忙しい。

    それは分かっている。

    だからこそ、診察前に目を通してもらえたら、

    無駄な説明を省けると思った。

    だが、現実はそう簡単ではなかった。

    受付では

    「患者さんからのメモはスキャンできない」

    「看護師に相談します」

    と待たされ、結局あきらめることになった。

    制度としては正しい。

    でも、配慮としては噛み合わない。

    ここで感じたのは、

    誰かが悪いという話ではなく、

    大病院は“例外を許容しない構造”で動いているという事実だった。

    それでも診察は、医学的には妥当だった

    耳鼻科の診察では、内視鏡検査を受けた。

    「急性の耳鼻科的問題は否定的」

    フォローは4か月後。

    この判断自体は、医学的に妥当だと思った。

    今すぐ何かをする必要はない。

    ただ、環境や背景を調整しながら経過を見る段階だ。

    ここで一つ、大事な前提がそろった。

    少なくとも、喉の構造的な問題が主因ではないという確認だ。

    紙一枚で、医療の風景が変わる

    午後、内科の診療所へ向かった。

    こちらは紙カルテの診療所。

    耳鼻科での結果と、

    ARB休薬後の経過をまとめたメモを受付で渡した。

    正直、

    「受け取ってもらえないかもしれない」

    とも思っていた。

    でも、あっさり受け取ってもらえた。

    診察室に入ると、

    医師はすでに状況を把握していた。

    説明を一からする必要はなかった。

    話は最初から「判断の段階」に入った。

    この瞬間、はっきり分かった。

    紙カルテか電子カルテか、ではない。

    “情報がどう流れるか”が、診療の質を左右する。

    薬を変える、という合意

    医師から聞かれた。

    「なぜ以前、Ca拮抗薬からARBに変えたんですか?」

    正直に答えた。

    「前の先生が、こっちの方が効くと言われて変更しました」

    医師は少し考え込むように「うーん」と言った。

    否定ではない。

    再評価だ。

    そして、

    血圧管理は継続しつつ、

    薬の変更を行う方針になった。

    ここで、最初に自分が望んでいた形に、ようやく辿り着いた。

    一方的に指示されるのでもなく、

    感情的に訴えるのでもなく、

    情報を共有した上で、一緒に決める。

    これが、医療系の教科書によく書いてあるEBM+SDMなのだと思う。

    医療は、人ではなく構造で決まる

    今日一日を振り返って、

    医師が冷たかったわけでも、

    受付が不親切だったわけでもないと感じている。

    違いを生んだのは、構造だった。

    大病院か診療所か 電子カルテか紙カルテか 処理の場か、判断の場か

    同じ医療でも、設計が違えば体験はまったく変わる。

    そして、

    「患者と一緒に治療を考える医療」は、

    時間と余白がある場でないと成立しにくい。

    これは、誰かの怠慢ではない。

    今の医療が抱えている静かな歪みだと思う。

    今日という一日

    今日は、正直、疲れた。

    体調のこと、医療のこと、構造のこと。

    考えることが多すぎた。

    でも同時に、

    無駄な一日ではなかったとも思う。

    自分の体のことを、

    自分の言葉で整理し、

    医療とどう向き合うかを、

    少しだけ前に進めた一日だった。

    こういう一日が積み重なって、

    医療は変わるのかもしれないし、

    変わらないのかもしれない。

    ただ、少なくとも今日は、

    「考えることをやめなかった」。

    それだけで、十分だった気がする。

  • 診療所で「診られない」と言われた日

    ――医療と患者のすれ違いについて考えたこと

    今日は、耳鼻咽喉科の診療所を受診した。

    喉の違和感で、これまで地域の基幹病院に一年ほど通ってきた。
    異常が見つかり、経過を追い、いったん消失したことから、
    「今後は診療所でフォローアップでよい」という判断になり、紹介状を書いてもらった。

    その流れで診療所を受診し、今後は継続的にフォローアップしてもらう予定だった。
    しかし、2回目の診察(1か月後)で再度異常が見つかり、
    総合病院への紹介状を書いてもらうことになった。

    改めて総合病院を受診したところ、
    「これまで見ていた症状の再燃であり、今後は診療所でフォローアップでよい」
    との判断となり、再び診療所への紹介状が書かれた。
    そして今日、その診療所を再受診した。

    結論から言うと、フォローアップは引き受けてもらえなかった。
    「うちでは生検の設備がない」「フォローはできない」「もう一度総合病院で診てもらった方がいい」
    そういう説明だった。

    こちらとしては、治療を求めていたわけでも、生検を強く希望していたわけでもない。
    ファイバーで定期的に観察してもらい、変化があれば再度病院に戻る。
    その程度のフォローアップを想定していた。

    しかし、話は噛み合わなかった。

    ファイバーで見てほしいと伝えると「患者さんの負担になる」と言われ、
    生検は外注という形もあるのでは、と話すと「できない」と返された。
    次第に、説明ではなく押し切るような空気になり、こちらも感情的になりかけた。

    結局、その日の所見を紹介状に書いてもらうことになり、ファイバーは実施された。
    説明も受け、自分のスマホに記録用として写真も撮らせてもらった。
    それで診察は終わった。

    その後も、受付や看護師とのやり取りが続いた。
    紹介状の宛名、会計の扱い、紹介状の受け取り時に再診扱いになるかどうか。
    ひとつひとつは小さなことだが、全体としてどこかちぐはぐで、噛み合わない感覚が残った。

    特に印象に残ったのは、診察が終わった後のタイミングで、「善意の確認」があったことだ。
    医療の場では、ときに「善意の確認」が
    本人にとっては負担になることがある。
    この日も、そう感じる場面があった。


    聞くこと自体が悪いわけではない。
    ただ、そのタイミングで、その文脈で聞かれる理由が分からず、
    答えることで自分に不利になる予感だけがして、答えなかった。

    14時に来院し、15時前には会計を終えて帰宅した。
    時間にすれば短い出来事だ。
    でも、疲労感はかなり大きかった。


    帰宅してから、今日のやり取りを振り返り、考えた。

    まず気づいたのは、「耳鼻咽喉科」という標榜と、実際の診療内容のズレだった。
    多くの診療所で日常的に診ているのは、耳と鼻が中心だ。
    喉といっても、口を開けて扁桃や咽頭を見るところまでが大半で、
    喉頭ファイバーで声帯や下咽頭を継続的にフォローする体制は、実はかなり限られている。ただファイバースコープの設備はある。

    「耳鼻咽喉科なら喉も診られる」と患者は思う。
    でも現実には、「喉頭を日常的に診る設計」になっていない診療所も多い。

    そう考えると、今回の出来事は、誰か一人が悪いという話ではないのかもしれない。

    医師は、自分の引き受けられる責任の範囲を守ろうとした。
    看護師や受付スタッフも、それぞれの役割の中で対応していた。
    ただ、その結果として、患者である自分には「なぜそうなるのか」が十分に説明されず、
    「診られない」という結論だけが残った。

    ここで、もう一つの気づきがあった。

    医療者は、意識していようがいまいが、患者をコントロールする方向に動く。
    それは悪意ではなく、命と健康を扱う以上、リスクを管理しようとする自然な動きだと思う。

    ただ、その構造が見えないまま体験すると、人は簡単に医療不信に傾く。
    なぜ断られたのか分からない。
    なぜ話が噛み合わないのか分からない。
    その積み重ねが、「医師は信用できない」という感情に変わっていく。

    医療の知識がない人ほど、そうなりやすいだろう。

    自分自身は、今回の体験で医療不信になったわけではない。
    むしろ、医療の役割分担や限界を、あらためて理解した気がしている。

    診療所は、軽症で定型的な対応に最適化された場所だ。
    薬をもらう、短期で完結する相談をする。
    そういう使い方が合っている。

    一方で、判断がグレーな状態を長期にフォローする医療は、
    最初からそれを引き受ける覚悟と設計のある場所を選ばないと、
    患者も医療者も疲弊する。

    最近、工学部出身の医師や、医師免許を持って起業する人が増えているのも、
    こうした構造的な限界を内側から感じている人が増えた結果なのだと思う。
    臨床だけでは変えられないものを、別のレイヤーから変えようとしているのだろう。

    医師免許が、週に一度の非常勤で生活を支えられるほど強いセーフティネットになっていることも、
    医療を支えている一方で、歪みを生んでいる面がある。
    これは個人の善悪ではなく、制度の話だ。

    結局のところ、今日感じた違和感は、
    「医師が悪い」という話でも、「自分が悪い」という話でもない。

    医療の設計と、患者の期待が、ずれていただけだ。

    そう理解したことで、少し楽になった。

    これからは、医療に多くを期待しすぎず、
    役割を見極めて、必要なときに必要な場所を使う。
    それでいいのだと思う。

    今日は嫌なことも多かったが、
    吐き出して、考えて、ここで一区切りつけたい。

  • なぜ日本人は英語を話せないのか?話さないのか?

    英語を大人になって再び学んでみてふと思ったことがある。それを書き留めてみようと思う

    ──能力ではなく「言語文化」の問題

    日本人は英語が苦手だ、とよく言われる。

    学校教育が悪い、発音が難しい、恥ずかしがり屋だから──理由はいくつも挙げられる。

    けれど、少し距離を取って眺めてみると、これは能力の問題ではなく、言語文化の設計差だと感じる。

    日本語は「感覚共有型」の言語

    日本語は、とても高度な言語だ。

    主語を省略できる 結論を曖昧にできる 行間を読む・読ませることが前提 空気や文脈が意味を補完する

    「ちょっと不思議だなと思う」

    この一言で、驚くほど多くの情報が共有できる。

    日本社会では、これは成熟したコミュニケーションとして機能してきた。

    英語は「言語化前提」の言語

    一方、英語(特にビジネス英語)は構造が違う。

    主語と立場を明確にする What / Why / How を言語化する 言わないことは存在しない 曖昧さは理解不足や不誠実と受け取られやすい

    英語圏では、

    言語化できない意見は、存在しない意見

    として扱われることが多い。

    日本人は「話せない」のではなく「話さない」

    多くの日本人は、英語を

    読める 聞ける 文法もある程度分かる

    それでも話さない。

    それは語学力の不足ではなく、

    「言い切ることへの心理的ブレーキ」が強く働くからだ。

    日本語では、

    断定しないことが配慮 余白を残すことが知性 空気を壊さないことが美徳

    この美徳が、英語では足枷になる。

    平成生まれは、なぜ違うのか

    近年、若い世代は比較的英語に抵抗が少ないと言われる。

    平成後半〜令和世代は、

    SNSで常に言語化している 自分の立場を明示する訓練を受けている 正解より「自分の意見」を求められてきた 多文化・多価値観に慣れている

    つまり、

    英語的思考様式を、日本語の中で先に身につけている。

    だから英語への移行がスムーズなのだろう。

    どちらが優れている、ではない

    昭和世代は、

    日本語では非常に高度 英語では沈黙しがち

    平成後期以降の世代は、

    日本語では雑に見えることもある 英語では積極的

    これは優劣ではない。

    最適化されている環境が違うだけだ。

    大切なのは「切り替え」

    日本では、感覚で語ることが強い。

    海外では、言語化しないと始まらない。

    必要なのは、どちらかを捨てることではなく、

    相手の文化に合わせてモードを切り替えること。

    感覚で置く言葉も、

    論理で説明する言葉も、

    どちらも本来は武器になる。

    結論

    日本人が英語を話せないのは、能力不足ではない。

    日本語があまりにも高度な「空気共有言語」だからだ。

    そして、

    英語は勇気の問題ではなく、

    思考と言語の設計を切り替える技術の問題なのだと思う。

    これは語学論ではなく、文化論として考えた方が、ずっと腑に落ちる。

  • openDolphin PoCとORCA連携を試みて分かったこと

    ― AWS/Ubuntu 22.04/CLAIMの壁 ―

    はじめに

    オープンソース電子カルテ openDolphin を用いた PoC(概念実証)として、AWS上に構築した ORCA との連携(CLAIM接続)を試みた。

    結論から言えば、
    今回の構成では openDolphin と ORCA の連携は見送りとした。

    ただしこれは「失敗」ではなく、
    技術的に確認すべき点をすべて確認した上での判断である。

    本記事は、
    その過程を 記録として整理したものであり、
    同様の検証を行う人への参考、
    また医療IT理解のための資料として残すことを目的としている。


    検証の前提条件

    openDolphin 側

    • Windows Server 2022
    • サーバ/クライアント同居構成
    • PoC用途(本番想定なし)

    ORCA 側

    • AWS EC2
    • Ubuntu 22.04 LTS(Jammy)
    • ORCA公式手順書(Jammy版)に従って構築
    • 診療データは自分自身のテストデータのみ

    目標

    • openDolphin と ORCA を CLAIM(8220/8221)で疎通確認
    • 本格連携ではなく「疎通レベル」での確認

    まず結論

    • AWS上の Jammy ORCA では、CLAIM受信が有効になっていなかった
    • openDolphin は実質的に CLAIM前提設計
    • 今回の ORCA 構成では、後付けで CLAIM を有効化するのはリスクが高い
    • よって openDolphin PoC は ORCA 非連携で進める という判断に至った

    実際に起きたこと(技術的事実)

    CLAIM疎通確認

    nc -vz <ORCA_PRIVATE_IP> 8221
    

    結果:

    Connection refused
    
    • ネットワーク到達性はある
    • しかし ORCA 側で 8221 が LISTEN していない

    CLAIM設定ファイルの不存在

    ls /etc/jma-receipt/claim/
    

    結果:

    No such file or directory
    
    • 従来の ORCA(CLAIM前提構成)で存在するはずのディレクトリがない

    jma-receipt パッケージの不在

    apt-cache policy jma-receipt
    

    結果:

    パッケージ jma-receipt が見つかりません
    
    • 旧来の CLAIM 前提 ORCA パッケージ体系ではなかったことが確定(自分のローカルPCで構築したVMのORCAとは違った)

    「同じ Ubuntu 22.04 なのに違う」問題

    ローカル VM 環境では、

    • Ubuntu 22.04 Jammy
    • ORCA × CLAIM
    • RSBASE 連携

    が成立している。

    一方、AWS では成立しない。

    違いは OSのバージョンではなかった


    違いの正体:Ubuntuの「育ち方」

    整理すると、差分は以下だった。

    • ローカルVM
      • ORCA推奨の Ubuntu インストーラ
      • ORCAが暗黙に前提としている環境が揃っている
    • AWS
      • AWS公式 Ubuntu AMI
      • クラウド最適化・最小構成
      • ORCA側が想定していない初期状態

    加えて、
    ORCAから公表されているが、「CLAIM非前提」の構成が標準になっているという背景もあるのだろうか。


    CLAIMを無理に有効化しなかった理由

    理論上は、

    • 旧来の ORCA リポジトリを追加
    • CLAIM関連パッケージを導入

    という道も考えられる。

    しかし今回は以下の理由から見送った。

    • ORCAを壊すリスクが高い
    • PoC環境とはいえ、検証対象が変質する
    • 「できるかどうか」ではなく「判断材料を集める」段階だった

    openDolphin PoC のスコープ再定義

    今回の判断を踏まえ、
    openDolphin PoC のスコープを以下に再定義した。

    In-Scope

    • 受付(来院の表現)
    • 診療録作成
    • 院内オーダ入力
    • 基本マスタの考え方

    Out-of-Scope

    • ORCA連携(会計・請求)
    • RSBASE連携(画像・検査結果)
    • 実運用・本番想定

    このPoCの位置づけ

    今回の検証は、

    • openDolphin を「導入する/しない」を決めるためではなく、電子カルテとは何か医療情報システムはどう分業されているか、を理解するための PoC である

    という位置づけに切り替えた。

    特に私が所属する法人では、

    • 「電子カルテ=全部入りシステム」
    • 「ORCA=電子カルテ」

    といった誤解が多く、
    このPoCは 勉強教材として非常に有効だと判断している。


    次のステップ

    • openDolphin PoC を 教育用途として活用
    • 電子カルテ/レセコン/検査/画像の役割分担を整理
    • 本格開発は openEHR を前提に再検討

    CLAIM連携については、
    「今やらない」だけであり、
    「不要」と判断したわけではない。


    おわりに

    今回の検証で一番大きかったのは、

    できる/できないを切り分け、
    無理に進まない判断ができたこと

    だと思っている。

    医療ITは、
    技術そのもの以上に 前提条件と設計思想が支配的だ。

    この記録が、
    同じ場所で悩む誰かの参考になれば幸いである。