かざいむ日誌

IT関係で知ったことなどを記事としてあげていきます。内容に不備や質問などあればぜひコメントをよせてください。

VBAでツール開発 2023

ポイント

  • コードはariawaseを使ってエクスポートして管理
  • コードはざっとVSCodeで書いて、Excelで動作確認
  • GitHub Copilotを使ったので定型的なコードはさっと書けた
  • 今回データ取り込み、CSV出力機能を実装したがダミーデータでもいいので一連の流れを一通り動かせるようにすると進捗が出るように思った。

ポイント詳細

コード管理

以前と違い、Rubberduckがいろいろな機能を提供していたけど、コードのインポートで上書きしてくれなかったりでまごついたのでariawaseを使った。ariawaseはルートフォルダに ちょっとしたプログラムを置いて、その下に、binフォルダを作り、そこにxlsmファイルを置く。プログラムを呼び出して、decompileすると、srcフォルダにxlsmファイル名のフォルダが作成されて、VBAのコード、ユーザーフォームのコードがエクスポートされる。詳しくは、以下のリンクを参照。

kanegolabo.com

 

GitHub Copilotなどの利用

今回GitHub Copilotを使いながらコードを書いたが、過去にある程度書いたことがある人にとっては便利という印象。一番最後の入力行までループを回すとか、繰り返しセルにアクセスして、といったコードも保管してくれた。ただ、2023年6月時点では信じきれないので、要注意。ファイル操作するコードが提案されたけど、Excelで動かしてみたら動かなかった。
今回ariawaseでコードをエクスポートした。このツールではシートに紐づくVBAはdcmという拡張子でエクスポートされる。GitHub Copilotはbasファイルだけサジェストしてくれるので、xxx.dcm.basと拡張子を書き換えてコード補完を利用した。
また、サジェストされないコードについてはChatGPTで質問してみたが、そこまで当てにならない印象だった。セルのメモをプログラムで追加するコードをかけるか質問したら、できないと言われたが、ググったらけっこうあっさり見つかった。

 

VBAのコード全般について

VBAはできる限りExcelの機能を全面的に利用する方がよさそうに感じた。また、VBAもできるだけシートに書くようにして、共通モジュールは避ける方がよさそう。具体的には下に書くが、VBAExcelファイルにアクセスするので、スコープを狭くするよう意識的に設計するのがよさそう。

例えば、データの受け渡しは名前の定義を利用する、クラスの初期化は呼び出し側で行う、VBAはできるだけ、シートのマクロとして定義する、できるだけ関数に寄せる、といったところが注意点だと思う。

また、変数のスコープがどうも思っていたのと違って、いくつかの変数宣言の直後に明示的に初期化をして、値が残っているように見える現象を回避した。これはもう少しちゃんと仕様を確認したほうが良いと思う。

 

今回のはまりどころ 

今回はとある国の地域情報を入力するために、郡プルダウンと村プルダウンとで連動するプルダウンを作成した。郡、村その他情報を入力するシート、県を選択する設定シート、県・郡・村のマスタデータシートを持つExcelファイルを考えた。
設定シートで最初に県を選択すると、入力シートの郡プルダウンでその県にある郡が選択候補になり、郡プルダウンを選択すると、その郡にある村が選択候補になるという仕様。具体的にはこのサイトを参照。

www.pc-koubou.jpこのサイトでは入力規則と名前の定義の組み合わせるというやり方を紹介しているが、これはデータを作り込まないといけないと思い却下した。
そこで、セルの入力規則を動的に設定するプログラムを書いたが、入力規則が255文字までという制限にひっかかり代替案を探すことになった。最終的には、上記のサイトのやり方とVBAを使った折衷案となった。名前の規則をVBAで定義することで、データの作り込みを回避した。
名前の定義を利用すると、名前の定義の中で探せばよいので、親子関係などがあるデータでも複雑にならなかった。

 

参考URL

ariawaseツールについての説明

kanegolabo.com

 

wikiwiki.jp

 

連動プルダウンの作成

www.pc-koubou.jp


Rubberduckについて

devlights.hatenablog.com

時間について

時間は存在しない、という本を読んでいる。他の人が読んでて面白そうだったのと、時間について自分の中で考え直したいと思ったから。また読み終わったら感想を書くけど、時間のとらえ方がもう少し変わると自分の生活を大きく変えられると思う。

そういう意味では先日からゆるゆるとタスクシュートによる時間管理をしている。この時間管理とToDo管理を分けて考えたのはとても良くて、ポモドーロテクニックの考案者による著書や、限りある時間の使い方という本でも触れられている部分だと思う。

