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 以外で、初めてスクラムを適用した人です。しかも、スクラムの説明にあるように小さなチームからのスタートではなく、トラブルに陥った２００名を超えるプロジェクトを立てなおすためにスクラムが使われました。

 

氏の研修は、Enterprise Scrum (企業のためのスクラム)となっています。

ソフトウェアに限らず、さまざまなビジネスがいかにアジャイル・リーンという方向性に向いてきたかを解き明かしながら、どうやってスクラムを活用したらよいかという面を中心とした内容となっています。その中で、どうやってアジャイルマニフェストが、”アジャイル”という言葉を選んだのかが解き明かされます。これまで、あまりアジャイル開発向きではないと思われていた業界、業務で、どのようにスクラムを活用するかというプラクティスは、今の日本のソフトウェア業界でも参考になることが多いと思われます。

 

また、最近ふたたび注目をあびつつあるパターンランゲージが、どうスクラムの成立と発展に寄与したかを知ることができるのも興味深いと思われます。最近、翻訳された「組織パターン」と、野中・竹内氏の論文、そしてリーンがどのよう組み合わさってスクラムが生まれ、さらにビジネスにおけるパターンを産み出してきたかが語られます。

 

今回、２回の認定スクラムマスタ研修を行いますが、１回目は同時通訳無しで行います(テキストは、日英対訳のものを用意します)。逐次の翻訳は行いませんが、必要に応じて私が通訳支援をしますので、ぜひ英語の練習も兼ねて参加していただけるとよろしいかと思います。

 

それでは、ご参加をお待ちしております。

 

開催概要

f:id:haradakiro:20131126130711g:plain

 

 

f:id:haradakiro:20131126130724g:plain

 

スクラムチームの最悪の敵に対処する

寒くなってきましたね。

この前の記事が暑い話だったのは、いつの話ですかね。

 

で、今回は、スクラムチームの最悪の敵の話です。

まあ、プロダクト開発をぐるぐる続けられているなら、魑魅魍魎ステークホルダーともうまくつきあえるようになっているでしょう。

 

でも、怖い敵はいるのです。

 

 

 

 

インフルエンザ

 

寒くなってくると、そろそろと流行りはじめます。

 

チームメンバーの誰かが、敵の手に落ちます。敵もさることながら、いきなりは攻撃してきません。ちょっとだるいなとか、頭が重いなくらいの感覚です。

 

でもプロジェクトは進めないといけませんから、がんばって出社します。最近の風邪薬は強力ですから、多少の熱、咳くらいはコントロールできます。熱が下がったのでデイリースクラムに参加します。プランニングポーカーでエキサイトすることもあるでしょう。

 

はい、これでチームは敵の手に落ちてしまいました。しばらくすると、みんな感染します。フロア全体に蔓延したりします。あれれ、今回のスプリントどこまでやるんだったっけ？多少のベロシティ変化がぶっとぶくらいのダメージです。

 

改善しましょう。 

  • チームで予防接種を受けましょう。
  •  ちょっとでも体調がすぐれなかったら、出社せずに様子をみましょう（あなたは敵の手に落ちた生物テロ兵器になってるかもしれません）
  • リモートワークの練習をしましょう。

それでは、みなさまお大事に。

次回のふりかえりのときに、ぜひ話し合ってみてくださいな。

 

追記(2013/11/14 16:40):

具合の悪そうなのがデイリースクラムにいるのを見つけた時は、そいつをつまみ出して、適切な治療を受けさせるのはスクラムマスターの仕事です。咳こみながらデイリースクラムにでるんじゃありませんよ。

 

 

P.S.

筆者は神戸在住なので、数年前の新型インフルエンザのときは、しばらくクライアント先に行かず閉じこもってました。なかなか手強いです。 

 

がんばるあなたがプロジェクトを殺す

あまりに暑いのでちょっと怪談を。

 

今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。

 

投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。

 

しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)のところに相談がいく。

 

彼は、たいてい最後まで残業している。メンバーがみんな帰っても、「あとちょっと」と言いながら、最後まで残っている。メンバーは、「彼があんなにがんばっているんだから、私もあれくらいは、、、」と思っている。

 

本人に聞くと、「私ががんばらないと、このプロジェクトはまずいので、」と必ず返ってくる。彼は、時々朝まで仕事をしていることがある。プロジェクトレビューがあったりするときとか、部内の進捗会議がある日とかね。ドキュメントをチェックして、誤字を直したり、テスト環境のデータベースパスワードが間違っているのを修正したり、進捗資料の画面ハードコピーを取り直したり、、、

 

そう彼はとても真面目でプロジェクトのために身を粉にして働いている。プロジェクトの問題を修正し続けている。みんな彼を頼りにしている。

 

で、壊れる。プロジェクトまたは彼自身が。「または」はプログラマの OR だからね。どっちも壊れることもある。

 

