サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Nintendo Direct
konifar-zatsu.hatenadiary.jp
マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。 ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは?」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。 つまるところ、いわゆるマネージャーとプレイヤーの違いは、
仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。 ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。 それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。 一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状
先日参加した pmconf 2021 の Discord に、クロージングのあと約20分ほどハンターハンターのチャンネルが作成され、そこで少し雑談をした。 ハンターハンターの台詞はプロダクト開発の中でも活かせるものが多いよねという、雑談チャンネルにふさわしい内容であった。正直自分でも後で何の話だっけ?となりそうなので、話した内容 + α をざっと書いておく。 ドキドキ2択クイ~~~~~~~~ズ!! プロダクト開発の中で、トレードオフを考慮しなければいけない場面は多い。「ではドキドキ2択クイズしますか」のように使うと議論が整理できてよい。ただし、この場合の答えは「沈黙」ではない。また、トレードオフだと思い込んでいるだけで実は「ナカヌキ」的な一手が存在しうることもあるので注意が必要。 今オレ達にとって最悪のケースってのは何だ? 議論の本質が見えなくなった時に整理できる。実は今話している前提から
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack
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
幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。 発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか?」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。 成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。 一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題
グレード評価制度において、上のグレードに行けば行くほど期待が抽象的になるよねという話を会社の同僚氏と話していた。 ICでもマネジメントでも影響を及ぼす範囲も広がり、できることも増える中で求められることも自然と多くなってくる。 そんな抽象的な期待を明確にする部分も求められているよねと同僚氏が言っていて、それはたしかにと思った。要するに、自分がどこで成果を出すべきかを自分で定義できるスキルが必要になってくるということである。 ジュニアとシニアみたいな分け方があるが、これはシニアに求められるスキルの一つかもしれない。何をやったらいいのかわからない中でもまわりを見渡して、必要なアクション (must)と自分のやりたいこと (will)とできること (can)をすり合わせて方向を決めるみたいな話である。 それはマネージャーの仕事だろと言われればその通りなんだけど、グレードが上がるとそういう抽象的な期
何かを伝えたり聞いたりする時には本人と直接話す方がよい。当たり前っちゃ当たり前なのだが、意外とうまくできていないことも多いので最近特に強く意識するようにしている。 「どうなってるか分からなくてモヤモヤする」とか「あの発言や行動ってどういう意図なんだろう」とか、内に籠もって想像だけしているとロクなことがない。直接本人と話してみると実は何の問題もなかったなんてこともある。 ただ、直接話すのは簡単なようで難しい。話す側は感情のコントロールと言語化のスキルが要求される。聞く側のスタンスも重要で、これは話す側はコントロールできない領域なのでより難易度が上がる。話す側聞く側どちらかに負荷が偏ると相手のコミュニケーション能力のせいにして余計にめんどくさいことになってしまう。組織においては、直接話して物事を解決すること自体を推奨するといった工夫が必要かもしれない。また、ある程度はスキルトレーニングもあった
社内アンケートや読んでおいてほしいマニュアルなどがある時、『タスクが終わったらleaveするSlackチャネル』を作って必要な人を全員入れておくと楽。同じようなことをやってる会社も多いんじゃないかと思う。 自分が所属している会社のSlackチャネル命名規則では、こういった一時的な用途で使うチャネルには tmp- prefixをつけるようにしている。 どのくらいの人が終わったかをチャネル内の人数で把握できるし、リマインドも @here メンションでできる。チャネルを切り出しているので、Zapierなどでリマインドを自動化するのも楽。 やる側としても tmp チャネルにずっと入っているのは嫌なので早めにやるモチベーションになる。 やったことがないと「うざったいんじゃないの?」と思われるかもしれないが、関係なかったらすぐleaveすればよいし、関係あったら終わらせてleaveすればよいだけなので
マネジメントの仕事を始めて1年半くらい経った。日々ハチャメチャが押し寄せてきて泣いている場合じゃなく、落ち込んだりもしたけれどわたしは元気です。 主に気持ちの持ち方みたいなところでの変化を雑に3つくらい書いておくことにする。 自分がやる必要はない 全部やろうとせず委譲するのが大事とはわかっていても、それをやっていると「俺いる意味あるんか...?」と感じることがある。側から見るといわゆる自己組織化、適切な権限委譲が行われているということになるかもしれないが、当人は焦ってしまったりする。 自分が為すべきことを明確にして、それを達成できるのであればどんな形でもよしというマインドを持っておくとよい。メンバーを信頼して任せるというのはもちろん、自分にできないことをまわりを巻き込んで達成することも必要。極端な例だと、自分の言葉でチームメンバーのモチベーションを上げられないのであれば、別の適切な人を召喚
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな
ソフトウェア開発の経験がない嫁氏と、たまに開発の話をする。いつだったか、たしか個人開発している時だったと思うが、CIとCDを先に整えておくのはとても重要という話をした。 仕事が終わってからもMacbookをいじっている自分に「今何してるの?」と聞かれたのがきっかけだった気がする。「開発に入る前の下準備だよ」「下準備って?」「やっておいた方がそのあとの効率がよくなることってのがいくつかあって、それをやってる」「たとえば?」「CI/CDの設定とか」みたいな感じ。そこからCIの説明に入った。ざっくりまとめると以下のような会話だ。 CIというのは、食洗機のようなものだ。我々も食洗機を使い出す前は「食洗機なくてもいいよね」という話をしていたと思う。しかし今はどうだ?食洗機がない生活は考えられない。食洗機をもっと早く買っておくべきだったという共通認識がある。 使い出す前はどうだったか。「何でも洗えるわ
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
2021年も雑にまとまりのない話を書いていくぞ! 今まで4社くらい経験してきた中で、嫌だなあ何とかしたいなあと思っている課題がある。「意見を言ってくれた人がなんだか孤立してしまう現象」である。どういうことか何となくイメージがつく人も多いのではないかと思う。 例えば何かのフローの改善提案をしてくれた時。課題と解決案を提示してくれた人 vs その他の人たちのような構図が生まれてしまうことがある。答えのない難しい課題ほど、そういう空気になりがちだったりする。 本来そういった意見を出した人は最大限リスペクトされるべきである。30点レベルであってもたたき台を作るのが一番大変だし、何かを提案するという行為自体がとてもエネルギーのいることだからだ。 しかし、悪意はなくともなんだか対立構造のような形になってしまうことがある。自分も何度か経験があって、「あれなんで俺こんな責められてるみたいな感じになってるん
この記事はSHIROBAKO Advent Calendar 2020 25日目の記事です。 実は今所属している会社にはアニメ制作進行をやっていた経験があるProject Managerがいる。彼の視野の広さ、進行の管理能力にはいつも感嘆している。 プロジェクトが並行で複数走り、Product Managerやエンジニア、デザイナー、法務にMarketing担当、時には経営陣まで巻き込んでリリースに向けて適切なコミュニケーションを取って進めてくれている。つまり宮森である。 そんなProject Managerの宮森と雑談した時の話を雑にまとめてみようと思う*1。 宮森ですね! 「なんで新卒でアニメ制作会社に入ったんです?」 「アニメを作りたかったからですね」 「なるほど、宮森ですね!」 最初の『ねぇよ』話 「SHIROBAKOって、たしか『あるある』が50%、『こんなだったらいいな』が20
リモートで働くようになって、当然だけど雑談が減った。 適度な雑談は必要だと思っている。雑にコミュニケーションとっておくと仕事で絡む時も楽だし、課題や改善の話がポロッと出たりもする。入社したばかりの人は馴染みやすくなるし、マネジメントする人はチームの状態を把握しやすくなる。HIGH OUTPUT MANAGEMENTの中でもフロアをうろついて話しかけるみたいな話が書いてあった気がする。 フルリモートになって色々工夫してみたけど対面より優れたやり方がまだ見つかっていない。現時点でやってみたことや考えてることを書き出してみる。 自由に参加できる雑談の予定を週一でセットして話す 参加するメンバーが固定化されてしまってあまりワークしなかった そもそも「雑談」という予定を入れた時点で全然雑じゃなくて、なんだか真面目な感じになるというジレンマを抱えている 入社したメンバーと職種違うメンバーを数人指名して
次のページ
このページを最初にブックマークしてみませんか?
『Konifar's ZATSU』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く