Stories / 最終更新時間:2008年06月24日 22時56分47秒

目次

本についての簡単なレビュー記事です。

グレートゲーム・オブ・ビジネス

社員の能力をフルに引き出す最強のマネジメントと題して、オープンブックマネジメントの古典が邦訳されている。

言っていることはシンプル。

やりたいと思える目標を設定すること。一日の勝利、一週間の勝利、月の勝利、四半期の勝利、年の勝利を味わう仕組みを用意すること。目標を全社で共有すること。そのとき、目標と現状を数字で表せるようにすることが大事。つまり、主観をいれない。これらのことを行う前に経営者、管理職、社員の間に信頼関係を築くこと。それは本当のことを言う――嘘の数字を言わない、情報を開示し、本音と建前を分けない――ということ。従業員が自分の仕事に誇りをもてるようにすること。

これらを具体的に実行して、会社を立て直し成長させていく様子が事細かに書かれている。文章は長く、わかり易くはない。実際の表などもない。けれど、死んだような顔、やる気のないしょぼくれた職場、誇りのもてない仕事、そういう状態だった会社を見事立ち直らせていく過程はとても熱く、興味深い。無理だと思っていたことがある。少しずつ問題が見つかり、解決されていく。数字のグラフが伸びていく。もしかしたら・・・という気持ちが広がる。

そういう本でした。うまくいかないときのこともちゃんと書かれています。

プログラミング作法

Brian W. KernighanとRob PikeによるC/C++/Javaプログラミングの解説本。コーディングスタイルから個々の技法や注意することまで、丁寧かつ無駄のない文章で解説されている。初心者向けの本に見えるが、詳しい人もプログラミングの面白さを再発見できる良書。

The Practice of ProgrammingのWebサイトにてSource Codeなども見ることが出来ます。
また、一部の内容がココで邦訳されてます。

日本の昔話(柳田国男著)

昔話を収集して本にまとめたもの。文庫本でリーズナブル。昔話はなにかと味がありますが、ときどき、つっこまずにはいられない昔話に出くわします。ひとつダイジェストでご紹介。[1]

  • [1]雰囲気、文体、筋などはそのまま
  瓜子姫

爺と婆は川を流れてきた瓜(うり)の中から
女の子を拾いました。
爺と婆は瓜から生まれたので瓜子姫と名付け可愛り、
鎮守様のお祭りには瓜子をお参りに連れていこうと、
お駕籠(かご)を買いに町へ出かけました。
留守中、瓜子姫が機を織っていると、
あまのじゃくが作り声をして
「裏の柿の実を取って上げましょう、瓜子さん」
と言って瓜子姫を連れ出て、柿の樹に縛りつけました。
そうしてあまのじゃくは瓜子姫の着物を着て化けて知らぬ顔をして
機を織っています。
そこへ爺と婆は帰って来ました。
あまのじゃくを乗せて鎮守様へ参ろうとしていると、
瓜子姫が「瓜子を乗せないでようよう、あまのじゃくばかり
駕籠に乗せてようよう」と大きな声で泣き、
爺と婆はびっくりして引き帰してきて、
それから爺は鎌をふり上げて、あまのじゃくの首を切り、
黍(きび)の畑に捨ててしまいました。
黍の茎が秋赤くなるのは、そのあまのじゃくの
血が染まったからだそうです。

だそうです、じゃないだろう。
――こんな感じで、とくに「爺」が凄いです。

とらのゆめ

緑色のトラが夢のなかを歩き回る絵本。一回目はそっけなく読み終わったのに、何度か読み返すうちに不思議な含蓄を感じるようになる。同じ言葉が、読み返すごとにそのままの意味ではなくなっていく。

   ぐう ぐう ぐう
   とらの とらきちは
   ゆめを みます
   ねむい ねむい

ピープルウエア 第2版

優しい本よりも、たいていは毒舌な本の方が面白い。著者の言っていることが的外れでなければ。

この本、実際読んでみて、そう的外れには思えなかった。だから長い時間が経っても復刻され読みつがれるのだと思う。

本の結論を要約すると、

  • ソフトウェア開発者には集中できるまとまった時間・環境が必要
  • 目標に向って結束したチームの生産性は高いうえに楽しい
  • ヤル気こそプロジェクト成功の鍵

