ぷりまると娘と犬と猫と猫との日常

DIYとか仕事とか育児とか動物とか雑多に

チャットコミュニケーションがうまくいく10の工夫

フルリモートで仕事するようになり、コミュニケーションにおけるチャットの比率が以前にも増して高くなってきました。
そんな中、思ったように伝えられなかったり理解できなかったり、やりづらさ・難しさを感じる場面もちらほら出てきています。

振り返ってみるとこれを手抜きしたら失敗した。というアンチパターンがいくつかあったので、じゃあ逆にここを押さえとけば失敗率が下がるじゃんというポイントを書いていきます

f:id:purimarusan:20210725132529p:plain


自分発信

連絡種別を冒頭に書く

まず、連絡における主旨や返答要否を冒頭に添えることで読み手は以降の文章をどういう心構えで読むか判断できます。

  • 返答を求めない情報伝達
  • 意見や申し出を求める相談、募集
  • 決裁、判断を求める確認、承認依頼

逆にこの分類が明示されずかつ文章からも読み取れないと「結局何が言いたいんだろう?」となったり、伝え手が期待する反応とはずれる可能性が高まると感じています。

期待値を添える(例示する)

f:id:purimarusan:20210725132826p:plain

例えば情報伝達のみの場合、一切の反応不要なのかそれともなんらかレスポンス(例えば特定のemojiをつけてね、等)がほしいのか。
確認の場合、Yes/Noなのか選択肢から選ぶのか自由回答なのか。
例えばコードレビューなら確認してほしい箇所、観点を伝えることで見てほしいところはスルーで意図せぬ箇所には指摘がある。といったことも避けやすくなります。

背景を伝える

f:id:purimarusan:20210725132610p:plain

特に反応を求める情報伝達では読み手側の時間を奪うことになります。

簡潔な文章は良いですが聞きたいことだけを一方的に伝えるのみでは受け手はなぜそれを聞かれているのか、返事しなければいけないのかわからず不要な衝突を招くことになる場合もあります。

文脈や背景をお互いによく理解している間ならともかく、そうでない場合はなぜこの連絡をするに至ったか、を申し添えることで心理的なしこりが生まれにくくすることができると思います。

抽象的、定性的な表現を避ける

ちゃんと、早く、しっかりといった単語で度合いを表現すると、その感覚の個人差によってズレが生まれることが多いです。
同様に「確認する」「共有する」等も具体的に聞こえますがどのような手段で、何を、などは解釈の余地があります。

相互で文脈の理解が一致していればそれでも問題ないケースもありますが、そうでない場合は意図した結果にならない一因となりえます。

返答時

質問の主旨を読み取る

f:id:purimarusan:20210725132850p:plain

これは連絡種別を冒頭に書く、を受け手の立場で考えます。

発信者が必ずしも明示してくれているとは限りませんが、なんらかの意図があって連絡しているのであれば必ず分類分けができるのでそれを読み取るよう意識します。
自信がなければ受け止めた上でレスポンスが必要か確認すれば確実です。

望まれる答えを先に書く

f:id:purimarusan:20210725132903p:plain

期待値に対応するもので、Yes/No, AorB、回答不可などまずは伝え手が期待する答えを伝えます。
付随する意見や主張はその次だと思ってます。

補足情報を添える

f:id:purimarusan:20210725132915p:plain

前のポイントで二の次 とした意見、主張や前提条件や制約条件、返答の思考プロセスを添えます。

これがあることで前提知識や理解度のズレに気付かないまま話が進んでしまうことを未然に防ぐことができます。

共通

事実と主観を明示的にする

f:id:purimarusan:20210725132928p:plain

これは慣れも必要だとは思いますが、正確な情報伝達のためには欠かせない要素だと考えます。

例えばAさんが「なんでこんなこともやってないの?」と発言したとして
「これをやっていなくてAさんが怒っていた」は主観です。 事実は「私がこれをやっていなかったことを知ったAさんはなんでこんなこともやってないの?と言った」です。 「怒っていた」というのは受け手が感じた評価であり事実であるかは定かではありません。

厳密に表現するなら 「私がこれをやっていなかったことを知ったAさんはなんでこんなこともやってないの?と言っていた。私はAさんが怒っていると感じた。」とか

