search
LoginSignup
0

posted at

updated at

プログラマ:顔を見合わせて会議、テレビ会議、コメント・チャット。 仮説(194)

プログラマの意思疎通の方法

ログラマが顔を見合わせて会議をやるか、テレビ会議をするか、コメント・チャットですますか

プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)7つの要点 仮説(48)

  1. GitHub, gitlab, bitbucketなどのissue, wikiなどに追記、注釈(comment)などをする。あるいは、twitter, facebook, slackなどで、chat。追記、注釈(comment)などをする。

  2. テレビ会議で、カメラと画面を共有して会議をする。
    この場合、一部、音声だけの参加者、chatだけの参加者がいる場合がある。

  3. 直接集まって会議をする。
    この場合に、一部、遠方でテレビ会議参加者がいる場合がある。

面直無し

ソフトウェアを一緒に作るといっても、部分的な道具に分かれていて、その部分は独立して作ることができる場合、一度も会ったことがなく一緒に仕事をする場合がある。

例えば、VZエディタの移植をした時に、割り込みベクタテーブルを試験する道具は、一度も会ったことがない方から提供を受けて利用した。

VZエディタはソースコードを公開する商用ソフト。
差分は無償で公開してよかった。
ソースコードは、差分も含めて全員で共有できた。
思いのままに変更して、差分を公開すると反応があった。
今のオープンソースでの反応のように。

ソースコードを通じてのやりとりなら、揉めない限り面直はいらない。
いくつもの、制約条件の違いによる分岐(fork)はあったとしても。

VZエディタ移植に当たって実施したことと成果 仮説(115)
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

年に1度から3年に1度

VZエディタの移植が動き始めてからは、利用者への配布を兼ねて、東京で会合を持った。
JUG/CP-Mというフリーソフトの配布団体の東京の会合には、3年に1度くらい出ていた。そのメンバが組織してくれて、東京で会合を持った。20人以上が集まってもらえた。ほぼ全員がNEC。

ネットでは書きづらい感想などは、恥ずかしいという視点と、間違いがあるといけないという観点と、悪意がないのに相手が誤解するといやだという過去の経験などから、面直の方が言いやすいらしい。たしかに、直接言えば、外していたかどうかは直感的にわかることがある。

VZ倶楽部の発行記念パーティでも初めてお会いする方や、3年に1度くらいしかお会いできない人に会えた。IT業界だと、3年経つと、会社がなくなっていたり、会社を移っていたり、存在確認の役にも立つ。

毎年ある行事には、3年に1度は出るとよいというのが経験則か。

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

月に1度から3月に1度

ある会社とOSの開発をしていた時に、試験プログラムとMISRA Cの検査を担当していた。
MISRA Cの検査のためには、一部プログラムを書き換えて、戻るgotoを、進むgotoに書き換えて試験する必要があった。スクリプトを同僚に書いてもらい、受け取ったら、試験のための処理の一部を自動実行して、1日で完了する体制を取った。

そのために、開発途中のソースコードを毎週もらい、順次試験をして、その時点で変更した方がいいところは報告して、場合によっては書き直す候補を提案した。
これらの作業は、すべてネットのメールなどで実行した。

月に1度か3ヶ月に1度、定例会議で会う。もう一方の作業をしている同僚と相手方とは、もう一つ前のOSの開発の際に、CPUの移植にあたって組んでいたため、そちらは面識が深く、この頻度で問題はなかった。こちらの組みも、面識はあったし、やりとりの中で、特に課題はなかった。そのため特別の面談の機会は設けなかった。

作業診断(process assessment)を成功させる5つの鍵。失敗する5つの罠 仮説(50)

プログラマはどれくらい人付き合いしないといけないか 仮説(47)

IT業界に説教は必要か 仮説(7)

週に1度から3週に1度

毎日、ネットで日報をあげてもらっている仕事の時に、週報は面直にした。
そうはいっても、出張などで出られない人は、3週に1度くらいになる。

日報は、進捗状況や、課題(個人と組織に分けて)をあげてもらうが、
週報は、自分の得意な技術の紹介や、この1週間で調べたことの報告、この1週間で書いたプログラムの報告をしてもらうことにした。

おかげで、いろいろな作業が進んだ。

10年くらい前には、週報は、その1週間の間に読んだ本(仕事でも仕事以外でも)の紹介をしていたことがある。amazon.co.jpで1万冊感想を上げる目標をたてていた時。

7人の読んだ本を、その週の間に拝見して、読んだ人とは違う視点を感想に書くようにしていたことがある。amazon.co.jpの感想で偏っている理由の一つかも。

プログラマの「日報、週報、月報、年報」考 仮説(73)

報連相 再考 仮説(40)

今日死ぬとしたら 日本語が不得意なプログラマが話をすること 仮説(116)
https://qiita.com/kaizen_nagoya/items/61a03864ac6c011e6164

毎日(daily)

組織によっては、朝会、昼会などをするところがあるらしい。
何か、助け合うことがあるならそれもいいとは思う。

実際に、会わないと聞けないことは多い。
言える雰囲気かどうか。

文書履歴(document history)

ver. 0.01 初稿 20190716
ver. 0.02 毎日追記 20190717

このエントリーをはてなブックマークに追加
https://b.hatena.ne.jp/guide/bbutton

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0