見出し画像

青い鳥の某SNSの最近の動向に見る持続性の話。

一般的な言葉なのか分からないですけれど、サードパーティ製アプリというものがあるかと思います。

青い鳥さんアイコンの某SNSは、この note のアカウントにも紐付けていますし、私は普通にリアルのアカウントも持っていたりします。それで、公式でないアプリ、つまりサードパーティ製のアプリも使ったりしていました。公式アプリにはない便利な機能があって重宝していたんですよね。

ところが、今月の12日に、いきなりそのアプリが使えなくなって、その時は「なんかのメンテンナンスかなー」と思っていましたらば、しばらく経っても全く復旧せず、19日になって、どうやら正式にほとんど全てのサードパティ製アプリが禁止、つまり締め出しになっていることが判明。

https://news.yahoo.co.jp/articles/f21e423b01a6884c2bbf46fa45101aba19c324b4

https://pc.watch.impress.co.jp/docs/news/1471951.html

https://www.techno-edge.net/article/2023/01/20/735.html

その背景と言いますか事情だったり排除の理由は、現時点では明らかになっていないですが、方々で様々な推測が飛び交っているようですね。

正直、企業の経営方針とかそういったものは、所詮、一ユーザが口出ししてどうのこうの言っても仕方ない面があると個人的には思うので、私としてはこの判断について何も言うことは無いです。今回の件は、ちょっと不便だけれど公式アプリを使えばいいだけの話なので。

ただ、経営方針はどうでもいいですが、ふと「企業」つまり「組織」ということを考えた時、なんだか色々と思うところが出てきたので、少し綴ってみます。

まず、この青い鳥さん企業については、経営者つまりトップが変わったことで、劇的なスピードで社内のアレヤコレヤが変わっていったように見えます。そして内部だけではなく、我々ユーザサイドなどの外部にも結構影響が出ちゃっていますよね。サードパーティ製アプリの禁止もその一環で。

で、トップが変わると、会社そのものもかなり変わるのは当然だと思います。しかも、そのトップがアクティブに色々やる人であったりする場合、会社の手続きやサービス自体もかなり変わっていくスピードが速かったりします。

何が言いたいかと言いますと、私の勤めている会社は、経営層のフットワークがかなり軽いんですよね。そのため、会社の事業だったり、組織改編だったり、そういった社内の基盤的なものがもう結構な頻度で変わっていきます。つまり、トップの判断として、色々な意思決定が早く、かつ柔軟に変化していくわけです。

これは一長一短あって、経営が身軽であればあるほど、事業としてマイナスの兆しのあるものは迅速に手を引く判断をすることができますし、あるいはブルーオーシャン的な領域で時季を見極めてチャンスを掴んだりもしやすくなると思います。ですが一方で、朝令暮改で変わっていく方針に対して、それについていく社内の従業員はなかなか大変だったりします。

青い鳥の会社と私の勤め先を一緒にはできないですが、ガンガンと引っ張っていくトップと、それに振り回されて四苦八苦する下々の者、という構図は何だか似ている気がして、しみじみと考えてしまったわけです。

さて、ここからは想像ですが、それによって何が起きるのか、考えてみます。私の経験も踏まえて。

まずは、従業員が離れていくと思います。フットワークが軽く、方針転換が頻繁にあると、「もうついていけない・・」と思って、辞める人が出てきます。ただ、それは別にその人が劣っているとか、残っている人が優秀だとか言うわけではなくて、単純に会社のカラーが合わなくて辞めていくものだと私は考えています。

で、その一方で、会社がどんどん人を採用する方針であれば、辞める人がたくさん出てくるものの、入ってくる人も増えていきます。組織内の循環と言いますか、流動的になります。

そのことは良い面もあれば良くない面もあるでしょう。

たとえば、人の流れが激しければそれだけ個人のスキルも多岐にわたるものが身に付きますし、何より、属人的であれば業務が回っていきませんから、おのずとマニュアル化していきます。そうすると、スキルが低かったりマッチしていなくても、それなりに仕事ができるようになります。だから、たくさん人が辞めても、新しい人で賄うことができるようになります。あとは、取引先に対しては、担当者がすぐに変わってしまうので癒着などの問題が起きにくくなるといった面もあるかと思います。

他方で、それだけ人がコロコロ変わっていくと、業務スキルのバリエーションは広がっても、スキルや知識、経験が個人の中に蓄積しづらくなるように思えます。もちろんその人それぞれの意欲とか適性もあるので一概には言えませんが。また、仮に従業員のスキルレベルが低くても仕事ができてしまうと、それだけでコストと言いますか、本来支払うべき賃金とギャップが出てくる可能性もあるかと思います。さらに、人材が定着しないことで、愛着と言いますか、愛社精神みたいなものも持ちにくいです。場合によっては、職場の中で「お前の代わりは幾らでもいるのだ」といったようなパワハラの風潮も出てくる可能性もあります。

ただ、いずれの場合でも、会社も必死なわけです。好き勝手に業務や運用をコロコロ変えているわけではありません(と思いますが・・)ので、事業として生き残っていくためには、必要な経営のアクションであると思うわけです。生き残り、つまりそれって「持続」していくために必死なんですよね。

何と言いますか。私が以前働いていた職場の中には、これとは全く真逆で、めちゃくちゃのんびりしている会社もあったんです。安定第一、事なかれ主義、そこに居るだけでお給料貰えますけど仕事は死ぬほどつまらないです、みたいな。

そういう毛色の違う職場を幾つか経験していると、本当に会社によって様々だよなぁ、なんて思います。どっちの会社のほうが良いというわけではありませんが、会社も働く人も、色んなスタイルをとっていて、必死なわけです。持続するために。

