エンジニアの皆さん、日々の業務お疲れ様です。
少しこの記事にお付き合い頂けるなら、ここ最近の業務を思い返してみて下さい。
どうでしょうか？
VSCodeとSlackのどちらの画面に向き合っている時間が長いですか？
VSCodeもSlackも使っていない？
そんな方は普段お使いのお気に入りのエディターとチャットツールを想像して下さい。
え？VSCodeの方が長い？
もしかしたら新たな発見があるかもしれません。
Slackの方が長い方はぜひぜひ聞いてほしいです。
すみません、前置きが長くなりました。
この記事のテーマはチャットツールの使い方改善です。
プログラムをリファクタリングするならチャットにも実施した方が良いのでは？
という観点で書いています。
アプリケーション開発の手法をインフラにも適用するInfrastructure as Code(IaC)という概念がありますが、
似たような考え方を導入しています。
(プログラムコード改善手法をチャット文章にも応用する。どちらも同じ文字列なので。)
具体的なツールを例にしたほうが話を進めやすいため今回はSlackを使用します。
また、個人利用でもチームのような大規模利用でも効果を発揮する内容にまとめました。
むしろ大規模利用の方が効果が高いと思います。
では、始めます。
情報エントロピーの増大
"あれ？どっかで見た気が、、、んー、見つからん、、、"
このフレーズを心の中で呟いたことがある方も多いと思います。
もしくは実際に聞いたことがある人もいるでしょう。
このフレーズに遭遇したなら要注意です。
その空間は既に情報エントロピーが増大しています。
エントロピーの定義はここでは重要ではないので、ひとまず"無秩序さの指標"として捉えて下さい。
一見したときに"なんか汚ない、、、"と直感で思った場合、それはエントロピーが増大しているということです。
無秩序の弊害
無秩序だと何がいけないのでしょうか？
無秩序がもたらすコストやリスクをいくつか挙げてみます。
-
時間的コスト
関連する情報が複数箇所に散在している場合、それらの情報を全て探し出して適切な順番に結合しなければなりません。
検索時間と結合した情報を理解する時間、これらの両方で時間がかかります。
時には高度な検索機能を利用しなければ探し当てられない情報があるかもしれません。
もしそうなら、検索機能の学習時間も別途必要となります。 -
誤認リスク
検索結果に基づき結合した情報の組み立て方が不適切な場合、文脈を読み違えてしまう危険性があります。 -
見落としリスク
そもそも目的の情報の一部を検索しきれなかった場合、文脈そのものが欠落してしまう可能性もあります。
これらのコストやリスクが発生し組み合わさると、
- 同じ話をしているはずなのに噛み合わない
- リソースへの設定ミス
- システム理解の妨げになる
- システム障害の誘発
等の残念な結果をもたらします。
エントロピー増大の兆候を探す
以下の兆候が確認できた場合は、エントロピーが増大している可能性が高いです。
-
タイムラインが縦に伸びている
具体的な指標は存在しません。読みにくいなと思う直感を頼りにして下さい。 -
検索結果が複数見つかる
検索機能を利用して目的の単語やリンクを検索をすると、
類似の単語や文章が画面一杯に表示される場合は危険信号です。
手遅れかも？ を もう手遅れ にしないために
具体的なTIPSを紹介していきます。
-
スレッドを活用する
この手法が最も改善効果が高いです。
スレッドをフル活用することで、タイムラインが縦に長大になることを防ぎ関連情報の集約率が高まります。
私が思う効果的な活用法を紹介します。
※例ではチケットシステムの利用を想定しています。
まずチャンネル投稿内容にはチケット番号 チケット要約 スレッドの一行のみに限定します。
以降はスレッドに記載します。
次にスレッドを開きチケットへのリンクを投稿します。
注意としては、チケットリンクに含まれる文字列とチャンネル投稿したチケット番号の文字列は分けることです。
そうすることでチャンネル投稿時のチケット番号が一意になり、
検索時にノイズに惑わされず、目的の情報にアクセスできます。
-
検索容易な文章を書く
スレッドの活用でも書きましたが、チャンネルやスレッド内で一意になる可能性が高い単語を選びましょう。
また、スレッド間で情報を連携したい場合は、
互いのスレッドに同じ文字列を投稿しておくとまとめて検索結果に表示させることもできるので便利です。
要はタグ付けによるグループ化ですね。 -
関連メンバーに配慮した文章を書く
AさんがBさんとチャットでやり取りしているとしましょう。
この２人はベテランのリードエンジニアです。
しかし、このチームには入社間もないCさん、Dさんも所属しています。
文章内容がCさん、Dさんにも関わりがあるのであれば、ある程度難解な単語は意図的に省いた文章構成にしましょう。
ただしここで大切なことは、伝えたい内容が改変されるほどに簡略化してはいけないということです。
メインはBさんとの意思疎通であることを忘れないようにして下さい。 -
省略記法の多用を控える
過去の自分や他のメンバーが理解に苦しまない程度に控えましよう。
省略記法は当座の理解短縮には役立ちますが、不特定多数の人が後で参照する可能性が高い文章には不向きな場合が多いです。
--- AWSでの一例 ---
運用者にとって"CW"は"Cloud Watch"のことかもしれませんが、
データサイエンティストにとっては"Glue Crawler"のことかもしれません。
ちょっとだけ横道
チャットに限らずドキュメントのような文章全般に言えることですが、
文章内容より以前に、置き場所が非常に重要だったりします。
海底に沈んだ世界中が感動する小説よりも、ドキュメント管理ツール上にある
５ヶ国語交えて書かれたアプリケージョンのデプロイ方法の方が有用なのは言うまでもないですよね。
明日からの実践
お読み頂き誠にありがとうございました。
この記事の内容は要約すると、文化の改善に尽きると思います。
文化の改善は一朝一夕ではなしえないことを心得ておく必要があります。
まずは個人の改善から。そしてチームへの波及へ。
まずは目の前の小さな改善から着手されてはいかがでしょうか。