過去と今のコミュニケーション

また久しぶりにデータベースの話をしたいと思います。前回は「論理削除か物理削除か」というテーマで記事を書いたらそこそこ反響がありました。こういったテーマは実際にDB設計に関わっている方でないと刺さらないのだと思いますが、そのうち入門者向けの話題も提供したいと考えています。

IDの採番方式

さて本題ですが、今回はIDの採番において私が実際に遭遇したトラブルについての話です。そもそも採番という言葉が一般的ではないのかなと思っていますが。というのも普通にPCで「さいばん」と打っても変換されないので、新しい現場へ行ってPCが貸与されると大抵この単語を辞書登録するからです。英語で言うと numbering が近いのでしょうか。別の言い方をすると発番あるいは番号の払出しといったところでしょうか。

利用するDBMS製品によってはIDの列に自動採番の属性を付与することで済ませるケースもありますが、多少癖もあるので緻密な運用を行いたい場合は自前で実装することになります。実装と言ってもそんなに難しいことはなく、IDが連番であることを利用してその最大値に1を足したものを新しいIDとするだけなのですが、その方式によっては注意が必要です。

これは設計者の好みの問題もあるのですが、テーブルの行数を見積もった時に、まあ普通に取り扱える規模であれば毎回最大値を計算して1を加算しても大した負荷にならないので私はその方式を良く使っています。一方で最大値を計算するのが負荷となるほどの行数が見込まれる場合は、本テーブルの他に最大値を管理する採番用テーブルを作ってそこで管理するケースがあります。

ちぐはぐなロジック

ある現場でデータの移行を実施した時のことです。ファイルに用意したデータ件数と、実際に取り込まれたデータの件数が1件だけ異なるという事故が起きました。あまり細かい話をしてもしょうがないのでざっくり書くと、そのシステムはWEBアプリケーションで、移行はバッチアプリケーションでしたが、両社でIDの採番方式が異なっていたためにWEBアプリで作られたデータを1件バッチで上書きしてしまっていたということが判明しました。

具体的には、WEB側では、採番用テーブルのIDに1足した番号を新しいIDとして本テーブルのレコードを作成し、その番号で採番用テーブルのIDを更新していたのですが、一方のバッチ側では、採番用テーブルのIDを使って本テーブルのレコードを作成し、そのID+1の番号で採番用テーブルのIDを更新していたのです。つまり採番用テーブルの番号が「使っている値の最大」なのか「次に使うべき値」なのかという解釈において相違があったわけです。

例えば、WEB側でIDが1~5までのデータが作成されていたとします。そこへ移行バッチでデータを追加すると本当は次のレコードのIDは6番でなければいけないのですが、採番用テーブルのIDが5番であるために追加するレコードのIDを5番としてしまい、すると結果的に既にある5番のデータが上書きされてしまうという事象が発生してしまいました。

鍵はコミュニケーション

この話の留意点は、どっちの方式が正しいかという議論ではないというところです。よくありがちなコミュニケーション不足、検討不足の症例です。要はどちらかのやり方にもう一方が合わせていれば全く問題の無かった話です。

また、これが実際に起こった時には、移行の作業等に起因してもっと状況がややこしく、原因を突き止めるのに苦労したのですが、その移行作業の問題点というのは本題を外れるので、いずれ機会があれば書きたいと思います。データベースの話と言いながらマネジメントの話っぽくなってしまいましたね。


論理削除か物理削除か

久しぶりにITの話をしたいと思います。情報システムには多くの場合リレーショナルデータベース(RDB)を利用しています。たとえスマートフォンのアプリであっても内部で組込み用のRDBを使っていることがあります。

RDBではテーブルという単位でデータの鋳型を定義して、その鋳型で出来る実際のデータはレコードと呼んでいます。レコードが不要になった時、レコードを削除するとその情報は消えてしまいます。一方で「削除したよ」という情報を付与するだけでレコード自体を残すことがあります。この場合、俗に前者を物理削除、後者を論理削除と呼んでいます。実はこの両者が、DB設計において一つのテーマであります。

