読者です 読者をやめる 読者になる 読者になる

hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

データモデリング・テクニック

社内勉強会用に流用するつもりではあるんだけど、一度データモデリングについては考えをまとめておきたかったので、資料化してみました。

 データモデリングについては、昔読んだ本を読み返したりもしたのだけど、なんとなく共通的な基盤がありながらも、これが標準と言えるような方法論がないのが難しいところ。私個人としては、「楽々ERDレッスン」の著者の羽生章洋さんがWeb+DBプレスに書いていた記事とか当時のブログに強く影響を受けました。

自分の考えが絶対に正しいというつもりはないんだけど、わりとトラディショナルな考え方をベースにいろんな人のノウハウっぽいものを詰め込んで書いたので、新人向けの教育資料としては手頃なんじゃないかと思ったりもしています。

まぁ、データモデリングは関しては、強い意見を持っている人も多いとは思うので、ご意見あればこのブログなりTwitter なりにお寄せいただければ、と。

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

 

 [2016/10/24追記] 用語の説明が足りてなかったところや非正規化の補足を追加しました。 

「科学が役に立つ」について思うこと

ノーベル医学・生理学賞の受賞が決まった大隅教授の

「科学が『役に立つ』という言葉が社会を駄目にしている。本当に役立つのは100年後かもしれない。将来を見据え、科学を一つの文化として認めてくれる社会を願っている」 

 という言葉が注目を集めている。とはいいつつも、科学系で日本人がノーベル賞受賞すると毎度同じようなことは言っている気はするけれど。

私も理工系の出身なので、その意見には賛同したい気もするのだけれど、やっぱり間違ってるよなぁ、と思ってしまう。この手の言い分は「企業は利益のためだけではなく、周辺社会や従業員の生活のためにも存在している」に通底するように思う。

例えば、誰から見ても一点の曇もなく役に立たない研究があったとしよう。具体的に思いつかなければ、「トリビアの泉」で紹介されるトリビアの種をひとつ念頭に置いていただきたい。通常、大学の教授ともなれば、1000万円程度の年収はあるだろう。この誰から見ても言っての曇りもなく役に立たない研究に政府は、年間1000万円を拠出しても構わないだろうか。日本にも貧困に苦しむ人はいくらでもいる。その人に渡した方がいいかもしれない。

文化として認めてほしいという言葉にも微妙なところがある。夜這いのようにすでに滅びた日本文化もあれば、一部のイスラム教国に見られる非人道的な規則も文化といえば文化だ。ゲームやアニメのように、かつては文化として認められなかったものが文化として浸透する場合もある。文化とは人々が自然と培っていくものであり、認めてもらえるようお願いするものではないように思う。

企業の目的は「収益を最大化すること」だ。だから、周辺社会や従業員の生活に気をかけるのは、そうすることが最終的には自社の利益に繋がるからと考えるのが筋だろう。

同じように、科学者は「私には今は思いつかないけれど、長い目でみれば役に立つんです。こういう地道な研究が社会の生産性を向上させるんです」というべきなのではないだろうか。一見、直接的には役には立たなそうな宇宙科学や歴史学であっても、多くの人の知的好奇心を満たすのであれば、経済学的な考えに沿って人々がその知的好奇心に支払ってもよいと考える金額に相応した費用を投じることは正当化できる。

言い方だけの問題かもしれないけれど、科学者にはもっと自信を持って「役に立つんです」と言ってほしいと個人的には思うのだ。

才能か努力か(おかわり)

以前のエントリーで「超一流になるのは才能か努力か?」を取り上げたけれども、その後、バランスを取るためにこれも読め、というツィートで紹介されていたのが次の本。

スポーツ遺伝子は勝者を決めるか?──アスリートの科学 (ハヤカワ・ノンフィクション文庫)

スポーツ遺伝子は勝者を決めるか?──アスリートの科学 (ハヤカワ・ノンフィクション文庫)

 

 「超一流…」本が努力すれば誰でも一流になれるという本に対して、この本はスポーツには遺伝子が重要であると主張する著者により書かれていて一見対極にある主張に見える。だけれども、読んでみるとむしろ「超一流…」本を補完する内容であることに気付かされる。

この本で書かれていることは、特に身体能力がそのまま成功につながる特に陸上競技のようなスポーツにおいては、遺伝によって形成される身体的特徴が決定的に重要であるということだ。具体的には次のよう例が紹介されている。

  • マラソンランナーは、酸素吸収能力が重要
  • バスケット選手は、身長と身体の横幅が重要
  • 高跳びの選手は、アキレス腱の長さが重要
  • 野球のバッターは、視力が重要

