なぜあの人は仕事が速いのか？仕組みをパッケージ化する「オブジェクト思考」の力
こんにちは。
50人の会社から、社会にちょっと良いインパクトを残したい、藤井です。
「藤井さんは、仕事が速いですね」
ありがたいことに、そう言われる機会がよくある。
だが、自分自身で「手が速い」と思ったことは、実はあまりない。
ただ、常に「速さ」を意識してはいる。
そもそも、「スピード」とは何だろうか。
物理的な概念で言えば、スピードとは「進んだ距離 ÷ 時間」で算出されるものだ。
どれだけの時間をかけて、どれだけの距離を進んだか。
しかし、ビジネスにおける「仕事の速さ」を考えるとき、単に「時間あたりの作業量（進んだ距離と時間）」だけを見ていては、改善の方向性を大きく掛け違えてしまう気がしている。
手元の作業スピードを上げて、短時間で多くの距離を進む。
それは素晴らしいことだが、どこか単なる「個人のスキルアップ」や「作業能力の向上」にとどまりがちだ。
仕事において、早いことは正義だ。
ミスが多くては意味がないが、スピードが信頼を生むのも事実だ。
カスタマーサクセスにおいても、「最初の成功体験（ファーストサクセス）」をどれだけ早く提供できるかが勝負を分ける。
返事をすぐにする。解決策をすぐに導き出す。
だが、本当に仕事が早い人というのは、単に「手が速い」のではない。
常に頭の中に「目的地（目標）までの距離」を置いているのだ。
目的地までの距離はどれくらいあるのか。
その目的地に到達するためには、どのルートを通り、どう時間を配分すべきか。
あるいは、目標を大きく超える成果を出すため、さらには創出した空き時間で人生をもっと楽しむために、どう動くか。
比較対象となる「目的地までの距離」を定義してはじめて、自分がいま出すべき本当の「スピード」が見えてくる。
私がスピードを保つために大切にしている感覚がある。
それは、
「他人が早いのではなく、自分が遅い」
と常に思うことだ。
自分が遅いと感じるからこそ、工夫が生まれる。
「この業務プロセス、どうにかしてスキップできないか？」
「どうすれば、目的地に向かって最大級のレバレッジを利かせられるか？」
その答えを探るヒントが、プログラミングの世界にある。
それが「オブジェクト指向」という仕組みだ。
「オブジェクト指向」とは、関連するデータと処理を「一つの部品（オブジェクト）」としてまとめ、それらを組み合わせて効率的にシステムを作る手法のことだ。
一からすべてのコードを書き直すのではなく、あらかじめ作った便利な「部品」を呼び出して使い回す。だから、開発スピードが上がり、バグ（ミス）も減る。
私は、この考え方をもじって、ビジネスや日常の仕事に「オブジェクト思考」という発想を取り入れている。
現代のビジネスパーソンは、真面目で泥臭い。
しかし、時として「目的地に向かう際、毎回一からすべてを手作業で作る」という罠に陥りがちだ。
これでは、どれだけ手の動き（作業速度）を速くしても、時間も体力も足りなくなってしまう。
「オブジェクト思考」は、仕事を「再利用可能なパーツ」として捉える。
- どの業務を、どのレベルまでAIに任せられるか？
- 何をデータベース化すれば、繰り返し使えるエンジンになるか？
- HubSpotの実装やマーケティング施策を、どうやってパッケージ化し効果を最大化するか？
すべては、変えられない「定数」に悩むのをやめ、動かせる「変数」に集中してレバレッジを利かせるための仕組みづくりだ。
パーツを組み合わせて仕組み化することで、単なる「手元の作業速度」ではなく、「目的地到達までのスピード」を爆発的に高めることができる。
さらに言えば、これは組織や「人」に対しても同じことが言える。
- 誰が新しい道を切り拓いてくれる可能性が高いか？
- ベクトルの強さや長さ、つまり明確な「指向性」を持っているのは誰か？
個々の強みや指向性をパーツ（オブジェクト）として捉え、適材適所で組み合わせていく。
それによって、自分一人だけでなく、組織全体の目的地へ向かうスピードが劇的に加速するのだ。
目的地を定めずに、ただ「手が速い」ことを競っていても意味はない。
それは、どこへ向かっているかも分からずに、その場で足踏みを早くしているようなものだ。
仕事の「目的地」を正しく見定め、「オブジェクト思考」でプロセスを構造化してみる。
そして、自分自身のスピードと目的地までの距離を常に計測し、問い直す。今日、あなたが取り組もうとしているその仕事。
それは、一回限りの泥臭い手作業だろうか。
それとも、未来の自分を目的地へ素早く運ぶ「部品」になっているだろうか。
日々、アップデート。
自分の歩幅で、進んでいこう。
クリエイティブホープ 藤井
