インフラもアプリも開発構築工程で自動化しないなんて自分がバグを出さないと言っているようにしか思えないんだけど

とあるプロジェクトでワタシのチームの横に別のシステムを担当するチームがあって、試験工程の時期にトラブっている状況が見え聞こえてきます。どうやら改修したときにでグレードしたらしい。で、今時のプロジェクトですから再発防止なんて求められていろいろと大変な状況になっているようです。

その点、具体的にはソフトウェアのプログラムや構成ファイルのリリースのデグレードに関しては、ワタシのチームでは記憶にないほどありません。記憶にないほどデグレードのリリースをしていないのはそうならないように開発構築工程での作業手順に配慮しているから、なんですが。

そうしている背景には、SIプロジェクトを何度か経験していれば、作業ミスをすれば即再発防止を求められ、その再発防止も根本的な解決よりは精神論的な対策だったり、やってもやらなくても何も影響しないチェックシートの導入だったりすることは誰でも想像に難くないと思っているからです。そして、それを、誰もうれしくない作業をしたくないと常々思っているので、

“事後の品質確認より事前の作業品質”

の方に関心もリソースも割り振るようにしています。まぁ、その分、事前の作業がスケジュールの比率もコストもメンバの負担も重くなるわけですけど、事後にトラブって文句言われるよりいいですから。

開発行為と位置づけるか製造行為と位置づけるのか
ソフトウェア開発では、インフラもアプリケーションも大括りには、「設計→開発構築→試験」の工程を経てリリースします。その中間にある実際にソフトウェアの開発構築工程では、設計どおりにプログラムやパラメータを実装するわけですが、そこでも人が介在すると間違いをするんですね。例えば冒頭の事例のように改修後のリリースでデグレード、つまりリリース予定のプログラムではなくて過去の古いバージョンのプログラムをリリースしてしまうことになるわけで。

先の、事前事後の話から言えば、ワタシは事前のしくみをそのシステムのリーダや実際にデグレードを起こしたエンジニアひっくるめて、

“繰り返しの工程をいつまでも開発工程のままで位置づけている”

のだと思っています。開発工程と製造工程の違いって何？と思うかもしれないですけど、違いますよね？例えば、ハードウェアを製造するなら、

開発(試作)→量産試作→量産

の工程を踏むと思うのですが、ソフトウェアの場合、設計、開発構築、試験の各工程の内の開発構築工程が開発(試作)にあたり、開発(試作)の位置づけのまま試験工程に突入していることになるわけです。つまり、試作のまま顧客に届けるソフトウェアを作っているということになるわけですよね。それって、製品開発して試験してリリースしているのですから一品モノを作っているということになるのですね。一品モノですからね、同じものを作る気もないわけです。だから、手作業でもいいとしておくわけで。

冒頭のデグレードを起こしたトラブルは、つまり、開発構築工程が一品モノの開発(試作)工程としか捉えられていなかったから、繰り返しの作業である改修のリリースで間違いを起こす手順のまま放置されていたということもできるのかな、と。

回帰試験を念頭に置けば製造の観点で考える必要がある
ワタシの場合、開発構築工程のしくみを作るときにまず初めに考えることは、あー開発構築工程に限りませんが何回繰り返すことが想定できるか、と言う観点で見ることにしています。これね、とても大事なことです。

だって、最初に開発構築工程をやったメンバと2回目、3回目の繰り返しのときに実際に手を動かすメンバが同じとは限らないですからね。人はね、自分で考えて試行錯誤した手順やしくみでないと正常にできて当然と思って結果を疑わないんですよ。そこでミスを見逃すわけです。その上、プロジェクトで大部分を占めるコストがエンジニアの費用ですから、何度も繰り返すことは費用が繰り返すだけ膨らむし、間違いを自分で仕込むし、最悪、再発防止で効果のない手順を仕組まなければなくなる、と言うことも一因にあったりします。

だから、開発構築工程では、プログラムや構成ファイルが開発環境からスクリプトなどで抜いて、データとしてデプロイしたい環境に配布したりできないか、そうした観点で自動化の可能性を調べてもらいます。

その上で、自動化にかかりそうなコストと繰り返す回数を天秤にかけて、そうはいっても基本的には自動化に踏み切りますけど、自動化のしくみを作ってもらいます。その点では、インフラであってもスクリプトを書けるエンジニアが一人は絶対に必要なんですよね。

で、なんで基本的に自動化すると考えるかって聞かれたら、こう答えます。