Design As Implementation

自分でもしつこいと思うが、アーキテクチャについて。実際に先日経験したことから書き留める。

同僚の開発プロジェクトに助言をしていて、システムのおおまかな構造の把握・設計をレビューした。そのプロジェクトでは、やっかいな既存モジュールを活用することになっており、それらがリスク要因であることは明らかだった。これらのモジュールは、利用側（つまり同僚が開発する方）の責任で「うまく」使ってやらなければならないが、仕様不在なのにモジュール間依存関係ありと、やっかいな代物だった。

この状況に対する僕の提案は、たいしたこともでもないが、要はそれらのやっかいなモジュールに対するアクセスを集約するクラスを用意することだった。そうすれば、何か望ましくない事態に陥ったとき、状況把握や原因究明などに無駄な時間を費やさなくて済む。

 

なんてことはない、提案の実体は「クラスを一つ用意せよ」でしかない。が、僕にはこれがアーキテクチャの本質のように思えてならなくなった。このクラスは、明らかにシステムに対する機能的な要求（外部仕様）からできたものではない。また、なにかの実装を行う過程や結果として必要になったクラスでもない。つまり、設計や実装から生じたものではない。

さらに重要なことは、このクラスの役割（アクセスをひとつにまとめることで、将来的なリスクに備える）は、このクラスの具体的な実装を待たずして「完成」していることだ。比較して、設計というものは、実装が完了するまではただの絵空事でしかない。設計実装の目的はなにかの機能の実現にあるのだから、設計が終わった時点で「機能が完成している」ということはあり得ない。しかし、いま述べているアーキテクチャ的なクラスについては、その存在と周囲の構造を採用すると決めた時点で、その目的が達成される。これは設計と大きく異なる。

 

この構造はもちろん僕が発明したものではなく、ファサードやリファクタリングにおける “Introduce Gateway” と形は同じ。私が違うといっているのは、これらが「なにかとのアクセスをまとめる機能」のための構造なのに対し、「高リスクモジュールとの結合度を下げる」という構造的な決定の結果だということである。（ファサードのページには「サブシステム間の独立性を高める事を目的とする」とあるので、ファサードがアーキテクチャ的に使えることは否定しない。）

最後に、これまでの議論を踏まえて、本稿で示した視点でのアーキテクチャに必要なものを考える。それは（コードではなく）構造によって実現可能な項目と、それに対応する構造例だ。実現可能な項目としては、

とか。ちょっと抽象的であやしい上にほかにもあるかもしれないが、今回取り上げた事例は後者だし、たとえば「Client-Server モデル」などは前者と言えるのではないか。特に後者についてまとめた書籍はあるのかな…。

 

と、蛇足になるが、実はもう一点だけ気になる視点がある。

それは、アーキテクチャが、システム開発を分割する前に適用しなければならない構造の集合である可能性である。可能性といったが、通常一般はこれだろう。「基本設計を始める前に決めておかなければいけないことのうち、構造に関するもの」という定義。

ある程度の規模のソフトウェアは複数人で開発されるから、並行して開発可能な単位にばらされなければならない。これには一定程度の構造が前提になっているが、その中には、一旦個別開発が進行したら後戻りできないものが存在する。たとえば、基本フレームワークだったり、セキュリティ、DBMSとの連携方式など。それらがアーキテクチャと呼ばれていることもあるようだし、位置づけに悩む。基盤的要素であることは間違いないが、構造に類するものなのやら…

 

（つづく）

SEMAT “Call for Action” の日本語訳

いまさらなんだろうけど、SEMATという活動に注目した。

それでいろいろ調べていて見つけたものの一つが、The Essence of Software Engineering: The SEMAT Kernel で、日本語訳が「ソフトウェアエンジニアリングのエッセンス」にある。訳者は SEMAT Japan Chapter のメンバー有志。ただし、もともとの文献が SEMAT vision statement をかなり引用しているようなので、そのような箇所はメンバーの一人、平鍋健児さんが訳した「ソフトウェア工学の方法論と理論」からの転載であることが多いようだ。

 

最初に後半部分を書いたんだけど、調べたらSEMAT自体がイマイチに感じてきたので、そちらを冒頭に持ってくる。

