2024年1月27日土曜日

JavaScript の module や class の話 -js と mjs-

 自分の勉強がてら TypeScript の話でもしようかなと思っていたのだが、その前に ES6 あたりで導入されたオブジェクト指向の文法のことなどを説明しておかないと話の流れ悪いよなあと我にかえる。

「Java と JavaScript の立場が逆転した」と言われる背景には、

・node という「使う場所を選ばない」実行環境が整備されたこと

・文法の仕様がオブジェクト指向に振られたこと

が大きいと考えているが、腑に落ちる説明が意外になかったりする。

フロント系は人材不足なのかなあと思ったり。


前置きはこれくらいにして本題に入ろう。

と言っても文法上の部分的な解説なら、良い記事はまあまあ見つかる。

class に関しては『JavaScriptのclassを理解する』がよくまとまっていた。

が、気になったのは node 環境下でそのまま実行したのではエラーが出るサンプルコードがあったこと。

具体的には、

class Person {
name;
age; 
setName(name)
{ this.name = name; }
setAge(age) { this.age = age; }
introduce() { console.log(`My name is ${this.name} and I'm ${this.age} years old.`); }
}

export default Person;

というクラス Person (person.mjs) があった時、これを他のファイル(test.mjs)から利用するには

import Person from './Person.mjs';

const person1 = new Person();
person1.setName("Alice");
person1.setAge(25);
person1.introduce();

としないと Cannot use import statement outside a module などのエラーが出る。

なんでこんなことが起こるかは、この記事あたりを読んでください。

要するに「環境によっては、一連の機能が単なる JavaScript なのか、それともモジュールなのか区別できないため、モジュールとして使う場合はそのファイルの拡張子を .mjs にせよ」ということのようです。



(適宜加筆)




2024年1月23日火曜日

イマドキのフロントエンド開発



以前に bootstrap に関して書いたが、その時は bootstrap を「手動」で導入した。

だが、イマドキのフロンエンド開発ならば、こんなことはせず、npm を使ってパッケージとして組み込むだろう。

ネットで探しても良い参考記事が見つからなかったのだが、

入門者/初心者必見 npmでパッケージ管理するための基礎

が、ほぼドンピシャの内容。

こちらでも解説記事書くかも。

→ 某先生がサンプルを github にあげてくれました。感謝!
bootstrap は導入していませんが、実用的に webpack も組み込まれています。

node-npm-webpack の最小限の構成なので、何をやっているかわかりやすい(はず)。

【アバウトな解説】
プロジェクトフォルダ、index.html などの準備
まず、プロジェクトフォルダ sample を作成し、そこに最終的に表示させたい index.html を用意する(後でもいいが何やっているかわからなくなると思うので、最初に用意しておきましょう)。
index.html の中身は何でもいいですが、例えば以下の内容。
jquery などをまとめあげた js ファイルを dist/bundle.js としたいので、script タグで指定しておく。

<!doctype html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>npm node</title>
    <script src="dist/bundle.js"></script>
  </head>
  <body>
    <h1>Hello node</h1>
  </body>
</html>

エントリポイントとして使用する index.js も用意。

import $ from "jquery";

$(function () {
  console.log("jquery");
  console.log("jquery2");
});

パッケージを利用するので "jquery" で持ってこれます。
今、何やっているかわからなければオマジナイだと思って import 〜 としておきましょう。

npm コマンド操作
コマンドラインから
$ npm init -y
として、初期化。この時点で package.json ができます。
使いたいパッケージをインストール。
$ npm install jquery
今回は webpack も使うので
$npm install --save-dev webpack
$npm install --save-dev webpack-cli
$npm install --save-dev webpack-dev-server
も忘れずに。(サーバーは他にも立て方はありますが、今回はこれで)

webpack.config.js と package.json の準備
設定ファイル webpack.config.js は手動で作成します。

const path = require('path')

