目次
システムの保守を他社に引き継ぐとき、最初に詰まるのは技術の話ではありません。「どこまで見せるのか」です。相談までは進むのに、見積の段になると社内で止まってしまう。最近も、続けてそういうことがありました。理由を伺うと、だいたい同じです。本番を触られたら困る。自社のソースコードを丸ごと外に出していいのか。一度渡したら、あとで取り消せるのか。もっともな警戒だと思います。先に結論をお伝えすると、見積と最初の診断は、多くの場合「見えるだけ」の権限で足ります。そして渡した権限は、後から消せます。この記事では、段階ごとに何を渡すことになるのかをお話しします。
止まるのは、技術の話ではないところ
保守の引き継ぎ（保守移管）のご相談は、最初の何回かは話が進みます。困っていること、いま起きている不具合、現在の保守会社との関係。ここまでは会話だけで進みます。
止まるのは、そのあとです。「では、ソースコードとサーバーの中を拝見させてください」とお願いした瞬間に、社内で確認が始まって、そこから返事が来なくなる。技術的に難しい話ではなく、どこまで見せていいのかを判断する材料がないために止まっています。
判断できないのは当然です。「ソースコードを見せてください」「サーバーに入れるようにしてください」という依頼は、受け取る側からすると会社の資産を丸ごと明け渡す依頼のように見えるからです。実際に必要なのはもっと狭い範囲なのですが、依頼の言葉だけではその狭さが伝わりません。
見せることと、明け渡すことは違う
渡すものは、段階ごとに変わります。最初から全部を渡す必要はありません。
ご相談の段階では、渡していただくものはありません。困っていることと、実際に動いている画面を見せていただければ、引き継げそうかどうかの見当はつきます。
次の見積と診断の段階で、はじめて中を見せていただくことになります。ここが今回の本題です。この段階で必要なのは見るための権限だけで、作成・変更・削除の操作は必要ありません。私たちがお願いする権限にも、それらは含めません。
保守が始まってからは、作業に必要な範囲が加わります。ここで大事なのは権限の広さより本番に反映する手順です。誰が確認して、いつ反映するのか。それを先に決めておけば、権限を持っていること自体は怖いものではなくなります。
そして最後の段階です。保守が終わるとき、あるいは他社に移すときには、渡した権限を消していただきます。そのために、最初から消せる形で渡しておく——ここまで含めて引き継ぎだと考えています。
見積のために本当に見たいもの
まず見たいのはソースコードです。これが読めれば、何がどう作られているのか、保守にどれくらい手間がかかるのかの見当がつきます。仕様書がなくても構いません。私たちはAIを使ったソース解析で、言語を問わず構造を読み解くところから始めています（現行システムの仕様書がない場合）。
次にサーバーの構成と設定が分かると、見積の精度が上がります。どこで動いているのか、どんなサービスを使っているのか、外部と何がつながっているのか。ここが分からないままだと、金額に幅を持たせるしかなくなります。
加えてログや監視のデータが見られれば、実際にどんなエラーがどれくらい出ているのかが分かります。ここまで見えると、引き継いだ直後に何から手を付けるべきかまで判断できます。
逆に、データベースの中身を見せていただく必要はありません。顧客名簿や取引の記録といった実データは、見積のためには要りません。構造が分かれば足りるからです。ソースコード・構成・ログはシステムの「構造」の情報で、実データはそこに入っていません。この線引きは、私たちがAIを使うときの線引きとも同じです（開発を委託するとき、相手のAI利用はどこまで決めておくべきか）。
ソースコードの渡し方は2通り
実務でよく起きるのが、「送りたいがメールに添付できない」という詰まりです。渡し方は2つあります。
1つは、ソースコードの置き場所（GitHubなどのリポジトリ）に、読み取り専用で招待していただく形です。こちらのアカウントを1つ追加するだけで、書き込みはできません。終わるときは招待を外していただけば、それで終わりです。いちばん手数が少なく、後始末も簡単なので、可能ならこの形をお願いしています。
もう1つは、圧縮ファイルでお渡しいただく形です。リポジトリで管理していない場合や、社外のアカウントを追加できない規定がある場合はこちらになります。この場合はお渡しいただいたものが手元に残るので、預かったものをどう扱うかを先に決めておきます（後述します）。
サーバーの見せ方は、環境によって変わる
ここは、お使いの環境によって現実的にできることが変わります。以下はいちばん多いケースとしてAWSを想定した場合の話です。
クラウドであれば、閲覧だけができる利用者を作っていただく形が取れることが多いです。作成・変更・削除の権限を1つも含めない状態にできるので、見られる範囲は限定され、こちらから何かを壊すことは仕組みの上でできません。
さらに安全なのは、そもそも鍵をお渡しいただかない形です。御社のクラウド環境の側に、アクシアからだけ入れる入口を決めた範囲で用意していただく方法があり、この形なら認証情報そのものを預ける必要がありません。私たちはいちばん安全な方法から順にご提案します。ただし、環境や社内の事情によって実現できないこともあります。その場合は、実現できるやり方の中から選んでいきます。
一方で、一般的なレンタルサーバーや共有型のホスティングでは、権限をそこまで細かく分けられません。ログイン情報が1つしかなく、それを共有するしかないこともあります。この場合は「見るだけの権限」で守るという考え方が成立しないので、代わりに期間と後始末で守ります。何をする作業なのかを先に決め、その作業が終わったらお渡しいただいた情報を削除する。必要ならパスワードを変更していただく。権限で絞れないぶんを、範囲と時間で絞る形です。
渡す前に決めておくことが、2つあります
1つは契約です。私たちは、秘密保持契約を締結してから権限のお願いをする順番にしています。中を見せていただく前に、見たものをどう扱うかが決まっている状態にしておきたいからです。
もう1つは名義です。サーバーやドメインの契約が現在の開発会社の名義になっている場合、御社の側で権限を作ることそのものができません。これは珍しいことではなく、引き継ぎのご相談で実際によく出てきます。誰の名義で契約されているかを先に確認しておくと、後戻りが減ります（サーバーにアクセスする情報がない場合）。
預かった鍵は、消せる形にしておく
原則として、認証情報をお預かりしない方法からご提案します。それでも環境によっては、お預かりするしかないことがあります。その場合にお約束しているのは2つです。
- 御社の側でいつでも削除できる状態にしていただくこと。私たちの都合に関係なく、御社の判断で権限を切れる状態にしておきます
- 削除の操作が御社側でできない事情がある場合は、必要な対応が終わった時点で、アクシア側で預かった情報をすべて削除すること
診断のためにお預かりした情報は、診断が終われば不要になります。ご都合のよいタイミングで消していただいて構いません、とお伝えしています。
もう1つ補足します。私たちは解析にAIを使いますが、お預かりした認証情報や本番のデータをAIに入力することはしません。AIに読ませるのはソースコードや構成といった構造の情報までです。この線引きは別の記事に詳しく書いています。
「いまの会社に知られたくない」場合
乗り換えを検討している段階では、決まるまで現在の保守会社に知られたくない、というのが普通です。ところが権限の作り方によっては、設定を変えた通知が現在の会社に届いてしまうことがあります。私たちはそこを避けられる方法を選んでご案内しますので、秘密にしたまま検討したい旨は、遠慮なく先にお伝えください。この話は関わる論点が多いので、別の記事で改めて書きます。
まとめ
保守を他社に頼むときに何をどこまで見せるのか、お伝えしたかったことをまとめます。
- 相談の段階で渡すものはない。中を見せていただくのは見積と診断から
- その段階で必要なのは見るための権限だけ。作成・変更・削除は含めない
- 見たいのはソースコード・構成・ログ。データベースの中身は要らない
- ソースコードは読み取り専用の招待か、圧縮ファイルで。メールに添付できなくても方法はある
- サーバーは環境次第。閲覧だけの利用者を作れることが多いが、細かく分けられない環境では期間と後始末で守る
- 渡す前に契約と名義を先に。名義が現ベンダーだと権限を作れない
- 預けた鍵はいつでも消せる状態にする。消せない事情があるなら、終わった時点でこちらが消す
引き継ぎのために御社側で洗い出しておく情報（関係者・ドキュメント・定期作業など）は「システム引き継ぎの進め方──必要な情報チェックリストとベンダー乗り換えの注意点」にまとめています。また、解析の過程で私たちが作ったドキュメントは御社の資産としてお渡しします。他社に移すときに困らない状態を保っておくことも、引き継ぎの一部だと考えています。
「どこまで見せることになるのか分からないので、社内で話を進められない」——その状態でのご相談で構いません。御社の環境で何ができるのかを確認しながら、いちばん安全な形からご提案します。