となる。当たり前です。このことがいかに無視されているかを、具体的な例、やってはいけないこと、育む方法などをまじえて率直に紹介しているのが本書の特徴。

たとえば、以下の項目についてどう思うだろうか?

  1. 生産性を飛躍的に向上させる方法があるはずなのに、今までずっと見落としてきた。
  2. 他の管理者は2倍も3倍も成果をあげている。
  3. 技術は日進月歩で、油断するとすぐ置いていかれる。
  4. プログラミング言語を変えれば、生産性は大幅に上がる。
  5. バックログが多いから、すぐにでも生産性を2倍にする必要がある。
  6. 何もかも自動化してしまおう。そうすれば、ソフトウェア開発者がいらなくなるのではないか?
  7. 部下に大きなプレッシャーをかければ、もっと働くようになる。

著者はこれらを「管理者が陥りやすい7つの錯覚」としてあげ、ひとつひとつ説明している。技術や手法の進歩や実践を否定しているわけではない。分かりやすく効果の薄いエサに飛びつく前に、もっと根本的な「人が開発するということ」に焦点をあてた方が効果的ですよ、ということ。

どの程度信頼性があるかは別として、こんな表もある。

目標値設定者による生産性の違い

目標設定者 平均の生産性 プロジェクト数
プログラマー 8.0 19
管理者 6.6 23
プログラマーと管理者 7.8 16
システムアナリスト 9.5 21
目標なし 12.0 24

スケジュールを決める担当が違うだけで、なぜこんな差が生まれたのか。誤った目標値の設定はプログラマーにやる気を失わせる。プログラマー自身が加わればより現実的な値になるし、責任感も生まれるだろう。多くの失敗や成功の経験を持つシステムアナリストは現場を冷静に見て正確な見積もりができた。最後に、なぜ日程的な目標がない状態が最も力が発揮できたのか? まったく理由が思い浮かばないなら、それはピープルウェアについて疎かにしている証拠かもしれない。

頭脳労働時間と肉体労働時間は違うということもこの本が強調している点。ただ机の前に座っている時間よりも、割り込みなしでひとり精神集中できる時間が重要ということで、これは作業している本人も忘れていることが多い。そこでオフィスの騒音や電話が問題になってくるわけだ[2]。Radium Softwareの040205 - Fire and Motion (1)にも同様のエピソードが載っていて面白い。

  • [2]メールは受け手の時間に合わせられるのでいいけれど、メッセンジャーは微妙ですね

チームについては、それぞれがやる気を出すためにこそチームがあると考えると、ちょっと違う見方ができるかもしれない。

各章の概要についてはこちらのホームページで管理者の方が自身の言葉をおりまぜつつ紹介しているようなので参考にどうぞ。

熊とワルツを

ピープルウェアで有名な、トム・デマルコとティモシー・リスターによるプロジェクト(リスク)管理の指南書。軽妙な語り口でリスク管理の理由、効果、方法を説いている。本の中にこんなエピソードがある。

(ティモシー・リスター)わたしの父は数学者で、数学の教授だったがいまは引退している。ある日父は、ソフトウェア・プロジェクトはどれも遅れる、ほぼ100パーセント遅れるではないかと責めた。

 「どうしてなんだ」と父はたずねた。

 「プロジェクトには二通りの結果がありえます。期日に終わるか、期日に遅れるかです。少数の類まれなケースを除いて、後者の確率が高いでしょうね」

 「ティム、ありうる結果は二つだけじゃないぞ」と父は答えた。「三つ目がある。期日より早く終わる場合がな」

これにはハッとさせられた。この三番目の可能性がゼロなら、遅れなんて起こるべくして起こるに違いない。

このほかRISKLOGYというエクセルシートを使ったリスク管理ツールの紹介も面白い。
このツールは、プロジェクトの開始日とあらゆる幸運が続いたときに完成する日を入れると、プロジェクトがいつ終わる可能性が何%かというグラフを表示してくれる。

計算にはどんなソフトウェアプロジェクトにもありえる以下のコアリスクを使っている[3]

  1. 内在的なスケジュールの欠陥
  2. 要求の増大(要求の変更)
  3. 人員の離脱
  4. 仕様の崩壊
  • [3]ほかのリスクを入れたり、コアリスクを自社のこれまでのデータに変更することもできる

