flint>flint blog
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »

抜け落ちるもの

ソフトウェア開発の工程は大きく分けて、要件定義, 設計, コーディングの三段階からなります。 (実際には、その後にテスト, デバッグなどの段階が続きますし、これらも明確に区別されるわけではなく、互いに絡み合っている部分もありますが、「作る過程」の説明としては大きく外してはいないはず。) これらの段階においては、「何を」「どのように」作るかということが順次決定されていきます。 そこで決められた事項は、仕様書設計図として文書化され、開発に携わるメンバの間で共有されることになるわけですが、この共有の際に零れ落ちてしまう、あるいは、作る過程では確かにあったのに、完成品からは抜け落ちてしまうものがあります。

例えば、データベースの仕様書には、各テーブルに属するカラムの名前, データ型や、それらが満たすべき制約については、逐一正確に書き込まれます。 しかし、それらの事項がどのような理由・経緯によって決定されたのかということについては、ドキュメントは何も教えてはくれません。 書きあがったプログラムを眺めても、例えば関数名や引数の並びについて、何故そのようになったのか、ということは分からないようになっているのが一般的です。 それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

けれども、ソフトウェア開発の知識・技術の本質とは、こうした「作る過程」における「瑣末なもの」の中にこそある、と私は考えています。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

技術と魔法のギャップ

テクノロジーの進歩についての語りにおいて、よく引用されるフレーズに「クラークの三法則」の第三法則があります。

Any sufficiently advanced technology is indistinguishable from magic.
(高度に発達した技術は魔法と区別がつかない。)

近年の映像・音声認識技術の向上や、様々な入力デバイス (タッチパネル, リモートコントローラなど) の普及によって、エンドユーザ層がこれまで抱いていた「コンピュータはとっつきにくいもの」という認識は急速に緩和されているように観察されます。 こうした社会の流れの中にあって、「技術」はその原理や本質をブラックボックスの内部に隠蔽していき、魔法としての装いを強めてきました。 世の中に魔法が満ち溢れ、誰もそれを不思議とは思わない社会は、もはやSFでもファンタジーでもなく、実現のものとなりつつあると言えるでしょう。

とは云え、現実には魔法などというものが存在しないということは、皆様もご存知の通り。 あらゆるモノゴトの振る舞いが例外なく (私たち人間さえも) 物理法則によって支配されている以上、どんな魔法にも必ずタネと仕掛けがあります。 「魔法に見えること」と「魔法であること」は、決してイコールではありません。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Words describe you again, and again

近年の Facebook, Twitter に代表される SNS (Social Networking Service) の勢力拡大には目覚しいものがありますね。 周囲を見渡してみても、これらのサービスのアカウントを保有していない人を探す方が大変なほど。 以前、ブログによってインターネット上の「発信者」の数が激増したという話 (参照: 議論の仕方) をしましたが、SNSによってこの増加に拍車が掛かったように思われます。

ところで、これほど多くの人々が情報を発信するようになったことで、インターネットがどう変わったかと改めて考えてみると、私が期待していたのとはだいぶ違った方向へ進んでいるように思えます。 と言うのは、その内容には特に意味のない、「発信者」同士の関係を表すためのだけの情報が、ネット上で交換されるデータの大部分を占めているように観察されるからです。 特にその傾向が強いのが Twitter で、リツイート (Retweet) と呼ばれる機能により、他のユーザの投稿内容を自分の投稿に引用するということが頻繁に行われています。 これは、ユーザの関心が「何を語るか」「何が語られているか」よりも、「誰が言ったか」「誰がそれを読んだか」に向けられていることを示すものでしょう。 もっとも、それがソーシャル・ネットワークの本質であるわけなのですが、個人的には色々な人の多様な考え・意見が読めるようになると期待していたので、ちょっと残念に感じてしまうのかもしれません。

ところで、この頃のネットでは引用が多くなったから、自分の意見を語るまえに、どこかから引用をしようとする。 自分の意見を持たない者も増えた。 「誰某がこんなこと言っているらしいけれど、どうよ?」 「ああ、それなら、こんなこと言っていた奴もいるみたいだよ」 というリンク先を交換するだけで意見交換をしていない。 しかも、原典まで辿らず、伝聞だけの「噂話」に終始する。 こういった情報のシェアが、「親切」の一種だという価値観が生まれたように見えるが、たぶん、昔からあったことだろう。

実は、ネット上に限らず、現実空間における人との係わり合いにおいてもこうした傾向を感じています。 人間は普通、課題や仕事に取り組んだり、本を読んだりすれば、それらに対して何らかの感想や、自分なりの意見を持つのではないでしょうか。 しかし、そうした意見や感想を持たない、あるいはそれを自分の言葉で表現しない・できない人が非常に多いのです。 見たもの・やったことを淡々と説明したり、それに関連するこんな記事を読んだという 「事実」の説明はできるのですが、「それについてあなたはどう感じた・考えたか」を尋ねられると、途端に言葉に詰まってしまうというケースが頻繁に観察されます。

