きょうは、「プログラムはなぜ”書く”と言わずに”組む”と言うのか？」 と題してちょっと専門的なお話をしてみたいと思います。

まぁこれは諸説、賛否両論はあるかと思いますし、どうでもよい話のようでもあるんですが(笑)、でも、 プログラムを効率よく作るという観点からこれを考えてみると、結構本質的な面が見えてくるかと思います。

で、「えっ、プログラムって書くものじゃないの？」
と思われた方もいるかと思いますが、日ごろ、自分のマクロの作り方って 効率よくないなぁ～と思ってる人は、今回の話よく聞いてください。

ゴリ書きとは・・・

私が長年携わってきたシステム開発の現場（コンピュータのプログラムを 作る場所）では、プログラムを「ゴリ書きする」 という一種の業界用語があります。

この「ゴリ書き」というのは、その名の通り「ごりごりとプログラムを書く」 という意味であるんですが、プログラム作りを専門にやっているプログラマーが プログラムをごりごりと（どんどん）書くというのですから、これは一見、よい 意味の言葉のようにも聞こえるかと思いますが、、

実は、システム開発の現場で これは決してよい言葉として使われてるわけではありません。むしろその逆で、 悪い意味として使われることが多い言葉です。

そうなんです、プロ（職業プログラマー）にとっては この「プログラムをごりごり書く」（ごりごり書かなければならない・・）というのは、 悪い意味（面倒くさい事や よくない作り方を意味する言葉）に他なりません。

職業プログラマーは書くのが嫌い？

たとえば、マクロの場合でもよくＶＢＡをわざわざ最初から（Sub ～ End Sub から手打ちで書き出す所から）書くような作り方をする人もいるかと思いますが、 賢いプロの殆どは決してそんな作り方はしません。

基本、プロのプログラマーはプログラムを書くのが嫌いだからー、です。
でも、それは事実です。（毎日毎日、開けても暮れても朝から晩までプログラムばかり書いてるわけなので。。）

サンプルコード好きな人はドツボにはまる！

話はちょっと変わりますが、私よくマクロの初心者セミナーなんかの際に「この中に サンプルコード好きな人はいませんか？」と聞くことがあるのですが、

素人プログラマーの方で 一番多い失敗の原因というが、何か自分のやりたい事と似た事をやっているサンプルコードを ネット上から見つけてきて、まずは、それをそっくりそのままコピッペして、後は これの何処をどう直せば自分のやりたいことに使えるのか？と、それを あれこれやりだすわけです。

それで結局、解らずに（直せば直すほどおかしくなっていき・・）案の定ドツボにはまっていって 多大な時間を無駄に費やすだけの結果で終わる というのが、下手なやり方をするアマチュアプログラマーの言わば定番であるわけです。

なので、「サンプルコード探しはやめなさい！！」と、内の生徒の皆さんには いつもそう注意しています。

いいとこ取りで

でも実は、プロの現場のプログラマーというのは皆 「サンプルコード好き」なんです。。(笑)

ただ、プロは見つけてきたサンプルコードの中の一部分 しか使いません。下手な素人プログラマーのように 全部をコピッペしてその一部を直そう・・だなんて そのような考えは一切持っていません（他人のプログラマーは基本信じません！笑）ので、

書き方の解らない部分だけをそのサンプルコードの中から素早く見つけ出して、それで その部分の数行だけをコピッペして取り出して、自分のいま作ってるプログラムの中に 組み込んでいきます。

そうです、うまいプロはプログラムをうまく組み込んで作っていく・・・ というわけなんです。

要するに、 下手なプログラマーいうのは 他人のふんどしで相撲を取ろうとする 人です。それでは到底勝てません。サッカーでいえば、なぜだか不利なアウェーで試合をやりたがるという人が 非常に多いわけです。自ら不利なアウェーに飛び込んでいきたがります。。。

うまいプロは、圧倒的に有利なホームグラウンドで戦うことを考えます。他人のプログラムからは ただ「いいとこ取り」をしている というだけなのです。

コード再利用の正しい順番

それで、そのいわゆる「再利用」のコツ（順番）としては、

１．まずは、自分が過去に作ったコード（確実に動く事がわかっている）の中から探す
２．なければ同様に、自分の身の周り（社内や開発プロジェクトのライブラリ）の中から探す
３．それでもなければ、メーカーが公開しているサンプルコードから探す
４．それでもなければ、本屋の参考書で探す
５．それでもなければ、ネット上で探す

