振り回されないソフトウェア開発

おはようございます。

もちろん起き抜けではありませんが、なんとなく起きたばっかり感がまだ抜けない今日この頃。そういえば、昨日の晩御飯がまだ胃に残ってる感があるかもしれません。消化不良かな。

今や、どの社会、どの企業でも、必ずと言っていいほど、ＩＴ化は進んでいて、少なからず何かしらＩＴによるツールやシステムを導入していることかと思います。

ERP(Enterprise Resources Planning)やRPA(Robotic Process Automation)などを導入して効率化を図っている企業もあるでしょうし、CMS(Content Management System)なんかを運営している企業もあると思います。基幹業務に関係のないところではグループウェアなんかを使っている企業も多いのではないでしょうか。最近では、クラウドサービスも充実してきたので、そちらを多用されている企業も相当増えているみたいです。

私が今いるところでは、バックオフィスは壊滅的ですね…運用・保守をされている部門の方々が、かなり古い技術しかお持ち合わせでないから、新技術(と言っても大概レガシー化してますが)系は一切導入しようとしませんし、自分たちで物理的にサーバーを管理するのが楽しいのか、未だに「クラウドはセキュリティが怖い」の一点張りです。

　「医者の不養生」

とはよく言ったもので、フロントではユーザーに新しいシステムの導入をおススメし、様々なソフトウェアやシステムを納めている一方で、バックでは20～30年以上前のシステムを、再三再四「使いにくい」「遅い」「落ちる」等言われながら改善しようとしないでいます。

ユーザー企業にはそうなってほしくないものです（仕事がなくなっちゃう！）。

ＩＴ企業が行う開発の種類

契約形態はともあれ、私たちＩＴ企業では、ソフトウェアを中心に色々するわけですが、なにも「プログラミング」だけしていれば何でもいいというわけではありません。

昨今では、大木の企業がＩＴ化を推進してきた結果、新しい技術の分野でない限り『新規構築』するＩＴシステムの開発と言うものはほぼ残っていないと言われています。もちろん、ＡＩやＩｏＴの台頭のおかげで、そういったプロジェクトも増えてはいますが、市場全体で見れば微々たるものではないでしょうか。

基本的には、カスタマイズやリプレイス、マイグレーション、コンバージョン、ポーティングと言った、既に存在しているシステム(＝既存システム)に対する不満や要望への対応が殆どを占めていることでしょう。

ですが、現場のエンジニアはこの違いをあまり意識していません。

結果的に、設計して、プログラミングして、テストして、問題がなければ納品することに変わりがないと思っているのかもしれません。

ある意味では間違っていません。ですが、これらの要件ごとにその設計思想や事前調査の観点が大きく異なるため、これを正しく理解しておかないと、システムを作る際に必ずと言っていいほど、「潜在不良」を混入させることになってしまいます。

実際、数年前にはそれを理解しないまま、ユーザーの言うとおりに進め、ユーザーの受入テストになってから、無理難題を吹っ掛けられたプロジェクトの解決に立ち会ったことがあります（アレも相当ひどかった…）。

では、カスタマイズ、リプレース、マイグレーション、コンバージョン、ポーティングと言った言葉の定義は、具体的にどのようになっているのでしょう。

カスタマイズ

customize。ユーザーの好みと使い方に合わせて、システムやソフトウェアの機能などを設定し直すことです。「調整」「改造」「改修」とも言います。「改造」「改修」の意味を持つ英単語に由来して使われています。

基本的に開発規模が小さく、また既存のシステムやソフトウェアを母体にして修正するものですので、基本的に動作環境を変えるようなことはありません。

リプレイス（リプレース）

replace。老朽化したり、破損したりと、使えなくあるいは使いづらくなったシステムやハードウェア、ソフトウェアなどを新しいものや同等の機能を持った別のものに置き換えることを指します。

システムは大きな高額商品となりますので、必ず「固定資産（無形固定資産）」と言う扱いになります。減価償却の原則があり、およそ５年で価値を失います。

サーバーなどのハードウェアは部品交換などが可能なサポート期間がリミットになるのですが、ソフトウェアの動作保証もそのハードウェアに依存したものになっていることが多く、ハードウェアの交換時期にあわせて、ソフトウェアも刷新するのが一般的です。ＯＳなどのミドルウェアに依存するケースもあります。

