作ったあとのことを、考えたことがあるか
独立を考えてるエンジニアなら、こういう場面を想像したことがあると思う。
クライアントに「これ、ちょっと動きがおかしいんですけど」って連絡が来る。
夜に。
週末に。
あるいは、リリース直後の月曜の朝に。
対応する。
直す。
「助かりました」って言われる。
それはいい。
でも翌週、また違う件で連絡が来る。
正直に言うと、フリーランスで「何でも対応します」をやると、
「保守」という名前の、終わりのない作業に飲み込まれていく。
作ったものを守ることと、もっと良くすることが、
ごちゃまぜになったまま走り続ける感じ。
Miyaviは、ここを分けて考えている。
「修復」と「改善」は、なぜ別物なのか
シンプルに言う。
修復は「壊れたものを、動く状態に戻すこと」。
改善は「動いてるものを、もっと良くすること」。
この2つは、目的が違う。
優先度が違う。
対応スピードも、かける時間の感覚も、違う。
なのに「保守」という一言でまとめると、
どちらも同じ温度で対応しなきゃいけない気がしてくる。
エラーが出て止まってる。→ 今すぐ直さなきゃ。
「もう少し使いやすくできますか」。→ それは検討できる。
両方を「保守」として受け取ると、
緊急と要望が同じ窓口に来て、気づいたら全部が「優先」になる。
わかります。
技術があっても、この整理ができてないせいで消耗するエンジニアを、
僕はたくさん見てきた。
Miyaviが保守をどう設計しているか
Miyaviでは、ツールを作るときから「直す」と「良くする」の窓口を、最初に分けて設計する。
たとえばこんな感じ。
修復（バグ対応・障害）
→ 動いてるものが動かなくなった、データがおかしい、エラーが出て止まってる。
→ 記録が残っているので、どこで何が起きたか追いやすい。
→ 万一おかしくなっても、元の状態に戻せる仕組みを持っている。
改善（機能追加・UX向上）
→ 「もっとこうしたい」「この作業、自動にできますか」。
→ ヒアリングを挟む。要望の背景を整理する。
→ 優先度を確認してから、動くものを作って見せる。
この2つを、最初から別の流れとして設計しておくと、
何かあったときに落ち着いて対処できる。
「これは修復。これは改善の話。」
それだけで、対応の速さも、伝え方も、変わる。
エンジニアが独立を怖いと思う理由のひとつ、ここじゃないか
技術力があっても、独立が怖いのは、
「作ったあとのことが見えない」からだと思う。
何かトラブルがあったとき、一人で抱えられるか。
クライアントの「ちょっと直して」に、いつまで応え続けるのか。
正直、僕もそこが一番不安な場所だと思っている。
でも、設計の段階で「修復」と「改善」を分けておくと、
トラブルが来ても、要望が来ても、
「どっちの話か」が最初に整理できる。
それが、一人でもクライアントに誠実に向き合える土台になる。
Miyaviでは、こういう設計の考え方ごと、最初のヒアリングで確認している。
面談の録画を入れるだけで、仕様書の下書きが9割くらいできることが多い。
何を作るかだけじゃなく、「作ったあとをどうするか」まで、最初に話し合う。
よくある質問
Q. 保守の設計って、作り終わってからでも考えられますか？
できないことはないけど、後から分けるのは正直、手間がかかる。
最初から「修復はこのルートで、改善はこのルートで」と決めておく方が、クライアントにも説明しやすいし、自分も楽になる。
Miyaviではツールの設計段階で、この話も一緒に整理できる。
Q. 自分はコードが書けるので、Miyaviは関係ない気がします。
作る力はある。でも、クライアントへの提案の仕方、保守の切り分け方、売る仕組みの整え方は別の話。
Miyaviは「作れないから」だけじゃなく、「作れるけど、それ以外が不安」な人にも使える仕組みを持っている。
最後に
「直す」と「良くする」は、別の話。
それを最初から設計に組み込んでおくだけで、
独立後の不安が、少し軽くなると思う。
Miyaviは、そういうことを一緒に考えながら形にしていく仕組み。
気になったこと、疑問に思ったことがあれば、
お気軽にコメントやLINEで聞いてみてください。
難しく考えなくて大丈夫。
コメント