プログラマの意思疎通の方法
ログラマが顔を見合わせて会議をやるか、テレビ会議をするか、コメント・チャットですますか
プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点 仮説（48）
https://qiita.com/kaizen_nagoya/items/f322df6978853c708c99
-
GitHub, gitlab, bitbucketなどのissue, wikiなどに追記、注釈(comment)などをする。あるいは、twitter, facebook, slackなどで、chat。追記、注釈(comment)などをする。
-
テレビ会議で、カメラと画面を共有して会議をする。
この場合、一部、音声だけの参加者、chatだけの参加者がいる場合がある。 -
直接集まって会議をする。
この場合に、一部、遠方でテレビ会議参加者がいる場合がある。
面直無し
ソフトウェアを一緒に作るといっても、部分的な道具に分かれていて、その部分は独立して作ることができる場合、一度も会ったことがなく一緒に仕事をする場合がある。
例えば、VZエディタの移植をした時に、割り込みベクタテーブルを試験する道具は、一度も会ったことがない方から提供を受けて利用した。
VZエディタはソースコードを公開する商用ソフト。
差分は無償で公開してよかった。
ソースコードは、差分も含めて全員で共有できた。
思いのままに変更して、差分を公開すると反応があった。
今のオープンソースでの反応のように。
ソースコードを通じてのやりとりなら、揉めない限り面直はいらない。
いくつもの、制約条件の違いによる分岐(fork)はあったとしても。
VZエディタ移植に当たって実施したことと成果 仮説(115)
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949
年に１度から３年に１度
VZエディタの移植が動き始めてからは、利用者への配布を兼ねて、東京で会合を持った。
JUG/CP-Mというフリーソフトの配布団体の東京の会合には、３年に１度くらい出ていた。そのメンバが組織してくれて、東京で会合を持った。２０人以上が集まってもらえた。ほぼ全員がNEC。
ネットでは書きづらい感想などは、恥ずかしいという視点と、間違いがあるといけないという観点と、悪意がないのに相手が誤解するといやだという過去の経験などから、面直の方が言いやすいらしい。たしかに、直接言えば、外していたかどうかは直感的にわかることがある。
VZ倶楽部の発行記念パーティでも初めてお会いする方や、３年に１度くらいしかお会いできない人に会えた。IT業界だと、３年経つと、会社がなくなっていたり、会社を移っていたり、存在確認の役にも立つ。
毎年ある行事には、３年に１度は出るとよいというのが経験則か。
VZエディタのように、開発環境DOSの上にVZエディタを使い、optasmのコンパイルスクリプトまで同じであれば、環境の構築に手間はかからない。
Windows, MacOS, Linuxなどの複数のOSで、複数のコンパイラという環境では、環境の構築が容易ではない。
WindowsでAnaconda構築の Qiita記事が、Views自己最高なのも、道具の導入の困難性を物語っている。
同じ環境で作業しない限り、情報の共有は無理。環境の共有ができていないのだから。
githubでソースコードの共有ができても、それぞれの機材に違うソフトウェアが入っていれば、同じ環境の構築はできない。
docker hubに環境をあげておけば、いつでも、どこでも同じ環境で作業できる。
ソースコードと環境の共有が、情報共有の基礎。githubとdockerを使わずに、情報共有は片腹痛い。
公開算譜は機敏だ(open source is agile) GitHub and docker 仮説(51）
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4
docker(18) なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2
月に１度から３月に１度
ある会社とOSの開発をしていた時に、試験プログラムとMISRA Cの検査を担当していた。
MISRA Cの検査のためには、一部プログラムを書き換えて、戻るgotoを、進むgotoに書き換えて試験する必要があった。スクリプトを同僚に書いてもらい、受け取ったら、試験のための処理の一部を自動実行して、１日で完了する体制を取った。
そのために、開発途中のソースコードを毎週もらい、順次試験をして、その時点で変更した方がいいところは報告して、場合によっては書き直す候補を提案した。
これらの作業は、すべてネットのメールなどで実行した。
月に１度か３ヶ月に１度、定例会議で会う。もう一方の作業をしている同僚と相手方とは、もう一つ前のOSの開発の際に、CPUの移植にあたって組んでいたため、そちらは面識が深く、この頻度で問題はなかった。こちらの組みも、面識はあったし、やりとりの中で、特に課題はなかった。そのため特別の面談の機会は設けなかった。
作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠 仮説(50）
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab
プログラマはどれくらい人付き合いしないといけないか 仮説（47）
https://qiita.com/search?page=3&q=kaizen_nagoya+人
IT業界に説教は必要か 仮説（7）
https://qiita.com/kaizen_nagoya/items/2f088f496d8a66132ec6
週に１度から３週に１度
毎日、ネットで日報をあげてもらっている仕事の時に、週報は面直にした。
そうはいっても、出張などで出られない人は、３週に１度くらいになる。
日報は、進捗状況や、課題（個人と組織に分けて）をあげてもらうが、
週報は、自分の得意な技術の紹介や、この１週間で調べたことの報告、この１週間で書いたプログラムの報告をしてもらうことにした。
おかげで、いろいろな作業が進んだ。
１０年くらい前には、週報は、その１週間の間に読んだ本（仕事でも仕事以外でも）の紹介をしていたことがある。amazon.co.jpで１万冊感想を上げる目標をたてていた時。
７人の読んだ本を、その週の間に拝見して、読んだ人とは違う視点を感想に書くようにしていたことがある。amazon.co.jpの感想で偏っている理由の一つかも。
プログラマの「日報、週報、月報、年報」考 仮説(73)
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
報連相 再考 仮説（40）
https://qiita.com/kaizen_nagoya/items/013f2779bd2beba720b7
今日死ぬとしたら 日本語が不得意なプログラマが話をすること 仮説（116）
https://qiita.com/kaizen_nagoya/items/61a03864ac6c011e6164
毎日(daily)
組織によっては、朝会、昼会などをするところがあるらしい。
何か、助け合うことがあるならそれもいいとは思う。
実際に、会わないと聞けないことは多い。
言える雰囲気かどうか。
文書履歴(document history)
ver. 0.01 初稿 20190716
ver. 0.02 毎日追記 20190717
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
