オープン後に残る仕事、引き潮のあとの保守を考える

ハルスペースを作り始めたころは、やはりオープンする瞬間をよく思い浮かべていた。機能がきちんと動き、画面が考えていた姿に近づき、誰かが実際に訪れて使ってくれる瞬間だ。

ところが少しずつ形になってくると、オープンそのものより、そのあとのことを考える時間が増えた。作ることも難しいが、作ったものに責任を持ち続けることは、まったく別の難しさだからだ。

私はいくつもの役割でサービス公開の前後に関わり、似た光景を何度も見てきた。公開前は多くの人が同じ方向を見る。日程があり、解決すべき一覧があり、終えたときに一緒に喜ぶ理由もある。しかし公開を過ぎると空気が変わる。プロジェクトのために集まった人は次の仕事へ移り、契約を終える人もいて、判断をしていた人も別の責任を担う。

押し寄せていた水が引いたあとの海辺のように、残った場所には運用すべきシステムと、整理し切れなかった問いが姿を現す。そして、その前に少人数が残る。

オープン後に残った人の気持ち

誰かが離れることを悪いことだとは考えたくない。プロジェクトは、一定の期間だけ人の時間を集め、また別の場所へ送り出すことがある。問題は、人と一緒に文脈まで抜けていくときに起きる。

なぜこの機能が今の形になったのか、どの案を検討してやめたのか、不自然に見えるコードがどんな制約に耐えるため残っているのか。それを知る人が一人ずついなくなる。資料があっても、判断した当時の迷いまで書かれていることは多くない。

残った人が引き継ぐのはシステムだけではない。説明されていない選択と、これから起きることへの不安も一緒に受け取る。障害が起きたら誰が最初の連絡を受けるのか。急いだ修正が別の場所に影響しないか。今すぐ触れてよい部分と、慎重に待つべき部分はどこか。静かな日にも、そんな問いを頭の片隅に置くことになる。

その気持ちは、ときに荷物のように重い。きちんと守りたいという責任感と、なぜここまで自分一人が知っていなければならないのかという息苦しさが同時にやってくる。残る人数が少ないほど、個人の真面目さで耐えることが簡単に当然とされてしまう。

ハルスペースを作りながら、私はできるだけ同じ光景を繰り返したくないと思っている。今は小さなサービスでも、小さいからという理由で運用の負担を先送りしてしまえば、規模が大きくなった日に突然よい習慣が生まれるわけではない。

これから起きることは計画よりいつも多彩だ

サービスを公開すると、開発中には見えなかったことが起きる。利用者は私が想像した順序だけで動かず、端末とブラウザーの組み合わせは予想より多い。外部で頼っているサービスの状態も、こちらの予定どおりには動かない。

何でもない文言の修正が思わぬ画面を押し出すこともある。普段は静かな機能が、特定の条件だけで急に遅くなることもある。一つの問題を急いで抑えた結果、別の不便を作ることもある。私がいう「これからのスペクタクルな仕事」は、大事件だけを指しているのではない。小さな変数が同じ日にまとめて現れる普通の運用日も、十分にスペクタクルだ。

多くの人が利用する公共向けサービスなら、その重さはさらに大きい。担当者には短い遅延や一画面の不具合に見えても、誰かにとっては必要な申請や確認、生活の大切な手続きが止まったことになる。影響が広いほど小さな判断にも慎重さが必要になる一方、いつまでも判断を延ばすことはできない。

速く動かなければならないが、雑に動いてはいけない。この矛盾が保守を難しくする。

素早い対応は、最も速く走る一人から生まれない

問題が起きたとき、最も経験のある人が駆けつけ、すべてを理解して解決する姿は頼もしく見える。しかし、その一人がいないだけで対応速度が落ちるなら、それは速い仕組みというより、一人の犠牲を借りている仕組みに近い。

私が考える素早い対応は、普段からいくつかの問いに答えられる状態から始まる。

• サービスが普段と違うことに気づけるか
• どの問題を先に扱うか、共通の判断基準があるか
• 変更の範囲を小さくし、必要なら戻せるか
• 誰が判断し、誰が状況を共有するか分かるか
• 解決後に原因と判断を次の人も探せる形で残すか

