2011年7月27日水曜日

Access本

ExcelユーザのためのAccessデータベース分析テクニック(ナツメ社) http://www.amazon.co.jp/exec/obidos/ASIN/481633016X(Amazon)


Excelに習熟しているユーザー向けに、増えすぎたデータの管理にAccessを導入してみませんか?という本。


Excel、Accessでできること、できないこと。向いていること、向いていないこと。

なじみのExcelをAccessに接続し、インターフェースとして使えるようにすることから始める、というなかなか他の入門書に見られない斬新な切り口。

両方を並行に操作しながら、まずはAccessのスピードと容量の大きさを実感してみよう、ということから始められるようになっている。


Excelのフィルタやピボットテーブルと同様のことをAccessでやるには?インデックスってなぜ必要なの?無いとどうなるの?…と、Excelを便利に使ってきたであろうユーザーが疑問に感じそうなポイントを一つ一つ実験で確かめてクリアにしていく。


後半では「ExcelのデータをAccessに移行してみよう!」となるのだが、その手段も3つ提示され、それぞれのメリット・デメリットも書かれている。


代わりにほとんど全く触れられていないのが、表の設計のありかたとか、入力フォームやレポートの作り方みたいなもの。頭を捻って設計した、空のデータベースにデータを1件1件手で入力していくような場面は全く無い。既にあふれそうになってるデータをどうしましょうか?というのが本書のテーマだから。


添付のCD-ROMの容量のほとんどは、パフォーマンスの実験に使うサンプルデータ。手で入力することを考えると涙が出て来そうな量の、かつ実務で実際に出て来そうな(会計、売上計上等)データが、ExcelとAccess双方のフォーマットで収録されている。


一昔前の発行のため、最新の機能に即していないだろうことが惜しい。今の仕様だったらもっと便利だろうから。

2011年7月26日火曜日

今日のごほん

#また読書メモか…

名人椿正明が教える帳票分析50のケーススタディ (DB Magazine SELECTION)
Amazonの商品紹介ページ

業務分析の場にお呼びがかかるようなキャリアの持ち主じゃないけど「帳票」の2文字に惹かれて手に取った。この単語をタイトルに含んでいる本ってなかなか見かけないのだ。自分は大好きなんだけど。帳票。


データモデルを構築するときに行う、帳票分析の事例を集めた本。名刺やスーパーのレシート、診察券みたいなものから時刻表、勤務表、etc.・・・


比較的簡単な事例10から、より複雑な事例へ…という展開だが、1つ1つの事例の説明に省略が多すぎてついていけなかった。

特に、導入的に紹介されている最初の10件はもう少し丁寧に説明して欲しかった。基本的な事例だから…とワークシートの掲載さえ省略されている。結論として示されたモデルが直感的に良さそうか否かじゃなくて、提示されている情報から理詰めで結論に到達できることが示されないと、手法が手法として成り立っているのかどうか、その手法でどこまで実現できているのか分らないではないか。


