本音で考えるアジャイル

いろいろな

アジャイル

アジャイルの

宣伝

アジャイルと

コミニュケーション

アジャイルのスピード

アジャイルとウォーターフォール

アジャイルの

テスト駆動開発

アジャイルと

テスト

アジャイルの

プラクティス

アジャイルと

ドキュメント

アジャイルと

スキル

アジャイルの

管理

アジャイルという

システム

アジャイルの勤務時間

アジャイルと

大規模開発

アジャイルと

日本人

XP

スクラム

リーン開発

RUP

一つではないので、

いろいろな説があります。

用語も統一されていません。

混乱しないようにしましょう。

アジャイルの宣教師たちは、

大変宣伝がうまいです

単に事実を説明すれば終わりと思っているような技術者ではありません

ただしそのため、

誤解を生んでいる部分もあります

ドキュメントを書かないなんて

いったい誰が言ったのだ、

とかいう羽目になっていたり。

そろそろ愚直な技術者向けに

本音で話す資料も必要なのでは？

矛盾している？

自由

個人個人が、開発をうまく進めるために必要だと思うことをなんでも行う自由

規律

個人個人が、開発をうまく進めるために必要な規律を考え、守る

言っている事をそのまま聞かず、

言いたいことを想像するようにしたほうがよい

各種プラクティスも

それを前提としたものが

多いです。

スピードが大切

生産性とは少し違う

生産性は、

ウォーターフォールと

そんなに変わらない

• ３分で処理する

• ５分で処理する

• すぐとりかかって５分で処理する

• 書類がたまっていて、取りかかるのは３日後

大切なのは

リードタイム

この辺の理屈は

リーン開発などで

よくわかる

類似の労働で世界を支えた人々

• ２倍の賃金で募集されたT型フォード製造労働者

• 高度成長期の日本を支えた労働者

• 大国の官僚

アジャイルとの共通点

古いウォーターフォールと、

新しいアジャイルを

比較していることが多い

ウォーターフォールで新しく導入されたプラクティスのうち、多くがアジャイルに取り入れられています

自動テスト

リファクタリング

汎用機時代から一部の天才などは本能的に行っていたようです

各工程における徹底的なピアレビューを行うことにより、品質の大きな向上が見込まれます。それによる生産効率の向上はピアレビューの工数を上回り、結局はピアレビューをした方が開発は早くなることが、古くから指摘されています。

IBMによる

インスペクションの提唱

レビューの時間は多ければ多いほど品質が上がり、ひいては生産性が向上する。

いっそプログラムしている間、レビュアーがずっとつきっきりでいればいいんじゃ？

世の中にはウォーターフォール開発が向かない事例もあります

変化の早い開発

世の中全体の変化は速くなってきています

中小企業ならなおさらです

ウォーターフォールしか選択肢がないのはまずいのでは？

顧客との

コミニュケーション

顧客の望む機能

頻繁なリリース

常駐

変更はいつでも受け入れる

実際に作れないと

意味ない

修正に次ぐ修正

できるなら

ウォーターフォールでも

やっている

アジャイルに向いた

修正に強い

開発技術

テスト駆動開発

単体テスト

実装

内部設計

に相当するもの

テスト駆動開発

全体はアジャイルではなくても

個人で管理できる単位なので、

導入が行いやすい。

テスト駆動開発の名前

どれも大体同じです

• テストファースト

テストを最初にすればいいんだろう？

• テスト駆動開発

なんだかんだ言ってもテスト技法なんだろう？

• ビヘイビア駆動開発

振る舞いを記述していくことで開発を駆動するんです！！

テストファーストの頃から

テストは振る舞いを書くようにとか、

テストで駆動することが大事なんだとか、

いっていたと思うんですけどね。

アジャイル以前から何が変わった？

テストを

自動化する

一部では昔から

行われていました

効率化

テストを

100％

自動化する

ボタン一つ押すだけで

テストと結果チェックまで

ボタンすら押さなくても

勝手にテストして

結果をチェックして

報告メールを送りつけてくる

好きな時に好きなだけ

テストができる

遠慮なく

コードを修正できる！

リファクタリング

コードの可読性が

いくらでも上げられる

コードがドキュメント

