読者です 読者をやめる 読者になる 読者になる

プロジェクトマネジメントの話とか

「プロジェクトマネジメント」をはじめ、ライフハック・IT業界の話を中心に、ビジネス全般について書いています


仕事が丁寧で遅い人に共通する、たった1つの問題点とその対策。

ライフハック-仕事術 ライフハック オススメ

 
 完璧主義で丁寧すぎるから、作業に時間がかかるって?

 その分析、半分は正解です。今回は仕事が遅くなる原因の、残り半分について話をしようと思います。

「巧遅(こうち)は拙速(せっそく)に如(し)かず」
――孫子

 「丁寧だけど遅い」仕事よりも、「荒削りでも速い」ほうが良いネ!という、この孫子の格言。

 ビジネスパーソンであれば誰もが、その重要性を痛感しているかと思います(せわしない世の中ですよねぇ……)。携わっている仕事のタイプにもよりますが、着手のタイミングが早いこと、そして遂行のスピード自体も速ければ速いほど、多くの「失敗→起動修正」を積み重ねることができるため、その分、より良いものを作れる可能性が高まるのです。

 しかし現実問題、細かくて仕事がバカ丁寧な人に「6割でいいよ!」「80%でGO!」などと言ったところで、そんなことができるワケないのです。そして多くの完璧主義者は「3歩進んで2歩下がる」を、無意識のうちに繰り返してしまうわけです。

 人間の性格は簡単には変えられません。これは人としての宿命(S-A-D-A-M-E)です。でも行動は変えられるのです。

過去記事
完璧主義の克服と、ガサツな人の思考回路。 - プロジェクトマネジメントの話とか
では、少し説明が抽象的になっていたため、今回は実践的・具体的かつ、上っ面のテクニックに依存しない、汎用的な改善策・解決策を考えてみたいと思います。

※もちろん、過去記事と併せて読んでいただくことで、より深い理解が可能になるかと思います!

 

スポンサーリンク

 

 

完璧主義者に何が起きているか、資料作成を例に考えよう

 普段、皆さんが行っている資料作成の例で考えてみましょう。完璧主義の人は資料を作る過程で、「さっき修正したこの図がやっぱり気になるから、もう少し綺麗にしよう」だとか、「この表現がやっぱり不自然なのでもう一度推敲し直そう」などという形で、先ほど述べた通り「3歩進んで2歩下がって」しまったり、もっと酷い場合は「行ったり来たりの堂々巡り」のようなことをしています。次の「図1」を参照ください。

完璧主義が陥る堂々巡り

図1:完璧主義者が陥りがちな状態

 つまり、細かいレベルで「何度も同じことを繰り返している」わけですね。では、具体的にどうすれば良いのでしょうか?Tipsでなく根本的な解決策に迫っていきましょう。

スピードアップするための具体的な対処法は?

 下記「図2」が理想の形となります。堂々巡りをやめるには、一度、最後まで走り抜ける必要があるのです。

id:wiz7:細かいことは考えずに走り切る

図2:まがりなりにも、最後まで走り抜ける理想形

 とはいえ、これができないから苦労しているわけですよね……。では何故できないかを考えてみましょう。

 そう。お察しの通り、一言で言えば「不安感」が原因です。

 これで大丈夫かな、アレが気になるな、もう少しこうしたほうが良いような……。等といった、より良いものを作ろうとする意識が裏目に出た形がこの状態なのです。つまり、この「不安感」を払拭できるだけの「安心感」を与えられる仕組みづくりをしてやればよいのです。

 次に、この安心感を保証する、2つのセーフティーネットを作ってみましょう。以下の「図3」における、「設計工程」と「チェック工程」がそれに相当します。

id:wiz7:チェック工程でじっくりと見直す時間を確保

図3:3つのブロックからなる作業の完成形

設計工程

 まず第一に、作業に着手する前に、全体の構成・設計を考える工程が必要となります。具体的に何をするかを事前にデザインしておけば、いざ走る段階で迷うことなく走り抜けることができるようになります。

 走りながら色々と考えるからカオスになってしまうのです。まずは事前の戦略会議が必要なのです。

 また、ここで重要なのは手を動かすことで紙に書き出し、思考を可視化することです。思考は次々とシャボン玉のように消えていくので、見える化することで堂々巡りを防ぐことができます。

チェック工程

 二つ目の策として、走り抜けた後の「熟考チェック」の時間を設けるようにします。チェック工程でじっくり内容と向き合い、ブラッシュアップするための時間を確保するのです。

 この時間があるからこそ、「チェック工程は」荒削りでも良いから最後まで走り抜けよう、という思いが湧き上がるのです。これがなければ心配性の完璧主義者は恐ろしくて走ることすらできなくなり、堂々巡りの牛歩進捗となってしまうのです。