ここが気になった

  1. ボトムアップ手法と言いつつ、そうなっていない。
    • データ項目の要否を勝手に判断している。
      • レシートの預り金額、お釣りがデータ項目に取り込まれなかった。特売情報に至っては候補にすら挙がっていない。
    • データ項目の区分を勝手に整理している。
      • 診察券の"国保・社保・自費"を"保険診療か自費か"、"国保か社保か"の2つに分割。

    筆者の出した結論はきっと正しいのだろう。しかし、その判断の根拠が空中から掴み取られている。帳票に表現されていない背景を勝手に想像している。これが推理小説だったら読者が怒るかもしれない。筆者自身の常識と勘と経験と度胸が暗黙的な入力になっているのだろうけど、手法から自動的に導き出される情報と、そうでない情報があまり区別されていないところにもやもやとしたものを感じる。

    疑問に思ったのは、ボトムアップと言いつつ、実際には「あるべきデータモデル」が予め想定されていて、それに当てはめてみせているのではないか?というところ。

    そのやり方が良い悪いと主張するわけではない。しかし、説明しようとしている手法と実際の分析でとられている手法が食い違っているのであれば手法の解説本、事例集として読むことはできない。本来必要な分析の一部だけを切り取って見せているために分析過程が飛んでいるかのように見えるのではないだろうか。


  2. アレ?と思えるデータモデルがある。
    • ATMの取引明細に、銀行口座の情報と取引に使われたATMの情報がある…けど支店の店番の項目が一つしか無い。この銀行って、もしかして口座のある店のATMしか使えないの?

    帳票という限られた情報源からモデルを構築するわけだから当然漏れや誤りがあって当然。なんだけど…。作ったデータモデルが妥当かレビューする観点、手段の提示もあればなぁと思った。

    別の事例として挙げられている、経理伝票から導き出されたデータモデルに承認者関係の情報が無かったのも疑問だ。純粋に経理事務だけを扱うシステムであれば決算書の入力として使われない情報は入力する必要も無いから、結論としていらないという判断なんだろう。けど、「この経費通したの誰よ」って追跡が期待されていないとも限らない。1と絡むが、分析対象の業務をどこまでシステム化することが求められているかによって、モデル化が必要な範囲も変わるはずだ。


  3. 伝票を帳票として扱って良いか。

    システムへのINPUTである伝票と、システムからのOUTPUTである帳票を同じ観点で扱っている。データ項目の切り出しという点ではどちらも重要だろうけど。この点は疑問に思いはしたものの、どうあるべきかという見解は自分も持ち合わせていない。粒度の大きいデータ(帳票向け)を崩して、粒度の小さいデータ(ほぼ伝票)を生成しようとしてコケてるところを横目で見た事があるから、これってアリ?と思っただけ。


もっと事例の数を絞って、1つ1つのシステムの分析をていねいに追った本が読みたかったかな。

少なくとも自分の能力では、筆者の手法で1本の帳票からデータモデルを構築するのはかなり難しく感じられた。明細になってる部分とそれ以外の部分が区別できるかってくらい?

やはり複数の帳票を突き合わせて情報の関連を見るなり、入力も含めて流れを追うなりしないと、与えられたその帳票の読み方すら分らない。


おまけ) 私が帳票大好きな理由:
  • ユーザーの希望や設計者の好みに引っ張られがちな入力系よりも、業務要件の本筋に正直。

さらにおまけ) 他人にはお勧めしない理由
  • システムの挙動がおかしいとき、まず「帳票に変な数字が出た」と言われがち。トラブル対応窓口直結。

今日も見つけたすごい本

図書館にあるコンピュータ本なんて、古い本ばかりだろうし、中身も適当だろうし…と思ってコーナーに寄るのを避けてきた。しかし、一つ考えかたを変えてみれば、自分の金ではとても買えないような、会社の経費で買うのもはばかられるような、そんな本に出あうチャンスでもある。

「かんたんZope - 無料のwebサーバで君だけのWebサイトを!」(I/O Books)


本来簡単でないものを簡単に説明しようとしたときの歪みみたいなものをこの本に感じた。


Zopeというのはwebサイトを構築するためのサーバーとフレームワークがセットになったもので、これ自体はフリーソフトウェアでインストーラーから簡単にインストールできる。
ページを書くにはHTMLを生成するのに使うテンプレートが必要で、そのテンプレートの記述に使うDTMLについても説明がある。
ここまではいい。(本当はあまり気に入らないんだけど)

データの保存にはMySQLを使う。ちょっと凝ったことをやろうとすればPythonでのプログラミングが必要だ。これらについての説明は他の本を…と来た。
「中身が分らなくてもいいから、この通りに打ち込んでください」という長いリストについては、入力が面倒ならCD-ROMからコピーすればいいから、とりあえず作例通りにはサイトを作れるとして。
 …作れるとして。

作例通りにやった(つもり)なのにも係わらず(なぜか!)うまく動かなかった場合。作例を改変して自分用のサイトを構築しようとする場合。
発生するかもしれない問題と、それに対応するための情報がほとんどない。(全くないと書きたいが、実はどこかに書いてあったのかもしれない)

トラブルとは言わないまでも、データベースのメンテナンスに関する情報というか、そもそもメンテナンスが必要であるという情報もない。(もしかしてMySQLってメンテナンス・フリーなの?)