コードの拡張性が

いくらでも上げられる

YAGNI

テスト駆動開発

開発技術

テストではない

テストも充実する

総合的に従来のテスト以上

• 簡単に再実行できる

• 行カバレッジ100％

• 受け入れテストまで自動化

これでもういいんじゃ？

ただし

従来のテスト技法は

生かせません

ホワイトボックステストとか

ブラックボックステストとか言われても、

コードの前にテスト書くし

アジャイルには

たくさんのプラクティスがあります

週40時間労働

全部導入する必要は

ありません

状況を考えて

導入できるものを

Ruby on Railsが開発された時

アジャイルで開発されたと思われる

アジャイル開発の見本のようなフレームワークですし

アジャイルでは、メンバー同士や顧客とのコミュニケーションが非常に重視されます。常に顔の見える状況で、声をかけられるような状況にいることが求められます。

なのですが

メインプログラマーである

David Heinemeir Hanssonは

在宅勤務でした

会社所在地

アメリカ イリノイ州

シカゴ

自宅

デンマーク

アジャイルには、

工夫次第でどうにもならないことなど、

なにも無いようですね。

そうなんですけど

どれでも好きな組み合わせで使えるなんてことは誰も言ってないですよ？

一部導入した時にうまくいくかどうかは確認しないとわかりません

全部導入は上手く行った実績があります

たとえば

ペアプログラミング

効果が3つあります

ペアプログラミングを

導入しないなら一つ一つに

対策が必要です

• レビューとして品質を確保する

体系的に徹底的な

レビューを行えばよい

• 知識の共有のため

たまにペアで行えば済む

• 割り込みに強くなる

どうしたらいいかわからないが

どうせ現在そんな

プログラムに集中してないし

たとえば

リファクタリング

自動テストなしには

大変難しい

たとえば

コードがドキュメント

リファクタリング

なしには無理

それぞれのプラクティスの影響と、代替え手段を知り尽くしてないといけない

いっそ全部採用した方が楽なんじゃ？

アジャイルは

ドキュメントを書かない

と言われてました

最近はむきになって

否定しています

ドキュメントを

書くべき時は書く

ですね。

本当にそのドキュメントは

必要ですか？

ドキュメントの保守工数まで考えてますか？

すでにいないメンバーが、

ドキュメントを残して行ったので、

保守しなくてはならない。

うれしいですか？

悲しいですか？

もっと喜ばれる方法は

ないですか？

コードが

ドキュメント

わかりやすいコードがあれば、

設計書はいらない

どうせみんなコードのほうを信用しているし

今まで通りコードを書いて、

これがドキュメントだと言い張ればよい。

なわけがないです。

簡単じゃないですよ？

文字通り、

ドキュメントとして使える

コードが必要

日本語の文章で書いた

ドキュメント以上の

可読性、保守性

• 実行コード

内部設計書

• テストコード

外部設計書

コメントは邪魔

というくらいを目指します

リファクタリング

設計＝コードの推敲

文章の作文でも、

文章を書いたら書きっぱなしでは、

わかりやすく書く技術は

上達しません。

同じ文章を、

わかりやすく書くためには

どうしたらいいか、

何度も何度も書き直すことで、

上達します。

これは個人的な意見ですが

日本語識別子の推奨

少なくとも、覚える期間は

わかりやすい

文章の書き方の練習を、

外国語でしよう

ってのは無理。

DRY

ただし、

これらを行うことにより、

ドキュメントを書く量は減りますが、

考えること、伝えることは減りません

優秀な人じゃないと出来ない？

違うとあちこちで言われています

「僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。」

ケント・ベック

そもそも、すごく優秀である必要はない

プログラムの複雑さは

どんどん増大

自分の頭の回転に頼っているようでは

あっという間に限界が

難しいことを

簡単にできるようにするのが

プログラム技術

アジャイルでは、

全く別のスキルセットが

必要とされる

今まで優秀と言われていた人が

何もできなくなることもありうる

だから難しいとか思われているんですかね。

管理も

変化に対応することが

必要です。

アジャイルではない場合

計画をうまく立てる優秀な人

細部まで細かく計画を立てる

WBS

特に規模が大きくなった場合、

これは極めて変化に弱くなります。

