プログラマーの真似をしない!非プログラマーのためのプログラミングの心得

非プログラマーのためのプログラミング

製造業のエンジニアの中には、プログラマーではないけれど、仕事上プログラミングを避けて通れないという人もいるのではないでしょうか? ルーティン作業をなんとかしたい、でもプログラミングのプロではないから、ちゃんと作れない。仕方なく、毎回適当に作業しているといった状況です。

作業を効率化し、付加価値の高い本来の仕事に集中するために、非プログラマーは、どのようにプログラミングに取り組めばよいのでしょうか。半導体メーカーの現役エンジニアが、非プログラマーのプログラミングについて考えます。

何のためのプログラミングか? 伝説の先輩の話

大学時代、私の所属していた研究室では、伝説の先輩の話が語り継がれていました。その先輩は大事な論文発表の前日の夜、発表原稿の修正に追われていました。発表当日の明け方、ようやく原稿が完成した後、少し仮眠をとることにしました。ところが、研究室に目覚まし時計がありません。パソコンで、自分で目覚ましプログラムを作ったのです。

プログラミングに要した時間は1時間半。そもそも仮眠できる時間は3時間しかなかったのに、その半分を費やしたことになります。しかも、その目覚ましプログラムは、ビープ音を鳴らすだけのシンプルなものだったので、結局起きることができず、その先輩は大事な論文発表をすっぽかしてしまったそうです。

これは極端な例ですが、製造業の非プログラマーのエンジニアにとって、プログラミングは目的ではなく手段です。仕事の中でプログラムを組む作業は、あくまで生産や開発のため。本業のシステムエンジニアとは違う考え方をしなくてはなりません。今回は非プログラマーにとって、より効果的なプログラミングとの付き合い方を考えてみましょう。

非プログラマーのプログラミングは、何が違うのか?

まず、非プログラマーによるプログラミングと、本業のプログラマーのプログラミングの特徴について考えてみましょう。一体、何が違うのでしょうか?

1:規模が小さい

本職のプログラマーは、トータルで何千人月といった大規模なシステムを組みます。一方、非プログラマーのエンジニアが取り組むプログラムは、数日、長くとも1か月程度のごく小さな規模のものです(基本的に片手間なので、その程度が現実的な限界です)。

2:使う人が限定されている

例えば、Microsoft Officeのようなソフトウェアは、非常に広範囲なユーザーを想定する必要があります。リテラシーの高いユーザーだけでなく、パソコンを使い始めて1か月のおばあちゃんでも、問題を起こさないものでなくてはなりません。 一方、非プログラマーが作るプログラムのユーザーは、基本的にその道のプロです。社内の人間だけ、同じグループの人間だけ、さらに自分だけ、という場合も多いです。想定外の使われ方をするケースはあまりありません。

3:プログラミングをする環境が、バラバラ

プログラミングは進化が激しい技術分野です。本職のプログラマーは、それに対応した効率的な環境(プログラミングソフトウェア開発環境)を使うことができます。 しかし、非プログラマーの場合、測定器や生産設備のソフトウェアの制約から、特殊環境でプログラミングをしなくてはいけません。

例えば、測定器のパソコンが古くPC-98(NEC製)時代のN88-Basicというプログラミング言語を使わなければならなかったり、ソフトウェアベンダーの独自マクロしか使えなかったり、またあるときはLabVIEW(ナショナルインスツルメント製)のようなグラフィカルプログラミング環境を使うことがあります。効率的なプログラミング環境とは、とても言えません。

非プログラマーのプログラミングを効率的にするポイント

これを踏まえて、製造業の非プログラマーが、プログラムを書くときの方針について考えてみましょう。

1:最初にマニュアルを見ない。サンプルプログラムをコピペ(コピー&ペースト)

まず、マニュアルや入門書を読むというスタイルでは、効率がよくありません。すべてを勉強しても、すぐには役に立ちません。なるべく無駄を少なくするために、やりたいことをできるサンプルプログラムを探して、それを改変するという形でプログラムを書くのがよいでしょう。

もし、適切なサンプルプログラムがない場合は、社外への業務委託も考えましょう。ただし、丸投げをしてはいけません。使いづらかったり、改善が難しくなったりします。自分が理解できる仕様で作ってもらいましょう。

2:冗長になっても、バグを発見しやすいようにする

プログラミングで一番難しいのは、バグ取りです。多くの場合、使いながら、バグを修正することになります。この場合、危険なのは、一見すると正しくみえる結果を出すバグです。変数の初期値にありえない値を入れるなど、すぐ異常に気付けるように工夫しましょう。

プログラムを読みやすくすることも大事です。例えば、処理を細かくサブルーチンに分けすぎると、ジャンプばかりするので、プログラムの流れが追いにくくなることがあります。もし、デバッグ中に「この関数って、何だっけ?」と何回も確認するようであれば、いっそのことメインのルーティンに書き込んだ方が早いかもしれません。

3:ユーザーインターフェース(UI)、エラー処理、汎用性は、手を抜く

使うのは自分や同僚のエンジニアですから、ユーザーインターフェース(UI)に凝る必要はありません。また、入力値のチェックも不要です。変な入力をすれば、変な結果が出るので分かります。プロのユーザーにとって、親切さは必須ではありません。プログラムをシンプルにするために、どんどん省いていきましょう。これは前の章でも説明したバグ取りのしやすさにもつながります。

また、後からプログラムを拡張するための工夫(汎用性の追求)も、無駄に終わることが多くあります。確率の低い機能追加に備えるくらいなら、早く終わらせて、他の仕事をしましょう。

非プログラマーのプログラミングを効率的にするポイント

プログラミングが得意な人ほど、ワナにはまりやすい

実は、エンジニアにとって、プログラミングは、得意な人ほどワナにはまりやすいのです。プログラムを書くのが好きなので、より汎用的に、よりエレガントにと、どんどんのめり込んでいってしまいます。その結果、1日の作業を短縮するために、2日かけてプログラムを組む、といった非効率が生まれます。仕事でプログラムを書くときは、常に目的を意識することが大切です。

また、プログラミングが苦手で避けてきた人にとっては、上記の3つのポイントをマスターすることで、仕事の効率を大きく向上できる可能性があります。今回紹介したように、サンプルプログラムを使ったプログラムであれば、イチから学ぶより障壁は低いはず。ぜひ、チャレンジしてみてください。