で、どちらかが壊れたとき、プロジェクトを安全に元に戻すことはできない。プロジェクトが抱える多くの問題は、彼しか直せないからだ。彼が直せなくなったとき、プロジェクトはどうしようもなくなる。

 

これが怪談なのは、誰も悪意を持っていないところだ。彼はプロジェクトを助けるために働き、皆もそれに感謝した。結果、プロジェクトが破綻に近づいた。

 

この状況に問題があるとすると一点だけ。彼がプロジェクトメンバーが学習する機会を奪ったという点だけだ。自分が作ったドキュメント、コード、デモ、プレゼンテーションのどこに不具合があるかを知ることができなければ、次によくすることもできない。

 

少しは、涼しくなっただろうか。怖くなったらみんなでビールを飲みに行くのがいいんじゃないかな。

 

よい夏休みを。

 

 

 

 

 

 

 

 

 

ぐるぐる DDD/Scrum というワークショップをやってきました

東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。

 

ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。

 

正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。

 

ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。

 

参加された方は、各チームの発表したモデルの中心(コアドメイン)が、どれも一致していないことに気づかれたかと思います。どんなビジネスをやりたいかによって、同じドメインでも、どこをコア、サポート、一般サブドメインにするかは異なります。駐車場みたいに、比較的簡単なドメインでさえそうです。

 

ぜひ、みなさんのプロジェクトでも、プロジェクトを始めるときに、あるいは途中でも、そしてできればプロジェクトの間中ずっと DDD/Scrum のぐるぐるをやってもらえればと思います。

 

ご質問などありましたら、ご遠慮なくご連絡ください。 

 

 

 
で、こんなワークショップが成立したのは、何より強力な講師陣がいたからですね。増田さん(@masuda220)、和智さん(@digitalsoul0124)、井上さん(@i_takehiro)、ありがとうございました。
 
また、イベントを企画した運営された東北デベロッパーズコミュニティの皆様、ありがとうございました。
 

P.S. いやー、仙台、涼しくて、食べ物おいしくて、参加者が元気で、すばらしいです。また、おじゃましたいと思います。

 

「プロジェクトが成功するためならなんでもする」と考えておけば十分か

まあ、大人げないと思いつつ。いろいろ考えるのですよ。

というわけでアジャイルに不慣れな受託のマネージャー向けに。

 

「プロジェクトが成功するためならなんでもする」

まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。

で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか？職務経歴書お送りしますよ。」だ。

あうち。

ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。

ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける。

プロセスも一緒で、どこのプロセスでも「なんでもやりますよ」をやると、小学生のサッカーみたいになる。見たことあるでしょ、流行のバズワードのプラクティスは全部やってるように見えて、実際には何も役に立っていないような現場を(テストカバレッジが100%だけど、アサーションが一行もないとか)。

私は、

  • 無駄とわかっていることを、さらに続けることを無駄という
  • 改善とは、成果の量と品質と保ちつつ、やることを減らすことである

という立場だ。

でも、どうやって無駄を認識して、取り除いていくか？また、より良いプロセスを試行するか。それを変えにくい(依存しやすい)プロセスとして入れておく必要があるだろう。

プロセスが生み出した結果(プロダクト)とプロセスを定期的にふりかえり、やめること、次に試すことを決めることだ。スクラムだと、スプリントレビューとレトロスペクティブを必ず固定のタイムボックスにいれるというところだな。「なんでもやる」という姿勢を続けるための安定した基盤としては、今のところ有効なメタプロセスであると自身では思っている。

ただ、そこで止まっているわけではないよ。最近名前を聞くようになってきた、Kanban というプロセスでは(ところで日本語訳はまだ出ないのかなぁ？)、タイムボックスが改善の妨げになると主張している。バッチを小さくするのに飽き足らずフローでの開発に取り組むという野心的な取り組みだ。うまくいく例、いかない例が報告され、だんだん知見が蓄積されていくのではないかな。楽しみだ。

 

P.S.

うーん、でも職業アジャイラーって何だろう？

 

アジャイルがそんなにダメだと思わない7つの理由

鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。

 

1. 全体スケジュールにコミットできない 

コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。

全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。

全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。

  • 全体は全体ではない。あなたの見えている範囲にすぎない。それが十分でなかったら拡張しなければならない。計画の実施を優先して、全体の範囲の確認を怠るとどうなるかは、たくさんの事例があるだろう。想定外は言い訳にならない。
  • 計画はあたらない。どんだけの努力を払ったところで、計画が必ずあたるということはない。それを素直に認めることだ。それでも計画を当てようとする努力を怠るわけではない。

 Plans are useless but planning is indispensable.

 

