============================================================================== 分科会1 セッションB3: SWEST3 議事録 「組込みソフトウェアの品質向上を目指して 〜第一部:技術 vs. プロセス/管理(開発プロセスと手法)〜」 ============================================================================== 【 会場/参加者 】 会場の広さ: B会場(席数40脚程度用意) 参加者の数: 35人程度 【 分科会全体 】 会場の雰囲気: 議論は静かに展開されていたが、緊張した雰囲気が感じられた。 参加者のこの議題に対する興味の深さがうかがえた。 後半は話題の焦点が参加者の興味と一致しはじめたのでは。 全体の方向性や結論: ・技術とプロセスは車の両輪。どちらも必要である。 ・SWESTを通じて、組込みソフト開発に役立つ開発プロセスの情報交換を   進めていくべきである。 ------------------------------------------------------------------------------ 【 ポジショントーク 1/3】 「ソフトウェア開発プロセスの簡単なまとめ」(株)エス・キュー・シー 西 康晴 技術絶対主義 ・技術至高 ・よいものは技術 ・管理されるのはいや プロセスとは? ・ソフトウェア開発の作業や仕組みを定義したもの ・古典的なプロセス 流行のプロセス ・国際標準系 <- 重いので嫌われる - ISO9000s - SLCP/SPA/SPICE - RUP(Rational Unified Process) ・CMU - CMM(Capability Maturity Model) <- 国防総省が発注 - PSP/TSP(Personal/Team Softeare Process) <- CMM は重いという意見を受けて開発されたもの ・カウボーイ系 - XP(eXtreme Programming) ・その他(プロジェクト管理および品質管理) - PMBOK/PMI - GQM/TQM/Six sigma PSPとその進化 ・エンジニア個人に適用される ・130時間で一人前? ・フェーズが決められている XPのプロセス ・Webアプリ開発 - オブジェクト指向開発 ・ムダがない ・品質が高い ・コツは技術ではない 軽いプロセス ・組込みに向いているのでは ・軽量ソフトウェア開発同盟というアライアンスが出現 組込みソフトウェア開発にプロセス管理は必要か? プロセス vs 技術 ・必要派 - 仕事の進め方ぐらい決めよう - プロセスがないと管理できない - プロセスがないとせっかくの技術がいかせない ・無駄派 - 技術があれば安全 ・中間派 ------------------------------------------------------------------------------ 【 ポジショントーク 2/3】 「組込みソフト業界とCMM」 NECエレクトトロンデバイス 門田 浩 ソフトへの付加価値シフト ・ソフトウェアの重要性は増大する傾向にある。 プロセス ・良いプロダクトは、良い仕組み・プロセスから生まれる ・プロセスの改善は、段階的にすすむ ・地道な原因追求・事後分析の継続必要 CMM ・米DoDとカーネギーメロン大学が開発した組織能力レベルの指標 ・5段階の成熟度レベル ・レベル判定の質問票 CMMのキープロセスエリア ・日本の多くの組織のレベルはレベル1以下 ・要件管理(顧客の言っていることを管理できているか?) ・プロジェクト管理(経験値を生かしているか?) ・外注管理(外注を使った場合、必要なことを外注屋とネゴできているか?) ・品質保証(外に対する指標を提示することができるか?) ・ソフトウェア変更管理(バージョン管理等) CMMの成熟度レベル ・米国、インドでレベル5企業多数(とはいえ、<100) -> US/カナダはアイデアとプロセスで進んでいる。 ・生産性と成熟度レベルには相関関係がある - プロセスを改善するための指標をあたえられることが必要 - 94年までのISO9000sはそれを示すことができなかった(敗因) インド企業とBoeingの関係 ・レベル5企業全体の70%以上はインド企業 ・Boeing もレベル4〜5 -> ビジネスがスムーズに行なえる(プロトコルが一致) 経済産業省の決断 ・調達基準にCMMレベル3相当を採用するという話が進んでいる ・米国SEIよりライセンスを取得 ・2003年度より日本語アナウンス ------------------------------------------------------------------------------ 【 ポジショントーク 3/3】 「Technology Flow 〜ソフトウェア組織に対するもう一つの視点〜」 アルパイン情報システム 児玉 剛 自動車向けのカーナビゲーションシステムなどを OEM で開発。 OEM であるため回収することは困難。信頼を失わないために、品質を高く維持 しつづけることが非常に重要となっている。 モノの流れ.. ・経営の基本は、人・モノ・金・情報の流れる仕組みをつくること ・モノの流れからみた技術 - 仕入れたものを加工し、価値を付加するのが技術 ソフトウェア部門を流れるもの ・仕入れが存在しない - しかし、新しい技術が生まれ、投入される ・技術そのものが流れている ・ソフトウェアの2つの技術 - 部品を統合するための技術 - 市場に投入されるための、仕入れて流す「技術」 ハードウェアの2つの技術 ・新しい技術がまれ、投入される ・技術はパッケージに納められる、「部品」に姿を買える - 部品化により技術の市場投入速度が高められる - 部品化されないものは技術者が補う ・ソフトウェアの世界での部品は? - 数年前、部品化という概念が一般化 経営者の仕事 ・技術が流れる仕組みをつくること ・「モノの流れる仕組み」を見習う - モノは、上流工程から下流工程へと流れる。 -> 情報を上流から下流へ統制すること ・技術が流れる仕組みを顧客視点で優先することが必要 技術とプロセス ・プロセスは仕事の進め方 - 当り前のこと。力のあるエンジニアなら必ずやっている。 (組織としては文書になっていないこともあるが、納期に出すのだから何ら かの形でプロセスのようなことをやっているはずである。) ・技術とは? - 設計、プログラミング、デバッグ、技術の修得、検証、展開 開発チームとして ・チームとして - 第一に、技術力があること。 ・強いチームを作るために - マネージャの仕事。マネージメント なぜ「技術かプロセスか」 ・最初は技術(技術が先行したに違いない) ・プロセスがあとから強制力 - 邪魔だったり、面倒 -> 反発 ・技術とプロセスを両立することが必要 問題を分割する ・技術はエンジニアの問題 - 技術的なスキルアップとかはエンジニアの仕事 ・プロセスはマネージャの仕事 - エンジニアをどう生かし、最大限のパワーを発揮できるプロセスを組み 上げ、環境に応じてスクラップ&ビルドを行なう。 プロセスの要件 ・技術者が最大限の力を発揮するには - 無駄な工数が発生しない(仕様変更など) - 残業しないといけないのか? いつ休めるのか? ・目新しいことではない... プロセス改善 ・プロセスは改善であって、「定義&導入」ではない ・現状を意識して、ステップを踏んで改善を繰り返す。 ・HW屋さんが歩いてきた道のりはとても参考になる。 ・マネージャの仕事 ・現場を諦めて管理職にならざるを得なかった管理者は、 地道な改善活動、組織づくりを取り組みはじめることが必要。 議論に望むものとして... ・両立を阻害するものは? ・マネージメントの課題は? ・強いエンジニアとは? - チームを導くエンジニアとは? ------------------------------------------------------------------------------ 【 議論の内容 】 分科会参加者は、プロセス派? 技術派? それとも... ・プロセスが嫌いという人は 若干名 ・プロセスがよいという人は 若干名 ・どちらでもない(中間層) 多数 中間層が大多数。では、どういう意見を持っているのか? ・型に入れられるのは嫌いだが、プロセスは必要だとは認識している。 ・今言われているプロセスが自分の現場にそのままあてはまるわけじゃない。 ・プロセスを整備してもダメ。 ・いいバランスがあって、それを見付ける プロセスが必要である状況とは? ・現状では、個人個人のレベル差が開きすぎ。(10倍〜無限大) ・100人の良いプログラムがいれば最高だが、現状はそうではない。 ・悪いプログラマを100人集めて、プロセス管理しても出力はゼロ。 プロセスを不要とする根拠は? ・製造業はベルトコンベア式を見直しセル方式に移行している企業もある -> 複写機を一人で作る方が達成感があり、品質が改善されている。 ・苦労していることは、皆同じ。 - 共有メモリが書き代わっていたり、デッドロックが発生。 - 良い道具を使う。古い道具に執着してはダメ。 (Java による開発はメモリリークとかバグの混入を気にしなくてもよい。) -> 開発期間が10分の1以下になるはず。 ・組織がすべて同じ方法をとるのか、個人の管理を自己責任とするのか? ・ベルトコンベア式のプロセスはエンジニアのやる気を高めることはできない。 - プロセスはラウンドをまわる方式がほとんどである。 ・仕様をもらうだけのプログラマでは、スキルアップは望めない。 - 仕様から作成するプログラマは、やりがいを持つことができ、スキルアップが期 待で きる。 ・どのプロセスを選択するのか、プロセスそのものを否定するのか。 ・全員が一つの方法を守るのはよくないのでは。 ・みんながスーパープログラマであれば、プロセスは必要ない。 - Linux 開発にプロセスを適用しているという話しは聞かない。 - バラツキを抑えるためにプロセス管理は必要 ・プロセスを使わなくてもJavaを使えば効率がよくなる。 ソフトウェア工学とプロセス ・プロセスがいいという人は、どのプロセスがいいのか? ・それぞれに依るのでベストなプロセスはない。 ・ベストなプロセスはない。あれば、ソフトウェア工学はもっと進んでいる。 ・ソフトウェア工学は現在の発展に寄与していない。 ・教科書になっていないからプロセスは使えないというのではなく、 ソフトウェア技術者が作っていくことが必要。 ソフトウェア工学者の立場 ・現在の発展に寄与できていないのは確か。 ・それを解決するための方法が必要。組込み向けで考えるのか? 各社でのプロセス使用の現状はどうなっている? ・きちんとしたプロセス管理は存在するか? 1人 ・形式だけの(屍となった)プロセスがあるのか? 0人 プロセス適用事例 ・プロジェクトリーダの裁量で、プロセスを柔軟に運用。 - プロセスのいいとこどり。 プロセスとプロジェクト ・プロセスはプロジェクト運営のテンプレート、各自でカスタマイズが必要 ・プロセスを運営することも技術である。プロジェクト運営技術が未熟であ るから、プロセスを役にたたないといっているにすぎない。 ・よいプロセスを作るためには、技術者がプロジェクトをうまく運営できる ようにカスタマイズすることが必要。 プロセスを改善することでよくなったという事例は? 1. オープンソース型開発 ・ML で変更部分を流させる。他人に指摘されると、逆に他人のを指摘する ようになる。レベルの低い人は高い人に引き上げられる。全体のレベルアッ プができた。(IBMからヒント) ・精神論では? 米国では、バグのでないツールを使うはずだ。 ・メールはダメ。どんどん流れて良くので、ドキュメントとして蓄積なし ・アーカイブを残して、それを参照して議論している。 ・95年を境に世界は変わった。 2. 繰り返し型開発 ・RUPをベースに、スパイラルを適用。 ・開発期間を4つのphaseに。 1. 方向付け(macroな要求分析) 2. ソフトウェアのアーキテクチャ(モジュール分け、インターフェース定義) 3. 構築(作り込む) 4. 推敲 -> ソフトウェア工学の。共通認識ができる。 ・RUPの肝は? - 推敲フェーズでもすべてが解消されるわけではない。方向付けができればよい。 - 危ないところから作る。(肝の部分、難しいところから作る。) - プロセスエンジニアを定義している。 プロジェクトを評価できる特殊能力をもつエンジニアを育成 3. ・60〜70人のプログラマ、1年の開発期間 ・プロセスも適用しているが、コンサルティングを受けている。 ・データを取り続けている。 ・あまり効率はあがっていないが、予測性(リリース、バグの収束)があがった。 - 製品の種類は変わらないが、規模が拡大しているもの。 - 過去のデータから+-1週間で予測精度をもつことができた。 4. ・KI (knowledge innovation)を投入。 ・残業時間 200->60、チーム力の底上げ。 ・開発の初期段階で、アウトプットを全員で確認。 ・週の頭に、個人レベルの作業のバラシのミーティング - 新人を含めた全員、問題の洗い出しをする。 ・突然現われるようなバグをなくし、初期段階でつぶすことができた。 ・開発期間をフラットになった。 ・ストーリを立てる。ストーリの上から順に中レベルを ・最終的なアウトプットのイメージの統一。 ・進捗管理を徹底的にやる。 ・コンサルティングを導入(97年4月〜98年夏) ・リーダクラスが反発したプロジェクトは、コンサルティングをいれても 失敗した。「ミーティングに時間をかけるくらいなら、作業をしろ。」 ・ミーティングは普通に行なわれていることではないのか? ・丸一日かけて、チーム全体で個人の作業を認識する。 RUP、XPについて ・RUP では、ラーニングプロセスが確立できるとされている。 前のプロジェクトから学んだことを次のプロジェクトに生かそうとする。 ・XP も同じ。今日の天気から明日の天気を予測することである。 ・現状の忙しい状況では、プロセスを学ぶことはできない。 ・現状困っている会社では、プロセスエンジニアを置くことができるのか? ・必要性が認められていないことである。 - 認めさせることが必要である。 今後すべきことは? ・投入すべきところに工数を投入すべき(マネジメント、技術修得)。 ・マネジメント投入とかは、ずっと言って来られているのに、 実現されていない。いまさらいってもどうにかなるのか? ・マネジメントの中に人を育てていく工程を含めて行なうことが重要。 ・成功している所の肝は、「人をどう育てるか?」にある? ・「彼にまかせたらOK」はダメ。 ・その「彼」を増やせ。&「危ない奴」に目をつけろ。 ・人を無視したプロセスはだめ。 ・「彼」にまかえせてもOKということを定量的な指標で示す。 ・ツールを取り込むことで、工数を減らし、工数を費すべきところに費す。 ・費すところは検証ではなく、検証をツールにまかせる。 ・検証にかける時間を減らして、機能を実現するための(考える)時間に費す。 ・新しい技術を投入するために、情報の流通を活発にすることが必要。 ・プロセスを measure して改善することが必要である。 ・上司を説得することが重要だ ------------------------------------------------------------------------------ 【 記録者自身の感想 】 プロセスの賛成/否定派のそれぞれのプロセスに対するイメージが最初異なっ ていたために、議論が噛み合わない部分もいくらかみられた。 プロセス否定派も、プロセス適用に期待しているように感じられた。 プロセスは現在、米国など海外主導である。日本の特質にあった独自のプロセ スを発信していくことが必要ではないかと感じた。 ==============================================================================