小手先のExcelテクニックを学ぶ前に、リレーショナルデータベースを学べ

巷には「超速Excel仕事術」、「仕事に差がつくExcelテクニック〇〇選」のような書籍や記事が溢れていますが、私はこの手のものに甚だ疑問を感じております。
仕事でExcelを使う以上は関数やテクを学ぶ必要はあるし、何かを調べたい時に役立つ記事もあるのですが、「これを学べば超絶仕事ができる様になる！」といった論調の記事が散見される現状には、苦言を呈さずにはいられません。

Excel操作が得意でも本質的に仕事ができる事にはならないし、PCが普及する前の時代で言えば、ペンと計算機と方眼紙が使える事をドヤっているのと同じです。
Excelを酷使する職種の方ならともかく、小手先のテクだけ覚えて一つの作業時間を数秒～数十秒短縮したところで、普通のサラリーマンに新たな仕事の付加価値がどれだけ生み出せるのか？と問いたい。
数千～数万行、複数のシートに渡るデータを扱う様になって初めて、様々なテクの積み重ねが活きてきます。

私は決してExcelを否定しているわけではなく、もちろんExcelを含めた表計算ソフトは現代の仕事における必須ツールです。
基本ノーコードで、しかも2万円未満の出費でこれほど多彩な事が出来るExcelというソフトは、世紀の大発明とすら思っています。
（最近はGoogleスプレッドシートなどが無料で使用できるからさらにすごい）

また私は、IT業界を含めて長らくコンサルタント業をやってきましたので、Excelの使い方に少々のこだわりもあります。
今まで数えきれないほど、『空気を読まないセル結合、同じ列でのデータ型不揃い、フィルターしながら使いたいリスト型のデータで1列目にブランクを作るアホ』といった、様々な悲劇を見てきました。
その度に、お前がしたクソ編集がどれだけ後工程に影響を及ぼしているのかを小一時間ほど問い詰めたい気持を抑えて優しく修正のアドバイスをしてきましたが、冗談はさておき「取り組んでいる仕事の目的」と「ツールの本質」を理解した上で文明の利器を活用しましょうというのが、今回の記事を通じて申し上げたい事のひとつです。
本来Wordで作った方が良い文書をわざわざExcelで作ってしまう悲劇を回避する、といった概念もこれに含まれます。

前置きが長くなりましたが、今回の記事でまずお伝えしたいのはタイトルの通り、「小手先のExcelテクニックを学ぶ前に、リレーショナルデータベースを学べ」という事です。
全ての職種でとは言いませんが、少なくともExcel等を活用した業務管理、データ整理や分析を行う事が多い仕事では、リレーショナルデータベースを学ぶことで劇的にその品質が上がります。
そればかりか、適切に業務設計して処理・遂行できる仕事の基礎力さえ身につくと思っています。

たぶん、この記事で言いたい結論はこんな感じです。

リレーショナルデータベースを学ぶことで・・・

〇情報を体系化する能力が身につく
〇分析能力が身につく
〇論理的に業務を設計し、適切なステップで処理・遂行する能力が養われる
〇結果的に、変なExcelの使い方（良く揶揄されているような）は死んでもしなくなる
〇Excelだけでなく、Notionのようなノーコードツールもより使いこなせるようになる

ではなぜ私がそう考えるのか、以降でお話して参りましょう。

1.リレーショナルデータベースとは？

今回のお話を始める上で、まずリレーショナルデータベースについてご説明せねばなりません。
リレーショナルデータベースは様々あるデータベースの種類のうちの一つですが、詳細まで説明するときりが無いので、今回は必要な基本事項だけご説明します。

身近なところではMicrosoft Accessがリレーショナルデータベースの一種なので、これを使って勉強するのが一番手っ取り早いと思います。

リレーショナルデータベースをめちゃくちゃ単純な絵で表すと、以下の様な感じです。

この様に、複数のデータをテーブルと言われるExcelのような箱で別々に持ち、ある情報項目でテーブル同士を関連付けます（赤い線のところ）。
上の図では、「顧客ID」が顧客テーブルと受注テーブルで共通の項目となっています。
こうすると、受注テーブルには「顧客ID」を入れておくだけで、顧客テーブルから顧客名、住所、電話番号といった、「顧客ID」に紐づく顧客情報を引っ張り出してくる事が出来ます。
それがクリーム色の表のイメージです。
ちなみに★の主キーは、テーブルのレコード（1行のデータ）を一意に定義するものです。
その為、主キーに重複は許されません。

では、会社の業務で考えてみましょう。
例えば、個々の受注に対して受注伝票を作りたいという目的があったとします。
受注伝票には、受注番号、受注日、顧客名とその情報、受注の明細等が記載されます。
データベースが無ければ毎回毎回、受注伝票の雛形にこれらの情報を手で入力する必要がありますが、数が増えれば増えるほどこの作業は大変です。

