近年の Facebook, Twitter に代表される SNS (Social Networking Service) の勢力拡大には目覚しいものがありますね。
周囲を見渡してみても、これらのサービスのアカウントを保有していない人を探す方が大変なほど。
以前、ブログによってインターネット上の「発信者」の数が激増したという話 (参照: 議論の仕方) をしましたが、SNSによってこの増加に拍車が掛かったように思われます。
ところで、これほど多くの人々が情報を発信するようになったことで、インターネットがどう変わったかと改めて考えてみると、私が期待していたのとはだいぶ違った方向へ進んでいるように思えます。
と言うのは、その内容には特に意味のない、「発信者」同士の関係を表すためのだけの情報が、ネット上で交換されるデータの大部分を占めているように観察されるからです。
特にその傾向が強いのが Twitter で、リツイート (Retweet) と呼ばれる機能により、他のユーザの投稿内容を自分の投稿に引用するということが頻繁に行われています。
これは、ユーザの関心が「何を語るか」「何が語られているか」よりも、「誰が言ったか」「誰がそれを読んだか」に向けられていることを示すものでしょう。
もっとも、それがソーシャル・ネットワークの本質であるわけなのですが、個人的には色々な人の多様な考え・意見が読めるようになると期待していたので、ちょっと残念に感じてしまうのかもしれません。
ところで、この頃のネットでは引用が多くなったから、自分の意見を語るまえに、どこかから引用をしようとする。
自分の意見を持たない者も増えた。
「誰某がこんなこと言っているらしいけれど、どうよ？」
「ああ、それなら、こんなこと言っていた奴もいるみたいだよ」
というリンク先を交換するだけで意見交換をしていない。
しかも、原典まで辿らず、伝聞だけの「噂話」に終始する。
こういった情報のシェアが、「親切」の一種だという価値観が生まれたように見えるが、たぶん、昔からあったことだろう。
実は、ネット上に限らず、現実空間における人との係わり合いにおいてもこうした傾向を感じています。
人間は普通、課題や仕事に取り組んだり、本を読んだりすれば、それらに対して何らかの感想や、自分なりの意見を持つのではないでしょうか。
しかし、そうした意見や感想を持たない、あるいはそれを自分の言葉で表現しない・できない人が非常に多いのです。
見たもの・やったことを淡々と説明したり、それに関連するこんな記事を読んだという 「事実」の説明はできるのですが、「それについてあなたはどう感じた・考えたか」を尋ねられると、途端に言葉に詰まってしまうというケースが頻繁に観察されます。
意外に思われるかも知れませんが、特にITの分野では、仕事をする上で自分なりの考え・意見を持つこと、それを表現することは非常に重要な意味を持ちます。
何故ならば、客観的な事実の記録や、外部の情報への接続 (リンク) などの行為は、コンピュータによってほぼ完全に賄われてしまうからです。(参照: 思考の価値)
人間を遥かに凌ぐ記憶精度・容量と演算速度をもつコンピュータによって稼動するシステムの中にあって、それでも人間をそこで働かせる必要があるのは、こうした人間が持つ経験や勘 (と呼ばれるもの) や、そこから生まれるデータ化できないノウハウ、即ち、個人的な考えと判断が不可欠だからに他なりません。
「主観的なものの見方は、ビジネスにおいて害悪である」という考え方は、必ずしも正しくないのです。
そしてまた、そうした考え・意見を、自分の言葉で、他人に分かるように伝えるということも大切。
これをやらずにいると、知らず知らずのうちに「考えること」自体ができなくなってしまいます。
「いざとなればできる」なんて思っていても、普段からある程度の運動をしていないと、実際に走ってみたときに想像以上に身体が鈍っていてびっくりするのに似ているかも知れません。
体重計を気にするのも結構ですが、脳メタボにもご用心、です。
通常、プログラムを書くときは、処理をただ順番に書き下すのではなく、いくつかの「関数」に分割します。
これによって各ステップの処理が部品化され、再利用が可能になるわけですが、関数分けの効用はそれだけに留まりません。
たとえ、たった一度しか実行されない処理でも、これらを上手く関数化し、本体から分離することで、プログラムの可読性・保守性を向上させることができます。
例えば、以下のようなフォームからデータを受け取るプログラムを考えてみましょう。
▼ソースを表示
▲ソースを隠す
<form action="./" method="post">
<div>
<input type="hidden" name="id" value="<%=office.id%>" />
</div>
<table>
<tr>
<th>名称</th>
<td><input type="text" name="name" value="<%=escape_html(office.name)%>" /></td>
</tr>
<tr>
<th>所在地</th>
<td>
<input type="text" name="postcode-a" value="<%=sprintf('%03d', postcode_a)%>" size="3" /> -
<input type="text" name="postcode-b" value="<%=sprintf('%04d', postcode_b)%>" size="4" /><br />
<textarea name="address" rows="2"><%=escape_html(office.address)%></textarea></td>
</tr>
<tr>
<th>Tel</th>
<td><input type="text" name="tel" value="<%=escape_html(office.tel)%>" /></td>
</tr>
<tr>
<th>Fax</th>
<td><input type="text" name="fax" value="<%=escape_html(office.fax)%>" /></td>
</tr>
</table>
<div>
<input type="submit" value="<%=escape_html((office.id != 0) ? ' 更新 ' : ' 登録 ')%>" />
</div>
</form>
天気がとても良かったので、磐梯町にある「猪苗代第一発電所」へ。
今回は、以前「猪苗代第二発電所」を訪れたときとは逆に、猪苗代湖側から膳棚山を経由して磐梯町駅方面へ抜けてみました。
コンピュータ・インターネットの世界は日進月歩。
これまで誰も予想しなかった技術・サービスが、あっという間に世界中に広がり、常識が一日ごとに塗り替えられていきます。
そうした環境においては、常に自己を革新することが求められ、新しいことに挑戦する勇気を持たぬものは消えていく運命にある......といったような認識を持っていらっしゃる方も多いのではないでしょうか。
そうした見方は概ね正しいと思います。
挑戦と革新はいつの世も進歩と発展の原動力であったことは間違いなく、またこれからもそうであることでしょう。
その一方で、プログラマの間でよく知られる格言に、
フェンスが建てられた理由が分からないうちは、それを倒してはならない。
Don't ever take a fence down until you know why it was put up.
というものがあります。
先週の金曜から夏休みを頂いて、青森県弘前市へ行ってきました。
まずは白神山地を観にいったのですが、折からの豪雨で川は増水し、登山道も荒れていたため、最初のチェックポイント (?) である「暗門滝」で引き返すことに。
世界遺産である白神のブナ林を満喫できなかったのは非常に残念でしたが、その手前にあった建設中の津軽ダムのバッチャープラント (コンクリートを作る設備) [参照] を見て興奮してきたので、モトはとれたと思いたいところです。
次なるお目当ては、8/1から開催される弘前ねぷた祭り。
20年ほど前に見たきりなので、本当に久しぶりです。
青森ねぶたと混同されることも多いですが、「ねぶた」が立体的に造形された灯篭 (3Dサーフィスモデルの先駆け!?) なのに対し、「ねぷた」は扇形の平たい灯篭にねぷた絵 [参考] と呼ばれる合戦絵をのせたものが主体であるところが大きく異なります。
(ねぷたの中にも、立体的に作られた「組みねぷた」はありますが。)
このねぷたも、途中から雨が降り出してしまい、途中で中止となってしまったのが返す返すも残念でした。
弘前は、日本の他の地方とは独特の文化・風土を持っており、東北地方 (宮城・福島) に住んでいる私から見ても、非常に強い異国情緒を感じさせる街です。
皆様も一度はこのエキゾチック都市・弘前を訪れてみてはいかがでしょうか。
- 写真左: アップルスナック (ジョナゴールド)
- http://www.net24.ne.jp/~applesnack/f-40.html#syohin
- 写真右: おきな屋『 紅玉天』
- http://www.a-okinaya.co.jp/products_06.html
以前に書いた知識の集め方 という記事で、「効率的な学習」について意見めいたことを書きましたが、今回はその続きというか補足です。
私がプログラミングを始めたのは10歳くらいのこと。
当時は、何か分からないことに遭遇したら、それに関する情報を集めるだけでも一苦労でした。
なにせ、インターネット接続環境がありませんでしたし、Google もまだ存在してはいなかったのですから。
身近にプログラミングに詳しい人もいなかったため、人に訊くことも能わず。
そのため、一つの問題への取り組みが数ヶ月、時には一年以上に及ぶことも珍しくはありませんでした。
情報源となるのはもっぱら書籍・雑誌ですが、その量や種類も、現在のように充実してはいなかった時代。
(その頃、「コンピュータ」というのはまだまだマイナな趣味だったのです。)
故に、「学習」は常に試行錯誤となり、全然見当違いの方向へ考えを進めては引き返すといったことを繰り返していました。
今思い返してみると、なんと非効率的なやり方。
現在のインターネットでの情報収集を利用した学習と比べると、両者のスピードには徒歩と自動車ほどの隔たりがあるでしょう。
しかしながら、この「歩く速さの学習」の経験の有無は、エンジニアとしての力量に決定的な差を与えるのではないかと考えています。
歩いて目的地へ向かっているときは、好きな時に立ち止まったり、気になる路地を見つけたときにひょいとそこに入ってみることができます。
そうやって、面白そうなお店を見つけたり、道の繋がりに気付いたりした経験のある人も多いのではないでしょうか。
学習の場合もそれと同じで、最短経路からの「横枝」を拡げていくことで、これまで無関係だと思われていた事柄がリンクし、知識に幅が生まれます。
自分のいる場所を俯瞰できるようになり、頭の中に「地図」があがっていく感覚ですね。
ところが、移動 (学習) の速度があがるにつれ、この「横枝」を拡げるチャンスは少なくなっていきます。
自動車で移動する際は路地に入れませんし、列車で移動しているときは駅以外の場所で降りることはできません。
その結果、知識からは広がりが失われ、「地図」というよりは一本の線で綴られた「路線図」のようなものになってしまいます。
ですが、かく言う私も、社会人になってからは、この「効率的」なやり方が学習の軸に……。
やはり、仕事を滞りなく回そうとすると、徒歩での移動には限界があるので、どうしても自動車に頼らざるをえません。
でも、それではエンジニアとしての可能性が先細りになってしまうので、プライベートで徒歩型の学習をして、仕事の方にフィードバックするよう心掛けています。
皆さん、ビデオゲーム (TVゲーム) はお好きでしょうか。
私はかなり好きな方で、休みの日などは一日中やっていることもあったり。
さて、「ビデオゲーム」というと、どうしても格の低い趣味と見なされがちですが、実際にいろいろなソフトをプレイしてみると、いろいろと学ぶ・考えるべき点が見つかります。
特に面白いのがユーザインターフェイス (UI) における工夫です。
ゲームでは「アイテムの選択」や「データの記録」などを何度も繰り返し行うため、これらの操作でユーザにストレスを感じさせるような設計は極力避けなければなりません。
そのためには、項目の配置, 画面遷移, カーソルの移動の仕方, 処理時間の短縮などあらゆる箇所に気を配る必要が出てきます。
例えば、メニューを開くとウィンドウが画面外からスライドインしてくる場合を考えてみましょう。
注意深く設計・実装されたソフトでは、ウィンドウが定位置に止まる前であっても、ユーザはその上でカーソルを動かすことができるようになっています。
逆に、こうした工夫がないゲームでは、ユーザはメニューを開くたびに1～2秒程度操作を中断しなければなりません。
その程度の待ち時間はたいしたことがないように思えるかも知れませんが、ゲーム中にメニューを開く頻度を考えると、プレイ時間全体に対する損失の割合はかなり大きなものになります。
他にも、データの読み込みをバックグラウンドで処理することでシーン切り替えの際のロード時間を短縮する手法など、ユーザに対する「気配り」が見え隠れする部分が多々あります。
ゲームとして長く遊ばれるかどうかは、「ストーリー」や「映像の美しさ」や「システムの斬新さ」だけでなく、こうした開発者の「気配り」の深さ・細かさによって決まることが多いようです。
こうしたユーザのストレスを低減する様々な工夫は、ゲーム以外のソフトウェアやウェブサイトを作る際にも応用できます。
「良いデザイン」に行き詰ったときは、気分転換もかねてビデオゲームをやってみてはいかがでしょうか。
毎週木曜日に開かれる全体ミーティングでは、スタッフが持ち回りで「勉強会」という名目でプレゼンテーションを行っています。
発表の内容はバラエティに富んでおり、「お菓子の作り方」から「インターネットの仕組み」まで様々。
自分が普段触れる機会のない知見に触れることができるイベントであるため、毎週とても楽しみにしています。
その一方で、発表終了後にスタッフが一言ずつ述べるコメントの中で、特に学生からよく出てくる、次のような意見に私は小さな引っかかりを覚えています。
それが何に、どのように役立つかまで話してもらえれば、もっと興味がもてます。
私がこれのどこに引っかかっているのか分かって頂けるでしょうか。
学校や職場で多少なりとも他人にものを教えること、すなわち教育に携わっている方にはピンとくるものがあるかもしれません。
上記の考え方の根元にはおそらく、「学んだことは (そのすべてを) 何かの役に立てたい」という気持ちがあるのでしょう。
そして、その気持ちはともすれば「役に立たない (役に立つという確証がない) ことは学びたくない」という考え方にシフトします。
そこからさらに進んで、話の過程をすっとばして、「結論だけを聞かせて欲しい」という態度に繋がることも少なくありません。
そのような姿勢が、実利を重視した、ドライで合理的な姿勢だと評価されることも少なくないようですが、私はそうは考えません。
何故なら、「考える力」を養うには、多くのモノの見方・考え方に触れる経験が欠かせないからです。
見聞きしたものは、たとえ自分が目的とする事柄に直接の関係はなくとも、その人が何かを考えるための材料としてストックされていくもの。
そして、そうした材料が何かに使えることに「気付く」ことによって初めて、経験が知識として自分の一部になるわけです。
それを集める手間を惜しみ、最短距離で目的とする知見まで一足飛びに到達したとしても、そこからの自分の考えを発展させることは難しいでしょう。
なにせ、材料の手持ちがないのですから。
では何故学生はこうした考え方をするようになってしまうのでしょうか。
個人的に、二つほど思い当たる事柄があります。
私がよく閲覧するサイトのひとつに、高木浩光＠自宅の日記があります。
(この業界の人の間ではかなりの有名ドコロですね。)
セキュリティ・プライバシに関する記事が多いのですが、その特徴はなんといっても、未熟・杜撰な技術や論評に対する辛辣な批判・批評。
「バカは死ねと言いたい。」
「儲かるんだからしょうがない。IT弱者から搾取して。」など、なかなかに過激なフレーズが随所に見られます。
筆者である高木氏は斯様に、罵倒ともいえるほど強い調子で批判を展開しますが、ただ声を荒げているだけではありません。
記事の中で、批判の対象と範囲および理由・根拠を明確に示し、必要に応じて技術的・社会的な背景についても詳細に解説してくれています。
同じ対象を批判している別の論者に対して、「その批判は要点がズレている」という旨の批判をするのがしばしば見られるのも、議論の筋道を重視するが故でしょう。
以下に、私が読んで参考になった記事をいくつかあげておきます。
- 日本のインターネットが終了する日
- 携帯電話の個体識別番号 (「かんたんログイン」などに使用される) の送信問題について。
- オレオレ警告の無視が危険なこれだけの理由
- SSL証明書の不適切な運用がもたらす弊害について。
- プログラミング解説書籍の脆弱性をどうするか
- デタラメなプログラミング技術解説が出版によって広まっている件について。
このような、要点を的確に押さえた切れ味ある批判は、私が範とするところでもあります。
プログラミングは非常に専門的な作業であるため、社内の人間であっても、ある人の仕事の内容を正確に理解・評価することは容易ではありません。
そのため、プログラマに対する評価はその成果物、すなわち完成したプログラムの動作や、それができるまでの期間といったものを基準に行われることが多くなります。
そうなると必然的に、指定された要件を満たして「とにかく動くプログラム」を「短い期間」で納品できるプログラマが高い評価を受けることになります。
しかし、動作が同じだからといって、プログラムの「質」が同じだと考えるのは大きな誤り。
何故なら、プログラムの質の良し悪しは、動いているときではなく、何らかの理由でそれが動かなくなったときにこそ問われるものだからです。
