47AgDragon(しるどら)運命の悪魔好評発売中 @47AgD 「コツを教えて下さい」 「基礎」 「だからそうじゃなくてコツを」 「基礎」 「基礎なんてそんな誰でもわかってるものじゃなくて」 「うるせえ黙れ基礎がわかってねえから困ってんだろ基礎が最適化された最善最短ルートのコツだから達人がみんな同じこと言うし全員に学ばせんだよわかれ」 文月葵 @Fuduki_Aoi これ ・基礎ができてないくせに、基礎は完璧だと思い込んでるマン ・基礎を省略できる方法があるはずで基礎からやるのはコスパ悪いマン がいてなおさらめんどくさい twitter.com/47AgD/status/1… きし ほだか / ナイル執行役員 事業COO @hoda_Nyle 鬼滅の刃で鱗滝さんの元で修行するシーン好きなんだよね。 途中までは基礎のイロハを教えてたけど、最終課題の手前で「教えることは無い」と伝え、炭治郎
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
私が「驚く」ようになったのは、ある学生との出会いがきっかけだった。その学生はすでに２回も卒業の機会を逃していた。卒論の時期になると大学に来なくなるから。 その学生は、何を問いかけても気のない返事。「はあ」「わかりません」意欲や能動性というものが一切欠如していた。 それまでの指導教官によると、あまりにも無気力なので仕方なく、あれをやれ、これをやれと指示を出すのだけど指示以下のことしかできず、しかも来なくなるのでお手上げだったという。私は、能動性、意欲を取り戻さないと話にならないと思い、まずはそれらを取り戻すことから始めることにした。 とある実験結果を示し、「これ、何か気づいたことある？」と尋ねた。「わかりません」という無気力な返事。しかしそれは織り込み済みなので「うん、僕もわからない。何しろ僕も初めて目にする結果だから。分からない者同士、気づいたことをともかく列挙してみよう。ここはどうなって
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
皆さんこんにちは！ 最近、猫様をお迎えし最高な毎日を過ごしていております、塩対応のしおりん（@jamgodtree）です。 はじめに 私はログラスのエンジニアチームにて、2022年8月からリーダーを半年経験してきました。 この記事では、チームパフォーマンスの最大化に向けて行動してきたこと・失敗談について書いていきます。 タイトルにもあるように、私は受身気質であり、先頭を走っていくタイプのリーダーではありません。 その上で、以下のような悩みがある方に読んでもらえると幸いです。 リーダーになる前に何をやったらいいのかわからない人 リーダーになりたてでどうしようか同じように悩んでいる人 また、ログラスに興味がある方も是非参考にしてみてください。 ログラスにおけるリーダーとは? ログラスにおいてリーダーは 「役割」 として定義されています。 「上司」と「部下」ではなく、フラットな関係性を指している
世間一般ではデザイナーは一括りに語られがちですが、デザイナーも千差万別、一人一人に個性があり、異なる価値観を持っています。この多種多様なデザイナーを一種類にまとめて扱うことは、デザイナーとのミスマッチに繋がり、デザイナーを擁する組織のマネジメントにとって、深刻な問題を引き起こすこともあります。 自分自身は経営者兼デザイナーとして仕事をし、今まで多くのデザイナーを見てきました。その私の経験則でいえば、デザイナーは大きく4つのタイプに分類できると考えています。例えば採用面接などで新たにデザイナーと出会った際には、まずはこの4タイプを手がかりにして、その方の理解を深めていったりします。 私が考えるデザイナーの4つのタイプとは、縦軸に「挑戦的」「保守的」、横軸に「感覚的」「論理的」を置いた4象限で表現できます。以下がその図です。 ここからは、理想実現型、成果追求型、共同作業型、実務遂行型の順に、そ
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
こんにちは！サグーワークスの開発リーダーをやっている池添（写真右奥）です！ この記事は ウィルゲート Advent Calendar 2019 - Qiita の3日目の記事です。 昨日は @cocoeyes02 の PHPカンファレンス 2019 に、ウィルゲートのエンジニアが登壇しました！ #phpcon でした。 ばりばりコードを書くエンジニアからマネジメント寄りなリーダーの役割に変わり１年ほど経ったので今までの学んできたことを元に今、僕が気をつけていることをまとめたいと思います。 少しでもエンジニアからマネジメント職を目指している人の助けになればと思います。 リーダー以前のバックグラウンド リーダーに対する想い 気をつけていること 1. 開発 原則自分の開発稼働は工数として勘定しない エンジニアとしてワクワクするか 2. 対事業・対プロダクト 同じ課題を解決する仲間になる 方法を知
blog.tinect.jp プロジェクトマネージャーの話らしく、抽象的な課題を具体的に落とし込むことができればそれだけで食っていける。転職の際はそこを強くアピールしたほうがいい。その能力を積むには実践と経験しかない。それはそのとおりかと。 でもこの記事には他に 「タスクをきちんと落とし込める人材が少ない。育たない。面接採用でもその能力は見抜けない。」というふわっとした課題がそこに発生している。主題ではないとしても「実践と経験つむしかない」は課題解決として弱い。 この記事で理想的な人は元スクエニCTO 橋本善久 が思い浮かぶ。 ロンチ大失敗したFF14を1から作り直した大黒柱の一人。 下のプレゼンは様々なタスク管理をコントロールする術が書かれている。 http://www.jp.square-enix.com/tech/openconference/library/2011/dldata/
ちょくちょく自省します。 皆さん、報連相してますか？ないし、されてますか？新入社員の時に口酸っぱく言われましたよね、報連相。ポパイかよって感じでした。 例えば、自分のタスクの進捗状況、あるいは進捗の不調を上司に共有することは大事です。 リスクを早め早めに共有することも重要ですし、課題について手が打てる内に上司に相談することも大変重要です。 「進捗ダメです」なら、ちゃんと「進捗ダメです」と言わないといけません。 リスクを自分ひとりで抱えていることは、その人にとっての不利益にもなります。 リスクを報告していれば「言ったやん」と言えるところを、リスクを共有していなければ「なんでこんなことになるまで一人で抱えこんでたんや」という話になる。リスクを報告することは、責任を移転することでもある。 だから、報連相は「プロジェクトの為」でもなく「会社の為」でもなく、なにより「自分の為」である。 うん、いや、
いろいろな会社で仕事をしていると、「ケアレスミスをする人」「同じミスを繰り返す人」に結構な割合で遭遇する。 やれるのにやらない、わかっていてもできない、大事なことを忘れる、そのような行動を繰り返す彼らに付けられる名前は無慈悲そのものだ。 すなわち、「無能」である。 そして、世間は無能には極めて厳しい。 ハーバード大学公衆衛生学のアトゥール・ガワンデ氏は次のように表現する。 私たちは、そのような「無能」の失敗に対しては感情的になってしまいがちだ。 「無知」による失敗は許せる。何がベストなのかわかっていない場合は、懸命に頑張ってくれれば私たちは満足できる。 しかし、知識があるにもかかわらず、それが正しく活用されてないと聞くと、私たちは憤慨せずにはいられない。 氏の述べる通り、「知っているのにやらない」時や、「わかっていてミスをした」時には、組織はミスをした人物に非常に冷酷な仕打ちをする。 叱責
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
最近ベイスターズが強くて毎日が楽しいクラウドワークスの安西です。マネージャー的なお仕事をやらせていただいております。やっていることはこんな感じです。 社内もそうなのですが、社外の各社さんに聞いても、エンジニアがマネージャーをやりたがらないという事案が発生しているようで、空前のエンジニアリングマネージャー不足であると勝手に認識しています（当社比）。 ということで、メンバーの力も借りつつ、なぜエンジニアはマネージャーをやりたがらないのかを考えてみました。 マネジメントとは？ そもそもマネジメントとは何なのでしょうか？検索すると様々な解釈が出てきます。それぞれ微妙に違ったりしますね。 d.hatena.ne.jp 【management】経営、管理。 目標、目的を達成するために必要な要素を分析し、成功するために手を打つこと。 ビジネスにおけるマネージメントに必要な要素 1.目標、目的を明確化する
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
