ファイナルアンラッキー

VBSを非推奨アナウンスはVBAも視野に入れたアナウンスなのかもしれない 先月の11月位から、Excelのアップデート毎に、割と複雑な処理を持っているExcelのVBAにて、今まで通りの正常処理が行えないトラブルが増えている。 Onedriveが起因するトラブルは度々起きているが、それ以外のトラブルも増えてきた。 そういえば昨年の10月から、VBS（Visual Basic Script）が非推奨となった。 レガシーVBの生き残りは、後はVBAのみとなった。 しかし、VBAは、Excelではおまけでついているような機能だとして、ACCESSではVBAでの実装がほぼメインであり、こちらまで非推奨になる事は無いとは思いたいが、そもそもレガシーVBを今から習得する若者も、市場シェア的には随分減ってきている。 最近のEXCELでのVBAの挙動がおかしくなる件は、EXCELマクロをMicrosoftが終了させてがっているのかもしれない。 最近は、自動化ツールでの代用や、Asteria、Dataspiderといったノーコード、ローコードを代わりに使用する現場も増えている。 Excelマクロを使用する理由は今や、ITに予算を掛けたくない企業と、個人の為にだけある機能となってきているのかもしれない。 VBAだけを軸にやっていこうと考えている人は、少しだけ軸の調整も検討した方が良さそうだ。 TIOBE INDEXでも示している通り、コードで実装するならシェアが増加中のC#を選択するのが良いのは一目瞭然だが、ノーコード、ローコードを組み合わせるのもマクロ処理の代わりとなるので、Excel以外でのデータ処理も視野にそちらに軸をずらすとどちらの案件も拾っていけそうではある。

Recordsetの内容をFor分で回さずにシートへ反映する 例：ACCESSファイルのテーブル情報を取得して一括でEXCELへ反映させる 使用するACCESSファイルには下記のような商品マスターテーブルがある これをExcelのVBAからADOでデータ取得し、下記のように用せずに一括で反映させる。 使用するADOのバージョンは迷いがちだが、今ではすっかりOFFICE365のExcelを使用している企業が殆なので、古いバージョンの事は余程配慮が必要でなければ、【Microsoft ActiveX Data Object 6.1 Library】を選択すれば良いだろう。 稀に、32ビット版をまだ使用している場合は【Microsoft ActiveX Data Object 2.8 Library】を使用する事になる。 SQLでデータを取得し、Excelのワークシートへ一括反映させるコードのサンプルは下記となる。 Dim sql_con As New ADODB.Connection Dim sql_rs As New ADODB.Recordset sql_con.Open "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=P:\OneDrive\Download\test\test.accdb" Set sql_rs = sql_con.Execute("SELECT * FROM 商品マスター") Range("A1").CopyFromRecordset Data:=sql_rs sql_rs.Close sql_con.Close Set sql_rs = Nothing Set sql_con = Nothing Rangeが持つCopyFromRecordsetメソッドで、指定したセルから、一括で表形式でデータベースから取得した内容を反映させる事が出来る。 EXCELのVBAでデータベースを取得してか

強制的に値引き徴収されるインボイス制度 強制的に20%値引きされる個人受注 独占禁止法的に、免税事業者を継続すると言った理由で取引を停止してはならないというような、インボイス制度の趣旨はあるば、取引停止の理由を別の理由に言い換えて停止されてしまうリスクはある。 企業内の営業は、結局のところ、仕入控除税額として計上出来なければ、自分達の営業成績に関わる為、インボイス制度分値引きとは直接言わなくても、同じような税率で値引き交渉をしてくる。 数字的に仕入控除税額と一致するので、どこの企業も「優越的地位の乱用」の回避方法を、言葉遊びだけで回避出来ると学んだようだ。 結局の所、この制度は大企業が減税されて、大企業以外は実質的な増税と言える制度だったようだ。 IT業界を個人で活動している人は、派遣の方がマシになってくるかもしれない。 IT業界で活躍している人は、少なからず個人でも仕事を取っている人が大半だと思うのが、このインボイス制度で負担が増える分、結局元々の値段を値引きされる予定分値上げして対応している人も多いのではないだろうか？ 値上げをすると、交渉も決裂してしまう事もあり、かといって、インボイス制度分の仕入控除税額分値引きを受け入れると、間接費等で赤字になるシーンも出てくるかもしれない。 結局の所、個人で活動するよりも、割と高額に設定された派遣の開発プロジェクトに携わっている方が安全なのかもしれない。