それぞれのメリットとデメリット

というのも、物理削除の場合、一旦消してしまうとバックアップデータから復元するしかありません。もしバックアップデータが無ければ復元する方法はなく、必要ならもう一度登録し直さなければなりません。

また、論理削除の場合、うっかり削除してしまっても簡単に復元することができますが、本当に不要になっても完全に削除することが出来ず、ゴミ(不要なデータのことを俗にこう呼びます)が残ります。その場合、別に物理削除を行う手段を設ける必要があります。

操作画面上で「削除」というボタンが有った場合に、物理削除の場合は確認ダイアログを表示して本当に削除して良いかしつこいくらいに尋ねる必要があります。しかし論理削除の場合は確認なしに削除してしまっても簡単に復元できるので、結果として操作画面の利便性は向上することになります。

つまり、たかがDB設計なのですが、論理削除か物理削除かというのは運用設計や画面設計とも密接に絡んでくる複雑な話なのです。

私はRDBを学び始めて間もない頃、あるいくつかの現場では全てのテーブルに削除フラグを設けているRDBを見たことがあります。その影響もあって私は全てのテーブルに削除フラグを設ける方針で他の現場でもDBを設計していました。事実、内部統制が緩い現場においてうっかりの操作ミスが多く、論理削除を採用していたことによって何度も助けられたことがあります。しかし一方で次のような課題もお客様から突き付けられました。

  • 間違えて登録したデータを完全に削除できないのは困る。
  • あるデータに関しては通常の運用で完全に削除したい。

論理削除か物理削除かを決めるもう一つの観点は、取り扱うデータが情報資産であるかどうかです。情報資産というのはデータの所有者が、それを保有することに価値を見出している情報という意味です。一定の役目を終えたからと言って完全に削除してしまうと、新たなデータの参考にすることすらできなくなります。その場合は論理削除が良いのではないかと思っています。

削除フラグと設計方針

そもそも「論理削除」の業務的(仕様的)な意味は何でしょうか。もし本当に論理的に削除したということ以上の意味が無ければそれでも良いかもしれませんが、本当にそうでしょうか。良く考えてみると実際には「一時的に非表示にした」「公開を終了した」「有効期限を過ぎた」「処理が終了した」「退会した」といった意味があるのではないでしょうか。そうすると、論理削除を表すには「削除フラグ」よりも「公開フラグ」や「表示フラグ」「処理済みフラグ」という呼称の項目を設けた方が良さそうですね。あるいはそれらを複合的に取り扱う「ステータス」という項目を設けてもいいかもしれません。

また別のアプローチとして有効期間の開始日時と終了日時、公開期間の開始日時と終了日時を管理するという方法もあります。この場合、クエリー(問合せ)は多少煩雑にはなりますが、緻密な管理が実現できます。

ステータス管理が必要なデータは適切な管理項目を設けてステータスを変更し、単純な間違いなどのゴミデータは物理削除できるようにする。そして、ステータス管理の必要のないデータはそのまま物理削除するというのが現実的な方針かなと思っています。いずれにせよ、条件反射のようになんでもかんでも削除フラグというのではなく、きちんとデータの特性を考えて設計する必要がありますね。

電子書籍の登場で自費出版が身近に

本日はIC協会の月例セミナーがあり、久しぶりに(今年初めて)参加してきました。講師はIC協会の会員でもある、有限会社ニコラデザイン・アンド・テクノロジーの水野操氏。「電子書籍で出版しよう!~『初心者Makersのための3Dプリンター&周辺ツール活用ガイド』を電子出版したワケ~」というテーマでお話しくださいました。

