「ほっ」と。キャンペーン

<   2012年 02月 ( 29 )   > この月の画像一覧

日本航空の再建

きょうの日経新聞のコラムで、日本航空の再建の記事が乗っていた。日航のV字回復を受けての記事だが、稲森CEOのとった手段が、以前に再建委員会が提出し却下された内容と同じものだったと強調していた。そうして倒産以前にも現場では同じような問題が指摘されているにもかかわらず、経営陣は対策を怠っていたというような内容の論調だった。

これから、やはり現場の意見が大切だとか、経営陣には外部からも迎えないといけないなどの結論を導くのは簡単だ。また、実際に倒産した会社がV字回復したのだから、経営判断に誤りがあったといわれても返す言葉はないだろう。

しかし、本当に前の経営陣が現場からの声を全く無視して、恣意的な経営をやっていたのだろうか。日航の経営内容が、山崎豊子の『沈まぬ太陽』に書かれているようなものなら大変なことではあるが、そうであればもっと早くに破綻が訪れていたような気がする。

利用者の意識の変化、原油価格、為替レートの変動、人件費の変化など経営環境の変化についていけなかったことの方が原因としては大きいような気がする。

一般に企業規模が大きくなるほど資金的な体力はあり、市場の占有率は高く、存続が容易くなるはずだ。しかし、一方では、企業規模が大きくなればなるほど経営環境の変化に応じて劇的に経営内容を変えるということができなくなる。また、経営陣に現場の生の情報が届かなくなってしまい、危機的な環境の変化に対応できなくなる傾向にはあるのかもしれない。

それならばということで社内企業などの試みをしてみたが、同じ市場を社内の企業同士で取り合ったり、似たような企画を統制もなく立ち上げたりなどうまくいかなかった。

巨大企業を安定的に運営するための科学的な方法論などないのだろう。あるとすれば、鍵となるのはコミュニケーションではないだろうか。現場の事情を経営陣が知らず、経営陣のビジョンを現場が理解出来ないというのは、そこに良好なコミュニケーションが成立していないことを示しているのではないだろうか。

企業の規模が企業の経営を脅かすとすれば、規模の拡大を補うコミュニケーションのシステムを構築しなければならないのではないかと思われる。ITは単なる道具に過ぎない。ITを整備したとしてもそれが本当のコミュニケーションに変わるわけではない。

ブラジルのセムラー社は、極力文書を作成しないシステムにしている。営業が顧客からのクレームを受けたときは、製造の担当者のところへ行って口頭で伝える。文書による伝達はコミュニケーションではないことを知っているからだろう。

巨大企業の循環不全を解決する鍵は、膨大な文書の作成をやめて職員同士が顔と顔を合わせて直接にコミュニケーションを取るようなシステムを作ることではないだろうか。
[PR]
by tnomura9 | 2012-02-29 13:03 | 考えるということ | Comments(0)

Google ドキュメントを使ってみた

Google ドキュメントを使ってみた。

ブログを使っていて一番うれしかったのは、どのパソコンからでも自分の文章を編集できることだった。管理人はWindowsのデスクトップパソコンと、ノートパソコン、Ubuntu のノートパソコン、Android のタブレットを持っているが、それぞれ置いてある場所が違う。ブログならどのパソコンからでもアクセスして編集できるので、ローカルのファイルに文書を作成するのが不便で仕方なくなる。

ただし、ブログに文書を作成してそれをアップロードすると、それは公開した文書になってしまう。これは、下書きを書きたいときには問題だ。簡単に編集したり校正したりできなくなるからだ。また、私的なメモ書きのようなものはブログには書けない。

今回たまたま Google ドキュメントを試して見たところ、これがまさに自分の求めていたものだったのに驚いた。

いままで、Google ドキュメントを触らないようにしていたのは、クラウドに文書を置くのに不安を感じていたからだ。自分のパソコンから外に出したデータは基本的に公開されているものと考えておいた方がいい。クラウドコンピューティングに慣れて、不用意に個人的なデータを書き込んでしまうのではないかという疑念があった。

その疑念は今でも拭い去れていないが、基本的に公開していい文書であれば、Google ドキュメントは本当に便利だ。ワードプロセッサやスプレッドシート、プレゼンテーションの基本的なオフィススイートが揃っているし、何といっても、どのコンピュータからでも同じ文書にアクセスすることができる。このどのコンピュータからでもアクセスできるという使い勝手には中毒性がある。この文章も Google ドキュメントで作成しているが、使い込んだら手放せなくなるような予感がする。

知的生産の道具がまた一つ増えた。

参考リンク