SEMATは「アルファ」という、チームが達成すべき項目（段階付けされた目標を持つ）を使うそうだ。

Alpha Cards（図はソフトウェアエンジニアリングのエッセンスから引用。ただし、当該記事ではこれをカーネルと示しているが、Jacobson による記事には “the SEMAT checkpoints measure outcome. Thus, the universal elements represent achievements rather than documents or artifacts. [omit] There elements are called alphas.” とあるように、誤解がある。）

SEMATいわく、これらアルファカードを参照することによって、次の図のようにチームの状態を把握することができる。

（図はソフトウェアエンジニアリングのエッセンスから引用）

また、チームの現在状態と次の着手内容を明確にするために、”Alpha Abacus”というアイディアも示されている。

 

で、これって結局、複数の観点について行うウォーターフォールと何が違うのかな？？

ウォーターフォールの失敗は反復がないことだけど、アルファも「フィードバック」の遷移矢印が書いてない。じゃあ本質的に反復でないってことだよね。

 

アルファを実際に運用して確実に起ることが、上を参照しながらたとえば “要求 が 受理可能 になったはずなのに、実は 一貫 してないことが判明した” ってやつだ。これはウォーターフォールでは「設計を始めたのに、要求定義が間違っていたことに気がついた」ってのと変わらない。

これが――関係者がハンコを押せばプロジェクトが次状態に確実に移行できるという仮定が――まったく現実的でないが故にウォーターフォールは失敗し続け、そしてSEMATアルファも上手くいかないだろう。

 

「いやアルファはSEMATの構成要素でしかなくて、もっと自由度がある。反復プロセスを扱うときはアルファが反復をしても構わないんだ」という反論もあるかもしれない。いやいやいや、そうやって逃げても問題は解決してない。だって、実際の開発ではなにかが確実に状態Aであるという判断は不可能だ。反復するしないじゃなくて、アルファの状態を決定できるという前提が成り立っていないんだよ。

ああいうブロック図で物事を単純化した人たちは気持ちいいだろうが、それは問題の本質的な複雑さを実践者たちに押しつけたに過ぎないんじゃないかな。

 

というわけで、このアルファについて理解したときに、私はSEMATを見限ることにしました。だいたい混沌を究めた方法論乱立の原因みたいな人たちが集まって、結局新しい飯の種をでっち上げただけって気がするわ。Vision Statement には共感したんだけどなあ。

 

 

以下、最初に書いた文章。

日本語訳が微妙で、誤訳に解釈誤り、果ては訳者による勝手な追記など無茶苦茶だったので書いたんだけど、どうでも良くなってしまった。

「ソフトウェア工学の方法論と理論」は平鍋さんが「とりあえず個人でやりました」的な立ち位置だと思うので特にアレだが、「ソフトウェアエンジニアリングのエッセンス」は SEMAT Japan Ch. としての活動なのだろうから、その内容には対外的な責任が生じるだろうと思う。

 

さてそうしたわけでとりあげる「―エッセンス」を通勤時間に読んでいたのだが、現状を嘆くところが面白かったので、書き手の意図を汲み取りたいと思って、英語の原文にも当たってみた。

そしたら、どうも訳がいまいちじゃないか。（そもそもタイトルからして、”The Essense of Software Engineering: The SEMAT Kernel” が「ソフトウェアエンジニアリングのエッセンス」という訳もどうなのか……。何も訳してない上に肝心の ”The SEMAT Kernel” が抜け落ちてていいのだろうか。）

Call for Action で現状を嘆くところ（私が共感したところ）にはこんなことが書いてある；

Some areas of software engineering today suffer from immature practices. Specific problems
include:

  • The prevalence of fads more typical of the fashion industry than an engineering discipline.
  • The lack of a sound, widely accepted theoretical basis.
  • The huge number of methods and method variants, with differences little understood and artificially magnified.
  • The lack of credible experimental evaluation and validation.
  • The split between industry practice and academic research.

さて日本語訳（太字と項番は私）は、

現在のソフトウェアエンジニアリングのいくつかの分野では、未成熟なプラクティス(immature practices)に苦しめられている。

