サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Nintendo Direct
konifar-zatsu.hatenadiary.jp
今日も今日とてインターネッツは騒がしい。 このツイットが内容、引用ツイ含めて興味深かった。 「初めまして。〇〇です。………一度打ち合わせをして頂けないでしょうか?」 「良いですよ。」 「ここから選んで下さい。」 TimeRex これいつも「は?」と思うの僕だけですか?— KEITO💻AIディレクター (@keitowebai) 2024年5月31日 「初めまして。〇〇です。………一度打ち合わせをして頂けないでしょうか?」 「良いですよ。」 「ここから選んで下さい。」 TimeRex これいつも「は?」と思うの僕だけですか? 正直自分は本文のやりとりをされたとしても何も問題には感じなかった。むしろ、日程調整の手間がかからずありがたいとポジティブに感じるくらいである。つまり、自分もこの「は?」と思われるやりとりをする可能性が大いにあるということである。自分の視野を広げるために、少しキャッチア
メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明
嫁氏はナチュラルコミュニケーションお化けである。 昼飯の時に社交性上げていかなきゃねみたいな話をしていた嫁氏がお昼の散歩中にママ友ができたらしくマジかってなった— こにふぁー (@konifar) 2021年1月13日 嫁氏就活の職場体験的なやつで「いると場が明るくなる」「グループにいてほしい」と複数人からフィードバックをもらってるらしく完全に俺にない才能を持ってる— こにふぁー (@konifar) 2023年7月19日 自分から見れば初対面の相手や複数人の集団とあんなスピードで打ち解け関係を作れるのは才能だとしか思えない。相手について気になったことを深堀って話していくとよいというアドバイスを受けたが、"できる人"のアドバイスで自分にはあまり参考にならなかった。 色々話した結果、才能がなければコミュニケーションを分解して単純なKPIにしてそれを達成しに行くというのがよいという結論にたどり
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
言った人と聞いた人の認識がずれやすい言葉というのがあると思っていて、その話を雑に書いておきたい。 自分はこれらを"要注意ワード"と呼んでいて、出てきたら真意を確認するようにしている。無意識的にやっている人は結構いると思うので、同じような"要注意ワード"の知見吸いたい。 リスク 「リスクがある」と言われたときは、何のリスクのことを言っているかを確認している。 たとえば何かの開発を1週間後にリリースしたい、と言った時に「いやーこれは結構怖いしリスクありますよね」みたいな話になったとする。ここでいうリスクは何を言っているのだろうか。なんとなく品質が担保しきれないリスクのことを言っているような気がするが、実は間に合わないかもしれないことをリスクと言っているのかもしれない。あるいは、チームメンバーのモチベーションが下がることをリスクと言っている可能性もある。 何のリスクのことを言っているのかすり合わ
組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」
誰かからの指摘を批判と捉えて過度に落ち込んだり反射的に言い返したりしまったりすることがある。 「指摘を批判と捉えない」というのは、"素直さ"を要素分解したうちの1つと言えると思う。 もちろん伝える側の表現に問題があることもあるけれど、攻撃されてるわけでもないのに勝手に自己防衛モードに入ってファイティングポーズ取ってしまう人は意外といる。 なぜ指摘を批判と捉えてしまうのかをあえて自分だけの問題として考えてみると、「能力が低い」「機嫌が悪い」の2つの結果ではないかと思う。 元も子もない話だが、能力が低いという話に帰着するというのが自分の結論である。 ここでいう能力というのは、一言でいうと想定力である。結局、自分が想定してなかったことを言われて処理しきれない時に発生する現象なのだ。全部先に想定されてる話なら、指摘されても批判とは捉えない気はする。 宿題をやってない子どもがおかんに宿題やらなくて大
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
最近zatsuを書いてなかったので、「理想のOKRとは何か」をハンターハンターを例にして書く。必要な前提知識は8巻にある。 高いObjectiveの設定とは何か クロロ「全部だ」「地下競売のお宝 丸ごとかっさらう」 8巻 P152~153 これが高いObjectiveの設定である。 戦略発表前にはメンバーは「どこ狙うと思う?あたしは古書全般だと思う。団長本好きだし」「違うね。きとゲームね」などと色々な予想をしていたが、それをはるかに超えた目標を掲げている。そう 「全部盗む」である。 OKR シリコンバレー式で大胆な目標を達成する方法では、『Objectiveは達成確率が60〜70%程度になるくらいの高い目標を設定せよ』とあるが、このクロロのセリフはまさにそれだと言っていい。 合意のプロセスとは何か OKRの運用において一番大事なのは、所属するメンバーとそのObjectiveについて話して納
権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい
UzabaseのPodcast Meet UB Techに、初のゲストとして参加してきた。光栄である。 open.spotify.com tech.uzabase.com 雑に言うと以下のような話をしている。がんばって話したので、気になったトピックがあれば聞いてみてほしい。自分の音質が悪すぎて申し訳ない!マイクも使っていたのになぜ... Kyashに入社してから今までの役割の変遷 VPoEになった背景 VPoEとCTOの役割分担 なぜVPoE READMEを書いたのか VPoE READMEを読んだ労務や人事のメンバーからも反応があった VPoE READMEに込めた温度感 VPoEを3ヶ月やってみた時点での反省 目標の立て方に関するマインドチェンジ 事業成長からの逆算 説明責任を最初に考えたらダメ、実行責任が先 信頼と心理的安全性 メンバーからの「ビビりすぎ」というフィードバック 採用活
7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ
組織において、主語を"集団"にしだすとよくないと思っていて、その話を雑に書いておきたい。 たとえば納得しにくい決定事項があった時に、「これってどういう経緯で決まった話ですか?」と聞いてみると、「法務側の要請で...」みたいな話になったりすることがある。 似たような話として、「営業チームの意見として」とか「経営陣からの意向で」とかも同じ。こういう"集団"が何かを言っているみたいな表現が出てきたら注意した方がいい。"チーム"も"経営陣"も"会社"も、それ自体が意見を言ったりしない。意見を言うのはいつでも個人なのだ。それを明確にしないと、バイアスにかかってしまったり遠回りしてしまったりして、物事をよい方向に進めにくくなる。 主語が"集団"になると、とたんに個々人ではコントロールしにくいものだと勘違いしてしまう。そういうちょっとしたストレスが積み重なって、「あのチームは〜」とかなんだか他人事のよう
fukabori.fm で話されていた『問いかけの作法』を読んだ。自分にとってはかなりよかったので、初めての感想文的なものを雑に書いておきたい。 https://amzn.to/40PBaXg とにかくよかった。これまで自分もたくさんの会議や1on1、面談などを行い都度反省して工夫してきたが、それらの工夫がほぼ全て"体系化"されてまとめられていた。自分がやってきた/やっていることが6割くらい、残り4割は新しい発見として楽しく読めた。ハンターハンターで言うと、念の六性図くらい見事に体系化されていると感じた。 たとえば質問を投げかけた後に意見が出なそうだったらいくつか具体例を出してあげるフォローアップなども、『列挙法』という名づけをして解説してくれている。カイゼン・ジャーニーの中で紹介されている、意見を5段階で示すファイブフィンガーも、この本の中の『パラフレイズ』という手法と捉えられる。 やっ
次のページ
このページを最初にブックマークしてみませんか?
『Konifar's ZATSU』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く