「普通」ができない僕の自分サーバー運用術（4）｜僕が作っていたのは、ライフハックではなく取扱説明書だった

【「自分サーバー」運用術｜全5話】
① 難しい仕事はできるのに、簡単なことで壊れる理由
② 僕は壊れているのではなく、そういう仕様の一台だった
③ 世間の正しいやり方が、僕には毒だった
④ 僕が作っていたのは、ライフハックではなく取扱説明書だった（この記事）
⑤ 「使えない人」ではなく、置き場所が違っていただけだった

第二部　僕という一台を、どう運用するか

第11章　運用には、三つの系統がある

ここから、僕が組んできた運用設定を具体的に開いていく。その前に、見取り図を一枚だけ渡しておきたい。

僕がやってきたことは、数は多いが、煎じ詰めると一つの発想から出ている。「僕という一台に、過剰な負荷をかけない」。それだけだ。落ちる原因は、いつもどこかにかかりすぎた負荷だった。

その負荷対策は、三つの系統に分かれる。

• 入口を絞る——外から流れ込む情報や、抱えるタスクが多すぎると僕はあふれる。だから、入口で量を減らす

• 溜め込まない——入ってきたものを頭に溜めると、やがて詰まる。だから、こまめに外へ出し、疲れは逃がす

• 逃げ道を持つ——中をどれだけ整えても、仕事が消えるような外の事故は起きる。だから、一本倒れても全体が倒れない形にしておく

これから話す運用は、すべてこのどれかに属している。ばらばらの小技に見えたとしても、根っこはこの三つのどれかだ。

設定を組む手順を、先に渡す

中身は僕の設定だ。あなたの正解ではない。だから、中身より先に、組み方を渡しておく。

これから並べる設定は、どれも同じ手つきから生まれている。四つの段だ。

• 外に出す——頭の中にあるままのものは観測できない。落ちたときの様子でも、詰まった瞬間のことでもいい。紙にひたすら出す。裁かず、整えず

• 落ちる条件を一つだけ名指す——「僕はダメだ」ではなく「僕はこういうときに落ちる」。情報が増えると落ちる、大きな塊を前にすると止まる、薬を忘れると霧が出る。具体的な一つを名前で押さえる

• その一つを外すか小さくする設定を、一つだけ組む——全部を一度に直そうとしない。名指した条件に狙いを絞る

• しばらく回して、効かなければ捨てる——未練は持たない。効かない設定にしがみつくと、それ自体が負荷になる

紙に四行、こう書いて埋めれば、それで一周だ。

• 止まった場面——いつ、何をしようとしていたか

• 負担になっていた条件——音、視線、移動、指示の曖昧さ、塊の大きさ、時間帯、体調

• 一つ変えること——減らす、外に出す、順番を入れ替える、相手と調整する

• 試した結果——何が楽になり、何が残ったか。効かなければ、消す

前回渡した五行の記録は、この一段目と二段目のための材料集めだった。四行目まで来たら、また一段目に戻る。それだけを、僕は三十年やっている。

真似してほしいのは、設定ではなく、この四行のほうだ。それさえ手元にあれば、あなたの設定は、あなたの手でいくつでも出てくる。

では、一つめの系統から始めよう。

第Ⅰ群　入口を絞る

第12章　入れないものを、先に決める

スケッチブックが教えてくれたのは、単純なことだった。僕の頭は、入ってきたものを自動では捨てられない。行きたい店も、三年前の失敗も、南の島も、一度入れば同じ重さで居座って作業の邪魔をする。

出すのが下手なら、入れる量を減らすしかない。

ここで、多くの本とは逆のことを言う。世の中には、いかに効率よく情報を取り込むかという技術があふれている。速読、情報収集術、インプットの質を上げる方法。だが僕に必要だったのは、その正反対だった。いかに情報を入れずに済ませるかだ。

僕が入口に付けた仕切りは、こういうものだ。

• SNSは、見る回数を極端に減らす。 そのうえで、「発見」や「おすすめ」のように、頼んでもいないものを次々に見せてくる機能を切る。フォローした相手の投稿だけが静かに並ぶ。それでいい

• ニュースサイトの見出し一覧を、見えないようにする。 開けば必ず飛び込んでくる、あの雑多な一覧を消す

