リリースへの一考

開発されたものは、いつか公（おおやけ）に公開される。基本的に、公開は「テストが完了した完成品」に対して行われるものであり、そういう意味合いにおいて「完全品」である。
しかし、公開されたとは言ってもその後のバグやら変更やら改善やらで、公開されたものが「そのまま」利用されつづけることは極めて少ない。
そういった「リリース」と「リリース後の変更」について、考察を重ねてみたい。
なお、考察の題材として、比較的変更が多いと思われるCGI関連の開発を仮想ターゲットとして考えている。

おこなってはいけない二つの極論

まずはじめに「何があっても陥ってはいけない」べからず論の方を二つほど取り上げる。

軽率な更新

一般的に、これは「高い頻度での無配慮な更新」という事例に直結することが多く､そしてその間違いは精神論によって肯定されることが多い。
曰く「毎日(或いはそれに匹敵する高頻度の)更新はWebにとって必須」であり「ユーザからの意見は出来うる限り速やかに(時間単位は概ね時間～日)反映する必要があ」り、そういったことを肯定する行動こそが正しい。
高頻度の更新によって起きるミスは「担当者が注意することによって」回避されるべきであり、間違っても「仕様の確定に手間取ってはいけない」。
ちなみに筆者は「サイトを日々良いものにしようとする意志と努力は絶対必要」という文言を拝聴したことがある(無論、その主旨そのものが間違っているわけではない)。そして念のために「本番稼動後もプログラムにかかわる変更でも、ろくな打ち合わせもせずに即時対応してどんどん取り入れるという事か？」と確認したところ、肯定する返答が帰ってきた。残念なことにノンフィクションで。
概ね、システム管理とか開発とかの訓練が皆無の状態において考えられやすい方向性である。且つ「ざっと聞くといかにも正論」に聞こえる辺りが、非常に危険である。
問題点をいくつか列挙してみよう。

「高頻度の更新が必須である」事自体はかまわない。Webにおいて、これが重要であることは確かに間違いのない事実だからである。しかし、この「高頻度」という言葉を真摯に受け止めないととんでもない目にあうこともまた、事実である。

「ユーザからの意見は出来うる限り速やかに(時間単位は概ね時間～日)反映する必要」は、ない。ユーザの意見を唯々諾々と飲み込むことは単純に「Web開発を行う人間の職務放棄」である。以下に理由を述べる。
元々、サイトの仕様というものは(厳密に考えれば文言の一字一句にいたるまで)ある程度の時間をかけて検討されている(はずの)ものである。
そういった(とりあえず)調和の取れたものを新しくするのに、作成部外者の意見に対して脊髄反射のような反応をしてはならない。なぜなら、ユーザは「自分の主観」という、非常に限定された視点から発言しているからである。
もし仮に「ユーザの意見に唯々諾々と従う」のであれば、そのサイトはそのうち「船頭多くして船山を上る」状態になるだろう。理由は簡単で「ユーザはそれぞれが異なる(己という)視点を持つ」にもかかわらず、その視点の差異を考えていないためである。それは「サイトについて考察し、統一性を出す」職務を負っているはずの人間の、職務怠慢以外の何者でもない。「万人受けは誰にも受けない」というマーフィーの法則を、或いは「甘くて辛くてしょっぱくて渋くて淡白で脂っこい」料理を想定してみて欲しい。
「すべてを盛り込む」事など不可能なのだ、はじめから。その不可能に挑戦してみるのは、それがプライベートならかまわないが、ビジネスに持ち込むべきではないだろう。あなたが「あらゆる病に効く万能薬」の存在を信じているのだとしても、なお。
ユーザの意見に真摯に対応するのは良いのだが、少なくとも「ユーザの意図」「意図に対する考察」「現在のサイトに意図をどのように反映するかの考察」「反映のスケジュール」「作成」「テスト」「リリース」程度の手順は踏んでしかるべきである。ユーザの意見を「徹底的に分析」し、「己のサイトとのすり合わせをきちんと行う」ことこそが、真に真摯な態度だといえる。なお、手順の細かい必要性については後述。

「高頻度の更新によって起きるミスは「担当者が注意することによって」回避されるべきである」。
突込みどころがありすぎて何もいえないのだが。一番大きな点を一つだけ突っ込んでおく。
根性論ないし精神論（注意する）だけでどうにかなるのであれば、世の中に管理のための手法など広まりはしない。広まるのは「精神を高める」方法だけである(常識的には思考メソッドがどーのとか。合理性を基準に考える場合暗示法ないし洗脳法の類が手っ取り早い)。
そもそも、誰も間違えたくて間違えているわけではない(ごく少数の例外を除く)。気をつけていてもミスはあるのである。いくら注意深くしても人間の能力には限界があり、だからこそ「ミスしにくい方向を考える」「ミスが検出しやすい方法を考える」のである。ミスが罪悪なのではない(無論少ないにこしたことはないが)。ミスは「事前に検出」できれば、最悪の事態が防げるのである。
その辺りの考察をなにもせず、ただひたすらに根性論を唱えても、事態は解決しない。
あるいは言い換えてみよう。「ミスをしない」ために可能な限りの手段を講じる。その手段を考察するという「根性を」こそ、必要とされているのだ、開発というものは。

更新に対する過度の慎重論

