権限を持つと人は偉そうになってしまう
最近配置転換があり、昇格してさまざまな権限を持つようになった。社内のほぼすべての書類を見ることができ、社員の管理ができ、各社員の給与を見ることのできる権限をもらい、予算の裁可権限までもらった。 権限を持つようになると「○○さんが知ってるよ」という情報をどこかから得てきた人が「お忙しいところすみません」というふうに声をかけてくるようになった。今までもそういう声かけは皆無ではなかったとはいえ、明らかに急増した。これが実に煩わしい。煩わしいので、一時しのぎの雑な対応になる。雑な対応になると「お忙しいところ申し訳ありません」というふうに声をかけられるようになる。権限がない人からすると、権限がある人になるべく早くやってもらわないと仕事が進まないのでどうしてもそうなるのだ。 そして、誰がどういう業務をやっているのかかなりハッキリ見えてくるようになった。これはすごい。まるで王様にでもなったかのような気持
エンジニアが「明日からマネジメントして」と言われたら
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
Ayo.js について - from scratch
Ayo.js とは 「Node.js の fork です。」と言ってもまだできたばかりで正直このタイミングで記事にしてもまだ語ることはそんなに多くないです。 ただし、JavaScript界隈が騒ぎになりかけていることは確かです。日本でも発言が増えてきたので自分なりにまとめて今時点での話をしようと思います。 ちなみに読み方は好きに読んでくれ、と言われてます。 「アイ・オー」でもいいし、「エイ・ヨー」でも良いとのことです。ネーミング的には昔あった io.js fork騒動を想起させるネーミングになってます。もしも io.js についてご存じない方もいるのであれば、こちらをご参照ください。 yosuke-furukawa.hatenablog.com Ayo.js の目的 https://github.com/ayojs/ayo/blob/zkat/values/VALUES.md ここを見ると
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
https://thepedia.co/article/2298/
See related links to what you are looking for.
ソニー株式会社を退職しました
表題の通り、数年勤めたソニー株式会社を退職しました。 個別具体の退職理由はいろいろあってそれらは後述しますが、退職を決めた基本的な理由は、個人的なキャリアパスの設計と会社の方針のミスマッチ、労働観のミスマッチ、技術投資の考え方のミスマッチの三点に集約できると思っています。 キャリアパスの設計と会社の方針のミスマッチ私はソニーでソフトウェアエンジニアとして働いていました。 ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達な理想工場"、エンジニアが自由に活躍できる会社、日本のメーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。 実際会社は説明会などでそういった説明をしましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」
割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2016 @8日目の記事です。 こんにちは、エンジニアのdo7beです。pixivFANBOXの開発などに携わっています。 さて、今回は新規開発プロジェクトに「割れ窓理論」を導入してサービスのクオリティ向上に繋がった話をご紹介したいと思います。 割れ窓理論とは 「割れ窓理論」とは、アメリカの犯罪学者ジョージ・ケリング氏が提唱した「建物の窓ガラスが割れたまま放置されると住民もゴミを捨てるようになり、治安が悪化し、より重大な犯罪が発生してしまう」という理論です。 つまり軽犯罪を取り締まることこそが、重大な犯罪を防ぐために重要であることを指しています。 私たちのチームではこれをWebサービスの新規開発プロジェクトに取り入れています。 WEBサービスにおける割れ窓は「軽度のデザイン崩れ」や「表記ゆれ」に、重大な犯罪は「バグ」や「全体のクオリティ低下
![割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a00de9ce0520f085a20aefec43b00295df450362/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20161208%2F20161208130750.jpg)
ダイバーシティ・マネジメント - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ダイバーシティ・マネジメント" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年4月） ダイバーシティ・マネジメント（Diversity Management）とは、個人や集団間に存在するさまざまな違い、すなわち「多様性」を競争優位の源泉として生かすために文化や制度、プログラムプラクティスなどの組織全体を変革しようとするマネジメントアプローチのことである。 特徴[編集] 多様性が企業の売り上げや発展に貢献し、競争力の源泉となるという考えに基づいている。具体的には多様性に基づくマネジメントで優位性があるとされる分野に、資源の獲得、マ
仕事ができる人が辞めてしまう9つの原因
トラヴィス・ブラッドベリー博士。シンクタンク、コンサルティング機関〈タレントスマート〉主宰・共同創立者。
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
社名変更のお知らせ
Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
｢人望がない人｣は､大体"話しすぎ"ている
いくら能力があっても、ひとりの人間には限界があります。よほどのカリスマ性がないかぎり（僕にはない）、人は無条件にはついてきません。僕がやっている監督という仕事は、人の力をどれだけ引き出すかにかかっています。では、どうやってその能力を引き出すのか？ そのコツのひとつは、「ウケる」です。 むやみに怒鳴りまくっていた、過去の僕 僕は「サラリーマンNEO」という番組の監督を務め、おかげさまでそこそこ人気番組になったのですが、その番組を始めた32歳の僕は、強烈なプレッシャーに駆られていました。 同期は局の顔的な番組であるNHKスペシャルなどを担当しているし、片や「サラリーマンNEO」は「これがNHKの番組？」と非難されること必至の番組です。だから、とにかく自分がリーダーシップをもって、現場を引っ張りまくることが必要だと、会議では自分の意見を押し通し、現場ではカメラマンを怒鳴りまくっていました。 殺伐
起業家が開発者のマネージメントで犯しやすい11の失敗 | readwrite.jp
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か？前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council （YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog
はてなCTOのid:stanakaです。 はてなアドベントカレンダー2014も最終日となりました。 今年のアドベントカレンダーは、スマートフォンアプリ開発からシステム系論文の話まで幅広いテーマが集りました。 読んでいて優秀なエンジニアがいるなぁ、としみじみ思います。 ちなみにアドベントカレンダーは25日までじゃないのか、という話がありそうですが、本来は24日までだそうです*1。 CTOとは何か論 最終日の今日は「CTOの役割と組織における技術的ポートフォリオの組み方」について考えているところを書いてみます。 最近、なぜかCTO論が盛んで、あちこちでよく耳にするようになってきています。 rebuild.fmでのnaoyaさんのマネージメント話や、WEB+DB Pressの舘野さんの連載などでもCTOやエンジニアのキャリアについての話が盛り上がっています。 つい先日でたWEB+DB Press
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
