タグ

managementに関するikosinのブックマーク (8)

  • 越境する開発

    パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へHironori Washizaki

    越境する開発
  • 辞めたくなる会社 | mediologic

    mediologic my thoughts on media/communication/marketing and everyday life. Search Primary menu 以前にいた会社の、自分がいた組織の離職者率が増えているのを聞いていると、それまで「働きたい会社」だったのが「辞めたくなる会社」になってきているということなのだろう、ということに悲しくなる。 ベンチャー的な気質をもった会社だと、「この会社、このプロダクトを使って何かをしてやろう」というチャレンジャーが集まり、その“志”がエンジンとなって前進していくものだが、あるタイミングからその会社がメジャーになってしまうと「入りたい会社」となってしまい、学歴だけよかったり、対して仕事ができないのに過去の会社での経歴を“華麗に言う”人間が増えてしまう。つまり実力者が入ってこない。またそういう傾向になると、「マネージャー」

  • はじめての開発マネージャーの教科書

    昔、はじめての課長の教科書を読んで、「中間管理職大変だなー」というのとともに、「中間管理職も必要なんだよなー」と思ったのですが、理想の開発マネージャーってどんなのかなぁとよく考えます。今日はそんな試行錯誤の日々について書いてみます。 楽しい仕事を創る 世の中には「つまらない」と感じる作業があると思います。僕の場合は、アジェンダ確認するだけのMTGに参加するのが当に苦手。段取りの悪い作業に参加するのも当に苦手。 つまらなそうな仕事をいかに「つまる仕事」にするか?これはマネージャーに問われる資質なのではないでしょうか。 開発の場合だと、定形業務とかは自動化したりツール化することができます。そのときに、チャレンジ要素を盛り込むと「つまる仕事」になったりする。過去にやったのが 完全チケット駆動開発で、最新開発環境を駆使し音速開発大会 最新版のRailsを使ってツールをアジャイルに作れ! 技術

    はじめての開発マネージャーの教科書
    ikosin
    ikosin 2013/04/20
    雑用の自動化
  • プロジェクトを円滑に回すには 島国大和のド畜生

    色々バタバタしてる最中に、twitterで呟いたらわりと反響があった言葉。 個人的にプロジェクトを円滑に回す仕組みに重要なのは『直接手を動かさない人は最大1名』『ブレない為に権力は一極集中』『問題点を早期に洗い出す為に、チーム単位+偉い人で高頻度レビュー』辺りだと思っている。正直たったコレだけの事を実行するのが組織の中では難しい。 組織にもっとも不要な人というのは『批評家』なのだが、『批評家のポジションは居心地が良すぎる(作業がない、責任がない、口だけでいい)ので、隙あらば誰もがそこに向かう』そして、組織にとっての重しになる。これがプロジェクトで手を動かさない人が増える理由の一つ。 当に能力のある人でも、ある分野では見当違いな批評家になるというのは良くあることなので(意識無意識にかかわらず)だからこそ、発言に責任を伴うかどうかが重要。 とにかく、プロジェクトを船にたとえると。 1.船頭が

  • プロジェクトファシリテーション実践編:朝会ガイド

    プロジェクトファシリテーション実践編:朝会ガイド Copyright (c) 2005-2016 Eiwa System Management, Inc. Object Club Kenji Hiranabe / Masaru Amano 1/17 プロジェクトファシリテーション 実践編 朝会ガイド (株)永和システムマネジメント オブラブ 平鍋健児 / 天野勝 Ver1.5 2005 年 3 月 2 日 Ver1.8 2013 年 1 月 10 日 Ver1.9 2013 年 6 月 14 日 Ver1.10 2016 年 3 月 1 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下で提供し ています。このライセンスについて詳しくは、 http://crea

  • 父親に聞いた管理職として「ダメなチームをデキるチームにする必勝パターン」 - komagataのブログ

    もう定年してますが、郵便局の管理職歴うん十年の父親に社会人の大後輩として、 「管理職としてダメなチームをデキるチームにする必勝パターンみたいなのってあるの?」 と聞いたら 「あるよ」 とあっさり。その話が面白かったので紹介します。 背景父親は郵便局員で公務員だった。郵政民営化する前の話。公務員は一般企業と違い犯罪でも犯さない限り首にならない。(管理の難易度が高い)郵便局の仕事は大きく「郵便」「貯金」「保険」の3つに分かれている。父親は「保険」のセールスマンの管理職を長年やっていた。郵便局の管理職は3年(?)毎に別の局(調布市郵便局とか)に移動する。 1. 新しい職場(チーム)に赴任したらそこの中心人物の協力を取り付ける中心人物:顔役的な人で大抵が年長者やリーダー気質の人。どこの組織にも必ずいて、誰にでもすぐに分かるそうです。(役職的には自分より下の人です。) 父「誰に聞いても山田(仮)さん

  • WBS は、作業分解構造ではないのよ。 - haradakiro's blog

    ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb

    WBS は、作業分解構造ではないのよ。 - haradakiro's blog
  • フロー(ZONE)理論を活用したチームビルディングの考え方 : LINE Corporation ディレクターブログ

    こんにちは、佐々木です。 今回、ディレクターブログ編集部から「チームビルティングについてなんか書いて」というリクエストをもらいましたので、プロダクトマネージャーとして意識している「フロー(ZONE)理論を活用したチームビルディングの考え方」というのをまとめてみたいと思います。 まずこの「フロー」という言葉ですが、Wikipediaによるとこういう意味だそうです。 人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴づけられ、完全にのめり込んでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう(ZONE、ピークエクスペリエンスとも呼ばれる) フロー - Wikipedia スポーツ選手のインタビューなんかを読んでいると、よくこういう話が出てきますね。野球選手が「ボールが止まって見える」とかいうのも、これにあたるんじゃないかと思います。ではこの

    フロー(ZONE)理論を活用したチームビルディングの考え方 : LINE Corporation ディレクターブログ
  • 1