●賢く記事を読んで利用する
いまや、ネット上のテキストにおいては、情報の公開速度のほうが、表現の精度よりも、重視されがちな時代です。論文でもニュース記事でも製品レビュー記事でも技術解説記事でも、時代を先取りした（あるいは時代に並走した）公開のタイミングが非常に重要になっています。
その弊害でしょうか、「日本語による文章の手本」であるはずのニュース記事でさえ、目を皿にして本文の中に5W1Hを探さなければならないことがあります。
技術解説記事の場合は、動作環境や開発環境という条件が絡んでいるため、現バージョンの間に公開することが、なにより優先されがちです。このような時代には、ライターが時代に合わせた執筆姿勢を身に付けるだけでなく、読者側にも賢い記事の読み方を身に付ける姿勢が必要になります。
サンプルプログラムを含む技術解説記事の場合は、次の2点に気を付けて、解説文を読み、コードを利用するとよいでしょう。
いまや、ネット上のテキストにおいては、情報の公開速度のほうが、表現の精度よりも、重視されがちな時代です。論文でもニュース記事でも製品レビュー記事でも技術解説記事でも、時代を先取りした（あるいは時代に並走した）公開のタイミングが非常に重要になっています。
その弊害でしょうか、「日本語による文章の手本」であるはずのニュース記事でさえ、目を皿にして本文の中に5W1Hを探さなければならないことがあります。
技術解説記事の場合は、動作環境や開発環境という条件が絡んでいるため、現バージョンの間に公開することが、なにより優先されがちです。このような時代には、ライターが時代に合わせた執筆姿勢を身に付けるだけでなく、読者側にも賢い記事の読み方を身に付ける姿勢が必要になります。
サンプルプログラムを含む技術解説記事の場合は、次の2点に気を付けて、解説文を読み、コードを利用するとよいでしょう。
（1）変数とリテラルの扱い
変数の名付けが明確か、不使用の変数が放置されていないかをザッとチェックして、変数の表すものを理解します。そのうえで、自分が知りたい処理の中の、着膨れしている部分（たとえば表示｜非表示の切り替えのような表現に関する部分）を取り除き、シンプルな形にしたうえで、ロジックを理解します。
処理への理解なく、コピペして適当な変数名に変えて流用することは避けるべきです。バグの原因を特定しにくくなります。
また、コード中の、整数リテラルや実数リテラルにも注意します。たとえば、速度、角度、高さ、幅、範囲などを表す値が直接コード内で指定されている場合、それらの値の根拠を、コメントや記事から読み取る必要があります。根拠を理解しないまま利用することは避けましょう（★1）。
（2）一次情報か、n次情報か
どのような記事も、言語仕様やクラスライブラリなど、何らかのリソースに基づいて書かれています。リソースには、一次情報からn次情報まで、いろいろなものがあります。
一次情報とは、たとえば、W3Cの仕様書やmsdnのクラスライブラリなどのドキュメントです（★2）。そして、「W3Cやmsdnのドキュメントを読み解いて書かれた記事」は二次情報です。さらに、「『W3Cやmsdnのドキュメントを読み解いて書かれた記事』を参考にして書かれた記事」は三次情報になります。
伝言ゲームのように、n次情報のnの値が大きいほど、仕様の解釈のズレは拡がりがちです。一次情報についてきちんと触れられている記事を選択するか、n次情報を基にした記事を読んだ後で、一次情報にもあたるとよいでしょう。
●プロを名乗るには、高い壁を超える
技術解説記事は、対象となる読者のレベルを想定したうえで、執筆されています。おおまかには、次のような設定です。
・入門者向け：技術者の裾野を拡大する「敷居は低く」
・プロ志願者向け：プロの壁を乗り越えさせる「壁は高く」
・プロ向け：高度な技術情報を提供する「雲を超えて」
入門者向けの記事は、「真似するだけでよく、すぐに動く」即効性のあるコードを中心としたものに傾きがちです（★3）。
プロ志願者向けの記事は、即効性はありませんが、しくみが理解できるように書かれています。そして、プロ向けには、先輩技術者ならではのノウハウも掲載されています。読者は、自分の目的に合った記事を読むことが重要です。
ネット上のリソースが充実した現在では、入門者がまたぐ敷居は低くなりました。エンジニア育成には、「敷居は低く、壁は高く」が基本です。敷居が低くなったぶん、技術者の裾野拡大やプログラミングの教養化は進むことでしょう。
ところが、敷居が低くなると、それに合わせて壁まで低くなる傾向にあります。プロ志願者の読者は、自分が「壁」だと思うよりも上のレベルの記事も読む必要があります。
昔は、プログラマとはソフトウェア・エンジニアであり、エンジニアの一種でした（★4）。壁を超えなければ、ノン・エンジニアのプログラマにとどまってしまいます。社会基盤を堅実に支えるエンジニアになるには、「高い壁」を超える必要があります（★5）。
●ロジックよりも、コンセプトに着目する
記事の着想と内容と表現のクオリティは別物です。表現は拙いけれども着想の優れた記事もあれば、その逆で、着想や内容はありきたりか、あるいは問題点があるけれども、正確無比なロジックで固められた記事もあります。
読者には、着想の部分にあたる、記事の本質を見抜く姿勢がもとめられます。
着想は、それが立ち現れるときには、言葉やコードの形を成しておらず、包括的で俯瞰的な、コンセプトでしかありません（★6）。
そのコンセプトを表すイメージは、ただちに言語やコードといった記号に置き換えられるものではありません。著者は、記号を当て嵌め、なければひねり出し、変換して、ロジックを積み上げていくのです。
もしロジックに破たんがあったとしても、だからといって、コンセプトそのものが否定されるものではありません。逆に、ロジックが正しくても、コンセプトが誤っているなら、積み上げたロジックは足元から崩れてしまいます。
重要なのは、（ヒトでなく計算機でも積み上げることができる）ロジックよりも、（ヒトならではの気付きである）コンセプトの方です（★7）。
すばらしいコンセプトの記事が、ロジックの検証に時間がかかりすぎるために、生煮えのまま公開されることもあるでしょう。
そういった記事に遭遇した時、コンセプトのクオリティをスルーして、表現のクオリティにこだわりすぎると、気付きの瞬間を、インスパイアされる機会を逃すことになってしまいます。それは、実にもったいないことです。
未来の社会を作るのは、ロジックの根底に、新しいコンセプトがある記事です。
●「社会的に」正しい記事を受け入れる
スタンドアロンから社内サーバへ、そしてISDNから、常時接続へ。PC間の境界は消え、情報はゆるやかに接続されるようになりました。
著作物の引用、n次利用、まとめ、要約は増えています。オリジナルからの派生情報が増えれば、誰もがそうしているからという理由で、流用は常識化していきます。
自他境界が曖昧で情報を共有していた時代から、所有の概念のある時代へ、そして再び自他境界がゆるやかに崩れて情報が接続される時代へ移り変わると、著作権の扱いは大きく変わります。それに伴い、もはや限界にある商標とドメインの扱いも変わります。
各個体の脳は集合知のひとつのノードにすぎないものとなり（★8）、脳機能センシングは脳内だだもれ社会を正当化します。
（現在の）盗用は（未来には）利用と言われるようになり、誰が考えたのか、誰が作ったのか、誰が発表したのかは、重要ではなくなります（★9）。未来の社会で歓迎されるのは、生成過程を問わず、社会に利益をもたらす記事です。
「社会的な」正しさは変遷します。この10数年でサンプルプログラムの二次利用は当たり前になり、敷居は低くなりました。そして、今度は、情報がフュージョンする時代を迎えようとしています。
読者には、そのときどきで、「社会的に」正しい記事を受け入れ、読みこなしていく姿勢が、もとめられています。
★1 筆者は、自動的に値を取得する処理を記述できるケースでは、リテラルの使用は最小限にとどめたほうが、読者には利用しやすいのではないかと考えています。
★2 筆者は、これまで、XMLをテーマとする多数の書籍や記事を執筆してきていますが、それらは一次情報（W3Cの英文仕様書）に基づいて書かれています。
W3Cの英文仕様書を読んで書かれた記事と、W3Cの英文仕様書の日本語訳を読んで書かれた記事と、「『W3Cの英文仕様書の日本語訳を読んで書かれた日本語の記事』を読んで書かれた記事」では、仕様の解釈が微妙に異なる可能性を否定できません（もちろん同じである場合もあります）。
★3 上級技術者が、入門者向けの記事やプロ志願者向けの記事を読んで、得るものがない低レベルの記事であると評価するのは間違いです。上級技術者は、自分の身の丈を超える記事を選択すべきです。
★4 筆者はプログラミングを受注したり、プログラミング本を執筆しており、顧客からはプロのプログラマだと思われています。が、自分ではプログラマを名乗ったことはありません。デザインのプロですから、他の分野のプロの壁の高さを分かります。プログラマの壁は、まだ登っている途中だと思っています。
★5 たとえばXMLでいえば、ウェルフォームドなXML文書を作成できることは、敷居をまたぐことにすぎません。XMLのデータ・デザインを業務として行うには、一次情報のW3C仕様書を理解する、という壁を超えなければなりません。
その壁を超えたうえで、対象とするデータの意味を理解し、あらゆる角度から構造を検討し、未来の運用期間終了日までの社会を俯瞰できなければなりません。入門者の定義したスキーマが増えれば増えるほど、再利用しにくい構造の文書が蓄積されるようになり、後々問題を引き起こします。
★6 ──アダマール自身もこう書いている．私が実際に思考しているときには，頭のなかには言語はまったく存在しないと私は主張できる．……私は，「思考は，言語で具体化されるとき死滅する」と書いたショーペンハウエルにまったく同意する．（ロジャー・ペンローズ「皇帝の新しい心」P.479、林一訳）
★7 このコンセプトのイメージを操る思考方法は、言葉を持たない乳幼児の思考の発展形です。しかし、言語を使う機会が増えるほど、衰えていくようです。
筆者は乳児のときから20代後半までイメージで考えていました。広告コピーやマニュアル原稿といった言葉を扱う仕事が増えてから、言語で考えるようになってしまいました。これにより、思考速度は大いに低下しました。言葉による思考速度には限界があります。人類は、言葉を超えた高速思考へ進化していくでしょう。
★8 「データ・デザインの地平［03］子ノード化する脳」参照。
< https://bn.dgcr.com/archives/20110214140400.html
>
★9 いま問題視されている、作曲家の事件も論文事件も、未来には問題視されないものとなる可能性すらあります。
----------------------------------------------------------------------
■【重要】
2014年4月9日（日本時間）に、Windows XP、Microsoft Office 2003、Internet Explorer 6 のサポートが終了します。
「Windows XP、Office 2003サポート終了の重要なお知らせ / よくあるご質問」を参照してください。
< http://www.microsoft.com/ja-jp/windows/lifecycle/xp_eos/faq.aspx
>
■de:code
マイクロソフト テクノロジの方向性と最新情報が分かる、今年度最大のテクニカル イベント。
< http://www.microsoft.com/ja-jp/events/developer/default.aspx
>
----------------------------------------------------------------------
【薬師寺聖／個人事業所 セイザインデザイン】
個人事業所 < http://www.seindesign.net/
>
< infosei@seindesign.net >
絵・音・詩・文・コードを扱うフリーのクリエーター、思索家。
エンジニアリング会社を経てデザイン事務所に勤務後、XML1.0勧告翌月に退職して開業。科学論文や電子カルテを扱うXML案件を手がける傍ら、XMLやRIAに関する書籍や連載を多数執筆（主にPROJECT KySS名義）。
現在は、受託業務から独自開発にシフト中。
Microsoft MVP for Client Development （Oct 2003-Sep 2014）
変数の名付けが明確か、不使用の変数が放置されていないかをザッとチェックして、変数の表すものを理解します。そのうえで、自分が知りたい処理の中の、着膨れしている部分（たとえば表示｜非表示の切り替えのような表現に関する部分）を取り除き、シンプルな形にしたうえで、ロジックを理解します。
処理への理解なく、コピペして適当な変数名に変えて流用することは避けるべきです。バグの原因を特定しにくくなります。
また、コード中の、整数リテラルや実数リテラルにも注意します。たとえば、速度、角度、高さ、幅、範囲などを表す値が直接コード内で指定されている場合、それらの値の根拠を、コメントや記事から読み取る必要があります。根拠を理解しないまま利用することは避けましょう（★1）。
（2）一次情報か、n次情報か
どのような記事も、言語仕様やクラスライブラリなど、何らかのリソースに基づいて書かれています。リソースには、一次情報からn次情報まで、いろいろなものがあります。
一次情報とは、たとえば、W3Cの仕様書やmsdnのクラスライブラリなどのドキュメントです（★2）。そして、「W3Cやmsdnのドキュメントを読み解いて書かれた記事」は二次情報です。さらに、「『W3Cやmsdnのドキュメントを読み解いて書かれた記事』を参考にして書かれた記事」は三次情報になります。
伝言ゲームのように、n次情報のnの値が大きいほど、仕様の解釈のズレは拡がりがちです。一次情報についてきちんと触れられている記事を選択するか、n次情報を基にした記事を読んだ後で、一次情報にもあたるとよいでしょう。
●プロを名乗るには、高い壁を超える
技術解説記事は、対象となる読者のレベルを想定したうえで、執筆されています。おおまかには、次のような設定です。
・入門者向け：技術者の裾野を拡大する「敷居は低く」
・プロ志願者向け：プロの壁を乗り越えさせる「壁は高く」
・プロ向け：高度な技術情報を提供する「雲を超えて」
入門者向けの記事は、「真似するだけでよく、すぐに動く」即効性のあるコードを中心としたものに傾きがちです（★3）。
プロ志願者向けの記事は、即効性はありませんが、しくみが理解できるように書かれています。そして、プロ向けには、先輩技術者ならではのノウハウも掲載されています。読者は、自分の目的に合った記事を読むことが重要です。
ネット上のリソースが充実した現在では、入門者がまたぐ敷居は低くなりました。エンジニア育成には、「敷居は低く、壁は高く」が基本です。敷居が低くなったぶん、技術者の裾野拡大やプログラミングの教養化は進むことでしょう。
ところが、敷居が低くなると、それに合わせて壁まで低くなる傾向にあります。プロ志願者の読者は、自分が「壁」だと思うよりも上のレベルの記事も読む必要があります。
昔は、プログラマとはソフトウェア・エンジニアであり、エンジニアの一種でした（★4）。壁を超えなければ、ノン・エンジニアのプログラマにとどまってしまいます。社会基盤を堅実に支えるエンジニアになるには、「高い壁」を超える必要があります（★5）。
●ロジックよりも、コンセプトに着目する
記事の着想と内容と表現のクオリティは別物です。表現は拙いけれども着想の優れた記事もあれば、その逆で、着想や内容はありきたりか、あるいは問題点があるけれども、正確無比なロジックで固められた記事もあります。
読者には、着想の部分にあたる、記事の本質を見抜く姿勢がもとめられます。
着想は、それが立ち現れるときには、言葉やコードの形を成しておらず、包括的で俯瞰的な、コンセプトでしかありません（★6）。
そのコンセプトを表すイメージは、ただちに言語やコードといった記号に置き換えられるものではありません。著者は、記号を当て嵌め、なければひねり出し、変換して、ロジックを積み上げていくのです。
もしロジックに破たんがあったとしても、だからといって、コンセプトそのものが否定されるものではありません。逆に、ロジックが正しくても、コンセプトが誤っているなら、積み上げたロジックは足元から崩れてしまいます。
重要なのは、（ヒトでなく計算機でも積み上げることができる）ロジックよりも、（ヒトならではの気付きである）コンセプトの方です（★7）。
すばらしいコンセプトの記事が、ロジックの検証に時間がかかりすぎるために、生煮えのまま公開されることもあるでしょう。
そういった記事に遭遇した時、コンセプトのクオリティをスルーして、表現のクオリティにこだわりすぎると、気付きの瞬間を、インスパイアされる機会を逃すことになってしまいます。それは、実にもったいないことです。
未来の社会を作るのは、ロジックの根底に、新しいコンセプトがある記事です。
●「社会的に」正しい記事を受け入れる
スタンドアロンから社内サーバへ、そしてISDNから、常時接続へ。PC間の境界は消え、情報はゆるやかに接続されるようになりました。
著作物の引用、n次利用、まとめ、要約は増えています。オリジナルからの派生情報が増えれば、誰もがそうしているからという理由で、流用は常識化していきます。
自他境界が曖昧で情報を共有していた時代から、所有の概念のある時代へ、そして再び自他境界がゆるやかに崩れて情報が接続される時代へ移り変わると、著作権の扱いは大きく変わります。それに伴い、もはや限界にある商標とドメインの扱いも変わります。
各個体の脳は集合知のひとつのノードにすぎないものとなり（★8）、脳機能センシングは脳内だだもれ社会を正当化します。
（現在の）盗用は（未来には）利用と言われるようになり、誰が考えたのか、誰が作ったのか、誰が発表したのかは、重要ではなくなります（★9）。未来の社会で歓迎されるのは、生成過程を問わず、社会に利益をもたらす記事です。
「社会的な」正しさは変遷します。この10数年でサンプルプログラムの二次利用は当たり前になり、敷居は低くなりました。そして、今度は、情報がフュージョンする時代を迎えようとしています。
読者には、そのときどきで、「社会的に」正しい記事を受け入れ、読みこなしていく姿勢が、もとめられています。
★1 筆者は、自動的に値を取得する処理を記述できるケースでは、リテラルの使用は最小限にとどめたほうが、読者には利用しやすいのではないかと考えています。
★2 筆者は、これまで、XMLをテーマとする多数の書籍や記事を執筆してきていますが、それらは一次情報（W3Cの英文仕様書）に基づいて書かれています。
W3Cの英文仕様書を読んで書かれた記事と、W3Cの英文仕様書の日本語訳を読んで書かれた記事と、「『W3Cの英文仕様書の日本語訳を読んで書かれた日本語の記事』を読んで書かれた記事」では、仕様の解釈が微妙に異なる可能性を否定できません（もちろん同じである場合もあります）。
★3 上級技術者が、入門者向けの記事やプロ志願者向けの記事を読んで、得るものがない低レベルの記事であると評価するのは間違いです。上級技術者は、自分の身の丈を超える記事を選択すべきです。
★4 筆者はプログラミングを受注したり、プログラミング本を執筆しており、顧客からはプロのプログラマだと思われています。が、自分ではプログラマを名乗ったことはありません。デザインのプロですから、他の分野のプロの壁の高さを分かります。プログラマの壁は、まだ登っている途中だと思っています。
★5 たとえばXMLでいえば、ウェルフォームドなXML文書を作成できることは、敷居をまたぐことにすぎません。XMLのデータ・デザインを業務として行うには、一次情報のW3C仕様書を理解する、という壁を超えなければなりません。
その壁を超えたうえで、対象とするデータの意味を理解し、あらゆる角度から構造を検討し、未来の運用期間終了日までの社会を俯瞰できなければなりません。入門者の定義したスキーマが増えれば増えるほど、再利用しにくい構造の文書が蓄積されるようになり、後々問題を引き起こします。
★6 ──アダマール自身もこう書いている．私が実際に思考しているときには，頭のなかには言語はまったく存在しないと私は主張できる．……私は，「思考は，言語で具体化されるとき死滅する」と書いたショーペンハウエルにまったく同意する．（ロジャー・ペンローズ「皇帝の新しい心」P.479、林一訳）
★7 このコンセプトのイメージを操る思考方法は、言葉を持たない乳幼児の思考の発展形です。しかし、言語を使う機会が増えるほど、衰えていくようです。
筆者は乳児のときから20代後半までイメージで考えていました。広告コピーやマニュアル原稿といった言葉を扱う仕事が増えてから、言語で考えるようになってしまいました。これにより、思考速度は大いに低下しました。言葉による思考速度には限界があります。人類は、言葉を超えた高速思考へ進化していくでしょう。
★8 「データ・デザインの地平［03］子ノード化する脳」参照。
< https://bn.dgcr.com/archives/20110214140400.html
>
★9 いま問題視されている、作曲家の事件も論文事件も、未来には問題視されないものとなる可能性すらあります。
----------------------------------------------------------------------
■【重要】
2014年4月9日（日本時間）に、Windows XP、Microsoft Office 2003、Internet Explorer 6 のサポートが終了します。
「Windows XP、Office 2003サポート終了の重要なお知らせ / よくあるご質問」を参照してください。
< http://www.microsoft.com/ja-jp/windows/lifecycle/xp_eos/faq.aspx
>
■de:code
マイクロソフト テクノロジの方向性と最新情報が分かる、今年度最大のテクニカル イベント。
< http://www.microsoft.com/ja-jp/events/developer/default.aspx
>
----------------------------------------------------------------------
【薬師寺聖／個人事業所 セイザインデザイン】
個人事業所 < http://www.seindesign.net/
>
< infosei@seindesign.net >
絵・音・詩・文・コードを扱うフリーのクリエーター、思索家。
エンジニアリング会社を経てデザイン事務所に勤務後、XML1.0勧告翌月に退職して開業。科学論文や電子カルテを扱うXML案件を手がける傍ら、XMLやRIAに関する書籍や連載を多数執筆（主にPROJECT KySS名義）。
現在は、受託業務から独自開発にシフト中。
Microsoft MVP for Client Development （Oct 2003-Sep 2014）