Jonathan Strauss – Team awe.sm いろんな役割や責任が世の中にはある。それらは会社によってそれぞれ違ったりするけれど、だいたいどういった役割であって、どういった責任を持っているのかを整理してみようと思う。 チームや組織に登場する人たち iOSエンジニアといった人たちは、わりかしわかりやすいので割愛して、 何をやっているのかわかりにくかったり、人によってやってることが違ったり、呼び方が違ったりする部分を中心に整理。経験則中心でまとめるけど、スクラム周りはスクラムガイドを読むのが一番いい。 プロダクトオーナー（省略形：PO、別名：プロダクトマネージャ）説明呼び方がオーナーだったりマネージャだったりするのでややこしいやつ。個人的にはどっちかにしてほしいプロダクトバックログが責任の中心にある役割プロダクトバックログアイテムを明確に表現するゴールとミッションを達成できるよ

最近知り合った方がプロセス改善にとても詳しかったので、どこでそんな勉強したのかを聞いてみました。すると、その人の上司が元トヨタのエリート社員で、「改善って言う前にこの本を読め！」と12冊オススメされたそう。どれも面白い本だったので、読んだ感想をそえてまとめてみます。 トヨタ生産方式 導入の奥義 「トヨタ式最強図解」だけあって、A3一枚にまとめるトヨタメソッドで各ページ紹介されています。製造業じゃない僕でもよくわかりました。 「こういうことがあってこうした」という、著者の経験が語られている部分が一番面白く、トヨタの改善マインドが、長い年月をかけて練られてきたものだと改めて感じました。 リンク： トヨタ生産方式 導入の奥義 トコトンやさしいコストダウンの本 コスト削減がメインの本。工場の話なんだけど何かとヒントになる事例が詰まっています。表紙を見ると「大丈夫か・・・この豚さん・・・」って思うか

採用関係の勉強がてら、Webサービス開発をしている企業の、採用案内を調べたり比べたりしていてふと思いました。たまに見かける「Java開発経験年数3年以上」などの表記。これは応募者のスキルチェックに使っているのかなぁと思うのですが、全然意味なさそうです。 経験年数 ＝ 実力とはいえない 仕事内容やその人のモチベーションにもよりますが、経験年数が多いほど実力が高いわけではありません。たとえば、 なんとなくこの業界に入って、なんとなく過ごしている人の3年 プログラミングが大好きで、休日も自前のアプリ開発に熱中している意識高い系の3年 は、多分「厚み」が違うはず。かといって「経験年数ゼロでも歓迎！」なわけではありません。 こう考えてみると、経験年数がその人を評価するときの「ものさし」として、ふさわしくない気がするんです。 職務経歴書もあてにならない そもそも、経験年数のような自己申告型の情報だけで

今週のゴールデンウィーク明けから育休中です。よってこのブログはしばらく育児日記や生活の知恵日記となる可能性があります。 育休を決めたわけ 娘が生まれたのがゴールデンウィーク前だったので、有給を使うだけで結構な期間を休めました。ただ、 はじめての子育て がんばった嫁や子供と一緒の時間を過ごしたい ついでに自分の人生を見つめなおそう と思い、育休をとることを決意しました。幸いなことに社内でも男子の育休が増えてきているそうで、上司や同僚も協力的でとても感謝しています。良い会社で働けて、よい仲間がいてよかった。 平成24年度雇用均等基本調査によると、女性の育児休業者割合が83.6%に対して、男性は1.89％とのこと。これだけ取られない制度だとむしろ取りたくなる。 一方で、育児休業制度の有無を見てみると、事業所規模5人以上では72.4％、事業所規模30人以上では 94.2％と結構高い。育休が不必要な

少し前にマネージャ層にアジャイル開発事例を話す機会がありました。皆さん「アジャイル」という言葉に抵抗があるようです。さてさてどうやって伝えたらいいものか。発表資料を作りながら悩んだことをここに書いておこうを思います。 アジャイルを語ると胡散臭い 前にもちょっと書いたんですが、アジャイル開発を話す人は胡散臭いです。 たとえば、アジャイルサムライの著者をお呼びしてトレーニングをしたときに思ったんですが、本のファン以外の人にトレーニングの価値を伝えにくかった感触がありました。おそらく「有識者」と名乗る見ず知らずの人（しかも外国人）の話を「信じてください」には無理があるんでしょう。 そのほかにも、別の誰かの話をしだす人は胡散臭いです（海外では〜、○○社では〜、書籍には〜）。これはリーンソフトウェア開発の提唱者メアリー・ポッペンディークさんの本が顕著です。すぐに3Mの話をしだすし具体的な要素が少ない

gemmoth via frickr 最近、「いいチームだなー」っていうのと「残念なチームだなー」っていうのを同時期に見ることがありました。どちらもアジャイル開発に取り組んでいたりしたので、残念な方を「うんこアジャイル」と名づけ、原因と対策を後輩といろいろ話しました。 よくある「うんこアジャイル」 思いつく限りの共通点を挙げてみましょう。 教科書通りのアジャイル開発を当てはめようとしている メンバーの性格に問題があるように感じてしまう 自分がやっていることが正しいか自信がない トレーニングや認定試験を重視する このへんの「不安」は『リーン開発の現場 監訳者まえがき』も参考になるかと思います。共通点だけ読むと「ああ、なんかつらそうだな」って思うのですが、後輩がこんなことを言ってました。 ちょっとうんこだろうと行動した分、失敗してもそこからまた行動しようとしている分、何も変わる気もない変える気

