私が仕事を任せる(委譲する)時の3つのポイント
こんにちは、NE会社に勤めますきんじょう(@o0h_)がお送りします。 突然ですが、皆さんは「権限委譲」やっていますか？[1] 「権限委譲」というのが大げさであれば、「自分の持っていた仕事を他の人に任せる」くらいの感覚で、読み替えてみても良いかも知れません。 いかがでしょう？ 業務負荷の集中を避けたり、後進の育成を目的として取り組んでいる人も多そうにも思います。 ただ、実際にやってみると「意外に難しい」とも感じる場面があるのではないでしょうか。 あるいは、「やりたいけどやれていない」という難しさもあるかも知れません。 私はマネージャー業に就いてから、あるいは自分より「若手」の多い職場に所属したことで、色々な場面で「仕事を預ける・任せる・委譲する」という経験をしてきました。 また、上司などの他の人から「仕事を受け取る」側の立場になったことも、もちろんあります。 そんな実践の中で、自分なりに気
50代のフルスタックエンジニア - nunulkのプログラミング徒然日記
はじめに この記事について 以下の記事を読んでわりと「うんうんわかるわかる」と思いながら読みましたが、50歳に至るまでの間にもうひとつ別の景色も見えてきていたので、そのあたりを一度言語化してみようという試みです。 note.com フルスタックとは 上記記事へのブコメには「フルスタック」と書きましたが、自分としてはあまりフルスタックと名乗りたくない、という気持ちはありまして、普段は「ウェブアプリケーションエンジニア」と自称しています。 ただ、今回は、元の記事に合わせるために本記事における「フルスタック」の定義を定めておきます。 以下の領域の技術を理解し使える インフラ アプリケーションが動作するサーバや協調するミドルウェア バックエンド サーバーサイドのアプリケーションに用いる言語やライブラリ フロントエンド クライアントサイドのアプリケーションに用いる言語やライブラリ すべてを理解してい
納期がなぜ生産性をぶち壊しにしているのか？｜牛尾 剛
昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。 最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。 日米納期の感覚の違い アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。 常に納期が
外部からいきなりCTOとして就任する時に気をつけていること｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 私は今はオープンロジでCTOをしていますが、オープンロジを含めて今まで4社でCTOをしています。CTOとしての実績と経験を積み重ねてきた結果、今ではある程度開発組織が大きくなった会社からCTOのオファーをいただくことが増えてきました。 いわゆるパラシュート人事というやつです。パラシュート人事は非常に難しく、私が今まで見てきた中でもパフォームしていないマネージャーはほとんどが外部登用でした。逆に現場上がりのマネージャーはうまくワークしており、微妙な人は少数でした。 このように失敗する可能性の高いパラシュート人事で入社する場合は、いろいろ気をつけないといけません。CxOとまではいかずとも、みなさんの中にも転職をきっかけに何らかの責任者としてのポジションを期待されて入社することもあるかと思います。そういった方に私の気をつけていることが参考に
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
プロダクトエンジニアとは何者か｜Niwa Takeru｜アセンド株式会社CTO
みなさん、こんにちは。物流・運送会社向けにSaaSを開発するアセンド株式会社でCTOを務めている丹羽です。今回はプロダクト志向を持つエンジニアに向けて、プロダクトエンジニアという職種についてまとめました。 プロダクトエンジニアはフロントエンド・バックエンド・デザイン、そしてあらゆる領域を越境してプロダクトのあるべき姿を構想し、優れた顧客体験を生み出します。そんな顧客課題を中心として、プロダクト志向を持って情熱的に開発するエンジニアにスポットライトを当てます。 プロダクトエンジニアという職種の出現みなさんは"プロダクトエンジニア”という職種を聞いたことはあるでしょうか。一般的なフロントエンドエンジニアやフルスタックエンジニアに比べると聞き馴染みはない一方で、開発の中心にプロダクトの価値追求を置くエンジニアを指すといえばしっくりくる方も多いと思います。プロダクト志向を持つエンジニアは体感的にも
成果の最大化と向き合うEM思考
2023/12/15開催のEMゆるミートアップで話した内容です。 linkや当日お話した部分、誤解を生みそうな部分に関していくつか補足を書いておきます。 - p5~p11 補足: EMは会社や事業、チームの状況によって、求められることが違うので、弊社のプロダクトや自分の立場についてお話しています。それを踏まえて資料を御覧ください。 - p13 link: HIGH OUTPUT MANAGEMENT - p17 link: LayerX羅針盤 - p19 link: 相互理解の重要性と、促進するためのワークショップのご紹介 #LayerXテックアドカレ -p23 補足: 委譲度は、図解真ん中の「同意する」がちょうど合議で決めるラインで、それより左はMgrが意思決定している状態で、右がメンバーに委譲して意思決定している状態です。徐々に右に進み、委譲度が大きくなるように意識しています。メンバー
ファシリテーションするときの心構え｜asato
こんにちは！asatoです！ 毎日寒いですが、道産子として内地で暖房などつけてなるものかと日々耐え忍んでます。 知人に「ファシリテーションってどうやるんですか？」と聞かれて、「noteにまとめてみますね」と言ってからもうどれくらい経ったでしょうか。さすがに良くないと思いましたので、書きます。笑 きっとスキル的なことを聞かれたのかなと思いますが、それは考え方や原則の上に成り立つものなので、心構えでも振り返って答えたことにします。 この人たちが出した結論が最高僕が一番大事にしている原則はこれかなーと想います。簡単に言えば参加者を信じるってことです。 ファシリテーションが必要なミーティングというのはなぜ開かれるのでしょうか。それは多角的な視点で議論することで良い意思決定に繋げるためです。逆にそこに過不足が存在するなら結論は出にくいかもしれません。そういった過不足が存在しないかをミーティング前から
タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
「心理的安全性」はなぜ混乱を招き続けるのか | Q by Livesense
心理的安全性という概念がある。ここ十年ほどチームづくりの最重要ファクターであるともてはやされ、他方では粗雑な理解によって批判されてきた。急に人気の出たアイドルの宿命みたいなものを背負っている。 世間的なイメージがどのようなものか、少し羅列してみよう。 なんでも言える。否定されない。安心して働ける。不安がない。感情を大切にしてもらえる。あなたはあなたのままでいいと肯定される。 こうしたイメージを抱いている人もいるかもしれないが、残念ながらこれらは、心理的安全性の正しい姿からは遠くかけ離れている。ただ安心してほしいのは、こうした誤解をしている人は決して少なくないということだ。 手持ちのグーグルで「心理的安全性 誤解」と検索してみると、何ページにもわたって理解を正す記事が並んでいる。NewsPicksも、プレジデントも、朝日新聞も、Qiitaも、東洋経済も、あらゆるメディアが心理的安全性の誤解に
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
仕組みやプロセスに興味がない - ミネムラ珈琲ブログ
1on1で喋っていて気づいたこと。 ぼくは仕事をうまくやる上で、仕組みとかプロセスで解決することにあまり興味を持っていない。チームメンバーがそれをやってくれることに対してウェルカムだし、自分でもそういう解決をしてるんだけど、本質的には興味がない。 例えばチームにおいて1人の特殊な知識や能力で仕事がうまくいっているとする。そうするとその人がいなくなったときにどうすんのって話がよくあって、なんらか仕組みで解決しましょうってことによくなる。 が、ぼくは「別になんもやらなくてもいいんじゃん？」とか思ってしまう。仕事の回し方なんて人それぞれだ。1人の特殊なキーパーソンがいなくなったところで、残った人や新しく入ってきた人が別の特性を発揮して新しい仕事の回し方が成立するものだと思っている。なんなら過去のやり方の再現を前提に引き継ぐみたいなのは下手したら残ったチームメンバーに合わない業務を強制しかねないぐ
作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
2年以上の育休から復帰したエンジニアのその後
まずは自己紹介 私は、2018年にSansanに中途入社してSansanやEightなどのバックエンドのシステムを開発しているエンジニアです。転職前は主に Ruby on Rails でWebアプリケーションの開発をしていて、Sansanでも Ruby を主に書いてました。最近は Node.js を書いてます。 そんな私ですが、2020年1月から産休育休をいただき、2人出産して今は1歳と2歳の娘がいます。 約2年4ヶ月お休みをいただいて、晴れて今年の4月末に元々いたチームにフルタイムで復帰しました。フルタイムで復帰して半年以上経ったので、産休前と復帰後の変化や今の生活スタイルについて紹介しようと思います。 頭の中はこんな変化がありました 休職前の自分 仕事楽しーい🥳 Ruby楽しーい🥳 お酒大好き🍺週2,3飲みに行って土日は家でダラダラ 海外旅行いきたい！次どこ行こう ただただ好きな
なぜシステムエンジニアに挫折するのか - orangeitems’s diary
25年前くらいの思い出 私は業界経験が長いので、かなり挫折したシステムエンジニア、もしくはその入門者の様子を見ています。ある一定の傾向が見られるので、考えをまとめておきたいと思います。 私がIT業界に行こうと思った1996年ごろ、インターネットはまだ黎明期で、ぎりぎりパソコン通信が生き残っていました。ニフティサーブと言う最大シェアのパソコン通信は使ったことはあったものの、私が主に使ったのはMSNと言う、マイクロソフトのサービスでした。ターミナルがWindows 95に標準付属だったので物珍しさで使ってみたというのもあります。 そのMSNで笹塚茶屋（当時マイクロソフトの本社が笹塚だったことから）という掲示板がありそこに良く出入りしていました。で、私が「システムエンジニアに就職してみたいんだけどどう？」と聞いてみたところ、たくさんの返信が寄せられた記憶がありよく覚えています。 当時MSNを使う
新しい環境でバリューが出せずに悩んでいる場合の解決法｜樫田光 | Hikaru Kashida
中途での転職など、新しい環境に入った時に自分がバリューが発揮できていない、と焦ったり悩んだりした経験はないでしょうか。 この種の問題については、人によって感じ方や対処法は様々だと思いますが、少なくとも僕自身はそういった状況に大きなストレスを抱えやすい性格です。また、度合いの強弱はあれど多くの人が似たような経験を持っている、またはこれからの人生で経験するのではないかと思います。 大事なことは自分に合った対処法のゴールデンルールを持っておくこと、そして同時に自分が落ち入りがちなアンチパターン、つまり良くない思考・行動の癖などを把握しておくことです。 この記事ではそういった、「新しい環境でまだ価値を発揮できずに焦っている」というシーンにおける対処方法を、僕自身のパターンを元に書いていきます。 僕と同じような性格の方はそのまま参考にしていただければ幸いですが、自分はそう言う経験はないな、という方は
零細企業を買収した後に行ったDXとは呼べないDX｜reisaikigyou_ma
零細企業買収ですこんにちは。ちっちゃい企業を買収したあとの諸々を適当にTwitterで吐き出してきましたが、いったんまとめるとどうなるのかな、とおもて書きます。どうぞ。 経営的な話題は汎用性ないことをやりまくっているので具体的に行ったDX施策、効率化施策だけにとりあえず特化します というか今流行りのDXって要はIT化ですよね。IT化が実はおおくの中小零細で全然できてなかったからワードを変えてIT化やってるだけっすよね。この記事にDXというワード出てきますがその度に「いやそれIT化だから、きっしょ(笑)」と突っ込んでいただけると。 そもそもの買収経緯小さい企業を買収しようと思う→トランビとかで探す→安いの見つける→買う という流れでした。そこに熱い思いとか、前経営者の思いとかの引継ぎみたいなのはなく、非常に淡々としたトランザクションでしたので、熱量だけ高いうっすいウェブ記事でありそうな「買収
あなたは上位何％？ITエンジニアの年収分布まとめ【データベース完全公開】 | Forkwell Press | フォークウェルプレス
こんにちは。Forkwell の赤川です。 本記事では、2022年4月時点で Forkwell に登録するIT/Webエンジニアの匿名データのうち1万人分を分析し、年代別・経験別の年収を解説します。単なる平均年収にとどまらない、世代別の年収分布、スキル別の年収分布を詳細に出した過去に類を見ないレポートです。このレポートが、ITエンジニアの年収事情の透明性を高め、個人がキャリアを考えるうえで検討材料となること、また企業の評価が適正になるきっかけとなることを願います。なお、このレポートは個人のキャリアに貢献することを目的として執筆しておりますので、商業媒体での引用等、営利目的で利用したい場合は筆者にご相談ください。それでは見てみましょう。 ITエンジニアの世代別年収は？ 以下のグラフは、ITエンジニア全体の平均年収が世代別にどのように分かれているかを示したものです。（グラフは Googleデー
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling
テレワーク下でOJTをする際に大切にしている5つのこと
テレワーク下でOJTをする際に大切にしている５つのこと 1. 即レス Slackでの質問やレビュー依頼に早く応えます。回答でなくともいいのでまず反応をします。 テレワークのため物理的に離れてはいますが、Slack越しで会話に近いコミュニケーションができてすぐそこにいるような存在と思ってもらえるよう努めます。 レビューのスピードでいえば、レビューにかかる時間はその人の仕事のスピード、生産性に直結しますし、またその時間が長くかかることでコードレビューが面倒なプロセスに覚えてしまうかもしれません。 2. Issueから始める GitHub Issue上でタスクを管理し作業や試行錯誤の記録をすることで、課題をよりうまく解決できるように訓練されます。 解くべき問題を見極め、Issueとして切り出し、明確なタスクとゴールに向かって集中でき、また記録を残すことで複数人で意思決定の情報や同じコンテキストを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