昨日の天気

ある国が、精密な天気予報コンピュータシステムを構築することを決めた。数え切れないくらいのお金を費やした後、彼らは素晴らしい結果を出した。そして、高らかにこう言ったのだ。このシステムの精度は70%である、と。

ところが、誰かがあることに気が付いた。この国で「今日の天気は昨日の天気と一緒だ」と予報すれば、69.5%の確率で当たる、と。

「Martin Fowler's Bliki in Japanese」より

管理の精度は、

管理にかけたコストには

比例しない

要領よく

やらないとね

変化に対応するコストを

最小にする方法で

• 管理しなくていいものは管理しない

タスクの優先順位はその場で決める

イテレーション単位の時間数は一定

進捗が遅れたら無理せず遅らせる

• ただ粛々と、速度（べロシティ）を測り、遅れる原因があれば取り除く

XPなどのアジャイル開発手法は、

かなり考え抜かれたシステムです

朝会

朝会は短くしましょう

と言うだけではなく

朝会は10分以内にしましょう

と言うだけでもなく

朝会は立って行います

と言う

自然と短く

必要があれば、自然に少し長く

まあ我慢強い日本人の場合は、もう一工夫いるかもしれませんけどね。

タスクの見積り

絶対時間ではなく、

前回と比較してどのくらいか

その方が、直感的に精度良い数字を出しやすい

のいずれかの数字で見積もる

• 5か6かを悩むのは無駄
• 13か16かを悩むのも無駄

• 選んでよい数字はなんだったか、覚えるのも簡単

1,2,3,5,8,13,21

何をしたいかの目標だけでなく、何をすればそれが自然に実行できるかまで、細かく考えてある。

もう実に細かいですね。

週40時間労働

一定時間内にどれだけの作業ができるかを重視

終わらないから残業すればいいやとかいうルーズな思考はもともと合わないのですよ

的確にラップを刻んでいく

週40時間労働の真の意味は、

そういうことではない

週40時間燃焼!!

週40時間

完全燃焼！！

ペアプログラミングなんかを活用して、

残業なんかできないほど疲れ果てるほど集中する

楽じゃなさそうですね

楽しそうですけどね

アジャイルでは

大規模開発はできないと

言われます

現状では

それは不正確です。

300人規模のプロジェクトの

実績があります

世界トップクラスの

アジャイル技術

をもってすれば可能

残念ながら、ノウハウが広まっているわけでもないです

ThoughtWorks

マーチン・ファウラーがいるところ

XP

アメリカっぽいです

リーン開発

日本人にも合ってます

そもそも元はトヨタ式

提唱者の一人、メアリー・ポッペンディークは、アメリカの工場でトヨタ式を導入した経歴の持ち主

5S

ムリ・ムラ・ムダ

カンバン

PDCA

もともと、

日本で花開いた方法論の

逆輸入

向いてないってことはないはず

• 日本人は保守的にも思えますが

• まわり見てあわせるのでまわり中が変化しようという雰囲気になると、一気に革新します

明治維新

戦後の復興

• いずれアジャイルも普及していくのではないでしょうか？

御清聴ありがとうございました

デミング博士

Crystal Clear

• XP

• リーン開発

Adaptive Software Development

ユーザ機能駆動開発

Dynamic Systems Development Method

同僚と

顧客と

まず

コミュニケーションが

大切です

リードタイム

一枚の書類を受け取った時

生産性

一枚の書類を受け取った時

本音で考える

アジャイル

そこまで悪いものでもありません。

むしろ

先人の叡智

• 非国民
• 反革命分子
• ウォーターフォール

ペアプログラミング

You ain't gonna need it

いずれ必要にはならない

変化に

とても

強くなる

コミュニケーション

スキル

難しいプログラムを

簡単に作れるようにする

技術

新しいことに

挑戦する姿勢

Don't repeat yourself

同じ作業を繰り返さない

訂正にかかる労力と

ドキュメントの質は

反比例します!!

多重保守は

絶対に避ける

変化に強い

考え方

イテレーション

テスト駆動開発

メタファ

ペアプログラミング

リファクタリング

YAGNI

ソースコードの

共同所有

短期リリース

継続的

インテグレーション