Engineering, Marketing, Designing

最近のエンジニアが必要とされる能力
私も１０年ほどソフトウェアで飯を食ってきたわけですが、いわゆる「デキるエンジニア」が持つスキルとやらがはっきりしてきたなということ。それは大きく３つの技術です。

• Engineering（技術）
• Marketing（マーケティング）
• Designing（アートやら認知工学）

需要がありそうなサービスをMarketingしちゃって、おしゃれで使い易いインタフェースにDesigningしちゃって、プログラムをEngineeringして公開しちゃいなyou！、ってことです。
ひと昔前のように「俺、Oracleマスターです」じゃ、なかなかエンジニアの価値になりにくくなってきてしまっていることです。

日本大手電機が陥る分業化の罠
高度成長期の日本企業でも、製品を企画・開発していた人たちにとっては、これら３つのスキルは持っていました。
それが、効率化の追求や製品品質の過剰化に伴い、エンジニアの分業化が進みました。
そのため３つのスキルをトータルで持ち合わせた人材が少なくなります。
ソフトウェア業界も分業化が進み、ネットワークエンジニアだとか、データベースエンジニアだとか、プロジェクトマネージャだとか、超上流SEだとか。たくさんありすぎて、何が何やら。。。
日本のソフトウェア企業に勤めるエンジニアは、この分業化の時代の中で、具体的なスキルセットを可視化して売り文句にしてきたのです。

統合型のエンジニアになろう
さて、時は流れ、最近のソフトウェア業界は価格破壊が進んでいます。価格破壊が起きている原因は、主にこのキーワードは「クラウド」、「グローバル化」、「オープンソース」。
とくに「クラウド」の時代では専門知識を必要としないままサービスを立ち上げることが可能となりました。これまでのオーダメイド型のソフトウェア一括請負というビジネスを根幹を揺るがす「破壊的イノベーション」です。
他の業界に比べ比較的安定的であった「ITサービス」という業界自体が、じわじわと存亡の危機に瀕している状況です。
このクラウドの時代に新たにサービスを起こそうとすると、資本金はほとんど必要ありません。GoogleやAmazonのクラウドサービスを使えば、非常に低コストでビジネスを始められます。 そんなリーンスタートアップなエンジニアになるための技術は、やはり「Engineering」、「Marketing」、「Designing」をトータルで扱える統合型エンジニアが重要になる時代なのです。

とまぁ、私もそんな統合型エンジニアになれるよう、家の中で「芸術」に触れる機会を増やそうかと思います。だって外は寒いんだし。

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

とある里の診療所

　先日、地域医療ネットワークを押し出している「とある県」の「とある町」に出張してきました。今回の出張の目的は、その地域の「かかりつけ診療所」に電子カルテを導入し、県の中核病院とカルテを共有するという、今時のお仕事でした。これにより、中核病院で行った画像診断やら検査結果を、山の中にある診療所でもリアルタイムで共有することができるため、医師不足が著しいと言われる過疎地での医療に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の時代が進みます。
アジアの安い労働力と日々進化するコンピュータ性能、そして満たされた生活。
その中で、ビジネスとして必要なのは高いコンセプトとデザインであると考えます。
まさにハイ・コンセプトの時代に変わりつつあるということです。
技術力はあるが、借金まみれの日本という国は、何故か対フランスでは貿易赤字になります。
車やハイテクなモノを世界で売って輸出したとしても、ブランド志向の高い日本女性が、資生堂ではなくフランスの化粧品、日本製鞄ではなくプラダやディオールを買うから、イタリア・フランスに対して貿易赤字になるのです。
そう考えると、世界的な日本製ブランドがたくさん出来て、今後消費が伸びるであろうアジアで鞄・靴・化粧品を売れるようなブランドになれば、日本という国は高齢化社会を迎えてもある程度やっていける国になるのではと考えています（という考えをデフレの正体という本を読んでおもしろいなと思ったわけです）。