さきほどのグラフは業界の平均データをもとにモンテカルロ法でプロジェクトを500回シミュレートしたもの。一番右のグラフはプロジェクト完了しない可能性だ。それぞれのバーを足し合わせると500になる。つまり、70%の確率でプロジェクトが完了する安全性を確保したければ、バーを左の期日から足していき、500×0.7=350になる日を選べばよい。

進歩状況、現在獲得価値(EVR)の判断には、細かなインクリメンタル開発を薦めている。全部を100の部品に分けたとしたら、バージョン1(V1)はAとBを含み獲得価値は11%、V2はCとDとEで価値は19%、V10で全価値が盛り込まれ100%となるというような形で進めていく開発だ。ただし、受身のインクリメンタル開発(率先して公表していない、場当たり的な)ではその長所がまったく活かせない。

事前に入念な計画をする先見的インクリメンタル開発では、プロジェクトの各機能の価値にあわせて優先順位をつけ[4]、リスクのある部分に早めに取り掛かることができる。

このあたり至極もっともだけれど、詳細設計図(インプリメントすべき最低レベルのモジュールやクラスと、その相関関係を示す図)を作るのはなかなかたいへんそうだ。変更をリスクと考えるか、前提と考えるかでこのあたりの捉え方が変わるかもしれない。アジャイル開発手法とうまくマッチする詳細設計手法はどんなものなんだろう。

  • [4]優先順位をつけることで、すべての部分が等しく重要だという病癖を取り除ける。

ライト、ついてますか

古い本で前口上が長いけれどポイントポイントは面白い本。内容は「あわてて問題解決に乗り出す前にもっと考えることがありますよ」という主張です。

なにか「問題」を感じ取ったり、持ちかけられて解決しようとすると、いろんな立場の人が別の問題を感じていて、それぞれ別の解決方法(ほかの立場のひとには到底受け入れられないものも!)が考えられることを忘れてしまいがち。「それは誰の問題なんだろう?」

この相手では話が進まない。うまくいかない、困った、どうすればいいだろう。こうしたらどうだ、ああしたらどうだ、いろんな可能性が考えられる。しかし相手の態度の悪さはどこから来たのだろう? この相手と過去応対した人々(自分を含めたわれわれ自身)の態度に問題があったのかもしれない。「問題はどこから来たのか」

新しい視点は新しい不適合を作り出す。問題を解決したが、そのせいでまた別の問題が起こる。問題は決してなくならないし、問題解決が余計なこともある。「他人が自分の問題を自分で完全に解けるときに、それを解いてやろうとするな」

よし、うまくいった! しかし得られた解答はちっともほしいものじゃないかもしれない。「私はそれを本当に解きたいか?」

と、ダイジェストで紹介してみました。ライトの話は本書を読んでのお楽しみ。イラストが年代を感じさせます。

ザ・ゴールからクリティカルチェーンまで

経営管理の理論について書かれた指南小説。本の大筋の解説はAll About Japanの「ザ・ゴールシリーズの関連ガイド」や自動車産業関連リンク集の「TOC(制約条件の理論)」に譲るとして、ここではソフトウェア開発をする個人の視点から概説を。

ゴール ― 企業の究極の目的とは何か

イスラエルの物理学者エリヤフ・ゴールドラット博士は、工場を経営していた友人から「生産管理のスケジューリングがうまくいかない」と相談を受けたとき、物理学の研究をしてきたやり方で、その問題の解決法を考え友人に伝えました。

結果は予想以上。博士はやがてOPTという生産スケジューリングソフトを販売する会社を起こし、その販売促進用に「ザ・ゴール」という小説を書きました。OPTを導入すると短期間に生産性が上がり、余計な在庫は消える……成果は十分だったものの、詳しい原理を公表せず、疑いや無視の対象にもなっていたので、小説の形で分かりやすくその原理を説明しようとしたわけです。ベストセラー、販売も順調、しかし思わぬ状況が待っていました。

