独立前に書いたブログ記事に手直しを入れてアップロードしたものへの閲覧者及びクローラ誘導のためのエントリを作ってみることに。
今回取り上げるのは「学習」をテーマにした記事です。
プログラマに限らず、技術者は絶えず新たな技術を習得し続けることが要求される職業。
同時に、必要に応じてそれを後進に教え伝えていくことも、避けて通ることのできないものとなります。
そうした学ぶ・教えるという行為は、業界において色々と見落とされている要素があるように思えたため、そのあたりについて語ってみました。
確かに、コンピュータは、ここ20年ほどで台頭してきた新しいジャンルであり、(最近はその速度が緩んできてはいるものの、) 他の分野と比べて格段に速い進歩・革新が見られます。
しかし、そんな現在のコンピュータ技術もまた、これまで情報技術に携わってきた人々の創意工夫の積み重ねを基礎として成り立っており、何ができて、何ができないかといったことは、それなりの精度で確かめられています。
そうして積み上げられてきた常識・定石を覆すような画期的な発明を行うことは、容易なことではありません。
少なくとも「ちょっとした」思いつきや工夫でなんとかなるほど軽い話ではないわけです。
(もしそれでなんとかなるのであれば、先人たちはどれだけマヌケだったのかということになってしまいます。)
結局のところ、「裏技」を求める人々の心理の裏には、苦労せずに成功したい、というムシのよい考えがあるのではないでしょうか。
「プログラムを書けるようになりたいが、地道で退屈な勉強はしたくない。」
「画期的で高品質なサービスを作りたいが、研究開発や人材教育などのコストはかけたくない。」
そういった願望を持つ人々にとって、この手の「裏技」が非常に魅力的に思えることは想像に難くありません。
しかし、そうした「裏技」の99.9%は「スカ」であることは心に留めておくべきでしょう。
今日の高度に発達した技術に取り囲まれた社会にあって、学生たちの目には、IT業界で活躍するために必要な技能の習得が果ての見えない長く険しい道と映っているようです。
そうした事情も考えあわせれば、「すぐに役立つ」知識・技術に飛びつき、それ以外のことに注意を払わなくなるのもむべなるかな、と思えます。
しかしながら、そのような「効率的な学習」の背後には、「何が役に立ち、何が役に立たないか、予め判断できる」という思い上がりが見え隠れします。
先にも述べたように、見聞きし、触れ、考えたことは、人生において直接何かの役には立たずとも、その人がものを考えるための材料となります。
その材料を学びの過程で拾い集めることなく目的地にたどりついたとして、そこでいったい何ができるでしょうか。
歩いて目的地へ向かっているときは、好きな時に立ち止まったり、気になる路地を見つけたときにひょいとそこに入ってみることができます。
そうやって、面白そうなお店を見つけたり、道の繋がりに気付いたりした経験のある人も多いのではないでしょうか。
学習の場合もそれと同じで、最短経路からの「横枝」を拡げていくことで、これまで無関係だと思われていた事柄がリンクし、知識に幅が生まれます。
自分のいる場所を俯瞰できるようになり、頭の中に「地図」があがっていく感覚ですね。
ところが、移動 (学習) の速度があがるにつれ、この「横枝」を拡げるチャンスは少なくなっていきます。
自動車で移動する際は路地に入れませんし、列車で移動しているときは駅以外の場所で降りることはできません。
その結果、知識からは広がりが失われ、「地図」というよりは一本の線で綴られた「路線図」のようなものになってしまいます。
例えば、建築の現場では、高所作業のために足場を組みますが、この足場は建物の完成時には取り除かれるため、最終的にはそこに残るものではありません。
しかし、この足場をいかに素早く、安定したものを組むか、また、楽に撤収できるようにするかというところに、技術の本質があるのです。
足場は、その上で行われる作業のベースであり、その良し悪しが工事の期間や安全性を大きく左右する要素となることは想像に難くないでしょう。
また、建物が完成してすぐには気付かないかもしれませんが、全体が補修・拡張などの作業を想定して設計されているかどうかは、長期的に見た場合に、その建築物の品質に大きな影響を与えます。
ソフトウェアもこれと同じで、ロジックの共通化、インターフェイスの整備などにより、できあがった「もの」をちょっと眺めただけでは分からない、しかし、決定的な品質の差が生じます。
(参照: 拙速を尊ばない)
その差を生み出すのは、一言で表すならば、作られるに際してどの程度「作りやすいカタチ」「壊れにくいカタチ」「直しやすいカタチ」が意識されたか。
しかし、残念なことに、この「作るときの意識 (あるいは思考, 目線)」はドキュメントにも完成品にも残らず、常に抜け落ちてしまうもののようなのです。
成田 (新しいエントリを書く気力がないので埋め草......じゃないよ！)
山梨市にある琴川ダムに行ってきました。
甲府から向かう場合は、甲府山梨道路終点の万力ランプで降りて雁坂みちを通り、牧丘トンネルを抜けたところで左 (西) に折れ、県道219号 (柳平塩山線) に入るのが良いようです。
(諸事情によってここ2日の間に数往復した経験より。)
ダム湖 (乙女湖) の湖畔には駐車場付きの公園があり、散策するには良い場所。
近くにある管理事務所に一般利用が可能なトイレが併設されているという利便性もあってか、釣り人にも人気のスポットのようです。
甲府市へ引っ越して来てから、一年。
取引先の皆様や、個人的にお付き合い頂いている地域の皆様には大変お世話になりました。
今後ともよろしくお願い致します。
思い返してみれば、この一年間色々なことがありました。
際立った変化として挙げられるのは、これまでと全く異なる環境での仕事故に、習得しなければならない技術が次々と出てきたことでしょうか。
当時エントリで紹介した Asterisk, Ruby on Rails や Android に始まり、MySQL, PHP と続き、現在は Tomcat や ActionScript に取り組んでいます。
とにかく (私にとって) 目新しい言語やフレームワークとの遭遇の連続で、退屈する暇がありません。
また、仕事でご一緒させて頂いている常駐先エンジニアの皆さんとの情報・意見交換は非常に大きな刺激となっています。
余談ですが、PHPについては、その言語仕様のあまりの腐りっぷりに幾度となく苦しめられてたので、近いうちにその駄目さ加減を指弾するエントリを書く予定でいますので、お楽しみに...。
そんなこんなで、扱うことのできる言語やフレームワークも増え、更にデキるようになりましたので、ソフトウェア開発のための人員確保に悩んでいるようであれば、お気軽に声を掛けて頂きたく存じます。
6月に入りました。
甲府に来てから、そろそろ一年になります。
私はじりじりと上昇していく気温と湿度に、昨年経験した悪夢の如き蒸し暑い日々の再来を確信し恐れ慄いておりますが、皆様におかれましてはいかがお過ごしでしょうか。
プログラマといえど、身体が何より重要な資本であることは他の職種と変わりはありません。
まして私のような自営業では、夏バテなどで倒れたりすれば、その時点で収入がパッタリと途絶えることに。
従って、自身の体調・健康の維持管理に努めることは、仕事の一部であり、義務であるとも言えるでしょう。
そんなわけで、今回の記事では、暑くて食欲がイマイチなときでも比較的容易に栄養を取ることができるスープの作り方を紹介しようと思います。
以前の記事 (理想と現実) において、初めての確定申告を無事済ませたと書きましたが、実を言うとあまり「無事」ではありませんでした。
というのも、独立してからしばらくの間は忙しさにかまけて帳簿付けをサボっていたためです。
領収書・レシートの類も取っておいたつもりだったのですが、後から集めてみるとあちこち抜けていたり。
そんなこんなで、申告期限間際に大慌ててで帳簿を作成するハメに。
担当して頂いた税理士さんにとっても、忙しい時期に面倒この上ないクライアントであったに違いありません。
帳簿は OpenOffice.org Calc (表計算) で作成したのですが、とにかく集計とその確認が大変な手間です。
「おかしいな。この1,350円の余りはどっから出てきたんだ？」なんてことをやっていたので、三月上旬は寝不足気味で少しフラフラしていました。
さて、ここからがプログラマの悪いクセ。
「来期は帳簿を管理するシステムを作って確定申告をスマートにこなしてしまおう！」などと思い立ち、これを行うウェブアプリケーションの開発を始めてしまいました。
さいわいにして、簿記については以前手掛けた業務で一通りの勉強はしてあった (参照: Expert of Everything (2)) ので、DB設計などはすんなりとできましたが、難しいのはやはりユーザインターフェイスの設計です。
みなさんは、今ネット上で話題となっている「武雄市図書館問題」をご存知でしょうか。
コトの発端は、佐賀県武雄市が行った、図書館運営民間委託構想の発表です。
TSUTAYA (ツタヤ) を運営するカルチュア・コンビニエンス・クラブ (CCC) と佐賀県武雄市は4日、武雄市図書館の企画・運営に関する提携で基本合意したと発表した。
CCCが指定管理者として来年4月から図書館を運営し、開館時間を延長するなどサービスの向上を図る。
武雄市図書館の運営費は年間約1億4500万円かかっているが、同市はCCCへの委託で1割程度減らせると見込む。
この日都内で会見した樋渡啓祐 (ひわたし・けいすけ) 市長は「サービスを向上しつつも経費を下げるために、民間のノウハウを提供してもらう」と述べた。
( 中略 )
図書館の利用カードはCCCのポイントカード「Tカード」へ切り替える。
Tカードは若い世代に普及しており、図書館を使わない人が多いとみられる若年層を呼び込む狙いがある。
本を借りた人へのポイント付与も検討する。
この構想を主導する樋渡市長は、昨年8月に武雄市のウェブサイトをFacebookに全面移行し、「Facebook 市長」として有名になった人物。
(参考: 「市長がはまっている」佐賀県武雄市、市のページをFacebookに完全移行へ - ITmedia ニュース)
その他にも「日本Twitter学会」なるものを立ち上げ、その会長を務めるなど、SNSの活用にひとかたならぬ熱意をもっているようです。
この図書館民間委託構想について、産総研のセキュリティ研究者である高木浩光氏によってプライバシー保護上発生しうる問題の指摘および懸念の表明 (詳細は後述) がなされました。
しかし、これに対して樋渡市長は常識では考えられない不誠実な対応を行い、現時点においてもそれは継続されています。
これまでの経緯をまとめることが本エントリの趣旨ではないので、ご存知でない方は以下のページをご覧ください。
当ブログは、私の事業の公式であることもあり、普段はこうした特定・個別の社会問題については言及することを避けています。
しかし、今回の一件は私が独立するに至った理由と、この事業を行っている動機に密接に関連するものであるため、今回のエントリではこれについて自分の見解を述べる、より正確には、この図書館民営化構想の推進側の対応について、以下の三点から批判を行うことを決意しました。
- 議論における不誠実さ
- 指導者としての無能
- 無責任な「市民」
追記 [2012/05/13 7:30]
以下、他の視点からの批判・指摘などを紹介。
- 動機が（自称）善だから何やってもOKなんです（キリッ） - カレーなる辛口Javaな転職日記
- http://d.hatena.ne.jp/JavaBlack/20120507/p1
- 覆水は盆に返せるのか？ - がるの健忘録
- http://d.hatena.ne.jp/gallu/20120505/p1
- プライバシー侵害を懸念する際に「個人情報保護法」でいう個人情報でないから問題ないと主張する組織が相次いでいるのが問題 - 発声練習
- http://d.hatena.ne.jp/next49/20120510/p1
- もし現役首長が「知り合いのスーパーハカーが黙ってないぞ」と言いだしたら - conflict error
- http://webkit.seesaa.net/article/269469626.html
三月も終わり、新年度に突入。
確定申告もなんとか終えることができました。
今月からはまた新しい仕事が始まります。
独立してからの9ヶ月間、会社員でいた頃よりも幾分長く、「自分は今何をするべきか」を考えて過ごしてきたような気がします。
今後の展望、仕事と休息のバランス、独自サービスの構想と開発、などなど。
自分の代わりに考えたり決断してくれる人のいない環境にあるが故に、否応なくそうしたことに頭を回すことになるようです。
己の在り方や為すべきことについて考えるとき、私はいつも「理想」と「現実」という二つの軸に沿って問題を整理します。
やりたいことは何で、現状はどうなっているだろう？
目標に近づくにはどのようなアプローチを取るのが良い？
将来的にトラブルを招きそうな事案を抱えてはいないか？
そうやって、理想と現実のギャップをできるだけ正確に把握し、これを埋めるべく計画を立て、然るべき行動を取るわけです。
こんな風に言葉にしてみると随分とご立派な感じがしますが、これは社会人であれば誰もが行っていることのはず。
取立てて語るべきことではありません。
とは言え、いざこれを実践に移そうとすると、これがなかなかに難しいもの。
その原因は何なのかと考えてみるに、「理想」と「現実」の狭間を往くのに必要な「バランス感覚」の妙にあるような気がしています。
「料理」は、私の数少ない趣味の一つ。
仕事で遅くなることもあって、ずっと自炊というわけにはいきませんが、休日や外食に飽きたときなどに、台所に立っています。
あれこれと忙しくしている間はそちらに意識が集中するため、気分転換・ストレス解消にはもってこいの作業です。
ところで、「料理」というと、一般的には「女性らしい」「可愛らしい」あるいは「優美」というイメージがあるようで、これを私のようなムサい男が趣味にしていると知ると、失笑や揶揄を含んだ反応を返してくる人も少なくありません。
「男らしくない」「女々しい」と受け取られているらしいのです。
確かに、私が料理を教わったのは主に母からですが、実際に料理に取り組んでみると、これが他にはちょっと類をみないほど「男らしい」仕事であることが分かるでしょう。
刃物 (包丁) を振るって皮を剥ぎ、肉を切り、骨を絶つ。
ガスの炎を操り、高温の油の飛沫に耐えながら、食材を加工する。
少しばかり盛った表現をするなら「火と鉄の世界」。
世間一般に言われる「男らしい」趣味、例えばクルマの運転やギターの演奏などと比較してみても、遜色ない程度には勇気と技量の要る行為ではないかと思うのですが......。
さらにここから派生して、調理の主要な道具である包丁の研ぎとなれば、まさに「男の仕事」という感じがするのではないでしょうか。
刃物の研ぎ方は父から教わった (というか教え込まれた) のですが、そこでも様々な知識を経験として得ることができました。
例えば、「切れ味」というのは、刃の断面の楔型を鋭くすることよりも、むしろ刃に沿った微妙な凹凸による部分が大きいこと、鉄が意外に「柔らかい」ことなど、色々な発見があります。
また、客先に常駐して仕事をしている私にとって、ワイシャツの皺伸ばしは日々欠かすことのできない作業。
背広は自分で洗うことが難しいのでクリーニングに出していますが、ワイシャツの洗濯と、アイロン掛けは自分で行っています。
このアイロン掛けもまた、「灼けた鉄」を繰って為されるもので、油断をすると衣類を焦がしてしまったり、自身が火傷を負ったりするなかなかに危険なもの。
私が使用しているのは母から譲り受けた相当に古いアイロン (松下電器製: キューティNI-111) で、温度調節不可、過熱防止機構なし、スチームなしというシロモノなので、最近のものと比べて取り扱いに注意を要します。
余談ですが、アイロンをかけているときって、無心の境地に入ってしまいますね。
個人的にこの状態を「アイロン瞑想 (ironing meditation)」と呼んでいたり。
プログラミングに集中するとやたらと空腹を感じることから思い付いた「プログラミング痩身」とあわせて、なんとか流行させようと思っているのですが、全然上手くいきません。
一般的に、コンピュータに格納されるファイルは、その属性として「作成日時」および「更新日時」の値を保持しています。
そこからの連想なのでしょうが、データベース設計においても、重要なデータを格納するテーブルにこれらの値を格納するカラムが設けられていることが少なくありません。
例えば、次のように定義されたテーブルを見たことはないでしょうか。
message
| カラム |
型 |
制約 |
解説 |
| id |
INTEGER |
PRIMARY KEY |
識別子 |
| subject |
TEXT |
NOT NULL |
表題 |
| content |
TEXT |
NOT NULL |
本文 |
| disabled |
INTEGER |
NOT NULL |
状態
[ 0: 有効, 1: 無効, 2: 削除 ] |
| time_register |
TIMESTAMP |
NOT NULL |
登録日時 |
| time_update |
TIMESTAMP |
NOT NULL |
更新日時 |
けれども、この「更新日時」が実用にどれほど役に立つものかを考えてみると、その効果のほどは甚だ疑問です。
何故なら、このフィールドはあくまで「最終の」更新日時を表すものに過ぎず、次の更新が生じたときに、その値は上書きされてしまうもの。
その最終の更新についてさえ、「いつ」行われたかは分かるものの、「どのような」変更がなされたかについては、何の情報も提供されません。
そうしたことを考えると、この「更新日時」のフィールドは殆ど意味を持たないものだと言えます。
話は変わりますが、Mac OS においてはファイルへのアクセス日時が最終のものだけでなくすべてが記録される模様。
これは便利と言えば便利なのかもしれませんが、恐ろしい気もしますね。
閑話休題。
こうした事情から、より重要なデータを扱うシステムでは任意の時点におけるレコードの状態を参照できるようにするため「履歴」の情報を含めてデータベースに格納する手法が採られます。
しかしながら、この履歴を取る方法は、作り手によってまちまち。
特に、記録の対象を重要なフィールドに限定したり、変更の差分だけを格納するテクニックを駆使したりし始めると、データベースの構造とそれを処理するコードは急速にその複雑さを増し、保守運用の困難なシロモノと化す傾向があります。
そこで今回は、この履歴をとるために私が用いているごく簡単な手法を紹介したいと思います。
ソフトウェアが大規模化・複雑化の一途をたどる今日では、ユーザインターフェイスの設計は、本体の設計・製造と切り離され、それを専門とする「デザイナ (designer)」と呼ばれる人々によって為されるものとなっています。
これにより、ソフトウェアの外観は洗練されたものとなり、同時に利用者にとって親しみやすいものとなりました。
事実、デザイナが作成するロゴやボタンなどの画像は、私がペイントで描くものとは比較にならないほど優美でスタイリッシュです。
けれども、私はときに彼らの「デザイン」に強い違和感、もっと言えば不満を覚えることが少なくありません。
それは、彼らが「美術 (fine art)」の技法・概念を偏重するあまり、対象となるソフトウェアの機能や役割から逸脱したものを作る傾向があるからです。
そもそも「インターフェイスデザイン」というのは、対象となるソフトウェアをユーザが容易・快適に使えるようにすることを目的としているもののはず。
ところが、その関係がいつの間にか逆転し、「美しいインターフェイス」を作るために操作性や機能が犠牲にされてしまっているケースが頻繁に観察されます。
また、単純な知識・技術あるいは経験が不足しているために、工学的に問題のあるデザインが為されている例も枚挙に暇がないほど。
例えば、綺麗なフォントで読ませたいがために、文章を全部画像にしてしまっているウェブページ。
代替テキスト (alt あるいは longdesc 属性) も提供しないので、検索エンジンのクローラには拾われない上、画像表示に対応していないブラウザや視覚障害者などにはアクセス不能の代物に。
その上、彼らが好んで用いる小さなフォント (9～10ポイントあたり) は、読んでて目が疲れるのなんの。
健常者にとっても不便なことしきりです。
(参照: 文字の大きさ)
さらに深刻なのは、そうした問題を指摘されても、デザイナが「アートだから」とか「感性の問題」などと言って、それを退けてしまうこと。
「コスト」だの「費用対効果」といった用語を持ち出して、自分のデザインの拙さを正当化する人も多く見られます。
(画像内の文字をテキストとしてHTMLソースに埋め込むのに、いったいどれだけの「コスト」が掛かるというのでしょう？)
そうした姿勢・認識は「業界」に常識あるいは雰囲気として定着してしまっており、容易には変わりそうにありません。
それでも、注意して見てみれば、この現状を問題アリと認識しているデザイナ, アーティストの意見を見付けることができます。
(以前の記事 (「デザイン」の問題) で引用した KOJI's Diary のその一つ。)
今回は彩夢万丈というサイトで見つけたある記事と、そこで取り上げられている作品を紹介したいと思います。
