プログラム
状態マシン図
シーケンス図
タイミング図
名古屋のIoTは名古屋のOSで

プログラマが学会・研究会で対外発表する際の9つの関門

プログラマは、普段はプログラムを書いてる。計算機相手の仕事。
計算機相手ではなく、人間相手の会話は不得意なことがある。
私は記憶が苦手だ。それで計算機に記憶を記録するために計算機の仕事についた。
また、私は人と会話したくないためにプログラマになった。
対外発表も苦手だった。ある師匠に、「笑いを三度取れれば、その発表は成功だ」と言われた。

人相手の発表が苦手だという方への参考情報。対外発表する前に次の9つの関門を通っていれば、喋りがダメであろうが、プレゼンの作りがダメであろうが、なんとかなるという案を記載。

関門1 過去のその行事の発表を3回遡って調べておこう。

過去の行事に同じ分野の発表や、類似の発表がないかを調べよう。過去の発表にどういう追加的な視点や施行をしたのかを含まない発表は、手戻りでしかない。時間があれば、10回(10年分)調べるとよい。10年経つと、また同じ現象や、流行りが現れるかもしれない。
過去の類似の事項を知らずに、発表して過去のことを教えてもらうのも一つの勉強の方法ではある。

20180114追記

ソースコードがついている場合で、プログラムの断片は、コンパイルできる形にしてコンパイルしよう。
https://qiita.com/kaizen_nagoya/items/5f4b155030259497c4de

また、ソースコードが電子的に提供されていない場合には、自分で手打ちしてみると誤植を見つけることがある。お礼に最新版をいただいたり、ネットに報告者名を掲載していただけることもある。
http://www.event-b.org/A_errata.pdf

関門2 過去の発表の類似点を探そう。

過去の発表に、自分の発表と類似点がないということはない。類似点がないと思うのは、理解力がないか、思い込みかもしれないと仮定して、何がなんでも類似点を見つけ出そう。主体、顧客、制約条件、問題の構造、解決法、対象領域、科学分類、道具類、頻出用語、参考文献など。類似点のある過去の発表は、自分の発表で参考文献に1つから3つはあげておくと良い。3年では、一つも参考文献欄にあげられる過去の発表が見当たらなければ、10年、20年遡るとあるかもしれない。

関門3 目的(purpose)、目標(goal)を絞り込もう。

自分のプログラム、仕事には、いっぱい思いがあるかもしれない。
資料を作る段階では、ひとまず、いっぱい書き下して見て、当日までに順に絞り込もう。2つのことを記述するより、1つのことに絞ったほうがわかりやすい。一つのことをわかったもらった人には、その次にもう一つのことを伝えれば良い。

20180114追記

結局、当日まで一つに絞り込めなかったことは過去になんどもある。現地についてから、自分より前の発表の質疑を聞いて、その場にいる人たちの興味のある内容に絞ることがある。いわゆる泥縄かもしれないが、興味のなさそうなことを話すよりいいかもしれない。その場にいる人達が理解するのに必要な説明を追加するのもよい。
しかし、場に迎合する必要はない。よくあの人の話はよくわからないということを聞くことがある。関門4の制約条件を厳密に書いておけばよい。わからないという人は、制約条件がわかっていない場合がある。

関門4 課題を解決する道具類(CPU, OS, 言語、ネットワーク、DB)の制約条件を精密に書こう。

どのCPUだから、どのOSだから、どの言語だから、どのネットワークだから、どのDBだからなど、道具の種類によって、より良い解決方法が違うかもしれない。その道具を使ったことがない人には、その道具の制約条件が書かれていれば、分かることもある。精密に制約条件を記載しよう。

20180114追記

道具類の制約条件を書いていくと、対象領域の制約条件との矛盾、包含関係が明確になることがある。道具の方が不十分だったり、幅が広すぎたり。それなら、対象領域の制約条件も書いておいて、なぜ、その道具を、そういう使い方をするのかの鍵を提供することができる。
ソースコードには、そのソースコードも目的(purpose)と成果(outcome)を記載するとよい。
https://researchmap.jp/jovqfzcc8-1797580/#_1797580

関門5 参考文献(reference)は3代前まで遡ろう