• コメント欄を表示しない。 記事の下にぶら下がっている見知らぬ他人の意見は、読むと必ず何かが心に居座る

• 自動で流れ込む仕組みを、全部止める。 RSSのような新着通知は、放っておくと僕の作業台を頼みもしない情報で埋めてしまう

• どうしても集中したいときは、回線ごと遮断する。 時間を決めて切る

最後のものに使っているのは、子どもの使いすぎを防ぐためのフィルタリングソフトだ。子ども向けの道具が、四十を過ぎた僕の集中をいちばん確実に守ってくれる。書くのは少し気恥ずかしいが、効くのだから使う。

本当に効いたのは、その先だった

仕切りを付けながら、僕は自分の情報の入れ方を観測するようになった。すると、妙なことに気づいた。

僕がいちばん大量に情報を詰め込んでいたのは、学びたいときではなく、不安なときだった。

きっかけは、たいてい誰かの投稿だった。自分よりずっと先を行く人の発信。それを目にした瞬間、僕の中で古い回路が起動する。「それに比べて、お前は」。長年しみついた、あの声だ。

その声が鳴ると、僕は落ち着かなくなる。この遅れを取り戻さなければ、と焦る。そして、焦りを鎮めようとして、手当たり次第に情報を詰め込みはじめる。不安を情報で埋めようとするみたいに。だが、詰め込むほど頭は騒がしくなり、かえって何も手につかなくなる。落ち着くどころか、また自分を責める。

つまり僕の入れすぎは、知識欲ではなかった。不安に駆り立てられた過食だった。そして、その過食に火をつけていたのが、自分より先を行く人たちの姿だった。

だから僕は、その人たちのフォローを外した。

尊敬していないからではない。むしろ逆で、まぶしすぎた。彼らの発信は、僕にとって栄養であると同時に、あの回路への餌でもあった。餌を断てば、回路は静かになる。回路が静かになれば、不安に駆られた詰め込みも止まる。同じように、「今すぐ追いつかないと置いていかれる」と煽ってくる声も、片っ端から遠ざけた。

向上心を捨てたのではない。自分を潰していた回路に、燃料を送るのをやめただけだ。

道具では閉められなかった水門

だが、いちばん奥にあった水門は、設定では閉められなかった。

僕はずっと、ある考えに追い立てられていた。「情報をキャッチアップし続けなければ、この業界では生き残れない」。新しい技術が出るたびに乗り遅れまいと焦り、片っ端から頭に詰め込もうとしていた。あの汚部屋の半分は、この焦りが運び込んだものだったと思う。

観測を重ねるうちに、僕はこの考えのほうを疑うようになった。

すべてをキャッチアップするなど、そもそも誰にもできない。まして、入れたそばから同率一位で騒ぎ出すような僕の頭では。僕がやるべきなのは、世界のすべてを追いかけることではなく、自分にできることと、世間が求めていることが重なる一点を見つけて、そこに情報を集中させることだった。

この考えに切り替えたとき、いちばん大きな水門が閉まった。「全部を追う」のをやめた瞬間、入ってくる情報は驚くほど減った。そして、頭は驚くほど静かになった。

一つだけ、うまくいかなかったこと

正直に書くと、この絞り方には失敗もあった。

一時期、僕は絞りすぎた。技術情報の流れを断ち、SNSも見ない。頭は静かになった。ところが数ヶ月して、現場の会話で知らない言葉が続けて出てきた。周りが当たり前に使っている道具を、僕だけ知らなかった。

絞るのは、遮断ではない。量を減らすことと、経路を断つことは違う。

そこで一つ足した。信頼できる人が書いた要約を、週に一度だけ読む。流れてくるのを止め、自分で取りに行く形に変えた。取りに行くなら、量は僕が決められる。

——気づいた人もいるかもしれない。僕はこの章で、前の章の四行をそのまま一周回しただけだ。条件を名指し、設定を一つ組み、効かない部分を直した。

これから先の章も、やっていることは全部これと同じだ。だから、いちいち「これは僕の設定です」とはもう言わない。あなたが名指す条件は、きっと情報ではない別の何かだろう。それでも、回し方は変わらない。

第13章　起動できる大きさまで、落とす

入口を絞って、頭が少し静かになった。次にぶつかったのは、別の問題だった。