電子書籍はもう5年以上も前から存在していますが、ではそれを自分で出版しようと思ったことがあるでしょうか。ちょっと知っている人であれば難しそうだと思うかもしれません。実は私もそう思っていました。電子書籍といっても複数のフォーマットが存在しますし、とあるフォーマットについて言えばオーサリングツールと呼ばれるソフトウェアも高価で誰でも気軽にという環境ではないと思っていました。事実かつて私が見たものはそうでした。

ところが今日の水野さんの実体験を伺い、今では思っていたよりもかなり手軽に、気軽に電子出版ができる環境が整っているということが分かりました。一方で、内容が伴い、かつ一定のクオリティを保っていないといけないという極々当たり前の話に帰結します。つまり、これまでは出版というと企画を通すことだったり、費用の高さや出版までの日数という障壁になっていたものが、電子出版という新しいプラットフォームの登場によって取り去られ、本質の部分で勝負できる(或いは、せざるを得ない)状況になったと言えるのかもしれません。

もちろんだからといって内容が良ければ売れるかというのはまた別な話で、そういった周辺の話も伺うことができて大変有意義だったと思います。


それからビッグデータはどうなったのか

本日、JSDG(日本システムアドミニストレータ連絡会)の第37回東京ミニ研修会が開催され、参加してきました。今回はミニ研修会の幹事会、ミニ研修会、懇親会(忘年会)の三本立て。とても有意義な時間を過ごさせていただきました。

まず最初の幹事会ですが、これは今年1年間の活動の振り返りと、今準備している来年開催予定の東京研修会についての報告(これは近々お知らせできるかもしれません)、そして来年度の活動予定です。今年は年初にミニ研修会の開催日程を計画し、その通りに実施したという初めての試みを行いました。これは評価も高く、来年も継続していこうという事になりました。

2番目の研修会ですが、JSDG会員の石黒さんによるビッグデータについての発表がありました。ビッグデータというキーワードを聞くと私は正直ゲッとなってしまうのですが、表面ではない本質を汲み取るとなかなか奥深いものがあります。そのビッグデータについて、実務の経験を踏まえてこの一年くらいの動向をお話し下さいました。現在様々な用途があるということを教えてくれましたが、私は特に予測ということについて興味を持ちました。また、ビッグデータというのはバズワードであり、一通り消費されたら終わりなのでしょうが、ビッグデータという名称は使わなくとも、その本来の狙いに向けて活動を続けている企業はたくさんあるのだということを知りました。

私も数年前にWEBマーケティングの真似事をしたことがあり、膨大なログや検索ワードを追いかけていたことがあるので(別にキュレータというわけではなかったのですが)、非常に興味深く聴かせていただきました。そしてその話題は懇親会に入っても続き、ソーシャルメディアと絡めて更に掘り下げた話題で盛り上がりました。また来年はどのような集まりになるのか、今から楽しみです。


混雑時でもレジで待たされないパン屋さん

本日12日付け日経新聞の首都圏経済面に面白い記事がありましたのでご紹介します。DONQというパン屋さんのチェーンがありますが、明日、西国分寺にオープンする店舗で新しい会計システムを導入するということのようです。

その新しい会計システムというのは、画像認識の技術を応用してパンを載せたトレーをカメラで撮影し、その画像を基に商品を特定して合計金額を表示するというものだそうです。

この記事を読んで「なるほど」と思いました。週に1回くらいは近所のパン屋さんを利用するのですが、いつも感心するのはどの店員さんもパンを見ただけで商品名を暗唱しながらレジを打っていく事です。店によっては種類も豊富で、よく間違えずにレジ打ちが出来るものだと思います。おそらく新人のアルバイトはまず商品の名前と単価を覚えるところから始めるのでしょうね。

ただ、いくら店員さんの処理能力が高いといっても、混雑時にはやはりレジに並んで待たされますよね。今回の会計システムは、混雑時でも待たされること無く会計が出来る画期的なものです。課題があるとすれば、パンは全く同じ形ということはありえませんので、ある程度の割合で誤認識が発生するのではないかということです。この辺をどうやって補正し、あるいはシステムにパターンを学習させていくかが運用していく上での鍵となるのではないでしょうか。期待したいです。


