ラベル 読書 の投稿を表示しています。 すべての投稿を表示
ラベル 読書 の投稿を表示しています。 すべての投稿を表示

2012年12月29日土曜日

経済学って何やってんの?

みけ@ダークモードです。

まあ、最近貧困化が云々とか、

安倍政権が脱デフレとか言っているんだけど…


そもそもお金がないのにどうやってインフレさせんのよ。

正確にはお金が流通していないのに

どうやってインフレさせるのかという話。


僕は子供の頃から、

僕が僕であることを

不思議に思っていたので、

まあ、いわゆる「哲学」とかいうのに

はまってしまった厨二病的に人間なのですが、

そういうのを一蹴してくれたのが、

マルクスで彼の『資本論』なわけです。


マルクスの『資本論』というのは、

名前とは違って、どちらかというと思想書に

あたるわけですが、

よく読むと最近の経済状況と重なる部分があって、

ちゃんとした経済学の書籍であるとも

思えるようになりました。


第一巻の最初の方ですが、

  • 小資本家を何も持たない労働者の地位に落とす
  • 資本はより大きな資本になる

という記述があるわけですが、

まさにこれは今の日本に平等に起きている状況

貧困化

だと思うわけです。


だから僕は経済学というのが一体何をやっているのか

それがよくわからんのですよ。

マルクスに学ぶことはないはずなのに、

なんでマルクスに負けてんのwww

2012年9月24日月曜日

Android温泉2012夏の陣&つ部温泉に行ってきた #drospa2012

ドラクエ廃人のみけです。

ドラクエをやっている人は是非、ひめちゃんを雇ってあげて下さい。

温泉


Android温泉2012夏の陣&つ部温泉に行ってきました。

当日の様子については、ツイートがまとめられています



やったこと


まあ、適当にモクモクするという趣旨の合宿なので、

皆、適当にモクモクしている中、

僕は本を読んでいました。

読んでいた本はこれです。




内容


本の中身ですが、

普通のプログラマーならやってて当たり前だよねという内容でした。


合宿の方は…


大きな部屋で35人が雑魚寝するとか、

ちょっとありえない経験ができました。