単語はなるべく文章にする

「情報共有する」「確認する」など単語で簡潔にまとめることもできますが、この表現だと具体的な方法は受け手の解釈に依存してしまい、方法がわからない場合は実行することもできません。

情報共有する、なら何月何日の会議Aの議題に記載して参加者へ伝える。slackの○○チャンネルに誰宛にメッセージを送る。ナレッジ共有サイトに記載し、記載したページのURLをどこどこで配布する。など

一度に全てを詰め込まない

f:id:purimarusan:20210725132943p:plain

ここまで色々書きましたが、一度のメッセージに全てを詰め込むと情報量が多くレスポンス速度が落ちる、返答の網羅率が下がることがあります。

テキストチャットはメール等と比較してリアルタイム性が高く、やりとりの往復を前提として使われていることが多いと思います。
なので、相手からの反応を受けて次の話に進むよう双方向のコミュニケーションを前提とした情報量を心がけると負担が軽いです。

このあたりは小出しにしすぎてもうまくいかなかったり塩梅が難しいところではあるので試行錯誤を重ねてほどよいバランスを身につけるほかないかなと思います。

全体を見てみて

チャットコミュニケーション、と掲げはしたものの口頭でもなんでも共通して心がけるとよい点だなと感じました。

口頭、メール、チャット等はあくまで手段であってコミュニケーションの本質が大きく変わるものではありません。
手段特有で使えるテクニック等はありますが。

注意

色々と書きましたがこれらはあくまで「自分が心がけていくこと」であって必ずしも相手に求めるべきものではありません。

曖昧な表現や読み取りづらいメッセージを受け取った。がんばって伝えたのに理解してくれないといったことは往々にして起こりますが
相手に原因を置いて責めたところで何かが良くなることはないのです。

自分が受け手でわかりづらいと感じた点があるのならそれを埋めるための質問をすればよく、自分が伝えた情報が期待通りに伝わらなかったのならその差分を埋めた上でなぜ伝わらなかったのか、どう工夫すれば期待通りに伝えられたかを考え、自分自身が次に活かすことが大切です。

間違っても、誰々の話はよくわからない。誰々は話が全然通じない。等と他人を攻撃することで思考停止することのないよう意識していきたいと思います。

最後に

これら全てできれば間違いないということもなく、常に100点を取れるわけでもないですが
仕事だけでなくプライベートでもコミュニケーションを図る上でより良くするためのネタ程度に誰かの参考になると幸いです。

私自身も現状で満足せず改善していけるよう常に模索し続けていこうと思います。

f:id:purimarusan:20210725133007p:plain

「プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける」の読書感想文とちょっとの自分語り

はじめに

ここ最近、自分の観測範囲内で"プロダクトマネジメント"という単語をよく見かけるようになった気がします。

プロジェクトマネージャ(PjM)、プロダクトオーナー(PO)といった職能がこれまであった中で現れた"プロダクトマネージャ"(PdM)とはなんなのか、その謎を解き明かすべく我々調査隊はアマゾンで本を買った。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)

総評

すごく、よかったです。

PjM、PO、PdM、もしくは職能としてラベル付けはされていないけど親しい役割を担っている方は読んで損はないですし、そうではないエンジニアやマーケター、管理職の方もフレームワークやテクニック部分はさておき思想の部分を理解することで得られる気付きはあると思います。

特に個人的に刺さったポイント4選

行動規範のGood/Badパターン

これは、私がこの本を手に取るきっかけになったことでもありますが、目次を読むと以下のような章があります。

  • 悪いプロダクトマネージャーの典型
  • 優れたプロダクトマネージャー

悪いプロダクトマネージャーの中の見出しで、こうありました。

プロジェクトマネージャーだった人

現職ではプロジェクトマネージャの役割が多いため「なんやて!」と興味を持ち読んでみると
内容的にはそりゃそうだと納得するもので、うまく釣られた結果になりました。

この章の中ではスクラムフレームワークにおけるプロダクトオーナーと本書で指すプロダクトマネージャとの違いが明確に記載されています。

自分の立ち位置に合った内容がある

