地域医療ネットワークと過疎対策

とある里の診療所

　先日、地域医療ネットワークを押し出している「とある県」の「とある町」に出張してきました。今回の出張の目的は、その地域の「かかりつけ診療所」に電子カルテを導入し、県の中核病院とカルテを共有するという、今時のお仕事でした。これにより、中核病院で行った画像診断やら検査結果を、山の中にある診療所でもリアルタイムで共有することができるため、医師不足が著しいと言われる過疎地での医療にITが貢献するという、お手本のような導入事例でした。

　さて、実際にその診療所伺ったのですが、交通の便の惨さに戦慄を覚えました。東京から新幹線でその県庁所在市に降り立った後、そこから車で約１時間３０分かかるわけですが、曲がりくねる道に車酔いすることこの上なし。さらに、途中何度か１車線になってしまうため、ダンプカーが対抗して来た時には、１００mほどバックして道を譲るということが何度となくありました。
　途中、山の上からみる風景は非常に美しく、仕事に来てるのか、ドライブしにきたのか分からなくなるほど。これが日本のふるさとってやつですね。まー、もう一度ドライブしたいかと言えば。。ないかなと。

過疎という実感

　車酔いで吐きそうになった状態で、作ってきたプログラムをサーバに入れて、電源を入れてみて、ちゃんと中核病院とつながることを確認して計１０分。何もすることが無くなりました。ではと、診療所の周りを色々と徘徊してみたら、過疎という事実をまざまざと見せつけられました。

　ちゃんと駅はあるのですが、１時間に１〜２本の電車から降りる人が見受けられない。駅の周りでご飯を食べたのですが、お客さんは私だけ。診療所には外来患者さんが１日あたり２０人ほどで、多分先生が診療所に来るためのタクシー代ぐらいしか、診療報酬は出ないかと。外来に来られた老夫婦が受付していたのですが、両方ともどうやら軽い認知症らしく、受付に手間取ること。地域の特産品がこの町の経済活動を支えているようですが、道を歩く高齢の方のスピードはかなりのろく、１日の半分以上を畑までの往復に使っているのではないかと。これをスローライフと捉えていいのだろうか？

　もう町全体から感じるのは高齢化による若者不足の実態。人口８０００人程度のこの町は、１年あたり約２００人ずつ減少しており（１月あたり２０人程度の高齢者の方が亡くなっている。）、そして、その人口のほとんどが７０歳以上の高齢者で占められているという実態があります。１０年後にはこのまま行くと人口は半分以下になるでしょう。高齢化どころかもう町自体が消滅の危機に瀕していると言えます。

　そう考えると、次々と疑問がわいてくる訳です。国からの補助金によるこの遠隔医療に意味があったのか？町自体、コミュニティー自体がもう既に終末期を迎えているのではないか？幾ばくかの補助金による地域医療の拡充が、たかだか５年程度の延命措置に消えただけじゃないか？と。

過疎対策よりも見切ること

　２３年度の国の税収（詳しくは税収等）は４０．９兆円程度です。そして、歳出で一番を占める医療費は３７兆円にまで増えています。さらに言うと、７０歳以上の高齢者に対する医療費はそのうち１７兆円ほどです。未だに、日本では高齢者に対する負担を増やすという選択が出来ない状況です（選挙あるし）。そのような中で、医療費を減らす取り組みとして、無駄な延命治療よりも、より自然な終末期医療と向き合うやり方が有効だと考えたりもします。

　さて、過疎地域は日本全国に蔓延しています。過疎地ではみな医師が不足していると言われますが、介護サービスも不足しています。ですが、最終的には所帯を持つ若者が介護サービスを一生の仕事にするとは思えません。そうなると、ある一定以上の経済活動がその地域に根付くことが最低限必要となるのですが、全国にある全ての過疎地域で新たな経済活動が生まれるとは到底思えません。国が補助金をいくら流したところで、地域が再生するケースというのは稀かと。やはりどこかのタイミングで、過疎末期の町に対して見切ることが重要になるのではないかと思います。より自然に町の終末期を迎えさせることが必要となるように。。。

不平等な都市開発（コンパクトシティ）

　まず、全国一律の平等な行政サービスを一刻も早く止めることが重要です。山の中の過疎地で高齢者だけのコミュニティを作るのは非常に厳しいものがあります。それよりも、湾岸部のいわゆる中核都市に高齢者を集めて生活をしてもらえる、高齢者向けコンパクトシティを作るべきです。
　過疎地にある住居は、そのまま作業時の休憩地として使い、朝４時に出発する１日往復２本のバスに乗って畑を耕しに行くのです。そして、夜８時には都市の集合住宅でゆっくり温泉でも入りながら眠ってもらう方がよいかと。医療や行政サービスは都市に集中したら、町役場を田舎に立てるより全然コストが安くなります。そして、老齢の人たちがそのコミュニティの中で恋愛でもしてもらえたら、日本の消費も増えること間違いないです。

　過疎地のお客様で止まったシステムの復旧を待っている中で、この文章を書いている心境を少しは皆も考えるがいいさ。ソ○トバ○クやら、WiM○Xやら、その他ネットワーク会社、もう少し過疎地で無線を張れ、マジで。

なぜに医療の情報化が進まないか？

　とあるお役所の人と、「なぜに医療の情報化が進まないか？」という議題を検討する場があったので、その中での話をまとめてみる。だって、外は雨なので。

レセプト請求の電子化の遅れ

　医療ＩＴが日本は後進国になりつつあります。お隣の韓国では医療請求はほぼ完全オンライン化されており、日本がやはり遅れているという状況にあります。この遅れの理由として、やはり計算の単純さがあるわけで、韓国の医療請求はほぼ足し算と引き算だけで構成されているということ。

　日本では長年、医師会と厚生労働省との綱引きの中で、医療改定が行われており、〇〇％減算とかが当たり前になっています。割り算があると、「足し算」と「割り算」の順番が変わることで計算結果が変わるのですから、計算順序まで法定化しないと行けなくなる訳です。実際にはそこまで法定化されていないため、医科点数表の解釈がどんどんと分厚くなってしまうという現実があるわけです。高額療養費の高所得者の「総医療費の１％」なんていうのも、「適正な負担」と「莫大な医療事務の現場のコスト」が見合っているのか疑問に思います。（しかし、難しい計算があればあるほど、医療事務という雇用が守られ、ニチイやユーキャンなどの医療事務学習の産業が存続しているという現実もありますが。。。）

診療情報の情報化の遅れ

　医療請求に関する情報化でも日本は遅れていますが、診療の情報化（ＥＨＲ）も負けず劣らず普及していません。電子カルテを日本で導入してみると、医療情報課の担当者さんが電子カルテベンダーに文句を言います。「電子カルテにしたのに、役立つ情報がとれない」。実はこれ、電子カルテが悪い訳ではなくって、「医師のカルテの書き方が今まで全く標準化されていなかった」ということが、電子カルテを使ってみて初めて分かったということ。

　例えば、同じ血圧でも「血圧（上）」、「収縮期血圧」、「最高血圧」と、医師や病院によってデータを１元的に取り扱うかどうかが違ってきます。そこが診療の情報化を進めるにあたり、非常に難しいところになっている。現在「オントロジー工学」や「セマンティックWEB技術」を使った文章解析技術で解決を図ることが進められていますが、その前に医大の履修科目に「カルテの書き方」を必須項目とすると、診療情報の二次利用が大きく進むはずです。

　今の日本におけるカルテというのは、「診療報酬で査定されないためのカルテ」になりがちです。本来の「診療を良くするためのカルテ」を普及するためには、カルテ記載の定型化、及び標準化が重要になるでしょう。

国民背番号制導入の必要性