一回限りの時間として捉えなおす。

そういう意味では、重松清の流星ワゴンや、植島啓司の生きるチカラでも触れられている、考え方だと思う。

雨が多い時期になって

雨が多い時期になって、子どもがiPadで遊ぶ時間が増えてる。あまりiPadばかり見てほしくないけど、積極的に巻き込める遊びが思いつかず、多少はiPad見てもいいかと思い傍観している。

自分が子どもの頃は雨の日は何をしていただろう。テレビは見ていたと思う。でもさすがに土日は吉本やカープの中継ばかりでそんなに見るものもなかったように思う。ひたすら紙飛行機を作ったり、押し入れのものをだしたり、トラップみたいなものを作ったり、庭に水たまりを作って遊んでたように思う。

そうだ、雨の話からずれるけど、父が元気だったころには新興系の宗教の拠点に連れてかれた。日曜の朝にお参りに行って、父の真似をして、昼ご飯はどうだっただろう。月末の夕方には床屋に連れてかれた。友達とうちで遊ぶようなことはなかった。あとは、ちょくちょく車で20分ほどの祖母の家にも連れてかれた。お小遣いをもらうのが楽しみだったけど、叔母がよく祖母の家に来ていて、いろいろと言われたように思う。

iPadだと片付けの手間はないけど、味気ないように思う。もう、土で遊ぶようなこともしばらくはないかもしれない。

問題解決型と、比較優位型という課題へのアプローチ

今日同僚と話しててなかなか話が伝わらなかったので他の人の意見が知りたい。システム開発するときは、問題解決型で開発の提案をしますか?それともシステム導入後のメリットで開発を提案しますか?これまで、業務システムでは問題解決を主としつつ、メリットを混ぜた案件に入ることが多かったように思う。

この問題解決型とメリット型について最初に知ったのは大学で所属していた英会話サークル(ESS)の活動だった。このサークルはいくつか活動があり、私は政策などを英語で議論するDiscussionユニットに入っていた。そこでは課題に2つのアプローチをする。

  • Problem-Solving (問題解決型)
  • Comparative Advantage(比較優位型)

1つ目の問題解決型では、現状こんな問題があり、それによってこういう害が出ている。それを解決すべきだという点でまずコンセンサスを取り、次に具体的に何をすべきかを提案する。一方の比較優位型は現状はこう、次にこういう政策を考えています、これを実施したらこんなメリットがあります。どうでしょう?という具合に話を進める。

最近私が入っているプロジェクトでは1つ目のアプローチを徹底するように上司からもアドバイスされている。これをやりたいから援助してほしいという話が出たときに、上司がbeaurocratic redundancyは避けようと言っていた。beaurocratic redundancyとは官僚は仕事を増やしがちというような意味合いで使われると理解している。やった方がいいことをやっていくと、どんどん無駄な仕事が増える。

問題解決型についてもう少し詳しく言うと、もし何か援助してほしいと言われたら具体的に今何に困っているか、現在それに対して具体的にどんな行動をとっているか、というのを聞き取りそれらからその課題について相手が問題意識を持っていて、取り組んでいる場合にのみ、何をするのかを考えるのだ。

援助の話でいうと、やった方がいいことはいくらでもあるし、やりたいと思うが、足していくときりがない。そうすると本当に解決すべきことに取り組む余裕がなくなってしまうかもしれない。学校のカリキュラムも同じで、金融教育もやったほうが良いし、英語も勉強できた方がいい、問題解決やリサーチとかもできたらいい。でも、授業時間は限られているので、全部を細切れにしてカリキュラムを組むと、その分野に詳しくない先生が、知らないなりに教えることになり、なんだか本末転倒な結果となる気がする。

こういうことは民間企業では起きにくい。企業であれば利潤という評価指標があるからだ。だから公共部門はという話ではなく、評価軸が一つではない公共セクターはできたらいいことを足していくと大事なことができなくなるから、慎重にしないといけないという教訓なんだと思う。

難しい本『事業分析・データ設計のためのモデル作成技術入門』を読んでいる

最近知恵熱が出るような経験をあまりしていない。漫画やちょっとした技術書を読むけど体力が要るような読書や、頭がショートするような読書体験をしていない。

これではいかんと思ってたところで、データベース、DOAについて関心が向くようになってきた。フロントエンドはスピードが速くフルタイムでシステム開発していない今頑張れない、、むしろ業務について本質的な観点を持ちたい、というのが理由としてあるんだと思う。

