私が社会人になって勉強したプログラミング言語はExcelVBAです。
オフィスワークには何かとExcelを必要とする場面があり、私もその一人でした。
ExcelVBAでパソコンにルーチンワークを任せたい
Excelに限らず、日々何らかのツールを使って作業するというのは、往々にしてルーチンワークが含まれていることが多いです。
ルーチンワークとは、決まった処理の繰り返しであり、それらは人間がするよりプログラムに任せたほうが効率的で正確です。
そして、パソコンにこれらの作業をさせる為の仕組み作りがプログラミングであり、Excelであれば必然的にVBAを使うことになります。
VBAは必要に迫られて学んだ
私の場合はVBAを学ぼうと思って学んだというより、仕事で必要だから(自分自身が楽をしたかいから)学んだという言い方が正確かもしれません。
完全な独学でしたが、VBAプログラミングの書き方はほとんどネット上にサンプルコードがありました。
ですので、それらの手法やプログラミングコードを読み解き、自身が作成しようとするものに取り入れることで、自分が必要とするツールを完成させることができました。
プログラミングは何を作りたいかが最優先
「プログラミング＝言語を習得する」
とか
「プログラミング＝作法を習得する」
などと考えがちですが、私の見解は、そのようなものは「後回しでよい」でした。
何を作りたいのか？
どのような作業を自動化したいのか？
どのような作業をコンピュータに任せたいのか？
を紙とペンで書き出し図式化出来るか。
これが最も重要ですね。
極論、この作業がプログラミング作業の8割を占めるべきと言っても過言ではありません。
実現したい動きを描けないのに、言語もプログラミングもありません。
まずこれが出来てから、機能を実現するために必要な言語を選別し、コードを書いていきます。コードの書き方はネットに無数に存在します。
サンプルコードの探し方
例えば「特定の文字を判別し、その行数を取得する VBA」等と検索すれば、そのコードはヒットします。
英語を日本語に翻訳するものグーグル翻訳で出来ますよね。
それと同じです。このようにしてコードの部品を収集することは割と容易いです。
しかし、部品をいくら収集しても、何をどうしたいのか？という設計図が出来上がっていないと宝の持ち腐れになります。
まとめ
「プログラミングの勉強＝言語の習得」という誤解は捨て、ある作業の開始から終了までの動きを紙とペンで描けるかが(賢い人は頭ですべて描くでしょう)、プログラミング技術の近道と考えます。
「計画8割・実行2割」がプログラミング作業の基本です。