understanding_data_2

Basic Steps in Working with Data (データに取り組む基礎的な手順)

There are at least three key concepts you need to understand when starting a data project:

あなたがデータプロジェクトを始める時に、少なくとも３つのキーコンセプトを理解する必要がある:

• Data requests should begin with a list of questions you want to answer.

• Data often is messy and needs to be cleaned.

• Data may have undocumented features

• データを求める際にあなたが答えようとしている質問のリストから始めるべきだ。

• データはたいていひどい状態で、奇麗にする必要がある。

• データには明示的になっていない特徴があるかもしれない。

Figure 69. Messy Data 図 69. ひどいデータ

Know the Questions You Want to Answer

あなたが答えようとしている質問を理解する

In many ways, working with data is like interviewing a live source. You ask questions of the data and get it to reveal the answers. But just as a source can only give answers about which he or she has information, a data set can only answer questions for which it has the right records and the proper variables. This means that you should consider carefully what questions you need to answer even before you acquire your data. Basically, you work backwards. First, list the data-evidenced statements you want to make in your story. Then decide which variables and records you would have to acquire and analyze in order to make those statements.

多くの場合、データを処理する事は生身の情報源にインタービューをする事に似ている。 あなたは、あるデータについて質問をして答えを引き出そうとする。しかし、情報源の人が自分たちが知っている事しか答えてくれないように、一塊のデータは正しい情報を持っている質問にしか答えてくれない。つまり、あなたはデータを取得する前に自分がどんな質問に答える必要があるのかを注意深く考える必要があるのだ。基本的には、あなたは逆向きに作業を進めることになる。最初にデータによって証明できる供述のリストを

Consider an example involving local crime reports. Let’s say you want to do a story looking at crime patterns in your city, and the statements you want to make involve the times of day and the days of a week in which different kinds of crimes are most likely to happen, as well as what parts of town are hot spots for various crime categories.

犯罪レポートに関するサンプルを考えてみよう。あなたがあなたの住む都市の犯罪の傾向に注目したストーリーを考えるとしよう。あなたが論じようとしているのは、異なる犯罪が一番発生しやすい一日のうちの時間帯と曜日、その都市のどのエリアが様々な犯罪カテゴリのホットスポットかである。

You would realize that your data request has to include the date and the time each crime was reported, the kind of crime (murder, theft, burglary, etc.) as well as the address of where the crime occurred. So Date, Time, Crime Category and Address are the minimum variables you need to answer those questions.

あなたはあなたが要求するデータが犯罪の報告された日と時間、犯罪の種類（殺人、窃盗、強盗など）、そして犯罪が起こった場所の情報を含んでいなければならない事に気づく。だから、日付と時間、犯罪のカテゴリと住所があなたがそうした質問に答えるのに必要な最低限の要素だ。

But be aware that there are a number of potentially interesting questions that this four-variable data set CAN’T answer, like the race and gender of victims, or the total value of stolen property, or which officers are most productive in making arrests. Also, you may only be able to get records for a certain time period, like the past three years, which would mean you couldn’t say anything about whether crime patterns have changed over a longer period of time. Those questions may be outside of the planned purview of your story, and that’s fine. But you don’t want to get into your data analysis and suddenly decide you need to know what percentage of crimes in different parts of town are solved by arrest.

しかし、この４つの変数のデータセットでは答える事ができない興味深い質問がたくさんあることに注意してほしい。例えば被害者の人種と性別、盗まれたものの総額、または最も多く逮捕者を出した警官は誰かなど。それに、あなたは例えば３年間といった特定の機関の記録しか得る事ができない。こうした疑問はあなたの想定していたストーリーの範囲の外にあるかもしれないが、それは問題ではない。しかし、データの分析をはじめてから突然に都市の地域毎にどれだけの犯罪が逮捕によって解決されたかの比率を知りたくはないだろう。

