- ベストアンサー
電子カルテのＶＢ開発
よろしくお願いします！ 一ヶ月程度、某メーカーの電子カルテのパッケージの開発をすることになりました。私はこれまでパッケージと呼ばれるような大規模システムの開発はしたことがありません。ＤＢデータを画面に表示させたり、ファイル出力させたりする程度のものしかプログラミングしたことがありません。業務知識も全くありません。開発経験がごく僅かかな私にできるのかとても不安です。電子カルテといっても沢山あるので、答えるのは難しいと思いますが、開発経験のある方のご意見やお話を聞かせていただけないでしょうか。 電子カルテといっても、単なるカルテだけではなく沢山の機能があるのですね。私がどんな機能の開発をするのかすら分からないので、答えようがないと思いますが、何か些細なことでも、開発の話を聞かせてください。 言語：ＶＢ６．０ どうぞよろしくお願いします。
- hekiji
- お礼率76% (90/117)
- SE・インフラ・Webエンジニア
- 回答数7
- ありがとう数6
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
なかなか凄そうなソースですね。 >>仕様書に全ての仕様が記載されてないようで＾＾； まあ、これはよくある話ですね。まあ、仕様書よりソース見るほうが早い。ソースから読み取るのが困難な部分だけ記載してあればいいと思う。 >>共通関数や制限事項、禁止事項はたくさんあるようですが、いくつかソースを見た結果、統一感は感じられませんでした。モジュール構成もバラバラで。 大規模システムといっても、構造体とか、共通関数などは、少人数で作成すると思います。また、最初の何本かのプログラムをコーディングレベルの中心になる方が作り、それらのコードを見本として作成すれば、いちおうの統一感って出てくると思います。 でも、そういうように「統合電子カルテ」って思想で、大きな予算を持って開発されたのじゃあなく、カルテにまつわる業務の部分ごとに作成された小さなサブシステムを寄せ集めただけなのかもしれませんね。例えば、受診予約システムとか、Ｘ線画像システムって単位で作っていたものを、寄せ集めて、なんとか格好をつけようとしているとか。 そうなると、設計思想も製造思想もバラバラ、できあがったコードに統一感が無いのも納得。 まあ、そもそもＶＢで作ると、Ｃ、Ｃ＋＋等よりも、モジュール化が難しいので、統一化が困難になりがちです。 >>大規模システムに・・・・ >>コメント（コードレベルのコメント、プロシージャレベルのコメント、モジュールレベルのコメントのどれも）が殆ど殆ど無いのは、よくあることなのでしょうか。 ソースに統一感っていうのが無くても、今まで仕事で見た大規模なＶＢソースは、コメントはしっかり入っていましたね。プログラミングの一般常識を全く学習していない方が作ったか、知っていても、「どーせ、作っても、使いものにならないシステムだ」なんて思いながら、いいかげんに仕事したか、もうコメントを記述する気力・体力も消えた、納期大幅超過状態で作られたのかもしれませんね。 少なくとも、完成したソースを、管理者がざっとでもながめたら、一発で判ることです。そういうことが全くされていないデタラメなこともＯＫの状態で生まれたコードなのでしょうね。
その他の回答 (6)
- don_go
- ベストアンサー率31% (336/1059)
＞電子カルテのパッケージの開発をすることになりました。 hekijiさんが開発責任者としてシステム設計を行うので なくて、単なるPGとしての参加であれば、SEが作成した 仕様書通りに作成するだけですから、業務知識の有無は 特に関係ありません。 プログラムも多くの人間が参加する大規模システムでは 各人が勝手気ままに作ると後の保守が大変なので、共通 関数が用意されている事が普通です。 ＃雛型となるプログラムが有りそれを元にして作成する ＃事も有ります。
お礼
ありがとうございます。レスが遅くなり申し訳ないです。 ＞仕様書通りに作成するだけですから 仕様書に全ての仕様が記載されてないようで＾＾； 共通関数や制限事項、禁止事項はたくさんあるようですが、いくつかソースを見た結果、統一感は感じられませんでした。モジュール構成もバラバラで。 大規模システムに・・・・ コメント（コードレベルのコメント、プロシージャレベルのコメント、モジュールレベルのコメントのどれも）が殆ど殆ど無いのは、よくあることなのでしょうか。 これまで小さなシステムしか経験がありませんが、プロシージャ一つにしろ、概要や引数の説明、戻り値の説明など書いていたので、大規模システムなら余計に書いてあるものだと思っていたので驚きでした。
- lv4u
- ベストアンサー率27% (1862/6715)
No.3のお礼へのレスです。 >>小さいシステムの仕変のような感じなのでしょうか。 仕事をとってきたときの思惑は、「パッケージができているから、ちいさな変更だけで納品できて、変更工数少なくて儲かるだろう」だったようです。でも、パッケージには、いろいろ問題あって、仕様変更も難しい。しかも、納入先の病院の要望は、あたりまえだけど、病院の事情があって画一じゃあないから、変更は大きいようですね。ただ、「仕事の進め方が下手！」っていうのもあったみたいです。「なんでも仰るとおりに変更します！」って安請け合いしたように見えましたから。簡単そうな変更に見えて、実際にはＤＢの項目追加が必要なこともあるわけで、そうなると結構大変になりますからね。 >>大手だからしっかりしてると思ってたので驚きました。 大手から発売している製品に見えて、実際は、単なるブローカであって、開発元は小さな会社っていうことも多いようですよ。そもそも、「パッケージとして開発した」のじゃあなく、Ａ社向けに作ったけど、「パッケージという名称をつけて、ほかにも売ろう」ってことも多いようです。ですので、制限事項が多かったり、修正が難しかったりするわけですね。 昔、「大手のＦ社の販売しているパッケージだから安心」って採用したら、ろくでもないシロモンで、同業エンドユーザの電算部門が作ったシステムに変更ってこともありました。
お礼
ありがとうございます。レスが遅くなり申し訳ないです。 とうとう勤務が始まりました。 lv4u様のおっしゃるとおり、ＯＪＴは皆無です。派遣先企業の方には「この人に何でも聞いてください」と言われましたが、その聞いても良い人がまた別の会社の人です。業務知識の無い私を馬鹿にしている感じです。 販売しているパッケージなのに、仕様が仕様書に全て記載されている訳でもないらしいです＾＾；細かくはソースを追えと言われました＾＾；作りも複雑だし、制限事項も多いし、ソースにはコメントがほとんどありません。共通関数の仕様すら見えません。初めての私にはハードルが高いようです。
- stone_x
- ベストアンサー率25% (1/4)
この質問が成立するところがすごいですね。 会社の先輩とか、某メーカの担当者に聞きながら（助けてもらいながら）１つづつ解決していくしかないんじゃないでしょうか。そうしていくうちに、電子カルテのことも次第に解ってくると思います。できれば、その後のユーザの声なども聞けるポジションであれば、いろんな関連業務知識も付いてくるのではないかと思います。その辺がＯＪＴと呼ばれるあたりではないかと思います。それらを「吸収しよう」と前向きに取り込む質問者さんの姿勢が一番大切なのじゃないかと思います。
お礼
ありがとうございます。 >この質問が成立するところがすごいですね。 人一倍の心配性で何か少しでも聞けたら嬉しいなと思ったのですが、何をどう開発するのか判っていない段階で投稿しても何をどう回答して良いのか分からないですよね。質問する側が何も情報を出せないのですから。そんな中、みなさんがご存知のことを教えてくださり・・・本当にありがたく思っています。 医療系だとかパッケージとかって聞いてビビッてしまっていました。日に日に身に付けていくものですよね。最初から分かる人なんていませんよね。もし業務知識が必要なレベルの業務を与えるなら、条件として出してきますよね。 ＶＢも自信はありませんが、ＶＢも業務のことも身に付けていきたいと思います。
- lv4u
- ベストアンサー率27% (1862/6715)
電子カルテではありませんが、医療系のＶＢパッケージ開発やっているのを横で見ていました。新規開発ではなく、機能拡張の作業でしたが・・・。（私は、ＶＢ嫌いで通っているので、仕事は来ない） >>開発経験がごく僅かかな私にできるのかとても不安です。電子カルテといっても沢山あるので、答えるのは難しいと思いますが、開発経験のある方のご意見やお話を聞かせていただけないでしょうか。 ベースパッケージは他社が作成していましたが、納品先の医療機関ごとに、仕様が変わるのは当然ですよね。で、開発中や納品・運用開始後に、バグが判るわけです。そうすると、障害の発生した医療機関のソフトはとりあえず修正しますが、同様なバグが他社納品分にも隠れているわけです。でも、それらをすぐに入れ替えるかどうか不明。さらに、ソースのバージョン管理がきっちりされていないので、「どれが最新なんですか？似たのが沢山あるんですけど・・・」って声が上がったりしていました。 Ｃ言語等だと、バージョン管理がやり易いので、しっかりやるでしょうが、ＶＢとなると、ちょっとやりにくい面があって、以前の会社もいいかげんみたいでしたね。 そういうことで、開発元のバージョン管理がでたらめだったことと、過激な勤務でパッケージ開発会社のメンバーに病気退職の人が続出したようでした。 それから、設計に当たっては、最低レベルの医療知識が無いとできないと思いますし、医療現場の方たちの仕事を理解していないと、トンデモ仕様なパッケージになる可能性が大きいでしょうね。 >>なぜ私は雇われることになったんだろう・・・って思います。 受注しちゃったからでは？で、人手不足だから。営業は、「開発はあいつの仕事。営業の俺は、受注してノルマ達成すれば終わりで、後のことは知らん！」ってスタンスが多いですし。 私なら、「ＶＢ６．０でＤＢ使って大規模パッケージ開発」という時点で逃げます。
お礼
ありがとうございます。 ユーザーは１つではないので、各納入先によって仕様を変えることも大変なんですね。小さいシステムの仕変のような感じなのでしょうか。バージョン管理やバグ管理も大変そうですね。これまで私は派遣で、次の派遣先と同じグループ会社で何度か働きましたが、どこもテキトーな会社だなというイメージを持ちました。大手だからしっかりしてると思ってたので驚きました。さすがに製品として販売しているようなので、管理されているでしょう。 人手不足ではあるようです。とりあえずＶＢ経験のある人間を雇っただけだと思います。 私は.NETの経験もなくVB6までしか経験がないので、逃げられないのです＞＜CやJavaを習得しないと今後は厳しいですよね。
DBは何を使うのですかね 画面部分だけがVB、DB（Oracleなど）、処理部はVC（I/O部分とかストアドプロシジャのキックとかです） って感じになっていることが多いんじゃないかと思います なので、VB側にとっては画面設計が大きな割合を占めるんじゃないかと思います 大きなプロジェクトとかパッケージソフトとかだと画面などのデザインは専門の方がやったりすることもあります 統一感がないといけないですから
補足
ありがとうございます。 ＤＢは自社オリジナルのようなことを言っていました。 SQLの基本を知っていれば問題ないといった感じで、 ＤＢのことはあまり気にしなくて良いと言われました。 大規模だから一つの言語で開発という訳ではありませんね。 上の人が言っていたことなので、本当かどうかは分かりませんが、 設計をすることはないと言っていました。画面の処理をＰＧするのが私の担当かもしれませんね。始めてみないとわかりませんが。 パッケージだからデザインもしっかり専門の方がしますよね。 勉強になります。
- miracle3535
- ベストアンサー率20% (306/1469)
誰が使うか分からない状況を考えてください。 どんな操作ミス（Y/N等）を行ってもやり直し等を行えて正しく計算処理をきるプログラムにすることです。 パッケージソフトの基本中の基本です。 あまりのイロハのイで参考にならなかったかな。すみません。
補足
ユーザーが誰か全く分からないソフトを開発したことはありません。 できる限りどんな操作をするかを考えながら作りましたが、「この操作はしないでください」「この内容のチェック処理はしません」といった前提条件を設けることもありました。パッケージソフトには許されないことですね。 そのほか、パッケージソフトのイロハも聞かせていただけると嬉しいです。 なぜ私は雇われることになったんだろう・・・って思います。かなり高レベルの開発ですよね。。。。。
お礼
レスありがとうございます。 大変お礼が遅くなり申し訳ありません！ 数ヶ月ＰＧしました。 あのシステムを導入している病院があるのかと思うと怖いです。 コーディング規約もあってないようなもので、ＰＧによって様々でした。バグがバグを生み、そのバグがさらにバグを生んでいました。時間がいくらあっても終わりは無いなって感じでした。同じ関数名が付いていても、機能によって違う動作のものもいっぱいありました。 完璧な動作をしなくても早くＰＧ完了した人がデキル人だという扱いがされていたように感じます。私は仕様が判らないままＰＧしたくないし、テストもしっかりしたかったので時間がかかってしまいました。 私がコメントを書いていたら「コメントは書く必要が無い」と言われました。こんなこと言われたのは初めてです。これまでは「誰が見ても解りやすいようにコメントを書く」を心がけていました。 >まあ、仕様書よりソース見るほうが早い。ソースから読み取るのが困難な部分だけ記載してあればいいと思う。 結局はソースを見るんですけどね。条件など記述していないと判らないようなことでも、業務知識が無い人でもプログラマの判断で組んでいました。条件が違っていても動けば良い感じでしたので。 仕様書などの資料も同じようなものが沢山ありましたが、どれもこれも中途半端で、記述されていないことも沢山だし、誤りも沢山でした。 >少なくとも、完成したソースを、管理者がざっとでもながめたら、一発で判ることです。 デキル人（＝早くＰＧ完了した人）のソースは信頼して見てないようです。 ある意味、勉強になりました。