AI は確かに重要な技術です。機械学習、ディープラーニング、ビックデータも重要なキーワードです。ですが、そこに行くまでのずっと手前に大切なことがたくさんあります。その一つとして、データベースの重要性を考えてみましょう。デジタルトランスフォーメーション（DX）のトレンドも、ビジネス基盤やビジネスモデルに IT 的発想と具体的なIT技術を導入することに還元されます。 そこに近道はありません。意外と地道なことを地道に積み重ねていく必要があるのです。今回は、ビジネス基盤としてデータベースの重要性を考える機会を提供出来ればと思います。
データは意味とセットで
コピペマシンのような人
ある企業が業務を精査したところ、基幹業務ソフトから別の集計業務を行うために、十数回のコピぺ（コピー＆ペースト）が必要だったということです。会社でみんながパソコンに向かって熱心に作業していれば、仕事をしているように見えます。しかし、そこにひそむ膨大な無駄が検証されることは少ないようです。
非効率な業務を見直すことなく、コピペ作業や定型的な操作を自動的にやらせようという動きもあります。RPA=Robotics Procedure Automation と呼ばれる技術です。しかし、わたしは RPA を懐疑的に見ています。画面上のボタンやメニューを位置で覚えさせて、操作を自動化する RPA にはリスクや無駄も多いからです。IT で効率化することが大好きな筆者ですが、RPA に過度な期待は禁物、ナンセンスだとさえ思います。
微妙な違いの行き着く先は
可能な限り、CSV（Comma Separated Values）でのインポート・エクスポートとバッチ処理、 XML（Extensible Markup Language）/JSON（JavaScript Object Notation）等のデジタル形式のフォーマットで API（Application Programing Interface）と呼ばれる連携仕様による連携を第一義に考えるべきです。
ここは、AI や IT を考える上で重要なポイントの一つです。十分に考察しておきましょう。RPA は画面のボタンやメニューの位置と操作の手順を覚えているだけです。
ソフトは何をしているか、わかっていません。60ピクセル隣のボタンが、【保存】なのか、【すべて削除】なのか、わかっていないとしたら、おそろしくありませんか？
わたしはこういう方法でコンピュータに仕事をさせることには反対です。そもそも、人間にやらせることも反対です。
人間もコンピュータも、あくまでも意味とセットで仕事をするべきだと思うのです。AI が進化して、人間の知能を超えてしまうレベルをシンギュラリティ、技術的な特異点と呼び、人間を脅かす存在になる危険性に警鐘を鳴らす人がいます。
しかし、わたしは RPA の方が危険に感じます。RPA でも、画面の位置ではなくて、ボタンの名前から対象となる操作を選択する方法もありますが、高度に進化したコンピュータにフロントエンドで指示を与える操作では、その意味と影響の範囲に重みを与えることも考えておく必要があります。
余談ですが、某大手企業では RPA を導入した際、誤作動していないか人間が張り付いて監視していなければならないそうで・・・。なんともシュールでディストピアな世界です。
根本的な問題を置きざりにしていないか
そもそも論として、紙をベースにした業務をそのままにして、RPA で自動化させようというところにも問題があります。自治体や行政機関を中心にナンセンスな案件が増殖しているようです。何ともシュールな状況で、そのうちハンコを自動でつく RPA が出てきかねないでしょう。そして、ハンコが正しくつかれているか監視する人間を配置するんでしょうか。
旧来型の企業でも形式的で非効率な事務処理を根本的に見直すことなく、中途半端にデジタル化が導入されています。紙とデジタルの両方で処理しなければならず、二重手間になっているだけの IT 化も見かけます。結局、「ハンコいるんかい！」というオチが良く付いてきます。
日本のホワイトカラーの生産性が低いのは、こういうところに問題があります。既存の手続きを見直すことが出来ず、屋上屋を重ねるような処理、本質的に手を付けず小手先で対応しているうちに、処理が複雑化、条件の組み合わせを管理するための作業が必要になり、無駄な作業が無駄な作業を呼び込む温床になっていきます。
根本や本質に手を付けることなく、表面的にデジタル化しているように見える案件には気をつけないとなりません。
目指すべき IT 化は
PDF 書式をダウンロードして、印刷して手書きで記入してハンコ付いて、Faxまたは郵送という手順も多くて嫌になります。PDF で何らかの申請フォーマットが用意されていると多少はまともに見えますが、PDF を用意するならせめてフォーム機能を使う位のことをしてほしいものです。
理想的にはデジタル形式のデータによる完全にオンラインでの連携が望ましいものです。そして、システム間はデジタルでデータを交換するべきです。
そして、CSVファイルの読み込みであれば、順序に依存しないようにする必要があります。順序が変わっても大丈夫なように列名を照合して読み込むようにします。さらに、JSON や XMLなどの構造化したデータで連携させることを目指すべきです。
画面の位置やデータの並び順のような、意味と切り離された仕様を基準にしたシステムは、大きなリスクを内在します。
意味と操作の連動性
ちなみに、以下の意味がわかりますか。
sudo rm -r /
わたしは何度見ても、一瞬ドキっとしてしまうコマンドです。Linux コンピュータは黒い画面にコマンドを打ち込むことで操作します。Windows でも PowerShell 、Mac であればターミナルで同様のコマンドライン操作が出来ます。
rm は削除、/ は一番上のディレクトリです。sudo はLinux におけるスーパーユーザーとしてコマンドを実行するという意味です。何となく結果が想像出来ますか。
インターネットの黎明期でしたが、どこかのプロバイダーの技術者がバックアップと勘違いして、ごっそりファイルを消してしまって、問題になったことがありました。
デジタル空間では、ファイルにも情報にも重みがありません。どうでも良いファイルも、2週間かけて書いている企画書の原稿ファイルも、同じように消せてしまいます。
本来、コンピュータシステムを考える上では、こうした影響範囲の大きさに重み付けを与えることによって、操作を制限することが必要です。
産業機械では、プレス加工などで手をはさんでしまうような事故を防止するため、両手でボタンを押さないと機能しないようにしている機械があります。
今後のコンピューターシステムは、その影響力の大きさを考慮して、コマンドの実行に対して、こうした制限や閾値を設けるようなことが必要だと思います。しかし、社会システムとして、こうした具体的な議論が出てこないことを懸念しています。
表計算ソフトの問題
データを活用するには、出来るだけ、データの意味とセットで考える必要があるということを意識しておくと良いでしょう。そして、表計算ソフトは、前述したような問題を内在しています。
=G13*F13*$B$2
G13セルとF13セルに絶対参照でB2セルをかけ算しているわけですが、表計算ソフトは、G13が単価でF13が個数、B2が税率だとは識別していません。意味と操作が分離してしまっています。
一方、データベースソフトでは、
【金額】=【単価】x【個数】× 【税率】として定義出来るわけです。
上記のような単純な式のうちは良いですか、セル数が増え多重にセルを参照するにつれて、構造を把握しにくくなります。メンテナンスもしにくくなり、ミスの原因となる可能性も高まります。
もちろんコンピューターソフトが人間が考えるような意味で対象を認識をしているわけではありません。しかし、自分で作成したデータでも第三者とデータを共有する場合でも、そのセル内の式が何を意味しているかわかりにくい表計算ソフトより、データベースソフトの方が何をしているか、その意味を理解しやすい構造であることは理解いただけるものと思います。
表計算ソフトはビジネスの基本スキルとして普及していますが、データベースが基本スキルとして認識されているかと言えば、まだまだ、そういう状況ではないと思います。
しかも、ありがちで困った使い方の一つが、表計算ソフトをレイアウトソフトとして使ってしまっているケースです。見た目を調整するため、セルの挿入や結合を使ってしまうと他のシステム=データベースに取り込む際にたいへん面倒なことになります。データが正規化されておらず、整形に一手間必要になってしまうことが非常に多いのです。
世はプログラミング学習がブームのようですが、いきなりプログラム言語を学ぶよりは、データベースを学習することをお勧めします。中途半端にプログラムを学習するよりも、現在利用しているソフトをよりデータベース的、IT的に活用することを学ぶ方がよほど実践的です。
表計算ソフトを利用する上でも、テーブルとして定義する、セルを名前で参照する、1行を1レコードとして維持して VLookup関数を利用する、マクロやクエリーを使うなど、データベース的・IT的な使い方も存在します。
IT 化に必要な人材ピース
会社や組織全体での役割という視点も持ってみましょう。IT を推進する上で、実際にプログラムを書くプログラマに対して、業務側で IT システムの仕様を検討する、必要なデータをプログラマに支給するなど、業務とのすりあわせをする人間が必要です。
この立場の人に必要なスキルの一つがデータの正規化です。全角半角の統一や表記ゆれの問題への対処などとあわせて、プログラマにデータを渡す際、必要となる考え方やスキルの一つでもあります。
全角半角・文字コード・改行コード・機種依存文字・表記ゆれ
おそろしいほど多くの人が意識していない問題に、文字コードや表記ゆれがあります。クリエイターやエンジニアを中心とした Mac ユーザーは長年、Windowsユーザーから見た傍流として仕事してきたので、これらの問題に悩まされ続けてきましたし、対処すべき手法も比較的、心得ています。
しかし、一般的なビジネスユーザー、Windows ユーザーはあまりにもこの問題に無頓着です。全角半角か意識していない人も多いですし、Windows しか使っていない人は平気で機種依存文字を使用する傾向があります。以前、驚いたのは日本製の某統合業務ソフトからエクスポートされる CSV のフィールド（カラム）名称に機種依存文字や半角カタカナが使われていたことです。これには、わたしも愕然としました。
データをインポート／エクスポートしたり、検索、集計、ソートしようと思ったら、表記やコード体系が統一されている必要があります。AI だビッグデータだと言っても、元になるデータに統一性がなければ、正しい連携、検索、集計、ソートが行われなくなってしまいます。
データ変換に慣れる
今後、表計算ソフトとデータベース、オンプレミスとクラウド、基幹業務ソフトと分析・集計ソフト、営業支援システムと顧客管理システム、多様なシステム間でデータをインポート/エクスポートする機会が増えていくでしょう。
こうしたデータ変換において配慮すべき項目には以下のようなものがあります。
文字コード
文字コードと文字表記の問題は奥が深いので、ここでは深入りしませんが、システム間でデータを連携させるには文字コードを統一しておく必要があることだけ覚えておいていただければと思います。
文字化けしたときは、文字コードが違うということを思い出して、双方のシステムやソフトが文字コードに何を使っているか、文字コードを変換する方法を覚えておくだけでも有益です。
EUC-JP
古くからUNIX系で使われて Web サーバーのプログラミング言語で使われていることが多かったコードですが、最近は使われることが少なくなりました。
SHIFT-JIS
Windows 標準の文字コードでもっとも使われてきた文字コードです。
UTF-8
現在のデファクトスタンダードと言って良いでしょう。
改行コード
Windows は、LF+CR、Mac は CR、UNIX は LFです。
全角・半角
金融機関や古い業務システムでいまだに使われている半角カタカナですが、極力使わないようにしましょう。英数字記号は半角で統一したいところですが、ここはポリシー次第で、フィールド毎にルール化されていれば良いと思いますが、検索やソート対象とするフィールドでは統一しておく必要があることは忘れないようにしましょう。
機種依存文字
以下のような機種依存文字にも気をつけましょう。
表記揺れ
株式会社と表記するか（株）のように表記するか、（株）の（）が全角か半角か、さらには（株）に上記の機種依存文字を使用している場合もあったりします。こうした表記揺れがシステム上の問題となります。渡辺 ・渡邊のような漢字表記に関するものから、ウインドウ・ウィンドウ、キヤノン・キャノンのようなものまで、表記が統一されていないことで問題が起こる可能性が、至るところに潜んでいます。
エディタの勧め
エディタを使えるようになっておくと、データ変換に強くなれます。MacであればJEdit 、Windows であれば秀丸エディタあたりが有名なところです。文字コード、改行コード、全角・半角の一括変換、正規表現による検索・置換が可能です。正規表現など、エディタの使い方は別の機会にでも取り上げたいと思います。
データベース=データ+システム+インフラ
ようやくデータベースに辿りつきました。データベースと言ったとき、一般のオフィスワーカーが思い浮かべるのは MS Access でしょうか。あまりご存知でない方も多いのですが、使いやすいデータベースソフトとしてお勧めしたいのが、FileMaker です。
FileMaker は直感的に理解しやすいカード型のデータベース作成から始めることが出来るので、データベースの基本を学ぶ上でも最適のソフトです。
Apple の子会社である Claris 社によって開発販売されており、30年以上の歴史があります。もともとは Mac 専用でパーソナルユースに適していましたが、現在ではmacOS/Windows/iOSで使えるようになり、本格的なリレーショナルデータベースの構築まで可能になりました。
サーバ版であるFileMaker Server も発売から25年以上が経ち、機能性と安定性が向上してきており、クライアントサーバーでの共有型データベースの運用まで活用範囲が大幅に広まっています。
iOS アプリの FileMaker GO も用意されており、iPad を活用することで現場やフィールドで活用するシステムとしても展開しやすいプラットフォームになっています。整理しておくと、データベースは以下の3つの段階で考えておく必要があります。
データ
データベースに記録されているデータそのものです。自社の資産であり、特定のシステムやベンダーに依存しないように、自社でハンドリング出来るようにしておくことが重要です。一般的にデータベースソフトからは、SQLやCSVなどので形式でデータを取り出せるようになっています。
マスターデータをどのような形式で保存しておくか、バックアップをどのような形式にしておくか、考えておきましょう。
システム
データベースに情報を入力するには何らかのシステムを介して行います。整合性のチェック、ビジネスロジック、画面構成、画面遷移等、こうしたシステムもデータベースの重要な構成要素です。システム自体の保守性や可搬性を含めて考えます。
インフラ
データとシステムを動かすプラットホームであり、インフラですね。物理サーバーかクラウドか、PC、スマホ、何らかの専用デバイスなど、システム全体のインフラとしての構成要素を考えましょう。
データをビジネス基盤として活用する上で、データベースの重要性を理解いただけましたでしょうか。
弊社ではFileMakerを多様な業務で活用しており、そうした事例やノウハウをお伝えするセミナーも実施しています。ご興味のある方はご活用ください。
