無料ブログはココログ

« 2013年2月 | トップページ | 2013年4月 »

工夫が凝らされたSCRUM BOOT CAMP THE BOOKの構成

SCRUM BOOT CAMP THE BOOK は読み易くて内容が濃い本です。マンガによるストーリーを活用した従来の技術書にはない構成によって実現できたのだと思います。

従来の技術書

技術書にも色々ありますが、記事や論文を束ねた書籍を除くと、用語の説明方法で大きく3種類に分けられると思います。

入門書
本を初めから読むと理解できる様に、順序だてて説明されています。説明されてない用語が突然出てこない様に工夫されていますが、概要と詳細などで同じ用語がなんども説明される事があります。説明順序が工夫されているだけなので必ずしも内容が薄い訳ではなく、「〔改訂〕Trac入門 」のように案外濃い内容が載っているものもあります。

中級書
ある程度詳しい説明をする場合、あらかじめ用語を説明しておく方が説明が容易になります。そこで、導入部でなるべく多くの用語を説明しておきます。それでも不十分な場合は脚注で別のページへのリンクを示したり、説明を補うなどします。「Redmineによるタスクマネジメント実践技法 」は「プロになるためのWeb技術入門」を参考に中級書を意識して書いています。

上級書
さらに色々な事を説明したい場合は、同じ脚注を何度も書けないので、用語集としてまとめます。このようにしておくと、用語の説明に左右されず全体を構成できるほか、特定の場所だけを読み直した際にもあちこち読まなくても、読みたいところと必要に応じて用語集を見れば良いようになります。

チケット駆動開発 」は前作でかけなかった内容をより多く書く目的で、20世紀に多かったこのような専門書を意識して書いています(なので図が少ない、読みにくい、色々書きすぎ、などと言われても困っていたりします)。

このほかいずれの場合でも、全体の流れを乱してしまうような内容を書きたい場合は、コラム(囲み記事)として分離する、逆引きができる様に索引を付ける、といった工夫をします。

「SCRUM BOOT CAMP THE BOOK」はマンガに気を取られて入門書だと思ってしまいがちですが、初めに吉羽さんの解説がある事から、中級書の構成になっていますし、読み応えのあるコラムや一覧し易い索引があり、なかなか良くできています。

マンガによるストーリー

「SCRUM BOOT CAMP THE BOOK」は全体のストーリーをマンガで構成し、関連する説明を比較的多めの文章で補っています。一見、文章がメインでマンガを挿絵の代わりだと思ってしまいがちですが、中級書の脚注が複数ページになったと考える事もできます。そう考えるとやはり中級書と言えるでしょう。

ストーリーで技術を説明するとイメージがわかり易くなる事から、これまでも多くの本で採用されています。たとえば「アジャイルと規律 」では TSPとXPの比較に利用されていますが、部分的なものです。また「バグがないプログラムのつくり方」は全体をストーリーで構成していますが、文章のみで構成している入門書です。

「SCRUM BOOT CAMP THE BOOK」はマンガでストーリーを示しているので、解説の文章との対比が明確になっています。この効果で、ストーリーに引っ張られずに、実践的な情報をふんだんに取り入れても違和感を感じない構成になっています。

まとめ

技術書以外の既存の本で考えると、「クッキングパパ」や「酒のほそ道」のコミックなど料理マンガのレシピを増やしたイメージとも考えられますし、かつての「科学と学習」や小学館の学習雑誌の付録似ついてきたマンガをベースにした解説本のようにも感じます。

これらの本は内容が濃いものの、楽しく読めるという特徴があります。クッキングパパではレシピの最後に「おいしいぞ!」と語りかけられると、ついつい作ってみようかという気持ちになります。マンガは雰囲気が伝え易く、親しみ易いので、より多くの情報を伝える事ができるのでしょうね。

アジャイル開発もいよいよ本格的な普及期に入ったと思います。これからは原則に則った方法だけでなく、より現実的で実践的な情報が必要とされるでしょう。

この本の様に様々な工夫が凝らされた本が増え、ソフトウェア業界が健全に発展する事を期待しています。


SCRUM BOOT CAMP THE BOOKからの学び

Bootcamp

ようやく読み終えたので、内容の感想を書きます。この本は、とても読み応えがありました。特にシーン20以降は実践的で、経験の少ない方にはぜひ読んでいただきたい内容でした。

マンガが載っているので入門書だと思って読むと、実践的なノウハウがたくさん詰まっていてきっと驚かれるでしょう(これには構成による効果が大きいのですが、それは別に書く事にします)。

この本はスクラムと書名に入っていますが、スクラムの内容はスクラムを始める際に必要なものに限定しています。その反面、必要な内容はスクラムでないことも載っていることは、以前書いた通りです。

この本には3つの大切な事にたくさんのページを割いています。

準備
インセプションデッキや見積もりなど、開発を始める前にする事が多く書かれています。アジャイル開発は実装優先のはずですがなかなか開発が始まらず、1/3が準備に割かれています。

確認
インセプションデッキから、スプリント計画ミーティング、スプリントレビュー、そのほか全てが常に確認・改善されながらお話が進んでいきます。透明化によって問題を見える化し、確認する事が大切なのだと思いました。

タイムボックス
この本の中で、「プロジェクトの先を見通すために、タイムボックスは必要なんだ」と力説されているのがタイムボックスです。ベロシティをきちんと測定するには、タイムボックスを守らないと行けません。

これは、スプリント計画ミーティング、スプリントレビュー、スプリントレトロスペクティブ(ふりかえり)の比率を一手に保つためにも必要な事でしょう。また、本には書かれていませんが、チームのリズムを守り、効率的な開発を維持すると言う側面もあると思います。