これは特定の道具を一つ導入すれば完成するものではない。観測できる状態、小さな変更、戻せる選択、短く正確な共有、日頃の確認が互いを支える必要がある。

何より、実際に問題が起きた日が、対応手順を初めて試す日になってはいけない。頻繁には使わない流れも、ときどき確かめる。担当が変わっても同じ道をたどれるかを見る。速い対応は瞬発力だけではなく、普段から迷いを減らしてきた結果だと思う。

もちろん、ハルスペースの具体的な運用方法や保護に必要な内容を、そのまま公開記録へ移すことはできない。ただ、個人情報を露出せずに状態を理解できること、変更の範囲を管理できること、問題があれば安全に止めたり戻したりできること。この原則は最初から手放したくない。

引き継ぎ資料は必要だが、それだけでは足りない

引き継ぎを準備するとき、最初に思い浮かぶのは文書だ。文書は必ず必要だ。問題は、数冊の資料で誰かが数か月、数年かけて積み上げた判断をすべて移せると期待することにある。

引き継ぎ資料は、書いた日のシステムを撮った写真に近い。サービスは翌日にも変わる。書いたときには当たり前すぎた前提が、あとでは最も見つけにくい情報になる。何を作ったかは書かれていても、なぜそうしたのか、何をしないと決めたのか、失敗したときにどこから疑ったのかは抜けやすい。

受け取る側も、短い期間ですべての質問を思いつけるわけではない。実際に運用し、最初の問題に出会ってから初めて、理解できていない部分が見える。そのときには答えを知る人がすでに別の仕事へ遠ざかっていることもある。

だから私は、引き継ぎを最後に一度だけ行う行事ではなく、サービスのあいだ中ずっと更新する仕事として考えたい。

判断の理由を短く残す。繰り返し起きた問題と確認の順序を探せるようにする。失敗した試みも物語から消さない。新しい人が実際に資料どおり進めて空白を見つける。一人だけが知る領域を一緒に見る機会を作り、文書が今の状態とずれていないか定期的に確かめる。

よい引き継ぎはページ数ではなく、次の人が一人で推測する時間をどれだけ減らせるかで決まると思う。

維持できる大きさで作る

機能を追加するときには、それによって何が可能になるかが先に見える。運用するときには、その機能が増やす状態と依存関係が見える。だからこれからは、機能の価値と同時に、誰がどのように維持するかも尋ねたい。

今は魅力的に見えても、説明できず、戻すことも難しいなら一度立ち止まる。使われない機能は思い切って減らし、同じことをする流れはできるだけまとめる。新しい技術を選ぶときには、作る楽しさだけでなく、数年後にも理解できるかを見たい。

これは変化を避けるという意味ではない。変わり続けるために、抱えられる複雑さを守るという意味に近い。

ハルスペースには、これから作りたいものがたくさんある。その数だけ予想外の問題もついてくるだろう。すべてを先に当てることはできない。それでも、問題のたびに少人数の記憶と体力だけを燃やさない方向は、今から選べる。

残る人に荷物だけを渡さないために

オープンは拍手を受けやすく、保守は目立ちにくい。何も起きなかった一日が誰かの丁寧な確認のおかげだったとしても、その仕事は簡単に通り過ぎてしまう。

私はハルスペースを作りながら、新しい機能の紹介だけを記録したくない。運用で迷った判断、予想と違った部分、引き継ぎから抜けていた質問、負担を減らすために削った機能も一緒に残したい。

記録ですべての負担をなくすことはできない。それでも、次の人が最初から推測だけで始めることを防ぎ、残った人が一人で全体を抱える時間を短くすることはできる。

いつかハルスペースにも人が訪れ、そして離れるだろう。そのとき、引き潮のあとに立つ人が、空いた席と説明のないシステムだけを荷物のように眺めないでほしい。前の人が残した理由を読み、今の判断を加え、少し軽い状態で次へ渡せる場所であってほしい。

サービスを長く守る力は、完璧な一人より、責任と文脈を分けられる仕組みから生まれると私は信じている。オープンを準備する今から保守を一緒に考えたい理由も、そこにある。