採用されたのは大変ありがたいことだ。素直に感謝したい。
シンポジウムは2019年3月27日(水)～28日(木)に開催予定なので，論文はリアルタイムOSのテストの関することで，論文の詳しい内容については触れられないが，毎度のことながら査読コメントにはげっそりさせられる。
誤字や内容についての指摘はありがたく指摘を受け入れたいのだが，論文の査読コメントはなぜ，匿名なのだろうか。それってなんで隠すのだろうっていつも思う。
※1 JaSST では査読時は投稿者が誰か知らされていないという指摘があったため訂正。
査読者がもしも知り合いだったら失礼になるので変なこともかけないのだが，査読者が誰だか分からないから遠慮すべきかどうかもまったくわからない。だから，失礼かもしれないが，言いたいことを言ってしまおうと思う。
査読者が匿名なのは，おそらく投稿者である下々の者が，偉い先生方に対してコメントに反論するなど，あり得ない。受け付けないというということなのだろう。※2 でも，論文査読時のその上から目線が大っ嫌いだ。査読者がそういうつもりでなくても，査読のシステムがそうなっている。査読者は名乗らない，査読に対する意見は受け付けないというシステムなのだ。
※2 投稿者/査読者 ともに匿名にすることで公平性を担保する意図があるそうです。
そして，いつも「フン」と思うのは，論文の作法に則っていないという指摘だ。「最初に他の研究の問題点や違いが述べられていない」とか「考察が先，結論が後」とか，「参照する他の論文をもっと掲載せよ」といったコメントは，ごもっともなのだろうが，本質的な話じゃないなと思う。
例えば，論文の投稿者はその学会やシンポジウムに観客を呼び込むための大切なネタ元であると考える。そうすると，学会やシンポジウムの主催者や査読者は次もその次も気持ち良く論文を投稿してもらう必要がある。ならば，論文査読コメントは次のような書きぶりにしたらどうだろうか。
【論文査読結果のお知らせ】
この度は，○○学会に論文をご投稿いただき，まことにありがとうございます。投稿いただいた論文を拝読だせていただきました。
△△に関する研究は貴重であり，たいへん興味深い内容です。□□の結果はソフトウェアのーーを向上させることのつながると思います。
なお，ーーの部分については，さらにーーのような掘り下げを行えば，さらなる展開が見られるのではないかと思います。
：
非常に形式的な指摘で恐縮ですが，ーーの部分は，ーーのようにした方がより論文として説得力が高まると思われます。また，本論文と同じような研究があれば，読者の参考となるため，ーーのデータベースで関連する論文を検索して，参照論文として掲載してはいかがでしょうか。
：
○○学会にて，本研究のご発表をお待ちしております。また，ーー様の更なる研究と投稿をお待ちしております。
【例示終わり】※査読がコメントがこんな感じになることはあり得ないけど。
ソフトウェアのレビューにレビューワとして参加するときは，できるだけ本質的なことを重点的にディスカッションし，形式的な問題はレビューが終わったあとにこっそり指摘したり，メールでお知らせしたりして，プロジェクトメンバのモチベーションが下がらないように気を遣ったりしている。
それは，レビューではエンドユーザーに対する価値向上につなげるために指摘をするのあって，ルールやシステムへの逸脱を是正することが最終目的ではないからだ。ルールやシステムに従うことはあくまでも間接的にエンドユーザーに対する価値向上につながっているのだということをすっかり忘れるソフトウェアの品質保証担当もいる。ルールを守ることが目的になっているケースだ。そういう組織では現場のエンジニアはゲンナリしていたり，QAとは建て前で接して本音を言うのはやめようと諦めてしまったりしている。
だから，問題を解決したい，改善したい，世の中のためになりたいと思って論文という書き物をしているのに，形式的な指摘はイラッとすることがある。
だから，自分は論文書いて査読コメントを受ける度に，論文ではなく本で勝負したいと思う。自分はアカデミアにはなれない，ならない思う。論文で偉い先生方に評価されるより，本で「役に立った」という評価を受ける方が100倍うれしい。
アカデミアが学生を育てて教え子が社会に貢献するようになるのは，すごくやり甲斐があると思う・・・ちなみに，アカデミアが論文に関して新規性や作法に関する指摘をする理由を知っている。学位を取るためには，学会で論文を採用されることが必要であり，論文採用の条件として過去の論文との違いや新規性が求められるからだ。
でも，ソフトウェアの品質向上に関する分野で，役に立つか立たないかをさておき，新規性を最重要と見るのには，強い違和感を感じる。仮に，同じような研究や実証があったとしたって，それが現場の役に立つならいいじゃないかと思う。
また，情報系のアカデミアが数学的に検証可能な論理が大好きなのも知っている。例えばフォーマルメソッドなどがその例だ。数式を使って論理の正しさを証明できると，いかにももっともらしい論文になるから，みんな好きなんだろう。
でも，まってくれよと言いたい。ソフトウェアを作っているのはロボットじゃない人間だろって思う。人間の思考や振る舞いは数式で表すことができない。最近流行のAIだって，人間の脳神経系のしくみをシミュレートしているのだ。
だから，情報系の論文はもっと心理学とか人間の行動学を取り入れていいはずだ。ソフトウェアのメトリックスで語りきれない部分に解決策があることも多い。
GD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦はトヨタとGMはすでにどちらも90%以上の品質を実現できているが，GMがトヨタに数%勝てないのは「品質を心配する意識：Awareness : Worrying about Quality」の違いだと言った。詳しくはこちら。
「品質を心配する意識：Awareness : Worrying about Quality」はおそらく数値では表せない。でも，数値では表せないところを解明していかないと，最後の数%の品質は上がらないのではないか。そこをもっと研究しろよとアカデミアに言いたい。
みなさんは「ソフトウェアエンジニアリング論文集 80's」という本を読んだことがあるだどうか。
これが，論文の形式に則った論文か？といったものばかりだ。超有名どころの論文だから許されるのか？ いや，論文が主張するべきところが共感できるから，受け入れられているのではないか。
最初に載っている論文はワインバーグの論文で，冒頭で宮本武蔵の五輪の書を紹介している。
論文の書き出しはこうだ
宮本武蔵は，五輪の書の中で次のように書いている。
大きな所は見えやすし，ちいさき所は見えがたし，其子細大人数のことは即座にもとをりがたし，一人の事は心一つにてかわることはやきによつて，ちいさき所しる事得がたし。
「大きなところは見えやすく，小さいところは見えにくい。というのは，大人数でやることは急速に転換できないから容易に捕捉できるのに対し，個人のことはその人の心一つですぐ変化するから分かりにくい。」ソフトウェア研究者の Barry Boehmは "Software Engineering Economics" の中で次のように書いている。
へたくそな管理は，他のいかなる要因よりもソフトウェアのコストを急速に増大させる。ワインバーグだから許されるのかもしれないが，論文の作法はまったく無視している。この本に掲載されている論文はどれも「中身で勝負」という内容であるように思える。
：
ソフトウェアの品質を向上させるためにメトリクスを取るというのもよくあるし，メトリクスに関する論文はよく見る。でも，ソフトウェアのメトリクスを取るにしても，それはプロジェクトメンバーがソフトウェアの品質を改善するためにメトリクスを取ろう！となれば，有効なデータとなるだろうが，いやいややらされている状態で有効なデータが取れないのではないか。
それは，結局，ソフトウェアの品質問題はエンジニアという人の問題に帰着するからではないか。だから，数字だけを追っかけても改善するわけもなく，人の問題も同時に改善する気持ちがないと効果が上がらないのではないか。
人の問題は数字にしにくいし，数学的論文にはならないから，人をテーマにした情報系の論文はほとんど見ない？が，それでは結局のところ，現場の改善にはつながらないのではと思う。
P.S.
人材の育成や現場の改善に尽力をつくしているアカデミアの方々には敬意を表します。
アカデミアの友人もたくさんいるのでこの手の記事書くときには気を遣うなあ・・・