また、雑魚寝とかやってみたいですね(白目


2012年7月28日土曜日

7月成果

ワ・タ・シがヴィムであーる。

暑いですね。

早いもので人間、じゃない会社員をやめてから、

もう4ヶ月過ぎちゃいました。

7月のまとめ


成果は大して上がっていないかも…

  • Fx-Js-JUnitの公開 : あと少し…orz
  • Gradle - gitignore-plugin : 公開
  • JavaFX勉強会でのLT : 目標達成
  • Gradleトーキョー開催 : 目標達成
  • ソートアルゴリズムの車輪の再発明 : 下記のアルゴリズムを復習
    • バブルソート
    • 選択ソート
    • 挿入ソート
    • マージソート
    • クイックソート
    • ヒープソート
  • ちょっとだけErlangの勉強

所感


Gradle

Gradleに関してはカスタムプラグインの作り方が分かったので、

まあ、よしとします。

mavenセントラルリポジトリーへの公開は9月の課題ですかね。

Fx-Js-JUnit

Fx-Js-JUnitはあと少しで皆さんにお使いいただけるレベルに

なるんですが、残りあと少しというところがきついんですよね。

きついんで、サボっております。

これも9月かな…

あと、このフレームワークの課題として、

テストが複数起動できないという弱点があるので、

テストランナーレベルでの実装が必要かと

考えています。

これはGradleやJenkinsでのプラグインで解決する方向で、

9月以降やりたいと思います。

ちなみにこれにWebサーバーやJavaEEサーバーも

載せたいと思っているので、

それらを含めて9月以降ですかね。

岡山の年末忘年会くらいにはお披露目できるかも。

その前にお金が亡くならなければいいですが…

アルゴリズム

ソートとかは単に『アルゴリズムを学ぼう』を読んで

JavaScriptで写経して、qunitでテストするという感じです。

アルゴリズムは、情報処理技術者試験での勉強中に

軽くやっただけだったので、結構面白いです。

この本はオススメですね。



Erlang

JGGUG総会およびワークショップで

並列計算フレームワークJCSPが取り上げられたことや、

Fx-Js-JUnitでマルチスレッドの勉強をしたこともあり、

並列計算というのが気になっています。

というわけで、もとから並列計算に特化した言語である

Erlangをやり始めています。

本当にやり始めなので、


で勉強する程度です。

まあ、これは教養の話なので、一日20分程度ずつやっていきます。

総括


全般的に見ると、今月の興味は次のとおりだったと思います。

  • 並列処理
  • JavaScript/Erlang等型付けの弱い言語

どちらも最近花形と呼ばれる分野ですね。

一般的な社畜プログラマーとしては関わりは

ない分野ですが、

今後のユーザー・エクスペリエンス向上に

欠かせない分野だと思っています。


8月は


夏ですので、特別強化月間として、

いまさらですがObjective-Cをやります。


ちょっとした仕事がiPhoneでの開発が入っていたりして、

仕事が取れないという場面が最近よくあるので、

Objective-Cをやって幅を広げようと思います。



2012年7月7日土曜日

国政競争力増強へ「政治家40歳定年を」 政府が珍しく長期ビジョン

元ネタはこちら

パロディです

 国家戦略会議(議長・野◯首相)の分科会は6日、国の長期ビジョン「フロンティア構想」の報告書をまとめた。国家の衰退を防ぎ、政治家や政府が能力を最大限生かして新たな価値を生む国家像を2020年に実現するための政策を提言。「40歳定年」で被選挙権を流動化するなど政策生産性を高める改革案を盛り込んだ。

 学識者や企業人らで構成するフロンティア分科会(座長・大◯第二東京大学大学院教授)が野◯首相に報告した。首相は「社会全体で国づくりの議論が喚起されることを期待する」と述べ、近くまとめる日本再生戦略にも反映する意向を示した。

 改革案の柱は政府分野だ。無定年制では政府内に人材が固定化し、国家の新陳代謝を阻害していると指摘。老害が合意しなくとも、老害に変わる人が増える40歳での定年制もできる柔軟な被選挙権を求めた。早期定年を選んだ政党には引退者への引退後1~2年間の所得補償を義務付ける。党員の再教育の支援制度も作る。マニフェストは原則、有期とし、「マニフェスト?ああ、そんなものあったっけ?」もなくす。

 もっとも定年制の前倒しには老政治屋の強い反発が必至だ。党員教育で党員に先行投資する政党側の抵抗も予想される。改革の実現にはダーマ神殿の充実や超優遇型の国会議員の歳費、旅費及び手当等に関する法律、政治家の人間教育などと一体的な検討が必要だ。改革案は長期的な指針であるが、早急な着手を目指すという位置づけにあるほど危険な状態だ。

 報告書は現状、日本は新興国との競争に敗れ、少子高齢化となっており既に「坂を転げ落ちている」と測定している。将来の理想は付加価値の高い産業が立地する「共創の国」とした。あらゆる課題に対して適切な者が対応するようになれば政治と金を適切に切り分ける人が増え、政治の透明化は改善すると見込んでいる。

2012年7月6日金曜日

6月の成果~8月展望

相変わらず働きたくないでござるのみけです。

成果


一応、プー太郎と言えども、成果がなければ、人間でないと思うので、

たとえどんなものでもいいから成果を挙げてみようとおもいます。

  • Spring Roo in Action テストの章の途中まで読んだ(全体の2/3くらい)
  • JavaFX勉強会の資料73枚作成

こんな所でしょうか。

お勤めの方の作業量に比べると明らかに少ないですね。

今月の予定


相変わらず、働きたくないでござるの状態ですので、

勉強してベースアップしたいと思います。

内容としては

  • Gradle トーキョー2時間しゃべりまくる
  • Spring Roo in Action 読み終わる
  • Fx-Js-JUnitをそろそろちゃんと公開する
  • Java Compile Time Testを実装してみる

3.のFx-Js-JUnitについてはひと通り動いているのですが、

モジュールを分割したいです。

  • 現状、JavaFXアプリケーションによる、JavaScript実行のモジュールとJettyによるstatic Webサーバーが合体しているのを分割する。
  • Jetty Static WebサーバーにMocking Handlerを追加できるような仕様を追加する
  • 複数テスト同時実行が可能なようにJavaFXアプリケーション部分を改修する

といった、作業をした後に公開しようと思います。

8月の予定


どうやらObjective-Cの勢いが凄いので、抑えておきたいなと思うので、

Objective-Cの勉強をしようと思います。



2012年3月31日土曜日

@HIROCASTER さんに刺激されて書いてみた、新社会人Javaプログラマー向け、失敗しないんじゃないかなと思う書籍

こんにちわ。

春ですね。

幸せな気分になる季節です。

なぜって、素敵なスーツ姿の新入社員と思しきお姉様桜が見頃の季節だからです。

みけです。

新社会人向けの絶対に失敗しない書籍


僕が触発されたHIROCASTERさんのエントリー

新社会人Webプログラマ向け、絶対に失敗しない参考書・推薦書

をどうぞ。

Javaプログラマー向け


P系言語は色々と書かれていたんですけど、Javaがないやってことで、

こっからがこのエントリーの本番。

JavaはとにかくIDEが重要

というわけで、JavaはとにかくIDEをどれだけ手になじませるかが重要です。

そこで次の三冊。







の本はEclipseの定番中の定番。

閉鎖環境では大抵Eclipseが使われていることが多いので、

これを読んでおきましょう。

なお、私のような不良社会人がIntelliJ IDEAという

イケナイ有償のIDEを進めてくることがあります。

本当にイクナイですね~。


真ん中の本はNetBeansの本。

NetBeansはOracleがリリースしているJavaのIDEです。

JavaEE開発する場合は、こちらの方が充実していることが多いようです。(棒

(NetBeans未使用なオレがなんてことを言う)


の本はGoogle Appengine + Slim3の本ですが、

実はEclipseを効率良く使う方法が色々と掲載されています。



いや、そもそもJavaがアレで…

まあ、このあたりがいいでしょう。








の本は幅広く抑えた一冊という感じ。僕も時おり読みます。


真ん中の本はJavaの仕様の本。この本を読まないと何も始まりません。

なお、このブログの執筆者はこの本を読んだことは…おっと消しゴムが落ちてしまった…


の本はJavaのコードをより良くするための本です。コード書く時に迷ったら読んでいます。

会社用と自宅用の二冊を準備しておくことが望ましいです。


品質

ドクター・ペッパーを買ったはずなのに、コカ・コーラが出てきたら嫌ですよね。

だから、品質はすごい大切です。

そのためにはプログラムは動かして試さないといけません。

そのためにはソフトウェアは動くことが求められます。








の本はHIROCASTERさんの紹介にもあった本です。

一回くらいは写経して、最後あたりにがっかりしてみるのもいいかもしれません。


の本はJUnitに絞った本です。

結構、現場でのシーンに即して書かれた本なのでお勧めです。

特にDbUnitの使い方やJUnit4で書かれているあたりは実用性が高いです。


よりイケてるJavaプログラマーになるために

やっぱりGroovyですよ。ということで…




Groovyで日本の本といえば、この一択です。

Groovy in Action忘れてた…orz



チケット管理


きっと入社した会社ではチケット管理していますよね。

チケット管理について学んでおきましょう。

会社で使っていなかったとしたら、

もう少しで会社が滅びる可能性があるので

チケット管理を導入するために学んでおきましょう。








の本は最もイケてるチケット管理システムJIRAの本です。

JIRAは徹底的に気の利いたチケット管理システムです。

一度触ると他のチケット管理なんて…ってなってしまいます。

一部ノイズが入ってしまいました。

なんたって、Javaでできているんですよー。


真ん中の本は比較的良くできているオープンソースのチケット管理システム

Redmineの有効な活用の仕方が書かれた本です。

ちょうど私が仕事の進め方ってって考えている時に出版された本で、

非常に参考になりました。


の本はまた別の比較的よくできているオープンソースのチケット管理システム

Tracの本です。

まあ、素のままTracを使う人はいないので、Trac Lighteningとか使うと思いますが、

Tracでのチケット管理全般について書いてあると思います。

思いますというのは、僕が読んだことがないからです。

僕が持っているのは

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイドなので、

これを紹介したかったのですが、絶版になっているのかAmazonで入手不可っぽいです。



その他の書籍を会社や僕はオススメしているよ。ってのがあれば、

Twitterで教えてください。
(文章パクリ)

2012年3月30日金曜日

推論に関する覚書き2[『系統樹思考の世界』の読書メモ]

前回のポストは時間の関係で途中で投稿しました。

観察されたデータを絶対的なものとするか、

それとも

仮説を絶対的なものとしてそれに見合うデータを待つか

という二つの立場に対して柔軟な立場をとるのが3.アブダクションです。



3.アブダクション


データを批判的に検討しつつ、データが仮説に対してモル証拠としての価値を擁護する(三中、同著、p.64)

理論の「真偽」を問うのではなく、観察データのもとでどの理論が「より良い説明」を与えてくれるのかを相互比較する


というのが、アブダクションの立場です。

例えば次のような例が挙げられます。
  • 観察データ : 二つあるパソコン用のディスプレイが両方とも何も映らなくなった。
    • 仮説1 : 電源ケーブルが外れた
    • 仮説2 : グラフィックカードが壊れた
    • 仮説3 : 両方のディスプレイが壊れた

この観察データからは仮説の1が「真に」正しいのか、

それとも仮説の2が「真に」正しいのか問うことがナンセンスです。


なぜなら、観察データは個々の場合によって異なるからです。

こういった個々のケースを推論するような場合には、

従来の演繹法や帰納法などのように

データと仮説との関係性に強さを与えるのではなく、

もっとデータと仮説との間の弱い関係性が必要です。


今、手元にあるデータから最も当てはまりそうな、

いい感じの仮説をとりあえずは採用するスタイルの推論を

アブダクションと呼びます。


そして、アブダクションという推論は終わることなく続けられます。

というのも、アブダクションという推論は「真偽」の絶対的な確定行為ではなく、

どの説が最もよくデータに当てはまるかを

テストし、一時的に採用するという

一時的な仮定行為だからです。


例に戻る

先の例においては、皆さんも行う通り、

最初の観察データの後、

とりあえず電源ケーブルを見たり、

他のディスプレイに変えたり

他のパソコンに繋げてみたりといった

新たなデータを取得してみて、

どの仮説が適切であるかを推論していきます。


これが例えば、開発であった場合などは

  • 観察データ:画面のボタンを減らしたら、業務効率が上がった
    • 仮説1 : タブを押す回数が少なくなったから
    • 仮説2 : ユーザーがシステムのUIに不慣れであった。

このような仮説が立てられます。

もし、この後に、「ユーザーはUI操作に習熟している」というようなデータが得られれば、

仮説1の方が妥当でありそうですから、

  • いらない機能が多かった

とシステムに対して新たな事実を発見することができそうです。


そうなれば、その機能はいらないのか、

必要だけど普通のユーザーは使わないので、

特別なユーザーだけ使えるようにする

といった選択が出てくると思います。


まとめ


こうして見てみると、アブダクションという推論過程は

いわゆるアジャイル的なプラクティスに近いものが

あるのかと思われます。


ウォーターフォール型開発は、

真の仕様とは何であるかを定義して、

(演繹的もしくは経験的に真を決定してから、)

開発するようなスタイルでです。

「真」に到達したときに開発は終わります。


これに対してアジャイル型開発は、

変化を受け入れ、もしかしたら学習をして

開発していくスタイルです。

開発にはおそらく終わりはないでしょう。

なぜなら、すべてのリリースが一時的な仮定行為なのだから。



もしかしたらアブダクション的なスタイルの

開発というのもありかもしれませんし、

それでユーザーの価値が向上するなら、

取り組んで見る価値があるかもしれません。


こぼれ話


実は『系統樹思考の世界』という本を読み進めていくと、

アブダクションという推論様式はAIを開発する過程で研究されたという記述が出てきます。


AIは機械が人間のような振る舞いを見せるために

学習するという部分を研究する必要があったのでしょう。


そうするうちに研究の結果が他の分野へも派生して行って、

昨今のアジャイルプラクティスの勃興につながったのではないか

な~んて仮説が出てきたりしますね。

(逆かもしれませんが…)

2012年3月28日水曜日

推論に関する覚書き[『系統樹思考の世界』の読書メモ]

ここで推論という言葉を用いているが、

この推論とは、科学における推論の様式であって、

型推論とか、このブログを御覧になっている人が

手に熱くなるような推論ではないので、ご注意を。

推論の三様式


  • 演繹法
  • 帰納法
  • アブダクション


おそらく、最後のアブダクションを除いて最初の二つは

まともに高校を卒業しているはずなら聞いたことのある

推論様式であると思うし、詳しく説明する必要はないでしょう。


1.演繹法


前提となる主張から、ある主張を導き出す方法。


例えば、

  • 「波長Xの光が目で観測可能である」→「波長Xの光は可視光」
  • 「三角形Pが正三角形である」→「三角形Pは二等辺三角形である」
  • このテストが通る場合、このテストに含有されるこのテストは検証されたことと同等とみなして良い

という感じ。

この推論形式の最高峰はスピノザの『エチカ』における神の存在証明ですね。

この本は面白いから読んでおいたほうが良いです。

唯物論的に神の存在を証明しているので。

「神なんかいるわけ無いじゃん、馬鹿じゃないの、死ぬの?

ニーチェもそう言っているし」という輩はとにかくこの本を読め。


それと最近はやりの形式証明手法言語Alloyとかはこのパターンに

含まれるのかな(棒:Alloy知らない



2.帰納法


経験法とも言います。

蓄積された観察データ元に普遍的な法則を発見する方法。


例えば、

  • 数値0について当てはまる法則が、ある自然数kについて当てはまる時にk+1でも問題が無いので、この法則は正しい
  • ある放射性物質から発せられる単位時間あたりの放射線量がXXからYYに減少したから、この放射線の半減期はZZ年である
  • このテストが動いているのだから、このプログラムは問題なく動いている


これらは直感的に訴えかけるものがあり、この論証スタイルは非常に人気があります。

TDDや、プログラムのテストなどはこの方法が大前提となっています。


しかし、データから推論する過程そのものは

論理的にも心理的にも大きく訴えるものがあるものの、

データそのものが間違っているかどうかは、

訴えるものからは別に検討されなければなりません。


三中はこのように述べています。

「データと理論の間にはどのような関係があるのか」という問題です。これまで説明してきたように、「経験に照らす」ことが科学にとっては不可欠です。しかし、その主張は、私たちが得る「経験(データ)」が完全無欠であるということを意味してはいません。むしろ、仮説や理論がまちがう可能性がある一方、観察データもまた誤りや不確かさを含んでいるかもしれないという現実的な状況のもとで、…(中略)…データに照らして整合的な仮説は「真」であり、矛盾する仮説は「偽」であるという解釈は、データがつねに完全無欠であるという前提を置いています。しかし、その前提はしばしば破られます。だからこそ、仮説や理論の「真偽」を言うことはきわめて難しいのです。


三中信宏『系統樹思考の世界』(講談社現代新書、2006年、pp.59-60)


データを絶対視する立場からすれば、

仮説や学説はその下僕であり、

データを不安視する立場からすれば、

仮設や言説にはデータは何の役にも立たない。


言い換えると、

JUnitの結果を絶対視する立場から見れば、

仕様はその下僕であり、

JUnitの結果を不安視する立場から見れば、

仕様にはJUnitは何の役にも立たない。



まあ、でも、そんな両極端ではうまく行かないわけで、次のような立場が生じる。


3.アブダクション



おっと、だれかお客が来たようだ…

2012年3月26日月曜日

読書と価値

教育ママとか教育パパとかはびこる世の中において、

僕は子供たちにたくさんの物語を読んでおいてもらいたいと

思っています。

具体的には?

って聞かれると困るんですが、

というのも手持ちのネタが少なくて…

『ヴェニスの商人』とか『若きウェルテルの悩み』とか『罪と罰』、『カラマーゾフの兄弟』とか。

もっと、子供同士の友情と葛藤を描いた話があれば、それも読んで下さい。


理由ですが、

人生で訪れるであろう好機を逃さないために、

いろいろなシミュレーションを立てておいて欲しいと思っています。


私はそれほど本を読む人ではなかったので、

そういうシミュレーションがうまく立てられないのかと思っています。


ベンヤミンの『歴史哲学テーゼ』をあえて誤読すると、

ヘーゲルの前進的な弁証法ではなく、

過去の別の選択肢を展開すること、

ここに今目の前に起こっていることに対する様々な選択肢に

どのように対処するかをシミュレートする機会があるのかと思います。


もう一つ、本を読むときのアドバイス、

ロマン主義的に読まないで欲しいです。


人間の苦悩の中に真実があるとか訳の解らんことをほざいて本を読むのではなく、

ドミトリーならドミトリーにとって胸を叩くことにいかなる価値があったのか、

そしてアリョーシャがそれを思い出した時の胸を叩く価値の再発見についても

シミュレートして欲しいのです。

価値とは他者と交換されることで初めて生み出される概念です。

苦悩そのものは交換できません。

胸の肉1ポンドは血を含めて肉1ポンドであることそれが交換条件であり、交換価値です。

その価値、私はそれを物象化と読んでいますが、その価値が何であるかを

しっかり見極めつつ、本を読んでもらいたいと思うわけです。


2012年3月20日火曜日

反復不可能な観察行為に関する覚書き[『系統樹思考の世界』の読書メモ]

歴史学が「二級科学」であるとされる理由について


  • 歴史学には直接的な実験や観察に対応するものがない。
  • 実験科学における仮設や理論に対する経験的な実験・観察が歴史学に存在しない。

と言われているため。


実験科学における直接的な実験や観察が寄与するところ


理論T「物質Aに物質Bを反応させると物質Pが生成される」というテーゼについて

理論Tに対しては半理論T'「物質Aに物質Bを反応させると物質Pが生成されない」が存在する。


実験

物質Aに物質Bを反応させると物質Pが生成した


推論過程

科学者がここで半理論T'を採択する場合には、

  • 物質Aを物質Bと作用させるためには触媒Nが必要であった
  • 実験環境には◯◯という条件が必要であった
  • 実験は正しく行われなかった

という、付随する説明が求められる。(説明があっても十分ではないが…)

そのため、科学者は理論Tを採用する。


真偽

意外と罠が多い「真偽」。




2012年3月19日月曜日

これまでITと無関係なところにいたのになんとかSIerに入社をこぎつけることの出来た新社会人がとりあえず一年目のうちに読んでおきたい本を適当に見繕ってみた(ただし、まじ適当)

こんちは。

エビリファイという薬を処方されて飲んだ結果、

椅子に座ってコーディングする集中力がなくなって、

無性に身体を動かしたくなっているみけです。

ちなみに、このエビリファイという薬、効能を見ると、統合失調症と書かれていて、

え、オレ統合失調症だったの?!と驚いている次第です。


本題


そんなに本を読んでいるわけではないので、

じつはあまりおすすめできる本がないというのが、

本当のところです。

なので、これまで私が読んできた本でおすすめのもの、

現場で使えそうなもの、最低限ITを売り物にしている人がリテラシーとして読んでおきたいものを挙げてみます。


コンピューター科学の基礎的なところ


なぜコンピューターは動くのか



最低限、CPUとはどういうことをやっているのか、

I/Oとは何か?CPUキャッシュとかメモリとかそういうのはなんのためにあるのか?

そういうコンピューターにまつわる基本的なことは覚えておくことが大事です。

なぜ大事か???

そんなことオレに聞くな(テキトー)


マスタリングTCP/IP



SIerの現場というのは大量のパソコンが置いてあって、

それがネットワークにつながっている。

そして、それが閉鎖環境なら外のネットワークにはつながっていないが、

閉鎖環境でなければ外の膨大なネットワークにつながっている。

IPv4という限りある資源でどうやって通信を成功させているのか、

また、IPアドレスというのはどのようにして取得されるのか?

なぜブラウザーでは繋がるのに、curlコマンドでは繋がらないのか?

こういったネットワークに関する基礎知識がないと、

SIerという人を大量に一箇所に集めた環境で働くには苦労を強いられることまちがいなしです。


つながらないからといって、適当に線を繋ぎ直すとか、

そんなサイコロに運命をかけるようなエンジニアにはならないようにしましょう。


これならわかるSQL 入門の入門



システムというとなんともごっついものを想定しますが、

単純に言えば、データ(データのなかにビジネスフローも含まれる)と画面がほぼ全てです。

で、大概の障害とかはデータの不整合が原因で発生するものが殆どです。

なので、データを操作する言葉=SQLは確実に覚えておいたほうがよいです。

しかも、副問い合わせとか複雑なSQLよりも、

もっと単純なSQLをちゃんと使いこなせるようになっておくことが望ましいです。


現場では、凄まじく複雑なSQLが頻繁に出てきます。

条件句の中になんか他のリストを取得するようなSELECT文があったり、

JOINの相手にすでにJOINされた結果が含まれていたりとか…


こういうのは皆さんの先輩がシンプルなSQLを覚えるべきところを、

どっかでとち来るって複雑なSQLが書ける人こそ世界一ィィィィィ(by シュトロハイム)のような完治が難しい勘違いをしたまま、

データベースを設計してしまったからです。


一つの出来事、一つの事実を一つのテーブルに入れるという単純明快な理論を無視して

データベースを設計したため、複雑にSQLを書かないといけなくなってしまったという状態なのです。


そうならないためにもシンプルなSQLが書けるように、シンプルなSQLしか書かないように最初から訓練しておきましょう。


併せて読みたい

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして



シンプルなSQLの先にあるのがシンプルなデータベース設計ということでT字型ER図です。

この手法の特徴はひとつのテーブルには一つの事実、あるいは出来事しか入れないということを徹底していることです。

残念なことに、テーブルの数は半端なく増えます。






もっと、もっと、よんで欲しい本があるんだけど、とりあえず、ここまで。

2012年3月18日日曜日

自然科学の5つの基準

ふとした興味で三中信宏『系統樹思考の世界』という本を読んでいます。



この本の要旨は、生物の進化を記述する記法として系統樹を用いているが、

この記法を非生物のそれにも当てはめることができないだろうかという試みが書かれています。

更には、生物を分類する時に類とか科のように分類し系統立てて認識するが、

同様の試みを非生物に対しても行えないだろうかということが書かれています。

動機


本自体の存在は数年前に知っていたのですが、

最近ふと気になって買いました。

デブサミの最終日の打ち上げで、

@snskさん

じゃ、次回のAndroidテスト祭り、オレが探索的テストのデモやってみようか!

と述べており、その手順を聞いているうちに、ふと系統樹を思い出したというのが、

その気になった理由です。

内容


まだ、全体280ページ中、50ページ程度しか読んでいないので、なんとも言えませんが、

元々大学でアビ・ヴァールブルグとか読んでいた関係上、だいたいどういった方向に議論が進むのかは、

想定しています。

今日、ブログに残しておきたいこと


読んでいる途中に、自然科学の五基準という用語で

書かれていた項目が、我々プログラマーがUnit Testのために必要な条件と一致しているように思えたので、

それを残しておきたいと思いました。


というわけで、以下、自然科学の五基準

  • 観察可能であること
    • ある現象に関する仮説なり理論をテストするためには、それが直接的に観察できなければならないという基準
  • 実験可能であること
    • ある化学反応(炎色反応のような)や物理現象(重力のような)に代表される自然界の過程に関しては、実験することによってはじめて科学的な知見が得られるという基準
  • 反復可能であること
    • ある自然現象に関する知見が正しいものであれば、同じ実験結果はいつでもどこでも誰がやっても確実に得られるという基準
  • 予測可能であること
    • 自然現象に関するある主張から導かれる予測を現実のデータに照らしてみることにより、その主張の正しさがテストできるという基準
  • 一般化可能であること
    • 現象に関する普遍的な法則性(万有引力の法則のように)として定式化できるという基準

(引用:三中信宏『系統樹思考の世界』, 講談社現代新書, p.38, 2006年)


1.の観察可能であることというのは、逆に観察可能でない場合にはテストは出来ません。

2.の実験可能であることというのも同様で、テストすると書いてあったりしますが、実際にそのコードを実行することができなければテストは出来ません。

3.の反復可能であることというのも、我々は誰がやっても同一のテスト結果に至るようにテストを実施できないとテストとしての信頼が確保できません。

4.の予測可能であることというのは、テストに際して、あるデータを投入したら、これこれのデータが出力されるような形で記述できていなければ、テストは行えません。

5.の一般化可能であること、これは定式化(仕様化)され得ないものについてはテストが実施できない(何が正しいのかわからない)ということから明らかです。


さて…


ここで三中が自然科学の基準としてこれらの項目をあげていますが、

これは、歴史学、ひいては生物進化学というものが科学たりうるのかという問いに対して、一般的な基準として示したものです。

三中の専門は生物進化学ですので、進化学、つまり歴史学が科学であることを説明付けなければなりません。

しかし、例えば、北京原人とアウストラロピテクスなどと行った人類の祖先っぽいものにかんして、

観察可能ではない(絶滅している)、実験可能ではない(サンプルが手に入らない)、

反復可能ではない(進化というのは非可逆の過程)、予測可能でない(どのように進化するかは想定できない)、

一般化可能でない(北京原人は絶滅したのに、アウストラロピテクスは進化に成功しているのを根拠付けて一般化できない)

といった理由で、進化学というものは歴史学と同様に科学という立場から見れば、

まったく根拠のないでたらめな学に成り下がってしまう可能性があるわけです。


これは探索的テストという、一般定式化がなされない方法論に対して、

テスト方法としてどうなのというような問いに対する答えのようなものが期待できるのではないか、

そして、探索的テストという属人的なテスト手法を体系化できる糸口があるのではないかという

そのような期待がこの本の中に込められているのではないかと思えるわけです。



最近流行っている分野でログ解析など大量データの分析をする機会が増えてくると思われます。

それにともなって、博物的に取得できる大量のデータを用いて、ユーザーなどの心理分析をする際に、

我々は系統樹としてユーザー心理 = 歴史を再現する必要が増えてくると思います。

ログ解析といった分野や探索的テストという方法論があるようでまだ方法論が確立していない分野に対して、

三中が述べるように系統樹思考を適用させることができるか、

それがこの分野でのチャンスではないかと思います。


気になった皆様も一読されてみてはいかがでしょうか?



2012年3月13日火曜日

砕蜂刑軍軍団長閣下のこれまでのアイコン

ども、

最近Twitterのアイコンを毎日頑張って変えております。

テーマはマンガ『Bleach』の二番隊隊長の砕蜂さんです。

二点ほど、砕蜂さんのアイコンを選定するときの基準を設けております。

  • 夜一さんとの絡みは採用しない
  • やらしい画像は使用しない

夜一さんとの絡み


まあ、これは設定上避けようのないものなのですが、
砕蜂さんのツンデレな所
もとい隊長としてのプロ気質に惚れ込んでおりますので、
夜一さんには出てもらわないようにしております。

気丈な砕蜂さんを気に入っておる次第なのです。

やらしい画像は利用しない


砕蜂さんの画像を探していると、
袴の横から紐が出ている画像を散見します。

ツイート上でエロオヤジ全快のツイートをしていますが、
あまり二次元にはエロを求めていないので、
これは避けています。


というわけで、

これまでの砕蜂さんギャラリー


初回の砕蜂さん。



クールな砕蜂隊長です。

冷静に状況を分析してしかるべき対応を練っているという様が見て取れると思います。




















二回目の砕蜂さん



なんかクールでいいですね。

実は結構お気に入りです。


















三回目の砕蜂さん



これもクールビューティーという感じです。

結構気に入っているんですが、身体全体を表示しようとすると、

髪型の部分があまり強調されなくて非常に悩ましいです。




















四回目の砕蜂さん



モノトーンにGradleマークということで、

クールな感じに仕上がりました。

これも結構お気に入りです。

















五回目の砕蜂さん



雀蜂雷公鞭を出した砕蜂さん。

かっこいいのですが、色使い過ぎで何がなんだかわからないあたりが残念でなりません。























六回目の砕蜂さん




どうも、その辺からパクってくる砕蜂さんの画像は、

元々砕蜂さんが白黒というモノトーンな色のため、

いろいろ脚色をつけやすいので、

全体的に色が増えてしまう傾向があります。

そのためか、 Gradleアイコンがよくわからん結果になってしまって、

ちょっと残念(´・ω・`)。



さて、次回はどうしようかな???

2012年3月10日土曜日

エンジニアのための英語入門

こんちわ。

春眠暁を覚えずなミケでやんす。

今日は適当に英語が身近に感じられるための本を紹介しようと思います。

英会話




スティーブ・ソレイシィのこの本が比較的読みやすくてお勧めです。

英単語帳だと単語数が2,000とかよくあるけど、目標としての数値として四桁というのは一人の人間には少し大きすぎる感じがします。

この本なら目標は100なので、達成不可能な数字ではないと思います。

実際、休日の午後3時間くらいで読むことができると思います。

この本は声に出しながら読むといいでしょう。

これで会話をする時に結構話ができるようになります。


英語全般


英語全般と書いていますが、これは読む・書くの力を指しています。

これは月並みなのですが、本をたくさん読むに限るわけです。


とはいえ、どういう本を読めばいいかというと、結構難しくて、

ロマン主義の小説なんか読んでも、なんの特にもならないし、

シェイクスピアなんかは古すぎてお話にならないし、

読む本を選ぶというのはかなり難しいわけです。


そこでバランスがいい本となると、

英語の教師として悩みに悩んだ末、選んだリーダーを読むのがそこそこいい気がします。




これは東京大学の教養学部前期課程(1~2年)で用いるリーダーっぽいのですが、

幅広い分野をカバーしつつ、そこそこレベルの高い単語を扱っているし、

英語に頻出な表現が散りばめられているので、妥当なリーダーと言えます。


ここで、高校以来英語の勉強なんかしたことないよという人へのアドバイスですが、

この本を読むときは辞書なんか持たずに一気に読みましょう(一つの章につき目標10分以内)。


辞書は言葉の使い方が色々と書いてあって、読み物としては面白いものですが、

本を読むときに参照するようなものではありません。


文章を読み終わった後、どうしても気になった単語があったら、

辞書で調べるくらいに留めておくとよいでしょう。


若干ビジネスより


このあたりを読んでおけば、まず間違いは無いです。



ドラッカーですね。ビジネスマンなら必読の読み物です。

だから、邦訳を読まずに英語で読みましょう。


結論


だいたいここらへんに上げた本が読めるようになったら、

技術書のたぐいは簡単に読めるようになります。

後はお好きなジャンルの本を積極的に英語で読みましょう。






2012年3月8日木曜日

"291 things every developer should know"でLTしてきた

デベロッパーが知るべき291のことというイベントに参加してきました。

ニコニコ生放送でも放映されていたようです。

  • 監訳者の紹介とコメント
  • 監訳者たちがデベロッパーとして課題だと思っていることを議論する
  • 読者達による98個目の知るべきこと(LT)
という内容でした。

当日のtogetter@sinyaa31さんによって既にまとめられています。


当日の議論


同じテーブルに座らせてもらった@sue445さんいわおさん澈さんと議論しました。

1.チームワーク

まあ、メンバーの他の人に仕事してもらいやすいようにやりたいよねっていった感じの話をしましたが、

他の人(他者)っていうのは何だろうという、エマニュエル・レヴィナスばりの問いが立てられた所で終わってしまいました。

チームワークというのは、今眼の前にいるメンバーだけのことではなくて、

どこの誰だかわからない人も含めてチームメンバーではないのかという意味ですね。

そういえば、『プログラマー97』本で、恥ずかしいテストデータを作らないというのがあったと思いますが、

これはまさに、どこの誰だかわからない人も含めたチームメンバーのために仕事をする

というのに当てはまる気がします。

また、どこの誰だかわからない人をメンバーとして考えるという点で行くと、

最近よく言われるソーシャルコーディングというのも含まれると思います。


PM、アーキテクト、プログラマーあえて一番重要な役割を選ぶならどの人?

これは答えは出ませんでした。

この3つの役割がうまく回ってこそのプロジェクトであり、プロダクトだろうということで。

ちなみに私の中での勝手な物理的形態ですが…
  • PM … デリバリー
  • アーキテクト … 品質
  • プログラマー … 製品
という感じです。


少子化、国際化、ユーザー企業の意識の変化におけるプログラマーの生きる道

内容的には一番シビアなものでした。

ソフトウェアは価格の叩き合い、運用コストについても価格の叩き合い、データセンターは土地が大きい所(アメリカ)が有利という中で、

日本の情報産業というのは生き残れるのか?もし生き残るとしたらどのようにして生き残るべきなのか?

少子高齢化という現状において、日本の労働力をどのように支えていくのか?

また、外国人労働者の占める割合が極端に低い日本でどのように労働力を確保するのか?

一つ一つが重たい内容だったと思います。


私はわずかではありますが、英語が話せますので、海外に行ってやっていくという自信はあります。

したがって、それほどこの問題への自分への影響はないのかなと考えています。


ただ、まあ、社会問題として考えるなら、結構私は極論を走っていて、

「どんどん外国人を受け入れればいいじゃないの?」と思っていたりします。

イタリア系ブラジル人なアレッサンドラ・アンブロジオみたいなお姉様大歓迎でございます。

人口が少子高齢化で減ってしまう分、補給しなければ、サービスが廃れていくわけですし、新たなサービスの創出などもできないわけで、

小さな島国といえど純血度を下げてでも、海外の人口を受け入れなければやっていけないのではないかと思っています。


まあ、そうは言っても、これには高度に政治的な判断もあるでしょうし、

言葉の問題もあるでしょう。

なので、私が考えるほど単純な問題ではないと思っています。


懇親会 + LT


LTでお話をさせて頂きました。

実は私97本のうちのひとつ『97 things every Project Manager should know』だけは英語版で持っていて、

邦訳が発売される前に既に読んでいました。

そのようなことを元に、英語で英語の本を読もうというようなテーマでLTをしました。


しかし、英語の本を見ていると、

日本では某◯山先生が注目したことによってオワコン感たっぷりなSpring Rooに

cookbookとか出ていたりして、海外と日本とで技術の流行(?)に差があることがよくわかります。

Groovyなんかも同様で、やはり英語の文献は数が多いですね。

Groovyは日本だとマイナーな言語ですが、海外ではそうでもないみたいです。


懇親会の方

オライリーの方がいらっしゃったので、Gradle本とRoo本の翻訳をやりたいんですけどと申し出てみました。





オライリー・ジャパンでは薄い本についての翻訳は今対応を検討しているところだそうですが、

もし面白い本であればいってくださいとの回答でした。

この辺の本の邦訳があるといいなと思ったりするんですけどね






実は英語の本を漁っていると面白そうな本ばかりで、逆に最近の日本の書籍に興味を持てなくなりつつあったりします…

2012年2月12日日曜日

単語がわからんでもどうにかなる英字新聞

ど~も。


受験生の頃から英単語を覚えるのが苦手で、今でも単語がよくわからなくて困っていたりします。


まあ、そういう時に文脈から推測する方法を身につけておけば、安心です。意外と何とかなります。


というわけで、今日(2012/02/12)のTHE NIKKEI WEEKLYから例文を取り出してみました。


Japan tested, Asia approved

Marketing strategies honed in Ginza give Western designers confidence in rest of Asia.

It is no secret: Much of the rest of Asia is overshadowing Japan's economy. In at least one regard, however, the Land of the Rising Yen remains the king of consumerdom: Not only is Japan a major source of earnings for the West's luxury labels, it is a laboratory for new marketing strategies.



まず、見出し1から。

「Japan tested, Asia approved」から、「日本テスト、アジア認められる」こんな感じですね。
受験英語ではどうやら後から訳すことが多くて、後ろから理解したい気がしなくもないですが、左から右へ因果関係がたいてい書かれていますので、この流れを掴んでおきましょう。



見出し2。

わからない単語があります。
「hone」「confidence」。
なんだかわかりませんね。
とりあえず、ほうっておいて読んでいきます。
訳していくと、「マーケティングの戦略…銀座で」「西欧のデザイナーに…を与える」「のこりのアジアでの」となります。

見出し1から推測すると、「日本で確認して、アジアでうまくいく」みたいな因果関係が有りそうなので、この部分も同様に解釈してみます。
で、「日本で確認」することによってデザイナーが何を与えられるかと考えると、うまく行ったという「自信」が与えられるのでは?と推測できます。
というわけで、「confidence」は「自信」ではないかと推測できます。

で、ここまでいくと、「honed」という単語は意味がわからなくてもなんとかなりそうです。おそらく「tested」とほぼ同意なのかと推測できます。

というわけで、訳すと「マーケティング戦略を銀座で試すことによって、西欧のデザイナーは自信を持って他のアジアの国々に展開することができる」となります。



本文1

「It is no secret」はいいですよね。「秘密でないこと」=「明らかなこと」って感じですね。

さて、「overshadowing」という単語がよくわかりませんね。
「shadowing」とすると、なんか影を追っかけているのか、もしくは「影になっている」という感じがしますが、「over」が付いているので、なんかよくわかりませんね。

まあ、でも前に「明らかなこと」と説明が付いているので、現在の経済状況を鑑みると、日本よりも他のアジアのほうが元気なので、そういうような意味でとっても構わなそうですね。

というわけで、「Much of the rest of Asia is overshadowing Japan's economy.」を訳してみると「他のアジアの国々のほうが日本の経済よりもいい感じである」となりそうです。



本文2

長いので、「consumerdom」で区切ります。

区切ったのはいいけど、「regard」と「consumerdom」がよくわかりませんね。というか、「consumerdom」にいたっては、造語っぽいですね。

「regard」はよくメールの最後に使いますね。「Best Regards」みたいな感じで。あれも意味わからんで書いているのですが、まあ「物事」というくらいに捉えておけばいい単語なのかなと思っています。

ところで、この文章では「however」という反対の意味を強調する接続詞がついていますね。なので、文としては前の文の反対の意味のことを言おうとしていることがわかります。前の文では「日本やばい、アジアすごい」ということを述べていますので、この文では「日本すごい」ということを述べようとしているというのがわかります。

「Rising Yen」というのは、昨今の日本円に関する情報を考えると、「日本円の高騰、円高」という意味でしょう。
円高になると何がどうなるか考えると、1 euroが130円だったのが80円くらいになっているわけで、今まで1,000 euro=130,000円したバッグが、今では80,000円で買えることになります。

そしてこれまでの文意「日本でテスト、アジアで攻める」という文意からすると、日本での消費はあくまでテストであって、アジアが本命ということになります。
逆に日本人側からの心理で行けば、今までよりも安く買えるので西欧のブランド品を気軽に試せるという話になります。

そうすると「consumerdom」というのは「consumer」消費者を象徴するような意味の単語であるというのが推測が付きます。

ところで「dom」で終わる単語なんか他になかったっけ?と考えてみると、「kingdom」という単語が浮かんできます。「kingdom」は「王座」というイメージがあるので、「consumerdom」は「消費者の座」という意味であると推測できそうです。

まあ、このあたりをまとめると「しかし一つの点においては、昨今の円高によって消費大国の座にいることに変わりはない」と訳せそうです。



本文2後半

「not only」と聞いたらすぐに「but also」を思いつきます。しかし、この文章には「but also」はありません。
ここで、「not only」の対称は「Japan」であることが書かれています。
そしてこれまでの文から対比されるのは「rest of Asia」ですので、暗黙的に「but also rest of Asia」が書いてあると解釈します。

あと、「Not only is Japan」となっていますが、これは倒置法ですね。まあ、何かを強調したい時に使うやつですね。
「but also」が省略されていることから、これは残りの「a major source of earnings」という部分を強調するわけではなくて、それ以外のことを強調しようとしています。
それが何かというと、「,」以降の部分になります。

訳すと「日本だけが主要な収入源として西欧のレーベルに寄与しているわけではない(他のアジアの国も寄与している)」となります。

まあ、のこりの部分はそれほど難しくありませんね。
「(日本は)新しいマーケティング戦略の実験場としても寄与している」となります。
そして、先の倒置法のぶぶんからあわせても、この部分が強調されていて、「日本で新たな製品のテストをしてアジアで稼ぐ」という文意が読み取れてきます。


というわけで、単語がわからなくてもなんとか読んでいくことができます。
英語と聞くとビビってGoogle翻訳さんに頼りたくなりますが、まあ私も頼っていますが、文章の主張自体は推測で大体つかめるので、たまにはgoogle先生に頼らず英文を読んでみてはいかがでしょうか。

2011年12月28日水曜日

今読んでいる技術書

最近、困ったことに朝低体温症(34℃くらいしかない)で体が動かせず困っているmikeです。

いろふさんの記事に触発されて、とりあえず、今読んでおきたい本をピックアップして見ました。

Mike Cohn著、安井力、角谷信太郎訳、『アジャイルな見積もりと計画づくり 』(毎日コミュニケーションズ)



まあ、いまさらですが、ベトナム出張したプロジェクト明らかに納期に対して要求機能が多すぎて、しかも要求がまとめられていないという状況でデスマりました。その挙句(…)な状況で、プロジェクトの運営とか顧客に価値を提供するには顧客にとって何が一番の価値で、それを早い段階で提供できることが今のプロジェクト運営には求められていると思っています。だからといって、アジャイルがそれに応えられるかどうかはわかりません。ただし、顧客の期待をコントロールすること、こういうアジャイル特有のプロセスは今確実にみにつけて置かなければ、プログラマーとして失格だと思っています。というわけで、この本を先ずは取り上げました。

Amazonで3,360円で売っているようです。



Christian Johansen著、『Test-Driven JavaScript Development』(Addison-Wesley Professional, 2010/9)





邦訳も売り出されています。が、残念ながら、私が日本に帰ってきたときは、すでに手に入らない状況だったので、まあ英語でいいやと思って購入。なんかこの一冊でJavascriptパターン本に匹敵するJavascript力を手に入れられそうな気がしなくもない。ちなみにJavascriptパターン本も良書なので、ぜひ読んでおきたい本です。

Amazonで3,652円くらいです。






山本さん、上原さん、杉浦さん著『Grails 徹底入門』(翔泳社、2008年)



最近、Grails2.0がリリースされました。チュートリアルを見ていても、簡単なものしか作れなさそうなので、バージョンは古いですが、1.0からコツコツ勉強していくのが最短の道かと思っています。
なぜ、Grailsに注目しているかというと、ある程度規約を覚えてしまえば、Webアプリケーションがすぐ作れて、そのぶん顧客からのフィードバックを早い段階から得られるあたりが非常に気になっています。
言い換えると、Ruby on Railsに非常に注目しているのですが、Java屋からRubyに乗り換えるの結構厳しくて、Groovyの方が自分には近かったという怠惰な理由もあるんですけどね。

Amazonで3,780円くらいです。


おっと、Grailsをやる前に抑えておきたいのが…

阪田浩一著『SpringによるWebアプリケーションスーパーサンプル』(ソフトバンククリエイティブ、2010年)

それとあわせて

Maria Odea Ching著『Apache Maven2 Effective Implementaion』(Packt Publishing 2009)




Spring関連の書籍、日本では意外と少なくて、勉強したくて購入したのですが、全然進んでいません。
ただ、考え方などはだいたいわかっているので、ついでということで、Mavenスタイルでの開発、テストを実施しています。

Mavenに関してはかなり音痴なので、この本を読みながら、IntelliJ IDEAにほとんどお任せという感じになっていますが、これでも結構勉強になっています。
早い段階で、Springの基本的なところは抑えて、Spring Rooに進みたいというのが今の私の心情。

Springの本は、3,990円。

Maven2の方は3,245円くらいで売っています。





ちょっとプラスアルファ的なもの

Apache Maven3 Cookbook



意外と色々な使い方が載っている良書です。

Androidプロジェクトをテストプロジェクトを含めてMaven管理下に置く方法などのちょっとしたTipsが載っています。

ちなみにSpringに関しても結構大きな部分を割いており、さっきのSpring関連でもお世話になっています。

なお、3,279円くらいです。








ちなみに、今mongodbのこと調べていますが、参考文献はなしです。
ネットに転がっている情報を漁っています。





2011年8月26日金曜日

『テスト駆動開発入門』読書会 in 秋田

『テスト駆動開発入門』読書会 in 秋田を一人で開催しました。


その成果物をここで上げていきます。

第一章


1.テストのみの状態のMoneyTest.java

1.コンパイルが通るようになったMoneyTest.javaとDollar.java

1.当然落ちるMoneyTest.java

1.強引にテストを通過させるDollar.java

1.重複を取り除いたDollar.java

第二章


2.新たな振る舞いを記述したMoneyTest.java

2.解決策が思いつかないのでVariableを導入したMoneyTest.java

2.とりあえずコンパイルエラーをなくしたDollar.java

2.正しいと思われるコードに修正して動きを確認できたDollar.java

第三章


3.全てにたいする等価性を検証するMoneyTest.java

3.等価性の仮実装Dollar.java

3.不安を三角測量で表すMoney.java

3.一般化の実施Dollar.java

第四章


4.情報が豊富になってきたのでリファクタリングしたMoneyTest.java

4.さらにインライン化したMoneyTest.java

4.Dollar.javaオブジェクトだけがamountフィールドを扱えるようになったのでprivate化する

第五章


5.フランのテストと実装

なにテキストで公開して欲しい?本を買うか、図書館で借りてください。


2011年8月10日水曜日

『アジャイルサムライ』読書記録 - 7章 - 見積もり:当てずっぽうの奥義

単なる読書メモなので、あまり読んでもおもろくないと思う。

まあ、SIerはそれをずっと維持し続けようとするから、あとで火を噴く訳だな。
開発なんてやってみなければどれくらいのスピードでできるかわからない。

  • 今後の計画をたてられる
  • 見積もりは当てずっぽうだという前提を踏まえている
  • ソフトウェア開発の複雑さを認めている


このプロジェクトをやり遂げられそうなのか?!は非常に重要なところだと思う。

できないものをできるとかいうと後々痛い目を見そうだし。

7.2 ピンチをチャンスに


  • ストーリーそれぞれを互いに相対的なサイズで見積もる
  • ポイントをもとにして進捗を追跡する



相対的な見積もりについて

ポイントについて

見積もりは確実なものでないとわかっているので、日数でなく、これくらいみたいな感じで見積もっておいたほうがよいってことかな。

SIer「このプログラム何日かかる?」
プログラマー「わかりませんが、この前の仕事の5割増ですね。」
SIer「つまり3日だね?」
プログラマー「どうですかね?この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり3日だね?」
プログラマー「いや、分かりません。」
SIer「この前のは2日でできたのだから、それの5割増だから、3日だろう。」
プログラマー「どうですかね?この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり3日だね?」
…以下続く

見積り技法


三角測量

ストーリーの一覧から1回のイテレーションの期間に収まりそうなサイズのストーリーを大中小選び出す。
選び出す際の視点。
  • 論理的なグループ分けができる
  • エンド・トゥ・エンドになっている
  • プロジェクトを象徴するストーリー

スパイク

今まで経験したことのないようなストーリーに対する見積もり方法。
タイムボックス化して数日以内でストーリーを見積もれる程度に様々な調査を行う。

プランニングポーカー

開発メンバーが一つ一つのストーリーを自分自身で見積もる。
その結果をメンバー同士で共有する。
一致していたら、その見積もりにする。
異なっていたら相違について話し合って見積りを出す。

重要なポイントは話し合いがあること。
プランニングポーカーは投票システムではないこと。
ストーリーのサイズは小さくする。(1、3、エピックを表すのに5を使う。)