フリーランス体制で止まったアプリ開発を引き継いだ導入事例
他社が作ったアプリのコードを流用して作られ、仕様書も残っていないスマートフォンアプリの開発・保守を引き継いだ導入事例です。作り直さず、まず保守できる状態にしてから月額制で改善を進めました。
- CLIENT
- 一般消費者向けのスマートフォンアプリを
複数提供している企業 - SCOPE
- 開発途中のアプリの
開発・保守の引き継ぎ - CONTRACT
- 月額制
（引継ぎ費用の一括払いなし）
どんなシステムだったか
最初のアプリは、開発会社に依頼して作られていました。問題はその後です。増えたアプリは、最初のアプリのコードをコピーして流用する形で作られていました。
アプリとWebでリポジトリが分かれた構成で、本番環境と検証環境をクラウド上で運用されていました。仕様書は残っていません。
STRUCTURE
コピーして作られたアプリは、誰の担当でもなくなる
ご相談の内容
「個人に発注するのではなく、体制を組める会社と組みたい」
今いるフリーランスの方を全員切りたいという話ではなく、必要に応じて残せる形を探されていました。求められていたのは人ではなく、引き継いだ後も続く体制です。
引き受ける前に読んだ
引き受けられるかどうかを、中を見ないまま回答することはしていません。この順番で進めました。
- 秘密保持契約を締結する
- ソースコードの閲覧権限をいただく
- 開発チームで実際にコードを読み、保守する上での問題点を洗い出す
- 洗い出した内容をそのままお伝えし、引き受けられる範囲と条件を示す
読んで分かったこと
- サポートが終了したバージョンで動いていたRubyで書かれたシステムで、言語もフレームワークも、すでにサポートが終了したバージョンのままでした。
- データベースの構造に手当てが必要だったそのまま機能を足していくと、後で作り直す範囲が広がる箇所がありました。
- アプリ経由でしか使えない想定の画面に、直接たどり着けた仕様ではなく作りの問題です。引き継ぐ前に読んでいなければ、引き継いだ後に気づくことになります。
引き継ぎの進め方
作り直しを先に決めず、まず引き継いで保守できる状態にすることを選びました。
ドキュメントが残っていないので、引き継ぐ側で作りました。リポジトリの構成、本番と検証の環境、データベースへの接続方法、設定値の置き場所、性能を確認するための道具——どこに何があるのかを一覧にまとめるところから始めています。
これは事務作業ではありません。仕様書が残っていないシステムを引き継げるかどうかは、コードを読める人がいるかどうかだけでは決まりません。読んだ結果をチームで共有できる形に残すかどうかで決まります。
対応範囲も引き受ける前に確認しました。スマートフォンアプリを含む構成のため、どこまでをアクシアが持ち、どこからをお客様側で持つかの線を先に引いています。月額の稼働は案件ごとに記録し、何にどれだけ使ったかを追える状態で進行しました。
費用の考え方
止まっている開発を動かすときの選択肢は、大きく2つあります。
動いているものを止めずに作り直す分の費用が乗ります。加えて、作り直している期間中、今出ている不具合を見る人がいなくなります。
まず保守できる状態にしてから、改善に予算を寄せていけます。先に大きな一括額を決める必要がありません。
作り直しが適切な場合もあります。ただしその判断は、中を読んだ後にしかできません。本件では読んだうえで、引き継ぐ方を選んでいます。
引き継ぎの後
- 仕様書がなく、社内の誰も全体を把握していない→コードを解析し、保守できる状態にした
- フリーランスを複数人集めて個別に対応→会社として引き受ける体制に切り替えた
- サポートが終了したバージョンで動いていることに気づいていない→引き受ける前の調査でリスクを可視化した
OTHER CASES