Google ドキュメント
動画マニュアル.com
[PR]
by tnomura9 | 2012-02-28 09:28 | 考えるということ | Comments(0)

国土交通省の「ノアの方舟」

国土交通省が高知県の津波対策として「ノアの箱舟」計画を提案している。大型船のグラスファイバー製の救命ボートを改造して、25人乗りの救命艇を作る。費用は一隻あたり300万円だそうだ。

高知県内の老人施設や保育所に1000隻の配備を予定している。2万5千人が救われる計算になる。津波の際に高台へ避難するのに比べ、避難までの時間が数分で済み、自分で動けない入所者も移動することができる。総額で30億円ほどかかるが、防潮堤は1箇所で1000億円単位の費用がかかり、効果もはっきりしない。

1000隻のボートの回収をどうするのか、周辺の住民までが避難してきた時にどうするのか、こどもがボートで遊んで怪我をする危険はないのか、メインテナンスはどうするのか、めったに使用しない機具なので津波の時に実際に使えるのか、同様の理由で避難演習がきちんと実行されるだろうか等の問題点は残るが、防潮堤などに比べて費用対効果比が大きい。

アイディアだおれではないかという危惧もあるが、船舶の救命艇を改造するので、初期不具合はあまりないだろう。また、避難までの時間が圧倒的に短い。何と言ってもコスト・効果比が魅力的だ。

この政策の良いところは、津波から人命を守るという本質に注目していること。老人や子供は退避のために長い距離をすみやかに移動することが難しいという見逃せない問題点に配慮していること。既存の救命艇のように使用実績のあるものを転用して不具合の発生を防ぐ工夫をしていること。津波は明日来るかもしれないので、早急な対応が必要とされているがそれに極力間に合う方法を考えていること。費用対効果にたいして十分に配慮していることなどだ。

これらは、単にスローガン的なトップダウンからの発想からは思いつくことはできないだろう。発想の中に現場の匂いがする。

このように柔軟で現場に即した政策はどんどん打ち出して欲しいものだ。
[PR]
by tnomura9 | 2012-02-27 12:52 | 話のネタ | Comments(0)

葛飾応為

数日前、葛飾北斎の一生がNHKの番組で放映された。終わりの方で北斎の晩年に起居を共にした北斎の娘の応為の話が出てきた。北斎が何十年も筆をとっているのに猫一匹うまく描けないと涙ぐんだときに、自分が未熟だと知っていることが大切だと慰めたという。

その応為の作とされる夜桜美人図が映されていた。うら若い美女が庭で夜中に庭の灯篭の明かりを頼りに和歌をしたためている。宵闇の庭の中で、灯篭に照らし出された彼女の白い顔と手元、そうして庭の桜の花だけが浮き出て明るい。また、彼女の足元には背の低いもう一つの灯篭があり、彼女の着ている華やかな着物の裾を浮き立たせている。明るいのは色鮮やかなその二ヶ所だけであたりは闇に沈んでいる。しかし、空を見上げると満天の星空だ。なんとも独創的で幽玄な構図だ。また、女性の顔も気品のある緊張感を感じさせる。

この絵が気になって仕方なかったのでネットで探していたらいい記事を見つけた。

葛飾応為《夜桜美人図》抒情と科学の暗闇──「安村敏信」

不美人で、掃除をせず、嫁ぎ先の夫の絵を笑って離縁になり北斎と住むようになったらしい。着るものにも、食べ物にも無頓着で、北斎の絵の手伝いをしていたが自分の名前で絵を発表しようとはしなかった。上に述べた代表作の夜桜美人図にも落款はない。雅号を持つようになったが、北斎が自分のことを「オーイ、オーイ」と呼ぶから応為としたらしい。また、北斎の書く枕絵などにも積極的に手伝ったりアドバイスしていたりしていたようだ。着物を着せた木製の人形がヒットし巨万の冨を得るが、北斎の死と共に出家し消息不明となった。なんとも不思議なひとだが、この絵のアイディアや腕前はただものではない。

こんな人もいたのだ。
[PR]
by tnomura9 | 2012-02-24 23:51 | 話のネタ | Comments(2)

Coming Soon ????

まるで映画の予告編のようだ。

【AMU & HIMA 】チーム☆アステロイド [ DREAM TEAM ] PV



既に十分アイドル。猫も。

大人の女性すらかんじさせる美しい動きの「ひま」と、顔は可愛いのに圧倒的なパワーダンスの「AMU」。このふたりのコラボは見てみたい気がする。驚いたことに、ふたりとも、まだ10歳だ。おとなになったらどんなダンサーになるのだろうか。