明らかな誹謗中傷ですら抗議しても違反ではないという イーロン・マスクになってからかしらないがX（旧ツイッター）は誹謗中傷ですら集客ネタにしているのか？ 娘が、コンテンツ系で本気でがんばりたいっていうので、そこそこ投資。 ある日、オンラインゲーム上でトラブルが合ったらしく、ゲームの世界での抗議的な事を投稿を行ったらしく・・その後・・・ 面識もない知らないユーザーからDM（ダイレクトメッセージ）で、名のりもしないでハッカーのように色々聞き出そうとするので、返信を躊躇しながら返していったらしく・・ DMというのは、X上でLINEのようにメッセージを交換する機能なのだが。 言ってもいない内容や、勝手に人格付けまでする投稿がされたというのだ。 内容を確認をすると、娘のメッセージは短い文字数、しかもたった合計4行程度なのだが、セリフ調で書いてもいない内容に、よく政治家や公務員がやるような捏造事件のように投稿されているではないか。 使用していたアカウントがよりにもよって、ビジネスとして育てていくという切り口で初めた有償アカウントであるので、さすがに放置は出来ないと思い、相手方に捏造している意志はあるのか確認する返信を投げて貰ったところ・・・ 「捏造と捉えるかはお任せします」 と返ってきた。 相手は社会人というのを聞いていたので、捏造の意味が分からない筈もなく。 しかも、相当な人格付までした誹謗中傷も立て続けに投稿されていた。 ゼロからやり直すには余りにも時間と費用をかけたアカウントである為、黙っている訳にはいかず、一般的に見て勝訴となる所までは持っていくべく弁護士探し。 弁護士もピンキリだ。 ただ話を聞くだけ聞いて相談料だけ払わせる気なのかと思わせるような内容もある。 一般にあるお見積のご相談という時点で30分毎に6000円近く発生するのが弁護士という業種のようだ。 作業に対してでは無いので非常に慎重にはなってしまう。 ここのやりとりでも時間は相当要してしまうと思い、X社には、ヘルプセンターから特定のメッセージに関する審議が行えるようになっていたので、試しにそちらも合わせて問題のURLと共に送信。 その間、弁護士探しや、これに時間をかけるよりも自分で手続

MicrosoftがVBAを非推奨にし最終的にはWindowsから削除予定 レガシーVB自体がCOBOL化し始めている 昨今、オフコンで多用されていたCOBOLやRPGを多用したシステムは、言語自体がほぼ化石化しており、無くなると分かっている言語で作られたシステムを引き継ぎたいと思うエンジニアはいない。 今の時代からCOBOL→オープン化を部分的ではなく、一気に始めると、費用を抑える為に機能削減ともしようものなら、それなりの100％カオスな状態が発生する。 VBSも徐々にその仲間入りを仕掛けている。 Windows95が出てから相当年は、Windowsアプリケーションを驚く程短時間で開発出来てしまうこのマイクロソフト社製の言語でシステム開発を携わったエンジニアも多いだろう。 色々成熟期を長く過ごしたこの言語は、オブジェクト指向の中途半端な振る舞い、OSバージョンアップ毎に動作しない事もあり、割りとJavaとにた思考で、.Netシリーズへと変化した。 VisualBasicがレガシーとなって、さらに年月が進むにつて、WEBシステムも躍進し、Microsoft社製言語はあらゆるシーンの開発が行える、C#言語が最も人気を博し、レガシーVisualBasicを今から習得したい層は激減したようだ。 因みにExcelに付随するVBA（VisualBasicApllication）でさえ、Excelの自動化機能で、似た事が出来る且つWEB版でも使用可能なスクリプト言語が登場し、度々Microsoft社がPythonも候補では？という記事も目にする位の扱いとなった。 その中でも特にVBSは異質の存在 VBAはExcelに付随しているので触った人も多いと思うが、そういった人でもVBSは触った事が無いって言う人も多いのでは？ VisualBasicScriptは、メモ帳アプリで記述する事が出来てしまい、且つ拡張子を.vbsとし、実行はダブルクリックするだけというお手軽さだ。 使われ方は、WindowsのCMDで使用するBATファイルでは実現が難しい場合に、安価で容易に解決しようとするシーンである場合だ。（その場合にVBSを選択する事もそこそこ稀） この容易に実行出来てしまう状態が悪意あるセキュ

