「あから2010」対清水市代女流王将の対局のログ分析
10月11日、東京大学で行われた「あから2010」対清水市代女流王将の対局の合議サーバのログを分析しました。
ログは、http://www.ipsj.or.jp/50anv/shogi/akara2010.log に公開されているものを使用しました。
398回の合議に対し、各プログラムの稼働率（投票参加率）、採用率（当該プログラムの投票が採用となった率）を調べました。
また、実際は各プログラムの投票には重み付けがされていましたが、これを無視してすべて１票として合議した場合の「傾斜なし採用率」（同点の場合はすべて採用と数える）も計算しました。
結果は以下の通りです。
結果を見て感じたことを、思いつくままに書いてみます。素人の適当な感想です。
- クラスタは稼働率が低い。まだ不安定なのでしょうか？ http://524.teacup.com/yss/bbs/1810 に「テストが十分にできなかったため」とあるのも気になります。
- 全般にクラスタのほうが採用率が低い。傾斜なし採用率でも同じ傾向。個人的には、深く読めば「正解」に漸近していくというイメージだったのだが、そうでもないのか？
- 「激指」だけ傾斜配点が多いのは、直近の大会（第20回世界コンピュータ将棋選手権や第15回コンピュータオリンピアード）で優勝している実績からだと思われるが、傾斜なしで見ると「激指」が最も採用率が低くなる。
- 上２つの結果より、「強い」アルゴリズムは合議で少数意見となってしまう傾向がある？ 合議は「ミスを減らす」より「衆愚」となるのではないか？
オープンソースハードウェア（OSHW）定義草案バージョン 0.4 日本語訳
オープンソースハードウェア（OSHW）定義草案バージョン 0.4 を日本語訳してみました。（原文）
Make: Japan Blog さんの、バージョン0.3日本語訳 をもとにして、差分を変更しました。
序文
オープンソースハードウェア（OSHW）とは、すべての人に製造、改造、配布、使用ができるように設計が一般に公開される形のある実体......機械や装置などの製造物......を示します。この定義は、オープンソースハードウェアのためのライセンスの開発および評価の指針となることを目的とします。
留意すべきは、実体のある物を作るうえで、かならず物理的な資源を取り込むという点において、ハードウェアはソフトウェアと異なるという点です。そのため、OSHWライセンスの下で物（製品）を作る人や企業は、その製品の製造、販売、保証、その他の許諾行為をオリジナルの開発者が行うかのように思わせる表示をしないという責任を負います。また、オリジナル開発者が所有するいかなる商標も、使わないように気をつけなければなりません。オープンソースハードウェアの配布条件は、以下の基準に準拠しなければなりません。
1. 資料
ハードウェアを配布する際には、設計ファイルを含む資料を添付してください。また、この設計ファイルの改変と配布も自由に行える必要があります。製品に資料を添付できないときは、ごく一般的な方法により、相応な複製費用で、望ましくはインターネットから無料ダウンロードで、資料を入手できる態勢を整えておく必要があります。この資料には、ハードウェア開発者が設計を変更できるよう、例えばCADプログラムのネイティブファイルのような設計ファイルを含めてください。設計ファイルの内容を故意に分かりづらくすることは認められません。また、コンパイルされたコンピューターコードに類似する中間的形態......たとえば、CADプログラムの印刷用プリント基板パターンのファイルなど......を代用にすることも認められません。このライセンスは、設計ファイルが完全にドキュメント化されたオープンなフォーマットで提供されることを要求することもできます。2．スコープ
ハードウェアに対する資料には、設計のどの部分（全て、ではない場合）がこのライセンスのもとにリリースされるのかを明白に特定する必要があります。例えば、製造者がプロプライエタリのICを組み込んだ基盤の設計をリリースする際、このライセンスで、部品表を一般的な、オープンソースの、またはその他の非プロプライエタリのコンポーネントに制限することができます。3. 必要なソフトウエア
このライセンスのもとでリリースされるハードウェアが、それを正しく操作するためや、その重要な機能を実現するために、組み込み、もしくは非組み込みのソフトウェアを必要とする場合、ライセンスは以下の一つの条件に合致するものを要求することができます。
a) 常識的に見て、装置を正しく操作するためや、その重要な機能を実現するためのオープンソースソフトウェアを書くことができるのに十分に、ごまかしがなく、インタフェースがドキュメント化されていること。
b) OSI承認オープンソースライセンスのもとに、必要なソフトウェアがリリースされていること。3. 派生作品
このライセンスでは、改造および派生作品、さらに、オリジナルのハードウェアのライセンスと同一条件での配布を許可してください。またこのライセンスは、製品に添付された設計ファイル、またはその派生設計ファイルをもとに作られた製品の製造、販売、配布、使用を許可するものでなければなりません。4. 再配布の自由
このライセンスは、出典の異なる複数の設計を含む集合的配布の構成要素としてのプロジェクト資料の販売および無料配布を、いかなる団体に対しても制限してはいけません。このライセンスでは、そうした販売にともなう著作権料、またはその他の料金を要求してはいけません。このライセンスでは、派生作品の販売に伴う著作権料、または、その他の料金を要求してはいけません。5. 帰属
このライセンスでは、設計ファイル、製造製品、派生製品、あるいはこれらすべてを配布する際には、派生作品にオリジナル開発者が特定できるようにしてください。また、このライセンスでは、派生作品には、オリジナル設計とは異なる名称、バージョンナンバーを付けてください。6. 人および団体を差別しない
このライセンスでは、いかなる人および団体をも差別してはいけません。7. 分野および目的を差別しない
このライセンスでは、ハードウェアを使用する分野および目的によって使用者に制限を加えてはいけません。たとえば、商用利用を制限したり、核開発での利用を制限するといったことはできません。8. ライセンスの配布
ハードウェアに付与された権利は、製品または資料を再配布された者にも与えられます。この際、受け手は新たにライセンスの取得手続きを行う必要はありません。9. ライセンスは単独製品に特定的に与えてはならない
ハードウェアに付与された権利は、大規模な製品の一部品として組み込まれたときに変更されることがあってはいけません。もし、このハードウェアが製品から取り出され、ハードウェアのライセンスの条件下で使用または配布された場合も、このハードウェアを受け取ったすべての人に、オリジナルの製品とともに与えられている同じ権利が与えられます。10. ライセンスは、他のハードウェアまたはソフトウェアによって制限されてはいけない
このライセンスでは、ライセンスされたハードウェアと共に配布または使用する他のハードウェアまたはソフトウェアに関して制限を加えるものではありません。たとえば、同時に販売された他のハードウェアをオープンソースであると主張することはできません。または、このハードウェアにはオープンソースソフトウェアしか使えないといった制限はできません。11. ライセンスは技術的に中立であること
このライセンスのいかなる条項も、個別の技術またはインターフェイスの形式を前提としてはいけません。あとがき
このオープンソースハードウェア定義に署名した人たちは、オープンソース運動が情報共有のためのひとつの手段にすぎないことを認識しています。私たちは、この定義に合う合わないを別として、あらゆる形のオープン化と共同製作を促進し、支援していきます。
「日本的業務慣行」と「業務パッケージのベストプラクティス」
日本の大企業にはホワイトカラーの仕事を標準化しない、という信念、もしくは伝統がある。そこでは、業務用パッケージの導入が不可能なくらいに、柔軟、場当たり的、独自のやり方で業務をこなすのがその特徴であり、これが生産現場に比べて圧倒的に生産性が低いと言われる我が国のホワイトカラーの特徴だ。
「業務用パッケージの導入が不可能」というと、むしろ生産現場のことではないかと私は思います。よく聞く話としては、下の事例のように
トヨタ流生産管理とR/3が前提にする生産管理とが相入れるものかどうか、プロジェクト開始前に慎重に検討する姿勢がノーリツにあれば、その後の展開は全く違っていただろう。
のように、生産管理業務が「業務用パッケージの導入が不可能」とジャッジされるケースが多いように感じています。
市場調査、シェアなんかを見ても、
生産管理パッケージの評価については，「自社製オーダーシステム」が6割近く利用されており，個々の製品のユーザー数が少ないので参考値程度に考えてもらいたい。
国産製品は海外製品に比べ、現場のニーズに即した機能改善が図られており、支持を集めた。
という感じで、生産管理分野は手組み（スクラッチ）システムが多く、またSAP, Oracleに代表される外資系ERPパッケージより、「現場のニーズに即した機能改善が図られ」ている日本製パッケージのほうが強いという結果が数字にも表れています。
そもそも、（経理のような）ERP が比較的スムーズに導入できてしまうような分野、パッケージシステムと一般職・派遣の人だけでこなせるような定型業務はそもそも本当に「ホワイトカラー」なんでしょうかねぇ？ 工場所属で作業服を着て仕事をしていたとしても、生産管理や製品設計に携わる社員のほうがよっぽど「知的労働者」と言うにふさわしいと私は思います。
「日本的業務慣行」と「業務パッケージのベストプラクティス」は相反する面がありますが、どちらかが一方的に優れているという訳ではなく、会社、部門毎に適材適所なんですよね。「業務パッケージのベストプラクティス」にこだわるあまり自社の強みを殺してしまい「角を矯めて牛を殺す」ような結果にならないようにだけはしたいものです。
NGK2009忘年会
昨日の NGK2009忘年会 に参加してきました。
いやぁ、凄い熱気！（温度計的な意味でも） いろいろと勉強になったり刺激を受けたりできました！
私のLTの資料も、こっそり公開しておきます。Slideshare にアップロードしたらなんかフォントが変わってしまって見にくいですが、気にしない！(後で直すかも) PDFにしてアップロードしたらフォントは直りました、が、画像の背景がおかしい・・・まぁいいや。
GPL And SIer
View more documents from Koichi TAKAGI.
「密造酒をつくる」こと
するとまず、厨房でバイトの女の子が激しく叱られているのが聞こえてきた。
さらに、突然店長というどう考えても年下の若者が出てきて、私たちに説教しはじめた。こういうことをしてもらったら困る、ここはお店である、などなど。
私たちはいちおう事情を言った。この人は、こういうわけでもう日本にいなくなるのです。その本人がおみやげとして海外から持ってきた特別なお酒なんです。どうしてもだめでしょうか？ いくらかお金もお支払いしますから……。
店長には言わなかったが、もっと書くと実はそのワインはその子の亡くなったご主人の散骨旅行のおみやげでもあった。人にはいろいろな事情があるものだ。
しかし、店長は言った。ばかみたいにまじめな顔でだ。
「こういうことを一度許してしまいますと、きりがなくなるのです」
「バイトの女の子」さんの機転を利かせた行為を、ルールを盾に店長がつぶしてしまいました。
居酒屋に限らず、よくあることだと思います。私はＳＥなのでそれを例に取ると、ＰＭの判断でプロジェクトにアジャイル的手法を取り入れたところ、レビューで「ISO9001に反している」「開発標準に反している」などとしてそのボトムアップの工夫を潰してしまうことはよくありがちだと思います。
一般的に、社歴が長い会社、規模の大きい会社では、ルールが幅をきかせている、いわゆる「官僚的」で「風通しの悪い」組織になりがちです。長い時間の中で培われたルールはそれなりに妥当性もあるものだし、また規模の大きい会社では例外を認め出すときりがないという事情もわかります。全てのケースを網羅したルールなんか作れるわけもありません。
とはいえ、歴史のある大手企業でも、「官僚的」で「風通しの悪い」組織でいいわけがありません。
- 作者: 日経ビジネス
- 出版社/メーカー: 日経BP社
- 発売日: 1998/01/20
- メディア: 単行本
- 購入: 2人 クリック: 6回
- この商品を含むブログ (3件) を見る
によると、上司に隠れて研究をしてよい「ブートレッギング（密造酒づくりの意）」、業務時間の１５％を好きな研究に充ててよい「１５％ルール*1」などのルールが公式なものとして存在し、ボトムアップの創意工夫を殺さない工夫が３Ｍ社にはあるとのことです。
ルールでかんじがらめにするのではなく、ボトムアップの自由な創意工夫を大事にすること、またそれを意識的に公式のルールや、成功ストーリーとして流布することが、「官僚的」で「風通しの悪い」組織になることを防ぐには重要と思います。
404 Blog Not Found:居酒屋は何を売っているのか
- 作者: 河合篤男,山路直人,山田幸三,伊藤博之
- 出版社/メーカー: 中央経済社
- 発売日: 2004/02
- メディア: 単行本
- 購入: 1人 クリック: 7回
- この商品を含むブログ (1件) を見る
