やったほうがいいと分かっているのに、手が動かない作業がある。 記事の告知、週報、顧客への連絡、数字の集計。 重要度は理解しているのに、毎回その気にならなければ始められない。
以前の私は、この状態を意志の弱さだと考えていた。 けれど、作業を続けられない理由は、意志よりも工程の設計にあることが多い。 入力から出力までの途中に、判断のいらない反復や、成果に直結しない手順が混ざっている。
そこで私は、面倒な作業を減らすための考え方を「怠惰設計」と呼ぶようになった。 怠けることを正当化する言葉ではない。 動けない日があることを前提に、それでも必要な結果へ届く流れを作る試みである。
まず「何をしたくないのか」ではなく、目的を言い直す#
「SNSで記事を紹介する」は、作業の名前であって目的ではない。 本来の目的は、関心を持つ人に記事の存在を知ってもらうことかもしれない。 ここを混同すると、投稿文を毎回考え、投稿のタイミングを悩み、反応まで追い続けることが仕事になる。
怠惰設計の出発点は、やることリストを増やすことではない。 作業の最後に得たい状態を、一文で置き直すことである。
たとえば、「週報を書く」を「関係者が今週の判断と次の相談事項を把握できる状態にする」と言い換える。 すると、装飾や細かな経緯を毎週書く必要があるのかを検討できる。 残すべきものは、出来事の網羅ではなく、次の判断に必要な情報だと分かる。
目的を言い直すと、削れる工程が見えてくる。 同時に、自動化してはいけない工程も見えてくる。 相手との約束、公開前の最終判断、例外への対応は、手作業のまま残したほうがよい場合がある。
工程を「人が決める部分」と「繰り返す部分」に分ける#
目的が決まったら、今の作業を入力、加工、出力の順に分ける。 このとき大切なのは、最初から完全自動化を目指さないことだ。
個人開発で記事の紹介文を作るなら、入力は記事本文、出力は投稿用の短い文章になる。 その間にある要約、候補の比較、投稿先への貼り付けを一つずつ眺める。 本文から候補を作る処理は生成AIに任せられる。 一方で、どの候補が自分の言葉として出せるかを選ぶのは、人が持つべき判断である。
私は、記事の告知を毎回手で組み立てることに強い抵抗があった。 そこで「本文を渡す」「候補を受け取る」「一つ選んで貼る」という流れに分けた。 全部を自動投稿にはせず、最後の選択を残したことで、作業は短くなり、内容への違和感にも気づけるようになった。
人の作業をゼロにすることが目的ではない。 人にしかできない判断へ、限られた集中力を使えるようにすることが目的である。
小さく動かし、失敗したら捨てられる形にする#
仕組み化は、便利そうなツールを選ぶところから始めると大きくなりやすい。 連携サービス、データベース、管理画面を先に作ると、使われるか分からない機能を維持することになる。
先に確かめるべきなのは、その仕組みが本当に面倒を減らすかである。 私は、ある発信作業を半自動化できないかと考えたとき、先に利用者へ「この作業は負担か」「候補だけでも出れば使うか」を聞いた。 反応を確認してから、最小限の入力と出力だけを作った。
この順番なら、外れたときの損失は小さい。 使われなければ捨てられるし、使われれば次の改善に進める。 個人開発では、完成度を上げる前に、手作業が一回減ったか、誰かの判断が速くなったかを見たほうがよい。
怠惰設計を使うときの確認項目#
仕組みを作る前に、私は次の三つを確認する。
- この作業を終えたとき、誰が何を判断できればよいか。
- 同じ入力に対して、毎回ほぼ同じ処理を繰り返していないか。
- 自動化が失敗したとき、人が短時間で気づき、元へ戻せるか。
三つ目が抜けると、面倒を減らすつもりの仕組みが、監視の仕事を増やす。 生成AIの出力も同じである。 候補を作る速度は上がるが、事実関係、言葉の温度、公開してよい内容まで任せることはできない。 任せる範囲を決めることが、仕組みを続ける条件になる。
頑張れない日を前提に、次の試行を残す#
怠惰設計は、努力を減らすためだけの方法ではない。 反復を減らして空いた時間と気力を、次の検証へ回すための方法である。
一度の大きな挑戦に賭けると、失敗は重くなる。 小さく作り、使われ方を見て、合わなければ直すか捨てる。 この循環を続けられれば、動けない日があっても、挑戦全体は止まりにくい。
やりたくない作業に出会ったら、根性で片付ける前に立ち止まる。 目的を言い直し、繰り返しを分け、最小の形で試す。 それだけで、面倒な仕事は少しずつ、自分の時間を守る仕組みに変わっていく。
