ぼうメモ帳

2005-10-31

わかったつもり 読解力が付かない本当の原因

| わかったつもり 読解力が付かない本当の原因を含むブックマーク

ISBN:4334033229

文章を深く理解できない原因を、文章が「わからない」ではなく「わかったつもり」であるという観点から、読者にさまざまな例題を出すことで、実感させながら最終的には文章の読み方の指針を示す本だ。注意が必要なのは、最終的には文章の読み方の指針を示すだけであって、「10日で伸びる読書*1」のような内容ではない。

この本は読者に「わかったつもり」を実感させるために、事例とその解説に紙面のほとんどを費やしている。言い換えると、「わかったつもり」のために文章が読めていないことを実感することはできるが、それを回避するための技術ははあまり身に付かない。

私がこの本を読んで感じたことは、この本は「読者のために書かれているのではない、作者のために書かれている」ということだ。この本は、「わかったつもり」を読書時の最も危なくかつ排除困難な問題とし、「わかったつもり」のために誤読が起こる原因が丁寧に書かれている。この原因を知ることで利益を得ることが出来るのは、文章を書く人間ではないだろうか。

世の中では文章を書くときには「分かりやすい文章」を書けという風潮がある*2。面白いことにこの本の例文はどれも分かりやすい文章である。ほとんどの例文は、小学校教科書に載るような文章のため、大人が読めば一発で理解した「つもり」になれる。しかし、この本を読んでもらえば分かるように、そんな「分かりやすい文章」でも実際にはさらに深い読みが可能、もしくは誤読が多発している。

なぜそのようなことが起こるかについて丁寧に解説されているため、文章を書く人間がこの本に書かれている内容を「読者」ではなく「作者」という立場から読み込むことで、ただ分かりやすい文章だけではない、読者に深い理解を促す、誤読の発生を防ぐような文章を書くことが出来るようになるのではないだろうか。

逆に、「分かったつもり」の原因を逆手に利用することで、読者に「分かったつもり」にさせる文章を書くことができるのではないか。これは、必ずしも好ましいことではないが、文章の内容を読者に「分かったつもり」にさせるような文章構成の技術も、文章を書く者にとっては必要な場面が存在する。仕事をしているときに、相手に理解させることに労力を費やすより、相手に「分かったつもり」になってもらうことで、こちらの労力も低減し、しかも物事を有利な方向へと進ませるという場面は存在すると思う。たとえばプレゼンなんていうのが良い例だ。プレゼンを行う場合、大抵、例えば商品を買ってもらうことや意見を求めるなどの、相手に何らかの働きかけを行いたい場面が多い。そのような時、「分かったつもり」にさせる技術というのは有効に働くと思う。

このような視点から、この本は、読書力を高めるたい人というよりも、文章を書かなければならない人が一読する価値のある本だと思う。

*1:実在する本ではありません。例として適当に作ったタイトルです。

*2:このように書くと、私はこのことに反対しているように読めるけど、そんなことはない

トラックバック - http://d.hatena.ne.jp/susumu/20051031

2005-10-29

他人を信じて仕事を任せる

| 他人を信じて仕事を任せるを含むブックマーク

先週金曜日から、会社研修を受けている。この研修はいやに力が入っていて、計20日という丸1ヶ月間の長期研修だ。研修だけに6時には終わるものの、まじめにやろうとするとなぜか業務よりも疲労度が高いという、恐ろしい罠が待っている。研修初日の講師の一言、「いままでの研修は全てこの研修のための前座」という意味がよく分かった。それぐらい気を張り詰めなければならない研修ということだ。

で、この研修を受けて学んだことが一つある。それが「他人を信じて仕事を任せる」だ。

いままでは、仕事を任せようとしてもその完成度に不満がありありだったことが多く、嫌悪していた感があった。大学院ではほとんど自分の作業は自分で行っていたし、また現在携わっている部署での業務もほぼ個人作業がメインなので*1、他人と共同作業ということに慣れていなかった。また、出来ることならば自分の力でという思いも強かった。

が、今回の研修では嫌でも共同作業をしなければならない。というか、共同作業を行うことが前提だし、共同作業をしなければそもそも作業が終わらないということで、嫌でもチームメンバに仕事を任せなければならない。そして思った。あれ、仕事を任せることって案外楽しくないか。

