"マネジメント"投稿一覧

kentaro haneda（jumbo）

エンジニア

そもそも1on1のアジェンダが評価だけになることはなく、雑談だったりライフイベントの話だったりをします。評価に関わるときはスクラムや朝会など別の会議体で行うこともあります。

kentaro haneda（jumbo）

エンジニア

面接官によってもズレが起きてしまうので、そういうことが起きづらいように「この人ってこういうことできるよね」みたいな構造化した面接をすることが重要だと思います。
入社後にずれが生じたときに採用プロセスにFBする決まり切った構造があるわけではありませんが、採用担当者がそれぞれ思う部分があるので、その点で振り返ってもらうようにしています。

kentaro haneda（jumbo）

エンジニア

本人に期待役割を伝えるだけでなく、関係するメンバーにもどういう役割で入ってもらうのかをお伝えして、自分以外が本人に期待値を伝えられないという状況はなるべく起こらないようにしています。また、実際にポジションとしてわかりやすく示すようにしています。

kentaro haneda（jumbo）

エンジニア

全体的に言語化しにくい領域ではあるので、話し合いながら「こういう手段だとうまく行かないか」みたいな話をして擦り合わせます。マネジメントは新しい成長要素ことであるという理解をもってもらい、時には「いまはまだ出来なくて当然」という考えのもとで、周りとうまく話し合ってもらうことが重要です。温度感を擦り合わせることでアレルギーみたいなのは出なくなると思います。

kentaro haneda（jumbo）

エンジニア

デザイナーやPdMへのフィードバックの機会があります。基本的には具体的すぎる内容では評価が難しい（ex. クリエイティブの質）ので、少し抽象度を上げることや、むしろより具体にして成果を定性から定量に落とします。難易度については被評価者だけでなく、関係したメンバーからも話を聞いておくことや、難しかったことをより言語化してもらうことで客観評価をできる状況を作ります。

kentaro haneda（jumbo）

エンジニア

期待値がズレていることや、そもそも評価への向き合い方に課題があります。被評価者は自分以外の人の評価や目標設定を見ることがないので、様々な状況・ケースを事例などを用いながら伝えます。なるべく評価されるのが上手い人にばかり評価が良いものが集まらないように公平になるよう心がけ、評価されることがまだ得意じゃない人には評価制度の意味から何度でも説明します。その上でもシンプルに差が出てしまうときは期待値や成果... 続きを見る

kentaro haneda（jumbo）

エンジニア

スキル不足であることを直接伝えます。またそれでけではなく、それがどういう理由で、なんのために今求められているかをセットで伝えることも大事なので、そこにも力を入れます。ただ大体褒めもします。助かっている部分もちゃんと伝えつつ力のかけ方をすり合わせます。特にコーディングや設計などのわかりやすいスキルを除いた言語化しにくい領域などで期待されていることについては、目標設定や1on1の仕組みを使いながら期待... 続きを見る

和田健太郎

エンジニア

短期的にはその領域を得意としている有識者（同組織のマネージャーなど）の力を借ります。
マネージャーの存在理由がチームの成果の最大化、FBの目的がメンバーのレベルアップだと捉えると、必ずしもマネージャー自身が全てにおいてFBできる必要はないというのが持論でもあります。

ただし、このやり方が成り立つのはメンバーとの信頼関係が構築できている前提であるため、やはり中長期で見... 続きを見る

山本隼汰

エンジニア

基本的には、カルチャー面さえ自社とマッチしていればいいかなとは思っていて、ある人と「価値観が合っている」と感じている状態は自分自身の油断を生み出すため、「やばいな」と思うようにしています。価値観が合っていると感じるから、つい注意不足になってしまいますし、すり合わせが不十分なまま進んで「認識が合っているように見えたのに、実は違った」が一番大きい損失になるためです。

基本的には、... 続きを見る

ABEChan@iOS/Android Developer

プロジェクトマネジメント

企業サイドの立場であれ労働者の立場だとしても、経営方針や企業の文化と個人の価値観は一致させ続けることが非常に難しいです。
企業側の場合は採用の際に事業共感を求めすぎない(あればそれはそれでいい)こと、むしろそこが採用時に強すぎる方は、企業側の変化に非常にナイーブな傾向が多いようなので、むしろ慎重に採用を進めます。
また個人視点ではその雇用主に要求すること(待遇/文化/価値観等)... 続きを見る

