  |
はてなキーワード: VbAとは
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
てほしい。
プログラミングを理解できない人はいます。いい加減この事実を認めて下さい。
こういう話になると、やれ「教え方が悪い」だとか、やれ「順序立てて学べば誰でも理解できる」などという輩が出てきますが、それは事実に反します。
まず、プログラミングは手順さえ覚えれば誰でもできるようになると言うものではありません。プログラミングを理解するには、一定レベルの論理的思考能力を要します。それが身に付いていない人には無理です。また、どんなレベルの人でも、プログラミングで分からないことは出てきます。プログラミングができる人は、そういう時に、
といったことをして解決する力があります。そういう試行錯誤をしない人や、複雑だったり抽象的な概念を突き詰めて考えることをしない人に、プログラミングを理解するのは不可能です。
たとえば、再帰関数が分からないとしましょう。具体的に何が分からないのかは人によって異なります。たとえば、
など。これらを解決するには、自分で仕組みを突き詰めて考えたり、コードを書いてデバッグしてみたり、調べたり人に聴いたりするしかありません。講師が気の聞いた喩え話などをすれば、たちまち疑問が氷解するなどということはあり得ません。
また、一口に「プログラミングを理解する」と言っても、そのレベルは様々です。
最初の2〜3程度が「自分の思うプログラミングの全て」な人が、軽々しく「プログラミングは誰でも理解できる」などと思わないでいただきたいのです。それは実用上は全然足りていません。サンプルコードをググりながら、やっとこさVBAで複数のエクセルファイルを集計できる程度の人が「プログラミングできる」気になっていては困るのです。
上記の大部分は、自分のプログラムを他人に見せるつもりのある人なら十分に習得しておく必要があります。ましてや、プログラミングで飯食おうと言う人間が、FizzBuzzに毛の生えたようなコードを読み書きするのに精一杯で、効率や保守性に気を配れないのは論外です。
上記の特に後半に書いたようなことは、誰にでもできることではありません。ちょっとしたコツや方針を守れば機械的にこなせるというものではなく、技術力の高い人でも熟考を要することです。彼らは、そうした高度なことを正しく考える力があるから、技術力が高いのです。そういう力は、誰かに用意してもらったカリキュラムを受動的にこなすだけではまず身に付きません。
Python流行っているが、Officeを使っての業務が主だと、それほど便利になっている気がしない。
Pythonからエクセルを触ることは出来るが、サーバーを持っていてバッチ処理する、といった場合でないとあまりメリットを感じない。
VBAやPowerShellでなんとかしようとするが、それくらいしか道具がない。
グラフの描画も表計算も数値計算もExcelの方でよくない？？
関数、ピボット、VBA、ソルバー当たり使いこなせばだいたいのことできるのでは…
強いて言うならpandasのdf.describe()には感動したけど、普通にExcelでも関数書くだけだしな〜と思ってしまう。
データ分析の基礎しか勉強していないから、あれなんだけど、これからどんどんExcelではできない作業がPythonではできるようになるの？？？
ちなみに、スクレイピングとかは圧倒的にVBAよりPythonとかなんだろうなってのは思っています。
（追記）
皆さんありがとう。データの量という観点が抜け落ちてました。重大なご示唆をありがとうございます。
これだけ
（追記）
ド玄人
・RDBっぽく使うテクニックと勘違いしてる素人チラホラおるな
・PowerQueryはちょっとでかいデータ食わせるとすぐフリーズする、DAXもPBIに比べていまいち使いづらい。
・スピルを使いこなせる人かなぁ
・PowerQueryを使いこなせるやつが職場に1人いたらなあ。
・お前みたいなACCESSとEXCELの使い分けができない人間は迷惑
・まずはリスト形式で作成してピボットでマトリクス化するのが文明人
・Access使ったほうがいいのでは
・行列に貼り付けたデータ範囲からSQLで柔軟にデータ抜き出せるような技でもあるの？
・https://www.soumu.go.jp/main_content/000723697.pdf ←これをちゃんと理解しつつ実行できてるか、は結構重要。
・INDIRECT関数 rowやらmatchやら数値を返す系の関数をうまく扱えるようになると玄人感出せる
・テーブル化、シートが多いブックで参照が飛び交う場合は命名ルールをちゃんと整理するかCtrl+[ のショトカを活用するかしないと、ここで参照してるテーブルどのシートだっけ？が多発するぞい
ド素人
・テーブルとか言って、今あるデータを見映え加工してる帳票屋を自負すること自体がもうね。
・テーブル化という言葉を知らなかったから知られてみたら、普通にいつも使っている方法だった。GUIだとわざわざその動作の名前を知らなくても良いのが魅力ね。
・整然データになってるならテーブル化してるかしてないかは正直どうでもいい
・テーブル化は汎用性無くなるので嫌い。ピボットテーブルはもっと酷い。
・テーブル化を知った人々、それほどデータもないしょうもないリストまでテーブル化し始めるので、「おぉ、こいつは金槌を手に入れたのだな」って気持ちになる
・AXCELがどうしたって？
・エクセル・サーガ？
社内システムからCSV吐かせて報告書書いてるんだけど
弊社システム正規化なんかクソくらえみたいなふざけたCSV吐き捨ててきやがんの
しゃーないから自分で適当に正規化するかあと思ったんだが
弊社非IT企業でパソコンにはExcelとWordとTeamsくらいしか入ってない
稟議通すのもだるいからVBAでなんとかしようと思う
ほんでVBAよくわかんないから検索して情報集めようとしてるんだけど
Excelは使えますプログラミングはわかりませんみたいな人向けの情報ならいくらでも出てくるけど
まともにプログラミングするための情報はえらい少ない
何千行もあるコード書くわけじゃないから変にスタイリッシュにしようとせず愚直に手続き的に書いてってもいいんだけど
というかVBEで書いててスタイリッシュもクソもないんだけど
なんかいい感じにVBAでプログラミングする方法あったら教えてほしいです
クラスモジュールとか使った方がいいの？
あれ使う気しないんだけど
我
多忙な日々だった。
1日の勤務は所定で8～6時間だけど、超絶な詰め込みの仕事だった。
完全に、常勤と同じ働き方だった。
ちなみに、私以外の職員はエンジニアでない常勤職員が多かったけど、ほぼ定時に帰っていた。
最初は定時で帰れていた。
自分自身の生き方として、私は病気になった家族と一緒に過ごしたかった。
それに、多少は前職の製造業（IT事業がメインだったが）で貯蓄を作れていた。
裕福では全然ないけど。
人間関係は悪くなかった。
どちらかと言えば、上司・同僚も良い人たちだったと思う。
工数の概念はないし、納期ものんびりペースで調整させてもらうことができた。
開発の経験もあったし、Excelは当然のこと、AccessもVBAもSQLも余裕中の余裕だから、現場の仕事では人気になれた。
だから、常勤職員が絶対にやりたがらない電話対応とか、ヘルプデスク対応も、進んで自分からやった。
最初は定時で帰れるように他部署と調整しつつも、上司に提案したりして、新しい仕事も掴みとっていった。
でも、どんどん苦痛になっていった。
非常勤は基本的に雑用ばかりを押しつけられ、楽しそうなやりがいのある仕事は全部常勤職員が取っていくからだ。
でも、仕事の量はどんどん増やされていく。
「残業をつけずに働いたほうが働きやすいよ」とか、「ここの職場では常勤職員と同じように働いても大丈夫なんだよ」とか、
暗に、常勤職員並みにに働くことを求められたことは頻繁にある。
あと、信じられないことも言われた。
「常勤職員並みに働かないと、来期の契約は結ばない可能性がある」
だって。
情報システム部門の管理職（部長・室長）は、現場の仕事の実態を何も理解していなかった。
これが大きな問題だった。
管理職に、システムの実務を経験したことのあ職員が皆無だったのだ。
職員のスキルの実態については、自分以外は誰もAccessさえまともに使えなかった。
Accessを起動してテーブルを参照できるレベルの職員のことを、上司は「Accessができる」と高評価していた。
Accessが使えればSQLも自動的に理解できる、それくらい簡単なのだと言っていた。
バカかよ。
私とは別に委託業者もいて、ヘルプデスクは基本的には業者が対応していた。
私が辞めたあとは、全部そちらに丸投げするらしい。
ヒラの職員からは、「いなくなったら職場が大変になるね」と言われた。
「下の人間がやる仕事」、「外注に回す仕事」と思っているらしい。
SESを馬鹿にするわけではないが、ヘルプデスクに技術的対応ができるSEなんて、ほぼいないのが現実なんだけどな。
上は、ITの実務・現場対応に関しては、「自分たちの仕事ではない」という意識らしいのだ。
辞めた後、私の個人携帯にはヘルプデスクの外注業者の方から、度々、「教えてほしい」のメールが来る。
でも、自分もそうだったのだ。
私は、これでも、やりがいを持って働いていたんだ。
最初はね。
真面目で好感がもてる人だなあ。
2009年とかなら別だけど。
まあフツーならMicrosoft Bookingsやろなあ。
https://blog.formzu.com/microsoft_bookings
予算ということだが月2000円とかケチる会社なら早々にやめたほうがいいｗ
https://www.zoho.com/jp/bookings/pricing.html
感染症対策のために、お客さんが来るときは事前予約を取ることになった。
毎日数組程度なので今は電話で聞いてOutlookの予定表に記載・予定表を共有することで回してるけど、これシステム化したいねって話になった。
最初は予約サイトを立ち上げて運用する案が出たけど、そんな予算は無かったので引き続きOutlookで管理することに。
社内の要望をヒアリングした結果、お客さんには予約希望書（エクセル）をメールで送ってもらうことにした。
VBAでフォルダ内の予約希望書から必要な情報を抜き出しに1クリック、ics書き出しに1クリック、予約確定メール自動作成に1クリックの、計3クリックで完了するシステムを開発した。
（メチャクチャ褒めてほしい。1から勉強した。馬鹿だから3週間かかった。VBAなんて触るの初めてだった）
完成したので担当に送ったら、次は休店日が分かる方が良いよねとか、予約重複の際は警告を出せないかとか、色々と追加要望が。
そろそろ私の手に余ってきた。予約重複の警告ってOutlookが控えめに出してるアレだよね。アレって変えられるのかな。まったく分からん。
休店日は予約希望書エクセル内で入力時に警告出せば良いと思うけどさ。
私の本来の仕事は単なる事務で、開発に時間が取られて自分の仕事が滞ってきたよ。
でも今更「やめます」とは言えないし、関数組んだりマクロでなんとか自分の作業効率化してただけの事務員にはきついものがある。
高卒で三十路手前だが今まで派遣社員として裏方で電話対応のない事務員として働いていた。
タッチタイピングとExcel（VBA含む）は比較的得意だったので、いい加減手に職つけたいと思っていた所、幸運な事にIT企業に拾ってもらった。
入社してから1ヶ月研修があり、javaを使い簡単なアプリケーションを作るという内容なのだが、最終日に役員に向けて発表があるらしい。これが憂鬱すぎて研修内容が頭に入らなくなってしまった。
というのも、俺は新卒で公務員をしていた。昔から人前で話すのが苦手だったが、数をこなせばこなす程慣れるどころか自意識が強まり喋れなくなってしまい、精神を壊してしまった。最終的には精神科のお世話になって仕事を辞めた。数年のスパンを置いて2度ほどwais-3を受けたが、不安事があると俺は動作性知能言語性知能共にIQが20程下がるるしい。
周りの人間も「人前で話すの嫌だなぁ」とは言っていたけど、俺は嫌すぎて目がチカチカするし光がすごい白く感じるしずっと動悸がするし雑談する余裕も無くなるし色んな音が耳元で聞こえてくるし食欲もなるし朝動けなくなる。
プログラミング自体はまあまあ楽しかったし一生コーダーで良いのだが、俺みたいなタイプの人間ってどういう生存戦略を立てて生きているんだろう。
以前一度だけ派遣社員として勤めたことがあるけど、準社員かな？ってくらいハードだった。
年単位の仕事で、スポットでなく2-3年はいて欲しいという業務だった。（この時点で普通の派遣とはちょっと違う）
その部署の派遣社員は全員自分の名刺を作ってもらえて、外部の会社に見積もりを取ったり直接打ち合わせにも出たりできる。
繁忙期があったので、そのときは残業もやれるだけやって良かった。
業務上、ExcelのマクロをVBAで組んだり、イラレで版下を作ったりもした。
時々出張で1週間くらいホテル暮らしになることもあったけど、社員と部屋のランクに格差もなかった。（みんなの部屋の手配をするのも自分だし）
マルチにやってた割に時給は1350円（通勤費別）だったけど、とにかくやり甲斐はあった。
まあ、どんなに長く続けても社員に登用する方針がない会社だったので辞めちゃったし、別の会社で正社員になったけど。
そんな派遣社員しかやったことがなかったので、今の会社での派遣社員はExcelでvlookupができる人もなかなかいないし、簡単な補助業務だけで9-17時で帰れるっていうのが意外過ぎてびっくりしてる。
だから（実在するとして）当時の技術の浸透度を考えてもまじめな判定をしている可能性はほぼなくて
多少はマシなひらがな解析と、適当な思いつきで組んだランダム同然な判定を混ぜた遊び程度のものだと思うんだよね
ランダム同然というのはたとえば文字コードを参照してスコア化するとかでもいい
難しい漢字が出たらスコアを下げるくらいの判定はできるので意外とそれっぽい数字になるかもしれない
ただ文が短かったり、ひらがな・感嘆符が少なかったりすると精度が落ちてランダムスコアの重みが増してしまうとかの意図せぬ特性もありそうだ