具体的には、以下の問題を含む。

  1. 言葉の流行が、エンジニアリングの一分野というよりファッション業界のようである。
  2. 堅固で広く受け入れられるような理論的基礎を欠いている。
  3. 非常に多くの方法論(methods)とその派生であふれ、それらの違いはほとんど理解されず作為的に強調されている。
  4. 信頼できる実験的評価(experimental evaluation)と妥当性確認(validation)を欠いている。
  5. 産業界の実践(industry practice)と学界の研究(academic research)の乖離。

らしい。

違和感があるので私が訳してみた；

現在のソフトウェア工学のいくつかの分野では、未熟なやり方に悩まされている。具体的な問題としてたとえば、

  1. 工学分野よりもファッション業界でよくある一時的な流行の蔓延
  2. 広く受け入れられた、強固な理論的基礎の欠如
  3. よく理解されず誇張された違いを持つ、非常に多くの手法と亜種
  4. 信頼できる実験的な評価と検証の欠如
  5. 業界の慣行と学術研究の乖離

 

日本語としてこなれてるかどうかは別にいいんだけど、文意が変わっているようだと参考にしづらいなあ。SEMATに期待する点の一つに “kernel languages” を定義する、という活動があるらしいので、それらの日本語訳についても正確なものをお願いしたいところです。

甲状腺がんと事故との因果関係の帰無仮説は

影響は無いよ派

影響してるんじゃね派

 

甲状腺癌については、もともと「100万人に1人」とかだったわけでしょ。

それで調査してみたら、37万人に50人いた。

そしたら「調査方法が違うからあと数年は待たないと～」

 

事故による甲状腺癌への影響は軽微だ、というのなら、

将来の調査に対する基準を予め言及しておくべきだよね。

「スクリーニングで100万につき34人以上発見されたら有意水準95%で影響があったと判断する」、みたいな。

 

そういう真摯な検証姿勢を見せないまま、ただただ調査結果について事後的にいちゃもんつけるだけじゃあ中立とは言えないんじゃないかな。

ファイルスラック領域の偽装

スラック領域というのが争点の一つらしいですね。

http://bylines.news.yahoo.co.jp/egawashoko/20140323-00033814/

関氏も多くの痕跡が「ファイルスラック領域」から出てきた、と述べた。ファイルスラック領域は、あるファイルの上に、それよりサイズの小さいファイルを上書きした場合、クラスタ内で元データが消去されずに残った部分。この領域に意図的にデータを残すことは「非常に難しい」と関証人は証言した。その理由を、次のように説明した。

「あるデータをファイルスラック領域に残したい場合、そのデータが含まれるファイルより小さいファイルを上書きすることになるが、新たに保存するファイルがHD内のどこに書き込まれるのかを、ユーザは決められない。狙った場所に上書きすることは難しい」

でも、次の手順で書き込めるんじゃ……

  1. 偽装したい内容を含む512バイト（セクタサイズ）のファイルを用意する。
    今回で言えば、「犯罪の証拠となるパス」を含んだデータ。
  2. 全く無関係のファイルを用意する。
    内容などなんでもよいが、ファイルサイズには、条件がある；
    クラスタサイズの整数倍から、少なくともセクタサイズだけ小さくなければならない。
    たとえば、NTFSで一般的な4kbクラスタなら、1バイト～3584バイトのファイルなど。
  3. (2)のファイルについて、セクタサイズの整数倍になるように末尾に0を追加する。
  4. (2)のファイルの末尾に(1)のファイルを連結する。
  5. (2)のファイルのサイズを元のサイズに戻す。

こうすると、(4)の時点で任意の内容を持つセクタをディスク上に作成できて、(5)の処理でファイル領域としてはフリーになるんじゃないかな（未確認）。どうだろう。

あと、真犯人が

「ファイルスラック」とかは知らなかったです。

最近の公判報告サイトで原理を知りましたが、そのストレージ内に以前そういうデータがあった痕跡なら、あってもおかしくないですね。

むしろ言及されていないのが不思議なこととして、ファイルスラックではない普通の削除済み領域からはあまり復元されてないのかしら？

のちに誰かがデフラグ＆ゼロフィルしたのかな？

