hirax.net::Keywords::「図解」のブログ



2009-03-22[n年前へ]

デジタルがアナログに追いつく日 

 こう言うと「冗談」だと思われることも多いのですが、私はコンピュータを扱うのが本当に苦手です。何か資料を作るときは、ハサミと糊でマニュアリー(手作業)でコピー・ペーストをしながら、仕上げることが多いくらいです。

 先日書いた「論理的にプレゼンする技術 」の特長はとてもイラストが使われていることです。そのイラスト・イメージは、駅中の喫茶店で、いつも持ち歩いている小さなホワイトボードに絵を描きながら「イメージ」を編集者に伝えました。「こういうことを伝えたい」という絵をホワイトボードに描き、そして、それをケータイで撮影して記録していくのです。

 そんな携帯用ホワイトボードに描いた、ラクガキの例が下の画像です(あるいは、さらにその下に小さく張り付けたような「まとめ」用イラスト例になります)。本書のページを本屋で手にとって、一枚一枚めくってみれば、こんな稚拙なラクガキを元に綺麗に・わかりやすく描き直されたイラストを、必ずどこかに見つけることができるはずです。

 ところで、手書きで「言いたいこと」を描くよりも、コンピュータを使って資料を作る方がずっと時間がかかるように思います。しかも、プレゼンテーション・ソフトウェアで図を作ったりした日には、「考えていること・言いたいこと」がメリハリがつかなくなり、わかりにくい資料になってしまうことが多いようにすら思うのです。不思議なような気もしますが、そう私は感じています。

 デジタルがアナログに追いつく日は、まだまだ来ないのではないでしょうか。それは、単に「私が追い付いていない」だけなのかもしれません。けれど、やはり、デジタルがアナログに追いつく日は、まだまだ来ないのではないか、と思うのです。

イラストイラストフローフロー






2009-04-03[n年前へ]

「わかる」技術への道は1日してならず 

 畑村式「わかる」技術を読みました。その結果、「わかる」ということはどういうことか、「わかる」に近づくためのやり方にはどんなことがあるのかということについて、再確認したり・頭の中の整理を進めたりすることができたように思います。

 「理解術」が「説明術」を支えているでこんなことを書きました。

 わかりやすく物事を説明できる人の話を聞いていると、多くの場合、その人たちが私たちにわかりやすく話をすることができる理由に気づかされます。それは、その人自身の中で、話題・議論の中身について「十分に物事が整理されている」ということです。そして、その人自身の中で「わかりやすい話」として十分な理解ができている、ということです。
 つまり、「説明術」の根本にあるのは「理解術」なのです。その人たちは、「(十分に理解した上で)わかりやすい話」を話しているから、「わかりやすく物事を説明できる」というわけです。
 つまり、「わかりやすい説明」をするためには、「十分な理解」=「わかる」ことが必須だと信じています。だから、たくさんの「わかる」方法を知りたくて、畑村式「わかる」技術を読みました。

 この本の中に書かれている、節タイトルをいくつか抜き出してみると、こんな具合になります。

  • 「わかる」とはどういうことか
  • 学校の教科書や授業はなぜわかりにくいのか
  • 「直観」と「直感」の違いを考える
  • 「わかりやすいこと」の落とし穴
  • 暗記で、できること、できないこと
  • 「面白い話」をする人は何がどうちがうのか
  • 絵を描くことの意味
どの部分も「なるほど」と思わせられます。「わかる」ということが「どのようなことか」「どのようなことができるようになることか」を、実感させられます。

 残る課題は、「わかる」ということ=「そのようなこと」「そのようなことができるようになる」ためには、どうしたら良いかを自分なりに考え・実践してみること、のようです。「わかる」技術への道は1日してならず、のようです。

 複雑な世界だからこそ、「わかる」ことが必要になる。その重要性はますます高まっているのです。

わかる






2009-05-09[n年前へ]

「野球の統計データ」を通して眺める「統計解析の基本と仕組み」 

 山口和範「図解入門 よくわかる統計解析の基本と仕組み―統計データ分析入門 」は、わかりやすい本です。けれど、この本の読んでいて感じる面白さは「わかりやすさ」より、「心で感じることができる楽しさ」にあると思います。

 どういうことかというと、この本にに出てくる例は「現実に即した例」で、それが工場の不良品率とかいった役に立つけれど「私たちの仕事から離れた趣味」とは必ずしも繋がらないような例ではなく、「私たちの私たちの趣味」と繋がるような、「(本当に)実際の野球選手にまつわるさまざまなデータ」なのです。不思議なくらい、そんなデータで「相関」や「主成分分析」などの話題が説明されていくのです。面白い本です。

 まずは、本塁打とフォアボールの数の関係を示したグラフが下の図になります。たとえば、このデータの場合イは、「本塁打を打つ選手は(に対しては)、フォアボールが多い」という直観・実感に即したデータです。ホームランバッターにはボール球を多く投げたくなる状況が多いでしょうから、これはごく自然なデータでしょう。ちなみに、ここで言うホームランバッターというのは、本塁打数が20本を超えるような選手だということがこのグラフからわかります。

 ところが、次の「本塁打」と「死球(デッドボール)」の関係グラフを眺めてみると、少し意外に感じます。ホームランバッターには危険球ぎみのボールを投げ、その結果デッドボールが多くなるかと思いきや、そういうわけではないようです。・・・考えてみれば、死球が多く、その結果怪我をしがちだったりしたら、ホームラン(本塁打)を多く打つことができなくなってしまうわけですから、これもよくよく考えてみればあたり前なのかもしれません。

 というわけで、ここまでは、よくよく考えてみると自然に納得できるデータです。次のまだ「関係がよくわからないデータ」は、打率と三振の関係を示したデータです。高打率を誇る選手は三振が少なそうに思えるのですが、そういうわけではないようです。どういう状況があることで、こういう関係が成り立っているのでしょうか。

