論文研修会最終回 - タイトルとあらましは論文を示す -

SRA Advent Calendar 2019 の記事です。

論文を書き方に最も大切なことを書きます。

ふりかえり

ここまで論文の書き方を説明してきました。

• 論文研修会（導入編）- 論理的思考のすすめ -
• 論文研修会（座学 本編）
• 論文研修会（WS はじめに編）
• 論文研修会（情報を正確に伝える構造）

そのポイントは構造で、論理的思考につながるもので技術文書全般に利用できるものです。
私たちが学んだ起承転結（wikipedia）ではなく、パラグラフライティングを基本としたあらかじめ全体像や見通しを示した後に詳細を示す構造です。

重要性

パラグラフ（段落）だけでなく文章全体がその示す単位の全体像や見通しから始まっているのですから、タイトルやあらましは論文そのものの価値を示す最も重要な部分です。

「論文の採否はタイトルとあらましで6～7割決まる。いや8割かもしれない」そう教わりました。実際、論文の査読の際はタイトルとあらましで大まかに担当者が決められたりするでしょうし、論文を読む際もタイトルとあらましで期待を高めたり、困惑しながら読み始めます（ちなみに、タイトルとあらまし、はじめに、結論と読んでから他の部分を読む人が多いようです）。

何を書くか

端的に言うとアピールすべきことです。論文というのは、書きたいことを書くものではありません。もちろん採録されることだけが目的ではないですが、中身を理解してもらって採録されなければ論文を読んでもらうこともできません。書きたいことではなく、書かないといけないことを書いてください。

論文は研究者あるいは現場の人が研究成果や経験を書くもので、研究論文なら新規性、一般性、信頼性、経験論文なら有効性、一般性、信頼性を評価されます（シンポジウムなら参加者のニーズなどが入る場合もあるでしょう）。ですので、文字数は少ないながらもタイトルやあらましにこれらの内容を書書ないといけません。

タイトルには色々な流派がありますが、例えば「Aを目的としたB法によるC(問題)の(対策)D」のように対象分野、問題、手法、どこまで解決しを明確にするとともに示します。こう書くと一般性に制限を付けたように読めるかもしれませんが、そもそも論文とはこれまで積み上げられてきた研究という巨人の肩に乗って、少しだけ良くしたものです。適用分野明確にすることや方法を示すことで信頼性を上げています。一般性や有効性はXXを目的としたで示します。新規性は問題と解決法の組み合わせで示すことが多いようです。

あらましにも色々な流派がありますが、整理しやすいパターンとしては以下のような項目を書いています。

• 本論文ではXX（タイトルの内容）を示す
• YYによる評価の結果、ZZだとわかった
• XXを用いることで、これまで××だったAがより〇〇に△△できるようになった

さらに必要なら、課題と将来性にふれることもあります。

タイトルとあらましは最後に書く

タイトルとあらましは論文の顔です。明確な問題設定がなければ書くことができません。開発現場の人が論文を書く際に難しいのは、経験しすぎていることです。自分の実現したことも、なかなか端的に表現できません。

そこで「はじめに」を書いて問題を絞っていくことから始めましたが、結論まで書いたところで一度「はじめに」を見直してください。問題とはやったことの裏返しです。解決したことがどのような問題を解決したかをよく考えて、必要なら書き直してください。

はじめにの見直しができたなら、ようやくタイトルとあらましを書くことができます。発表準備にタイトルとあらましが必要になるかもしれませんが、それはあくまで仮のものです。問題設定がふらついているのに魅力的なタイトルと思ってしまうとそれに引きずられて、わかりにくくなりますので、注意してください。

おわりに

これまで説明した論文の書き方を踏まえて、タイトルとあらましの書き方を説明しました。ここに書いた内容は筆者の限られた経験から書いていますので、他にももっと良い書き方があるでしょう。ぜひ、多くの論文を読んであなた流の書き方を作ってください。その際にこのブログが少しでも役立ったなら幸いです。

さて、今回の研修は論理的思考を身に着けてもらうために実施しました。論文を書く行為は、説明しないといけない内容を、決められた構造に合わせて、組み立て、整理することです。整理された内容は構造化されていますので、検索して容易に取り出すことができますし、組み合わせることも可能です。また、新しい情報に出会った際にも応用や修正が可能でしょう。（参考： 実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -）

説明しないといけない内容は、相手の求めていることです。相手の求めていることに合わせて、説明し、アピールする、そういった当たり前のことが難しいのは、説明すべき構造に合わせて単純化できていないからです。論文の書き方を応用することで、話が長い、理解されない、勘違いするといったことが改善されるでしょう。ぜひ、実社会に役立ててください。

Tweet

論文研修会（情報を正確に伝える構造）

SRA Advent Calendar 2019 17日目の記事です。

論文をはじめとする技術文書はパラグラフライティングが基本です。パラグラフライティングの作法 -書き手にもメリットのある文配置ルール- によると、

