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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大量のデータを処理するときに知っておきたい前提知識

大量のデータを処理するとき、何の工夫もないまま設計していると、すごく結果出力までに時間がかかる。このことはなんとなく分かってはいるけども、なんとなくのレベルなので勉強してみた。

遅くなる理由

結果からいうと、大量データを素直に捌こうとすると、メモリだけでは賄いきれず、ディスクを読み込む必要が出てくるため。ディスクは物理的制約があり、メモリと比べると探索にすごい時間がかかるため。 ではなぜメモリは探索が速く、ディスクは遅いのか？

メモリは電気的な部品

もともと電気的な部品のため、物理的制約を受けないので、探索を高速に行なえる。その上、データを転送するためのメモリとCPUとのハブもかなり速い。結果として、メモリはディスクと比べ、10⁵〜10⁶ほど速くなるとのこと。

ディスクは物理的な操作が必要

一方ディスクは、円盤にデータを記録していくため、探索する際にヘッドを移動させ、円盤を回転させ、といった作業をしなければならない。その上、データを転送する際のディスクとCPU間のハブもメモリのそれと比べ低速。

SSD使えば速くなるのでは？

SSDは物理的な回転がないので、探索自体を高速化することができるが、CPUへのデータ転送のときのハブ自体は変わらないので、やはりメモリと比べると遅い。

大規模データを扱うときのコツ

1. いかにメモリ上で処理させるか

メモリとディスクを比べると、圧倒的にメモリのほうが速いというのは自明である。なので出来る限り、メモリ上で処理させようとするのは自然な流れ。 昨今の主な工夫の仕方としては以下のようなものがある

• RedisのようなインメモリのDBを使う
• OSレイヤーで、一回でディスクから読み取るデータ量を増やす（メモリにたくさんデータを置く）

2. いかに扱うデータ量を少なくするか

メモリ上で処理させる方針をとり、さらに高速に処理したいとなると、次は扱うデータ量をできるだけ少なくする方法を考える必要がある。主な方法としては圧縮技術を活用する、といったものがある。例えば、ディスクにはアプリケーションファイルをまんまおくのではなく、圧縮し一つのファイルとして作っておき、転送する際も圧縮された小さなデータを送信し、転送先では圧縮ファイルをメモリ上で読み込み、ビルドするといった手法などがある。

3. データ処理に強いアルゴリズムを知る

ディスクを使用するとなったとしても、線形探索を愚直にやったのでは遅くなるのは仕方がない。なので探索アルゴリズムについて基礎的でも良いので知っておき、探索アルゴリズムを用途に合わせて使いこなす、という工夫で高速化することもできる。

4. 検索エンジン活用という解決策を考慮する

DBだけではそろそろ探索処理を賄うにはきついってなってくると、ある検索条件に特化した検索エンジン的なシステムを用意して、それを利用するというのも一つの手。

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

エントリタイトル

** エントリ本文