意外に思われるかも知れませんが、特にITの分野では、仕事をする上で自分なりの考え・意見を持つこと、それを表現することは非常に重要な意味を持ちます。 何故ならば、客観的な事実の記録や、外部の情報への接続 (リンク) などの行為は、コンピュータによってほぼ完全に賄われてしまうからです。(参照: 思考の価値) 人間を遥かに凌ぐ記憶精度・容量と演算速度をもつコンピュータによって稼動するシステムの中にあって、それでも人間をそこで働かせる必要があるのは、こうした人間が持つ経験や勘 (と呼ばれるもの) や、そこから生まれるデータ化できないノウハウ、即ち、個人的な考えと判断が不可欠だからに他なりません。 「主観的なものの見方は、ビジネスにおいて害悪である」という考え方は、必ずしも正しくないのです。

そしてまた、そうした考え・意見を、自分の言葉で、他人に分かるように伝えるということも大切。 これをやらずにいると、知らず知らずのうちに「考えること」自体ができなくなってしまいます。 「いざとなればできる」なんて思っていても、普段からある程度の運動をしていないと、実際に走ってみたときに想像以上に身体が鈍っていてびっくりするのに似ているかも知れません。 体重計を気にするのも結構ですが、脳メタボにもご用心、です。

成田 (書くことは考えること)
このエントリーをはてなブックマークに追加

関数分けの効用

通常、プログラムを書くときは、処理をただ順番に書き下すのではなく、いくつかの「関数」に分割します。 これによって各ステップの処理が部品化され、再利用が可能になるわけですが、関数分けの効用はそれだけに留まりません。 たとえ、たった一度しか実行されない処理でも、これらを上手く関数化し、本体から分離することで、プログラムの可読性・保守性を向上させることができます。

例えば、以下のようなフォームからデータを受け取るプログラムを考えてみましょう。

名称
所在地
-
Tel
Fax
▲ソースを隠す
<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>
>> 続きを読む
成田
このエントリーをはてなブックマークに追加

猪苗代第一発電所

azure water and blue sky

天気がとても良かったので、磐梯町にある「猪苗代第一発電所」へ。 今回は、以前「猪苗代第二発電所」を訪れたときとは逆に、猪苗代湖側から膳棚山を経由して磐梯町駅方面へ抜けてみました。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

柵の倒し方

安全なウェブサイトの作り方 by IPA

コンピュータ・インターネットの世界は日進月歩。 これまで誰も予想しなかった技術・サービスが、あっという間に世界中に広がり、常識が一日ごとに塗り替えられていきます。 そうした環境においては、常に自己を革新することが求められ、新しいことに挑戦する勇気を持たぬものは消えていく運命にある......といったような認識を持っていらっしゃる方も多いのではないでしょうか。 そうした見方は概ね正しいと思います。 挑戦と革新はいつの世も進歩と発展の原動力であったことは間違いなく、またこれからもそうであることでしょう。

その一方で、プログラマの間でよく知られる格言に、

フェンスが建てられた理由が分からないうちは、それを倒してはならない。
Don't ever take a fence down until you know why it was put up.

というものがあります。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Hirosaki Exotica

先週の金曜から夏休みを頂いて、青森県弘前市へ行ってきました。

まずは白神山地を観にいったのですが、折からの豪雨で川は増水し、登山道も荒れていたため、最初のチェックポイント (?) である「暗門滝」で引き返すことに。 世界遺産である白神のブナ林を満喫できなかったのは非常に残念でしたが、その手前にあった建設中の津軽ダムのバッチャープラント (コンクリートを作る設備) [参照] を見て興奮してきたので、モトはとれたと思いたいところです。

次なるお目当ては、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 もまだ存在してはいなかったのですから。 身近にプログラミングに詳しい人もいなかったため、人に訊くことも能わず。 そのため、一つの問題への取り組みが数ヶ月、時には一年以上に及ぶことも珍しくはありませんでした。 情報源となるのはもっぱら書籍・雑誌ですが、その量や種類も、現在のように充実してはいなかった時代。 (その頃、「コンピュータ」というのはまだまだマイナな趣味だったのです。) 故に、「学習」は常に試行錯誤となり、全然見当違いの方向へ考えを進めては引き返すといったことを繰り返していました。

今思い返してみると、なんと非効率的なやり方。 現在のインターネットでの情報収集を利用した学習と比べると、両者のスピードには徒歩と自動車ほどの隔たりがあるでしょう。 しかしながら、この「歩く速さの学習」の経験の有無は、エンジニアとしての力量に決定的な差を与えるのではないかと考えています。

歩いて目的地へ向かっているときは、好きな時に立ち止まったり、気になる路地を見つけたときにひょいとそこに入ってみることができます。 そうやって、面白そうなお店を見つけたり、道の繋がりに気付いたりした経験のある人も多いのではないでしょうか。 学習の場合もそれと同じで、最短経路からの「横枝」を拡げていくことで、これまで無関係だと思われていた事柄がリンクし、知識に幅が生まれます。 自分のいる場所を俯瞰できるようになり、頭の中に「地図」があがっていく感覚ですね。