パラグラフライティングは，文章のまとまりを作るルールと，各まとまりの中での文の配置のルールに則って文を書く方法です．そのルールを簡単に言えば，「共通の話題で括れる内容は一つのまとまりとする」というものと，「各まとまりの先頭には最も重要な文を置き，それ以後にはその文の補足説明のための文を置く

というものです。これはパラグラフ（段落）だけでなく、文章全体も同じような構造になっています。いわゆる起承転結と違い、結果を先に示した上で詳細を説明します。

このような構造はドラマ「刑事コロンボ」や円蔵師匠の落語、最近ではドラマ「時効警察」の一部でもそのような構造になっています。先に結果を示すことで結果に至る過程を楽しむことができます。

論文の構成は基本的に以下のような構成になっていて、随所で要点と全体の見通しが示され、情報が正確に伝わるようにガイドします。

あらまし

論文で何を提案するか、評価の結果、その価値などアピールする点を説明します。

はじめに

対象とする問題とその一般的な意味を説明します（これは問題設定と呼ばれます）。そして最後に論文の構成を示します。

関連研究

この章でどのような関連研究を示すかを述べた後、関連研究の説明をします。この説明は一般にどういわれているかではありません。提案の扱う問題と解決手法がこれまでどこまで行われ、提案する手法以外では解決されていないこと、いわゆる新規性を示します。

提案手法、評価方法、結果、考察

これらも先に構造を示すと、見通しが良くなり読みやすくなります。また、それぞれの説明の中で互いの関係を示すと内容をよく理解してもらえるでしょう。

おわりに

論文で提案した内容とその効果、将来展望と課題を示します。

あらまし、はじめに、おわりに、は同じような内容です。それぞれの位置づけに合わせて、どこを詳しく書くかが異なるだけです。

正確に情報が伝わるように

論文を読みなれている人は、あらまし、はじめに、おわりに、結論の順に読んで論文の主張を理解した上で、他の章を読み出します。これらの内容に一貫性があり、さらにほかの章が論文の適切なアピールに役立っているなら、読者はきちんと評価してくれるでしょう。

逆に、各章や全体の見通しが悪かったり、話がずれていると、素晴らしい成果であっても読者は理解できないでしょう。論文はある問題に対する解決法を提案するものであって、それ以外の情報は要りません。書かないといけないものを書くのであって、書きたいことを書くのではありません。

このことは論文だけではありません。技術文章をはじめ、お客様への提案賞など、仕事にかかわる文章すべてが同じです。要点を絞り、結論と全体像を示せは、情報を正しく伝えることができるでしょう。

最終回に続く

Tweet