いざ何かに取りかかろうとしても、手が動かない。

やるべきことはわかっている。たとえば「記事を一本書く」。目の前に、それがある。なのに体が固まる。怠けているわけではない。やる気がないわけでもない。ただ、その塊を前にすると頭が真っ白になって、最初の一歩が踏み出せない。

長いあいだ、これを「意志が弱いからだ」と思っていた。だが、観測してみるとそうではなかった。

手が止まるのは、塊が大きすぎるときだった。

「記事を書く」という塊の中には、いくつもの別々の作業がぎゅうぎゅうに詰まっている。何を問うか決める。材料を思い出す。使える材料を選ぶ。順番を組む。文章にする。削る。整える。これだけの工程が、一言に団子になって入っている。

その団子を前にして、僕の頭は全部を一度にやろうとする。書きながら同時に、これは使えるかと選び、順番を考え、言い回しを直そうとする。いくつもの判断が同時に手を挙げる。あの、同率一位の騒ぎだ。頭は渋滞し、そして止まる。

やることは決まっていた。団子を、ほどく。

僕が記事を書くとき、実際にやっているのはこうだ。まず、頭に浮かぶ言葉を片っ端から書き出す。このとき、使えるかどうかはいっさい考えない。ただ、出す。出しきってからはじめて、別の工程として使えるものを選ぶ。

出す作業と選ぶ作業を、混ぜない。 これが肝だった。

書きながら選ぼうとするから、詰まる。出すときは出すことだけ。選ぶときは選ぶことだけ。一つの手に、一つの判断。そうやってほどいていくと、一つひとつはちゃんと手が動く大きさになる。「記事を書く」では動けなくても、「思いつくままに言葉を書き出す」なら動ける。

どこまで小さくするか。答えは決まっている。自分の手が動くところまでだ。動かないなら、まだ大きい。もっと割る。割って割って、「これならできる」と体が感じるその大きさが、僕にとっての最小単位だった。

これが、一つめの分割だ。塊を、空間的に割る。

割ったら、次は長さの問題が来た

小さく割ったピースの一つに取りかかる。すると今度は、「これにどれくらい時間をかけよう」と考えはじめる。三十分か、一時間か。区切りをどこに置くか。

気づくだろうか。これもまた判断なのだ。 作業を始める前に、僕はまた一つ決めごとを増やしている。そのたびに、あの騒がしい頭が少しずつ消耗する。

そこで僕は、思い切ったことにした。長さを毎回決めるのを、やめた。

いろいろ試した末に、僕にちょうどいいのは十五分だった。だから、十五分に固定した。この作業は何分にしようか、と考えるのを、やめた。何であれ、十五分。

「時間で区切らない」と言ったはずだが

ここで、前回書いたことと食い違うように見えるかもしれない。

前回、僕はポモドーロが効かなかったと書いた。二十五分のタイマーが、残り時間を見張らせるからだ。だから「時間で区切るのをやめて、作業の大きさで区切った」と書いた。

なのに、いま十五分に固定したと言っている。

矛盾しているようだが、この二つは別のことをしている。

• 作業の大きさは、どこで終わるかを決めるためのもの。「この章を読み終える」「この一枠を描く」。終われば立つ

• 十五分は、どこで終わるかを決めるためのものではない。長さを毎回考えないためのもの

僕にとって二十五分が駄目だったのは、長さそのものより、「あと何分か」を見張らせる作りのほうだった。だから僕は、数字が減っていくタイマーを使わない。十五分の砂時計を置いている。落ちきったら顔を上げる。それだけだ。落ちきる前に作業が終われば、砂は無視して立つ。

第1話で「一回分を三十分以内で終わる大きさに切る」と書いたのも、これだ。砂時計一つ、足りなければ二つ。それより大きい塊は、僕には持てない。

長さが決まっていれば、あとは「この作業に、十五分をいくつ割り当てるか」を、ざっくり見当をつけるだけでいい。

もっとも、その見当はたいてい外れる。十五分ふたつで終わると思った作業が、四つかかったりする。でも、それでいい。僕はソフト開発の現場で、見積もりというものがそう簡単には当たらないことを、嫌というほど知っている。厳密に計画して、その通りにいかずに自分を責めるくらいなら、はじめから緩くやるほうがいい。区切りは、自分を縛る道具ではなく、手を動かしはじめるためのきっかけにすぎない。