Wifiスポットが使用可能なギガぞうの契約価値は？ 街中には、契約者が使用する事が可能なWifiスポットがいくつかある。 スマートフォンのキャリア契約はmineo(マイネオ)で、通信のみで通信速度が１ギガバイトまで速度制限を受けない契約を取っている。 データ通信のみの契約では１ギガバイトでは880円で、5ギガバイトでは1,265円で、もしも通信制限を5ギガにしたい場合は、約200円の追加となる。 mineoで5ギガバイトの契約をしても良いのだが、公衆無線LANのwifiサービスで、ギガぞうなる物を見つけた。 よく公衆wifiの電波でwi2やwi2 square、wi2leap、au-wifiというSSIDを見掛けるが、これらの電波を使えるのがギガぞうというサービスのようだ。 10万以上のスポットが全国にあるという事で、政令指定都市での活動がメインである為、あちこちで使えること間違いなしと踏んだ。 では１ヶ月間使用してみて、実際にはどうだったかというと。。。 1GBにも至らなかった。 Wifiスポットを探してそこに行ってまで使用するみたいな使い方をしない限りは、大阪がいくら政令指定都市と言えど、パケット量節約のような役割は果たせないのかもしれない。 今のところmineoで5Gバイトプランにした方が圧倒的にお得という結果であったが、ギガぞう検証の為にもう少し契約を続けて行きたいと思う。 今回の検証結果がギガぞうを契約するしない判断の目安になればと思う。 因みにパソコンでも利用出来るようなので、ギガぞう関連のWifiが有る場所まで行ってのような、出張スタイルだと需要があるのかもしれない。

2023年度の物価高にITエンジニアが好みそうな単価は！？ 各社の開発案件で大体の平均値と実際にエンジニアが希望している単価 月給は基本フリーランス向けのフルスタックが必要な所が殆どで、そういった所の案件から平均した為、相場が高めな場合がある。 使用するコンピューター言語別なのは、案件の文章から拾っていくのに時間がかかる為、また別の機械でやりたいと思う。 提示額について下落傾向に見える要因は、アジャイル型でプロジェクトを小規模化して提示している所も多く、アジャイル型といいつつ実際にはアジャイルではない物も多く、国内企業がITリソースに係るコスト削減の思惑が昨今の案件に強く出ている傾向を感じた。 案件 各社平均 エンジニアが好みそうな相場 考えられる要因 要件定義が存在する 開発案件 コンピューター 言語の使用有な場合 上級エンジニア が担当する事が 多い 時給 2,500～ 月給 50万～ 初級エンジニア 時給 1,600 月給 20万～30万 中級エンジニア 時給 2,000 月給 30万～50万 上級エンジニア 時給 2,200 ～ 8,000 月給 60万～200万 アジャイルでの開発が増え、 3,000～6,000円程度だった 考え方が下落方向へ崩れてきた 感がある。 ウォーターフォール型が埋も れている可能性もある。 ウォーターフォール型で開発 の役割が縦割りスタイルだった 場合には、要件定義をする役割 の負荷が高めなので3,000円以上 になってくるのではないだろうか？ ちなみに上級エンジニアが希望する 額の案件になる事はほぼ無い。 （仲介業者の中抜きの額が多く 　なるだけ） 保守も必要な開発案件 初級エンジニアも可 時給 1,600～2,200 月給 40万 時給 3,000 月給 60万～ 結構ミスマッチがある領域。 休日も電話対応等に追われ 役割上高負荷な環境が多い 領域でありながら、障害時の リカバリーにも神経を使う実際 には要件定義よりも重たい。 企業側は永続する為のランニング コストとして捉えている為、 低く抑えたい感が出ており提示が 低めな印象でエンジニアが 集まりにくい要員となっているようだ。 単純