ではデータベースを作って、そこに入っているデータが自動で伝票形式の帳票に出力される仕組みを作ろう。
その為に、テーブルにデータを入力して溜めていきます。
ただもし、このテーブルが一つしかなかった場合、結局は毎回毎回、日付、顧客名、住所、電話番号・・・etc. を入力する事になり、仕事は全く楽になりません。

そこで複数のテーブルを作成し、データを分割して保持します。
まずは顧客データを保持する顧客テーブルを作ります。
ここに入るデータは顧客情報に変更がない限り、一度入力すれば次回から再入力する必要はありません。

次に、受注伝票の頭の部分になる受注テーブルを作ります。
さてここで、顧客IDの活躍です。
こちらのテーブルには顧客IDさえ保持しておけば、その他の顧客情報を持つ必要が無くなります。
リレーションを使って顧客データと受注伝票のデータを組み合わせる事で、まず伝票の頭の部分までが作れます。

ここまではデータベースの仕組みをお話したのでイメージがつきにくいかもしれませんが、あなたが会社の業務システムで受注伝票を打つ時を想定すると、こんな感じです。

あなたが既存の顧客から、新規の受注をもらいました。
顧客データは既にマスタに登録されています。
あなたは受注伝票入力画面を開き、発注をしてくれた顧客を画面上で選びます。
一般的な業務システムでは、プルダウンで顧客名を選択したり、検索窓を使って探せるようなタイプが多いと思います。

あなたが顧客名を選んだ時点で、システムの裏では顧客IDが選択されています。
そうすると、顧客IDに紐づく顧客の住所、電話番号などの情報が、パパっと伝票の各項目に自動で提案されるのです。

しかし、これだけの情報では受注伝票としては不十分です。
受注明細も必要なので、受注明細テーブルを作り、受注IDなど受注を一意に定義するキーで受注基本データと関連付けします。
また、既存商品の名称や価格を毎回手で入力するのも面倒です。
そこでさらに、商品マスタのテーブルも作ります。
そうすると伝票入力時に商品IDだけ入力すれば（実際は入力画面上で商品を選択すれば）、価格やサイズなど、商品マスタに入っている情報なら何でも引っ張って来ることが出来るようになります。

かなり簡略化してご説明しましたが、データベースを使用した一般的な業務システムの裏側では、こんな事が起きているのです。

2.次は、業務システムについて考えてみる

ここまでで、リレーショナルデータベースを使った業務システムがなんとなくイメージできる様になったかと思います。
では次に、業務システムについてもう少し考えてみましょう。
わかりやすいように、また受注伝票システムを起点に説明します。

受注伝票システム（または機能）自体の目的は、顧客からの受注データを入力・保持し、最終的には受注伝票として出力する事です。
また後工程となる他部署へ視野を拡げると、受注データに基づき製造部門に適切な製造指示を出す、あるいは倉庫管理部門に出荷の指示を出すといった事も目的になってきます。
経理部門なら売掛金を管理したいです。

例えば製造部門には、商品毎の製造数とその期日を渡します。
その為には今入っている仕掛中の受注データを集計し、さらに現在倉庫にある在庫数との差額を算出して、商品Aは12月20日までに1,000個、商品Dは12月24日までに500個といった情報が必要です。
出荷を担当する倉庫管理部門では、12月27日までにどこどこの鈴木商店へ、商品Aを100個、商品Cを30個のような出荷指示書が欲しいです。

すごく簡単に言うと業務システムとはこれらの目的から逆算して、どんな種類のデータをどのような形で保持し、どうやって料理して出してやろうかを考えて設計されるものです。

つまり、「入力（Input）」→「処理・分析（Processing）」→「結果（Output）」を考える事です。

3.「入力（Input）」→「処理・分析（Processing）」→「結果（Output）」は全ての仕事の基本

見出しを見て、いきなり話が飛躍した様に思えるかもしれませんが、割とまじめに私はそうだと思っています。
まずは個人の業務で考えてみましょう。

販売促進部門で勤務するあなたが上司から、「先日打ったキャンペーン広告の効果を調べてレポートしてくれ」と指示されました。
まずあなたは、どんなレポートを出せば（Outputすれば）上司が満足してくれるかを考えます。

次に、どんな情報を集めれば（Inputすれば）良いかを考えます。
いつどこの地域に、どれだけの量の広告を打って、いつまでにどれだけの問い合わせがあり、何件の受注を獲得できたか。
一般的には、こんな感じでしょうか。

それからこれらのデータをどのように処理・分析し（Processing）、レポートにするかを考えます。
例えば、地域毎の反響率を広告数と問合せ数から算出し、比べる事が出来そうです。
もし地域ごとに顕著な違いが現れたら、調査するべき新たな課題が見つかります。
時間があれば、それぞれの地域の世帯特性や、周辺の競合の存在などを調べる事になるでしょう（追加のInput）。
仮に反響率が似通った地域同士でも、受注率に差異があれば、各地域の営業担当部門への示唆が必要になるかもしれません。

