プログラマは、普段はプログラムを書いてる。計算機相手の仕事。
計算機相手ではなく、人間相手の会話は不得意なことがある。
私は記憶が苦手だ。それで計算機に記憶を記録するために計算機の仕事についた。
また、私は人と会話したくないためにプログラマになった。
対外発表も苦手だった。ある師匠に、「笑いを三度取れれば、その発表は成功だ」と言われた。
人相手の発表が苦手だという方への参考情報。対外発表する前に次の９つの関門を通っていれば、喋りがダメであろうが、プレゼンの作りがダメであろうが、なんとかなるという案を記載。
関門１ 過去のその行事の発表を３回遡って調べておこう。
過去の行事に同じ分野の発表や、類似の発表がないかを調べよう。過去の発表にどういう追加的な視点や施行をしたのかを含まない発表は、手戻りでしかない。時間があれば、１０回（１０年分）調べるとよい。１０年経つと、また同じ現象や、流行りが現れるかもしれない。
過去の類似の事項を知らずに、発表して過去のことを教えてもらうのも一つの勉強の方法ではある。
20180114追記
ソースコードがついている場合で、プログラムの断片は、コンパイルできる形にしてコンパイルしよう。
https://qiita.com/kaizen_nagoya/items/5f4b155030259497c4de
また、ソースコードが電子的に提供されていない場合には、自分で手打ちしてみると誤植を見つけることがある。お礼に最新版をいただいたり、ネットに報告者名を掲載していただけることもある。
http://www.event-b.org/A_errata.pdf
関門２ 過去の発表の類似点を探そう。
過去の発表に、自分の発表と類似点がないということはない。類似点がないと思うのは、理解力がないか、思い込みかもしれないと仮定して、何がなんでも類似点を見つけ出そう。主体、顧客、制約条件、問題の構造、解決法、対象領域、科学分類、道具類、頻出用語、参考文献など。類似点のある過去の発表は、自分の発表で参考文献に１つから３つはあげておくと良い。３年では、一つも参考文献欄にあげられる過去の発表が見当たらなければ、１０年、２０年遡るとあるかもしれない。
関門３ 目的(purpose)、目標(goal)を絞り込もう。
自分のプログラム、仕事には、いっぱい思いがあるかもしれない。
資料を作る段階では、ひとまず、いっぱい書き下して見て、当日までに順に絞り込もう。２つのことを記述するより、１つのことに絞ったほうがわかりやすい。一つのことをわかったもらった人には、その次にもう一つのことを伝えれば良い。
20180114追記
結局、当日まで一つに絞り込めなかったことは過去になんどもある。現地についてから、自分より前の発表の質疑を聞いて、その場にいる人たちの興味のある内容に絞ることがある。いわゆる泥縄かもしれないが、興味のなさそうなことを話すよりいいかもしれない。その場にいる人達が理解するのに必要な説明を追加するのもよい。
しかし、場に迎合する必要はない。よくあの人の話はよくわからないということを聞くことがある。関門４の制約条件を厳密に書いておけばよい。わからないという人は、制約条件がわかっていない場合がある。
関門４ 課題を解決する道具類（CPU, OS, 言語、ネットワーク、DB）の制約条件を精密に書こう。
どのCPUだから、どのOSだから、どの言語だから、どのネットワークだから、どのDBだからなど、道具の種類によって、より良い解決方法が違うかもしれない。その道具を使ったことがない人には、その道具の制約条件が書かれていれば、分かることもある。精密に制約条件を記載しよう。
20180114追記
道具類の制約条件を書いていくと、対象領域の制約条件との矛盾、包含関係が明確になることがある。道具の方が不十分だったり、幅が広すぎたり。それなら、対象領域の制約条件も書いておいて、なぜ、その道具を、そういう使い方をするのかの鍵を提供することができる。
ソースコードには、そのソースコードも目的(purpose)と成果(outcome)を記載するとよい。
https://researchmap.jp/jovqfzcc8-1797580/#_1797580
関門５ 参考文献(reference)は３代前まで遡ろう
ある資料を参考文献にあげるときに、その参考文献の「参考文献欄」に記載のある資料は、入手可能かどうか調べておこう。発表した際に、自分では入手不可能だと思った文献を持っている人に出会えるかもしれない。丸１日調べて入手できそうにない文献を「参考文献欄」に記載している文献を、発表した参考文献欄に書いておいて、その資料の入手方法を教えてもらったことが何度かある。
できれば、参考文献に掲載した文献の「参考文献欄」に掲載されている文献の「参考文献欄」に掲載されている文献も調べておくと良い。
３代前まで遡ると、１冊で１０参考文献があると仮定すると、１０００文献に当たることになる。そのうち、分野によっては重複が５０％くらいになる場合もあれば、２０％くらいにとどまる分野もある。その重複具合によって、自分が柱にするべき文献が何かを考えることができることがある。
20180114追記
プログラミング関係だとURLを記載することがある。記載のあるURLは、接続可能かどうか調べて、最新の情報を掲載すると感謝されることがある。
例：
https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography
関門６ できれば英語で投稿または英語で発表しよう
プログラミング言語の大方の用語は英単語由来です。英語で発表すれば、すごく簡単なことが、日本語で発表するためにややこしくなることがあります。また、英語で発表したほうが、わかってもらえる人の割合も多くなります。日本語で発表した場合の意見と英語で発表した場合の意見で、次につながる意見や、具体的に役立つ関係資料を教えてもらえるのは英語の発表の場合の方が、経験則では倍くらい多いです。
20180114追記
自分は専門は通信規約です。英語で発表した時、Availability, Band width, Cost, Delay, Error, Fault, Geometric distance, Hop countと言うように、アルファベット順に１枚づつ項目整理をしたら、すごく受けたことがある。英語だとプログラムの用語で作りやすいので超お勧め。
関門７ プログラム例は必ず入れよう
プログラムの断片であっても、プログラム例は必ず入れよう。引用して、変数や演算子を変更した場合だけであっても、プログラムのコメント欄と参考文献にその引用元を掲載して記載すればよい。
プログラム例があれば、日本語、英語以外の言語で話している方からも、質問、意見がもらえる。
https://researchmap.jp/jownvh0ye-1797580/#_1797580
関門8 図または表、写真を入れよう
英語で資料を整理する際の、要点は、プログラムの説明と、いれる図、表、写真があるとよい。プログラム、図、表、写真を並べ替えて、筋書きを整理するとよい。文章が必要な場合は、プログラム、図、表、写真の説明を書けばよい。
図を入れる場合には、状態遷移(state)図、時系列(sequence)図、刻時(timing)図を入れれないか検討しよう。分野によっては利用事例(use case)図でもよい。状態遷移は状態遷移表と両方あるとよいこともある。
関門9 過去の発表で表彰されたものを、出発点にしよう。
英語で資料を作る場合に、初めての場合は悩みが多い。過去の発表で、類似のものがないと思ったら、表彰されたものを出発点にしよう。
受賞したものは、その論理構造が良いのか、問題に対する姿勢が良いのか、経験が貴重なのか、整理の仕方が良いのか、わかりやすいのか、何か利点があるはず。その良いところから出発すれば、自分の勉強にもなる。
事例
プログラマで、学会・研究会発表で手本にすると良い人を何人か紹介する。
清水吉男
SWESTの講演でも、そのあとの部屋での議論でも、自分の経験ではという限定をつけてお話をされる。
自分の経験していないことについては言及しないし、自分の経験の範囲内での特徴的な事象を熱心に話をされます。
成功体験は語っても、成功体験に頼らないために。清水吉男・田中伸明・柏原一雄・佐々木 眞一。仮説・検証（153）
参考文献の参考文献は参考文献だ「「派生開発」を成功させるプロセス改善の技術と極意」を超えて
二上貴夫
SWESTのMISRAの解説で、少年のような目で技術を語っていた。
未来を見つめ、方向性を示すことに注力している。
白井諭
日本語語彙大系 追悼：白井諭。Lisperへの敬意を込めて。
追悼 白井諭（自然言語処理)「言語・認識・表現」年次研究会一覧
https://researchmap.jp/jov1bp0k3-45644/#_45644
田中和明
具体的で、プログラムを示し、動かして結果を説明する。SWEST実行委員ではピカ１。
mruby/cをdocker hubにあげた。要点５つ課題６つ。docker(129)
https://qiita.com/kaizen_nagoya/items/b908c594ff9d829683b5
中村晋一郎
TOPPERSのアプリケーションコンテストの表彰後の講演で、代表の高田広章と同じくらいの人を集めたのはこの人だけだと思う。
聞いているだけで、迫力がある。必要性を明確にしている。
TOPPERS活用アイデア・アプリケーション開発コンテスト受賞作品紹介(1) 第一回(2011)アプリケーション開発部門銀賞『Natural Tiny Shell Task』中村晋一郎
TOPPERS活用アイデア・アプリケーション開発コンテスト受賞作品紹介(6)第三回アプリケーション開発部門銀賞 TOPPERS Realtime System Sample（RSS）- LPCXpresso GPS Clock 中村 晋一郎（個人）
坂井弘亮
圧倒的に面白い。自分でプログラミングを楽しんでいる。OSCのセミナでは抜群。
TOPPERS開発者会議で講演していただいた。
12ステップで作る組込みOS自作入門 坂井 弘亮
参考資料
今日、「お気に入りのQiita記事」を選びました。
https://qiita.com/kaizen_nagoya/items/7fa1f8d89b11e952a9b6
＜この稿は書きかけです。順次追記しています。＞
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20180114 午前
ver. 0.02 追記 20180114 昼
ver. 0.03 補足 20180226
ver. 0.04 補足 20180228
ver. 0.05 補足 20180314
ver. 0.06 標題追記 20190523
ver. 0.07 URL追記 20210831
ver. 0.08 白井諭 追記 20190524
ver. 0.09 ありがとう追記 20230513
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.