ふとあるミーティングで熱く議論した後に思ったことです。

色々な組織レベルで、「会社を活性化するには？」とか「売上を伸ばすにはどうしたら良いか？」という類のアイデア出しやブレーンストーミングを目的とするミーティングや会議があります。
その場で色々と議論、話し合って、(少なくともその時は)ある一定の結論やアイデアを出尽くした感が持ちます。

が、しばらく後…時には数日後などに…やはり(そのミーティングで真剣に考えていればいるほど)、潜在意識で考えているのか、ふと「あ、そう言えばこんな案もあるな」とか「こういうのはどうだろう？」と浮かんで来ることがあります。
そしてそういう考え、アイデアの中に案外、ブレークスルー(もしくはそのきっかけ)が含まれていることもあると思います。

ただ残念なことに、その良いアイデアを伝える、ミーティングの場は既に終わっていたり、窓口が無かったり、分からなかったりします。
そしてせっかくの良いアイデアは表に出ることなく消えていきます。

自分の中に思い浮かんだ時もそうですし、別の機会に「実はあの後で～」なんて聞くと、「おぉ、なんてもったいない」と思うわけです。
なので、こういうミーティングやイベントのアフターフォローとして、継続して意見を言える環境…窓口なりなんなり、方法は色々ありますが…を用意して、明確にしておくのが、おそらく本体のミーティング以上に大事なことでは？と思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

先日、あるサービスから「メンテナンス作業をするので数時間(ブログなどに)アクセスできなくなる」という旨の連絡がありました。

で、そのメンテナンスの日になりました。
が、再開予定時間になっても使用できないままで、提供側の経過報告もほとんどなく…結局、想定の時間を大幅に過ぎてから復旧しました。

1ユーザとしては無料利用とは言え、「残念やなぁ」と気持ちがあったのですが、それ以上に、SEとして…日常業務の「サーバ運用」やサーバ移行作業などの経験から…その経過に興味を持ちました。

今回のメンテナンスがどのような内容か…サーバ移行なのかネットワークの増強なのかなど…は分かりません。
が、この手の作業にはほぼ必ずと言って良いほど「移行手順書(計画書)」の類が作られるはずです。

そこには…
・どのような手順をどのような順番で行うのか？
・それぞれ確認すべき項目は何か？
・タイムスケジュール
…などが記述されているものです。

特にタイムスケジュールは不特定多数向けのインターネットサービスなので、割と厳しめに設定されているはずです。
また、切り戻しポイント…ある時間までにある条件が満たされていなければ、移行を中止する…が設定されていると思います。
＃メンテナンスの作業によっては設定できないこともありますが。

そして、「移行手順書(計画書)」に基づいてのリハーサルも行っていると思います。

で、これらの準備をした上で、本番のメンテナンス作業のプロセスでどこでどんなことがあって、そこでどんな判断の結果、想定外の長いサービス中断となってしまったのか？というのにとても興味があります。

こういう失敗事例は、(社内でも)なかなか分析されず、結果として次に活かされないことが多いように思います。
「やっちゃったわぁ」的な現場SEの経験をもっと共有でき、活かすことができれば、顧客に対して良いサービスを提供できるのにと思いました。
＃「やっちゃったわぁ」の当事者の方々は大変だったとは思いますが。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Goh Rhy Yan