検察も弁護もファイルスラックのことばかり言うのが少しヘンだなと思います。

っていってたけど、確かに……

空き領域に痕跡を残すんなら、別にスラック領域使わなくともファイルを作って消せばいい。それが最終的にスラック領域になるかどうかは犯行には全然関係ないし、確率的にも単なる空き領域から検出される可能性のほうが高い。また、情報の関連性の証左という点では同じセクタ内に存在しているということが重要なので、スラック領域かどうかはやっぱりどうでもいい。

つまり、検察側としては「スラック領域にあった！」ではなくて、「未使用セクタにあった！」と言えば十分。なのになんで小難しいスラック領域なんてのをわざわざ持ち出してきたのか……。もしかして、この期に及んでも実は検察は技術的内容をよく理解できてなくて、ラックの報告内容をそのまま主張しているだけなんじゃあ……。

スラック領域を持っているファイルへの操作がUSNジャーナルから推測できれば強力な証拠だと思うけど、結局2つの証拠は独立のようなので意味ないし。もしかしてこれが噂の印象操作というやつなのかな。

あとまあ、反対の可能性としては、犯人は証拠隠滅のためにゼロフィル（or ランダムフィル）をしたけど、スラック領域まで気が回らなくて、実は本当に予定外の痕跡なのかもしれないね。ラックは空き領域がクリアされていることに気がついていて、スラック領域に残っていたことの重要性を訴えたい。けど検察が理解できなくて、スラック領域という単語だけ一人歩き、とか。

ゼロフィルはHDDにかなり負荷を掛けるので、フルスピードで実行した場合は使用中のユーザが気がつく可能性がある。デフラグは、この目的にはあまり有効ではないね。

PC遠隔操作 真犯人のメール

進展がありましたね。「自称真犯人からのメール（本日午前11時37分に送付されてきた）」

内容を読んでビックリしたので書いてみます。

以下、”真犯人”が本当にいると仮定して述べていきます。

技術的な内容

GUIDを利用した証拠偽造

AssemblyInfo.cs というのはVisual C#でプロジェクトを作成した際に自動的に作成されるファイルですが、中には（書き換えを前提とした）作成者の情報とプログラム（アセンブリ）を識別するためのGUIDが含まれます。

ここで、もっと簡単に片山さんに容疑を着せるのなら ”kyusuke” とでも書いておけばいいのですが、真犯人はわざわざGUIDを利用したそうです。ということは、真犯人はGUIDが技術的に「乱数に基づいていて、同じ識別子はほぼ生成されない」「VC#が自動的に生成する」「コンパイル後のプログラムにも情報が残る」ことなどを知っていて、応用したってことです。

apkについての言及

真犯人のメールにはこのような記述があります。

携帯マルウェアについては、片山氏がスーファミエミュのapkファイルなど入れて動かしていたので、一瞬のタイミングで紛れ込ませることに成功しました。

apkってなんなのかご存じの方って意外と少ないですよね。Androidのアプリの配布ファイルで、Windowsでいえば.msiみたいなものです。apkはつまりアプリのソフトウェア一式で、普通Google Play経由で端末にインストールされます。

ただし、開発用の特別な方法があります。PCに接続したAndroid端末に対して、adbというプログラム経由で命令すると、独自のapkを端末にインストールできます。これはAndroid開発者なら大抵知っていることですが、エンタープライズやWeb系の開発者には縁のない知識です。真犯人の「apkファイルなどを入れて動かしていた」というのはこの手順を指しているの思います。真犯人はAndroid開発についてある程度詳しいんですね（とはいえ、野良apkを入れるために、詳しくないけどAndroid SDKを入れている人もいるようですが）。

「一瞬のタイミング」というのは、いくら遠隔操作でも端末を物理的に接続させることはできないので、「片山さんがたまたまAndroid端末をPCに接続していて、遠隔操作してもバレないタイミング」ということでしょう。端末が開発者モードになっていれば、「一瞬」というのは大げさな気がしますが。

なんにせよ、真犯人はAndroidにある程度は詳しいということで、C#に加えてJavaについても理解があることが分かります。

プログラムの改造

iesysの開発については次のようにのべています。

