ほうれんそう 法蓮草 v.s. 報連相
「ほうれんそう」という言葉をご存知だろうか。
私は法蓮草（ほうれんそう）が大好きだ。炒め物によし、おしたしによし、カレーによし。
そんな私が、報連相（ほうれんそう）は大嫌いだ。
報告しても、連絡しても、無駄なことをやらせるだけで、
役にたつことをしてもらったことがない。
相談なんてしようものなら、
そんなことはやるな、
それをやるならやめてもらわなきゃならぬ。最近では「パワハラ」というらしい事態は何度も経験した。
あっちをやってからやれ、
足ひっぱりの嵐が始まる。
報連相は無駄の嵐。
自分がLine, Slack, Facebook, Messengerほか、文字で
報告を受けたり、
連絡をもらったり、
相談を受けたら、
何か、今の自分で手伝えることがないなら、
既読スルーすることもある。
ごめんなさい。スルーするのは肯定文だと思っていただけると嬉しい。
<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words in order.
前提(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 "本日の作業報告" butyo@example.com
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）
https://qiita.com/kaizen_nagoya/items/013f2779bd2beba720b7
プログラマが英語で報告・質問する時のいくつかの事例・方法。英語(8) 仮説(97)
https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67
週報(weekly report)
日報を自動生成するとして、週報もそれを５つ重ねれば、自動生成も可能。
ただし、それぞれの日報間の抜け漏れ、優先順位の変化、
課題に計上したものと、そのうちで解決したものとの関係などについての
個人的な見解があるとよいかもしれない。
事例 週報(case study weekly report)
その週でやったことを5分のLTで報告してもらっている。
スライドを３枚から１０枚くらい作成して報告している。
私の場合は、slideshareに掲載した内容か、Qiitaの記事を報告にしている。
GitHub, bitbucketから週報を自動生成するスクリプトを調査中。
下記参考文献欄の日報等のスクリプトを順次試し中。
月報(monthly report)
月給制の場合には、日報、週報を自動生成したものを集めたものでもよい。
年間の目標または四半期の目標を立てている場合には、その目標の達成上の
成果、課題（未解決事項）、あるとよい資源などについての記載があるとよい。
年間の目標達成とうまく連携していない場合には、目標の見直しを助言するかどうかが管理者の仕事かも。
年報(annual)
月報を１２集めたものでもよい。
年間の目標、個々の事業目標との関係の把握が可能かどうか。
管理者がボーナス査定に使うばあいには、事実関係の確認、抜け漏れ、無駄の確認をするとよい。
考察(consideration)
タスク管理についての個人的まとめ
https://qiita.com/Amebayashi/items/55448bb5321d7e752f14
で違和感があったのは、対策に並んでいることが優先順位がついていないこと。
ある場合の優先順位は下記。
- 作業方法見直し 2. 優先順位の見直し 3.教育訓練 4.作業者の見直し 5.納期調整 6.残業
という感じです。作業方法見直しには道具の変更（導入）を含みます。
要員増やしは作業遅延の最大の要因だったりするので候補に入れていません。
助っ人を頼むことはあります。助言や、道具の導入、作業方法の見直し、優先順位の見直し、教育訓練など、実作業以外で。作業者に、作業方法の見直しの案が出てこない時など。
相談(consult)
日本語でコンサルタントというと印象が悪いことがある。
それは、コンサルタントを吊し上げたことがない人の印象かもしれない。
20代の頃、IBMを退職されたコンサルタントの方と、合計１週間程度の合宿研修を受けたことがある。
ことごとく、コンサルタントの発言に食いついて反論した。
コンサルタントの方が話す前提となる状況が全然違うのである。
僕らは自分でプログラム書いて解決している。
SIerに発注することを前提としたコンサルでは話にならない。
コンサルタントは経験がある。吊るし上げると、自分たちで作る場合に参考になる話をつぎつぎしてくださった。
その当時、開発班３人のうち１人はプログラムを書かれず、プログラムを書く人との間に溝があった。コンサルタントを吊し上げていくうちに、コンサルタントが役に立ちそうな話をしてくだると、コンサルタントに対する信頼ではなく、プログラマに対する信頼を持ってくださった。
コンサルの使い方の基本だとわかった。日本でもいろいろな組織で、コンサルタントの国籍を問わず、基本行動原理だとわかった。
コンサルを含む相談相手に、いいかげんな答えを許すのは、自分が悪いのだということを告白しているのかもしれない。
参考資料(reference)
新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1
マネージャー・リーダーの私にとって有益な知見が得られた書籍
https://qiita.com/kazuo_reve/items/6976029e72763ea73245
日報(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 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)
英語で週報を書こう
https://qiita.com/chatarun/items/f9d3e8cb00016b24cecf
めんどくさい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毎にスケジュール通知を設定する方法
https://qiita.com/norhythm/items/a7d5f00b6ca66306fefd
関連事項(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
自己記事一覧
物理記事 上位100
https://qiita.com/kaizen_nagoya/items/66e90fe31fbe3facc6ff
量子(0) 計算機, 量子力学
https://qiita.com/kaizen_nagoya/items/1cd954cb0eed92879fd4
数学関連記事１００
https://qiita.com/kaizen_nagoya/items/d8dadb49a6397e854c6d
統計(0)一覧
https://qiita.com/kaizen_nagoya/items/80d3b221807e53e88aba
品質一覧
https://qiita.com/kaizen_nagoya/items/2b99b8e9db6d94b2e971
言語・文学記事 １００
https://qiita.com/kaizen_nagoya/items/42d58d5ef7fb53c407d6
医工連携関連記事一覧
https://qiita.com/kaizen_nagoya/items/6ab51c12ba51bc260a82
自動車 記事 １００
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5
通信記事１００
https://qiita.com/kaizen_nagoya/items/1d67de5e1cd207b05ef7
日本語（０）一欄
https://qiita.com/kaizen_nagoya/items/7498dcfa3a9ba7fd1e68
英語(0) 一覧
https://qiita.com/kaizen_nagoya/items/680e3f5cbf9430486c7d
転職(0)一覧
https://qiita.com/kaizen_nagoya/items/f77520d378d33451d6fe
仮説（0）一覧（目標100現在40）
https://qiita.com/kaizen_nagoya/items/f000506fe1837b3590df
音楽 一覧(0)
https://qiita.com/kaizen_nagoya/items/b6e5f42bbfe3bbe40f5d
「@kazuo_reve 新人の方によく展開している有益な情報」確認一覧
https://qiita.com/kaizen_nagoya/items/b9380888d1e5a042646b
Qiita(0)Qiita関連記事一覧（自分）
https://qiita.com/kaizen_nagoya/items/58db5fbf036b28e9dfa6
鉄道（０）鉄道のシステム考察はてっちゃんがてつだってくれる
https://qiita.com/kaizen_nagoya/items/26bda595f341a27901a0
安全（0）安全工学シンポジウムに向けて: 21
https://qiita.com/kaizen_nagoya/items/c5d78f3def8195cb2409
一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39
Ethernet 記事一覧 Ethernet(0)
https://qiita.com/kaizen_nagoya/items/88d35e99f74aefc98794
Wireshark 一覧 wireshark(0)、Ethernet(48)
https://qiita.com/kaizen_nagoya/items/fbed841f61875c4731d0
線網（Wi-Fi）空中線(antenna)(0) 記事一覧(118/300目標)
https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001
OSEK OS設計の基礎 OSEK(100)
https://qiita.com/kaizen_nagoya/items/7528a22a14242d2d58a3
Error一覧 error(0)
https://qiita.com/kaizen_nagoya/items/48b6cbc8d68eae2c42b8
++ Support(0)
https://qiita.com/kaizen_nagoya/items/8720d26f762369a80514
Coding(0) Rules, C, Secure, MISRA and so on
https://qiita.com/kaizen_nagoya/items/400725644a8a0e90fbb0
プログラマによる、プログラマのための、統計(0)と確率のプログラミングとその後
https://qiita.com/kaizen_nagoya/items/6e9897eb641268766909
なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2
言語処理100本ノックをdockerで。python覚えるのに最適。:10+12
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4
プログラムちょい替え（0）一覧:4件
https://qiita.com/kaizen_nagoya/items/296d87ef4bfd516bc394
Python(0)記事をまとめたい。
https://qiita.com/kaizen_nagoya/items/088c57d70ab6904ebb53
官公庁・学校・公的団体（NPOを含む）システムの課題、官（０）
https://qiita.com/kaizen_nagoya/items/04ee6eaf7ec13d3af4c3
「はじめての」シリーズ ベクタージャパン
https://qiita.com/kaizen_nagoya/items/2e41634f6e21a3cf74eb
AUTOSAR(0)Qiita記事一覧, OSEK(75)
https://qiita.com/kaizen_nagoya/items/89c07961b59a8754c869
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
LaTeX(0) 一覧
https://qiita.com/kaizen_nagoya/items/e3f7dafacab58c499792
自動制御、制御工学一覧（０）
https://qiita.com/kaizen_nagoya/items/7767a4e19a6ae1479e6b
Rust(0) 一覧
https://qiita.com/kaizen_nagoya/items/5e8bb080ba6ca0281927
100以上いいねをいただいた記事16選
https://qiita.com/kaizen_nagoya/items/f8d958d9084ffbd15d2a
小川清最終講義、最終講義（再）計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on my individual experience. It has nothing to do with the organization or business to which I currently belong.
文書履歴(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
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