小説を読み、人の手でその考え方を実践した工場が、それだけで小説のような成果をあげたという手紙が寄せられます。現実の工場はスケジューリングが複雑だからOPTがなければ無理だと考えていたものの……どうやらそうではないらしい。博士は会社を離れTOCの研究所を設立、TOCの教育・研究を推進していくことになります。

TOCは常識的で理屈にあっているので「なぜうまくいくのか」納得できます。実績もある。しかし、工場を離れてソフトウェア開発などに応用するにはどうしたらいいのか、すでに結果をあるなら調べてみたいと思い、他シリーズも読んでみることにしました。

ザ・ゴール 2 ― 思考プロセス

ザ・ゴールは新しい考え方を主人公と一緒に追っていく形だったのに、ザ・ゴール2はすでにある思考ツールを主人公と一緒に使っていくという形になり、前よりもすっきりしない感じがします。

しかし、全シリーズを読んだあと、一番役に立ったのはこのゴール2です。応用範囲が広さがメリットであり、デメリットでもあり。

ゴール2の背景には、TOCによる改善で生産性を増した工業・部署が、生産性を増していることが原因で従業員の削減対象になるという「努力すれば仕事がなくなる」現実がありました。

制約が工場にあるのではなく、市場にある場合、どう対処すればいいのか。それに対するTOCの答えがこれです。

チェンジ・ザ・ルール!― なぜ出せるはずの利益が出ないのか?

ソフトウェア開発会社を舞台に移したということで、内容に期待していたものの、ゴール1、2のおさらいのよう。システム開発ではなく、ITシステムを導入した企業がそのメリットを活かす方法についての話が大部分。

ただ、表題にもある明確な主張の重要度を知るには、この一冊分が必要だったのかもしれないです。

「チェンジ・ザ・ルール」

暗黙の前提やルールが変わらないなら、新しいなにかを導入しても変化は起きない、メリットは活かされない。

製品の売り込みで実際の効果を約束するやり方、そういう自負を持てるだけの考えがあるということ。半分騙すようでないと売れない製品を作るのをやめて、基本に立ち返った世界。なんだか羨望を覚えます。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

大学のエグゼクティブMBAを舞台に今度は「プロジェクト管理」の制約を探り、新しい管理方法を提示します。小説としても読ませる内容。TOCが工場だけの理論でないことをよく示しています。

ただ、ソフトウェアのプロジェクト管理にこれをそのまま適用できるのか? と問われると、即答できない違和感があります。たとえば、ピープルウェアのトム・デマルコ氏も「TOCは素晴らしい。しかし、システム開発には向かない。知的労働者にはゆとりが必要だ」という意味の発言をしています。

とはいえ、トム・デマルコ氏の主張とエリヤフ・ゴールドラット博士の主張、双方共通する点も多く、お互いを補完するなんらかの解決策があるのではないかと思わずにはいれません。

そして、TOCにはこんなときこそ使える解決方法――思考ツールがあります。

関連リンク

ゆとりの法則

ピープルウェアでおなじみのトム・デマルコの本。ソフトウェア会社やソフトウェア開発プロジェクトのよりよい運営にはゆとりが必要だ、という主張です。

最初ゆとりと聞いたとき時間のことかと思ったのだけれど、それだけではなく「管理のゆとり」、つまり上司が一方的に権限を行使するのではなく部下に自由にやらせるなどあらゆる意味での「ゆとり」が含まれてるのがポイント。

ゆとりの法則の内容は、2004年頭に開かれたDevelopers Summit 2004での講演でも述べられています。詳しくは「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏トム・デマルコ講演の個人的メモなどトム・デマルコ関連リンクからたどっていただくとして……ここではゆとりについてもう少し。

ありがちな意見として「もちろんゆとりはあったほうがいいけど、予算や競争でそうもいかないのが現実」という声があります。けれど、ゆとりがないことの悪影響は、結局は予算超過や売れない製品として自分に返ってくると考えれば、ゆとりについて真剣に検討してもよいと思えるかもしれません。

もうひとつ理由があります。もし本当に価値のある製品だったなら、そんな予算が足らないもの? 誰もたいしてほしがらない、喜ばれないものを作っているのでは? バグがなければよい製品? 悪い点のあるなしではなく、世界や体験がどう変わったかが重要なのでは? そんな意見が検討されることはあまりないようです。