[#Node-RED] ファンクションノードのデバッグどうしてる？

今年はNode-RED UG Osaka勉強会 vol.3 で発表しました。

[Node-RED] ファンクションノードのデバッグどうしてる？ from Makoto SAKAI

Node-REDのファンクションノードはJavascriptでプログラミングすることができます。一つのノードで複数の処理を行えますので、ループ処理も一つのノードで実現できます。

その反面、Node-REDであるにもかかわらず、工夫をしないとVisualなデバッグはできません。この発表では、デバッグ方法に応じたテクニックを説明しました。

１．プログラムを一時的に修正して確認する

デバッグの際はプログラムを一部修正して動作を確認します。しかし確認が終われば元に戻さないといけません。できれば簡単に変更して、簡単に戻したいものです。

• デバッグ用に端子を増やしても既存コードは そのままで良い

ファンクションノードの端子は簡単に増減できます。それぞれの端子にmsgを送るには配列をnode.send()しないといけません。しかし、配列の要素と端子数は必ずしも一致しなくてよいので、最終端子をデバッグ用に使えば、簡単にデバッグ情報の追加削除が（フロー的に）できます。

• コメントアウトは[CTRL]+[ / ]

とはいえ、ファンクションノードのプログラムに追記する必要がありますし、console.log()が使いやすい場合もあるでしょう。そのようなデバッグのコードをコメントアウトする際は、[CTRL]+[ / ]を使うと行単位でコメントできます。再度[CTRL]+[ / ]するとコメントが外せます。

２．処理の追跡が容易なこと

デバッグの際は、プログラムがどのように、あるいはどこまで進んだかを確認して、どこが間違っているかを確認します。

• デバッグノードの出力を切り分ける

デバッグノードの出力は標準のデバッグタブのほか、ステータスやコンソールにも出力できます。ほかの情報があまり出力されていない出力先を選べば、確認が容易になるでしょう。

• イベント的なものにはディレイノードや Dashboardのnotificationが便利

今どこを処理しているかを確認したい場合は、短時間表示された後に自動的に消えるディレイノードや Dashboardのnotificationが便利です。特にディレイノードはディレイする時間だけ表示されるので便利です。

• httpStaticにログ等を出力する

大量なログの場合、ファイルノードを使って出力する方法があります。その出力先をseting.jsのhttpStaticに指定されたディレクトリに置くと、ブラウザで取り出せるようになります。単純なファイルはもちろん、CSVやHTML形式にすると、色々と応用できるでしょう。

３．プログラム状態を見分けやすいこと

処理の経路ではなく状態を示したい時もあるでしょう。

• ファンクションノードやデバッグノードのstatusで状態を表示

一瞬ではなく状態を表示したままにするのには、ファンクションノードやデバッグノードのstatusが便利です。一度表示すると、新しい情報を表示するまで状態を確認できます。

• Dashboardのtextも便利

Dashboardのtextはブラウザで確認することができます。

このようにファンクションノードのデバッグ方法は多様です。必要に応じて使ってください。

Tweet

論文研修会（WS はじめに編）

この記事は SRA Advent Calendar 2019 16日目の記事です。
今回は実際に論文（実際は事例報告の要旨）の「はじめに」を書いてもらいました。「はじめに」は論文の問題設定と問題に対する論文のアプローチを説明します。実際に書いてもらって気になる点を指摘しました。なかなか面白い事例が出てきて、基本の3点さえ押さえれば良い事例報告になりそうでした。

解説

まず、前回の振り返りを兼ねてパラグラフライティングを説明しました（サンプル１）。各段落の先頭だけを読むだけで全体の論理展開がわかるようになっています。ただし最初の1段落目は2行目に趣旨があります。

これは興味を引くように「ツールやプロセスが重要」ということをアジャイルソフトウェア開発宣言を用いて逆説的に説明しているからです。また、最初の段落の最後が「つなぎ」になっていることも説明しました。

ワークショップ

採録された（普通レベルの）サンプル２を示して、各自の事例の「はじめに」を書いてもらいました。

事例を5行の箇条書きで書いてくるように課題を出していました。これはサンプル1の最初の1行に相当するものですが、それを2段落ごとにまとめて、問題設定、事例の内容、結論で1段落ずつになるように書いてもらいました。

実際に書いたものをみんなで読みながらコメントしました。コメントの多くは以下の基本的なものでした。

１．問題設定はやったことの裏返し、関係ないことは書かない
２．問題設定は広い内容から狭い具体的な内容に狭めていく
３．評価に合わせて書く。具体的すぎない一般的問題として説明すると汎用性が上がる。評価者が興味を持つようにする。

特に３番目は仕事でも重要なところで、お客様に合わせた提案でないとうまくいかないですね。このように論文を書くことは、実際の仕事にもつながる学びがあって面白いです。

次回は残りの本文を書きます。「全体を示してから詳細を書く」というパラグラフライティングの構造が入れ子になっていることを説明するつもりです。

Tweet

論文研修会（座学 本編）

この記事は SRA Advent Calendar 2019 9日目の記事です。

前回（論文研修会（導入編）- 論理的思考のすすめ -）に続き、論文の書き方を情報伝達あるいは論理的思考の観点で説明しました。
大まかな構造を理解してもらえたかと思います。

社会人のためのシンポジウム発表入門 リーン論文作法 from Makoto SAKAI

同じスライドを以前はシンポジウム参加の勧めとして書いていました（社会人のためのシンポジウム発表入門 リーン論文作法）

次回はいよいよワークショップです。事例報告の「はじめに」を書き始めてもらいます（16日目の記事に続く）。

Tweet

論文研修会（導入編）- 論理的思考のすすめ -

この記事は SRA Advent Calendar 2019 2日目の記事です。

私の所属する関西事業部では、社内研修会というものを実施しています。個人的には、勉強会のようなものはオープンに行う方が、新しい技術を身につけられてよいし、社内を知ることができると思っています（社内勉強会より社外の勉強会）。しかし、社内でないと話しにくい内容もあるもので、今回行う論文の書き方などがそれで、論文と言いながら事例報告の概要を書くのですが、外に出せるネタがあるとは限らないので、社員だけが知ることのできる事例をもとに書き方を学び、それを通じて論理的思考を学ぶ。なんていうのは社内だからできることです。

論文というのは技術情報を伝達する方法の一つです。古くからソフトウェア開発では「コミュニケーション」が問題とされることが多くありました。しかし、この「コミュニケーション」には2つの側面があって、一つは情報伝達、もう一つが人間関係に起因する協力的な関係が気づけるかどうかだと思います。

このうち情報伝達のトラブルは、論理的思考力を身に着けることで大きく改善します。スライド中にある

• いつのまにか話が長くなって 打ち合わせがなかなか終らない。
• お客様や上司に理解してもらえず 意見が通らない。
• 話を直接聞いているのに勘違いする。

などは、論文作成を通じて論理的思考力が身についていれば、多くの混乱を避けることができるでし
ょう。

論理的思考力を身に着けるための論文研修 from Makoto SAKAI

参加者は社外発表をきたされている人や、昇格に向けて一皮むけてほしい人たちでした。内容はそれなりに伝わったようで、納得したり、耳が痛かったりしたようです。

スライドの説明のあと、以前日科技連でお話しした論文の書き方を説明しました（9日目の記事に続く）。

Tweet