2019-03-13

ITエンジニア向けExcelの研修用教本をどれにするか

新人向けにExcelとExcel VBAを使って「変数」やら「関数」やらについて教えようと画策中なのですが、その中で候補として挙がってきた本があるので、それについてメモを残しておきます。自分用メモです。ちなみに見ているのは2016年の第1版です。

できるビジネスパーソンのためのExcel関数&マクロの仕事術 (Excel for BIZ)

これです。一見した感じ、スプレッドシート上での数値の簡易入力方法やちょっとしたTipsも織り交ぜながら、わかりやすく説明されているようです。以下は、あくまで「文系の大学を出た新卒新人が読んだ場合」を想定した指摘や対応案です。

面白い点

50ページ: 日付と時刻についての話の中で、シリアル値による年月日時刻表現を小数部分まで含めてきちんと説明しているのはいいですね。
53ページ: 同じく日付と時刻の話のコラムで、国による表現の違いについて触れているのも面白いです。
70ページ: 期間に関する計算で、DATEDIF関数のバグについても言及しているのは興味深いです。ただ、市販品にバグがあるという点について新人が疑問を持つようであればフォローは必要かもしれません。
77ページ: 関数を使わずにデータの個数を数えるという話で、ステータスバーの表示内容などについても説明しているのはいいですね。
164ページ: マクロとVBAの説明で、二つを混同せずにきちんと説明されているのが好印象です。マクロ自体の説明は少し乏しいですが、マクロを定義するプログラミング言語としてVBAが用意されているというのはわかりやすい説明です*1。また、この説明を裏付けるように、いきなり「マクロの記録」から入るのではなくVBEを使ったメッセージボックス表示マクロを作るところから入っているのも好印象です。
181ページ: 09章変数とオブジェクト、変数や代入式などの説明はおそらくわかりやすい部類だと思います。配列なども「なぜそんなものが必要なのか」という説明があり、ざっくり言うと「有った方が楽なので」という説明になっていて昨年、私が新人に説明したのとほぼほぼ同じ流れになっていたため好感が持てます。もちろん「有った方がいい」という説明だけでは駄目で、そこから実際に配列を使った簡単なサンプルを一緒に作って体験するという場を設けましたが。

優先度を下げても良さそうな箇所

109ページ: 06章入力補助や自動色付けがある表の作成 …… 実務で使う内容なのでいずれはやっておくべきですが、教育の目的をVBAの習得と捉えた場合、優先度は下げても良いと思います。内容も後半に行くほどそこそこ複雑になるので、言われたとおりにやったからといって頭に入るかどうかという点が少々疑問（あふれるのではないかと）。
139ページ: 07章テーブルと構造化参照 …… こちらも同様の理由で。知っておいて損はありませんが、教育の冒頭というよりは応用編として扱っても良さそうです。
251ページ: 12章ファイル操作 …… まぁ末尾の章ですしここまで来られたらやってもいいですが、どのみちメインの教育対象言語（C#とか）でやるのなら飛ばしても問題無いと思います。

気づいた点

いずれも、自社の新人向け教育に使ったら、という前提です。ある程度仕事の経験があったり、工学部などの理系学部卒業者が見る場合はまた違ってくると思いますので注意してください。

15ページ: マクロやらVBAということばが唐突に出てきます。全くの新人を対象にした4月からの教材とすると、事前にある程度の説明をしておくか、逆に「判らない単語が出てきたら積極的にスキップする」という指示を徹底させるなどの対応が必要かもしれません。もちろんその場で説明しても構いませんが。
20ページ: 冒頭部分で「ショートカット」を「シートカット」と誤記。まぁ判りますが、本当の新人はこのような間違いもきちんと考えて悩みますので適宜サポートする必要あり。
24ページ: 文字列操作の基本として、文字と数値の違い、扱いの違いを説明しています。ただ、プログラムやデータ型といった概念に全く触れていない新人の場合、いきなり用語や考え方の違いで遅れを取る可能性があるので、適宜フォローが必要かと。
44ページ: その他の便利な文字列関数という話の中で文字コードという言葉が出てきます。これも補足が必要であると思います。
45ページ: 改行文字を入力するというところですが、もしかしたら「改行文字」という考え方自体、全く理解できない可能性があります。コンピューターでの情報操作上の都合で「改行」という状況に「制御記号」を割り当てたものが改行文字なので、そのあたりの概念は適宜補足しないといけないかもしれません。
全体: 論理式などの使い方、AND、ORといった論理演算の基礎については補足が必要かもしれません。
85ページ: オートフィルターが突然登場します。このシリーズの別の本から通しで読めば説明があるのかもしれませんが、この本だけを読むと初登場になると思うので適宜フォローが必要です。
88ページ: ついにvlookupが登場します。しっかりとページを割いて説明されているので大丈夫かと思いますが、このあたりが不要という考えであれば除外してもいいかもしれません。
104ページ: データ型に絡む問題の解決というセクションで、セルにシングルクォートを入れた場合に文字扱いされるという件がサラっと出てきます。このあたり、見逃さずにルールを学んで欲しいので補足した方が良さそうです。
203ページ: VBAにおける引数と戻り値の説明で、その前のオブジェクトに関する説明でチラっと出てきたメソッドという言葉が頻発するようになります。メソッド、関数、引数、戻り値などの言葉の相関や意味について、おそらく少しフォローした方が良いように思います。

