XP祭り2014 を開催した。

XP祭り2014を開催した。大きな事故もなく終えることができたのはみなさまのご協力のたまものだ。規模が大きくなっているのに、手作り感が残っているのがよいというご意見もいただいた。スタッフは少人数でそれなりに大変なので、実行委員をやっていただける方が、ボチボチと手を上げていただけると助かる。すでに手を挙げていただいた方もいる。毎年、「初めて来ました」という方が多いのが特徴だ。数年ぶりという方もいる。気軽に来て、なにか発表してみたり、他の方からエネルギーをもらったり、相談できる仲間を見つけてかえっていただけると、うれしい。

前説の資料はこちら。なるべくコンパクトにXPの説明と、XP祭りの説明を入れることを試みてみた。
https://speakerdeck.com/kawaguti/xp-matsuri-2014

今回は、Joseph Yoder もカンファレンスに寄ってくれた上に、トークもやってくれた。今後もタイミングが合えばぜひ英語でのセッションも用意できればと思う。5分でキッチリ銅鑼を鳴らすLTの形式に興味を持ってくれて、懇親会で5分スピーチにチャレンジしてくれたのが、とてもよかった。

ありがとうございました。

ゼネコンとITゼネコンとデスマーチと工程修正

よしおかさんがざっくりいいきるときは、だいたい適当なので、突っ込んだ方が損した気になったりするものなので、適当には適当で返しておこうと思います。なのでこちらの話はとても適当ですので、突っ込まれると知識不足が露呈しますが、予めご容赦ください。

システム管理者、感謝の日イベントに参加した。 - 未来のいつか/hyoshiokの日記

どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。

建築プロジェクトではデスマーチの代わりに工期遅延が起こる

ワールドカップやオリンピックごとに、建築間に合うのか問題が起きているのは、日本じゃないから、という事なんでしょうか。うまくいってない工事というのもあり(東京青山の億ション工事で最強トリオが引き起こした前代未聞の大失敗)、そこまでいかなくても、ディテールを修正して間に合わせるという判断も起きているはず。そういう意味では、細かな要件の見送りや削減は日常茶飯事でしょう。土地図面の信頼性はあまり高くないらしいので、掘ってみないと分からないことは多いっぽいです。掘ってみたら遺跡が出てきて大幅な工期遅延ってよく聞きます。都市伝説かもしれませんが。

IT業界のゼネコンさんも同じこと言いますよね

たぶん、SIer(IT業界のゼネコンさん)も同じこと言うと思います。「うちは要件定義と調査能力に強みがあるので、発注いただいた後の工程の大きな変更は起きないですし、問題が起きてもすぐに対応していますので、デスマーチのようなことはなかなか起きないと思います。ただ、もちろん、お客様のご都合になるべくあわせ、最終的にはなんとかします。」とかとか。
実際は営業さんと付き合いがあまりないのでよく知りません。適当です。

分かってない人が出ていって約束しちゃう問題

ソフトウェア業界の問題は、従来は請け負ってこなかった分野をパワポ一つで取りにいってしまう、エンジニア経験のない営業さんが起こしている部分もあるのかもしれません。業務要件をきちんと理解し、PMBOKやITILをきちんと勉強していれば防げるたぐいの凡ミスも多いんじゃないかと推察します。エンジニアサイドで昔からよく聞く話は「営業がこんなの約束してきやがった。」です。

あ、関係ないですけど、だいぶ前に、引っ越し屋さんも同じこといってました。

そもそもエンジニア知識を持っている人が足りない問題

たぶん、日本のソフトウェア業界ではエンジニアリング知識(コンピュータサイエンスとまで言わないまでも)を持った人がすくないので、そういう人が営業することもないし、顧客やユーザーとの折衝に入っていくことも最後の手段と見られています。そんなことよりコードを生み出せ、と言われていると思います。でも実際は、エンジニア知識がない人がたくさんのムダな仕事を生んでいたりして、結局すり切れるまでエンジニアが火消ししている、なんて状況がたまにあります。ちょっとできる若いエンジニアの人からすれば、そういう時に頼られることがカタルシスだったりしますし。

あ、これ20代くらいの自分を見返して書きました。すみません。

得意分野でないとこをカジュアルに攻めちゃう問題

建設業界のゼネコンさんって得意分野が明らかで、作ったことがあるものを量産するタイプのマンション建築ではそういうのが得意なメーカーさんが優位性を持っているようです。ちょっと難しいのを中心に請け負う最先端のメーカーさんもあるみたいです(ブランドがある)。構造設計が難しい橋梁建築も、特定の会社しか受けないと聞きます。

