仕事の情報を管理しよう
自慢ではありませんが、50歳も近くなって最近では依頼・相談を受ける仕事や業務のほとんどにおいて単純なパフォーマンス…作業時間や作業効率は周囲と圧倒的に差が出てくるようになりました。
具体的には、ほかの人が実施すれば１～２人日要する…と言われるものであればおそらく２～３時間程度で使える程度まで仕上げてしまいます。完成度をあげるならプラス１時間もあればできてしまいます。
「複数の仕事を並行に進めていて、
いったいどうやってたくさんの管理しているんですか？」
ときどき、そんなことを聞かれます。
もちろん昔からそんなことができていたわけではありません。すくなくとも昔の私は仕事の山をかかえて早朝から真夜中まで働いていた時期もありました。効率の悪い年代というのもあったと思います。
基本的に最初から要領が良かったり、段取り上手だったわけではありません。
当然、今でも力量の許容量を超えればそうなってしまうこともあります。まぁその時抱えてる仕事量は周囲の５倍以上は軽く超えていることでしょうけど…。
とりわけ意識したことはないのですが、トラブルプロジェクトの解決が多かった背景から膨大な量の情報や業務に追われることに慣れてしまったせいか、いつの間にかそれらを捌く技術が向上していったなかで、今から思えば「たぶんこれかな？」と思えるものは確かにあります。
そう。ある２つの「仕組み」を仕事に取り入れることによって、私のワークスタイルは劇変しました。
そのひとつは「『作業系』の仕事を徹底的に効率化すること」。
そしてもうひとつが「あらゆるタスクを一元管理すること」です。
そもそも、あらゆる仕事が「仕組み化」できるかというと、そうではありません。
「仕組み化」が必要な仕事とそうでない仕事があります。もちろん何度か経験していれば細かいタスクに部品化する術を覚え、考える仕事すらもアルゴリズム化することが可能になり、徐々に仕組化が可能な領域は増えていきますが、そうなるまでにはどうしても経験をデータに変えて統計化する必要性がある以上、時間がかかってしまいます。
最小限の時間と労力で最大の成果を得るためには、どのような仕事にどのような「仕組み」をつくるべきなのか、その点に思いを馳せなくてはなりません。
「作業系」と「思考系」
日々、みなさんが行っている仕事は大別すると２つに分けることができます。
この２つをそれぞれ、「作業系」「思考系」と名づけます。
■「作業系」の仕事
頭を使わないで処理できる仕事。
手や身体を動かすなど行動をともなう実務作業。
毎回同じ成果、同じ質であることを求められるルーチンワークであることが多い。
例）書類作成、帳簿作成、会議の準備・議事進行、机の片づけ、等々。
■「思考系」の仕事
頭を使って考える必要がある仕事。知的作業。
例）承認行為、企画立案、原稿執筆、経営戦略、人事考課、等々。
このような視点で、みなさんの一日の仕事を見直してみましょう。
業種や職種、役割などによって多少業務内容には差はあると思いますが、たいていのビジネスパーソンは仕事をしている時間の７～８割を「作業系」に費やしている、と実感すると思います。
そして、「作業系」の仕事にこそ仕組みづくりが有効です。
「思考系」にも当てはめることは可能ですが、先ほども申し上げました通りそうするには何度か繰り返し実施してある程度データを集める必要がありますし、場合によっては独自性といって２つとして同じものはない…という業務もありますので、まずは「作業系」に集中しましょう。「仕組み」によって時聞と労力の徹底的な効率化をはかるのです。
一方で「思考系」の仕事には、時間と労力を費やすべきです。
なぜなら、その「思考系」の仕事から生まれた新規事業等が将来の成果を左右していくからです。「作業系」の仕事だけでは自分も会社も大きく成長することはありません。そのためにも「作業系」の仕事を「仕組み化」することで捻出できた時間を「思考系」の仕事に充て、「思考系」の精度を上げて実績を積めばさらに多くの機会を得て、経験が増えれば増えただけ「思考系」のアルゴリズムも構築でき、さらなる仕組化が可能となるのです。
これが、本当の意味で求められている『働き方の改革』です。
その効果として、残業の低減などによるワークライフバランスの確立が図られなければなりません。ただ単純に「残業するなー」「働き方改革しろー」というのは簡単ですが
「どうやって？」
を明確に指示できないようでは、形骸化するのも当然ですよね。
ふわっと、漠然と
「とにかくちゃんとしなさい！」
といわれても、「何を？」「"ちゃんと"って？」と混乱してしまうのと同じです。
「面倒くさい」の使い分け
仕事に「仕組み」をつくろうとするとき、じつは「面倒くさい」という感情が大切です。簡単に言ってしまえば、「面倒くさいことは、徹底的に楽にやることを追求する」ことこそが効率化の本質です。
一見ネガティブにも聞こえますが、この考え方は「仕組み化」を考える上でとても重要です。
「面倒くさい」という意味について、もう少し説明しましょう。
「面倒くさい」にも２種類あります。
頭で考える必要のある、つまり「思考系」の面倒くさいことは進んで行う。
頭で考える必要のない、つまり「作業系」の面倒くさいことは徹底的に楽をする。
「思考系」の面倒くさいことに関してはそれがどんなに面倒でも、私たちは積極的に取り組んでいかなければなりません。ひたすら頭を使って考えることこそが、高度に情報化された現代のビジネスシーンを勝ち抜く、唯一の手段だからです。
一方で「作業系」の面倒くさいことは、いかに手間や時間をかけずにすますかを考え、
できるかぎり効率化をはかるべきです。１分で済ますことができる作業があるのに、わざわざ５分かけて実施する意味はありませんよね。それでもあえて５分かけるというのであれば、そうする必要性やそうすることで企業にどのような貢献となるのか、明確に示す必要があります…けど、そんなことできません。
とはいえ、ここに意外な落とし穴があります。
というのは、「思考系」の面倒よりも「作業系」の面倒のほうが頭を使わなくていいことが多いため、人は往々にして前者を避けて後者を選んでしまいがちになるからです。
こうした思想の人が会社の中核を担ってしまい、組織を自分と同じ色に染めようとしていくようになると徐々に衰退がはじまります。
日本の一流企業と呼ばれる歴史の長い大会社も、創業期は成長の一途をたどっていました。歴史的な貢献もあったことでしょう。企業Webサイトなどを見ても沿革だけ見ればすごいものです。
しかし、安定期に入るとどこも衰退がはじまり、事業の切り売りが始まります。
なぜか？
創業期は殆どの仕事が未知の領域であったがために、面倒かどうかに関わらずみんなが知恵を出しあって会社に貢献することが当たり前となっていました。
しかし、安定期に入るとそれまでの成功事例が蓄積され、ある程度は仕組化／フレームワーク化されてしまった事業や仕事ばかりになります。継続することに特化した人を柱に据えた部署などもできていくことでしょう。
すると、時代や市場の変化に鈍感になり、イノベーションが起こりにくくなります。
人間は基本的に"変化を嫌い"、"改善を疎かにする"生き物ですから、成功事例があればあるほどそれに甘えます。失敗やトラブルが発生したときによく聞く言い訳の１つにも
「前はそれで成功した」
「これまでは、この方法で問題なかった」
といったフレーズがあるのもそのためです。
そのたびに私は
Fools say they learn from experience; I prefer to learn from the experience of others.（愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。）
という言葉を贈ります。
日本人は特にその傾向が強いと言われており、だからこそ欧米のプロセス志向『ＰＤＣＡ』が根付きにくいと言われています。
思い当たる節はないでしょうか。
たとえば、そこそこ大きい企業であれば、企業ガバナンスの根幹を支えるマネジメントシステムとして
ＩＳＭＳ（ISO 27001）
ＱＭＳ（ISO 9001）
プライバシーマーク（JIS Q 15001）
などを取得しているところも多いと思いますが、これらの仕組みも全て規格文書の序章においてＰＤＣＡをベースにしていることが謳われています。これらを取得しているということは、本来「社内にＰＤＣＡの風土を根付かせ、徹底します」と宣言しているようなものなのですが、実際にそれを推進している経営者というのはあまり見たことがありません。そしてみなさんは常に安定に頼らず、改善を続け、試行錯誤しているでしょうか。
PMBOKやCMMI(Lv5)、A-SPICEなども同様です。
このように「思考系」の業務のなかで考えることそれ自体を面倒くさがって先送りにしたり、「作業系」の仕事にばかり逃げ込んだりするビジネスパーソンは、案外多いのです。
それもそのはず。そういうことを経営層や管理職層など、上の立場があまり実施しようとせずに収益の数字ばかり見て「もっと○○しろ」ということだけに注力しているものですから、「親の背中を見て子は育つ」「子供は親の写し鏡」と同じように、社員たちも徐々に出世等を行っていく中で
「それでいいんだ」
となってしまうのは必定です。
なぜ一元管理が必要なのか？
一元管理とは、ひとことで言えば
「同じものをふたつ持たない」
ということです。
たとえば、会議資料を見て検討しようというときにその資料が、
会社のPCに入っているのか、自分のノートPCにも入っているのかわからなくなっていたり、あるいはそのどちらにも入っているけれどどちらかが更新前の古いバージョンだったり…それでは困ってしまいますよね。
このように一元管理がされていないと、それらを探したり確かめたりする時間も手間もすべて無駄になります。作業系業務における冗長工数に直結します。
時間や手聞はすなわちコストであり、お金（時給で考えればわかりやすい）です。
仕事を一元管理することによって、そういったロスをなくしていくわけです。
一元管理することが、なぜ「仕組み」につながるのか。
まだピンとこない方もおられるかもしれません。
そんな方は、「仕組み」の定義に戻って考えてみましょう。
そう、「仕組み」とは再現性の塊です。
誰がやっても
いつやっても
何度やっても
同じ成果が出せるシステムのことです。
たとえば、あなたが事故で入院することになったときに、あなたの仕事を、他の誰かが、あなたと同じようにできるようになっている。
これが「仕組み」ができているということです。
そんなとき、会議資料がどこにあるのか自分でもわからないようでは、話になりません。
「考えるべきこと」以外に頭を使わず、
また個人の記憶力にも頼ることなく、
日々の仕事の山を効率的に処理していくために、
あらゆるタスクを一元管理する
ことは、きわめて役立つ「仕組み」となります。
ちなみに、管理職や管理者に求められる情報の管理も要するにこのことを指しています。一元管理に必要なコツをいくつかピックアップしてみると、次のようなものがあります。
ＰＣは１台をとことん使う
データを一元管理していくうえで、とくにポイントとなる事柄。
何より基本は、情報をとにかく１ヶ所に集約することです。
たとえば、サーバーとノートＰＣを併用し使い分けている方がいらっしゃるかもしれませんが、これは情報の一元管理の観点からすると好ましくありません。
どのデータがどこに入っているのか、わからなくなってしまうからです。
いちいちすべてのＰＣを開いて検索しないと探している情報の所在がわからないのでは時間の無駄づかいです。ただのエクスプローラーでファイル共有するのは、一元管理とは言いません。環境としてはそれも可能ですが仕組みとなっていませんし、人の判断や行動によって安定しない結果となりかねません。
私の場合、データのマスターは常に１台に限定して、その他のビジネスシーンでは複写したものを使います。複写はマスターになることはなく、CRUDで言えば
「R(eference/ead)」
にのみ用います。マスターは一元化されていて「C(reate)」「U(pdate)」「D(elete)」はそちらで行います。
エンジニアの方であればもうお分かりのはずです。
すなわち、SVNやGitなどのバージョン管理システム等でリポジトリに一元管理することを指しているのです。こういったツールの利用はソフトウェア開発プロジェクトのみ、ソースコードのみと勝手に決めつけている人もいると思いますが、そうではありません。
私は、開発を離れた今でもごく当然のように用いています。ローカルPC上にマスターを置くことはありません。それはプライベートPCでも同様です。
なんでも放りこむ
情報を集約する場所が決まったら、次はそこに「とにかくなんでも放りこむ」のが重要です。なぜかといえば、すべて放りこんでしまうことで、
「自分の頭で記憶しないですむ」からです。
「記憶より記録」
は属人性を排除し、仕組みを成立させるための第一歩です。
自分の能力や脳を「記憶」に使うのはもったいないですし、不完全な生き物である人間の「記憶」だけに何百万、何千万、何億と言うプロジェクトの命運を委ねるのは現実的ではありません。
必要なことはすべてPCに「記録」しておけばそういったリスクが排除でき、且つ頭はそれ以外のところに使えて一石二鳥なのです。
また、なんでも放り込むといっても体系化もされず、雑然と放り込まれたのでは、結局「どこになにがあるか」を記憶する手間が増えるだけで意味がありません。
当然、ここでもフォルダ構成などを体系化し、整理し、わざわざ記憶しなくても容易に導き出せるよう、その構成に配慮する必要があります。
フォルダを細かく分けすぎない
ＰＣに入っているデータを細かくフォルダに分けて、サブフォルダなどの階層も何段階もつくっていくタイプの人がいます。
もちろん、最低限の管理が出来なければなりませんし、仮に他の人と仕組みを共有すると言うのであればなおさらわかりやすくなっていた方が良いのですが、
それでも、あまり細かすぎると逆に問題を誘発してしまいます。ネスト（入れ子構造）を深くしてしまうことは、そのまま「複雑度」を向上させてしまうからです。
理由は大きく２つあります。
まず、フォルダが多すぎるといかに秩序立っていても次に探すときに「どこに何が入っていたっけ？」となって、意外と手聞がかかることがあります。フォルダ名やその配置などがわかりやすくなっていなければ、確実にそういった事故が起きます。
もうひとつは、新しいタスクを入力するときにどのフォルダに入れるかに頭を使い、迷うことになるからです。現在のＰＣ、たとえばWindowsやgoogleデスクトップなどは検索機能が優れていますので、フォルダに関係なく全文検索で拾ってくれます。
たくさんフォルダをつくって細かく分類するよりも、ある程度おおざっぱな分類でフォルダをつくっておいて、そこにダーーッとデータを放り込んでおく…それで十分なケースもあるということです。
とはいえ、一般的な住所と同じく、
市区町村・丁目・番地・号
くらいの階層化はあった方がいいでしょう。
世の中の住所がそう構造化されているように、３…どんなに多くても４層くらいまで整理しておくと分類化しやすくなりますし、逆に人間の管理もそのあたりまでが限界と言うことです。
ファイル名にルールをつくる
これもエンジニアの方であれば、よく理解できると思います。
これは言ってみれば、
コーディング規約／命名規則
のようなものです。フォルダでの分類はおおざっぱである代わりに、ファイル名やフォルダ名にはルールをつくって管理するのがポイントです。
たとえば、作成している議事録ファイルをつくるとしましょう。
そのときファイル名は、
「20220714 議事録 XXXX会議(〇〇について：△△)」
として「会議体」フォルダに保存します。
こうするとまず「会議体」フォルダの中で、時系列順にひと目で一覧できます。
また、ＰＣ内で検索すれば「議事録」「xxxx会議」「〇〇(テーマ名)」でも該当しますし、相手先の「△△(顧客名)」でも見つけることができます。
このように、検索するであろう単語を入れたファイル名をつけて一度保存したらあとはファイル名も、ファイルを入れた場所も、全部忘れてしまって大丈夫。「記憶力に頼る」という非常にリスクの高い仕事の進め方から解放されることになるのです。
もちろん、みなさんが同じ様式でファイル名をつける必要はありません。各自が見やすく、検索しやすいようなルールをつくって、それに沿ってファイル名をつけてください。
「その他」フォルタをつくる
先述では「フォルダを細かく分けすぎない」ようにと書きました。
そうすると、どのフォルダにも入らないもの、どのフォルダに入れればいいのかわからないものが出てきます。この場合は新しいフォルダをつくるよりも、「その他」フォルダに入れておくといいでしょう。
「当面必要ではないけれど、捨てられない」
といったファイルも、みんなここに入れます。
ＰＣ上のデータの整理については人それぞれのやり方があることは重々承知しています。しかし、このテーマで大事なポイントは、
「記憶しないですむこと」
「毎日繰り返される"探す時問"をできるかぎり減らすこと」
であり、そうすることで冗長的な工数を増やすリスクを避けることにあります。
そこに、好き嫌いと言った価値意識はありません。
本質的目的が果たせるかどうか、以外の判断要素はすべて無価値だからです。
よく会議や相談などで、私はほとんど思考することなく即答する機会があります。周囲からはそれで「なんでそんなにスラスラ出てくるの？」と驚かれることが多いのですがこれもこのコツの応用です。
全てをまるっと記憶しているのではなく、全ての情報を整理して引き出しやすいように管理しているからこそ、ＰＣ内であっても脳内であっても探すことなく引き出せるだけなのです。
これは頭がいいとか悪いとか、センスがいいとか悪いとかと言った要素は関係ありません。先にも言ったように、私も昔から要領が良かったわけではありません。
コツと習慣化だけで誰でもできることなのです。
成果をあげることは一つの習慣である。習慣的な能力の集積である。習慣的な能力は修得に努めることが必要である
成果をあげるには、性格、強み、弱み、価値観、信条はいかようであってもよい。なされるべきことをなすだけでよい。成果をあげることは、習慣である。したがって、他の習慣と同じように身につけることのできるものである。そして身につけなければならないものである
後から知ったことですが、ドラッカーも「習慣」の重要性をよく説いていますよね。
この「経営者の条件」は経営者だけが読んで得する内容というわけではありません。私たちのように従業者の立場からでも参考になることはたくさん載っています。特に「八つの習慣」についてはプロジェクトマネージャーや管理職などでも参考にするべきではないでしょうか。
しかし、先述のように、人は「思考系」に対する面倒くさい努力を好まない傾向があります。だからこそ「やる人／やらない人」が明確に分かれ、結果として「できる人／できない人」ができるだけのことなのです。
自身や周囲を見渡してみてください。
「できない人＝やってこなかった人」であり、「できる人＝普段からやっている人」のはずです。
バックアップを「仕組み化」する
１つ目のコツで「１台に集約するべき」だと説明しました。
しかし、１台に集約するとそこでPCが壊れてしまったり、データに問題があったりしたときにどうにもならなくなってしまいます。
そこで重要なのが、バックアップを「仕組み化」することです。
「バックアップは、気がついたときにやってるよ」
そうおっしゃる方もいるでしょう。
しかし、それでは不十分です。
気がつかなかったらいつまでもバックアップしないからです。
それよりも、たとえば週１回、毎週木曜日の朝一番にバックアップをとることに決めるなど、日々のルーチンワーク…すなわち「作業系」の中にバックアップをとることを組み入れてしまうのです。なんなら自動化してもいいでしょう。仕組化できるということは、システムやツールなどで自動化できるということでもあります。
将来的に自動化や自動化を駆使して楽をすることを見据えるのであれば、その前段階として「仕組み」としてしまうことは絶対に必須条件になります。そういった意味でも、いたるところで仕組化は日ごろから考えておいたほうがいいのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。