二つの分割は、同じことを言っている

こうして並べてみると、気づく。

タスクを空間で小さく割るのも、長さを十五分に固定するのも、やっていることは変わらない。どちらも、頭が一度に抱える判断を減らしている。大きな塊は判断の団子だから、ほどく。長さを毎回決めるのは判断の上乗せだから、やめる。僕の頭は、判断がいくつも重なると渋滞して止まる。だから、判断を一つずつに小分けにする。それだけのことだった。

あなたの手は、どこで止まるだろう。「記事を書く」なのか、「メールを一本返す」なのか、「電話をかける」なのか。止まる場所は、人によってまるで違う。十五分という長さも、僕にたまたま合っただけの数字だ。

だが、一つだけ、たぶん共通している。手が止まるとき、その塊の中には、いくつもの判断が団子になって詰まっている。止まる場所さえ見つかれば、あとはほどくだけだ。

第Ⅱ群　溜め込まない

第14章　頭の中のものは、全部、外に出す

スケッチブックで、僕は思考を外に出すことを覚えた。出してみて、初めて自分が何を抱えていたかが見えた。

だが、しばらく運用してみて気づいた。外に出すべきものは、思考だけではなかった。

やるべきこと。今の自分の状態。溜まっていく疲労。どれも、内に溜め込んだままにしておくと、いつのまにか容量を食い、最後には僕を落とす。答えは、思考のときと同じだ。全部、外に出す。

一つめ：やるべきこと

僕は、やることを頭の中に置いておけない。置いておくと、それが「同率一位」の一つになって、作業の最中に何度も顔を出す。だから、思いついた時点ですぐ外へ——ToDoを書き留める道具に、預けてしまう。

道具は、役割で二つに分けている。

• 先の見えている定常的な用事——決まった手順のあるもの。これは一覧に置くだけでいい

• 手を付けてみないと形の見えない仕事——これは、前の章でやったことを、そのまま道具の上でやる

後者に取りかかるときは、浮かんでくる疑問、調べるべきこと、割れそうな単位を、軽重を判断せずとにかく書き出す。そして、手が自然に動く大きさになるまで、それを繰り返す。頭は、覚えておく係から解放される。覚えているのは、道具の仕事だ。

二つめ：自分の状態

僕には、困った癖がある。調子が悪くなっていることに、落ちてから気づくのだ。気づいたときには、もう作業にならない。

サーバーの世界には、監視という仕組みがある。落ちてから慌てるのではなく、負荷が危険域に近づいたら、あらかじめ警告が鳴るようにしておく。あれを、自分にも仕掛けられないか。

とはいえ、自分のサインが最初から分かっていたわけではない。そこで僕は、逆から辿った。ひどく落ちた日をいくつか思い返す。そして、その日の落ちる少し前に何が起きていたかを書き出す。すると、毎回のように顔を出す共通の前触れが、いくつか浮かび上がってきた。

落ちてから探すのではなく、過去の墜落から先回りして拾っておく。これが、僕の赤信号の作り方だった。

いま僕が使っている赤信号は、こういうものだ。

• 十五分の区切りすら、最後まで走れない

• 作業台が、目に見えて狭くなる——プログラムを書いていて、一つの部分から別の部分へ視線を移した瞬間に、さっきまで見ていた内容が頭からきれいに消える

• 胸のあたりに、ざわざわとした落ち着かなさが立つ

• 強い眠気に襲われる

理由まではわからなくていい。「これが出たら危ない」という自分の赤信号を、いくつか覚えておく。

あるとき、まさにそれが起きた。前任者の書いたコードが、読んでも読んでも頭に入ってこない。別の部分に目を移すと、直前まで追っていた中身がフッと消える。戻ると、また消える。穴の空いたバケツで水を汲んでいるようだった。

以前の僕なら「頭が悪くなった」と落ち込んだだろう。だがそのときは、ふと自分にこう問えた。「どうした。ちょっと、メモリリークしてないか」。

落ち着いて振り返ると、朝に飲むべき薬を飲み忘れていた。慌てて飲んだが、すぐには効かない。だから、並行して手を打った。その日は、複雑なコードを読むのをいったん諦めた。代わりに、小さな試作品を組む作業に切り替えた。