ITゼネコンさんも以前は分野が明らかで、ノウハウの蓄積先も明瞭だったのでしょうが、そのあたりが徐々に崩れてきて、技術者もキープできなくなって...というのがここ10-20年くらいの流れではないかと思います。これはたぶん順番としてはITが早くきていて(クラウド)、徐々にモノ作りメーカーの技術者に進んできている、という感じもします(もちろんモノ作りベンチャーさんは以前からたくさんいますけれど)。

追記: 建設業における労働災害発生状況

Facebook の方で、Yoshiya Tachikawa さんに、「事柄、建設業の方と接する機会が多いのですが、結構デスマーチありますよ。分かり易い例だと工事中の事故が起きた時とか。事故だけでも年間2万件以上ありますので。」というご指摘をいただきました。ITだと精神疾患が多く判定が難しいため、労災の適用になる比率は多くないかもしれません（そういう意味では、建設業界の方が労働災害が明確に見える化されている、と言えるかもしれないですが、そんなこと分かっても誰も得しないですね）。

建設業における労働災害発生状況
http://www.kensaibou.or.jp/data/statistics_graph.html

えーっと、こういったデータを元に、建設業界とIT業界の優劣を論じる気はありません。
「ITゼネコン」という単語が正しいかどうかにも、興味はありません。

自分より長生きするソフトウェアより、自分より長生きするチーム

scrum

同僚が、
「自分より長生きするモノが作れたら、開発者としては幸せだろうね。」
と書いていた。


私も以前はそう思っていたんだけど、いつ頃からかそう思わなくなった。その「想い」によって、よいソフトウェアも、ダメなソフトウェアも生み出されるんじゃなかろうか...と考えるようになったからだろう。


ダメなソフトウェアというのは、いろいろあるが、開発者が去った後にメンテできなくなってしまったソフトウェアも、やはりダメなものだと思う。ソースコードがいかに優れていても、メンテナンス体制が組まれなくなってしまえば、徐々に利用価値を蝕んでいくようになる。実装がまともでないものは論外だが(リリース時点でだめとか、リリース前に負けてるとか)、設計も実装も当初の運用もすべてまともであっても、時が過ぎるとダメになってしまうものは、よくあるのだ。


自動車のエンジンが危険なく動き続けるためにはメンテナンスが必要で、それは少なくとも製品の寿命に等しい期間必要になる。なので、その期間存在できるチームを作る必要がある。外部の力を頼ってもそれは同じで、保守費はかかるし、バージョンアップのときに前のソフトウェアは引き継げない。


だから、本質的にはチームを小さく維持して長生きさせることと、継続的にアウトプットを出し続けるようマイルストーンとバックログを整備することが、ゾンビを生み出さない唯一の道なのではないか。


実は、ソフトウェアを必要としない状況であればゾンビも生まれないのだけれど、実際は目の前の状況は既に生まれたゾンビと新しい状況への対応で日々戦っているので、今のところソフトウェアを要求していることが多いとみている。次善の策として、複数のゾンビを処理しながら、一つの生きているソフトウェアを生み出し、それをやり続けるチームを維持する。


あと、つらいと思ったら続かないので、楽しくやる仕組みを考えるのは大事なことだと思う。

- - -

こういうことが、スクラムに出会ったときにちょうど気づいたところだったりする。
...ような気がする。

Chris Sims さんのビジネス価値見積りのゲーム - Global Scrum Gathering

scrum

Global Scrum Gathering Day1 で参加した、Chris Sims さんのビジネス価値見積りのワークショップの手順を書いてみます。Chrisさんにブログへの掲載を快諾いただきました。


背景

スクラムでは優先順位付けされたプロダクトバックログが必要だ。優先順位はROIに従うべきだろう。ROIが高いものは優先して顧客に届けたい。ROI = 価値/コスト で、コストはチームメンバーが固定である限りストーリーポイントが相当する。あとはビジネス価値がだせるといい。ビジネス価値といえば、リリースした後に得られる売上のうちその機能に属する部分だとか、その機能によって削減されるであろう手間に関する人件費の推測なんかをして、お金に換算するのが普通だ。しかし、まだ売り上げている訳でもないので、実際にはこの見積りは困難だ。しかも、ビジネス価値は"お金"だけではない。顧客の信頼を得るとか、ブランドを高めるとか、システムが安定化するとか、顧客満足が高まるとか、お金に換算しづらいものもたくさんある。

ステークホルダーの共通認識が重要

ビジネス価値の正確さ、というのはがんばって情報を集めて計算しても、所詮は推測の積み重ねなので、それほど高まっていかない。もちろん推測できなければ予算もとれなかったりするので金額は大事で、とにかく数値を出さなければ前に進めないことも多い。そして、積み上げた数字をステークホルダーに納得してもらう必要がある。

というわけで、じゃあステークホルダー参加で見積もれば、作成とフィードバックと議論を行いながら、順位付けまで全部できるじゃないの、というのがこのワークショップだ。

