SEの方に「事務仕事の効率を上げる方法」について質問です。

質問

はじめまして。
今度、営業事務の仕事につくことになったんですが、あくまでも私、一個人の仕事の段取り・効率を上げる方法について質問があります。
私の仕事はとりあえず与えられた仕事をこなすだけなんですが、どう効率を上げたら一番いいか？考えてます。
ザックバランですが、私の仕事の段取りは以下の様な感じです。

1.まず、上司の頭の引き出しをあけ、
2.言われるがままダー！っとメモし、
3.スタートとゴールを決めて段取りを組み始め、
4.真ん中の内容を「８±１」で分割し、
5.時間短縮できるところを探していく。
（慣れると勝手に内容は３分割くらいになってます）

以上の様な感じを自分のＰＣのエクセルシートにまとめて保存してます。何か非効率な点・組み方におかしい点などありましたら、ご指導よろしくお願い致します。
その他、ジャンルや仕事方法が違くても構いませんが、仕事の効率を上げる良い方法などあれば教えて下さい。

個人的には、意外とメモをとるところが穴で、自分の字が汚くなって読めなかったりとか、全部を書きすぎてポイントが絞れてなかったりして遅れてます。これが実はネックかなとも思ってます。これも仕事の段取り、効率を上げる重要なところがわかってないからかな？？とも思います。

穴はたくさんあるかもしれませんが、よろしくお願いします！

回答No.1

xcrOSgS2wY · ベストアンサー

いやー、こういう質問いいですね。「何がなんだか全然分かりません。誰か答えを全部教えてください」的な質問ばかり続く中で一服の清涼剤です。

「これが正解」と言えるような回答はおそらく出てこないと思うので、安心して(?)自己流を披露したいと思います。

私流の段取りは

1. まず要求されていることを順序関係なく雑多に聞き取り。しょうもない細かい点も可能な限りメモ。
2. 要求者が「1つの要求」と思っている内容でも、たいてい実際には複数の独立した流れがあるので、それを分離。
3. 要求者に「こういう要求ですね？違っていたら指摘して」と確認。たいていはメールで送信。
4. それぞれの流れごとに、「もう少し詳細を聞いておかないとこの場所で作業が滞る」という場所を探す。ただし、探すことに多くの時間は割かない。見つからない場合は6.へ。
5. 詳細なしでは作業が滞ると思われる部分について、質問を投げておく。可能であれば、予期される回答の選択肢（「Aでしょうか、Bでしょうか、それ以外でしょうか」等）と回答が遅れた場合の影響（「この情報は〇〇に必要なので、回答があるまで〇〇ができません」等）もあわせて提示。たいてい質問はメールなので、送信記録に質問フラグを立てておく。
6. 2.で分離した流れのうち、特定の1つについて取り組み開始。どれを選ぶかは、各流れの依存関係や締め切りを眺めて適当に決める。
7. 滞りそうな場所が新たに見つかったら、その都度質問を投げておく。
8. いよいよ滞ったら、6.で選んだのとは違う別の流れについて取り組みを開始して7.へ。
9. どれも全部滞ったら、質問フラグを眺めて「回答待ちですよ、回答がないせいで作業が滞ってますよ」と回答を催促。
10. どの流れも全部処理が終わるまで7.から繰り返す。

という感じです。気分はほとんど、プログラム（＝要求）を自動的にマルチスレッド化してコンパイルし、それを実行するCPUです。

私にとっての段取りのキモは、まず、とにかく面倒でも「確認」を書面（メールでもよい、とにかく文字の形）で行うことです。すごく面倒なんですけど(笑)。でも、やっといて本当によかったと思うことが1ヶ月に1回くらいあります。（私は1人自営業なので、勤め人よりもそう思う機会がずっと多いのかもしれませんが。）

それから、質問者さんと同じく「メモ」をとにかく取ること。どんなつまらない（と聞いた時点では思うような）ことでもメモ。そして、できれば適宜、日時もメモ。後から読み返すときに、時刻があるおかげでよく思い出せることが案外あるものです。

この辺は、多分MicrosoftのOneNoteを使えば楽になるんでしょうけど、どうしても普段使い慣れた道具を使ってしまうので、なかなか移行する気になれません・・・

ところで、メモは、メモを取る時点でポイントを絞る必要は全くないと思います。必要のないことは後でいくらでも消せばいいんですから。逆に後になって「そういえばあの時、こんなこと言ってたような、言ってなかったような・・・」という事態になるよりはずっといいですよ。（メモ書きのときに「こんなこと書くまでもないだろう」と端折って、後で悩んだことがどれだけあるか・・・(笑)）

お礼

1～10のうち、私の個人的な穴は「2.4.6.8.」の別流があるといったところでした。口から出てくる言葉はひとつにですが、同時に色んな意味のことを言ってるんでまとまんなかったのですが、別流をつくるといいんですね。ご指摘、ありがとうございます。これで守るところを守り、固めて実行して行くといった感じでしょうか？プログラミングって守り重視なんですか？とふと疑問が沸いてきました。お時間があれば是非、ご回答よろしくお願いします。

回答No.5

Broner

こういう仕事をする場合は、理系の考え方が必要です。
物事をいろんな角度から照査して、プログラム処理するのです。
その手順は、
1. 現状把握
　　先入観無しで現状を把握する。たとえば、大会社との取引でも、最近は、倒産している可能性もあります。しっかり、照査することです。
物もいろんな見方があります。
2. 計　　画
　　現状把握に基づいて、計画します。
　　詳細は長くなりますので省略。
3. 実　行
　　計画に基づいて、実行します。
　　詳細は長くなりますので省略。
14. 検　　証
　　実行した結果を検証して、目的の効果が得られたか、確認します。
　　そうでなかったら、1 に戻ります。