変更を想定しないシステムはダメなのか

こんにちは。今日は久しぶりに新聞記事を採り上げます。日経新聞の企業面(10面)に今日から「消費増税の焦点」という連載が始まりました。

「消費増税」という表現には違和感を覚えますが、これは2014年4月と2015年10月に予定されている消費税率の引き上げの事を指しているようです。(といっても巷ではほとんどこの言い回ししかされていないようですが)

コンピュータシステムの中でも勘定系や決済系のシステムでは諸税法の改正などにより日々のメンテナンスを余儀なくされます。基準日や割合(率)、基準値の境界などの定数を書き換えなければなりません。ただ変えれば良いのではなく、新しい率がいつから適用されるのか、またどの範囲に適用されるのかといったことを緻密に管理していかなければなりません。

今日の新聞記事で採り上げられていたのは東日本旅客鉄道のIC乗車券といえばお馴染みの Suica です。記事によると Suica のシステムは、サービスインの期日を優先するため消費税率の変更機能の作り込みを見送ったそうです。おそらく見送った機能はそれだけではないと思いますが、それでも、今度の税率引き上げ期日までに消費税率変更機能を実装するには1年以上の期間と数十億円の費用を見積もっているとのこと。

記事はここまでの状況を淡々と伝えるにとどまり、このことについてどう評価すべきかについては何も書かれていません。これは非常にげんなりする状況です。だからといって設計者や当システムのオーナーを簡単に責めるべきではないと思います。サービスインの期日を優先するということはビジネス戦略上の判断だったと思います。2000年問題の時もそうでした。多くのシステムでは将来の改修費用よりも現在のストレージ費用の節約を選びました。しかしその一方で、必ずやって来る2000年を想定して最初から年を4桁で格納するように設計されたシステムも存在していたのです。

最初からあらゆる変更に対応できるように、あるいはあらゆる業務に対応できるように汎用的なシステムを望むユーザーは多いです。しかしそのためにはシステムの設計からテストまで費用も時間もかかってしまうし、汎用的であるということは裏を返すと「どの局面においても使い勝手がイマイチ」となるリスクもあるのです。重要なことはあらゆる変更や変化を想定した上で、どこで折り合いをつけるかというトレードオフであるということ。そして判断には少なからず責任が伴うということではないでしょうか。


「パーフェクトソフトウェア」ジェラルド・M・ワインバーグ著

皆さんはシステム障害のニュースを耳にしたとき、どのように思われるでしょうか。私はこれまで何度もソフトウェアのテストを行ってきましたが、それでもシステム障害のニュースを聞くとつい「本当にテストしたの?」と思ってしまいます。これは本書の前文に紹介されているエピソードと丁度重なります。そしてその反応は「テストをすれば完璧な製品ができる」という誤解からくるのだと指摘されています。実際、全くテストをせずにリリースされるソフトウェアというのは存在しないでしょう。しかし、テストの結果を正しく使えていないソフトウェアというのはそこそこあるかも知れません。本書はそんなソフトウェアのテストについての誤解を解き、ソフトウェアのテストについて様々な示唆を与える著作です。

本書に何度か出てくるテクニックとして、バグの分類が挙げられます。実際の開発現場ではバグ(障害)をどのように分類するかということがしばしば議論になります。(もっとも何も議論せずに決められているパターンも残念ながら多いです)よくある分類は重要度や優先度でしょう。ところが重要度や優先度はどちらかというと主観的な基準であるため、誰かが統一的な判定を下すのでなければ基準が曖昧になり、せっかくの分類が機能しなくなってしまいます。そこで弊社では本書で薦められているバグレベルによる分類を次のようにアレンジして現場に適用しています。

  • レベル0 ・・・他テストを妨害
  • レベル1 ・・・業務遂行不可
  • レベル2 ・・・作業効率低下
  • レベル3 ・・・頻発すれば問題