今回の研修では幸運なことに、チームメンバに恵まれた。チームは5人。よく知っている二人は信頼が置ける。しかも、そのうちの一人は、3ヶ月前からでは信じられないぐらい出来るようになっていて、大学院の2年間は社会人の3ヶ月という言葉が脳裏に響いた。また以前から知ってはいるが初めて一緒に仕事をする一人は、仕事を一緒に行うことでこいつは凄いと感じた。ほとんどの最終決断を彼に委ねている*2。そして、本当に初対面の最後の一人は、俺の全く知らない世界を知っていて、分業という言葉をまじまじと俺の中に突きつけてくれた。そう考えると、非常にチームメンバに恵まれたと思う。それを考えると、チームメンバに恵まれなかった友人の愚痴などを聞いていると、可哀想だ*3

作業中にふと半年前にクラスの担任の言葉が脳裏によぎった。

「人に仕事を任せられるようにならないといけない」

実はこの言葉がずっと頭の中から離れなくて、悩んだ時期もある。ましてや、今の業務に対する先行きの不安や自分のスキルの身に付き具合が絡み合って、何が悩みなのか分からなくなり、脳内ぐちゃぐちゃ、精神ふらふらな状態だった時期もあり、同期に愚痴を聞いてもらいつつ、慰めてもらってた時期もあったりする。

で、研修に入るときも実は不安だった。周りは、俺と同じチームになれば楽が出来るという。そんな実力があるわけもなく、周りは軽い気持ちで言ってるんだろうけど、それが凄いプレッシャーだったりする。しかも、苦手な共同作業をしなければならないときたら、もう、お先真っ暗。個人作業は得意でも、共同作業はどうも苦手。唯一の救いは、定時に帰れるということぐらい。

でも、いざ始まってしまうと、共同作業が非常に楽しいものだと感じてしまった。アクセルしか踏もうとしない俺に対しキチンとブレーキをかけてくれるメンバもいれば、周りが見えなくなった俺に水をかけて目を覚まさせてくれるメンバもいれば、道に迷ったときに何気なくサポートに回ってくれるメンバもいて、また、スケジューリングなど苦手なことを考えなくても済むだけに自分の得意とする分野で思う存分力を発揮することができる。*4

それで思った。担任の「人に仕事を任せられるようにならないといけない」という言葉は、「他人を信頼しろ」ということではないか。26にもなって、いまさらこんな当たり前のことに気づき、実践できていない自分がいるが、12月には管理という仕事もやらなければならなくなる可能性があることを考えると、なんとかこの研修中に、「他人を信じて仕事を任せる」というスキルを身につけたいと思う、そんな今日この頃

*1:方式系で、しかもチームのメンバがトレーナと俺を合わせて二人しかいない立ち上がったばかりのプロジェクトorz

*2:俺が最終決断を委ねるのは、本当に信頼している人か、興味関心のない問題に対する最終決断かのどちらか。今回の研修で後者はありえない。

*3:決してチームメンバが良くないという意味ではない。あくまで相性が合わないということ

*4:こう書くと、迷惑しかかけてないな、俺orz

トラックバック - http://d.hatena.ne.jp/susumu/20051029

2005-10-22

寮の清掃点検に向けて、できることはすべてやったつもり。

これで、再点検になったら仕方がない。

東京モーターショーに行ってきた

東京モーターショーに行ってきたを含むブックマーク

最近のデジカメはすごいですね。

少しでも車を見ようと、がんばって背伸びしてたんですよ。そしたらおもむろに、前の人がデジカメを上に掲げて写真を撮ろうとしました。ちょっと邪魔だよと思いながらも、デジカメ液晶が目に移りました。

ここからでも見えるんだアと思いながら、デジカメの関心をしていると、そのデジカメが写そうとしてるのは、キャンペーンガールばっかり。

周りを見渡してみれば、キャンペーンガールを写そうとしているデジカメばかりです。もう、車を写そうとしている人なんていません。全員が全員、キャンペーンガールばかり写してます。

その異様な光景に、一緒にいた友人たちと爆笑してました。そんな東京モーターショー初体験でした。

