「強いチームの作り方」という記事を WEB+DB PRESS Vol 83 に書きました
が、ブログのURLが含まれていることに気がつきまして、最新エントリがさすがに去年のままだとまずかろうと。
WEB+DB Press Vol.83は先週の金曜日発売でした。
内容についての紹介は、共著のryuzeeがもう書いてくれたので、割愛して、こちらでは、ちょっとその背景みたいなものを書いてみようと思います。
仕事がら、コンサルタント、コーチまたはトレーナーなどとして、いろいろなチームに伺うことが多いのですが、こういう立場で呼ばれるということは、いろいろと問題があることが多いのですね。
ご依頼の内容の通りの問題があるときももちろんあるのですが、よく見受けられるのは、問題そのものを議論の対象にすること自体を怖れているという状況です。問題があることはわかっているが、それに触れてしまうと、もっと大きな問題を引き起こしそうで、みんな触りたがらないという状態ですね。
そうなってしまうと、どう解きほぐしていくかは、状況に依ります。対策にあたるメンバーを変えるようなことが必要なこともあります。
でも、そういうことになるまえに、ちょっと練習をしておくだけで、そういう状況に陥ることが避けられるようになりますし、大きな問題に接したときも、怖れずに議論できるようになります。この特集では、そういうときに役立ちそうな考え方、プラクティス、ワークショップなどを入れてみたつもりです。どうだったでしょうか?ぜひ、お読みになったご感想をお知らせください。
- 作者: 原田騎郎,吉羽龍太郎,山口陽平,青木雅弥,松下誠太,三宅英明,高橋征義,南川毅文,伊藤直也,海野弘成,高安洋輝,佐藤歩,泉水翔吾,佐藤太一,横江直輔,舘野祐一,橋本翔,渡邊恵太,中島聡,はまちや2,小沢邦雄,長沢智治,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2014/10/24
- メディア: 大型本
- この商品を含むブログを見る
あと、ご紹介したバルンガ、改善ゲーム、星取表などのワークショップは、どこかで体験できる機会を設けられるといいですね。ぜひご遠慮なく、ご相談ください。
Barnga: A Simulation Game on Cultural Clashes (25th Anniversary Edition)
- 作者: Sivasailam Thiagarakan,Raja Thiagarajan
- 出版社/メーカー: Intercultural Pr
- 発売日: 2006/05/15
- メディア: ペーパーバック
- この商品を含むブログを見る
2013のコミュニティ活動のまとめ
今年も暮れてきましたが、今年のコミュニティ活動についてまとめておく予定地。
発表スライドとか、イベントサイトとかへのリンクを足していきます。
こう眺めると、けっこういろいろやってますね。
また来年もいろいろやると思いますので、一緒に連れて行け、やってみたい、なにか手伝ってほしいなど、何かできることがあれば、ご遠慮なくお知らせください。
よろしくお願いします。
今年の活動履歴
日付 | 場所 | イベント | 活動 |
---|---|---|---|
1/7-11 | Kihei | ScrumPLoP mini | Writer |
1/15-16 | 東京 | Scrum Gathering Tokyo 2013 | Talk / Organizer |
2/22 | 横浜 | Agile Samurai横浜道場番外編 | Workshop |
3/4-6 | HCMC | 3 Days of Lean and Kaizen | Sponsor |
3/19 | 名古屋 | DevLOVE 名古屋 準備会 | Agitator |
4/23 | 東京 | QCon Tokyo 2013 | Talk "DDD-Scrum" |
4/24 | 東京 | DDD/Scrum Workshop | Workshop |
4/27 | 大阪 | XP祭り関西 | Talk |
5/2-24 | Tisvildeleje | ScrumPLoP 2013 | PLoP |
5/28-29 | Zurich | Scrum in Manufacturing | Trouble Maker |
6/12 | 神戸 | Lego Scrum Kobe | Host |
7/3-5 | 上海 | Scrum Gathering 上海 | Talk |
7/13 | 仙台 | レッツゴーデベロッパー変真 | Workshop |
7/20 | 大阪 | TDD for embedded C | Workshop |
8/19 | マラケシュ | アフリカ上陸 | Strayer |
8/31 | 岡山 | TDD BC 岡山 2.0 | Participant / LT Talker |
9/11-12 | 東京 | ソフトウェア品質シンポジウム2013 / SQiP | Tutorial |
9/20 | 神戸 | DevSumi 関西 | Talk x 2 |
9/21 | 大阪 | Scrum Boot Camp 大阪 | Trainer |
9/23-27 | HCMC | Agile Retreat 2013 | Coach |
10/5 | 大阪 | Agile Tour Osaka 2013 | Organizer/Interpreter |
10/26 | 大阪 | DDD/Scrum Workshop with SEA | Workshop |
11/1 | 仙台 | DDD/Scrum Workshop mini | Workshop |
11/3 | 石巻 | ツール・ド・東北 | Rider |
11/7 | HCMC | DDD/Scrum Workshop in Ho Chi Minh City | Workshop |
11/8-9 | HCMC | Agile Tour Ho Chi Minh City | Talkx2/Workshop |
11/10 | Hanoi | Agile Tour Hanoi | Talk/Workshop |
12/8 | Honolulu | Honolulu Marathon | Runner |
12/14 | 神戸 | Global Day of Coderetreat in Kobe 2013 | Facilitator |
Mike Beedle 氏の認定スクラムマスタ研修を開催します。
来年の年始、1/14-15に開催されるRegional Scrum Gathering Tokyo 2014に、Mike Beedle氏がキーノートスピーカーとして来日します。
その来日に合わせて、1/9-10 と 1/16-17 に Mike氏による認定スクラムマスタ研修を開催します。詳細資料はこちら。
Mike Beedle 氏は、スクラムを作った Jeff Sutherland / Ken Schwaber 以外で、初めてスクラムを適用した人です。しかも、スクラムの説明にあるように小さなチームからのスタートではなく、トラブルに陥った200名を超えるプロジェクトを立てなおすためにスクラムが使われました。
氏の研修は、Enterprise Scrum (企業のためのスクラム)となっています。
ソフトウェアに限らず、さまざまなビジネスがいかにアジャイル・リーンという方向性に向いてきたかを解き明かしながら、どうやってスクラムを活用したらよいかという面を中心とした内容となっています。その中で、どうやってアジャイルマニフェストが、”アジャイル”という言葉を選んだのかが解き明かされます。これまで、あまりアジャイル開発向きではないと思われていた業界、業務で、どのようにスクラムを活用するかというプラクティスは、今の日本のソフトウェア業界でも参考になることが多いと思われます。
また、最近ふたたび注目をあびつつあるパターンランゲージが、どうスクラムの成立と発展に寄与したかを知ることができるのも興味深いと思われます。最近、翻訳された「組織パターン」と、野中・竹内氏の論文、そしてリーンがどのよう組み合わさってスクラムが生まれ、さらにビジネスにおけるパターンを産み出してきたかが語られます。
今回、2回の認定スクラムマスタ研修を行いますが、1回目は同時通訳無しで行います(テキストは、日英対訳のものを用意します)。逐次の翻訳は行いませんが、必要に応じて私が通訳支援をしますので、ぜひ英語の練習も兼ねて参加していただけるとよろしいかと思います。
それでは、ご参加をお待ちしております。
開催概要
- 日付: 2014年1月9日〜10日 2日間
- 時間: 10:00 〜 18:00 (各日)
- 同時通訳無し(トレーニングは英語で実施します)
- 開催場所: 豆蔵トレーニングルーム
- 〒163-0715 東京都新宿区西新宿二丁目7番1号 小田急第一生命ビル15階
- 価格: 18万円(税込み)
- 主催: Enterprise Scrum
- 共催: 株式会社アトラクタ
- 申込先: http://www.scrumalliance.org/courses-events/courses/csm/japan/shinjuku/2014/january/20135495-certified-scrummaster
- 問合先: info [at] attractor-inc.jp
- 日付: 2014年1月16日〜17日 2日間
- 時間: 10:00 〜 18:00 (各日)
- 同時通訳有り
- 開催場所: 株式会社 VOYAGE GROUP 会議室パンゲア
- 〒150-0045 東京都渋谷区神泉町8-16 渋谷ファーストプレイス8F
- 価格: 20万円(税込み)
- 主催: Enterprise Scrum
- 共催: 株式会社アトラクタ
- 申込先: http://www.scrumalliance.org/courses-events/courses/csm/japan/tokyo/2014/january/20135496-certified-scrummaster
- 問合先: info [at] attractor-inc.jp
スクラムチームの最悪の敵に対処する
寒くなってきましたね。
この前の記事が暑い話だったのは、いつの話ですかね。
で、今回は、スクラムチームの最悪の敵の話です。
まあ、プロダクト開発をぐるぐる続けられているなら、魑魅魍魎ステークホルダーともうまくつきあえるようになっているでしょう。
でも、怖い敵はいるのです。
インフルエンザ
寒くなってくると、そろそろと流行りはじめます。
チームメンバーの誰かが、敵の手に落ちます。敵もさることながら、いきなりは攻撃してきません。ちょっとだるいなとか、頭が重いなくらいの感覚です。
でもプロジェクトは進めないといけませんから、がんばって出社します。最近の風邪薬は強力ですから、多少の熱、咳くらいはコントロールできます。熱が下がったのでデイリースクラムに参加します。プランニングポーカーでエキサイトすることもあるでしょう。
はい、これでチームは敵の手に落ちてしまいました。しばらくすると、みんな感染します。フロア全体に蔓延したりします。あれれ、今回のスプリントどこまでやるんだったっけ?多少のベロシティ変化がぶっとぶくらいのダメージです。
改善しましょう。
- チームで予防接種を受けましょう。
- ちょっとでも体調がすぐれなかったら、出社せずに様子をみましょう(あなたは敵の手に落ちた生物テロ兵器になってるかもしれません)
- リモートワークの練習をしましょう。
それでは、みなさまお大事に。
次回のふりかえりのときに、ぜひ話し合ってみてくださいな。
追記(2013/11/14 16:40):
具合の悪そうなのがデイリースクラムにいるのを見つけた時は、そいつをつまみ出して、適切な治療を受けさせるのはスクラムマスターの仕事です。咳こみながらデイリースクラムにでるんじゃありませんよ。
P.S.
筆者は神戸在住なので、数年前の新型インフルエンザのときは、しばらくクライアント先に行かず閉じこもってました。なかなか手強いです。
がんばるあなたがプロジェクトを殺す
あまりに暑いのでちょっと怪談を。
今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。
投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。
しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)のところに相談がいく。
彼は、たいてい最後まで残業している。メンバーがみんな帰っても、「あとちょっと」と言いながら、最後まで残っている。メンバーは、「彼があんなにがんばっているんだから、私もあれくらいは、、、」と思っている。
本人に聞くと、「私ががんばらないと、このプロジェクトはまずいので、」と必ず返ってくる。彼は、時々朝まで仕事をしていることがある。プロジェクトレビューがあったりするときとか、部内の進捗会議がある日とかね。ドキュメントをチェックして、誤字を直したり、テスト環境のデータベースパスワードが間違っているのを修正したり、進捗資料の画面ハードコピーを取り直したり、、、
そう彼はとても真面目でプロジェクトのために身を粉にして働いている。プロジェクトの問題を修正し続けている。みんな彼を頼りにしている。
で、壊れる。プロジェクトまたは彼自身が。「または」はプログラマの OR だからね。どっちも壊れることもある。
で、どちらかが壊れたとき、プロジェクトを安全に元に戻すことはできない。プロジェクトが抱える多くの問題は、彼しか直せないからだ。彼が直せなくなったとき、プロジェクトはどうしようもなくなる。
これが怪談なのは、誰も悪意を持っていないところだ。彼はプロジェクトを助けるために働き、皆もそれに感謝した。結果、プロジェクトが破綻に近づいた。
この状況に問題があるとすると一点だけ。彼がプロジェクトメンバーが学習する機会を奪ったという点だけだ。自分が作ったドキュメント、コード、デモ、プレゼンテーションのどこに不具合があるかを知ることができなければ、次によくすることもできない。
少しは、涼しくなっただろうか。怖くなったらみんなでビールを飲みに行くのがいいんじゃないかな。
よい夏休みを。
ぐるぐる DDD/Scrum というワークショップをやってきました
東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。
ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。
正直、1時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。
ただ、1時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。
参加された方は、各チームの発表したモデルの中心(コアドメイン)が、どれも一致していないことに気づかれたかと思います。どんなビジネスをやりたいかによって、同じドメインでも、どこをコア、サポート、一般サブドメインにするかは異なります。駐車場みたいに、比較的簡単なドメインでさえそうです。
ぜひ、みなさんのプロジェクトでも、プロジェクトを始めるときに、あるいは途中でも、そしてできればプロジェクトの間中ずっと DDD/Scrum のぐるぐるをやってもらえればと思います。
ご質問などありましたら、ご遠慮なくご連絡ください。
P.S. いやー、仙台、涼しくて、食べ物おいしくて、参加者が元気で、すばらしいです。また、おじゃましたいと思います。
「プロジェクトが成功するためならなんでもする」と考えておけば十分か
まあ、大人げないと思いつつ。いろいろ考えるのですよ。
というわけでアジャイルに不慣れな受託のマネージャー向けに。
「プロジェクトが成功するためならなんでもする」
まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。
で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか?職務経歴書お送りしますよ。」だ。
あうち。
ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。
ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける。
プロセスも一緒で、どこのプロセスでも「なんでもやりますよ」をやると、小学生のサッカーみたいになる。見たことあるでしょ、流行のバズワードのプラクティスは全部やってるように見えて、実際には何も役に立っていないような現場を(テストカバレッジが100%だけど、アサーションが一行もないとか)。
私は、
- 無駄とわかっていることを、さらに続けることを無駄という
- 改善とは、成果の量と品質と保ちつつ、やることを減らすことである
という立場だ。
でも、どうやって無駄を認識して、取り除いていくか?また、より良いプロセスを試行するか。それを変えにくい(依存しやすい)プロセスとして入れておく必要があるだろう。
プロセスが生み出した結果(プロダクト)とプロセスを定期的にふりかえり、やめること、次に試すことを決めることだ。スクラムだと、スプリントレビューとレトロスペクティブを必ず固定のタイムボックスにいれるというところだな。「なんでもやる」という姿勢を続けるための安定した基盤としては、今のところ有効なメタプロセスであると自身では思っている。
ただ、そこで止まっているわけではないよ。最近名前を聞くようになってきた、Kanban というプロセスでは(ところで日本語訳はまだ出ないのかなぁ?)、タイムボックスが改善の妨げになると主張している。バッチを小さくするのに飽き足らずフローでの開発に取り組むという野心的な取り組みだ。うまくいく例、いかない例が報告され、だんだん知見が蓄積されていくのではないかな。楽しみだ。
P.S.
うーん、でも職業アジャイラーって何だろう?