YouTube のチャンネル

ひま (emurin4jp)
AMU(mat2988)
[PR]
by tnomura9 | 2012-02-23 08:22 | ボーカロイド | Comments(0)

1日食塩摂取量

1日食塩摂取量を計算するページをアップしました。ダウンロードすればローカルの環境でも使用可能だと思います。一応検算はしていますが、ユーザの責任でのご使用をお願いします。

1日食塩摂取量
[PR]
by tnomura9 | 2012-02-23 01:39 | 話のネタ | Comments(0)

Haskell 記事リスト RWHの読み方

Real World Haskell の読み方 (1) Getting started
Real World Haskell の読み方 (2)
Real World Haskell の読み方 (3) Types and Functions
RWH の読み方 (4) 第2章
RWH の読み方(5) 第2章
RWH の読み方(6) 第2章
RWH の読み方(7) 第2章
RWH の読み方(8) 第2章
RWH の読み方(9) 第2章
RWH の読み方(10) 第2章
RWH の読み方(11) 第3章 Defining Types, Streamlining Functions
RWH の読み方(12) 第3章
RWH の読み方(13) 第3章
RWH の読み方(14) 第3章
RWH の読み方(15) 第3章
RWH の読み方(16) 第3章
RWH の読み方(17) 第3章
RWH の読み方(18) 第3章
RWH の読み方(19) 第3章
RWH の読み方(20) 第3章
RWH の読み方(21) 第3章
RWH の読み方(22) 第3章
RWH の読み方(23) 第4章
RWH の読み方(24) 第4章
RWH の読み方(25) 第4章 Functional Programming
RWH の読み方(26) 第4章
RWH の読み方(27) 第4章
RWH の読み方(28) 第4章
RWH の読み方(29) 第4章
再帰関数について
RWH の読み方(30) 第4章
RWH の読み方(31) 第4章
RWH の読み方(32) 第4章
RWH の読み方(33) 第4章
RWH の読み方(34) 第4章
RWH の読み方(35) 第4章
RWH の読み方(36) 第4章
RWH の読み方(37) 第4章
RWH の読み方(38) 第4章
RWH の読み方(39) 第4章
RWH の読み方(40) 第4章
RWH の読み方(41) 第5章 Writing a Library: Working with JSON Data
RWH の読み方(42) 第6章 Using Typeclasses
RWH の読み方(43) 第6章
RWH の読み方(44) 第6章
RWH の読み方(45) 第6章
RWH の読み方(46) 第6章
RWH の読み方(47) 第6章
RWH の読み方(48) 第6章
おさらい
おさらい その2
RWH の読み方(49) 第6章
RWH の読み方(50) 第7章
ghci の multiline command
RWH の読み方(51) 第7章
三段論法
Haskell の printf デバッグ
Debug.Trace
RWH の読み方(52) 第7章
RWH の読み方(53) 第7
RWH の読み方(53) 第7章
IOモナドのアクション
RWH の読み方(54) 第7章
RWH の読み方(55) 第7章
RWH の読み方(56) 第7章
Haskell でヒストグラムを作る。
RWH の読み方(57) 第7章
[PR]
by tnomura9 | 2012-02-22 18:12 | Haskell 記事リスト | Comments(0)

RWH の読み方(10) 第2章

Real World Haskell の第2章 Types and Functions のまとめの最終回。

The Type of a Function of More Than One Argument

引き数が2つ以上の関数の型 (type signature) がどのように表記されるかという説明。

Prelude> :type take
take :: Int -> [a] -> [a]

上の関数の型をみると、関数 take の引き数が Int と [a] (リスト) で結果が [a] リストになるというのは分かるが、それが全部 -> でつながれている。なぜ Int, [a] -> [a] にしないのかという疑問が湧くがこれは次のように解釈する必要がある。

take :: Int -> ([a] -> [a])

つまり、take は Int という一個の引き数をとり、([a] -> [a]) 型の関数を戻値として戻す関数であるという見方だ。この意味は関数の部分適用とカリー化に関係するが後述すると書いてある。

Haskell は関数を値として考えることができるのでこのような芸当ができる。関数を全て1引き数の関数と考えるやりかたは IO モナドの >= 演算子を活用する際に重要になってくる。

Why the Fuss over Purity?

なぜ、関数の純粋性 purity が必要なのかという説明。最初に not の関数の型を表示してそれから何が考えられるのかということを推測している。

Prelude> :type not
not :: Bool -> Bool