module.exports = {
    entry: path.resolve(__dirname, "index.js"),  //エントリポイントであるファイルのパスを指定
    output: {
        path: path.resolve(__dirname, 'dist'),  //バンドルしたファイルの出力先のパスを指定
        filename: 'bundle.js' //出力時のファイル名の指定
    },
    devServer: {
        static: {
            directory: path.join(__dirname, './'),
          }
        //contentBase: path.join(__dirname, './')
      }
}

ここで dist/bundle.js を作成させていることに注意。

ビルド・テストしやすいように package.json に以下のような scripts を追加。

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "webpack --mode development",
    "build": "webpack --mode production",
    "start": "webpack serve --port 3000 --mode development --open "
  },

ビルド・テスト
これで準備は整いました。

$npm run build

で bundle.js を生成。

$ npm run start

で、サーバーが立ち上がり、Hello node が表示されます。
コンソールに
jquery1
jquery2
と表示されれば、OKです。


参考
webpack入門(Node.jsの導入からjsファイルのバンドルまで)』バンドルがキモ。

node.js 習うより慣れろ』内容薄い・・・。もうちょっとがんがれ。


ところで、フロントエンド開発というと Nuxt や React という話にはなると思うが、node や TypeScript の存在意義わかってないと何やっているかわからないと思うんだけどなー。





2024年1月22日月曜日

Fラン私立理系大卒


 Fランク大学叩きはネット界の鉄板ネタの一つ。

彼らのおバカな言動はいわゆるDQNに近いものがあり、ネット民たちはその香ばしい言動をネタにして楽しんでいるわけだ。

だが、この場合の「Fラン」とは私立文系を暗黙の前提としているように思う。

でも、地方にある私立理系大学は低偏差値のところが多い。

だが、こちらの方はさしてネタにならない。

ああいう大学の世間的な評判というのはどういうものなんだろう?

ちょっと興味を持ったので、地方出身の方々に聞いてみた。

「私の出身は新潟だけど、例えば新潟工科大なんかは偏差値的には F ラン私立理系大になると思う。

設立は 1990 年代だと思った(注:調べた。正確には1994年)。

新潟県はもともと、・大学が少ない、・大学進学率が低い、ということもあって、設立時には地元の期待は相当高かった。

新潟は農業県と思われているかもしれないが、長岡にはそこそこ著名な企業もあるし、燕は金属加工が盛んだ。さらに系列企業もあるわけだから、地元出身のエンジニア候補は必要。

国立の新潟大卒業生はそんなところはいかないので、こういった大学が必要とされたのはわかるし、設立当初はおかしな評判も聞かなかった。

ただ、現在はどうだろう。いくらなんでも基礎学力が低すぎる。卒業生に頼れないと思う。今から思えば、企業の成長戦略としては、こういった大学に頼るのではなく、自社育成を貫いた方が良かったのかもしれない。

高度経済成長期を夢見ていたのか、バブルで浮かれていたのか、理由はわからないが、大学に過度に期待しすぎていたことは確かだと思う。」

他の方にも聞いたが「卒業生の(急激な)質の低下を予想していなかったのでは?」という意見は同様に口にしていた。

「こんな時代だから、地元企業の雇用状況も安定していない。

ニートになるのもいるし、就職しても適応できずに独立するものもいる。
都市圏では使い物にならなくても、地方では周囲では技術方面に明るいってことで、そこまで悲惨なことにはならない。

ただ、トラブルは多いね。地元に戻るとこの手の話は無茶苦茶耳に入ってくる。
「俺はすごいことやったー」って言っても大抵の場合、全然すごくない。
抑圧されている分、自己顕示欲がすごく強いってのもある。

マスコミやネットのネタになることはないが、状況はいろんな意味でよくない。
目立たないだけ余計タチが悪いかも。

能登地震の時に、米山さんが「棄村」みたいなことを主張して物議を醸したが、そういう背景がわかってないとあの真意は汲み取れないと思う。

