仕事ができるようになるちょっとしたコツ：プロセス記述法
雑魚には仕事術が必要である
僕は雑魚エンジニアである。
飯を食べるためだけにエンジニアをやっている。
モチベは低いし、技術に興味はない。
加えてガッツもなければ、体力もない。
でも、努力は最低限しかやりたくない。
なので仕事術は必須である。
「量をこなす」という仕事ができるようになる最強の技が使えないため、
仕事術により効率を上げる必要があるのだ。
今回紹介する仕事術はとある自己啓発本で見つけたものである。
実践してみたところ、快適になり、周りからの評価が上がったので紹介する。
ちなみに僕という雑魚が「雑魚用の仕事術・ライフハック」を雑魚達の生存戦略というカテゴリーでまとめているので、興味がある方は他の記事も読んでみてください。
作業プロセス記述法
偉大なる作曲家「ヘンデル」は作曲プロセスを毎度記録していた。
その記録を読めばヘンデルがどういう思いで、どういったふうに作曲したか理解できる。
そして、後世の作曲家達の参考になり、音楽会に多大なる影響を与えたとされている。
プロセスを記述することで自分の仕事を周りの人に理解してもらいやすくなる。
上記のような文章を自己啓発本で読み、とりあえず仕事中にやってみた。
仕事を任されたら下記のようなプロセス・推論を徹底してnotionというノートアプリにまとめた。
・今回の仕事の達成したいこと
・参考資料、参考リンク
・プログラミング中の実装メモ
・エラー内容
・動作確認方法
・動作確認結果
・スケジュール
・問題に対する推論、試したこと
・何が分からないか、理解していないか
僕はnotionを使ったけどツールは何でもいいと思う。
IT業界だとけっこう会社でノートアプリやドキュメントツールを契約していることが多いので、それを使えばいいと思う。
グーグルドライブ内にスプレッドシートで書いても良いし、共有フォルダにテキストファイルを置いても良い。
ちょっとでも思考能力を鍛えられればいいなあ、
くらいに思っていたのですが、
続けているうちに思った以上にメリットがあることに気づきました。
プロセス記述法のメリット1：説明が楽
エンジニアをやっていると、
自分が実装したプログラムに対して質問が飛んでくることが多い。
「～さんの実装した所なんですが、ここってどういう動作するんですかね？
軽く説明してもらえませんか？」
上記のような質問に回答したくても、
一ヶ月以上前のことなんて僕はほぼ覚えていない。
一ヶ月前の自分なんて細胞入れ替わりまくってるし、
もはや他人ではなかろうか。
コードを書いたのは僕だが、内容なんて蒸発して消えている。
雑魚エンジニアの僕は質問されることが嫌いだった。
質問の回答という面倒な作業をプロセス記述法は劇的に楽にしてくれる。
プロセス記述法によりがっつり記録を残していると、
資料をぶん投げるだけで説明ができるのだ。
「資料の～あたりに記載しています。ご確認ください」
とメッセージを添えて、
該当資料のリンクをぶん投げるだけで説明が完了するのだ。
口頭で説明を求められても、
資料を見ながらであればかなり詳しく説明できる。
なにせ自分の推論や思考の動きまで記述してあるのだから、
さすがに思い出しやすい。
とりあえず質問が飛んできたら作った資料に目を通せばよい。
PCの環境設定などの面倒くさいフローもプロセスとしてメモっておけば簡単に再現できる。
新しい人員が追加され、初期セットアップを手伝う時なども資料を投げつければ終わり。
素晴らしい。
プロセス記述法のメリット2：不適正な難易度の対策になる
どんな仕事でも共通していることだと思うが、仕事の難易度はとても重要だ。
簡単すぎると飽きるし、難しすぎると死にたくなる。
エンジニアをやっていると難しすぎる案件をふられて発狂しそうになるのはよくあることだ。
プロセス記述法でメモりまくっていると、
不適正な難易度の時に助かることが多い。
簡単すぎる場合、
完全に理解している状態でプロセスを書くから資料の完成度が非常に高くなる。
資料を読めば簡単であったことが一目瞭然である。
上司が目を通せば、
「しっかり作業しているな。もう少し難しいものを渡しても大丈夫だろう」
と判断しやすくなる。
よって次にふられる案件の難易度が適正に近づきやすい。
実力的に難しい場合、
理解できていないから資料の完成度が下がる。
推論が多くなり、
「ここはどうすればいいのか？」「～を試したがNGだった」
のようなマイナス表現が多くなる。
でも、プロセスを記述しているので試行錯誤したことは証明できる。
さて、その資料を提示して上司に相談した場合、どう思われるだろうか？
少なくとも悪い評価はされないと僕は思っている。
仮定や推論を繰り返し、悪戦苦闘したことがプロセスとして残っているからだ。
頑張っている人に悪い評価は付け辛いのだ。
むしろ評価は上がるとさえ思っている。
正直に分からない点とそれに対する推論まで書いているし、
なにより頑張りが可視化されているのが大きい。
同じ雑魚だとしても頑張る雑魚のほうが可愛いものだ。
有能な上司なら資料を読めば「何が分かっていないか」も見抜ける可能性が高い。
そうなると的確なアドバイスを貰える確率もぐんと上がる。
さて、プロセスをメモって、それを公開しつつ作業していると上司がだんだん能力値を把握してくれる。
次にふられる案件が適正難易度になる可能性を上げられるのだ。
あくまで上司がまともであれば……だが。
プロセス記述法のメリット3：思考の整理がしやすい
誰から聞いたか忘れてしまったが、納得した言葉がある。
「思考とは書くことである。言語化して初めて考えたことになる」
つまりメモを書きまくるということは思考回数を増やすことになるのではなかろうか。
プロセスをメモっていると、前よりコーディングがしやすくなっている気がしている。
案件のドメイン知識や前提条件なども全部メモっているから、
前より頭の中がクリアに保たれている感じがある。
何かを忘れてしまっても資料を読み直せばいいから、気も楽だ。
参考書類・リンクなども全部メモってるからいつでも参考資料に帰れる。
エビデンスもないあくまで主観的な感覚だが、
「思考が整理されている状態」をキープしやすい感じがする。
プロセス記述法のデメリット：時間の消費
物事は表裏一体。
メリットもあればデメリットもある。
プロセスを記述しまくると素晴らしいメリットがあるが、
一時的に時間は喰う。
資料を探す手間や説明の手間を省けるので最終的にはむしろ時間を短縮できると思う。
でも、これまでになかったメモをとる時間は発生する。
僕は必要経費と割り切っているし、
総合的に時間を節約できるんだから全く問題ないと思っている。
しかし、上司によってはそんなドキュメントなんか作成してないで早く仕事しろ、と言われるケースもあるかもしれない。
そんな現場なら早く抜けたほうがよい。
まとめ
プロセス記述法は良い。
もうかれこれ半年以上続けているが、仕事がずいぶんと楽になった。
うざったい質問の回答が楽になったのが嬉しすぎる。
ぜひやってみて欲しい。
