だいぶ日が経ってしまいましたが、13日の金曜日（！）、
人生で初めて勉強会というものに参加しました。
勉強会というもの自体が初めてで、完全なるビジネス素人がついていけるか不安でしたが、
率直に言って、楽しかったです。
定例会の最後に、宿題として感想文のご用命をいただきましたが、
私は昔から超のつくほど感想文が苦手で、夏休みの宿題もあまり提出できなかった人間でした。
なので、感想文というよりは、この度学んだ内容を私なりにまとめてみることにします。
ただ、例によってまとめるのがへたくそなため、いつも以上に文字多めです…ご了承ください。
ブログもリーダブルにしないとですね。。。
参加の経緯。
ある日ツイッターを眺めていたところ、こんなツイートを発見しました。
「定例会、リモートで参加しませんか？」
…え、リモート？
このブログでVBAの記事を書くきっかけにもなった、憧れのタカハシさん。
地方在住のため今まで参加が出来ず残念に思っていましたが、絶好のチャンスと思いました。
緊張に震えながら少し前のめり気味にリプライを送ってみたところ、
「おお！お声がけありがとうございます！直接メッセージしてもいいですか？」
と、暖かく迎えていただきました。（…たぶん。）
早速、そのまま夜中に入会手続きを行い、各種SNSなどの準備を進めました。
（その勢いで、深夜にもかかわらずそのままタカハシさんに完了報告をしてしまいました…
その節は大変申し訳ありませんでした…）
概要。
というわけで、例によって前置きが長くなりましたが、今回は、
ノンプログラマーのためのスキルアップ研究会（通称：ノンプロ研 ）の
定例会Vol.5に、興奮気味に参加しました。
今回のメインテーマは、ずばり
ノンプログラマーのための『リーダブルコード』超入門。
我流になりがちなノンプログラマー（プログラミングを本職としていない人々）のコードを
「読みやすく、かつ使いやすくするには？」というお話でした。
大筋の内容やコンセプトはタカハシさんの著書（↓）の後半とほぼ同じですが、
今回はそれに加えて、実例とプラスαを学びました。
テクニックや、コーディングするにあたっての心構えなど、
初心者事務員プログラマーにはなかなか自力で手に入れることのできない知識をたくさん共有頂きました。
（あくまでも、指導ではなく「共有」がポイントとのこと。）
それと、前回までは「セミナー」だったのですが、今回からは「定例会」に変更して
みんなが主役！みんなで学ぶ！がコンセプトになったとのことです。
そのため、メインテーマ以外にも、いくつかライフハックのプレゼン（LTというそうです）もありました。
こちらはここでは具体的には書きませんが、こちらもとてもためになるお話でした！
ちなみに、ノンプロ研と定例会の内容について、詳しくはこちらもご覧ください。
▼ノンプロ研
tonari-it.com
▼定例会の公式レポート（主宰のタカハシさんのブログです） tonari-it.com
それでは、今回学んだ内容を、備忘録として記録していきます。
たとえばこんなテクニック。
メッセージの連結。
VBA2年生には知らなかったテクニックのひとつです。
Dim m As String m = “たとえば、“ m = m & “長いメッセージも” m = m & “こんな感じに” m = m & “1行ずつ分解が” m = m & “出来るんだって。” m = m & “すごい。美しい。” Msgbox m
改行のアレ（ _）とかVbCrLfとか、要らなくなります。スッキリ。
そして出力のイメージ。
ほほー。
本職さんとノンプログラマとの違い。
大きく言えば、組織で動けるかどうかということ。
本職プログラマ様は、プログラミングを「仕事」として与えられるので、
組織のフォロー、バックアップ体制が得られるのが、大きなメリット。
チーム内で知識の交換･共有ができ、
また、定期的なレビューで、コーディングを一定の水準に保つこともできる。
対してノンプログラマーは、こっそり（？）コツコツ「付帯業務」として取り組むしかないので、
知識やテクニックが我流になりやすい。
だから俺様コードがどんどん生まれる。そして、過去のコードは負債化して行く…と。
＜注釈＞
他の参加者の方のブログ↓では、女性向けに「お姫様コード」と名付けていらっしゃいました（笑）
www.excel-prog.com
（こちらのブログも、いつも楽しく勉強になるのでノンプログラマーにはオススメです！）
当ブログでもいっちょまえに VBAリファレンス集 なんて偉そうに書いてますが、
先日ここでも修正ポイントを見つけました…はぁ、負債か…
独学だと、知識の確認もアップデートも進まないんですよね。
せめてチームで出来れば、、、というのが孤独な事務系職のボヤキです。
そこで、敢えて自分の知識レベルを晒して、あわよくばレビューをいただきたい、というのを
今後、当カテゴリの隠れ（？）ポリシーにしようと思います。
（だからと言って誤りを広めていい理由にはならないけど…）
コメントの残し方。
ドキュメンテーションコメント。
ネットでコードを検索すると、
コードの上の方に長ったらしく説明が書かれていることがあります。
これを、ドキュメンテーションコメントというようです。
具体的には、何をするコードなのか、また、どうやって使うのかを残すこと。
今までずっと「コメントは少なければ少ないほどキレイ」と思い込んでいて、
いつもコメントが増えるし邪魔だと思っていました…ごめんなさい。
自分で作ったのだから意味が分かって当然、のはずが、
時間が経つと自分ですら読めなくなる。まして、第三者なら読めるはずも無く…
この視点、大事にしたいです。「俺様コード」にも通ずる話。
…邪魔だと思っていたのは、単に私に読み解くだけの知識が足りなかっただけのことですね。笑
ということで、できるだけ後世に残せるように書き方を学んでみます。
コメントの対象レベルは？
↑の話にも関係しますが、後半、「コメントをどの程度残すべきか？」との質問がありました。
タカハシさんからは、「あまり対象のレベルを下げるべきでは無い」とのお答え。
複雑な事をするのであれば、読み手にもそのレベルを求めても良いし、
むしろお互いに評価しあえるようになるべき、と。
…なるほど。
もちろん、専門家レベルのテクニックだったり、入れ替わりの激しい企業とかで
いつも新任者が多かったりすれば、この限りでは無いと思いますが、
コピペするにしたって、「ちゃんと」意味を知った上で使わなければ、後々事故につながる。
そのためには、書き手と読み手双方でスキルアップをしていかなきゃいけない。
ということですよね。
人に要求することがあれば、完全にではなくとも機能を理解してお願いするようにしよう。
命名は、センス良く、お行儀良く。
コメントも大事ですがやっぱり…
「変数名」などの「命名」に気を使ってあげれば、
そもそもコメントだって要らなくなる！
これは本にも載っていました。
本を読んでから、私も日々気をつけているつもりではあります。
ただ、「センス」が難しいんですよね…
Googleさんと翻訳ごっこしても、聞いたこと無いし意味もピンと来ない言い回しになるんです。
結果、日本語でコメント。
THE 本末転倒！＼(^O^)／
というわけで、方法としては、
- 「何をするか」ではなく、「（それを使うことで）何が起こるか」を示す
- Boolean型を返す関数、プロシージャなら、is～, has～, can～などで「～かどうか」形式にする
- マジックナンバー（数値や文字列の直接指定）は定数にしちゃう
- キャメル形式とスネーク形式を使い分ける ▼参考 qiita.com
などなどを挙げられていました。
ちなみに、今回の内容に合わせて（でしょうか？）、タカハシさんのブログで
このような記事↓もアップされていました。
まだ試せてないのですが、とても便利そうです！！
ごめんなさい、たしかに記事を読んだはずなのですが該当のページが見つけられず…
私自身も少しずつセンスを勉強しなくては…
モノは試しで。
早速、
- 「何をするか」ではなく、「（それを使うことで）何が起こるか」を示す
↑を参考に、早速こちら↓も変更してみました。
'変更前（＝条件付き書式をセットする） Sub setConditionalFormatting() '変更後 Sub setCheckSheet()
"ConditionalFormat"なんて聞いたことないし。笑
VBAやる方ならエクセルで「条件付き書式」は使ったことあると思いますけど…
ちなみにちなみに、感想文とあわせて宿題のあった、現時点で私のベスト・オブ・変数名は、
MySweetMemories
です。笑
メールサポートが仕事で、過去の対応履歴（アーカイブ）を個人的に残しています。
クレームも、ストレスたまる案件も全部、いまの私の栄養と思いたい。そんな意味で。
第三者が意味を理解できるかというとアレなので、
今回の宿題として求められているのとは多少意味が違うと思いますが。。。
データは構造化。
ここは本を読んでも定例会でも理解が追い付かなくて。
いまいちピンと来なかったので、少し調べてみました。
コンピュータはデータの計算や加工が得意です。
人間は、コンピュータを進化させながら、今まで色々な作業を覚え込ませて任せてきました。
そして、コンピュータが「パーソナル」になるにつれて、使う人のレベルや目的が変わってきました。
パソコンが広く普及したおかげで、扱うデータもどんどん多様化し、複雑になって行きます。
例えばエクセルで言えば、セルの「番地」は、関数やプログラムでよく使う大事な大事なデータ。
それなのにセルを「連結」したりすると、資料の作成など視覚的には便利ですが、
他のセルは吸収合併の犠牲になり、「地名」が無くなります。
結果コンピュータには、確かにそこにあったはずの住所が隠されてしまうので混乱を招きます。
必然的にプログラミングも、複雑になり難しくなります。
そこで1つ、「構造化」の工夫が必要ということ。
たとえばこういうのや
こういうのではなく、
こんな感じに。
※画像はイメージです※
見た目は落ちるけど、コンピュータにやさしい形に整えておく（＝構造化）のが大事。
…CSVファイルのような二次元配列が基本、という理解で合ってるでしょうか。まだちょっと自信が無い。
これ質問箱で聞いてみようかな。
まとめ。
最後に、ここまでの内容（とその他諸々）をまとめて、
コーディングのスキルとして以下の3つを挙げられていました。
- （とりあえず）うごく
- （コードの意味が）わかる
- （良いコードの）書き方がわかる
これを、リーダブルコードの三段活用と言います（言ってない）。
これをマスターして、アン・リーダブルなライアビリティたちをソフィスティケートして、
クールなノンプログラマになりたい！と思いました。
…ああ、しかしまずこのブログがイケてないよ！！悔しい！！！！