マッチポンプみたいなことをやっている連中の生活を保障するって意味あると思う?

地方でも「地元のエース」みたいになる人って、大抵、都市圏からのUターン組でしょ」


ざっくりまとめると「Fラン私立理系大卒は、ネット上で派手にネタになるようなことはそう多くないが、局地的に実利を伴うようなトラブルを起こすことが多い」という傾向はあるようだ。


OpenDolphin


OpenDolphin というオープンソースの電子カルテに関して、私どもの記事やかつておこなった活動などが再評価されているようなんでちょっと書いてみよう。

まず、OpenDolphin とはなんぞや?って方は『OpenDolphin -wikipedia 風解説-』を読んでほしい。
よく「オープンソースの」とか「開業医の先生が開発に関与した」と広報されていたが、実態はそんなものではなかったかなり問題のあるプロジェクトだったことがわかると思う。

実際、現役で稼働しているドルフィンはそう多くないと思う。

しかしながら私たちが関与している OpenDolphin-2.7m および関連ソフトの類に限っては再評価されてきていると思う。

例えば、グーグルあたりで「OpenDolphin」を検索すると関係者の書いた記事がいくつも引っかかる。

なんで今さら?と思われるかもしれないが、歴史的評価ともいうべき段階に入って、われわれが主張してきたことが受け入れられる土壌が出来上がっていたからだと思われる。
ようやく、という感じはするが。

標準型電子カルテ』でも触れたが、うちの代表が厚労省の班会議でこんな発言をした。

”あと、すみ分けと言っているのですけれども、今となってはいにしえのオーパーツみたいなものですが、オープンドルフィンという経産省が旗振りをしたオープンソースの電子カルテがありました。あれは、商用化は、LSCというところがある程度やっていましたが、結局売れなくて、現在はメドレーが引き取ったような形になっています。オープンドルフィンは自力運用している施設が多くて、多分その次ぐらいに私がカスタマイズしたバージョンが普及していたようですが、私は対価は一銭ももらっていませんし、サポートもできる限り無料で答えていました。  これは国がやる事業ですから、収支とか、そこら辺は私は疎くてよく分からないですけれども、過度に意識する必要はないのではないかと思います。私はクライアントソフトは、無料で配布しましたが、1日十数件ぐらいダウンロードされていました。商用化を意識したからといってそれが必ずしも普及に結びつくわけではないので、やり方は様々だと思います。”

一昔前なら、このような発言が重視されることはなかっただろう。

では、どこら辺が評価されているのだろう?

私でも思いあたることをいくつか。

一つは、動作原理の解析・ソースコードの読解を通じて、それまで言われていたことがかなりおかしいことを明らかにしたことだろう。

他には、電子カルテとしての基準を満たすために各種ユーティリティソフトを独自に開発したことも評価されているようだ。


(適宜加筆予定)

参考:

開いたいるかの都市伝説は本当だったか』現代的なドルフィンプロジェクトへの批判はこの記事から始まったと言っても過言ではないでしょう。

ソースコード嫁』彼にしては珍しく推測も入れてます。しかし、誰しもが思っていたことでしょう。歴史的な評価が必要になったことを踏まえてようやく記事にしてくれました。

@masudanaika による個人情報流出ツィート動画の方で「ドルフィンをある意味象徴するような人」と増田内科(当時)増田茂医師を評しています。こういう記事を書く人ではないのですが、うやむやにするわけにはいかないということでしょう。

Dolphin プロジェクトと皆川和史』混乱を来した原因を具体的なエピソードを挙げながら解説しています。動画も(わかる人には)刺さる内容でしょう。



ミリタリー界のPコート

 秋葉ちゃんが『ヲタ、冬を乗り越える』で私が密かに「ミリタリー界隈のPコート」と呼んでいる N-3B に関して触れていた。

おおー、そこに注目するようになったじゃん、成長するする