前述よりはましなのだが、やはりいくつかの問題がある。
特に気をつけたいのが「石橋を叩いて壊す」状態である。慎重に議論を重ねてそのまま、などはその典型的な例。
本番稼動後の慎重さは大切なのだが、それは「更新しなくてもいい」と同意語ではない。飽く迄眼目は「出来うる限りの頻度での更新が可能である」だけのフットワークの軽さであり、その軽さを損なわない慎重さこそが必要とされるのだ。
ちなみに筆者が見ている限り、軽微～中程度の更新は、一週間～二週間程度のスパンが好ましく思われることが多い。理由はいくつかあるのだが、概ね「週一ペースの更新」は、見ている人間が比較的リピーターになりやすい一つの目安になっているから、という辺りに集中する。
もう一つは「(比較的)軽微な更新」と「重大な更新」を切り分けること。軽微な更新に過度な慎重論を振りかざしても、あまり利益はない。この辺の切り分けはそれなりに熟練が必要とされるのだが、その辺は各自訓練して欲しい。

フリーズ(仕様凍結)という考え方

本番への反映は、通常(或いは希望的観測として)十分なテストが行われてから、である(少なくとも、正常系とごく常識的に考えられうる異常系ていどは一通り)。
そして、当然のことながらテストは「プログラムが完成してから」である。この場合の完成とは「テストがはじまってから終了するまでプログラムが変更されていない」ことを指す。
ここで「テスト中に発生したバグ」への対応で間違いがおきやすいので記述しておく。
単純なミスに起因するものは無論修正する必要があるのだが。これが「設計ミス」に起因するものの場合、本当にその場で修正するのかは検討する必要がある。場合によっては「特記事項」とし、修正は次回にまわす決断もまた必要である。
話を元に戻して。
テスト中にプログラムに変更があると思うが、取りあえずまず一度「すべてテスト」する（テスト仕様書の項目を一通りなめる）。
で、修正が終わってから、「もう一度」「すべてのテストを」やり直す。これで(後回しにしたバグを除いて)バグがでてこなければ、これで初めて「テスト終了」である。間違っても「テスト中に修正」が入ったときに、修正前のプログラムに対するテストをそのまま鵜呑みで信用しないように。たとえ「全然関係ない」修正でも、それが本当に影響していないとは限らないからだ。
テストがすべて完了したタイミングで、仕様凍結をいったんかける。すべてのリソースをどこかにバックアップし、原則として現在の（つまりテストの完了した）リソースに触れてはならない。これは鉄則である。
したがって、これを逆の捕らえ方で考えると「すべての仕様の確定と変更はフリーズの前に片付ける」必要があり、つまりそれは「テスト前には」出尽くしている必要がある。
可能な限り、バージョン番号を付与することが望ましい。考えるのが大変な場合、日付がその代用となる（例：テストCGI 20020731版）。

フリーズ後の修正

「フリーズしたからもう何もしない」訳には、無論、いかない。軽微な修正から(場合によってはかなりの)大規模修正まで、時間とともに発生していく。
ここで「脊髄反射で」修正することにも「なにもしない」ことにも問題があるという点についてはすでに前述したとおり。
というわけで、「問題を起こさない」程度に「できるだけ迅速な」方法について考えたい。

まず何はともあれ、以下のステップは最低限踏むべきである。

修正意図の明確化と考察: ユーザからの意見であれ内部からの意見であれ、意見についての考察を行う必要がある。特にユーザからの意見の場合「サイト運営から見た」視点で意見を見直す必要がある。基本は一つで「意見の中に含まれる"ニーズの根幹"を如何につかむか」。
ここでしくじると「おかしな更新」「見当違いな修正」が発生する。
現在のサイトに意図をどのように反映するかの考察: ニーズの根っこをつかんだところで、現在の「サイトが持つ根っこ」と如何にすり合わせていくか、を考察。サイトの個性を壊さずに如何に新しい意見を取り入れていくか、という微妙な作業である。
ここでしくじると「(意図する方向がバラバラであるために)よくわからないサイト」が出来上がってしまう。
反映のスケジュール: 反映とその方向性が決まったら、スケジュールを立てる。無理のない程度に「できるだけ早く」行うことが、得てして求められる。
無理があれば結果的に作成物の質の低下に直結し、長すぎると「更新頻度の低い」サイトが出来上がってしまう。
作成とテスト: そのまんま。ただし、特にある程度の規模の変更やある程度の量の変更の場合、できれば一回「全テスト」をやっておくほうが好ましい。
ここでのミスは既知と思われるので省略。ただし、テストの重要性はどこまで語られても語り尽くされることはない。
リリース: テストでOKならば、リリースを行う。このときに、リリースタイミングでの「すべてのリソースのバックアップ」を行う。当然以前のことだが、会員データなど「修復がきかない」データに関しては、事前に十分なバックアップを取ることが要求される。

特に大掛かりな修正の反映手法

基本は似たようなものだが、万が一のことを考えて、以下の要素を考慮する必要が出てくる。
・反映がうまくいかなかったときのロールバック手法とそのタイミング
状況として。「バージョンアップしようとしてうまくいかなくて本番サイトが止まり続けている」状態は、もっとも避けるべき出来事の一つである。そのために「バージョンアップしようとしたけど出来なかったので旧バージョンに戻して取りあえず運用を開始、後日改めてバージョンアップを行う」状況に、せめて戻せるようにしておこう、というのが主旨。
できれば「ロールバックの手順だけをどこかでテスト」できることが一番望ましい。

最後に

本番稼動後のシステムの変更は、大変にデリケートである。したがって、考えるべき方向性は「万が一」である。だれも、ミスをしようとしてするわけではない。しかし、現実にミスはおきうるのだ。
そんな状況を「事前に回避」するために、人は努力して、さまざまな方法論を編み出してきた。先人たちのそんな知恵を捨てる理由は、私には見当たらない。
願わくば、そんな「先人たちの知恵」への興味を、皆様にほんのひとかけらでもお伝えすることができれば。そう思い、執筆をしてみました。

戻る　