この関数の型をみれば、not がどういう動作をするのか知らなくても、結果が引き数を無視していつもTrueかFalseを返すとか、引き数の値をそのまま戻すとか、引き数の値を反転して戻すとか推測できる。

それと同時に、この関数がファイルにアクセスしたり、ネットワークに接続したり、時刻を取得したりできないのが分かる。つまり、not は副作用をもたず、純粋関数であるということだ。

純粋関数の結果はグローバル変数の値や、データベースのデータやネットワークの接続の状況に影響されない。純粋な関数は本質的に modular (モジュール化されている)で、自己完結 self-contained していて、明確なインターフェース well-defined interface を持っている。

Haskell の関数は純粋関数が標準なので、そのコードは入力によってのみ結果が戻され、入力以外の影響で結果が変化することはない。

(副作用というとその関数の実行が他の関数に影響するという意味に捉えやすいが、上の説明をみると、目に見えない他の状況が関数の結果に影響すると考えるほうが、その影響を理解しやすいような気がする。純粋関数が同じ入力にたいしいつも同じ出力を返すというのは、目に見えないグローバルな環境の影響を全く受けないということだ -- 管理人)

副作用のある関数と、純粋関数をはっきりと分けることは、目に見えない攻撃からコードを守ることになる。

まとめ

これで Real World Haskell の第2章まで読み終えたことになる。第1章、第2章と読んできて、この本が Haskell についてどのように解説しようとしているのかが分かる。それは、具体的な Haskell の使い方を超えて、Haskell というプログラム言語のもつ思想を伝えたいと考えているようだ。そうして Haskell の設計思想の根底にあるものが、型システムと抽象性だ。

管理人が RWH を何回読んでも忘れてしまっていたのは、How to ではなく、What is が書かれていたためだろう。これは知っていると流し読みした箇所に書かれていた、Haskell とは何かという意味を読み取ることが出来なかったからだ。

RWHに具体例が記載されていないわけではなく、3章以下は実際に動くプログラムを作りながら Haskell の特徴を理解していくような記述がされている。読者はそれらの例を実際にファイルに作成して動作を確認しながら読み進めたほうがいいだろう。ただ、その際も Haskell とは何かという著者のメッセージを逃さないように読んでいったほうがいいのかもしれない。

このままプログで3章以下を続けることも考えたが、それは、日本語訳の本も出版されているので重複するのではないかと考えたので2章まででやめることにする。正直、人に伝えるために書くのはしんどい。実際、3章以下は読めていなかったので、管理人自身がこれから読むことになる。

Haskell は奥が深いようだ、3章以下を読むのが楽しみだ。
[PR]
by tnomura9 | 2012-02-22 07:44 | Haskell | Comments(0)

RWH の読み方(9) 第2章

Real World Haskell の第2章 Types and Functions のまとめの続き。

Polymorphism in Haskell

原著に忠実なまとめが難しかったので、以下は、管理人の視点からの要約になる。

この節では多形性 polymorphism を扱っている。しかし、多形性とは何かという定義を厳密に記述するより、リストの関数 last という具体的な例を上げて直観的に説明しようとしているように見える。

last をリスト [1,2,3,4,5] に適用するとリストの最後尾の要素 5 が返される。また、last を文字列 "baz"に適用すると戻値は最後尾の要素 z だ。[1,2,3,4,5] の型は [Int] であり、"baz" の型は [Char] だから、last は型の異なる値に対してそれぞれに相応しい結果を返すことができる。

型の異なる値に適用できるので last は polymorphic function だ。

polymorphic function の type signature は type variable を含むのですぐ分かる。(ことさら英語の用語を使うつもりはないのだが、これらの用語を日本語でどう訳すのかわからないのだ。日本で Haskell を本格的に広めるためには、日本語の Haskell 用語委員会のようなものを作る必要があるのではないだろうか。)

Prelude> :type last
last :: [a] -> a

上の type signature の a が type variable (型変数) だ。これを見ると、last は型 a の要素のリストを引数に取り、型 a の値を返すことが分かる。また、引き数のリストの要素の型と結果の値の型は同じ型だ。

また、型 a の部分には Int や Char などいろいろな型を当てはめることができる。このようなタイプの関数の多形性を parametric polymorphism と呼ぶ。

このような関数の type signature からは、実際の値の型がどういうものかを推測することはできない。last は、Intのリストを操作するとか文字列を操作するという具体的なものを離れた、リスト一般という抽象的なものを操作する関数だからだ。