なお、個人的にはホンダ日産のブースが良かったです。ホンダは、家族連れのお子さんがキャッキャはしゃいでいたのが印象的で、日産は、30〜50代男性ターゲットにしたCMのようなドラマが印象的でした。

トラックバック - http://d.hatena.ne.jp/susumu/20051022

2005-10-16

お手軽GUI構築ツールキットに向けて

| お手軽GUI構築ツールキットに向けてを含むブックマーク

swingGUIを書いていると、似たようなコードを大量生成しなければならないのが苦痛になってくる。そこで、お手軽にGUIを構築するためのツールキットを準備中

機能的には、次な感じ。

  • GUI構築の自動化
  • 永続化の自動化

言ってしまうと、処理するデータをデータオブジェクトとして定義し、モデルルールベースで記述する。で、ビューとコントローラは自動生成みたいな感じ。

イメージ的には、データオブジェクトの定義を食わせてあげて、いくつかのルールを記述するだけで、ガツンとGUIが自動生成されつつ、しかもそれらで編集したデータは自動的に永続化されるという、すばらしいもの。どこまで自動化が実現できるかは分からないけど。

とりあえず、データオブジェクト編集GUI構築の自動化と、永続化の自動化は技術的な目処はほとんど立っているから、あとはがりがりコーディングするだけ。問題は、モデルをどのように記述し、定義し、それをGUIと結びつけるかってことだ。ここはできないかもしれない。

サーバーサイド系では、このあたりのことは既にやられてそうだから、それを調べてみるのも手かもなあ。

で、家計簿とみるくは、これが出来上がってからかな。

やっちった

やっちったを含むブックマーク

缶チューハイをベッドにぶちまけるという失態をorz

このペースでいったら、寮を追い出されるのも時間の問題かもorz

トラックバック - http://d.hatena.ne.jp/susumu/20051016

2005-10-14

最近、自分の主義主張をあまり表に出していないことが、ストレスになってきているので、ここで発散させてもらう。

ソフトウェア技術者は、ハードウェア設計技法を学ぶべきだと思います

ソフトウェア技術者は、ハードウェア設計技法を学ぶべきだと思いますを含むブックマーク

通常の動作テストでは発見困難なバグとして、複数のスレッドによるリソースの競合や、レース状態が挙げられる。これらの問題は、結果的に起こってみないとわからないし、起こってしまえば原因を突き止めることは難しくない。

マルチスレッドにまつわる問題の多くは、設計者やプログラマの経験不足*1が原因だと思っている。

最近、ハードウェア設計者と少しだけ話をする機会があった。そのとき感じたことは、明らかに検証という分野においては、ソフトウェアハードウェアに対して、遅れをとっている。物理的な制約が存在するハードウェアは、ソフトウェアに対して検証のモデルを構築しやすいことや、もともと非同期並列やデバイス依存の動作のバラつきが存在すること、また不具合修正のコストが全体的に大きかったことが、検証という分野を発展せざるをえなかった理由だと思っている。

それに対しソフトウェアは、その基本的な動作は決定的であるため、どれもまったく同じ動作をし、適当に作っても比較的適当に動いてしまう。

いま、ソフトウェア開発者の中で、開発中のプログラム内の全てのスレッドを把握し、それらが舐めるコードの1ステップステップに対し、一瞬でも被ってしまうがために不具合が発生するというバグを意識しながら、設計やコーディングを行っているという方は、多くないと思う。ましてや、多くに人員を投入するプロジェクトでは、完全に分業体制が確立されており、全てのコード*2を把握している者は、まずいない*3。1年以下の案件ですら、キロ・ステップ単位ではなく、メガ・ステップ単位のコードが開発される現状で、いったい誰が全てのコード*4を把握できるでしょうか。

そんな世界で活きてくるのが、検証技術だと思います。

もちろん、ハードウェアに対して自由度の大きいソフトウェアでは、規模の大きいシステムに対し形式的検証など望むまでもなく、実現することは非常に困難です。テスト項目とテストパターンによる半しらみつぶし作戦で、信頼性を上げるしかありません。

しかし、マルチスレッドを用いたプログラムでは、この半しらみつぶし大作戦だけでは、バグは普通に通り抜けてしまいます。そのため、これらは事後に発見するんどえはなく、設計・コーディング段階で未然に防がなければなりません。