とお姉さんとしては、喜んだ。というのは、このコートはこれまで過小評価であったと思う。


ミリタリー系のコートといえば、モッズコートがそれなりの地位をしめている。

が、これはヲタ系の男子が着ると「ぼわっとしてカッコ悪い」、「着こなしが難しいのに雑に着ている」、「正直ダサい」と女子ウケはかんばしいものではなかった。

(なお、女子がモッズコート着るときはそれなりに気を使ってます。街中で見かける女子はみんな可愛く着てるでしょ)

なんで、N-3B 行かないんだよっ!

と心の中で叫んでいたのだが、通じたか?

N-3B のいい点を挙げておく。

・組み立てて使うことを前提にデザインされているモッズコートと比較して作りがしっかりしている。(極寒での使用が前提なので当たり前)

・防風性&防寒性ともに高いレベルにある

・着丈的にはハーフコートなので取り回しが楽

・(AVIREX VINTAGE は特に)セージグリーンの発色がキレイ

いいことづくめ(笑)。

つか、服としての完成度高いから、羽織っただけでも様になるんよ。

カジュアルおしゃれめに振れば

 N-3B + ベージュ系のチノパン/カーペンターズパンツ + 赤系のスニーカー/ブーツ

は、鉄板。例えヲタ系であってもこの着こなしでサマにならない男子はもう素材自体に難があると言っていい。


ちなみに、女子でも大柄な人は着こなせると思う。


2024年1月19日金曜日

標準型電子カルテ

国が進めている医療DXの一環として標準型電子カルテというものの開発が予定されている。 

厚労省が主催した標準型電子カルテの第一回技術作業班にうちの代表も出席したのだが、その議事録が公開されている。


X(twitter)の医療情報クラスタは結構盛り上がっていた模様。

で、彼は議事録上では4回発言している。
(追記)彼がコメントしたことなども追記した。

① 自己紹介〜システム提案

○PHAZOR PHAZORと申します。
 私は、精神科の医師なのですけれども、一般医療人の意見でもいいのかと勘違いしてアンケートを出して、参加させていただきました。ありがとうございます。一応、会社も持っていますが。
 資料を見ていて、私は精神科医ですから、そう思うのかもしれませんが、一般病院と精神科病院は区別されていると感じます。厚労省の先生もおっしゃられたと思うのですけれども、電子カルテの普及率は、200床未満の一般病院で5割程度ですが、精神科病院はもっと少なくて、民間の調べだとトータルで40%ぐらいです。そして、その操作性や完成度にみんな満足しているかというと、そうではなくて、ほとんど満足していないと思います。
 今日は幸いにもいろいろなメーカーの皆様が来られているので、お願いしますが、精神科病院用の電子カルテだとか、あるいは汎用電子カルテに精神科病院に求められる特有の機能、例えば隔離拘束診察の記載機能などを付け加えた電子カルテは、その分コストがかかると思いますが、そういうものをつくっていただければ、より普及が進むと思いますので、ぜひとも検討していただければと思います。
 それと、私はもう一つ完全に勘違いをしていたことがあります。私がクリニックなどで外来診療をやる場合、ブラウザータイプのクラウドのカルテを使わせてもらっています。ただ、ほとんどの臨床医はこの形態がベストだとは思っていなくて、通信障害が起こった場合、一時的に診療がストップします。東日本大震災のときは、通信障害に加えて端末も駄目になりましたから、以前の処方内容がまるっきり分かりません。医学的にはいいことではないのですが、やむなく、臨床的な感で薬を出したことがあります。
 そこで、3-tierのクライアントサーバーシステムを提案させていただきました。施設特有のカスタマイズを入れたい場合、クラウドにフロントエンドサーバーとバックエンドサーバーの両方を入れるぐらいだったら、思い切ってフロントエンドサーバーを施設内に置いてしまって、例えばそこでバックアップを取るとか、大抵の場合、既存のオーダリングシステムとレセコンがあるので、それらとフロントエンドサーバーをつないでしまえば、施設特有のカスタマイズはシンプルにできるとすごく単純に考えていました。全部の機能をクラウドに上げるのは前提なのですか。そこがよく分からなかったです。

