チャットワークの使い始めはまずこれだけ覚えよう「グループチャットでのお作法」

新型コロナウイルス感染症の影響によって働き方が変化しています。新しい生活様式を日常生活に取り入れ、毎日通勤出社する生活から在宅勤務へ移行。特にデスクワークなどどこでもできる仕事に携わっている方は、極力出社を控え、ウェブ会議やチャットを導入して働き方のスタイルがテレワークに急速に変わりつつあります。

マネジメント層の方々のなかには、新型コロナウイルスを契機に、場の共有の大切さやリモートでも対応可能なところなど、いままでの働き方では分からなかった業務メリットを認識した方も多くいるでしょう。仮に収束しても、オフィスを半減したり解約をしたり、業務改革の推進計画を立案したり、働き方が元に戻らず、在宅勤務が定着する兆しもあります。

シングスで行う制作開発や保守管理サービスでも、以前からチャットツールを使ってクライアントと業務を円滑に進めてきたため、業務に影響はほとんどなく進められました。とくに保守管理サービスでは、事業継続計画として機能し障害対応や復旧対応をあらかじめ立案しているため影響を最小限にとどめています。

周りを見渡すと、多くの企業で急遽在宅勤務の環境を整備するところがたくさんありました。PCやネット環境を整えたり、ウェブ会議にチャットに対応したり、慣れないことばかり。

今回チャットツール「チャットワーク」を取り上げて、グループチャットでのお作法としてこれだけ押さえれば、スムーズに参加できてコミュニケーションが取りやすくなるポイントを 3 つ紹介したいと思います。もちろん他のチャットツールでも通用する基本的なことですので応用してみてください。

はじめてグループチャットに参加してみたけどやり取りはどうすれば、いいのか分からないこともあるでしょう。使い続けて慣れてくれば徐々にわかってきますが、はじめの一歩として参考になれば幸いです。

なぜ「チャットワーク」を使うの?

チャットツールは、チャットワーク他、Slack や Microsoft Teams、LINE WORKS などビジネス用途だけでもたくさんあります。その中で「チャットワーク」をメインで使っているいちばんの理由は、フラットな関係性をつくりたいから。

チャットツールを使うだけでも拒否感を持ったり、他ツールと違ってエンジニア優位に見えなさそうなところから。チャットルーム毎の対象は、ブロガーなど個人の方、小規模から中小中堅の企業と多彩なため対応しやすい。グループチャットに参加する方は、直接の担当者はじめ、社長、総務など管理部門の方など様々な関係者が複数の方が入っています。コミュニケーションの取りやすさと双方向的に情報共有ができる環境を作って、チャットツールを初めて使う方やITに疎い方にも使えるように心がけています。

場をオープンに共有する意識の会話に慣れよう

グループチャットでは、通常のダイレクトな 1対1 のチャットや閉じられた中での数人の限られた人との会話と違い、参加者すべての方と一緒にチャットルームの場をオープンに共有する意識を持つことが大切です。

お互い持っている問題意識や課題を共有し、今何が問題なのか現状を多角的に把握しやすくなります。問題解決のアイデアもたくさん出やすい。履歴が残るので、進捗も随時把握できる。引き継ぎ業務も容易になります。次第に先を見越した取り組みを行うことができるようになり、業務遂行も早まります。

グループチャットに初めて参加する方には、テキストでの会話に慣れることが大切です。

まずは「メッセージを入力」欄でメッセージを送信してみましょう。チャットワークには、あらかじめ自分だけのチャットができる「マイチャット」があります。そこでメッセージ投稿の練習をしてもいいでしょう。

メッセージを入力する

また慣れないときは、一行ごとにメッセージを複数回送信してしまう方をたまに見受けられます。「メッセージを入力」欄は複数行の入力をして送信できます。メッセージを受け取る側はメッセージが来るたびに通知音がなったり、バイブレーションが発動するので、複数のメッセージを送るときは、話題で切り分けるなど適切な長さのメッセージを送る配慮を心がけましょう。

誰に向かって会話をしているか分かるようにしよう

グループチャットは、参加者全員で会話すべてを共有する場になります。その場である特定の人や複数人の人だけにメッセージを送りたいときがあります。複数の人が参加するグループチャットでは、会話の流れを見える化する上でも相手を呼びかけ明確にすることは大切です。

よく見られるのは、メールの使い方を引きずっている方です。使い続けていくうちにチャットに慣れてくれば次第になくなりますが、メッセージの冒頭に挨拶文を付けたり、〇〇様と宛先を付けたり。

