いつも返却ポストとして利用している図書館で、参加費無料のアジャイルソフトウェア開発のセミナーをやるというので、今借りてる本の返却期限はまだであるが、自転車を30分漕いで行ってきた。
【内容】
- Kent Beck氏からのビデオレター上映
被災した日本の皆様にお悔やみ申し上げますって感じの20秒くらいのもの。
再生後、日本語訳が説明され、それを踏まえてということで、もう一度再生された。 - テクノロジックアートの長瀬氏による講話
後述 - ThoughtWorks社のDavid Joyceという人のオーストラリアからのテレ講演
System thinkingとかLean開発とか - パネル討論会
後述
【長瀬氏のお話】
これまでは、アジャイル開発をやってきた人はオブジェクト指向のプロフェッショナルだったりして、アジャイル開発でうまく行ったという話も、アジャイル開発でなくてもうまくできるような人がやってた。それに対して、最近はウォーターフォールをやってた所がやり始めている。
アジャイル開発を始めるには、まずそこのカルチャーを見極めないといけない。きちんとドキュメントを作ってきた所なのか、インターネット系でオープンソースをばりばり使ってるのか、新しい技術が好きで次々に取り込んでるのか、若い人中心でゲーム感覚で作っているのか。
日本ではアジャイル特有の言葉はあまり使わない方がいい。既存の概念に囚われない目的でそうするものだが、既存の概念を捨て去るのは合わない。
全員がプログラムも設計もできる、というようにするのは難しい。それらは分業することになるが、そうするとオペレーション（イテレーションの周期）が２週間では厳しい。４週間とかになるだろう。
アジャイルにはオブジェクト指向設計が大事。最適な設計はオブジェクト指向設計から。やったことがない所ならオブジェクト指向の教育をみっちりと。
アジャイル導入には、まず手順書を作ること。テストを作ってから中身を作って、とか、それぞれの人の役割をはっきりするとか。それにはじっくり１ヶ月はかかる。
テスト駆動開発はユーザーの要求を漏れなく反映できるかにかかっている。欧米ではそのためのしっかりしたツールがあるが、欧米ではユーザー（顧客）が技術に明るいことが多く、ツールの作りもそれが前提になっている。それに対し、日本のユーザーは漠然とした要求しか出さないケースが多いので注意が必要。
ツールを使ったら使ったで、その内毎日のCI(Continuous Integration)つまり結合と自動テストが夜中に終わらないということも起こることがある。考えるべきことは多い。
拠点が分散しているとツールを使わざるを得ない。しかし、日本ではこれまでアジャイルは1つの拠点で小規模にされることが多かったので、アジャイル特有のツールが広まっていない。
【パネル討論会】
テーマ：アジャイルは失敗するって本当ですか？
パネラー：長瀬さん(T)、細谷さん(H)、永田さん(N)
司会：前川さん(M)
M: 本当です。
アジャイルは今第２次ブーム。
アジャイル宣言から10年、最初は技術者が主体だったが、ちょっと下火になった時期があって、今は経営陣が興味を持つようになってまたブームになってきた。
それ故、十分な知識が持たれないことが増えてきた。
| M: | パネラーの皆さんにとって、Agileとは、一言で言うと？ |
| H: | 開発をマネジメントする為の有効なフレームワークの１つ。 |
| N: | "interplay" （JAZZの用語、誰かがピアノを弾いてる所に、阿吽の呼吸で合わせていくようなこと。 営業でも開発でも、メンバーの誰かが課題やアイデアを持ったら、他のメンバーがそれに合わせて動く、のような意味合い。） |
| T: | 日本のソフトウェア開発を崩壊させるかも知れないもの。 それについていけないと、日本のソフトウェア開発が無くなってしまうもの。 |
| M: | 皆さんにとって、何をもってAgileが成功したと言えるか？ |
| H: | お客様が満足するか、プロジェクトが計画通りに進むこと。 |
| N: | Deliveryを満たすこと。 |
| T: | 日本では、イテレーションが回るようになったこと、開発が楽しそうであることを言うのではないか。 お客様が要求をはっきり言わず、具体的な要求は変化するので、機能追加型で開発できないといけない。その為には、リファクタリングもできないといけない。そこまでできて、イテレーションが完結すると言える。 |
| Q: | アジャイルを始める動機は何が多いか？Waterfallに失敗したから？ |
| T: | Waterfallが失敗したから、と言って相談に来る人はいない。このままではダメになるのではないか、Waterfallだけではだめなのではないか、という感じの漠然とした危機感を持っている人が多い。 |
| Q: | 欧米では、組み込み系と業務用システムで、どちらの方がAgileが成功しているか？ |
| （中略） | |
| H: | ドメインによって違いはあると思う。 ハードウェアまで作り込むとか難しい物理的な制御をするなら、最初にある程度きちんと作らないと、全然動かない。 業務用システムを作るなら、最初は簡単に作って見てもらうことも可能。 |
| T: | 欧米では、開発が相当早い。 CIが活用されていて、毎回3,000のビルドが行われたりしている。 ツールチェーンが確立していて、ストーリーカードから実装、CIまでが繋がっている。 ビジネスアナリストからエンジニアまで、速く作れる体制が整っている。 ビジネス分析者がエンジニアと同じ稼ぎ。 ソフトウェア工学的には、日本はかなり遅れていると思わざるを得ない。 |
| Q: | 管理するツールという面で、Redmineはどうなのか？ |
| A（阪井さん）: | 何の為に使うかによる。ツールはプロセス改善のために導入されるべきもの、何の為にツールを使うかを明確にすることが大事。 |
| H: | Redmineでは、メンバーにある程度マネージメントの権限を委譲できるのが良い。 ガントチャートを更新するというのは結構大変な作業。 但し、より上位のスケジュールとの差異をどう管理するかが問題。 |
| M: | Redmineの失敗事例として、ただチケットを発行して現場任せにして、遅れがあれば催促する、ということをやって、現場の担当者がチケット恐怖症になり、自分からはチケットを発行しないようになったということがある。 |
| T: | ツールを使うのが目的になるのではなく、マニュアル（手作業）でやってみて問題があったらツールを使う、というのが正しい。 欧米ではツールとマニュアルと両方やっている。ツール使いながらストーリーカードが壁に貼ってある。 |
| M: | PDCAを回す（計画を直しながら進める）のとタイムボックスを守るのとの違いは？ |
| N: | Agileはプロセスなのか、プロセス改善なのかという話があった。 Engineeringから見ると、Agileはなかなか大変だと思う。 |
| H: | 不安感が生産性に影響すると思っている。漏れ聞こえる噂に左右される。 タイムボックス化の効果は、2週間は邪魔が入らず集中できること。 |
| M: | 結局、マネージャーが、このメンバーで何が作れるか、どう成長するかをはっきりと予想できるかどうかにかかっているような気がする。 |
| H: | そこまでわかってたらWaterfallでできるのではないか？ |
| C: | 2002年くらいの論文では、Waterfallは見直されていて、2回回せばいいという論文も出ている。 |
| ?: | Waterfallの知識が無いとAgileはできないと思う。Waterfallは、プロジェクト検証の過程が無いのが問題なだけではないか。 |
| H: | WaterfallでもAgileでも、実行可能だと大多数の人が思っている計画しかうまくいかないというのが真実ではないかと思っている。スキルが上がると、Waterfall力がついてくる。 |
| Q: | Agileって儲かるのか？ |
| T: | 儲からないと思う。 ユーザーから見て、Waterfallは途中が見えないから博打、Agileは見えるから安心ではある。開発とユーザーとの信頼関係は上がる。しかし、Agileは失敗したらユーザーの責任になることがあまり理解されていない。 |
| M: | これからAgileを始めたい人に一言 |
| H: | 失敗する所はちゃんとわかってやらないから失敗する、という話もあるが、興味あるならやってみれば良いと思う。 |
| N: | 海外の人は、AgileはEngineeringだという意識が強い。だから進んでいる。 Lean開発の目的がqualityになってるのがやっぱり凄いと思った。 |
| T: | 大手は大体そのどこかではやっていて、失敗した経験も持っているので、今後は失敗は減っていくだろう。 最初から失敗したくなかったら、コンサルタントを雇うとか、金が無かったら、こういうセミナーで擬似的にやってみるとか。 |
| Q: | 外注さんが含まれる場合、どうお願いすればいいのか？ |
| Q: | 詳細設計ってどうやるのか？ |