自分の不具合対応記録 [vol.3] 資料を、整理整頓しないで1か所に、乱雑にため込んでいる。
私の最も苦手なことの１つに、「整理整頓」があります。
机回り、資料、PCのデスクトップやフォルダは、いつもモノがごちゃごちゃしてて、何か使いたいときは、まるで、昔流行った「ウォーリーを探せ」状態。
特に資料は、欲しい資料がすぐに出せず、仕事の効率にも影響が出ていました。
本やネットなどで、整理整頓のノウハウなどを見るけど、「いるもの・いらないもの」に、なかなか分別できなくて、とりあえず普段持ち歩く「ファイル」に綴じるか、机の上においてしまう。
後でまとめて片づけようと思いつつ、だんだん、机は、資料の要塞化・・・。
今回は、師走の大掃除シーズン真っ最中でもあるので、整理整頓のうち、主に「資料の取り扱い」について、不具合対応してみました。
◆状況
「資料の取り扱い」において、自分が起こしているトラブルは、主に以下のとおりです。
- 作業スペース、PCのファイル類、資料類など、いつもごちゃごちゃになっている。
- ワークファイルは満杯状態。
- 満杯の ワークファイルは、幅広タイプに移し替えて、持ち歩くファイルが大きくなる。
- 持ちきれなくなった資料は、机の上に積んでおく。
- たまに「整理整頓」しても、すぐに、また、乱雑な状態に戻る。
- 作業に追われていると、整理整頓する時間がもったいなく感じる。
- 「後で」「もう少ししたら」で、整理整頓は後回しにしておく。
- その結果、資料探しにあたふたして、作業効率が悪い。
- 欲しい資料を出そうと思うと、資料が見つからない。
- 過去の状況を聞かれた場合など、資料がすぐに提示できず、打合せを長引かせてしまう。
- 最新資料が曖昧になってしまい、最新状況を再確認しなくてはいけない。
- しかも、上司には言いにくいので、ばれないように、確認する。
- スケジュール上、作業開始しているはずが、実は、まだ、関係資料の確認に手間取っていることが多い。
◆原因(現状運用)
上記の各トラブルについて、原因を分析してみました。
資料の取り扱い方の現状運用です。
作業中の資料の場合
- 検討中、作業中、残作業状態、対応保留状態にものは、作業が完了していないので、すべて「検討中(ワーク)」ファイルに綴じておく。
- 「目に見えるところに出しておいたほうが、すぐに使えて効率的」といった気持ちで、机の上に置いておく
作業完了後の資料の場合
- 不具合等でまた使うかもしれないので、他の資料と同じファイルやカバンに入れて、もう少し手元に置いておく
- 数か月たったら、とりあえずもう使わないと思うので、手元から、机回りの、「空きスペース」に、とりあえず移動しておく
上記の行動の際、以下の「理由」がありました。
これらの「理由=自分の理屈」が、現実と違っていたため、いつも、資料を探すはめになっていました。
- 自分が、一番記憶できる場所に入れておけば、すぐ出せる （って、自分、記憶できる場所自体をわすれがちなのに）
- 使うものは、1か所にまとめておいておけば、すぐ使えて効率的
本音は、
- 一度、片づけてしまうと、次に必要になったとき、すぐに探し出せる自信がない（今までのしょっちゅう探し物をしている実績から・・・）
ので、片づけたくても、片づけられない状況を起こしていました。
◆解決案①と実施結果
上記のような、私のやらかしている様子を見た先輩が、資料の分類方法について、アドバイスしてくれました。
- 1か所にまとめておくにも、容量の限度があり、多すぎるとかえってわかりにくいので、分類したほうがよい
- ただし、「分類素人」が いきなり細かく分類しようとしてもかえって、分類に迷うので、まずは、３～４パターンぐらいがいいのではないか
- 資料は、「検討中」「正式版」「ボツ・過去資料」などのファイルに分類する
- 資料のカテゴリ、プロジェクトごとに、タグインデックスをつける
で、そのアドバイスを参考に、以下の分類基準で、まずは、今までためてあった資料を分類してみました。
- 検討中：現在作業中の関連資料、残作業項目(保留状態の作業も含む)の関連資料
- 正式版：プロジェクト完了状態の資料(納品物件状態の完成版）
- ボツ・過去資料：修正する前のNG資料、もう2度と使わない資料
う～～～ん、
作業自体をため込んでいる私の場合「検討中」に分類される資料が、圧倒的に多い・・・。
多少は、正式版、ボツ・過去資料に分けれたものの、あまり効果がなさそうな・・・。
でも、先輩に悪いし、上司の手前、整理整頓しているように見せないと、まずいだろうし・・・で、「とりあえず」3つのファイルへの分類をやってみることにしました。
上司や先輩からは、「最近、資料は、整理整頓できてる？」と聞かれるたびに、
「なんとか、整理整頓してます」
と、ちょっと曖昧な返事をして、その場を済ませていました。
(前回記事「自分の不具合対応記録 [vol.2] 自分の「ごまかし」を棚卸してみた - そろそろ「自分システム」の不具合対応をまじめにやってみようと思う」の、「自分のごまかしリスト」のNo５が発生していました。)
| No | 自分のごまかしの理屈・言動 | 現実（結果） |
|---|---|---|
| 5 | 資料、情報を、検討中、正式版、ボツに分類して、「検討中状態」をため込まない | すぐに、検討中にため込んで、数か月以上放置状態だが、上司には、分類しているように答える |
しばらくすると、「検討中」ファイルは、満杯状態に。
資料検索も、相変わらず、時間がかかってしまう点は、改善できませんでした。
この前の打ち合わせで、仕様確定版になった資料を見たいのに、その資料がぱっと出てこなくて、いらいらしてしまう。
確かに、「これから作業するための資料だから」ということで、検討中ファイルに入れたはずなのに。
なぜないんだ？といういら立ちばかりが・・・。
◆解決案②と実施結果
またまた、あたふたしている私の様子を見て、先輩から、
「資料の分類の定義、守れてる？」
と声かけられました。私は、前述の分類の定義を話し、
「分類はしてるけど、検討ファイルに一杯たまってしまう」
ことを伝えました。
先輩から、
「その分類の定義、おかしくない？」
と、指摘が・・・。
先輩のアドバイスに基づいて、資料の分類の定義をしなおしました。
（赤字部分が、解決案①のときと大きく変わる部分です）
- 検討中：現在「検討中」「作成途中」の資料のみを綴じる。
- 作業中のプロジェクトでも、仕様確定した資料は、正式版に移す。
- 保留状態の作業の関連資料は、いったん「ボツ・過去資料」ファイルに移す。
- 仕様検討中・資料作成途中のものが入っているので、製造（コーディング）時は、ここの情報を当てにしてはだめ。
- 正式版：仕様が確定した資料を綴じる。
- コーディングなどは、この「正式版」に入っている資料を見ながら、作業する。
- プロジェクトがすべて完了した場合、最終資料は、下記の納品版に移動する。
- ボツ・過去資料：修正する前のNG資料、現状しばらく使わない資料、対応保留中（残作業にずっと残っていて、上司との相談して保留中のもの）を綴じる。
- 対応保留中の作業が、再度復活したら、「検討中」ファイルに差し戻す。
- NG資料は、本来廃棄してもいいが、もし、過去のNG理由などを再確認したい場合を考慮して、一定期間保存する。
- 本当に使わないことが確定したら、このファイルから抜いて廃棄する。
- 納品版：プロジェクト完了状態の資料(納品物件状態の完成版）。
- 客先に渡したものの控えや仕様確定の最終版のもの。
- プロジェクト、フェーズごとにファイリングして、納品版保管場所で、管理する。
- 客先からの問い合わせ、仕様追加などの依頼があった場合、この納品版の情報を確認する。
- 客先に最終納品したものと同じ資料が入っているはず。
上記の定義により、正式版、ボツ・過去資料、納品版への分類ができるようになり、「検討中」に該当する資料が、一気に減りました。
私の、最初の分類の定義が間違っていて、「実際は、分類にならない基準」を設定していたため、先輩のアドバイスが活用できていませんでした。
◆今後の課題
解決案②のおかげで、以前に比べ、資料は整理できるようになってきました。
しかし、まだ、以下の課題が残っています。
- 定期的な資料の状態チェックの徹底化
- 作業に追われると、まだ、たまに、検討中に入れたままになっている資料があるので、もう少し、意識を保つ必要がある
- 「ボツ・過去資料」の整理整頓
- ボツ・過去資料に分類した、作業保留状態の残作業分の資料が膨大にあるので、残作業を早く片付ける、残作業の優先順位や要・不要の検討を行い、本当に不要の資料を、廃棄するなどを行い、机回りにある古い資料類を片づける
あと、今はやりの「ペーパーレス」化も、検討する部分がありそうです。
ただ、「紙」資料が持つ、「机に並べて一見しやすい」「その場で書き込み可能」「手書きの自由度が高い」「PC等のシステム、ネットワーク状況に左右されにくい」などのメリットを考えると、なかなか、紙も手放せないかなと。
ペーパーレス化を意識しつつ、「紙」資料の整理整頓を、まだ改善したいとおもいます。
自分の不具合対応記録 [vol.2] 自分の「ごまかし」を棚卸してみた
前回の記事の終わりに、私が、報告をしない（したくない）原因に、「スケジュールの立て方が、まずいのかも」と思い、「次は、スケジュール作成、管理について、不具合調査をしてみようと思う」と書いたのですが、その後、上司と話しをしていて、もっと重要なことに気が付いたので、そのことについて、先に考えてみたいと思います。
報告しているときの、上司からのつっこみ
上司から、また、作業報告の催促を受けてしまい、慌てて、作業の現状を説明していました。
自分の落ち度を突っ込まれないよう、言葉を選びながら話していたのですが、やはり、つけ刃的に、説明した内容では、「よくわからない」「話に違和感がある」らしく、報告内容について、上司は、いろいろ突っ込んできます。
聞かれたくないことほど、上司に細かく聞かれて、だんだん、返答に詰まってきてしまいます。
でも、自分の作業段取のまずさや考慮不足が発覚して、報告の時間が長引くのは避けたいので、上司の質問やツッコミに対して、「自分は考えてやっているアピール」の返事を返していました。
そのうち、上司が、
「ちょいちょい、ごまかしを入れてくるね」
と、ぼそっと言いました。
（ヤバイ。ばれてる）.
「そんなことは、ないです」と、さらにごまかしを追加したものの、上司には、言い訳できない状態。
「すいません」というしかなくなりました。
そのあと、上司から、私が、自分の仕事全般にかかわる、大きな問題を抱えていることを指摘されました。
その問題点は
「わたしは、報告や、自己認識の中に、その場しのぎ的に、ちょいちょいごまかしを入れて、自分もまわりも、間違った判断をさせている」
ということでした。
上司曰く、
「間違った情報からは、間違った判断しかできない」
この状態では、いくら、やり方を教えてもらったり、やり直ししてもうまくいかない。
「～の仕方」「XXXノウハウ」をいくらマネてみても、ごまかしが入る限り、うまくいかない・・・ですね。
私が見直すべき重要課題は
「ごまかしをしないで、正確な状況把握、認識、報告をすること」
と、言われました。
じぶんの、「ごまかし」の現状をあげてみた
そこで、私が、今までにやっていた「ごまかし」を、あげてみました。
| No | 自分のごまかしの理屈・言動 | 現実（結果） |
|---|---|---|
| 1 | 遅れを取り戻す | 遅れの取り戻し方すらわからず、夜中、休日まで、時間をかけて作業する。しかし、遅れは拡大している |
| 2 | 毎日、作業報告する | 上司に聞かれるまで、状況説明、報告しない。聞かれたくないと思っている |
| 3 | 段取を立ててから、作業する | よく考えるのが面倒くさい、よくわからないので、思い付いたことをリストアップした状態で、段取したとごまかして、作業に入る |
| 4 | 複数プロジェクト・作業を並行して進めるスケジュールを立てるので、今までより、早く売上があがるはず | 1つのプロジェクト、作業にかかりっきりになり、他のプロジェクトを放棄している |
| 5 | 資料、情報を、検討中、正式版、ボツに分類して、「検討中状態」をため込まない | すぐに、検討中にため込んで、数か月以上放置状態だが、上司には、分類しているように答える |
| 6 | 作業の前後を確認・考慮して、全体を把握する | 上司に言われたことだけ、その場で考えたくせに、前々から、いろいろ考えていたような話し方をして、ごまかす |
| 7 | 自分のスキル(現実)にあったスケジュールを立て、自己管理する（理想論で、ごまかさない） | 「やらなくていけない」の理想だけで、最初から無理なスケジュールを引く。スケジュールを引くと、できた気になり、その後は、スケジュールは無視する |
| 8 | リーダーとして、プロジェクト全体を管理し、自分から考えて行動し、売上アップできる状況を作る | 自分ではどうすればいいかわからないので、上司に言われたことだけしかやらない。しかし上司に言われたことも、間に合わせない。 |
| 9 | 作業環境を整理整頓しながら、効率よく作業する | あとでまとめてやればいいと、整理整頓をさぼる。後になって、時間が足りない中、慌てて整理整頓してミスを起こす |
| 10 | 人の話を否定しないで受け入れ、理解する | 人の話は、敵対心・偏見で、勝手な思い込みを入れながら聞き、自分のノウハウには、組み込まない |
| 11 | 話の論点をすり替えない | 言い訳したり、自分をよく見せようとして、話の論点や、話自体すりかえる |
| 12 | 上司、関係者に確認しながら作業する | 誰にも確認しないで勝手にやる。注意されると、せっかくやったのにと怒る |
| 13 | 頭のうろ覚えを当てにしないで、確認しながらやる | 確認が面倒くさいので、すぐに頭のうろ覚えをたよりにして、そのうろ覚えも曖昧で、嘘の結果しか得られていない |
| 14 | 今度こそは、ちゃんと（正しいこと、決めたことを）やる | 「ちゃんと」の中身がわかっていないので、今までと同じ作業をして、いい加減なものを作る |
| 15 | 自分の言いたいことより、相手の聞きたいことを先に話す | 自分の言いたいことだけ言って、相手の話は聞く気がない |
| 16 | 「今日はXXXをやる」と予定を決め、他人にアピールする | 決めてあった「XXX」をやらずにすぐに、自分のやりたい(おもいついた)ことを、ちょっとだけと言ってやり始め、メイン作業に勝手にすり替えてやる |
| 17 | 社内で取り決めたルールに従う | 面倒くさい部分はすべて無視して、自分のやり方でやって、失敗する |
| 18 | （やりたくない作業でも）やりますと答える | やりたくない作業は、後回しにして、そのままフェードアウトして、なかったことにしようとする |
| 19 | いいわけやごまかししないで、必要なことを、まじめにやる | すぐに言い訳、ごまかしの理屈を返して、済まそうとする。必要なことは、最初だけやりかけるが、実力つくまで継続してやらない。何か理由ができると、やらないことを正当化する言い訳で済ませる |
| 20 | スケジュール管理を毎日やる | スケジュールを何回引き直してもすぐに破綻する。また、すぐ遅れが出るので、スケジュール表も見なくなり、放置する。上司にスケジュール管理しているか聞かれると、「管理しているが遅れが出ている」と、管理していないことをごまかす |
| 21 | 作業しにくいと思ったら、上司、関係者に相談し、自分から効率化を図る | 他人に相談するのが面倒くさいと思い、勝手に、自分のやり方・順番に変えるか、不満を感じながらそのまま放置。うまくいかないと、他人のやり方が悪いと文句を言う |
| 22 | （上司、他人に）言われたことは、自分もやっている・わかっている・考える必要があると思っている | 言われる前は、気づいていない。言われてから、相手の言葉のうけうりで考えようとしているが、「ずっと考えているところ」とごまかす |
| 23 | 自分の作業の遅れ具合の現状を理解している | 遅れが拡大してきてヤバいということはわかるが、本当の遅れ具合（工数）が、明確にはわからず、放置している |
| 24 | わからないことがあったら、現状整理してわからない部分・理由を明確にしてからやることを決める | 状況がよくわからなくても、早く何かやらないといけないからと、とりあえず思いつくことをやる。思いつくところを調べる |
| 25 | 「大丈夫か？」聞かれると大丈夫と答える | 大丈夫といえる根拠がなく、願望で言っているだけ。間違った作業したり、よくわからず困っていたり、本当に良いかどうか迷っていることが多い。 |
| 26 | XXXをみて、学べた気がする（わかった気がする） | 何を学んだのかを、明確に言えない。本当は学んでいないが、願望から、調子の良いことを言っているだけ。 |
| 27 | 売上アップできる事業計画を立てて、実行に移す | 事業計画は願望だけで立てていて、現実は売上アップできる根拠がない状態。計画を立てて終わっている。実現できるような行動をしていない。 |
| 28 | STP分析、ペルソナ設定等のマーケ作業を行ってから作業に入る | 少し検討した状態で、すぐに実作業に入り、行き詰っている |
| 29 | 自社製品にあったマーケティングのフレームワークを構築して製品開発に役立てる | 受け売りのマーケティング分析作業すら、できていない。(何を売りにして、営業、製品開発すればいいかのアイディアがでていないのが証拠） |
| 30 | 世間の関心、ニーズを勉強する | 作業がたまっていることを言い訳にして、自分から勉強する時間を作り出していない。世間のニーズを勉強していない。そのため周りのマーケ情報を聞いても、ピンときてない。でもそれもごまかして、わかったような返事をする |
| 31 | XXX作業が落ち着いたら、営業回りする | 過去何回もその予定を言うが、他の作業を言い訳にして、営業回りしない |
| 32 | 客先に行く前に、交渉をイメージして、契約とれる商談を行う | 押し売りして契約とれない。客に契約してもらうために割引などしかできず、利益が出ない契約しかとれない |
| 33 | 客との商談の手応えでは、契約できそうな感じがする | よほど安い金額や、マシン入れ替え以外の新規システムの案件・提案は、断られている。自分の感じた「手応え」は、願望でしかなかった |
| 34 | 自社の過去の開発実績を見せれば、客は興味持つはず（多種多様の基幹業務の実績があるから） | 客の業務と同じ系統の実績がないとかえって、「合わない」と判断されて断られる。自分が、経験・スキル・知識不足だと、話をしているところで、見抜かれて、断られる。 |
| 35 | 顧客本位で考えられるように、客や上司、他人からの注意、不満は、素直に受け取る | 自分が気に入らない、気にしていること、都合の悪いことを言われると腹を立てて、言い訳したり、言い返したり、不機嫌な態度をする |
こんなに、いろいろと出てきて、非常に恥ずかしいです・・・。
（もっと細かなものまであげると、きりがない状態です）
自分の「この場の体裁を取り繕いたい」「根拠ないけど大丈夫」で、次々に出てくる「ごまかし」たち。
・結果的にごまかしになっているもの
・自分でも「ごまかし」と最初から認識しているもの
・大きなごまかし（現実と自分の言葉が対局にあるもの）
・ちょっと話を盛る程度のごまかし
「ごまかし」のタイプはいろいろありますが、こんなにいっぱい自分が「ごまかし」を発信しているとは・・・。
「ごまかし」していない時はあるんだろうか？と思うほどです。
たとえ、1個1個は、「ちょいごまかし」レベルであっても（「ちょい」では済まないものもありますが）、これだけの数(場面)を、ごまかししているとは、うまくいかないはずです・・・。
「ごまかし」の心理を考えてみた
なぜ、過去何度も、「すぐに上司にばれる」のに、私は、ごまかしをするのか？
「ごまかす」自分の思考、意識、心理の問題点は何か？
を、自分なりに、分析してみます。
ごまかしのパターンを分けてみました。
(A)他にやりたいことがあるので、その場を早くすませたい場合
（これ以上、注意を受けるより、早く話をおわらせて、自分の作業に戻りたい）
（面倒くさい勉強や調査に時間かけるより、早く実作業に移りたい。）
上記の表のうち、16個が該当しました。
(B)自分の体裁を取り繕う場合
（他人にバカにされたくない）
（自分は、ちゃんとやっている、考えているように見せたい）
これも、表のうち、17個が該当。
(C)やるべきことを、やっていないことを正当化する場合
（なるべく、面倒くさいこと、時間かかることやりたくないので、「ざっと」簡単に済ませて、ちゃんとやった」ことにして、次の作業に進みたい）
（苦手なことは、後回しにするときの、それらしい理由を主張）
これは2個でした。
ただ、表にはないものの、仕事以外でも、誰かに用事を頼まれたりしたときに、「今、XXXやってるから」とか「○○がないから、できない」という言葉が、口癖のようになっている感じはあります。
自分の心理は、以下のような感じのようです。
・スキルやノウハウがなく自信がない
↓
・でも、自分の「できなさ」をバカにされたくない（ここで、ごまかしで、見栄を張る）
↓
・自分のやり方で、なんとかうまくやりたい
↓
・報告などに時間とるより、早く自分の作業に戻りたい
↓
・とりあえず「わかった」体にして、この場をすませる（ここで、ごまかしで、わかったように「XXXします」という）
↓
・「やる」ことをやっていないことを指摘されると「XXXしていたので」と正当化を主張する（ここで、ごまかしの言い訳）
う～ん、私の心の闇が・・・。
今後の課題
私は、自分のごまかしによって、正しい状況の把握ができなくなっていて、その上、嘘やごまかしの情報で、自分自身が惑わされ、振り回されていることが見えてきました。
そして、そのことを指摘されると、イライラして、周りに対して、攻撃的になり、さらに、ごまかして、現実からずれて行ってしまうという、悪循環に、自分からはまり込んでいる状態です。
また、このブログを書いていて、1つ疑問が出てきました。
それは「理解する」「身に着ける」とは、どういうことなのか、を私は理解できているのかなということ。「本当の理解」ができていないから、どんな情報も薄っぺらくて、ちょっと突っ込まれると、返事ができなくなってしまう・・・。
今後の課題は、
・外に発信する前に、ごまかしにつながる自分の言動を自制する
（ごまかししたい気持ちを自制つき）
・そもそも「ごまかし」しなくて済むように、「早く」自分のスキルをつける
（スキルをつける際に、わかってないことをごまかさないという自制つき）
・「『理解する』『身に着ける』とはどういうことなのか」の本質を理解する
上記の課題を克服しながら、自分の日々の「やらかし」の不具合対応を、ごまかさないでやっていこうと思います。
自分の不具合対応記録 [vol.1] 「報告」をしない（後編）
前回の続きです
自分の不具合対応記録 [vol.1]「報告」をしない（前編） - そろそろ「自分システム」の不具合対応をまじめにやってみようと思う
前回のおさらい
前回、自分の、1日の作業の流れの現状調査を行い、「報告」に関係する、以下の問題点が、見えてきました。
解決案
以下のような解決案を考え、日々の作業に組み込んでみました。
1.作業報告のフォーマット作成
「上司が聞きたい順（事業全体の進捗→詳細作業の進捗状況）」に、
報告する項目を並べたフォーマットを作成しておく。
そのフォーマットを、毎日コピペして、書き込む。
フォーマットに記載する項目は、以下のとおりです。
記述例
2.上記のフォーマットに、毎日、書き込んでいく。
書き込んだら、作成した報告書を見ながら、
始業時と、退社前に、上司に報告する。
3.翌日（次）の作業開始時、前日の報告書
（特に「申し送り事項」と進捗表）を確認し、
本日の作業を確認する。
実施結果
このブログを書いている時点での、実施状況は以下の通りです。
・報告書のフォーマットを決めて、それに合わせて書き込む
ことにより、何から書こうという悩むことはなくなりました。
・WEBシステム上で、作業日報として、上記のフォーマットを
用意して、日々の状況をかきこんでいくことはできるように
なりました。
・報告書を見ながらであれば、上司が気にしている「大日程」
での現状部分から、上司のツッコミに合わせて、中日程、
小日程のように、順番に話すことができるようになってきました。
・部分的な1つの作業だけでの自己評価も減り、担当作業全体に
ついて、意識できるようになってきました。
・「作業の遅れ」の認識の仕方も、今までの、ある作業が
1日遅れだから、報告でも「遅れは1日追加」ではなく、
「1日*担当作業数（関係者数）」として、より、
状況を厳しく把握する意識はでてきました。
しかし、その反面、現状では、以下の課題がまだ
残っています。
・口頭での報告のタイミングがうまく図れず、いまだに、
上司の催促を受けてしまいます。自分から報告できず、
上司に問われてから答えることは変わっていません。
（運用の「ルーチンワーク化」がまだ完成できていない）
・私の報告書は、社内ネットであれば、閲覧可能なため、
上司は状況を確認できなくもないのですが、これでは、
コミュニケーションとしては、NG。解決には至っていません。
今後の課題
上記の課題の、原因は、今のところ、日々の作業の成果が
あがっていない（作業の遅れが取り戻せていない）ことが
大きいと思います。
私の場合は、報告の仕方だけを変えても、
報告しづらい状況では、
「もう少しやって、報告しやすい結果を出してから」
という自分の見栄、体裁を守りたい感情が、まだ、
「報告する」ルールを守る気持ちより強く、
「報告をしない」不具合の解消にならないことが、
わかりました。
自分が作成した、進捗表（作業スケジュール表）は、
常に、遅れた状態になっています。
この状態を、報告することが、とても嫌で、
気が重いです。
スケジュールの立て方が、まずいのかもしれません。
次は、スケジュール作成、管理について、
不具合調査をしてみようと思います。
自分の不具合対応記録 [vol.1]「報告」をしない（前編）
私は、報告書を書いたり、報告することが苦痛で、自ら、上司に作業報告をすることは、ほとんどありません。
そのため、いつも上司に、報告してないことを注意されます。
注意されると、2、3日は、報告しますが、またすぐに、報告しなくなり、上司に注意を受ける・・・の繰り返しです。
報告しないといけないという気持ちはあるのですが、「報告」をさぼってしまう。
なぜ、自分は、報告書を書く、報告することが苦痛なのか自問してみました。
状況(現状運用)
「報告」において、自分が起こしているトラブルは、主に以下のとおりです。
- 自分から、報告をしない。
- 上司から、報告内容が、わかりにくいと言われる。
- 報告書の書き直し、報告のしなおしに時間がかかり、他の作業が遅れる。
また、上司からの注意点は以下の通り
・「報告」がルーチンワーク化されていない→定期的な作業報告をしてこない
・今の作業のことしか話をしない
これまでの経緯、今後の予定を考慮していない
担当しているプロジェクト全体の状況を報告しない
・上司(聞き手)が知りたい情報から報告してもらえない
・言葉の定義が曖昧で、報告者と聞き手との間で、認識のずれが発生し、もめることになる
・主観的な言い方でごまかし、客観的な数字での報告がなく、正確な状況が掴めない
・自分自身が、状況をよく整理しないで、いきなり思いついたことを話すので、話が支離滅裂になっている。
原因
上記の各トラブルについて、原因を分析してみました。
まず、自分の普段の作業の流れ（運用）を、チェックしてみました。
1.始業時
(1) メールチェック
返信が必要な用件へ、メール返信する
顧客からの問い合わせなどが入っている場合は、顧客対応優先で、顧客に連絡を取る（不具合発生時なら状況確認、システムの使い方等の質問なら、回答文作成などを行います）
(2) 昨日の作業の続きを行うため、関連書類を机に出して、作成途中のExcelファイル開いて、作業開始
(3) 作業が遅れているので、とにかく、早くやらないといけないと思い、午前中とにかく資料作成・修正を行う
2.昼
(1) 昼食時間→食事
(2) 食事後、メールチェック
メールチェック対応は、始業時と同じ
(3) 午後の作業開始
(4) 基本的に、午前中の作業の続き
(5) 遅れがある場合がほとんどなので、とりあえず作業の続きを始める
3.終業時
(1) メールチェック
メールチェック対応は、始業時と同じ
(2) 定時内で作業が終了しないため、とりあえずもう少しやってから帰ろうと思い、そのまま作業を継続する
(3) 2～3時間残業したあと、退社準備と、メールチェック
メールチェック対応は、始業時と同じ
(4)退社
4.帰宅後
(1) 自宅に持ち帰り可能な資料の場合は、夕食後、作業の続きを始める
(2) 1～2時間ぐらい自宅で作業する。
上記のような作業を数日間行っていると、上司から、以下の注意を受けてしまう
- 報告のルールを守っていないのはなぜか
- 昨日までの状況は、どうなっているか
上記の自分の普段の作業の流れを見て、以下のことに気づきました。
1.自分の作業は「とりあえず」から始めることが多い
2.いきなり、前日使用した資料、ファイルを見て作業に入る
3.メールチェックは頻繁に行っている
4.受信したメール内容によって、その日の作業がすぐに変更になる
(1) 「メールへの対応は、すぐに終わるから」と、誰にも報告・相談しないで、もともと予定していた作業よりもメールへの対応を優先的に行う
(2) 常に作業が遅れている状態である
自分の報告のトラブルの原因を考えてみました。
1.「自分から、報告をしない」件について
(1) 報告できる成果をあげていない
・もう少しやって、成果をあげてから報告しようと思い、そのまま作業を継続するものの、思ったような成果にならず、報告をスルーしてしまう
(2) 作業が遅れているため、報告の時間を割きたくない。
・報告のたびに、「報告」がうまくできず、上司に注意を受けるため、時間がかかる。
・その結果、「報告すると作業が遅れる」という間違った理屈になり、報告を後回しにする。
2.「上司から、報告内容が、わかりにくいと言われる」件
(1) 口頭での報告時、自分の言いたいことを一方的にいってしまい、相手にとって、今何を聞きたいかの気持ちを無視している
(2) うまくいったことは自慢したくなり、うまくいかないことは、無かったことにしたい気持ちがある。
(3) 進捗率、遅れの日数、作業の精度などを、数値化しない（できない）ので、自分の主観で状況を話す。そのため、相手の認識と、自分の現実とがずれている。
(4) 部分的な話となり、話がまだら状態で、他人は、状況をイメージができない
(5) 上司に、状況報告を催促されてから、報告書を書いたり、口頭で報告する。
その結果、その場の思い付きの話を、後先考えずに言ってしまい、後々、つじつまが合わなくなってくる。
(6) 上司にきかれてから、ざっと資料を見ただけで、ほぼ思い付きで、質問に答える」
3.「報告書の書き直し、報告のしなおしに時間がかかり、他の作業が遅れる」件
(1) 報告書のかき直しを繰り返しているので、実務の作業時間がなくなり、プロジェクトの遅れが拡大する。
解決策（案）
次回で、解決策の検討→実証の様子を、書いていこうと思います。
このブログを書こうと思った理由
私は、苦手なことが多い、やらかしポンコツエンジニアです。
毎日、何かしらやらかしてしまい、最後の締めが甘いと言われ、日々落ち込みます。
やらかしが多い分、作業は遅くなり、いつも時間が足りない状態。
注意されたことを、守ろうとするものの、他の注意事項が抜けてしまったり、自分のやりたい方法を押し通して、さらに悪化させることもたびたび。
で、余計に時間がなくなり、さらに、自分をいらいらさせたり、焦って手を抜いたりと、どんどん負のスパイラルにはまり込んでいっている。
そして負のスパイラルにはまったまま、何回やり直してもうまくいかず、
「自分のやりたかった仕事ではないから仕方ない」
「こういう仕事は苦手だから、自分には無理！」
「やりたくない仕事を無理やりやらされている」
と、愚痴ったり、開き直っているだけでした。
そんな私が、
「『愚痴って、開き直って、問題放置』は、自分の望む『目的』を達成できない」
という、当たり前のことが、自分の意識から抜けていたことに気づき、もう一度向き合って、自分改善、スキルアップを図ろうと思うようになりました。
（ようやくかよ～と、周りからツッコミが入りそうですが・・・）
今までの自分の失敗は、基本的なホウ・レン・ソウなどのコミュニケーションやスケジュール管理がうまくできない、作業スペースの散らかり、確認不足による無駄作業や、作業抜けの発生、それに伴うプロジェクトの遅れなどなど、ここでは、上げきれないぐらい、多岐にわたっています。
また、ビジネス書なども読んでみたものの、いまひとつ、自分の仕事に生かせていない。
例えば、他人の『XXXXノウハウ』を真似てみるものの、すぐに挫折してしまう・・・。
上記のように、できている人たちのノウハウを、自分の作業に、うまく組み込ませることができないといった問題も抱えています。
（本を勧めてくれた人たちは、本で紹介されているノウハウを参考にして、うまく仕事をこなせているのに・・・。）
「なぜ、他人はできて、自分は、すぐに挫折するのか？」
「なぜ、プロのやり方が、自分には定着しないのか？」
という、何か、根本的な部分から、原因調査する必要がありそうです。
「今さら感」はありますが、せっかく、自分の現状運用を見直すなら、「自分の不具合対応記録」を残そうと思いました。
そこで、今まで起こしてきたトラブル事例を1つずつ分析し、「○○とは何だろう」と、考えたり、試したりしていく様子を整理して、ブログに書いてみようと思ってます。
あとは、ネットニュースなどを見て、気になったことなども、参考情報として書いていこうと思います。
これまでのやらかし具合からみると、失敗の連続、試行錯誤になりそうですが、自分のブログが、同じような悩みを持っている人のちょっとしたヒント（「やっちゃダメ事例」か？）にでもなれるといいかなと思っています。
また、このブログを読んだ方から、Jobコントロール、プロジェクト管理、整理整頓などのコツや、体験談などを教えていただけるとうれしいです。
（記事の下のコメント欄への投稿、ツイッター
https://twitter.com/TidyKM
へのフォロー、どちらでも構いません。）
果たして、私は、いっぱしのエンジニアになれるのか？
頑張れ、自分。