進め方

ワークショップの写真を十分に撮っていないので、机上で再現した(ほんとにデスクの上)。写真を追って説明してみたい。

順序付け

まずはプロダクトバックログアイテムないし機能の束がある。
Aさん、Bさん、Cさんのなかでこれらのビジネス価値を合意したい。

まず最初のカードを場に出す。
Aさんは、場のカードと、束の一番上のカードでどちらが価値が大きいかを決定する。右が価値が高いほう。

Aさん「カーペットクリーニングも大事だが、トイレを増設しないと、家族が喧嘩になるんだ。だからとても価値が高い。」

Bさんの番。次のカードを出すか、場に出ているカードを一枚動かすか、どちらかを行うことができる。

Bさん「カーペットクリーニングしないとダニとかでて病気になっちゃう。こっちの方が価値が高い」

次はCさんの番。次のカードを出すか、場に出ているカードを一枚動かすか、どちらかを行うことができる。

Cさん「キッチンに新しい機材がほしい。値段も張るし、一番価値がたかい。」

ふたたびAさんの番。２週目以降もルールは同じだ。

Aさん「やっぱりトイレが一番価値が高いと思う。よくお腹痛くなるし。」

Bさんの番

Bさん「プールですよプール。みなさんあこがれの。これは一番価値高いでしょう。」

Cさん「アメリカじゃないんだからプールは必要ないと思う。一番下に持ってく。」

ビジネス価値の見積り

ここまでで相対的な並べ替えはだいたい終わった。ここからビジネス価値を数値で見積もっていく。

まず一番左のカードの左上にマイナス(-)のカードを置く。ここからまた順番をまわしていく。数字のカードを出すか、既存のカードをずらすことができる。数字のカードはフィボナッチ数列で、まず1のカードから始まっている。

Aさん「価値がマイナスのものはなさそうだから、一番左が1かな」

Bさん「プールは価値ないので、(-)と1を右にずらしとく」

Cさん「カーペットクリーニングに対してキッチンの調理機材は倍くらい価値がありそう」

Aさん「トイレはとても価値がある。カーペットクリーニングの３倍くらいには」

Bさん「キッチンの増強とトイレの増強はおんなじくらいの価値だと思うなぁ」

という風に、多面的に議論しながらフィボナッチ数列のカードをだしていく。

すべてのカードを出し終えて、場所の変更もなくなったら、終了。
相対的にビジネス価値が見積もられ、ステークホルダーの議論も反映したリストが出来上がる。

制約

この議論に参加していない人に議論の内容を伝えることは難しい。
そのかわり、短い時間でできるので、ステークホルダーの代表に参加してもらうのがよいだろう。

謝辞

教えていただいた Chris Sims さんに感謝いたします。
Thank you!! Chris-san!

Global Scrum Gathering Day 2 の基調講演 : 音楽業界BMI社でのアジャイル適用

scrum

引き続き Global Scrum Gathering に参加している。

Day2基調講演 : BMI社でのアジャイル適用

Day 2 朝の基調講演は音楽業界の老舗 BMI 社の組織全体でのアジャイル導入事例の話。

音楽業界は大きな変化がきており、アーティストや作曲家はクラウドソースになったり、ストリーミングや権利、イベント運営などいろいろな分野で変化が起きているそうだ。

まず開発でパイロットプロジェクトでのスクラムをやってみたところ、よい結果が出た。そのあと、コードベースを統一したり、スマホ向けのレスポンシブデザイン対応のサイトを作った。

当初DAD(ディシプリンドアジャイルデリバリー)を利用して、そのあと自分たち流にアレンジしてプロセスを定義した。

で、そこから Jeff Sutherland の奥さんである Arline さんが Agile 2009で発表していた Scrum in Church (教会の慈善活動へのスクラム適用) にヒントを得て、技術系でない人たちにもスクラムを適用することにしたそうだ。先進的な副社長が「Why not？」と後押ししたらしい。やりながら、財務系のチームの完了の定義(DoD)は予算を予定通り決められたかどうか、なんてふうに変換したらしい。


非エンジニアのスクラムというのは多くの人にとって共通のトピックなのか、質問の列が休憩中の30分間途切れなかった。

昨夜はパーティだった

昨日のエントリの後にパーティに参加したので少し写真を貼っておきたい。

ホテルから道半分を占有して警官付きでパレードしながらバーへ。バーは予想以上に人が多かったのか、飲み物も食事も長い列ができていた(ディナーの設計は超難しいと思う)。


スクラムマスターズナイトをやられている知花さんたちとカフェでワニのフライをつまみ、タバスコ社のスパイシー醤油というお土産に心引かれつつ(買わなかった)。一日目終了。

Ken Rubin 基調講演 "経済合理性のあるスクラム" - Global Scrum Gathering Day 1