そこで、大学生向けのデータベースの教科書、増永良文著『リレーショナルデータベース入門』と佐藤正美著『事業分析・データ設計のためのモデル作成技術入門』(TM本)の2冊を一時帰国時に買い込んでほくほくしてラオスに戻ってきた。でも開いてみるとどちらも思った以上に骨太な感じ。

今はTM本のほうから読み進めているけど、ウィトゲンシュタインとかゲーテルとか出てきてそれがデータベースにつながるのか、わかるような、わからんようなと思いながら読んでいる。これは何回か読まないといけなさそう。でも多少なりともDBの知識・経験があるので点と点がうっすら点線でつながりそうな感じで読めている。

そういえば私は大学は文系で、あまり歯ごたえのあるのを読んでこなかったように思う。社会学比較文学の本はちょこちょこ読んだけど、まぁそんなに難しい本は読まなかった。一度だけ、大学院で課題図書としてフーコーの『これはパイプではない』という思想エッセイを読んだが、なかみが全然わからなかった。これはマルグリットの『これはパイプではない』という絵の解釈についてのエッセイだったと記憶している。課題図書なので読むのをやめるわけにもいかず、でも読んでも意味が取れないので、しばらく放置して、休み休み読んでいたらある時、急に内容が頭に入ってきた。

卒業してからSIerに就職して、一時期かぶれてメイヤーのオブジェクト指向入門という鈍器のような本を買ったけど、これは積読になっていつの間にか手元からなくなっていた。もったいないことをしたが、今考えるとそれよりも前に読むべき本があったと思う。今の私が若い時の私にアドバイスするならTCP/IPLinuxカーネル情報理論、データベース、アルゴリズムなどの骨太な本を勧めるだろう。まぁ、若い時の私からするとちょっと面倒なおじさんに見えるだろうな。

今回買った、TM本やリレーショナルデータベース入門でもパイプ本のように理解が深まる瞬間が来てほしい。というか、読書会とかしたい。そうでもしないと頭の中で整とんできないように思う。読書会したい本はもう一冊あって、市谷聡啓著『デジタルトランスフォーメーション・ジャーニー』だ。TM本やRDB入門は概念を整理するのに他の人が欲しい感じ。DX本は読んだ人それぞれの現在の立ち位置から本の内容がどう読めたかを共有したい。興味がある人がいたら連絡ください。

がくっと集中力が落ちた

最近、頭が常にぼんやりしている気がする。コロナ後遺症はこれまでなかったから原因は別にあるんじゃないかと思う。集中力は肉体的にすとんと落ちてしまうものじゃないかと思う。30代になってすぐ、それまでの集中力が消え失せて、メモリが足りなくなってしまったような気がするようになった。

40代になった今、またさらに集中力が減退して、何を考えてもぼんやりしているように感じる。いつからかというと、おそらくこれは子どもたちが夏休みが終わってラオスに戻ってきて、また一緒に生活するようになってからだと思う。ということは単純な運動不足が原因だと思う。

夏休みの前も同じ状況だったけど、こういう衰えはある日突然来るからそこはあまり考えずに対策を取りたい。単純に運動を増やしてみたいと思う。運動はちょっとずつでも積み重ねると閾値を超えると思うので、まとまった時間が取れなくても意味があると考えて、行動してみたい。

あとは、頭がぐるぐる回転するような経験も不足していると思う。これは英語を一生懸命話したりしているときに頭が回っているように思うので、シャドウイングが役に立つと思う。

いろんなものを合わせて取り込むのが大事で、若い時には特に何もやらなくてもよかったけど、もうおじさんだから昔のようにはいかないとちゃんと理解する必要があると思う。

ラジオ体操のように本を読む

新しい学校の先生から子どもにもっと本を読ませるようにとアドバイスをもらった。これまでは日付、読んだ本、親のサインを書く表形式の紙を渡されていたが、新しい学校ではフォーマットはないとのこと。

ちょうどよいと思ったので表をカレンダー形式に変えて以下のように子どもたちに提案した。読んだ日は3種類のスタンプのうち好きなものを押していい。読まなかったらもう押せない。本は漫画でもなんでも構わない。 カレンダーだとやはり押さないのは気になるのかとりあえず二日目の昨日までは本を読んでいる。

小学校のとき夏休みに朝近くの公園でラジオ体操行って、スタンプを押してもらっていたけどやはりあれはいい手段だと思う。 読書だけでなく、やったことが表示されるより、やってないことが見えるのがいいのかも。