身長や骨格、アキレス腱の長さなどの身体的特徴は、遺伝の影響が極めて大きく、訓練だけでは、その形質を獲得することができない。そのため、トップアスリートになるには、素質が極めて重要になるということのようだ。データからは、幼いころ足の遅い人が、その後の練習によって速くなるケースはないとさえ結論されている。

だが、この本の面白さはそこで終わらないところにある。素質があると考えられるケースであっても、生まれながらにトップアスリート並みの能力を持つ突然変異的な人もいれば、練習量に応じて爆発的に能力が増加するタイプの人もいる、であったり、環境的要因、たとえば毎日ゲームや甘いものに囲まれた生活ではもし素質を持っていたとしても、それを開花させる環境にないため、結果的に貧しい地域の出身者にトップアスリートが生まれやすいという、遺伝子の複雑さやそれをとりまく様々な環境との相互作用が説明される。

さらに、逆のケース、優れた遺伝的形質を持っているが故に上手くいかないケースも紹介されている。サッカーのコーチは皆、足の速いアスリートを求めるが、速筋線維の多い選手は大腿屈筋群を痛め怪我するケースが多く、結果的に速筋線維の少ない選手のみが残ってしまう。痛みを感じない家系の話などは(不謹慎な話ではあるが)とても興味深い。

別の遺伝子が、一〇代のパキスタン人ストリートパフォーマーの才能を追求した科学者によって発見された。

パキスタンのラホールにある病院の関係者は、この少年をよく知っていた。自分の腕にナイフを突き通したり、燃えている炭の上に立ったりした後にやって来ては、傷口を元通りに縫い合わせてもらっていた。ただし、痛みから救うために治療を行ったのではない。少年は痛みをまったく感じることができなかったのだ。

イギリスの遺伝学者が少年を研究するためにパキスタンを訪れる前に、彼は一四歳ですでになくなっていた。友だちの気を引こうとして屋根から飛び降りたのだ。

(中略)

生まれつき痛みに対する感覚がない人間はそれほど長くは生きられない傾向にある。座ったり、眠ったり、立ったりするときに、私たちが無意識にするように体重移動をせず、それがもとで関節感染症を起こして死んでしまうのだ。

この本で語られる内容と「超一流…」本をあわせて考えれば、どこまでが遺伝子の影響で、どこまでが努力の結果なのか、何となく想像できる。結局、コンピュータのハードウェア、ソフトウェアの関係と同じということなのだろう。

ハードウェアの性能は遺伝で決まり、大きくは変えられない。だからハードウェアの能力が決定的に重要な場合には、ソフトウェアでいくらカバーしようとしてもカバーできない。それはファイルI/O性能ではHDDがSSDに太刀打ちできないのと同じことだ。

しかし、いくらSSDのファイルI/O性能が良くても、常に同期書き込みをするようなことをしていたら、HDDにも劣る性能になるかもしれない。性能を活かすには、それ相応のソフトウェアが必要となる。

特にトップアスリートでは、ソフトウェアは極限までチューニングしている状態に等しく差がつかない。だからハードウェアの性能が決定的に重要になる。

一方で、ソフトウェアについては、「頭のでき―決めるのは遺伝か、環境か」などからも、個々の人々でさほど差が出ないことが伺える。実際には遺伝により多少の差はあるのかもしれないが、ソフトウェアはアルゴリズムの優秀さで大きな差が出る。訓練により専用回路を獲得してしまえば、多少の素質の差は問題にならないということなのかもしれない。頭脳や戦術が重要な分野では、「超一流…」本の内容は引き続き有効ということになる。

とはいえ、多少気になる記載もある。それは、「脳科学は人格を変えられるか?」でも議論となっていた楽観的/悲観的、あるいはやる気の部分だ。「超一流…」本では、意志の力の差などない、と結論づけられていたが、本書では少なくともスポーツに関してはもっと運動したいという「やる気」に関する形質が存在することが明らかにされている。誰でも努力すれば成長できるけれども、努力する気持ちは遺伝によって決まっているのだとすると悲しいものがある。では、ドーピングで改善できれば良いのか、というと自由意志の問題にも発展しかねない。なかなか難しい問題だ。 

超一流になるのは才能か努力か?

超一流になるのは才能か努力か?

 

 

Rust 言語で JNI ライブラリを作る