そこで、私は思います。複数のスレッドを走らせたとき、どの部分で問題が発生するかを、コードを読むだけで目星がついてしまうという、よく分からない得意技をこの3年間で身に着けました。危ないところは匂いがする*5、という感じです。

この良くわからない特技は、非同期回路の開発を通して身に付いたと最近思っています。非同期回路では、至る所にレースが発生する可能性*6があり、脳内シミュレーションで可能な限り排除しなければなりません。

この、脳内シミュレーションで排除するという行動が、不具合の少ない設計やコーディングに効いてくるのではないか。そんな考えの下、ソフトウェア技術者も、ハードウェア設計の経験を持つべきではないかと、最近思うようになりました。

以上です。

*1:悪いけど言い切らせてもらう。酔いどれだし

*2プログラムは設計どおりに動くのではなく、コードとして記述されたとおりに動きます

*3:ここでも言い切ります

*4:設計じゃありません

*5:正確には、どのようにすれば発見できるかという技術存在します。それを駆使すれば、かなり容易に発見できます。

*6:開発方法論によりますが、プリミティブに落としていくと、基本的には発生すると考えています

トラックバック - http://d.hatena.ne.jp/susumu/20051014

2005-10-13

仕事が疲れる

仕事が疲れるを含むブックマーク

毎日3時間ぐらい残業をしているけど、それが虚しい。

やっぱり、事業部で顧客相手の仕事をしていればよかったのかなあと思う今日この頃。

前は、好きなことができて嬉しいとか思ってたけど、最近は罪悪感の方が強くなってきて、事業部で死にそうな思いをしながら仕事をしている同期の話とかを聞くと、申し訳ない気持ちでいっぱいになり、辛すぎる。

今している仕事は、プロジェクトの立ち上がりで、しかもお金を産むかもどうか分からない得体の知れない物体を相手にしているわけだけど、3ヶ月前に、「大変だろうけど、がんばってモチベーションを維持しろ」という命令が、最近になって身にしみて良く分かる。

はてさて、どうなることやら。

Winnyの技術

| Winnyの技術を含むブックマーク

ISBN4756145485

やっとこさ登場。

コレを見て思ったこと。

少なくとも、Winnyの設計では、オープンソースは耐えられない。

どういうことかというと、Winnyの現状の設計では、ソースコードオープンにしたとたん、匿名ネットワークが崩壊するということだ。なぜそう感じたのかは、書くのが面倒なので省くけど*1オープンソース匿名性を維持しつつ情報発信を行いたければ、隣接ノードが完全に自分のノードとは異なる実装であっても、自分が発信している情報が本当に自分から発信されている情報かどうかを、他ノードが判断できないようにしなければならない。

たとえば、隣接ノードに自分が保持している情報リストを渡すとする。このとき、自分のノードが明らかにP2Pネットへの新参者であると分かる場合、その情報リストは、自分が保持している情報であることの意思表明をしていることになり、その情報を元に何らかの危害が自分に加わる可能性があることを意味している。

また、新しい情報を投下する場合、隣接ノードにその情報PUSHすると、それは、自分がその情報を持っていることだとばらしてしまうため、同様の危険性が発生する。

そのような危険性を回避するためには、

などを行わなければならない。

オープンソースでこのようなことを実現するためには、このソフトなら安心して使えるという根拠をユーザに与え、そして、オープンな実装がネットワーク全体のマジョリティを占める状態を確保した上で、徹底的に隣接ノードに自分のオリジナルな情報を流さなくても済むような方式を考えなければならない。

もしこれが実現できれば、たとえ悪意のあるユーザがネットワークに参加しても、隣接ノードからの情報を頼りにした追跡という手法が取れなくなり、ノードの追跡は事実上不可能になる。

コレが実現できるならば、本当に匿名性を維持できるようになるのではないだろうか。なお、ここでいう匿名性とは、自分が特定されることではなく、自分が発信している情報が、本当に自分が発信しているのかを特定できないようにするという意味での匿名性であることに注意。また、その情報の中に、自分を特定できてしまうような情報が含まれていたら、このような仕組みもまったく意味がないことに注意。

*1:酔いどれ中のため、勘弁

トラックバック - http://d.hatena.ne.jp/susumu/20051013
267982