この分類のメリットは基準がどちらかというと客観的だということです。それでも最初は迷うこともありますが、それぞれどういうケースかということを考えていけば自ずと分類は決まってきます。例えばログのメッセージが不適切というケースでは、障害時の原因究明に余計な時間がかかってしまうということで「作業効率低下」に分類できます。例えばサイズ0のファイルをDBに登録できてしまうというケースでは、通常の操作ではサイズ0のファイルを扱うことがないと考えれば「頻発すれば問題」に分類できます。このバグレベルのおかげで分類作業の効率が上がりました。これは一種の優先度による分類ですが、紛れもなくレベル0のバグは優先して対応すべきものです。極端な話、レベル3のバグであれば状況により対応を見送るという判断もあるでしょう。

本書でも紹介されているように、ソフトウェアの開発に理解がない(あるいは理解があると自認している)管理者や営業担当者が、開発者に対してバグゼロを要求するケースを何度も見てきました。しかし、何がバグであるかが自明なケースもあれば、ビジネス環境に応じてバグの基準は変化することもあり、仮にリリース時点でバグがゼロであったとしても(それもあり得ないのですが)それを将来に亘って保障することはできないのです。本書はテストを担当する技術者のみならず、開発チームに関わる管理者や営業担当者の方にも読んでいただきたい一冊です。

――――
書名:パーフェクトソフトウェア
副題:テストにまつわる幻想
著者:ジェラルド・M・ワインバーグ
発行:日経BP社/2010年5月31日
ISBN:978-4-8222-8429-9

常識という壁の向こう側

1月16日付の日本経済新聞1面(及び11面)に不確定性原理が成り立たないケースが発見されたという記事が掲載されていました。私は普段の仕事の上では直接関係のないトピックではありますが、理系の学部で量子物理学をかじった者としてはなかなか衝撃的で興味深いニュースです。どのくらい衝撃的かというと、物理学の教科書が書き換わるくらいと記事には書かれています。

不確定性原理なんて私たちの日常生活では耳慣れない言葉ですよね。しかもなんだか難しそう。詳細な解説は専門書に譲りますが、大雑把にいうとミクロの世界では「観察」すなわち「測定」という行為そのものが対象に関与してしまうため、正確な測定ができないという原理です。よく歌を歌うとき、一人で練習の時は歌えるのに、みんなの前に出るとうまく歌えなくなるのに似ていますね。似ていませんか?失礼しました。とにかく原理というのは「そういうものだ」として片づけられてしまうものであり、いわば「常識」です。

しかし、その常識が覆ったというのです。不確定性原理という殻を破ることができれば、例えば電子などの微粒子の正確な位置が測定できるということになります。電子の正確な位置を知ることができれば、研究及び実験によって電子を細かくコントロールすることができるかもしれません。電子をコントロールできればいったいどんな世界が待っているのでしょうか。なにしろこれまで常識では不可能とされていたことが、ある条件の下では可能となったのです。

今後この分野の研究は急激に進むでしょう。コンピュータが当たり前のように私たちの生活の中に入り込んできたように、この分野の研究の成果も当たり前のように私たちが利用する日が来るかもしれません。もし常識だからという理由で原理という壁に挑戦しなかったなら、このような発見はなかったと思います。私たちも是非見倣って常識とされていることに疑問を持つことから始めたいですね。

『サイバー攻撃に備えはあるか』

昨日8日付及び本日9日付けの日経新聞の経済教室欄に「サイバー攻撃に備えはあるか」というテーマで記事が書かれており、興味深かったのでご紹介したいと思います。

まずは8日付の記事です。まずはサイバー攻撃のパターンの変遷について。以前はコンピュータ・ウィルスをばら撒く様な不特定多数の被害をもたらすタイプの攻撃が主流だったのに対して、最近は特定の企業や団体に対する攻撃が増えているそうです。特定の標的を持つということは、攻撃に目的があるということでもあり、目的があるということはそれを達成するためにあらゆる手段を用いてくることを考えると、狙われたらアウトという心積もりで準備をした方が良いかもしれません。