egserviceは片山氏のIP【60.36.185.80】の会社のPCから盗んできたものです。

リネームの上、AssemblyInfo.csなどビルド情報をそのままにしたまま、全く違うプログラムに改造しました。

こういうのって、スクリプトキディの域を超えていると思いますが、どうなんですかね。

改造はすでに明らかになったようにコピペの集合のようですが、どんな方法でも所望の成果物を作れるなら、完全にいっぱしの開発者ですよ。

それにすでに私が指摘したように、iesysのC#プログラムはどことなくJavaの香りがします。真犯人はAndroid, Javaに詳しくて、コードはコピペ、クラスレベルの設計は自分の好みに合わせて修正したのだと思います。

計画の周到さ

メールには真犯人の計画的行動についても記載があります。

他に確認したのは、鹿島神宮、鹿島ハイツ、伊勢神宮、道の駅富士川楽座、駿河健康ランド、会津若松駅、会津桧原駅、高崎駅、行田市などです。

すごいと思います。

なぜって、こうして調べた内容を現在でもメールに起こせるということは、真犯人は下準備の段階でも綿密に記録を残しながら行動していたってことです。

最近某研究者が碌な研究ノートを残していなかったと話題になっていますが、言うは易し、普通は個人的な作業の記録を残したりできません。しかしこの犯人の”ノート”にはかなりの情報量がありそうです。そういう、地道で几帳面な性格なんだなと思います。

几帳面な性格

几帳面な性格でいえば、これもその証拠です。

単語の記述

真犯人のメールには、下記の英字の単語が出現します。

1000, iesys, B-CAS, Jane, USB, OS, OCN, PC, IP, toshiba, ＰＣ数台, IE, .exe, .bat, apk

AKB, docomo, 2012.txt, AMD, blog, 2ch

egservice, VC#, AssemblyInfo.cs, cofee, WindowsFormApplication, GUID

3.4×10の38乗, "TKY_DEV_PC07", "TKY_DEV_PC07_2", "Hewlett Packard", auto, 6682

DNA, onigoroshijuzo2

NHK

すべて半角、ＰＣ以外は大文字小文字ばっちり、ハイフンや×記号も正しく使用されています。GUIDはC#クラス的にはGuidなんですが、用語としてはGUIDなので、この場合は全部大文字で正解。メールの文面は何度も推敲された上で送信されたに違いありませんが、そうだとしてもこの程度まで整えられる能力はなかなかすごいと思います。

括弧の対応

また、メール本文には括弧を用いた部分があります。

(OCN)

（多分ネットカフェかな？）

（ほかにもAKB脅迫について、踏み台PCを三重の人と書いたのは勘違いでした＾＾）

（片山氏が福島県出身なので）

（まだ公開されてない…はず）

（長いので以下略）

関心するのは、括弧内が英字だけで構成される場合 (OCN) は半角括弧”()”、日本語文の場合は全角括弧”（）”と使い分けをしている点です。

もしかしたら、真犯人はかな入力なのかも？？？　私もかな入力ですが、かな入力は英字は英字モードで打ちますから、このような使い分けが自然にできます。ローマ字入力だと全部半角とかって人多いですよね。

不思議な点

以上のように純粋に書き物としては感心するような内容なんですが、不思議な点もあります。

ネットカフェPCへの感染

PCを制御下に置いたことについて、

ほか、一時的に使ったＰＣ数台（多分ネットカフェかな？）を、管理下に置きました。

とありますが、いくらなんでも自宅からネカフェにウイルス感染済みプログラムを持参して使いますかね？？

普通にネカフェを利用すればPCはクリーンな状態で起動しているはずだし、ウイルスに感染する可能性はかなり低いと思いますが、、、。ネットカフェPCを制御下におけた経緯の説明はちょっと疑問です。でもネカフェからアクセスがあったということだから、制御できたんだろうし、、、

「スクリプトキディ」について

真犯人は

もともと、私は海外サイトで拾ったウイルスジェネレータで作ったものを使うだけのスクリプトキディでした。

といっていますが、私はこれは謙遜か、正体を誤魔化すための方便だと思います。やってのけた事実を考えれば、「配布されているものを使用しただけ」というレベルではないことは明らかです。もしかしたらプログラミング能力については平均的なのかもしれませんが、行動力に相応しくない慎重さ・思考力などは平均的な人のそれを大きく上回ることは間違いないのでは。