こういった本をこれまで読んだ中で時折あったこととして、書籍内のストーリーや登場人物、企業の文化や立ち位置、レイヤーが自分自身とギャップがありすぎて
内容は勉強になるものの、どう活用・適用していくか。行動を変容させていくかに迷ったり
組織として必要なレポートの実現ができなかったりすることがありました。

本書ではPdMのキャリアパスから、ポジション毎の期待値や役割・戦術/運営/戦略のウエイト、チームの設計とアンチパターンと自身が置かれる立場に応じた観点で読むことができました。

"プロダクトのカタ"という抽象なフレームワーク

思想や理想、期待値を理解したとしてじゃあどう取り組んでいくかという点で
具体な方法ではなく抽象度の高いフレームワークとして解説されています。

それぞれでやること自体はシンプルですが、できていない・知らないこともありました。
知らないなら聞き調べ、その結果できていない状態なら始めるだけです。

本書ではできていないケースも多分に記載されています。
それらをヒントに、自身の組織ではどうか?ということを考え・確かめることは自分ひとりでも始められますし、行動に移しやすいと感じました。

コンパクトな文字量でも高密度

付録やまえがき、謝辞を除く本編のみのページ数はたったの186ページです。オライリーの技術書と比較すると圧倒的に薄いです。

ですが、情報量・密度が薄いということは決してなく、広範かつ必要な深さで解説がされていると感じました。

ちょっと自分語り

この本を読み終えて、これまでの自分が携わってきたプロジェクトはどうだったかを思い返してみました。

この内容を踏まえて自分史上最も成功させられたプロジェクトは、結果的にプログラムの修正を1行も本番デプロイせず顧客の課題を解決したものでした。

詳細は伏せますが、当時の担当サービスで顧客が利用する際に大きく不便・不利益があり
業界のサービス比較で圧倒的マイナスポイントとして挙げられるほどの課題がありました。

それを解消する仕様を検討・策定して機能追加するプロジェクトのPjMでしたが
色々あって対応としては運用上のデータ変更のみで途中まで進めていた設計・プログラムは日の目を見ることなく全て破棄することになったものの、課題は完全に解決することができたという話です。

私自身、査定評価のための目標に"プロジェクトをN件リリースすること", "hogeプロジェクトを完了させること"などを設けていましたが、それありきで開発することは選択しなかった結果
当初の目標としては開発してないので未達ではあるものの、判断理由・結果・色々の対処内容を踏まえて評価もしっかりついてきたと思っています。

リリースすること自体を最終目標にせず、価値提供・課題解決を正しくしていくことへの意識は常に持ち続けないといけないなと改めて思いました。

最後に

デプロイ頻度や、施策の起案からリリースまでのリードタイムといった指標を目安数値として置くこともあると思いますが
今回の話はそれらと相反するものではなく、価値提供するために必要な要素の一つであることを認識した上で計測し・高めていくものであって、この指標を高めること自体を目的にしないよう注意することが大切であると感じました。

本書の翻訳をされている吉羽さんのツイートで、強い言葉だけど真理だと感じたものを引用させていただき、今回の記事を終えたいと思います。

IPA 情報処理技術者試験 PM(プロジェクトマネージャ)に受験・合格した話

もう3年ほど経つけど、2018年に受験・合格したのでそのときの勉強内容や試験の話です。

どんな試験・資格か

情報処理推進機構(通称、IPA)が実施している情報処理技術者試験の一つです。 ITプロジェクトマネジメントに特化した経済産業省が認定する国家資格です。

f:id:purimarusan:20210222194846p:plain 出典 : IPA 独立行政法人 情報処理推進機構:試験制度:試験区分一覧

資格情報をまとめているサイトでは偏差値69と難関資格に位置づけられています。 直近(令和2年度10月)の合格率は15.1%だそうです。

wikipediaでは以下のように記述されています。

公表されている合格率は例年15%未満である[2]が、受験者の大部分は既に応用情報技術者試験(スキルレベル3)や基本情報技術者試験(スキルレベル2)は勿論、システムアーキテクト試験やITサービスマネージャ試験など他の高度情報処理技術者試験の区分にも合格している場合が多いため、実際の難易度は相対的に非常に高いものとなっている。 試験制度上は他の高度情報処理技術者試験と同等のスキルレベル4とされているが、実際には実務経験者でも合格するのは非常に難しい試験として知られており、ITストラテジスト試験、システム監査技術者試験と並ぶ高度情報処理技術者試験の最難関として名高い。2014年度までの累計合格率は12.9%[3]で、情報処理技術者試験の中で最も低い。 引用元 : プロジェクトマネージャ試験(wikipedia)

