プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
で報連相について少し書いた。（以下、再掲し、すこしづつ手直し。）
<この項は書きかけです。順次追記します。>
報連相
報連相というのが流行った時代があった。
報連相は、報告、連絡、相談の略。
報告も、連絡も、相談も、その費やした労力に見合う成果があればよい。
どんどん報連相が進む。
報連相がうまくいかないのは、ほとんどが、報告しても、連絡しても、相談しても、その労力に見合う成果がない場合。
報連相が、管理者が仕事をしているという振りをするための余分で無駄な作業になっている時。
ていうか、報告、連絡、相談したために無駄な作業が増える場合があちこちで散見。
日常の作業自体が報連相
電子的に作業をしていて、その作業内容が閲覧できれば、そこで報告と連絡は済んでいる。
gitでソースコードあげていれば、作業量もわかる。
コンパイルエラーなど、issueで必ず上げて入れば課題もわかる。
issueであがったものが相談だと思えばいい。
issueもcloseできない人に、相談しても仕方がない。
大事なのは、例えばコンパイルエラーがあったら必ずissueに記録すること。
それだけで、すごい量の報告になる。
報告でもあり、連絡でもあり、相談でもある。
自分で解決してもよい。すぐに思いついても、自分でissueをあげて自分でcloseすればよい。
対面だけが報連相じゃない。
報連相をしろって言っている人で、まともに相談に応じる人は１割も知らない。
報告
プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点
https://qiita.com/kaizen_nagoya/items/f322df6978853c708c99
それでも、翌日自分が休んだ時の引き継ぎや、自分が困っていることを誰かが助けてくれる可能性や、給料を貰っている場合には、評価の資料として、なんらかの記録があるとよい。
コンパイルしているなら、コンパイルのlogで十分。
というか、コンパイルしてエラーがでたlogを保存しない人たちがいるのは不思議で仕方がない。
どのソースをコンパイルしてどういうエラーが出て、それをどう修正したらどういうエラーが取れたかは、
記録しておいて、今後の参考にするとよい。
最新の設計環境ではそれらのlogに基づいて、修正候補を提示する機能をつけようという動きもあるやに風の便りに聞いている。
日報、週報、月報、年報の例は
プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
p.s.
報連相をうたっていた会社が倒産したことを忘れてはいけない。
報連相していて、仕事をしていなければ意味がない。
仕事をしている上で、より効率的に解決するための道具の一つ。
GitHub > docker > その他の電子記録 > 報連相
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190513 午前
ver. 0.02 追記 20190513 昼
ver. 0.03 追記 20190503 午後
ver. 0.04 表題追記 20190514
ver. 0.05 ありがとう追記 20230311
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