通常は、どんなに高額なシステムであっても、10年ほどがライフサイクルで、10年後には買いなおし（作り直し）をしなければなりません（軽く億を超えるようなシステムは7～8年目から検討・開発が始まっているでしょう）。

部品やソフトウェアなどの部分的な入れ替え、交換を意味する場合も、機器やシステム全体を新しくすることを指す場合(システムリプレース)もあります。交換(する)、置換(する)、元に戻す、後を継ぐ、などの意味を持つ英単語に由来して使われています。

マイグレーション

migration。ソフトウェアを、古いバージョンから新しいバージョンに入れ替えることを言います。プログラミングやソフトウェア開発で、古いプログラミング言語や開発環境で記述・開発されたソフトウェアを、別の言語や新しい環境に適合するよう変換することなどにも用います。

老朽化した機器や開発元のサポートが期限切れとなったソフトウェアなどを破棄し、同じ働きをする新しいシステムを構築して切り替えることを「レガシーマイグレーション」、あるいは単に「マイグレーション」と言います。もうすぐWindows7のサポートが切れますが、それにあわせてPCの購入やOSのバージョンアップを行い、これまで使っていたアプリケーションやファイルをもう一度ＰＣに入れなおすのもマイグレーションと言えます。

データベースなどで、古いバージョン、あるいはアプリケーションに蓄えられたデータを抽出・変換して新しいバージョンや別のアプリケーションに移転することを「データマイグレーション」、あるいは単に「マイグレーション」と言ったりすることもあります。移行、移転、移住、移動、乗換などの意味を持つ英単語に由来して使われています。

ポーティング

porting。コンピューターの特定機種用に作られたプログラムを、他の機種で使えるように書き換えることです。ソースコードを使って、元のソフトウェアが対応していないプラットフォームでそのソフトウェアが動作するように作業することを指します。

国内では、ポーティングされたバージョンを「移植版」などと呼びますね。AndroidOSで動くアプリを、iOS版でも同じように提供するのがこれにあたります。

全てに通じて注意すべき点

どれも似たような意味を持っており、もちろんすべてに通じて注意すべき点もありますが、同時に、注意すべき点は個々に異なる点も存在しています。

それは、

　「既存のデータやデータの流れは必ず再利用されること」

です。既存…つまり「既にあるもの」は、ユーザーにとってはこれからも使っていきたいわけです。ユーザーにとって本当に大事なのは、システムそのものではなく、それまでシステムを使って培ってきたデータです。基幹システムであれば、事業そのものを指すものです。システムは何度でも作り直すことができますが、データは一度完全になくなると、過去の記憶に頼るしかなく、元に戻すことはほぼ不可能です。

だからこそ、これまで紡がれてきたデータやデータの流れを再利用することは、100%絶対遵守すべき、必要最低限の要求事項です（変更するニーズがない限り）。これ抜きにシステムを作ることはあってはなりません。ユーザーが、今まで培ってきたデータ群を放棄することなど100%あり得ないのです。

にも拘らず、エンジニアの大半は「何を作るか」にばかり注目していて、
データ移行や既存資源の再利用についての吟味を疎かにしてしまう傾向が強く、納品直前に大慌てになることが多々あります。

個々に注意すべき点

たとえば次のようなものがあります。

■リプレース

既存システムが、「相当古い」「当時の担当者が在籍していない」などによってシステム納品当時の資材（設計書や仕様書等）が紛失されていて、システムの中身がブラックボックス化されている(当時の経緯や証跡が残っていない)ケースも非常に多く、改めて作り直そうとしたときに、ユーザーの真意がわからず要求と異なるものを作ってしまう。

また、5年後10年後にリプレースされることを想定した設計になっていないことも多く、データ移行や業務改善が困難となり、想定しない規模のトラブルを引き起こしやすい。

既存システムを継承して新しいシステムを作り直す「リプレイス開発」を成功させるポイントは、常に"設計"にあります。

■マイグレーション

注意すべきは、実装前の段階で、「何ができればOKか」という点を明確化することです。