　診療を情報化する上で最重要なのが国民背番号制の導入です。医療機関で診療情報をしっかり分析したところで、その診療によってどうなかったかという結果の情報が得られません。人間死ぬ時が病院の中だけではありません。何時、何処で、どのように死んだかが分かるためには、死亡を取り扱う住基ネットとの連携が必要となります。

　現在、マイナンバー制度が国会審議されており、法案成立は全く見えてこない状況です。しかし、このマイナンバー制度は、総務省の管轄であり、厚生労働省が進める保険証番号との連携がされない見込みです（霞ヶ関の縄張り争いが見え隠れします）。マイナンバー制度を総務省と厚生労働省が一体となって進めて、レセプト請求データと住基ネットを早期に統合されないと、ＥＢＭ（エビデンスに基づく医療）の実現は難しいと言えます。（医師会団体が国民背番号制度に反対しているという事実は非常に興味深い。。。そんなに税金がry...）

JavaからJNI経由で共有メモリ for Win

javaからJNIで共有メモリを弄りたい。
そんな、ひと夏の衝動にかられて、JNIで共有メモリをアクセスしてみました。
https://github.com/tkymism/sharedmem

今回も流れるインタフェースを駆使して、こんな感じのインタフェースにしてみた訳です。

---

---

使い方
(1)VisualStudioでdll生成

•   構成プロパティ➡C/C++-➡全般➡追加のインクルードディレクトリ
• [jdk_dir]\include;
• [jdk_dir]\include\win32;
• [git_dir]\sharedmem\sharedmem-win\include

•   構成プロパティ➡C/C++➡コード生成➡ランタイムライブラリ
• マルチスレッド (/MT)

•  構成プロパティ➡リンカー➡全般➡追加のライブラリディレクトリ
• [jdk_dir]\lib;

•  構成プロパティ➡リンカー➡入力➡追加の依存ファイル
• jvm.lib;

(2)maven installでjar生成

---

解説
"hogehoge"という名前で共有メモリに書き込んでいます。0~99byteはヘッダーとして使用して、100byte目以降を実態のファイルとしてallocateする図です。
locateでは0~99byte目にアクセスしてByteBuffer(Direct)で共有メモリに直接attachします。 100byte目以降(locate)にもdataを突っ込んで、そしてreleaseする訳です。
やはり、共有メモリに対してアクセスするためには排他制御が必要です。今回は読み込みと書き込み両方でMutexを使って排他制御を行っています。
このプログラムではMutexの名前には"<共有メモリ名>+.lock"で生成します。

SharedMemoryRepository#readonly(String name)	排他する
SharedMemoryRepository#writable(String name)	排他する
SharedMemoryRepository#copy(String name)	排他しない

WindowsAPIのOpenFileMappingとMapViewOfFileでは読み込みモードが一緒じゃないとアクセス権でエラーが出ました。なので、以下のようにopenした段階でモードを決定してmappingのモードと同じになるようにしています。 ByteBufferは非常に便利なんですが、共有メモリにjavaのObjectをserializedしたbyte配列を格納したいと思い立ったため、こんなインタフェースも追加してみました。

---

課題
NativeAPIを触るとやはりallocateの煩わしさにいらだちます。allocateする際にbyte列を指定するのですが、CreateFileMapping関数ではサイズを64bitで指定できるのですが、32bitづつ分けて設定してくれという大胆な関数でした。 そんな変態的な仕様に対して、javaからはlong(8byte)をint(4byte)に分割して状態でJNIに引き渡すようにしてみた訳ですが、本当に正しいかが疑問に残ります。 ほかにも色々課題はあるのですが、とりあえずこれでcommit.

---

共有メモリを使う動機
私の部署で開発しているパッケージは基本的にjava(Swing)で開発している訳ですが、既存製品から移行し続ける経緯もあり、未だに帳票処理やバッチ処理ではCOBOLで開発しています。旧モデルの保守性を考えると、ビジネスロジック(COBOL)の資産がそのまま残ってしまったということです。
さて、javaからCOBOLを呼び出す際にはJava->JNI(C)->COBOLという破廉恥な連携が行われている訳ですが、たまにヘタクソなコボラーさんが、添字エラーを起こしちゃうようなプログラムを作っちゃうと、javaごとプロセスが死んでしまうという大惨事が引き起こされます。
なので、COBOLの処理をなんとかして別プロセスで動作させたいという動機が生まれた訳です。
でも、javaで抱えるメモリは共有したい！ということで、Google App EngineなんかであるようなMemcacheを、Windowsの共有メモリを使って実現したいということになったわけです。

JNIでヒープ外を参照

JNIを使ってヒープ外のメモリにアクセスしていたわけで。そしたら、実装方法により性能が全然違ったのでメモ。

ByteBufferでアクセス

ByteBufferクラスを使ってアクセスするのが最高性能が出ました。以下に実装例を記載。

Java
C++(MSVC)

---

byte[]でアクセス

ByteBufferより倍の性能かかった実装例で、byte[]を引き渡す方式。C側でJavaの配列操作をするのに時間がかかるようです。
Java
C++(MSVC)

---

1 byteずつアクセス

最初はbyte数分、Java側でループを行って1byteずつ参照する方式。JNIのオーバヘッドが大きいようで、ByteBufferクラスに比べ100倍以上の時間がかかっていた。
Java
C++(MSVC)

Java外部起動

最近、Windowsの共有メモリ(BaseNamedObjects)をJavaでアクセスするプログラムを書いているのだけど、そうすると別プロセスの起動をJUnitで書きたくなる訳で。
Javaの別プロセスを起動する場合にこんな感じで書けたら良いなと思いながら書いたものをgithubに公開してみる、そんな夕下がり。
https://github.com/tkymism/java-launch