全員に共有する場合、そのままメッセージを送るといいのです。しかし、そのメッセージが誰に対して発言している場合は、誰かがわからないので、誰に向かって会話しているか分かるようにしたほうがいいでしょう。

チャットツールには誰に呼びかけるか参加者を指名できる機能があります。チャットワークでは「TO機能」です。

「TO」アイコンをタップすると、グループチャットの参加者一覧が表示されます。そこから参加者をタップして選んで (複数人も可) メッセージを送るだけです。

メッセージの相手を指名する:TO機能

メッセージには、誰に向かっての発言かがわかるので、返事ももらいやすく、グループチャットでは会話の流れが把握しやすくする配慮を心がけましょう。

会話が続くように返信をしよう

メッセージには、できる限り返信しましょう。メッセージに対して返信メッセージが送れるので、返事を返して疑問に思うところを遠慮なく聞いてみたり、意思の疎通を図って相互理解を深めましょう。グループチャットは、そのやり取りの回数を重ねることが、自分だけでなく周りの参加者にも共通認識が深まり、信頼感の醸成に繋がります。

メッセージを返信する

また報告や連絡に対していちいち返事を返すのが正直面倒なところもあります。特に定時または定型的なメッセージの場合。その場合は、絵文字でリアクションだけでも返すようにしましょう。円滑なコミュニケーションにとってメッセージに対して何も反応しないよりましになるかと思います。

メッセージにリアクションする

以上を心がけるだけでも参加者全員で会話の流れが把握しやすく、コミュニケーションの取りやすさと情報共有に役立つグループチャットの場になるかと思います。是非参考にしてみてください。

WordPressプラグイン「WP Auto Updater」に通知機能が付きました

WordPressの本体 (コア)、テーマ、プラグイン、翻訳を自動更新するプラグイン「WP Auto Updater」には、今まで更新したテーマやプラグインなどのアップデート履歴を記録し、管理画面上で確認できますが、今回バージョン 1.4.0 へアップデートに伴い、新たに更新完了時にメールで更新内容を通知する機能を実装しました。

通知を有効にしていると、こんな感じのメールが届きます。

タイトル:
[シングス] プラグインは自動的に更新されました

本文:

次のプラグインは正常に更新されました:
WP Auto Updater v1.4.0 (upgraded from v1.3.0)


アップデート履歴を見る
https://http://example.com/wp-admin/index.php?page=wp-auto-updater-history

通知メールは、本体・テーマ・プラグイン・翻訳毎に受け取りたい通知を有効/無効ができます。
またメールの宛先、送信先も管理者権限グループを持っているユーザーを受取人に選択できます。
管理画面からいろいろ設定できますので、運用に合わせて活用できます。

管理画面はこんな感じ。

WordPressプラグイン「WP Auto Updater」の管理画面

是非試してみてください。

カスタム投稿タイプのデフォルトウィジェットブロック一式が詰まったWordPressプラグイン「Custom Post Type Widget Blocks」をリリースしました

カスタム投稿タイプで活用できるデフォルトウィジェットブロック 7 点が詰まった WordPressプラグイン「Custom Post Type Widget Blocks」を作りました。

WordPressプラグイン「Custom Post Type Widget Blocks」は、以前つくったウィジェット版の WordPressプラグイン「Custom Post Type Widgets」のブロックエディタ版です。

WordPress 5.0 から標準エディタがブロックエディタになりました。それに伴い、ウィジェットはブロックエディタに統合されていくことを見越して、ブロックの作り方をちょこちょこ学びつつ作ってみました。

機能は、Custom Post Type や Taxonomy で絞り込みができる以外は、標準のウィジェットブロックとほぼ同じです。
ある程度安定した状態になれば、将来的に機能を追加して拡張していこうかと思います。

是非ブロックエディタで活用してみてくださいね。

WordPressテーマ「Foresight」がレビューを経て wordpress.org 公式ディレクトリに掲載されました

WordPressテーマ「Foresight」が wordpress.org 公式ディレクトリに掲載されました。

WordPressテーマ「Foresight」は、公式ディレクトリ登録を目指していたので、テーマ開発に取り組んで目標の一つを達成できて一段落つきました。これからもテーマの改良を続けてブロックエディタの活用を充実させたり、いろいろ研究開発を行っていきたいですね。