Java にはプラットフォーム固有のライブラリを利用するために JNI (Java Native Interface) という機構が用意されている。この機構の問題点は、どこのプラットフォームにバイナリを持っていっても同じように動くという Java の最大の利点を失わせてしまうことにもちろんある。それはそうなのだけれど、最大の問題は様々な環境用のバイナリを用意するにはそれぞれコンパイル環境を用意する必要があり、現実的には難しいという点にある。

そこで考えたのだが、Rust はクロスコンパイルができるようになったと聞いた覚えがある。ということは単一環境(例えば、普段デスクトップとして使っているWindows PC)からでも各環境に対応した共有ライブラリが生成できるのではなかろうか。

まずは、Rust で JNI ができるのか調べてみた。すると出てきたのが次のサイト。

nitschinger.at

問題なくできるようだ。さらに調べたところ、

github.com

を使えば、jni.h の定義を Rust 用にいちいち手動変換する必要もないこともわかった。

Rust 付属のパッケージマネージャーは npm と似た仕組みになっているので、簡単にライブラリを追加できる。Cargo.toml に次の記述を追加する。

[lib]
crate-type = ["cdylib"]

[dependencies]
jni-sys = "0.1"

はじめは、crate-type = ["dylib"] と指定していたのだけれど、JNIで呼び出す場合は、Rust からの呼び出しは必要ないので、外部呼び出し専用の cdylib で構わない。これを指定するだけでファイルサイズが 2.2MB から 22KB になる。

さて、前述のサイトの add メソッドを jni-sys を使用して書き直すとこうなるになる。

extern crate jni_sys;

use jni_sys::*;

#[no_mangle]
#[allow(unused_variables, non_snake_case)]
pub extern fn Java_RustTest_add(jre: *mut JNIEnv, class: jclass, v1: jint, v2: jint) -> jint {
    v1 + v2
}

あとは普通に cargo build --release するだけでいい。予想以上に簡単。

この記述を見ればわかるように、プラットフォームに依存する記述はないため、この時点で少なくともマルチプラットフォームに対応できていることになる。

あとは、クロスコンパイル……と行きたいところなのだけれど、残念ながら現時点ではうまく行っていない。どうもランタイム環境は必要となるらしく、Windows 上で Linux バイナリを作るのは難しいようだ(Windows Subsystem for Linux を使えばできるはずだけれども)。 とほほ。

当初の思惑とは外れたとはいえ、予想外に簡単に JNI が実現できたことがわかったのは良かった。あとは SQLite とか各種ライブラリが Rust に移植されてくるといろんなことができるようになって面白くなるのだけど、そういう未来は来るのだろうか。

プロジェクトマネージャーが本当に気にすべきこと

仕事柄、プロジェクト管理についてはいつも関心を向けているのだけど、私自身があまりプロジェクト全体を管理する立場にないこともあり(基本、アーキなので)、なかなか考えをまとめる機会もなかった。たまたま、本屋でパラパラと PMBOK の本を眺めていて思ったことがあったので、書き留めてみることにする。

PMBOK 自体は辞典的な定義付けという意味では理解できるところは多いのだけど、実践的という観点からするとあまりにも表面的な内容に思えあまり意味があるように思えない。

例えば(といいつつ本題に入るのだけれど)、PMBOK には9つの知識領域というものがあり、これを管理すれば網羅的だよ、という言い方がされる。具体的には次のものが管理対象として挙げられている。

  • スコープ
  • タイム
  • コスト
  • 品質
  • 人的資源
  • コミュニケーション
  • リスク
  • 調達
  • ステークホルダー

たしかに嘘ではない。嘘ではないだが、正直ピンとこない。実際にPMになったとき、これを見ても何をすればいいのかがよくわからないのではないだろうか。

私が思うに、本当の管理対象はこうだ。

  • 顧客
  • 体制
  • タスク
  • 品質

一見して、QCDのCとD、通常最も重視されるコストと納期がないじゃないか、と即座にツッコミが入ると思うのだけれども、外したのには理由がある。

第一に、コストと納期は結果に過ぎない、と考えているからだ。管理してなんとかなものであれば、超優秀なPMを雇えば100円で明日までに100万人月のプロジェクトを成功させることだって可能なはずだが、もちろんそんなことは起きない。

不必要にコストを使っている(プロジェクトの経費で毎日銀座を飲み歩いている、とか)、不必要に期間を費やしている(メンバーが皆、毎日新聞を読みに会社に来ている、とか)というのであれば、管理せざるを得ないとは思うが、そんなことはめったになく、皆最大限に努力しているにも関わらずうまくいかないというのがだいたいのところだろう。

