仕事のミスをなくし、生産性を向上させるための4つの工夫（社内報）
マーケティング／Offersの体制／エンジニア採用などに関してのnoteを書いてきたが、経営する中でいろんな課題も増えてきた（4期目）社内で言っていることを言語化しておきたいので第1弾。
---------
私は全社のマーケティング、CS、プロダクトと幅広く戦略から実行レイヤーまで見ている。事業／サービスの成長とともに段階的に権限移譲を進めている。
権限移譲をする中で新しくマネージャーになった人がいるが、
プレイヤーからの脱皮が難しい（自分がやっていたことを引き継いだら、他の人だと同じようなアウトプットが出てこない）、自分の想定通りに人が動いてくれない悩みがある人も出てきている。
社内の新卒〜数年目に主にフィードバックしている内容ではあるが、
メンバーやプレイヤーの実務をどのように改善するか／フィードバックをしているかについて書いていく。
---------
▼ この記事を読んでいただきたい方
・仕事で同じミスを繰り返してしまう
・何度同じミスを繰り返したらわかるのか？、と言われたことがある／言ったことがある方
・ミスを繰り返さないための対処の方法がわからない方
・仕組み化がどのように行われるのか、またその意味がわからない方
経営／マネージャーをする中で「これはスループットをあげる上で役に立った、大切だった」ことを4つほど紹介する。
チャレンジなしに前進はないし、チャレンジにミスはつきもの。
ミス自体が悪いことではなく、実行から得たものを改善しないことが悪。
まずは同じミスを繰り返す人の特徴から整理し、自分が当てはまってないか気をつけていきたい。
※スループットとは
「スループット」という言葉を、どなたも一度は聞いたことがあると思います。主にアプリケーションなどの性能（パフォーマンス）の文脈で使われます
https://codezine.jp/article/detail/9614
1 同じミスを繰り返してしまう人の特徴
1-1. 人の話を聞いていない
・議事録やメモを後から振り返りやすい状態でとっていない
・人の話を聞いて、理解したふりをしている
・完全に理解できていないときに質問し返さない
→ 不安な時はそれってこういうことで良いですか？など相手に聞き返すことができる人が話を聞いている。
1-2. 自分が何故指摘されているのか理解していない
・自分で問題が何か理解できていない
1-3. 他責思考がついてしまっている
・〇〇さんが〇〇だと言ったから
・〇〇が〇〇だから
・あなたの役割、責任のあるボールを誰かが改善してくれるのを待っている
・あなたの役割、責任のあるボールを誰かがやってくれるだろうと考えてしまっている
→ 誰の、どんなボールなのか、責任の所在を曖昧にしてしまっている
1-4. 一定の自信は必要だが、無駄な自信を持っている
・自分の悪い癖に向き合わず、解決しようとしない
・苦手なことがあるなら適切に人に依頼するなど手段があるが、自分で物事を解決しない
・実行したことに自信を持ってしまっている人は、大事なのは結果であることを理解した方が良い
→ 特にミドル〜シニアになるほど「時間当たりでの実行品質＝事業成果／組織貢献」が求められる
具体的な施策に関してよりも、メンバーが持っているマインドがアウトプットの品質に影響を与えていることもある。
上記のような特徴に合致する傾向が見えた時は適切にフィードバックする。そうしなければ、仕事を任せるマネージャーも会社の方向性と自分のキャリアを照らし合わせて頑張るメンバーも会社も幸せにならない。
採用サービスや自社の採用をやってて思うが、上記に当てはまる人は転職回数／職種変更が多かったり、入社時の期待値＝信頼残高が一定ある段階から結果が安定しないのでどんどん信頼がなくなっていく。
信頼がなくなっていくと仕事のサイズが小さくなっていき、面白い／責任のある／責任の範囲が広い仕事がなくなっていく。
しっかり自分と向き合って結果が安定するまでやりきることが大事だと思う。
ここからは具体的なミスをなくすためのプロセスを整理してみる。
2 付箋／Google spread sheetなどでタスクを見える化する（初期実行時-PD部分）
2-1. タスクを自分で見える化する
ダメな例
・見える化されているけど、タスクに対しての工数が見積れていない
・自分の過去タスクの処理時間などを参照
・タスクの内容と工数、今日何をするべきかが明確になっていない
オンラインのタスク見える化で難しい場合は、付箋などのオフラインのものもおすすめ。大事なのは自分のタスクを意識できること。
2-2. タスクの実行とその結果をまとめる時間をとる
・1日1日細かい変化だとしても毎日の仕事に取り掛かるまでの準備が大事
・準備しないでいきなり実行して期待する結果は得られない。何に対しての実行か、目標がぼやけないようにする
・一定なにか得られたとしても、たまたま得られた結果で再現性がないかもしれないとネガティブチェックする
・自分に自信を持つことは大切だが、過度に自信を持たないこと
・再現性の高いアウトプット＝成果を継続できることで自信を持つこと
・前日やタスクで指摘された事項があれば、なぜ指摘されたのか背景までセットで理解する
→ 事業の目標に対して安定した結果を出し続けられることによって評価できるので短期的な成果を積み重ねることが大事。
このようなことができないことでミスを繰り返してしまう最初の原因になる。
3 起きた時の課題、次どうすればいいかを整理している（チェック-C部分）
3-1. タスクを可視化し、工数を見積もった上で実行、その後見積もり（計画）と行動のギャップ＝課題化
→見積もりや仮説とのギャップを課題と思わない人が多い。課題と思わない、振り返りをしないから同じミスを起こしてしまうor実行品質が向上しない。
3-2. 課題の可視化を行う
→ 例：タスクの期限設定と予定日の遅延のギャップ、見積もり工数と実際にかかった時間のギャップなどを数値化し、閾値を設けてアラートを設定する。ソフトウェアによる自動化ができるのであれば自動化する
3-3. 課題に対してのネクストアクションをどうするかアイデアを出す
・ネクストアクションを出した後の優先順位はどのようにするかを考える
・優先順位の決め方をなぜやるのか、事業／サービスのKGI／KPI数値や目標、工数、インパクト、短期・中長期に効くことなのかを考慮して設定する
4 Google App Scriptなどの仕組みで解決する（アクション-A部分）
4-1. 課題は仕組みで解決しないと人間は究極エラーを起こす
◼︎ 問題の起きる流れの例
・仕事が増えていく
・その場合に何も対処しない／何も行動を変えなければ、自分がやらないといけない仕事が増えていく。
・仕事が増えていくと自分の集中力／アウトプットできる総量／時間は限られているので、失敗・アウトプットの品質が下がっていく
・そしてミスをしやすい状態になっていく
4-2. ヒューマンエラーを起こすの前提。仕組みで解決する
→ マニュアル／ドキュメントなどを作っても「マニュアルを見ない、マニュアルを見たけど漏れていました」ということは少なくない。
・常に100%エラーを出さない人などいないので、これを考慮した仕組みづくりを行う
・ヒューマンエラーがおこらないためのことをまた人を採用することでカバーするとどんどん複雑性がましていき、よりコントロールしづらくなっていく＝少数で目標とする結果を出せるような運用を考えるのが理想
4-3. Google Apps ScriptやほかSaaSを利用
大切なのは課題の解像度をあげることと、課題を把握すること。課題＝見積もりと実行のギャップだと定義すると課題は見つけやすい。
◼︎ 自動化の一例
背景／課題：タスク実行時のサポート、所定の位置への入力項目の追記漏れ
やりたいこと：作業進捗や作業の完了判断し、課題の自動判断／アラートを設定
進め方：作業進捗や作業の完了判断するロジックを作る
フォロー・リマインドなどの自動化→人がリマインドやフォローしている部分を自動化することでタスクのボール落ちを防ぐことができる。
◼︎ 自動化を行う意味
繰り返し行われるようなタスクに関しては、どんなに小さなことであっても効率化・自動化する。やらなければ時間は増えていかない。確認／判断作業に時間を取られているのであれば、そうしないための工夫が必要。
課題の可視化（発見）自体を自動化し、実行した後に人がタスク処理することから自動化させていく仕組み化なしに人が本来やるべきことに集中する時間／できる幅は広がっていかないし、大きなことは実現できない。できることの広さと深さを意識して仕事に取り組もう
4-4. 仕組み化が自分で作れなければアウトソースし、すぐ解決する
◼︎ 実行前に考慮すること
・解決したい課題
→ なにがどう繰り返されているか、問題は何かを具体的にする
・課題の解決策のアイデア
・実現したいことを書き出し、要件をまとめる
・課題が大きければ自動化することを実行に移す
◼︎ 実行段階
・リソース
・クラウドソーシングサービスでエンジニアを探す
・社内のエンジニアに相談
→ 社内リソースを使う場合、どれくらいの課題なのかを明記。社内のエンジニアの方が給与が高く、仕事に対してのコストの方が高いのであればアウトソースする
・予算
・相見積もりなど取ってみて予算から判断する
・課題の規模／解決されることで増える時間などに応じてだが、予算が数十万円と高価でなければ意思決定をする
→数万円程度であれば許容範囲と割り切る。もしくは事前に上司に交渉／確認しておく
自分でGAS／そのほかAPIが絡み、実装できないこともある。自分で実装できて解決できればそれがベストだが、無理であればできる人にアウトソースして仕組みを作りきる。
仕組みを作りきるところまでやり切らないと、「なんとなく設計はできたけど、仕組み化ができないからいいや」で終わってしまいがち。
そうすると「確認／アラート／リマインドが関連するタスクによる問題」が積み重なっていってしまう。
余談：仕組み化ができずに目標が上がっていくと起きること
・問題があらゆる点で発生する
・仕組みを作る前に人がカバーしていたところから漏れていく
・一度問題が発生した時にフォローに時間がかかり、これまで出ていた成果も下がっていく
・解決のためにフォローをする人の時間も奪っていく
5 言い訳を無くし、他責思考をやめる（マインド面）
2-4ができていればこれはなくなってくるが、
実行はできるのに重要な部分だけ他責（結果に無頓着）な人がいる。
そういう人は信頼をできなくなっていくし、大きな責任を任せることができない。
自分の仕事やキャリアを作っているのは自分。会社や上司（環境）ももちろん大切だが、良い環境にいたとしても自分と向き合ったり、未来を見据えて自分の行動／アクションを改善していなければ前進しない。誰かがあなたの人生を生きているわけではないのだから。
他の人の動きをみて嫉妬したり、羨んでいるのであれば自分の本当の弱い部分と向き合っていかないといけない。また、目標や視点が低いとそのような行動をとってしまう場合がある。
そのような時は自分のキャリアや未来はどうありたいのか、そこから逆算して今の自分はどういう言動をしているか振り返ってみる。
私は「完璧な人間などいない、完璧な人間ではない」と理解している。
なので、問題を起こさない／起きにくい設計が大事だと考えている。もちろん、チャレンジしない／させないという意味ではない。
むしろ誰よりも新しい挑戦が大好きだし、応援したい。
どのようなポジション／職種であっても内省する時間を作り、より良い影響を与えられる人／自分で改善し続けられる人であるように努力することが大切ではないだろうか。
最後に
全部書いてみて当たり前では？と思われる部分もあったかもしれないが、凡事徹底することは何よりも難しい。
スループットを高めて仕事をしやすい環境／チーム作り＝「成果を出しやすい、成果が安定する強いチーム」だと考えているので徹底していきたい。組織もプロダクトである。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？