あなたが上司の期待水準を正しく理解し、目の付け所が大きく外れていなければ、見出しのステップを何度か繰り返す事でかなり高い品質のレポートを提出する事が出来ます。

営業職にも応用できます。
見出しの概念をデータベースや業務システムから少し抽象化して、営業のステップに当てはめてみます。
営業職の目的（Output）は多くの場合、売上高や成約件数になるのではないでしょうか？
営業するターゲットやプロセスがある程度定型化されているのであれば、

(1) Input
・営業ターゲットとなる企業のリストアップ
・リストアップした企業へテレアポやメールなどで接触　etc.

(2) Processing
・商談アポ設定とその管理
・商談の準備と実施、提案プロセスの管理
・見込み客のランク付け（優先度や成約確度の高低）とその管理
・見込み客毎の提案内容や想定受注額（または見積）の管理　 etc.

(3) Output
受注額、契約件数など、自分の目標

のようにマッピングできそうです。
（一口に営業といっても、その業務の性質によって状況やプロセスは変わってきますので、上記はあくまで一例です）

ここまでで例に挙げた業務ではわざわざデータベースまで作る必要は無さそうですが、おそらくExcel等を活用する事になるでしょう。

過去に使用したフォーマットや、その為の業務管理システムが既にあれば良いですが、自分でイチからやろうとした時は途中で色々と悩むことが出てくるんじゃないかと思います。

例えばキャンペーン広告効果のレポートであれば、反響があったお客さんの住所、性別、年齢、過去の注文履歴などの属性情報をどこまでInputするか？
（会社が保持できている情報に限りますが）

営業であれば、最初に作るターゲット企業リストにはどんな情報を保持しておくべきか？
また後々の管理の事を考えたら、企業所在地のエリア区分はどう区切っておくべきか？（単純に市区町村だけでなく、城東エリア／城南エリアなど）
営業プロセスの進捗管理の為のステータス区分は？（アポ済み/見積作成中など）
見込み客ランクの名称とそれぞれのランク付け定義は？

などなど、必要な情報項目が網羅されている事はもちろん、それらを後々に集計・管理する事を考えて適切な分類ができる様にしておく必要があります。

◆必要な情報項目：
データベースのテーブルやExcelで言う所の、右に延びていく「列」。
例えば一口に『住所情報』と言っても、後々の集計や業務効率の事を考えてあえて、郵便番号や県、市町村を別々の列に分割する場合もある。

◆「適切な分類」の例：
・営業エリア区分→訪問効率や地域特性などを考えて、通常の住所以外に『城北／城南／城東／城西』の様な分類を付ける。
・見込み客ランク→A（9割5分成約になる）、B（8割方）、C（五分五分）・・・E（管理外） etc.

これらはつまり、情報を体系化する事に他なりません。
情報を体系化する能力が身につけば分析力も高まりますし、業務の効率化や品質アップにもつながります。
先ほどの営業の例で言えば、この様に情報を体系化して分析を繰り返す事で、自分の成約率や見込みのランクアップ率などを客観的に把握する事が出来ます。
ここまで来れば、Output（目標）の為にどのくらいの営業活動量を担保すれば良いのかが見えて来ますし、より少ない活動量で成果を出したければ、どのプロセスを改善すれば良いかの仮説が立ちます。

既存のグループウェアや、営業ならSalesforceなど使っている場合も多いかも知れませんが、ぜひ一度は自力で業務管理の仕組みを作ってみて欲しいです。
遊びでいいので、Accessの様なデータベースソフトを試してみて下さい。
始めは設計でかなり悩みますが、情報管理のリテラシーが飛躍的に高まります。

また業務で使用する事を想定すると、ただ情報をきれいに蓄積しておくだけでなく、業務の流れやオペレーションを考慮する必要が出てきます。
（これには、業務にシステムを合わせるのか、システム導入を機に業務も変えるのかの両側面がある）

情報の体系化に加え、さらに時間の流れ（業務フロー）が加わるわけですから、これはかなり高度な事ですよ。

このように、リレーショナルデータベースを使って簡単なシステムを作ってみる事で結果的に、論理的に業務設計し、処理・遂行する能力（あるいはリテラシー）が養われると私は考えます。
リテラシーが高まると今までやった事が無い仕事でも、こんな情報収集から始めて、こうやって進めて行けばいいのかな、というのがなんとなく見えてくるようになります。

コンサルタントが、アナリストという職種（調査やデータ分析、一部の資料作成などが職務）からスタートする理由も、この辺にあるのではと思っています。
アナリストは膨大なデータの収集と分析、アウトプット作成を経験します。

