継続は力なり―大器晩成エンジニアを目指して

第9回 ログのすすめ

この記事を読むのに必要な時間:およそ 2 分

試行錯誤とログ

動いているコードがないので,それを動くようにするのに試行錯誤が必要である。たくさんの試行錯誤をしているときに困るのは,⁠自分がどこで何をしているのか」がわからなくなることだ。時間の節約のために2つのことを同時に試してみる。作業中にチャットで話しかけられる。作業が日をまたぐ。あっという間にどこで何をしているのかがわからなくなる。

試行錯誤はツリー構造であることが多い。複数の枝X,枝Y,枝Zと順々に試していく。場合によってはX1,X2など枝Xの中に降りていってさらに試行錯誤をする場合もあるだろう。これらをツリーとして描くと,自分がどこにいるのか,どこに戻るべきかが明白だ。

ツリーを絵として描くのは面倒なので,その代わりにリスト2のようなログを利用する。先ほどと同様にネストしたリスト形式だ。このようにリスト構造でツリー構造を再現すれば,⁠自分がどこで何をしているのか」が一目瞭然である。

リスト2 試行錯誤の作業ログ

- システムAをローカルで動かしてみる
    - __done__ ライブラリDが必要らしい
        - __done__ dependencyに追加した
    - __here__ スタックトレースを見るとDIで失敗している
        - そもそもそのdependencyは必要なのか
    - 本番サーバのconfigを見てみる
- システムAをデバッガで動かしてみて処理を追う

復帰ポイントとログ

タスクが1日で終わらない場合,前日の作業から復帰しなければいけない。ドキュメントを読んでいたかもしれない。複雑な試行錯誤の途中だったかもしれない。ログを残していれば,先述のhereとマークを付けたところを検索して前後のログを読む。そうすれば簡単に作業を再開できるだろう。

相談相手としてのログ

ここまでは主に記録としてのログを取り上げてきた。だが筆者はログの一番大事な部分は「対話」だと考える。相談相手がいない状況を,ログを記録することを通して自分自身と相談しながら進んでいるのだ。自分にとってログをわかりやすく書こうと思う。自然とその事柄についてより深い理解が必要であることがわかる。自分が何をしようしているのか,どのような状態なのかを把握することになる。このように擬似的な客観性を持ちつつ自分自身と対話する。そのことが「作業を進める」助けになるのだ。

筆者はわからないことを,リストとしてログにまとめている。それぞれの質問の答えに近付くにはどうすればよいか。リストに書き足していくと前に進める。わからない状態のまま進む場合もある。答えがわかった時点で疑問点に立ち戻ればよいのだ。やってはいけないのは,誰にも相談できず,頭の中でぐるぐると堂々巡りになることだ。ログと相談しよう。

まとめ

複雑な作業をしているときは,自分がだめなループに入っていたり,パニックになっていたりすることに気付きにくい。筆者はそのような状況に陥ったことが何度もある(あとから気付いた⁠⁠。作業ログを書くことでより客観的な目線を手にできる。みなさんの作業効率が少しでも上がれば幸いである。

ログを読み返すのか

筆者の経験上,99%のログは読み返さない。作業している期間に見るだけである。以前は「ひょっとしたらあとから検索するかも?」とタグや検索キーワードを付けていたがほとんど使ったことはない。ただし,読み返さないからといって雑でよいわけではない。繰り返しになるが自身との対話が大事なので,取り組んでいる問題が複雑であるほど丁寧に書くべきだ。丁寧に書くというプロセスを経て,考えが整理されるのを感じると思う。

WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.122

2021年4月24日発売
B5判/168ページ
定価1,628円
(本体1,480円+税10%)
ISBN978-4-297-12119-8

  • 特集1
    上から下まで全レイヤ解説! 複雑化した世界を体系的に学ぶ
    Web技術総整理
  • 特集2
    新バージョン登場! PythonによるWeb開発の基本
    はじめてのDjango
  • 特集3
    Rustで実装!
    作って学ぶRDBMSのしくみ

著者プロフィール

ひげぽん(Taro Minowa)

Software Engineer.

Mona OS/Mosh Scheme

URL:http://www.monaos.org/
技術ネタ:http://d.hatena.ne.jp/higepon