懇親会付きのイベントに出没する迷惑な人対策の一考察｜wakatono
自分がとあるイベントあわせでやったこと。 トリガは以下の記事の公開および、記事の内容に関連する各種レポート。 IT系コミュニティをタダ飯狙いの不審者からどう守るべきか。あるイベントで発生した深刻な事案と提言 － Publickey (publickey1.jp) 若手が相当おそれて課題提起してくれたこともあり、大きいところは自分のほうで巻き取って対応。過去に別のところでやってるし、（手慣れてるとは言わないけど）うごくせきぞう状態の自分がやったほうが良いと判断して対応。 以下、対応の流れをおおまかに。 運営関係者間で対応を協議の上、大きな方針をまとめる課題提起を受けて、イベントの運営側で協議を行い、大きな方針をまとめる。この方針の中で、会場および管轄の警察署との連携を強化することを確定。そしてこの中で、主担当者（今回の場合はオレ）をあらためて決定。 今回立てた方針は、以下の2つ。 不審なのが
50人ほどの小規模なコミュニティを運営する時、どういうタイプのメンバーをケアすべきなのかという話に共感集まる「ネトゲのギルドあるある」
ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ガジェット・IT系書いてる。今年から3年ほどの人生目標は「10年後にかっこいいババアになる」です。 「おたばぶ」のばぶの方。相棒のおたよりさん（ @otayori_otbb ） 飯テロがライフワーク。ネトゲもする。 Amazonのリンクは全部アソシエイト。 sampo-note.net ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ネトゲで50人ほどの小規模コミュニティを運用してたときの話。メンバーは大体5つに分類できて。 1）挨拶や呼び掛け、提案を積極的にしてくれる人 2）上記に割と乗ってくれ、発言も多い人 3）名指しで声掛けしたりお膳立てしないと乗らない人 4）とりあえずラジオにしてる人 5）空気 3～5はどう働きかけても、なにをしても、コミュニティに対して積極性を持ってはくれなかった。 ただ、4～5は別
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
「説得力がTwitterとは段違いだった」Twitterでボロクソ言われてる人のマネジメント研修の内容が非常にタメになる
中田:‖ @paddy_joy 今日のマネジメント研修はめちゃくちゃ良かった。Twitterではボロクソに言われてる人が講師だったのでむしろネタにしてやろうくらいの気持ちで受けたんだけれども説得力がTwitterとは段違いだった。発信する場によってこれくらい印象が変わること自体が一つのケーススタディーになりそう。 2023-03-08 17:09:03 中田:‖ @paddy_joy 「"心理的安全性"は部下の立場でしか語られないのが大きな問題。「指摘したら部下が落ち込むんじゃないか」「指導をしたらパワハラ扱いじゃないか」などと心配するのは上司の側の心理的安全性が脅かされている。ダメなものはダメだと上司が躊躇なく言えなければその組織も強くならない」 2023-03-08 17:14:14 中田:‖ @paddy_joy ↑この前段に、「部下が上司に指摘できない組織は死ぬ」というデータがいく
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
管理職のための役職引退マニュアル | DevelopersIO
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
SQUARE ENIX OPEN CONFERENCEゲーム開発プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
プロジェクト未経験でPM試験に合格した勉強ノートを晒す - Qiita
はじめに 当時の状況 エンジニア2年目。運用エンジニアの経験のみ。 プロジェクトが常に忙しかったが、常に忙しい状況というのはおかしい、と思っていた マネジメントを学びがてら、プロジェクトマネージャ試験を受験 勉強期間は1ヶ月。仕事は炎上中。 プロジェクトマネージャ試験の概要(Wikipediaより) 情報処理技術者試験の一区分である。<中略>高度情報処理技術者試験に含まれる。 高度情報処理技術者試験の最難関として名高い 論文課題形式 (の問題がある※) 当時の勉強時間や、利用した参考書など詳しいことは以前ブログに書いたのでそちらを参照されたし 経緯 部屋の整理をしていたら、プロジェクトマネージャ試験の勉強ノートが見つかりました。全部で13ページです。 思ったよりも短かく、ちょうどいい分量だった(?)ので、参考になる人がいるかもと思って公開します。 筆記対策 p1. マインドツリーでざっくり
「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Meetup Osaka 2020-02-05
Rakus Meetup Osaka #5 の発表資料です。 https://rakus.connpass.com/event/182082/
【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
【EOF2019資料公開】社員100人規模のWebサービスにおけるエンジニアリングマネジメント - BASEプロダクトチームブログ
こんにちは！BASE株式会社の藤川（えふしん）です。 2019年10月31日開催されたEOF2019 (Engineering Organization Festival 2019)というエンジニアのチームマネジメントに携わる人達のイベントに、スポンサーとして参加すると共に登壇してまいりました。 こちらが当日の発表資料になります。 2019/10/31 BASE社発表資料 - EOF2019 from 真一 藤川 プレゼンテーションの目的としては、エンジニアのマネジメント業務はクリエイティブな仕事であり、エンジニアリングの延長線上でしかないんだよ！ということを知って欲しい。その結果として、エンジニアリングマネージャに挑戦する人を増やしたいというものです。 なお、BASE株式会社に僕がCTOとしてジョインした時には、すでにエンジニアが何人かいる状態でした。一応、BASE創業直後から技術顧問と
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
(翻訳) エンジニアとマネージャの振り子 - ふしみのブログ
"The Engineer/Manager Pendulum" というブログ記事を筆者の許可を得て翻訳してみました。 最近、Twitter上で何人かのキャリア相談に乗ることがあった。多くの相談はこんな調子だった。 わたしは現在シニアエンジニアで、マネージャになろうと思っている。自分は技術が大好きなのだ。でも、ときどき自分は同じ問題を繰り返し繰り返し解決しているような気がしてしまう。ほんとうに解決すべきなのはヒトの問題 (people problems) なんじゃないか? 昇進するためにはマネージャになる必要があることは知ってる。マネージャになるのは最悪じゃなきゃいいなと思っている。悪い噂ばかり聞くから。 キャリア相談に乗りながら、この記事を書きたいとずっと思うようになった。言いたいことはたくさんあるが、最初に言いたいのは 「マネージャだけがキャリアパスを前に進むことができる」という考えはク
仕事ができる人ほど、できない人に優しく振る舞うのは、マネジメントの定石。
昔、ある会社の営業MTGで、忘れられないやりとりがあった。 少々詳しく描写すると、出席者は以下の通り。 ・役員（部長） ・リーダー ・メンバー 7名のメンバーの能力は各々、高、高、中、中、中、中、低。 二人ぐらい優秀な人物がいて、一人「できない人」が混ざっているイメージだ。 また、役員とリーダーは切れ者で、部下の報告の論理矛盾やダメな点にはすぐに気づく。 さて、こんな状況で来期の「営業計画」について、MTGが開催された。このMTGの議長はリーダーだ。 リーダーはテキパキと議事を進める。 来期の営業部の方針に始まり、具体的な目標設定、個人の役割など、メンバーへの指示も簡潔でわかりやすい。 ここまではなんの問題もなかった。 だが、今年一年を振り返っての営業報告が始まると、雰囲気が変わった。 無理もない。メンバーの一人ひとりが、自分の過去の実績と、これからの具体的行動を発表しているのだから、緊張
全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ
自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです？ とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
心理的安全性ゲームをやってみよう