2. アーキテクチャ上の無駄が生じる

 無駄をわかっていることを、さらに続けることを無駄という。あとで無駄とわかったから、それは避けられたというか？それを避けていたら、もっと大きい無駄を見逃すことにならないか。

 Twitter が最初から Scala にしていたら、作り直しの無駄は避けられたか？避けられたかもしれない、でも今の Twitter の隆盛もなかったかもしれない。

 

3. コーチって何だよ

これは痛い。かといって、成果に連携した契約にする気もない。

おむつを変える気もないけどね。自分のケツは自分で拭け。

それでも、コーチがいたほうがいいと思う。別にコーチでなくてもいい。エンジニアのチームの中のコミットメントに参加しない部外者が。

卑怯な話であるのは認める。でも、私がコーチで現場の近くにいて一番気にしているのは、自分より優秀なエンジニアを過労で失う経験はもうしたくない、ということだ。

優秀なエンジニアは本当に優秀だ。びっくりする。でも、優秀であるが故に、自分の負荷が見えていない人が多い。優秀なエンジニアは、自分のタコメーターが壊れていることに気がつかない。気がつかないから、優秀なのかもしれない。

そこを見える第三者がプロジェクトの近くにいるのは、必要なことだと考えている。

 

4. 変化ヲ抱擁スルために固定化している

すべてを変化しやすくすることはできない。人間が耐えられる変化の量はきっと、これまでもいまからも大してかわらない。それでも変化ヲ包容スルためには、変化しないところと、変化しやすいところを読んで賭けるよりない。それがアーキテクティングだろう。

変化を包容するために、集団もしくはチームの維持にアーキテクチャを賭けるのは、筋の悪い選択だとは思わない。伊勢神宮の式年遷宮が今年も可能なのは、建物ではなく宮大工の集団に永続性を見いだしたからだ。

蛇足かもしれないが、ソフトウェアの成果物に重力が働かないことは、ソフトウェアの変化の量を読むのをものすごく難しくしている。重力の働かない場所で、今の建築技術はどこまで使えるんだろう。

 

5.実証主義的な説明に過ぎない

その通り。すべてのベストプラクティスは過去のプラクティスである。次にうまくいく保証はない。

いい人材がいれば成功するだろう。そのとおり。でも、いい人材をどうやって見いだすんだい？どうやって伯楽が育つんだい？それこそ実証的にやっていくよりないだろう。

 

6.手段が目的になっている

まあ、その通り。それでビジネスにはならないし、すべきでもない。

でも、初期には手段を目的にして練習してもいいんじゃないかな。野球を練習するとき、プロで勝つことを目的にはしないでしょ。純粋にキャッチボールやバットで打つのが楽しい。入り口はそこでいい。でも、プロになるには、それだけでは無理という話は矛盾しない。

まあ、「アジャイルで開発したいんだけど、、、」という依頼が来たときは、大抵断ってますけどね。

 

7.アジリティはアジャイルだけのものではない

特定のプロセスにこだわるのは、アジャイルだとは思わない。必要ならプロセスも変えればいいのだ。実証的に。

1980年代ウォーターフォールの形式化に貢献した、アメリカ国防省(DoD)が今何をやっているかご存知だろうか？

 これが、DoD 傘下の Command and Control Research Program の最新の研究成果である。

 

 

The Agility Advantage: A Survival Guide For Complex Enterprise and Endaevors

「アジリティの優位性: 複雑な企業と作戦のサバイバルガイド」

 

これが、アジリティということだろう。

 

 

WBS は、作業分解構造ではないのよ。

ちょっと大人数で行うプロジェクトに参加したことがある人なら、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 は、成果物のことだ。Workbench (ワークベンチ)、Workshop(ワークショップ)、WIP(ワークインプログレス)で使われるのと同じ意味で、作業の対象となるモノのことだ。WBS の性質をいちばん的確に表しているのは、"Plan Outcomes, Not Actions" 「成果を計画せよ、作業を計画するな」である。

 

WBS を作業計画に使うと何が起こるかを検討してみよう。例題は、例によってキャンプで作るカレーライスである。

 

作業ベースで WBS を作成すると、一番上の項目はこんなふうになるだろう。

  • カレールーを作る
  • 飯盒でご飯を炊く

 

成果物ベースで WBS を作ると、こうなる

  • 温かいカレールー
  • 温かいご飯

 

キャンプでの作業であるから、とうぜん失敗することもある。カレールーは失敗することはあんまりないだろうが、ご飯は焦げたり、生煮えだったり、いろいろ失敗する。

 

失敗したとき WBS をつかって、どう挽回できるだろうか。作業ベースでつくってしまうと、「ご飯を炊くのは４０分遅れですが挽回できます」しかない。成果物ベースの場合は、サトウのごはんという挽回策がある :)

 

WBS を使ったプロジェクトが、おいしいカレーを食べられることを祈る。