第二に、コストと納期はプロジェクトが始まる前には概ね決着しているということもある。標準工期という概念はあるにしろ、特に業務システムは決算期の切り替え時期やシステム更改の時期があるため、納期は顧客から指定される場合がほとんどとなる。コストについても、近年はコンペや相見積りが必須となる場合が多く、PMがアサインされる頃にはコストの枠は決まってしまっていて変えることは困難だ。

プロジェクトマネージャーの仕事とは、あらかじめ決められたコスト、納期を実現するために別の何かを管理するということなのではないかな、と思うわけだ。

ついでに言えば、リスクも管理対象ではない。というのも、コストも期間も限られている中、起こるかどうかわからないことに対処することは事実上不可能だからだ。リスクに対処するにはそれ相応のお金を積むしかなく、お金を積むのであれば見積り時点で考慮する必要がある。コストが管理対象でないことは前述の通り。

さて、本筋に戻ろう。まず「顧客」である。顧客を管理すると言うと大変失礼な言い方になってしまうが、例えば JUAS のソフトウェアメトリクス調査を見ると、工期遅延理由の半分は要件あるいは開発規模の増大に起因するという結果が出ていたりする。このことを踏まえれば、顧客は発注者であると同時に最大のプロジェクト失敗要因という言い方もできる。もちろん、逆の言い方をすれば、プロジェクトの成功を決めるのも顧客であるとも言えるわけだから、その関係を円滑にすることが重要でないわけがない。

PMBOKで言えば、ステークホルダー、スコープ、コミュニケーションが対応する。

次に「体制」。この体制は、ベンダーサイドの体制を意図している。昔、どこかで「あの男は優秀なPMだと思っていたから、今年の新人を全員投入してプロジェクトを任せたら炎上している」みたいな話を聞いたが、どんなにPMが優秀でも、メンバがまったく使い物にならないのではプロジェクトの成功はおぼつかない。むしろ、PMは並だが、メンバが優秀な人ばかり、という場合のほうがよほど成功しやすいだろう*1

きちんとした体制さえ組めれば、コミニュケーションは自然と改善するものではと個人的には思っている*2PMBOKで言えば、人的資源、コミニュケーション、調達が対応する(人的でない資源の調達は、実際のプロジェクトではそこまでボトルネックになるケースは少ないのではないかと考え一旦無視している)。

「顧客」と「体制」は人的側面の両面であるが、「タスク」と「品質」も構築対象の両面を表している。

「タスク」管理が重要なことはライフハック系の話で必ず言及されることから明らかであるが、プロジェクト管理の側面で言うと期限が重視されすぎなのではと感じる。個人的な経験から言えば、これはまったく間違っている。

タスクとその優先順位が明確になっていれさえすれば、あとは最善の努力でそれをこなすということが重要なのであって、期限自体はある種の目安に過ぎない。困難なタスクはどう期限を切ろうが簡単には終わらないし、そのようなタスクほどあらかじめ作業時間の見込みを立てるのは難しい。そのタスクができるだろうと踏んだ人に任せたら終わるまで待つしかなく、終わる見込みがなければ別の人に頼むしかない。期限は守れたが品質はボロボロというのでは、むしろプロジェクトの失敗に貢献しているとさえ言える。最近、CCPMという制約理論(TOC)に基づく進捗管理手法に言及されることがあるが、この観点からもなかなか良い手法なのではないかと思い始めている。

一方の「品質」は、成功の指標であるQCDのひとつではあるものの、他のふたつが客観的で明白な指標であるのに品質はあまり明確ではなく、見えにくいという点がキモである。コストと期間が制約されている状況下では、その結果が品質の低下として現れるのは必然ではある。とはいえ、多少の品質劣化であれば、必ずしも大きな問題とはなるわけではない。業務的にカバーできる内容であれば、リリース後に修正してもよいわけだし、めったに使わない機能に存在する不具合の場合、誰も気付かないことだってありうる。また、システム開発の裁判においても、納品後も不具合が残ることは一般的であり、それ自体はプロジェクト中断の理由とはならないとされている。

問題はユーザの利用を妨げるほど著しく品質が悪い場合だ。開発がわからないプロジェクトマネージャーのつまづきポイントがここにある。タスクとスケジュールだけを管理し、品質をまったく見ずに進めた結果、完成したと思われていたはずのものが実は完成していないというオチがおとずれる。どんなボタンを押しても例外が発生するという明らかな不具合から、すべての金額計算が浮動小数点型で行われているといった細かい問題もある。魂は細部に宿るではないけれど、ミクロだが致命的な問題は見えづらいがゆえに、納期直前に発覚する事が多く致命傷になることもある。途中でソースコードレビューを行ったからといって、すべての不具合が検出できるわけではもちろんないが、成果物の品質水準や開発者のレベルはある程度わかる*3