ある資料を参考文献にあげるときに、その参考文献の「参考文献欄」に記載のある資料は、入手可能かどうか調べておこう。発表した際に、自分では入手不可能だと思った文献を持っている人に出会えるかもしれない。丸1日調べて入手できそうにない文献を「参考文献欄」に記載している文献を、発表した参考文献欄に書いておいて、その資料の入手方法を教えてもらったことが何度かある。
 できれば、参考文献に掲載した文献の「参考文献欄」に掲載されている文献の「参考文献欄」に掲載されている文献も調べておくと良い。
3代前まで遡ると、1冊で10参考文献があると仮定すると、1000文献に当たることになる。そのうち、分野によっては重複が50%くらいになる場合もあれば、20%くらいにとどまる分野もある。その重複具合によって、自分が柱にするべき文献が何かを考えることができることがある。

20180114追記

プログラミング関係だとURLを記載することがある。記載のあるURLは、接続可能かどうか調べて、最新の情報を掲載すると感謝されることがある。
例:
https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography

関門6 できれば英語で投稿または英語で発表しよう

プログラミング言語の大方の用語は英単語由来です。英語で発表すれば、すごく簡単なことが、日本語で発表するためにややこしくなることがあります。また、英語で発表したほうが、わかってもらえる人の割合も多くなります。日本語で発表した場合の意見と英語で発表した場合の意見で、次につながる意見や、具体的に役立つ関係資料を教えてもらえるのは英語の発表の場合の方が、経験則では倍くらい多いです。

20180114追記

自分は専門は通信規約です。英語で発表した時、Availability, Band width, Cost, Delay, Error, Fault, Geometric distance, Hop countと言うように、アルファベット順に1枚づつ項目整理をしたら、すごく受けたことがある。英語だとプログラムの用語で作りやすいので超お勧め。

関門7 プログラム例は必ず入れよう

 プログラムの断片であっても、プログラム例は必ず入れよう。引用して、変数や演算子を変更した場合だけであっても、プログラムのコメント欄と参考文献にその引用元を掲載して記載すればよい。
 プログラム例があれば、日本語、英語以外の言語で話している方からも、質問、意見がもらえる。
https://researchmap.jp/jownvh0ye-1797580/#_1797580

関門8 図または表、写真を入れよう

 英語で資料を整理する際の、要点は、プログラムの説明と、いれる図、表、写真があるとよい。プログラム、図、表、写真を並べ替えて、筋書きを整理するとよい。文章が必要な場合は、プログラム、図、表、写真の説明を書けばよい。
 図を入れる場合には、状態遷移(state)図、時系列(sequence)図、刻時(timing)図を入れれないか検討しよう。分野によっては利用事例(use case)図でもよい。状態遷移は状態遷移表と両方あるとよいこともある。

関門9 過去の発表で表彰されたものを、出発点にしよう。

 英語で資料を作る場合に、初めての場合は悩みが多い。過去の発表で、類似のものがないと思ったら、表彰されたものを出発点にしよう。
受賞したものは、その論理構造が良いのか、問題に対する姿勢が良いのか、経験が貴重なのか、整理の仕方が良いのか、わかりやすいのか、何か利点があるはず。その良いところから出発すれば、自分の勉強にもなる。

事例

プログラマで、学会・研究会発表で手本にすると良い人を何人か紹介する。

清水吉男

SWESTの講演でも、そのあとの部屋での議論でも、自分の経験ではという限定をつけてお話をされる。
自分の経験していないことについては言及しないし、自分の経験の範囲内での特徴的な事象を熱心に話をされます。

二上貴夫

SWESTのMISRAの解説で、少年のような目で技術を語っていた。
未来を見つめ、方向性を示すことに注力している。

田中和明

具体的で、プログラムを示し、動かして結果を説明する。SWEST実行委員ではピカ1。

中村晋一郎

TOPPERSのアプリケーションコンテストの表彰後の講演で、代表の高田広章と同じくらいの人を集めたのはこの人だけだと思う。
聞いているだけで、迫力がある。必要性を明確にしている。

坂井弘亮

圧倒的に面白い。自分でプログラミングを楽しんでいる。OSCのセミナでは抜群。
TOPPERS開発者会議で講演していただいた。
https://www.slideshare.net/asmtanka/2-sakaihiroakija

<この稿は書きかけです。順次追記しています。>
december_400x400.jpeg