コメント
いわゆるベンダーの人間ではないため、どういう経緯・意図で出席したかまず説明する必要があると考えた。その際に、電子カルテの開発に医師目線が必要だと考えたため、東日本大震災時のエピソードを披露した。そこから望ましいアーキテクチャの話に繋げた。
ちなみに能登半島地震が起こったのはこの後。医師であれば災害時の堅牢性みたいなことは考えるが、ベンダーはこの視点が抜けがち。その点は意識してもらうように工夫した。

② ORCAやオープンドルフィン

○PHAZOR 度々すみません。
 大抵のクリニックはORCAを使っているところが多くて、ORCAはAPIもほぼ完全に開放されているし、データベースの構造も何ならわかるので、直接データを抜いてきたりもできます。すごく便利だと思います。私は使ったことがないのですけれども、カルテとつなげないようなレセコンは、現在あるのですか。私、現状がよく分からないです。APIの開放もできないようなベンダーのレセコンの面倒を見る必要があるのか疑問だと思います。
 あと、すみ分けと言っているのですけれども、今となってはいにしえのオーパーツみたいなものですが、オープンドルフィンという経産省が旗振りをしたオープンソースの電子カルテがありました。あれは、商用化は、LSCというところがある程度やっていましたが、結局売れなくて、現在はメドレーが引き取ったような形になっています。オープンドルフィンは自力運用している施設が多くて、多分その次ぐらいに私がカスタマイズしたバージョンが普及していたようですが、私は対価は一銭ももらっていませんし、サポートもできる限り無料で答えていました。
 これは国がやる事業ですから、収支とか、そこら辺は私は疎くてよく分からないですけれども、過度に意識する必要はないのではないかと思います。私はクライアントソフトは、無料で配布しましたが、1日十数件ぐらいダウンロードされていました。商用化を意識したからといってそれが必ずしも普及に結びつくわけではないので、やり方は様々だと思います。

コメント
システム・アーキテクチャの軽めの提案ができればいいくらいに考えていたが、「レセコンまでは導入しているが、電子カルテまでは導入していない施設が多い」という状況が提示されたため、これは ORCA のことを言っているのだろうと補足的な意味を込めて発言した。
ORCA と日本医師会の関係が特異であるため、触れにくいという雰囲気はあった。
だが、そこをスルーしたのでは、このプロジェクト自体が失敗すると考えた。
ドルフィン(OpenDolphin)に言及したのもほぼ似たような意図。民間ベンダー独自のプロダクツではない場合(ドルフィンプロジェクトには行政も関与している)、どういうことが起こりうるのか提起しておく必要があると考えた上での発言。

③ 医療画像の取り扱い

○PHAZOR 度々すみません。
 今、画像の話が出ていたので、えっと思ったのですけれども、今すぐ画像をクラウドに上げる必要はないでしょうね。そこまで求められていないと思うし、DICOMなど医療画像を保管するPACSサーバーのクラウド型があるのは知っていますが、DICOMの仕様的に多施設で使うことはあまり前提とされていないので、データ量の問題からいって、PACSサーバーは大抵院内に置いていると思います。
 富士通Japan様がおっしゃった軽量なプログラムとか、アプリケーションティア、フロントエンドサーバー、呼び方はなんでもいいのですけれども、そういったものを院内に置いてしまったほうが画像を引っ張ってくるときは楽です。ご存知だと思いますが、例えばDICOMをブラウザ上でJPEGやPNGなどで描画させるのであれば、PACSサーバーに患者IDを問いかけて、これこれのスタディーを持ってこいという命令を出して、DICOM-汎用画像変換サーバーで、DICOMからJPEG変換、DICOMからPNG変換などをすれば、ブラウザ上で表示はできます。それをクラウドでやろうとすると、かなり難しいと思います。院内にDICOM-汎用画像変換サーバーまではいかなくても、専用の軽量なプログラムを置いてしまえばできますので、画像ということであれば、いきなりクラウドに上げるということを考えるのはあまり現実的ではなくて、院内でケアしたほうがうまくいくと思います。
 私は、OsiriXのオープンソースバージョンのコントリビューターをやっていました。その程度の素人の意見ですが、ご高配のほどよろしくお願いします。

