Copilotで聞いてもうまくいかないとき
気が向いたら追加するかも。
先輩やら上司と喋るのが嫌すぎて相談はほぼCopilotかネット検索してたので色々書いときます。Copilot使いづらいんだけど使わなきゃ…みたいな人は参考になるかもしれない。
・エラーに対処したい時
エラーメッセージをそのまま書くとかコピペしてそれを解消したいと書く
（例：404 not found を解消したい とか）
・実現したい処理とか
機能が明確になっている時はそれを書く
・モジュールの使い方
モジュール名とかメソッド名書いて使い方とか追記すれば大まかに教えてくれる
（例：javascript document.getElementByIdの書き方 とか）
・実現したい処理が抽象的だったり自分の中で定まっていない時
ExcelでもWordでも何でもいいので機能について分かっていることを書きだしたりして実現したい機能を具体化する
ある程度抽象的でもサンプルコードは書いてくれる。先日HTMLで行数取得について聞くと適当な手段でサンプルコードの回答が出た。後からボタン押下時の取得はどう書くかとか聞けば修正は可能。
全体共通
自分の要求を具体化しておくことが必須。できてない場合は何度も聞きなおすことになるので結構時間がかかる。
「DBの接続方法」とかだと何の言語で接続するのか書いてないのでPHPから接続したい場合でも、DBに接続するための準備とか接続のコマンドとかが出てくる。多分。
まぁ後から「PHPでDBに接続」とかで聞き直せば出ますが。
大抵は「PHPでMySQLに接続するコード」とか「404 not found を解消したい」とか「javascript document.getElementByIdの書き方」みたいにプログラム言語とかモジュール名とかの後ろに使い方とか〇〇方法とかを引っ付けて書くだけで割と欲しい解答が出てくる。
小言
めんどくさい人とばっかり話してると具体的で伝わりやすい言葉のやり取りが難しくなってしまうが、Copilotで伝わりやすい言葉を練習するのはあり。仕事の説明をする時も検索する時の文章を意識すると伝わりやすい印象。
使う言語とかモジュールとかが決まってる場合はどうしても決まりを上司に聞かなければならないが、正直、決まり以外はCopilotに聞いて進めるのが吉。
Copilotのお話
便利だったお話
JavaやらVBAやらを仕事でやってコーディングのやり方が多少分かってきたのでPHPを独学で勉強し始めてますが、なんかCopilotの解答が優秀すぎて怖いです。
サンプルコードがそのままコピペで全然使えるし別のパターンだとどう書けばいいのかも聞いたら大体希望通りの機能のコード書いてくれるしでテンション上がりすぎました。
正直コーディングの相談は会社の先輩よりCopilotに聞いた方がよっぽど速い。相談する場合だといちいちコードの説明しないといけないし、プログラム書いてる癖にかみ砕いて話さないと理解できなかったりするし、何より気を使ってもらえないと話聞けないとかあるし…相談一つするにも疲れすぎる。どっちが相談者か分からんわ。
まぁ会社の場合は情報漏洩の心配があるから検索一つでも気を付けないといけないらしいからCopilot使うのは若干怖いけど。
それがクリアできてたら圧倒的にCopilotが楽。
というわけで、人に相談するのが嫌な人はCopilotを使いこなすと楽になれるよという話でした。
VBAはCopilotに聞くといいかも
Copilotに「VBA 最終行の取得」とか「VBA Accessファイルのデータ取得」とか入れるとサンプルコードが出てきますが、普通にプロシージャ内にコピペすれば使えるので、割と便利です。ただ、シートオブジェクトを変数に入れないコードだったりするので、VBA始めたてとかだと結構危ないコードを書いてしまいそうではあります。
でも長々とうんちくが多い記事を見るよりは、Copilotにサンプルコード出してもらって、エラーもCopilotに聞いてっていうのが手っ取り早い気がします。今不要な情報を見る時間と労力がもったいないので。とにかく作って覚えたい人はCopilot使うのが一番疲れないかなと思います。
仕事中に独学でCopilot使う場合は、自分の資料の中でバックアップ取りやすいデータを使って、少しずつ開発すると割と安心です。VBAのデータが消えてもすぐ復元できますし。
学習が容易とはいえ落とし穴が多い言語なので、いきなり他の人が使うシステムを作るのは割と怖いです。まずは自分の資料で色々試して検証を重ねてから広めていくのがオススメです。
VBAのエラーメッセージは原因の特定がしづらい
本題の対処法については、最初の解決策とかにだけ書いてます。大した事は書いてませんが…時間が惜しい人は解決策だけ見ればいいと思います。
解決策とか
VBAでエラーの原因を調べるのによく使うのは、基本的にはデバッグモードで動かして、エラーがでた箇所の値をDebug.PrintとかMsgBoxとかでみていく方法です。
こういう時に変数定義でクラス（StringとかLongとか）を明確にしておくと、比較的原因が特定しやすいです。配列の処理をするのに文字列入れたとか、数値の処理に文字列いれたとかに気づきやすい。
ちなみに、オートメーションエラーはPCへの負荷が大きい時に出る事が多いそうで、処理自体に欠陥があるというよりは、処理しきれずにエラーが出るみたいです。このエラーは大抵デバッグモードにしてエラー箇所を動かすと直ります。
それで直らない時は、エラー処理を一旦コメントアウトしてコンパイルすると直ります。それでも直らない場合は…色々試すしかないです。
こんな感じで初心者だと対処が難しいエラーが出る事が多々ありますので、VBAに詳しい人が居ない、頼れないとかだと、色々苦労します。
苦労した話
他の言語を業務で使った経験が今のところほぼ皆無なので、VBAに限った話かは分かりませんが、保守してて思う事は、とにもかくにもエラーの原因が本当に分からないことが多い点です。
「致命的なエラーです。」とか「オートメーションエラーです。」とか出た時は、これという解決策があまりでないので、かなり苦労します。ネット検索で見つかった方法を試すうちになんとか解決することもありますが疲弊することが多いです。
問い合わせ対応する時とか、大体はエラーメッセージのままで待っといてもらって、調べた後でメッセージ閉じていい良いとか伝えたりしますが、待たせるので大抵イライラされたりウンザリされたりで割とへこみます。
私の態度が悪いのもあるかもですが…
態度悪くても対応がスムーズだとそんなに機嫌悪くされたりしないので、せめてスムーズに対応できる環境が欲しい。
VBA プロシージャの引数と戻り値
一応サンプルコード置いてますが、解説とかがメインです。
'メインプロシージャ（ByRef）
Sub test_sub()
Dim a as Long
Dim b as Long
Dim c as Long
b = 10
c = 5
a = test_calc(b,c)
MsgBox("a=" & a)
MsgBox("b=" & b)
MsgBox("c=" & c)
End Sub
'計算するプロシージャ（ByRef）
Function test_calc(ByRef d as Long, ByRef e as Long) as Long
d = 15
e = 20
test_calc = d * e
End Function
Functionで戻り値の型を指定する場合、閉じカッコの後に as Longを記述します。（as Dateなど他の型も可）
引数のByVal、ByRef、戻り値のas Longは省略可能ですが、エラーの温床になるのでお勧めしません。ByVal、ByRefを省略した場合、ByRefが書かれたことになります。
ByValは引数を生成する時に値をコピーし、ByRefはコピーせずにそのまま参照します。
なんかByValは値渡し、ByRefは参照渡しっていうらしいです。面倒だから専門用語増やすなと言いたい。
ByValを使った場合、引数をいじっても遷移元のプロシージャでは値は変わりません。
ByRefだと、引数いじったら変わります。
基本引数を変えたい場面ってないのでByValでいいと思いますが、値コピーだから、恐らくメモリ食ってるのかな？とか思ったりします。が、詳しくは知りません。
怖かったらByValを使っておいて、気になった時に調べればいいと思います。
VBA サンプルコード プロシージャの呼び出し方
'メインプロシージャ
Sub test_sub()
Dim a as Long
Dim b as Long
Dim c as Long
b = 10
c = 5
a = test_calc(b,c)
MsgBox(a)
End Sub
'計算するプロシージャ
Function test_calc(ByVal d as Long, ByVal e as Long) as Long
test_calc = d * e
End Function
引数のByValはByRefと書くこともあります。詳しくは下記にて解説。
VBA その辺に転がってるサンプルコードで気を付ける事とか
ウイルスになるようなコードが転がっている…というのを聞いた事はありますが、そういうのは探さないとむしろなさそうです。
正直、最近で怖いのはVBA特有のコード省略をフル活用した、短縮コードです。
ぶっちゃけ下記のコードは短くて超便利なんですが、VBA多用してる会社とかだと、複数のVBAを同時に動かしたりして、こういうコードでめっちゃ面倒な問題になることがあります。
Cells(1, "A") = Date
これ、Cellsだけしか書いてないんですが、実はActiveWorkbook.ActiveSheetというめっちゃ長いコードが省略されていて、全部書くとActiveWorkbook.ActiveSheet.Cellsになります。
このActiveWorkbook.ActiveSheetは、今開いているExcelファイルのシートを読み書きするもので、これを使うと、読み書きするシートがリアルタイムで変わってしまいます。
VBAが動いてる途中で別のExcelを開いたりすると、開いたExcelのシートを読み書きしてしまうので、下手すると関数壊しちゃったりします。
ちなみにVBAでExcelのセルを書き換えた場合、元に戻す機能が使えないので、関数壊しちゃったのを戻したい場合は、保存せずに閉じるしかないです。
保存してなかったら諦めるしかありません。これが結構痛いです。
安定した挙動を確保する場合はWorkbooksとかWorksheetsとかでブックとシートを指定することを強くお勧めします。
また、エラーが良く出るVBAはこういう書き方してることが多く、開発者にシステムの挙動が聞けない環境だともう最悪です。
テストで動かす分には省略しても全く問題ありませんが、業務で広く使う場合、他の資料を破壊してしまうので、放置すると割と笑えない未来が待ってます。
