めんどくさい作業を改善できるようになるには - Konifar's ZATSU
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU
権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい
見ているタイムスパンを揃える - Konifar's ZATSU
仕事で「なんだかうまく話が通じない」「考え方が違う」と感じる時は、それぞれが見ているタイムスパンが違っていることが多い。どのくらいの期間で物事を考えているかをすり合わせてみると一気に話しやすくなったりするのでそのへんの話を雑に書いておく。 たとえば、1ヶ月後のKPIを意識して施策優先順位を考えている人と、3ヶ月後を考えている人とが話すと思いのほか議論が進まないことがある。文章で単純化するとちゃんと話して認識合わせればいいじゃんと思うかもしれないが、当事者になると意外と白熱してそもそも見ているタイムスパンがずれていることに気づかなかったりする。 1年後のことを考えて"今"からリアーキテクチャを進めたいという提案と、"今"は3ヶ月後の事業成果にしたいという意見などもタイムスパンの認識を合わせて見る景色を揃えるところから始めると話しやすくなる。両方とも"今"何をするかの話をしているが、いつ成果が
意思決定できる人の手順の型 - Konifar's ZATSU
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
目標設定とは何か - Konifar's ZATSU
目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件
マネージャーに"キャパオーバー"はない - Konifar's ZATSU
Sansanの@m_nishibaさんを雑談に誘ってお話ししている中で、自分がふと「ちょっとキャパオーバー気味なんですよねぇ」と口にしたところ、それはちょっと"臭う"兆候だよねという話になったので雑にまとめておきたい。 3行でまとめるとこんな感じ。 (一般論として) マネージャーはやることを自分で決められる裁量がある キャパオーバーではなく、"優先順位を下げてやらない"判断であるべき キャパオーバーという言葉が出てきたら一度立ち止まって優先順位の見直しをするとよい たしかに~~~~。ポロッとキャパの話してしまうことがあるんだけど、本来は何をやるか/やらないか (≒キャパ) を決めるのもマネージャーの役割なので、キャパオーバーはおかしい。キャパオーバーという言葉が出てきたら、それは優先順位づけがうまくできていないサインと思う方がよい。 とはいえマネージャーはやること多すぎて自分でキャパ決める
メンバーからのフィードバックに向き合う - Konifar's ZATSU
7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ
方針が浸透していない時のチェックリスト - Konifar's ZATSU
チームの方針を伝えたはずなのにうまく伝わっていないということはよくある。そういう時、「前にも言いましたけど」みたいな話をしだすと不幸にしかならない。情報のやりとりは伝える側と伝えられる側双方の協力が不可欠だが、コントロールしやすいのは伝える側である。方針が浸透していない時に確認したいチェックリストを雑にまとめておく。 理解してくれているか 同じ言葉でも認識が違うことは多い 特に方針はキャッチーな表現を使って抽象度が高いこともある 具体も伝えて理解しているかどうかを確認すること 納得してくれているか 意義を感じていないと浸透しない 説明する側が納得していることはもちろん、納得させられるまで話すこと 方針の背景や議論の流れ、最終決定事項までアクセスしやすくして個々人が自律してキャッチアップできるようにしておくことも重要。いわゆる情報の透明性、フラットさ どちらかに決めて進む必要があることも多い
自分の勉強や開発をできなくなった - Konifar's ZATSU
最近夜や休日に自分の勉強や開発をできなくなった。 夜や休日にそんなことせずに業務時間内でやるべきでしょという意見もあると思うが、自分の場合は以前は苦もなく自然とやれていた。それが今はできていない。 理由は明確で、自分が集中できていないからである。背景には育児家事の話はもちろんあるが、時間が取れていないわけではない。 息子は睡眠エリートで毎日2~3時間昼寝をするし夜20時半には寝ている。寝ている時間に何かをすればよいのだが、手が付かない。イメージとしては、1日のMPを使い果たしている感じ。こういう感覚は育児に関係なく経験していて、集中できなくなってしまう時期はあった。 なので「育児家事で時間が取れない」というのは正確ではなくて、「自分が集中できていない」というのが正しい気がする。これは自分の考えであって、家庭にもよるとは思う。家事育児の事情は本当に家庭によって全然違う。子どもが生まれたことで
Slackでよく使うフレーズ - Konifar's ZATSU
自分がSlackやオンラインでよく使うフレーズをメモしておく。他の人のも知りたい。 「質問です！ :raising_hand:」 質問をしたい時に最初に書く 例) 質問です！これって○○ということですか？ 「進捗です」 ひとまず進捗報告する時に最初に書く 例) 進捗です！結論から言うと1日分くらい遅れてます :bow: 「just ideaですが」 ポッと思いついたアイデアを伝えたい時に最初に書く 例) just ideaですが、○○というのはどうでしょう？ 「間違ってたら指摘してください :pray:」 誰かの考えられた意見に対して意見を言う時に書く 例) これって○○の方がいいかもと思ったんですがどうでしょう？間違ってたらすみません指摘してください :pray: 「:cool:」 よいと思ったときに最初に書く 例) Cool :cool: 「念のため確認です！」 相手もすでに考えてるで
技術的にも工数的にもできるけど歯切れが悪い返事をしてしまった - Konifar's ZATSU
会社で微妙な返事をしてしまって、しかもその気持ちをうまく伝えきれなかったので雑にまとめておく。 何が起きたかというと、技術的にも工数的にも何も問題ない機能なんだけど「うーん、それ今やるのかぁ」みたいな気持ちが拭えず微妙な返事をして結論を出しにくい空気にしてしまったのだった（完） コードを書く人がこういう反応をすると、デザイナーさんやビジネスのメンバーは対応に困ると思う。仕事に限らず、誰かに何かをしてもらうときには相手に納得してもらった上でやってもらいたい。その方がお互いに幸せなのは間違いない。 今回の話でいえば、「やる・やらないで言えばやった方がいい」というのは間違いなかった。問題なのは、「テストも含めると意外と時間がかかる改善になりそう」ということだ。といっても、1週間もあればできる話だった。 人によると思うけど、自分がそういうときに考えるのは「そのコストを払った分ユーザーか会社にメリッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
