英語はそれこそ中学校の頃からなのでかれこれ十数年勉強している訳ですが、それでもなかなか思うようにぺらぺらとはしゃべれないものです。その一番の原因は「勉強」しているのに「使わない」からだと思っています。車の運転でも教習所でいくら車の仕組みや交通ルールを学んだところで、上手に運転できるかどうかは普段から車に乗っているかどうかであって普段から使っているというところがポイントなんだと思っています。
そんなこんなで、英語を普段から使うようにしようと思い始めたのは、それもだいぶ前ですが就職したてぐらいの頃でしょうか。外資系に就職したものの、周りの方々とは違いエイゴ嫌いでそれまで過ごしてきたので喋るどころか読むのもしんどい。単語を知らないし、文法も知らない。それでも就職して約5年でなんとかぎこちないながらも英語でメールを書いたり、読んだりできるようになったのも社内外にある技術系のたくさんの英文メール(1日100〜200通)を読み、たまには書いていたという積み重ねだったんだろうと思います。
ただ、ここにきて気づいたのはあまりにも知っている単語の範囲が技術系に偏っているというところでした。技術系のプレゼンは通訳なしでもそこそこわかるのに、映画やニュースの英語はほとんどわからない。そこで最近あらためて、BBC Newsのインターネット版を毎日読むようにしはじめました。
BBCはPodcastも配信しているのでそれでも良かったんですが、毎日iPodにつなぐのが面倒ですぐにやらなくなってしまいました・・・。インターネット版のニュースであれば、ブラウザを立ち上げたときのデフォルトページをYahoo!からBBCにするだけですぐに毎日目にするようになりますし、RSSを購読するのも便利です。個人的には会社のPCと自宅のPCでどのニュースを既に読んだか、という情報を共有したかったのでGoogle ReaderというRSS購読サービスを使ってニュースを読んでいます。
BBCではなくCNNやNBCあるいはNHKの英語版なんかでも良かったんですが、アメリカ系メディアはなんとなく犯罪などのショッキングな出来事の報道が多くて気がめいる気がしたのと、NHKのように日本の話題中心でも少し面白くないのでBBCにしました。
さて、これでうまく生活の中に英語ニュースを取り込めれば英語力もメキメキアップするでしょうか。継続は力なりという言葉を信じてやっていってみることにしましょう。
7月に小笠原に行った際にシカク豆(Winged Bean)という豆の天ぷらを食べました。それはサヤごと天ぷらにしたもので歯ごたえもあってとてもおいしい物でした。そこで、ということで小笠原でそのシカクマメの種を買ってきました。
だいたい豆だから、植えるのは4月か5月ぐらいだろう、と思いながらも一部の種を植えてみました。Wikipediaによればなんと、多年草なんだそうで運良く生き延びてくれればそのまま来年まで生き延びてくれるかもしれません(とはいえ暖かいところの植物なので無理でしょうけど・・・)。
蒔き始めたのは8月上旬です・・・。今年の収穫は怪しいということで種のうち半分だけ蒔くことにしました。蒔いてから数日で芽が出始めました。
今度はドキュメントに関する話題です。佐藤さんのブログによると、ドキュメントは不要、最小限に。とのことで、これは同じくそう思います。というか、そうあってほしいと願っていますが、なかなかそういう訳にも行きません。
佐藤さんは今回のブログ・エントリでは触れられていませんが、 今後の潮流としては開発の現場にも内部統制がはいってくるということがこのドキュメントを残すという、エンジニアのあまりやりたがらない作業を法令等によって強いられることになります。
今回、佐藤さんはドキュメントの役割は「人に伝えること」 をドキュメントの主な使命とされていますが、内部統制という視点から見れば「監査あるいは内部統制の証拠」としての使命を負うことになります。内部統制がどの程度開発の現場にはいってくるのかは不勉強のため今はわかりませんが、少なくとも開発から本番への移行は必ず別の担当者が行わなければならないとか、そういったルールがはいってくるでしょうし、勘定系や基幹系のシステムであればそのシステム仕様書と実装に矛盾が無いかなどの監査を受けることになるかもしれません。
ところで近年、開発の現場ではウォータフォールの反省あるいは、様々な開発支援ツールを導入することによって積極的にドキュメントを作成する工数を減らそうという動きがありました。たとえばJavaであればそのAPI仕様をソースコード中に記述し、javadocという形式のドキュメントが自動生成できるようになりました。また、JavaのソースコードからUML表現を相互に同期をとれるような、たとえばNetBeans Enterprise Packとか、ツールも安価あるいは無償で手に入るようになりました。
また、あるいはその逆にWordやExcelで作ったドキュメントをもとにJavaソースコードや設定ファイルを生成するようなソフトウエア、たとえばキヤノンソフトウエアのWeb Performerなど、も数多く存在するようになりました。
この二つのアプローチは「ドキュメントを作成する」という工数を確実に自動／半自動化することを可能にしました。 佐藤さんの言うような「実装者の意思を設計者に伝える」という種類のものは前者の「プログラムからドキュメントを生成」というアプローチ、また「顧客の意思を設計者に伝える」という種類の物は後者の「ドキュメントからプログラムを生成」というタイプのアプローチによって自動／半自動化することが可能になってきました。
ところが、たしかにこのような潮流によって主としてメンテナンスしなければならないドキュメントが減ってくれることを期待していましたが、現実をみれば実際には重複した内容のドキュメント、冗長あるいは不必要なドキュメントは未だに氾濫しており、ドキュメントを作成し、探し出し、利用するための工数は実質的ほとんど減っていません。
この問題の原因と考えているのはドキュメントがどういう目的で、誰に読ませようとしているのかが不明瞭である状態のまま作成され続けているというところです。この傾向は知る限り日本においては顕著です(せいぜい英語がぎりぎり読めるぐらいなのでそれほど多くの国の事情を知っている訳ではありませんが・・・)。
たとえば日本でよく見かけるドキュメントの「はじめに」の章は形式的な挨拶が書かれている程度でそれ自体無くても不都合のない場合がほとんどです。このため、たとえば対象読者をプロジェクト全員に広げてしまい、実際に読むのはJavaに詳しいエンジニアであるのにも関わらずJavaの基礎を延々と説いているというような無意味なドキュメントが作成されてしまっています。一方、欧米のドキュメントでは最初の章に「ドキュメントの利用目的」「ドキュメントの対象読者」「ドキュメントの前提としている事柄」といったことが記述されており、それに続く内容も整合性がとれた物になっています。
そういった意味で、実際のところ開発プロセス云々の前にドキュメントの作り方自体が間違っていると言わざるを得ないと思っています。ぜひとも、開発プロセス云々の前に「理科系の作文技術」でも読んでもらいたいと思うシーン幾度か経験したことがあります。
オープトーンの佐藤さんのところでオープンソースで開発プロセスを作られているそうです。でもちょっと違うな、と感じるというか、もはや口出しできる状態ではないような気がするのでこちらからコメントさせていただこうと思います。
アジャイルは「変化に強い」という幻想
「変化に強いプロセス」というのは存在しないと思っています。アジャイルも、RUPも決してその性質として「変化に強い」ということは無くて、偶発的に「変化に強く見えている」ということにすぎないというのがその考えの根拠です。
本来、プロセスはその意味通り、一連の決まったやり方によって作業なりをこなすことであって、そもそもプロセス化可能であるというのは既にその作業について一定の経験の蓄積があってこそできるのであって、「変化に強い」というのはそもそもプロセス化されていないということにほかならないためです。
アジャイルやRUPが「変化に強いように錯覚されている」のは、ウォーターフォールのような旧来のプロセスに比べて最終コストが低く抑えられたためだと思うし、「最終コストが低く抑えられた」ことを「変化に強い」という解釈をするのは生兵法は怪我のもと、なんて言いたくなるぐらい。
足して二で割るという危険さ
プロセスは、消しゴムと鉛筆をくっつけたら便利になった！というような、成果物を作る過程において素材を足して二で割るのと違い、その作業過程には大きなリスクが混じり込むように思います。
たとえばソフトウエア製品を思い出していただければわかりやすいと思うけれど、ソフトウエアというのは、それ自体一連のプロセスとなっていて、あるソフトウエア2つをくっつけて一緒にするという作業を想像したとき、例えばWordとExcelを完全に一つのソフトウエアとして統合する、という作業を想像してみると、たとえばWordとExcelはそれぞれ成熟したソフトウエアであって、巨大なプロセスの集合体です。それらを統合しようとするのであればファイル形式から利用形態まですべてを抽象化した上で統合しなければ、上っ面だけ統合された（例えば昔ならMS Worksなんてのがありましたが）ソフトウエアになるだけであって、それは統合された、というよりは集約された、というだけに他ならないように思うからです。
プロセスを集約する、という作業自体が無意味であるという訳ではないけれども、そのアプローチは潜在的に分裂も容易である、と思えるし、そう陥ればこのプロジェクトは求心力を失いかねないし、一枚岩ではないものでは訴求力も分散する危険性を感じるためです。
権利関係について
この開発プロセスはオープンソースを謳っているものの、仮に深意は無いとしても制約が大きすぎるように思います。たとえば権利関係についてのページの次の項目(2006年8月22日時点)。
本プロセスならびにプロセス内の雛形集は商用・非商用に関わらず
自由に使用することができます。ただし、本プロセス自体ないし、
改変を加えたものを商品として販売することはできません。
とのことですが、プロセスの販売を禁じるのは結構厳しいかと。最悪、GPL汚染呼ばわりされかねない危険性があるように思いますがいかがでしょう。たとえば、SIであるA社が顧客であるB社に対しこのプロセスにA社のノウハウを詰め込んだ上で提供しようとしてもできない可能性があるのでは？
先日バッテリー交換プログラムに申し込みをしましたが、申し込んだ次の日には届いてしまいました。まあ、プログラムが発表されてから少し時間が経っていたことと、また逆に経ちすぎていなかったことからおそらく在庫があったのでしょう。それにしてもアップルは近年カスタマーサポートがとても良くなってきたような印象があります。他のPCを使っていないので直接比較はできませんが、昔の印象だと交換パーツも他社を含めだいたい2〜3週間はかかったりしたような場合があったような気がしますが最近は数日で届く。もちろん、在庫の加減次第であるというのは重々承知ですがそれにしても発送までの時間はおそらくいろいろな努力によって短縮されているのだと思います。
ところで、今回のバッテリー交換プログラムですが配達は引き取り交換という形式で送付されてきました。申し込んだ次の日には届いていたのですが、たまたまそのときには交換の古いバッテリーを持ち合わせていなかったので受け取りができませんでした。こんなことなら申し込みをしたときに教えてくれれば良いのに・・。と思いましたが、何はともあれすぐ届いたのでやっとバッテリー問題は解決で、新品をゲットすることができました。
川崎市の多摩川花火大会に行ってきました。川崎市に引っ越してからかれこれ5年ぐらいですが、まともにみたのは今回が初めてでした。昔は川崎市と世田谷区の合同でしたがここ数年は川崎市のみとなっています。寂しくなったなあと思っていたら、今年の多摩川花火大会では世田谷区長の挨拶があり、安全性の確保が見通しが立ったので、来年からは世田谷区側もやる、とのことで会場からは拍手喝采がわき上がりました。
二子新地駅、二子玉川駅あたりは遠くからみた限りでは気が遠くなるような混み方をしていましたが、我々一行は高津駅から遠回りをして第三京浜側から回り込んだのでそれほどの混雑には巻き込まれずにすみました。大会会場に着いたのも打ち上げの30分前ぐらいでしたが、それでもなんとか場所が確保できました。でも、さすがに打ち上げポイントから近すぎたためずっと上を見上げていたら首が痛くなってきました。来年は土手の場所取りをして寝転びながらみたいなあと心に誓いました。
MacBook Proのバッテリー交換プログラムが発表されてからすこし経ちましたが、まあ、今は忙しいのでもう少しおちついてからやろうかな〜とおもっていたところ、バッテリーに変化が・・・。
すこしわかりにくいかもしれませんが、バッテリーの右側が盛り上がっています。まあ、この夏の暑い時期なので、とかエアコンもつけてないのでうちの部屋が暑すぎるのかな〜とかいろいろ考えられますが(笑)。それにしてもこんなこと初めてです。
聞くところによるとリチウムイオンバッテリーというのは通常、少なからず膨張するという性質があるそうで、通常その膨張を見越してバッテリーの箱は大きめに作ってあるとか。
でもここまで膨張してくるとちょっと発火とかしそうな気もしなくはないし、そもそもこれを装着すると平らな机に置くとMacBook Pro本体までカタカタいう始末・・・・。とりあえずこれではヤバいので早速交換プログラムに申し込みましたが、プログラムがあったことがラッキーだったのかどうかはよくわかりませんが、まあ早く安心したいものです。
先日、知り合いに呼ばれて行ってみると何かと思えばとあるビジネスの話でした。「とあるビジネス」とはよくあるネットワーク・ビジネスのお話で、まあ、マルチ商法ではないとのことでしたが、そういった話に限らず儲け話の類はしょっちゅう電話なりメールなりで来るので、なあんだまたかと思っていましたが、話を一通り聞いてその場での印象としては
- 商品の内容 : まあ良い
- ビジネスのシステム : まあ良い
という印象でしたが、いかにも逃がさないぞというオーラ丸出しの姿勢でかえって印象を悪くした気がします。それでもまあ、根拠なくYesともNoとも言わない状態を続けるのは先方にも時間を割いてもらったことを考えれば悪いなあと思い、自分なりに納得のいく結論を出せるように調査をしてみることにしました。
説明をしてくださった方曰くは、家かえってインターネットで調べてもネガティブなことしか載ってないから信用しないように、たとえば2ちゃんねるの書き込みみてネガティブなことを言われても困る。というまあ、ごもっともなお話を頂きましたが、こちらとしてはコンピュータ業界で長年やってるんだから情報の信頼性もそれなりにわかっているつもりでしたからちゃんとした方法で調べていくことにしました。
今回このブログでは該当の商品や団体について伏せたいために詳しくは書きませんが、まずは、総務省統計局 の統計情報を確認しました。統計についてはいろいろな観点があるので読み方も注意しなければならないのですが、統計局の出されている統計情報は信頼性もさることながらExcel形式で元データが入手可能なこともあり手元で目的のデータに加工しやすいというところも気に入っているところです。
こういった調査の結果、今回は自分の中で明確に「No」という答え(=自分には合わないという結論)を出すことができました。今度先方から連絡があったらその旨伝えて、お互い無駄な時間をすごさないようにしたいものです。
遅まきながらやっとソーシャルブックマークで有名なdel.icio.usを使い始めました。コンピュータ業界にいながらこの送れっぷりはちょっとどうかなあ～と思うところもありますが、それをためらわせていたものは自前のブックマークで十分だという状況でした。もともと、5年ぐらい前からブラウザのブックマーク機能は使わなくなり、自前のサイトにリンク集なりWikiなりを立ててそれをブックマーク代わりにしていたのでまったく不自由していなかったんですが、ここにきてようやく使おうと思ったのはタグのシステムがあったからでした。
Wikiにしてもリンク集にしてもそれぞれいい面はあるものの、とにかくバンバン ブックマークしまくる場合には整理をするのが難しくなりがちです。Wikiだとやたら細かいページがたくさんできてしまったり、リンク集だとリンクを置く場所をどこにしようかと迷ったりといったところですね。それがタグによるシステムであれば、ブックマークのような情報がたくさん細かく作成しようとしていても分類をしないことにより情報を収納するときのテンポが確実に速くできる、というところが一番の魅力でしょう。
あと面白いのはタグがどのようについているかで自分の興味の持っている分野がなんとなく明らかになること。たとえばこんな感じです。
これを見てみると、以下に興味をもっている分野にまとまりがないかが一目瞭然・・・。
以前英語学習とPodcastというエントリで紹介したEnglish Aya Podですが、残念なことにあと3回で終了してしまうとのことです。とても内容といい、品質といい、長さといい気に入っていたんで有料でもいいから続けて欲しかったところですが、まあそれはいろいろな事情があって難しい決断をされたんだろうと思います。