あ、「もともと」なので、今はそれを超える能力を持っているというふうにも読み取れますね。

GUIDの数

GUIDの説明について、

3.4×10の38乗通りのパターンを持つ.NetのGUID(128bit)が一致したならさすがに宇宙規模の奇跡ですよね。

という箇所もあり、これは普通は 2 の 128 乗と書くと思うのですが、なんで基数が10なんだ？と思って調べました。基数変換はlogで計算できますけど、わざわざやらないと思うので。

そしたらこれはGUID値を生成するには？からの情報ですね。

その数値の範囲が2の128乗、つまり「およそ3.4×（10の38乗）」（＝340億の100兆倍の100兆倍）もあるので、現実的に同じIDが生成される可能性はきわめて低い。

でもなあ、なんでわざわざここからのコピペなのかなあ。Google ですぐヒットする Wikipedia でいいと思うし（ここには有効な空間としては2^122とある）。2進数は一般人には馴染みが薄いから、親切に10進数で表現？

わざわざ手間を掛けて@ITあたりから引っ張ってきたんじゃないかと疑っちゃいます。

まとめ

  • 今回のメールは本当に真犯人からのものだと思う
  • かなり几帳面だが、実利があると判断すれば手を抜けるタイプ。
  • 当事者なのに月単位でダンマリできるくらいの忍耐強さがある。
  • 長期間に及ぶ計画を人知れず遂行できる行動力と慎重さがある。

こんなレベルだと、本人がミスしない限り捕まえられないんじゃないかなあ。

構造体とnullの比較

public struct S {

    public readonly long Offset;
    public readonly int Length;

}

こういう構造体があったとして、なぜ

S s;

if (s != null)  { }

がエラーじゃないのか不思議だったんですが、なんてことはない

if (((object)s) != null) { } // auto boxing

ということだったんですね。。。

性能劣化の原因として突き止めるのがすごく大変でした。。。

いくらなんでも警告くらい出すか、True にしちゃえばいいのに。

論文の剽窃は本当に罪なのか

STAP騒動で、論文の一部が他人の論文のコピペであったことが問題になっている。

著作権法があるのだから、独創性のある文章を無断転載すれば著作権法違反になることはもちろん間違いない。

しかし、それは外野がとやかく指摘することなのか？　著作権侵害は親告罪であるから「第三者は告訴できない」という事実の他に、そもそも論文には研究分野独特の価値観があると思う。

いったい何が論文として問題なのか

調べたところ、今回の問題について批評する人は、何が問題なのか良く分らないまま批判している節がある。現状ではSTAP論文は不正確で剽窃・盗用あり、再現不能などとにかく怪しいので、「いろいろ問題だからダメだ！」と書いている。

