状況報告、報告を受ける側が知りたいのは尽きるところ「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」というところです - Magnolia Tech
自分が気をつけていることに「今この状況を説明して」って言われた時に2分くらいにポイントを絞って話せるように常時準備しておく、というのが有って、これができるとだいぶ印象が違います 仕事で報告を求める人が最優先で知りたいのは「ヤバいか、ヤバくないか、アクションするのは俺か、お前か」です— magnoliak🍧 (@magnolia_k_) 2024年3月3日 繰り返し言ってるけど、状況報告、報告を受ける側が知りたいのは尽きるところ「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」というところです— magnoliak🍧 (@magnolia_k_) 2024年4月11日 振り返ると定期的に同じことを書いているんですけど、「報告を受ける側」が期待することって、「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」を素早く判断して、行動に起こすための情報が欲しいわけです
「心理的安全性」をバリューに掲げたけど、ほぼ効果がなかった話｜藤田 雄一郎
今回は、組織づくりについての話。 現在うちの会社は７期目で、メンバーは業務委託の方を含めると100人近くになりました。 おかげさまで退職率も低く「みんないい表情で働いてますね」と言っていただくことも増えました。心理的安全性も高く、「組織をよくするために自ら積極的に動く」というカルチャーが醸成されていると自負しています。 ただ、ずっと平和でいい感じだったのかというと、そんなことはありません。当初、組織づくりはめちゃくちゃ大変で、起業して最初の２〜３年はずっと組織のことで悩んでいました。 そんな状態から、どうやって今のようになったのか？ 同じように組織づくりに悩んでいる人のヒントになればと思い、僕の経験を書いてみたいと思います。 「お前やれるのか？」みたいな空気感初期の頃、オフィスはシーンとしていて緊張感がありました。 プロフェッショナリティのすごく高い人たちが集まっていて「俺はこんだけやるけ
“細かすぎるリソース管理”が「いかにメンバーに空きを作らせないか」という思考の原因になる プロジェクトマネージャーが陥りがちなアンチパターン回避法
アンチパターンその2 「細かすぎるリソース管理」 西郷智史氏：アンチパターンの2つ目は、細かすぎるリソース管理です。先ほど、計画の時にもリソースというキーワードが出ましたが、みなさんはリソースの管理をどのようにしているでしょうか？ よくあるのが、日単位・時間単位でリソースの負荷調整を詳細に行うこと。IT業界でよくやっています。「何にどれぐらいの時間を使ったの？」と後で集計して、この人は設計や会議、管理などにどれぐらいの時間を使っているのか、そういった細かい管理をするケースがあると思います。 （スライドを示して）「Let's Check」の1つ目を見てください。例えば、「Aさんは、Xというプロジェクトに0.5、Yに0.3、それ以外に0.2の割合でアサイン」と、小数点を用いてリソース負荷を管理しているケースはないですか？ マネージャーはよくこのようなことになりがちです。 あとは、すべての負荷が
「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない｜柴田史郎
ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」＞「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ（解決策わからない） では詳細を書いていく。 勝手に学ぶ人：自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人
プロジェクトマネジメント手法 vs 絶対にどうにかする覚悟 - ミネムラ珈琲ブログ
WEBサービス開発みたいな界隈でもう5年マネージャー業をしているので、おそらく人並みにはプロジェクトマネジメントの手法に触れてきている。実際やってきたこともあれば、やってはいないが事例やテクニックとして知っていることも含む。*1 そうやって過ごしてきたが、結局プロジェクトマネジメント手法よりも絶対にどうにかする覚悟、つまり精神論の方が重要だという個人的な結論に至っている。 どんなに精緻に工数とリスクを見積もって振り返りを繰り返しても、「まあ遅れてもいいや」という空気ではプロジェクトは遅延し続ける。逆に見積もりが雑でも「どうにかする覚悟」さえあればなんとか目標とした期日に間に合う。 もちろん覚悟と精神論でやっていると残業が常態化して炎上と言って差し支えない状態になるのだが、覚悟がなくて遅延したプロジェクトも最終的に炎上としか言いようのない状態になるので、同じ炎上なら期日に間に合っている方がマ
「マネージャー不要」という人いますけど、大抵の人はマネージャーが管理してくれないと仕事ができないんです。
ホーム > 「マネージャー不要」という人いますけど、大抵の人はマネージャーが管理してくれないと仕事ができないんです。 こんな記事を拝読しました。 どう考えてもマネージャなんて不要だからそれで上手くいくなんて期待しない方がいい 色んなマネージャがいる。何をやる仕事だろうか？役に立ってる？要らないだろ？って話をまとめたい。 別段批判という訳ではないんですが、思ったことを書きます。 私はシステム関係の仕事をしておりますので、この話を「一般的なシステム開発におけるマネージャーの仕事」の話として解釈してみます。 数人から十数人程度のメンバーが、それぞれ細分化されたタスクを割り振られて、当該タスクの達成を日々のミッションとして働いている現場と、その現場をまとめているマネージャーを想定しましょう。 で、そのマネージャーが不要かどうか、と考えます。 web上で「マネージャー不要論」というものを目にする機会
どう考えてもマネージャなんて不要だからそれで上手くいくなんて期待しない方がいい
色んなマネージャがいる。何をやる仕事だろうか？役に立ってる？要らないだろ？って話をまとめたい。 チームを助けるどうやって？1on1でお互いの理解を深めていく？ 皆さん知らないかもしれないが、この世界は実は、売上とそれを支える進捗が救いなんだ。進捗の源泉はアーキテクチャでありドメインモデリングでありシステム設計者だ。マネージャではない。 経営方針を伝えるそんなもん、直で伝える方が絶対にいい。伝え方が上手くないならなおさらだよ、早めに経験値を稼ごう。 チームメンバはでかいビジョンは理解してるけど、具体的なアクションが見えないかもしれない。伝わってるか否かを観察して、次はもっと上手くやろう。マネージャの出る幕はない。 人事評価をする人事評価はお互いの納得が最低条件であり、丁寧にやらないといけない。マネージャは納得させることができるだろうか？ 元エンジニアのマネージャなら、しばらくは保つかもね。で
「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
マネジメントとエンジニアリングの両立が難しいのはなぜか？のたとえ話 - 文字っぽいの。
与太話です。 数ヶ月前、マネジメントをしながらメイン機能の開発をしていたら完全にタスクがオーバーフローして大変なことになったんですよ。 その時に「両立が難しいのは分かったが、なぜ両立が難しいんだろうか。」をひたすら考えていたら思いついた「たとえ話」です。 素潜り漁師と漁船で例えます。 エンジニアリングは素潜り漁 コードを書いているときは集中して潜りきらないといけない エンジニアが割り込みを嫌うのはこのため 途中で呼び止められたら潜水をやめて浮上しないといけない 割り込みが終わったらまた潜り始める 難しい機能を作る時ほど深く潜らないといけないというイメージ 深さと釣果には相関がないので深ければ大漁というわけではない ただ、深い漁場は素人の素潜り漁師が到達できないので、漁場が荒らされていなくて釣果が期待できる 浅めの場所を複数箇所どんどん潜って数を稼ぐタイプがいる フルスタックエンジニアみたい
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
long_time_work_cannot_finish_tasks
先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい？ 困ったことはない？」と尋ねられ、 僕は即座に「すごく楽しいですよ。日本で働いていた会社とは大違いです」と答えた。 「日本では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日本の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか？」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる
Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 - プログラマの思索
Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et
稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から
多くの製造業においては、工場の稼働率が、重要な管理指標として今も使われている。3週間前のエントリ「原価の秘密 － なぜ、黒字案件だけを選別受注すると赤字に陥るのか 」（2014/07/06）でも説明したように、製品の個別原価を計算する際、材料費や労務費などの他に、製造機械の使用時間に応じた費用を含めるのが普通だ。その製品の加工作業で、製造機械が何時間必要だったかをベースに、機械のコストをチャージする。いわば“機械の使用料”だ。 個別の機械1時間あたりの使用料単価を『機械賃率』と呼ぶが、これは各機械の年間の維持費用（減価償却費等）を、年間の実稼働時間で割って計算する。機械の遊んでいる時間が多いほど、実稼働時間は減るから、同じ作業をしていても原価が上がる、というのがふつうの会計の仕組みだ。だから、製造業では稼働率を上げるべく、あれこれと努力するという訳である。 そして、前回のエントリを読まれた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