経験上、僕は知っている。こういう日は、「読む」より「作る」ほうが負荷が低い。同じ仕事でも、負荷の軽い入口から入り直せば、手は動く。

大事なのは、サインの中身より、サインを先に決めておくことだ。決めておけば、それが出た瞬間に、気合いで押し切ろうとするのではなく、「ああ、いま危険域だ」と手を止められる。落ちる前に気づける。そして、責める代わりに点検できる。

三つめ：溜まった疲労

サインの中でも、強い眠気は少し特別だ。あれは不調のサインであると同時に、体からのはっきりした要求でもある。冷やせ、と言っている。

サーバーは、高い負荷で動き続けると熱を持つ。熱がこもれば、やがて落ちる。だから、逃がす。僕にとっての睡眠は、まさにこれだった。眠るのは、サボることでも止まることでもない。頭にこもった熱を逃がして、翌日また動けるようにするための、れっきとした運用工程だ。

世間では、睡眠時間を削って働くことがどこか美徳とされている。だが、僕の頭は、冷やさなければ次の日に落ちる。

だから僕は、脳を冷やすことに手を尽くしている。

• 夏場は、部屋を涼しくして眠る

• 枕は、通気性のいいものを選ぶ——頭がこもる感じのするものは、僕には合わなかった

• 昼間、気絶しそうな眠気が来たら逆らわない——ノイズを消すイヤホンをつけて、五分だけ目をつぶる。入ってくる情報を完全に遮断する。五分でも、こもった熱が少し抜ける

• 目覚ましでは起きない——体が自然に浮上してくるのを待つ。無理に叩き起こすと、その日一日、頭がうまく冷えないままになる。だから、良い状態で目覚めるサイクルから逆算して、夜ふかしをせず、決まったタイミングに寝る

細かい工夫は人それぞれだと思うが、共通しているのは「頭に熱をこもらせない」という一点だ。

なお、どうしても眠れない時期には、医師に相談して処方された薬に頼ることもある。ただ、これは自己判断で手を出す話ではない。専門家と決めたこと、とだけ言い添えておく。前に出てきた朝の薬も同じだ。この連載で薬の話が出てきても、そこだけは真似の対象にしないでほしい。

三つとも、同じことをしている

やるべきことも、自分の状態も、溜まった疲労も、内に抱え込んだままにすれば、必ず僕を落とす。だから、抱え込まない。タスクは道具に預ける。状態はサインにして外に出す。疲労は眠って逃がす。

溜めない、出す、逃がす。

抱え込むのをやめてから、僕は落ちる前に手を止められるようになった。落ちてから悔やむのではなく、その手前で休む。その先で手にしたのは、そういう小さな余裕だった。

第Ⅲ群　逃げ道を確保する

第15章　壊れる仕事を、断れるだけの余白を持つ

ここまでは、頭の中をどう運用するかという話だった。入口を絞り、判断を小分けにし、溜め込まずに外へ出す。これで、僕という一台はだいぶ安定して動くようになった。

だが、自分の中をどれだけ整えても、どうにもならないことがある。仕事そのものが、外の事情で消えてしまうときだ。

サーバーの世界では、大事な仕組みを一台だけで動かすことはしない。その一台が壊れたら、全部が止まってしまうからだ。だから、系統を複数用意しておく。一つが落ちても、別のものが引き継いで、全体は止まらない。冗長化と呼ばれるこの考え方を、僕は自分の食いぶちに持ち込んだ。

きっかけは、はっきりしていた。

僕は、常駐の仕事ができない。毎朝決まった時間に通い、同じ席に一日じゅう座る。それだけで削れて、落ちる。だから、早い段階で決めた。オフィスに通わなくていい仕事しか受けない、と。

ところが当時、その条件で受けられるソフト開発の仕事は、そう多くなかった。腕のいい人ほど現場に常駐するのが当たり前の時代だった。落ちない働き方を貫こうとすると、収入は細る。

つまり僕にとって、収入を複数の柱に分けることは、「もっと稼ぐため」ではなかった。落ちない働き方を、手放さないためだった。一本の太い柱に頼れないなら、細い柱を何本か立てて支えるしかない。

折れて、入れ替わってきた三十年

最初に僕を支えてくれたのは、外国語の実務翻訳だった。

