いまも変わらぬ「業務ノウハウ不滅の法則」
市古：2月8日（月）に『グラス片手にデータベース設計 販売管理システム編 第2版』を刊行しますが、もともと初版は翔泳社が刊行していた『DB Magazine』での連載から始まっています。当時、梅田さんから業務知識の連載をしたいというメールをいただいたんですね。僕も編集部会議で似たような連載企画を提案していたんですが、業務知識だけだとちょっと難しいと言われていました。
そんなとき、ちょうど梅田さんからデータベースと絡めたらどうかというご提案があったわけです。そうして連載が始まり、書籍にもなりました。自分で企画から連載、書籍化まで担当したのは本書が初めてだったので、とても思い入れがあります。
あの頃はただの編集者で、会社のお金やモノの動き、業務システムのことも知らなかったんですが、『DB Magazine』をやるうえで、つまりエンタープライズ企業とお付き合いしていくうえでそうした知識は必須です。それをこの連載で勉強させていただきました。本書の初版は2003年刊行ですが、連載の第1回は2002年ですので、およそ14年前。冒頭の見出しは「業務ノウハウ不滅の法則」でしたが、第2版でもこの点が強調されています。これは当時もいまも変わらないのでしょうか？
梅田：今回改めて読み直しましたが、根幹の部分は変わっていません。当時学んだ方はいまも役立っているのではないでしょうか。
市古：初版は15刷となり、読まれた方も多いかと思います。ビジネス書タイプの業務知識の書籍はたくさんありますが、エンジニア視点のものはほとんどありませんでした。
梅田：そこはこだわっています。学術的に業務システムについて学ぶ方は多いと思いますが、実際にそれを構築するとなると、学んだこととはかなり異なるノウハウが必要です。ですから、システム化するときのポイントや誰もが悩むことを積極的に書きました。
新しいことを学ぶために原稿を書く梅田式勉強法
市古：いまはご自身で立ち上げられたシステムインテグレータでWeb-ERP（統合型業務ソフトウェア）のGRANDITという製品の開発を担当されています。20年以上前になりますが、前職ではProActiveを作られていました。その頃すでに業務知識をお持ちだったと思いますが、学ぶ過程で苦労はありましたか？
梅田：当時、豊富な知識があって作っていたわけではなく、勉強しつつ試行錯誤しながら作っていました。その最中にノウハウを身につけて、製品を世の中に出したあと、いろんな会社に導入していく中でも知識が広がっていきましたね。
だいたいいつもそうなんです。例えばOracle8がシェアを伸ばしてきたときは、勉強するためにOracle 8の入門書を書きました。その次はSQL Server 7が出てきたから、『DB Magazine』でその原稿を書くことで勉強しました。
市古：まさに梅田式勉強法ですよね。当時はご自身で設計から実装までされていたんでしょうか。
梅田：細かいところまで設計していましたが、プログラミングまではしていませんでしたね。製品自体を企画して、グランドデザイン、画面のレイアウト、データベースのモデリングを考えて……。作るのは任せて、テストは自分でやっていました。そうすると改善案が出てきますから。
改善案はプログラマにとって仕様変更であり、あまり嬉しくないことでしょう。ですが、製品開発は請負の仕事と違って売れるもの、いいものを作らないと成功とはいえません。予算をオーバーしてでも、よくなるのであれば手を加えないといけないんです。
勉強のコツは、基本を学んで差分を見つけ補足していくこと
市古：エンジニアが業務知識を学ぶとき、つまずいてしまうのはどういうところなのでしょうか。
梅田：業務知識を解説するテキストには、一般論までで説明が終わっているものが多いですよね。これが問題です。業務知識は明確な解答があまりなく、会社によってもバリエーションがあります。そうすると、テキストを作る側は「いろいろある」と書いておくだけにして、あとで攻撃されないようにするんです。でもそれだとピンと来ないので、私は「少なくとも自分はこうやっている」というところまで踏み込んで書いています。
読む側も、さっと読んで分かった気になっただけではいざというときに応用が効きません。どこまで深く理解するかが重要です。1ページずつノートをきちんと取って勉強するような方法が身につく読み方になります。
市古：本に書かれていることが自分のやっている方法と違っていても、別の方法を理解できれば差分を知ることができますよね。次の勉強に繋がっていきます。
梅田：差分を見つけるのは大事ですね。私が書いたことが必ずしも正解というわけではありません。私が間違っていることもありますし、私の方法と読者がすでにやっている方法がどちらも正解ということもあります。別の方法もあるんだな、と気づけますよね。それは私がいろんな会社を回る中で、各社の正解を教えてもらったのと同じです。
市古：販売管理システムは根源のところで業務とシステムが普遍的に合致することが多いので、会社や業務によって骨組みの異なる部分が少ないですよね。そういう意味で本書（初版）は重要だと梅田さんにうかがった記憶があります。
梅田：よく覚えていますね（笑）。
市古：思い入れがある企画でしたので（笑）。
梅田：インターネットで検索すれば調べたいポイントを知ることはできますが、全体の骨組みや関係性といった基本のところを把握するのは難しいでしょう。ですから、そういったことは書籍で勉強するのがいまも有効だと思います。
市古：まず基本を勉強して、自分がやろうとしているサービスに合わない、足りないと分かれば、その部分をインターネットで調べればいいんですよね。たしかに、商品や販売方法が変わったとしても、全体の骨組みである受発注や支払い、在庫といった考え方やシステムは変わりません。
梅田：入社してすぐ、あるいは若いうちに勉強しておくと、いろいろな会社の業務のやり方を吸収しやすいと思います。OJTで覚えるだけで書籍できちんと勉強しない方が多くなっていますが、インターネットの断片的な情報だけで理解する前に、本書で勉強してもらうのがいいでしょうね。
市古：まずは土台を作って、あとは差分をインターネットで補足していくということですね。
普段パッケージを使う人たちがいつかデータベースを設計するときに
市古：本書では販売管理システムの基本的な事柄が解説されていますが、データベース設計については説明すべきことが山ほどあると思います。難しいのは、説明が普遍的すぎるとぼやっとしてしまいますし、詳細に書きすぎると読者が混乱してしまう点です。
梅田：本書が変わっている点は、データベースと業務知識の両方を欲張って入れ込んだことです。それぞれのバランスや関連付けはかなり工夫しましたね。いまの時代だとパッケージを使うのが普通になっていて、自分でシステムを作ることがあまりありません。
そういう人たちがデータベースの構造の話を読んでも、いまあるパッケージのカスタマイズはしても一からは作らないので、役に立たないのではと思ってしまいます。業務知識のほうがありがたいと思うはずなんです。ですが、業務知識をデータベース設計と絡めることで両方を学べますから、普段パッケージを使う人たちに、いつかデータベースを設計するかもしれないときに本書を役立ててほしいんですね。
業務上での悩みはいろいろあるでしょう。例えば消費税の計算にしても、明細ごとに計算したあと足し合わせるのと、全部足したあとに消費税を計算するのとでは数値が変わることがあります。さらにその伝票を複数集めて請求書を作成したときまた数値が異なる、という具合です。三段階変わる可能性があることを理解しておく必要があります。
全部足し合わせて消費税を計算しても構わないんですが、いまのうちに明細ごとにやっておかないと、軽減税率が導入されたあとたいへん困ります。システムや製品は将来税率が変わることなどを見越して設計しなければなりません。
基幹業務にデジタルマーケティングが取り込まれる？
市古：軽減税率はまさに現代的な悩みの種ですが、初版と第2版での違いはどこに表れているのでしょうか。
梅田：今回振り返ってみて、時代の流れで変わってきたことがいろいろあります。軽減税率はもちろん、Eコマースもいまほど複雑ではありませんでした。それについては第2版で新たに「インターネットビジネスのDB設計」という章を設けています。
それと、私自身の宗旨替えもあったんです。例えば、あんまりログを厳密にとってもしょうがないんじゃないか、と昔は考えていたんですが、いまは個人情報の取り扱いが厳しくなり、システムに対するセキュリティの脅威が格段に大きくなっています。ログはきちんと取らなくてはいけないという時代になっているのです。
市古：今回、新しい章でオムニチャンネルの項目も設けています。前になかった要素として大きいのはCRM（顧客関係管理）でしょうか。いままでは顧客管理は営業の仕事で、基幹業務の中には含まれていませんでしたが、最近は密接になってきました。
梅田：昔の基幹業務は会計に関わることが守備範囲でしたが、いまや受注や見積もりも基幹業務です。さらにSFAやCRMなどのサービスも基幹業務になっています。ただ、なんでもかんでもERPのパッケージでやるというのはいまの流れではありません。書籍でどこまでカバーするかという問題もありましたが、あくまでERPを中心に、あとは知識程度ということで言及しています。
市古：たしかにその先になると個別の製品の話になりますよね。もし次に作るなら顧客管理編、マーケティング編でしょうか。
梅田：実はいまCRMに注力しています。というのも、店舗、ECサイト、楽天など複数の場所で買い物をする1人のお客さんをデータに基づいて同一人物として紐づけないと、小売業は立ちゆかないからです。ただ、普通のCRMだとその紐づけはあまり得意ではないので、弊社でオムニチャンネル系CRMの製品を作っているんです。
市古：デジタルマーケティングは急拡大していますよね。いままでのERPはバックヤードの効率を上げることが使命でしたが、これからはマーケティングや市場作り、お客さんとの関係作りを行なうための機能も必要だということでしょうか。
梅田：ただ、バックヤードの業務効率化は不変の課題です。新しいものには目が向きがちですし、それが重要なのは間違いありませんが、それでも基幹業務の役割はきちんとしなければなりません。意外と、まだまだこんなこともできていない、ということがあるんですよ。ですから、基幹業務には基幹業務の役割がありますので、そこにデジタルマーケティングを取り込んでいく必要はない気もしています。
従来からの基幹業務はずっと必要とされ続ける
市古：ITを利用したビジネスが増えている中で、いままでは売りきりだったものをサービス化して期間を設けて売るものが増えています。そういった切り替えに基幹業務も対応し、大きく方向性を変える必要があるかもしれません。商品が購入される際の入金のタイミングも違いますよね。
例えば電子書籍のビジネスには売りきりモデルだけでなく、複数のコンテンツから好きなもの読めるといったサービスモデルもあります。これを既存の仕組みでやりくりするのが限界になりつつあり、出版社としての基幹業務を見直さないといけなくなっています。翔泳社では電子書籍やPODに取り組んでいるので、まさにそういうことが目の前で起きているんですね。
梅田：我々の業界でも、ソフトウェアの売りきりがクラウドに切り替わっていっています。
市古：だからこそ、エンジニアは基幹業務の基礎を学んでおく必要があるわけですね。そのうえで応用していかなければならないのだと思います。
梅田：そうです。先ほどの「不滅の法則」ではないですが、従来からの基幹業務はずっと必要とされていますからね。
市古：いろんなビジネスが出てきたとき、基本を知っていないと対応できません。そうした変化にも柔軟に対応できるエンジニアになるためにも、プログラミングやデータだけでなく業務の流れやデータの取り扱いが分かっていないといけませんよね。
梅田：でも……いまのエンジニアに基幹業務はあまり人気がないんですよ。派手で参入障壁の低いSNSやゲームをやりたいという人が多い。逆に言うと、基幹業務を分かっているエンジニアは少なくなってきているので、とても価値があります。どちらがいいかは一口に言えませんが……。
私にとってIT業界はとても魅力的ですが、日本では闇の部分が見え隠れすることがあって残念に思うこともあります。ですから、いろんな人にこの業界が魅力的だと感じてもらうために、日本のエンジニアにはもっといい仕事をしてもらいたいですね。
いい仕事をするには、エンジニアはいま以上に勉強しなければいけません。新しい技術だけでなく、ぜひ本書でITの中心になる基幹業務の勉強をやって、成長してください。