このように、考え方の基本を学ぶのが「デカルトの方法序説」です。

回答No.4

nofutureforyou

いわれた事だけをやるのではなくて、全体の仕事の中で自分の役割が何かを把握して、やるべき事をやるというやりかたもあります。

回答No.3

xcrOSgS2wY

私の段取りがかなり守り重視（に見える）のには、いくつかの理由があります。文字にしてみるとどれも「当たり前」な感じで恐縮ですが、挙げさせていただきます。

(1) 何と言っても、まずは保身の意味が大きいです(笑)

自分の責任範疇にないはずのことを要求された場合、その要求がどういう経緯で発生しており、本来どこ（誰）が責任を負うべきなのかを客観的に反論する材料になるので。

こういうことはたいてい佳境に差し掛かってから、あるいは修羅場の最中に発生するので、反論の際は極力感情を排することが重要になります。そんなとき、客観的な判断材料というのはありがたいものです。

(2) 口頭による指示伝達は信頼性に（大いに）問題があるため

口頭による伝達の前にしっかりレジュメでも用意してあれば別ですが、たいていはその場で思いついたことを口に出しながら指示をしているはずです。（そもそも、そんなしっかりしたレジュメがあるのならば、それを渡せば口頭伝達のほとんどは省略できるわけですし。）

ところが、考えながら話す内容というのは、後になって分析してみると前後不揃いだったり、意味を取り違えていたり、思い違いをしていたり、あるいは言葉足らずで不明瞭だったりと、その伝達内容の信頼性は低いものになりがちです。

その上、聞き間違いというのは非常に起こりやすいものであるため、聞き取りの段階でもう一段、信頼性が下がることになります。

これらの問題を担保するには、どこかに「エラー訂正」の手順を入れておくしかありません。そのエラー訂正時に再度エラーが混入しては話にならない（伝達がいつまでたっても終わらない）ので、どうしても、これは文書で行うということになります。

(3) 文字の形を取ることで、一貫性を確保しやすくなる

文字にすると「一覧性」と「一貫性」を他の方法より容易に確保できます。プログラミングの場合は特に「一貫性」が必要になるので、この性質はとても重要です。

（他の分野では一貫性があまり必要ない、という意味合いではありません。プログラミングは一貫性の権化であるコンピュータを相手にするので人間側が頑張る必要があるわけです。人間対人間の場合、相手がある程度融通を利かせてくれるので、コンピュータを相手にするほど頑張る必要がない場合が多いかと思います。）

(4) 時間が節約できる

文書を作る時間が必要なのに、どうして時間の節約になるのか？と思われるかもしれません。でも、こう考えてみてください。もしメールやFAXの使用が禁止されて今後全部電話を使わなければならないことになったとしたら・・・送り出し側も受け取り側も、長時間、不必要に拘束されることになってしまいます。

メールやFAXの利点はいまさら繰り返す必要はないでしょう。

ああそれなのに、伝達を必ず口頭で行う（口頭でしか行わない）顧客のなんと多いことよ（愚痴）。まぁお客さんですから文句を言いはしませんけど。

お礼

ありがとうございます。サッカーじゃないですけど、仕事では攻めてると勝ってると勘違いしますよね。攻めは相手が完璧に崩れてる状態のことを言う訳ですからね。僕も守り重視なので、いかにして10のものを１に分類するかばっかり考えてますね。逆をやられた時、取り返しのつかないミスを自分サイドがしないよう「守るところは守る」の方針は変えたくはありません。他にも、何か気づかれた点などあればよろしくお願いします。

回答No.2

Broner

いやー、こういう質問いいですね。「何がなんだか全然分かりません。」内容が難しいのです。
回答も何が間違いで、何が正解か、判別しょうがありません。気が楽です。

では、回答します。
　作業手順を大きく分けて、入力、処理、出力と分けます。これが三分割です。つぎに、詳細にいります。
1. まず、上司の頭の引き出しをあけ
　この部分の作業手順をきちんとすることが、一番効率的です。
　しかし、相手が上司であるだけに、虎の尻尾を踏む思いがします。
　これに引き下がるようでは、未来はありません。
　　納得されたら次に進みましょう。
　この部分の作業手順としては、仕事の入力、出力の大体を（初めから全てを出せるわけが無いので、気楽におおまかに、できるだけ詳細に、あっ、わたし、何か矛盾したことを言ってます。しかし、気持ちはこの通りなんです。）表にしてもらう。これを作業手順として確立します。

　2. 真ん中の内容即ち、処理
　　これは、まず、上司の頭の引き出しをあけ、この仕事の非常に大雑把なフローを書いてもらいます。真ん中の内容を「８±１」で分割し、そうです、このくらいの項目数でフローを書いてもらいます。これも作業手順として確立します。

3. プログラム作成
　1,2の内容により、プログラムを作成します。
　作業の中で、真ん中の内容即ち、処理フローを詳細にしていき、プログラムを作成していきます。勿論、プログラムは、入力、処理、出力の　3つに分けて、構造化します。
　ここで、非常に大雑把なフローを、詳細にする作業をおこないます。
「８±１」の項目を詳細にするのです。

4. 最後に、こういう処理には、考えを纏めることが必要です。デカルトの方法序説を読まれることを、お勧めします。

如何ですか、的外れでしょうか。

お礼

多分、的の内側です。私、おバカなので料理に例えますと「入力→材料」、「処理→クッキング（８±１）」、「出力→できあがり」で考えるって感じでしょうか？考えを纏めるには「デカルトの方法序説」が「処理」に必要になってくるとおっしゃてると思うのですが、どんな感じで役立つのでしょうか？さわりだけでもお時間のある時に回答、頂ければ有難いです。よろしくお願いします。