考え方が合わないのか情報が揃っていないのか - Konifar's ZATSU
「考え方が合わないなー」と感じた時は、相手と自分の持っている情報が揃っているかを疑ったほうがいいよね、という話を雑に書く。 たとえば「上司の理解がない」「部下の危機感が足りない」「同僚が慎重すぎる」みたいなやつ。なんでそんな考え方をするのかわからなくて憤りを感じるようなことがある。本当に考え方が合わないこともあるが、実は持っている情報量の違いによって思考結果が異なるだけで、思考回路自体に違いはなかったということも多い。 例を出してみる。プロダクトの1年後を考えてこれを絶対にやったほうがいいというボトムアップの提案が受け入れられなかったとする。 この時、実は相手は裏側で短期の売上目標を達成するために必死なのかもしれないし、ステークホルダーとのハードな交渉をしているのかもしれない。あるいは、プライベートで大変なことがあって考える余裕がないのかもしれない。逆の立場で見ると、実は提案する側はメンバ
レビュワーを"憑依"させて Pull Request をセルフレビューする - Konifar's ZATSU
メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明
社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D
個人コミュニケーションKPI - Konifar's ZATSU
嫁氏はナチュラルコミュニケーションお化けである。 昼飯の時に社交性上げていかなきゃねみたいな話をしていた嫁氏がお昼の散歩中にママ友ができたらしくマジかってなった— こにふぁー (@konifar) 2021年1月13日 嫁氏就活の職場体験的なやつで「いると場が明るくなる」「グループにいてほしい」と複数人からフィードバックをもらってるらしく完全に俺にない才能を持ってる— こにふぁー (@konifar) 2023年7月19日 自分から見れば初対面の相手や複数人の集団とあんなスピードで打ち解け関係を作れるのは才能だとしか思えない。相手について気になったことを深堀って話していくとよいというアドバイスを受けたが、"できる人"のアドバイスで自分にはあまり参考にならなかった。 色々話した結果、才能がなければコミュニケーションを分解して単純なKPIにしてそれを達成しに行くというのがよいという結論にたどり
マネジメント半年くらいの自分へ - Konifar's ZATSU
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
タスクの目的と担当と期日を決めろ - Konifar's ZATSU
世の中当たり前のことが一番難しい。 どんな粒度のタスクであっても必ずやらないといけないことがある。 タスクの目的を明確にして、責任を持つ担当者とケツの期日を決める これだけだ。「いやいや他にもあるでしょ」と言われるかもしれない。うん、あるよ。実際にタスクを終わらせるにはいっぱいやることあるよ。完了の条件を決めたりやることを明確にしたりアサインを決めたりチェックポイントとなる日付を設定したり色々あるよね。けどそれらは全部担当と期日を決めてからの話だよね。 目的を明確にして担当と期日さえ決めさえすればだいたいのことはうまく進むはずなのに、それすら決めてないせいで全然進まないみたいなことあるよね。タスクを前に進めたければ、とにかく目的と担当と期日を決めろ。話はそれからだ。アデュー
うまくフィードバックをもらうためのTips - Konifar's ZATSU
春だ。初めてソフトウェアエンジニアとして働き始めた頃、いつも機能のレビューで突っ込まれまくって涙目になっていたのを思い出した。今ならそんなことにはならないので、意識していることを雑にまとめておこうと思う。 今の状況を最初に伝える ざっと考えた仕様や、とりあえず作ってみたプロトタイプを見てもらおうとしただけなのに、めちゃくちゃ細かい部分まで突っ込まれて「あー今そういう感じじゃないのになぁぐぬぬぬ」となったことはないだろうか。これを防ぐには、最初に今の状況を伝えて認識を合わせておくとよい。 「先に今の状況を伝えておくと、まだ完成度は20%くらいです」 「まだ叩き台なのでアラも多いと思うんですがとりあえずざっと作って持ってきました」 みたいな一言があるだけでもだいぶ違う。大事なのは、これを最初の説明で自分から言うことだ。意見をもらい出すと相手も白熱してきてなかなか言うタイミングが難しくなることが
説明責任と信頼 - Konifar's ZATSU
仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。 ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。 それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。 一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状
めんどくさい作業を改善できるようになるには - Konifar's ZATSU
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
真意を確認している要注意ワード - Konifar's ZATSU
言った人と聞いた人の認識がずれやすい言葉というのがあると思っていて、その話を雑に書いておきたい。 自分はこれらを"要注意ワード"と呼んでいて、出てきたら真意を確認するようにしている。無意識的にやっている人は結構いると思うので、同じような"要注意ワード"の知見吸いたい。 リスク 「リスクがある」と言われたときは、何のリスクのことを言っているかを確認している。 たとえば何かの開発を1週間後にリリースしたい、と言った時に「いやーこれは結構怖いしリスクありますよね」みたいな話になったとする。ここでいうリスクは何を言っているのだろうか。なんとなく品質が担保しきれないリスクのことを言っているような気がするが、実は間に合わないかもしれないことをリスクと言っているのかもしれない。あるいは、チームメンバーのモチベーションが下がることをリスクと言っている可能性もある。 何のリスクのことを言っているのかすり合わ
"提案"のレベルを上げる - Konifar's ZATSU
組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」
社内の知らないことを探すパターン - Konifar's ZATSU
社で何かキャッチアップするのがめちゃくちゃ上手い人がいる。 情報がまとまっているか、参照しやすいかといった社の状況にもよるのだけれど、上手い人には一定のパターンがある気がしていて、そのへんを雑にまとめておきたい。 検索対象の選択肢を持ち、最速を意識している Slackのやりとりを検索する、GitHubのIssueやPRを探す、Google Driveを検索するといった感じでまずシュッと探してみる癖が染み付いている どこに情報がまとまっているかを見極め、選択肢のうちどこからあたるかのが最速かを素早く判断している 検索条件を駆使している ワードでの検索だけではなく、日時の範囲指定、投稿者・メンション先といったフィルタリング、除外設定などを駆使している インデックスとなる人や聞く場所を作っている 人に聞いた方が早いことも多いので、どこで誰に聞けば辿れるかインデックスを作っている。人や場所がない場
指摘を批判と捉えない - Konifar's ZATSU
誰かからの指摘を批判と捉えて過度に落ち込んだり反射的に言い返したりしまったりすることがある。 「指摘を批判と捉えない」というのは、"素直さ"を要素分解したうちの1つと言えると思う。 もちろん伝える側の表現に問題があることもあるけれど、攻撃されてるわけでもないのに勝手に自己防衛モードに入ってファイティングポーズ取ってしまう人は意外といる。 なぜ指摘を批判と捉えてしまうのかをあえて自分だけの問題として考えてみると、「能力が低い」「機嫌が悪い」の2つの結果ではないかと思う。 元も子もない話だが、能力が低いという話に帰着するというのが自分の結論である。 ここでいう能力というのは、一言でいうと想定力である。結局、自分が想定してなかったことを言われて処理しきれない時に発生する現象なのだ。全部先に想定されてる話なら、指摘されても批判とは捉えない気はする。 宿題をやってない子どもがおかんに宿題やらなくて大
意思決定できる人の手順の型 - Konifar's ZATSU
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
演じるうちにできるようになる - Konifar's ZATSU
ある日SNSをみると知り合いが嘆いていた。子どもがYouTuberの話し方や仕草を真似し出して、あの不自然なハイテンションというか独特の雰囲気がひどく嫌らしい。 ちょっとわかる。一方で、そこまで影響を与えられるのすごいなと思ってしまった。何度も見ているうちに無意識に似てくるのだろう。逆に、この人の所作を真似してほしいという動画を見せていたら人は意外と簡単に行動や性格が変わってくるのかもしれない。 思えば、自分のまわりのできる人は色々なところからエッセンスを抽出して真似るのが上手い気がする。それは本だったり先輩だったりSNS上ですごいと感じる人だったり、様々である。例えば同じエディタやキーボードを使ってみたり、会議のファシリテーション中の言い回しを真似してみたり、いいと思うところを組み合わせて自分のものにしているなと感じる。 自分のロールモデルを見つけるとよいとか、自分が一番下手くそでいよう
目標設定とは何か - Konifar's ZATSU
目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件
マネージャーに"キャパオーバー"はない - Konifar's ZATSU
Sansanの@m_nishibaさんを雑談に誘ってお話ししている中で、自分がふと「ちょっとキャパオーバー気味なんですよねぇ」と口にしたところ、それはちょっと"臭う"兆候だよねという話になったので雑にまとめておきたい。 3行でまとめるとこんな感じ。 (一般論として) マネージャーはやることを自分で決められる裁量がある キャパオーバーではなく、"優先順位を下げてやらない"判断であるべき キャパオーバーという言葉が出てきたら一度立ち止まって優先順位の見直しをするとよい たしかに~~~~。ポロッとキャパの話してしまうことがあるんだけど、本来は何をやるか/やらないか (≒キャパ) を決めるのもマネージャーの役割なので、キャパオーバーはおかしい。キャパオーバーという言葉が出てきたら、それは優先順位づけがうまくできていないサインと思う方がよい。 とはいえマネージャーはやること多すぎて自分でキャパ決める
仕事のインパクトを大きくしようとすると人を巻き込む必要がある - Konifar's ZATSU
マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。 ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは？」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。 つまるところ、いわゆるマネージャーとプレイヤーの違いは、
ドキュメントが更新されない問題 - Konifar's ZATSU
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
相談されなくなる理由 - Konifar's ZATSU
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