One lesson here is that it’s often a good idea to request ALL the variables and records in the database, rather than the subset that could answer the questions for the immediate story. (In fact, getting all the data can be cheaper than getting a subset, if you have to pay the agency for the programming necessary to write out the subset.) You can always subset the data on your own, and having access to the full data set will let you answer new questions that may come up in your reporting and even produce new ideas for follow-up stories. It may be that confidentiality laws or other policies mean that some variables, such as the identities of victims or the names of confidential informants, can’t be released. But even a partial database is much better than none, as long as you understand which questions the redacted database can and can’t answer.

ここから学べる事はデータベースにあるレコードとレコードに含まれる値をすべて要求するのは、目の前にあるストーリーのための質問に答えるだけの部分的なデータを要求するよりも良いアイデアだと言う事だ。（実際に、部分的なデータを取得するのにエージェンシーにプログラミングを依頼するなら、すべてのデータを取得する方が安く済む）あなたはいつでも自分のデータの一部を抽出する事ができるし、すべてのデータセットにアクセスできれば、レポートを書いている最中に後から思いつく新しい質問にも答えられる。そして、ストーリーを補足する他の質問のアイデアを与えてくれるかもしれない。守秘義務に関する法律やほかのポリシーによってあるデータ、犠牲者の身元や匿名の情報源などは公開できないかもしれない。しかし、部分的なデータベースであっても何も無いよりずいぶんと良いものだ。編集されたデータベースが、どの質問に答える事ができてどの質問に答える事ができないかをあなたが理解している限りは。

Cleaning Messy Data

乱雑なデータをきれいにする

One of the biggest problems in database work is that often you will be using for analysis reasons data that has been gathered for bureaucratic reasons. The problem is that the standard of accuracy for those two is quite different.

データベースに関する作業で最も大きな問題の一つは、しばしばあなたが分析のために使うデータが役所のために集められているということだ。問題は正確さの標準がこの２つの間でかなり異なる事だ。

For example, a key function of a criminal justice system database is to make sure that defendant Jones is brought from the jail to be in front of Judge Smith at the time of his hearing. For that purpose, it really doesn’t matter a lot if Jones' birth date is incorrect, or that his street address is misspelled, or even if his middle initial is wrong. Generally, the system still can use this imperfect record to get Jones to Smith’s courtroom at the appointed time.

例えば、犯罪者の裁判システムのデータベースの主要な機能は、被告人ジョーンズを監獄から出して裁判官スミスの元に公聴会の時間に確実に連れて行く事だ。このためにはジョーンズの誕生日が間違っていても、彼の住所が誤って記載されていても、あるいはミドルネームが間違っていることさえ大きな問題にはならない。一般的には、このシステムは不完全なレコードをつかってもジョーンズをスミスの裁判部屋に約束通りの時間に連れて行く事ができる。

But such errors can skew a data journalist’s attempts to discover the patterns in the database. For that reason, the first big piece of work to undertake when you acquire a new data set is to examine how messy it is and then clean it up. A good quick way to look for messiness is to create frequency tables of the categorical variables, the ones that would be expected to have a relatively small number of different values. (When using Excel, for instance, you can do this by using Filter or Pivot Tables on each categorical variable.)

しかしそうした間違いはデータ・ジャーナリストがデータベースからパターンを発見しようとする試みを歪ませる。そのため、あたらしいデータセットを手に入れた際にあなたが最初にするべき仕事の大部分は、データがどれだけひどいかを調査することであり、それを奇麗にすることである。データのひどさをチェックする手っ取り早くて有効な手段は、カテゴリ別の値の頻度の表を作る事で、そうするとそれぞれの値は比較的小さな違いしか持たないはずだ。（例えばExcelなら、フィルタかピボット・テーブルを使う事でこれを実現できる）

