【基本のき】システム刷新時に注意すべきこと７選
更新日: 2022年3月14日
この記事は、すでに稼働している基幹系システムが古くなっているため刷新したいという方を対象にしています。
せっかくの刷新なので、ここはノーコード・ローコード開発方式を採用して「開発費削減」「納期短縮」を実現しようとお考えですね！そのような読者へ向けた、注意すべきこと７選をまとめました。
刷新の場合、とにかく大変なのが「現行システムの仕様を把握する」ことです。別の言い方をすると「現行システムの仕様を記した文書が残っていないか、書き方が甘くて役に立たない」場合がほとんどです。
これはシステムがブラックボックス化された状態です。保守しているエンジニアが詳細を把握していればまだしも、放置された状態で使われ続けているシステムの調査は骨が折れます。
そこで私たちが提案する、刷新で注意すべき一丁目一番地は、ずばり「今度こそ、ブラックボックス化させないようにする」です。
具体的には「設計書と、稼働しているシステムが完全に同期している状態」にしましょう。目指しましょう、ではありません。そうしないと開発ができないような仕組みにしましょうということです。
設計書には次の三つの情報が必ず書かれています。
いずれも「データ」の話ですね。
設計書の中心に位置付けられるのはデータですので、このシステムが取り扱うデータについての責任者を決めましょう。
仮にこの責任者を「データ・モデラー」と呼びます。
つまり、データ・モデラーは「システムが取り扱うすべてのデータを把握」します。
刷新プロジェクトでよく話題となるテーマの一つが、現行システムの仕様（AsIs）を把握することと、あるべき姿（ToBe）の仕様を定めるという二つの整理が大変 というものです。
先の説明で、ブラックボックス状態の現行システム仕様を紐解いていくのは並大抵ではないとお伝えしました。
それでも現行システムの機能を全て引き継ぐことが刷新後のシステムの要件であれば、AsIs の把握は必須です。
しかし刷新後のシステムはこうありたいという姿（ToBe）を先に定め、これにあわせて現行システムからデータや機能を引っ越すという方法もあります。
どちらが正解ということはないのです。
刷新が AsIs からの忠実な引き継ぎであれば、現在のデータベースを再利用をしたいと思うかもしれません。（ToBe から入るアプローチなら、データベースは再設計し、使えるデータを移行することになります。）
ところが AsIs 重視方式であっても、いろいろ考えると再設計＆データ移行した方がいい、ということはあるのです。その判断ポイントをお伝えします。
(1) 現在のデータベースの「テーブル」と「各テーブルに含まれる項目（カラム）」についてすべて説明できますか？
(2) 採用するツールは、そのテーブルの再利用ができますか？
ちなみにクラウドで提供されるプラットフォーム方式の場合は、そもそもデータベースの再利用は仕組み的に不可能です。
データベースを再利用するかどうかは「目先の開発を楽にするため」ではなく「今後の保守を楽にするため」という視点で、じっくりと検討してください。
「この刷新プロジェクトをアジャイル開発で……」という考えがありますか？その場合は一度、ちょっと冷静になりましょう。
アジャイル方式とは「システム化する内容（仕様）を、その時点の状況（経営環境）にあわせて臨機応変に変えたい」という要望に対応した、開発の進め方のことです。
しかし刷新プロジェクトというのは「システム化する内容（仕様）はすでに明らかであり、しかもこの仕様は多くの場合、複雑なので、漏れや抜けがないようにしっかりチェックしながら進める」ことが求められています。
つまり、アジャイル方式が向いているテーマというわけではないのです。
もし開発費削減という視点でアジャイル方式を検討中でしたら、それは刷新プロジェクトには不向きなので、早めに誤解をといておきましょう。
"開発費削減はノーコード・ローコード開発ツールの能力を引き出すことで達成するようにしましょう。"
この説明について補足します。
よくある失敗例を紹介します。
このアプローチはうまくいきません！
つまり、ノーコード・ローコード開発時代では、上流と下流という工程の分け方そのものがナンセンスなのです。
要件定義の段階から、もっというと AsIs と ToBe のどちらを優先するかの議論の段階から、ノーコード・ローコード開発の経験者に入ってもらうことです。
最後の注意点は、多くのツールはこまめにバージョンアップをしている、ということです。
クラウド提供方式であれば、ツールを含めた開発と運用環境自体がプラットフォームとなっているため、自動的にバージョンアップされます。
ツールを開発者のPCにインストールする方式であれば、手動でバージョンアップを行うことになります。
いずれであっても常に最新の環境としてください。
今の時代、例え社内システムであってもファイアウォールやウィルスチェックがあれば安心とは言えなくなりました。
セキュリティ脆弱性対応はツールが提供する、重要なサービスの一つです。
そこで気になるのはツール自体の仕様変更やデグレードです。
これを見越して、回帰テストを簡単に行える環境を提供するツールもあります。この点も調べてみることをお勧めします。
ノーコード・ローコード開発によって自分達で簡単に既存システムを刷新したい、というテーマにも、さまざまな注意点があることをお伝えしました。
いろいろ書きましたが、もっとも大切なのは「自分たちのシステムの中身を自分たちで把握する」という大原則を忘れないことだと思っています。
開発自体は簡単に行える時代になりました。
これによって「少人数の開発チームで、大規模システムの開発と運用」が行えるようになります。はじめに
１. 今度こそ、ブラックボックス化させない
なぜなら、関係者は全員、これまでの経験から、これを仕組みではなく人力でやることは無理だとわかっているからです。
２．データ、データ、データ
それもそのはず。業務システムとは、業務で発生するデータを管理するシステムだからです。
（なお、一人とは限りません。規模の大きなシステムであれば複数人いることは普通にあります）
モデラーとはモデリングする人という意味です。
モデリングとは「現実世界にあるデータのうち、このシステムで扱うデータを選んでシステムが理解できる形に整える」ことを指します。
これはデータの形や量といったことに加えて、次のような情報も含みます。
（誰がこのデータを入力するのか、いつこのデータは破棄されるのか）
それぞれの現場では、現行システムにこういう操作をすると自分の仕事は完了するということは知っています。
しかしこのデータがどこからきて、どこへいくのか、を把握している人がいません。
そのため、よくわからないままコピペしたり、自分のExcelに似たようなデータをもっていたりすることになっています。
これが日常業務の生産性の足を引っ張っていることは、いうまでもありません。
３．AsIs と ToBe の両方を把握するのは大変
ただし現行システムの内部情報（いわゆるソースコード）を解析することだけが解決策ではありません。
現場の担当者からのヒアリングを含め、AsIs をどうとりまとめるのか、についても多くの手法があります。
（ここでは説明を割愛しますが、私たちが注目しているのはマジカというアプローチです。）
この場合、ブラックボックスとなったシステムから決別します。
しかし刷新を「現行重視」とするか「新設計」とするかは、先に決めておきましょう。
ここをあいまいにしたまま進めると、多くの関係者が "自分が思っていたものとは違う" と混乱することになります。
４．今のデータベースを再利用していい？
説明できれば再利用しても安心です。説明できないテーブルやカラムが多いなら、再設計の方が今後の保守は楽になりそうです。
ツールによっては、例えば複合キーを含んだテーブルは再利用できない（のでテーブルの定義を変える必要がある）ということがあります。
検討する必要がないという意味では楽かもしれません。
この判断が御社の次の10年の競争力を支えるのです。
５．ちょっと待った！今、アジャイル開発って言った？
どちらかというと、システムの設計にじっくりと時間をかけ、実装とテストを短時間で済ませるという考え方が求められています。
開発費削減はノーコード・ローコード開発ツールの能力を引き出すことで達成するようにしましょう。
６．ツールの特性を活かした設計をしていますか？
これは、ノーコード・ローコード開発ツールの能力を引き出すような設計があるということです。
上流工程と下流工程をそれぞれ別の会社に発注しました。
上流工程を請け負った会社はノーコード・ローコード開発を知らず、これまでどおりの方式で設計書をまとめました。
ユーザ企業はこの設計書を下流工程を担当する会社に渡し、ツールを使うので安くできるだろうと期待しました。
なぜなら最初にお伝えしたように、設計書と実装（プログラミングされる部分）は不可分として扱うのがノーコード・ローコード開発です。
そのため、採用するツールによってそれぞれ得意な設計方法というのがあります。
それに合わせることで最高のパフォーマンスを発揮できるようになっています。
この視点を取り入れたプロジェクトは、成功の可能性が飛躍的に高まります。
７．ツールはどんどんバージョンアップします
その最大の理由は「セキュリティ脆弱性への対応」です。
攻撃は社内システムであっても発生します。
（詳細は長くなるので触れませんが、「ゼロトラストネットワーク」というキーワードは抑えておいてください）
そのためには脆弱性に対応したバージョンへと常に入れ替える必要があります。
この影響を早めに検出し、ツールベンダーと緊密に連携するためにも、ユーザ企業は「回帰テスト」を行う仕組みをもっておくことが望ましいです。
まとめ
今度こそ、そのシステムの核となる「データ」をしっかりと自分たちの手元で管理できるようにして、業務プロセスやインタフェースをツールで実現する体制にしましょう。
是非、このゴールを目指してください。