【技術判断】保守できないコードは納品しない

引き継ぎを前提に僕が守っている5つの線

テストは通り、画面も動いている。
だから渡すボタンを押せば終わり——かつての僕は、そう思っていました。

けれど翌朝、引き継いだ相手の画面は起動の手前で止まります。
説明書が空で、設定の場所が口頭でしか伝わっておらず、反映の手順が僕の手元にしか無かったからです。

動いたという事実だけでは、まだ納品ではありませんでした。

動くものと、渡してよいものは別だった

みなさんは、動いている画面を渡した翌朝、相手からの「手元で起動できません」という連絡で1日が始まったことはありませんか？

僕には何度もあります。
しかも、他人に引き継いだ案件だけではありません。
数週間後に自分で保守へ戻ったときも、まったく同じ止まり方をしたのです。

受託開発では、納品した瞬間にコードが自分の手を離れます。
たとえ機能が一通り動いていても、次の人が触れない状態のまま渡せば、請求を終えたあとに質問や手直しとして自分の元へ戻ってきてしまいます。

この記事では、SEとして10年、フリーランスとして15年コードを渡してきたなかで決めた「越えたら渡さない5つの線」と、納品前にそのまま使っているチェックリストをまとめました。

動いていれば渡せると信じていた

かつての僕の納品は、いつも「自分のパソコンで動いた」がゴールでした。

納期が迫ってくると、まず削るのは説明や周辺の手順です。
「動くものを先に出そう。ドキュメントや整理は、落ち着いてからでいい」と自分に言い聞かせていました。
自分の手元では毎日動かしているので、どこに何があるかも、どの順番でコマンドを叩けばいいかも頭に入っています。
だから、何も書かずに渡しても相手も動かせるだろうと思い込んでいたのです。

ところが、引き継ぎの現場では毎回同じことが起きました。

渡した直後に「どのブランチを見ればいいですか？」「本番だけエラーが出るのですが、設定はどこにありますか？」と連絡が入ります。
納期に間に合わせて渡したはずなのに、翌週には別案件の作業を止めて、過去のチャットの履歴や自分の記憶を掘り返す時間が発生していました。

一番堪えたのは、数週間後に自分自身で保守へ戻ったときです。
急いで渡したリポジトリを開いた瞬間、どこから触ればいいのか分からず、自分の画面の前で手が止まりました。
納期を守るために後回しにしたツケは、消えることなく未来の自分に返ってきていたのです。

新しいリンターではなく、止まった朝を並べた

転機になったのは、新しい静的解析ツールやフレームワークを入れたときではありません。
引き継ぎや保守で「手が止まった朝」の原因を、1枚のノートに書き出して並べたときでした。

書き出してみると、止まった原因は高度なアルゴリズムや設計の難しさではありませんでした。

どれにも共通していたのは、「動いた」だけで「渡してよいか」を判定する線がなかったことです。
線がないと、納期のプレッシャーが来た瞬間に確認を飛ばしてしまいます。

個人開発なら、自分さえ分かれば問題ありません。
しかし、誰かに引き継ぐ受託のコードは別です。
そこから僕は、納品ボタンを押す前に必ず確認する基準を5つの線に絞り、1つでも欠けていたら渡さないと決めました。

保守できないコードは、納品ではありません。
引き継いだ人が最初に迎える朝こそが、納品物の本当の成績表だったのです。

守っている5つの線

ここからは、僕が納品前に必ず見ている5つの線を、失敗した具体例と現在の確認方法とあわせて紹介します。