ここでのポイントは標準出力を親プロセスに引き渡すJavaMainクラス。(参考:ひしだま's 技術メモページ)
インタフェースは流してみる。
Linuxは現在、未対応でMacとWindowsで動作確認済。
標準出力で文字コードを正しく読み取るためには親プロセスと子プロセスで文字コードを合わせる必要があるようです。

生レバー、最小不幸社会、オーバー・コンプライアンス

嗚呼、生レバー

　生レバーがとうとう禁止となりました。私としては焼いたレバーはモソモソとした食感があまり好きではなく、生レバーの方が食べやすいと思っていた生レバー推進はだったので、今回の厚生労働省のオーバー・コンプライアンスに基づいた法令制定にはデモを主催してやろうかと考えていた次第です。時を同じくして、カリフォルニア州においても、フォアグラが禁止になっています。こちらはガチョウや鴨に対して強制的に餌を与えて太らせるという飼育方法が虐待だということです。世界の贅肉の３分の１を抱え込む米国でこのような法案が可決されるのは、非常な皮肉な結果かと。

最小不幸社会

　さて、日本の生レバーが禁止される経緯において、ブラウン管越しでも衝撃的にまで「痛さ」を感じさせ、お茶の間を震撼させた、某焼き肉屋社長の功績が大きいのかと。いくらデフレでも３００円のユッケをメニューにしたらいかんやろ、と。しかし、このような特定の失敗事例に基づいて、この日本では逐次新たな規制（コンプライアンス）というものが設けられていきます。目指す社会は、どんな経営者や消費者でも、限りなくノーリスクで焼き肉を供給・消費出来るあり得ない社会なのでしょう。ですが、このオーバー・コンプライアンスにより、焼き肉という生肉をも美味しく頂くクリエーティブな生業が死んだことになります。このようなオーバー・コンプライアンスは、最近の日本電機企業がグローバルでの凋落している状況を生んでいるという話もあります。「過剰品質」、「PL法」、「個人情報保護法」等など。いつぞやの首相が目指した「最小不幸社会」というノーリスク社会。

日本のソフトウェアはレシピ作り

　日本でソフトウェアを開発するにあたり、徹底した品質管理の元に開発されています。これら旧来の品質管理では、不具合（バグ）がないよう、ソースコードよりも多くのドキュメント（設計書、テスト仕様書）が生成されます。例えば、正しい設計であるか品質測定するために、「レビュー指摘件数を〇〇件以上」という指標を与えられてプロジェクトが進みます。すると、設計書のレビューで「句読点がない」やら「ここに改行が必要」とか、ドキュメントに対するほぼなんの価値もないレビュー指摘が列挙されます。そして「レビュー指摘件数が〇〇件以上あるから、品質が保たれた」ということが当たり前のように行われている。「アホ」かと。レストランのメニュー開発で、ただひたすらレシピをレビューして、失敗するリスクがほとんどないメニュー開発してるということです。

オーバー・コンプライアンスの罠

　日本の大手IT企業に勤めているエンジニアで、ソースコードを見ないで仕事をしている人が約８割程度ではないかと。その状況でレシピ作りだけに勤しんでいても、Dropboxは生まれないんじゃないかと気づかないといけないと思うのです。日本から正しいソフトウェアでパッケージングされたヒット商品が出てこない理由は、ノーリスクでソフトウェアを開発しようっていう「最小バグ開発」が原因ではないかと（ちゃんとリスクを取って、バグが少ないのは良いことですけど）。クリエイティブにはやはりリスクを取ることが必須であると思う訳で。

　さて、この理屈で言うと、某焼き肉屋社長はクリエイティブということになります。しかし、クリエイティブな作業にはもう一つ重要なことがあります。まさに「間抜けを無力化する-Joel on Software」。能力って平等じゃないっていう事実を踏まえ、プロジェクトはマネジメントしなくてはいけないという教訓かと。

プログラミングの３ワード

未来へのお手紙

 以前、プロジェクトメンバーに「君が今書いているソースコードは君ではない誰かが修正することに間違いなくなる。その未来の仲間に手紙を書いているようなもんなんだから、ちゃんと分かりやすく書いてあげるようにしなさいよ。バグ修正する時に君も悲惨なプログラムをなんぼも見たやろ！」というような話をプロジェクトのメンバーに言いました。そんな話をしたら、「そうですね〜」と、そのメンバーは言ってくれてました。長髪ではないが金八先生並みの熱い指導力を持っていたことでしょう。

 １年以上経ったこの前、そのメンバーがソース書いているところを横目で見てたんですが、まー悲惨に読みにくいこと。なんの成長も感じられない。どんだけ、金八的に熱く語ろうが、「読みやすく」書くこと自体が難しいテクニックなのだなーと実感します。実際、その人に払っている給料はそこまで高くありません。そんなソフトウェアが日本のインフラをしょっているという現実。本当に「読みやすく」書ける人がいたら、ここでは仕事をしていなく、海外企業やベンチャーでバリバリやってるわなと、脱金八で邪推するのであります。

「正しい、読みやすい、速い」

 会社の別部署のベテランプログラマさんが、とある講座で言っていた話。「プログラム」において一番重要な３つの要素は「正しい」「読みやすい（保守性）」「速い（性能）」であるということ。ベテランはさらに言葉を続け、「この順序が重要である。まず、正しく動作することが最重要で、次に見易いことで、最後に性能を求めよう」という。

読みにくいプログラムが出来上がってしまっていたとしたら、他の優秀なプログラマーが性能を良くしようとしても出来ません。チーム開発をする上では、やはり保守性が重要であるというお話でした。

 別のアジャイル開発の指導者的な人と話をした時に、この３ワードの話したところ、「読みやすい、正しい、早い」でしょうと。ペアプログラムをしていると、ソースコードが会話みたいなもんだから、話が通じること、つまり「読みやすさ」が一番拘るべきで、そうじゃないと正しいかどうかもわからんと仰っていました。やはり、チーム開発においては、この「読みやすい」というファクターが最重要とされているのでしょう。

美しいコードを書こうとするのは悪いプログラマー？

 Dropboxの生みの親になるYコンビネータの創業者ポール・グレアムさんは、こんな常識を全く覆す説「美しいコードを書こうとするのは悪いプログラマーだ」を唱えています。つまり、使われないサービスのソースコードがどんなに美しくても、意味が無い。それよりは、使い心地のよい性能の良いプログラムを書からないと、そもそも使ってももらえないということかと思います。この話はつまり、作り手は作って終わるマスタベーションではなくて、ちゃんと使ってもらえるサービスを作ることが重要だよと言っていると思います。こんなマーケティングの姿勢を持ち、かつプログラム書ける人が世界で通じるハッカーであると思う訳です。今後、日本もこんなマーケティングと技術を兼ね備えた人材が創出できないと世界ではやっていけないなと。フラッシュメモリを開発していた現東京大学教授の竹内健さんの著書「世界で勝負する仕事術」で読んだ、MOT(Management of Technorogy)にも話が通じるなと思いました。

３ワードを組み替えろ！

 さて、プログラムの３ワード「正しい、読みやすい、早い」の優先順位について再度考察します。

スタートアップビジネスで必要とされるのは、より魅力的なプロトタイプであるため、「正しい、早い、読みやすい」の順序、つまり保守性は低くなるということ。そして、ソフトウェアを受注する旧来型ビジネスでは、「読みやすい、正しい、早い」という順序で、保守性を大事にするということ。規模が大きくなればなるほど、後者の優先順位が望ましく、規模が小さければ前者の優先順位が望ましいということになるかと。

 これは吉野家の牛丼のキャッチフレーズ「早い、うまい、安い」が、市場動向によって「うまい、安い、早い」等、優先順位を変化させていたことに似ているかと。これは答えは一つではなく、ビジネス形態や市場動向によって「常に組み替えること」が最も重要であるということが今回の結論とさせて頂きます。

私のプログラムにコメントがいっさい書かれていないことに不満を抱いているレビュアーの方。私はスタートアップ企業だということでご了承お願い致します。

一般名処方と最低薬価

一般名処方が始まりました
４月１日より一般名処方の運用が始まりました。４月以降、病院や診療所でもらう院外処方せんには「ロキソニン」ではなく、「【般】ロキソプロフェン」という見慣れない言葉と【般】という記号が出回っていることでしょう。先発品「ロキソニン」ではなく、「ロキソプロフェン」という一般名で処方せんを記載すると、院外薬局で後発医薬品に振り替えて良いことになります。薬の一般名に【般】をくっつけて処方せんを出すだけで、処方せん１枚あたり２点の加算が算定できるため、お金を稼ぎたい診療所の先生たちは、これまで一般名と格闘していたことと思われます。
一般名処方加算は、原則として官報告示されている医薬品（先発医薬品）の中で「同一剤形・規格の後発医薬品がある先発医薬品」に対して加算がとれることとなってます（約１０００件近く収載されています。）。しかし、厚生労働省から通知されている一般名の記載例は約２００件程度しか記載されていません。厚生労働省としては、順次記載例を公開して少しずつ一般名を広めたいという考えのようですが、コンピュータで処方せんが印刷される時代に、一般名で印刷する「だけ」で２点取れるであれば、可能な限りゲットしたくなるのは当然です。
さて、厚労省から通知されている医薬品２００件以外で一般名処方加算をゲットするためには「後発医薬品の最低薬価」が必要となります。この「最低薬価」というバズワードが、医療機関・調剤薬局の流行語大賞になっているようです。

後発医薬品の最低薬価が分からない

「最低薬価」とはなんなのか、ここで簡単に説明します。医療機関で算定できる処方せん料は、処方せんに記載される医薬品の種類数により点数が変わります。

7種類以上	40点
6種類以下	68点

種類のカウントにおいて「薬剤料に掲げる所定単位当たり（１剤１日）の薬価が２０５円以下の場合は、１種類とする」というルールがあります。つまり、処方せん料を正しく請求するためには、処方せんに記載した薬の価格が必要となります。一般名で記載した場合、「一般名処方を行った場合の(４)の取扱いにおいて、「種類」の計算にあたっては、該当する医薬品の薬価のうち最も低いものの薬価とみなすものとする。」ことになりました。しかしこの「後発医薬品の最低薬価」が非常に難解なのです。

先発医薬品に対する後発医薬品を調べるための一つの手段として薬価基準コード（YJコード）を使用することが想定できます。例えば、ガスター錠１０mg（ファモチジン）の場合、一般名の薬価は「9.6円」になります。口腔内崩壊という口の中で溶ける薬と、一般薬がひとくくりで最低薬価を決めています。デバケン錠の場合、それぞれのグループで一般名の薬価が採用されます。徐方性（薬の溶け方が早い）があれば、別々に後発品をグルーピングするという考え方が採用されます。錠とカプセルもまとめるという考え方もあるので、単純にYJコードの9桁でグルーピングした薬価で決められないのです。きっと、このようなケースを全て調査する時間が足りなかったから、厚生労働省も「順次」提供することになったのでしょう。
なんとなく最低薬価を見つけられるように、こんな表作ってみました。Excelで見つけるよりは簡単だと思います。https://genericsearch.appspot.com/?locale=ja


時代にあった制度設計が必要
 コンピュータやプログラムは、あいまいなことが非常に苦手です。特に医療のような信頼性を要求される業界では、あいまいな制度設計が行われると、とたんに太刀打ちできなくなります。最近では電子請求が普及したため、システム化が容易な制度改定が続いていましたが、今回の「一般名処方」はちょっと準備不足であることが否めません。
 中医協の議事録では、「医師の頭の中には商品名しかないから、カルテは商品名で記載して、レセプトコンピュータで一般名を検索して処方せんを出す」という議論のようです。実際、療担規則は「カルテに一般名で記載すること」という記載にはなっていません。医師がなるべく苦労せずに、コンピュータで２点取る制度改定ということかと思われます。。。

 後発品への「変更不可」はコンピュータでの自動化が望ましくないと言いつつも、一般名を検索するところはコンピュータ任せというご都合主義。コンピュータ任せにするならば、厚生労働省は最低薬価を設定したレセプト電算マスタを公表するか、２０５点ルールを廃止するかどちらかが必要だったと思われる訳です。

 若干嫌な予感はしていましたが、ここまでとは。。。

デザイン思考が大事

ひどいユーザインタフェースに出会った怒り

 他人が設計したユーザインタフェースを見て思うのは、センスがある人とない人でユーザインタフェースの完成度が全く違うということです。最近みた画面で一番センスないなーと感じたのは、ワイドディスプレイ一杯にボタンやツリーが貼付けられた画面でした。多分、パワーポイントを使って設計したのでしょう。とりあえず、広がったワイドディスプレイ一杯に機能が盛り込まれています。カタログを見たら「たくさん機能があるな〜」と感じます。しかし、実際使ってみると、フルHDの右側と左側を交互に見るはめになり目線が左右に散らばるため本当に疲れます（マウスも右へ左へ行ったり来たりします）。最後にボタンを押せば、必要性を全く感じさせない確認画面が表示され、苛立ちを覚えます。さらに、デザインに統一性がないため、マニュアルなしでは何処に何の機能があるのかがさっぱりわからない始末でした。こんなユーザインタフェースでお金を取っていること自体、犯罪だと思います。どんな言い訳をしても死刑です。

ひどいユーザインタフェースが出来るまで

 こんなひどいユーザインタフェースが出来るまでの過程というのは、まさに日本企業の悪い文化が出ているなと感じます。
フルHDになった画面に対して設計した上記の例では、今までの画面設計を見直さずに、画面が広くなって空いているところにただ機能を詰め込んだだけでした。
「使える画面が広くなった」ということで全体的に設計を見直すことなく、ただ広がったところに機能を追加しただけです。
設計者は、きっと追加された画面の一部分に対して細やかに設計していましたが、全体的なユーザインタフェースについては、見直すことに躊躇したのだと思います。
全体的な見直しを行わず、今ままであった部分を直すこと無く、機能を追加したのでしょう。
設計者はきっとこう言い訳するはず。
「互換性を重視」、「上司に言われたとおり追加しました」。
まさしく、日本人特有の悪しき文化である、前例主義、部分最適、他責文化がまざまざと現れています。

ユーザインタフェースとは芸術

このGUIを設計できる技術を向上させることは、社会人になってからでは遅いというのが私の持論です。
ユーザインタフェースを作る作業は芸術品を作るものと同じです。
もちろん美意識が強くないと駄目で、さらには、ユーザ（他人）に対する洞察力、斬新的なものを作るための想像性、統一性を持たせるための論理性等、様々な能力が必要とされます。
会社員になってから、これらの能力は著しく伸ばすようなことは出来ません。
それは、才能であり、多感な時期である10代に以下に創造的な挑戦を行っていたかどうかだと私は考えます。
ですが、日本の企業はこういった人材を大事に出来ません。
こんな才能を持っている部下がいたら、上司だった扱いづらい部下に見えるでしょう。
これらの能力はお客さんを喜ばすことにはなるかも知れませんが、上司や会社に対して反抗的になりがちであり、部下として扱うにはめんどくさいものです。
日本企業でやはり必要とされるのは委員会的に調整する人であり、気難しい芸術家を大事にできないのでしょう。
最近のソニーが作るモノが面白くないのは、まさに「委員会による設計」のアンチパターンに陥っているのではと考えたりもします。

日本に必要とされるデザイン思考

今後、日本だけでなく世界的にCreator or Serverの時代が進みます。
アジアの安い労働力と日々進化するコンピュータ性能、そして満たされた生活。
その中で、ビジネスとして必要なのは高いコンセプトとデザインであると考えます。
まさにハイ・コンセプトの時代に変わりつつあるということです。
技術力はあるが、借金まみれの日本という国は、何故か対フランスでは貿易赤字になります。
車やハイテクなモノを世界で売って輸出したとしても、ブランド志向の高い日本女性が、資生堂ではなくフランスの化粧品、日本製鞄ではなくプラダやディオールを買うから、イタリア・フランスに対して貿易赤字になるのです。
そう考えると、世界的な日本製ブランドがたくさん出来て、今後消費が伸びるであろうアジアで鞄・靴・化粧品を売れるようなブランドになれば、日本という国は高齢化社会を迎えてもある程度やっていける国になるのではと考えています（という考えをデフレの正体という本を読んでおもしろいなと思ったわけです）。

高額療養費の外来現物給付化

高額療養費の外来現物給付化

 2012年度4月より、高額療養費制度が入院だけでなく、外来の医療費についても現物給付化されます。従来、外来の高額療養費については、役所等でまとめて「償還払い」（後払い）されていました。つまり、役所で払ってもらうまで、患者は立て替える必要があった訳です。平成24年4月以降は、役所であらかじめ「限度額認定証」を申請・取得(※)しておけば、医療機関が患者に対して所得に応じた自己負担限度額までしか請求しなくなるため（現物給付されるため）、患者が立て替えることがなくります。

※70歳以上の場合、役所で申請すること無く現物給付の扱いになります。

70歳未満

所得区分	自己負担	多数該当
上位所得	150,000円 ＋（医療費－500,000円）×1%	83,400円
一般	80,100円 ＋（医療費－267,000円）×1%	44,400円
低所得者	35,400円	24,600円

70歳以上

所得区分	外来	入院	多数該当
現役並所得者	44,400円	80,100円 ＋（医療費－267,000円）×1%	44,400円
一般	12,000円	44,400円
低所得者Ⅰ	8,000円	24,600円
低所得者Ⅱ		15,000円

高額療養費は難しい
 この高額療養費制度は、制度自体が非常に難解であり、今まで入院担当の医療事務員を苦しめていました。例えば、患者さんの請求は１０円単位に四捨五入されて請求されます。そのため、５点（５０円×３割＝１５円⇒患者請求２０円）の診療があった２回あった場合、月で見たら１０点だけど、患者請求は４０円になります。4月以降、通常の外来でも現物給付化が始まることから、請求の端数が出まくることは想定されます。病院の窓口で10円高いだ低いだのと騒ぐクレーマーが外来窓口を困らせることでしょう。
 さらに、特定疾患等の公費があった場合には、さらに最低です。レセプトに記載する「医療の１％」の計算が変態的に難しいのです。今後、診療所のレセプトチェックでも、電卓を弾く時間が多くなることが想定できます。

高まる医科向けソフトウェアの参入障壁

 外来現物給付化が始まることで、診療所市場等で販売されている中小の電子カルテベンダーが疲弊し、撤退する会社が増えることが想定できます。もともと、大手ベンダーによる寡占状況が続いた医科向けソフトウェア市場は、他のソフトウェア市場よりお値段が高いです（中小の電子カルテベンダーが参入したことで、市場価格が若干下がりました）。特に医科のレセコンベンダーは調剤のそれに比べ、扱っているベンダー数が少ない。それは、高額療養費を含めた、医療報酬制度が調剤に比べ難解であるため、参入障壁となるからです。

診療報酬制度は医師会と厚生労働省との綱引きにより決まっています。綱引きの中で、条件が設けられ、診療報酬制度は更に複雑になります。つまり、医師会と厚生労働省が綱引きをすればするほど、医科向けソフトウェアの市場価格が高く維持される結果になるということです。

医療請求制度は社会的コストが高すぎる

 医療機関は正しく請求するために、高価なレセコンやレセプトチェックのソフトウェアを購入し、審査支払機関は独自のソフトウェアでチェックを行い、各保険者でも別にソフトウェアを作成してチェックする。診療報酬改定があるたびに、別々にソフトウェアを改造しているこの状況は、社会全体から見たら、単なるお金の無駄遣いにしか思えません。みんなが安く利用できるレセプトチェックシステムがクラウドで提供されれば、社会的コストは大幅に下げれます。そうなると審査支払機関がソフトウェアをオープンソース化して公開すれば、全体的な社会的コストは大幅に下がるのですが、審査支払機関自体の必要性が無くなってしまうため、審査支払機関はきっとしないでしょう。

 お隣の韓国では診療報酬の電子化が日本よりも圧倒的に早く進みました。それは、診療報酬制度が簡単だったからです（日本では３０％減とか普通ですが、韓国では基本足し算と引き算だけです。）。逼迫する医療保険制度をなんとかするため、診療報酬制度を変えていくのはいいのですが、処方せん改定みたいな効果のないことするぐらいだったら、社会的コストを押さえるように、厚生労働省にはもう少しシンプル制度設計してもらいたいです。

一般名処方加算について

一般名処方加算

来る平成24年4月に、薬剤を一般名で記載して処方箋を発行した場合、通常の処方箋料（49点）に加え、「一般名処方加算（2点）」が算定できることとなります。この改定の狙いは、調剤薬局における在庫管理の効率化とされています。医師が処方せんに後発医薬品の銘柄を記載する従来運用の場合、調剤薬局で後発医薬品を多種に在庫として抱える必要が出てきます。この問題に対するアプローチとして、「処方箋の一般名による記載」が有効であると考えた訳です。つまり、薬剤の銘柄（製品名）を処方せんに記載するのではなく、成分を元とした「一般名」で記載することで、調剤薬局で後発医薬品を自由に処方できるようにし、後発医薬品の普及を促そうというのが狙いです。

一般名は難しい

例えば「ガスター」は「ファモチジン」という一般名があります。普通に考えれば「ガスター」が「一般」名に思われますが、学会で使用される成分名を元にした「ファモチジン」が一般名のため、処方せんに「ファモチジン」と記載したら２点（２０円）分、医療費を高く請求できるということになります。そのため、２４年４月以降、医療機関では「ガスター」と呼ばずに、「ファモ」等の一般名をより身近にするような薬の愛称が流行するでしょう。さらに、一般名処方加算（処方せん１枚あたり２０円）欲しさに、「この薬の一般名なんやねん？」的な話題が医療機関で流行ると思います。医療機関で働く医療事務員に人たちも、必死になってこの難解な「一般名」を覚えなくてはならず、医療機関の会計窓口では少なからず混乱を招くことでしょう。

一般名加算の存在意義を問う

さて、ここまでして「一般名」を流行させる必要はあるのでしょうか？「先発品」を記載して「後発品に変更して良いよ」と一筆添える今までの方法でも、調剤薬局の在庫管理問題は十分に解決できます（後発医薬品名の銘柄が処方せんに記載されることが問題なので、先発品を記載して「変更可能」と記載すれば、調剤薬局側で自由に処方できます）。診療報酬で考えても、平成２０年４月時点に点数が逆戻りしただけです。この改定は、ただただ、学会で使用されている「一般名」を普及させたいだけとしか思えなくなります。

平成20年	平成22年	平成24年
処方せん料 後発品を含む（７０点） 後発品を含まない（６８点）	処方せん料（６８点）	処方せん料（６８点） 一般名処方加算（２点）

それでも後発医薬品は普及しない

前回、後発医薬品の普及でも述べましたが、先発品と後発品は効能は同じであると厚生労働省がいくら広報しても、ブランド志向の高い日本では、ブランド品の「先発品」の需要が高いです。さらに言うと、どこの調剤薬局に行っても、国民皆保険制度により、常に７０％ディスカウントされます。そんなディスカウントが効くお店でユニクロのパーカーを買う人は少ないはずで、プラダやグッチなどのブランド品を買う方がお得と考えるはずです。つまり、日本人の異常なまでのブランド志向と、充実した保険制度が存在する限り、後発医薬品は普及しないという結論になります。（本気で、後発医薬品を普及させるためには、先発品と後発医薬品を含めた平均価格で、保険請求することにし、差額分は自費請求にすると、後発医薬品が普及し、社会負担も減ると思います。）

優秀な現場の人がパッケージをだめにする

３月１日のとあるドラマ

201X年3月1日、地方銀行向けパッケージの開発ルームでは、異様な雰囲気の中、メンバー全員がその日の朝を迎えた。その日は北海道、長崎、そして兵庫の３つの銀行で一斉に稼働する日であり、多くのメンバーは現地に立ち会う等の臨戦態勢が敷かれていた。稼働後２時間が経った朝１０時頃、開発チームに同時に２つのトラブル報告が入った。いずれもデータベースがダウンし、待機系システムに切り替わったという致命的な内容だった。開発メンバーの一人がデータベースのログを調査し、データベースがダウンした原因が接続プロセス数の制限を超えたことよるものと判明したため、急遽、現地で立ち会っているフィールドSEにパラメータ設定とシステム再起動を指示した。昼１２時に、最高責任者である事業部長は、事態の改善を行うべく、担当部長と担当課長を現地投入することを決断した。昼１３時、運用系システムの再起動が行われ、それぞれの銀行で運用系システムに無事切り替わったとの報告があった直後、更なるトラブルが現地から報告された。運用系システムの発番プログラムが正常動作せず、データ重複によりシステムエラーが複数で発生し始めた。事業部長はさらに現地に開発メンバーを投入し、早急にデータ復旧を行うよう、迅速に指示を出した。事業部長は「お客様のシステムを決して止めてはいけない」と鼓舞し、開発メンバーを送り出した。。。

隣のプロジェクトで起きていた今週の出来事をシリアスタッチに書いてみました。そのトラブルの様を見ながら思ったことは、「ちゃんとトラブらないモノを作ろうよ」です。

パッケージ開発の失敗例

このパッケージは大規模向けに販売されていたパッケージを移植して、中小規模向けに販売するというコンセプトの商品でした。データベースの変更に伴うプログラム修正は中国でオフショア開発され、日本ではプロジェクトマネージメントを中心に作業するという方法で進められました。いわゆる品質指標も丁寧に数値化されていたため、一定の品質が担保できているだろうという認識でした。

ところが、ふたを開けてみると、移植元のパッケージがぼろかったりとかして、トラブルが続発しています。バグがあっても、一体誰が作り込んだのかがさっぱり分からないようで、早急に修正できないという困った状況です。さらには、稼働させるためにはデータベースのチューニングなどのSE作業が必要となるため、初期導入費用がかかってしまい製品競合力も低いです。まさにパッケージ開発における失敗のオンパレードといった感です。

サポートしている同僚は自嘲的に言いました。「生まれてこなければ良かったのに」。まさに不毛な子です。

優秀なSEとパッケージのジレンマ

私が勤務する会社は大手の日本法人のIT会社で、星の数ほどパッケージ製品をリリースしていますが、利益になるパッケージはほとんど存在していません。この理由は、優秀な現場のSEが数多くいるから、良いパッケージが生まれないというジレンマだからだと思います。現場で働く有能なSEが存在するから、場当たり的になんとかしてしまうから、パッケージにフィードバックされないのではないかと思います。

当の私もパッケージを開発していますが、粗利益が非常に高いです。その理由は、インストーラー、導入ツール、マニュアル、プロモーションツール等の「仕組み」が充実しているからです。「仕組み」が充実していると、２５〜３０歳くらいの若い女性インストラクターさんで導入できます。導入費が安くできます。なんとかやりくりしてくれる優秀なSEさんが存在してしまったら、この「仕組み」を作ろうという気持ちになりません。現場の人が「楽して儲け」させるように「仕組む」思考がパッケージ開発には必要なのです。

今回のリリースされたパッケージの場合、「有能な現場SEを最大限に活用する」というコンセプトが存在しました。しかし、このコンセプト自体がパッケージには合わないということを経営者が理解できなかったのが根本原因だと考えます。

日本人は「仕組み」が下手

歴史を振り返ると、日本人は「仕組み」を作るのが下手な民族性だと思います。社会に存在するほとんどの「仕組み」は欧米から持ってきたものが実際に多い。しかし、それは、現場の日本人が優秀すぎるというジレンマだと考えられます。

例えば棚田とかを見ると、年貢が厳しい中、農民が工夫して作り上げた芸術作品です。ですが、牛も入れないような田んぼなので、効率的とは言えません。これも優秀な日本の農民が場当たり的になんとかしちゃったのでしょう。エルピーダメモリの会社更生法についても、グローバル時代の中でDRAMを販売するというのは厳しい状況であったにも関わらず、優秀な現場の人が場当たり的にコストダウンに取り組んだために、撤退という経営判断が行われずに、今の今まで持ってしまったのだと考えられます。この前の日本の戦争においても、世界で最も優秀な現場の兵隊が存在したから、明確な戦略という「仕組み」を大本営が見いだせず、結果、あのような悲惨な状況になったと考えられます。

「仕組み」を作れる人になるためには、「真面目」じゃだめで、「楽して儲ける」的な発想が重要かなと思います。しかし、この発想は、従来の日本の美徳に反するところがあるようです。実際にうちの会社の執行役員常務と話をする機会があったのですが、私の主張する上記の話についても「上手く行ってるビジネスの上であぐらかいてんじゃねぇ」的なことを言ってました（この人の経歴を調べたんですが、うちのプロジェクトのような粗利を稼げるビジネスが一つもない部署のご出身のようでした）。これからのグローバル時代で乗り切るためには、このような割り切った発想を持つことが重要なのではと思います。

モックアップビジネスモデル

初期費用０円受託開発

　永和システムマネジメントさんが初期費用０円の受託開発をやっていることを、人づてに聞きました。この話を同僚の何人かに話したところ「こんなの出来る訳ない！」と口を揃えて言ってました。私の会社はＩＴゼネコン大手です。従来の「受託」ヒエラルキー構造でビジネスを行っていたため、このような新しいビジネスモデルに理解を示そうとしないのでしょう。しかし、私はこのビジネスモデルが生まれたこと自体が日本のソフトウェア業界が変化の兆しと捉えています。

モックアップビジネスのメリット

このビジネスモデルは、最初の試作品（モックアップ）を０円で開発し、その試作品を気に入った会社は、その後利用料を月額で払っていくという、いわゆるクラウド型のビジネスモデルです。このビジネスモデルは、通常の受託ビジネスモデルに比べ、以下のメリットがあります。

     １．利益率の向上

私が所属している部署はパッケージ提供型の箱売りビジネスですが、たんなる「受託」に比べると利益率が２～３倍以上に上がります。受託ビジネスの場合、赤字を抱え込むリスクはなくなりますが、「人月」あたりの利益額は一定となります（極論、「無能」なプログラマをできるだけ安く集めて、マネジメントでなんとかプロジェクトを完了させることが、最も利益率を上げる手法となります）。自前で企画から開発までをサービスとして提供すれば、どこかの会社に中抜きされることなく、高い利益率のビジネスを実現できます、また、このモデルの場合、お客さんを「囲い込み」しますので、利益の継続性という観点でも魅力です。

     ２．低コスト化の実現

通常受託の場合、開発言語やＯＳ・データベース等のミドルウェアは、お客の都合で決まります。そのため、様々な技術に対して人材教育・人材配置が必要となり、そのままコストとしてビジネスに乗っかります。モックアップビジネスモデルの場合、自社が得意とする開発言語とミドルウェア構成で試作品を作ってしまえば言い訳で、リソースの選択と集中が可能となり、開発コストを大幅に下げることが可能となります。さらに、一度開発した共通部品や各種基盤系フレームワークは、次のモックアップでもそのまま流用できるため、コスト低減だけでなく、納期短縮や製品品質の向上も実現できます。

    ３．開発者のモチベーション向上

試作品開発では、ＧＵＩから大枠の仕様を自社で決められるため、開発者のモチベーションは上がります。開発者の気持ちとしては、出来上がってからの仕様変更は苦痛そのものです。最初に試作品を作り切ってしまうことは、お客さんとのイメージの共有が簡単になるため、大きな仕様変更が発生しないことになります。さらに、今回のモデルの場合、仕様変更は月額に移行した段階で発生するため、「仕様変更しないと金払わんぞ、ゴラ！」という、よくあるお客さんの脅迫タイミングを奪うことが出来ます。

　このように、モックアップ型ビジネスモデルには上記のようなメリットがあるため、初期投資が「０円」でも採算があうのではと考えています。もっと言うと「０円」じゃないとダメです。「０円」という言葉はマーケティング的には絶大な効果を発揮します。だから５０００円じゃだめなんです。（「０円」の言葉の力については、「予想どおり不合理」にも詳しく書かれています。）

モックアップビジネスを成功させるポイント

そうは言ってもこの新しいビジネスモデルは、従来型の「人月」モデルに比べると、失敗するリスク顕在化します。私が考えるに、このモデルを成功させるためには、以下のポイントが重要だと思います。

　　 １．有能なデザイナーの投入

  受注を成功させるためには、試作品のデザイン性が最重要です。「痒いところに手が届く」という機能要求については、月額の段階で対応するようにして、モックアップ段階で訴求すべきは「見た目」になるはずです。そのため、優秀なデザイナーが必要となるのです。「ハイ・コンセプト「新しいこと」を考え出す人の時代」や、「デザイン思考が世界を変える―イノベーションを導く新しい考え方」にも書かれていますが、これからは感性の時代に突入します。そのため、優秀なデザイナーを社内で育成することが重要課題であると考えます。

２．再利用の徹底によるコスト削減

モックアップでは低コストでアジャイルに作り上げることが重要です。そのためにはプログラムを徹底的に再利用させるよう、共通フレームワークを拡充することがポイントとなるでしょう。モックアップ段階では、入社２、３年目の新人プログラマーと、優秀なデザイナーの組み合わせだけで開発できるくらいの、使いやすい部品ライブラリがあれば理想的なのではないかと思います。きっと、永和システムマネジメントさんの場合、開発言語はＲｕｂｙでアジャイルに開発しているのだろうと思いますので、この点で言うと問題は無いかと思われます。

３．創造性の追求（受託意識からの脱却）

　受託開発の場合、製品の魅力が乏しいと感じられても「お客さんが言ったんだから、そのままやっておけばいい」という、一種の逃げが許されたりもします。しかし、自前でサービスを提供するということは、常に創造的であることを要求されます。本当に使いやすいユーザインタフェース、創造的な機能を創り出せる「センス」は、誰しもが持っているものではないというのが、私の持論です。魅力的なユーザインタフェースを想像すること自体、アーティストと同じ活動だと考えます。なので、そのような人材がキーマンとして社内にいるかいないかがポイントになると考えています。 

イノベーションのジレンマ

最近は、Ｎさんも赤字体質に苦しんでいる訳で、インドや中国の買収されるなんてことも現実味を帯びている状況です。今までのような受託ヒエラルキーの構造で、同じように受注できればいいのですが、クラウドの登場により市場価格が急速に押し下がっている状況を見ると、そんな大金をソフトウェアに出せるお客さんがどれだけいるか疑問です。日本のソフトウェア業界において、クラウドはまさにイノベーションのジレンマです。デジタルカメラを自社で開発しておきながら、フィルムビジネスの急速な落ち込みに対応できず、コダックはあえなく潰れました。今、日本中のＩＴ企業がクラウドを進めていますが、まず自らの仕事のやり方を見直さない限り、コダックの二の舞になってしまってしまうと私は考えます。

ニーズをシーズでウォンツに！

ビジネスモデルって何やねん？

５、６年前くらい前に、会社でビジネスモデル特許を書けという至極あいまいな業務命令が私に下りました。技術特許については、それまでにも何件か出願依頼していましたので、十分理解していましたが、「ビジネスモデル特許」については、一種の「ハイパーメディア」なにがし的な胡散臭さが感じられていたため、意識的に避けていました。が、「ハイパービジネスモデルは胡散臭いのでちょっと。。」なんて、サラリーマンとして上司に対して言えないため、教育嫌いな私ですが、「ビジネスモデル」関連の社内教育を探し出して、理解を深めようとした訳です。

さて、その「ビジネスモデルなにがし」の社内教育に出向いてみると、片手に携帯よろしくノートパソコンに向かっている「チョイワル」な壮年男性が講師の席に座っておられました。周りの受講生は、その「チョイワル」講師をまるで有名人を伺うかのように、興味津々に見つめていたので、自分がえらく場違いな場所に来てしまったと後悔していたのを覚えています。講義を進めて行くと、著作「コンサルタントの質問力」の紹介がありました。その方がコンサルタント業界では有名な野口吉昭さんであることが初めて分かりました。

ニーズとシーズでウォンツを！

講義の内容は当初期待していた「ビジネスモデル特許」とは全く関係がないものでしたが、オフィス用品販売「アスクル」や、大田区を中心にお弁当を販売している「玉子屋」等を事例に、様々な業態でのビジネスモデルを分析するという、知的欲求を満たすとても有意義な講義内容でした。特に私が感銘を受けたのは、「新たなビジネスモデルを創出する過程において、ニーズとシーズでウォンツすることが必要」という話です。

ニーズはいわゆるお客さんの声。具体的ではあるが、視野が狭く、短絡的な内容が多いです。それは決して本当に欲しいモノ、いわゆる「ウォンツ」ではない。スティーブ・ジョブスは「客は本当に欲しいものを知らない」と言っていたとか。だけど、お客の誰もが知らない「ウォンツ」を創り出すなんて、簡単には出来ない。でも、社内のどこかにあるシーズ（技術）を最大限に活用すれば、「ニーズ」を「ウォンツ」に変えることが出来るという話でした。

iPhoneが出来上がるまで

「スティーブ・ジョブス」でiPhoneが世界中で圧倒的な驚きを持ってリリースするまでの話を読んだとき、まさに「ニーズをシーズでウォンツに！」のケースに全く以て当てはまるなと感心しました。iPodが世の中を席巻していた頃、iPodを脅かすのはウォークマンではなく携帯電話であるとAppleは考えていました。デジタルカメラがカメラ付き携帯電話の登場により販売が落ち込む様を見ていたので、危機感を強く持っていたのでしょう。さて、AppleはMotorolaと共同でIPod付き携帯電話を開発し販売しました。しかし、これは大失敗に終わりました。携帯にiPodが内蔵した、「ニーズ」をそのまま具現化した「だけ」の製品だったからです。特にデザインがしょぼかったらしく、「スティーブ・ジョブス」の本の中でも糞味噌にこき下ろしていました。

ここで、Appleは既に開発を進めていたタブレット技術に目を付けます(iPhoneより先に、iPadを開発しようとしていたというのが面白い)。このマルチタッチ機能を「シーズ」として組み合わせ、徹底的にブラッシュアップを重ねた結果、まさにお客の誰もが想像もつかないようなiPhoneという「ウォンツ」が創造された訳です。

「現場」はフィールドだけじゃない

さて、私の仕事はソフトウェア開発なので、それに立ち戻って話をします。日本のソフトウェア業界に働いている人は必ずこの言葉を聴いたことがあると思います。「お客様の現場に出向いてお客の話を良く聞け！」。この言葉は半分は正しいですが、半分は間違いです。お客さんが欲しいモノを提供するためには、お客さんの現場に出向いて「ニーズ」を聞くことは重要ですが、それだけでは本当にウォンツなモノは作れない。「シーズ」は常に開発現場に落ちている訳で、開発現場にも同じように、いや、それ以上に出向かないと、本当に売れるウォンツな商品は出来上がらないと思う訳です。これから日本ではモノを作ったら当たり前のように売れるという時代じゃありません。客を感動させ、ワクワクさせる「ウォンツ」なモノを作るためには、やはり「ニーズ」と「シーズ」を繰り返し組み合わせながら、新たな「ウォンツ」を作り上げる思考パターンが必要とされるのでしょう。

この話は今週の重役向けスピーチのネタです。当初は（http://blog.livedoor.jp/kazu_fujisawa/archives/25610490.html）を元にアレンジして、「ソフトウェア業界における少子化問題を考える」を用意したのですが、「無駄に炎上させてもしょうがないだろう」という上司判断により、今回の話のネタを日曜夕方に書き下している訳です。上司の命令を従順に従う私こそサラリーマンエンジニア。

後発医薬品、処方箋様式改定、プラセボ効果

後発医薬品の普及について

　２０１２年度の診療報酬改定では、社会保障費の赤字が慢性的に膨らむ中、診療報酬を１．３８％上げて、その分薬価を１．３８％下げて全体でトントンにするとの方針「平成２４年度診療報酬改定について」を中医協が出しています。中医協や厚生労働省が薬価の引き下げに期待しているのが、後発医薬品（ジェネリック医薬品）の推進です。

　２０１２年度の診療報酬改定においても、処方箋の書式を変更して、後発医薬品を推進させようという施策「後発医薬品の使用促進のための環境整備の骨子」が議論されているようです。後発医薬品の普及に関して処方箋の様式が変更されたのは、２００６年度の診療報酬改定の「後発医薬品への変更可」の欄の新設が初めてでした。これは後発医薬品に変更しても良い場合、新設の欄に医師名を印字することで、調剤側が後発医薬品に変更しても構わないという制度です。しかし、そもそも署名しない医師が多く、あまり効果が出なかったと言われています。その後、２００８年度に、「後発医薬品への変更不可」の欄に変更されます。これは、意味を逆転させて、「医師名が署名されない場合に」後発医薬品への振り替るという制度改定でした。しかし、この制度改定も「後発医薬品への変更不可」がプレ印刷された処方箋で発行される等の抜け道があったようです。そして今回、薬剤単位に「変更不可」を指定する書式に変更して、プレ印刷問題を解決しようという目論見と思われます。

処方箋の様式を変えても後発医薬品は普及しない

しかし、処方箋の様式を変えようが後発医薬品が普及に影響が出ないということに、中医協にはもうそろそろ気づいてほしいです。そもそも、現在、院外処方箋のほとんどはオーダリングやレセコン等のコンピュータから印刷されています。いかに、「後発医薬品への変更」を促すような処方箋の様式だったとしても、医師が簡単な操作で「後発医薬品に変更不可」にしてしまう機能が開発されてしまう訳ですから、処方箋の様式を変更して後発医薬品を推進させるという施策自体がナンセンスなのです。さらに、処方箋の様式を変更した場合、それぞれの医療機関でシステム修正や、プレ印刷紙の購入等、莫大なコストがかかります。これでは、システム業者や、印刷業者が儲かるだけです。中医協には「後発医薬品の品質確保」等の正攻法に注力してもらいたいです。

プラセボ効果と後発医薬品

　後発医薬品は生物学的な試験により生物学的に同等効能であることが証明されていますが、安い後発医薬品よりも先発品の需要が高いのが現状です。その理由として、「プラセボ効果」が挙げられます。「プラセボ効果」については、行動経済学の学者が書いた「予想どおり不合理」を読むと良く分かります。本書では、２ドルのアスピリンの方が、１ドルのアスピリンより、良く効くという「プラセボ効果」の事例について説明しています。つまり、効く薬が高価なのではなく、高価な薬ほど良く効いてしまうということです。つまり「プラセボ効果」を考慮した場合、後発医薬品を推進すると、逆に投与量が増えて、社会保障費が上がってしまうかもしれないということになります。「予想どおり不合理」では他にも、スターバックスのコーヒーがおいしい理由、レストランでべらぼうに高いメニューがあると客の単価が上がる等々、面白い事例がたくさん載っている本なので、超お勧めです。

プラセボ効果で患者負担を考える

　うつ病等の場合、後発医薬品よりも先発品の方が良く効くようで、先発品の採用が高かったそうです。しかし、２００６年度に施行された自立支援法で１割の患者負担に引き下がってしまってるので、「プラセボ効果」自体が効かなくなってしまいます。今年度の改定では、外来の高額療養費を現物給付化するとのことで、「プラセボ効果」で考えると、患者の負担額が低く見えてしまうので、治りにくくなるということになります。極論、外来の患者負担については、若者・老人問わず３割負担に設定し、高額療養費と公費は全て償還払いにした方が、プラセボ効果で病気が治りやすくなり、医療費削減に繋がるのではと考えるわけです。

緊張と緩和

お笑いの緊張と緩和
 この緊張と緩和という言葉は最近テレビでもよく耳にするキーワードでありますが、もともとは関西落語の桂枝雀さんが、「全ての噺は緊張と緩和で分類できる」という主張が最初とのこと。この「緊張」と「緩和」理論について、落語の世界を通して説明している動画がyoutubeに掲載されていたので、じっくりと見てしまいました。
 近年のお笑いは、いかに「緩和」させるかではなく、いかに上質の「緊張」を演出できるかだと思います。例えば、大晦日に放送された「笑ってはいけない」等の番組では、シュールレアリズムによる緊張と「アウト〜」による緩和と考えれば、まさにあの「緊張」の間が重要なのではないかと考える訳です。また、M１グランプリを振り返ってみても、徹底した変態キャラのチュートリアルや、徐々に盛り上がる喧嘩のブラックマヨネーズ等のコンビは「緊張」できる「場」を上手く演出しているな〜と改めて考えさせられます。桂枝雀さんは１９９７年にお亡くなりになられてますが、「緊張」と「緩和」は、お笑いの現場に最も取り入れられている理論だなぁと感心します。

音楽の緊張と緩和
 緊張と緩和の動画を見た上でiphoneの曲を聴いていたら、ヘビーローテーョンされる曲のほとんどが、緊張と緩和のダイナミズムがしっかり構成されている曲ばかりであることに気づきました。

例えば、ライブ曲での終盤のジャムセッションがラストのコーラスに向けて盛り上げる曲は何度聴いても脳内アドレナリンが分泌されます。最も重要なのは、ジャムセッションの質が高く、間延びしない程度の「緊張」を演出しているかだと思います。


レッチリのBy the wayなんかは、ライブじゃなくても曲自体が緊張と緩和で構成されてるため、ダイナミズムがあって、チャートインもなるほどなと感じます。

高校の時に流行ったダンスミュージックもやはり、ドラムが一定間隔で鼓動する「緊張」と、休憩時間？的な「緩和」がしっかりと構成されている曲だったなと思い出しました。

創出の緊張と緩和
古来中国の諺で、「良い考えは馬上、枕上、厠上で生まれる」と言われるそうで、ブレークスルーはリラックスされた「緩和」の中で生まれるとのこと。なるほど、私の仕事のソフトウェア開発でも、長時間かけて作ったものが全て必要なくなるくらいのアイデアは、家に帰ってお風呂に入った時に生まれたりすることが多い。様々な切り口で物事を捉えようと努めても、やはり緊張している状況では、視野が狭くなっているのでしょう。では、ずっと緩和（リラックス）すればいいのかというとそうでもない。本当に質の高いブレークスルーが生まれるためには、突き詰めて物事を考える緊張や、悪戦苦闘して実行する緊張が、過程に必要なのです。緩和しきった中での「軽い」アイデアを聴いても、聴いている人は魅力を感じないものです。

プロジェクト活動の緊張と緩和
良い作品をプロジェクトで成果を出すには、緊張と緩和のダイナミズムをチーム全体で形成する必要がある。各メンバーがそれぞれ持つ「緊張」と「緩和」の波長が、チーム全体で大きな波長になり、それは共振作用を起こし、信じられない程のパワーが生み出される場合がある。まさに「狂熱」である。このようなプロジェクトにするためには、各メンバーの波長を検知し、マネージャ自身の波長を乗せながら、チーム全体の波長に化けさせるマネジメントが必要だ。つまり、プロジェクトマネージャの目指すべき仕事とは、Excelでガントチャートを書いて報告することではないということだ。
このような考えは一般的なソフトウェア開発のPMとは異なる考えなので、私はPMにはなりたくないというのが結論。今年の春の情報処理試験は何も受けません！