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

ほうれんそう 法蓮草 v.s. 報連相

「ほうれんそう」という言葉をご存知だろうか。

私は法蓮草（ほうれんそう）が大好きだ。炒め物によし、おしたしによし、カレーによし。

そんな私が、報連相（ほうれんそう）は大嫌いだ。

報告しても、連絡しても、無駄なことをやらせるだけで、
役にたつことをしてもらったことがない。
相談なんてしようものなら、
そんなことはやるな、
それをやるならやめてもらわなきゃならぬ。最近では「パワハラ」というらしい事態は何度も経験した。
あっちをやってからやれ、
足ひっぱりの嵐が始まる。
報連相は無駄の嵐。

自分がLine, Slack, Facebook, Messengerほか、文字で
報告を受けたり、
連絡をもらったり、
相談を受けたら、
何か、今の自分で手伝えることがないなら、
既読スルーすることもある。

ごめんなさい。スルーするのは肯定文だと思っていただけると嬉しい。

前提(assumption)

組織または個人の年間目標、個々の事業目標を設定している。
人数は１人から１００万人くらいの組織を想定。

筆者の経験

３０００人くらいの組織（サービス業、情報処理含む）の人事経験６年。３万人の組織の系列組織で人事システムは連動。

1人から100人くらいの事業の責任者などを歴任。

報連相(report, message, consultation)

報連相というのが流行った時代があった。

報連相は、報告、連絡、相談の略。

報告しても、連絡しても、相談しても、その費やした労力に見合う成果がなければ、無駄な作業だと感じた。
ていうか、報告、連絡、相談したために無駄な作業が増える場合があちこちで散見した。

報連相をうたった組織が、大事なことについての連絡が不十分で、組織が崩れて言ったのを何度か目撃したかもしれない。

プログラマであれば、gitでソースコードあげていれば、作業量もわかる。
コンパイルもオンラインで作業していれば、コンパイルエラーなど、issueで必ず上げて入れば課題もわかる。
大事なのは、コンパイルエラーをissueに記録すること。
それだけで、すごい量の報告になる。
報告でもあり、連絡でもあり、相談でもある。

自分で解決してもよい。すぐに思いついても、自分でissueをあげて自分でcloseすればよい。

対面だけが報連相じゃない。

報連相をしろって言っている人で、まともに相談に応じる人は１割も知らないかもしれない。

ソースコードだけで十分な場合

VZ

gitなどのない時代から、ソースコードをネットにあげて作業しているのは、オープンソース（フリーソフト）だけではありませんでした。
例えば、VZエディタというアセンブラのソースコードのついているソフトウェアでは、お互いに特定の版のソースコードを持っていることを前提に、ソースコードの差分をネットにあげて作業していました。

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

ソースコードだけでよいのは、すべてのソースコードがある場合です。
すべてのソースコードがないと、設計の良し悪しはわかりません。

ソースコードではわからないという話の半分くらいは、すべてのソースコードを受け渡しをしていない場合でした。

「ソースコードではわからない」のではなく、「すべてのソースコードがないとわからない」のです。

makeできない