「作業工程」で、振り返らずに走り抜け!

 以上2点のセーフティーネットが用意されて初めて、目の前の作業に集中できるのです。繰り返しになりますが、実際の作業に入ったならば、とにかく最後まで走りきることが重要です。

 完成度は5割程度でもかまいません。作業工程で、どうしても気になることが発生したら、メモに書き出して頭から追い出しましょう。ひたすら前へ進むのです。メモは後から確認すればよいのです。

 また、寄り道せずに走りきるためには、脳のコンディションも重要となってきます。疲労が蓄積すると、目の前のタスクに集中し切れずに、あちこち寄り道してしまうことになりかねません。脳のメンテナンス方法については、以下の記事をご参考に。

 このように、一度最後まで走り切れば一通りは出来上がり、全体像が明確になるはずです。今まではベースがない状態で熟考していましたが、今後はそれなりのベースが存在する状態からのスタートとなるので、不毛な手戻り・堂々巡りが激減することになるのです。

 以上が対処法となります。

 次に、もう一つの例として、皆さんが毎日使う「メールの処理」についても考えてみましょう。

 

そのメール、返信するまでに合計、何回読んでる?

 まず、初めてメールを受信・開封したタイミングで1回読みますよね。その場で返信可能であればそこで処理は完了ですが、「返信はあの人に確認してから……」などというケースも多々あるので、フラグなどを付与し、返信を先送りすることもあるかと思います。

 そのまま何も対処しなければ、日々、メールを山ほど受信するような人であれば、放置していたフラグつきメールを、2回、3回……と、何度も読み返して「あ、これはまだ返信しなくていいや、つーか、コレ何度目だろ」となってしまうことにもなりかねません。

 この例も、資料作りの例と同様、無意識に「同じことを何度も繰り返している」状態にあるわけです。この時間、完全に無駄ですよね?

 メールを読んでいいのは原則、初めて開封した時と、返信する時の計2回までです。

 開封したタイミングで、その場での返信が不能であれば、タスクリストにぶち込む必要があります。そしてタスクが仕上がったら、直ぐにメールの返信を行います。ここには一切の無駄がありません。

 これを先ほど説明したフローに当てはめると……

  1. 設計工程
    メール処理のルールを事前に決めておきます。その場で返せないならタスクリストに入れる、という決め事がそれに相当します。
  2. 作業工程
    ルールにのっとり、タスク処理に集中。原則、この間はメールは一切見ません。
  3. チェック工程
    最後にタスクの結果と併せてメールの内容を確認し、返信します。

 という流れになります。これによって、何度も同じ作業を繰り返すような事態を回避できるわけですね。

 

ITプロジェクトも、他の仕事も同じこと

 IT業界の方は途中で気づかれたかもしれませんが、この「設計工程」→「作業工程」→「チェック工程」という一連の流れは、システム開発と全く同じ考え方なのです。

 小規模で簡易なプログラムであれば、頭の中で設計しながらプログラムを組むことも可能ですが、大規模で複雑である場合は事前に「何をつくるべきか?」を、まず整理(=設計)し、手順を明確化してから作り込みの作業(=プログラム実装)に着手することになります。

 整理することで混乱を防ぎ、リソース(=人・時間という資源)を、目の前のタスクに集中的に投入できるようにするためです。

 今回の記事で説明した方法は、言わば「一人プロジェクト」のようなものですね。世間一般のプロジェクトとの一番の違いは「作業工程」の完成が荒削りでも全く問題ない、という点です。

 実際の開発現場で、まともに動かないバグだらけのプログラムを引っさげて試験フェーズへ突入してしまうと、大変なことになってしまします。「全然できてねえじゃねえか!コラ!ヽ(`・ω・´)ノ」ってね。

 でも、今回の一人プロジェクトであれば自由気ままに、完成度が仮に50%の状態でも「チェック工程」に突入できるわけです。これって、今までに比べてとっても気持ちが楽じゃありませんか?これで超優秀な「一人プロジェクトマネージャー」の誕生ですね!


 仕事も遊びも――。

 少しでも楽に。少しでも面白く。

 優秀な「一人プロジェクトマネージャー」がいれば、それも難しくないかもしれませんね!

 

 

適当教典

適当教典

 
がんばりすぎるあなたへ 完璧主義を健全な習慣に変える方法

がんばりすぎるあなたへ 完璧主義を健全な習慣に変える方法

 
スタンフォードの自分を変える教室

スタンフォードの自分を変える教室

 

photo by Philip Chapman-Bell

文章、画像等を含む全ての著作物の不正利用・転載を禁止します。
© 2017 プロジェクトマネジメントの話とか, ALL RIGHTS RESERVED.