一方、9日付の記事では、「サイバーテロの問題は何故難しいか」という問いを立て、セキュリティ対策に関するインセンティブという切り口で見解が述べられています。適切な対策が施されるかどうかがインセンティブに依存しています。なぜならセキュリティ対策というのは一般的に費用・労力がかかるからです。また、どこまで対策を施せばよいかは攻撃側のインセンティブにかかっています。攻撃者にとってメリットがなければ執拗に攻撃されないからです。

また、ソフトウェアにおけるセキュリティ機能の特徴として挙げられているのが「肉を切らせて骨を裁つ」方式だということです。例えば、侵入は許可するが、情報の改ざんや漏洩等の攻撃は完遂させないといえば分かり易いでしょうか。記事の中では地震対策に喩えて、震度6には耐えたいが震度7が来たら諦めるという考え方をしていると、全体として対策は弱くなってしまうと警鐘を鳴らしています。

しかし、一つの企業や団体が個別にセキュリティ対策を行っていくのには限界があるので、地震対策と同様に国や地域、また業界全体での取組みの必要性も示されています。そして、日本でなされている取組みを紹介し、サイバー攻撃対策分野における技術革新に期待を寄せて締めくくっています。

昔からセキュリティ分野は「イタチごっこ」と言われて来ています。対策には費用及び労力がかかるので、一定の対策をしてしまったら終わりにしてしまいたいという気持ちになります。本当にこの問題に終止符が打てるような技術革新を個人的には待ち望んでいます。


Googleのカラーフィルターで画像を探しやすく

もう10年近く前になるかもしれませんが、NAVERという検索エンジンで画像検索を最初に試したときの衝撃は忘れられません。それまで検索といえば文字列でWEBサイトを検索するというのが当たり前だったので話を聞いただけではピンと来ませんでした。半信半疑で試してみたところ、(当時はそれほど精度は良くありませんでしたが)キーワードに関連する画像が一覧で表示されたのを見て大層感心したものです。

一方、Googleという検索エンジンがありますが、そこにも画像検索の機能が備わっていますね。私はそれほど開発者の動きを追いかけていませんので、気がつくとインタフェースや機能が変わっていたり追加されていることが多々あります。そしてそのGoogleの画像検索に色でフィルタリングする機能が実装されました。おそらく私が気付いていなかっただけでしょうが、それを試したときの衝撃は初めて画像検索をした時のそれに次ぐものでした。

カラーフィルターのGUIそのカラーフィルター機能(が正式な名称かは分かりませんが)というのは左の画像のようなインタフェースを持ち、着色された正方形をクリックすると、該当する色に近い画像のみ検索結果に表示されるというものです。(現在はYahoo! JapanもGoogleのエンジンを採用しているので同じ機能が備わっていますね。)

例えば花束の写真を検索したいとします。画像検索のキーワードとして「花束」と入力すると花束の画像が沢山出てきます。ですがその一覧には様々な色の写真が混じっているのではないでしょうか。次にカラーフィルターで黄色を指定すると全体的に黄色っぽい写真ばかりが表示されませんか。

そんな機能、いったい何に使うんだと思う方も居られるでしょう。単に画像を検索したいだけであれば特に使う必要性はありません。権利処理は別途行うとして、画像を検索して素材として利用する方にはとても便利な機能です。(ちなみに検索オプションでは権利状態を指定できるようです。)

例えばちょっとした招待状を作成しているとしましょう。企画のイメージから、文字や画像のレイアウトを決め、その招待状に相応しい配色を決定します。そしてその配色に合う画像を調達しなければなりません。そんな時にとても役に立つ機能なのです。是非お試し下さい。

※ 登録商標(™及び®)などの記述は省略しています