たとえば

  • 彼女の論文には不適切なデータの処理・加工・流用、そして、文章の剽窃などが認められることから、その研究内容の正確性に疑惑が向けられている。（他研究者の論文からの文章剽窃（盗用）１件目）
    • 内容が正しいかは、情報の出所とは無関係です。
      ○　不適切なデータの処理・加工が不正確な結果に結びつく
      ？　データの流用、文章の剽窃が不正確な結果に結びつく
  • 小保方ら論文著者はKC1などのOCRの誤認識に基づく誤記をそのままにして剽窃していることから、ほとんど剽窃文章の中身を吟味していないことが推測され、実験機器名に関しても実際には使用していないにも関わらずそのまま剽窃して記載してしまった可能性があります。（他研究者の論文からの文章剽窃（盗用）１件目）
    • 不正確であることを（意図的かどうか分かりませんが）ごっちゃにして「剽窃が問題」としています。これは批評に当たっては不誠実な態度だと思います。
  • 約１００ページの論文のうち、冒頭の２６ページを割いて幹細胞研究の意義や背景を説明しているが、うち２０ページはＮＩＨの「幹細胞の基礎」というサイトとほぼ同じ記述だった。（小保方氏の博士論文　２０ページが米ＮＩＨサイトとほぼ同じ）
  • ２０ページがほぼ同じ記述ということは、これは完全に剽窃(ひょうせつ,Plagiarism)であります、他人の技術的成果物をクレジット表示することなく論文に取り込むという、学術論文では絶対にあってはならない禁じ手であります。（学生時代からの剽窃常習犯である小保方晴子さんは完全にアウト）
    • たぶん著作権侵害でありましょうから「あってはならない」のはそのとおりなんですが、なんで「学術論文では絶対にあってはならない」んでしょうかね。個人的に、「絶対」と人が言うときは逆に根拠がないときだと感じています。
  • 研究・出版における不正行為には、明白なデータねつ造だけでなく、別の実験で得たスペクトルデータを偽って載せる、反応収率を過大に表現するなど細かいものもあります。また、論文の剽窃(plagiarism)にもさまざまな形態があり、参考にした文献を故意に引用しない、他の著者の論文から表現の一部を借りながら自分のものとして発表するなども含まれます。特に後者は、論文のintroductionで化合物や反応の重要性を述べるなど誰が書いても似たような内容になるときに起こりやすく、また英語を母国語としない研究者が他の著者のうまい表現を借りたくなる気持ちは分かるが、あくまで許されることではないと指摘します。（理研・野依理事長が研究・出版倫理と不正行為についてAdv. Synth. Catal.誌に寄稿）
    • なんで「あくまで許されることではない」のでしょう？　法律で決まっているから？
      まーそうですけど、法律は事後的・人為的に設けられたものですから、ダメな理由は法律に依らずに説明されるべきでしょう。

私が思うに、STAP論文の論文としての問題点はただ一つ、内容が不正確であることです。剽窃は当事者間の利害ですから、第三者としての関係分野の研究者であれば、STAP細胞があるのかないのか、それだけが重要でしょう。小保方さんの人となりとか、ぱくりぱくられというのはどうでもよろしい。それらが気になるのは小保方さんと一緒に仕事するか迷っている人や、弁護士くらいじゃないでしょうかね。

論文は小説ではない

普段私たちが目にする文章というのは、事実よりも表現に価値があるものがほとんどです。小説がそうだし、歌詞もそう、面白いブログ記事、まとめ記事など。どれも、同じ情報をどうやって日本語として表現するかで面白さがかなり変わる。だから表現を他人にコピーされると困るわけです。俺の飯の種を盗むな、と。小説のコピーを勝手に売られたら自分の収入が減りますからね。

しかし、論文は小説などと異なり、表現よりも事実に価値があるものです。

たとえば同じようなものに、速報のニュースがあります。「オリンピックは東京に決定」など。こういったものは、どのメディアも、新規性・速報性・正確性を追求していて、表現を一番には考えていません。別のメディアが後から似た表現で同じ内容を配信することなど日常茶飯事だとは思いますが、どこも問題にしません。これは正確な事実を早く配信することが価値なのであって、表現はコピーされようがぜんぜん痛くもかゆくもないからです。一番に届けることが大切なんです。

論文も一緒で、新規性のある内容を、誰よりも先に発表することが一番大切です。ですから、確かに盗用は違法で権利者は告訴の権利がありますが、割とそんなことどうでもいい（というのが研究者の感覚）だと思います。そりゃもちろん苦労して考えたのを丸ぱくりされれば腹は立ちますが、それで何か自分の利益が失われたわけではないのです。ここが小説家と大きく違います。

今回、「剽窃」「盗用」が大問題だ（＝単なる法律違反ではなく、外野が殊更に騒ぎ立てる必要がある）という態度の人たちは、何か論文を小説と勘違いしているんじゃないでしようか。だから、指摘は確かに正しいのですが、なんだかサッカー選手を土俵上に連れてきて「なんで転んだんだ！」という感じです。門外漢なら黙っているのが大人の対応だと思います。

著作権法を盾にした批判は有益ではない

先日、某Kシェフが他店のレストランの料理を評点していて、あまりに美味しかったのか「うちの店でも出します！」と断言し、周囲の共演者に咎められても再度提供すると言っていたのを見ました。見ててドン引きでした。料理のレシピは著作権法の保護下にありませんから著作権侵害には当たりませんが、もしこれを川越シェフがクレジットなしで提供するとすれば「剽窃」にはあたりそうです。でも、合法です。