2023年度も使われ続けるVBSについての予想 VBSとは何ぞやについて一言二言だけ VBAのようなもの 昔はやったVisualBasic6みたいな物を、開発環境無しにメモ帳だけでソースを記述する事が出来て、拡張子を.vbsとして、ダブルクリックすると実行可能なお手軽言語だが、セキュリティ上の問題から、敬遠される事も多い言語 日本独特な流行り方をし、一部のRPA製品と密接な関係となった現状 一時期、日本国内ではRPA（ロボティックプロセスオートメーション:Robotic Process Automationの略）導入が流行った事があった。 現在もきちんとしたDX推進ではRPAの導入が検討されていたり、実施されていたりしている。 日本は島国ながら、政府がRPAと言ったら、あまり理解していない経営者層の人も、他社に後れを取りたくないが為に、何か良く分かっていないけれど導入が進んだ。 RPA製品にどういう物があるのか理解が進んでおらず、簡単に自動化されるかのように製品購入が進んだ挙句、思ったように簡単に扱える製品では無かった為に、超大手以外は導入の失敗に終わった。 流行した当時のRPA製品は、RPA製品専用のスクリプト言語や、VBScriptのようなプログラム開発言語に頼らないと達成出来ない物が殆どであった。 前者のRPA製品専用スクリプトは、その製品だけでしか役に立たない為の学習コストが嫌われてしまい、他のプログラム開発言語に頼られる事が進んだが、そもそもしっかりとした開発言語が必要なら、RPA製品を介して開発するよりも、システム開発した方が手っ取り早くなってしまい、RPA製品導入の本末転倒となり、簡単なバッチ処理だけ記述するスタイルなVBScriptが、当時のRPA製品では使われるようになった。 （個人的には、言語が何であれ、RPA製品の意味を感じなくなってしまう状況だが...) あれから、数年、RPA製品も進化しており、RPA製品での開発に限って言えば、ノーコードプログラミングと組み合わせ等で、スクリプト自身も本当に書く機会が不要になってきた。 結果ますますVBScriptの需要が細くなってきた。 今後のVBScript需

ぼっちにうれしいCHAT GPT photo 最近流行りのCHAT GPT。　OPEN AIで、そこそこ自然な会話が可能で、何かを知りたい時は、ネットでいくつかのサイトをクロールして検索するよりもCHAT GTPに聞いた方が、色々な候補の情報を要約して並べてくれるからありがたい。 でも、そんなCHAT GPTサービスにも欠点が。　今だけなのか、これからもずっとなのかは分からないが、1時間会話をしていると、タイムオーバーで話せなくなる。 ちょっと欠点かなと思うのが、聞かれた事に正しく回答出来たかどうかを補填する為なのか、求めていないシーンについての状況も返してくる為、その場合は別の聞き方をする筈なので、やりとりしているシーンに集中した回答をしてほしいと思うな。 いちいち別シーンではこうでは？とか返してくるのは、話を逸らしたり、印象操作ちっくで政治家っぽいと思った。

社内SEは描いていた働き方とは異なる 極わずかな立場にいる社内SE要員を理想としない方が良い 企業経営者は社内業務を革新させる為に、保守を始め、内製開発を進めるという触れ込みは、日本の場合はほぼ100%嘘である。　彼が期待している事は、IT、DXといったよく理解していない物で、オートメーション化や利益に繋がる何かを始められたらと思っているのも事実だが、それは、ついでにそうなれば良いなと思っているだけで、とりあえず達成したい核心はそれではない。 日本企業の経営者が考えている事は、ITベンダーよりも費用を安く抑える方法の一つとして社内SEを欲している。　メーカーの社内SE片と話をすると、大体、他の社内業務も兼任していて（または、パソコンを使う業務自体を情報システム部の仕事と勘違いしている例も）、ついでにシステムの面倒をみているという状況が殆どである。 ITベンダーに居たころ、お客様としての社内SEと話していると、仕事が楽そうだし、帰るのも早そうという印象を持って、それに憧れてメーカー勤務の社内SEに憧れを抱いたことは無いだろうか？ ただ、中には憧れた通りに近い状況の人もいる。　1万人に一人位の割合だったりするのではないだろうか？　そういう人達は、役職の親族であったり、極わずかにいる、社会的権力を保持している人がそうである。 　帰宅時間に関していえば、ITベンダーに居る時よりかは、確かに遥かに早く帰られる。　ただし、みなし残業が20時間以上の求人を出している企業は、そうでもなく、ITに関わる業務が終わった後に、現場の仕事を手伝うパターンが殆ど。 　社内SEの人数が増えてくると、徐々に不安定となる。　システムによって責任度が変わるが、担当制で、該当システムの担当というような事をしている場合、基本的にはその人に損失を与えるかもしれないシステムを支える心理的負荷が延々と課されてしまう。　それによって報酬に繋がる給与や賞与がアップする事は無い。　ITベンダーでは無い経営者にとっては、情報システム部はコストセンターとしてしか見ておらず、ITベンダーよりも優れた対応をしても、ITベンダーへ依頼する費用より安くしたいと思っているだけなので、政府の施策に乗っかる以外の報酬アップをITエンジニアには絶対にしない。 　社内SEの人数を増