ソースコードがあってもmake(ビルド）できなければ意味がない。
ソースコードだけでよい場合は、お互いの開発環境で、どちらでも同じソースコードがコンパイル（VZの場合はアセンブル）できる必要がある。

ソースコードではわからないのではなく、
ソースコードをコンパイル（アセンブル）する方法がわからないのです。

ソースコードで仕事をするときは、まず、相互にコンパイル環境がどうなっているかを知らせ合います。

今では、dockerという、コンパイル環境そのものをやりとりできるようになりました。

コンパイル（アセンブル）する方法がわからない確率が大幅に減ってきました。

ちなみに、私の記事の最大のviewsがあるのは、WindowsにAnaconda(Python)を導入する記事です。
Deep Learningの読書会で、最大の壁はWindowsにAnacondaを導入することでした。

M.S.WindowsにPython3 (Anaconda3) を導入する（7つの罠）
https://qiita.com/kaizen_nagoya/items/7bfd7ecdc4e8edcbd679

docker(18) なぜdockerでpython/Rを使って機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

構成管理

ソースコード全部があっても、ある枝分かれと、別の枝分かれの中に、逆の役割を果たすようなソースコードが入って入れば、混乱する。

例えば、時間優先の枝に、空間優先のソースが入っていたり、
空間優先の枝に、時間優勢のソースコードがはいっていれば、どうするとよいかわからなくなることがある。

全体を見渡せる人が、構成管理または交通整理をしていることが大事だ。文書ではなく、人だ。

Linuxのカーネルソースの議論で、Alac Coxが答えてくれたことがある。日本では誰も返事をくれなくても、本家に行けば検討してもらえる。全体を見ている人が、構成管理または交通整理をしていればよい。その人が必要な文書はあってもいい。ソースコードだけだったりすることもある。

報告・連絡(report)

公開の事業では
https://github.com/kaizen-nagoya

非公開の事業では
https://gitlab.com

のissueをまず上げる。

緊急の場合には、Lineで連絡するか、slackで連絡するか、facebookのmessengerで連絡するかは事業、相手によりそれぞれ。

資料を整理して記録しようとすると解決することが１割から２割程度ある。
また、整理した資料に、ネットで検索して追記していくと解決することが１割りから２割程度ある。
自己解決の割合は２割から３割くらい。

プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点
https://qiita.com/kaizen_nagoya/items/f322df6978853c708c99

それでも、翌日自分が休んだ時の引き継ぎや、自分が困っていることを誰かが助けてくれる可能性や、給料を貰っている場合には、評価の資料として、なんらかの記録があるとよい。

コンパイルしているなら、コンパイルのlogで十分。
というか、コンパイルしてエラーがでたlogを保存しない人たちがいるのは不思議で仕方がない。

どのソースをコンパイルしてどういうエラーが出て、それをどう修正したらどういうエラーが取れたかは、
記録しておいて、今後の参考にするとよい。

最新の設計環境ではそれらのlogに基づいて、修正候補を提示する機能をつけようという動きもあるやに風の便りに聞いている。

プログラマにも読んでほしい「QCべからず集」
https://qiita.com/kaizen_nagoya/items/d8ada7b7fceafe2e5f0e

にも書いたが、無駄なことが１日の時間の半分を超えたら、日報、週報、月報の片隅にそっと書いておこう。質問でもいい。XXは無駄ではないですか？って。

上から言われれば、やむをえないこともあります。
顧客から言われれば、やらざるをえないこともあります。
それらが半分の時間を超えたら、日報か、週報か、月報で警告を出してみましょう。

そこで、日報、週報、月報、年報に必要な内容と実例を記録する。

日報(daily report)

GitHub, bitbucketなどを利用している場合には、
ソース、issueに対する記録だけで日報を自動生成してもよい。

gitコマンドで、メールで日報を紹介していただいていた記事参照。

gitで今日の作業を振り返る @mironal
https://qiita.com/mironal/items/bccdffaaf720a60672df

$ git log --after="`date '+%Y-%m-%d'` 0:0" --oneline --branches * | mail -s "本日の作業報告" [e-mail]

githubやbitbucketなどと連携していない作業では、コンパイルエラーや、インタプリタのエラーがあるとよい。

また、RPAという仕組みのうち、記録部分を有効活用してもよいかもしれない。

Web Isolation, RPA, Deep Learning, 量子コンピュータ,HAZOP
https://qiita.com/kaizen_nagoya/items/29c7bac44861503a0612

業務のメールは全部上司または日報管理者にccまたはbccしておき、日報を自動生成してもよい。

コンパイルも、メールもない日は、timetrackerというソフトが自動記録を補助してくれるかもしれない。
https://www.timetracker.jp

いずれにしても、日報の基本は自動生成。

質問、相談などを日報に書いてもいい。

事例 日報(case study daily report)

上記記事とは真逆の話。

名古屋市工業研究所の研修生の方には、
1 わかったこと
2 わからなかったこと
3 よかったこと
4 あらためるとよいこと
を報告してもらっている。

前提として、目標設定を最初にしており、ある期間で到達する目標を設定しているため、
今日、何をしたかどうかは、わかったこと、わからなかったことから逆算できるかもしれない。

やったことを報告すれば報告だというのが一番危険。
わかってやったのか、わからずにやったのか、それが課題。

現在、 システムはcybozu liveを使っていた。2019年３月までなので、どこに乗り換えようか探し中だった。bitbucketでやっている少人数の事業はbitbucketで閉じてやれるように模索中。結果として、Gitlabに移行した。ただし、オープンソースの案件はGithubに移行した。

KPTという手法同様、このやり方を固定して長くなると抜け漏れや、冗長化や、マンネリに陥る。報連相同様、作った労力以上の成果を作成者に返すことが大事。

管理者だけで返そうと思うのは無理。相互扶助を基本にしないと管理者は倒れる。
何人か、倒れたり、病欠になった管理者を知っている。

報告したらそれにお返しをするのを自動でやるのは一つの考え。そうでないと管理者が疲弊するかも。

JubatusでQiita記事を推薦してくれる日報アプリ作ってみたhttps://qiita.com/kawasyaki/items/431b3e49cd727d93d278

報連相　再考。仮説（40）

プログラマが英語で報告・質問する時のいくつかの事例・方法。英語(8) 仮説(97)

週報(weekly report)

日報を自動生成するとして、週報もそれを５つ重ねれば、自動生成も可能。

ただし、それぞれの日報間の抜け漏れ、優先順位の変化、
課題に計上したものと、そのうちで解決したものとの関係などについての
個人的な見解があるとよいかもしれない。

事例　週報(case study weekly report)

その週でやったことを5分のLTで報告してもらっている。
スライドを３枚から１０枚くらい作成して報告している。
私の場合は、slideshareに掲載した内容か、Qiitaの記事を報告にしている。

GitHub, bitbucketから週報を自動生成するスクリプトを調査中。
下記参考文献欄の日報等のスクリプトを順次試し中。

月報(monthly report)

月給制の場合には、日報、週報を自動生成したものを集めたものでもよい。

年間の目標または四半期の目標を立てている場合には、その目標の達成上の
成果、課題（未解決事項）、あるとよい資源などについての記載があるとよい。

年間の目標達成とうまく連携していない場合には、目標の見直しを助言するかどうかが管理者の仕事かも。

年報(annual)

月報を１２集めたものでもよい。

年間の目標、個々の事業目標との関係の把握が可能かどうか。

管理者がボーナス査定に使うばあいには、事実関係の確認、抜け漏れ、無駄の確認をするとよい。

考察(consideration)

タスク管理についての個人的まとめ
https://qiita.com/Amebayashi/items/55448bb5321d7e752f14

で違和感があったのは、対策に並んでいることが優先順位がついていないこと。
ある場合の優先順位は下記。

1. 作業方法見直し 2. 優先順位の見直し 3.教育訓練 4.作業者の見直し 5.納期調整 6.残業

という感じです。作業方法見直しには道具の変更（導入）を含みます。

要員増やしは作業遅延の最大の要因だったりするので候補に入れていません。
助っ人を頼むことはあります。助言や、道具の導入、作業方法の見直し、優先順位の見直し、教育訓練など、実作業以外で。作業者に、作業方法の見直しの案が出てこない時など。

相談(consult)

日本語でコンサルタントというと印象が悪いことがある。
それは、コンサルタントを吊し上げたことがない人の印象かもしれない。

20代の頃、IBMを退職されたコンサルタントの方と、合計１週間程度の合宿研修を受けたことがある。

ことごとく、コンサルタントの発言に食いついて反論した。
コンサルタントの方が話す前提となる状況が全然違うのである。

僕らは自分でプログラム書いて解決している。
SIerに発注することを前提としたコンサルでは話にならない。

コンサルタントは経験がある。吊るし上げると、自分たちで作る場合に参考になる話をつぎつぎしてくださった。

その当時、開発班３人のうち１人はプログラムを書かれず、プログラムを書く人との間に溝があった。コンサルタントを吊し上げていくうちに、コンサルタントが役に立ちそうな話をしてくだると、コンサルタントに対する信頼ではなく、プログラマに対する信頼を持ってくださった。

コンサルの使い方の基本だとわかった。日本でもいろいろな組織で、コンサルタントの国籍を問わず、基本行動原理だとわかった。

コンサルを含む相談相手に、いいかげんな答えを許すのは、自分が悪いのだということを告白しているのかもしれない。

参考資料(reference)

新人の方によく展開している有益な情報

マネージャー・リーダーの私にとって有益な知見が得られた書籍

日報(daily report)

日報の書き方
https://qiita.com/sassy_watson/items/6f50e4ff64d9455aa9dc

成長に差が出る日報駆動開発(DRDD)について
https://qiita.com/senseiswift/items/8816e8a528939cabf3ee

開発以外の仕事でやってるちょっとした自動化の紹介
https://qiita.com/toyoshi/items/f620efe654cffdbf7731

日報を自動作成する
https://qiita.com/jTakasuRyuji/items/8940364dd90db65fc234

Qiita:Teamで日報管理している方へ向けて
https://qiita.com/syossan27/items/2fcd710ad84f618ca3bf

outlook のVBAで日報提出
https://qiita.com/Naoki_Narematsu/items/b828637616c868edfdb7

日報強制Botを作った話
https://qiita.com/T_2/items/7807dc6e564795fb16fb

意見：日報自体は自動生成でいいとおもっています。このBotは、何かの意見をだしてもらいたい場合や、修正を出して欲しい場合に利用できればと思います。そのため、ソース収集botまたは意見収集botという感じで、github, bitbucketでと連動している場合でも使えるかもしれません。

slack

Slack で日報を運用する
https://qiita.com/hoto17296/items/442b816fcc6d17136fc1

Slack Web API + JavaScript で Slack 分報 から 日報を作成する
https://qiita.com/mihoko_az/items/eb050d3fdc20ec8d8e8a
「Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ」を読んで
https://qiita.com/acairojuni/items/f3ed4745b636ccbffff3

google

Google Calendar から日報を生成する
https://qiita.com/vkgtaro/items/4d39790707c594f2cd9e

新卒一年目がGASで日報自動出力アプリケーションを作るまで（1/2）
https://qiita.com/nagaminenot/items/120ed37b40ea1db01646

新卒一年目がGASで日報自動出力アプリケーションを作るまで（2/2）
https://qiita.com/nagaminenot/items/c6fd5e5e9b553989693f

git

日報用git-log
https://qiita.com/Layzie/items/acb685e9d4fcc138cc67

Git で今日の作業を確認する(日報のお供)
https://qiita.com/sotarok/items/b1f537b77f31aa010b8f

slackに当日の自分の作業分のgit logを流す
https://qiita.com/n_slender/items/f9cbfeaaa637487cf97c

issue

open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6

日報

GitHub のコミットログを日報がわりにする
https://qiita.com/kyanny/items/4b677ef2d3276683e98e

日報をVimで書く
https://qiita.com/kentaro/items/3090998366e8e6e15c87

週報(weekly report)

英語で週報を書こう

めんどくさいExcel週報をRubyスクリプトでサクッとメール送信する
https://qiita.com/damassima/items/f5bb078fa907cd6fc873

[GAS]GoogleAppsScriptで報告資料の定期自動複製
https://qiita.com/hanahiro_aze/items/4762635643e1d3c7b300

まだ勤怠処理で消耗してるの？nightmareによる自動化のススメ
https://qiita.com/kumabook/items/de159bd02de5458927b8

便利！無料で使えるStatsbot！Google Analyticsの情報をSlackへ通知する方法とchannel毎にスケジュール通知を設定する方法
https://qiita.com/norhythm/items/a7d5f00b6ca66306fefd

009-週報提出フォームを作成したい
https://qiita.com/co-ikeya/items/3f79d6503b38e8bd6972

月報(monthly report)

OSS コントリビューションや GitHub 上のアクティビティのまとめレポート投稿を自動化する
https://qiita.com/sugarshin/items/cf89e5e03fd839cf6f90

Pentahoのインストールと基本設定
https://qiita.com/mik/items/07112c344e658811463c

Mac のClipMenu にアクション（JavaScript）を追加する
https://qiita.com/Humangas/items/be139d59d918ea2af985

便利！無料で使えるStatsbot！Google Analyticsの情報をSlackへ通知する方法とchannel毎にスケジュール通知を設定する方法

関連事項(additional information)

与件解析(data analysis)入門
https://qiita.com/kaizen_nagoya/items/d9474c3bdb8ea0029bee

計算機・ソフトウェアが思うように動かなかった時にするとよい１０箇条
https://qiita.com/kaizen_nagoya/items/3ba624e1d88b97d62d89

プログラマが心がけるとよい文章の書き方
https://qiita.com/kaizen_nagoya/items/af1e6207ccaa063dafb8

プログラマの思い込みの激しさは強みであって弱点ではない３つの理由
https://qiita.com/kaizen_nagoya/items/bc5dd86e414de402ec29

2020年の開発者が知っておくべき11の必須技能→回答編 → 並べ替え→項目合併(8項目)→内容追記
https://qiita.com/kaizen_nagoya/items/39e1c69bddb8e608b42b

人格改造　あいうえお　取組中
https://qiita.com/kaizen_nagoya/items/bfae8b4a486ee5fd72de

文書履歴(document history)

ver. 0.01 初稿 20180815
ver. 0.02 参考文献追記 20181218
ver. 0.03 open issue 追記　20190208
ver. 0.04 はてなブックマーク　追記 20190225
ver. 0.05 gitで今日の作業を振り返る@mironal 追記 20190526
ver. 0.06 自己解決追記 20200217
ver. 0.07 プロセス改善に関して、個人的に有益な情報 https://qiita.com/kazuo_reve/items/2c9a2d13bd57282bec1f にリンクを貼っていただけたのを機に、表現を補正。20210220
ver. 0.08 追記 20210304
ver. 0.09 見出し追記 20210501
ver. 0.10 ソースコード、make, 構成管理、追記 20210515
ver. 0.11 見出しから検証削除 20220218
ver. 0.12 はじめの文章添削 20220404
ver. 0.13 タグ変更　20220611

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞

http://b.hatena.ne.jp/guide/bbutton

最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.