既存システムのリニューアルにおける開発のコツを教えてください

Question

はじめに

　既存システムを仕様などはほぼ同じで別言語・別フレームワークでリニューアルすることになりました。
開発のコツや、うまく行った事例、手法があれば教えていただきたいです。
よろしくお願いいたします。

概要

　画面のデザインは一新する予定で（CRUDなどはほぼ一緒です）、仕様などは既存システムに合わせる方針です。
仕様書などは無く、既存システムの動作を見て真似をする形で開発しています。

　モデルなどはフレームワークが吸収してくれているので問題ないのですが、ビジネスロジックの部分の関数やクラスが大量に存在し、これの移植の難易度が高い状況です。

　以下の 1, 2 の方法が案として出ています。

1. 既存システムのコードを流用し、PHP -> Ruby のコードの変換作業を行い、動くようにする
2. 既存システムのコードと動作を見て、既存コードを無視し新規にRubyでコードを書いて動くようにする

　既存システムのコードをそのまま動くように移植する 1 では PHP -> Ruby への変換作業が必要になりますが、この変換作業はあまり捗っていません。というのも変換作業に時間がかかり、効率的な作業が出来ていません。また、PHPで用意されている関数やクラスもRuby側で用意しなければならず、この作業も効率的とは今のところ思えません。もちろん Ruby にも類似の関数などはあるので、それで代用は可能ですが、まったく同じではないので吸収する必要があります。

　既存システムの動作を見て、既存システムのコードを無視してRubyで新規にコードを書くという 2 の作業も、既存システムの仕様が不明なところが多いため、開発の難易度が高い状況です。よって、既存システムの仕様をなぞれる前述の 1 の方法に開発方針が傾いていますが、前述の通り 1 の方法もあまり効率的ではありません。

1, 2 の方法であればどちらが有望そうでしょうか？また、それ以外の 3 の方法があればご教授頂きたい所存です。
現在は 1, 2 をミックスして進行していますが、どちらも難易度が高いように思えます。

新旧システムの概観

　以下がプロジェクトの概観です。

既存システム

• 言語: PHP
• バックエンド: CakePHP
• フロントエンド: jQuery

新システム

• 言語: Ruby
• バックエンド: Rails
• フロントエンド: React

Answer 1

１と２何れについても、俯瞰可能な資料をどうするかだと思います。
全体が見えないのに、各々が個別に行ってすんなり終着するとは思えません。

仮に仕様書があったなら、どうされますか？
先ずは、完全でなくとも設計書を作って、常にブラッシュアップを行い、それを拠り所としないと、手戻りが多く発生しそうです。

細かいレベルの設計書ではなく、メンバー間で認識の統一が図れるレベルである方が望ましいと思います。

---

どのような開発であっても、開発に於ける工程について、結果的に作業量が少なかったという事はあっても、無条件に省略してしまうと、上手く行きません。
システムのリプレースの場合は、各工程のインプットとして既存システムの資源/仕様などが含まれると考えるべきです。

もうスタートしているとの事なので、そこそこの人数の要員がアサインされているのでしょうか？

要件定義などはプロジェクトの総工数に対しては、比較的小さな工数（経験豊富な少人数）で行う方が効率が良いものです。
溢れるメンバーがいるようなら、（要件定義へインプットする）既存システムの解析資料の作成に充てるようにしてはどうでしょうか。

Comments

[退会済みユーザー]

アサインは結構な人数がされています。資料作成を並行して行う案はいいですね。参考にさせていただきます。

Answer 2

自分がやるとしたら、1も2も選べる状態では無いと判断し、

• 現在の要件/外部仕様を明確にするor現在の業務を元に新要件/仕様を作成するというプロジェクトを立ち上げて最終的な仕様を明確にしてから1か2を選択する。

(プロジェクト完了要件としてふるまいを客観的に確認出来るテストケースか外部テスト仕様書の作成を必須として「なんとなくわかった気がする」を防ぐ)

か

• 現在の業務/システムを分割して、可能なところから要件を整理して、現行業務を邪魔しない新仕様でリニューアルしていく（ユーザー部門を巻き込んでの進行が可能な権限/体制がある場合のみ）

のどちらかでしょうか。

すでに1と2をミックスして進行されているということですが、一旦全開発リソースを現システムの要件と仕様の明確化に振りなおすくらいの事をしないことには懸念されてる通りの理由で皆が不幸になると思います。

（**現物があるからそのままリニューアルすればいいでしょ！**みたいなノリでリニューアルして成功するケースはかなりレアというか条件が限られるので、自分がその事業の経営判断が出来る立場以外ではやりたくないです。リリース後に1年くらい不具合がバシバシ出ても許される＆修正するための体制が維持される環境なら2で進めるのもありかも）

---

以下、1も2も選べる状態ではないと思う理由

既存システムの仕様が不明なところが多いため、開発の難易度が高い状況です。

既存システムの仕様がわからない状態で1を行うということは、

• かなり細かい言語仕様まで再現しないといけないの現実的に考えてかなり面倒
• 旧言語言語＆フレームワークの仕様を再現=新機能&言語のメリットを削るという作業になることが多い

という感じになりがちなので、1を選択するのはかなりハードかつリターンの少ない道のりです。
クラスライブラリとかならリターンの方が大きいケースもあるでしょうが、アプリケーションそのもので実施するのは辛すぎます。

では2なら行けるかというと、原理的に要件の取りこぼしを防げない=致命的な問題の発生におびえながら開発を進めることになるので、開発チームのストレスが高くなりすぎて真面目な開発者ほど逃げたくなることでしょう。

Comments

[退会済みユーザー]

私なら、リニューアルの動機を明確にすることから始めます。
で、明確に理解して、それを実現できる人にマネジメントさせるかなぁ。。。

[退会済みユーザー]

1,2の感想をありがとうございます。参考にさせていただきます