スクラムは「アジャイル開発とスクラム 」にあるように、オブジェクト指向から考えられたプロセスです。カプセル化のモチーフになったとも言われる小さな細胞の組み合によって実現される大きな生命体の様に、確実なプロセスを積み上げないといけません。

そのようなスクラム開発だからこそ、きちんと準備され、確認され、タイムボックスできちんと管理されたプロセスが必要なのでしょう。そしてそのような開発を通じた実践的な「学び」を続ける事が、本当の意味の「守破離」の道なのだと思いました。


アジャイルがダメだと思う7つの理由を前向きに考えてみる

アジャイルがダメだと思う7つの理由話題になっています。感想としてはTwitterでつぶやいた様に

と思っています。せっかく話題になっているので、私も便乗して前向きに考えてみました。

書いているうちに、ご本人が書かれている様に、良く言われているパターンを面白おかしく書かれているだけと言うのが透けて見えました。関連する議論には有益なものもありますが、気持ちが前面に出ているものもあり、私には不毛だと思えました。一部で解説を求められたので、追記します。

以前、論文を書く上での注意点で書いた様に、研究の初めの問題設定が新たな発見によって見直さないといけない場合、主張した点を裏返して問題設定します。今回はこの逆で、問題からどう実践すれば良いかを考えてみます。

物事の本質を見極めるには余分なものを取り払わないといけません。対称性、一般性、同値類などを考えて整理すると論理が明確になると思います。

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

全体スケジュールにコミットしないといけないなら、アジャイル開発しない。アジャイル開発と同様に理想時間で見積もるCCPMの方が向いているでしょう。 変動を認めるなら小さめの必須分のみコミットすれば良いでしょう。

元記事は「経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。」とされています。

技術には適用範囲がある事を忘れてはいけません。アジャイル開発の特徴はタイムボックスを固定して実現する仕様の範囲(スコープ)を可変にする点です。仕様を固定すると言う事は優先順位の高いものから実現する事で無駄を省くという考えに合いません。

全体仕様を確定した上で無駄を省くなら、アジャイル開発でなく仕様を固定しタイムバッファを変動させるCCPMの方が向いているでしょう。スコープの無駄を省くものの一定のコミットメントが必要なら、優先順位を決めた上で、必須のものをコミットするのが良いでしょう。

2.アーキテクチャ上の無駄が生じる
アーキテクチャは予め検討して始めましょう。しかし、リーンソフトウェア開発で言われているように、最終責任時点まで決定をできるだけ遅らせることで、選択肢を維持しましょう。

元記事は

「アジャイルだから全体が決まらないとか言って、なんとなく流行の技術を使って作ってないか?そうやって作られた物は負債になる。」

とされています。当たり前の指摘なので、予め検討すべきだと思います。ただし、全てを決定する必要はなく、その時点で決めておかなければいけない事のみを決めれば良いはずです。選択肢の残し方はリーンが役に立つでしょう。

3.コーチって何だよ
コーチはニワトリです。身を削りません。豚はその卵を食べて甘えるなら、身を切られても余るぐらい知識を貯えないといけません。得た知識を再伝搬して元を取りしょう。

元記事は「成果を生み出さない人員なんか不要なんだよ。」とされています。スクラムの世界では身を切るものを豚、身を切らない努力をする者をニワトリと呼びます。アジャイルコーチはニワトリなので、存在する事によって効果がないといけません。投資対効果を考えろと言う事です。

4.変化ヲ抱擁スルために固定化している
暗黙知が特定の人に固定化されない様に気をつけましょう。ペアプロやコード共有は重要ということですね。

元記事は「大抵の場合は要員を固定化するという前提が付くのです。」とされています。アジャイル開発はドキュメントと言う形式知は必要最低限にして、コミュニケーションを活発にして暗黙知を活用します。

アジャイル開発の効果を期待するなら、ドキュメント増やさないで必要なアジャイルプラクティスを活用すれば良いでしょう。

5.実証主義的な説明に過ぎない
良い人材を育てましょう。

元記事「結局、良い人材がいればチームは成功するってことなんだよ。」とあるとおりです。元記事に「でも、そんなのは難しいから、」されていますが、プロセス改善は文化を変える事です。なので、これは何もしないと言う意味になります。

もし、求められるレベルが高すぎると言うなら、アジャイルコーチが短期的な解決策になりますが、3と矛盾します。

6.手段が目的になっている
目的や問題を見極めて手法を導入しましょう

タイトル通りですね。元記事の

「アジャイルという手法にこだわって「理解しない顧客が悪い」だの「契約が悪い」だの、そんなの言い訳でしょ。」

という意見はアジャイル開発を前提にしていて、プロセスに責任を持つプロとして、目的を見失っていますね。理解せずにプロセスを変更してはいけません。

7.アジリティはアジャイルだけのものではない
保守性の高い構造を考慮しましょう

元記事は「アジャイルなんて、一部分に過ぎないことを自覚して欲しい。」と言っています。ソフトウェア開発の目的はソフトウェアの開発です。あたり前過ぎてこれ以上は説明できません。

う〜ん、普通の話になってしまいました。

これまでの10年、救われないカルト宗教のような誇張した表現で色々な議論がされてきました。それはそれで面白いのですが、S/N比が悪くなってしまいます。もっと技術論をしましょうよ。

このエントリーをはてなブックマークに追加

使えるアジャイル開発の本 - SCRUM BOOT CAMP THE BOOK とプロセス -