できるビジネスパーソンのためのExcel VBAの仕事術 (Excel for BIZ)

作者: 西沢夢路
出版社/メーカー: SBクリエイティブ
発売日: 2016/08/27
メディア: 単行本
この商品を含むブログ (1件) を見る

VBA学習の位置づけについて

今担当している教育では、基本、プログラミングの中核はC#を使った講義および実習で学ぶことにしています。当初、プログラミングに関する講義は5月からで、実習も5月中旬くらいから入ってくる予定だったのですが、やはり4月の期間で手を動かす経験をしておかないと「眠くなるだろうなぁ」ということもあり、そこでVBAを入れようと考えています。実際、昨年の研修ではそれでExcelの関数やVBAを使って「そもそも関数って何」「変数って何？」というあたりを教えました。その方がC#の学習のとっかかりで「文法も判らなければ概念も難しい＝ダメだ！」というリスクは低減できるかと考えての措置です。
実際、Excelはセル内で関数を普通に使え、また、その結果が直ぐに見えるので「関数というものの振る舞い」については理解しやすいように思います。

あとは「マクロ」と「VBA」の違いを講師がきちんと説明できるかとか、そのあたりの先輩側の教育ですね。案外このあたり、まともに質問すると答えられない人が多いので。

まとめ

総じて良い本だと思います。上にいろいろ書きましたが、ある程度プログラミングの概念や仕掛けが判っている人であれば、本を渡して「勉強しておいて」でもなんとかなるのではないかと。また、Excel等の入門者、たとえば入社数年くらいの事務方の人が少しプログラミングにも手を出したいなんて場合もそのまま使えるのでは無いでしょうか。
とりあえず今度の4月からはコレを使うということでいいと思います。

できるビジネスパーソンのためのExcel関数&マクロの仕事術 (Excel for BIZ)

作者: 七條達弘,渡辺健,田中雅之
出版社/メーカー: SBクリエイティブ
発売日: 2016/10/29
メディア: 単行本
この商品を含むブログを見る

*1:マクロ/macro: Dictionary.com : "Also called macro-instruction. An instruction that represents a sequence of instructions in abbreviated form. 複数命令の連なりに略称などをつけたもの。C言語における「マクロ」がこの定義そのまんまですね。

2019-03-13

データ登録処理時の確認メッセージと内容チェックの順序

misc. 業務日誌

業務システムを作っていると、データ登録処理なんてのは大量に作ることになるわけで、そのあたりのよくある機能や実装というのはいつものやり方があるかとおもいます。が、そのやり方を選択した理由まできちんと考えていて、人に聞かれたときに説明できるかどうか、というと意外に答えられない人が多いのでは無いかと。

実際、以下のような話が挙がりました。

データ登録処理の際内部ロジックをどう実装すべきか
- 登録ボタン押下 → 登録しますか確認 → データ内容チェック → 登録
- 登録ボタン押下 → データ内容チェック → 登録しますか確認 → 登録

どちらの実装を主張する人も、「普通こうだから」という理由しか話さないので、それぞれの方法を採る理由について考えてみました。

はじめに: これは設計者、実装者の責任です

まず先に言っておくと、この手の方針決めは「いつもそうやっているから」ではなく「なぜなのか」を人に説明できるように心がけましょう。設計にしても実装方針にしても、なんにせよ理由ありきで行うべきです。仕事で作るプログラムや設計に「なんとなく」はNG。特にプロジェクトメンバーが増えれば増えるほど、こうした理由をきちんと述べることで、作業依頼時に相手の腑に落ちる指示が出せますし、並行作業時に都度都度方針ややりかたを聞かれたりする回数も減り、余計な作業コストを出さないようにできます。こういうところに手間をかけず「いいからやれ！」という指示を出すと人間関係やモチベーションといった、修復に非常に手間のかかる部分で損害が出始めます。設計者もプログラマーも、常に「数ある選択肢からこの方法を選んだのはなぜか」に意識を向けましょう。