単価のいい仕事は、たいてい午後に頼まれて翌朝までに納める、という超短納期のものだった。普通なら音を上げそうな条件だが、僕はプログラマとして身につけた効率化の発想で、短納期でも一定の品質が出るように作業を仕組みにして回した。しばらくは、これが家計の主力だった。

やがて、その柱が細りはじめる。機械翻訳の性能が上がり、仕事の数が減り、単価も下がっていった。だが、ちょうど入れ替わるように、次の柱が育っていた。

ブログだ。検索で読まれる記事に、論理の通った、構造のはっきりした書き手が求められるようになった時期だった。僕は、検索エンジンが何を求めているかを読み、記事を素早く直しては試すことを繰り返した。とりわけ旅について書いたものが読まれて、旅ブロガーとしては上々のところまでいった。翻訳が細っても、こちらが支えてくれた。

そのブログの柱も、あるとき突然折れた。検索の仕組みが大きく変わり、個人が細々と書くブログは軒並み読まれなくなった。一夜にして、とはいかないが、それに近い勢いで崩れた。

もし、これ一本に賭けていたら、僕は終わっていたと思う。だが、またしても入れ替わるように、次の柱が立ちかけていた。

世の中が、自宅で過ごす時間の長いあの時期に入ったころだ。オンラインで新しいことを学ぼうという人が増え、僕はプログラミングを学ぶ人たちを画面越しに教える仕事を始めた。

ここでも効いたのが、外に出す運用だった。生徒一人ひとりの背景や、それまでの進み具合を、全部あらかじめ書き出して目に入るところに並べておく。すると、面談のあいだ、頭は思い出す作業から解放されて、目の前の相手のことだけを自由に考えられる。おかげで、参画して間もないころに、指導する側として高い評価をもらえた。

こうして振り返ると、僕の三十年は、一本の柱が折れるたびに別の柱が支えてきた歴史だった。どれか一つが太く育ったわけではない。ただ、同時に何本かが立っていて、一本が倒れても全部は倒れなかった。

柱を増やしすぎて、一度失敗した

きれいな話に見えるかもしれないので、失敗も書いておく。

冗長化が効くと分かってから、僕は柱を増やしすぎた時期がある。翻訳とブログと教える仕事が同時に走り、そこに単発の依頼が乗った。収入は安定した。だが、頭の中が同率一位で埋まった。

前の章に書いた赤信号が、そのころ毎日出ていた。十五分が走りきれない。視線を移すと内容が消える。抱えている仕事の種類が多いこと自体が、僕にとっては入力の多さと同じだった。

冗長化は、負荷分散とは別のものだった。 柱を増やせば安定するが、同時に走らせる本数を増やせば、僕は落ちる。

そこで、決め方を変えた。柱は複数持つが、同じ時期に本気で回すのは二本まで。三本目は、種を撒いておくだけにして、動かさない。折れたときに、そこから起こす。

持っている柱の本数と、同時に動かす本数を、別に数える。これは、いまでも守っている。

冗長化とは、拒否権のことだった

この、何本か立てておくということには、稼ぎ以上の意味があった。

柱が一本しかないと、その仕事にしがみつくしかなくなる。どんなに自分を削る条件でも、断れない。断てば食べていけないからだ。だが、柱が何本かあれば話が変わる。「この仕事は、僕を落とす」と観測できたとき、それを断れる。

冗長化とは、余白のことだった。そして余白とは、断る自由のことだった。落ちない働き方を守るために複数の柱を立てたら、その柱そのものが、僕に断る権利をくれていた。

柱の数も種類も、人によって違っていい。翻訳やブログである必要はまったくない。大事なのは、たった一本にすべてを賭けない、という一点だけだ。

そして、断る自由が手に入ってはじめて、次の章の話ができる。

条件を、口に出して伝えることだ。

第16章　自分の取扱説明書を書く

機械や道具には、たいてい取扱説明書が付いている。この温度で保管してください、直射日光は避けてください、こう使えばうまく動きます——そういう、そっけない説明書きが。

あるとき僕は思った。自分にも、それを書けばいいのではないか、と。

考えてみれば、ここまでやってきたことは、全部その下書きだった。

