このページは
なぜ作業日誌を書くのか
- どの変更をいつ加えてどのように変わったのか、の情報を全部覚えておけないから
- 再現率の低いバグの再現条件の洗い出しのため
- 再現しにくいバグの情報をかき集める時に「数カ月前の実験の時どうだったっけ」ってなることがある
- ロボコンで重要なのは言わずもがな
- バグを実際に見た時に、思ったことを後から振り返るときに必要だから
-
- 動かしてうまくいかない -> 考察する -> 変更する -> 動かしてみる を繰り返す
-
- 動かしてうまくいかない -> とりあえず変更する -> 動かしてみるを繰り返して、まとめて一日の終わりに考察する
- ロボットの場合、2の方が効率良いと思っている
- 特に実験場所の都合でロボットを動かせる時間が決まっている場合はなおさらだと思っている
- 2においてまとめて考察するときに細かい情報が必要
- 後（時には半年後レベルで）から変更したときの挙動の変わり方を参照したいから
- git使っていればそれが作業日誌にならない？
- ならないと思ってる
- 変更に対してどう結果が変わったかを書く必要がある
- gitのコミットで結果は書かない気がする
書き残す上での前提
- どこに書き残しているの？
- 僕は 個人のwikiに書いている
- 別になんでもいいと思うけど、何かしらで検索機能を有しているアプリ等を想定している
- この手の作業日誌で意識していること
- とにかく箇条書きで書きなぐる
- 綺麗に書こうと思わない、コマンドをコピペする、変更したパラメータをコピペする
- 実験の作業日誌において表は使わない方がいいと思っている
- これが綺麗にまとめようという意識が働いて書きなぐる精神が消える
- あとスライド形式で作業日誌書くのとかは違うやろって個人的に思っている
- 以下みたいな表はそれっぽく見えるのは分かるけど、書きなぐって後から検索すれば良くない？って個人的には思っている
- まとめながら作業日誌書くのが辛いと思っているけど、スーパー要領がいい人ならできる気もする
- 少なくとも僕はできない
| 時間 |
内容 |
作業 |
| 14:00 |
タスクA |
パラメータを変えた |
- (余談)
- なんで表形式が多いのかなぁと思ってふと「作業日誌 書き方」でggってみたら表形式しか出てこなくて地獄を感じた
- 日報というものが世の中ではWordとExcelに支配されているらしいと学んだ
- 単純作業の繰り返しの報告書なら表形式でいいも思うけど、バグが次から次へ湧いてくるロボット開発には向いてないと僕は思うのです