ただ、個人的にはこの数字の低さが直接的に難易度を表しているわけではないと考えています。 なぜなら情報処理技術者試験は、試験免除の仕組があり最初から合格を目的とせず受験する人も母数に含まれるからです。

試験免除とは、直近2年以内に応用情報・高度試験に合格、もしくは高度試験の午前Ⅰ試験で基準点以上の成績をとった場合、午前Ⅰ試験を免除されるというものです。 実際、私の受験時も午前Ⅰ試験後に退席される方が複数名いました。

試験時期や受験費用などはIPAの公式サイトから最新の情報をご確認ください。 当時は春期試験でしたが、令和3年(2021年)2月現在では秋期試験となっています。

www.jitec.ipa.go.jp

試験勉強

前提条件

  • PMの実務経験3~4年
  • 業界はWEB系
  • プログラミング経験はほぼゼロ
  • PMBOKに関して、社内研修で一通り学んでいた

教材

勉強の進め方

とにかく過去問をこなしました。その中で苦手分野が見えてくるので、そこを重点的に学習。

…とできれば理想的ですが、午前免除できればいいかな程度の低い意識で受験・勉強に臨んでいた私は 午前Ⅰ,Ⅱの過去問4年分に専念し、間違えた箇所を繰り返し解いて暗記していきました。

f:id:purimarusan:20210222201858p:plain

プログラミング経験がないこともありアルゴリズムなどを含む午前が自分の弱点だと理解していたことと 午後の試験は論述式で過去問やるにも時間がかかる 論述は得意だぜ!という根拠のない謎の自信からです。 午後1,2は本を軽く目を通したぐらいです。

試験概要

簡単に箇条書きで記載します。

  • 午前Ⅰ
    • 4択 * 30問
  • 午前Ⅱ
    • 4択 * 25問
  • 午後Ⅰ
    • 記述式(穴埋め、論述)
    • 3問中 2問を選択して回答
  • 午後Ⅱ←鬼門
    • 論述式(小論文)
    • 2問中 1問を選択して回答
    • 最低でも1,800文字程度の記述が必要条件として定義

受験当日

私は家から最寄りの受験会場が青山学院大学で、幸いにもそこで受験することができました。 ただ、朝は自分にとっては早かったです。

情報処理技術者試験を受験する層の人々にとっては辛い時間なのか、試験開始しても空席のままの席もちらほら見受けられました。 勤めたことはないですが、SIerだと会社から受験指示が出るケースもあるのか 申込みだけして会場にはこない人もいるという説もあるそうです。

受験会場に辿り着くことが試験。某ハンター試験を彷彿とさせますね。

試験内容のtips

午前Ⅰ,Ⅱは暗記するのみなので割愛します。

午後Ⅰはまず答案で記述様式を見て設問をおおよそ推察することができます。 私の場合、数字の計算で時間を取られたくなかったので数字を記入するような解答欄のある問を避けて選択しました。 正攻法ではないですが、効率的に時間を使うための自分なりの工夫です。

午後Ⅱはテーマを読み取り、これまでに担当・経験したプロジェクトのエピソードを当てはめられる問を選びました。 これは各人の経験、年度ごとの問の内容によるのでテクニックも何もない気がします。

資格勉強の講座などでは有料で添削してくれるところもあるようですが 学校の国語の勉強がそこそこ得意で、ある程度の実務経験がある方は自力のみでなんとかなるかもしれません。

結果

f:id:purimarusan:20210222204652j:plain

午前免除狙いとは言え全力でがんばった結果、奇跡的に合格することができました。 午前Ⅰから順に点数が上がっていることから自分の得意・不得意が顕著に出ていると感じます。

プロジェクトマネージャに関する資格はPMPもありますが 更新が必要なPMPとは違い、この資格は一度取得すれば一生物です。

更新が必要ないとは言え、日々変化が目まぐるしい世の中・業界なので 取り残されないよう継続的に学び、長く最前線で戦うソルジャーでいられるよう今後もがんばっていきます。