情報を入れすぎると落ちる。だから入口を絞る。大きな塊の前では手が止まる。だから小さく割る。頭の中に溜め込むとあふれる。だから外に出す。一本の仕事に賭けると、折れたとき倒れる。だから柱を何本か持つ。

これらは一つひとつ、僕という一台の仕様書に書き込まれていった項目だった。「この個体は、こういう条件で落ち、こういう条件で動く」。観測を重ねるほど、説明書きは詳しくなっていった。

最初、それは自分で読むためのものだった。自分の落ちる条件を忘れないように書いていた。

だが、いちばん効いたのは、その先だった。書いた仕様書を、一緒に働く相手に渡すことだ。

実際に渡している文面

第1話の冒頭で、僕が四つの条件を先に伝えた話を書いた。あれは、思いついたことをその場で口にしたのではない。何年もかけて書き直してきた文面を、読み上げただけだ。

いま使っているものを、ほぼそのまま出す。固有名詞と単価の部分だけ削った。

ご依頼を検討いただく前に、私の働き方の条件をお伝えします。合わない場合は、この段階でお断りいただいて構いません。

• 勤務形態：フルリモートでお願いします。常駐および定期的な出社は、お引き受けできません

• 連絡への返信：当日中、遅くとも翌営業日までに返します。即時の返信は約束できません。急ぎの用件は件名に「至急」と入れてください。その場合は優先して確認します

• 打ち合わせ：音声・映像の会議は、週一回程度までを希望します。仕様の確認は、できるだけテキストでお願いします。会議で決まったことは、私が当日中に箇条書きにして共有します

• 成果物の出し方：完成後に一度に出すのではなく、途中の区切りごとに確認をお願いします。区切りの単位は、着手時にこちらから提案します

上記の代わりに、以下をお約束します。

• まとまった作業時間を確保し、品質で返します

• 仕様の判断が必要な点は、こちらから選択肢の形で提示します

• 進捗は週次で、こちらから報告します

長くはない。A4で半分もない。だが、これを渡すようになってから、仕事の始まり方がまるで変わった。

書き方で、意識していること

この文面には、四つのルールがある。

• できないことを、能力の話にしない。 「集中力がなくて」と書かない。「常駐はお引き受けできません」と書く。理由の説明は、訊かれたときだけする

• 数字を入れる。 「早めに返します」ではなく「当日中、遅くとも翌営業日」。曖昧な約束は、相手の中で勝手に厳しく解釈される

• 代わりに出すものを、必ず並べる。 これがないと、条件の一覧はただの要求書になる

• 相手の手間を減らす形にする。 「至急と書いてください」は、僕の都合だが、相手にとっては判断の手間が一つ増えるだけで済む。相手の負担が小さい形に翻訳する

四つめが、いちばん大事だと思っている。

条件を通すコツは、たぶん、こちらの都合をそのまま押し出さないことだ。「僕は即レスができません」は僕の話だ。「急ぎのときは、こう書いてもらえれば先に見ます」は、相手の話になっている。同じことを言っているのに、後者は通る。

実際に、どう調整されたか

渡して、そのまま全部通ったことは、ほとんどない。よくある反応と、僕がどう折り合ったかを書く。

• 「打ち合わせは減らせない」——いちばん多い。定例が組織の仕組みとして動いているところでは、まず動かない。だから僕は、出る代わりに議事メモを引き受ける。これで、僕がいちばん苦手な「口で決まって記録に残らない」状態が消える。会議の数ではなく、会議の後始末を取りに行く

• 「区切りごとのレビューは、こちらの手間が増える」——これも言われる。そこで、レビューの形を軽くする提案に変えた。会議は要らない。動くものを置いて、一行「ここまでで方向は合っていますか」と訊く。返事は「はい」か「違う」だけでいい。手間を、こちらが設計する

• 「返信が翌営業日だと、進行が止まる」——止まる箇所を特定してもらった。多くの場合、詰まるのは仕様の判断待ちだった。だから僕は、質問を投げるときに、必ず選択肢と推奨を付けることにした。「AかBか、僕はAを推します。理由はこれです」。これなら、相手は返事を一言で済ませられる。返信の速度ではなく、往復の回数を減らす

三つとも、条件を引っ込めていない。通らなかった条件を、別の形で無害化している。