今どきですから、特にこの4番目と5番目は逆でも、AI使うんでもよいとは思いますが、 3番目のメーカーというのはエクセルVBAの場合はマイクロソフト社 （VBAのヘルプ画面の使用例やマイクロソフト社の開発者向けサイトもそうですが、 主にはこれは「マクロの記録」ですね！）ということになります。

「マクロの記録」は人間が書いたコード（こういう操作を記録したらこう書きなさいと人間が機会に指示して書かれたもの）になりますから、AIが書くコードとは違って一定で、間違いがありません。長年の実績もあり、安全です。

（※今どきの生成AIに書いてもらったコードを丸写しにして（完コピして）、そのままVBエディタに貼り付けて実行するといった危険な行為は、絶対にやってはなりません！）

コードは出来る限り書かない

で、本題に戻りますが、要するに、プログラムとは（少なくともうまいプログラマーの世界では・・・） 「組むもの」なんです。決して、Sub ～ End Sub から ゴリゴリ書き始めたりするものではありません。

（プロというのは いつでも納期に追われて仕事してますから、「効率重視！」は当然です。）

あと、「ゴリ書きするな！」（手打ちするな！）という理由にはもう一つあり ます。

人間は必ず、キーボードを打てば可也の確率で打ち間違いというのをするわけ です。たとえば、沢山のデータを入力しなければならないという時に 入力代行業者に頼んで入力をしてもらった場合に、納品されるデータの 正答率保証というのは精々が95%程度です。5%は間違っていたとしても納品業者に 文句は言えません。

これは要するに、1日中データ入力をやっている入力のプロであっても 100個の文字を打てばその中の5文字は間違える・・というわけでありますから、 朝から晩まで一日中キーボードを打つ事を仕事にしてるわけではない我々 入力の素人であれば、有に10％や20％は打ち間違えをするわけです。 キーボードはそれを自覚して打たなければいけません。

しかも、メールやワードで日本語の文章を打つ場合ならまだしもですが、 とにかくアルファベットの入力が多いプログラムというものは ちょっと微妙な打ち間違いをしてしまうと中々自分ではその間違いに気付きにくい ものですよね。

誰しもそうした痛い経験は必ずあるかと思いますが、先日もある方から、

Sub Macro1()
　　a = CStr(ActiveSheets.Name)
　　Sheets("Sheet3").Name = a & "_8月"
End Sub

と、このようなプログラムを書いたんですけど、エラーになる。 原因がわかりません・・とのご質問があったんですが（このコードの内容は、 いま開いてるシート名を取得してそれで他のシート名を変更するマクロです。） これはただの単純な打ち間違いだけです。

誤）　a = CStr(ActiveSheets.Name)
　　　　　　　　　　　　↓
正）　a = CStr(ActiveSheet.Name)

まぁこれは英語と一緒で単数形と複数形の違い（Ｓが付くか付かないか）だけ なので、英語の試験での答案見直しでも同じと思いますが、自分自身では一番 気が付きにくいタイプの間違いの一つであると思います。

だから、出来る限り書かない（可能な限り手打ちはしない！） プログラムの作り方を心掛ける それに尽きるわけです。可能な限り過去に作った確かなものからコピッペして持ってくる。 プログラムは書くという意識でなく 組み込むことを意識して作っていく。

それこそが、できるプログラマーなら皆が実践してる 「効率よいプログラムの作り方」であるわけです。

その辺を知っているか知らないかで、プログラム作りというのは 楽にも苦しくもなる と思いますので、この意識というのはけっこう重要だと思います。

プログラムを読むとは・・・

あと、付け足しですが、一方の【プログラムを読む】という事なんですが、 これ、よくVBAの参考書や雑誌のライターレベルの人が（厳しいプロの現場では到底 通用しないだろうーの人が?!）気安くプログラムを読め だなんてよく言ってるかと思いますけれど、、

【プログラムを読む】とは、 【プログラムの流れを読む】ということでありますので、 言語を読む（コードを翻訳する）という意味ではけっしてありませんですから、そんな何とも トンチンカンな主張 というのは本当、とんちんかん！ですね。笑

(第一、プログラムのコードというものは その全てが単なる記号の羅列に過ぎません。)

情報処理試験とかソフトウエア工学とか、そういった教育をちゃんと受けたことも無い と思しき素人先生の偽主張を間に受けないよう、くれぐれもご注意ください。 （もぉー本当ＶＢＡの世界ってまともに情報処理の勉強もした事ないような デタラメ言ってる人が、おおいこと多い事。。。(困!)）

というわけで、

本日は富士通などでコードレビューを述べ１万回以上はやって来ましたわたくしベテランSEの見地から、賢く うまいプロのプログラム作りのやり方についてお話をしました。ご参考になれば幸いです。