まぁ、私自身はプロジェクト管理の経験が豊富とは言えないので、今まで傍から見てきた感想と思っていただきたい。

TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門

TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門

 

 

*1:前述のJUASの調査によれば、ベンダー側PMの能力はソフトウェアの品質に大きく影響するという結果が出ているので、PMが重要でないと言いたいわけではもちろんない

*2:宮﨑駿は、人間関係もふまえアニメーターの座席を自ら決めるそうだが、それはやりすぎな気がするし万人におすすめするような手法とも思えない。

*3:よく品質は自動チェックツールで判断すればよいのでは、という話が出るのだが、自動チェックツールはコンピュータでしか気付けないような不具合の発見に得意な反面、さきほどの浮動小数点型の利用といった業務的な観点での不具合は見つけてくれないため、実際のところ品質の判定には使えない気がする。むしろコーディング規約の違反に開発者のスキルレベルが現れやすい感がある。

最強の圧縮アルゴリズム ZStandard を試す

以前「続・圧縮アルゴリズム(実測)」というエントリにて、各種圧縮コマンドの特徴を調べたが、このたび facebook より最強と名高い ZStandard がリリースされたので、追加で実測してみた。

以下はその結果。圧縮率はほぼ GZip 同等にも関わらず、圧縮時間は1/5、伸張時間も1/2、使用メモリ量は増えるもののさほどでもない。たしかに、これはなかなかの優れもの。高圧縮モードで使えば、bzip2並の圧縮率になるというのも良い。試していないけれども、あらかじめ辞書を作っておくと、圧縮率を更に上げることもできるようだ(どういう教育データを用意すればいいのかよくわからなかった)。

圧縮プログラム圧縮後
サイズ
圧縮時間圧縮時
最大メモリ量
伸張時間伸長時
最大メモリ量
lzip(best) 0.69 31.6 164.17 2.52 17.45
xz 0.69 23.87 106.96 2.45 12.23
lzip 0.71 19.65 102.26 2.48 12.41
brotli 0.72 94.97 72.48 0.59 7.29
bzip2 0.79 4.2 7.98 5.14 5.61
zstd(best) 0.81 17.34 66.1 0.55 12.29
xz(fast) 0.85 1.66 4.05 2.47 1.66
zopfli 0.89 2200.87 75.25 0.92 1
gzip(best) 0.95 6.49 0.96 0.97 1
lzip(fast) 0.97 3.26 14.47 2.58 2.86
gzip 1 1 1 1 1
lzfse 1 1.73 30.17 0.61 24.84
zstd 1.08 0.26 3.19 0.53 2.75
zstd(fast) 1.11 0.19 1.82 0.55 2.08
gzip(fast) 1.18 0.47 1 1.06 1
lzop(best) 1.21 12.04 1.84 0.38 1.2
lz4(best) 1.29 1.4 6.52 0.36 7.3
snzip 1.49 0.22 1.39 0.41 1.61
lzop 1.5 0.22 1.44 0.42 1.2
lzop(fast) 1.5 0.2 1.59 0.45 1.2
lz4 1.61 0.2 6.37 0.35 7.56

こうやって比較すると、Apple の新圧縮フォーマット lzfse は早くもお払い箱感がある。

才能か努力か

Twitter で話題になっていた「超一流になるのは才能か努力か?」が届いたので読み始めたところ、これがべらぼうに面白い。最近やってる社内勉強会でそのうち話そうかという気になり、勢いでプレゼン資料まで作ってしまった。

お気に入りの名著「頭のでき―決めるのは遺伝か、環境か」の内容とか経済学系の知識なんかもちょっとだけ加えてみたけれど、基本的には同書の内容の要約版になっている。要約紹介を実際に作ってみて気付いたけれども、この手の本はトピックだけだとエビデンスが欠如して信頼感が落ちてしまうところが難しい。実際に本文を読めば、裏付けとなる話がたくさん掲載されていて信頼を感じることができるけれども、要約だけだと怪しい啓蒙書に見えてしまうかもしれない。
表紙は地味だけど、刺激的な話が満載でまったく損をさせないとても面白い本なので、ぜひ買って読んで頂けたらと。
超一流になるのは才能か努力か?

超一流になるのは才能か努力か?

 

 

頭のでき―決めるのは遺伝か、環境か

頭のでき―決めるのは遺伝か、環境か