ソフトウェア開発プロセスの定義は色々ありますが、モデルとして考えるなら

  「選択的なタスクの集合」

だと思っています。特定のやり方を強制するのではなく、状況に応じて対応できないといけないと思っているからです。

これまでのアジャイル開発の本は仕組みや考え方のの解説が多く、多様性があまり無い物が多かったと思います。 SCRUM BOOT CAMP THE BOOKはスクラムで不足している内容を補っているだけではなく、多様性を与える事で使えるアジャイル開発の本であると思います。

守破離の危険性

CMMブームの際に議論になったのはレベル3(定義されたれレベル)の壁です。CMMで考える良いプロセスは、定量的で管理され(レベル4)、常に最適化される(レベル5)プロセスです。

しかし実際は、段階モデルに従ってレベルを達成していくと、レベル3でとどまる事が多いと議論されていました。これはレベルの達成に時間がかかって疲弊してしまうだけではなく、「ルールだから守れ」というトップダウン的な強制が思考停止を招くからだと思います。

アジャイル開発に置いても同じ事が起こりうると思います。それぞれのチームがルールだからと何も考えずに実践していれば、改善の考え方や仕組みが組み込まれていても、いずれおざなりになるからです。

ワークショップの危険性

ワークショップは特定の技術を体感して身につけるには効果的です。しかし、体験した印象があまりにも強く、講師が複数の選択肢を示していても記憶に残るのは唯一の経験でしょう。

これは開発の現場でも良く起きる事です。一度、プロジェクトで成功すると前提条件が変わっても同じ方法をとり続けて失敗するというパターンがあります。このような状況を避けるには、書籍や他の開発者との交流などで、より多くの判断可能な知識を得ておく事が重要です。

どのように考えてリリーススプリントの実施を決めるかなど、この本の様に示されていれば、現在のチームの状況を見定めた上で実施方法を判断する事ができるでしょう。

業務の開発では失敗できない

UltimateAgileStories iteration2のアジャイル放談で細谷さんが語られた様に、トラブルが発生した場合、ウォーターフォールは対策方法がわかっていてそれなりに鎮火できますが、アジャイル開発はその解決方法がこなれておらず、とんでもない事になると思います。