直接私たちの何かの役に立つわけでもない「野球の統計データ」を通し、私たちが直接役に立てることができる「統計解析の基本と仕組み」を学ぶのは、何だか楽しく思えます。

意外な野球の統計データ意外な野球の統計データ意外な野球の統計データ






2009-12-15[n年前へ]

ComThreadを使った「制御プログラムの作り方」図解編 

 以前、Rubyでテキストや(比較的単純低速な)バイナリデータ送受信のためのクラスであるComThreadを作りました(情報ページ)。それでは、どんな風に使うかということも、これまた以前、ComThreadを使った「制御プログラムの作り方」に書いたことがあります。

 ComThreadという名前が、実にありがちな名前であるので、他のライブラリともしかしたら混同されているのかもしれませんが、「送受信に2つのポートを必要とするのか?」という質問があったので、「そんなことはないですよ」とここに書いておきます(もしかしたら、最初に作成した際の紹介記事の2番目の例が、機器間のシリアル通信をモニタリングする例だったから、そういう風に勘違いされたかもしれません)。

 最初の記事の2番目の例、すなわち、機器間のシリアル通信をモニタリングする例は、AとBという機器間で行われている通信をモニタしたい、AとBは通常通り通信しあう関係にしたままで、その互いのやり取りを知りたい、という場合に、シリアル通信の内容を調べる、というプログラムです。つまり、簡略図にすると、A<->Bという関係をA<->PC<->Bというにしてやり、PCはAから受信した内容をBに送り、Bから受信した内容をAに送るわけです。だから、PCからみると、機器Aへの接続を行うCOMポートと、機器Bへの接続を行うCOMポートの2つが必要だったというわけです。

 もちろん、それは2機器間の通信をモニタリングする例だったからで、(最初の紹介記事の)一番最初に挙げた例のように、1つの機器相手に送受信を行うだけであれば、当たり前のはなしですが、COMポートは1つしか必要としません。

 さて、これだけではつまらないので、今日は、ComThreadを使った「制御プログラムの作り方」で書いたことを図にしてみました。つまり、前回、文章とコードで書いた内容を「図」にしてみました。それが下の図になります。

 前回書いたように、(センサーやモーターといった)各ハードウェア機器に対するモデル・クラスをConThreadクラスを継承させて作り、また、制御を行うコントローラをThreadクラスを継承して作り、そのコンローラインスタンスに、各モデルのインスタンスを渡してやる、というのがComThreadを使い、複数機器を制御するのであれば、一番整理しやすいような気がします。

 つまり、(各ハードウェア)モデル・インスタンス(スレッド)を作成し、コントローラ・インスタンス(スレッド)を作成して、(各ハードウェア)モデル・インスタンスをコントローラ・インスタンスに渡した上で、必要な期間だけそれらのスレッドを動かしておく、というようなスクリプトを作る、という具合です。

ComThreadを使った「制御プログラムの作り方」図解編






2011-05-01[n年前へ]

「誤解させるための立体グラフ」の作り方!? 

 グラフを眺める人を誤解させる、値を勘違いさせることを目的とした、”悪い”立体棒グラフを作ってみました。「○×電力と△□電力の一月あたりの電気料金を比較する」と題したグラフです。グラフを作ることだけが目的ですから、データ自体にはまったく意味はありません

 「一月あたりの電気料金を比べてみると、△□電力は○×電力の2倍(前者が1万円で後者が2万円)」なのですが、その「2倍」の違いが「3〜5倍程度」に感じられます。それはもちろん、このグラフが「電球の高さ」を用いて電気料金を表現しているのに、その高さに応じて電球の幅まで変えているからです。

 電球の高さで2倍の違いが、電球の面積では4倍の広さの違いになり、もしも電球の立体感まで忠実に感じてしまったなら8倍もの大きさの違いに感じられてしまう…というわけです。

 ただし、感覚というのは対数的に働くでしょうし、それと同時にグラフの軸を眺め・判断をすることもありますから、実際には「8倍」というほどの違いは感じないように思います。だから、大雑把に見て「3〜5倍程度の違いに感じてしまう」という辺りになるわけです。

 下のグラフは、上の棒グラフをさらに「三次元空間内の物体」として認識させやすくしてみたものです。もともとのグラフが、棒グラフを3次元物体と感じさせることで「誤解」をさせることが目的のグラフでしたから、これはつまり「さらに誤解しやすくさせたグラフ」です。

 遠近感(パース)も利用して誤解させることを目的としたこのグラフ、「感覚的に」眺めたとしたら「△□電力は○×電力の電気料金はどの程度の違い」として感じられるでしょうか?

「誤解させるための立体グラフ」の作り方!?「誤解させるための立体グラフ」の作り方!?








■Powered by yagm.net