Take “Gender”, an easy example. You may discover that your Gender field includes any of a mix of values like these: Male, Female, M, F, 1, 0, MALE, FEMALE, etc., including misspellings like ‘Femal’. To do a proper gender analysis, you must standardise — decide on M and F, perhaps — and then change all the variations to match the standards. Another common database with these kinds of problems are American campaign finance records, where the Occupation field might list “Lawyer”, “Attorney”, “Atty”, “Counsel”, “Trial Lawyer” and any of a wealth of variations and misspellings; again, the trick is to standardise the occupation titles into a shorter list of possibilities.

簡単な例として”性別”を取り上げてみよう。あなたは性別のフィールドに例えばMale、Female、M、F、1、0、MALE、FEMALEといったような値がごちゃまぜになっているのを見つけるかもしれないし、"Femal"のような綴り間違いも含まれているかもしれない。性別の分析を正しく行うためには、あなたは表記の統一ー恐らくMとFにーを行い、そしてすべての値をこの表記に合わせなければいけない。同じような問題を抱えたデータベースとして、もう一つアメリカの選挙戦の収支レポートがある。そこでは、職業欄に“Lawyer”、“Attorney”。“Atty”、“Counsel”、“Trial Lawyer” などのたくさんの異なる表記と綴り間違いが入っていたりするかもしれない。ここでもやはり、場所の表記をもっと短いリストになるように標準化の作業が必要だ。

Data cleanup gets even more problematic when working with names. Are “Joseph T. Smith”, “Joseph Smith”, “J.T. Smith”, “Jos. Smith” and “Joe Smith” all the same person? It may take looking at other variables like address or date of birth, or even deeper research in other records, to decide. But tools like Google Refine can make the cleanup and standardisation task faster and less tedious.

名前を取り扱っているとき、データの掃除はさらに面倒になる。"Joseph T. Smith"、"Joseph Smith"、"J.T.Smith"、"Jos. Smith"そして"Joe Smith"はすべて同じ人だろうか？ それを決めるのには、住所や誕生日などの他の値を見るか、あるいはもっと大変な調査を行う必要があるかもしれない。Google Refineのようなツールは、データの掃除と標準化の作業のスピードを早めて退屈を軽減してくれる。

Data May Have Undocumented Features

データは解説されていない特徴を持っているかもしれない

The Rosetta Stone of any database is the so-called data dictionary. Typically, this file (it may be text or PDF or even a spreadsheet) will tell you how the data file is formatted (delimited text, fixed width text, Excel, dBase, et al.), the order of the variables, the names of each variable and the datatype of each variable (text string, integer, decimal, et al.) You will use this information to help you properly import the data file into the analysis software you intend to use (Excel, Access, SPSS, Fusion Tables, any of various flavors of SQL, et al.)

データベースの重要な鍵となるのはデータ辞書と呼ばれるものだ。典型的には、このファイル（テキストやPDF、スプレッドシートの時もある）は、データファイルがどのようなフォーマットになっているか（区切りを持つテキスト、固定長のテキスト、エクセル、ディーベースなど）、要素の並べ替えの順番、それぞれの要素の名前とデータのタイプ（文字列、整数、１０進数など）。あなたはこの情報をあなたが使おうとしている分析用のソフトウェア（エクセル、アクセス、SPSS、フュージョン・テーブル、各種SQLなど）に適切に読み込むために使う。

The other key element of a data dictionary is an explanation of any codes being used by particular variables. For instance, Gender may be coded so that ‘1=Male’ and ‘0=Female’. Crimes may be coded by your jurisdiction’s statute numbers for each kind of crime. Hospital treatment records may use any of hundreds of 5-digit codes for the diagnoses of the conditions for which a patient is being treated. Without the data dictionary, these data sets could be difficult or even impossible to analyze properly.

データ辞書のもう一つのキーとなる要素は、各々の要素で使われるコードの説明である。例えば、性別は’１が男性’で'0が女性'という風にコード化されるだろう。犯罪は裁判管轄区域の犯罪の種類別ステータス番号でコード化されるだろう。病院の治療記録は数百種類はある５桁の患者の受けた診察の状況を示すコードを使うだろう。データ辞書が無くては、こうしたデータの集まりは分析するのが難しいか、あるいは分析不可能になってしまう。