ということで、公式ディレクトリ登録を行う上で欠かせないテーマレビューはどのようなものか。2ヶ月ほどやり取りしていたレビューの所感を綴ってみたと思います。

WordPressテーマ「Foresight」の詳細や作ったときの感想は、以下を見てください。

テーマレビュー経緯

テーマの登録申請を2019年11月25日にしました。
その時のテーマレビュー待ち200余り。
とりあえず気ままに待つことに。

待つこと3ヶ月ほど。
2020年2月13日にレビューアさんが付いてくれました。
途中新型コロナウイルスの大流行で滞りなくレビューが進むのが心配していましたが、普通にレビューが進んでいきました。こういうときにコミュニティが機能しているありがたさが実感できますね。

最初のレビューは、作ったWordPressテーマが、Theme CheckTheme Handbook のガイドラインに準拠しているかを主に診てくれます。

そして、修正をしながら進めていくとさらにソースコートを隅々まで詳細にレビュー (complete review) してくれます。

指摘されて改善したところ (パート1)

  • ディレクトリ構成が少し特殊な形なので、構成やファイル名を見直した。
  • JavaScript ファイルは minified しか入れていなかったので、レビューできるように生のソースも追加で入れた。最初 webpack でバンドルしていたけど、出力される生のソースも特殊な出力なのでレビューできるかどうか分からなかった。ということで普通の結合 (concat) に変えた。
  • オプションのデータの持たせ方を変えた。取り回しが効きやすいようにいつも複数の options に分けて入れているけど、公式テーマだと theme_mod (一つの配列) に入れるようにすることが大切。参考: Customizer Objects#Settings
  • タブキーでのフォーカス移動などキーボード操作できるようアクセスビリティをしっかり診てくれた。特にドロップダウンメニューが展開するグローバルメニューの部分。普段キーボード操作をあまり意識していなかったのでこういうところも大切だなぁと改めて気づいた。
  • テンプレート階層を少し触っているのでそのことを聞かれた。理由を説明するとすんなり受け入れてくれた。そんなに厳格さはなく、柔軟に対応してくれるようだ。

やり取りと修正を2回ほど繰り返し、ひとまず承認された。

次にダブルチェック的な最終テーマレビューへ進む。
少しベテランな感じ?のレビューワーさんが付いてくれました。
更に細かい部分まで診てくれる。特にセキュリティ面でエスケープやサニタイジングのところ。

指摘されて改善したところ (パート2)

  • エスケープやサニタイジングを結構見落としているところがあった。のでチェックしてくれるの助かる。
  • コピーライトやクレジットの表記の見直し
  • readme.txt ドキュメントの見直し
  • ライセンス上使っていい CDN や画像などサードパーティリソースの見直し。スクリーンショットを変えた。
  • 標準コアにあるカスタマイザの機能を一部削除していたのでその調整をした。
  • javascript のグローバル変数の扱い。プリフィックスをつけるか、または即時関数にしてローカルオブジェクトにする。
  • デザイン的にボタンやメニューを画面に fixed すると。ログイン状態でページを見る場合、adminバー (ツールバー) に重なるところがある。位置をずらして重なりを回避するの厄介だった。バーの高さは通常PCで32pxでタブレットやスマホビューで46pxに変わる。adminバーはスクロールしても上部に固定されているが、スマホビューでは挙動が変わり、固定がなくなる。その高さと挙動に合わせて fixed している position を CSSやjavascriptで調整。

やり取りを繰り返し、2020年4月26日にレビューが終了した。
即日 wordpress.org にあるテーマページが公開されて、7,472点あるディレクトリ掲載テーマ (2020年4月28日現在) の一員に加わりました。
晴れて Theme Developer になりましたとさ。

WordPressテーマを公式ディレクトリ登録してみてよかったこと、感じたこと

  • WordPressエコシステムの土台に乗って世界中で幅広い人に使われるように、レビュー済みで一定の品質基準を確保した WordPressテーマができた。
  • いままでテーマの公式ディレクトリにはあまり縁がなかったけど。独自機能を実装したテーマと公式ディレクトリに掲載される準拠さをもったテーマとの技術的な比較基準をもつことができた。
  • 公式ディレクトリに登録されているテーマの完成度が上がっている。これからも上がっていく感。よく言及されるスクリーンショット映え感ではなく技術実装面で。以前はブログ用途とかスキン的な感じのテーマが多かったりソースコードを見るとグチャグチャな感じも見受けられたけど。ブロックエディタとの兼ね合いなのか技術的にそれなりのレベル、また幅広くトータルなレベルが求められている感じがする。今後テーマを一人で作り切るのはスキル的に求められるものが多くなりそうで大変そう。チームでテーマを開発するとかに進むのかなぁ。
  • 機能面の充実より、用途の提案とか、コンセプト面の充実がテーマに求められそう。そのほうが活用の広がりが生まれる。
  • 今回テーマを作ったり、WordPressテーマスタータキット「WP Theme Boilerplate」を開発したりしてきて。WordPressテーマの開発は、スクラッチから作ったり、フレームワークから作ったり。公式テーマや無料有料テーマのありあわせものでサクッと立ち上げたり、カスタマイズしたり。多様なアプローチが取れるようになってきていると思う。その都度ふさわしいやり方を選んでプロジェクトが進められそう。プロジェクトマネジメント面の発展とかにつながる。