しかし、実際のマイグレーション案件においては、リプレイスと同じく、インプットとなるシステム要件や仕様書が十分とは限りませんし、リソースも十分ではありません。また実機で確認するにしても、設計(根拠)がない以上、どこまで操作すれば「100%把握した」と言い切れるのか明確に定義できません。

怖いのは、仕様も設計もなく、「ソースが正」「ソースが仕様」と言い出すユーザーです。ハードやＯＳが大きく変わる場合、過去のソースコードはあくまで過去のハードやＯＳにあわせて作られたモノです。新しく作り直すにあたって前提となる次のハードやＯＳにあわせて作られたものではありません。

「まったく同じ動作にしてほしい」と依頼されることもありますが、ハードやＯＳの制約上、まったく同じ動作をさせられない…なんてことも珍しくありません。

以前あったユーザーは、既存ハードが組込み系端末、ＯＳはWindowsCEだったものを、次期ハードはモバイル端末、ＯＳはWindows8.1で実装したいと言ってきたことがあります。これはもう、"Windows"と言う冠がついているだけで、完全な移植（ポーティング）です。この場合、機能仕様だけは既存のソースコードから読み取れることはできますが、ハードやＯＳの制約上、決して同じにできない部分も出てきます。

たとえば、既存の組込み端末/WinCEでは、バッテリーを抜いても５分くらいは動作し続ける機能がありました。ですがモバイル端末/Win8.1ではバッテリーを抜いた瞬間にダウンします。ユーザーはこれを「バグ」だと言い出したなんてこともあります。当然ながら、物理的に電気が流れない状態になるので、ソフトウェアでは対応できません。

ハードやＯＳの選定はユーザー側があらかじめ指定してきたものですが、モバイル端末の（携帯やタブレットと同じ）仕組みを理解していなかったのでしょう。開発部署からは「ユーザーを説得させられない」と泣きつかれて、少々支援したことがありますが、エンジニア側にもそうしたマイグレーションやポーティングならではの差異を理解しておらず、事前調査が甘かった点などが大きな問題だったのではないかと思います。

納品すればそれで終わりではない

システムは１度納品すればそれで終わりではありません（終わるのはプロジェクトと言う活動単位であって、システムのライフサイクルはそこからがスタートです）。

市場やビジネスモデルが劇的に変化しない限り、システムはカスタマイズ、リプレイス、マイグレーション、etc…様々な方法を用いて姿かたちを変え、生き残っていくことになります。毎回毎回、何億ものお金を出して新規に作り直すなんてことはそうそうありません。

しかし、そのことを意識して設計しているエンジニアははたして何割いるでしょうか。

たとえば、あるシステムの開発時において、システム償却期間(寿命)を７～８年程度…とした場合、

　「次にリプレイスされるときに必要な資料は何を残せばいいか」
　「リプレイスするとしたら、どんな作りにしておくと後々楽になるか」

こういった発想を疎かにしてシステムを開発すると、殆ど新規構築が存在しない現在において、カスタマイズ、リプレイス、マイグレーション、etc…と言った案件に携わる際に、自らが苦労する側に回ることになるのは明白です。

カスタマイズやリプレイス、マイグレーション、コンバージョン、ポーティングと言った、こうした言葉はどれも一様にあたかも、今までと同じものが格安に短期で出来上がってしまうような気になってしまう魔法の言葉です。

お客さまの方でも、大抵が誤解されていることでしょう。

しかし、開発側に立つ私たちだけは、その甘言に惑わされることなく、システムが稼働し続けるライフサイクルを意識した設計を心がけなくてはいけません。

①20年先も「システム(仕組み)」は残っていると仮定する。
　(当然、ITシステム自体は何度か作り直されているかもしれない)
②ビジネスモデルなんて5年で大きく変化しているだろうと仮定する。
　(じゃあ、5～7年でリプレイスされることを視野に入れる)
③次もまた自分が受注し、開発するかもしれないと仮定する。
　(自分が担当ではないかもしれないが、困らない情報に何を残せばいいか？
　 再開発しやすいようにするためには、どのようなアーキテクチャにして
　 おけばよいか？)

このことを念頭に入れて設計しておかないと、冒頭に述べたように、次の開発(カスタマイズ、リプレイス等)を阻害するという意味で、甚大な障害(トラブル)を潜伏させてしまいかねない、ということを肝に銘じておかなくてはならないと思うのです。