システム開発が思うように進まなかった経験から考えたこと｜信頼を守るために必要だったこと

以前、他社が開発したシステムを引き継ぎ、改修に取り組んだことがありました。

当初は、既存システムをベースに必要な部分を改修していく想定でした。

ところが、中身を詳しく確認していくと、思っていた以上に複雑な状態になっていました。

データ構造が複雑だったことに加えて、顧客ごとに仕様や設計がかなり異なっていたのです。

いわゆる「共通のシステムに一部カスタマイズを加えている」という状態ではなく、顧客ごとにそれぞれ別のシステムを作っていることに近い状態でした。

そのため、すべてを一つの仕組みにまとめながら改修することが難しくなりました。

最終的には、既存の仕組みを直し続けるより、新しいシステムとして設計し直した方がよいと判断しました。

ただ、その判断をしたからといって、すぐに問題が解決したわけではありません。

開発には遅れも生じました。

顧客との信頼や信用についても、改めて考えることになりました。

この経験は、システム開発そのものだけではなく、新しいことへ取り組むときの考え方についても、大きな学びになっています。

「改修」のつもりが、新規開発に近かった

既存システムを引き継ぐ場合、どうしても「今あるものを改善する」という前提で考えます。

しかし、実際に内部を確認してみると、その前提自体が違っていることがあります。

このときも、顧客ごとにデータの持ち方や仕様が大きく異なっていました。

本来、共通となるベースシステムがあり、そこへ必要に応じた機能を追加しているのであれば、カスタマイズとして整理できます。

ところが、根本となるデータ設計まで顧客ごとに違えば、一つの変更がどこまで影響するのかを判断することも難しくなります。

そのまま改修を続ければ、さらに複雑になる可能性もありました。

そこで、

「今あるシステムをどう直すか」

ではなく、

「この事業に本来必要なシステムとは何か」

から考え直すことにしました。

聞いていた内容と実態が違う可能性まで考えるべきだった

振り返ってみると、反省していることもあります。

引継ぎ前に把握していた内容と、実際に中身を確認して分かったことには違いがありました。

もちろん、既存システムの内部構造を事前にすべて把握することは簡単ではありません。

それでも、

「引き継いでから詳しく確認すればよい」

という考え方だけでは不十分だったと思っています。

既存システムの構造はどうなっているのか。

顧客ごとの差分はどこまであるのか。

共通化されている部分はどこなのか。

変更した場合、どこまで影響するのか。

そして、分からないのであれば、「まだ分からない」ということ自体を関係者で共有しておく必要があります。

分からないことをゼロにするのではなく、分からない部分がどこにあるのかを把握すること。

これは、既存システムを引き継ぐうえで非常に重要だったと感じています。

システムではなく、業界と業務から考え直した

新しいシステムとして設計し直すことを決めた後は、単純に既存機能を新しい環境へ移植するのではなく、業界や業務フローそのものから見直しました。

同じものをきれいに作り直しただけでは、同じ問題をもう一度作る可能性があったからです。

複数の顧客や関係者にも話を聞きました。

実際にはどのような業務をしているのか。

会社によって異なる部分はどこなのか。

反対に、共通化できる業務は何なのか。

システムの機能から考えるのではなく、まず実際の仕事を整理しました。

競合サービスについても調べました。

その中で分かったのは、特定の業務やタスクだけに絞って提供しているサービスも多いということでした。

機能を限定すれば、システムはシンプルになります。

価格も抑えやすくなります。

一方で、複数の業務を一つにまとめようとすると、設計は複雑になります。

そこで、

「誰のためのシステムなのか」

「何を一つにまとめるのか」

「そのシステムを使うことで仕事がどう変わるのか」

というコンセプトとターゲットも、改めて整理することになりました。

後からマーケットに合わせるのは難しい

この経験から強く感じたのが、システムを作り始めた後に市場へ合わせていく難しさです。

本来であれば、

市場を調べる
↓
顧客の課題を確認する
↓
ターゲットを決める
↓
コンセプトをつくる
↓
必要なシステムを設計する

という順番で進められると、比較的整理しやすくなります。

しかし、既存システムや顧客を引き継ぐ場合、必ずしもこの順番にはなりません。

既存顧客への対応を考えながら、今あるシステムを調べ、市場や競合を確認し、新しい仕組みを設計することになります。

つまり、走りながら方向を整えるような状態になります。

すでに顧客がいることは大きな強みです。

一方で、すでに提供しているものや、それまでの運用も存在します。

ゼロから新しいサービスを作る場合とは違う難しさがあることを、この経験から学びました。

正しい方向へ修正していても、相手から見えるのは結果

システムを作り直す。

業務フローを調べる。

関係者へヒアリングする。

競合を調査する。

コンセプトを整理する。

一つひとつを見れば、必要なことだったと思っています。

しかし、その結果として開発が遅れてしまえば、顧客から見える景色は違います。

開発側としては、

「より良くするために見直している」

という事情があります。

一方、顧客からすれば、

「予定していたものがまだ使えない」

という事実があります。

どちらか一方だけが正しいという話ではありません。

だからこそ、プロジェクトの途中で想定が変わったときには、その状況をどこまで共有できるかが重要になります。

