なんでstersさんは作業がはやいの?

定期的に誰かから聞かれるのだけど、あんまり考えたことがなかったので考えてみる。

はやい、とは

“はやい” には速いと早いがある。速いは速度が高い。早いは時間や時刻が手前になっている。例文を出すと「速い手段で移動したから、到着が早かった」

そうして"作業がはやい"を分解するといくつかの可能性が考えられる。

  • 作業時間が同じくらい
    • =同じルートを通るがスタートダッシュしている
    • 着手タイミングが手前になっているから、終わるタイミングも手前になり、結果として早くおわる
  • 作業時間を増やしている
    • =同じルートを通るがスター状態
    • 着手タイミングが同じでも、終わるタイミングが手前になって、早くおわる
  • 作業時間が短い
    • =同じルートを通らずにショートカットをしている
    • 着手タイミングが同じでも、作業時間が短いから、終わるタイミングが手前になって、早くおわる

どうやってスタートダッシュをするか

やりそうなことを事前にキャッチして、下調べや準備をしておく。

プロダクト開発においては、プロダクトの方針を決めるオーナーがいるはずなので、彼らと会話をすればどんなことをやりそうか、やりたいか、を知ることができる。あるいは、先周りして、プロダクトを使っている人たちと直接的/間接的なコミュニケーションして、クリアになっていない困りごとを知ることもできる。

もっと上のレイヤー、会社の方針とか、を元に、こういうことをやりそうだな〜というのはぼんやりと見えてくるはず。でもあんまりぼんやりすぎるところに突っ込んでいくと無駄になってしまうのでほどほどに。

他にも、自分で気になることを提案して進めていく、という手段もある。自分がこうやればできそうなので、やりませんか?っていう方法。

やりたいことが見えてきたら、じゃあそれをどのようにしてやろうか、というのを調べて、PoCまでもっていくとかなりスタートダッシュが効いた状態になる。

とはいえ、普段の業務をやりながらそういったことをやるのは難しい。待ち時間や、手の空いたわずかな時間を活用するしかない。興味があって、好きでやっているなら、業務に関係のない範囲で、知識探求としてやるのもよい。

どうやってスター状態にするか

余計なものを減らすか、本当に増やすか。

余計なものというのは、その作業に対する余計なもの、という意味。例えば、作業に直接関係のないMTGが代表例。作業したいのに1on1とか定例とか、別タスクの相談とか、は全部余計なもの。

具体的なテクニックとしてはタイムブロッキングがやりやすい。この時間は絶対これをやるぞ!というもの。そこに、ポモドーロ(25分やる→5分休憩)やフロータイム(やる→疲れたら休む)の集中度を高めるためのテクニックを導入してもよい。

ぼくはあんまり意識はしてないけれど、フロータイム的なアプローチはよくやる。例えばCI待ちになるような場面で、立ち上がってウロウロしたり、Slack眺めたり。

「別タスクに手を伸ばしちゃう」というのも余計なもの。そういえばこっちはどうだっけ?とチラ見するのはあんまり良くない。ちょっと休憩〜みたいなオフモードになっているときにやるのはありだけど、あんまりやらないほうがいいだろう。そっちに意識が向いちゃうので。

時間を本当に増やすのは、業務という点においては、残業という手段しかない。残業が常態化して、それ前提の見積もりになったりするのはNGなので、そういうところは気をつけていきたい。

どうやってショートカットをするか

そのショートカットがあることの知識を持つか、アイテムを使うか。

「そこにショートカットがある」という知識は、基本的には「やらなきゃわからない」。それは業務からかもしれないし、「どうやってスタートダッシュをするか」でも書いたように自分で好き勝手やるときかもしれない。

例えば「Webページ上でボタンを押したらAPIを呼び出して、結果に応じてモーダルを表示したい」といった要件があったときに、近い実装をやったことがあれば「APIのドキュメントはここにあって、それに従ってfetchするコードを書いて、モーダルは既存のものがあるから使い方はこれで。よし1時間あれば動作確認してもおつりが出そうだな」といったイメージが付く。

でもやったことがない、そもそもAPI呼び出しも知らなければそれを調べて、どうやるかを見つけ出さないといけない。見つけ出すところでも知識が必要で、未経験な人によろしく〜といっても無理がある。どんなキーワードでググるかもわからない。

そういった"知識"がショートカットの正体だと思う。「どうやってスタートダッシュをするか」と結構被るところだとは思うけど。

ただ最近はAIの進化がすごくて、コーディングはもちろん、企画、設計、レビュー、なんでもこなせる。まったく知らないリポジトリをポンっと渡されても、コーディングエージェントで開いて「初めて触るんだけど概要おしえて。あとこういうタスクをやろうとしているので実装して、その解説を書いて」などと伝えたら仕上がってしまう。

そういったアイテムを使うこともショートカットの重要な手段。特にコーディングに関しては、人が書くよりめちゃくちゃ速い。仕上がりの質についてはコンテキストが足りない=彼らの知識が少ない、という状態だろうので、ポン出ししただけなら、セルフレビューをさせたり、同じリポジトリ内のコードを読んで統一感を出してもらったり、やりようはある。

巨大な集合知を活用しよう。

AI使うのはいいんだけど、気をつけることがあって、自分の知識・経験になりにくい(AIがこういってました〜になりがち)ところと、AIの出した回答があっているか確認するには自分の知識が必要、というところ。

もう少し時間がたって、AIエージェントをマネージメントするのが一般的になったとしても、自分の知識がないとうまくマネージメントできないね、というところになって、結局は自分の知識なんだろうな〜と今のところは思っている。どうなるかわからんけど。

まとめ

Q. なんでstersさんは作業がはやいの?

A. 知識をもっていることでスタートダッシュとショートカットが出来ている。あとはスター状態になることで集中した作業をしている。だからはやい。特殊能力じゃない。だれでもできる。

サイト案内

運営してるひと: @sters9

最近は Go, Ruby, Rails, Kubernetes, GCP, Datadog あたりをしていますがもっといろいろやりたい!

プロフィール

開発環境の紹介

プライバシーポリシー

tools.gomiba.co

building-microservices.gomiba.co

サイト内検索

アーカイブ

2025/12 (2) 2025/11 (1) 2025/10 (2) 2025/09 (4) 2025/08 (1) 2025/07 (6) 2025/06 (1) 2025/05 (1) 2025/04 (3) 2025/03 (1) 2025/02 (3) 2025/01 (4)

2024/12 (2) 2024/09 (3) 2024/07 (1) 2024/06 (3) 2024/05 (1) 2024/04 (7) 2024/03 (4) 2024/01 (3)

2023/12 (1) 2023/11 (3) 2023/10 (1) 2023/09 (1) 2023/08 (2) 2023/05 (4) 2023/04 (4) 2023/03 (4) 2023/02 (2) 2023/01 (1)

2022/12 (2) 2022/11 (4) 2022/10 (3) 2022/09 (2) 2022/08 (4) 2022/07 (5) 2022/06 (4) 2022/05 (9) 2022/04 (8) 2022/03 (10) 2022/02 (21) 2022/01 (8)

2021/12 (11) 2021/11 (1) 2021/10 (4) 2021/09 (2) 2021/08 (1) 2021/07 (2) 2021/06 (5) 2021/05 (10) 2021/04 (1) 2021/03 (8) 2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)