私は出始めから「Slack」というものがなぜあるのかわからなかった。コンピュータネタ、目次へ
流れに入っていくためには、やりとりを最初から追いかけたほうがいいのは分かるが時間的には無駄だろう、と思ったわけだ。いままでの話を自動で要約する機能が付いていれば別だが、一人の人が書いた文章よりも複数人の会話をまとめるほうがはるかに難しいのは自明の理である。さらには各人の意見が徐々に変わっていくのがむしろ普通だし。が、よーやく思い出した。それ、自分の会社では「不要」と判断されたのでそういうもんだと思っていたのだ。1998年のことである。
（ちなみに当社でディクレはありえない。それまでメインフレームがほとんどであったシステム開発にダウンサイジングを取り入れようということになったキックオフミーディングで、新たに考慮しなければならないルールは何か？という話になった時に「コンパイル環境があちこちにできるから、コンパイラとライブラリの管理ルールを作る必要がある。そうしないと同じソースから異なったロードモジュールができてしまう」と主張したら「そんなことはありえない」と却下された。1992年の年末であった。）長野オリンピックのころ、私が考えたのはこういうことである。
システム障害がおこる。当然対処する。ここで情報の流れを整理し、誰にでも見えるものとする必要がある。運用部門や現地で対処している人間からの報告、ユーザー部との連絡事項、これらを複数人が電話で受けてホワイトボードに書き込んでいくだけでは経験的に情報が錯綜する。さらにキーマンを上席が呼んで状況をヒアリングする間、判断を仰げないので対処が止まってしまうのは避けたい。（しかも、次長と部長が同じことを尋ねるために別々に呼んだり。）
ならば障害のたびに電子掲示板を立ち上げて、そこに報告や指示事項を書き込むようにしよう。上席に報告する代わり、それを読んでもらって質問があれば書き込んでもらう運用にしよう、そうすれば情報は一元化され、キーマンは集中して対処に当たれる。さらには障害収拾完了後、各発言をタイムスタンプとともに見ていけば良かった点、改善点も見えてくるだろうから、次回以降の対処がスムーズになる。
というわけでこのためにPerlを覚えて掲示板ソフトを書いた。もちろんであるが動いた。なお参加は自由だが登録は必要（誰が見ているか、一覧できないと予期しない報告事務が発生する）。当然登録も自動化しているが。ポイントは何か？
トピックごとにスレッドを起こすということよ。
（障害対応なら１障害＝１スレッドが自明だろうが、多くの場合はスレッドを分割したり、まとめたりしたほうがベター。Slackはこれをうまくやってくれるというならまだ話は分かる。）
あと、スレッドの内容をまとめる、ということ。
こうすればシステム障害対処は、今できる最短の時間で完了し、さらに改善してゆくことだったろう。が、「却下」。
理由は「上席への報告で対処が遅れるということはありえない。」みなさん「ありえない」が好きだったなあ。「借用して返さないということはあり得ない。」「火を貸して、ってその火を返しますか？（情報を借りれば媒体は返せても情報そのものは返却できない、ということを比喩を使って説明したつもり。）」
関係者引退したからもう書いちゃっていいでしょ。