サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
konifar-zatsu.hatenadiary.jp
自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対
マネジメントでよく言われるセオリーとして、組織の「これをやらねば」という "must" とメンバーの「これやりたい」という "will" とメンバーの「これが得意」という "can" の重なるところを見出して目標設定やアサインをすべしという話がある。 特に "will" が大事で出発点にすべきという話も聞く。現在の興味領域である短期的な will に加えて、キャリア志向を踏まえた中長期的な will もきちんとすり合わせていくとよいという。まあわかる。人間やりたいことをやってる時が一番力を発揮できる。逆にやりたくないことをやっている時は全然パフォーマンスが出ないものだ。 わかるんだけど、メンバー "will" をどのように考慮するかって結構難しいなと思っていて、雑に考えを残しておきたい。 何が難しいというかというと、メンバーが考えている "will" というのはあくまで今のメンバーの目線で
複数人に必ずやってほしいタスクがある時、『そのタスクが終わったら各自抜けるSlackチャネル』を作る運用にすると楽。最近試験的に"月の勤怠を提出したら抜けるチャネル"を Zapier で自動作成するようにしたので雑に書いておく。 Zapier はこんな感じで組んで、毎月1日10時になったら前月分の勤怠提出を促すための #tmp-kintai-YYYYMM チャネルを作成してメンバーを招待する。 で、11時、15時、19時に自動でリマインドし続けるだけ。若干無駄に Action を消費する Zap になっているので改善すべきだとは思う。 毎月ちゃんと提出してくれる人にはうざったいだけなので、そういう人は自動招待の対象から外していっている。だんだんと対象人数が減ってきているので、最終的にはこの仕組み自体が不要になればいいと思う。あと、欲を言えばこういうしつこく強制力のつよいリマインド機能自体は
組織において何か新しいことを始める時、あるいは既存の取り組みを変えていく時に、「まずいつまでそれをやってみるか」という"有効期限"を最初に決めておくと進めやすい。自分の中であまり整理できていないので雑に書いておきたい。 前提として、組織を取り巻く内部/外部の状況はどんどん変わっていくので変化があるのはいいことである。変化がない方がやばい。 たとえば、組織体制の変更、出社/リモート方針の変更、会社のバリューの変更といった全体に関わることもあれば、会議体の再設定、1on1の開催頻度の変更、リードの新任といったチーム内での変化もある。 それらを一定の合意を取りながら変えていく時に、振り返るタイミングを作る意味で最初に"有効期限"を決めておくとよい。内容によっては、お試し期間、キャンペーン期間、消費期限 のような表現のほうがしっくりくるかもいいかもしれない。 何かを変える時にはエネルギーがいる。変
自分のまわりのすごいなと思う人の仕事を観察していると、ひとつひとつのタスクを自分の"作品"のように仕上げているように見える。実際に彼らがどう考えているかはわからないが、自分から見た印象を雑に書いてみる。 たとえばチャットツールでの依頼のメッセージひとつ取っても、過不足なく端的な内容になっている。人によっては読み返して細かい表現を編集して変えていたりもする。美容師の最後の仕上げのようである。 エンジニアであれば、コード自体はもちろんコミットログを丁寧に残したりとかもそう。GitHubを使うならそこまでコミットログ自体にこだわりすぎなくても履歴を追いやすいが、それでも手元でrebaseやsquashを駆使して綺麗に整えている。 同様に、IssueやPull Requestのテンプレートがあればそれに沿ってきっちり埋めてくる。テンプレートのままの状態で出したり無視して適当に書いたりしない。もしも
個人目標を考えるのは難しい。以前自分の思考整理も兼ねて、開発メンバー向けに"個人目標設定の手引き"をスライドにして共有したことがあった。 組織によって制度も解釈も違うのでそのまま適用できるものではないと思うが、もしかしたらどこかの誰かの何かの参考になるかもしれないので雑に内容を共有してみる。 ちなみに自分は 何のための個人目標設定？ - Speaker Deck に書いたとおり、目標設定自体は必要だとは思っている。「そもそも目標設定なんて不要やろ」って意見も間違っていないが、雑にいうと"組織による"としか言えないのでそこは触れずにおく。 よい個人目標とは 『意義を自分の言葉で語れて、 日々の行動が変化する目標』 『意義を自分の言葉で語れるか』 トップダウン/ボトムアップどちらでも構いません。 かなり高い目標でもちょうどよい目標でもどちらでもいいです。 「なぜそれが今必要なのか」 「やること
スキルも経験も積み重ねてきた人が抱きがちな悩みとして、「自分が意見を出すと毎回大きな反論なく通ってしまって不安になる」というのがある。 いわゆるリードができるレベルになると、他のメンバーより視野を広く持って色々なことに考慮した意見を出せるようになる。しかし実際には明確な答えは持っていなくて自信があるわけでもないこともある。 それなのに自分が言ったことがそのまま通ってしまう。発言すると、「たしかに」「そうですね」「いいと思います」みたいな雰囲気になって採用されていくのである。新しいサービスの設計方針の議論、コードレビューでのやりとり、チーム目標を決めるミーティング、さまざまなところでこういうことが起きる。 「本当にこれで大丈夫なのか」という不安も感じるし、「もしかしたら自分が発言することで他の人の意見をふさいでしまったり萎縮させてしまったりしてるんじゃないか」と心配になってくる。人によっては
何かの取り組みを始める時、たいていまずは"過去の経緯"をざっと調べると思う。そうしないと過去に起きた問題を踏んでしまったり再発明をしてしまったりするからである。 皆当たり前にやっているように見えて、この過去の経緯の調べ方には意外とスキルのバラつきがある。自分も常にうまくできているわけではないので、思考整理のために雑に書き出してみる。 たとえば一例として、「Androidの自動テストの方針」を決めようとしているとしよう。背景にある課題は適当に想定してほしい。次のようなステップで過去の経緯を調査していく。 1. 調査期間を決める 調査はダラダラとやってしまいがちなので自分で期限を決める 内容にもよるが、自分は半日~1日に設定することが多い。社外の方とのスケジュール調整が入る場合には1週間くらいかかることもある 例で言うと、自分ならいったん1日で設定してガッと集中して調べてキャッチアップすると思
誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって
「マネージャーとして大事なのは常にご機嫌でいること」という話がある。わかる。正しい。不機嫌だと相談されなくなり、結果として軌道修正もできず組織の成果も上がらなくなる。本当にご機嫌じゃなくとも、少なくとも"ご機嫌なように見える"状態をキープした方がいい。 この話には完全に同意なんだけど、マネージャー自身がコンフォートゾーンを抜けてチャレンジしている時に常にご機嫌でいることってまあまあ難しい。疲れたりして余裕がなくなると頭が回らなくて反応も少し雑になり、周囲から見ると不機嫌に見えてしまうこともある。 そういう時に、「不機嫌に見えたとしてもあなたのせいではないよ」と先に伝えておくといいかもしれないという話を雑に書いてみる。これは同僚が昔やっていてすごいなと思って、それ以来いざという時の自分の"引き出し"のひとつになっている。 誰かが不機嫌な時に萎縮してしまうのは、「もしかして私が何かよくないこと
今思い返すと小学校の頃の色々な決まりごとはよくできていて、"大人"の組織にも適用できること多いよなと思うことがある。 ジェネレーションギャップもありそうだが雑に書いてみる。 帰りの会 いわゆる"夕会"だよね。大事な連絡事項を漏らさず伝えて、皆で話し合うべきことがあれば話せている。そういう場が定期的に必ずやってくるのは大事。 係活動 "勉強"という主目的以外に必要な取り組みをうまく分割して役割として任せて自律させている。大人になった今、組織目標に囚われて必要な取り組みを"差し込みタスク"のように扱っていないだろうか。必要なことであれば、"いきもの係"的に切り出して取り組めるように設計するといいかもしれない。 日直 リードをローテーションして皆が均等にできるようにしている。ある程度マニュアル化されており、たいてい2人ずつアサインされるところもいい仕組みだと思う。小学校の日直でできていたなら、定
「透明性が大事」「透明性を高めるべき」という声をよく聞くが、意外と"透明性が高い"という状態が何なのか人によって認識が違うことも多い気がする。 認識をある程度揃えておかないと、透明性だか何なのかよくわからないものを過剰に追い求めて疲弊してしまいがちなので雑にまとめておきたい。 透明性とは何か、なぜ必要か 目的は事業の成長。成長を安定させスピードを上げていくには、組織が自走できる状態を作るべきという前提 組織が自走できる状態を作るには、"情報"と"価値観"を揃えることが必要条件 特に"情報"を揃えやすくすることを「透明性を上げる」と表現しているという理解 情報が揃っていないと正解に近い意思決定を素早く行えないだけでなく、組織内の不和を生みやすいのでとても重要 透明性の要素分解 組織の"透明性"を形作る要素は次の4つだと考えている。 1. 公開されていること 情報が公開されていないと何もわから
雑に書いていくぞ！気合い抜いてけ！ わりと大きめの障害が起きても焦らずどっしり構えて対応できる人がいる。大舞台での登壇でも余裕で堂々と話せる人がいる。 これはひとえに、たくさん打席に立った結果「あの時のあれよりは楽/マシだな」と思える境地に達しているのだと思っている。思えば、自分も「あの時よりマシ」を積み重ねて更新しながら生きている気がする。 社会人2年目の時、大障害が発生して先輩方が全員対応にあたることになり、既存の開発と問合せ対応をまるっと任されたことがあ��た。何度思い出してもハチャメチャで、今でもユーザー対応をしていると「あの時よりは楽だな」と感じることも多い。 2014年に世界コスプレサミットのアプリコンテストで入賞して、コスプレ会場で3分のピッチをすることになった。会場に着いてみると想像していた規模と違ってマジかよと震えながらも何とかやりきった。 今でもカンファレンスなどでの登壇
最近雑じゃなくなってきた気がするのでより雑めに垂れ流すことにする。 自分が苦手だと思い込んでいたことが、苦手とかそういう属性次元の話じゃなくて事前の準備が足りないだけということがある。 たとえば、自分は「メールが苦手でつい見逃しちゃうんですよね」と言っていたことがある。Slackだとすぐ反応できるのにメールだと億劫になってしまうのだ。 少し時間を取ってラベルを整理したりSlackに連携して流すようにしたりすることで解決した。苦手とかではなくて、単に工夫のひと手間をサボっていただけだった。 人前で話すのも苦手と言って避けていたことがある。 話すのがうまいように見える人にどうしてるか聞いて観察してみると、自分より入念に調べてフィードバックをもらって10倍リハーサルをしていた。苦手とかではなくて、単に補うための準備が足りていないだけだった。 懇親会でボッチになるのが苦手と言っていたことがある。話
マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
会社のカジュアル面談に来てくれた方と話すと、自分自身考えさせられたり意見を交わして理解が深まったりする。 自分が以前に聞かれて特に面白かった質問を雑にいくつか書き出してみる。会話の中で出てきた質問なので、このままストレートに聞かれたわけではない。 いま楽しいとしんどいの割合はどのくらいですか EMをやっていた時で、しんどいが7くらいで答えたと思う 割合を答えるだけなので答えやすく、それに対してどう感じているかといった深堀った話もできて面白かった もちろん楽しい割合が多いのも素晴らしいのだけれど、ある程度しんどさもあるのが常だし真っ当だと思っていてリアルなところを聞けるいい質問だと思う 自分が入るであろうチームで一番大きい課題は何ですか 当時解決してほしい課題は明確にいくつかあったものの、実は"一番"大きい課題と聞かれるとバシッと答えられなかった 話していく中でこういうところが一番ですかねみ
ワールドトリガー247話にて、ヒュースが若村に話した言葉が非常によかった。 "刻むんだ" 目の前の1段を登るために必要な要素を 1段の中でさらに刻んで 自分が登れる小さいステップを作るんだ その行動を努力と呼ぶ 痺れる~~~。この"刻む"というのは目標達成のための大事な考え方なのはもちろん、タスクを進める時にも同じように"刻む"技術が必要。自分もうまくできないことがあるので、雑に考えを書いておきたい。 仕事において、ゴールまでの道筋を刻んで小さくして進めるのはとても重要。進み具合をトラッキングできるし、刻むことでチームで仕事をしやすくなる。いわゆるジュニア、ミドル、シニアの違いは「どれくらい抽象的で大きいことを刻んで進められるか」の差と言ってもいいかもしれない。 このゴールを"刻む"技術はどうすれば身につくのだろうか。経験によって全体を把握する力がついた結果できるようになるというのも一定あ
誰かがリードしている時に、それを支え、あと押しするような振る舞いをフォロワーシップと呼ぶ。 フォロワーシップについては、Derek Sivers の TEDトーク How to start a movement や あんちぽさんのやっていき、のっていき が自分は好き。研究でいうとロバート・ケリー教授の The Power of Followership の5つの分類が有名。 難しそうに感じるかもしれないが、実はフォロワーシップの実践というのはもっとゆるいところにも現れるものだと思う。自分のまわりの人たちがおそらく無意識的に実践しているように見えることを雑に書きだしてみる。 1. 反応を返す 誰かが発言したり何かを書いたりしたことに対してわかりやすく"反応を返す"という振る舞いは、意外と皆ができていなかったりする ミーティングで最初の挨拶に対して挨拶を返したり、「何か質問や意見ありますか？」
課題を見極めたり新しい取り組みを始めたりする時に、「どういう状態だとうまくいってると言えるんだっけ？」という質問に答えてみると考えを整理しやすい。 たとえば、マネージャーの立場で「なんだか組織の雰囲気がよくないと感じる」という声を拾ったとする。これに対して、「どういうところで感じるか、なぜそう感じるか」という深堀りをして根っこを見極めることももちろん大事なんだけれど、その人にとって「雰囲気がいい」というのはどういう状態かを聞いてみると何を目指していくべきか目線を揃えやすい。 目標設定制度をどうしていくかを考える時なども同様で、「目標設定がうまくいってる状態ってどういう状態だっけ？」という話から考えてみると議論しやすかったりする。たとえば、「今あなたは何にチャレンジしていますか？と質問したら皆が即答できる状態」みたいな定義がでてくるかもしれない。 マネージャーが職責を果たしている状態とはどう
何かを説明する時に具体例を出すと主題が伝わりづらくなってしまう現象について雑に書いておきたい。 具体例によって読み手/聞き手がイメージしやすくなり理解を深められる一方で、次のようなことが起きる。 一例を全てのように捉えられる 主題ではなく例示に注目される 1は、あくまで主題をわかりやすくするための補足としてひとつの例を上げただけなのにそのケースのこと"のみ"を言っていると捉えられるという話。抽象的な主題を頭に残したまま具体例を具体例として捉えて理解するのは難しいことなのだ。 2は、読み手/聞き手が理解しやすい具体例の内容に引っ張られてしまうという話。説明を補足する具体例というのはわかりやすい分、頭がそこにフォーカスしてしまいがち。しっくりくる例ではないことが原因ということもあるが、具体的な話には突っ込みやすいのでそっちに引き寄せられてしまうのだ。 じゃあ伝える側はどう工夫すればいいかという
マネジメントの想定問題集があれば、疑似体験により引き出しが増えて成長が早まるのではないかと思ったことがあるので雑にかいておきたい。 マネジメントは昔からたくさんの関連書籍も出ていて、ある程度型をもって技術として磨いていけるものではある。 一方で、「やらないことを決める」「思い切って委譲する」といったいわゆる"セオリー"的なことは理解はしつつも、そういう小綺麗な話ばかりではないのはマネジメント経験者なら共感できるのではなかろうか。 社内での役割や経営・メンバーとの関係性にもよるけれども、たとえば次のような泥くさい想定問題があったらどう答えるか考えてみると面白いかもしれない。 1on1 でメンバーから「事業 / プロダクトの方針がわからない」と言われました このまま放置すると離職リスクになりうるかもしれません マネージャーとしてどう動きますか？ 事業計画上、4週間後にはリリースしたい機能があり
人がやる気になる理由というのはそんなに単純に整理できるものではないが、自分にとっては"報酬"と"成長"と"貢献"の3つのバランスで成り立っていると感じる。 そんなに整理できていないので雑にまとめておきたい。 報酬 いくらもらえるかはめちゃくちゃ大事 報酬で自分の価値を確認できるという人もいる 安かったらいざという時に踏ん張れないし、高かったらその分頑張ろうと思える 成長 自分のためになっているか、成長しているかという感覚もめちゃくちゃ大事 まわりに尊敬できる人がいるとか、近くで働いていると刺激を受けるとか勉強になるとか 成長実感以外でも、すごい/かっこいいと思われたいみたいなのもこれ 貢献 同僚の役に立てたり、ユーザーに喜ばれたりする感覚もめちゃくちゃ大事 自分の力を何かしら活かせているかという話で、これを満たしていると自己肯定感も高まっていく 全部大事と書いてしまったけれど、年齢やライフ
無駄なミーティングは減らすべきという考えには完全に同意しつつ、自分はミーティングを先にセットしてしまって事前にアジェンダを作りながら考えや論点を整理して進めることも多い。締切駆動の派生、"ミーティングアジェンダ駆動"で整理していると言える。 自分にとっては素早く物事を前に進める"型"のひとつになっているので、どんなアジェンダdocsをまとめながら整理しているか雑に書いておく。 目的 目的が明確じゃないミーティングは不要なので、ここを最初に書く。書けないならミーティング自体をバラす そもそも何したいんだっけ？というのを再確認できる。意外と研ぎ澄まして書けないこともある 語尾は「~したい」のように"目指したい姿"を表す形で箇条書きにすると整理しやすい 今日のゴール 目的とは似ているが違う。今日のゴールは、これが達成できたらこのミーティングは成功という指標。目的を具体化して到達するべきラインを明
何かを進める時に感じている懸念をうまく伝えるのは地味にむずかしい。 あまり気にせず伝えられる人もいると思うが、自分が消極的なことばかり言って水を差してるみたいな空気になる気がして言いにくいという人もわりといるんじゃなかろうか。自分もそう考えてしまって伝え方やタイミングに悩むことがある。 しかし個々人が感じている懸念というのはめちゃくちゃ重要で、小さな違和感もちゃんと伝えてくれる方がよい。これまで誰かのちょっとした懸念から事故を防げたということは何度もあった。 "伝え方"にも一定コツはあるが、"吸い上げ方"にも工夫できることはあるので、雑にまとめておきたい。 枕詞の引き出しを増やす 伝え方の工夫として、変な空気になりにくい枕詞がある 「めちゃくちゃ心配性なこと言ってもいいですか」、「やりたくないとかではなくて、イチ意見として気になったんですけど」、「今さらなんですけど、皆で安心していい感じに
7月くらいに入社した同僚氏は「問題を放置しない」が口癖で、半ば麻痺している痛いところを突いてはすぐに何かしらアクションに移して状況を変化させている。ハイレベル問題解決ブルドーザーである。 「これは放置しないほうがいいですね」、「放置しないほうがいいのでやりましょう」といった感じで話してくることもあれば、「これどうします？放置しますか？」のように聞いてくることもある。見て見ぬふりをしたり、なんとなく結論が曖昧な状態のままにしておくことを"放置"と言っているらしい。ややこしい言い方をすれば、"今は (いつまで) 放置する"と決めたのであればそれは放置してはいないということなのだそうだ。 先日、彼が会議中にボソッと「問題を放置さえしなければちょっとずつよくなっていくんですよ」と言っていて、たしかになあとしみじみ噛み締めてしまった。 何かチャレンジをしていれば問題が多々発生するのは当たり前ではある
チャットコミュニケーションむずかしい。全然そんなつもりで書いてないのに受け手の解釈が乗っかって伝わったりする。 たとえば純粋に質問しているだけなのに責められているように感じる人もいるし、感謝を伝えたつもりが煽りや嫌味と捉えられることもありうる。 そもそもチャット以前の関係性の問題として対処すべきこともあるし、受け手の人となりや状況を完全に理解することもできないのであまり気にしすぎても仕方ない。一方で、自分の経験上解釈ズレが起きやすい表現は明確にあって、自分はそれらを"禁止"するマイルールを作っている。誰でもできるチャットコミュニケーションの工夫の一つとして雑にまとめておく。 あー / えっと 「あー (そうじゃなくて)」とか「えっと (理解できないみたいだからどう言おうかな)」みたいな感じで相手に非があるという印象で伝わることもある じっくり考えられるチャットでこれらを書く必要もないので使
実質的に何かの役割を担っている"自称"の状態と、組織図上にも表されるような自他ともに認める明確な責務を持つ状態とでは、あまり変化がないようで全然違うという話を雑に書いておきたい。 たとえば「ほぼマネージャーみたいなことをしてます」という状態と「マネージャーとしてやってます」という状態は、マインドも動き方もプレッシャーも実は全然違う。 同じように、「事業責任者みたいなもんですね」という状態から実際に事業責任者というタイトルがつくと、想像よりも周囲の期待や自分のスタンスの変化が大きい。 タイトルが大事というわけではないが、名付けがされると自他ともにそのタイトルに対する期待イメージがより明確になる。それに伴って自分の心持ちや考え方、行動が変わるのはもちろん、周囲の反応も変わる。たとえば実質技術責任者みたいな役割を担っていた人にCTOという名付けがされると、急に「CTOとしてどう考えているのか」と
自分が動かせない前提条件と思い込んでいたことを、同僚氏の助言で実はコントロールできることに気づいて前に進められたということが何度もあった。 前提条件や制約だと決めつけてしまって問題を解決できないと思い込んでることあるよなという話を雑に書いておきたい。 特に陥りがちなのは、期限や人員、予算、規約、法律あたりだろうか。 たとえば「この日までにできないと失注と言われている」みたいな話も、先方と話すと代替案の提示で調整可能なこともある。 「今期の予算が取れない」といった話も、実は今後1年のROIを正しく理解してもらえれば変更しうることもある。 所属開発チームの中ではなかなか動かすのが難しい改修も、社全体での位置づけを説明して短期のプロジェクトチームを作ればできるかもしれない。 これらはただの例であって、それくらい考えるのは当たり前だろと思う人もいるかもしれないし、ただの社内のプロセスの問題ではと感
ミーティング中にうまく意見を言えないという相談を受けた。めちゃくちゃわかる。自分は開発関連のミーティングではそういう悩みは少なくなったけれど、経営関連のミーティングでは今でも歯がゆく悔しい思いをすることが多い。 相談された時にはうまく答えられなかったので、雑に自分がやっていることを書き出してみる。必要な役割としてミーティングに入っているというのを前提として、そもそものミーティングの必要性や参加者の要否についてはここでは対象外とする。 1. 事前に予習する 意見を言えないのは、その場で理解できなかったり考えがまとまらなかったりするから 事前にアジェンダが用意されていたら読み、関連ドキュメントがあればそれも目を通しておくなどできるかぎり事前準備をしておく わからないところや聞いておきたいことがあればコメントしたり頭出ししたりしておくとよい 2. 話を振ってもらう 意見を言えないのは、発言するタ
次のページ
このページを最初にブックマークしてみませんか？
『Konifar's ZATSU』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