この経験を通じて、技術的に正しい判断だけでは、信頼を守れないこともあると感じました。

信頼を守るには、問題が起きたときの共有まで考えておく

もちろん、問題を起こさないことが一番です。

しかし、新しい事業やシステム開発では、事前にすべてを把握できないこともあります。

だからこそ、

現在何が分かっているのか。

何がまだ分かっていないのか。

どこにリスクがあるのか。

当初の想定から何が変わったのか。

次に何を確認するのか。

こうした情報を関係者と共有しておくことが重要です。

良い話だけを共有していると、問題が起きたときに初めて大きな認識差が表面化します。

反対に、リスクや不確定な部分についても普段から共有できていれば、何かあったときに一緒に判断しやすくなります。

この経験以降、私は、

「失敗しないための情報共有」だけでなく、「失敗したときにカバーできるだけの情報共有」も必要なのではないか

と考えるようになりました。

そして、そうしたコミュニケーションに付き合ってくれる取引先や開発会社を選ぶことも大切だと思います。

「ニーズがある」からといって、うまくいくとは限らない

新しい商品やサービスを考えていると、

「お客様が欲しいと言っている」

「すでに利用者がいる」

「こういう機能が必要だと言われている」

という話が出てきます。

当然、何もニーズがない状態よりは良いスタートです。

ただ、この経験から、ニーズがあることと、事業として成立することは別だと改めて感じました。

技術的に実現できるか。

どこまで共通化するのか。

どこから個別対応するのか。

いくらで提供するのか。

継続して運用できるのか。

競合と比較されたときに何が違うのか。

こうした条件が重なって、初めて事業として形になっていきます。

新しいことへ取り組むと、当初の想定より大変になることは珍しくありません。

そのため、成功することだけを前提にするのではなく、

「思ったようにいかなかった場合、何を会社に残すのか」

まで考えておくことも重要だと思っています。

作ったものを売ることだけが、成果とは限らない

システムを開発したのであれば、それが売れ、利益につながることが一番分かりやすい成果です。

ただ、新しい取り組みの成果は、それだけではありません。

例えば、この経験では、

業界について調べる。

顧客や関係者へヒアリングする。

業務フローを整理する。

データ構造を考える。

競合サービスを調査する。

ターゲットやコンセプトを考える。

といったことにも取り組みました。

その過程で、

「この機能は共通化しにくい」

「この業務は企業ごとの差が大きい」

「反対に、この部分は共通化できる」

といったことも見えてきます。

こうした情報は、その後の事業判断にも使えます。

新しい取り組みには失敗する可能性があります。

それでも、そこに使った時間や費用をすべて「損だった」で終わらせるのではなく、そこで得た知識や情報をどう次へつなげるか。

そこまで含めて、事業として考える必要があるのだと思います。

AIで作りやすくなった今だからこそ、仕事の原点へ戻る

現在はAIの進化によって、以前よりもシステム開発へ取り組みやすくなっています。

簡単な業務ツールであれば、短期間で試作できるケースも増えています。

だからこそ、

「作れるから作る」

にならないように注意する必要があります。

誰が使うのか。

何を解決するのか。

どこまでを共通機能にするのか。

どこからカスタマイズするのか。

何を提供しないのか。

こうしたことは、開発技術が進歩しても考え続ける必要があります。

むしろ、作ること自体が簡単になった今だからこそ、

「そもそも何のために作るのか」

という仕事の原点へ戻ることが、以前より大切になっているのかもしれません。

システム開発を始める前に確認しておきたいこと

この経験を振り返ると、特に既存システムの改修や他社からの引継ぎでは、次のような点を確認しておく必要があると考えています。

• 現在のシステムに共通となるデータ設計や基本機能があるか
• 顧客ごとの個別仕様が、どこまで存在しているか
• 分かっていることだけでなく「まだ分からないこと」を共有できているか
• システムを作る目的、ターゲット、提供する価値が整理されているか
• 想定どおり進まなかった場合の情報共有や判断方法まで話せているか

すべてを完璧に把握してから始めることは難しいと思います。

ただ、

「分からないことに気付いていない状態」

と、

「ここはまだ分からないと認識している状態」

では、大きな違いがあります。

まとめ｜うまくいかなかった経験を、次の判断材料にする

システム開発に限らず、新しいことへ取り組めば、思ったようにいかないことはあります。

実際、私たちも既存システムの引継ぎで、当初の想定とは違う状況に直面したことがありました。

もっと慎重に確認するべきだった。

もっと早く情報を共有できたかもしれない。

振り返れば、そう思う部分もあります。

一方で、その経験があったからこそ、

業務を先に整理すること。

コンセプトを明確にすること。

分からないことも共有すること。

失敗した場合に何を残すかまで考えること。

こうした考え方を、以前より重視するようになりました。

新しい取り組みで大切なのは、失敗しないことだけではありません。

想定と違ったときに、どのように向き合うのか。

そこで得たものを、どのように次へつなげるのか。

そして、関係者との信頼をどう積み重ね直していくのか。

システム開発の経験を振り返ると、技術以上に、こうした部分が事業を続けるうえでは重要なのだと感じています。