④ シメの言葉

○PHAZOR 度々すみません。
 この班会議に出るに当たって、仲間内で必ずしも出席できるかわからないけれど、アンケートを出してみないことには始まらないみたいな感じでアンケートを出しました。そのときに、周囲のお医者さん連中から言われたのは、今まで例えば国がやったHER-SYSであるとか、G-MISやVRSなどは、開業医の人からするとすごく使いづらい、出席した場合にはそのことを主張してほしいと言われました。東京都医師会の某先生はかなりお怒りの様子でした。リリース前に試用させてくれないと。今回はα版があるから大丈夫だと思うのですが、突然ぽんと出てきて使ってくださいというのが今まででした。コロナのときはしようがなかった気もするのですけれども、そういうことは結構言われました。
 標準型電子カルテではアジャイルなどを意識したほうがいいと思います。ITに関して、割と意識が高めの開業医の先生などもいらっしゃいますから、そういったところにベータテストみたいなことをやってもらって、なるべく早くフィードバックを得る。プロトタイプを早くつくってユーザーに使わせて、フィードバックをもらう。私などが言うよりも、ベンダーの皆様方のほうがよく御存じだと思いますが、特にウェブシステムの場合、みんなが使うということを目指していますから、そちらのほうが有効だと思います。
 私は基幹病院などに勤めたことがあります。基幹病院クラスの電子カルテ導入時には、ウォーターフォール開発方式でおこなわれ要件定義などですごく時間がかかる。標準型電子カルテでは、開業医も含めて、中小の病院、精神科病院も今後使うみたいなことになると、そういったユーザーにいきなりぽんと渡して、はい、使ってくださいと言っても、多分使わないと思う。アジャイル開発方式も意識してやっていかれるといいと思います。
 あと、これは私もよく分からないのですけれども、COCOAのとき、多重下請けなどが問題になりました。別の質問になってしまいますが、再々委託みたいなものは禁止とか、そういうことはできるのですか。可能であれば、後で答えてほしいです。
 多くの医者は、データを人質に取られることをすごく嫌っています。最近はベンダーさんもその点を意識してくれて、ネット経由でクラウド上にあるカルテの記載内容をJSON形式でローカルに持ってこれたりだとか、格好いい機能を入れてくれたりしています。けれども、ひと昔前はデータ移行だけでも何百万も取られたり、下請け構造があるものだから、本社の人間がデータ構造を把握していないということもあった。開発元ならば、データベースを見れば、データベース単体からでもある程度データ抽出はできないとおかしいはずなのに、それができないみたいな奇妙な状況があったと思います。そこら辺をすっきりさせながら、標準型電子カルテをつくっていってもらえたらいいと思っています。

最初と最後をキメて、あとは流れにそって個別事項を答えるとか・・・やるなあ。



2023年11月23日木曜日

ユーザーとか取り巻きとか


 私の所属する会社(休眠がちだが)は、集まったメンバー(学生バイト含む)の仲がよく、とてもよくまとまっていると思う。

この点に関してはなんの不満もないのだが、リリースしたソフトのユーザーやなんか微妙な感じで擦り寄ってくる人たちについては、なんの不満もないかと言われるとちょっと微妙。

ユーザー