なんか腑に落ちません（私は）。　思うに、現状の著作権法は不自然です。

そもそも、人権や所有権と異なり、「著作権」というのはなんだかはっきりしない権利です。

確かに、私の作ったソフトウェアを勝手にコピーされると困りますし、小説だってそうでしょう。でもレシピもそうでしょ？

私は法律の専門家ではないですが、

では、著作物であるレシピ本を見て実際に料理を作って販売したら、著作権侵害にあたるのでしょうか？

これは著作権侵害にはあたりません。なぜなら、レシピという「表現」のもとになっている調理方法そのものは「アイデア」に過ぎず、アイデアを具現化することは著作権者だけに認められている権利ではないからです。

著作権法は「アイデア」ではなく「表現そのもの」を保護するという大原則があります。たとえば、「未来から猫型ロボットがやってきて、便利な道具を出してくれる」というアイデアを使ってマンガを描いて出版しても、イラストやストーリーが独自のものであれば、問題はありません。
同様に、「アイデア」であるレシピを使って料理を作り販売しても、著作権侵害にはあたらないのです。（「料理レシピ」に著作権はない!?）

とのこと。じゃあ論文の背景なんかは誰が書いても同じになりやすいのだから、著作権法の範囲とはあまり言えない、すくなくとも積極的に保護すべき対象とはいえない。論文の文章の盗用は権利者の利益をほぼ害さないのに大問題で、料理のレシピは権利者の利益を害す可能性があるのに合法だから問題ではない。

でもまてよ、あるレシピから同じように料理を作って同じように盛りつけしたら、その料理は「レシピの表現そのもの」だから、保護の対象なのかな。小説文章が物理的なインクではなく言葉という概念として保護されていることから類推すると、似たような盛りつけの料理が「ある著作物」として保護される可能性があるってこと？　文芸、学術、美術又は音楽の範囲に属さないからダメ？　でも料理には美しさも必要でしょ。わけわからんよ著作権法。

こんな分けわからんことになるのは、批評が「著作権法違反か」となっているからです。できたら、「その転載によって権利者の利益が害されたか」を基準に批判すればよいのではないでしょうか。もともと創作者の権益を確保することが著作権法の理念だと思いますし。

論文の文章を盗用することの問題

というわけで、論文の文章の盗用は、第三者的には大したことじゃないので、批判はどうかと思います。

ただ、もっと大きな視点では研究論文における盗用は悩ましい問題です。簡単に言うと、盗用したから研究がダメなのではなく、研究計画能力が低いから盗用するんです。そして、研究計画能力とかの訓練のためには、盗用せずに自分で考えることが必要です。

優れた研究計画を立てられる能力があれば、論文の文章なんかわざわざ盗まなくても自分でちゃちゃっと書けるんですよ。小説じゃないから、美しい表現なんて要らないし、目的と結果が明らかであれば、そこまでの導入や、立証すべき事実なども自明です。それを実際に実験することは大変でも、論理を考えることは難しくない――能力が足りていれば。

ですから、盗用がたとえ事実上問題にならなくとも、30歳前後の研究者は自分の言葉で研究の意義を説明しないといけない。それが研究の論理を組み立てる訓練になるからです。（30後半になってできないようなら研究者向いてない。）

ところで「剽窃」って？

Wikipedia の定義によれば、「剽窃」は必ずしも違法とはいえないんですが、なんで批判している人たちは「剽窃」っていうんですかね。第三者が批判するなら「盗用」とか「侵害」としないと大きなお世話だと思うんですが。

不正確だと批判している人たちが、あまり正確さを重視しないのかな。

それとも、よく考えず、「思い至らなければ故意ではないからセーフ」ということなのかな。

大学関係ではよく剽窃NOといっています（慶応大学が剽窃＝違法とする根拠は謎ですが）。教育においては、たとえ相手が同意しようとも、レポートや論文に転載するようなこと（剽窃）は有害だからです。つまりコピペすんなと。違法性の問題ではなく、自分で考えろってことを言いたいので、これは「剽窃NO」であっていますね。