type variable によって表される、[a] はリスト一般という抽象的なリストを表している。この型は parameterized type または polymorphic type と呼ばれる。[a] はリストという枠組みそのものを指し示すことができるのだ。last はこの一般的なリストに作用する関数だ。したがって、last は具体的な値を作り出すこともできないし、具体的な値をチェックすることもできない。しかし、この抽象性の故に、[a] の a にIntやChar を当てはめた具体的なリストのどれに対しても同じ last という関数を適用させることができる。

関数の多形性は、その関数が抽象的なデータを加工していることを意味しているのだ。

Haskell の多形性は他のプログラム言語の多形性とはことなる特質があり、それについての考察がなされているが省略する。

原著の内容を勝手に編集してどうするのだという意見もあるかもしれないが、管理人の視点から見た原著の内容を記述してみた。原著に忠実でない場合が、かえって原著のアイディアに焦点を当てることが出来る場合もあるのではないだろうか。単に、原著の骨組みを抜き出すよりはノートをとる意味があるような気がする。

Reasoning about Polymorphic Functions

上のサブタイトルは、Polymorphism in Haskell 節の中の小見出しだ。ここでは fst を例にとって、fst の type signature から fst の動作がどのようなものであるかを推測して見せている。Reason about は推測するという意味。:type コマンドで fst の型を表示させると次のようになる。

Prelude> :type fst
fst :: (a, b) -> a

上の fst の type signature からいろいろなことが推測できる。まず fst の引き数は pair でその要素の型は a と b とあるように異なっていてもいい。また、fst の戻値の型は、pair の第1の要素と同じ型であって、第2の要素の型とは必ずしも一致しない。

ここで、気をつけておかないといけないのは、(a, b) -> a は引き数の第1要素の型と戻値の型が同じということを示しているだけで、第1引き数の値と戻値の値が同じであるということを意味しているわけではないということだ。そこを混同してしまうと誤解が生じてしまう。

いずれにせよ、関数の型から関数の動作を推測することができるということが大切だ。Haskell のプログラムを書くときの、関数の型宣言は煩雑に感じるが、この型宣言は関数を解読する場合の重要なドキュメントになる。

Further Reading

関数の型による推測についての文献が紹介してあるが、管理人には読みこなせそうにないので省略。

Polymorphism in Haskell 節を読んで思ったのが、Haskell の多形性はデータを抽象化する Haskell の能力と深い関係があるということだ。

Haskell の type variable はその抽象化の働きをサポートする使い勝手のいい道具なのかもしれない。Haskell でプログラムを組むことによって、自然に抽象的な問題についてのプログラムをその抽象性を損なわないまま記述してしまうことができるのではないかという気がする。

head や tail や last などのリスト操作の関数は直観的にたやすく扱うことができるが、これらの関数は実際は一般的なリストという抽象的なデータを加工しているのだ。

そのため、文字列の構造がどうかとかいちいち実装のことを考えなくても、何となく「リストの先頭の部分」とか「リストの残りの部分」などという曖昧な発想でプログラムを書くことができる。あまりに簡単にできるので気にも止まらないが、他の言語と比較した時にはとんでもないことをやっているのかもしれない。

Haskell は抽象的な思考をそのまま具体的なコードとして記述するための道具を備えているようにみえる。

だんだん Real World Haskell の記述の癖のようなものが分かってきた。この本は Haskell の具体的な使い方と言うよりは、Hakell を使う時の考え方を伝えようとしているのだろう。

この記事で一気に2章の最後まで行こうと思っていたがどうやら無理なようだ。
[PR]
by tnomura9 | 2012-02-21 20:02 | Haskell | Comments(0)

メランコリック

原曲

メランコリック pv

歌ってみた

Tianshi - Melancholic
【白服】Melancholic メランコリック を歌って踊ってみた【仮面2】HD
【Nico Nico Chorus】Melancholic 【8 People's Chorus + 1】

踊ってみた

【馬琴&ぐり子】メランコリック踊ってみた
【ささ・れれ】 Melancholic メランコリック 【踊ってみた】HD
【わた】メランコリック踊ってみた。C.S.Portリアレンジ
【こずえとマリス】メランコリックを踊ってみた
【ファイン&つるてぃー】Melancholic メランコリック踊ってみた
【@ちーちゃん×チカ】Melancholic メランコリック踊ってみた【AZATOROiD】
【ひま】メランコリックを踊ってみた【NICOLE ver.】
【中国娘】メランコリックを【踊ってみた】by: mayaya&KI
Melancholic メランコリック full dance ver.踊ってみたとTALKBOX演奏 ft.PESS-T
【いくらミンカ】メランコリックを踊ってみた【魚民】
[PR]
by tnomura9 | 2012-02-21 03:52 | ボーカロイド | Comments(0)