ゆとりは一種の投資である。ゆとりを無駄と考えず投資と考えることが、ビジネスを理解している組織と、単に忙しいだけの組織の違いである。

本の帯にはこんな文が引用されています。

人間は時間的プレッシャーをいくらかけられても、速くは考えられない

   ――ティム・リスター

労働者がガレー船の奴隷で、プレッシャーがむちだとしたら、むちを使うほど「これ以上は速くこげない」というところまで仕事のペースは上がるかもしれない。頭脳による識別の速度は変えられないため、プレッシャーに対応できる量は少なく、

  • 無駄な時間をなくす(そもそも知識労働者は時間の無駄を楽しむより、不満に思うことが多い。無駄にしている時間はそれほど多くない――超過勤務だらけのときは別だが)
  • クリティカルパスにない仕事を後回しにする(優先度がはっきりしているなら、仕事が完成して満足感が得られるようそれを優先したいと思っている)
  • 夜遅くまで仕事をする(短期的には効果があがるが、体にこたえるうえ、家庭や個人の生活の面でプレッシャーが高まり、いずれ適正なバランスに修正される。毎日過剰に働いてるのに昼も夜も遊ばず集中して作業したりするだろうか?)

くらいしか方法がなく、メリットがデメリットを上回るか疑問でしょう。

まちがった管理についての法則を2つ。

一.うまくいかないことがあったらもっとやれ

「いまやろうとしていることはうまくいくはずだ。うまくいっていないのは、一生懸命やっていないせいだろう」という理屈。

二.自分自身のユーティリティ・プレイヤーになれ

ストレスの過剰の組織では管理することが「危険」なので、自分がボスであると同時に部下のひとりとして仕事をすることで管理をパートタイムに処理し、安全を確保する。下部の仕事は重要だし、それを自分で受け持つのだから悪いことはなさそうに見えるけれど、管理は片手間にできるほど簡単で影響力の低いものなのか? という話[5]

  • [5]ちなみに、管理が難しいのは人間関係、そのほか微妙で「難しい技能」が必要だからであって、やるべき仕事が多いからではないという点に注意。「働きすぎている管理者はほぼ間違いなくやるべきではない仕事をやっている」

本書の内容を一部紹介するとこんな感じ。面白い本です。
最後に、ゆとりがないとどうなるのかを引用します。

必要なゆとりが足りないと、組織は狂乱状態になり、恐怖感に支配され、リスクを避けようとし、大切な従業員はもっと働くのに適した場所を求め去っていく。

考える脳 考えるコンピューター

Palmの生みの親ジェフ・ホーキンスが人生にかける二種類の情熱。ひとつはモバイルコンピューティング。もうひとつは――「脳」。

氏は幾多の苦難にめげずレッドウッド神経科学研究所や、Numentaという新タイプの記憶システムを研究する会社を設立したりしています。

人工知能の判定方法として有名なチューリングテストですが、人工知能研究が誤った方向にいきがちな理由のひとつがこれ。

わたしが静かに本を読むとき、目に見える行動を何一つとらなくても、あきらかに理解して知識を得たと、少なくとも本人は思っている。(中略)質問して確かめることもできるが、理解は物語を読んだときに起こったのであって、質問に答えた瞬間ではない。この本で主張することの一つは、理解したかどうかは外側から見える行動では判断できないというものだ。

テストするものが「行動結果だけ」だったために、脳がどのように機能しているか(脳のシミュレーション)を疎かにしてしまっている、という意味の主張です。理解とは何かについて解明するのが知性あるコンピュータを作るためのキーで、中国語の部屋の論争にもあるように出力が知的だからといって「理解」しているとはいえないというわけ。

以下いろいろネタばれがあるので、ご注意を。

脳はなぜ最速のコンピューターよりも速くて有用な処理を実行できるのか? 「簡単なことだ」と、脳をコンピューターとみなす人々はいう。「脳は並列コンピュータだ。何十億という細胞が一斉に計算をする。この並列処理によって、生体の脳の処理能力ははるかに高くなっている」

しかし、氏はこれが詭弁だと言います。十分なメモリと高速なプロセッサー、大量の並列処理さえこなせれば知能を備えた機械ができるなんて迷信で、いまの人工知能には根本的欠陥がある、と。

