アプリなら、コメントが見やすい！
トップへ戻る
なごみ系Wikipedia
konifar-zatsu.hatenadiary.jp
Sansanの@m_nishibaさんを雑談に誘ってお話ししている中で、自分がふと「ちょっとキャパオーバー気味なんですよねぇ」と口にしたところ、それはちょっと"臭う"兆候だよねという話になったので雑にまとめておきたい。 3行でまとめるとこんな感じ。 (一般論として) マネージャーはやることを自分で決められる裁量がある キャパオーバーではなく、"優先順位を下げてやらない"判断であるべき キャパオーバーという言葉が出てきたら一度立ち止まって優先順位の見直しをするとよい たしかに~~~~。ポロッとキャパの話してしまうことがあるんだけど、本来は何をやるか/やらないか (≒キャパ) を決めるのもマネージャーの役割なので、キャパオーバーはおかしい。キャパオーバーという言葉が出てきたら、それは優先順位づけがうまくできていないサインと思う方がよい。 とはいえマネージャーはやること多すぎて自分でキャパ決める
何かを相談された時、自分は相手の状況や主張にまず共感を示してしまいがちである。嘘をついて同調しているわけではないのだが、この姿勢自体が状況を悪化させることもわりとあるよなと思っていて、雑にまとめておきたい。 たとえば「他チームの◯◯さんが開発の状況を理解してくれていない。理解する気も見えない」といった相談をされたとする。それに対して、「あーなるほど、たしかにねぇ」みたいなことを言った瞬間に、溝を広げることになってしまうかもしれない。 この場合、本来はお互いの歩み寄りが必要な話なのだが、相談してくれた側に寄り添って話すことで当事者間の関係性がよくなるどころか悪化することもありうる。吐き出してスッキリするかもしれないが、根本の解決にはならない。 チームメンバー思いのマネージャーや組織の中の"いい人"ほど、知らず知らずのうちにこの罠に陥りがちな気がする。おそらくコーチングを学んだ人はこういう相談
7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ
率直に思ったことを言ってくれる人は貴重である。貴重であるが故に、敬意をもって接しなければならない。 特に反対意見や耳の痛い感想はなかなか言えない人も多い。 たとえば何かをやるかどうかの相談をした時に、「そもそもやる意味あるんですか？」とか「全く賛成できないですね」とか「自分は絶対やりたくないです」とか。言い方は改善の余地があるかもしれないが、こういう意見をぶつけてくれる人は大事にした方がいい。 大事にするというのはどういうことかというと、意見を言ってくれたことに対してお礼を言う、誠実に向き合って返答する、伝え方に関してフィードバックをするといった具体的なアクションを起こすことである。当たり前と言えば当たり前なんだけど、実行できる人は意外と多くはない。 特にお礼を言うというのは意外とやれていなかったりする。性格にもよるとは思うが、率直に意見を言うのにはエネルギーがいる。相手に伝わるように強め
組織において、主語を"集団"にしだすとよくないと思っていて、その話を雑に書いておきたい。 たとえば納得しにくい決定事項があった時に、「これってどういう経緯で決まった話ですか？」と聞いてみると、「法務側の要請で...」みたいな話になったりすることがある。 似たような話として、「営業チームの意見として」とか「経営陣からの意向で」とかも同じ。こういう"集団"が何かを言っているみたいな表現が出てきたら注意した方がいい。"チーム"も"経営陣"も"会社"も、それ自体が意見を言ったりしない。意見を言うのはいつでも個人なのだ。それを明確にしないと、バイアスにかかってしまったり遠回りしてしまったりして、物事をよい方向に進めにくくなる。 主語が"集団"になると、とたんに個々人ではコントロールしにくいものだと勘違いしてしまう。そういうちょっとしたストレスが積み重なって、「あのチームは〜」とかなんだか他人事のよう
fukabori.fm で話されていた『問いかけの作法』を読んだ。自分にとってはかなりよかったので、初めての感想文的なものを雑に書いておきたい。 amzn.to とにかくよかった。これまで自分もたくさんの会議や1on1、面談などを行い都度反省して工夫してきたが、それらの工夫がほぼ全て"体系化"されてまとめられていた。自分がやってきた/やっていることが6割くらい、残り4割は新しい発見として楽しく読めた。ハンターハンターで言うと、念の六性図くらい見事に体系化されていると感じた。 たとえば質問を投げかけた後に意見が出なそうだったらいくつか具体例を出してあげるフォローアップなども、『列挙法』という名づけをして解説してくれている。カイゼン・ジャーニーの中で紹介されている、意見を5段階で示すファイブフィンガーも、この本の中の『パラフレイズ』という手法と捉えられる。 やっていることに名づけがされると頭の
何かを決めるゴールを設定した会議において難しいのは、議論を収束させていくフェーズである。 議論の抽象度の高さによって難易度は変わるが、収束させるにあたってここは抑えておくとよいみたいなTipsはあると思うので書き出してみる。 決めることがゴールという認識を合わせる そもそも決める場だという認識が揃っていないと収束させるのが難しい。会議のフォーマットに目的やゴールを明記しておくとよい 最終的な決め方を決める 最終決定者、時間、多数決などなんでもいいが、最後にどう決めるかを決めるのが大事。できれば議論が始まる前にやっておくと、議論中もそれを意識して進められるのでやりやすい 決めるための材料の認識を合わせる 判断軸とも言える。議論が何かうまくいかない時にはだいたいこのへんの認識が揃っていない。言葉に対する認識が揃っていないこともあるので齟齬をなくしておくの大事 決めるための材料を今揃えられるかを
チームの方針を伝えたはずなのにうまく伝わっていないということはよくある。そういう時、「前にも言いましたけど」みたいな話をしだすと不幸にしかならない。情報のやりとりは伝える側と伝えられる側双方の協力が不可欠だが、コントロールしやすいのは伝える側である。方針が浸透していない時に確認したいチェックリストを雑にまとめておく。 理解してくれているか 同じ言葉でも認識が違うことは多い 特に方針はキャッチーな表現を使って抽象度が高いこともある 具体も伝えて理解しているかどうかを確認すること 納得してくれているか 意義を感じていないと浸透しない 説明する側が納得していることはもちろん、納得させられるまで話すこと 方針の背景や議論の流れ、最終決定事項までアクセスしやすくして個々人が自律してキャッチアップできるようにしておくことも重要。いわゆる情報の透明性、フラットさ どちらかに決めて進む必要があることも多い
誰かから相談を受けた時、後でよくなかったなと思うことがちょいちょいあるので雑に書いておく。 相談の種類や関係性にもよるので、たぶん違和感を覚える内容も含まれるとは思う。 相手の話を聞く 当たり前なんだけど、意外とできてないこともある 自分の話を起点にしてはいけない。相手の話を聞くのが先で、自分の話は聞かれたらするくらいでいた方がいい アドバイスが必要かどうかを見極める 相談をされると解決のための話をしてしまいがちだが、そういう論理の話をしたいわけではないこともある 例えば聞いてくれるだけで救われることもあるし、相談相手が感情的に怒ってくれることで自分が冷静になるみたいなこともある 相手がアドバイスを求めているのか見極めた上で、アドバイスする場合にはバイアスをかけないように慎重に 同調しすぎない 共感と同調は違う。共感することは大事だけど、同調しすぎると相手の負の感情を増幅させることにもなる
最近嫁氏とバチェラー4を見ていて思ったことを雑に書いておきたい。 第4話にて、ある女性が「バチェラーがこう言ってた」みたいな少し事実と異なる内容を他の女性陣に話したことで、バチェラーへの不信感が広がりだいぶ面倒なことになるという"事件"があった。 それに対しバチェラーがすぐに1人ずつ対話の時間を作り説明していたのを見て、結局これしかないよなあと思った。 種類や程度は違えど、組織においてこういうことはよく起こる。その時に重要なのは、関係する当人とすぐに直接話すことである。 例えば事業の優先順位に納得できないときに、説明を受けた者同士でああだこうだと話したりするよりも説明をした人に直接聞いた方がよい。 あるいは誰かの発言に棘を感じてモヤモヤした時は、本人に直接話して解消したほうがよい。 小さいところだと、Slackで「これ大丈夫かな」「どうなってるんだろ」みたいな懸念を書くときには関係しそうな
何かの共有や相談をする時に、文章の表現や伝えるタイミング、伝え方や伝える順番などがとても"上手い"と感じる人がたまにいる。 逆に下手な人もいて、そういう人を見ると"もったいない"という気持ちになる。そういう人は伝え方で損をしてしまっているだけで、内容についてはかなりよく考えて準備もしていることが多いからである。上手い人と下手な人の違いはわりと暗黙知になりがちなので、何が違うかを考えながら雑に書きなぐっておきたい。 文章のテクニックや声の抑揚、表情といった細かい要素はあるのだけれど、一番の違いはコミュニケーションをとる時のシナリオをどれだけ想定できているかだと思う。イメージとしては将棋やチェスで相手の手を読むのに近い。 「この話はSlackで伝えたら微妙なニュアンスが伝わらなそうだから直接話そう」とか「チームの定例で話すよりも1対1で直接説明した方がいいかもな」とか、それくらいのレベルのシナ
マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。 ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは？」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。 つまるところ、いわゆるマネージャーとプレイヤーの違いは、
仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。 ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。 それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。 一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状
先日参加した pmconf 2021 の Discord に、クロージングのあと約20分ほどハンターハンターのチャンネルが作成され、そこで少し雑談をした。 ハンターハンターの台詞はプロダクト開発の中でも活かせるものが多いよねという、雑談チャンネルにふさわしい内容であった。正直自分でも後で何の話だっけ？となりそうなので、話した内容 + α をざっと書いておく。 ドキドキ2択クイ~~~~~~~~ズ!! プロダクト開発の中で、トレードオフを考慮しなければいけない場面は多い。「ではドキドキ2択クイズしますか」のように使うと議論が整理できてよい。ただし、この場合の答えは「沈黙」ではない。また、トレードオフだと思い込んでいるだけで実は「ナカヌキ」的な一手が存在しうることもあるので注意が必要。 今オレ達にとって最悪のケースってのは何だ？ 議論の本質が見えなくなった時に整理できる。実は今話している前提から
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack
TECH SCHOOLが提供しているBackend master classの題材であるSimple Bankをやってみた感想を書いておく。最後までやってから書こうかと考えていたが、思ったより内容が濃くて忘れちゃいそうなので途中経過を書くことにした。 github.com 全31回分のYouTubeの動画を見ながら残高管理、送金を行える簡易銀行サービスを作成する形式で、いま10回分やってみたが結構よさそう。10回でどのくらいまでいくかというと、DBスキーマの設計・作成、CRUD制御のGoのコード/テストコード作成、Postgresのデッドロックや同時実行制御の理解、GitHub ActionsによるCIの設定ができる。 対象レベル ある程度開発経験のある人が対象 Databaseとは？Dockerとは？Git/GitHubとは？といった説明はない GoはTour of GoをやっておけばO
幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。 発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか？」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。 成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。 一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題
視座の可視化というこの記事がめちゃくちゃ好きで、たまに読み返している。 note.com ここに書いてある、課題があった時のアクションのレベルみたいな話がわかる~~~って感じで好き。 具体的には何らかの課題があったときに下記のどのアクションをするか判断できそうです。 ・ そもそも気づいていない ・ 認知してる（けど言語化できない） ・ 問題指摘する ・ 解決策を提示する ・ 解決する 自分の経験だと、「問題指摘する」と「解決策を提示する」の間に結構隔たりがあって、指摘したら物事が前に進むと感じている人が意外と多い気がする。 また、問題を指摘してるつもりで、実は問題を把握できてなかったり適切に指摘できてないケースも多い。例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えればいいのに」とコメントしたとして、これは問題の指摘と言えるだろうか。これは
組織の透明性を高めるためには発信側の工夫が不可欠だが、情報を受け取る側のスタンスも認識を揃えておいた方がよい。 自分の経験上、こういうスタンスでいるとよいんじゃないかという話をざっとまとめておく。 情報は常に100点ではないもの オープンになった情報は常に完璧な状態というわけではないという姿勢でいた方がよい たとえばSlackでシュッと投げ込まれたタスクや事業の方針に対して、背景がわからずモヤッとしたみたいな経験はあるかもしれない 複雑な話ではこういうことが起きがちで、わからないことがあると人は不安になる とはいえ、完璧を目指して情報が公開されるのが遅れたり公開されなくなったりするのはよくない 情報を公開する側は、実は結構緊張していたりする そのため、情報を受け取る立場としては、「情報は常に100点な状態ではなくむしろ100点に近づけていく部分も皆でやるんだ」くらいのスタンスでいた方がよい
たまに「あー今自分をよく見せることを考えて発言しちゃってるな」と自覚して恥ずかしくなることがある。 例えばミーティング中、何かを前に進めることよりも皆にオッと思われるような内容を言うことに頭を使っているみたいな。そういう時はたいてい後で恥ずかしくなってｳﾜｱｧｧｱｧ!!!となる。 状況によっては、信用を得るためにそういう振る舞いが必要になることもある。「コイツできる...」と思わせることで物事をうまく進められることも多い。自分をよく見せるために何かをすること自体が悪いわけではない。問題なのは、その振る舞いが癖になって自覚できなくなっているケースである。 「何かいいことを言ってやろう」という気持ちが先行しすぎた状況と言えるかもしれない。誰かの意見に対して「自分はもっとこう考えてる」みたいな話をとにかく出そうとしたり。インターネッツ上だとさらに厄介である。 例えば、採用候補者が期待とそぐわない
最近夜や休日に自分の勉強や開発をできなくなった。 夜や休日にそんなことせずに業務時間内でやるべきでしょという意見もあると思うが、自分の場合は以前は苦もなく自然とやれていた。それが今はできていない。 理由は明確で、自分が集中できていないからである。背景には育児家事の話はもちろんあるが、時間が取れていないわけではない。 息子は睡眠エリートで毎日2~3時間昼寝をするし夜20時半には寝ている。寝ている時間に何かをすればよいのだが、手が付かない。イメージとしては、1日のMPを使い果たしている感じ。こういう感覚は育児に関係なく経験していて、集中できなくなってしまう時期はあった。 なので「育児家事で時間が取れない」というのは正確ではなくて、「自分が集中できていない」というのが正しい気がする。これは自分の考えであって、家庭にもよるとは思う。家事育児の事情は本当に家庭によって全然違う。子どもが生まれたことで
グレード評価制度において、上のグレードに行けば行くほど期待が抽象的になるよねという話を会社の同僚氏と話していた。 ICでもマネジメントでも影響を及ぼす範囲も広がり、できることも増える中で求められることも自然と多くなってくる。 そんな抽象的な期待を明確にする部分も求められているよねと同僚氏が言っていて、それはたしかにと思った。要するに、自分がどこで成果を出すべきかを自分で定義できるスキルが必要になってくるということである。 ジュニアとシニアみたいな分け方があるが、これはシニアに求められるスキルの一つかもしれない。何をやったらいいのかわからない中でもまわりを見渡して、必要なアクション (must)と自分のやりたいこと (will)とできること (can)をすり合わせて方向を決めるみたいな話である。 それはマネージャーの仕事だろと言われればその通りなんだけど、グレードが上がるとそういう抽象的な期
何かを伝えたり聞いたりする時には本人と直接話す方がよい。当たり前っちゃ当たり前なのだが、意外とうまくできていないことも多いので最近特に強く意識するようにしている。 「どうなってるか分からなくてモヤモヤする」とか「あの発言や行動ってどういう意図なんだろう」とか、内に籠もって想像だけしているとロクなことがない。直接本人と話してみると実は何の問題もなかったなんてこともある。 ただ、直接話すのは簡単なようで難しい。話す側は感情のコントロールと言語化のスキルが要求される。聞く側のスタンスも重要で、これは話す側はコントロールできない領域なのでより難易度が上がる。話す側聞く側どちらかに負荷が偏ると相手のコミュニケーション能力のせいにして余計にめんどくさいことになってしまう。組織においては、直接話して物事を解決すること自体を推奨するといった工夫が必要かもしれない。また、ある程度はスキルトレーニングもあった
社内アンケートや読んでおいてほしいマニュアルなどがある時、『タスクが終わったらleaveするSlackチャネル』を作って必要な人を全員入れておくと楽。同じようなことをやってる会社も多いんじゃないかと思う。 自分が所属している会社のSlackチャネル命名規則では、こういった一時的な用途で使うチャネルには tmp- prefixをつけるようにしている。 どのくらいの人が終わったかをチャネル内の人数で把握できるし、リマインドも @here メンションでできる。チャネルを切り出しているので、Zapierなどでリマインドを自動化するのも楽。 やる側としても tmp チャネルにずっと入っているのは嫌なので早めにやるモチベーションになる。 やったことがないと「うざったいんじゃないの？」と思われるかもしれないが、関係なかったらすぐleaveすればよいし、関係あったら終わらせてleaveすればよいだけなので
マネジメントの仕事を始めて1年半くらい経った。日々ﾊﾁｬﾒﾁｬが押し寄せてきて泣いている場合じゃなく、落ち込んだりもしたけれどわたしは元気です。 主に気持ちの持ち方みたいなところでの変化を雑に3つくらい書いておくことにする。 自分がやる必要はない 全部やろうとせず委譲するのが大事とはわかっていても、それをやっていると「俺いる意味あるんか...？」と感じることがある。側から見るといわゆる自己組織化、適切な権限委譲が行われているということになるかもしれないが、当人は焦ってしまったりする。 自分が為すべきことを明確にして、それを達成できるのであればどんな形でもよしというマインドを持っておくとよい。メンバーを信頼して任せるというのはもちろん、自分にできないことをまわりを巻き込んで達成することも必要。極端な例だと、自分の言葉でチームメンバーのモチベーションを上げられないのであれば、別の適切な人を召喚
オンラインのミーティングで「何か質問や意見ありますか」と聞いた後の無言がつらいんだよねという話を聞いた。わかる。自分はもはや慣れきってしまったけれど、今でもいい方法ないかなあと考えている。 いくつかやったことを書いてみる。組織によってもだいぶ違うと思うけれど、他の人の知見をめちゃくちゃ聞きたい。 最初に声を出してもらう 少しでも最初に声を出しておくと意見を言いやすいという研究があるらしい。なんとなく実感としても正しい気がしている。 ただ全員に雑談を振るというのもちょっとなあという時に自分がやっているのが「出席をとります」である。皆なつかしい気持ちになってほんわかするし、返事をするだけでもよいので楽。時間もかからない。 参加者の役割を最初に話す どういう役割や発言を期待しているかを明確にしてあげるとそのスタンスで意見を言いやすくなる。たとえば「○○さんにはモバイルの開発工数観点でかなり現実的
息子氏がスプーンやフォークで一人で飯を食えるようになってめちゃくちゃ楽になった。素晴らしい権限委譲だ。ﾔｯﾀﾈ!! 自分はタスクを人にお願いするのが未だに得意ではない。息子氏がスプーンで飯を食えるようになったのも、嫁氏がスプーンを持たせて少しずつやらせていったという要因が大きい。自分は朝の忙しい時などついアーンさせてしまうことも多かった。 この「自分でやった方が早い」、あるいは「相手にはこのタスクはまだできない」という思い込みが、タスクの委譲をうまくできない根本の原因である。できるかどうかはやってみないと判断できないにも関わらず、お願いする前から決めつけてしまっているのである。 そもそも何かのタスクを委譲しようとする時、それは相手にとって初めての内容であることが多い。なので基本的にはお願いしてみないことには何も始まらない。相手を信頼して任せた上で、うまく進めるための設計を考える必要がある。
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションボードなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するなり
次のページ
このページを最初にブックマークしてみませんか？
『Konifar's ZATSU』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
