ブックマーク / konifar-zatsu.hatenadiary.jp (33)

  • 相手に話が通じないと感じた時の対処法 - Konifar's ZATSU

    相手に話が通じず物事を前に進めにくいと感じることがある。特に、階層化された組織の違うレイヤーの相手や他部署の相手の場合にありがちかもしれない。 そういう時はついついヒートアップしてしまい相手のせいにしてハレーションを生むような話し方をしてしまいがち。"相手が理解してくれないのは相手の頭が悪くて理解できないから"みたいな態度は相手に伝わり、関係がこじれてより一層物事を前に進めにくくなってしまう。 こういう時に感情的になってうまく対処できないのは解決のための引き出しが少ないのが原因なので、思いつく対処法を雑に書きとめておく。 いったん自責思考に切り替える あまりに話が通じないと感じると自分の方が賢くて相手が悪いみたいなスタンスになりがちなのでまずはリセットする 相手に勝とうとするのではなく、目的を思い出して相手も自分も勝つにはどうすればよいかを考えるよう切り替える ほぼ相手に非があることももち

    相手に話が通じないと感じた時の対処法 - Konifar's ZATSU
  • 暇そうに見えるマネージャーとはどういう状態か - Konifar's ZATSU

    マネージャーは暇そうに見えるくらいの方がいいという話をちょいちょい聞く。実際に暇ということではなく、"暇そうに見える"というのが重要っぽい。 なんとなく言いたいことはわからなくはないけれどあまり腹落ちできていないので、"暇そうな状態を目指す"とはどういうことなのかを雑に書いてみる。 メンバーから相談されやすい状態を作る マネジメントは正確な観察から。メンバーからの情報が集まりやすい状態を作る オフラインならふらっと雑談してみたりとか カレンダーが予定でいっぱいで遠慮させてしまって「ちょっといいですか」と声がけされにくくなるみたいなことにならないようにする ルーチンワークを見直し効率化する 一定やらなければいけないことは多くなるのは仕方ないが、使える時間を増やすために徹底的な効率化を行う 効率化したほうがいいと思いながら半年経つとかはよくない まとまった考える時間を取る インパクトのある問題

    暇そうに見えるマネージャーとはどういう状態か - Konifar's ZATSU
  • 常に即答できるようにすべき質問は何か - Konifar's ZATSU

    先日社外の人に「いま一番何に悩んでますか?」と聞かれて即答できなかった。 もちろん常に色々な課題があって頭を使っているつもりだけれども、スコープを絞らず "一番" "悩んでいる" ことは何かと急に聞かれるとちょっと考えてしまった。普段から観察が足りないし優先順位も整理できてないんだなということが浮き彫りになって興味深かった。 これに限らず、"聞かれたら常に答えられるべき質問" を持っておくとよいのかもしれない。たぶん意識せずやっている人はいる気がするが、意識的に持っておくと自身の振る舞いのヘルスチェックに使える。 たとえばマネージャーだったら「いまチームで自分が一番解決すべき課題は何か」「自分が時間を使うトップ3は何か」とか。他のメンバーに聞かれて即答できないのなら、無計画でタスクに忙殺されているのかもしれない。そういったきな臭い兆候に気づくための質問を用意しておくイメージ。 プレイヤーな

    常に即答できるようにすべき質問は何か - Konifar's ZATSU
  • 抽象度の高い仕事の進め方 - Konifar's ZATSU

    仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」

    抽象度の高い仕事の進め方 - Konifar's ZATSU
  • 社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU

    自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D

    社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
  • 言いたいことを言える場の設計 - Konifar's ZATSU

    言いたいことを言える場を強制的に作っておくことってめちゃくちゃ大事だと感じているのでその話をガッと書く。同じような話はいろんな書籍やブログで書かれているので、体系的なことを知りたい人はそっち読んだ方がいい。 いい感じのチームでは、言いたいことを言える状態をうまく作っているなあと感じることが多い。 例えばプロジェクト中に1週間2週間ごとに振り返りの場を設定していたり、毎日の朝会の中で相談コーナーを設けていたり、ウチでもやってるよというところは多いと思う。1on1もその機能の一端を担っている。一方で、場を設定したからといって言いたいことを言えるかというとそうでもない。場の設計が必要なのである。 例えば、「そもそもこのプロジェクトってやる意味あるのかよくわかってないんですよね」みたいな話をプロジェクトごとの振り返りでポンと言えるかと言うと、なかなか言いにくい。 こういう今さら感のある話や言いにく

    言いたいことを言える場の設計 - Konifar's ZATSU
  • マネジメント半年くらいの自分へ - Konifar's ZATSU

    あの頃の俺に伝えたい内容を雑に書く。 を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて

    マネジメント半年くらいの自分へ - Konifar's ZATSU
  • めんどくさい作業を改善できるようになるには - Konifar's ZATSU

    めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか?」「なぜこれをやってるんだっけ?」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状

    めんどくさい作業を改善できるようになるには - Konifar's ZATSU
  • 斜に構えるタイプの人は変われるのか - Konifar's ZATSU

    ちょっと辛辣な話になってしまうかもしれないが、斜に構えた態度をとる人が"変わった"事例を見たことがない。どうしていくのがいいのか答えがないので雑に書いておきたい。先に書いておくと答えはここには書いていない! そもそも"斜に構える"というのはこういう意味らしい。 「斜に構える」は、もともと「剣術で相手(敵)に対して刀を下げて斜めに身構えること」から「改まった態度をとる」「おつに気取る・身構える」「物事に正面から対処しないで、皮肉な態度で臨む」ことをいいます。 「斜め[ナナメ]に構えている」は、「斜[シャ]に構える」では? | ことば(放送用語) - 放送現場の疑問・視聴者の疑問 | NHK放送文化研究所 程度によって変わる話ではあるが、「物事に正面から対処しないで、皮肉な態度で臨む」が自分の定義と近い。 過去に自分がだいぶ斜に構えているなーと感じたタイプの人には一定の特徴があった。 そつなく

    斜に構えるタイプの人は変われるのか - Konifar's ZATSU
  • 真意を確認している要注意ワード - Konifar's ZATSU

    言った人と聞いた人の認識がずれやすい言葉というのがあると思っていて、その話を雑に書いておきたい。 自分はこれらを"要注意ワード"と呼んでいて、出てきたら真意を確認するようにしている。無意識的にやっている人は結構いると思うので、同じような"要注意ワード"の知見吸いたい。 リスク 「リスクがある」と言われたときは、何のリスクのことを言っているかを確認している。 たとえば何かの開発を1週間後にリリースしたい、と言った時に「いやーこれは結構怖いしリスクありますよね」みたいな話になったとする。ここでいうリスクは何を言っているのだろうか。なんとなく品質が担保しきれないリスクのことを言っているような気がするが、実は間に合わないかもしれないことをリスクと言っているのかもしれない。あるいは、チームメンバーのモチベーションが下がることをリスクと言っている可能性もある。 何のリスクのことを言っているのかすり合わ

    真意を確認している要注意ワード - Konifar's ZATSU
  • 権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU

    権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい

    権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU
  • "提案"のレベルを上げる - Konifar's ZATSU

    組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

    "提案"のレベルを上げる - Konifar's ZATSU
  • 見ているタイムスパンを揃える - Konifar's ZATSU

    仕事で「なんだかうまく話が通じない」「考え方が違う」と感じる時は、それぞれが見ているタイムスパンが違っていることが多い。どのくらいの期間で物事を考えているかをすり合わせてみると一気に話しやすくなったりするのでそのへんの話を雑に書いておく。 たとえば、1ヶ月後のKPIを意識して施策優先順位を考えている人と、3ヶ月後を考えている人とが話すと思いのほか議論が進まないことがある。文章で単純化するとちゃんと話して認識合わせればいいじゃんと思うかもしれないが、当事者になると意外と白熱してそもそも見ているタイムスパンがずれていることに気づかなかったりする。 1年後のことを考えて"今"からリアーキテクチャを進めたいという提案と、"今"は3ヶ月後の事業成果にしたいという意見などもタイムスパンの認識を合わせて見る景色を揃えるところから始めると話しやすくなる。両方とも"今"何をするかの話をしているが、いつ成果が

    見ているタイムスパンを揃える - Konifar's ZATSU
  • 指摘を批判と捉えない - Konifar's ZATSU

    誰かからの指摘を批判と捉えて過度に落ち込んだり反射的に言い返したりしまったりすることがある。 「指摘を批判と捉えない」というのは、"素直さ"を要素分解したうちの1つと言えると思う。 もちろん伝える側の表現に問題があることもあるけれど、攻撃されてるわけでもないのに勝手に自己防衛モードに入ってファイティングポーズ取ってしまう人は意外といる。 なぜ指摘を批判と捉えてしまうのかをあえて自分だけの問題として考えてみると、「能力が低い」「機嫌が悪い」の2つの結果ではないかと思う。 元も子もない話だが、能力が低いという話に帰着するというのが自分の結論である。 ここでいう能力というのは、一言でいうと想定力である。結局、自分が想定してなかったことを言われて処理しきれない時に発生する現象なのだ。全部先に想定されてる話なら、指摘されても批判とは捉えない気はする。 宿題をやってない子どもがおかんに宿題やらなくて大

    指摘を批判と捉えない - Konifar's ZATSU
  • 意思決定できる人の手順の型 - Konifar's ZATSU

    意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

    意思決定できる人の手順の型 - Konifar's ZATSU
  • 目標設定とは何か - Konifar's ZATSU

    目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかチョット調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件

    目標設定とは何か - Konifar's ZATSU
  • HUNTER×HUNTER×OKR - Konifar's ZATSU

    最近zatsuを書いてなかったので、「理想のOKRとは何か」をハンターハンターを例にして書く。必要な前提知識は8巻にある。 高いObjectiveの設定とは何か クロロ「全部だ」「地下競売のお宝 丸ごとかっさらう」 8巻 P152~153 これが高いObjectiveの設定である。 戦略発表前にはメンバーは「どこ狙うと思う?あたしは古書全般だと思う。団長好きだし」「違うね。きとゲームね」などと色々な予想をしていたが、それをはるかに超えた目標を掲げている。そう 「全部盗む」である。 OKR シリコンバレー式で大胆な目標を達成する方法では、『Objectiveは達成確率が60〜70%程度になるくらいの高い目標を設定せよ』とあるが、このクロロのセリフはまさにそれだと言っていい。 合意のプロセスとは何か OKRの運用において一番大事なのは、所属するメンバーとそのObjectiveについて話して納

    HUNTER×HUNTER×OKR - Konifar's ZATSU
  • 方針が浸透していない時のチェックリスト - Konifar's ZATSU

    チームの方針を伝えたはずなのにうまく伝わっていないということはよくある。そういう時、「前にも言いましたけど」みたいな話をしだすと不幸にしかならない。情報のやりとりは伝える側と伝えられる側双方の協力が不可欠だが、コントロールしやすいのは伝える側である。方針が浸透していない時に確認したいチェックリストを雑にまとめておく。 理解してくれているか 同じ言葉でも認識が違うことは多い 特に方針はキャッチーな表現を使って抽象度が高いこともある 具体も伝えて理解しているかどうかを確認すること 納得してくれているか 意義を感じていないと浸透しない 説明する側が納得していることはもちろん、納得させられるまで話すこと 方針の背景や議論の流れ、最終決定事項までアクセスしやすくして個々人が自律してキャッチアップできるようにしておくことも重要。いわゆる情報の透明性、フラットさ どちらかに決めて進む必要があることも多い

    方針が浸透していない時のチェックリスト - Konifar's ZATSU
  • ドキュメントが更新されない問題 - Konifar's ZATSU

    むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま

    ドキュメントが更新されない問題 - Konifar's ZATSU
  • 共通認識を揃えて前置きの謝罪を減らす - Konifar's ZATSU

    不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack

    共通認識を揃えて前置きの謝罪を減らす - Konifar's ZATSU