【コミュニケーション】業務中に情報の受け渡しをするときは、範囲と条件を意識して一意に決まるよう工夫するとスムーズになる
はじめに
対象
- 業務上のテキストコミュニケーションで、相手に追加質問されがちな方向け。
一意であるかは範囲と条件で決まる
一意（unique）とは、「一つのことに集中する」あるいは「ただ一つに定まる」という意味の熟語。IT分野ではもっぱら後者の意味で用いられる。 一意である状態や性質、度合いのことは「一意性」という。
一意とは？意味を分かりやすく解説 - IT用語辞典 e-Words
あなたはどこの鈴木さん？
一意性とは「ある条件を満たすものが、ただ1つのみ存在する状態」のことです。システム開発の現場では、よくデータベースの一意制約が出てきますね。同テーブル内で、同じ値のカラムを持つレコードが1つも存在しないようにする制約です。
一意である状態を決めるのは、主に範囲と条件です。学校のクラスで考えてみましょう。
もし佐藤という名字の生徒がA組に1人だけ存在するなら、A組の中では一意であると言えるでしょう。では範囲を学年まで拡大するとどうでしょうか。もしB組に佐藤がもう一人いたら一意ではなくなってしまいますね。
では名字だけでなく、名前も条件に加えましょう。A組にいるのが佐藤一郎さん、B組にいるのが佐藤二郎さんであれば、一意であると言えますね。他のクラスに同姓同名の方がいない場合、ですが。
もしもBクラスに佐藤一郎さんが引越してきたらどうしましょう。多くの場合そうしているように、名前で呼んだり佐藤（一）と略して書いたりするだけでは、どちらの佐藤一郎さんなのか分かりません。A組の佐藤一郎さん、まで伝えないと一意に特定ができないのです。
範囲と条件を意識したコミュニケーションを
ちなみにこれ、ヒヤリ・ハットでは部署違いの同姓相手に機密情報を漏洩してしまったとかいう、割と洒落にならない事態になることもあります。メールアドレスが似ていて間違えるとか、下の名前を聞いていなかったとかですね。会社単位で間違えるともっと悲惨。
一意なものの特定に失敗するのは、範囲が特定できないときか、条件が足りないときの2つです。つまり一言でいうと情報不足です。
言語コミュニケーションにおいて人は略せるものは略そうとするので、それが範囲であれ条件であれ無駄を削ぎ落とそうとします。結果として言葉が足らなくなり、受け取った側が一意に特定できない状態で情報を渡してしまうのです。
これを解決するには、面倒でも範囲を定めたドキュメントを作成し、必要な条件を全て網羅する形で渡す必要があります。
具体的な事例で見る範囲と条件
ここではITエンジニアらしく、環境の特定に焦点を当てて説明します。
- 環境
- メンバーAのローカル環境
- メンバーBのローカル環境
- ステージング環境
- 本番環境
- 制作会社の検証環境
- リリースサイクル
- 毎週、日曜夜にリリース
条件に該当するものが複数存在する
営業から不具合報告が上がってくる。あるあるだと思います。動きません、想定と違います、ここどうにかなりませんか。要望が書かれたチケットを見て開発者は思います。
それは一体、どの環境なんだろうと。それはいつの話なんだろうと。
彼らは開発者ではないので、ローカル環境は構築すらしていません。きっと検証環境以降のどれかでしょう。今日が月曜日だとして、確認したのは今朝の話でしょうか。それとも金曜日に見つけて来週報告しようと思ったことでしょうか。
もしも同じく金曜日にインフラ担当の方が臨時作業を行っていたら。前日の木曜日に運用担当がマスターデータの整備や、アプリの設定変更をしていたら。一意性を語るにあたり時間軸が絡むほど厄介な話もありません。一意条件の可変性については頭の片隅に入れておきましょう。
環境とバージョンの特定だけでこの体たらくなので、画面の特定や操作手順など他の事象の特定も考えると頭の痛い話です。
一意に定まる情報を授受する方法
解決方法は至って明快です。
- 環境一覧をWikiに作成し周知する。
- チケットテンプレートを追加する。
- 不具合・障害が発生している画面のURL・日時など。
まずは環境一覧を作成して範囲を明確にします。開発者だけが知っていればいいではなく、不具合報告をする可能性のある方、全てが確認できる場所・内容にしましょう。
そしてチケットのテンプレートを作成し、必要な情報を書き込んでもらうようにします。画面のURLが分かるだけでもものすごく助かります。発生日時が分かればログが探しやすくなります。日時からバージョンが分かればローカル環境で動かして確認もできます。
もっともこれらの方法は、バグ票の書き方や不具合報告の仕方などの記事で、再三に渡り周知されてきたことと同じです。前提条件や再現手順などを事細かに伝えよといっているのは、本質的にはバグを再現するための状態をなるべく一意に近付けるためです。
変化する状況の中で作業を依頼する相手に、あるいは後世そのバグ票を読み返すであろう開発者に、どれだけ一意性の高い情報を残せるか、常に考えながら起票する必要があると思います。
必要な情報が何かを常に考える
さてチケットテンプレート通り、画面のURLを貼りました。
おわかりいただけただろうか。ローカル環境であることは分かりますが、誰のものかは分かりません。厄介なことにブランチを切り替えれば、どのバージョンでも動かすことができるでしょう。最新のmainなのか、developなのか。何か変な操作はしていないか。
起票者の環境に当たりを付けて調査を行っていたら、実は新入社員や上司の代わりに起票しただけだったという場合もあります。
この問題はルール決めをするだけでは解決しません。起票者自身が複数の環境が存在することを理解し、それぞれの環境がどのような性質を持っているか把握し、一意に識別可能な情報を提供するために常に意識して考えて書かないといけません。
必要な情報が何かを常に考える番外
ついでなので、開発者がやりがちなものも一つ紹介しておきます。何も考えずにREADME.mdやWikiにリンクを張って終わりにしていないでしょうか。
私もリンクだけ貼って済ませることはありますが、それはリンク先の手順が迷う余地のない、一本道の場合です。問題は次のようなケースです。
ssh-keygen -t rsa -b 4096 -f key_name
ssh-keygen -t ecdsa -b 521 -f key_name
ssh-keygen -t ed25519 -f key_name
鍵の作り方が沢山書いてあります。稼働してるシステムです。いや、どの種類の鍵なんだと。せめて生成コマンドごと置いて行けと。ステージング環境の鍵を調べて、ホワイトペーパー全部読んで、コマンドを特定してWikiに手順を書き起こして。
何かあったらいけないので、そりゃ慎重にもなります。この時間があったら別のことに使いたいですし、何より本来必要のない作業をしてるのがもったいないですよね。
そもそもリンク先の内容が当時と同じ内容である保証はないので、引用形式で残しておくなどの工夫も必要です。元記事を確認して更新されていれば、新しいものに移行しなければなりませんし。
一意性どころか無限大に発散してしまってますが、このようなケースも情報不足で一意に特定するのが難しいので、自分がやらかしていないか今一度見直してみましょう。
おわりに
特に指示出しの上手いITエンジニアの方だと、無意識的にこれができてることが多いです。自然と範囲、つまり全体を確認する癖が付いてるんでしょうね。
全部視界に入っていないと、指示した内容で一意に伝わるか分からないですし、自身で戦略を練るときも情報を重複させたまま考えないですから。逆に言えば、そこまで頭が回っているかという話でもある。
自分の仕事の範囲だけ・自分に関係のある範囲だけしか見えていないと、その知識の中から文章を出力することになるので、その外側で一意にならないことが増えます。もっとも知識量や経験値による対象検出範囲の格差が原因の場合もあるので、一概には言えませんが。
それはまた別の記事で。
Discussion