アジャイルがそんなにダメだと思わない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 を使ったプロジェクトが、おいしいカレーを食べられることを祈る。
なぜ Coderetreat に参加するのか。
プログラムを書くのを仕事としていると、締め切りとは無縁でいるわけにはいきません。
もうちょっとコードを書き換えたい、不要なコードを消したい、ちょっと設計を変えたい、いろいろなことを思ったとしても、締め切りがあるのでまずは動くコードを書いてしまいます。そのたびに、ちょっとだけコードの品質が下がっていきます。ちょっとだけ。
・これくらいのコードなら、まああとでメンテできるから大丈夫
・この設計はまだちゃんと動くか確認できていないから、まだ実システムに使うのは早い
・ここは OX を使った方がよさそうだけれど、実際に使ったことはないから、いつまでかかるかわからない。
そんなことを言い訳にしながら、実際のコードはだんだん汚くなっていきます。コードの汚さにもだんだん慣れてきて、そのうち汚さにも気付かなくなっていきます。
Coderetreat は、朝から晩まで45分のペアプロセッションを６回も繰り返します。しかも毎回ペアが変わります。ペア持っているスキルは毎回変わりますし、そもそも同じ言語を使えるかどうかもわかりません。問題は毎回コンウェイのライフゲームですから、だんだん問題に対する理解は深まっていきます。
Coderetreat は、課題を終わらせることが目標ではありません。よいコードを書き、よい設計をすることが目標です。始めてペアを組む相手と、よいコード、よい設計とは何かを話し合いながら、実装しつつ試してみましょう。ファシリテーターがちょっとお手伝いをします。コードを動くようにできないこともあれば、結果としてひどいコードになることもあります。でも、問題ありません。４５分のセッションが終わってしまったら、コードは削除されてしまいますから。
締め切りのある現場に戻ったとき、ちょっとだけ品質を下がるのを避けられる、ちょっとだけコードを良く出来る、ちょっとだけ速くできるようになる。そうなれば、仕事のコードもちょっとだけ良くなっていくでしょう。あ、ペアプロもきっと、ちょっと上手になっていますね。
あ、Coderetreat には必ずおいしい昼食がついています。そちらもお楽しみに。
2012/12/8 は、Global Day of Coderetreat が開催されます。いまのところ150を超える場所で開催される予定です。
View GDCR2012 in a larger map
Deep Agile People で考えていたこと
一週間ちょい経過したので、Agile Japan 2012 で参加させていただいた Deep Agile People について、何を考えて話していたかを、ちょっとメモを残しておこうと思います。
細谷さん、森崎さんに、企画からコメントからいろいろと助けて頂きました。あれがなかったら、単なる酔っ払いトークだった気がするので、大変ありがたかったです。DevLove HangerFlight のときのビデオを提供頂いた富田さん、あのオープニングを編集頂いた(あ)さん、ありがとうございました。
あの場に参加頂いた皆さんに感謝します。ぜひ今度は本当にビール入りでやりましょう。
- 方法論者ではなく実践者でありたい
Scrum や XP などの方法を、枠組みとして定義する人々はものすごい苦労をしてまとめています。いろいろな状況に対応できるように、改善や推敲を重ね、ようやくできるようなひとかたまりのやり方のかたまりになります。すばらしいと思います。
ただ、その方法論を実際に使おうとする場合は、方法論者のまねをしてもうまくいきません。
自身で気をつけているのは、自分でその方法論の弱点を説明できない、もっと単刀直入に言ってしまえば、自分でその方法論を dis れないうちは、その方法論は使わない、ということです。もちろん、その弱点は方法論を適用する状況、現場によりますから、その弱点を現場と切り離して議論することはやりません。簡単に空中戦になっちゃいますからね。
方法論やプロセスをあらたに導入しようとする場合は、もしそれがなかったら何が起こるか？どうやったらこの方法論の利益を破壊できるか？を考えるとよいと思っています。もちろん個々のプラクティスでも。
- 書いていないことには意味がある
Scrum や XP みたいな方法やフレームワークもそうですし、DDD の方法自体や、それで書かれたドメインモデルにもいえることなのですが、そこに書いていないことは、重要な意味があります。
Scrum には技術プラクティスは書いてありませんが、技術を軽視しているわけではありません。Scrum の場合は、元々 SmallTalk の技術方法論が含まれていたのですが、あるとき技術プラクティスは除去するという判断がなされて、今の形になっています。XP にも、もっとマネジメントのプラクティスが含まれていたはずです。ドメインモデルには、ドメインモデルをつかってなにかをよりよくしたいと考えているモデラーの視点は含まれることはありません。
そこに書いていないことは、作成者が利用者を信頼して、自分で考えて欲しいということを願った場所です。その成果をよりよく使ってもらうために。批判があっても、あえて除いたところ。そこで自分で考えることを外してしまったら、どんな方法論もモデルもうまく使えないでしょう。
利用者を信頼せず、考えてもらいもしなかった方法論がどうなったか、ここで批判するのはやめておきます。
どうもありがとうございました。何かの役立てていただけたら良いのですが。コメント、ご意見、ご批判はいつでもどうぞ。お待ちしております。
さて、続きはいつやろう？＞川端さん、牛尾さん
Jenkins 蛙本
Jenkins 蛙本の献本をいただきました。ありがとうございます。
チケット管理システム大決戦でご一緒した、@ikeike443 さんのご厚意です。
ちょうど第二回大阪Jenkins勉強会で、翻訳者の玉川さんとご一緒だったので、非常にタイムリーでした。
チーム用にも予約していたので、まもなくそちらも届くかな。
他の書評にある通り初心者向けの本ではありません。インストールや設定手順も説明はあるのですが、第5章のビルドジョブのセットアップあたりから、いきなり実践編に突入します。著者も翻訳者も、だいぶ Jenkins を使い込んでいそうです。
自分では第10章の高度なビルドと第11章の分散ビルドが参考になりました。パラメータ化ビルドやマルチ構成ビルドジョブは、現在一緒に仕事をしているチームがいつも苦しんでいる課題を解決するのに役立ちそうです。
第12章の自動化デプロイメントと継続的デリバリの章も短いですが適切にまとまっています。第12章を読んでから第10章、第11章に戻れば、なぜそのような高度なビルドを行おうとしているかが理解できるのではと思います。さらに知りたくなったら来月発売の継続的デリバリーを読むと良いですね。
お約束ですが、ツールがチームの生産性を高めるわけではありません。チームの継続的な改善努力があって、その上でツールを使うことが非常に強力な助っ人になるということです。チーム開発では、チームが単一の作業成果物に対して協力して作業を行うことが重要です。それを思い出させ、そうなっていることを確認するために Jenkins はとても有効ですし、その Jenkins を使いこなすのにこの本はとても有用です。
付録Bのプラグインの開発は、@ikeike443 さんが書かれているのですが、Jenkins が動く仕組みがうかがい知れて楽しいです。Trac はほぼプラグインなしで使っていますが、Jenkins はいろいろプラグインを使って使うことになるかなと思います。
P.S. XFD などでチームに「見えなくできない化」を進めている身としては、Remote Access API の使用例などがもうちょっとあると嬉しかったかな。
Arduino で Jenkins の XFD を作る
というお題で、第二回大阪Jenkins勉強会でデモをしてきました。
Arduino jenkins
View more presentations from Kiro Harada.
Jenkins がせっせとビルドしてエラーを報告してくれるのは助かるのですけれど、やっぱり忙しくなると見に行かなくなってしまうのですよね。パトランプなどの実体のあるデバイスを置いておくのは、やっぱり有効です。
タスクボードやバーンダウンチャートは、まずは紙！という感覚とも近いのかもしれません。
Arduino のデジタル８番ピンを、リレーの制御に使っています。
今回利用したArudino やリレーなどは、Strawberry Linux で入手できます。
はじめての場合は、Arduino はじめようキットなどのブレットボードとセットになったものが良いかと思います。
まずは、LED の点滅などで Jenkins の状態を確認できることができてから、リレーを接続して、いろいろなデバイスをつないでみると良いでしょう。AC100V を使うときや、大電流が流れるランプなどを制御するときは、感電に注意して、必ずヒューズやポリスイッチを使ってください。
面白い XFD ができたら、ぜひシェアしてください。
Enjoy Making.
P.S.
Aruduino で、こんなのも作れます。楽しいですよ。
デイリースクラムで ScrumMaster がやるべきこと
デイリースクラムのやり方は、いろいろなところに書いてあるし、チームによっていろいろ工夫をしていると思うので、ここでは書かない。
Scrum Guide にも書いていないけれど、ScrumMaster が絶対にやるべき重要なことがある。
メンバーの顔色を確認することだ。メンバーの体調を計測することだ。それだけでも、ScrumMaster がフルタイムの役割である十分な理由がある。
メンバーの体調は、常に気を配っていないと気付くことはできない。デイリースクラムの３つの質問に気を遣うと同時に、ScrumMaster はメンバーの体調についても十分注意を払う必要がある。
どうも風邪薬や栄養剤のCMのおかげで、体調が悪くても会社にいくべき、のような風潮がある。でも、この時期、インフルエンザのメンバーを一日出社させてしまったら、そのスプリントは終わりだ。チームが全滅するだろうし、他のチームにも迷惑をかける。
熱っぽくて、咳き込んでいるようなメンバーが出たら、まず帰らせて休ませよう。
ある建築会社の PM の方から、「メンバーにけが人を出したらPM失格」と言われたことがある。ScrumMaster は PM ではないけれど、この部分の責務は一緒だ。
もちろん、自身の体調管理にも気をつけて。
