Station-AX

タグ: Slack

  • NoCode はタダではうまく行かないなぁ

    NoCode はタダではうまく行かないなぁ

    タダ＝無料という話。

    最近、仕事とかのコミュニケーションは専ら Slack を使っているのだが、並行してメールも受信している。

    このメールの受信と通知を Slack にできないかなぁと、調べたときの備忘録。

    Slack 側の前提条件

    少なくともプロ版以上の有料プランを設定する必要がある。
    チャンネルにメッセージを直接突っ込むなどのAPI連携は、基本有料プランにする必要がある。

    メール ⇒ Slack 連携で利用するブリッジサービス

    選定したのは、とりあえず以下。

    • Make（旧 Integromat）
    • Zapier

    いずれも有名なグローバルサービス会社であったのが選定の理由。
    考え方は安直だけど、ビジネスの継続性とか発展性とか、それがまぁまぁ重要な理由でもある。

    GMail ⇒ Make ⇒ Slack

    最初に試したのがこれ。

    Google の API 開放手順がかなり面倒

    まぁこれは、Make 内に対処手順が動画やドキュメントが事細かくあるので、頑張って英語と戦って対処すれば何とかできる。

    ISO-2202-JP 非対応

    これが Make 利用を断念した最大の理由。
    一応 Make には、文字コード変換するためのコンバーターがモジュールとして提供されてはいるのだが、ShiftJIS には対応してるものの ISO-2202-JP は非対応。

    これを対策するには、別途 Webhook かなんかで ISO-2202-JP ⇒ UTF8 変換するサイトかなんかを作成して、それを通してから Slack に投げ込むしかない。

    もしくは、ISO-2202-JP がこの世界から滅んで、全ての文字コードが UTF8 になれば良い。

    それはさておき、この Webhoock を実装・設置するのを今すぐはできないので、ここで一時保留。

    IMAP ⇒ Make ⇒ Slack

    これも技術的には問題ないけど、やはり ISO-2202-JP 文字コードの問題が歓待に解決できないので、保留。
    Make を使う以上は、この問題がずっと、つきまとう。

    GMail ⇒ Zapier ⇒ Slack

    @gmail.com の場合、連携不可能

    Google Workspace などを利用し、企業ドメインなどを GMail で受け取っている場合は、モジュールを接続するだけで連携することができる（みたい）

    しかしながら、@gmail.com など（「一般消費者アカウント」と言うらしい、これ）を利用していて、これを外部連携やサードパーティアプリなどと連携する場合は、認証には OAuth が必要になる。

    GMail(IMAP) ⇒ Zapier ⇒ Slack

    GMail を使う場合、おそらくこれが最も現実的な連携方法なのかも知れないが、この場合「安全性の低いアプリ」として当該アカウントの許可設定をする必要があり、それはそれで不安。

    IMAP ⇒ Zapier ⇒ Slack

    そもそも IMAP で繋ぐのであれば、自分の場合は GMail に拘る必要がないので、別のメールサービスを使って IMAP を使う。

    ISO-2202-JP の問題は特に発生しない。特に文字コードの仕掛けは必要なく、普通に ISO-2202-JP のメールも文字化けなく Slack に配信可能。

    ところが、フィルタを追加すると有料。

    というのも Zapier を無料で利用する場合はシングルステップのみ、しかも月間100タスクまでという制限がある。

    指定メアドに着信したメールをすべて Slack に流して良いのであれば、以下のようなシングルステップとなる。

    IMAP⇒ Slack

    これであれば、月 100 タスクまでであれば問題ない。
    （100 タスク ≒ 処理 100 回、まぁメール100通だけという訳ではないが、正直これはこれで心許ない。）

    しかしながら「題名」や「送信者」など、特定条件のみのメールだけをフィルタリングしてメッセージを Slack に流す場合、別途「フィルタ」という処理が別途必要になる。つまり以下。

    IMAP⇒ フィルタ ⇒ Slack

    これだと処理的にはマルチステップと見做されるらしく、そしてマルチステップは Free プランで利用できない。Starter プラン以上の有料プランにする必要がある。（2022 年 11 月現在、およそ $20/mo …）

    詰んだ。

    そもそもの話

    Slack はプロ版以上だと、チャンネルに個別にメアドを取得することができるので、そこに直接放り込まれるような仕掛けにしたほうがいいのかも。

    とはいえ機械的なメアドをそのまま送信者に案内するのも何なので、判りやすいメアドを別途取得して、以下のような感じにするのが良いかと思ってる。

    メアド1
    （判りやすいメアド）
    ↓
    （転送）
    ↓
    メアド２
    （Slack チャンネルと連携している機械的なメアド）
    ↓
    Slackチャンネル

    多分コレが一番手間も余計なカネもかからない気がする。

  • Python と git と Redmine

    最近、色々な場面で Python がプログラム言語として仕事や話題に上がってくる事が増えたので、ちょっとこのタイミングで勉強しようかと。

    丁度、ChatWork から Slack への引越データが公式が提供するインポート／エクスポート機能だけでは上手く移転できないのと、引越のついでにデータの中身（添付ファイルのリンク先とか）を少しイジりたかったので、これらの変換プログラムを Python でやってみることに。
    （プログラム自体は多分使い捨て。ゴミプロになる予定。）

    さらに「ついで」として、プロジェクト管理で使用している Redmine。こいつも git と繋ぎ込みできるため、その環境も整備する方向で。

    ちなみに今のトレンドだと、GitHub とか GitLab とか使うんだろうけど、以下の点から見送り。

    • Redmine でプロジェクト管理を網羅的運用してる。
    • 基本的にプライベートリポジトリ（非公開のプログラム）しか作らない。
    • 便利な機能色々あるだろうけど、今回は「リモートリポジトリ置き場」以上の機能は不要。
    • 英語をはじめ、外野からどうこう言われたり、対応するのは面倒。

    …そのうち気が変わって、使い始めるかもしれませんが、現状はこんな感じで。

    でもってリモートリポジトリは、Redmine のサーバとは異なるサーバで運用している。
    このような場合、Redmine サーバまわりで若干トリッキーな構築が必要になるので、これも併せてやってしまう。

    ・・・なんだか「大盛り」にしすぎですかね。。。

  • メーリングリストを別サービスに置き換えるための課題

    Line や Slack などのサービスを利用する？

    そのためにはまず、サービスの「将来性」を見極める必要もあります。
    たとえば長期利用可能か、一般的に認知されているか、など。
    近い将来にターミネートを迎えるサービスは勿論、無料⇒有料化されてしまうとか、制限が厳しくなるようなサービスはもちろん、サービスが社会的に認知されていること、「知る人ぞ知る」というようなサービスも選択は困難。

    あと大きな問題として「費用」。
    そして便利なサービスを利用するためには、有料サービスが「壁」となってしまいます。
    たとえ月々 500 円でも、100 名だと５万円、年間 60 万かかるようなランニングコストを支払うことになります。

    無料サービスだけで運用することも、ある程度は可能かもしれません。
    しかしながら、履歴が検索できない点をはじめとする制約が壁になったりします。
    無理矢理利用するために、トリッキーな運用をするのも、管理が煩雑になることだってあります。

    引き続きメーリングリストサービスを利用する？

    急場を凌ぐ意味で、引き続きメーリングリストサービスを利用するのもアリです。
    盲目的にメーリングリストを重宝している会社も多くあります。

    しかしながら様々なSNSが台頭してきた社会において、メーリングリストは最早レガシーなシステムとして位置づけられています。
    実際、Webサービスとしてメジャーなのは、もはや「Google グループ」だけになってしまいました。
    無料で提供されているサーバソフトウェアも、メジャーなものは fml など、選択肢が限られてます。

    このような選択肢の少なくなりつつある状況を考えると、メーリングリストの将来は暗く、利用できなくなるのも時間の問題かも知れません。

    それに、大量のメンバーにメールをばらまくこのシステムは、

    • メールは、すぐに埋もれてしまう。
    • 埋もれないよう、受信者が努力する必要がある。
    • 一度埋もれたメールを探すためには、手間がかかる。

    というような感じで、利用者にコストやリスクを負わせてしまいます。
    またウイルスやSPAMメールをばらまく機能として使われることもあり、通信業界でも度々問題視され、今後メールフィルタリングの対象となる可能性だってあります。

    しかもメールリストによる情報伝達は、情報を受け取る側の意識として、たとえ重要な内容を含んだものであっても「ダイレクトメール」扱いになってしまう傾向があります。
    つまり優先順位が低い扱いとなってしまう、「訴求力に欠ける」というのが実状だと思います。

    メールでの情報伝達というのは、正直なところ限界にきつつある思っております。
    Slack をはじめとした、全く別のSNSサービスを利用するような「前向きな検討」をするほうが、健全な気がします。