「無料のwebサーバで君だけのwebサイト」とあるが、その実現方法は「DynamicDNSサービスを使って、自分のPCをインターネットに公開する」である。それでいて「PCの電源が入ってないと、インターネットから消えます」的な説明はなかった。
(以前、tumblerで見た、「ホームページ作りました! ここにアクセス→ file:///C:/homepage/...」って張り紙ネタを思い出したよ)

「アクセルを踏めば車が動きます」という情報はあるんだけど、「公道を走るには免許が必要です」とか「制限時速を守ってください」とかいう情報が薄くて、そもそも「道交法に従う必要があります」ということすら書かれていない感じ。

これは怖い。とはいえ、自分でこのようなマニュアルの書き方をしないとは限らない。例えば、自分用のメモとして手順だけ記録しとけという場合とか、あるいは「何かあったら自分に連絡しろ」と書ける場合とか、もしかしたら最初から他人をハメるために書く場合とか…。


いろいろ思うことはあったけど、一番印象に残ったのは味のある本文イラストだ。中身に興味が無い人にもこれらのイラストだけは見て欲しい。そう思った。

2011年7月20日水曜日

今期これを見る

2011年夏の新番。見逃してしまい、そのまま放置しているのもあるけれど、もう固まってしまったので書く。期待してる順に並べた。


魔乳秘剣帖

心の目で見て、心の耳で聞く。様々な欲望と大人の事情との間隙から生まれ落ちた異形の番組。(作品としての評価はBD/DVDが基準だろうから、あくまで「番組」)

作り手にテレが入ってしまうとバカバカしさに水が差されて、観る側がシラけてしまう。そんなのは観てられないので、ぜひともシリアスさとテンションを維持してほしい。

人気者揃いの女性キャストに目を引かれるが、こういう作品だからこそ男性キャスト陣の二枚目演技にも気を配りたい。


うたの☆プリンスさまっ♪マジLOVE1000%

沢城みゆきさんが普通に主役をやる。ともすれば飛び道具とか変化球的な役柄になりがちだったからなぁ。


輪るピングドラム

この作品が終わるまでに、きれいなジャイアンの演技がどれだけ変わるか、それが楽しみ。


新番組はそこそこに、ついつい昔の番組の録画を見ちゃう。そんな夏。

2011年7月18日月曜日

電子書籍とのつきあいかた

今みたいに手軽に自炊できる環境が整う前からも、本は読みたい、でもスペースは節約したいという思いは大きく、文庫版コミックの登場を喜んだりしていた。四次元ポケットの開発が待ち遠してならない。単に本を集めるだけなら、田舎に倉庫を持てば済むかもしれないが、読みたい時にその場で取り出せるという利便性、検索性がうらやましい。やはり図書館には司書がいなければ。

現実の自分の購入パターン。コミックの場合は以下の通り。

  1. 電子書籍で探す
  2. 古本屋で探す
  3. 本屋で探す

間にAmazonが挟まったり、挟まらなかったり。

価格的に割安とは言えない電子書籍が最初に来るのは、紙のコミックも自力で電子化しているから。自分は、自炊するときに紙が巻き込まれてページがクシャクシャになっても泣かない人である。が、やっぱりきれいな本を読めるのならばそれに越したことはない。加えて、購入履歴を管理してくれている電子書籍サービスには、PCのトラブル時なども柔軟に対応してもらえている。本を紛失したときに、一緒に部屋の中を探してくれる本屋というのは聞いたことがない。もちろんサービスに限度はあるだろうが、自宅が火事で焼け落ちても復活の可能性が残るという安心感は大きい。結局、新品同様あるいはプラス手数料という価格設定を乗り越えて、まずは電子書籍を探すということをやっている。

問題は電子書籍にならないコミックもあること。同じ出版社、掲載誌でも出たり出なかったりするので、作者側・出版社側の判断なのか、時期的な問題なのかがこちらにはわからない。何ヶ月も電子書籍での販売を待ったあげく、結局ブックオフへ…というチキンレースみたいなことになっている。

本屋でコミック買うのは連載中コミックの最新刊を買う場合と、古本屋にも見当たらない場合。『ベイビー・ステップ』とかブックオフでも「高価買取中」なので、じゃぁAmazonでと思ったら古本の送料込み価格が新品の価格より高いという…。

逆に売る側として、自分みたいな購入パターンの客からなるべく金を漏らさず取ろうと思ったらどうするか。新刊を買ってもらえなくなるタイミング、つまり古本屋に普通に並んでしまうタイミングで電子書籍を出すのがいいんだろう。古本屋で105円の本をわざわざ新刊書店で買うような客はそもそも古本屋に本が並ぶまで待たないだろう。その上で、利益が古本屋との折半になってしまう前にもう一度回収のチャンスを作れるなら、それに越したことはない。

現在重宝している電子書籍(自炊でない)ではあるが、残っている不安もないではない。

サービス終了の時に書籍がどのように扱われるかという不安だ。レンタルではないので、ダウンロードしたものが消えてしまうことがないだろうが、専用ビューアのメンテナンスが止まって、OSのバージョンアップの時に制約になることはありうる。いや、そうなるだろう。

紙の書籍にだって経年変化はあるから決して永遠のものではない。が、ある時を境に幻のごとく消え失せて、残ったのは利用不可能なデータの残骸だけ、というのはちと切ない。

最初からDRMフリーなフォーマットで売ってくれとは言わないが、いざというときのために、ビューアのオープンソース化とか、オープンなフォーマットへの変換ツールの準備があるくらいは言って欲しいところ。

音楽のダウンロード販売と同様、売りっぱなしの商売にはならなくなってきていて、そこら辺が買う側には不安のタネでもあるし、売る側にとっても思案のしどころになっていると思う。逆にこのポイントをクリアしたところで、一気に普及が進むのではないかという期待も持っている。ま、一般に普及しなければ自炊するだけなんだけど。

2011年7月10日日曜日

作りっぱ

作成後、全く機能向上することもなく、半ば放置状態であった「ニコニコ動画 ランキングデータ」サービス。

http://nicorank.bagend.co.cc/

サービス開始以降のデータであれば、昔のデータのも取れるようにしてみた。といっても、ニコニコ動画そのものから過去のランキングを取ってくるわけではなく、内部的に取っておいたものを見せてるだけ。「ある程度データが貯まるまで機能の提供を控えておりました。(キリッ」とまでいうとウソになるけど。

今まで何もしてなかったわけではなく、ソースコードをGitHubに登録してみたり、修整予定をチケットに切ってみたり、テストの自動化に手を付けるフリをしてみたりと、中ではいろいろな勉強のタネにして遊んでた。

内部の作りもまだまだ適当だし、csvをYahooPipesに食わせてみたらタイムアウトになったりと、いろいろ問題も含んでいるので当面ネタには困らなさそう。

2011年7月8日金曜日

今日見つけたすごい本

たまには図書館でコンピュータの本でも読むかと、たまたま手に取った本がすごかった。色々と思い出したり考えたことがあったので吐き出してみる。

会計システムモデル 著:阿部錠輔/鈴木茂 同友社
一応Amazonのリンク貼るけど、もう取り扱ってないよ。

1996年の発行。かなり古い本だ。世はWindows3.1からWindows95への移行期。ページによってスクリーンショットがWin3.1版だったり、Win95版だったりする。

当時の自分はといえば入社2年目くらいで、先輩達がVisualBasicでアプリの画面を作るのを横目で見つつ、自分はUNIX向けCOBOLのマニュアルの(十数冊あるそれらのうちどれが昼寝の枕に一番いいか、とっかえひっかえしながら)目次を暗記していた。(サーバー機能担当だった)。その一方でユーザー向けのマニュアル(を目指して書いた紙の束)を書いていた。テクニカルライターみたいなのに憧れていたので、とても楽しい仕事だった。

なんでこんな思い出話になるのかというと、なんとなく自分の黒歴史を紐解いているような気分になったからだ。読み始めてすぐ「これは悪い見本になりそうだ。この本をもとに『やってはいけないリスト』が作れるのではないか」とメモを取り始めたくらいだ。


----- ここから愚痴 -----


何を書いている本なのか説明されていない。

タイトルから漠然と『会計システムのモデルのあるべき姿を示した』とか『その一例を挙げよう』的な本を想像していたのだが、本書はいきなりソフトウェアのインストール手順から始まっている。しかも本にCD-ROMが付属していることもなく、著者が作成したソフトウェアを巻末の申込書を使って購入するのである。価格は2万円~3万円。では、そのプログラムの説明書なのかというと、そういう書き方にもなっていない。


対象読者の想定が示されていない。

対象の読者はこのソフトウェアのユーザーなのか、会計のシステム一般について学びたい者なのか。この本を読むに当たってWindowsの操作に習熟している必要があるのか、VisualBasic自体の知識が必要なのか必要ないのか。

TABキーを押すと次の項目に移動できます的な説明とソフトウェアを構成するプログラムソースの説明が交互に出てくる。


対象業務の説明がない。

そもそも何をするシステムなのか。このようなインプットから、このようなアウトプットを作るのである的な情報が無い。もしかしたら、この辺りの知識は会計に係わる者なら知っていて当然だという意識かもしれない。でも「会計業務全体のうち、この範囲をシステム化します」というスコープも明示されていない。(「この機能は作らなかった」という説明はあった。)

業務モデル、データモデルの説明がなく、いきなり実装(ファイル名、データのレイアウト)の説明から始まる。

「○○をするには××せよ」という説明がなく、「××したら○○になります」という説明が多い。


やたら枝葉から枝葉に飛ぶ。

「○○の情報は××ファイルに作ります。ところでWindowsのファイル形式にはシーケンシャルファイルと……があります。」

一般論と個別論がバラバラ。会計用語とコンピュータ用語が無秩序に出てくる。説明のレベルの粒が揃っていない。


とても力が入った力作ということは感じられた。いい意味でも悪い意味でも書き手の苦労が伝わってくる。紙面に余裕があれば全ソースを掲載して説明したかった的なことも書かれていた。きっと、色々な相手に色々なことを伝えようとして、付け足しに付け足しを重ねてこうなったのだろう。


----- ここから黒歴史 -----


当時は書店のコンピュータ書と言えば、Officeの入門書や開発言語の書籍が多くて、テストのやり方とかユーザー向けマニュアルの書き方のような、むしろ職業エンジニアが必要とする、あるいはそのような者でなければ読まないような本が見当たらなくて困った記憶がある。

テストのやり方は会社で先輩から教わるものという認識だったし、マニュアルに至っては書き方を教えてくれる人もいなくて、自分であーだこーだと考えながら書いては顧客や上司にダメを出されながら試行錯誤していた。

GUIの標準化もまだまだだった。そもそもデザインや挙動が標準化されていないと使う人が困るのだと意識している人が少なかった。やたら色とりどりの画面がディスプレイを飾っていた。さすがに「チェックボックスかオプションボタンか、並べてみてカッコいい方を使う」とまで言い張る人はいなかったが。でもWindows版OASYSの起動画面でオプションボタンが実行ボタン代わりに使われているのを見たときに受けた、そのショックは未だに忘れられない。

データ指向設計みたいな言葉も知らなかった。こういう情報をメンテするための機能を作るという意識はなかった。機能と機能の間で受け渡すくらいの気持ち。もしかしたら言葉自体まだなかったかもしれないが。


テクニカルライター的な職業には実際にはつかなかったけど、今はブログなりwikiサイトなりに、ちょっとしたことを気楽に書けるようになったし、こういう風に書くべきみたいな指南やサンプルもたくさん見つけられて、いい時代になったよなぁ。実際の文章力がそれに伴ってアップしたとかはないだろうけど。紙の本みたいに、テーマに沿った内容をそれなりのボリュームで用意する必要がないというのがありがたい。あと、需要が期待できなくても形にできる。これがもっとありがたい。


----- ここからまた次の黒歴史 -----

ここはどこ?

ブログ「袋小路」の移転先です。

過去の「袋小路」


こちらは現在も継続中。


おいおいデザイン変えたり、プラグイン入れたりします。