前回に引続き、エンジニアリング業務の分類について説明します。
まず分類とシステムのライフサイクルを再掲します。
- スクラッチ開発
- エンハンス開発
- 更改
- リプレース
今回は更改、そしてリプレースについて説明します。
更改
更改とはプログラムやミドルウェアのバージョンアップをすることです。正確には、バージョンアップして、それによってシステムの動作に問題がないか検証することです。
以上です。
だとさみしいので、もう少し詳しく説明します。プログラム言語にしても、データベースなどのミドルウェアにしても日々改善されており、古いバージョンは一定のタイミングでサポートされなくなります。サポートされないと重大なバグがあっても修正されることがないため、新しいバージョンに切り替える必要があります。
一見新しいバージョンがリリースされたタイミングで常時そちらに切り替えるのが理想のように思えますが、実際はそうではありません。手間の問題もあるのですが、それについては台所事情によりますので、ここでは技術的な話にとどめます。
バージョンで重要な概念として最新版と安定版が存在します。最新版は文字通り最も新しくリリースされたバージョンであり、画期的な機能が提供されていたり、セキュリティが強固であるなど、メリットがあります。但し、リリースされたばかりのバージョン、特にメジャーバージョン[1]メジャーバージョン：バージョン XX.YY とあった場合の XX に該当する数値。一方 YY の数値はマイナーバージョンと呼ばれる。が上がった場合は、仕組みが根本的に見直されていることがあり、かつ充分に検証されていない（＝枯れていない）ため、大小様々なバグが混入されている可能性が残っています。そのため、システムを更改する場合は安定版に切り替えることがセオリーとされています。安定版の定義は厳密ではありません。ソフトウェアによってはあえて安定版（stable）と銘打っていることもありますが、一般的には 1〜2年程度前のバージョンを指し、稼働が安定してよいとされています。
具体的にアップするバージョンを確定したのち、更改をどのような流れで進めるかについて説明します。更改の手順は案外原始的で、まず公式ドキュメントに破壊的変更が記載されておりためそれをもとに、可能な範囲で影響の調査を行い、取り敢えずテスト環境でバージョンアップをして、わかっている範囲で設定やプログラムを修正します。その後は試験項目をもとにひたすら試験を行います。そこでエラーが発生したものを適宜対応する、ということになります。実際には、バージョンアップに伴い、プログラム言語やデータベースが提供する関数が使えなくなることがあり、エラーが発生することが多いです。
更改は調査とテストが中心になりますので、調査はベテラン SE が、テストは QA エンジニア[2]QA エンジニア：QA（Quality Assurance）は品質保証の意味で、テストを専門とするエンジニアのことを抱える企業であれば QA エンジニアが、そうでなければ若手やロースキルエンジニア[3]ロースキル：設計やプログラミングをせず、キッティング（PC の設定を行うこと）やテストを実施すること。個人的には言葉の響きが好きでない。中心に行います。人海戦術が効くタスクなので、IT 企業にはじめて就職して、最初のプロジェクトが更改案件だったという人も多いのではないでしょうか。
リプレース
連載となった本記事ですが、最後に真打ち登場です。それがプロジェクト炎上の女神こと、リプレースです。リプレース（replace）とはシステムをプラットフォームレベルで移設することです。具体的にはオンプレからクラウドへの載せ替えやプログラミング言語の変更や追加がこれに該当し、昨今では最も多いパターンです。オンプレとクラウドとは何であるかについては過去の記事を参照ください。
プラットフォームの変更は更改によく似ています。影響範囲を調査 → わかる範囲で対処したうえでシステムをそのまま移し替え → ひたすらテスト、の順です。更改と違うのはその範囲の広さです。
また、プログラミング言語の変更であればプラットフォームを変更せず、既存の設定書などからスクラッチと同じ要領で開発を進めます。
それだけのことですが、ほとんどのケースで炎上します。リプレース自体はシンプルなプロセスですが、これがなぜ炎上を招くかについて説明していきます。
リプレースが招く失敗の数々ですが、主に原因は以下の通りです。
- リーダの不在
- 運用とリプレースの境界が曖昧
- クライアントとの調整不足
それぞれについて説明していきます。
リーダの不在
リプレースは言うなれば、システムの引越し（或いはリフォーム）なので、システムに携わる人全員が関係者となります。エンジニアはもとより、サービス運用者（エンジニアではなく、システムの管理機能などを利用しながらサービスを運用する人）も含まれます。そこには当然システムのサービス方針を決定するエラい人も関わってきます。
リプレースをする動機にもよりますが、多くの場合、リプレースを発案する人は技術者であることが多く、その技術者は往々にして普段対象のプロジェクトに関わっておらず、そしてエラい人でもありません。そのため、発案者とリプレースの中心人物は異なります。ここで問題になるのは、誰がプロジェクトのリードするのか、ということです。
本来最も発言力があるのは、予算の決済権があるエラい人か上記サービス運用者となりますが、この立場にある人は多くの場合、IT に知見がありません。リプレースにはシステム全体の知見、ひいては IT の総合的な知見が必要になります。そのため、最も対象のシステムに詳しい現行のアプリケーションエンジニア（或いはアプリケーションエンジニアを束ねるリーダ）がリーダに据えられることが一般的です。
但し、アプリケーションエンジニアというものはステークホルダー（利害関係者）が一堂に会するとき、最も低い立場にあります。エラい人やサービス運用者はもとより、インフラエンジニアを含めてもその発言力は至って微妙です。従来アプリケーションエンジニアは誰かの要望を満たして対価を得るため、契約関係上でも仕事をもらう立場です。日本古来の習慣が色濃く残る大企業の業務に携わればエンジニアの立場がどのようなものか直ちに理解することができるでしょう。
つまりここで祭り上げられたリーダは各関連部署との仲介となるのが関の山です。最も身分の低い者が中心となれば発揮できるのは推進力でなく、交渉力です。特定の部署同士で関係が悪い、プロジェクトの責任を取りたくないがために保身に走る、など阻害要因は多分に存在します。それらの仲介をすることは相当な負担になることは想像に難くなりません。社内政治に巻き込まれたリーダは消耗し、本来の開発業務にも支障が出て、飛んでしまうことも珍しくありません。
以上、いろいろと書きましたが、要するに実質的にリーダ不在の状況となり、全員の合意を取ろうとして取り切れず、多くの時間を浪費するということです。
運用とリプレースの境界が曖昧
リプレースではインフラを整えて、アプリケーション（プログラム）を載せてそれぞれチューニングしたうえ、テストを実行し、不具合を修正します。ここのテストはシステムがデグレードしないように、かなり大規模になるため、それなりの期間が必要となります。
本来リプレースは現行のシステムをそのまま移行するのが本筋であって、言語自体に変更がなければ、現行のプログラムをそのまま移行するべきであり、リプレース期間中の開発は差し控えるのが理想です。リプレース期間中に発生した現行の開発はリプレースしているプログラムに反映し、改めてテストが必要になるためです。ただ、現実はそのようになりません。サービスの売上増強は日々検討されており、マーケティングの観点から開発をしないわけにいきません。
これでも充分に手間なのですが、リプレースと同時に提供される機能はさらに面倒なことになります。新しいミドルウェアをクラウドが提供するサービス（DB、認証など）にした場合、それらが提供する機能を利用して、システムに新しい機能を追加してしまうことがあります。
リプレースと同時に新規機能を提供することは、単純にリプレース期間が延びる、現行の機能と矛盾する場合、プログラムの取り扱いが難しくなる、といった事態を招くことになります。テストの量はさらに膨らみ、その間にさらに開発が…といったことになりがちです。
リプレースと機能開発は混ぜるな危険です。
クライアントとの調整不足
システムによりクライアントは異なりますが、ここでのクライアントとは、システムを使用する立場＝上記サービス運用者とご理解ください。
サービス運用者はシステムの使い方に精通していますが、システムの中身をよく知らないので、基本的にはエンジニアを抱える各部門が作業の主幹となります。エンジニアはシステムを作りますが、実際の使われ方を網羅していません。そのため、サービス運用者が普段どのようにシステムを利用しているかわからず、リプレースの結果として、意図せずサービス運用者に運用の変更や追加を強いることがあります。
リプレースはサーバの場所から、場合によっては Web サーバやデータベースのソフトウェア自体を変更することもあります。インフラを変更すれば IP アドレスは確実に変わりますし、接続する URL が変わることもあります。例えばサービス運用者が特定のファイルを FTP や Excel のツールなどで定期的に転送している場合は、それらのツールも修正する必要がありますし、運用者が使っているマニュアルがあればそれも修正することになります。
これらを予め把握できず、せーの！でリプレースを実施すると、あとから確認したサービス運用者から NG となり、場合によっては仕切り直しや打ち切りになりかねません。サービス運用部署はシステム開発に予算をつける立場にあり、権限が強く、会社の体質が古いとシステム部門が過失を犯した場合に見せしめ行為におよぶことも充分に考えられます。
定常でのシステム開発と同様、ステークホルダーすべての利益を考えるのは重要ですが、前述の通り、リプレースは社内政治が関わってくることも多いので、優先順位を決めて課題を洗い出し、最終的にステークホルダー全員に利するように進めることが理想です。
リプレースはシステムが生まれ変わる大きなイベントです。運営する会社に少なからずインパクトがあるため、社内政治が少なからず関与してしまいます。この場合、ユーザ部門のゴリ押しに遭ったり、逆にエンジニアが強い場合はリスク分析ばかりでいつまでも先に進まないこともあります。システムの中身も事業も俯瞰し、推進もできる人材を中心に据えることができれば成功することもあるかもしれませんが、そんなすべてを揃えた人はそこら中に転がっているものではありません。僕が過去に体験し、見聞きした限り、成功した、或いは軽傷で済んだリプレースの事例を知りません。今後知ることもないかもしれません。リプレースの宿命といっていいかもしれません。
余談ですが、僕は社内政治が戦争と大災害に並んで嫌いです。生理的に合いません。単純に苦手なのです。いい歳した大人が身の保身に精一杯になるを見るだけで気分が悪くなります。寝がけに巨大な G が寝室に現れたような気分になります。もしこれをご覧の方でこれに同意するようでしたら、悪いことは言いません、早いとこ独立しましょう。社内政治嫌いは会社に適合しない体質であり、会社に蹂躙されるか、搾取されるかのどちらかしか選択肢がありません。僕自身 20年近く我慢してきましたが、40歳過ぎてから我慢の限界を超えて独立に至りました。
エンジニアとしての生き方を選んだ以上、自分のためにも無意味な社内政治からは逃れて、自分も納得できて、人が喜ぶようなモノ作りに集中したいものです。
といったところで業務の分類についてはここで幕とします。
脚注