これは第1話でも書いたが、あらためて言い方を変えておく。条件交渉は、全部通すゲームではない。通らなかった一つについて、「では、その条件が守られなかった場合に僕が落ちる理由は何か」を考える。そこを別の手で埋められるなら、条件そのものは譲れる。

会議の数が多いこと自体は、実はそれほど僕を削らない。削るのは、記録が残らないことだ。それが分かっていれば、譲る場所を間違えない。

断られた話

受け入れられなかった例も書く。

一度、条件を伝えた段階で、話が終わったことがある。返ってきたのは、こういう内容だった。チームは毎朝の朝会で動いている。そこに出られない人がいると、進行が組めない。申し訳ないが、今回は見送らせてほしい。

もう一つ、始まってから合わなかった例もある。文面は受け入れてもらえた。だが実際に始まると、日に何度も、口頭で相談したいという連絡が来た。相手に悪意はない。その会社では、それが親切な進め方だった。三ヶ月ほど続けて、僕は消耗した。赤信号が続けて出たので、更新の時期に自分から辞退した。

このときに学んだのは、文面が受け入れられることと、実際にその通りに運用されることは別だということだ。

そこで、一つ手を足した。始まって二週間ほど経ったところで、こちらから一度確認する。「この進め方で、そちらに不便が出ていませんか」。ここで違和感が出れば、まだ直せる。三ヶ月経つと、直すには重い。

ただ、断られること自体は、失敗ではなくなった。

朝会の会社は、僕には合わない。もし条件を隠して入り、三ヶ月後に潰れて抜けたら、先方はまた人を探し直すことになる。前に僕がいた現場で、フリーランスが何人も来ては辞めていったのと同じだ。

先に断られるのは、早いうちに分かったということだ。仕様書は、要求を押し通す武器ではなく、合う場所と合わない場所を早めに見分ける道具だった。

あなたの分を、書く

これは、僕の文面だ。そのまま使えるものではない。だから、枠だけ置いていく。

紙一枚に、四つ書く。

• お引き受けできないこと——能力ではなく、形態で書く。「常駐はできません」「電話での指示は受けられません」「その日ごとに時間が変わる働き方はできません」

• 返せる速度と、その約束——数字を入れる。「返信は当日中」「初稿は着手から五営業日」

• 代わりに出せるもの——相手が得るものを書く。品質、報告、記録、選択肢の提示

• 相手にお願いする一手間——できるだけ小さく。「至急と書く」「口頭で決まったら一行だけ残す」

書けたら、次はこれを、いちばん通りそうな相手一人に渡す。全員に配る必要はない。一人で試して、返ってきた反応で直す。

僕も、最初の文面は三行しかなかった。「常駐はできません」だけを、おそるおそる言ったところから始まっている。

謝らないことにした

仕様書を渡すとき、僕はもう謝らないことにしている。

取扱説明書は、謝らない。ただ事実を淡々と書くだけだ。この条件で使えば動く、この条件では動かない、と。「大変申し訳ありませんが、この冷蔵庫は直射日光の下では正常に動きません」——そんな書き方はしない。

僕も、それでいくことにした。「こんなダメな人間ですみません」ではなく、「僕は、こういう条件なら力を出せます」と。

同じことを言っているようで、まるで違う。前者は、自分を責めている。後者は、ただ仕様を伝えている。

自分を責めるのをやめ、観測し、自分に合わせて運用を組み、そして最後に、その仕様を隠さずに外へ差し出す。ここまでが、僕という一台の運用のやり方だ。

ただ——最後に、一つだけ引っかかることがある。

僕が同じ仕様書を差し出しても、笑って受け取ってくれる相手もいれば、眉をひそめる相手もいる。同じ僕なのに、ある場所では戦力になり、別の場所では厄介者になる。

この違いは、いったいどこから来るのだろう。

【「自分サーバー」運用術｜全5話】
① 難しい仕事はできるのに、簡単なことで壊れる理由
② 僕は壊れているのではなく、そういう仕様の一台だった
③ 世間の正しいやり方が、僕には毒だった
④ 僕が作っていたのは、ライフハックではなく取扱説明書だった（この記事）
⑤ 「使えない人」ではなく、置き場所が違っていただけだった

▶ 次は→ 〈自分サーバー運用術（5） 「使えない人」ではなく、置き場所が違っていただけだった〉