scrum

Global Scrum Gathering 2014 に来ている。Scrum Gathering Tokyo の実行委員を３回つとめさせていただいたが、本家のScrum Gathering には未参加だったので、雰囲気を知らないといけない、ということで、遅ればせながら、今回初参加した。


冒頭の主催者のセッションによると、今回のカンファレンスは、 これまでで最大の規模になったとのこと。目分量でAgile Conferenceの半分くらい、500-700人くらいの規模ではないかと思う。23カ国から参加者が来ていて86%は米国からだそうだ。５並行セッションで48セッションが行われる。

基調講演 : Ken Rubin "Economically Sensible Scrum (経済合理性のあるスクラム)"

Essential Scrum の Ken Rubin の基調講演。Kenは以前 Scrum Alliance の理事をしていたそうだ。Essential Scrumは、もうすぐ日本で発売される予定だ。

今回はチームレベルのスクラムができている状態で課題になる、その外側の話。チームレベルの開発にスクラム適用がうまくいくと、次は組織に必要な価値との擦り合わせが課題になる。そこには３つの阻害要因があるという。

  • 開発時に、アジャイルの基本原則を無視する、または、間違って適用する
  • アジャイル原則をバリューチェーン全体に適用することに失敗する
  • チームを組み合わせるにあたり、経済的に合理性のある組織構造を作ることに失敗する

一つ目のアジャイル原則の適用については、Antifragileという本を紹介していた。状況が混乱したときにどのような影響があるかで、３つのレベルに分類すると、Fragile(うまくいかなくなる) - Robust(影響を受ける) - Antifragile(混乱から利益を得る) となる。ウォーターフォールはFragileで、アジャイル原則の適用によってRobustやAntifragileの実現を目指す。

二つ目のバリューチェーンは、複数チームが関わる場合にバリューチェーンを意識するということだ。開発チーム以外にもマーケティングやインフラ、運用チームなどがある場合に、要望が来てからリリースされるまでのサイクルタイムをいかに短くするか、というリーン原則を実現するようにチームを組む。

ここで重要なのは、各チームの稼働率を最大にすることは意味がないということだ。消防署で例えると、稼働率100%の消防署ばかりでは、いざ火事が起きた時に対応ができない。ビジネス要望に即応することと、稼働率を高めることは、稼働率が一定以上になったときに矛盾が生じる。ここでは70%弱くらいで待ち行列の大きさが倍になる例を示していた。開発チームがなかなか要求した仕事をしてくれないのは、だらだらしているのではなく、むしろがんばりすぎていて、稼働率が高すぎるからかもしれない。

三つ目の組織構造については、専門別の部門、地域ごとの部門、コンポーネントごとの部門、フィーチャーチームという４つのパターンを示した後、フィーチャーチームとコンポーネントチームの組み合わせがよいのではないかという結論だった。コンポーネントチームの代表がフィーチャーチームにも属し、花粉を運ぶ役割をもつ、ということだ。

軍隊や消防署のように、長く続く小隊はすでに過去の経験を共有しており、経済合理性がある。

うまくいっているチームが、「スクラムなんだからチームメンバーの変更は受け入れない」といいはじめて、各チームが同じことを言うと、組織全体としてはデッドロックに陥ってしまう。そうではなく、全体のフローの視点で考えようというのが印象的だった。

Coaches Clinic

休み時間にコーチに相談できるCoach's Clinicで、いまちょっと悩んでいることを相談した。
内容は割愛するが、個人的にすごく有益なアドバイスをいただいた。


Chris Sims "How to estimate Business Value"

ビジネス価値を導きだすワークショップ。Agile Conferenceでもやられているようなので、有名なのかもしれない。一般的にビジネス価値といえば金額を想定することが多いが、実際は金額以外の価値がたくさんあり、多面的な価値を考えなければならない。そこで、多様なステークホルダーが集まってさっと相談する。並べ替えと相対見積りを使ってビジネス価値をつけていく。ポイントはこの課程で共通認識ができるということだ。

ここでできた共通認識を外の人に伝えるのは難しいので(見積り結果は伝えられるが、多面的な議論のすべてを伝えるのが難しい)、ステークホルダーに集まってもらう必要がある。

結果として、複数の利害関係をゲームによって調整した結果のビジネス価値つきバックログが作られる。ビジネス価値は変動するものなので、スプリントごとに見積りをやり直す。

ビジネス価値がスプリントとともに変化する例の一つは次の通りだ。出荷可能な単位の機能の価値が300として、そこに３つのバックログ項目が含まれる場合は一つあたり100と考えられる。スプリントが一つ終わって一項目実装が終わると、残り２つ作れば300の価値が実現できるので、残り２項目の価値は100から150に上がる。

この方法が今のチームで使えるかどうか、ちょっと試してみたいと思う。