ところが、移動 (学習) の速度があがるにつれ、この「横枝」を拡げるチャンスは少なくなっていきます。 自動車で移動する際は路地に入れませんし、列車で移動しているときは駅以外の場所で降りることはできません。 その結果、知識からは広がりが失われ、「地図」というよりは一本の線で綴られた「路線図」のようなものになってしまいます。

ですが、かく言う私も、社会人になってからは、この「効率的」なやり方が学習の軸に……。 やはり、仕事を滞りなく回そうとすると、徒歩での移動には限界があるので、どうしても自動車に頼らざるをえません。 でも、それではエンジニアとしての可能性が先細りになってしまうので、プライベートで徒歩型の学習をして、仕事の方にフィードバックするよう心掛けています。

成田 (道草大好き)
このエントリーをはてなブックマークに追加

ビデオゲームのUI

皆さん、ビデオゲーム (TVゲーム) はお好きでしょうか。 私はかなり好きな方で、休みの日などは一日中やっていることもあったり。 さて、「ビデオゲーム」というと、どうしても格の低い趣味と見なされがちですが、実際にいろいろなソフトをプレイしてみると、いろいろと学ぶ・考えるべき点が見つかります。

特に面白いのがユーザインターフェイス (UI) における工夫です。 ゲームでは「アイテムの選択」や「データの記録」などを何度も繰り返し行うため、これらの操作でユーザにストレスを感じさせるような設計は極力避けなければなりません。 そのためには、項目の配置, 画面遷移, カーソルの移動の仕方, 処理時間の短縮などあらゆる箇所に気を配る必要が出てきます。

例えば、メニューを開くとウィンドウが画面外からスライドインしてくる場合を考えてみましょう。 注意深く設計・実装されたソフトでは、ウィンドウが定位置に止まる前であっても、ユーザはその上でカーソルを動かすことができるようになっています。 逆に、こうした工夫がないゲームでは、ユーザはメニューを開くたびに1~2秒程度操作を中断しなければなりません。 その程度の待ち時間はたいしたことがないように思えるかも知れませんが、ゲーム中にメニューを開く頻度を考えると、プレイ時間全体に対する損失の割合はかなり大きなものになります。

他にも、データの読み込みをバックグラウンドで処理することでシーン切り替えの際のロード時間を短縮する手法など、ユーザに対する「気配り」が見え隠れする部分が多々あります。 ゲームとして長く遊ばれるかどうかは、「ストーリー」や「映像の美しさ」や「システムの斬新さ」だけでなく、こうした開発者の「気配り」の深さ・細かさによって決まることが多いようです。

こうしたユーザのストレスを低減する様々な工夫は、ゲーム以外のソフトウェアやウェブサイトを作る際にも応用できます。 「良いデザイン」に行き詰ったときは、気分転換もかねてビデオゲームをやってみてはいかがでしょうか。

成田 (バイオハザードで学ぶ英会話)
このエントリーをはてなブックマークに追加

知識の集め方

毎週木曜日に開かれる全体ミーティングでは、スタッフが持ち回りで「勉強会」という名目でプレゼンテーションを行っています。 発表の内容はバラエティに富んでおり、「お菓子の作り方」から「インターネットの仕組み」まで様々。 自分が普段触れる機会のない知見に触れることができるイベントであるため、毎週とても楽しみにしています。 その一方で、発表終了後にスタッフが一言ずつ述べるコメントの中で、特に学生からよく出てくる、次のような意見に私は小さな引っかかりを覚えています。

それが何に、どのように役立つかまで話してもらえれば、もっと興味がもてます。

私がこれのどこに引っかかっているのか分かって頂けるでしょうか。 学校や職場で多少なりとも他人にものを教えること、すなわち教育に携わっている方にはピンとくるものがあるかもしれません。

上記の考え方の根元にはおそらく、「学んだことは (そのすべてを) 何かの役に立てたい」という気持ちがあるのでしょう。 そして、その気持ちはともすれば「役に立たない (役に立つという確証がない) ことは学びたくない」という考え方にシフトします。 そこからさらに進んで、話の過程をすっとばして、「結論だけを聞かせて欲しい」という態度に繋がることも少なくありません。

そのような姿勢が、実利を重視した、ドライで合理的な姿勢だと評価されることも少なくないようですが、私はそうは考えません。 何故なら、「考える力」を養うには、多くのモノの見方・考え方に触れる経験が欠かせないからです。 見聞きしたものは、たとえ自分が目的とする事柄に直接の関係はなくとも、その人が何かを考えるための材料としてストックされていくもの。 そして、そうした材料が何かに使えることに「気付く」ことによって初めて、経験が知識として自分の一部になるわけです。 それを集める手間を惜しみ、最短距離で目的とする知見まで一足飛びに到達したとしても、そこからの自分の考えを発展させることは難しいでしょう。 なにせ、材料の手持ちがないのですから。

では何故学生はこうした考え方をするようになってしまうのでしょうか。 個人的に、二つほど思い当たる事柄があります。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »