昨今のリプレイス案件でハマるであろう、プロジェクトの進め方の注意点

まず背景から話すと、某企業の某プロジェクトで既存システムのリプレイスを行なっています。そこで得た知見を、特にプロジェクトの進め方について今の所の自分の考えをまとめておきます。

レガシーからナウでヤングでモダンなシステムに

リプレイスをするということは、大体において「既存システムを作り変えて、時代にあったシステムにすること」だと言えます。特にC向けであったりすると、既存サービスを動かしたまま、少しずつリプレイスを図り、最終的に全システムをリプレイスするといったこともありえます。今回はそのケースを体験できているのですが、ここで問題がありまして。

リプレイス案件はウォーターフォールとアジャイル、どっちが向いているのか？

実際に進めていくにつれ、この二つの手法のどっちでやるべきなんだろうなぁともんもんと思っていたしだいです。既存システムの振る舞いは保守し、かつシステムや運用自体は新しいものにする、ということなので、「要件定義はある程度決まってる」かつ「あるべき論に立って、ミドルウェアや設計、運用などの新しくするものは新しくする」がごちゃごちゃしがちだと思うのです。これってウォーターフォールでやったほうがよさそうでもあるが、アジャイルでやっていくべきなのかもとも思う。経験がほぼない自分にとっては当初は判断しきれないことでした。

スクラムでやって気づいた問題点

事実、スクラムでチーム開発が始まりました。数ヶ月やってみて、今改めて振り返ると以下の問題点があると個人的に思います。

• 機能や要素ごとに仕様調査・設計・実装することで、システムの闇にぶち当たり再見積もりしがち
• ゴールまでの大まかな流れが見えづらく、直近1週間の仕様調査〜実装で手一杯

だんだんと、「あっ...これあかんやつやわ...某み◯ほ銀行問題に近そうやわこれ...」ってなってきて、改めてプロジェクトの進め方を考えるきっかけになり、こういう記事を書くまでに至ってます。

結論：ウォーターフォールで仮決め・アジャイルで柔軟に変更

ウォーターフォールの良いところは要件定義をしっかりして、完了までの期日を定義するところにあると思っています。そのために全体感を全員が把握する必要があるし、詳細仕様を早い段階で詰めていく作業をするので、抜け漏れが極力なくなりやすくなる。一方、よくない点は後戻りできないこと。どこかでこけた瞬間に地獄に変わる。だから誰かがデスマしなければならない状況などが生まれがち。 一方アジャイルだと仕様も期日も、開発体制やニーズに合わせて変更可能ってのが良いところで、特に未知の物をつくるのには向いている。 ここで、ではいわゆるリプレイス案件ではどれが最適？という話に戻るのだけども、個人的には

• 初期は、ウォーターフォールを意識して、詳細仕様書を作成し、実装できる状態を早めにつくることを念頭におく
• 実際に実装する段階でアジャイルに切り替えてウォーターフォールで定めていた期日を基準として、変更するべきところで変更していく

ではないかと思うのです。 まとめると、最初の段階で出来る限り、既存仕様の抜け漏れをできるだけなくした状態で把握し、作る段階であるべき論に立って考えようってことです。

ゴールは明確に、やる理由を明確に

リプレイスをする理由ってのは、システム的には上記の通りだと思うのです。ただ、「リプレイスしよっか」となるのって、わりと時代に追い付きたい・世の中のニーズに合った開発体制に変えたいなどのビジネス要件がキッカケだったりするのかなとも思います。システム観点・ビジネス観点をごちゃごちゃにしていると、ゴールが定まらず、余計な設計や検討が大量発生してしまう。なので本来、何をゴールにするべきなのか、それをハッキリさせるべきなのだなぁと反省。次に活かす！
　
なお、この機会に、基本情報処理技術者検定の教科書本にある「システム開発技術と監査」という章を読み直したのですが、学生のころ読むとでは、浸透率が断然違うものなんだなと思いました。実際に働いて肌感覚でわかるものって多いのですね。