ユーザーに関しては、一般的な水準で見れば良質だとは思う。
なにしろクレーマーのようなユーザーは一人もいなかった。
みんな、お行儀よい。おとなしいと言っていいかもしれない。
無い物ねだりかもしれないが、おとなしすぎて物足りない感じは正直ある。

例えば、OpenDolphin-2.7m 系列(ただし、これは代表のまったくの個人制作)に関しては、最近のユーザーの関心はもっぱらデータ移行だろう。
具体的にどことは言わないが基本設計自体がもはや古臭く、新規の導入は勧めていないし、私たちの興味は「標準型電子カルテ」を意識した新規のシステムで、実際、2.7m シリーズはメンテ程度しかやっていない。
だから、データ移行の必要が生じた際には「◯ヶ月程度を目処に、XXという電子カルテ向けにデータコンバートしてほしい」と明快に意思表示してもらわないと動きようがないのだ。準備にもそれなりの時間がかかるのだから。
どうも見ていると、OpenDolphin HTML/PDF Viewer あたりをばら撒いてくれることを期待しているようなのだ。
あちこちで「できない」とはっきりと言っていると思うんだけど?

”Q4 データ移行ツールのバイナリ・ソースコードなどは配布・公開しないのか? 

A4 これ、過去に商用開発元の方から似たような要望を受けたことがあります。 一瞬、私もそうしようかと思いました。が、

  OpenDolphin のカルテを途中経過版も含めて一括書き出し

  →途中経過版の一部を削除など加工

  →加工したデータを再度、OpenDolphin などの電子カルテデータベースに戻す

 という使い方をしてしまうと立派な「改竄」ツールになってしまうので、思い直してやめました。”

OPenDolphin-2.7m(系列)FAQ』より

これはおそらく
・以前に実行可能なファイルバックアップシステム付き OpenDolphin-2.7m クライアント
(いわゆる OpenOcean クライアント)を無料で配布した
・オープンソースプロダクツに「無料」というニュアンスを強く感じている
から、「どうせ、そのうち無料で配布してくれるんだろう」と安心しちゃっているからなのかなあと思う。

大事なことなので2回言いますが、ないですよ。

あとメンズ陣がたまに言うには「全然、勉強してないし、その痕跡も見せない。作業現場に来て暗い感じで、突っ立っているようなものなので、何も言葉がかけられない」んだそうだ。
ここら辺は、彼らはシビアだ。


取り巻き

医師(医学生)+αの肩書持っているような人たちだから、擦り寄ってくる人がいるのは想像にかたくない。

ただ、異口同音にいうのは、そういう人たちは「距離感がおかしい」んだそうだ。

お金になりそうな何かをする際には、どこかで企画やアイディアを立てるはずだが、それを(意識的に)チラ見せしているのに反応しない。

で、努力の甲斐あってモノになり始めると、突如として連絡が入り始めるんだそうだ。

まるで詐欺師のような行動パターンですね。


与えられることに慣れすぎていると・・・

私たちのグループはまだ成長段階だと思っている。

だから、運がいいと思いがけない方角から評価されることがある。

最近では、医療DX絡みで国から直々の選定を受けた。

主要なメンバーはそちらの作業に持っていかれることになるだろうから、これまでリリースしたプロダクツのリファインは(不本意だが)どうしても滞る。
ましてや、ユーザーが反応してくれない箇所などは最悪放置すらあり得るだろう。

日本のユーザーは、成熟したメーカーのそれなりによくできた製品(尖った部分はないが全体として80点みたいな製品)を使うことに慣れている。
私の個人的な印象かもしれないが、アメリカはここら辺はかなり違う。
名もなきベンチャーのピーキーな製品がしれっと販売され、一般市民もそれにチャレンジする。いかにダメな部分があろうが、魅力的な機能があれば、その製品のファンになってくれる。

このような消費行動の差が、日本のユーザーの一種の甘えにつながっているのかもしれない。

人生の多くの場面で当てはまることかもしれないが、「与えられることに慣れすぎている」と何かを失うのかもしれない。