プロダクトオーナーが知っておくべき、チームやステークホルダーとの付き合い方、価値やリスクマネジメントの考え方を紹介しています。 PO祭り2016(2016年11月26日)での基調講演の資料です。
研究成果によれば、「群れ」で思考すれば高度な知性を発揮する場合がある。だが、どう実践に移せばいいのか。チームを組んで仕事をするとき、どのようにメンバーを構成し、リーダーは何を心がければいいのか。「群れ」が陥りがちな危険を脱し、チームで成功するための具体的な方法論を探った(前編はこちら)。 みんなで失敗を回避しようとすると大失敗へ… チームワークを高めようとするときに、いちばん難しいのが、どうやってメンバー同士の共同作業を進めるか、というところだ。これがうまくいかないと、チームが破綻してしまう。 各メンバーは、それぞれ無数の偏見や思い込みを持っている。多彩な顔ぶれを揃えれば、それぞれの偏見が打ち消されるのではないかと期待する人もいるだろう。だが、チームで共同作業をしていると、かえってこうした偏見が強化されることも珍しくない。 そのせいで、少ないデータから過度な一般化をしたり、コントロールでき
みなさんこんにちは。@ryuzeeです。 2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。 その中でスクラムでよく起こる問題やその原因・対策に関するセッションを行いましたので資料を公開いたします。 アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。 それでは。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお
はじめに 今更ながらTeam Geekを読んでみたら良かったので、個人的に学びが多いと思った箇所をアンチパターンの形でまとめてみました。自分でやってしまった失敗に関係する内容がメインですが、メンバーとして嫌だなと思っていた部分もあります。 いくばくかのリーダー経験を経て(大半は失敗)、チームで結果を出す難しさと大切さを知った時期に、このような良書に出会えたことを感謝しつつ書きました。現在進行形でリーダーとしての働き方に悩まれている方や、これからリーダーになる方の一助となれば、そしてTeamGeekを手に取るきっかけとなれば幸いです。 内容について 冒頭にも書きましたが、以下すべて "アンチ" パターンです。(真似しちゃダメってやつですね) アンチパターンをやってしまうときのリーダーの頭の中を再現して書いてみました。(構成は自分の経験によって再編成しているのでTeamGeekのそれとは少し異
この記事は Sansan Advent Calendar 2016 - Qiita の代理記事です。年は明けてしまっていますが、残った枠が出ていたので埋めておこうかなと。 ここで話すこと 私が所属する部門で初めて技術基盤チームを置いたことの背景や、活動について 技術基盤チームを置いたことで、初めてチームが分割された時に起こったこと 弊社には運営するサービス + αの開発部門が存在するため、あくまでそのうちの一つの部門の話になります。 どういう部門の技術基盤チームか 所属する開発部門はエンジニアが入れ替わりはあれど 10 名程度所属しています。(インフラエンジニアさんは別に 2 名所属しています) 運営するサービスは足掛けでいうとおそらく運営開始からは 3 から 4 年経っていると思います。 私自身はその開発部門には 3 年程前から部署異動で参加しており、サービスの運営開始から半年から 1
新しい組織は「階層構造」から「共同体」になり、リーダーは「ファシリテーター」となる 共創し学習する新しい組織論:第2回 組織論の領域でも、これまでにコラボレーションを促進し、経験からの学びを活かす組織のあり方は研究されてきた。これらの研究では、旧来の階層構造とは異なる「共同体(community)」として組織を捉え直す研究が展開されている。前回のコラムの流れを受け、第2回のコラムでは、「実践の共同体(community of practice)」と「協働する共同体(collaborative community)」という二つの共同体についての議論を紹介し、「コラボレーションの促進」と「経験からの学び」がどのように可能となるのかを考えていきたい。 組織をプロセスではなく、「実践の共同体(community of practice)」として捉える 1990年代にマイケル・ハマーとジェームス・チ
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
はじめに 本記事は、他人の書いたソフトウェアのバグに遭遇したときにどうするかという流れを、実例を基にして、ストーリー仕立てでなるべく具体的に書きました。このようなときの対処に不慣れな人に、実際のデバッグ、バグレポート、および修正案の提出までの流れを掴んでもらうことが目的です。 バグに遭遇 筆者も参加していたLinux Advent Calendar 2016に、ある日シェルスクリプト(Bash)で作るTwitterクライアントという記事が投稿されました。twitter APIの認証に使われているOAuth1.0aとshell芸に興味があったことより、この記事を読んでみることにしました。 そこで紹介されているtweet.shというbash製twitterクライアントを試そうとしたところ、出力は次のようになりました。 いきなり何かがおかしいです。自分のtwitterアカウントに関するJSON形
この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと
これは feedforce Advent Calendar 2016 の19日目です。ひとつ前は mizukmb の わたしのGit/GitHubの使い方 でした。冒頭の写真、HKKBにカタカナのテプラが貼ってあるだけで「これは偽物なのかな?」と思わせる雰囲気が私は好きです。 さて私は、社内で書籍 チームが機能するとはどういうことか の読書会を社長や取締役から現場のエンジニアまで、様々な役職/職種の人で集まって開催していることについてお伝えしたいと思います。ちなみに本の内容についてはほとんど触れませんのでご了承ください。 経緯など 読書会を開催する前の状況は以下のような感じでした。 個人として本は持っているが内容はつまみ食いした程度 心理的安全性や「許可より謝罪」は理解している 新人エンジニアがSlackで「すみません」とか前置きしようものなら、先輩が「謝らなくていいんだよ」とフォローして
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした! それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう!」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN
2016 - 11 - 13 PM理論で考える、理想のリーダー像とは?って話 自分のこと 日常 たまには仕事関係の話でも書こうかな。 タイトルだけ見れば、やけにお固いタイトルだけど、オレが書いてるブログだからね、固くなるわけないよな。 柔らかい内容なんで、興味のある方は読んでみてくださいな。 毎週の初めに ミーティング やら行ってるんだけど、ちょうど、この話が出たんで書いてみるけどね。 理想のリーダー像 とは・・・ こんな事なんだよね 、ってノリで書いてみるぞ。 今、三つ仕事を持ってるんだけど、 事務系人材派遣の会社 、 進学塾 、 某生命保険の代理店 ・・・。 決めてることが有って・・・ 強いリーダーシップ! これは、オレの 背骨 だな。これがないと、 わざわざ自分で商売やってる意味ない って思ってるからな。 と言っても、仕事に限らず学校とか地域の活動やサークルなんかでも、何かしら組織っ
Help us understand the problem. What is going on with this article? 会社で働いていると、運用チームからの問い合わせがあると思います。 問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。 Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。 常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。 問い合わせが多くて辛みを味わっている方の参考になれば。 概要 Web自社サービス タスク管理ツール Redmine 毎日、5枚ほどチケットが増える 運用と開発がそれぞれ20人ほど こんな環境です。 改善のきっかけ うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。 窓口の人がチケットを解決したり、有識者にチケットを委譲した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く