チュートリアルセッションE1 アジャイルプロセスの現状〜組み込みへの適用可能性を探る〜橋本隆成(ソニー) B会場人数：120人 ======================== 講師の橋本さんの経歴三菱スペースソフトウェア 10年弱、マル防、弾道計算、戦闘指揮、射撃制御、コンソールシステム正確なものを作っていくということが課せられてきた ada c, c++, アセンブラが大かった。当時アメリカからきたオブジェクト指向も使った。日本HP 分散システムの構築オージス総研 OOP技術のコンサルテーションとトレーニング、ソニー OOP、方法論、開発環境導入などの社内コンサルテーション ======================== アジャイルプロセスって何？はじめて聞く方のために解説。このチュートリアルでは私の個人的な意見を入れずになるべくかいつまんで提唱者の意見をお伝えする。最後にそれぞれの問題点を。組み込みに有効か、不向きか、分野は？などの議論はF1にて。 ======================== アジェンダスクラム、Feature Driven Development の2つを中心に。他の手法についてはこれらを説明するときに引合いにだしながら紹介します。 ======================== アジャイルプロセスどうやってソフトウェアを作るか、というのに昔は注力していた。現代は大規模化、複雑化するシステム携帯電話の例携帯電話を使ってどのようなビジネスを行うか、国際的なビジネス顧客も何をしたらいいのかわからない。課題の多くはエンジニアリング以外の領域に存在している。どう対応するかが重要。 ======================== 組み込みシステムで期待されるアジャイルプロセス少人数での開発が多い。 CMMIやRUPはいいがいろいろな制約がある。大人数のほうが効果を出しやすいプロセスである。3,4人での開発だともっと他の手法があるのではないか。マーケットのためのスケジューリング。。下の〜理論はアジャイルプロセスの中でなんらかの形で扱われている。〜理論もひとつずつ簡単に紹介していきます。 ======================== アジャイルプロセスの定義はあってないようなもの「状況に応じて臨機応変に効率よくやっていきましょう」という程度。現状では新しいアプローチなのでまだ統一的なものはまだない。アジャイル宣言 ======================== アジャイルプロセスの定義はまだない。エンジニアリングプロセスかプロジェクトマネジメントプロセスかも。。 ======================== アジャイルプロセスのなかまたち XP が一番人気があって有名。その次にスクラム、クリスタル、FDD 最近アメリカで注目されているのがASD MDAもアジャイル宣言に賛同している。それぞれそのプロセスが重視している前提条件、価値観を述べているものもある。それらの哲学に注意する必要がある。価値体系、めざしているもの、強く影響を与えるもののちほどいくつか紹介します。 ======================== 方法論の特徴の比較。個性、特徴を簡単に紹介するために。 RUP, RAD, XP, スクラム ======================== スクラム時間の関係で詳しくご説明できないので概要がわかるように説明しますがこの本を翻訳していて8月にはでますので詳しくはこちらを。 XPより歴史が古くて1000以上のプロセスに適用されてる。プロジェクト管理プロセス。 XPが技術色の強いのを補完するためにXP+スクラムが注目されている。 Sprintと呼ばれる30日のサイクルを反復。明確な役割分担 <-> xpはみんな同じ 7人。大規模プロジェクトだと階層化再利用については考えないほうがいい。 ======================== 図で書いたものがこれ。顧客の要求を聞いて製品バックログという形で作る。形式は問わない。最初はスプリントを行うだけのバックログがあればよい。客と優先度アーキテクチャのミーティングスプリントバックログを作る。日々の作業のために4h〜16hの細かな単位に分割される。雑用も含める。資料のなかの「スプリット」は「スプリント」日々開発していく。デイリースクラム。 15minー30minで行われる。スクラムマスターに3つだけ答える・この24hに何をやったか。・明日のミーティングまでに何をやるか・どんなトラブルがあったか一人が話している間は割り込まない。コミュニケーションの問題を解決する。遅刻は厳禁。出張があっても電話などで必ず参加。厳密なルールによってチームとしての自己組織化。 30日のうち29日は開発を行う。実際に動作するものを作る。関係者全員でデモ。問題があればまた製品バックログを作る。規約書、コーディング規約などももちろん必要。これ以外にプロセスのためのアーキテクチャはない。。 ======================== スクラムチーム、自己組織化が非常に重要 30日間はチームに優先順位がある。バックログを実装するために何が必要かは必要な人間でフォローアップミーティングを行う。チームはどういう特徴を持っている、という理論から開発された。スクラムマスターはマネージメント。スクラムチームのために。報告先。プロダクトオーナーは外部。顧客の誰かでもいいしメーカーの誰かでもいい。顧客とプロダクトオーナーだけが優先度を決められる。 ======================== デイリースクラムブタ(チームメンバー)とニワトリ(メンバー以外、発言はできない) Sprint レビューミーティング全員参加 PowerPoint禁止。確認をして次の30日間。 30日に根拠はあるか？変更してもいいがいくつかの理由で30日がバランスがいい。マネジメント層が30日放置するのが限界。土日の休みを含めて適切なリズムを作りだす。 ======================== 30日間の作業をプロダクトバックログからどれが優先度が高いか決めて sprintの目標を替える。ビジネスの条件も考える。ツール、テクノロジ、実行可能なプロダクトの機能追加うまくいかなくても30日間を犠牲にするだけですむ。明確な制限があるのでどんなに最悪でも30日。 ======================== 進捗管理基本的には反復型開発でその中からえられた経験に従って次の見積りをだす。ザ・ゴールの著者も同じことをいっている。経験的なところがアジャイルの特徴的なところになっている。さっきの青い本もフィードバックプロセスの本ですが反復してフィードバックしないと知的な生産の進捗想定はむずかしい。 30日でできると思ったことができないことがある。思ったより進まない場合にはやらなくていい。→できなかったものはしょうがない。残った時間で次に何をやるべきか、を決める。プロセス指向ではなくて結果指向。結果として何ができたかだけに注目する。 ======================== スクラムの理論背景経験的な方法で反復によってやるとか。どうしてうまくいくのかという疑問が発生するでしょう。単に経験的なものからこういう出張をしているわけではない。古典的なものではSECIモデルというものがあるが、詳細に調べると違う結果がえられた。中断された並行性？突然成果を出すための隠れた成果がでている。人間なので段階的にコミュニケーションを行うというよりは断続さ平衡説どのようにして技術が伝わっていくか、暗黙知、形式知 ======================== スクラムの主張のまとめ。予見型、最適化型プロセスへの疑問、宇宙、航空のように安定していてせかされないものならできるだろうしのぎを削っているものには向かない。 ======================== スクラムを主張していた2人が予見型プロセスをやってきたがうまくいかない世の中を見てもうまくいってないほうがおおい。テイラーの1911,1916年の論文が起源、工業製品を作る話。ブルーカラー向け。決まったことをいかに効率的に行うか、という論文。知的生産ではない。うまくいかなくて当然。 ======================== (休憩) ======================== 前提的な制約をもういちどまとめておきます宇宙とか防衛で作るものはミッションクリティカル、競合他社はないことはないがあまりない世の中のlinux,windowsのような世界を考えると、とにかくシェアを拡大しないとだめ。航空宇宙はとにかく完璧を求める。他ではどれだけビジネスの環境に適合していくことが必要、というのが前提。ビジネス自体がカオスだ、とカオス理論を用いて説明することが。カオスの淵にいるのが重要。カオスの中にいると不安。そういう時にこそチームや世の中は創造性が発揮する。カオスの淵はどういう状態か？情報の流れる速さ、多重性(文化、考え方の違い,ソリューションの多さ)、つながり(コミュニケーション)、？？、？？カオスの淵に立たせると効率が高い。 FDDはもうちょっとわかりやすい ======================== FDDとはオブジェクト指向開発を進めていこうエンジニアリングプロセス。 Feature駆動。オブジェクト指向を使うことを前提にしている。 OOP開発の方法といってよい。人やチームの位置づけを重視している。スクラムよりは少ない。中大規模にも使える。 ======================== 要求を抽出、最初は不明確なので反復のなかで明確にしていく全体モデル(概念モデル)を作成する。静的な構造機能リストをつくる。ユーザー機能リストここまではウォーターフォール、このあとが反復全体の反復は必要に応じて行えばよい。 ======================== FDDが対象とする範囲図中央の囲われてる部分が対応している。その他のものは対象外。 ======================== 進捗報告ビジュアルなもの。機能(ユースケースとおなじ) の名前を書く、進捗をグラフで描く、計画からのずれは色で示す。90%シンドロームを避けるために手法が提案されている。チーフプログラマーは、フィーチャーを責任もって担当するプログラマー。 FDDは機能を責任もって開発する人とクラス担当者が分かれている。チーフプログラマはクラスオーナーと協力してその機能を実現する。 ======================== 他のプロセスとの比較 XPの共同所有について否定的。エンジニアの中では力の差があるのでスキルの高い人、政治的に強い人が支配的になるので難しい。大人数だと難しい。構成管理を考えると共同所有では難しいのではないか。 XPは誰が何をやるか、を明確に決めない。FDDはクラスオーナーとかチーフプログラマーといった明確な担当者がいる。 Use case drivenには若干問題がある。粒度があいまい。 FDDでは2weeksでできる粒度と決めている。 ======================== 組み込み/RTのプロセス〜MDA〜を中心に OMGなど。 MDAは人がどうこうという話がでてこない。モデルからいかにコードをだしてくるか。ソースを書いてデバッグして。というのはしかたなくやっている。本来、王道的なことをやりたい。自動ソースコード生成に注目している。人間がやるとバグや勘違いが入るがそういったものは排除できる。 ======================== 時間がないのでかけあしで紹介 XUML MDAを使うことを前提にしている。分析と設計を明確に分離しよう。分析結果を再利用しましょう。分析はドメインの問題、設計のところはツールが吸収。設計者、分析者を明確にしている。アクション記述どのインスタンスを何個作るのか。。。変換型ソースコード構成大手のメーカーなどでよく使われています ======================== ROOM Rational(IBM) 優劣は語らない、今どういうものが使われているかという視点で見てください。並列、並行性を積極的に取り扱っている。 UMLを拡張。。状態図にターゲット言語でアクションを記述。 ======================== Rhapsody ROPES これもツールでコード生成ができる。方法論自体はいままでのとはそんなに変わらない。プラスアルファ MDAの環境が提供されてる。 ======================== これがツールのイメージ図。状態図図を書く方法はいろいろある。セミスパイラル。マクロ的な反復〜ミクロ的な反復を提供している。 ======================== まとめ組み込みシステムの特徴いろんな製品がPCに繋がる、PCが他の製品に繋がる。他のことを直接言えない。赤いところが組み込みリアルタイムに近い、技術的複雑性が高い。管理の複雑性が高い。 ======================== CMMIとかは変化が少ない、だいきぼ、再利用重要なところで役に立つ。市場の変化、影響を受けるものにはアジャイル ======================== アジャイルの注意点厳密に要求仕様書外注さんをどうする？クライアントとどうやってコミュニケーションする？とかは大事だけど定義されてない。 ======================== XPのリーダーとかスクラムマスターとかは高いスキルを前提にしている。 ======================== MDAはソースコード生成に力をいれている。問題のごく一部しかない。細かなタスクを明確にしていない。重要な示唆を与えていない。 CMMIにPMBOK(プロジェクトマネジメントの知識体系) CMMIをやらずに食わず嫌いの人も多い。文化が非常に重要になる ======================== ケントベックとの写真 ======================== Q&A q. 小川(名古屋市工業研究所プロセスを適用するという考え方がわからない。問題があったら道具をもってきたらいいと思っていて、何故プロセスを適用するのかわからない。 a. プロセスがないのが理解できない。 q. プロセスを適用するという考え方がわからない。プロセスは存在している、問題を解決していけば a. 自分たちのやっているプロセスがいまいち効果がでない、効率や属人性を排除する。 q.「プロセスを適用する」という考え方じゃないですよね？ ======================== 間瀬(アイシン) さん q. 方向とかはわかりましたが工数とかの低減はどうなっているのか a. 定量的なものはまだ持っていない。スクラムのひとびとは2、3倍ではなくて100倍くらいでた。と。 FDDでは定量的なものは記憶にないです。 ======================== 木村(早稲田大)； q. 企業文化、関連企業の文化、アメリカ文化を反映している→日本用にカスタマイズする提案などはあるのか？ a. どういうふうにシステムを作っているか、日本企業をCMMIで評価するとよくないが、かならずしもできてないわけではない。日本企業は文書化しなくても人の流動性が低いので問題が起きなかったりする。