IBM Rational Software Conference 2009レポート
IBM Rational Software Conference 2009
先日、IBM主催のカンファレンスに参加してきましたのでそのメモです。開催日は台風18号が日本列島を通過した日で、私もずいぶん余裕を持って自宅を出たにもかかわらず途中で足止めをくらい、到着したのはキーノートの開始直後でした。公演者の方の一部には時間通りの到着が難しかった方もいらっしゃったようですが、セミナー自体は大きな混乱もなく無事開催されていました。
最近アジャイル開発手法に興味があり少し勉強しているのですが、手法は勉強できてもやはり大規模開発に実際にどのように適用するべきなのかという点で気になることが多いところです。今回、セッションにIBMとMicrosoftのアジャイル適用事例があることに興味があったので行ってきました。カンファレンスの名前の通りIBM Rational製品のプロモーションメインの雰囲気ではありましたが、いろいろと得るものがあって面白かったです。Rational Team Concertはなかなか気になるプロダクトで、今回から10ユーザまでは無償（v1は3ユーザまでだった）とのことなので使ってみたいと思っています。
セミナー概要・背景
基調講演1："Innovation Today" (IBM Neeraj Chandra氏)
- IBMでは"SmarterPlanet"を推進している。機能化(全てのものの状態を把握する)/相互接続/インテリジェント(変化にすばやく対応し将来のイベントに備えて性格に最適化)
- 接続されるデバイスが1兆個を越えると世界は10倍機能化する。
- 地理/組織/インフラ的バリアが存在しており、そのバリアにより人・プロセス・プロジェクトがサイロ状になる。
- Jazz：コラボレーション/自動化/レポート（リアルタイムな進捗測定）
- "Ratuional Software Delivery Plarform"をクラウド上でβサービスを予定。IBM Smart Business Cloud上でホスティング。
- 仮想化+標準化+自動化=コスト↓柔軟性↑
- rationalの規模はIBMに買収された7年前から比較すると3倍に拡大
- Measured Capability Improvement Framework（MCIF）
- ソフトウェアの投資に対するビジネスの結果を重視し、ソフトウェア開発をビジネス・プロセスとして捉え、それを継続的に改善していく枠組み
基調講演2："Making It Real" (IBM Walker Royce氏)
- Rationalはソフトウェアのベストプラクティスを提供。自分が過去学んできたこと。ソフトウェアはエンジニアリング的な規律より経済的な規律に起因する。世の中の複雑性・不確実性にどう対応するか。
- ソフトウェア開発からソフトウェアデリバリーへと価値観を変える必要がある。開発はビジネスプロセスとなりつつある。
- では不確実性にどう対応するか。スケジュールを伸ばしてもらう→NO。スコープを狭くする。品質を犠牲にする→NO
- 不確実性や計画の差異となる原因を特定し、影響を削除する。プロダクトのライフサイクルを通して差異を削減し、出荷予測を確実にする。
- 測定が重要。ソフトウェアの世界において不確実性を把握するために。
- 計画のパラメータは全て変数（不確実性を持つ）という考え方とする。
- "アジャイルガバナンス"="不確実性の管理"="差異の管理"
- 完了日ではなく、時点ではなく確率分布である。
- スコープは要求文書ではなく交渉の連続である。
- 計画は規定ではなく進化し変化する目標である。
- 最終的には"実行できるコード"が全てであり、それ以外は副次的な要素に過ぎない。
- MCIF。Jazzとして実現。開発環境のSOAのようなものである。
- 参考：システムの納期とは確率分布だ － Publickey
基調講演3："Evolution of Jazz Platform" (IBM Scott Rich氏)
- ソフトウェア開発技術基盤であるJazzの開発状況と今後の方向性。
- Jazzは2004年にビジョン提唱。2007年まではJazz.netなどJazz自体の構築に専念。
- 2008年に第1弾の製品(Rational Team Concert,Rational Requirements Composerなど)をリリースし、2009年度に第2弾のリリース。より大規模な製品統合に着目している。
- TeamConcertServetは今回10人までのExpress-Cは無料としたこと、また最大ユーザ数を無制限としたEnterpriseのエディションを提供している。
- 今後、"IBM Rational Software Delivery Services for Cloud"としてクラウド環境で機能を提供する予定である。
C-1：初挑戦で大成功！?人を育て、人を高め、進化する組織を作る開発スタイル(株式会社戦略スタッフ・サービス 三井 伸行 氏)
- ウォーターフォール型開発の体験しかなかった開発チームが初挑戦で見事に、制度改訂向け財務会計システムの受託開発を成功させた事例紹介
- 自己紹介：コンサルティング会社、岐阜県のソフトウェア開発力の強化も。今回はプロジェクト自体の話ではなく、開発している人、運用に焦点をあてた。
- OJTでやっていくのが基本的、地元IT企業、請負の底辺に近い（3次、4次）人のお話。
- アプリ概要など
- 単式簿記→複式簿記にするシステム。
- いわゆる通常のWebシステム、12末納期
- XP、スクラムを運用して開発。
- コアエンジニア2名。サブ1名でスタート。ワークロードにあわせて最大6名のチーム。
- bug175件中、2日以内に修正122件。
- リリース後仕様変更対応8件。
- 新メンバを入れて手法になれるまでに4週間かかったが、その後は安定したタスク消化数をだせている。1イテレーションあたり157時間の稼働時間。夕方5時以降は新しいタスクはとらない（残業しない）
- 毎月リリース。一度リーダがトップスピードでの開発（残業あり）を1週間実施。そのチームのポテンシャルを把握。（上記以外の）残業0休出0でこの品質をだせている。
- リリース後の体制は2名だけ。バグの中には当人が対応していないものもあったが対応できている。
- どうしてこういうことが実現できたか。
- どうやってこういう環境を作れるか。これができればアジャイルの良さを実感できる。
- ウォータフォールは高校野球、監督が仕切る。アジャイルはラグビー。フィールドにはいったら自分たちでやらないといけない。外からは支援しかない。
- つまり、いかに自分たちで処理しようとするか。
- 上下関係はない。当然リーダはいるがこれはクラブにおけるキャプテン。
- コミュニケーションはF2Fチームは一つのフロア。わいがや。コミュニケーションの密度が高い。
- 自分たちで運用ルールを作っていく。やりながら毎週改善をかける。チームの規律ができてくる。
- 「ストーリ」（命題を解決するためになにをつくればいいのか、おおまなかなレベルの絵コンテ）と「タスク」（そのために今月、今週、今日なにをするのか）が重要
- タスクを最初すべて詳細に規定する必要はない。その週が終わったときにつくればよい。
- タスクにはいろいろはいってくる、テスト環境をつくる必要があるとかもタスク。
- どうやってチームのパフォーマンスをださせるか。
- 管理者は上から目線ではなく、下支え管理者。
- 発注者を巻き込む。今までは言われたものをつくってきたが、これからは発注者と話てみる、最初は躊躇する。
- ユーザはなぜ色々注文をつけたがるのか。ユーザは我々が何を作っているのかわからないから不安。どうなるか分からないから、不安になりいろいろ機能をつけたがる。作ったプログラムの64％は使われないというデータもある、
- こまめに顧客と会話することにより、顧客が開発状況を把握した上でどこまで出来ればよいかがわかる。できたプログラムを使って会話することが重要。
- スクラムで、開発者と発注者の間のコミュニケーションを円滑にし開発者のパフォーマンスを最大化すること。
- XPのペアは毎日かわる。それにより情報共有が促される。タスクは横によけられない。かならずその時点での解決を必要とされることが、高い生産性をだせる秘密でもある。仕掛かりを作らないということである。
- 開発状況の情報は顧客もみることができる。進捗報告会議が不要。その時間分開発作業に稼働を使う。
- 運用ルール
- 下支え管理手法
- チームを全面的に信頼。あいつはこの経験がないからとかはだめ。
- 開発チームが一番うれしいのは、ユーザからの声。それが成功体験となる。いままでは上から文句言われるだけ。
- 管理職の目線ではストレス。どうやってチームに気がつかせるか。いわれると自主性がでてこない。決断も開発者が行う。
- 管理者に責任・権限は一切なし。チーム支えの精神。
- スクラムマスター（としての管理者）は発注者と開発者の関係を支援する。
- 週の振り返りは最初はネガティブなことしか出てこない、徐々に改善される。
- 顧客へ見せることによる信頼感。（不信感があれもやれこれもやれにつながる。）
- 下支えがないと、パフォーマンスがでない事例。テクニックだけ入れてもだめで、周囲の環境（スクラムマスターによる）がないとうまくいけない。
- 開発チームにあまり管理のための負担を感じさせないためのツールがRTCである。このようなタスクデータもとれるのでお勧め。
C-2：三菱UFJフィナンシャル・グループにおけるシステム開発のアジリティー向上の取り組み（三菱UFJインフォメーションテクノロジー株式会社 千貫 素成 氏）
- 3年前より行っているシステム開発のアジリティを向上させるための取り組みの紹介。(1)画面プロトタイピングによる要件確定のスピードアップ(2)プログラムの可視化によるレビュー効率向上(3)ユーザー〜設計者〜実装者間のコミュニケーションの質を高める、この3つの施策を同時平行で進めることによって大きな成果を上げることに成功。これら施策の実現のために採用したSOA技術や独自開発したゼロコードフレームワークやペーパレスミーティングシステムの詳細を説明。
- 2009年7月に3社が合併した会社。社員1500名
- 問題意識
- 要件定義→ユーザー部門、設計→システム部門、実装→実装ベンダー。多くは外注。オフショアも活用。
- 分業によるコミュニケーションギャップに注目。手戻りをしたくないため、分厚い議事録や沢山の判子等のギャップ・オーバヘッドをなんとかしたい。
- 極論として分業をやめるとオーバーヘッドは生じない。
- でもこの業界では実際には10年前からそのような考え方での開発もやっており、ディーリングや新商品開発部門など非常にスピードを求められる場合は、優秀なプログラマやマネージャを直接雇い迅速に開発を行っている。これはこれで一つの解ではあるがコストが高い。（スピードが求められる時代がさらに進むことで）将来の主流となる可能性もあるが・・
- 要件定義と設計のギャップ
- 実際に動く画面をすばやく繰り返し提示して潜在的なユーザ要件の掘り出しと具体化。
- ビジュアルな開発ツールによる可視化。
- 最新かつオープンな技術を採用し、技術者の調達を容易に。
- 私が昔からこだわっている所。優秀な技術者を安定的に確保でき、競争原理で最終的に安価になる。
- JFS自体は画面の遷移にしか使わず、ビジネスロジックは埋め込まない。
- 後ろにBPELエンジンをかまえてビジネスロジックはそこで実装。
- DBはXML-DB。クライアントから一貫で処理できるため、いざとなればRDBに戻すことも想定していたが、実際は性能もよくORマッパーなどの変換が不要なので開発効率が高い。
- プラットフォームとしてはすべて仮想マシン＋Linux＋GlassFish。XML-DBはDB2。
- 処理フローはBPELでビジュアルに開発。
- メリット：非常にレビューがしやすい。実行ログもビジュアルに出力され、テスト結果の確認や解析が容易。
- DBはDB2-9。当初他社のXML-DBを使っていたが性能問題があり、DB2を評価したら性能よかった。乗り換えも簡単であった。
- 各ツール間をフレームワークで統合しJavaコードを完全排除。ゼロコードフレームワーク”ZCF”
- XML-DBへのアクセサを自動生成、ＲＳＳフィードサービスの自動生成、全文検索自動生成。など
- この1年間はFWを進化させながら、APPを充実。23種類開発、受発注システム500画面ほどの遷移をコードを1行も書かずに実装できている。
- ワークスタイルの変遷
- ペーパーレスシステムを独自開発し、全部署へ配備。
- 専用ディスプレイスタンドを独自開発、ディスプレイの解像度がもっとも問題になると考え、最新の解像度のディスプレイを配備したが、使いやすいスタンドがなく、これも独自開発。
- 可動用キャスター。A3横をそのまま出力する、1920x1200、24インチ。
- 今後のとりくみとしてRTCを複数拠点で情報共有することを実現したい。
C-3：マイクロソフトもIBMもやっている！アジャイル開発の実践事例（マイクロソフト株式会社 長沢 智治 氏、日本アイ・ビー・エム株式会社 玉川 憲氏）
- マイクロソフトもIBMもグローバルな大規模分散開発において、自社の製品開発の効率化をアジャイル開発で成功させており、その事例を紹介。アジャイルは大規模でも使えることが実証されていることがメッセージである。また、その導入効果は高いので、エッセンスを取り入れていっていただきたい。
- IBM/MSともにアジャイルをサポートするツールを出してきているので、日本におけるアジャイル導入の敷居を低くしたい。
- ウオータフォール->反復型->アジャイル適用型。
- 製品数は増えているが、製品あたりの開発数は下がってきており、一人当たりの売り上げ数を増やさないといけない。
- 方法論は違いがあるが、基本的なベストプラクティスには共通点がある。
- 反復＆インクリメンタル＆適用型
- 短いタイムボックスで動くコード
- 一口単位での開発
- 大規模開発において、数年後の要求を今FIXできるのか。7割は使われない。後で統合時に問題が発生すると、手戻りが多く致命的。
- アジャイルで開発すると、後半になると顧客は重要機能が動作することに十分満足することが多々起こる。
- 「要求」ではなく「ストーリー」。柔軟な要求の表現
- タスクはオーナーシップを持たせる。
- では、大規模になると問題になるのか。
- IBMの事例
- プロジェクトを成功させるのは透明性が必要。→そのためのツール化
- 単純な反復ではなく、全チーム同じリズムでやっていることがポイント。
- jazz.netでは内部リリースからも完全に公開している。
- MSの事例
- People/Process/Toolをバランスよく。
- ユーザフィードバックを重視。
- 大規模でagileな開発を実践するのは透明性が重要と考えている。アジリティを重視した開発。
- VisualStudioの開発事例
- 開発者3596名、ビルド月に2000回、データ総量15T、分散開発環境。
- VS開発部門のそもそもの背景
- 目標：2年毎のリリースで開発者のニーズにに対応
- get clean->バグ根絶、自動化
- stay clean->code completeマインドからfeature completeという意識に変更。
- 5week sprints
- ageileな開発スタイルに対して、全体を通した透明性の維持をバランスしている。
- アジャイルプロジェクトマネージメント宣言と同じマインド
- Yello/red game
- マネージャからすればvisibleでおもしろいらしい。
- Feature単位での進捗報告
- データはINPUTするが、報告書はつくらない。レポートは自動生成。
- リスク管理
- 正直にかく。雪が降ったから遅れるなども十分、正しくあること。
- エンドエンドでの一貫した透明性を確保できる
- 取り組みの成果
- 高い予測可能性ができたのが重要。現在はほとんど予測通り。
- MSやIBMだから特殊か？
- No、アジリティを高めるのはやらないといけないという状況では、みんな同じ。
- プラクティスは手段、あてはまらない場合に変更はあり。やって、やるべき目的を達成するために採用。
- 開発ツールを入れればすむ話ではないが、大規模開発、分散開発においてはツールは非常に重要である。ツールを「自社化する」努力は継続的に必要。
C-4:パネルディスカッション（モデレータ：前@IT発行人、現Publickey編集長 新野純一氏、パネリスト：三井氏、千貫氏、玉川氏、長沢氏、エマーソン氏）
- まずは本日のセッションの振り返り
- 三井：セッションは人にフォーカスをあてていた。透明性を持たせることでアジャイルが成功している。当初はウォーターフォールのPJだったが、アジャイルにすると効果が高かった。チームが動くまで大変だったが、動いてからはほとんど手をだす必要はなかった。
- 千貫：ユーザ企業側の開発者の人間。アジャイルの手法そのものというより、コミュニケーションがが重要。そのために開発のフレームワークをつくりビジュアル化。またペーパレスシステムを作ることでコミュニケーションをしやすいようにした。
- 玉川：3つ予想外、台風、でもたくさんの来場者、アジャイルを切り開かなければならないという考え（※予想以上にアジャイルが受け入れられていることを示した）
- 長沢：大規模な開発でもアジャイル、アジリティができることをお話したかった。特にMSの事例としてはデイリービルドなどの手法はやってきていたが、無駄もあった、ツールなどの手段を採用することにより、うまくやっていることを示した。dogfood(外に出す前に社員が使う文化)も重要
- エマーソン：2003年アマゾンで本場のアジャイル。日本にきてアジャイルの事例が少ないので広めたいと思った。日本でもアジャイルが普及していることは実感してきている。
- アジェンダ
- パネリストへのの○×クエスチョン
- (1)受託開発でアジャイルするには
- MS,IBMはPKGベンダ、受託開発は事情が違うのでは？
- そういう契約をしたい客への対応は？
- 三：ファーストステップで、意外性を見せるという手はある。信頼を得られるような動き。例えばアーキテクチャのレビューの時に実働をみせる。実際は3割しかできてないが、顧客には9割わり出来ているようにみえる。現場で起きたことを全て見せる。
- 大きい会社だと、上からOLDなやりかたをいわれるのでは
- 千：自動的にそういう文化になる。ただ、コンサル契約のやりかたは金融では実はやっていた。
- 玉：一括契約も必ずしも悪いわけではない。今変わっているのは、契約を守るのに体力つぎ込める会社がどれだけあるか。現状でいうとユーザ側がそれを求められているのでは。
- 長：エンド側がアジリティをモトメている時代になってきている。自分たちがｱｼﾞﾘﾃｨをもったやりかたに熱心になった上で、それを広めるためのお膳立てをしないといけないと思う。
- エ：アンチパターン、顧客がアジャイルでやりたいと言い出した。最初コンサルをしてバックログつくり、スプリントをつくり、開発を始める。2週間でイテレーション。最初は顧客は熱心に参加していたが、次第に人が少なくなった。顧客に開発側からのFBを与えられていなかった。
- 作る側、受け取る側、両方でチームを作ることの実態は？
- 三：毎週リリースするための確認環境は顧客から見える。開発メンバは顧客からのFBがないと催促する。月一で岐阜へ出張いただく。ある意味むりやり巻き込む。
- 千：コーディネイト役、ペーパレスシステム、画面中心アプローチ、コンサル契約といいつつ画面の数はは、決めておくことで顧客がレビューに積極的になる。
- (2)大規模・オフショア開発でアジャイルするには
- オフショアでの特徴は？
- 多能工（いろいろできる人）にならないといけないことについて。大規模開発でそうなれるのか？
- (3)アジャイルに向けた変化を起こす
- アジャイルできてない理由→周囲の理解、スキルが足りないなど。会場挙手
- 玉：やってますという人が多かったのが以外。アンケートだと5％くらいだが、15％くらい手が上がっている。
- エ：日本企業は昔からアジャイルの要素がある。大学生でも反省会をやる。アメリカは反省会のやり方を高い受講料をはらってまず教わることから始まる。
- 三：アジャイルに対する反応はよいが、やはり不安などネガティブに捕らえられている。私は50台、WFの人。でも顧客と膝つめて話しすると、それは昔からやっていたという話になる。
- エ：ソフトウェア業界は（製造業などの）他業種から学ばなかったのではないか。
- 三：製造業の無駄取りについて、いろんな業種が見学にきているが、ソフトウェア業界だけはこないとのこと。その業界の存続理由にフォーカスすると、いまチャンスではないかと、ソフトウェア業界としてもアジャイルにむかっている契機では。
- 三；自分たちから情熱をもって顧客にどのような価値をだすべきなのかという本質を認識しようとするとアジリティにいきつくのではないか。顧客にしてみれば、その時の状況に応じたシステムであればよいのである。ウォータフォールの手法でもアジリティ要素を求める側面はあるはずで、そういう時に別の人種と考えないで。
- エ：HAPPYという言葉が出ていた。アジャイルだと動くものを納品出来た嬉しさ。欲しいものを得られた嬉しさでHAPPY
- 長：いろいろ取り組みは行われているが、まだ目立っていない。MSの主張をのせるというより、アジャイルを普及させる活動を行って生きたい。
- 玉：建設業の父にアジャイルについて説明すると、スコップで掘ってた時代にショベルカーが出てきた感覚らしい。今後は実証データを積み上げていきたい。
- 千：何なんのために取り組んでいくか。IT業界をよくしたい。今は疲れている。業界を変えるのは、現場の方々のクリエイティブである気持ちである。その気持ちを持ち続けて欲しい。
- アジャイルできてない理由→周囲の理解、スキルが足りないなど。会場挙手
