イベント
Agile Conference tokyo 2010 終了のご報告
株式会社テクノロジックアート
2010年7月21日、秋葉原駅の目の前の秋葉原コンベンションホールで、弊社主催のAgile Conference tokyo 2010が開催されました。
300人の定員でしたが、当日はほぼ埋まっていましたので、かなり出席率は高かったと推察します。
継続的デリバリー
最初は、ThoughtWorks社の Jez Humble 氏による基調講演です。
継続的結合(CI)の概念を越えて、頻繁にデリバリーを繰り返す継続的デリバリー(Continuous Delivery) についてご説明がありました。
デリバリーを早くする為に、Always Production Ready という体制を維持するとのお話がありました。何か変更した場合には、毎回細かくフィードバックを得られるようにすること、かつそれが全員に行き渡ることが大切とのことです。
継続的結合(CI)では、常に非同期でビルドを繰り返し自動化されたテストを走らせて、デグレードを検出します。Always Production Ready にする為には、非機能要求まで含めたリリースに必要な全てのテストを自動化し、全ての段階で実施して、常に信頼できるものを用意することが必要になるとのことでした。
その為には、deployment pipeline と呼ばれるリリースプロセスの整備が必要で、導入に役立つ実践的な工夫を何点かご紹介されていました。
例えば、継続的デプロイの3つの原則として、以下の3つを挙げていました。
1. ロールバックせずに、再デプロイする
2. 職人作業(属人的な作業)「work of art」を破壊する
3. 抜け道(例外)をなくし、全ての変更が同じプロセスを経るようにする
他にも青-緑デプロイやカナリアリリースといった、リリースに関するテクニックの話もありました。
印象的だったのが、これらの徹底的な自動化の鍵を握るのは人間であるとのことでした。リリースに必要なテストや作業をプロセスとして整備して自動化を進めるのは、一朝一夕では実現できるものではありません。人間による、継続的な改善(continuous improvement (kaizen)) が成功の為には欠かせないとのことです。
適切なツールとノウハウの導入に加え、やはりアジャイルマインドを持った、自律的な組織及び人材の育成こそが、成功の秘訣であると思います。
ALMソリューション
日本IBM の大澤浩二氏のご講演です。
アジャイル開発を適用しにくいと言われる受託型開発のSI案件について、様々な悩みとその解決策をご紹介いただきました。
(1) 要求確定に時間がかかる
(2) 作業状況が見えにくい
(3) 受け身型の開発スタイル
(4) 報告までの時間がかかる
それぞれ、アジャイル要求管理、バーチャルタスクボード管理、プロセスエンアクトメント、リアルタイムレポートといったキーワードで、ツールをベースとしたソリューションを提示されていました。
ツールは、手段にすぎませんが、上手く使いこなすことで、これまで到達不可能であった状況へと組織を導くことができます。適切に導入することが大切であると改めて感じました。
アジャイル開発の現状と今後
午後の最初には、特別講演として、IPAの松田晃一氏の講演がありました。
非ウォーターフォール型開発の調査研究を踏まえて、日本の現状のご紹介と、今後のアジャイル開発の普及に向けて取り組むべきポイントについてご説明されていました。
以下の4つの観点で整理されており、とても分りやすい講演であったと思います。
1. 適切な開発モデルの選択・組み合わせを考え、モデルを開発する
2. 外注における契約問題について整理する
3. アジャイル手法の理解と促進
4. 管理手法や技術面での環境整備
個人的に関心があったのは、アジャイルの理解・促進の障壁として、海外・国内共に文化の問題がトップに挙げられた点です。新たなパラダイムと言葉で言うのは簡単ですが、実際にこれまでの考え方を変えようとすると、個人の習慣から人間関係、組織から産業構造に至るまで、様々な局面で変化を求められます。目先の手法が変わるのではなく、考え方自体が異なるということをきちんと説明して理解を求めてゆくことが大切なのだと思います。
大規模システム向け日本版アジリティ開発手法「COMMONDATION-ReeL」
日立SASの英繁雄氏からは、大規模日本向けのアジリティ開発手法である「COMMONDATION-ReeL」のご紹介がありました。日本の大規模SIの現場では、様々な制約からアジャイル開発手法がそのまま適用できないとのことで、アジャイル開発手法のメリットを取り入れた、新しい日本向けの開発手法を開発されたそうです。
これまでの日本のアジャイル開発の普及状況は、如何にアジャイル開発手法を日本に適用させるか?という点で苦心してきました。いっそのこと、アジャイル開発手法をそのまま導入することを諦めて、既存の手法に良いところだけを取り入れようというのは、これまでも各所で行われてきたことだと思います。ですが、各社の工夫としてTips的に発表されているにすぎませんでした。
今回の発表は、それを体系立てて整理したという点で意義のあるものだと感じました。具体的な反面、日立システム様固有の事情が反映されていますので、そのまま使うことは難しいかもしれませんが、今後、アジャイル導入を検討する企業に一つの尺度を提供するものになると思います。
また、最後には、日本発のアジリティ開発手法を発信してゆこうとの呼びかけがありました。個人的には、このように旗を高く掲げる講演があると、非常にうれしく思います。
Going Agile With Tool
マイクロソフトの長沢智治氏の講演です。
アジャイル開発でのツール適用のポイントをご紹介いただきました。Visual Studio Team Foundation Server 2010 をベースにしています。
手慣れたもので、デモとスライドを織り交ぜながらのスムーズな講演でした。
プロセスの要所要所における、ツールの利用可能性について説明されていましたが、何といっても、Excel との連携が印象的でした。普段から使いなれたツールをフロントエンドとして使えることは、導入の教育コストや精神的な抵抗感を軽減するという意味で、非常に大きなアドバンテージだと思います。
アジャイルはじめの一歩
NECソフト株式会社の飯田治行氏から、導入事例のご紹介がありました。
自分達で工夫をしながら、現場主導でアジャイル開発手法を導入及び推進をされているそうです。失敗を繰り返しながらも、試行錯誤と情報発信を続けることで、ついには社長をも動かして、アジャイル社内標準化計画をトップダウンで進めるところまで持ってきたとのことでした。やはり現場力がアジャイル推進には欠かせないのだと、改めて感じさせられました。
また特に印象的であったのが、とにかくアジャイル開発は「楽しい」とおっしゃっていた点です。3K、4K等と言われるソフトウェア開発の現場ですが、もの作りの「楽しさ」を体感できるところがアジャイル開発の大きなメリットの一つです。
トークセッション
まず1部では、弊社長瀬からアジャイル開発QIMP研究会の研究報告について、ご紹介させて頂きました。本研究会は、2009年10月から4回にわたり、メーカー、SIer、製品ベンダーなどの有志により大規模アジャイルプロジェクトにおける課題への対応策、課題解決の考え方を検討しました。これを成果報告としてまとめましたので、これからアジャイル開発を始める方や、導入を検討している企業、担当者の方などに参考して頂ければと思います。
2部では、本日ご講演いただいた方々にご登壇いただき、トークセッションが行われました。日本IBMからは、大澤氏にかわり、榊原彰氏がご参加されています。
3つのテーマについて、それぞれご意見を頂戴しております。
まず、1つめのテーマは品質についてです。
Jez氏が日本はウォーターフォールで高品質なソフトウェアを作ることのできる世界でも珍しい国であると言っていたのが面白かったです。
アジャイル開発では、みなさん異口同音にスモールリリースが品質の要であるとおっしゃっていました。早期にユーザ確認をすることで、要求仕様と実装の乖離を検出できるだけに留まらず、要求仕様の妥当性の検証を具体的なソフトウェアを使ってできるところが大きいのでしょう。
2つめのテーマは、大規模アジャイルについてです。
MSの長沢氏には、小さくチームを分割することで、アジャイル開発を適用しているMSの事例をご紹介いただきました。日立システムの英氏は人材育成の重要性を挙げていました。IBM の榊原氏は、SIにおける大規模アジャイルの難しさを指摘されていました。プロダクト開発に比べて、SIでは規模の桁が一ケタ大きくなり、そこに難しさがあるとのことでした。大規模になり開発を小さい単位で切ったとしても、インターフェイスの複雑化や欠陥除去の問題が顕在化する。また小さくすればするほど、各開発単位毎の生産性の違いが顕著となる。スコープの変動により管理の難易度はあがるので、スコープ変動をどのように抑えるのかの手法が見いだせていないとのお考えのようです。
個人的には、Jez氏が指摘されていたコンウェイの法則が興味深かったです。組織の構造がソフトウェアアーキテクチャの構造に影響するというものです。結局、大規模のソフトウェア開発は、どのような開発手法を使っても難しいのです。しかし、できあがるソフトウェアの構造の善し悪しは、組織のコミュニケーションの善し悪しで大きく影響を受けることは、過去の事例から明らかです。小さく分割したチームを、きちんと構造化して、コミュニケーションを良くすることで、小さなコンポーネントがうまく連動する構造化されたアーキテクチャが実現できる、としています。つまり、組織作りが大切なんだ= 人が大切である、ということを強調されていたのが印象的でした。
3つめのテーマは予算の話でした。
Jez氏から、ThoughtWorksのやり方をご紹介いただきました。
予算=予測で、決して正しくはない。外れることが当たり前なので、小さく作って、外れた時の損失を小さくすることが大切という考え方に立ちます。大規模開発においては、まずはお金の話をする前に、プロジェクトがどのようなものか、2～4週間じっくり話合うそうです。ワーキングプロトタイプを作り、イメージを確認しつつ、お客様との信頼関係を構築します。4週間このような作業を行った後、3ヶ月くらいのプロジェクトを契約する。このタイミングになるまで金額は提示しないそうです。とにかく信頼関係を構築することが大切であると述べていました。
対して、日本の皆さまは、特に現状のSIでは、製品開発と異なり、全体予算の枠を抑えざるを得ないというのが、実情であるという認識でした。
やはり、アジャイル開発手法の導入とは、組織作りであり文化の育成でもあると言えます。簡単に変わるものではありませんので、いまから組織の変革を進めることで、先進的なアジャイル開発手法を導入する素地を固めることが大切であると考えます。
その他カンファレンスの模様
関連リンク