マネジメント半年くらいの自分へ - Konifar's ZATSU
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
考え方が合わないのか情報が揃っていないのか - Konifar's ZATSU
「考え方が合わないなー」と感じた時は、相手と自分の持っている情報が揃っているかを疑ったほうがいいよね、という話を雑に書く。 たとえば「上司の理解がない」「部下の危機感が足りない」「同僚が慎重すぎる」みたいなやつ。なんでそんな考え方をするのかわからなくて憤りを感じるようなことがある。本当に考え方が合わないこともあるが、実は持っている情報量の違いによって思考結果が異なるだけで、思考回路自体に違いはなかったということも多い。 例を出してみる。プロダクトの1年後を考えてこれを絶対にやったほうがいいというボトムアップの提案が受け入れられなかったとする。 この時、実は相手は裏側で短期の売上目標を達成するために必死なのかもしれないし、ステークホルダーとのハードな交渉をしているのかもしれない。あるいは、プライベートで大変なことがあって考える余裕がないのかもしれない。逆の立場で見ると、実は提案する側はメンバ
メンバーからのフィードバックに向き合う - Konifar's ZATSU
7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ
率直な意見をぶつけてくれる人に敬意を払う - Konifar's ZATSU
率直に思ったことを言ってくれる人は貴重である。貴重であるが故に、敬意をもって接しなければならない。 特に反対意見や耳の痛い感想はなかなか言えない人も多い。 たとえば何かをやるかどうかの相談をした時に、「そもそもやる意味あるんですか？」とか「全く賛成できないですね」とか「自分は絶対やりたくないです」とか。言い方は改善の余地があるかもしれないが、こういう意見をぶつけてくれる人は大事にした方がいい。 大事にするというのはどういうことかというと、意見を言ってくれたことに対してお礼を言う、誠実に向き合って返答する、伝え方に関してフィードバックをするといった具体的なアクションを起こすことである。当たり前と言えば当たり前なんだけど、実行できる人は意外と多くはない。 特にお礼を言うというのは意外とやれていなかったりする。性格にもよるとは思うが、率直に意見を言うのにはエネルギーがいる。相手に伝わるように強め
主語を個人にする - Konifar's ZATSU
組織において、主語を"集団"にしだすとよくないと思っていて、その話を雑に書いておきたい。 たとえば納得しにくい決定事項があった時に、「これってどういう経緯で決まった話ですか？」と聞いてみると、「法務側の要請で...」みたいな話になったりすることがある。 似たような話として、「営業チームの意見として」とか「経営陣からの意向で」とかも同じ。こういう"集団"が何かを言っているみたいな表現が出てきたら注意した方がいい。"チーム"も"経営陣"も"会社"も、それ自体が意見を言ったりしない。意見を言うのはいつでも個人なのだ。それを明確にしないと、バイアスにかかってしまったり遠回りしてしまったりして、物事をよい方向に進めにくくなる。 主語が"集団"になると、とたんに個々人ではコントロールしにくいものだと勘違いしてしまう。そういうちょっとしたストレスが積み重なって、「あのチームは〜」とかなんだか他人事のよう
『問いかけの作法』がとてもよかった - Konifar's ZATSU
fukabori.fm で話されていた『問いかけの作法』を読んだ。自分にとってはかなりよかったので、初めての感想文的なものを雑に書いておきたい。 https://amzn.to/40PBaXg とにかくよかった。これまで自分もたくさんの会議や1on1、面談などを行い都度反省して工夫してきたが、それらの工夫がほぼ全て"体系化"されてまとめられていた。自分がやってきた/やっていることが6割くらい、残り4割は新しい発見として楽しく読めた。ハンターハンターで言うと、念の六性図くらい見事に体系化されていると感じた。 たとえば質問を投げかけた後に意見が出なそうだったらいくつか具体例を出してあげるフォローアップなども、『列挙法』という名づけをして解説してくれている。カイゼン・ジャーニーの中で紹介されている、意見を5段階で示すファイブフィンガーも、この本の中の『パラフレイズ』という手法と捉えられる。 やっ
議論を収束させるTips - Konifar's ZATSU
何かを決めるゴールを設定した会議において難しいのは、議論を収束させていくフェーズである。 議論の抽象度の高さによって難易度は変わるが、収束させるにあたってここは抑えておくとよいみたいなTipsはあると思うので書き出してみる。 決めることがゴールという認識を合わせる そもそも決める場だという認識が揃っていないと収束させるのが難しい。会議のフォーマットに目的やゴールを明記しておくとよい 最終的な決め方を決める 最終決定者、時間、多数決などなんでもいいが、最後にどう決めるかを決めるのが大事。できれば議論が始まる前にやっておくと、議論中もそれを意識して進められるのでやりやすい 決めるための材料の認識を合わせる 判断軸とも言える。議論が何かうまくいかない時にはだいたいこのへんの認識が揃っていない。言葉に対する認識が揃っていないこともあるので齟齬をなくしておくの大事 決めるための材料を今揃えられるかを
方針が浸透していない時のチェックリスト - Konifar's ZATSU
チームの方針を伝えたはずなのにうまく伝わっていないということはよくある。そういう時、「前にも言いましたけど」みたいな話をしだすと不幸にしかならない。情報のやりとりは伝える側と伝えられる側双方の協力が不可欠だが、コントロールしやすいのは伝える側である。方針が浸透していない時に確認したいチェックリストを雑にまとめておく。 理解してくれているか 同じ言葉でも認識が違うことは多い 特に方針はキャッチーな表現を使って抽象度が高いこともある 具体も伝えて理解しているかどうかを確認すること 納得してくれているか 意義を感じていないと浸透しない 説明する側が納得していることはもちろん、納得させられるまで話すこと 方針の背景や議論の流れ、最終決定事項までアクセスしやすくして個々人が自律してキャッチアップできるようにしておくことも重要。いわゆる情報の透明性、フラットさ どちらかに決めて進む必要があることも多い
直接話す、すぐ話す - Konifar's ZATSU
最近嫁氏とバチェラー4を見ていて思ったことを雑に書いておきたい。 第4話にて、ある女性が「バチェラーがこう言ってた」みたいな少し事実と異なる内容を他の女性陣に話したことで、バチェラーへの不信感が広がりだいぶ面倒なことになるという"事件"があった。 それに対しバチェラーがすぐに1人ずつ対話の時間を作り説明していたのを見て、結局これしかないよなあと思った。 種類や程度は違えど、組織においてこういうことはよく起こる。その時に重要なのは、関係する当人とすぐに直接話すことである。 例えば事業の優先順位に納得できないときに、説明を受けた者同士でああだこうだと話したりするよりも説明をした人に直接聞いた方がよい。 あるいは誰かの発言に棘を感じてモヤモヤした時は、本人に直接話して解消したほうがよい。 小さいところだと、Slackで「これ大丈夫かな」「どうなってるんだろ」みたいな懸念を書くときには関係しそうな
コミュニケーションのシナリオ - Konifar's ZATSU
何かの共有や相談をする時に、文章の表現や伝えるタイミング、伝え方や伝える順番などがとても"上手い"と感じる人がたまにいる。 逆に下手な人もいて、そういう人を見ると"もったいない"という気持ちになる。そういう人は伝え方で損をしてしまっているだけで、内容についてはかなりよく考えて準備もしていることが多いからである。上手い人と下手な人の違いはわりと暗黙知になりがちなので、何が違うかを考えながら雑に書きなぐっておきたい。 文章のテクニックや声の抑揚、表情といった細かい要素はあるのだけれど、一番の違いはコミュニケーションをとる時のシナリオをどれだけ想定できているかだと思う。イメージとしては将棋やチェスで相手の手を読むのに近い。 「この話はSlackで伝えたら微妙なニュアンスが伝わらなそうだから直接話そう」とか「チームの定例で話すよりも1対1で直接説明した方がいいかもな」とか、それくらいのレベルのシナ
HUNTER×HUNTER×PdM - Konifar's ZATSU
先日参加した pmconf 2021 の Discord に、クロージングのあと約20分ほどハンターハンターのチャンネルが作成され、そこで少し雑談をした。 ハンターハンターの台詞はプロダクト開発の中でも活かせるものが多いよねという、雑談チャンネルにふさわしい内容であった。正直自分でも後で何の話だっけ？となりそうなので、話した内容 + α をざっと書いておく。 ドキドキ2択クイ~~~~~~~~ズ!! プロダクト開発の中で、トレードオフを考慮しなければいけない場面は多い。「ではドキドキ2択クイズしますか」のように使うと議論が整理できてよい。ただし、この場合の答えは「沈黙」ではない。また、トレードオフだと思い込んでいるだけで実は「ナカヌキ」的な一手が存在しうることもあるので注意が必要。 今オレ達にとって最悪のケースってのは何だ？ 議論の本質が見えなくなった時に整理できる。実は今話している前提から
ドキュメントが更新されない問題 - Konifar's ZATSU
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
共通認識を揃えて前置きの謝罪を減らす - Konifar's ZATSU
不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack
Simple Bankを#10までやった感想 - Konifar's ZATSU
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
成果が出ていても変化がないと飽きる - Konifar's ZATSU
幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。 発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか？」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。 成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。 一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題
ブログ記事を書けない時のTips - Konifar's ZATSU
何か文章を書こうとした時によく起きる2つの問題がある。「何を書けばいいのかわからない」と「どう書けばいいのかわからない」である。 自分は後者に陥ることがよくあって、結果めんどくさくなってお蔵入りしている話がたくさんある。「全く文章がまとまらない」とか「書いて意味があるのかわからなくなってきた」とか「冒頭の文章を推敲し続けてしまって進まない」とか、そういった状態である。 そういう時はたいてい色々書こうとしすぎなので、まずは内容を削ることを考えたほうがよい。あれもこれも入れて最高の文章に仕上げたくなるのもわかるが、読み手からすると長すぎる。感覚的には、筆ののらない記事は文量を3分の1くらいに削ってちょうどよいくらいな気がする。 削る方法は色々あるが、自分がよくやるやり方としては「構成を変える」と「内容を絞る」の2つがある。 例えば転職して1年経った話を書く場合、全部書こうとすると長くなりすぎて
何かいいことを言ってやろうとしていないか - Konifar's ZATSU
たまに「あー今自分をよく見せることを考えて発言しちゃってるな」と自覚して恥ずかしくなることがある。 例えばミーティング中、何かを前に進めることよりも皆にオッと思われるような内容を言うことに頭を使っているみたいな。そういう時はたいてい後で恥ずかしくなってｳﾜｱｧｧｱｧ!!!となる。 状況によっては、信用を得るためにそういう振る舞いが必要になることもある。「コイツできる...」と思わせることで物事をうまく進められることも多い。自分をよく見せるために何かをすること自体が悪いわけではない。問題なのは、その振る舞いが癖になって自覚できなくなっているケースである。 「何かいいことを言ってやろう」という気持ちが先行しすぎた状況と言えるかもしれない。誰かの意見に対して「自分はもっとこう考えてる」みたいな話をとにかく出そうとしたり。インターネッツ上だとさらに厄介である。 例えば、採用候補者が期待とそぐわない
抽象的な期待を自分ですり合わせるスキル - Konifar's ZATSU
グレード評価制度において、上のグレードに行けば行くほど期待が抽象的になるよねという話を会社の同僚氏と話していた。 ICでもマネジメントでも影響を及ぼす範囲も広がり、できることも増える中で求められることも自然と多くなってくる。 そんな抽象的な期待を明確にする部分も求められているよねと同僚氏が言っていて、それはたしかにと思った。要するに、自分がどこで成果を出すべきかを自分で定義できるスキルが必要になってくるということである。 ジュニアとシニアみたいな分け方があるが、これはシニアに求められるスキルの一つかもしれない。何をやったらいいのかわからない中でもまわりを見渡して、必要なアクション (must)と自分のやりたいこと (will)とできること (can)をすり合わせて方向を決めるみたいな話である。 それはマネージャーの仕事だろと言われればその通りなんだけど、グレードが上がるとそういう抽象的な期
「何か質問や意見ありますか」の後の無言対策 - Konifar's ZATSU
オンラインのミーティングで「何か質問や意見ありますか」と聞いた後の無言がつらいんだよねという話を聞いた。わかる。自分はもはや慣れきってしまったけれど、今でもいい方法ないかなあと考えている。 いくつかやったことを書いてみる。組織によってもだいぶ違うと思うけれど、他の人の知見をめちゃくちゃ聞きたい。 最初に声を出してもらう 少しでも最初に声を出しておくと意見を言いやすいという研究があるらしい。なんとなく実感としても正しい気がしている。 ただ全員に雑談を振るというのもちょっとなあという時に自分がやっているのが「出席をとります」である。皆なつかしい気持ちになってほんわかするし、返事をするだけでもよいので楽。時間もかからない。 参加者の役割を最初に話す どういう役割や発言を期待しているかを明確にしてあげるとそのスタンスで意見を言いやすくなる。たとえば「○○さんにはモバイルの開発工数観点でかなり現実的
CIと食洗機 - Konifar's ZATSU
ソフトウェア開発の経験がない嫁氏と、たまに開発の話をする。いつだったか、たしか個人開発している時だったと思うが、CIとCDを先に整えておくのはとても重要という話をした。 仕事が終わってからもMacbookをいじっている自分に「今何してるの？」と聞かれたのがきっかけだった気がする。「開発に入る前の下準備だよ」「下準備って？」「やっておいた方がそのあとの効率がよくなることってのがいくつかあって、それをやってる」「たとえば？」「CI/CDの設定とか」みたいな感じ。そこからCIの説明に入った。ざっくりまとめると以下のような会話だ。 CIというのは、食洗機のようなものだ。我々も食洗機を使い出す前は「食洗機なくてもいいよね」という話をしていたと思う。しかし今はどうだ？食洗機がない生活は考えられない。食洗機をもっと早く買っておくべきだったという共通認識がある。 使い出す前はどうだったか。「何でも洗えるわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
