《毎日「SCIENTIFIC AMERICAN」の表紙を眺める》
■新連載・ライル島の彼方［02］
開発者に英語が必要な、20の理由
薬師寺 聖
■クリエイター手抜きプロジェクト［405］書籍編
長期にわたってWeb関係の本を書いているとどうなるか
古籏一浩
--PR------------------------------------------------------------------
★DTP・印刷専門のデジタルコンテンツ販売サイト「印刷の泉」
≫≫≫ https://www.ddc.co.jp/estore/
≪≪≪
●セミナー・勉強会を撮影した動画・スライドも好評販売中！
●“無料”のPhotoshopアクション・Acrobat用プリフライトもあります！
●編集作業の味方！ PDFの違いを発見してくれるソフトを販売（体験版あり）
★電子書籍 PDF フォント 素材 スクリプト 動画を販売したい方を募集中！
-----------------------------------------------------------------PR---
■新連載・ライル島の彼方［02］
開発者に英語が必要な、20の理由
薬師寺 聖
■クリエイター手抜きプロジェクト［405］書籍編
長期にわたってWeb関係の本を書いているとどうなるか
古籏一浩
--PR------------------------------------------------------------------
★DTP・印刷専門のデジタルコンテンツ販売サイト「印刷の泉」
≫≫≫ https://www.ddc.co.jp/estore/
≪≪≪
●セミナー・勉強会を撮影した動画・スライドも好評販売中！
●“無料”のPhotoshopアクション・Acrobat用プリフライトもあります！
●編集作業の味方！ PDFの違いを発見してくれるソフトを販売（体験版あり）
★電子書籍 PDF フォント 素材 スクリプト 動画を販売したい方を募集中！
-----------------------------------------------------------------PR---
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■新連載・ライル島の彼方［02］
開発者に英語が必要な、20の理由
薬師寺 聖
< https://bn.dgcr.com/archives/20141027140200.html
>
───────────────────────────────────
前回に引き続き、ザル英語について取り上げる。
アプリ開発は、いきなり実装から始まるわけではない。段取り八分である。アプリの公開手順を理解し、開発言語や開発手法を学んで試し、企画、設計、データ・デザイン、UXデザインなどを行う。
それらの工程では、英語の情報が役立つこともある。機械翻訳に頼ることなく英語を理解できれば、次に揚げるように、なにかと便利ではなかろうか。
【1】リソースが豊富である
新製品やイベントを紹介するニュース記事、技術解説や一般コラムなどのオンライン記事、開発者個人のWebサイトやブログなどには、英語のリソースの方が圧倒的に多い。
【2】仕様書の翻訳を待たなくてよい
開発言語の仕様書（★1）のような分量の多いドキュメントは、ローカライズに時間がかかる。W3Cの標準化仕様書は、勧告となった後に、ようやく翻訳されることがある。
一方で、開発環境のバージョンアップはめまぐるしい。環境が変わらないうちに情報を入手するには、英文を直接読むしかない場合もある。
【3】仕様書の図表を活用しやすい
たとえば、HTMLの要素・属性の一覧や、DOMのIDL定義などのように、仕様書の中に表やリストの形で掲載されている情報がある。英語に抵抗感さえなければ、こういった翻訳不要の情報を、先行して利用できる。
【4】和書と洋書を併用して学べる
（専門分野によって異なるかもしれないが）国内では、どちらかといえば、入門者向けの書籍が充実している。初心者対象の和書で概要を把握した後に、専門家対象の洋書で細部を確認するのは、技術習得のひとつの方法である。
【5】プレビュー版を試しやすい
Windows 10 Technical Preview が公開された（★2）。既に多くのニュースがネット上を駆け巡っている。
海外ベンダーの製品は、通常、英語版が先行公開される。ダウンロード情報やセットアップ時のメッセージを読みながら試す方が、勘でセットアップするよりも確実だ。
【6】著作権情報を理解しやすい
アプリ開発において、他のプログラマの作った各種サンプルやツール、API、素材などを利用したい場合、使用許諾書や著作権などの情報を、スルーすることはできない。それらのテキストが英語で書かれていても、きちんと理解したうえで利用する必要がある。
【7】サンプルの処理を理解しやすい
海外の開発者が個人的に公開したサンプルコードのコメントは英語であることが多い。コードだけでなく、コメントも読める方が、ロジックを理解しやすい。
【8】開発時の名付けに困らない
クラス名や変数名などに、適切な名前付けをできる。また、分かりやすくインパクトのあるアプリのタイトルを付けることができる。
【9】スペルミスを減らせる
参照先のサブフォルダ名やファイル名にスペルミスがあると、アプリは正しく動作しない。また、RDBのフィールド名やXMLのタグ名にスペルミスがあると、プログラムが正しくても、目的のデータを処理できないなどのバグが生じることがある。
誤ったスペルのスキーマをもとに、大量のデータが蓄積される事態は避けなければならない。最初から正確につづるには、知っている単語は多い方がよい。
【10】困った時に答えを得やすい
英語圏のサポート情報やフォーラムでの質疑応答を参考にしたり、海外の開発者やベンダーの担当者にメールで問い合わせるには、英文を直接読み書きできる方が、意思疎通をはかりやすい。
【11】技術的解決策を検索しやすい
納期がタイトな開発案件で、急いで解決策を知りたいとき、英語のリソースも検索対象とした方が、答えの見つかる可能性が高くなる。
が、メソッド名やプロパティ名などで検索すると、膨大な検索結果が得られてしまい、目的の答えを見つけにくい。絞り込むには、英語で検索キーを的確に指定できるほうがよい。
【12】誤った情報を見分けられる
参考にしたい英語のリソースの中には、開発・実行環境のバージョンが異なるなどの理由により、解説通りの手順では正常に動作しないサンプルもあるだろう。動作環境や概要などの英文を読めば、原因に気付くことができるかもしれない。また、情報を鵜呑みにして適切でない処理を利用してしまうリスクを回避できる。
【13】火元になるリスクを減らせる
翻訳されたニュースやブログ記事の中には、時折、筆者の真意を読み取りにくい微妙な表現がある。原文を読んで確認できれば、早合点や誤解は減り、誤ったツィートを避けられる。
【14】訳文では分かりにくい部分を確認できる
W3Cの標準化仕様を元にした実装の途中で、仕様の詳細を確認するには、原文を直接あたるほうがよい（★3）。いかに優れた翻訳家が訳しても、訳文からは見えてこない部分があるからだ。
「MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL」の使い分けや、複数形と単数形の区別も、原文なら一目瞭然だ。
たとえば XPathの仕様書でいえば、nodesとnodeは、明確に使い分けられている（★4）。
データ処理プログラミングにおいては、指定する対象が、複数のノードなのか、それとも複数の中の特定のノードなのか、また、式の評価結果は複数なのか、それとも単一なのか、といったことを意識している方がよいだろう。
【15】初発情報を発信しやすい
新しい仕様が登場した当初は、日本語のリソースはごくわずかである。いちはやく技術を伝えようとすれば、英語のリソースを避けて通ることはできない（★5）。まだ適切な訳語がない場合は、背景やコンテクストから意味をイメージして、読者の理解を促すような訳語を考える必要がある（★6）
【16】技術者同士の交流の場を拡げやすい
海外エンジニアも参加するコミュニティイベントで交流したり、技術者同士でチャットするには、英語を操れるほうが、友人は増えるだろう。また、海外の開発者とのコラボレーションでは、英文ドキュメントを読み書きできるほうがよいだろう。
【17】ユーザーと意思疎通をはかりやすい
海外ユーザーからの問に答えたり、バージョンアップ要求の内容を理解するには、英語でやり取りできる方がよいだろう。
【18】開発物を宣伝しやすい
宣伝用コピーや行間を読ませる文章を書くスキルがあれば、機械翻訳よりも伝わりやすく表現できるだろう。動画サイトやSNSで、海外ユーザーに向けて開発物を宣伝できれば、ダウンロード数も期待できるだろう。
【19】海外に自分の技術を発信できる
英語でブログを書いたり、SNSを使いこなせれば、自身のもつ技術を、海外に向けて発信できる。日本語で考えて表現したものを英語に訳すのではなく、英語で直接考えて表現できると、より発信力が強まるに違いない。
【20】技術以外の多くの情報を得られる
拡がりのある企画を立てるには、専門分野以外の情報もウォッチしているほうがよい。
現在では、「科学・医学・倫理学」と「技術」には、クロスオーバーする部分が増えている。センサーを使ったアプリ開発についていえば、新たなセンサー素子の研究開発は「科学」であり、センサーと人体のシームレスな接続方法には「医療」が絡み、センサーデバイスがヒトの脳にもたらす影響には「倫理学」が必要になる。
そのうえ「研究」と「開発」もクロスオーバーしている。研究して開発した結果を研究にフィードバックして、ふたたび開発する、といったサイクルもある。
国内の技術情報サイトだけでなく、海外の「科学・医学・倫理学」の「研究」結果の情報を、ウォッチしてみるのもよいのではないだろうか（★7）。
英語に限らず、どのようなスキルでも、持っていないよりは、持っているほうがよい。
ただ、どの程度必要なのか？ といえば、それは意見の分かれるところだ。習得すべきスキルは、それぞれの立場や作業内容によって、異なるのだから。
今はもう、開発者にとって英語は必要なのだろうか？ と悩む時期は過ぎ、（筆者も含め）それぞれの作業に応じたスキルを獲得していく段階なのではなかろうか。
★1 たとえば、msdn の VB や C# の仕様書などである。
msdn C# リファレンス
< http://msdn.microsoft.com/ja-jp/library/618ayhy6.aspx
>
マウスオーバーで原文がポップアップされ、訳文では分かりにくい部分を確認できる。
★2 Windows 10 Technical Preview
< http://windows.microsoft.com/ja-jp/windows/preview
>
マイクロソフトの提供する技術については、公開されるやいなや、その技術分野の Microsoft MVP が紹介記事を書くので、関心ある分野の MVP のブログや facebook を普段からチェックしておこう。
< http://www.microsoft.com/ja-jp/communities/mvp/default.aspx
>
★3 データ・デザインの地平［39］「その記事は「社会的に」正しいか？」（2014/3/24配信）を参照。
< https://bn.dgcr.com/archives/20140324140200.html
>
★4 XMLデータ処理に限って言えば、ElementsかElementか、AttributesかAttributeか......挙げればキリがないが、頻発するのは、NodesとNodeである。
例文で説明しよう。「XML Path Language (XPath) 3.0 W3C Recommendation 08 April 2014」中の「3.3.1 Relative Path Expressions」の、Noteから引用する。
Since each step in a path provides context nodes for the following step, in effect, only the last step in a path is allowed to return a sequence of non-nodes.
単数形と複数形に注意して読むと、次のように解釈することができる。
「ひとつの」パスの「各々の」ステップは、「後続の特定の」ステップに、「複数の」コンテキスト・ノードを渡す。これにより、「ひとつの」パスの中の最後のステップ「だけ」は、ノードなき「ひとつの」シーケンスを返すこともある。
仕様書原文では、このように、単数形か複数形かという点が、正確に記述されている。
だが、日本語では、上記のように、単数形と複数形を明確に区別しすぎると、非常に読みにくい文章になってしまう。
そこで筆者は、解説文中で複数であることを伝えなければならないときは「ノード群」、それ以外を「ノード」と表記するなどして区別していたことがある。ただし、ここでいう「群」とは、あくまで学術用語ではなく、動物の群れをイメージさせる一般用語としての「群」であり、XML入門者向けに限定しての表記である。
★5 拙著「HTMLリファレンス」（1999年刊）の執筆においては、W3CのHTML仕様書の、全要素の全属性についてサンプルを作成して表示確認した。
また、MS-XSLの初発本「XML＋XSLによるWebサイトの構築と活用」（宮坂雅輝共著、筆者はXSLを担当）では、W3CのXSLTワーキングドラフトとMS-XSL（マイクロソフト独自仕様のXSLT）の仕様を突き合わせて確認する必要があった。
XMLマスター資格試験の初発本「XML MASTERテキスト XMLマスター（ベーシック）」（福内かおり共著、筆者はXSLT・XPath・DOM・Namespace・付録ビデオのシナリオを担当）も、W3C仕様書を読んで書く必要があった。新しい技術をひろめるには、原文を避けてとおることはできない。
★6 仕様書中の言葉の訳語が定まっていない場合は、ことばの意味をイメージさせる日本語をひっぱり出す必要がある。
たとえば、XML関連の仕様書に頻発する parse という言葉。現在なら「パース」と訳せばよい。が、XML黎明期にはノンエンジニアの入門者が非常に多く、「パース（構文解析）」という概念自体が知られているとはいえなかった。
そうした場合は、比較的知られた言葉に置き換えて伝える必要がある。筆者は、XML木をたどっていくさまを走査線に見立て、「走査」という言葉を使って解説していた。
★7 たとえば、毎日「SCIENTIFIC AMERICAN」の表紙を眺めるだけでも、リアルタイムで科学の今を実感できる。「日経サイエンス」のWebサイトにまとめ記事もある（リンク規約に抵触するおそれがあるためURIは記載しませんから、bingってください）
--------------------------------------------
オンラインブック「XML設計の心得」（無料、ただしサポートなし）
「筆者最後のXML本」のつもりで書いた本。2009年発行につき、一部内容に古い面はあるが、XMLについて知りたいHTMLのマークアップエンジニアには役立つと思われる。
PROJECT KySS名義だが筆者の単独執筆であり、第4章では、デジクリ連載「データ・デザインの地平」で取り上げてきた、「一意なものとは何か？」という問題についても少し触れている。
< http://sei.seindesign.net/Book1_DL/Default.htm
>
--------------------------------------------
■WWindows 10 Technical Preview のプレビュー版が公開されました。
プレビュー版を体験して、意見をフィードバックしよう。
< http://windows.microsoft.com/ja-jp/windows/preview
>
プレビュー版のリスクを正しく理解するために、インストール前に要一読。
「Windows Technical Preview をインストールする前に」
< http://windows.microsoft.com/ja-jp/windows/preview-faq?ocid=tp_site_insiderforum&#faq=tab5
>
--------------------------------------------
【薬師寺聖／個人事業所 セイザインデザイン】
個人事業所 < http://www.seindesign.net/
>
ブログ < http://blogs.itmedia.co.jp/seindesign/
>
< infosei@seindesign.net >
絵を描き、詩を書き、曲を書き、文を書き、企画書と仕様書を書き、コードを書く、在野の思索家。
科学・医療・福祉分野のXML案件を手掛ける傍ら、XML資格試験の初発本など、書籍や連載を多数執筆（主にPROJECT KySS名義）。
現在は、受託業務から独自発信にシフト中。
Microsoft MVP for Client Development (Oct 2003-Sep 2015)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■クリエイター手抜きプロジェクト［405］書籍編
長期にわたってWeb関係の本を書いているとどうなるか
古籏一浩
< https://bn.dgcr.com/archives/20141027140100.html
>
───────────────────────────────────
先週の土曜日（10/25）に「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」本が発売されました。
・jQuery+jQuery UI+jQuery Mobile逆引きハンドブック
< http://www.amazon.co.jp/dp/486354149X
>
これで56冊目くらいになります。56冊目くらいと書いたのは、出版された順番になっているわけでなく、原稿を書き上げた時点での冊数になっているためです。ちなみに何冊目なのかはプロフィールの所に記載してあります。もしかしたら、奇特なコレクターがいて全部揃えるかもしれないので（と勝手に思っているだけですが）。
ちなみに、この本はもともと一冊の本として出版される予定でしたが、出版社の都合と私の都合とページ数の都合で、三冊に分けて出版されることになりました。最初の一冊はすでに2012年9月に発売されています。
< ・JavaScript逆引きハンドブック
http://www.amazon.co.jp/dp/4863541082
>
残りの一冊は来年出版される予定です。三冊そろって相互に逆引きができるのが理想でしたが、現状ではそれはできていません。まあ、最後の一冊が出ていないからですが。
「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」は残りの一冊の本と相互に逆引きできないと、いまいち使い勝手が悪くなります。最後の一冊が出て増刷がかかるようなら、相互に逆引きできるようになるかもしれません。
ちなみに、この本の企画は2011年のものですので、最後の一冊が出るまでに三年以上かかることになります。Web業界において三年という期間はあまりに長く、三年であれよあれよという間に使われる技術やトレンドが変わってしまいました。
Web業界はドッグイヤーというほど流れが早く、一年前の技術でも陳腐化していることも珍しくはありません。それでも長期間にわたって使われる技術もあります。JavaScriptやjQueryも該当します。これらは、簡単には古びないので、多少時間かけて書いても大丈夫という安心感はあります。
しかし、実際に書いてみたら、そんなにあまくありませんでした。最初の「JavaScript逆引きハンドブック」は企画から一年程度で出版できたので、トレンドや最新技術からひどくずれてしまうことはありませんでした。（書名は「JavaScript逆引きハンドブック」ですが実際には「JavaScript+HTML5逆引きハンドブック」といったところ）
「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」は大変でした。通常はjQueryで一冊、jQuery UIで一冊、jQuery Mobileで一冊という感じで出版されるのですが、この本はお得感を出すために全部まとめて一冊。つまり三倍の手間がかかるということになります。
まず、jQuery自体がどんどんバージョンアップされてしまうため、それに対応するだけで時間がかかりました。当初はjQueryバージョン1.6.4で、これに対応したバージョンの原稿を書いていました（最終的には2.1.1）。
しかし、今回のjQuery本では他にもjQuery UIとjQuery Mobileにも対応しなければいけません。これらも別々にバージョンアップされていくため、三つのライブラリに逐次対応していく必要があります。
例えば、jQuery 1.6.4では正式な命令だったのが、次のバージョンでは廃止されたことです。執筆中には、このようなことが頻繁にありました。
特にjQuery Mobileは大変でした。jQuery Mobileのバージョンアップのたびに仕様が変更されるため、サンプルプログラムもバージョンごとに書き換えないといけませんでした。また、jQueryを土台にしているため、jQueryで変更があるとjQuery Mobileにも影響が及びます。
頑張って対応させたにもかかわらず、業界のトレンドはあれよあれよと変わっていきました。一年ほど前から作成されるWebアプリケーションではBackbone.jsやAngularJSが使われるようになり、jQueryはトレンドからは少しずつ外れていきました。
企画をたてた三年前はjQuery必須だったのが、中規模〜大規模開発ではjQueryを使うと問題があるので、使用しない方向に変わっていきました。これはjQueryに依存するとセキュリティの問題や不具合が発生した場合、jQueryのバージョンアップを待たなければならず、すぐに対応できないからです。jQueryに依存しないフレームワークなら、すぐに対応させられます。
あまりjQueryに依存しなくてもよくなった理由としては、Webブラウザの標準化が進んだことがあげられます。特にIEは他のブラウザとは異なる命令を使用していたり、動作が異なっていたりと、問題多発で開発のネックとなっていました。
jQueryはIEに対応するために便利だったのが、標準化されてしまえばあまり必要ではないということです（これは本の最初にも、さっくりと書いてあります）。
また、三年前と比べて格段にスマートフォンが使われる割合が高くなったということもあります。パソコンと比べてスマートフォンでは、より新しい技術を使用できる（HTML5+CSS3+JavaScriptに対応）状態になっています。
パソコンなら古いIEが消えるまで三〜五年待たなければいけないのが、スマートフォンなら今すぐに最新技術を使うことができます。また、データ通信量の節約という面からしても、jQuery+jQuery Mobileを使わない方がよいというのもあります（CDNでキャッシュが有効に機能するなら、また違いますが）。
Web関連の書籍は時間勝負なので、少なくとも企画から一年以内に出版しないと大変だというのが実感です。紙ではなく電子書籍なら素早く出版できるのでは？ という人もいるかもしれませんが、書く側で時間かかるので、思ったほど早くは出版できないものです。
一番いいのは企画を考えて一か月以内に全部原稿を書いてしまうことです。が、これはよほど勉強して技術をあげておかないと難しいでしょう。結局のところ、ひたすら勉強あるのみ、ということです（本当は勉強したくないけど...）。
【古籏一浩】openspc@alpha.ocn.ne.jp
< http://www.openspc2.org/
>
と書いてみたものの、年齢を重ねると地域関係の役とかいろいろで時間がとれなくなってくるというオチが待ってました。特に地元の田舎だと20〜40代の人口が少ないので60代（団塊の世代）なら一生に一度しか回ってこない（もしくは永久に回ってこない）役が、40代になると3回くらい回ってきたりします。
20代だとさらに回数が多くなり、役も多くなります。20代だと60代の10倍以上の役などの負担が大きくなる感じです（地元の人口比の場合。20代より80代以上が4倍以上いる^_^;）。
・jQuery+jQuery UI+jQuery Mobile逆引きハンドブック
< http://www.amazon.co.jp/dp/486354149X
>
・データビジュアライゼーションのためのD3.js徹底入門
< http://www.amazon.co.jp/dp/4797368861
>
・D3.js例文辞典
< http://www.openspc2.org/reibun/D3.js/
>
・ExtendScript Toolkit（ESTK）基本編
< http://www.amazon.co.jp/dp/B00JUBQKKY/
>
・Egison言語 例文辞典
< http://www.openspc2.org/reibun/Egison/3.3.2/
>
・4K/ハイビジョン映像素材集
< http://www.openspc2.org/HDTV/
>
・JavaScript逆引きハンドブック
< http://www.amazon.co.jp/dp/4863541082
>
・Adobe JavaScriptリファレンス
< http://www.amazon.co.jp/dp/4844395955
>
・Nexus 7（アンドロイドタブレット）使い方辞典
< http://www.openspc2.org/reibun/Android/Nexus7/
>
・クリエイター手抜きプロジェクト
< http://www.openspc2.org/projectX/
>
・Adobe Illustrator CS3 + JavaScript 自動化サンプル集
< https://www.ddc.co.jp/estore/cgi/item/start.cgi?m=DetailViewer&record_id=243
>
吉田印刷所の「印刷の泉」でも購入できるようになりました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集後記（10/27）
●小3生による「ひみつきち」作りが再び始まった。土曜日の午後に友達とふたりでダンボールの小屋を作った。今度は我が家の庭だ。隣家の庭との境界線フェンスにぴったり着けての建設だ。その部分の隣家の庭は木が何本も植わっていて、こっちが見えないから都合がいい。庭はレンタルなんだから本来なら違法だが、隣家の庭は芝生ではなく木が植わり、鉢が所狭しと置いてある。ふたりは、前回駐車場裏に建ててわずか一日で取り払われた小屋の三倍くらいの規模で建ちあげた。日曜日の午前中には、友達の弟も加わりさらに拡張工事が行われた。彼らが引き上げた後で、雨に備えて大きなブルーシートで覆っておいた。上階から見下ろしたらさぞ異様な光景だろう。
少し前のことだが、「マンションなんかに越してこないで、浦和の一戸建てにいたほうが気楽だったなあ」とうっかり漏らしたら、「じゃあここに来たのは間違いだったとでもいうのか」と短気な妻が怒り出した。「あなたがひとりで決めたんだよ。下見から帰ってきて、内金300万円出せと言ったのは誰よ。ここに来て我々もハニー（犬）も大満足だったはずじゃないの。いまになって何を言ってるのよ」とぶんむくれ。「ちょっと待ってほしい」と天声人語でかわして、誤解を解くために説明、いや弁解を始めたのであった。それは今のわたしの環境の変化だ。マンションは人付き合いがわずらわしい、めんどうくさいと考える人にとっては最高にお気楽な環境なのだが、最近のわたしはそうもいってられなくなった。
それは一年半前に、管理組合の「防災委員募集」に気まぐれで応じたことから始まる。233世帯のマンションで、手を挙げたのがわたしひとりしかいなかった。それからは、毎月行われる理事会に出席し、昨年度は「震災対応マニュアル」制作の事実上の責任者になってしまった。マンションのネットサービス会社から買った「震災対応マニュアル」のテンプレートを、我がマンション用にカスタマイズして、なんとか仕上げたものの、出来は満足できるものではなかった。そこで今期の理事会にも参加し、いまひとりで一から作り直している。理事会は来年の大規模修繕テーマにかかりきりで、震災対応テーマはわたしが責任者にならないと動かなくなっている。
マンションを29フロアー、6ブロックに分け、それぞれにリーダーをおいて……という震災後のシミュレーションをやっていると、さまざまな困難が考えられて、もう無理じゃないかとさえ思う。それでもなんとかルールを設けないと、マンション住民はばらばらの被災者になってしまう。いまのわたしは、自宅さえ守ればいいという立場にない。マンション全体の総力戦をデザインしなければならない。だから、つい「一戸建てにいたほうが気楽だったなあ」と思うのであった。いつでも、どんなときでも、ふと思う。今揺れたら……間に合わない、と。難儀やなあ。「ひみつきち」の家主は、なんの憂いもなく暗くなるまで遊びまくっていていいなあ。（柴田）
●どなたかデザイン、WordPress、コーディング、Flashなどのお仕事を手伝ってくださいませんか？ フットワークが軽く、連絡を密にしてくださる方。費用面の制限があるので（大阪価格）、実績や費用目安などを教えてくださると助かります。
仕事がパンパンで、私生活や健康、趣味などを犠牲にしていたんですが、もう限界に来てまして、過剰反応や逆反応しはじめてます……。どうかお願いします！ ご紹介してくださるとありがたいです。zacke@days-i.comまでお願いします。#拡散希望（←はじめて使った）
態勢が整ったら、打診があった時に微妙な対応しなくて済むし、もっと仕事を受けられる。延び延びになっている仕事も納められる。営業かけることだってできるかも。どうか私を女にしてくださいっ！（えっ?!）
大阪マラソンに出たかったよ〜。コブクロの地下鉄車内ソングがなくなるのは寂しいような。大音量で流れてて、「誰の着うたや、うるさいな〜」と思った。スピーカーが悪いのが原因だと思う。なぜかコブクロファンのN氏が謝ってました（笑）。結構な人数が思ったようで、数日後にはボリュームが絞られるようになったよ。
BGMとして音を絞って音楽鳴らしてもいいかもね。コンビニのBGMみたいに。映画の宣伝とか、地下鉄パワープレイとか（笑）。路線ごとに変えたりして、その路線利用者だけが流行る音楽が出来たりして。カフェミュージック的なのでもいいな。2分程度で終わる超ショートショート朗読とか。あ、今でもテレビ（モニタ）付き列車はあったね。CMや星占いとか流れるやつ。（hammer.mule）
< >
地下鉄で流れるコブクロの曲とメッセージ。
< http://togetter.com/li/726466
>
「大阪市営地下鉄で着うたテロ発生？」
< http://eonet.jp/osaka-marathon/2014/kobukuro/
>
終わってる！ コブクロ「42.195km」期間限定フリーダウンロード
< http://ja.wikipedia.org/wiki/42.195km_(コブクロの曲)
>
< http://emtg.jp/feature/osaka_marathon2014/
>
楽曲解説動画なるものが
■新連載・ライル島の彼方［02］
開発者に英語が必要な、20の理由
薬師寺 聖
< https://bn.dgcr.com/archives/20141027140200.html
>
───────────────────────────────────
前回に引き続き、ザル英語について取り上げる。
アプリ開発は、いきなり実装から始まるわけではない。段取り八分である。アプリの公開手順を理解し、開発言語や開発手法を学んで試し、企画、設計、データ・デザイン、UXデザインなどを行う。
それらの工程では、英語の情報が役立つこともある。機械翻訳に頼ることなく英語を理解できれば、次に揚げるように、なにかと便利ではなかろうか。
【1】リソースが豊富である
新製品やイベントを紹介するニュース記事、技術解説や一般コラムなどのオンライン記事、開発者個人のWebサイトやブログなどには、英語のリソースの方が圧倒的に多い。
【2】仕様書の翻訳を待たなくてよい
開発言語の仕様書（★1）のような分量の多いドキュメントは、ローカライズに時間がかかる。W3Cの標準化仕様書は、勧告となった後に、ようやく翻訳されることがある。
一方で、開発環境のバージョンアップはめまぐるしい。環境が変わらないうちに情報を入手するには、英文を直接読むしかない場合もある。
【3】仕様書の図表を活用しやすい
たとえば、HTMLの要素・属性の一覧や、DOMのIDL定義などのように、仕様書の中に表やリストの形で掲載されている情報がある。英語に抵抗感さえなければ、こういった翻訳不要の情報を、先行して利用できる。
【4】和書と洋書を併用して学べる
（専門分野によって異なるかもしれないが）国内では、どちらかといえば、入門者向けの書籍が充実している。初心者対象の和書で概要を把握した後に、専門家対象の洋書で細部を確認するのは、技術習得のひとつの方法である。
【5】プレビュー版を試しやすい
Windows 10 Technical Preview が公開された（★2）。既に多くのニュースがネット上を駆け巡っている。
海外ベンダーの製品は、通常、英語版が先行公開される。ダウンロード情報やセットアップ時のメッセージを読みながら試す方が、勘でセットアップするよりも確実だ。
【6】著作権情報を理解しやすい
アプリ開発において、他のプログラマの作った各種サンプルやツール、API、素材などを利用したい場合、使用許諾書や著作権などの情報を、スルーすることはできない。それらのテキストが英語で書かれていても、きちんと理解したうえで利用する必要がある。
【7】サンプルの処理を理解しやすい
海外の開発者が個人的に公開したサンプルコードのコメントは英語であることが多い。コードだけでなく、コメントも読める方が、ロジックを理解しやすい。
【8】開発時の名付けに困らない
クラス名や変数名などに、適切な名前付けをできる。また、分かりやすくインパクトのあるアプリのタイトルを付けることができる。
【9】スペルミスを減らせる
参照先のサブフォルダ名やファイル名にスペルミスがあると、アプリは正しく動作しない。また、RDBのフィールド名やXMLのタグ名にスペルミスがあると、プログラムが正しくても、目的のデータを処理できないなどのバグが生じることがある。
誤ったスペルのスキーマをもとに、大量のデータが蓄積される事態は避けなければならない。最初から正確につづるには、知っている単語は多い方がよい。
【10】困った時に答えを得やすい
英語圏のサポート情報やフォーラムでの質疑応答を参考にしたり、海外の開発者やベンダーの担当者にメールで問い合わせるには、英文を直接読み書きできる方が、意思疎通をはかりやすい。
【11】技術的解決策を検索しやすい
納期がタイトな開発案件で、急いで解決策を知りたいとき、英語のリソースも検索対象とした方が、答えの見つかる可能性が高くなる。
が、メソッド名やプロパティ名などで検索すると、膨大な検索結果が得られてしまい、目的の答えを見つけにくい。絞り込むには、英語で検索キーを的確に指定できるほうがよい。
【12】誤った情報を見分けられる
参考にしたい英語のリソースの中には、開発・実行環境のバージョンが異なるなどの理由により、解説通りの手順では正常に動作しないサンプルもあるだろう。動作環境や概要などの英文を読めば、原因に気付くことができるかもしれない。また、情報を鵜呑みにして適切でない処理を利用してしまうリスクを回避できる。
【13】火元になるリスクを減らせる
翻訳されたニュースやブログ記事の中には、時折、筆者の真意を読み取りにくい微妙な表現がある。原文を読んで確認できれば、早合点や誤解は減り、誤ったツィートを避けられる。
【14】訳文では分かりにくい部分を確認できる
W3Cの標準化仕様を元にした実装の途中で、仕様の詳細を確認するには、原文を直接あたるほうがよい（★3）。いかに優れた翻訳家が訳しても、訳文からは見えてこない部分があるからだ。
「MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL」の使い分けや、複数形と単数形の区別も、原文なら一目瞭然だ。
たとえば XPathの仕様書でいえば、nodesとnodeは、明確に使い分けられている（★4）。
データ処理プログラミングにおいては、指定する対象が、複数のノードなのか、それとも複数の中の特定のノードなのか、また、式の評価結果は複数なのか、それとも単一なのか、といったことを意識している方がよいだろう。
【15】初発情報を発信しやすい
新しい仕様が登場した当初は、日本語のリソースはごくわずかである。いちはやく技術を伝えようとすれば、英語のリソースを避けて通ることはできない（★5）。まだ適切な訳語がない場合は、背景やコンテクストから意味をイメージして、読者の理解を促すような訳語を考える必要がある（★6）
【16】技術者同士の交流の場を拡げやすい
海外エンジニアも参加するコミュニティイベントで交流したり、技術者同士でチャットするには、英語を操れるほうが、友人は増えるだろう。また、海外の開発者とのコラボレーションでは、英文ドキュメントを読み書きできるほうがよいだろう。
【17】ユーザーと意思疎通をはかりやすい
海外ユーザーからの問に答えたり、バージョンアップ要求の内容を理解するには、英語でやり取りできる方がよいだろう。
【18】開発物を宣伝しやすい
宣伝用コピーや行間を読ませる文章を書くスキルがあれば、機械翻訳よりも伝わりやすく表現できるだろう。動画サイトやSNSで、海外ユーザーに向けて開発物を宣伝できれば、ダウンロード数も期待できるだろう。
【19】海外に自分の技術を発信できる
英語でブログを書いたり、SNSを使いこなせれば、自身のもつ技術を、海外に向けて発信できる。日本語で考えて表現したものを英語に訳すのではなく、英語で直接考えて表現できると、より発信力が強まるに違いない。
【20】技術以外の多くの情報を得られる
拡がりのある企画を立てるには、専門分野以外の情報もウォッチしているほうがよい。
現在では、「科学・医学・倫理学」と「技術」には、クロスオーバーする部分が増えている。センサーを使ったアプリ開発についていえば、新たなセンサー素子の研究開発は「科学」であり、センサーと人体のシームレスな接続方法には「医療」が絡み、センサーデバイスがヒトの脳にもたらす影響には「倫理学」が必要になる。
そのうえ「研究」と「開発」もクロスオーバーしている。研究して開発した結果を研究にフィードバックして、ふたたび開発する、といったサイクルもある。
国内の技術情報サイトだけでなく、海外の「科学・医学・倫理学」の「研究」結果の情報を、ウォッチしてみるのもよいのではないだろうか（★7）。
英語に限らず、どのようなスキルでも、持っていないよりは、持っているほうがよい。
ただ、どの程度必要なのか？ といえば、それは意見の分かれるところだ。習得すべきスキルは、それぞれの立場や作業内容によって、異なるのだから。
今はもう、開発者にとって英語は必要なのだろうか？ と悩む時期は過ぎ、（筆者も含め）それぞれの作業に応じたスキルを獲得していく段階なのではなかろうか。
★1 たとえば、msdn の VB や C# の仕様書などである。
msdn C# リファレンス
< http://msdn.microsoft.com/ja-jp/library/618ayhy6.aspx
>
マウスオーバーで原文がポップアップされ、訳文では分かりにくい部分を確認できる。
★2 Windows 10 Technical Preview
< http://windows.microsoft.com/ja-jp/windows/preview
>
マイクロソフトの提供する技術については、公開されるやいなや、その技術分野の Microsoft MVP が紹介記事を書くので、関心ある分野の MVP のブログや facebook を普段からチェックしておこう。
< http://www.microsoft.com/ja-jp/communities/mvp/default.aspx
>
★3 データ・デザインの地平［39］「その記事は「社会的に」正しいか？」（2014/3/24配信）を参照。
< https://bn.dgcr.com/archives/20140324140200.html
>
★4 XMLデータ処理に限って言えば、ElementsかElementか、AttributesかAttributeか......挙げればキリがないが、頻発するのは、NodesとNodeである。
例文で説明しよう。「XML Path Language (XPath) 3.0 W3C Recommendation 08 April 2014」中の「3.3.1 Relative Path Expressions」の、Noteから引用する。
Since each step in a path provides context nodes for the following step, in effect, only the last step in a path is allowed to return a sequence of non-nodes.
単数形と複数形に注意して読むと、次のように解釈することができる。
「ひとつの」パスの「各々の」ステップは、「後続の特定の」ステップに、「複数の」コンテキスト・ノードを渡す。これにより、「ひとつの」パスの中の最後のステップ「だけ」は、ノードなき「ひとつの」シーケンスを返すこともある。
仕様書原文では、このように、単数形か複数形かという点が、正確に記述されている。
だが、日本語では、上記のように、単数形と複数形を明確に区別しすぎると、非常に読みにくい文章になってしまう。
そこで筆者は、解説文中で複数であることを伝えなければならないときは「ノード群」、それ以外を「ノード」と表記するなどして区別していたことがある。ただし、ここでいう「群」とは、あくまで学術用語ではなく、動物の群れをイメージさせる一般用語としての「群」であり、XML入門者向けに限定しての表記である。
★5 拙著「HTMLリファレンス」（1999年刊）の執筆においては、W3CのHTML仕様書の、全要素の全属性についてサンプルを作成して表示確認した。
また、MS-XSLの初発本「XML＋XSLによるWebサイトの構築と活用」（宮坂雅輝共著、筆者はXSLを担当）では、W3CのXSLTワーキングドラフトとMS-XSL（マイクロソフト独自仕様のXSLT）の仕様を突き合わせて確認する必要があった。
XMLマスター資格試験の初発本「XML MASTERテキスト XMLマスター（ベーシック）」（福内かおり共著、筆者はXSLT・XPath・DOM・Namespace・付録ビデオのシナリオを担当）も、W3C仕様書を読んで書く必要があった。新しい技術をひろめるには、原文を避けてとおることはできない。
★6 仕様書中の言葉の訳語が定まっていない場合は、ことばの意味をイメージさせる日本語をひっぱり出す必要がある。
たとえば、XML関連の仕様書に頻発する parse という言葉。現在なら「パース」と訳せばよい。が、XML黎明期にはノンエンジニアの入門者が非常に多く、「パース（構文解析）」という概念自体が知られているとはいえなかった。
そうした場合は、比較的知られた言葉に置き換えて伝える必要がある。筆者は、XML木をたどっていくさまを走査線に見立て、「走査」という言葉を使って解説していた。
★7 たとえば、毎日「SCIENTIFIC AMERICAN」の表紙を眺めるだけでも、リアルタイムで科学の今を実感できる。「日経サイエンス」のWebサイトにまとめ記事もある（リンク規約に抵触するおそれがあるためURIは記載しませんから、bingってください）
--------------------------------------------
オンラインブック「XML設計の心得」（無料、ただしサポートなし）
「筆者最後のXML本」のつもりで書いた本。2009年発行につき、一部内容に古い面はあるが、XMLについて知りたいHTMLのマークアップエンジニアには役立つと思われる。
PROJECT KySS名義だが筆者の単独執筆であり、第4章では、デジクリ連載「データ・デザインの地平」で取り上げてきた、「一意なものとは何か？」という問題についても少し触れている。
< http://sei.seindesign.net/Book1_DL/Default.htm
>
--------------------------------------------
■WWindows 10 Technical Preview のプレビュー版が公開されました。
プレビュー版を体験して、意見をフィードバックしよう。
< http://windows.microsoft.com/ja-jp/windows/preview
>
プレビュー版のリスクを正しく理解するために、インストール前に要一読。
「Windows Technical Preview をインストールする前に」
< http://windows.microsoft.com/ja-jp/windows/preview-faq?ocid=tp_site_insiderforum&#faq=tab5
>
--------------------------------------------
【薬師寺聖／個人事業所 セイザインデザイン】
個人事業所 < http://www.seindesign.net/
>
ブログ < http://blogs.itmedia.co.jp/seindesign/
>
< infosei@seindesign.net >
絵を描き、詩を書き、曲を書き、文を書き、企画書と仕様書を書き、コードを書く、在野の思索家。
科学・医療・福祉分野のXML案件を手掛ける傍ら、XML資格試験の初発本など、書籍や連載を多数執筆（主にPROJECT KySS名義）。
現在は、受託業務から独自発信にシフト中。
Microsoft MVP for Client Development (Oct 2003-Sep 2015)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■クリエイター手抜きプロジェクト［405］書籍編
長期にわたってWeb関係の本を書いているとどうなるか
古籏一浩
< https://bn.dgcr.com/archives/20141027140100.html
>
───────────────────────────────────
先週の土曜日（10/25）に「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」本が発売されました。
・jQuery+jQuery UI+jQuery Mobile逆引きハンドブック
< http://www.amazon.co.jp/dp/486354149X
>
これで56冊目くらいになります。56冊目くらいと書いたのは、出版された順番になっているわけでなく、原稿を書き上げた時点での冊数になっているためです。ちなみに何冊目なのかはプロフィールの所に記載してあります。もしかしたら、奇特なコレクターがいて全部揃えるかもしれないので（と勝手に思っているだけですが）。
ちなみに、この本はもともと一冊の本として出版される予定でしたが、出版社の都合と私の都合とページ数の都合で、三冊に分けて出版されることになりました。最初の一冊はすでに2012年9月に発売されています。
< ・JavaScript逆引きハンドブック
http://www.amazon.co.jp/dp/4863541082
>
残りの一冊は来年出版される予定です。三冊そろって相互に逆引きができるのが理想でしたが、現状ではそれはできていません。まあ、最後の一冊が出ていないからですが。
「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」は残りの一冊の本と相互に逆引きできないと、いまいち使い勝手が悪くなります。最後の一冊が出て増刷がかかるようなら、相互に逆引きできるようになるかもしれません。
ちなみに、この本の企画は2011年のものですので、最後の一冊が出るまでに三年以上かかることになります。Web業界において三年という期間はあまりに長く、三年であれよあれよという間に使われる技術やトレンドが変わってしまいました。
Web業界はドッグイヤーというほど流れが早く、一年前の技術でも陳腐化していることも珍しくはありません。それでも長期間にわたって使われる技術もあります。JavaScriptやjQueryも該当します。これらは、簡単には古びないので、多少時間かけて書いても大丈夫という安心感はあります。
しかし、実際に書いてみたら、そんなにあまくありませんでした。最初の「JavaScript逆引きハンドブック」は企画から一年程度で出版できたので、トレンドや最新技術からひどくずれてしまうことはありませんでした。（書名は「JavaScript逆引きハンドブック」ですが実際には「JavaScript+HTML5逆引きハンドブック」といったところ）
「jQuery+jQuery UI+jQuery Mobile逆引きハンドブック」は大変でした。通常はjQueryで一冊、jQuery UIで一冊、jQuery Mobileで一冊という感じで出版されるのですが、この本はお得感を出すために全部まとめて一冊。つまり三倍の手間がかかるということになります。
まず、jQuery自体がどんどんバージョンアップされてしまうため、それに対応するだけで時間がかかりました。当初はjQueryバージョン1.6.4で、これに対応したバージョンの原稿を書いていました（最終的には2.1.1）。
しかし、今回のjQuery本では他にもjQuery UIとjQuery Mobileにも対応しなければいけません。これらも別々にバージョンアップされていくため、三つのライブラリに逐次対応していく必要があります。
例えば、jQuery 1.6.4では正式な命令だったのが、次のバージョンでは廃止されたことです。執筆中には、このようなことが頻繁にありました。
特にjQuery Mobileは大変でした。jQuery Mobileのバージョンアップのたびに仕様が変更されるため、サンプルプログラムもバージョンごとに書き換えないといけませんでした。また、jQueryを土台にしているため、jQueryで変更があるとjQuery Mobileにも影響が及びます。
頑張って対応させたにもかかわらず、業界のトレンドはあれよあれよと変わっていきました。一年ほど前から作成されるWebアプリケーションではBackbone.jsやAngularJSが使われるようになり、jQueryはトレンドからは少しずつ外れていきました。
企画をたてた三年前はjQuery必須だったのが、中規模〜大規模開発ではjQueryを使うと問題があるので、使用しない方向に変わっていきました。これはjQueryに依存するとセキュリティの問題や不具合が発生した場合、jQueryのバージョンアップを待たなければならず、すぐに対応できないからです。jQueryに依存しないフレームワークなら、すぐに対応させられます。
あまりjQueryに依存しなくてもよくなった理由としては、Webブラウザの標準化が進んだことがあげられます。特にIEは他のブラウザとは異なる命令を使用していたり、動作が異なっていたりと、問題多発で開発のネックとなっていました。
jQueryはIEに対応するために便利だったのが、標準化されてしまえばあまり必要ではないということです（これは本の最初にも、さっくりと書いてあります）。
また、三年前と比べて格段にスマートフォンが使われる割合が高くなったということもあります。パソコンと比べてスマートフォンでは、より新しい技術を使用できる（HTML5+CSS3+JavaScriptに対応）状態になっています。
パソコンなら古いIEが消えるまで三〜五年待たなければいけないのが、スマートフォンなら今すぐに最新技術を使うことができます。また、データ通信量の節約という面からしても、jQuery+jQuery Mobileを使わない方がよいというのもあります（CDNでキャッシュが有効に機能するなら、また違いますが）。
Web関連の書籍は時間勝負なので、少なくとも企画から一年以内に出版しないと大変だというのが実感です。紙ではなく電子書籍なら素早く出版できるのでは？ という人もいるかもしれませんが、書く側で時間かかるので、思ったほど早くは出版できないものです。
一番いいのは企画を考えて一か月以内に全部原稿を書いてしまうことです。が、これはよほど勉強して技術をあげておかないと難しいでしょう。結局のところ、ひたすら勉強あるのみ、ということです（本当は勉強したくないけど...）。
【古籏一浩】openspc@alpha.ocn.ne.jp
< http://www.openspc2.org/
>
と書いてみたものの、年齢を重ねると地域関係の役とかいろいろで時間がとれなくなってくるというオチが待ってました。特に地元の田舎だと20〜40代の人口が少ないので60代（団塊の世代）なら一生に一度しか回ってこない（もしくは永久に回ってこない）役が、40代になると3回くらい回ってきたりします。
20代だとさらに回数が多くなり、役も多くなります。20代だと60代の10倍以上の役などの負担が大きくなる感じです（地元の人口比の場合。20代より80代以上が4倍以上いる^_^;）。
・jQuery+jQuery UI+jQuery Mobile逆引きハンドブック
< http://www.amazon.co.jp/dp/486354149X
>
・データビジュアライゼーションのためのD3.js徹底入門
< http://www.amazon.co.jp/dp/4797368861
>
・D3.js例文辞典
< http://www.openspc2.org/reibun/D3.js/
>
・ExtendScript Toolkit（ESTK）基本編
< http://www.amazon.co.jp/dp/B00JUBQKKY/
>
・Egison言語 例文辞典
< http://www.openspc2.org/reibun/Egison/3.3.2/
>
・4K/ハイビジョン映像素材集
< http://www.openspc2.org/HDTV/
>
・JavaScript逆引きハンドブック
< http://www.amazon.co.jp/dp/4863541082
>
・Adobe JavaScriptリファレンス
< http://www.amazon.co.jp/dp/4844395955
>
・Nexus 7（アンドロイドタブレット）使い方辞典
< http://www.openspc2.org/reibun/Android/Nexus7/
>
・クリエイター手抜きプロジェクト
< http://www.openspc2.org/projectX/
>
・Adobe Illustrator CS3 + JavaScript 自動化サンプル集
< https://www.ddc.co.jp/estore/cgi/item/start.cgi?m=DetailViewer&record_id=243
>
吉田印刷所の「印刷の泉」でも購入できるようになりました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集後記（10/27）
●小3生による「ひみつきち」作りが再び始まった。土曜日の午後に友達とふたりでダンボールの小屋を作った。今度は我が家の庭だ。隣家の庭との境界線フェンスにぴったり着けての建設だ。その部分の隣家の庭は木が何本も植わっていて、こっちが見えないから都合がいい。庭はレンタルなんだから本来なら違法だが、隣家の庭は芝生ではなく木が植わり、鉢が所狭しと置いてある。ふたりは、前回駐車場裏に建ててわずか一日で取り払われた小屋の三倍くらいの規模で建ちあげた。日曜日の午前中には、友達の弟も加わりさらに拡張工事が行われた。彼らが引き上げた後で、雨に備えて大きなブルーシートで覆っておいた。上階から見下ろしたらさぞ異様な光景だろう。
少し前のことだが、「マンションなんかに越してこないで、浦和の一戸建てにいたほうが気楽だったなあ」とうっかり漏らしたら、「じゃあここに来たのは間違いだったとでもいうのか」と短気な妻が怒り出した。「あなたがひとりで決めたんだよ。下見から帰ってきて、内金300万円出せと言ったのは誰よ。ここに来て我々もハニー（犬）も大満足だったはずじゃないの。いまになって何を言ってるのよ」とぶんむくれ。「ちょっと待ってほしい」と天声人語でかわして、誤解を解くために説明、いや弁解を始めたのであった。それは今のわたしの環境の変化だ。マンションは人付き合いがわずらわしい、めんどうくさいと考える人にとっては最高にお気楽な環境なのだが、最近のわたしはそうもいってられなくなった。
それは一年半前に、管理組合の「防災委員募集」に気まぐれで応じたことから始まる。233世帯のマンションで、手を挙げたのがわたしひとりしかいなかった。それからは、毎月行われる理事会に出席し、昨年度は「震災対応マニュアル」制作の事実上の責任者になってしまった。マンションのネットサービス会社から買った「震災対応マニュアル」のテンプレートを、我がマンション用にカスタマイズして、なんとか仕上げたものの、出来は満足できるものではなかった。そこで今期の理事会にも参加し、いまひとりで一から作り直している。理事会は来年の大規模修繕テーマにかかりきりで、震災対応テーマはわたしが責任者にならないと動かなくなっている。
マンションを29フロアー、6ブロックに分け、それぞれにリーダーをおいて……という震災後のシミュレーションをやっていると、さまざまな困難が考えられて、もう無理じゃないかとさえ思う。それでもなんとかルールを設けないと、マンション住民はばらばらの被災者になってしまう。いまのわたしは、自宅さえ守ればいいという立場にない。マンション全体の総力戦をデザインしなければならない。だから、つい「一戸建てにいたほうが気楽だったなあ」と思うのであった。いつでも、どんなときでも、ふと思う。今揺れたら……間に合わない、と。難儀やなあ。「ひみつきち」の家主は、なんの憂いもなく暗くなるまで遊びまくっていていいなあ。（柴田）
●どなたかデザイン、WordPress、コーディング、Flashなどのお仕事を手伝ってくださいませんか？ フットワークが軽く、連絡を密にしてくださる方。費用面の制限があるので（大阪価格）、実績や費用目安などを教えてくださると助かります。
仕事がパンパンで、私生活や健康、趣味などを犠牲にしていたんですが、もう限界に来てまして、過剰反応や逆反応しはじめてます……。どうかお願いします！ ご紹介してくださるとありがたいです。zacke@days-i.comまでお願いします。#拡散希望（←はじめて使った）
態勢が整ったら、打診があった時に微妙な対応しなくて済むし、もっと仕事を受けられる。延び延びになっている仕事も納められる。営業かけることだってできるかも。どうか私を女にしてくださいっ！（えっ?!）
大阪マラソンに出たかったよ〜。コブクロの地下鉄車内ソングがなくなるのは寂しいような。大音量で流れてて、「誰の着うたや、うるさいな〜」と思った。スピーカーが悪いのが原因だと思う。なぜかコブクロファンのN氏が謝ってました（笑）。結構な人数が思ったようで、数日後にはボリュームが絞られるようになったよ。
BGMとして音を絞って音楽鳴らしてもいいかもね。コンビニのBGMみたいに。映画の宣伝とか、地下鉄パワープレイとか（笑）。路線ごとに変えたりして、その路線利用者だけが流行る音楽が出来たりして。カフェミュージック的なのでもいいな。2分程度で終わる超ショートショート朗読とか。あ、今でもテレビ（モニタ）付き列車はあったね。CMや星占いとか流れるやつ。（hammer.mule）
< >
地下鉄で流れるコブクロの曲とメッセージ。
< http://togetter.com/li/726466
>
「大阪市営地下鉄で着うたテロ発生？」
< http://eonet.jp/osaka-marathon/2014/kobukuro/
>
終わってる！ コブクロ「42.195km」期間限定フリーダウンロード
< http://ja.wikipedia.org/wiki/42.195km_(コブクロの曲)
>
< http://emtg.jp/feature/osaka_marathon2014/
>
楽曲解説動画なるものが