可能性が広がっているなぁと感じる今日このごろです。

さくらのレンタルサーバでSSH接続して環境を整える (AWS CLIをインストールするまで)

SSH接続ができるレンタルサーバーも増えてきました。
さくらのレンタルサーバもそのひとつ。
今回 AWS CLI を使いたいため、さくらのレンタルサーバ (スタンダードプラン) にSSH接続して、AWS CLIをインストールしてみました。

ターミナルでさくらのレンタルサーバにSSH接続。

さくらのレンタルサーバのサーバー環境は、

  • FreeBSD
  • 標準のシェルが csh
  • 標準のテキストエディタ vi
  • Python が 2.7.x

という環境です。

さくらのレンタルサーバは、git や WP-CLI もすでにインストール済みで結構使える。

まずは、環境を整える

  • 標準のシェルを bash
  • 標準のテキストエディタ vim

に変更。

ログインシェルを bash に変更する

chsh コマンドでログインシェルを bash に変更する

chsh -s /usr/local/bin/bash

設定ファイルを作る。

touch ~/.bash_profile
touch ~/.bashrc

.bash_profile の中身を書く。

vi ~/.bash_profile
if [ -f $HOME/.bashrc ]; then
    source $HOME/.bashrc
fi

PATH=$PATH:$HOME/bin:$HOME/usr/local/bin:$HOME/.local/bin
export PATH

一度ログアウトして再ログインする。
ログインシェルが bash に切り替わる。

標準のテキストエディタを vim に切り替える

which vim

すると、vim はすでにインストール済みなので。

.bashrc の中身を書く。

vi ~/.bashrc
alias vi='vim'

vim の設定を変える。ここはお好みで。

  • カーソルキーでカーソル移動ができるように (カーソルキーでABCDと入力になるのを避けるため、vi互換モードを off に。通常のカーソル移動は「h,j,k,l」)
  • バックスペースキー (Macだとdeleteキー) で文字を削除できるように

以上の設定は、.vimrc を作って。

touch ~/.vimrc
vi ~/.vimrc

以下を設定。

set nocompatible
set backspace=indent,eol,start

一度ログアウトして再ログインする。
以上、環境を整えた。

Pythonのパッケージ管理システム pip をインストール

AWS CLI は、pip経由でインストールするため。
まずは pip をユーザー権限でインストールします。

Pythonの設定ファイル .pydistutils.cfg を作って設定。

touch ~/.pydistutils.cfg
vi ~/.pydistutils.cfg
[install]
user=1

インストール先は、ユーザーディレクトリになるため
以下のPATHを .bash_profile に設定してあらかじめ PATH を通しておく。(この記事ではすでに通し済みです)

$HOME/.local/bin

インストールの準備が整ったところで、pip をインストール

easy_install pip

インストールが完了したところで。

pip -V

バージョンが表示されていたら無事完了。
以下が表示されるなら。PATHが通っていないかも。

pip: Command not found.
source ~/.bash_profile

で、bashの設定を再読み込みして再度確認。

以下でユーザーディレクトリにインストールされたことが確認できる。

which pip

/home/<user>/.local/bin/pip

AWS CLIをインストール

AWS CLIを pip 経由でユーザーディレクトリ先にインストール。

pip install awscli --upgrade --user

インストールが完了したところで確認。

aws --version

aws-cli/1.17.2 Python/2.7.16 FreeBSD/11.2-RELEASE-p14 botocore/1.14.2

インストール先も確認。

which aws

/home/<user>/.local/bin/aws

これで、さくらのレンタルサーバで AWS CLI が使えるようになった。

最近の投稿

カテゴリー

アーカイブ