人間は(写真を見てそれがネコかどうか)0.5秒以内に正解を出す。しかもニューロンは反応が遅いから、その0.5秒の間では、脳に入った情報は100個の細胞を通過するだけだ。つまり、脳がこの問題を解くときには、全体として何個のニューロンが関与したとしても(並列に何億とニューロンが関与したとしても)、100回以下の「計算」しかできない。(中略)同じ問題を解こうとするコンピュータは何十億というステップを必要とするだろう。100回の演算では、画面に一文字を表示するのがやっとであり、意味のある仕事をするどころではない。(中略)どれほど高速に動かしても、難問の答えを100ステップで「計算」することは不可能だ。

これだと突っ込みどころがいろいろありそうです。でも、並列処理はある限界を超えると、(いくら並列にしても)総処理時間が短くならなくなるのは確かです。

では「計算」できないとき、どうやって答えを導き出すのか? プログラマーなら思い浮かぶことがあります――そうメモリです。氏は新皮質全体がひとつの記憶システムであって、コンピューターなどではないと主張します。

脳は問題の答えを「計算」するのではなく、記憶の中から引き出してくる。本質的に、答えはずっと昔から記憶されている。何かを記憶からとりだすだけなら、数ステップでできる。

さらに、このニューロンの遅さで現実のさまざまな出来事を瞬時に判断する高速性の理由を、

脳は低レベルの感覚についての予測をたて、あらゆる瞬間に何を見て、聞いて、触っているはずかを前もって期待しているのだ。しかも、それらは並列におこなわれる。新皮質のどの領域も、つぎに何を体験するかを予測しようとする。(中略)ここでいう「予測」とは、ドアについての感覚にかかわるニューロンが、入力を実際に受け取る前に興奮することを意味する。そして、現実の入力が到達したとき、予測された興奮と比較される。(中略)予測と実際の差によって、注意が喚起される。

と推測。階段を踏み外すような気がしたとき、お笑い番組で笑うときなど、身に覚えがある方もいるのではないでしょうか。

このあたりの仕組みは、面白さや興奮、安心感や心地よさ、落ち込みや感激を提供する、いろんな物作りにも活かせそう。

新皮質に注目しながら脳が理解する仕組みを考察していく中、次の注目は記憶の方法です。決まりきったテンプレートを記憶していたのでは効率が悪すぎて瞬時の判断には使えません。そこでキーとなるのが「シーケンス」「分類」「階層化」です。以下、少し長い引用に。

新皮質の領域では、分類にもとづいてシーケンスが組み立てられ、シーケンスにもとづいて分類が修正されるという相互作用によって、両者はつねに変化していき、それが生涯にわたってつづく。これが脳による学習の本質だ。

(中略)

新皮質の領域としてのあなたには、観察しているシーケンスの名前をつぎの階層に伝える役割がある。そこで、紙に「赤赤緑紫橙緑」という文字列を書き、上位の領域に渡す。これを受け取った領域にとって、文字列そのものにはほとんど意味がない。単なるパターンの名前として、ほかの入力と組み合わされ、分類され、さらに高次のシーケンスの一部となる。あなたと同じように、上位の担当者も自分が観察しているシーケンスの進行を見守っている。そして、ある時点で、あなたにこういうかもしれない。「ねえ、もしもぼくに渡すつぎの紙にどの文字列を書こうか悩んでいるのなら、ぼくの記憶では、それはきっと『黄黄赤緑黄』のはずだよ」と。この助言は、実質的に、あなたが入力パターンから見つけるべきシーケンスの指示だ。あなたは最大限の努力をして、このシーケンスが構成されるように入力を解釈しなければならない。

(中略)

人間はある瞬間に網膜に映った像を覚えるのでも、ある瞬間に蝸牛殻や皮膚が受け取ったパターンを記憶するのでもない。新皮質の階層構造によって、物体の記憶は単一の場所ではなく、階層全体に分散されて保存される。さらに、階層の各領域は記憶の普遍の表現を形成するので、新皮質の典型的な領域が学習するのは、普遍の表現のシーケンスが入れ子になったものだ。脳の中には、カップであれ、ほかのどんな物体であれ、具体的な画像は存在しない。(中略)しかし、忘れないでほしいのは、新皮質のどの領域が記憶する普遍の表現も、パターンが階層をくだっていくことで、実際に体験する詳細な予測にかわりうることだ。

