＼回答があります！／

• 

  Shun

  エンジニア

  1年前
  スクラムを導入しているため、割と毎日密接に関わる人とはデイリースクラムにおいて「相談したいこと」を募っておき、口頭で解決するようにしています。これにより1日のうちの7割くらいの相談は齟齬なく解消できていると感じてます。
  
  ただ、貴方様がおっしゃるビズサイドからのテキストについてはカバーできていないため、そこへのアプローチについて書いてみます。
  
  定期的に顔を合わせることのないメンバーとのテキストコミュニケーションについては、正直以下を感じた経験はあります。
  
  1. 何いってるのかわからない（文脈・コンテキスト・日本語そもそも）
  　- とりあえず自分で理解できる部分は整理して、「こう言うことですか？」と返信する
  2. で、どうしてほしいの？
  　- 「事象は理解できましたが、こちらとしては何をいつまでに行えばいいですか？」と返信する
  3. もう、何もわからない。（or これは不毛な時間が長くかかりそうと直感的に体が反応）
  　- ここでハドルやmeetを駆使します
  
  さらに返信が来た場合は、「どこかに情報整理されているドキュメントなどはありますか？」とやりとりしているメンバーだけで閉じた形にしないように、ドキュメント化を進めます。（これは組織文化にもよるとは思いますが）
  
  テキストコミュニケーションってたまに辛いですよね。
  ただ、逆に荒いコメントを理解して動いてくれる人材はこの時代貴重だなとフワッと思ったりしてますw
  view数 31
  • 1
  • 3
  • 2
  • 2
  • 1
  • 1

• 

  北山 淳也

  エンジニア

  1年前
  コロナ禍でリモートのお仕事が増えたことでわかったことなのですが
  ・「自分は誰かに何かを伝えなければならない状態である」ということを自認する能力
  ・自分の伝えたいことを言語化する能力
  ・言語化したことを文章にする能力
  ・デジタルな文章を書く能力（タイピング、音声入力などを使いこなす能力）
  ・文章を読みやすい状態に仕上げる能力
  ・画像が必要なら画像を作成したり用意する能力
  ・長文にも臆さず文章を読む能力
  ・文章から相手の伝えたいことを読み取る能力
  ・文章から読み取れないことを聞き返す能力
  ・非言語的なニュアンスなんかを文章の表現方法や絵文字などで表現する能力
  などなどがコミュニケーションを取ろうとする2以上のn人全員が備えてないと
  テキストコミュニケーションを成立させるのはとても難しい行為です。
  
  つまり、話した方が早い、ハドルの方が早い、カメラONで話した方が早い、会って話した方が早い、ので　それらを駆使してコミュニケーションの量を増やすことを意識しています。
  なので基本リモートワークで働いているのですが、必要があれば当然オフィスでもどこへでも行きます。
  
  幸いにも、私は文章を書いたりまとめたりすることが嫌いではないので
  話したことのドキュメント化やログの記録は
  私が書いたり、議事録自動生成ツールと何かしらの方法での要約なども活用しつつ
  デジタルなドキュメントを書くことが苦手な人に
  デジタルなドキュメントを書くことを強要しないことを重要視して
  テキストコミュニケーションでどうにもならん！を対処するようにしています。
  
  そして、おそらくこの投稿も
  頭の箇条書きの部分を読むのがもうつらい、って人も少なくないだろうなと思いながら書いています。 （編集済み）
  view数 19

• 

  大橋桃太郎

  プロジェクトマネジメント

  1年前
  意識の問題として考えてみたのですが、「リクエストは未完成であることを前提として、具体化から担うのがプロフェッショナル」と捉えるのが乗り越え方かな、と
  
  仮に既にリクエストが詳細に詰められていたとしても、昇華する機会にもなりますし、あらゆるリクエストは未完成である前提くらいがちょうどいいのではないかなーと思ってみました！（すぐに会話をしたり、要件を引き出す前のめりなコミュニケーションとても素敵だなと思いました！）
  view数 28

• 

  北野勝久

  エンジニア

  1年前
  テキストコミュニケーション、難しいですよね。
  
  書いてらっしゃるような情報がとっ散らかる問題以外にも、トゲトゲしちゃったりするようなこともあるあるだと思います。対面だとあったはずの情報量（表情や姿勢など）を何かしらの方法で補完しないと、無機質なものになりがちといいますか。
  
  個人的には、質問者様がおっしゃるような、ちょっと話しませんか？という雰囲気を積極的につくっていくスタイルが好みではありますね。いわゆるバーチャルオフィスのようなサービスをつかっていくことで、話しやすい雰囲気を仕組みで担保していくのも手だと思います。
  https://ja.gather.town/
  view数 24

• 

  Haruka Ishii

  プロジェクトマネジメント

  1年前
  上述の課題は、一つ一つの課題を潰していくよりも、開発プロセス全体を改善していくことで対処してくべき案件かと思います。なので、「全社的に開発プロセスの方針を決定し、開発プロセスの言語化する（ = ドキュメント化する）」のがまず最初にやることかと思います。
  
  開発プロセスの方針決定では以下の観点が変数としては大きいと思います。
  ・そもそも自社の事業の特徴はどのようなもので、どのような組織にしていきたいか
  ・誰に何の役割を担ってもらう（ = コストを払ってもらう）のか
  ・開発プロセスをどの程度厳密に設計するのか（柔軟性をどの程度持たせるか）
  
  一方、権限上自分ではそういう意思決定はできない、上申しても会社がそこまでのことをやってくれないなど、プロセスの抜本的な改善ができないときは、場当たり的ではありますが↓のような対応をすると多少コストが下がる気はしています。（↓のように「定例を開催する」などのアクションはだいたいの場合で権限的にも実施できる印象）
  ・ビジネス職からの要望を話し合う週一の定例ミーティングを開催する
  ・Slackで短期的な要望が出た場合は、「定例で議論しましょう」と案内する
  
  総じて、個人的には全社的な開発プロセスの言語化とその徹底こそが本質的で本当に大事だと思うのですが、それができない場合、「大体の施策が本質的ではなくベストな状態にはならない」的な感じの諦めを持つのが精神衛生には良いと思います。。
  view数 12
  • 1