既存システムに災対システムをどうやって組み入れるかプロセスを考えるのが楽しくて仕方がない

以前にそんなことをやる機会がありまして。勿論、そのプロセスの組み入れをワタシが欲しい情報を集めて試行錯誤をすれば、入手都度、仮決めで組み上げたプロセスを組み直すことも大した手間とは思うこともなく、一人楽しくマイルストーンまでに遊んでいればいいんですが、それでは周りは「楽しくなかろう？」と思って、そこからメンバに「考えて！」とお願いしたのでした。

こちらとしては無茶振りとは一切思っていないのは「だって楽しいじゃん？」と思っているからで、こんな楽しいことは周りにお裾分けしないといけないとも思うからで。そしたプロセスフローの設計の経験が少ないエンジニアにとっては迷惑かもしれませんけどね。でも、何時までも一担当で降りてくる仕事をしてもらっていても仕方がないわけですから。

既存システムに災対システムを組み入れるときに考えたこと
じゃあ、ソレ↑を考えたときに何を思って何をしたか、ですけど、そうしたケースでプロセスフローをどう考えているか、なんて頭の中を晒す人はそうそう居ないと思うので書いておこうかと。

既存システムの状態
災対システムの設計を検討するタイミグでは、既存システムは本番運用しているのか、その前の試験フェーズなのか、システム的につながりを持つ、つまり、接続するときには既存システムはどういったフェーズなのか、は気になりますね。それは、本番でサービス提供しているなら、そうそうお気軽に既存システムに照会のためのアクセスだって躊躇われますから。不用意なアクセスは事故の元ですし。

あとは、接続するタイミングで止められる時間帯が採れる運用なのか、というのも気になりますね。あとあとの、災対の構築方法によっては業務規制を掛けられるのかどうかインパクトを推し量らねばならないですから。

対外システムとの関係
既存システムに災対システムを追加するとき、災対システムと対外システムとの関係も洗わないといけないですね。例えば、ADと接続する様な場合、それはそれでいろいろとAD側とインタフェースの取り方を決めて設計しておかないといけないわけで。で、設計書に書いておかないと、あとで相違があったときに会話する土台がないので拗れちゃうし。

開発環境の扱い
既存システムに災対システムを追加するわけですけど、既存システムが本番運用しているシステムしかないとするならこのあと述べる手順の確立とか、機能試験とかどこでやりますかね。特に、災対システムに特定した機能の確認とか。まさか、本番運用している既存システム上で災対の機能試験なんでどうやってやるのでしょうか。やるにしても、本番運用しているのですから試験をできる時間はとても限られそうです。

そうすると、災対システムを構築するエンジニアが設定も試験もサーバの再起動もある程度調整してできる環境が必要です。ここを考えていない人が割として、その都度驚くんですけど。そんなにワタシのことを驚かせて楽しいのか？

災対システムの構築手順
既存システムがあって、災対システムを構築するとき、その構築の手順が確立している必要があるのは当然ですよね。それは既存システムが本番運用中の場合は、本番サービスに影響のないように災対システムを構築しないといけないし、接続の仕方によってはデータベースを初期化したり壊したりしかねないのでそうした被害を防ぐ意味があるのですよね。

そういう意味で災対システムを構築する際の二次被害の防止の観点だと、構築手順を確立するには、災対システムがスタンドアロンで建てつけ出来るのか、とか、試験を実施して品質保証の確証を得てから既存システムと接続するような手順が組めるのか、製品ベンダのサポートも含めて手順を確立しないといけないですね。

その、災対システムの構築の手順の確立の中では、接続の手順と切り戻しの手順も必要です。そうそう、場合によっては既存システムのバックアップリストアも「やる必要に迫られるかも！」と考えておかないといけない。

作業品質の担保
作業品質の担保とは、設計したパラメータなりプログラムを設計したとおり組み上げて、それを設計どおり配置してそれを確認するまで作業の範疇です。「何のためにやるのか？」ですって？勿論、作ろうとしたものが「設計どおり作れているよ。」という保証を得るためです。それは、試験フェーズでは確認できないこともあるからね。で、作業品質の担保のためには、作業して作成した値やプログラムがそのとおりに配置されていることを客観的に示すエビデンスが必要なのでどのタイミングで何をエビデンスとするかも考えないといけないです。

特に、既存システムがあって災対システムを追加するときに、既存システム側に災対システムのデータを追加で持ったり、その逆で既存システム側にagentを入れるなど、既存システム側に構成変更が入るときの既存システム側の影響範囲の特定は前述した構築手順で確立するんですが、その確立した手順の中でどの構成情報を変更するとか、新たに構成情報を追加するとかがはっきりさせないと担保しようにも闇雲になってしまうので。

品質保証の担保
これは、構築後の、作業品質の確保後の、実現する災対機能の確認と既存機能がデグレードしていないかの確認とあります。この品質保証も実装すべき機能が織り込まれているかとか確認するわけですが、どこに何を実装するのかとか、どこの既存システムの機能とインタフェースを取るのか、とかで確保するエビデンスが変わるわけです。そして間違えると、試験やり直し。

こういったことをメンバ全員が理解できる資料を作ってね
とお願いするのです。で、こうしたプロセスフロー設計は入手する情報で変わりますからね。最初は手書きで十分なんですよ。ホワイトボードでもいい。で、毎回写真に撮っておいてもいい。それを共有するんです。で、ある程度固まってきたら、例えば、ここ辺りは外部の決めで左右されるとか、ここは自分たちで決めること、だとかそうした色分けができるようになってからPowerPointでもなんででもいいので清書すればいいんです。

それまではあまりPowerPointで描くのは進めないですね。だって、清書しちゃうとできた気になっちゃうんだもの。これ、PowerPointができて安心してしまって思考が止まるのでよくないんですよ。

このようなプロセスフロー設計は、メンバ全員に影響するのでみんなで理解しておかないと間違える人が出てきたり、あとで文句を言う人が出てくるので最初にちゃんと巻き込んでおきたいんですよ。