作った人と連絡が取れない業務アプリの保守をどうするか

二年前に作ってもらった受注管理のアプリが、今日も問題なく動いている。ところが少し直したいことができて、当時のメールアドレスに送ってみたら返ってこない。名刺の電話番号は使われていない。アプリのほうは、今朝も普通に開いた。

困るのはこの時点ではない。困るのは、何かを変えたくなった日だ。新しく入った人のアカウントを足したい。項目を一つ増やしたい。サーバーの契約更新の通知が、辞めた人のアドレスに届いていたと分かる。動いているうちは、誰も気づかない。

連絡が取れなくなった相手を責めても状況は戻らないので、別の話をしたい。その後も手が出せる状態と、何もできない状態を分けているのは、腕でも人柄でもなく、頼んだときに何を決めておいたかであることがほとんどだ。

「保守」と呼ばれているものは、四つある

引き継ぎの話がややこしくなるのは、保守という一語に性質の違うものが押し込まれているからだ。契約に「保守 月額◯◯円」と一行あるだけの状態で、では何を頼めるのですかと聞かれると、払っている側も受けている側も答えられない。

分けると四つになる。決めた通りに動いていないものを直す不具合直し。動いてはいるが変えたくなった分の作り替え。アプリが乗っているサーバーの契約と支払いという置き場所の面倒。そして、使い方が分からない人に答える質問の受け答え。

この四つは、頼む相手も、お金のかかり方も、急ぐ度合いも違う。まとめて一つの契約に入れると、どれか一つが理由で四つとも止まる。連絡が取れなくなった途端に何もできなくなるのは、たいていこれが効いている。

頼む先も、お金の形も、四つとも違う

不具合直しは、作った本人がいちばん速い。中の構造を知っているからだ。ただしこれは期間で区切れる性質のもので、渡してから14日、30日といった形にしておけば、そこから先は自然に手が離れる。当方も、お渡しした後の14日と決めている。

作り替えは、作った人でなくてもよい。ソースコードが手元にあって、素直な作りになっていれば別の技術者に頼める。必要が出たときに都度見積もれば済むので、月額で押さえておく理由もない。むしろ、変えたいことが出てから相見積りを取ったほうが、金額の見当もつきやすい。

置き場所は、そもそも自分で持てる。契約の名義を依頼者側にしておけば、開発者と連絡が取れなくなってもアプリは止まらない。逆にここが相手の名義だと、その人の支払いが止まった日に、こちらのアプリも一緒に止まる。

質問の受け答えは、実のところ作った人でなくても足りることが多い。半年も使えば、社内でいちばん詳しいのは開発者ではなく毎日触っている人になる。ここを外に頼み続けているなら、払っている月額の大半はそれかもしれません。

手順書は「困ったときにやること」から書く

引き継ぎ用にと渡される手順書は、たいてい正常な流れから書かれている。ログインする、一覧を開く、新規登録を押す。順番に並んでいて、丁寧で、そしてほとんど読まれない。画面を見れば分かることが書いてあるからだ。

読まれるのは詰まったときだけだ。だから書く順番を逆にする。開かないときは何をするか。入れなくなったら誰に言うか。消してしまったものはどこから戻すか。止まるのは正常な流れではなく例外のほうで、手順書が要るのもそちら側である。

やっかいなのは、例外の側は書いた本人も一度も試さないまま書かれがちなことだ。戻す手順は、実際に一度戻してみるまで手順とは言えない。試した日付を横に書いておくと、次に読む人がどこまで信じてよいか分かります。書いた日ではなく、試した日のほうを残してください。

止まったとき手が出せるかは、契約の一覧で決まる

アプリが動くには、たいてい二つか三つの契約がぶら下がっている。置き場所のサービス、ドメイン、メールの送信。金額としては無料の範囲に収まっていることさえあるのに、そのどれがどこで契約されているのか分からないと、止まったときに打つ手がない。

よくあるのは、支払いに使っていたカードの期限が切れて、その通知は辞めた人のアドレスに届いていて、ある朝アプリが開かない、という止まり方だ。原因が技術の側にないので、直せる人を探しても解決しない。必要なのは、どこに何を払っていたかを知っている人のほうだ。

だから一覧を1枚だけ作っておく。サービス名、契約の名義、入れる人、支払い方法と期限、更新の月。書き残されていないものは、後から誰も確かめられない。契約は名義の本人しか手続きできないので、そこが空欄だと、やめることすらできなくなる。

一人しか触れない状態は、道具の選び方で減らせる

引き継げるかどうかは、ソースコードを受け取ったかどうかだけでは決まらない。受け取ったものを、次に来た人が無理なく読めるかどうかで決まる。同じ一式でも、見た瞬間に構造が分かるものと、解読から始まるものでは、その先にかかる費用が変わってくる。

次に触る人が読めない作りは、ソースを渡してあっても、渡していないのとあまり変わらない。

ここで効くのは、珍しい道具を使わないことだ。広く使われている言語と枠組み、ありふれた画面の作り、よくあるデータベース。これなら別の技術者に見せたときに「ああ、これですね」で話が終わる。探せば読める人がいる、という状態そのものが引き継ぎやすさになる。

逆に、作者が自分で用意した仕組みや、その人だけが使っている構成でできていると、読み解くところから料金が発生する。作った本人には速いやり方でも、引き継ぐ側の費用に化ける。頼むときに「何で作りますか」と一度だけ聞いておくとよい。聞いたことのない名前ばかりなら、そこは理由を尋ねてよいところです。

質問を受ける先と、直す先は分けてよい

最後は運用の形の話をしたい。連絡先が一つで済むほうが楽なので、窓口はまとめたくなる。ただ、まとめてよいのは連絡先までであって、契約まで一本にする必要はない。誰に聞くかと、誰が直すかは、切り離しておけます。

使い方の質問は社内で受ける。作り替えは必要が出たときに都度頼む。置き場所は自分の名義で持つ。不具合直しだけ、渡してから一定の期間を開発者に持ってもらう。こう分けておけば、誰か一人と連絡が取れなくなっても、止まるのは四つのうち一つで済む。

月額でまとめて預ける形が悪いわけではない。相手を替えられない一つの契約に、四つとも入れてしまう形が危ないだけだ。契約を結ぶ前に、この四つのうちどれが入っていて、どれが入っていないのかを聞いてみてください。そこを答えられる相手なら、引き継ぎのときも困らないはずです。

---

当方は元金融系のシステムエンジニアで、Excel・紙で回している業務を月額0円の買い切りWebアプリにする仕事をしている。サーバーは依頼者さま名義でご契約いただき、ソースコードは一式お渡しするので、後から別の技術者へ引き継ぐこともできます。今あるものをこの先どうするか決めかねている段階でも構いませんので、ココナラのメッセージからご相談ください。