But even with a data dictionary in hand, there can be problems. An example happened to reporters at the Miami Herald in Florida some years ago when they were doing an analysis of the varying rates of punishment that different judges were giving to people arrested for driving while intoxicated. The reporters acquired the conviction records from the court system and analyzed the numbers in the three different punishment variables in the data dictionary: amount of prison time given, amount of jail time given, and amount of fine given. These numbers varied quite a bit amongst the judges, giving the reporters' evidence for a story about how some judges were harsh and some were lenient.

しかし、データ辞書を手にしたとしても、まだ問題は残っている。数年前にフロリダのマイアミヘラルドのレポーター達、飲酒運転で逮捕された人々に下された刑罰の審判結果の裁判官による違いを分析していた時に、こんな事が起こった。レポーター達は有罪の記録を裁判所のシステムから取得し、データの中の３つの異なる刑罰についての数値ー拘置された期間、刑務所の刑期を分析した。 こうした数値は審判によってかなりばらつきがあり、レポーター達にある裁判官は厳しく、またある裁判官は寛大であるというストーリーの証拠をもたらし。

But for every judge, about 1-2 percent of the cases showed no prison time, no jail time and no fine. So the chart showing the sentencing patterns for each judge included a tiny amount of cases as “No punishment,” almost as an afterthought. When the story and chart was printed, the judges howled in complaint, saying the Herald was accusing them of breaking a state law that required that anyone convicted of drunk driving be punished.

しかし全ての判決の中で、１〜２パーセントのケースは交流期間や刑期を記していなかった。だからそれぞれの判決のパターンを示していたチャート に"無罪"はごくわずかしか無かった。そのストーリーとチャートが印刷されたとき、裁判官達は口々に文句を言った。ヘラルドが裁判官達を全ての飲酒運転違反者は罰せられるという州の法律を破っていると非難しているとして。

So the reporters went back to Clerk of the Court’s office that had produced the data file and asked what had caused this error. They were told that the cases in question involved indigent defendants with first-time arrests. Normally they would be given a fine, but they had no money. So the judges were sentencing them to community service, such as cleaning litter along the roads. As it turned out, the law requiring punishment had been passed after the database structure had been created. So all the court clerks knew that in the data, zeros in each of the prison-jail-fine variables meant community service. However, this WASN’T noted in the data dictionary, and therefore caused a Herald correction to be written.

レポーター達はこのデータファイルを作成した裁判所のオフィスのフロントに行って、この問題が発生した理由を訪ねた。彼らが言われたのは、それは低所得層の初回の逮捕のケースに関連しているということだった。彼らは罰金を命じられるが、お金を持っていない。そこで、裁判官は道路のゴミを片付けるというような社会貢献を命じるのだ。これは後から分かった事だが、全員を罰することを定めた法律はデータベースが構築された後で制定された。だから、裁判所の事務官達はデータのなかで刑務所に行く刑の項目で０があったら、それは社会貢献を意味すると知っていた。しかし、このことはデータ辞書に記されていなかったので、ヘラルドは訂正記事を書く事になった。

The lesson in this case is to always ask the agency giving you data if there are any undocumented elements in the data, whether it is newly-created codes that haven’t been included in the data dictionary, changes in the file layout, or anything else. Also, always examine the results of your analysis and ask “Does this make sense?” The Herald reporters were building the chart on deadline and were so focused on the average punishment levels of each judge that they failed to pay attention to the scant few cases that seemed to show no punishment. They should have asked themselves if it made sense that all the judges seemed to be violating state law, even if only to a tiny degree.

この事例から分かる教訓は、常にデータを与えてくれた人にドキュメントに書かれていない項目が無いか、データ辞書に含まれていない新しく作られたコードであるか、ファイル構成に変更はないか、などを尋ねるべきだ。

— Steve Doig, Walter Cronkite School of Journalism of Arizona State University