そのほか、新皮質の情報の流れ方(逆方向も重要)、海馬の役割についての面白い解釈(187ページあたり)や実際の考えるコンピューターに必要なハードウェア(説明は少し)、倫理、応用、役割など、盛りだくさんの内容になっています。応用例にもっと夢があってもいい気はしましたが:D

この主張が正しいかどうかは分かりません。でも自分がこの本でなにより面白いと思ったのは、「当分は考えるコンピューターなんて無理だよ」とあきらめムードが漂うAIの分野で、「結果が複雑だからといって原理が複雑だとは限らない。原理が分かればもっと早く実現できるはずだ」と果敢に挑戦する氏の姿勢です。それから、直感を疑うことの大事さを改めて感じました。こういう面白い時代に生きてて幸せだと思います。

新皮質は超高速の部品でできているわけではないし、使われている規則もさほど複雑ではない。だが何十億というニューロンと何兆というシナプスを含み、階層的な構造をしていることもたしかだ。理論的には単純だが、数的には巨大な記憶システムによって、人間の意識も、言葉も、文化も、芸術も、科学技術も、そしてこの本も生み出されている。(中略)新皮質は実際に働いている。けっして魔法ではない。その機能は必ず解明できる。そして、それと同じ原理で動作する真の知性を備えた機械は、コンピューターをつくることができたのと同様に、最後には実現される。

Palmの生みの親、人工知能分野の新会社設立へ--PCフォーラムで発表パームの生みの親は脳の研究に首ったけなんて記事も。

アイデアのつくり方

非常に薄い本だ。広告代理店で役員をしていたジェームス W.ヤング氏が、「アイデアをあなたはどうして手に入れるか」という質問に対する解答として、ひとつの技術なり公式なりを考えられないだろうか、と考え、解説した古典。言い回しは古いけれど、中身はシンプルで分かりやすい。つまり、よい意味で薄い本ということ。

そんな貴重な公式を惜しげもなく公開するのは、これが簡単すぎて実際に信用する人はわずかしかいないだろうということと、実際に実行するのは最も困難な知的労働が必要なので、アイデアマンの供給過多になることはまずないからだ、と氏は語っている。

アイデアとは既存の要素の新しい組み合わせ以外の何ものでもないということである。

これはおそらくアイデア作成に関する最も大切な事実である。

これが本書の前提。「真の意味での新しい発見なんてもう残されていなくて、あるのは既存のものの組み合わせにすぎない」という話を悲観的なトーンで語る文章を、昔色々なメディアで目にすることがあった。けれど、氏の語りはもっと楽観的だし、「真」なんてものを一切気にしていない。タフだ。

実際の手順についてはWikipediaにも少しだけあるが、意味合いを理解してもらうには本書を読んでもらうのが一番いいだろう。薄いので立ち読みでもすぐに読めるはず。

少しだけまとめると、

  1. 資料を集める(広告の場合は、「製品についての資料」と「ターゲットにしたい消費者についての資料」。そして生涯通して集め続ける一般的資料)
  2. 資料をいろいろな角度から眺めて、咀嚼し、関連性を探り、パズルを組み合わせる。そして嫌気がさす
  3. 放り出して別の刺激を受けることをして、無意識の中で考える
  4. アイデアが生まれる
  5. アイデアを現実に適合させるため、忍耐強くたくさんの手を加える。理解ある人々の批判をあおぐと、よいアイデアは自ら成長する

といった感じ。よく聞くような話だけれど、自分の経験ともよく合っていて納得がいくのではないだろうか。無駄に思えるかもしれないが、手順を省略することはできない。ようするに近道はないが、道はあるということ。

アイデア発想関係ではアイデア創発の素振り ITmedia Biz.IDがとてもよくまとまっていておすすめ。新しい組み合わせを生み出すための「トリガー」を並べる方法についていろいろ載っている。自分で実際使ったことがあるのはエクスカーションだけだけれど。未来年表初心者向け簡易検索(特許・実用新案)iタウンページを使った方法なども面白い。