"コミュニケーション/チームビルディング"投稿一覧

すごく共感です、、
人として気持ちが良いコミュニケーションをしましょうという基本的なことになってしまいますが、
以下意識していることを書きます。

・『!』『。』は必ず使う
→つけないフランクなやり取りもありますが基本的に使用する
・スタンプは極力自らつける、ファーストペンギンになる
・timesなどで自己開示し、話しやすい雰囲... 続きを見る

私はずっと開発エンジニアをやってきたのですが、逆にSRE/DevOpsの経験が不足している事が悩みです。

日本に来る可能性があるOpenAIなどはSoftware Engineer, Platform Reliabilityというポジションもありますし、24/7でソフトウェアを動作させ続けるためにいつか日本にもこのようなポジションがオープンする気がしています。
続きを見る

同様の課題感を何度か感じ、いくつか実践してみたことを箇条書きに述べてみます。

・脳死で「！」をつけなさい週間
・脳死で「スタンプ」をつけなさい週間
・脳死で「スタンプの代わりに画像」をつけなさい週間

ポイントはやはり「脳死で全員やる」というところですね。短期的な実践であっても、5人に1人くらいは馴染んでそのまま柔らかいコミュニケーショ...

私もNotion推奨派で、Notionをストックツールとして利用しています。
チーム規模や事業形態によって色々差分がある話とは思いつつ、以下何かの参考になれば幸いです。

前提として、個人的にNotion反対派に対してNotionの利用を進めるときに意識しているのが「社内の情報管理を設計する立場」と「社内の情報管理ツールを利用する立場」は異なるということです。 続きを見る

得手不得手についてお互いに確認し合い、その上で所有権と占有使用権について話し合います。

大抵の場合自分自身の棚卸しができてないから揉めるのかと…

おっしゃる通りフローとストックでツールを分ける必要がありますね。ただ、ストックの手段が本当に Notion が適しているかという問いは必要です。おっしゃるようなメリットは確かにあるものの、Google Drive だと下記のメリットがあります。

- スプレッドシートやスライドなどが一緒に使える
- 外部との共有もファイル / フォルダ単位で対応できる
- ... 続きを見る

サービスイン後の責任分界点が大きな課題でしょう。モノの製造なら未だしも、様々絡みがあるシステム開発で、ターンキーなんてのはサービス提供後に協業化した場合に責任の押し付けが必ず起こるし、信頼できる間柄ならまだしもという話は尽きません。最終需要家と親密であるとか、関係が近くあって立場が強い側に押し切られたりするか、勝手に話が変わっていたりはよくあります。　
あとありがちなのは、企業グループ統... 続きを見る

ゴールのすり合わせですね。
同じ機能を作るとしても、ビジネスサイドとエンジニアサイドでは見る観点が異なっており、ゴールの認識がズレる場合がありました。
なので最近は「この認識であってますか？」とゴールの認識合わせを必ずやるようにしています。

下記のようなのはありそうです。

- 使ってるツールが違うのでやり取りを把握しづらい（エンジニアは主にタスク管理ツールなどの履歴が残るもの、ビジネスサイドはSlackや通話など情報があとでみつけにくいけどやり取りが早いもの）
- そもそもプロダクト側がやっていることや考えたことを共有してもどこまで理解してもらえてるかわからない（難しい部分の「理解」はできないので「認知... 続きを見る

目的は一致していても手段の部分で合意形成がうまくいかない時には難しさを感じます。
目的が達成されれば手段はなんでもいとは思うのですがコスト感覚や考え方の部分ですれ違いを埋めるのは時間がかかるなと思います。

以下、参考になれば幸いです。

1.プロダクトマネージャーは、エンジニアの提案にどのような態度でアプローチし、フィードバックや意見交換を行うべきか？

提案の内容によりますが、他の開発チケットと同じようにICEスコアなどの要求定義の優先度を決めるためのロジックで同じように判断します。そのロジックや意思決定の背景を伝えます。 続きを見る

必要な準備というのは諸々動かれていると思うので、どちらかというとそこに取りこぼしが発生する前提で、引継ぎ後のコミュニケーションの場を設定して置くというのはよくやっております。

■引継ぎ後の３ヶ月くらいは週１位の頻度で引継ぎ前後のメンバーでランチMTGでお困りごとがないか確認してみる。
※退職されてしまう場合は残念ながらこの限りではないですが、その場合は正式な引継ぎ日... 続きを見る

こんにちは。

新卒でSIで働いていたときに学んだのですが、あの業界は入れ替わりが多いので、「手離れのいい仕事をしたほうがいい」と学びました。そうしなければ次に移れないし、残された人が苦労するので、自分の評価も下がるからです。

それ以来、あるポジションについたときから、再現可能な部分や必要最低限の情報は残すようにしています。開発にかたよった内容になりますが... 続きを見る

文化をざっくりと議論のテーマにしてしまうとどうも抽象度が高く、なかなか良い議論ができなかったなと個人的な経験では強く感じています。ゆえに、特に小さなチームにおいては「カルチャーは結果論」とある程度割り切ってしまうことも大事なのではないか？とさえ思ったりしています。いいプロダクトは、プロダクトに関わる人の貢献によって生み出されますし、関わる人たちと話し合いながらプロダクトをもっと効率的に、品質高く開... 続きを見る

役割上、私も代表の意見を言語化することが多いので、私の意見が参考になるかわかりませんが回答させてもらいます。

相手の考えや思い、言葉を理解する時に私が思う一番重要なポイントは、「相手と同じ言葉で話す」ということかなと考えています。ちょっとした形容詞だったり、語尾だったり、喋り方だったりをその人っぽい感じでトレースしていくと、不思議なものでその人と同じようなパターンで思考ができ... 続きを見る

ちなみに私は素朴ですが「会議体の整理」と「業務依頼箇所の統一」です。

私もコミュニケーション面だとこの2つは効果的だったと感じています。
業務依頼はフォーム化し、フォームからチームのバックログに同期されるようにつくっていますが、業務依頼に必要な情報をテンプレート化してもらうことで、よりチーム間での自律した動き方につながってい... 続きを見る

全社Notionと、Notion DBをフル活用しています。
フルリモート企業で、非同期的なコミュニケーションで業務を進めるため、
同期的なオンラインミーティング以外はほぼ全てがNotion、Slackで行われています。

▼ドキュメント、タスク管理
・弊社では個人のタスクの全てを管理する個人DBがあり、個人が何をやっているかほぼわかります。 続きを見る

その本を読んでないので、チームAPIの概念を読み違えていたらすみません。

これはわかりやすくチームが連携しやすくなった

この観点で僕のチームで取り組んでいることを回答させていただきます。
僕たちは「デザインコンポーネント」をデザイナーと協力しながら定義し、ネイティブアプリ内で使うUIパーツ、テキストカラーなどは基本... 続きを見る

皆さんとは少し違う切り口になりそうだと感じたので回答させていただくのですが、常に同時のコンテキストを持っておくことで何がきても切り替えが発生しない状態にしておく。というのを自分はやっているかもしれません（性格特性や職種もありそうです）

多数のアジェンダに触れることができる一方で、深く考えるのにはコツや、瞬発力が必要なので、よく知らない対象にはあまり使えないのですが。 続きを見る

忘れていることもありますが、なるべく質問するように意識しているのは
「チームや会社内で気になっていることはありますか？」というものです。
それだと出ない場合もあるので、「チームをこうしたらもっと良くなりそう、と思いつくことはありますか？」のように言い換えることもあります。

目的としては、マネージャー目線を持ってもらいたい、というところにあります。 続きを見る