あいかわらず、開発作業に没頭しつつも
合間合間に、雑務のような作業が回ってきて
年末からのシステム開発が完了に至っておりません(^^;)
取り組んでいたシステムそのものは、
業務の見直しがあったため、運用開始が未定なのです。
ただ、未定とは言っても運用する可能性は高く、
完成させておく必要はあるのですけどね。
開発している者としては「早く完成させなきゃ」と思いつつ
「いつ使うか判らないんだからゆっくりでいいや」なんて
考えちゃうのも事実なわけで(^^;)
で、合間に飛び込んでくる依頼も
実は「え？それって必要か？」というような
まるで思いつきのようなものばかり。
そもそも業務のシステム化ってのは、
それなりの工数が必要なわけで、
ユーザ企業だと「他部署の担当者の時間を使わせる」わけです。
ですので、依頼する側の部署も
システム化することによって
「自部署の業務遂行に、これだけ役立つ」ことを
しっかり意識したうえで、
組織として利益につながる前提で依頼せねばいけないはず。
ところが、
「何となくこういうデータが見たいなあ」で
システム化してほしい、と言ってくるヤツがいる。
仕様が曖昧ではシステムは開発できないので
「何を元に、どういうアウトプットが欲しいのか」
とヒアリングをするのですが、
思いつきなので、明確に答えは出ない。
で、「それじゃあシステム化できないッスよ」となる。
多いんですよ、まるでExcelファイルの作成依頼のように
簡単に言ってくるヤツらが(-"-)
あ、そうかExcelでもいいのかもしれないな。
でも、Excelってのも表の見栄えやら、
センスがいる部分もあるしなあ。
いやいや、Excelなら自分らで作ってみてよ、ねえ。
さて、先週悩んでいたのは、
画面上にＰＤＦファイルへのリンクを作り,
その横にそのＰＤＦファイルの作成日を表示する、というもの。
web環境（社内web）のASPを使っているので
VB ScriptとJAVA scriptを駆使しまくっているのですけど、
ネットで調べたときに「JAVA scriptで実行するためには…」を
先行で調べてしまったために
「ActiveXObjectでのファイル作成日取得方法」に行きつき、
そこから迷走が始まってしまったのでした。
ActiveXObject（XMLHttpRequest）を使ってwebで
「ABC.pdf：2021年1月25日」などと表示したいわけですが
その行を表示する際に作成日がまだ取得できておらず
「ABC.pdf：undefined」になっちゃうんですよね。
（undefined：「見当たりませんぜ、ダンナ」という意味）
ほんの一瞬なのですが、画面表示のほうが早い(^^;)
悩みました(^^;)
いろいろとトライしてみたのですがダメ。
もう作成日付表示を諦めようか、と思った時、
なぜか、ホントになぜか思いついたのです。
VB Script使ってデータベースを検索しているではないか、
ということはVB ScriptでFileSystemObjectを使ったらいいじゃないか、と。
あっけなく解決いたしました。
web画面を表示しているプロセスでActiveXObjectを使うのでは
当然処理中の画面表示のほうが早い。
で、ファイル作成日付取得前に画面表示が終わる。
でも、画面loading中のVB Scriptで取得すると、
画面表示時にはファイル作成日付を取得後に画面表示が動く。
要はそういうことだったのです。
第一線の技術者の方のセオリーは知りません。
でも、とりあえず実現には至った。
ここ１、２年で知った知識をバンバン引き出しに放り込んで
引き出しの中を整理できていなかったせいですから自業自得かも。
と、
こんなふうに、よその技術者ならすぐに解決しそうなことを
悩んでは何とか解決して、というのを繰り返しています。
昨年暮れからの開発上の壁も、
同じようにどうにか破りつつここまできています。
いったい…こんな仕事の進め方でいいのか、悪いのか…。
ハー…(^^;)
いやあ、今日は寒かったですねえ(^^;)
いやいや、まだ１２月だったか。
冬はこれからですもんね、仕方ない。
さて、気合入れて職場に向かい、
どれほど開発が進んだのでしょうか。
実は、システムでアウトプットする帳票があり、
「そのサンプルを明日の午後に検討したい」とのことで
今日は帳票設計に費やしました。
帳票と言っても、html(aspx)で作成するので
作成したものを画面上でおおまかなレイアウトチェックし、
そのaspxファイルをＰＤＦファイルに出力して
そのＰＤＦ上でのレイアウトチェックをするので、
やたら時間がかかちゃうのでした。
以前にも書きましたが、
ちょっと構造の変わったグループウェアなので
ブラウザの印刷機能で
画面をそのまま印刷することができないのです。
ですので、画面イメージで作って
それをwkhtmltopdfというツールで
ＰＤＦファイル化したものをユーザは開く、
そんな仕組みにせざるを得ないのでした。
で、今日は印刷用の画面をせっせと作成。
今日も２１時過ぎまでやるかなあ、と思いましたが
昨日の帰り道、ヘンな時間に職場最寄り駅で乗ると
乗り換えも、電車を降りてからのバスも
ものすごく接続が悪かったので、
今日はあらかじめ調べておいたのです。
で、職場を２０時４０分に出るとちょうどいい。
無事、全て２、３分の接続で帰宅できました。
ま、それでも２２時少し前でしたが(^^;)
明日は帳票の続きを先に取り組んで、
またシステム本体の開発に戻ります。
明日は残業ナシ。
速攻で帰らないと１９時キックオフの試合、
ＤＡＺＮ観戦に間に合わないのであーる。
今日も一日開発に集中でした。
ただ、昨日家で検討した手法がイマイチ上手くいかず
今日の達成度は50％というところ。残念(^^;)
はー、シンドイなあ。
２１時に職場を出ると、電車やバスの本数の関係で
帰宅が２３時近くになってしまうのでした。
それでも達成感があればいいのだけど、
悶々として職場をあとにするのはガッカリです。
で、帰り道、歩きながら
データベースがどうの、処理の順番がどうの、と
ブツブツ言いながら帰ってくるのです。
あ、人がいるところでは口には出しませんけどね。
さあ明日、全体からみて８割くらいまで
進んでくれるといいのだけど。
だって水曜日は速攻で帰って
ＤＡＺＮ観戦ですから。
明日、勝負だぞ！
今晩は、めずらしく２０時過ぎまで残業でした。
「なんだ、２０時なんて残業に入らねえよ」
なーんて言うなかれ、
９９％の人が定時の１７時で帰る職場です。
もちろん夜勤の看護師さんはいますが、
自分以外、デスクに向かっている人なんてまずいません。
そう、例の厄介事、うーん厄介というのはもうやめましょう。
緊急で開発のシステム。
今日は、とりあえずアウトラインを考えて、
データアクセス部分以外のデザイン的な箇所に着手。
ほぼイメージどおりの動きが見えてくるまでできました。
そして、またまためずらしく
プログラムソースを持ち帰り(^^;)
この土日に少し考えてみようというわけです。
ホントに土日にやるのかあ？
ずーーーっと、それこそコツコツと開発は進んでいるのですが。あ、これはグループウェアという大きなシステムの中で、ひとつひとつ機能を充実させているということなので、ひとつの機能の開発を終えたら、じゃあ次はコレというようなことですので、ある意味エンドレスともいえるのですけどね(^^;) 今は１１月から稼働させる予定の機能のテストと不足部分の追加などを行っているのですが、実は今までＰＣの配備がされていない担当者のところにもＰＣを設置しないといけない機能でもあります。現場作業に従事している方向けなのですけど、作業控室はあるのにＰＣについては別の部署にあるものを借りているとのこと。「ＰＣなんてほとんど使いませんよ」とは仰りますが、でも逆に作業の合間や休憩時にすぐ自分のところでＰＣを使えるならそれが一番です。ＰＣジプシーにさせたらいけませんよね。というわけで今週はその作業控室に配線を行いＰＣを設置。無事に１１月に稼働開始する機能を使っていただく準備が完了、というわけです。そう、組織内で動くシステムの提供は、ただ「作る」だけではダメなのです。「現状の分析」と「準備」そして「説明」。それがあって初めて皆さんが同じように使えるようになります。システムを作って「よし、できた！」なんてのはほんの入り口に過ぎません。システムの導入を行ってスムーズに運用するには、大勢の方の理解と納得が必要なのですから。
今週セットアップしたある部署のPC。
まあ、さるエラい方のweb用PCなのですが…。
ソフトウェアなどの環境はすぐに移行を終えたのですけど、
メールの移行につまずいて、今日やっと完了でした。
今までのメーラーがWindowsLiveMailだったことで
今回Office導入PCだったこともあり、Outlookに変更しました。
このLiveMailからOutlookへの移行は
一度メールを全て旧PC上でOutlookに変換したあと、
新PCに移すためにそのOutlookデータを取り出す（エクスポートする）のです。
ところが、あまり深く考えずに作業していましたが、
これがミョーに時間がかかる(^_^;)
おかしいのであらためてLiveMailの各フォルダを確認すると…
どひゃあ、メールが全部で２万件ほどあります(^_^;)
２万件ですよ、ニ・マ・ン・ケ・ン。
今回の移行元PCも６、７年前に移行していたようなので、
その時にも前のPCからメールを全て移行していたようですが、
そのとき2007年から６年の間に既に9000件ほどあったのです。
そしてその9000件のメールをそのままの状態で、
さらにそこから1万数千件のメール。
それらは95％くらいはDM系のようです。
ですので大した容量は食っていないのですが
あまりに件数が多い…。
さるエラい方ですので、高齢も高齢(^^;)
ご自分でメールの整理などされるわけもない(^^;)
ってか、する必要性も考えないでしょうし、
するつもりもない。
これだけ件数が多いと変換作業もそれなりに時間を要します。
ですので、移行先で正しくフォルダが生成されないなど
変換作業をやり直したい時でも数十分かかります。
もっと効率の良いやり方はないかと模索もしましたが
結局、地道に移行作業をしました。
そう、2007年からの約20000件のメールも含めて(^^;)
そういえば「最近メールのソフトが遅い」などと
言われていたような記憶もあります。
面と向かってお伝えすることができないので
例によってブログで吠えます。
LiveMail遅かったのは、
あなたが要らんメールを
整理しないからだよ！
俺ら作業するだけで
個人のメールは消せないンだから
自分で何とかしといてくれよぉ！
汚い言葉で失礼いたしましたm(__)m
と、またまた2007年からの
たぶん（いや絶対）不要のメールを移行させたまま
設置をするのでした。ムナシイ(^^;)
「メールは整理してくださいね」
などとお伝えしても、
「あ、消してくれていいですよ」
などと応えられるのだろうなあ。
だからあ、どのメールを消すのかわかンないですよ(-"-)
でも、ゴミ箱に入れられるだけだと一緒だしなあ。
ゴミ箱を「空にする」までしてもらわねえと意味ないんだよなあ。
しかし、１か月100件として１年で1200件か。
それが７年で8400件。うーん、ありえる件数だな。
マメに整理してくださいよぉ、ホントに。大変なんスから。
どうもPC内のファイルだとか、メールだとか
全部置いておけると思ってそうだよなあ。
いやいや、場所によってはPCの動きに影響しますよぉ。
ああ、PCの容量は無尽蔵じゃないことを
まずは知ってもらわなければいけないか。
職場のネットワーク環境で問題が発生しています。いや、発生じゃないな。これから実施しようとする作業を行った場合に問題が生じる可能性があるのです。一時的なテストを行ったところで発覚しまして愕然としているところです…orz さあ、どうしよう。ルーティングなどで回避できるものか、何か別の方策はないのか、昨日から悩みまくっているのでした。システムの開発作業とは異なり、安定稼働している既存機器の設定を変えるのはテストを行うだけでもリスクが高く躊躇します。ハー、これはこれでシンドいのでした(^^;)
今晩ではなくて…昨晩のことです。
めずらしく３時間ほど残業をしておりました。
決して忙しかったわけではなく、
自分自身のちょっとした開発時のミスが原因で、
その対応に追われてしまったのです。
ただ、システム上のトラブルとはいえ、
業務に大きく影響するようなものではなく、
「やっべー（大汗）」というほどの焦りはなかったので、
例によって「くっそー、何でだよー(-"-)」とブチブチ言いながら
必死こいておかしな動きのところを調べて無事解決には至りました。
結局のところ、自分の知識不足によるものだったのですけどね(^^;)
原因が判明したときはホッとしたものです。
細かいことを書いても一般的にはちんぷんかんぷんだとは思いますが、
自分の日記でもあるので、ちゃんと悩んだ記録を書いておきます。
webのaspプログラム内のjava scriptで２箇所のミスがありました。
画面上で「当月」「翌月」を指定して
カレンダーを画面に表示する、というプログラム。
（実際は単純なカレンダーではないのですけど）
まずひとつは、
java scriptの「new date()」で得る日付を文字列の８桁日付に変換するところ。
getMonthやgetDateで月や日を取得の場合、一桁の月や一桁の日は
そのまま一桁での取得になりますので、８桁日付にするためには
結果の数値の頭に「0」という文字列をひと桁目に付けてやる必要があります。
10より小さい月（1月から9月）の場合は"0"＋（getMonthで得た値）とする必要、
10より小さい日（1日から9日）の場合は"0"＋（getDateで得た値）とする必要があり、
getFullYearと結合していくと、めでたく「20200901」というような文字列になるのです。
この場面でのポイントは"0"という文字列を「＋演算子」で結合していることです。
これを開発してテストをしていたのが６月から７月。
ここで「＋演算子」に触れておくと、
「文字列＋数値」とすると“結合”となるのですが、
「数値＋数値」は“加算”になるという、
便利な反面引っ掛かかりやすいところでもあるのでした。
テストを繰り返していたのが６月頃ですので、必然的に「年＋“0”＋6」などとして、
「202006」とちゃんと生成され、８桁日付が出来上がっていました。
ところが、月が10より小さくない時、
そう、９月から見た翌月、10月は“0”を付加するロジックを通らないため、
文字列とするには空白文字を結合、つまり「年＋“”＋10」とする必要があるのに
「年＋月」としちゃっていたんですねえ(^^;)
そうなると「2020」という“数値”に、月の“数値”「10」が加算されてしまい、
いきなり「2030」となっちゃっていたわけです。
ここでまず202010という年月が生成されない、というミスが発覚(T_T)
ちなみに「日」を結合する際には、
「202010」が既に文字列になっていれば、加算にはなりませんが、
仮に20201010にしたい場合「2020＋10＋10」は当然「2040」となっちゃいます。
テスト時には文字の“0”を付加したので問題なく「20200705」などと出来ていたのに…。
で、カレンダーの初日となる20201001という８桁日付が存在しないので
そこからの処理がおかしな動きになっていたというわけ。
もうひとつは、実際にこの処理を８月３１日に行なったわけですが、
８月３１日に翌月指定をすると１０月のカレンダーを作ろうとしちゃうのです。
え？なんで８月の翌月が１０月？ということで
そこも不覚だったのでした。
java scriptの日付取得で本日日付を取得したあと、
翌月の１日からのカレンダー用にいったん「getMonth+1」で
月を１upする処理でのこと。
java scriptの仕様であり、書籍やネットでも注意点とされていますが、
８月３１日にとっての1ケ月後、９月３１日はないので、
９月３０日を超えた１日分はそのまま日付を足して１０月１日になる。
つまり、同じように１月３１日の１ケ月後（通常の年）であれば、
２月３１日はないので、プラス３日の３月３日となる、というわけで、
これもテスト時期が６月から７月だったことから、
小の月の末日（５月３１日→６月３１日）などのテスト漏れだったのです。
そんな２箇所のミスが重なり、
そもそも何で１０月になっちゃうのか、
１０月になったとしてもなぜ１０月カレンダーが出来ないのか、
そんな複合的なミスがあったために、思いの外解決に時間を要したのです。
それぞれ対応ロジックを追加して無事に解決したので、
今となっては、またひとつ知識が増えたとポジティブには捉えられますが、
一線でお仕事されている方にはきっと何でもないことなのに
やっぱり“ぼっち開発”をしていると“気づき”が足りませんね(^^;)
でもメゲてはいません。
おかしなところを「自分で解析して発見して解決した」のですから。
「ヘンなミスでダサイなあ」という思いと、「まだやれるじゃん」と
両方の気持ちではいますけど…。
ともあれ、自分の開発時のミスを
８月３１日に処理を行ったユーザが「おかしい」と発見してくれて、
バタバタしながらも対応できたことはラッキーでした(^^)v
ま、こんなふうに知識の蓄積もさることながら、
システム自体の精度も上がっていくのであれば
結果オーライとも考えられます。
ひさびさに独り言のグチを吐きながらも頭をフル稼働させて
それはそれは疲れましたが…。
自分のブログを検索したら
１０年ほど前にも同じようなことを書いていました。
休日に職場から個人の携帯に電話が入ることです。
昨日、病院にいる時と、サッカー練習をしている時に
二度、同じ方から電話があったようです。
いやいや、電話には出られなかったのですけど
ご丁寧に留守電メッセージまで残されて。
で、コールバックは…？ シカトしました(^^;)
その方は別な部署の、年配の偉い方ではあるのですが、
実は月曜日にその方から書類の原紙を２つ作ってほしいと言われ、
火曜日の午前中にお持ちしたわけですよ。
ひとつはExcelで入力する部分のセルを結合して
必要項目だけ手入力すれば完成する形の書類。
もうひとつは、申請者に手書きで書かせる書類なので
wordでサンプルを元に原紙として作成。
もちろん、作成する前には
「これは入力できる形で作りますが、
こちらは手書き用の書類の原紙でいいですね？」
と確認し、了解をとっていたものです。
そもそもその方の部下ではないので、ほぼサービス作業。
ま、これは「誰かほかの人間にやらせるよりも
アイツにやらせると早い」という評価だということもあり、
ワタシもビジネスキャリアで散々やってきたことですから
誰かがセンスのない文書を作るよりはワタシがやりますわ、
ということで「面倒くせえな」と思いつつ、
ちゃっちゃっと作成したのです。
要望は全て聞いたので問題なく受領いただきまして。
それが昨日、留守電に、
「手書きのほうも入力できる形にしたい。
どうしたらいいか教えてほしいので
連絡ください」
という伝言が入っていたわけです。
留守電の伝言を聞いたワタシは、
当然「うわ、めんどくせえ」でした。
そりゃあね、説明する内容が
二言三言で伝わるものならばコールバックして、
「ああして、こうしてくれればできますよ」と
お伝えしますよ。
でもね、その方７４歳(^^;)
自分で書類を作れない時点でご自分で書類を直すなんて無理。
手書き用の書類と言われたのでwordでフォームを作ったのに
それを入力可能な文書にするなんて、Excelだってwordだって、
電話で説明して理解できるはずもありません。キッパリ！
またね、その書類が、
項目内の日付の上に◯や△や×をつける欄がある。
これは、そもそも完全に手書き用の書類なわけですよ。
それをどうするのか、全然考えられていない。
ワタシだってよくよく考えないと実現できないもの。
でも、それを自分の都合で
個人の携帯にまで電話してきて、
折り返し電話してこい、だぁ？
悩みはしましたが、シカトしてしまいました(^^;)
きっとコールバックしたら、個人の携帯で
もしかして何10分も会話しなきゃならないですしね。
年齢的なものなのか、
「彼が作った書類だから」なのか、
「自分が急いでいるから」なのか、
それはわかりませんが、
「あ、今日は休みなのか。
じゃあ明日朝イチで頼むしかないな」と
どうしてそういう思考にならないのか
もう、不思議でしょうがない(^^;)
いやいや、その書類直しをその日やらないと、
倒産してしまうなどというなら話は別ですよ。
でも、そんな怖い情報を伝えられたわけでもない。
結局、今日はその方がお休みで、
「なんだ、次の日は自分が休みだったから、
自分が出勤の日に何とかしたかったのか」
と合点がいきました。
で、そんな経緯を近くの席の部長に話したら、
「そんな急ぎでもないことで休日に対応していたら、
またどうせしょーもないことで電話してくるので
取り合わなくて正解ですよ」
と言われちゃいました。
みなさん、よくご存じで。
そうなんです、職場にいる時なら
しょーもないことでも応えようとは思います。
でも、それを自分の休みの日に
電話代もこちら負担で対応はしないでしょう。
というグチ、と言うか
留守電聞いてガクっときたお話でした(^^;)
今週は、開発作業をいったん中断中です。
職場で利用している電子カルテＰＣは、
トラブル時に迅速に交換できるよう
予備機の用意をしているのですが、
その予備機はただ単に接続すればよいわけでなく、
当然ネットワークやサーバの管理下に入れなきゃいけない。
すると、そこで予備機としての仮設定から
本番で稼働させるための変更箇所を明確にして
その手順書を作成しておかねばなりません。
既に２年前にワタシが手順書を作成していたのですが、
ここにきて予備機の機種が変わるケースがあると(^^;)
ですので、同一機種での交換の場合、
それと別機種での交換の場合を統合した手順書を
あらためて作成する必要が発生したのでした。
これがねえ…メンドくさい(^^;)
ハードディスクのイメージバックアップをとり、
そのイメージバックアップを別のＰＣに落とす。
そのひとつひとつの手順を書きとめて、
ハードコピー（画面のコピー）をとれない画面は
ワタシのケータイで写して、それを加工して
最後にMS-Wordできちんと文書化。
で、もちろん最後には今一度手順どおりに
予備機のセットアップが完了し、
無事に電子カルテＰＣとして成り立つか、
そこまでテストをしなきゃいけない。
ところが、作業自体は想定しているものの
想定外の中断が多いのです。
イメージバックアップソフトのバージョン違いに起因して、
リカバリ時にイメージファイルが読めない、とか
作成されるイメージファイルの拡張子が異なっていて、
何だかうまく動かないとか…(^^;)
今週はそんなことばかりやっていますが
土曜日は配線作業をせねばなりません。
こちらは配線設計が済んでいるので
それを実現する作業のみ、のハズです。
まあ、どちらもメドは見えているので、
すっきり６月を迎えられそうです(*^-^*)
さ、明日、あさって、頑張るとするか。
またまた仕事のことではあるのですが…。ブラウザ上の開発で、ある画面を自動でPDFファイル化する処理をスクリプトからサーバ上のバッチ起動することで実現。あとは、その処理によって生成されたPDF をAdobe Readerで開くのですが、ほんの一瞬遅延させないとファイルが出来ていないのにopenしようとしてエラーになりかねません。まあ、ここまでもかなり悩んで苦しんだので進んでいることには満足もありますが。でも、やっぱり「この方法でよかったのか」という疑問は拭えません(^_^;) 周囲に意見を求めることのできる人がいないからです(^_^;) 思いつくだけの範囲内で実現しただけで正しい着地点なのかわからないまま今日もモヤモヤと一日は過ぎるのでした…。 ま、ストレスなく動くシステムならいいんだけどね(^^)v
仕事上のハナシです。
自分の覚え書きでもあるので、
解らない方はツマラナイことだと思います(^^;)
実は、先週からずっと調べていることがありまして。
院内でクローズしているネットワーク上のＷＥＢシステム、
まあ、言ってみればグループウェアですが、
これを昨年からずっと一人で開発しているわけです。
電子カルテが稼働するＰＣ、
電子カルテがインストールされていないＰＣ、
それらに共通してお手軽に情報共有するためには
ＷＥＢブラウザを使うのが簡単なわけです。
しかも電子カルテの初期画面はHTMLが動くウインドウ。
そのウインドウに表示する初期画面を
ＷＥＢブラウザのホーム画面にするのは
電子カルテが入っていないＰＣ。
つまり、トップページを共通のものにできるのです。
ところが、細かいところは書き切れませんが、
共通の仕様にしなくてはいけないのに、
微妙に稼働環境が異なるのです。
今、ハマっているのは印刷プロセス。
帳票印刷用の別ウインドウを表示することはできても
その別画面を閉じたあとに処理が必要で、
スクリプトエラーになってしまったり。
サーバサイドでＰＤＦ生成を実行した後に
java scriptでそのPDFを同じように開けなかったり。
そもそもブラウザで動くようにしたかったのは、
クライアント環境に左右されないようにと考えたからですが
電子カルテウインドウ内のHTML動作が
普通にＩＥなどで動かすものと、どうも何か違う(^^;)
ロジカルには「ああして、こうして、ああすれば出来るはず」
と考えた末の設計だったのですけど、
なかなか思うようにいかないのでした。
毎日方策を考えて、テストまで終わっても
ワタシが開発に使う端末では動くのに
電子カルテＰＣでは動かなかったり、
サーバでもまた動きが違ったり…。
日々堂々巡りが続いています(^^;)
この印刷プロセスさえ片付けば、
いろいろな開発で使えるし、
一気にいくつものシステムも組めるのですけど…。
ヤバいンです。マジで。 エーン(>_<)
研修の講師…いやMＣだな(^_^;) 無事終了です。参加の皆さん、仕事終わりだというのに頭を使わせてしまい、大変申し訳なかったですm(__)m ワタシも疲れましたわ。今回はネタばれしないように全て一人で準備でしたし、論理的な解の解説、ギリギリまでドタバタとファイルの作成に追われました(^_^;) まあ「頭が疲れたけど面白かった」との感想もいただき、とりあえずは満足しましたとサ。
50人弱の参加者でした。
先週、今週と、
講師もどきの仕事が続きます。
先週は、ほぼ毎年担当している、
病院に実習に来られる看護学生向けの
簡単なオリエンテーション。
ずいぶん前にもブログに書きましたが（→職場見学の高校生に…）
これを毎年のようにやっています。
まあ、病院の情報システムといったら、
やっぱり電子カルテ中心になるのですけど、
その操作講習ではないですし、
そんなのは、そもそも10分15分では終わるはずもない。
毎年同じレジュメを使って
「仕事とコンピューター」なんですけどね(^^;)
でも今年、２回８名に向けての話を終えたあとで
ただ単に
「コンピューターを道具として正しく使う」
という説明だけでなく、
そろそろ“情報セキュリティ”についても
触れたほうが良いのかな、と振り返りました。
正しいデータを入力し、
正しく仕事に活用し、
正しく守る。
おお、いいぞ。
来年もやることがあったら、
ちょびっとレジュメを更新するとするか。
で、明日は「医療安全研修」の講師をします。
まあ、医療安全と言っても、
システム屋のワタシがやるんですから(^^;)
やはり「情報」に主眼を置いたものになります。
さらに“勉強”と言えるようなものではありません。
普段あまり交流のない部署の職員が
なんてことはないテーマで議論する、
そんな場を提供する程度のものです。
もちろん大義名分は、
情報をきちんと共有することで
仕事の品質を上げて、医療上のケアレスミスを減らそう、
半ば強引ではありますが、そんな目的はあります。
テーマそのものは、ゲーム性のあるパズルで、
それをグループ分けしたメンバーみんなで
頭を使って解いてもらうのです。
情報の伝達、共有、取捨選択、整理、
この４つを含ませてはいるのですけど、
結構ややこしいパズルなので、
解答できなかったグループ向けに
最後に解き方を説明しなくてはいけません。
講師、というか司会進行のワタシにとっては、
感覚的なものではなく、
論理的にわかりやすい説明が求められます。
ワタシにとってはそこが勝負なのでした。
研修の進め方のシナリオもさることながら、
論理的な解の求め方の整理、
それがいちばん大変なのです。
土日にも資料を持ち帰り、日曜日には、
図書館の学習室で予習までしちゃいましたね(^^;)
本番は明日の夕方。
明日は一日ストーリーに合わせたパワポの最終チェック。
上手いことできるのでしょうか。
それよりも、
参加者に有意義に思ってもらえる研修となるのでしょうか。
それが一番心配だわ…。
ちょこちょこと、仕事のことも書いていますが、
12月に入ってから、ずっと頭を悩ませています。
まず、現在取り組んでいる開発。
遅々として捗らない。
実はいろいろな要因が絡んでいます。
技術的な知識のことも、環境的なことも。
ユーザ企業（病院ですが）であって、
内製開発であるために締め切りはズバリ…ない！
ですので「まあ、いいや明日でも」と思いがちなのです。
まあ、スケジュール的なものは
自己管理を徹底すればよいことなのですが。
でも、“自己”ですよ、“自己”。
なぜか一人で病院のイントラネット開発中。
他に知識のある人がいないので、
誰かに手伝ってもらえるわけじゃないですし、
誰かに手伝ってもらいたいわけでもありません。
ただ、孤独に
一人で企画して、一人で悩んで、
一人で開発して、一人で達成して、
誰に褒めてもらえるわけでもなく、心の中でガッツポーズ。
ユーザも、ワタシが提供した仕組みなんて
ごく普通にできると思っているのでしょうし。
あ、それは使う側としては当たり前ですね。
何かを使うのに「作るの大変だっただろうな」なんて
考える人はほとんどいませんもんね。
そして、開発を進めるにあたって、
その手法、技法が正しいのかがわからない。
お友達は書籍か、ネットの情報。
あとは一応、システム屋をやってきた自分の勘。
これはもちろん勘で開発するということではなく、
多分これでいけるのだろう、というもの。
それでも、ずっと疑問なわけですね。
ワタシの書くソースコードはセオリー通りなのか、
間違ってはいないのか（ベターな方法が主流なのか）、
正しいけれども時代遅れのソースなのか、
違うツールを組み込んだりするのがベストなのか。
孤独な開発では、誰にも聞けませんし、
間違っていてもそのまま進まざるを得ないわけです。
後々、書籍やネットで調べてベターな方法に気づくにしても
いったい何が正しくて、何が誤っているのかさえわからないから、
とりあえず、そのまま進むしかないのですね。
技術的な悩みはもちろんですが、
それは勉強すれば何とか解決に向かえます。
でも、環境的なものに対して悶々が続いています。
どうしようもないところがシンドイですけどね。
開発自体は…
Ａ、Ｂ、Ｃと開発が進む途中で
例えばＡのサブの機能、ＡＡやＡＢを思いつく。
Ｂ、Ｃの設計は頭の中にあるので
Ｂ、Ｃの開発を先に進めてしまうべきか、
それとも、Ｃの開発時にＣＡやＣＢも必要になりそうだから、
ＡＡ、ＡＢを先に開発しておくべきなのか。
そんなこんなで、
ＡＡに着手し、ＡＢも進めているうちに思うように進まず、
いろいろプログラムをいじっているうちに
完成したはずのＡＡやＡも動きがおかしくなってくる。
いや、おかしくなってくるというより、
元々正しかったのか怪しくなってくる。
慌ててＡＡやＡをバックアップから戻したり、
はたまた、それらを再度見直したり…。
ホントに12月はそんな３歩進んで２歩下がる的な
モヤモヤな日々が続いているのです。
11月までも同じようなことはありましたが、
とりあえず順調に進捗していたのです。
ところが、開発を進めるにつれて
急にハードルが高くなった気がします(>_<)
リリース（ユーザへの提供）も11月20日頃予定だったのに
既に１カ月経過(^^;)
うわーん、年内にリリースしたいよお。
頭がぐちゃぐちゃだよー(T_T)