The Kanban Pizza Game by agile42 is licensed under the Creative Commons Attribution-Share Alike 3.0 License. agile42というサイトで紹介されている「The Kanban Pizza Game」を日本語に訳してみました。ライセンスはCreative Commons Attribution-Share Alike 3.0 Licenseになります。カンバンシステムの全体像を学べ、既存のプロセスに適用させる方法といった実践的な学びを得られそうです。 以下が意訳です。原文はThe Kanban Pizza Gameです。 カンバン・ピザ・ゲーム 講演によってリーンやアジャイルの原則を簡単に伝えることは難しいものです。通常は「どうやったらうまくいくか」を感じとるために、自分たち自身の状況

86639298@N02 via flickr 社内の承認システム、タイムカードみたいな時間を管理するシステム、運用とかのツール・・・。どこの社内にもいろんなツールが転がっている。しかしながら、まぁ使いにくい。「よく考えているなぁ」ってのはまれだ。では、なんでこうなってしまうのだろうか？ 意見を聞いたユーザが偏っている よくあるのが「マネージャの意見を聞いて」とか。こう言っちゃうと水戸黄門の印籠みたいに、平社員は文句が言いにくくなるのもポイント。錦の御旗が間違っているほどつらいものはない。 それぞれの使い方があるツールの場合、いろんな視点を考慮できないと使いにくくなる。大多数のユーザがいる場合でも、適度に分散して意見を聞き、要求としてまとめるのが大切だろう。もちろん、導入や開発する側の都合より優先すべきだ。 システムやツールを使わない人が作っている 自社システムを外部に作ってもらうとかする

1位もリーンスタートアップネタ。わずか10枚の資料が1位ってのが熱い。 6位から50位まで こうやってみるといろいろあって面白いですねぇ。スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!は自分の環境にあわせた感が素敵だし、AgileJapan2010 佐賀県庁でもできる！プロジェクトファシリテーションは、何回みても面白い熱い物語だし、「納品のない受託開発」にみるソフトウェア受託開発の未来は講演を2〜3回見ているけど、何回聞いても面白かった。 33729viewsUXのためのUIデザイン 31199viewsふつうの受託開発チームのつくりかた 28019viewsAgileJapan2010 基調講演：野中郁次郎先生による「実践知のリーダシップ～スクラムと知の場作り」 27941viewsProject Facilitation From Hiranabe

ある日、メンバーに「アジャイルコーチってどんなことを考えているんですか？」と聞かれたので、普段考えてきたことをまとめてみました。アジャイルに限らない部分もありますが、個人別のふりかえりや、朝礼やふりかえりといった普段のイベントで、メンバーに伝えてきたことが中心です。技術スキルよりも、人材育成が近いかもしれません。 ステップ1：チームに入って1ヶ月ぐらいまで 第1段階では、個人レベルでの基本動作を身につけることが中心になります。これまでの経験上、だいたい1ヶ月でクリアできる内容です。すべらない話は、ストーリーテリングの練習として。 元気にあいさつができているか？ 突然ふられても、絶対にすべらない話ができるか？ ブログを定期的に書いて、考えをまとめたり、情報発信できているか？ カンファレンス、勉強会といったイベントでコネクションを増やしたり、情報収集できているか？ 朝礼で自分のやったこと、やっ

The Gates of Hell 昔あるプロジェクトに参加していたときに、エンドユーザからこんなことを言われて「もしかしてこれが噂の絶望の扉か？」と感じたことがありました。そのときはたしか開発リーダーかなにかで受託メンバーをまとめながら開発をしてました。結構忙しかった記憶があります。 自分は2次受けにあたり、1次受けのお客さんが売り込んだシステムの開発をしていました。システムとしては「まぁ悪くない」ものだったのですが、開発が進むにつれて「ぜんぜんイケてない」状態になっていくパターンでした。そして、エンドユーザ側の担当者が代わったときに、その方がぽろっと漏らしたのがこんな言葉でした。 このシステムは前任者が考えたもので、自分は引き継いだだけだ。プロジェクトが始まってしまったので、もう止まることはできないが、これが終わったら私が再度考えて作り直したい。 まじかよー。（まじかよー、まじかよー、

永和システムマネジメントさんで開催された「第108回 DevLOVE − Play! かんばんゲーム リベンジ」に参加してきました。DevLOVEに参加するのは2010年以来ではないか！@yattomさんの「かんばんゲーム」は、ずっとやってみたかったので夢が1つかないました。 かんばんゲームのルール はじめに言葉の定義としてタスクとかを貼りつける板を「かんばん」に統一。「TODO・DOING・DONE」や「設計・開発・テスト」といったそれぞれを「ステージ」と呼んでます。 このゲームをざっくり説明すると、実際に「かんばん」を使い、タスクを消化していくゲームです。さらに「Eventカード」や「Problemカード」や「Solutionカード」がゲームを盛り上げます。 タスクにはコスト（ストーリーポイント）が書かれているので、出したサイコロの目の数だけ減っていきます。今回は1テーブル5人で、メン

最近、「会社のために外部の勉強会で発表してくれてありがとうございます」みたいに言われて、とても違和感を感じることがあった。確かに会社名を入れて発表しているけど、決して、会社のために発表しているわけではない。 今日はそのことについて書こうと思う。 発表資料を作るときに考えていたこと ちょっとこれまでの発表資料を眺めてみた。ほとんどが事例紹介なのは、やったことしか話せないからだ。また、自分は見たものしか信じないので、評論とか理論とかをまとめたり、聞いたりするのが苦手でもある。 これは、初めて海外のカンファレンスに言った時のフィードバック資料。はじめての勉強会発表だったと思う。このときは、Agile2010ですごく面白い発表があったので、その話題を中心に面白さの共有をさせていただいた。