km2

プロジェクトマネジメント

初めまして
私の全くの私見です。そういう状況の時の考え方・選択肢は整理しています。

1,状況・環境を変える努力をする
2,あきらめて甘受する
3,辞める

この3択に照らし合わせて、どれが自分の人生にとって有利か？
有利とは、単に金銭的な有利もあれば、経験もあります。
自分の環境や関わる人含めて総合的に有利... 続きを見る

大橋桃太郎

プロジェクトマネジメント

（前提とされているように程度問題はあると思うのですが）例にあげられているようなケースであれば、 "未知に触れる機会" と捉えて糧にできるか、が重要に思います。不確実性を楽しめる能力といったところでしょうか。まずそう思ってみるところからしか拡がらない可能性がありますよね！

kentaro haneda（jumbo）

エンジニア

EMを経験しつつ、CTO2年目のまだまだ若輩の身ですが・・・

細かいトレンドや意思決定の際に大きくリスクにならないようなことは逆にチームやメンバーに任せるべきだと思うのですが、「中長期的に見て把握しておくべきことやボトムアップで導入が難しそうなもの」はちゃんと手探り感を持って意思決定や導入をEMがするのが効率がいいと思うので、どんなに忙しくても触っておいて乗り遅れないようにし... 続きを見る

荘野敬也（bowyer-app）

エンジニア

僕も同じ境遇です。
通勤時間を利用して、従事している技術の最新情報をキャッチアップしています。

また、カジュアル面談は積極的に引き受け、面談している方から最新の情報を仕入れるようにしています。
手をじっくり動かす時間はなかなか取れないので、アンテナを張って情報収集することに注力しています。

和田健太郎

エンジニア

世の中あらゆる場所で同じような疑問を持っている方がいるんだなと思い若輩ながら回答させていただきます。

個人的な見解としては、価値観のすり合わせ、というのは組織のマネージャーと現場との間のコミュニケーションの深さで解決するしかないだろうなというところです。

カルチャーマッチはそうなんですが、組織の価値観にピタリ一致する人を全世界から必要人数かき集めてくる、... 続きを見る

大井竹昭

データ分析

データの利活用を中心としたコンサルをやっております。

マイクロマネジメントにならないようにするには、信用することです。

指示としては、アウトプット像、その為のアウトカム例を明示することです。
それだけで不穏な顔をする人には、実現方法をアウトカム例を実演してみせるになります。

アウトカムの実現方法は同じやり方をなぞっても良い... 続きを見る

YOSHIOKA Yoji（吉岡洋司）

デザイナー

プレイングマネージャ歴5年です。
以下の2点を意識することで両立しています。

1. プレイヤの自分も、マネージャとしての自分の管理下に置き、他のプレイヤと同じように客観的にリソースを把握して管理し、仕事を振ること

2. 例えば、マネジメントの仕事のトラブルがあった時に、もう一方のプレイヤの仕事を進められないことに不安やストレスを感じるといったこ... 続きを見る

杉田大樹

プロジェクトマネジメント

マネジメントする組織のメンバーがある程度自律して任せられる状況であれば、おおまかな目指しどころと推進イメージをインプットして任せてしまいます。（何かあったら責任はこちらで取るので思うままにやってみてほしいと伝えます。）
一方メンバーの構成要素の中でまだ未熟なメンバーの割合が多い場合はある程度マイクロマネジメントにならざるを得ないなと感じております。（タスク化を一緒にやる、悩み相談などのフ... 続きを見る

山本隼汰

エンジニア

マネジメントしようとしないことでしょうか。変に力が入ってしまうとマイクロマネジメントになってしまうし、ぼーっとしてると放置・放任してるだけになってしまうため、ある程度、細部については無関心になりつつ、自分が相手に期待するゴールイメージを明確に持っておくことが重要かなぁと思ってます。（「うまく行った時のビジョンが見えているか」を自問自答しています）

そうするために、「最悪ここま... 続きを見る

Dai Fujihara

プロジェクトマネジメント

僕の場合は、マネージャになって、なんでもかんでも自分がやるには限界を感じたので、チームが自律して動ける方法を考えるようになりました。社会人であれば自立しているはずなので、個人やチームでの自律を目指します。

自律を促すためにポイントのひとつが、インプットとアウトプットです。

たとえば、インプットとして、こちらが相手に期待するものを伝えます。それはふるまいか... 続きを見る