視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
混ぜるな危険！？スクラムマスターとエンジニアリングマネージャーを兼務するということ - freee Developers Hub
こんにちは、freeeカード Unlimitedでエンジニア兼スクラムマスターをしている mattsunです。この記事は freee Developers Advent Calendar 2022 の4日目です。昨日は ichyさんのとりわけスクラム開発をやるときに立ち向かわなければならない壁の話でした。 freeeカード Unlimitedは、2022年1月26日に正式リリースされた比較的新しいサービスです。開発の裏側については、「【連載 第1回】freeeカード Unlimited の開発の道のり」の連載を参照ください。 はじめに 本記事では、「スクラムマスターとエンジニアリングマネージャーを兼務するということ」について考えます。 この記事から得られること 「スクラムマスター」や、「エンジニアリングマネージャー」というロールに期待されることの理解が深まる 「似ていること」「違うこと」を
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発副本部長の okady です。 サイボウズ開発本部では2019年に組織変更を実施し、当時のインタビュー記事で私はこんなことを言っていました。 「マネージャー、いないと無理なら、またつくればいい」 サイボウズの開発本部がマネジャーをなくしてみた「いないと無理なら、またつくればいい」 | サイボウズ式 そして今回の記事は、当時の私自身の言葉に応えるタイトルにしました。 「マネージャー、いないと無理だったので、またつくりました」 2019年の組織変更から3年が経ち、目的は概ね達成できました。しかし、思い通りにいかなかったことや当初想定していなかった問題もたくさんありました。そして2022年5月、開発本部の組織力をさらに強化すべく再び大きな組織変更に取り組むことを決断しました。 この記事では、2019年の組織変更とその後を振り返った上で、2022年に実施した新たな組織変更についてご
なぜIT技術者でマネジメントのキャリアパスを目指す人は少ないのか - Qiita
はじめに この記事で言うIT技術者とは、ITエンジニア・デザイナー全般を指します そして、それら職種でのマネジメント経験者は 「後継者が少ない」 という悩みを抱えている方が多い印象です この記事では、なぜそうなりがちなのか考えてみます キャリアパスについて 考えるにあたって、まずはマネジメントとそれ以外のキャリアパスについて触れます 組織によって異なりますが、キャリアパスは大別すると2種類に分かれます ヒト・モノ・カネのマネジメントを担う：マネジメント 技術に特化した役割を担う：スペシャリスト そして、現在それら役割は担っていない人はだいたい3種類に分けられると考えています どちらかのキャリアを目指し、邁進している人 どちらのキャリアも目指さず、現状維持で満足している人 どちらかのキャリアもイメージが湧かず、目指せると思っていない人or悩んでいる人 経験上、最も多くを占めるのは3つ目の ど
相談されなくなる理由 - Konifar's ZATSU
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
異職種から信頼されるエンジニアの5つの特徴 - Qiita
はじめに この記事はこれまで私が15年ほどの社会人経験の中で見てきた「異職種から信頼されている」エンジニアの特徴をまとめています。 今回は「異職種から〜」なので、例えば営業、マーケティング、デザイナー、事務職などなどの「エンジニア以外の人から信頼されているエンジニア」の話です。あくまで私の経験からの内容のため一例として読んで頂ければと思います。 昨今の組織では上司からの評価だけではなく、一緒に働くメンバーからの360度評価を採用している組織もあるかと思います。その中で、同じエンジニアからだけではなく、異職種のメンバーも含めた360度評価もあるかと思うのでその際の参考にもなれば幸いです。 また「評価のため」だけではなく、様々な職種で仕事を進めていく際に良い状態で臨むためにも参考になれば幸いです。 異職種から信頼されるエンジニアの特徴 目次 ①出来る方法を一緒に考えてくれる ②期限を過ぎる場合
エンジニアリングマネージャーになって半年経ったので、やったことと振り返りをしてみる - Qiita
2022年1月にマネージャーの役を仰せ仕ってはや半年が経過しました。 右も左もわからないが、理想はあった状態でのスタート。 方法論は日々色々なところでキャッチアップしたが、組織はナマモノ。 構成メンバーによってBest Practiceは変わる。 そんな感じで、よりよくするために結構色々やってきました。（つもり） うまくいった（と思っている）もの、全然だめだった（やめた）もの、迷走中のもの色々とあります。 ちょうど評価の時期でもあるので、外部公開できるレベルのものは全部書いてしまおうと思います。 なお１か月経過した頃に書いた記事は以下。 継続したこと、辞めたこと、新しく始めたことなど、状況が変わっているものもあります。 改めてやったこと、成果、今後やりたいことあたりをバババババーーーーああっと書いてみます。 この半年でやったことと結果 機能強化案件２ProjectをManage＆Play
新人の正論を取り込む準備と心構え - Konifar's ZATSU
最近新しく人が入ってきて、今まで手がつけられていなかった部分に対する正論をストレートにぶつけてきてくれて思わずにやけてしまった。 そう、新しい人には感じたことをそのまま言ってほしい。まだ自分が成果を出せるかわからないタイミングで正直に思ったことをぶつけるのはすごく勇気がいることだとは思うけれど、新しい旋風を巻き起こしてくれた方が嬉しいし、それをうまく取り込むのは既存メンバーの役割だと思っている。 正論をうまく取り込むには準備と心構えが必要だと思っていて、それをざっとまとめてみる。 社内ブログやSlackチャネル、定例など意見を言いやすい場所を用意しておく 感じたことは率直に言ってほしいと期待している役割などを伝えておく 口だけみたいになるのでは、という不安はいったん気にしなくていいと伝えておく 個人ではなく仕組みに対してという伝え方を意識してほしいと伝えておく 言ってくれたら、まず素直に感
社会人エンジニアになるに備えて - Qiita
背景 ここ数年間は、筆者が採用周りの仕事も増えてきて、そしてカジュアル面談などでも特に学生さんを中心に「就職するために必要なスキルやレベルを教えてほしい」とか、「自分のスキルが会社の開発業務でも通用するかわからない」的なご相談を多くいただいております。 確かに学生のうちは、企業での長期アルバイト経験がある方を除いて、ほとんどの人は社会人経験が皆無と言っていいでしょう。そんな中で不安を覚えるのも無理はありません。というわけで少しでも企業でのエンジニアとしての働き方のイメージが明確になれたらと思いながら、この記事を綴らせていただきました。 免責事項 この記事の内容については、あくまで筆者の経験に基づいた話であって、全ての企業に通用するわけではありません。ただ大きくかけ離れたことはおそらくないと思います。 本文 学生のうち、特に情報工学の経験がなく、あくまで趣味駆動でプログラミングを始めた学生さ
心理的安全のためにマネジャーがきょうからできる7つの習慣 - Qiita
チームが生産的・自律的であるために重要な「心理的安全」を高めるにはどうしたらいいか？ これを職場で考える機会が最近ありました。 それを踏まえ、職場のマネジャーにお勧めしたことをここでも共有してみます。 対等に話す 部下が上司に使うのと同じように、上司も部下も敬語を使うべきです。 「さん」づけで呼びかけるべきです。 なぜなら、常体（ため口）や「くん」づけは上下関係が前提になっているからです。 これは日本語ならではの特徴です。 問題は、本人は歩み寄っているつもりでも、部下からしたら怖いということがありえます。 もちろん雑談モードだったり、すでに双方の距離が近かったりすれば、問題にはなりません。 対等な言葉遣いをする別の利点は、 高齢化してきた組織では、ある日を境に突然、上下関係が逆転することがよくあり、 敬語や「さん」づけに慣れておけば、逆転しても自然な関係を維持できることです。 これは『会社
問いを立てるプロセスこそ、プロダクトマネージャーの腕の見せどころ - Qiita
はじめに 問いを立てるって難しいですよね この記事を書く自分自身もまだまだ見習いでひよっこです 取り組んでいる中で、ちょっとわかったことを今回記載します 見習いでひよっこだからこそ、しくじりを交えて 俺の屍を超えてゆけ 問いを立てるってどういうこと 問いを立てるとは、「解決すべき問題を設定する」であったり、「明らかにしたいことを決める」と言い表せるのではと思います。 つまり問いを立てることは、問題解決のはじめの一歩です。 良い問いを立てることができれば、理想や狙いを叶える可能性が高まります。 しかし問いを間違えると、この後に続く「仮説」「検証」「判断」「実行」のプロセスが全て無駄になってしまう恐れがあります。 これまで何度問いを間違えてきたことか…。それだけでなく、その後に続くプロセスも大失敗をしてきていますが、今回は正しい問いを立てるヒントを、自身のしくじりを交えて3つ共有＋1つおまけを
どん底から、テックブランド国内トップ10位にランクインした方法全部教えます。｜Ray Kataoka
２０２２年５月に日本CTO協会が発表した「テックブランド調査」において、ゆめみがトップ１０位にランクインしました。 錚々たる企業がランクインする中、自社サービスやプロダクトを展開しない企業としては最上位に位置付けています。 ただ、２０１８年当時はまだテックブランドどころか知名度も低かったのですし、２０１７年度はどん底にありました。 そこで、２０１９年にブランド目標を設定して、本格的にテックブランド構築の打ち手を継続的に行ってきたことが結果に繋がりました。 では、どのような取り組みを行ったのか？をお伝えできればと思いますが、コンセプトとしては「採用ドリブン経営」というものを実践してきました。 「採用ドリブン経営」というのは一般的な言葉ではないですが、今後あらゆるIT企業にとて必要になる考え方だと思っています。 私は、この採用ドリブン経営をゆめみで実践しているのですが、実践するようになった事に
コードを書いていてマネジメントもやるようになっちゃった人へ 背中で語っていた僕が、プロダクトとピープルに向き合うまで
「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。前半は、最初期のマネジメントとプログラマーとして犯してしまった禁忌について。 エンジニアにありがちなキャリアの変遷 海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Stud
スクラムにおいてプロダクトオーナーはどこまで「権限＋オーナーシップ」を持てるのか？ - Qiita
はじめに 今回はスクラムにおいての役割の1つであるプロダクトオーナーの「権限とオーナーシップ」について、自身の経験を踏まえて書いてみたいと思います。おそらく各組織チームによって状況も違うと思うので1つの答えは出ないと思いますが皆様の参考になれば。 プロダクトオーナーとは？ まずはスクラムにおいてのプロダクトオーナーとは スクラムガイド2020年11月 より ここで定義されているように、一番の役割は「プロダクトの価値を最大化することの結果に責任を持つ」になります。主にはプロダクトバックログを管理し、優先順位を決めていきます。開発チームに対して指示は出しませんが、全体の状況把握は必要になります。 「プロダクトの価値を最大化することの結果に責任を持つ」 とっても重要そうな役割ですよね。 価値とはなんでしょうか？売上？ユーザー数？品質？ブランド力？いろいろありそうですよね。 そして企業や組織の中で
「人の話をちゃんと聞けない人」の問題は、意識とかテクニックだけでは解決できないかもしれない。
つい最近、「人の話をちゃんと聞けない人」を「聞ける人」に変えるのは可能なのか、という話でディスカッションになった。 というのも、ある経営者が「お客さんの話を全く聞けないメンバーがいる」と愚痴をこぼしたからだ。 すると、周りの人々も、呼応するように、「いるいる」という。 その経営者の話を聞くと、おおむね次のような状況だった。 その人は、良く言われるテクニック的な「傾聴する姿勢を見せる」のは得意だという。 「聞き上手」のように、メモを取ったり、頷いたり、相槌を打ったりする。 人の話を遮ったりもしない。 しかし、同僚やクライアントからしばしば、次のようにクレームがあるという。 「あの人、全然話を聞いてないんだよね。」と。 具体的にはどのような事象でしょう？と聞くと、 「例えば、同僚から意見を求められても、「それでいいと思います」としか言えない。あるいは、クライアントが「この構成に対して指摘はあり
不確実性に立ち向かう一つのTips〜リスク管理に取り組んだ話〜 - BASEプロダクトチームブログ
こんにちはエンジニアリングマネージャーをしております植田です。4月18日にグロースプランの提供が開始されました。今回この開発プロジェクトにて「リスク管理」に取り組んでみたのでそのお話をします。 Index リスク管理に取り組んだ背景 そもそもリスク管理とは 具体的なリスク管理の進め方 リスク管理はどのようなプロジェクトで実行すべきか 実際にどのように取り組んだか 取り組んで良かったことと、今後発展させたいこと リスク管理に取り組んだ背景 まず今回なぜリスク管理に取り組んだかをお話します。BASEでは現在大小様々な開発プロジェクトが同時進行していますが、日に日にその複雑性は増しています。年月を追うごとに積み重なる仕様、日に日に拡大していくリポジトリ（ソースコード群）…と、複雑性・難易度は増す一方です。その中で、開発プロジェクトもいわゆる「不確実性が高い」と言われることが当たり前の状況になって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織の生産性を高める意思決定の構造と方法 / How to do make decision rapidly and effectively
リモートワークにおけるファシリテーションの方法論