先に「登録しますか？」確認を行う場合

よくある「登録します。よろしいですか？」的な確認メッセージを先に出し、その後で内容のチェックと登録処理を行うという方式は、以下のような場合に使うと良いと思います。

データの内容に不整合やエラーが含まれる頻度が低い。

たとえば別システムで生成されたデータファイルが元になっている場合など、手作業の割合が少ない入力データの場合に向いています。この方式のデメリットとして、データにエラーがあった場合、利用者は確認メッセージとエラー通知、2回のメッセージを見る羽目になるというものが挙げられます。これがあまり頻発すると「メッセージ出す回数減らしてよ！」という要望につながる可能性もあり、「メッセージがウザい」といったクレームの元になる可能性もあります。なので、そういうことが想定されるなら後述の方式を検討しましょう。

一方、この方式のメリットは「ユーザー側のアクションと、プログラム側のアクションを綺麗に分離できる」ということにあります。利用者の「登録したい」という意思は登録ボタンで決定されているので、まずはそれに対して確認を行うことで「利用者主導の手順」をいったん終わらせます。そこから先はプログラム側の仕事。内容のチェックと、実際にデータを登録する処理を走らせる。たとえば、データ内容チェックと登録処理を合わせた結果を戻り値とする関数にするといった構造にし、入力されたデータの確認結果は「DB登録失敗などのシステム側のトラブルと同じレベルで通知される」ように作ることもできます。そうすれば、登録ボタン押下から始まる「UI系の処理」と「内部系の処理」を分離してプログラムの構造をわかりやすくしやすくなります。

先にデータ内容チェックを行う場合

「登録します。よろしいですか？」の前に入力内容のチェックと、不備があれば「登録できないデータが入力されています。」的なメッセージを出すという方式。この方式の最大のメリットは、データ不備があればメッセージは1回だけでやりなおし。確認メッセージは表示されません。すなわち、不備がある場合でもメッセージ回数は1回で済むということにあります。なので

データの内容に不整合やエラーが含まれることが多い。

という場合に用いると、UI上での利用者とのやりとりを減らすことができます。手作業で大量の入力を行うような場合などですね。ただし、この場合登録ボタン押下イベントから始まる処理は、あくまでメッセージ表示の要否を確認して必要であればメッセージ表示するという流れを主軸にしたものになり、プログラムの構造がフラットな感じになりがちです。よく考えて実装しないと、ひたすらべた書きの処理が並ぶメソッドを作りがち。ですが、利用者にたびたびメッセージを出して手を煩わせることが無くなるという点ではメリットも大きい方法なので、状況に応じて選択し分けましょう。

もう1つの方式: データ確認機能を用意する

全く別の方式として、あまりにデータ不備が多い場合や、利用者自身に「データをチェックしている」という処理を意識させたい場合、「データチェックボタン」のようなものを用意してそれを押さなければ先に進めないようにする、といった手もあります。こうすれば、データ登録時の確認は最低限のものにできます。この場合も「データチェックボタンを配置したのはなぜか」をきちんと考えて、基本設計レベルで設計書に記載しておくと、類似した機能の設計時や実装時の方針決めの指針となることがあります。

まとめ: 理由無しの設計や実装はやめて！

ここまでの内容はあくまで私の私見で、もしかしたらもっと良い考え方や理由があるかもしれません。ですが、仮に最善で無かったとしても方針や設計の根底にある考え方をこうした機能の端々できちんと説明することで、設計に芯を持たせることができます。こういう芯がきちんと見えれば、チーム開発などの場合の意思疎通やコミュニケーションを効率化できますし（迷っても指針があれば自分で決定できる）、最悪、利用者の要求と齟齬があった場合でも、何と何がかみ合っていないのかが明確になりやすいので、問題解消への道筋も立てやすくなります。とにかく、設計者、実装者は常に「自分がなぜそれを選んだのか、なぜそう決めたのか」を考え、必要であれば記述し、必要であれば都度関係者に説明できるようにしましょう。「適切な設計」「適切な実装」は、必ず利用者やシステム全体の仕上がりに好影響をもたらすはずです。