ここまでを一度まとめます。
以上の事が、私がこの記事の冒頭で挙げた以下の結論を考えるに至った理由となります。

〇情報を体系化する能力が身につく
〇分析能力が身につく
〇論理的に業務を設計し、適切なステップで処理・遂行する能力が養われる

ちなみに私は、新卒で入社した会社でリレーショナルデータベースに触れる事になりました。
その当時は人事総務として勤務していたのですが、給与計算、賃金台帳、給与明細が全て手作業（手書き含む）で管理されていました。
2001年頃の話なのでまだまだ、PCと手書きが混在している会社も多かったと思います。

これはさすがにやってられんという事で、独学でリレーショナルデータベースの概念を学び、Microsoft Accessで賃金管理システムを作ってみたのが最初の体験です。
今ここで記事を書いている様に、業務時間を短縮した事以上に得るものが多かったと感じていますよ。

4.リテラシー不足が引き起こすExcelの悲劇、誤ったITツールの使用を撲滅しよう！

記事の冒頭に書いた、『空気を読まないセル結合、同じ列でのデータ型不揃い、フィルターしながら使いたいリスト型のデータで1列目にブランクを作るアホ』といったExcelの悲劇。
この様な悲劇は突き詰めれば、基本的な情報管理のリテラシーを皆が持っていれば、そうそう起こりえないと私は思うのです。

ここまでの事を実践した人は、後工程に影響が出る様なExcelのクソ編集は、死んでもしなくなるでしょう。
なぜなら、データベース構築やExcelの管理表を構築する過程で、「ああ、こんなデータの持ち方をするんじゃなかった」、「ここのテーブル設計をこうしておけばもっと楽だったのに」等と、おそらく何度も失敗と後悔を繰り返したはずだからです。

『空気を読まないセル結合』なんかはこれらと比べたらもっとレベルの低い話ですが、故にあなたは死んでも、この様な過ちは犯さなくなっていると思うのです。

今どきは日常業務でGoogleのスプレッドシート等を共有して使う場面も多いと思いますが、全角数字で金額を入れるような愚か者がいない、平和な世界を目指しましょう（笑）。

※シートの保護や入力規則を使えばいいじゃん、という突っ込みはここでは無しです（笑）

さて、ちょっと冗談めいた極端な例の話をしましたが、皆の情報管理リテラシーが高まれば日常業務のストレスが低減し、仕事の効率性や品質もかなり変わると私は真剣に思っています。
IT関係や管理部門系の職種以外の方にも、基本的な情報管理のリテラシーは是非身につけて頂きたいです。

リテラシーが高まるという事は、「仕事の本質を理解し、最適なツールを選び、最適な方法で活用する」という視点にもつながってくるからです。

ある程度費用をかけても、ITベンダーを使ってしっかりとした業務システムを導入すべきか？
あるいは、サブスクで安価に利用できるグループウェアやノーコードツールを導入し、自社でカスタマイズすれば十分対応可能か？
そんなことせずとも、Excelやスプレッドシートで間に合うか？

簡単に言うと、こういう事です。

昨今は経済記事を見るとDXという文字を目にしない日は無いですし、私は仕事柄、毎日様々な企業の求人を見ていますが、DX関連の職種は本当に多いです。
一方で、DXという言葉が独り歩きしていると感じる事もあります。
ITテクノロジーの進歩と導入が、企業の経営課題を何でも解決してくれる、みたいな風潮を一部から感じる事があるのです。

少々また話が飛躍するかもしれませんが、業務の本質を理解して適切にExcelも使えない人には、DX戦略の構築は到底出来ないと思います。
またテクノロジーを使うユーザー側にも、ある程度のリテラシーが無いと現場での活用も難しいと思っています。

もの凄いスピードで進化・変化を続けるテクノロジーを、死ぬほどある選択肢の中から選んで企業の課題解決につなげるわけですから、それ相応のリテラシーが求められます。

DXが上手くいかないケースと言うのはまず、経営トップ陣のリテラシー不足が多くの原因かと思います。
ベテランは「仕事の本質」は良く理解しているかも知れませんが、「最適なツールを選び、最適な方法で活用する」為のリテラシーを是非学んで頂きたい。

一方若手の方の場合は、ITやテクノロジーに対する理解がある人は多いかも知れません。
ただ、仕事の本質に迫る経験値がまだ少ないと思いますので、「入力（Input）」→「処理・分析（Processing）」→「結果（Output）」の基本を訓練し、未知の仕事でもある程度業務設計が出来る位のリテラシーを身につけるべきです。

大きな仕事も小さな一歩から。
また、一事が万事という言葉もありますね。

その第一歩として私は、『小手先のExcelテクニックを学ぶ前に、リレーショナルデータベースを学べ』というひとつの方法論を提唱します。