トラブルシューターとしての真価が問われる出題です。あなたの「一手」は？！
講師のラボトミです。よろしくお願いします！この講義で「Excel の原理追究」とは何かを知っていただければと思います。
やりたい作業
結果
先生、よろしくお願いします！ VLOOKUP は確かによく「＃N/A」が出ますね。実務でこれに似た現象が頻発し困っています。特に「式は合っているはずなのにうまくいかない 」ことが、すごく多いんです。
そうですね。この仕組みが明示的にわかっている人は実務家全体の10% もいないと思います。そもそもの原理が見えていません。
１．データタイプの把握・・・・そのセルのデータタイプが「数値」なのか「文字列」なのかはっきり把握できていること。
まず「データタイプ」という言葉が初めての方がいらっしゃると思います。Excel では各セルの書式と入力したデータ（値）を元にして、データタイプが決定されます。データタイプはいくつかありますが、ここでは２つ「数値」と「文字列」を覚えましょう。
「文字列」というのは、普通の言葉みたいなものが入力されたらほとんどこれに該当するんですね。むしろ「数値」とみなされないものは大抵「文字列」だと考えればいいのかもしれませんね。
その理解で大丈夫です。では改めて右のシートを見てくださ い。これを見て、B 列とE 列のデータタイプが一瞬で判断で きなければいけませんよ。B 列、E 列それぞれのデータタイプ がわかりますか？
［根拠１］ B 列の「0058」が「左揃え」になっていること。「 文字列」のデータタイプをとっているときは、セルの中のデータは左に寄る、つまり「左揃え」に表示される。
［根拠２］ B 列の各セルの左上に「エラー」を知らせる緑色の三角（アラート）が付いている。「数字」が「文字列」化しているときによくこのエラー表示が出る。
システムからの出力（CSV 形式）されたID などのデータは、冒頭の「0」が脱落するのを防ぐため「数字」が「文字列」としてExcelに出力されるようになっていることが多いのです。このようにシステムから出力された数字を見たら、今「数値」か「文字列」か、どちらのデータタイプをとっているかを判別できなければいけません。数値は右揃え、文字列は左揃えとして出力されるのが一般です。
●［１．データタイプの把握］ データタイプはそれぞれどうなっているか？
なるほど。「数字」は、「数値」と「文字列」という２つのデータタイプに分かれるんですね。左に寄っていれば「文字列」の可能性が高く、右に寄っていれば「数値」の可能性が高いんですね。
「数字」は２つのデータタイプを取りうる
「数字」と「数値」は違うので注意！
そうです。先程の２つの根拠より、B 列はほぼ間違いなく「文字列」化した数値だと予想されるでしょう。
では、今回も「文字列」という設定が掛かっているのでしょうか。
いいえ、結論としてはE 列は「数値」です。根拠は２つあります。
① E 列の数字が「右揃え」となっている。
②についてはあとで、データタイプとロジカルテストのところで意味がわかると思います。
なるほど。「ユーザー定義」から「0000」と設定をかけると、「58」と入力したときに「0058」と表記されるようになるんですね。
そうです。もしですね、「自分は上記のようなユーザー定義を掛けない」という方がいらっしゃっても、「前の担当者」や「別の担当者」
● B 列のデータタイプ＝「文字列」
●［２．ロジカルテストとデータタイプ］ Excel における「イコール性」とは？
ここまででB 列とE 列のデータタイプが違うことはわかりました。
上記の「E6 セル」の数式を見てください。これはロジカルテストとか論理式と呼ばれるものです。
普通に考えれば、B3 セルとE3 セルは、いずれも「0058」と表記されているので「＝」つまり「TRUE」だと思いますが、嫌な予感がしてきました。
結果は「FALSE」です。つまりロジカルテストにおいては見た目が同じ「0058」でも、「データタイプ」が違えば返り値はFALSE、つまり、「イコール性はない」と判断されるのです。この単純なロジカルテストにおいてFALSE を返すような二者は、VLOOKUP 関数やその他の検索関数でも、マッチングさせることができません。ここに多くのマッチング作業で起こるトラブルの原因があります。
データタイプが違えば、Excel は二者を「違うもの」とみなす。
どんなに見た目が似ていても、データタイプが違えば、「ニ者は等しくない」とみなされる。
●データタイプを変換する関数
つまり、この問題で「VLOOKUP」がエラーを返した理由は、B 列が文字列なのに、F 列は数値だから。ということになるんですね！=VLOOKUP(○○,○○,2,False) 」をうまく埋めることが要求されていましたが、データタイプが違うものをどうやってVLOOKUP するんですか？
データタイプを変換できる関数を使います。VLOOKUP 関数の第一引数は、現状で「数値」なんですよね？それを「数値→文字列」と変換してくれる関数はTEXT関数です。そして数値を文字列に変換できる関数として一般的なものは、「TEXT 関数」です。
●「元データ」自体をいじるという発想は事故のもと
関数により「数値→文字列」の変換を行うには「TEXT 関数」を使えばいいんですね。データタイプなんて全く意識したことがありませんでした！すごく大事なものなんですね！
確かに、下図のようにエラーチェック機能から「数値に変換する」とやれば［商品ID」は数値化して、当初のVLOOKUP 関数で動きます。けれど、B 列の商品ID を他の用途でマッチングさせたくても、もう00 は冒頭に付いてないですね。一旦、数値に変換してしまったことで、後からB 列データを再利用することができなくなります。
エラーチェックで数値に変換してもできるが、「00」が脱落したら後で別の作業をするときに、B 列のデータが正規の[ 商品ID]（00 がついているもの）とマッチングしなくなる。
上の図のように、あとで別の用途に使う可能性もあるため、
むやみに元データ自体を「数値化」すべきではない。
元データ自体を変換することの デメリット
●Excel の最善手を追究する
いつも、その場しのぎで「とりあえず今触っている関数が動けば良い」と思って作業して、後から「困ったな」となるんですよね。
そうですね。各担当者の個人のノウハウとしては、そういう失敗を解決するやり方が蓄積されているかもしれませんが、研修、講義でお会いする受講者の皆様のお話をきくと、多くは「自己流」であり、「曖昧な手筋によって、毎回試行錯誤を繰り返し、結局手作業がその都度入る」という状況に思われます。私は、日本の多くの企業では、そういうExcel の曖昧な手筋を総括して洗練させ、「一本筋の通ったExcel 最善手」をスタンダード化させる時期に来ていると考えています。そのためには皆さんがExcel の「原理」と「操作感」を見つめなおし、再構築し、最善手に習熟するというプロセスが必要です。
講義の前はExcel の「原理」って何？とか「今さらExcel で習うことなんてあるかな」と思っていましたが、Excel にある程度慣れた今こそ、体系的な学び直しが必要だと痛感できました。少し難しかったですが、初めてVLOOKUP の失敗原因が見えた気がします。
教室講義では実際にExcel を動かしながら、動的に理解していくのでもっとラクに楽しく理解できますよ。Excel 力は業務効率化と直結します。今回は「原理」を中心に扱いましたが、さらに「操作感」や「高度な関数の組み方」も学んでいくことで飛躍的にレベルアップできます。部署の全員が一段階上のレベルに到達すれば、かなりの作業が高速で正確になります。教室で皆さんとお会いできれば嬉しいです！