さて、というわけで、話を強引に戻します。

Twitter(あっ明言しちゃった)アカウントに、この note の新着記事などを同期していたわけですが、今後またどのように方針が変わるか分かりませんので、新たな SNS サービスも同期の対象にしてみました。まぁ同期と言いますか、遊びがてら新着記事の宣伝をしてみる次第です。

取り急ぎ、代替先としてよく挙げられがちな、Mastodon(マストドン)です。これを機にアカウントを作ってみました。
https://mastodon-japan.net/@asaburosan

私は初めてこういうタイプの SNS をやってみましたが、なかなか独特なんですね。

おおもとのデッカイ元締めというか中心的な場所があるというよりは、それぞれ有志がサーバを立てて、その中でアカウントを作って(ユーザを受け入れて)運用していくといったスタイル。運営も方針もそれぞれのサーバで異なっていて、言わばカラーが違うようです。例えるなら、まるで、それぞれの村みたいな感じでしょうか。それで各人は自分に合ったものを選ぶ、と。

それが「分散型ソーシャルネットワーク」というものらしいです。

さて、マストドンへのデータ連携について。

これはもう簡単でした。ネットでもたくさんサンプルあったので、それを見れば容易にコード書けました。たとえば、こんな感じです。

from mastodon import Mastodon

url = "https://mastodon-japan.net"  #使用インスタンスのアドレス

Mastodon.create_app("asaburosan_handmade",  #クライアント名(自由)
                    api_base_url=url,
                    to_file="cred.txt"
                    )

mastodon = Mastodon(
    client_id="cred.txt",
    api_base_url=url
)

mastodon.log_in(
    "xxxx@xxxx",  #ログインメールアドレス
    "xxxx",  #パスワード
    to_file="auth.txt"
)

今回もまたPythonで作りました。

まずは pip で Mastodon ライブラリをインストール。それから、マストドンに接続して API 実行するためのクライアント名を指定して、クライアントIDファイルと、ログインに必要な認証ファイルを作成。マストドンのアカウント(ログインするためのメールアドレスとパスワード)もそこで指定して無事に接続完了。この処理は一回だけで大丈夫な模様。あとは、出来上がったファイルを使いまわせばOKです。

次は生成されたファイルを使ってつぶやくだけです。

  mastodon = Mastodon(
        client_id="cred.txt", 
        access_token="auth.txt",
        api_base_url = "https://mastodon-japan.net")
 mastodon.toot("メッセージを何かつぶやく")

マストドンでは、つぶやくことを toot と呼ぶそうですね。toot メソッドを呼び出して、つぶやきたいメッセージを引数に渡して実行してあげるだけです。

そんなこんなで本当に簡単にできました。

ちなみに、マストドンのほうにつぶやく内容は基本的にTwitterと同じで、新着記事の宣伝メインです。Twitterのほうでは、それ以外にも今日のできごととか天気予報とかつぶやかせてますけど、マストドンのほうにもつぶやかせるかは未定です。やってもいいんだけど、なんか大して情報量無いのに、そんなにいっぱいつぶやかせてもなぁ、と。

↓出来上がりはこんな感じです。

つぶやいている内容は
Twitterのほうと同じく新着記事の宣伝

ただ、注意点と言いますか、実際このコードを書いたり何だりといった本筋以外のところで、実はかなり手こずったので、備忘録的に残しておきます。

1.APIが使えないサーバがあった

サーバというとちょっと分かりにくいので、マストドン的に「インスタンス」と呼びますが(もっと分かりにくい・・)、このインスタンスによっては、APIがそのまま使えないことが分かりました。

上記の通り、私は「mastodon-japan.net」というインスタンスでアカウントを作らせていただきましたが、当初は別のインスタンスでアカウントを作っていました。そこで API を試したら何だか知らないが最初からエラーが出ちゃって動かなかったんですよね。どこかは言いませんが。

で、ネットで色々調べているうちに、ザックリ言うとそこのインスタンスでは制限がかかっているということが分かりました。
詳しくはこちら。
https://github.com/halcy/Mastodon.py/issues/213

ただ、そこまで時間をかけたくなかったので、今回は場所を変えて行うことにしました。で、引っ越し先の「mastodon-japan.net」では、普通にAPI 実行できたという話です。

2.exe ファイルが作れなかった

以前記事にも書きましたが、この note の内容をはてなブログに同期させたり、Twitter で新着記事を宣伝したりするときに、Pythonのコードで書いていまして。で、それを実行する際には、そのソースコードごと exe ファイルにして、ファイルをポチっとダブルクリックなりして実行すれば動くようにしているんですね。

マストドンへの同期も同じように、そのPythonで作ったプロジェクト内のコードに含めて書いていたのですけれど、どうしても exe ファイルに出来ないわけです。いや、ファイルはできますけれど、実行するとエラーになってしまうのです。どうしてかなと調べてみると、どうやら、上記の認証ファイルなんかが正しく読み込めないようでした。--add-data してデータファイルとして組み込んだり、Tempフォルダからファイル抜くようにしてみたけれどダメで。

まだ解決していないのですが、暫定措置として、結局、ファイルは exe には含めずに、別出して読み込ませるというイマイチな手法をとることで一旦は解決しました。ただ、できればこれもいずれは1ファイル化したいなぁ、と思っています。

そんなこんなで、こちらも持続的に、チョコチョコといじって遊んでいければいいなと考えています。こちらもTwitter同様、あくまで bot 的と言いますか、自動投稿がメインになってくるとは思いますが。おしまい。

この記事が気に入ったらサポートをしてみませんか?