[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組みで書いた様に、私も過去にアジャイル開発で失敗していてうまくリカバリーできませんでした。この時は研究開発だったので失敗も経験のうちと考えられましたが、お客様の業務をになうシステムなら、大きな失敗はゆるされません。

プロジェクトを成功させるには、プロジェクトのゴールを明確にするだけでなく、リスクを明確にして対策を講じておかなければいけません。そのためには、プロジェクトがイメージでき、いざという時のために複数の手駒を用意しておかなければいけません。

設計時に複数のアーキテクチャを健闘した上で判断した方がより良いソフトウェアが実現できる様に、プロセスプログラミングにおいても、複数の方法を健闘した上で実践する方がうまくいくのです。

お客様の業務開発を考えたとき、ようやく使えるアジャイル開発の本が登場したと思いました。


日本文化に仕立て直した実践書 - SCRUM BOOT CAMP THE BOOK の意義 -

「 SCRUM BOOT CAMP THE BOOK」をじっくりと読んでいます。まだ1/3ほどしか読めていませんが、読み終わると今の思いだけでなく、別の事が書きたくなって収拾がつかないと思うので、一旦、感想を書いておきます。

結論から書くと、この本は欧米文化をベースに作られたスクラムを、日本人に合わせて見事に仕立て直しています。どのように実践すべきか、スクラムに不足しているところを補いながら、日本人が実践できる様に説明している良い本だと思います。

欧米の文化を考える

以前「スクラムを味方につけろ! - SEA関西プロセス分科会 -」と言う記事で「スクラムは敵か味方か」という不安を書いていましたが、「アジャイル開発とスクラム」とこの本を読んでいて、その背景にあるのはキリスト教的な欧米文化にあると思いました。もちろん、単純に述べられるものではないと思いますが、聖書から透けて見えるのは以下のような内容です。

契約文化

「新約聖書」と言いますが、新約の「約」は契約の「約」で、翻訳の「訳」ではありません。天国に行くには契約を守れば十分です。海外では仕事を頼んでも「その仕事は私の仕事ではありません」と断られてしまうことがあるそうですが、契約がすべての基本であるという文化的背景があると思います。

聖書の「善いサマリア人」(ルカ10・25-37)では博愛が説かれているのですが、それは「人にしてもらいたいと思うことは何でも、あなたがたも人にしなさい」(ルカ6・31、日本聖書協会 新共同訳)と考えるからで、気を利かせたり会社のためという感覚ではないと思われます。

このような契約文化があるので、価値観や考え方だけでなく「仕組み」としてプロセスを作り上げる必要があると思います。

能力の発揮が義務

タレントの語源になったと言われる「『タラントン』のたとえ 」(マタイ25・14-30)というものがあり、自分の能力を発揮しないといけません。

日本では指示されるとか、そういう雰囲気でなないと、自ら進んでコミットしない人が少なからずいます。しかし、欧米では信仰上、能力を発揮しないと天国に行けないので、進んでコミットメントするのが当然と考えられます(もちろん、例外もおられるでしょう)。

サーバントリーダーシップ

以前、アジャイル開発への壁は価値観の壁という記事に書いた様に上に立つ人は、仕える者のようになりなさい。」(ルカ22・26、日本聖書協会 新共同訳)という聖書の言葉があり、上の人間がメンバーが能力を発揮できる様に考える事が当然とされています。

日本では偉くなると人を使うものだと考えて、上司が細々と指示を出して、下の人がそれに従うイメージがあります。欧米でウォーターフォールがうまくいかず、日本ではある程度うまくいったのは、このような背景があるのかもしれません。

CMMをふりかえって

CMMも日本を含めて世界的に行われていた管理が先にあり、クロスビーの研究をベースに形式化されたと考えられます。CMMを導入した企業によっては、日本的な管理をベースに、改善がうまくいっていたのに破壊されたと言う意見を聞いた事があります。

標準になるとその方が優れている様に考えてしまいがちです。しかし、それが自分たちにとって必要なものであるか、そのまま受け入れて良いものか、良く見極める必要があると思います。

アジャイル開発とスクラム」では、オリジナルスクラムでの考え方がアジャイルスクラムでどのような仕組みにマッピングされているかを解説されていました。しかし、それはあくまでも仕組みです。そのような仕組みで前提にしている価値観についてはあまり書かれていませんでした。

スクラムを日本人向けに仕立て直す

「SCRUM BOOT CAMP THE BOOK」はアジャイルスクラムの前提である欧米文化を解説するのではなく、日本人がスクラムを実践するならどうすれば良いかと言う事が書かれています。

そこで、見え隠れするのは日本的なチームの一体感です。和辻哲郎氏の「自他不二」と言う言葉に示される様に、日本人は「場」において一体の仲間だと感じます。単なる互恵関係ではなく、互いを気遣い、助け合える関係です。

この本は、スクラムの仕組みを利用しつつ、このような日本文化を活かして、チームにどのように文化を構築するかが書かれていると思います。

それは、遠藤周作が当時のキリスト教に居心地の悪さを感じ、著作を通して日本人向けのキリスト教観を構築した様子に似ています。その著作は日本だけでなく、世界でも読まれています。特に「沈黙」はセンセーショナルで、日本だけでなく様々な国の言葉に翻訳されました。

「SCRUM BOOT CAMP THE BOOK」によって日本人にふさわしい形でスクラムが広がり、その文化がふたたび世界に広がる。そんな夢を抱きつつ、この本を読み進めたいと思います。


ソフトウェア開発はモノ作りなので、本来楽しいはず!

最近、色々な記事を読んでいて思い浮かんだ言葉です。

「ソフトウェア開発はモノ作りなので、本来楽しいはず!」

この言葉の主は、関西のメーカーに勤められていた「姫」と言えば、わかっていただける方も多いでしょう。

モノ作りの醍醐味

この言葉が出たのは、エクセル上に開発された携帯ソフトのテスト環境のプレゼンの時だったと思います。当時は3Kとか5Kという言葉でソフトウェア技術者が語られた時代のことです。

ソフトウェア開発はモノ作りなので、本来楽しいはずなのです。それを苦痛にしているのは自分達だという主旨でした。

携帯もその少し前から100万ステップを超えたと言われていましたから、テストはそれなりに大変なはずです。その状況をいかに克服するか、工夫する事がモノ作りの醍醐味なのだと思いました。

デバッグを教えてもらった話

私が新人のとき、バージョン0.5のOSで動く不安定なコンパイラで開発をしていました。あるとき、動作がおかしいプログラムがありました。どんなに見直してもコードに間違いはなく、とうとうギブアップしました。

そんな時に当時の上司が横の席に座り「どこまでなら大丈夫か確認していこう!」とバイナリサーチの要領で問題点をあぶり出してくれました。正攻法ではわからないことが、ちょっとした工夫でみつけることができて、問題は解決しました。

今で言うならペアプロの要領で、ソフトウェア開発は工夫である事を教えてもらったのです。

プロセスプログラミング

もちろん違法な職場派論外ですし、 どうしようもない時もあるかもしれません。しかし、「どないすんねん」と思ってしまう状況で、絡まった問題をほぐし、効果的に攻めることで、予想外の成果が得られる事もあります。

普通にやっていてはできない事が、作業のやり方や実施順序、モチベーションが高いチーム作り、といった様々な工夫によって大成功とはいかないものの一定の成果が得られます。

このような工夫を私は「プロセスプログラミング」と読んでいます。それを実践する私は「プロセスプログラマ」を自認して、モノ作りの楽しさを感じることを生き甲斐にしています。

モノ作りの楽しさ

モノ作りは楽しいです。今までなかったものを生み出して、社会に貢献する。なにより、作ったプログラムが動いたり、今まで大変だったことが簡単になったりすると「やったー」と思います。

そうは言うもの、大変な仕事が目の前に現れると、ついつい大丈夫かと不安にかられます。逃げ出したり、守りに入りたくなる事もあるでしょう。 信頼性が求められれば、入力した通りにしか動いてくれない計算機が相手なので、神経をすり減らしてしまいます。

でも、それだからこそ、達成した時の喜びは大きいものです。成功の鍵は、技術かもしれませんし、ツールかもしれません。あるいは、より良いコミュニケーションのためのお菓子タイムかも知れません。

ありとあらゆる工夫をして、モノ作りの楽しさを取り返そうではありませんか。

朝会の成否

朝会では進捗と予定を共有する時間は15分。立ってするのが良いそうです。しかし、私は必ずしもそうでないと思っています。

なぜなら、実装が始まると自分の開発に集中して、プロジェクトのメンバーがコミュニケーションを取る時間が少なくなるからです。誰かの問題の解決を朝会の場で行えば、互いの技術力を向上しつつ、人となりが見えてきて意見交換の効率が良くなると思うからです。

と書くとそれらしいですが、朝会後に関係者で集まる場合、5人のチームで3人が打ち合わせ関係者なら2人が仕事に戻って、まあそんなものかもしれません。しかし、関係者が4人だったり、チームが4人だったりすると、一人だけ外れて仲間はずれになってしまうと思うのが大きいかもしれません。

原則論でいくと、たとえそれが5分10分であっても作業時間を無駄にしてはいけないと言えますし、複数の作業を混ぜると問題点がよく見えなくなり、これはトヨタ式の整理整頓や、プロセスをOne thing in one placeで構築するとすると考えても、良くないと言えます。

そうは言うものの20分ぐらいで終わるならと言う思いがあって、課題の解決策等も朝会で話し合っています。あるとき、議論が長引いた時にこういわれました。

「先に進捗してしまいましょうよ!」

さて、みなさんはどう思われますか?

そんなの当たり前だ、原則に従ってやるべきだ!と思われますか?実際、その時はキリの良いところで切り上げてその意見に従ったのですが、私はこの意見が出た事を誇らしく思います。

今振り返ると、この朝会、というか、このプロジェクトは大成功だったと思っています。このような意見が出たのは、プロジェクトを効率的にという意見かもしれませんし、メモが取りにくいという理由かもしれません。はたまた、報告内容を忘れるという現実的な問題だったのかも知れません。

でもそのような理由はともかく、プロジェクトの運営に対して、この人は意見を言っていた事が大切です。与えられた仕事だけではなく、チームを見て意見を述べていたのです。

お酒を飲みながら愚痴を言う事はあっても、チームの進め方について話すのは、インセプションデッキや計画ゲーム、ふりかえりなどの機会が中心でしょう。でも、目の前の課題はなるべく早く解決したいものです。

この他にも、若い子が「ついでに相談して良いですか?」と言い出した事があります。もちろん、OKで、ドンドン相談してもらいました(あまり長くなると止めましたが、、)。

このプロジェクトは大変なプロジェクトでした。でも、和気あいあいのチームでした。朝会で気づいた事が自然と共有でき、問題が起こりにくく、仮に問題が起きてもアイデアを出し合って乗り越えることができました。私はそんなプロジェクトが大好きでした。

やっぱり、朝会は立ったまま15分で終わらないとダメですか?

コタツモデルを実現したスクラム開発 #devsumiA #qa_it

前の記事に書いた様に、アジャイルスクラムではチームがカプセル化されていて、プロダクトオーナーが作成・管理するプロダクトバックログの優先順位に従って開発されます。この優先順位はプロダクトオーナーが価値が高いものやリスクが高いと考えるものを高くして、早期に開発します。

しかし、以前書いた「アジャイル風開発ラフシミュレーション」の結果の様に、リスクが顕在化した際の影響を少なくするにはリスクの特性を考慮した優先順位をつける必要があります。

具体的には、リスクの大小だけではなく、リーンソフトウェア開発に書かれている様に「決定をできるだけ遅らせる」ことも必要に応じて行わないと行けません。たとえば、スクラムを活用したアジャイルなプロダクト管理(p.55)にあるように、ユーザインタフェースのデザインはその後の方向性を定めるために早めに実装して確認する必要があります。しかし、一度に全部を作るのではなく、典型的な画面をまず確認して、その後に横展開する方が効率的でしょう。

このような判断は、ある程度の実装の知識が必要になります。要求開発のコタツモデル(リンク先はITpro)の様に、ビジネスや業務だけでなく、常にシステムを考慮した優先順位を考える必要があります。

デブサミの講演「ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例」では、担当者の知っている言語Rubyを選び密度の高いコミュニケーションをはかる事で、コタツモデルに求められる効果を実現していました。アジャイル開発とスクラムで野中さんが、プロダクトオーナー及びスクラムマスターが「スクラムチームの内外両方に対して、積極的に働きかけなくてはならない」(p.239)を実現していたのです。

スクラムはアジャイル開発の優れたフレームワークのパッケージです。そのまま利用するだけでも大きな効果が得られるでしょう。しかし、より良くプロデュースすれば、さらに大きな効果が得られると思います。

スクラムに限らず、プロセス改善のゴールは組織やプロジェクトによって異なります。常に問題を見極める姿勢が大切だと思います。


壁を打ち破れ! - アジャイル開発とスクラムを読んで -

良書と呼ばれるものには、メッセージ性の強いもの、入門でありながら深いところまでかたるもの、網羅性の高いもの、色々な読み方ができるもの、など色々なパターンがあると思います。

この本は、「おわりに」にある様に「実践知リーダーシップ」というメッセージを中心に書かれていますが、基本から実践までが語られていて、色々な読み方ができます。著者らの思いとは少しずれているかもしれませんが、感じたままに感想を書かせていただきたいと思います。

私が感じたのは「実践知リーダーシップ」に必要な共同化を実現する「壁を打ち破る」ことが大切だと言う事です。この本を読み出したとき、「そもそもアジャイルとは何か」「スクラムでないとできない事は何か」など、ついつい曖昧になりがちな言葉の定義ではなく、そこで大切にされているものを知りたいと思いました。

オリジナルスクラムと壁

この本はアジャイルスクラム開発の本と言うよりは、事例やオリジナルのスクラムを通してアジャイルスクラムを見直している本だと思います。野中さんがオリジナルのスクラムの解説とそのアジャイルスクラムのマッピングをされていますが、所々、気になるところが出ています。

もちろん、アジャイルスクラムを応援されていますが、それよりも大切なものがオリジナルのスクラムにある様に思いました。それが、壁を打ち破り、知識を共同化し、 実践知リーダーシップ を発揮する事だと思います。

最初に「壁」が出てきたのはセールスフォース・ドット・コムの事例です。アジャイル開発の説明でありながら、この事例は組織の壁(p.24)を取り除いたのでうまくいったと思います。また、リクルートの事例でも組織の壁について語られています。

この壁と言うものは、ソフトウェア開発の最大の敵です。タスクカードを貼って情報を共有する場合には、壁はとても魅力的です。しかし、ステークホルダーの間に立ちはだかった場合には、プロジェクトの透明性が失われ、コミュニケーションが阻害され、対立構造が生まれてしまいます。

壁の経験

この本を読んで、壁の経験を思い出しました。

私は若い頃から複数のメーカーさんの仕事を何度かさせていただいています。そこでは、ハードとソフト、最近ではインテリジェントな周辺機器とメインの機器など複数のソフトウェアが並行に開発されています。

そのような場合、スクラム・オブ・スクラムというか、軽量化された五月雨ウォーターフォール開発・オブ・スクラム、とでも言うようなリーダーミーティングが行われています。これは、リーダーが実践知を持って互いにコミュニケーションをはかり、各チームに深く入り込んでいればうまくいきます。

特にある程度こなれた環境の場合は、スタブやシミュレータがあって、インターフェースのトラブルも限定されたものになります。しかし、新規にインタフェースを作る時には、よほど注意深く開発を進めないとうまくいきません。

以前、どうもあやしいと感じるプロジェクトがありました。その時はあるチームの責任を持つ立場でしたが、リーダーミーティング的な集まりはお客様の担当者が出られていました。出てくる資料や話からは詰めの甘いところが感じられました。

そこで、担当者の方に「このままでは無理です」と宣言しました(後から聞くと同僚は強気な発言に驚いた様です)。通常なら、Q&Aなどを通じて詳細を詰めていくのでしょうが、期間や内容を考えるとリスクが高過ぎました。そこで、お客様とお話しして他のチームとの合同のミーティングをしていただきました。壁を打ち破った瞬間でした。

オブジェクト指向だけでは堅すぎる

この本を読んでいると、アジャイルスクラムはオブジェクト指向開発をする上で、従来のやり方では難しいのでオブジェクト指向的な組織構造を作った(P.221)というジェフ・サザーランドさんのお話が載っています。

チームをカプセル化し、スクラムマスターがプロダクトオーナーとのメッセージを受け取る仕組みです。大規模化する際にはスクラムマスター同士が集まるチームを構成し、スクラム・オブ・スクラムを実現します。

しかし、オブジェクト指向がやりにくい場合に、アスペクトやミックスインをしたくなる様に、チームがうまく守られれば守られるほど、やりにくくなる可能性があります。

富士通の事例(P.173)では、朝会と夕会のそれぞれをチーム毎と全体の2回ずつ行っていますし、野中さんも「チームの外部への知識の伝達については未だ多くが語られていない」(P.217)とされています。

要求開発のコタツモデルのようにチームを越えて知識を共同化するには、「壁を打ち破る」事が必要なのだと思いました。

チケット駆動開発の壁

著者の平鍋さんはアナログ大好きな方の様です。この本の中でも遠隔地とは最初は同じ場所で始める、skypeを常につないでおく、といったお話が出てきます。とても参考になります。

チケット駆動開発は作業の中心にITSなどのチケットシステムを置いて、それに依存して常に見る様にする事で、アナログのタスクボードのような効果が得られます。

この時に注意しないと行けないのは、それだけではうまくいかない事を認識する事です。本に書かれた方法や、必要に応じて通信方法を選択する事も大切です。

RxTstudyなどの勉強会で議論していて良く出るのは

  • 議論が長引いて面倒な時は電話などで直接話をしてまとめをチケットに残す

と言う方法です。ありがちな説明では「手段が目的化」しないようにという説明になりますが、これもチケット駆動開発という方法の壁を打ち破ってコミュニケーションをすることと言えると思います。

この本で壁を打ち破ろう

アジャイルスクラムはオリジナルスクラムに比べで、ソフトウェアに最適化した非常に良くできたパッケージだと思います。しかし、チームの壁を超えた組織的な活動はこれからです。

これがあれば万全と言う銀の弾丸は未だにありません。ソフトウェア開発を担う私たちは、現実の問題に合わせてどのようにプロデュースし、どのようにパッケージングするか、常に求められています。この本はその時のヒントになる良書だと思います。


[#TiDD] チケット駆動開発はセメント

チケット駆動開発は変幻自在、プロジェクトを色々な形に作り上げる事ができる
XPは魂、助け合うチームを作ってプロジェクトの意思を築く
スクラムはフレームワーク、改善を繰り返してプロジェクトの枠組みを作る

チケット駆動開発はセメント、プロジェクトを色々な形に作り上げる事ができる
強い意思があればコンクリートになる
筋金入りのアジャイラーなら鉄筋コンクリートになる
枠組みで固めれれば、立派なアジャイル開発になる

そこに壊れかけたピラミッドがある
セメントだけでは直せない
石をつめてもすぐに崩れる
枠に入れようとしても入らない

さあ、壊れたところを取り除け
使えるところだけを残して造り直せ!

危険な穴を見つけたら
セメントに石をまぜて鉄筋を通し
穴を塞いで強固にしよう!

固まるまで安心するな
荒い作業ではうまくいかない
細か過ぎてもうまくいかない
見守って助け合え、経験の蓄積が成功の秘訣

それはアジャイルなのかと 君は聞いた
そんな事が大切なのかい?
君はアジャイルをしたいのか?
それともプロジェクトを成功させたいのか?

大切なゴールはプロジェクトの成功
どんなチームを創るのか
どんな文化を根付かせるのか
未来に向かって挑戦しよう!


[#TiDD] 世界に飛び出したチケット駆動開発

このブログで紹介した「なぜ日本ではチケット駆動開発が注目されるのか?」 と言う記事ががあきぴー(@akipii)さんの記事と共に英訳され、アトラシアン社の英語ブログに”What is Ticket Driven Development, and why is it attracting attention in Japan?”として公開されました。

日本語版とともに英語版の公開にあたっては、アトラシアンの大澤(@Sean_SF)さんに翻訳を初めとして、大変お世話になりました。ありがとうございました。

アトラシアンさんはJIRAというBTSを販売しておられる会社です。これ以外にもアジャイル開発のプロジェクト管理ツールGreenHopperも用意されていますし、SourceTreeというMac用の Git・Mercurial用の無料 Mac クライアントを公開されています。

もちろん、JIRAを使えばチケット駆動開発が可能です。しかし、残念ながらJIRAではチケットに相当するものは”issue”と呼ばれています。Redmineのチケットも英語では”issue”なので、tracユーザを除いては英語では”issue”の方が通りが良いと思われます。

しかし、記事を見ていただくとわかる様にチケット駆動開発を” Ticket Driven Development”としていただけました。このあたり、オープンソースへの貢献もされているアトラシアンさんの懐の深さを感じます。あらためてお礼を言わせていただきます。

さて、記事の内容は私の個人的な思いが入ったものですが、これまで英語であまり説明されていなかった日本のソフトウェア開発の現状とチケット駆動開発について書いたものです。外国の方に説明する際などに、ご利用いただければ幸いです。

すでに、ナイスなコメントも入っていますし、Twitterやfacebookなどのshareも他の記事に負けないくらいされている様です。チケット駆動開発に限らず、ソフトウェアの技術が国を超えて切磋琢磨できることを楽しみにしています。


[#TiDD] アジャイル風開発ラフシミュレーション

以前まとめたアジャイル風開発のリスク対応力についてラフシミュレーション、いわゆるドンブリ勘定をしてみました。突っ込みどころは多々あると思いますが、ざっくりと考えるきっかけになると思い、公開します。

前提

状況:いつでも実装を始められる。
仕様書作成:完成には1ヶ月かかる。期間は考慮するが工数は考慮外とする。
製造工数:12人月(アジャイル:3人×4ヶ月、その他: 4人×3ヶ月)
問題の発生パターン1:2・2・2人月、あるいは2・1・2・1人月の問題が開発後期に発生
問題の発生パターン2:2・1・ 0 ・ 0 人月の問題が開発後期に発生
残業:問題発生の翌月から25%の残業ができる
仕様削減:アジャイル開発、五月雨ウォーターフォールは2人月の仕様を削減可能

ウォーターフォール

ウォーターフォールでは仕様が固定されていますので、パターン1しかありません。

あふれた作業は残業でも吸収できません。4人月分残ります。リリースを1ヶ月のばすか、混乱を招いても人を足して少しでも早めるかですね。できれば残業と類似プロジェクトの経験者で何とかしたいところですね。

Sym_wf1_2

五月雨ウォーターフォール

図中ではまとめて書いていますが、文書化と開発を段階的に進めます。見積もりや発注が煩雑になりますが、文書による仕様の確認後に請負契約を段階的にします。

パターン1では、優先度の低い仕様を削減しても2人月あふれます。ウォーターフォールよりは少ないですが、残業での吸収は厳しいですね。

Sym_pwf1_2

パターン2では25%の残業で何とか吸収できます。リスクベースの計画で問題による工数が削減された事、優先度の低い仕様を削減できた事の効果が大きい様です。

Sym_pwf2_2

スクラムウォーターフォール

全体のプロセスをウォーターフォールで構成し、実装と単体テストをスクラムで開発する方法です。仕様はあらかじめ固定されていますが、段階的に開発する事で環境やUIなど実装中のリスクをある程度低減できます。

パターン1では4人月あふれますのでウォータフォールと変わりません。繰り返し開発によるプロセス改善で、少しは削減できると思われますが、ふりかえりの時間を削りたくなってしまうかもしれません。

Sym_wsf1_2

パターン2ではリスクベースの効果があるものの、徹底したプロセス改善であふれた2人月を削減するのは厳しいでしょう。

Sym_wsf2_2

アジャイル開発

最初の開発に必要なユースケース等が明らかになっていると言う前提ですので、文書化の期間も実装でき、少ない人数で開発できます。アジャイルでの残業と言う行為に目をつむると、残業の可能な期間も長くなります。

パターン1では最も少ない1.75人月の工数があふれます。ふりかえりの改善効果のほか、アジャイル開発では実装以降の作業も実装と同時に行うので、その工数を実装中に割り振ると考えると何とかなるかもしれません。

Sym_ag1_2

パターン2では25%の残業をするとなんと工数が余ります。残業を減らす事もできますし、削減可能な仕様を復活できるかもしれません。

Sym_ag2_2

まとめ

アジャイル風の開発と言ってもその効果は様々です。アジャイル開発で実装を優先する効果は大きく、リスクをうまく低減できる可能性があります。

一方、ウォータースクラムフォールは、チームのコミュニケーションやプロセス改善の効果は期待できると思われますが、リスクに対してはあまり効果がありません。今回は考慮しませんでしたが、ウォーターフォール開発でプロトタイピングや共通化によってリスクの低減を図る方が、場合によっては効果があるかもしれません。

今回の結果で意外と良かったのは五月雨ウォーターフォールです。安定した発注が可能かどうかと言う問題はありますが、うまくいくとウォータースクラムフォールよりも効果がありそうです。

最後にアジャイル開発のパターン2の問題の発見が遅れたパターンを考えてみました。リスクの考慮をしないで優先度のみで実装を進めると、リスクが顕在化が遅れてしまう可能性があります。この場合だと0.5人月ですが、あふれてしまいました。リスクの考慮は大切ということですね。

Sym_ag22_2

論文ネタを探している方へ

ご自由にこのネタを使ってください。ご協力も可能ですので、必要でしたらご連絡ください。

[#TiDD] 分類と制約から自律・協調へ #xpjugkansai #devsumi

アジャイル開発ブームに見られる様に、ソフトウェア開発の世界は大きく変わろうとしています。このような変化はソフトウェア開発だけではなく、複雑化する中でコミュニケーションが発達した社会全体の大きな流れです。人を律して管理するのではなく、尊重して助け合う事で個々の能力を活かす社会に変わりつつあります。

ソフトウェア開発技術のふりかえり

ソフトウェア工学の歴史は制約から始まりました。まず、初期のプログラミング言語には制御構造のパターンがなく、自由度が高過ぎたので、スペゲッティプログラムが蔓延しました。

そこで、ダイクストラ先生が混乱を導き易いGOTO文がなくてもプログラムが書ける事を論理的に示したことから、構造化プログラミングが始まりました。プログラミングに制約を加える事で、ロジックの分割統治を図ったのです。

分割統治の考え方は設計にも利用され構造化設計・分析になりました。それはトップダウンに機能で分割してしたが、共通化がうまくいかないという問題がありました。そこで、データやデータの流れに注目してボトムアップに共通化する方法と組み合わせて実現される様になりました。

しかし、この方法にもいくつかの問題がありました。ソフトウェアが階層構造を持つ場合、一つのモジュールの下位モジュールとの情報のやり取り(ファンアウトおよびファンイン)を一定に押さえないと理解が容易なプログラムにならない事です。

全体をピラミッドのようなきれいな構造にすると、理解が容易になるので実装や不具合の修正が容易になります。その反面、上位のモジュールに修正が必要となる仕様変更が発生した場合、大規模な改修が必要となりました。

そこで、システム全体を一つの大きな構造にするのではなく、独立したオブジェクトが連携する構造が主流になりました。

組織構造のふりかえり

組織構造にも同じような歴史がありました。会社が大きくなるに従って仕事はルールに従って実施するものとなり、機能的に分割された階層的な組織が作られました。しかし、1980年代の経済誌には「ピラミッド型組織からネットワーク組織へ」といった記事が書かれていました。

そこでは、巨大なピラミッド組織では社会の変化についていけないからと、上層部の意思がすぐに伝わるネットワーク構造が良いとされました。しかし、単純に高さの低いピラミッドにしただけでは、中間層の負担が大変でした。

そこで、事業部にはじまって、やがて部門ごとに独立採算制度を取って、それぞれの部門が決定を行う様になりました。独自にビジネスの実践が容易な様に、営業部門が単独ではなく、事業部や各部門の中にある所も多い様です。

ソフトウェアプロセスの振り返り

ソフトウェアプロセスも同じような進化をしました。プロジェクトは外科医チームと呼ばれる執刀医にあたるリーダーを中心に実施されていました(実際の外科医はこのようなものではないそうです)。

スーパーエンジニアに依存する方法は、時にして大成功をおさめました。しかし、ソフトウェアの規模が大きくなるに従って、個人の個人に依存した失敗が増えました。そこで、全体を機能ごとに工程に分けて、確認作業や管理作業が加えられました。

しかし、機能的に工程分割したので変化への対応が難しくなり、独立した単位で実装を繰り返す様になりました。

共通の方向へ

このように、ソフトウェア開発技術、組織構造、ソフトウェアプロセスは、ピラミッドや管理から自律・協調へと向かっています。これらの流れを読み解くには、細胞をモチーフにしたと言われるオブジェクト指向が参考になるかもしれません。

オブジェクト指向では、オブジェクトをカプセル化して外乱を避け、責務を実施し、それらが協調して、全体が構成されます。そのように考えると、以下のようなものも同じ流れであると思えます。

  • TDDやBDDによって責務が確実に実施し、それを組み合わせる。
  • 集中バージョン管理 から 分散バージョン管理
  • プログラム言語の強い型付きから型なしあるいは弱い型付き
  • デブサミ2013の和智さんの講演にある防火壁によってモジュールや組織、開発チームを守る
  • 仕組みに人を適応させる世界から人に仕組みを合わせる世界へ
  • コマンドコントロールからサーバントリーダーシップ
  • 能力の発揮には、あるいは、アドバイスや教育
  • システム的には交換機のように全体を確定してから実現するのではなく、インターネットのように組み合わせによって全体を実現する
  • 社会的には規制による平等よりも、自由なNPO活動による全体の活性化

このような視点で見ると、別の世界が現れるかもしれません。もちろん、これは一方向のものではなく、機能指向とデータ指向のように振り子の様な揺り戻しもあると思われます。

アジャイル開発やチケット駆動開発もこのような流れで見直すと、単にプラクティスを実践するだけでは得られないさらに多くの効果が得られるでしょう。

【告知】
2013年4月27日(土)に開催されるXP祭り関西2013で上記の流れを踏まえて
「能力を活かすアジャイルの風 ~規律から自律+協調へ~」
と題して基調講演します。ぜひお越し下さい。


« 2013年2月 | トップページ | 2013年4月 »