=========================================================================== 分科会　F2 「開発現場を楽しもう 〜開発現場で使える開発プロセス・開発管理手法について語ろう〜」 チェアマン：オージス総研 畑氏 人数：30人程度 =========================================================================== 自分がテストと開発プロセスを聞きたかったので提案したら、言い出しっぺが やれということで司会になった。 ポジションペーパーを見て開発プロセスを話題にしている方々にポジショント ークをお願いした。 ＜ポジショントーク＞ ○イメージリンク　山田氏 　20名程度の小さい会社で主にデジタルカメラの設計を行っている。 先ほどの畑さんが先の時間にプロジェクターで書いたように、ウォーターフォ ールで進めており、実際に開発を行って、問題点があることが分かっていると いう点は分かっているが、どこに問題点があるか考えた場合に、ディジタルカ メラでは新しいチップを使いこなす事が大きな問題となっている。ウォーター フォールの開発の中で最初に詳細設計次に仕様設計を行い、詳細が出てくる。 そこから進んでいく中で、一番ネックになるのは、最新のチップの使い方。仕 様は出てくるが、細かいレジスタの設定や細かいタイミングなどまでは書いて おらず、設計しながら端折りたくなるが絶対に抜けきれなくなる。詳細設計− 設計−デバッグを循環する形になり、最終的にはぐちゃぐちゃなウォーターフ ォールになってしまう。 オブジェクト指向手法を採用したいが、時間やスペックの制約などユーザの 様々な要求を満たすのに必死で、実際にはきれいな形ではできなかった。時間 をかけてじっくり行う方法もあるが、デジカメの開発期間は1年も無い。よく て6〜8ヶ月。最新のチップを使うということは、初めてのユーザとなる可能性 も出てくる。初めてのユーザはリスクが大きく、絶対にICにバグがあり、すん なり行かない。画像処理系なので目に見えてしまうので、ごまかして製品化す ることができない。現実的には、開発プロセスとしてはきれいにいかない。 　しかし、このままではいけないと考えている（自分達を苦しめる事になると 思っている）が、オブジェクト指向を開発プロセスと考えた場合、小さい会社 では高価なツールを導入できない。手法を取り入れる場合は書籍しか頼るもの が無い。コンサルタントに出す際に、大きな会社では予算が通れば問題ないが、 小さい会社では予算が取れるかどうかは別の問題になり、絶対的な金額をどこ に上乗せするか（例えば商品などに上乗せして、ユーザサイドにお金を出して もらう）が問題となる。書籍を読んで行うとなると、最終的には好きな人間が 根性を出して行うといったやる気の問題となり、難しいところがある。 　実際にやってる側として開発は好き。新しい事をする(チップを使う)のが好 き。１年ごとに新しいチップが出現し、それらのチップは新しい考え方が導入 されており、それを吸収するだけでも楽しい。職人芸を削るのがオブジェクト 指向的な考えではあり、本当は良くないのかもしれないが、開発を楽しむとな るとやっぱり熱意と新しいものが好きという点で落ち着いてしまうのではない か。できれば、学生が就職する場合は、なるべく大きい会社に入ってそういう もの（開発プロセスやオブジェクト指向）を習得し、その後で中小企業でコス トをかけずに発揮して欲しい。 ○eSOL　澤田氏 　今まで、特にプロセス改善に本格的に取り組んでいるわけではない。バック グラウンドとしては、開発を3年間行い、テストのサポートや製品のトレーニ ングなど雑多な業務に携わっている。プロセス改善を学んだわけではないが、 幸か不幸か決まった手順がまだ社内でできていない分野をやることが多かった ので、それらの経験から自分なりに考える機会があった。 　組込みソフトウェアは大規模化／複雑化の傾向にある。その中での弊害とし て、個人が全体を把握できなくなってくる。構成要素が増えると相互作用が増 え、動作や工数が事前に予測しきれない。またテスト工数の増加もある。対応 するリソース不足などで開発が失敗するケースもあった。 　改善策として、最近話題になっているのがプロセス改善であると思う。ここ でいうプロセスは、各工程の標準的な作業手順である。目的は、組織として学 習して失敗を繰り返さない「失敗学」を学習する。良いプロセスで開発を行う 事で良いものができる。逆に言うと失敗が少なくてよい製品ができるプロセス を良いプロセスという。しかし、良いプロセスがあるだけで、事態が改善する わけではない。プロセスの実施に関するコミットメントや状況に応じた最適化 も非常に重要である。 　プロセスの改善の方法は、まず、現状を客観的に把握する。主観的な評価を するための材料としての、既存の評価基準の導入も有用。あと、ベストプラク ティスの検出・分析・共有も有効。組込みの世界では「職人」「達人」と呼ば れるタイプの技術者の技を研究して、そこから技法的な手法を抽出して、共有 する。「経験しないとわからない」「経験してなんぼ」という人もいるが、そ れは一種の言い訳という面もあり、文章化する努力をする必要があるのではな いか。プロセスを考えたら、それを実施してみて、うまく行ったらそれを続け る。成功したら継続し、そうでなければ必要に応じて更新を行う。如何に使わ れるかという点で努力が必要。 　組込み開発におけるプロセス改善においては、ベストプラクティスの研究が 重要だと思う。確かに教育や文章化は難しいとは思うが。システムの規模が小 さい＝開発の人数が少ないということもあるが、達人による技の独占が長い目 で見た場合の効率の悪さにつながる。SW、開発、開発手段3者の関係の向上を 考える。 　プロセス改善を考えた時に、設計関連のツールが話題に上るが、他にもプロ セス改善に有効なツールがあると思う。重要なのは、開発対象が変わっても同 じツール・インタフェースで開発が行えるのもプロセス改善につながる。それ により、プロセス改善・ソフトウェアの大規模化・複雑化に対応できる。大規 模なソフトウェアを開発する際には、細かい部品の集合と捉えて、ソフトウェ ア一つ一つを極力ブラックボックスとして捉えることをサポートするツールが あれば、開発手順が楽になると思う。技術者の教育・知識の共有に有効なツー ルも必要ではないか。 　まとめになるが、本格的なプロセス改善はハードルが高く感じられる。トッ プダウンからのプロセス改善も大事だが、ボトムアップからの視点も大事なの ではないか。また、できることから実施する。既存の評価基準を利用して現状 を把握する。ベストプラクティスの研究。よりよいプロセスの模索・実施・メ ンテナンスという点では、自分の力の及ぶ範囲から文書化などを行う。これら を実施することで、各個人が自分のためになるという実感を持てれば、本格的 な実施の足がかりとなるのではないか。 ○デンソー　古畑氏 　2年前から実際に行っている現場改善の取り組みを、一つの成功事例として 紹介する。（意識改革が目覚しかった） 　1988年に研究職として入社。その後通信分野へ。研究畑出身なので、バック グランドに「考えること」がある。 　機械工学が専門なので、ソフトウェア開発の現場を見て愕然として。品質管 理がなっていなかった。 最初に配属された時の問題点。 　1)環境変化への対応ができない。 　　大規模化や短期間の要求に対して、神業的に作っている。 　2)自分達の仕事の仕方を工夫しない(考えない)。 　　企画や改善モデルをそのまま取り入れようとしており、正しい使い方を知 　　らない。 　3)プロのマネージャーが育っていない。 　　管理職の仕事の中に部下を育てるという仕事が無い。 　　管理論になるが、管理職の人間は、職場での「問題」「原因」「対応策」 「効果」「評価できるものさし」があるかについて、言えるようになるべき。 まず、改善には基本構想（戦略・シナリオ）が必要であると感じた。 　Step1)時間の確保が必要（時間を確保しないと改善の手が打てない） 　Step2)できた時間でプロセスの改善を行う 　　　　（同じ失敗を2度と繰り返さないように） 　Step3)技法・設計法・ツールの導入(デザインルール・デザインパターンなど) 担当した開発チームは、自分達のルールしか知らない閉じた開発集団(ハード もソフトも自社生産)であった。約束が守れない(納入遅れや不具合など)、躾が できていない(時間が守れない)といった問題点があった。 Step1)時間の確保 　・時間を確保して、連絡管理・コミュニケーションの時間を作る。 　・時間の確保のため、無駄を徹底的に排除する。 　・改善法(例) 　　1.会議 　　　会議のゴールを明確にする 　　　3回出席して発言しない人は参加させない 　　　結論が出ない時は仮定する(決定する日を明確にする) 　　　→会議が短くて早い。決定事項が明確になってきた 　　2.レビュー(効果的か?) 　　　参加者の理解を確認 　　3.ツールの流用 　　　他グループのツール(テストツール、不具合管理ツールなど)を徹底的に 　　　流用する。 　　→時間の確保ができた。 Step2)プロセス改善 　・問題は解決しなければ意味が無い。 　・「同じ失敗は繰り返さない」と決め、徹底的に行った。 　・反省を行い、次に改善策を打ち出せるようにする。 　　　混沌とした開発を改善。定量的評価、反省のサイクルへ。 　　　現場の意識改革。品質データの収集。 　　　QCDでのプロセス改善を行う。「何故何故何故」を繰り返す。 　　　「反省して直す」がキーワード。 　　　反省しやすくする。それには、記録が必要。（記録が無いと原因認識に 　　　時間がかかりすぎる） 　　(1)要求管理（問題点、原因、対策） 　　　問題点：要求が決まらないのに納期が変わらないので開発期間が 　　　　　　　なくなる。 　　　原因　：何故決まらないか？ 　　　　 顧客は決めるだけの情報をもっていない。 　　　　 「仕様はわれわれが提案する」という発想の転換。 　　　対策　：要求仕様を仮定し、顧客に提案（早い段階でシステムを明確に 　　　　　　　する）仮定が失敗したら自分の責任。客が違う、といったらや 　　　　　　　りなおす。提案することを前提にした仕組みつくり 　　(2)リリースごとの不具合解析 　　　各リリースごとに不具合を分析する(設計者ごとに)。それらは、次のリ 　　　リースに反映する。（危ないタスク、危ない人を手当てする） 　　(3)進捗管理 　　　エクセルシートを活用し、担当者の進捗を可視化する。 　　　開発の記録(工数、成果物、終了日)は反省材料として、仕様、開発の意 　　　思決定に使用する。 　　(4)データの一元管理 　　　ドキュメント、DR議事録、不具合情報のツールによる管理をすることで、 　　　探す手間の削減を行った。一元管理の専用ツールを作った。管理するの 　　　は、仕様書、DR、試験票、リリース管理、変更管理。これらをサーバー 　　　に入れて共有・管理するようにした。 今後の方針は、 　1)技法の導入 　　改善サイクルは回りだしたので、このまま継続的に実施しながら技法をプ 　　ロセスの中に入れていく。 　2)現場の自主的な改善活動。 　　若い設計者が自主的に改善できるように展開したい。QCサークルを知恵を 　　活用する場として活用する。 　3)マネージャーが足りない。 　　特に大規模なシステムを開発する時に感じる。問題意識が高く、改善能力 　　があり、部下の育成ができるマネージャーが欲しい。 最後に、CMMと15504は、書かれたものをそのまま利用するのではなく、開発ヒ ントを得て工夫することが重要。そのためには、目的をはっきり明確にさせな いといけない。CMMや15504を工夫するという姿勢が大切である。 ○豆蔵　濱野氏 　CMMの意義と導入の要点 　CMMはSW開発の成功原則を体系化した改善のフレームワークである。具体的 には、5段階からなる成熟度モデルが中心にあり、各成熟度モデルでは、”キ ープロセス”とそのゴールが定義されている。また、ゴールに到達するための 手法を提示してくれている。CMMの価値の中で特に重要なのは、製品に占める ソフトウェアの価値が上がっていることと、ソフトウェア開発の大規模化に伴 うソフトウェアの生産性や品質の改善が経営の問題として位置付けられなけれ ばならなくなった点である。 　そのような点で見た場合、CMMはリーズナブルな改善のフレームワークを提 供している。大きなところでは、SWの開発や組織の改善には順番がある。組織 では、まずオブジェクト志向の導入よりもプロジェクト管理を行うといった、 ステップをきちんと踏む事が重要。あと、特徴的なのは現場で問題解決型の改 善を行うことも重要であるが、組織全体と見たらプロセスの品質を上げて、そ の結果としてソフトウェアの品質・生産性を上げることも重要な考え方である。 CMMは現時点で最も有力な手法だと思う。 　一方、現場の人はCMMに対して抵抗感があるのも事実（重い、管理のオーバ ヘッドが大きくなるなど）。しかし、実際はそのようには考えていない。その 点を導入の要点として話す。 　まず、CMMの使い方を間違えている人が多い。現場の状況に合わせてプロセ スを作成することが重要である。SEPGがキーになる。プロセス(OSSP)は、適切 な人(現場の開発経験もある人)が作る必要がある。次に、プロセスは、プロジ ェクトにあわせて調整しなければならない(プロジェクトにプロセスが生かさ れなくなる)。重ければ軽く。不要な作業があれば削れば良い。重要な事は、プ ロセスはプロジェクトのゴールを達成するための戦略である。実際にそれがで きるようになるためには、プロセス要点を押さえたSEPGのサポートも重要とな る。 　次に、CMMに限らずいくら良いプロセスであっても、プロセスだけでは現場 はプロセスを受け入れられない。 ○新しいプロセスが現場で受け入れられるには、 　上級管理者のコミットメントとスポンサーシップ 　イニシエーション／動機付け(向かおうとしている方向) 　新しいプロセスの事前説明 　SEPGによる親身なプロジェクトのオンサイトサポート 　改善状況／結果のフィードバック ※プロセス改善は成果が見えにくいので、成果を定量的な目に見える形で見せ 　る事も必要である。 ○プロジェクト管理者にとって、CMMなどのプロセス管理は何をもたらすか 　・プロジェクトのゴール／現在の進行状況が共有され、一つのゴールに向か 　　い、一丸と障害を乗り越えていくことによる達成感がある。 　・見積もりに基づいた作業計画により、無理な作業がなくなる。 　・自分の仕事がどのように全体に影響するか見えるようになる。 　・実績が定量的に評価できるようになる。 　・新しい技術が導入され、新たに学んだ事が仕事に役立つ。 　・マネージメントが教育される（CMM:Change My Manager） まとめ 　CMMは有効な道具立ての一つ。問題は何にそれを使うか。SEPGは重要。 　現場が主体となって進めること。プロセスだけではダメで、もっとトータル に考える必要がある。 ＜ポジショントークを終えて質問から＞ 司会　CMMをあるプロジェクトチームで使う場合に、枠組みが決まっていると いう事は考える事が減り楽になる。古畑さんのようにゼロから考えることも いい事だが、フレームワーク／示唆を得る事があり、積極的にCMMを勉強しよ うと思う。プロジェクターとしてはどんなことから始めるべきか 濱野　SEPGなどが重要になる。自社で行うか、外にお願いするか。コンサルタ ントを利用する手もある。あと、CMMを導入する際に、視点がオブジェクト指 向だとモデリングという考え方から割とすぐに入っていけると思うので、戦略 をきちんとモデリングする。例えば、反復計画なら反復の所などをきちんとモ デリングして、モデルの満たす制約が何かを考える時にCMMなどを参考にする。 A　会議で発言しない人を削り、コアメンバーだけを抽出するということは、 全体に浸透させるという点で問題が出るのではないか？ 古畑　基本的に出ない人には議事録を会議の場で作成して送る。議事録を書け るような会議をしないと、結論が出ない。結論が出ない会議をするのは無駄で ある。会社では、会議を行うと社員がビクビクする。そうすることで、現場の 雰囲気が引き締まる。 古畑　（現場の話）現場では、入力に対する出力の効果が少ない。そこを最大 化する目的でメスを入れると、最初は言う事を聞かないが、だんだん楽になり、 最大限の効果が出てくる。経営の手法でいうABC、ABMの話も関連する。 B　失敗を2度と繰り返さないということを徹底するという事だが、自社ではバ グ管理ソフトを使用しているが、データベースは千件単位であり、検索も難し い。そのような状況で、新しく入ってきた人に失敗を2度と繰り返さないよう、 データベースを検索するように指示するのは簡単だが、実際には簡単には行か ない。どのように引用すればよいか？ 司会　バグは沢山出てくるが、原因を分析するのもいいと思う。スパゲティ状 になっているソフトはバグがたくさん出る。その中でよく見るのは「状態設計 をすればわかりやすいのに、全てフラグで書いていたり」、読むに耐えないコ ードがある。プロジェクトに入り、一緒にやっているお客さん側のコードのレ ビューをお願いする場合もあるが、重度の場合には書き直してしまう。ソフト ウェアの設計は確立されていないところがある(状態設計など)。一つの方法と しては、先輩社員が手本を見せて教育したり、作業ガイドラインに落としてい く。質問の答えとしては、バクを管理していてやばいと思うと分析しようとす る気が起きづらくなるが、どの段階で入ったバグか(モデルを書く時に防止で きた不具合か、実装の時に入った不具合か)を分析をしてる。 古畑　時間には限りがあるので、千数百件の不具合を処理できない。不具合に よってダメージがあるわけで、ひどい物順にならべ(ABCに分けて)ひどい物か ら絞ってつぶす。ひどいバグを繰り返すと責められ、開発者のプライドに関わ る。2つ目は時間との戦いなので、時間を考えて仕事を定義する必要がある。 しかしながら、時間は結構あったりする。経験的には、プロジェクトが終わっ た後などは、設計者は仕事をしているフリをしている。リリース後などといっ た時期には、大勢の中で一人は時間が余っている人がいるので、その人にお願 いするなどしている。 澤田　古畑さんが話していた議事録の共有の件に関連して、プロセスの共有の 面で浸透させるために工夫されているものはありますか？ 古畑　チームには最初はプロセスが何もなかったので、工程を作った。工程を 作らないと、反省ができない。ある程度の枠を決めてあげないと振り返ること ができないので、問題を解決するために工程を作る。 澤田　プロセスだけではなく、ルールも作られるわけですね。そのルールにつ いてはどのようにして浸透させるんですか？ 古畑　ルールを作るときは理想論ではなく、経験が長く一番要領の良い人の手 法をルールとする。簡単で上手く行っている所を使う。あまり無理な事は現場 ではできない。 C 自分のグループでもCMMが入り効果があったが、自分で問題意識をもって問 題を解決する事が重要だと感じた。その中で、まだハードウェアとのからみの 部分について自分のグループで解決していない。新しいチップなども出たりし ており、色々な組込みシステムがある。自分でも開発を行っているが、重大な エラーがでたりして、3ヶ月取られたりすることもある。現在のプロセスでは、 ハードウェアの事が考えられていなくて、そこは自分で考えなければならない と感じた。あと、興味があるのは、古畑さんのグループが上手く回っているの は、古畑さんの力があるからだと感じた。もし、古畑さんのグループで古畑さ んが抜けたらどうなるかと思い、部下を育てるということが重要だと感じた。 D 先ほどの話の続きとなるが、ハードウェアとのからみが問題。コンサルタン トをされてる人がいると思うが、ハードウェアとソフトウェアの切り分けの判 断はどのように行っているのか？ 司会　プロジェクト単位の話になるが、自分はプリンターと半導体を担当した が、ハードウェアの方には関わっていない(メーカ側に決めてもらっている)。 切り分けは、ターゲットや旧世代機のあるところからスタートする。自分の得 意な分野は、オブジェクト指向設計と実装なので、その部分はお客様にやって もらっている。プロセスにHWとの検証が入っていない話はその通りで、例えば eUMLでもあまり入っていないと思う。それらのについては、これからシステム 全体の要求分析などをして、システム全体のデザインをするプロセスが求めら れるのではないか。 古畑　HWの方は、新しいICが入ってくると問題が出る。プロセスの話は、最初 にどれだけ不具合が出るのかを予測するかが勝負となる。また、その予測をで きるのが技術者の能力である。 濱野　CMMの使い方というか、確かに今のソフトウェアCMMではハードウェア側 は考慮されていないが、CMMIになると本格的に入ってくると思われる。新しい システムが入ってきたときの検証については、最初にプロジェクト毎にプロセ ルをデザインしなければならないと思い、最初にライフサイクルモデルから具 体的に詳細化するが、その中に繰り返し型のプロセスを入れて、それを計画に 組み込んで評価を行いプロジェクトを進めると良いと思う。 畑　なかなか蓋を開けてみたら重厚な話が揃ってためになりました。最後に拍 手で終わりたいと思います。 ＜感想＞ 活発な議論が繰り広げられ、各企業のプロセスの改善に対する問題意識が高い と感じた。これは、組込みシステムの生産性に対する危機感とも取れると思う。 また、プロセス改善の実践経験についても議論が行われ、経験を生かすという 意味で有意義なものであったと感じた。