オンラインミーティングでカメラをONにすべきか - Konifar's ZATSU
「オンラインミーティングでカメラをONにすべきかどうか」という議論をたまに見る。カメラをONにしたほうが視覚情報も得られてコミュニケーションを取りやすいので、"カメラON推奨" のようなルールを決めているところもあると思う。 自分は「カメラONじゃなくても反応を多めにすればいいとは思うけれど、結構むずかしいのでスキルがないならカメラONにしといたほうがいい」という意見を持っている。どういうことかを雑に書き出してみる。 実は自分の所属でも当初 カメラはできるかぎりオンにしよう という指針*1を作っていたが、3週間くらいやってみて変えた。 github.com 背景は Pull Request の description に書かれているとおり。サマリは以下。 カメラON"推奨"という全体指針は、強制力がないため結局ONにしない人も多くてあまり意味をなさなかった カメラONにしたい理由は表情含め
実行責任が先、説明責任が後 - Konifar's ZATSU
責任には Responsibility と Accountability の2種類がある。 厳密な訳ではないけれど、前者を「仕事に対する実行の責任」、後者を「組織に対する説明の責任」という理解をしている。 この2つは両方大事なのだけれど、責任を果たす順番をつけるなら実行責任が先で説明責任が後。この順番を間違えると正しい意思決定ができなくなる。自分はちょっと油断するとすぐに説明責任を先に考えてしまいがちなので、雑に考えをまとめておく。 実行責任の第一歩は意思決定をすること。意思決定で一番大事なのは、意思決定者が「正しい」と思えることを打ち出すことである。結果として間違っていてもいい。むしろ正解にしていくことも実行責任に含まれるので、少なくとも意思決定者が「正しい」と思える決定を意思をもって掲げなければならない。 説明責任を先に考えてしまうと、正しいことが何かを考えることに時間を使わなくなる。
メンバー思い"風"マネージャー - Konifar's ZATSU
自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対
タスクを完了したら抜けるSlackチャネル - Konifar's ZATSU
複数人に必ずやってほしいタスクがある時、『そのタスクが終わったら各自抜けるSlackチャネル』を作る運用にすると楽。最近試験的に"月の勤怠を提出したら抜けるチャネル"を Zapier で自動作成するようにしたので雑に書いておく。 Zapier はこんな感じで組んで、毎月1日10時になったら前月分の勤怠提出を促すための #tmp-kintai-YYYYMM チャネルを作成してメンバーを招待する。 で、11時、15時、19時に自動でリマインドし続けるだけ。若干無駄に Action を消費する Zap になっているので改善すべきだとは思う。 毎月ちゃんと提出してくれる人にはうざったいだけなので、そういう人は自動招待の対象から外していっている。だんだんと対象人数が減ってきているので、最終的にはこの仕組み自体が不要になればいいと思う。あと、欲を言えばこういうしつこく強制力のつよいリマインド機能自体は
全てを自分の"作品"として仕上げる - Konifar's ZATSU
自分のまわりのすごいなと思う人の仕事を観察していると、ひとつひとつのタスクを自分の"作品"のように仕上げているように見える。実際に彼らがどう考えているかはわからないが、自分から見た印象を雑に書いてみる。 たとえばチャットツールでの依頼のメッセージひとつ取っても、過不足なく端的な内容になっている。人によっては読み返して細かい表現を編集して変えていたりもする。美容師の最後の仕上げのようである。 エンジニアであれば、コード自体はもちろんコミットログを丁寧に残したりとかもそう。GitHubを使うならそこまでコミットログ自体にこだわりすぎなくても履歴を追いやすいが、それでも手元でrebaseやsquashを駆使して綺麗に整えている。 同様に、IssueやPull Requestのテンプレートがあればそれに沿ってきっちり埋めてくる。テンプレートのままの状態で出したり無視して適当に書いたりしない。もしも
毎回自分の意見が通ってしまう不安を"受容"する - Konifar's ZATSU
スキルも経験も積み重ねてきた人が抱きがちな悩みとして、「自分が意見を出すと毎回大きな反論なく通ってしまって不安になる」というのがある。 いわゆるリードができるレベルになると、他のメンバーより視野を広く持って色々なことに考慮した意見を出せるようになる。しかし実際には明確な答えは持っていなくて自信があるわけでもないこともある。 それなのに自分が言ったことがそのまま通ってしまう。発言すると、「たしかに」「そうですね」「いいと思います」みたいな雰囲気になって採用されていくのである。新しいサービスの設計方針の議論、コードレビューでのやりとり、チーム目標を決めるミーティング、さまざまなところでこういうことが起きる。 「本当にこれで大丈夫なのか」という不安も感じるし、「もしかしたら自分が発言することで他の人の意見をふさいでしまったり萎縮させてしまったりしてるんじゃないか」と心配になってくる。人によっては
過去の経緯の調べ方 - Konifar's ZATSU
何かの取り組みを始める時、たいていまずは"過去の経緯"をざっと調べると思う。そうしないと過去に起きた問題を踏んでしまったり再発明をしてしまったりするからである。 皆当たり前にやっているように見えて、この過去の経緯の調べ方には意外とスキルのバラつきがある。自分も常にうまくできているわけではないので、思考整理のために雑に書き出してみる。 たとえば一例として、「Androidの自動テストの方針」を決めようとしているとしよう。背景にある課題は適当に想定してほしい。次のようなステップで過去の経緯を調査していく。 1. 調査期間を決める 調査はダラダラとやってしまいがちなので自分で期限を決める 内容にもよるが、自分は半日~1日に設定することが多い。社外の方とのスケジュール調整が入る場合には1週間くらいかかることもある 例で言うと、自分ならいったん1日で設定してガッと集中して調べてキャッチアップすると思
方針に納得できない時のお作法 - Konifar's ZATSU
誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって
極端な自責と他責を使い分ける - Konifar's ZATSU
何らかの問題に直面した時に、原因が自分にあると考えることを自責、他人や環境にあると考えることを他責という。 仕事をする上では自責思考がよいとされることが多いが、自責の念という言葉もあるとおり自分を責めてしまいがちでちょっとしんどいよね。 中には、「すみません、自分のせいで~~~」みたいな感じで過度な自責スタンスが謝罪以上の思考を停止させてしまうこともある。自責と卑屈は違うのだが、自分で自覚するのはなかなか難しい。 自分としては、自責思考がよいと偏って考えるのがよくないと思っている。そもそも何かの問題の原因が自分だけのことの方が少ないわけで、いろんな要因が絡んでいる。 常に自責で考える必要はなくて、自責と他責を切り替えて考えられればよい。「100%自分が悪いとしたら何ができたか」「100%自分が悪くないとしたら何ができたか」という2つの極端な自責と他責を考えてみると次につながる話が出やすかっ
役割をお願いする時に伝えていること - Konifar's ZATSU
マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
ゴールを"刻む"技術 - Konifar's ZATSU
ワールドトリガー247話にて、ヒュースが若村に話した言葉が非常によかった。 "刻むんだ" 目の前の1段を登るために必要な要素を 1段の中でさらに刻んで 自分が登れる小さいステップを作るんだ その行動を努力と呼ぶ 痺れる~~~。この"刻む"というのは目標達成のための大事な考え方なのはもちろん、タスクを進める時にも同じように"刻む"技術が必要。自分もうまくできないことがあるので、雑に考えを書いておきたい。 仕事において、ゴールまでの道筋を刻んで小さくして進めるのはとても重要。進み具合をトラッキングできるし、刻むことでチームで仕事をしやすくなる。いわゆるジュニア、ミドル、シニアの違いは「どれくらい抽象的で大きいことを刻んで進められるか」の差と言ってもいいかもしれない。 このゴールを"刻む"技術はどうすれば身につくのだろうか。経験によって全体を把握する力がついた結果できるようになるというのも一定あ
ゆるめのフォロワーシップ実践方法 - Konifar's ZATSU
誰かがリードしている時に、それを支え、あと押しするような振る舞いをフォロワーシップと呼ぶ。 フォロワーシップについては、Derek Sivers の TEDトーク How to start a movement や あんちぽさんのやっていき、のっていき が自分は好き。研究でいうとロバート・ケリー教授の The Power of Followership の5つの分類が有名。 難しそうに感じるかもしれないが、実はフォロワーシップの実践というのはもっとゆるいところにも現れるものだと思う。自分のまわりの人たちがおそらく無意識的に実践しているように見えることを雑に書きだしてみる。 1. 反応を返す 誰かが発言したり何かを書いたりしたことに対してわかりやすく"反応を返す"という振る舞いは、意外と皆ができていなかったりする ミーティングで最初の挨拶に対して挨拶を返したり、「何か質問や意見ありますか？」
マネジメント想定問題集ほしい - Konifar's ZATSU
マネジメントの想定問題集があれば、疑似体験により引き出しが増えて成長が早まるのではないかと思ったことがあるので雑にかいておきたい。 マネジメントは昔からたくさんの関連書籍も出ていて、ある程度型をもって技術として磨いていけるものではある。 一方で、「やらないことを決める」「思い切って委譲する」といったいわゆる"セオリー"的なことは理解はしつつも、そういう小綺麗な話ばかりではないのはマネジメント経験者なら共感できるのではなかろうか。 社内での役割や経営・メンバーとの関係性にもよるけれども、たとえば次のような泥くさい想定問題があったらどう答えるか考えてみると面白いかもしれない。 1on1 でメンバーから「事業 / プロダクトの方針がわからない」と言われました このまま放置すると離職リスクになりうるかもしれません マネージャーとしてどう動きますか？ 事業計画上、4週間後にはリリースしたい機能があり
問題を"放置"さえしなければちょっとずつよくなっていくんですよ - Konifar's ZATSU
7月くらいに入社した同僚氏は「問題を放置しない」が口癖で、半ば麻痺している痛いところを突いてはすぐに何かしらアクションに移して状況を変化させている。ハイレベル問題解決ブルドーザーである。 「これは放置しないほうがいいですね」、「放置しないほうがいいのでやりましょう」といった感じで話してくることもあれば、「これどうします？放置しますか？」のように聞いてくることもある。見て見ぬふりをしたり、なんとなく結論が曖昧な状態のままにしておくことを"放置"と言っているらしい。ややこしい言い方をすれば、"今は (いつまで) 放置する"と決めたのであればそれは放置してはいないということなのだそうだ。 先日、彼が会議中にボソッと「問題を放置さえしなければちょっとずつよくなっていくんですよ」と言っていて、たしかになあとしみじみ噛み締めてしまった。 何かチャレンジをしていれば問題が多々発生するのは当たり前ではある
チャットコミュニケーションで使わないようにしている表現 - Konifar's ZATSU
チャットコミュニケーションむずかしい。全然そんなつもりで書いてないのに受け手の解釈が乗っかって伝わったりする。 たとえば純粋に質問しているだけなのに責められているように感じる人もいるし、感謝を伝えたつもりが煽りや嫌味と捉えられることもありうる。 そもそもチャット以前の関係性の問題として対処すべきこともあるし、受け手の人となりや状況を完全に理解することもできないのであまり気にしすぎても仕方ない。一方で、自分の経験上解釈ズレが起きやすい表現は明確にあって、自分はそれらを"禁止"するマイルールを作っている。誰でもできるチャットコミュニケーションの工夫の一つとして雑にまとめておく。 あー / えっと 「あー (そうじゃなくて)」とか「えっと (理解できないみたいだからどう言おうかな)」みたいな感じで相手に非があるという印象で伝わることもある じっくり考えられるチャットでこれらを書く必要もないので使
実質的に役割を持つのと明確に責任を持つのは全然違う - Konifar's ZATSU
実質的に何かの役割を担っている"自称"の状態と、組織図上にも表されるような自他ともに認める明確な責務を持つ状態とでは、あまり変化がないようで全然違うという話を雑に書いておきたい。 たとえば「ほぼマネージャーみたいなことをしてます」という状態と「マネージャーとしてやってます」という状態は、マインドも動き方もプレッシャーも実は全然違う。 同じように、「事業責任者みたいなもんですね」という状態から実際に事業責任者というタイトルがつくと、想像よりも周囲の期待や自分のスタンスの変化が大きい。 タイトルが大事というわけではないが、名付けがされると自他ともにそのタイトルに対する期待イメージがより明確になる。それに伴って自分の心持ちや考え方、行動が変わるのはもちろん、周囲の反応も変わる。たとえば実質技術責任者みたいな役割を担っていた人にCTOという名付けがされると、急に「CTOとしてどう考えているのか」と
言語化能力の言語化 - Konifar's ZATSU
"言語化能力"とは何なのかちゃんと説明できないので、雑に分解して考えてみる。めちゃくちゃややこしい言い方をすれば、"言語化能力の言語化"である。 考えてみると、自分は "整理しづらいことを整理して人に伝える力" を言語化能力と呼んでいる。 整理しづらいこと 答えが明確で整理しなくても自明なことについて、言語化がどうこうという話にはならない。 たとえば人の感情が絡むことや固まりきっていないチームの価値観など、整理しづらいことが言語化の対象となる。 ここでいう整理しづらいことというのは、答えがないまたは答えを示すのが難しいことと言い換えてもいい。 整理する力 言語化のためには、自分でよく考えて"練"っておく必要がある。 考える元となる情報をインプットする "情報収集力" はもちろん、普段から色々なことを考えてああでもないこうでもないと考える "思考力" も必要。とっ散らかった情報を整理整頓でき
憧れている人はいるか - Konifar's ZATSU
チームメンバーや他社のエンジニアとの 1on1 の中で、「憧れている人とかいますか？」という話をすることがある。この質問はわりと継続して聞いているなと思ったので雑に書いておきたい。 チームメンバーとの 1on1 で聞くのは半年ごとくらい。目標設定など、たまにはちょっと中長期の話でもしますかってタイミングで話している。いわゆる"キャリア"の雑談である。 自分は「1年後/3年後どうなっていたいか？」みたいな質問がすごく苦手で、うまく答えられたことがない。どうなりたいかを明確にするのは大事なことだと思うけれど、正直3年後とか何もわからんという気持ちになる。自分ができないのでチームメンバーにも聞けない。 そこで、違う聞き方として「憧れている人はいるか？」という雑談をしている。この質問は人によって回答がぜんぜん違うのが面白い。 たとえばiOSエンジニアだと @k_katsumi さんとか。Go書いて
ミーティングの最初にルールや心構えを読み上げる - Konifar's ZATSU
ミーティングのファシリテーションをする時にミーティングのルールや心構えを音読するようにしてみていて、思ったよりいい感じなので雑に書いておきたい。 たとえば月1の開発チームのミーティングでは、次のようなルールを明記して読み上げている。 ドキュメント・Slackへのコメントを歓迎します。事前・MTG中いつでも質問・意見を入れてください あまり厳格にしすぎずハードルを上げない 議事録はみんなでMTG中に書く 最初に声に出してアナウンスすると、それに応えて意識した行動を取ってくれる人が増えているように思う。 他には、インシデント対応の初動で集まった時にはインシデントコマンダーの立場で次のような心構えを画面共有で映して話す試みを始めた。 犯人探しをしない チャレンジしてリリースすれば一定インシデントは発生する 犯人探しをせずユーザーへの対応と改善に目を向け、落ち着いてOne Teamで対応する 同期
相手に話が通じないと感じた時の対処法 - Konifar's ZATSU
相手に話が通じず物事を前に進めにくいと感じることがある。特に、階層化された組織の違うレイヤーの相手や他部署の相手の場合にありがちかもしれない。 そういう時はついついヒートアップしてしまい相手のせいにしてハレーションを生むような話し方をしてしまいがち。"相手が理解してくれないのは相手の頭が悪くて理解できないから"みたいな態度は相手に伝わり、関係がこじれてより一層物事を前に進めにくくなってしまう。 こういう時に感情的になってうまく対処できないのは解決のための引き出しが少ないのが原因なので、思いつく対処法を雑に書きとめておく。 いったん自責思考に切り替える あまりに話が通じないと感じると自分の方が賢くて相手が悪いみたいなスタンスになりがちなのでまずはリセットする 相手に勝とうとするのではなく、目的を思い出して相手も自分も勝つにはどうすればよいかを考えるよう切り替える ほぼ相手に非があることももち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
