=========================================================================== セッションC1 タイトル:組み込みソフトウェアにおけるソフトウェアプロセス改善:SPI(CMM/SPA) 講師  :小川清(名古屋市工業研究所) 会場規模:F会場60人席 参加人数:30〜40人程度。 =========================================================================== (講演内容を速記記録風に記録) はじめに: 昨日あちこちのセッションでも言いたいことが言えない事が多くて、このセッ ションの最初で喋ろうと思っていたが、教育のセッションで司会者をやること になっているので、そちらで喋ろうと思っている。 仕事としては名古屋市工業研究所。目的としては中小企業向けの技術指導。 今日は私の誕生日。 日経新聞より。  大手のパソコンメーカーが生産で提携  官庁の64事業開放。など。 みなさんが興味あるのはどの記事か? 宮城県などと一緒にやっているプロジェクトというのは、TOPPERSの色々なCPU の展開や開発をやっていいる。 毎日違う仕事をしている。 プロセス改善: 日本版CMM プロセス改善協議会には参加してない。ソフトウェアプロセス改善委員会とい うところのメンバー。ISO/IECの規格をつくるにあたって色々調査するためにお 金をつけてもらおうという話が最初にあったが、経済産業省にお金をつけても らっても良くはならない。 e-Japanなど電子政府の調達を、調達側のプロセスの改善を行うよう要請。 しかし色々な圧力がかかる。 既存の調達先から仕事がなくなると反発。 新規参入側からは、参入の条件の基準のほうを変えて欲しい。 前向きなところをメディアに載せると圧力がかかる。 トップダウンじゃなきゃだめだという人がいるが、トップダウンでやったこと がない。ボトムアップのやり方しか説明できない。フィードバックさえかかれ ばどちらでも良い。問題は二重管理にならないかということ。矛盾した二重管 理にさえならなければどうにでもなる。 仕事の目的が明確になっているか。そうでなければプロセス改善も意味がない。 用語の違い。プロセスとは何か?と思うような言葉。書かれている用語と自分 達の使っている用語の違いで惑わされる。 使えるものなら浸透する。 「やる問題があるからやるだけのこと」 客観的な把握の前に主観的な把握があるか。 方法自体に客観性があると思うのではなく、目標に向かって進んでいればその 事によって客観性も保証されて来る。 新しいプロセスの模索・思考・評価。 同じ事をしたくない人が取り組まなければならない。 良い製品は良い作業(プロセス)から生まれるという仮説。 自分達が考える良い作業(プロセス)から良い製品が生まれるかチェックして いるか?アウトプットの評価をしているか。 ソフトウェア品質に関するISO/IECの規格。 MADE IN JAPANの国際規格。 利用時の品質。 どういう品質を利用時点で示すかをはからないといけない。 各作業の段階ごとに、その品質をどういうものにしたらいいかきめていない。 ソフトを開発してる会社をみると、プロセスや品質の改善の前に人の待遇の改 善をすべきと思う場合がある。 どういう人がいて誰が何を作ったかがわからないと何をはかればいいのか、ど このプロセスを改善すればいいのかも分からない事がある。 プロセスとは何か? 自分達で決めている定義。  プロセスの標準を決めているか。やっていることを改善しないか。  自分達がやっていること、なにをやるかを決めるのは自分。  決めるにあたっては入力と出力はなにかを定める。  何がスタートか、何ができたら相手に渡すか。  そもそも何のためにそれをやるか。 こういうことを定めずにプロジェクトの作業標準とか、組織の作業標準を決め ても、いわゆる二重管理になるだけで、上で決めたことと下で決めたことで別 々のことをやっている。 標準がないからって遅れていると思う必要はない。 作業標準とは規定値の作業を決めるものである。 効率を高める。無駄な作業を省く。 プロセスのモデル: プロセスモデルにはいろいろなモデルがある。 アセスメントモデル: アセスメントするためのモデル。作業するためのモデルではない。 作業についてはかかれておらず、目的と成果のみかかれている。  作業定義 何をやればいいのか。   入力(開始条件) 品質(開始、受け入れ)   出力 品質(初期渡し、最終) セミナーにおいて実施したこと。  作業定義を一から書き下す。  作業にはどういう入力があるか。出力があるか。  そこから作業標準を作っていく。  作業は何のために何処を向いてやっているかということを揃えるために   ・入出力の優先順位付け。   ・開始と終りの条件。   ・メンバーの合意。 優先順位のつけ方。 PSP(Personal Software Process)での考え方  ある出力をするためにどれくらい時間をかけるのか。  目的のために今やっている作業はどういう役割を果たすかということを考え  てやっているか。  最終生産物に致命的な影響を与えるのは何か。 組み込みシステムには作業標準がなかった理由。 →それでも製品が作れたから。 一定以上の仕様で、期間も短くなって人も投入できない状況では途方にくれる。 途方にくれる前にできていたとき何をやっていたかという事を記録。又は弟子 に記録させる。私が開発者のやっていることを記録。 無意識に不具合を避ける操作、処理。初期条件、試験。 ベストプラクティスだけで、規模が変わっても可能。 ターゲットががらりと変わると不可能になることも。 必要な事は何か、必要な人材は何かということが制約条件として大きな位置を しめる。 要求における問題点は正確性。 オブジェクト指向などの言葉の意味の認識の差。 技術用語の意味の違いを確認しないといけない。 階層的な用語の定義が必要。 コンピューターに曖昧・矛盾した定義は致命的。 立場により一つの製品に対する事実・見え方が違う。 組み込みと組み込みじゃないところがちがう? 組み込みじゃない世界でもパッケージソフトと受託ソフトを作っている会社で は作っていることとかやり方とか、プロセスや仕事も違っていて、組み込みと 組み込みじゃない世界と同じくらい違う。 仕様が最後まで決まらないのはどこでもあること。その要因が違う。 開発環境・離夜環境・ハードウェア制約が決まっている場合とそうでない場合。  作業を進めながら予算・人材を変更できるか。  リアルタイム性に対する要求の差。  出荷後の変更が可能/不可能。  資金の制約、人材組織の制約。 CMMはマネージメントに分類されている。 どんな管理活動があるか。  根回しプロセスのチューニング。  顔色を見る。   プロジェクトマネージャになったらメンバーの顔色を毎日見るのが一番メ   インの管理活動。 何かモデルがあればうまくいくわけではない。  根回し ボトムアップ あうんの呼吸 をプロセスと思ってよい。 日本ではコンサルテーションにお金を払ってくれない。 モデルの説明をし、やってみましょうという話になるとお金を払うという会社 が多い。官庁は没落しない。官庁の仕事もプロセスモデルで評価してくれれば 良い。 「ソフトウェア開発作業は楽しくなければならない。そうでなければ間違っている」 テストのセッションでテストを楽しむにはどうするかという具体的な話は出な かった。  楽しい/楽しくない→気の持ちよう。 仕事ならば辛いこともある。自分は挨拶が苦手。 天才ならば遊んでいても凄いものを作る。 学生を磨く?  天才だったら磨かなくても光る。  原石のままのほうがいい人もいる。 ※続きは教育のセッションで。 ソフトウェアプロセスの改善: 部分の最適化は全体の最適化ではない。 全体的な最適化が大事だからといってトップダウンでくるのは好ましくない。 部分の最適化をなるべく残して無駄な部分が生じないよう全体を最適化にする 努力をしない人が多い。 改善をどうやったらいいか。  アセスメント。  東芝ではアセスメント=診断 開発・利用の目的にあった管理になっていないところを改善する。 評価は開発、ターゲットの利用目的に添って行う。 指標が決まっているものではない。 対象に対して分かっている人がいないと評価できるものではない。 組み込みと組み込みでない場合ではそんなに差がないが、規模によっては大幅 に差がある。 一人でやっている人でプロセス改善に興味のない人に言いたい。  ・秘伝書を作らないのか?  ・将来の自分のためにコメントを作らないのか?  ・自分を弟子にとってもらえば良い。  ・凄いことをやっている人は弟子がちゃんと記録を取って、作業標準とすれ   ば有効に使える。  ・新しいことをやりたい人にとっては過去のベストプラクティスをみたくな   い。  ・その人の記録をとってそれをまねればうまくいく場合も。 組織規模での違い: 10人の場合。  得意不得意を考慮していないことが多い。  それぞれの能力のある人に作業分担。  技術の調査は終わっているか?  マネージャだけが仕事をしているプレイングマネージャ。 100人の場合。  50人でできるはずなのに100人集めてしまうと、うまくいかない場合がある。  人数が増えれば増えるだけ情報交換の組み合わせが増える。ノイズが入る。  アセスメントよりも先に人数減らすべき。  100人のリーダーは全員の顔色を見る。 1000人の場合。  アセスメントがすごく有効。  人材・環境が整っているはずなのにできないのはコミュニケーション・作業分  担がかみ合っていない。  プロセスという単位で区切ってそれぞれが何をやれば良いのかを合意。 10000人の場合。  (私は)経験がない。  1000人ごとにプロジェクトをわけてアセスメントするべき。  でないと無責任な人間の集合になる。 誰の為のアセスメントか。 管理者に現場を理解してもらう。 組み込み系とそれ以外でも変わらない。 開発の必要がないにも関わらず、それを開発してる場合がある。 誰かが仕様を言う。受けたほうは仕事が増えるから作る。 人間が好きじゃない人が人間の管理をしないほうがいい。 今既にいいものを出しているところは今が一番最適で、改善の必要がないと言 っても良い。 成熟度が高ければ良いわけではない。 成熟度モデル: 成熟した後は腐るだけだが、成熟したまま維持できるわけがない。 その状態が一番いい状態であることもある。 成熟度モデルというのはプロセスの評価のたった一つの指標に過ぎない。 成熟度以外の評価があっても構わない。 必ずしも成熟度が高い事を目標にしているモデルではない。 規模が大きくなると組織・管理活動もある程度成熟していかないといけない。 体系化した指標: 作り直すつもりがないなら過去に作ったもモデルは使わないほうがいい。 Product, Process and People: 管理プロセス改善モデル、CMMなどは人間がちゃんと集まっていることが条件。 対象となる技術にちゃんと能力のある人が集まっても巧くいかないときの為の やり方。集まっていない場合は、そうでない人を底上げする為のモデルになる。 それそれのプロセスごとにプロダクトの評価をしなければプロセスの評価にな らない。 ソフトウェアプロセス: ベストプラクティスの体系化。 能力標準。 今後の課題。 違う言葉であっても、同じ意味である場合がある。それで論議をしていてもし ょうがない。現場で今何を改善したらいいかを考えたほうが良い。やる気があ ればなんでもできる。 質疑応答: Q: 大変興味深いお話をありがとうございました。さっき何人で開発してるかとい うところで、1、10、100、1000、10000ってあったんですが、WINDOWSの開発な ど何人で開発しているか分からないんですけど、10000人で開発することは実 際にはありえるのでしょうか。 A:自分では経験ないんですけど、なんかそういう噂は聞いてるんであるらしい という。9000人くらいが遊んでいて、1000人くらいが開発してるんじゃないか とは思うんですけど。 もっとひどいのは4000人くらいが4000人くらいの足を引っ張っていて、8000人 くらいは何の効果もなくって残り2000人だけが製品を作っているんじゃないか とか思っているんです。 10000人全員が生産的な活動をしているとは到底考えにくい。10000人で開発し てるプロジェクトには一遍チームで入りたいとは思ってるんですけど…あれば 是非お誘いください。 働くほうのメンバーになりますから。 Q: 先程の CMMのアセスメント実際の作業、作業内容を自分達の中で作業をしてい く中での標準というものがアセスメントするときにはあると思うんですが、そ の時は毎日の作業のアセスメントを変換する作業でやっていくのが宜しいんで しょうか。 A:それはそのプロジェクトの規模にもよるのですけど、何人くらいを想定して いますか?  Q:現在5人くらいのプロジェクトを考えています。 A:5人くらいのプロジェクトであればアセッサーのほうが変換を話を聞きながら やるんでアセスメントを受ける側が変換する必要は全然ないんですよね。 それができないようなアセッサーであればその人にはやってもらわない方が良 いんですよね。  Q:特にアセスメント為ののテンプレートをやっていくことは…。 A:自分がアセッサーになるつもりであればやっていただければ良いと思うんで すよ。アセッサーは外から呼んだ方が良いか、それとも中のプロジェクトマネ ージャがやるほうが良いか間接部門の人がやるほうが良いかっていうのは、そ の会社の仕事の仕方や風土によると思うんです。アセッサーの立場として振舞 うんであればそれをやってください。 Q: 大変興味深いお話をありがとうございました。参照モデルの話で、レベル5迄 行ってその後は落ちるだけ、腐るっていう話があったと思うんですが、それっ て言うのは具体的にはプロセスの改善の仕組みが巧く動かない、そういう事で 宜しいんでしょうか。 A:改善の仕組みが巧く動かなくなるって言うよりも、そんなに最適化しつづけ てると例えば日本のQC活動がかなり巧く行っていて、本当に成熟して制度とし ても確立して、色んな仕組みが一杯出来たんだけれども、段々その仕組みの中 で評価できない無理がどっかに出来てきて、例えばISO9000とかっていうのが バンとでてくると、もうやめちゃおうかって言う事になったりとか。 だから何がトリガーで下に落ちるかは分かんないんですけど、やっぱり最適な 手法を通しつづけてると言うのは凄いストレスがたまるんで、やっぱりその組 織は10年くらいは組織にいることはできても、やっぱり息は詰まる気はします よね。そういうプロジェクトに居続ける事に耐え得る人が何人いるかという事 になるかもしれないですし…。 Q: スライドの方で違うことを仰っているので確認したいんです。はっきりと言え ば。あるところではまったく組み込みソフトウェアもそうでないところも一緒 だとおっしゃってる。その真意がわかりにくかったのですが。 A:一緒だって言うのは何が一緒かって言うと場合によって違うと言う事が一緒 だっていうことを言っただけなんですけど…。だから、具体的にどういう組み 込みの開発とかをされていっていると言う具体性が出来ればそれに対してどう いったプロセス定義がいいかとかっていう議論ができるっていう話が一緒なだ けです。  Q:よく分かりました。どうもありがとうございました。 A:でも3分前に言った事を忘れちゃうんで、そうかどうかは保証はしないんで  すけど…。 司会者 いずれにしても組み込みソフトをいくつかカテゴライズした上で、もう少し突 っ込んだプロセス改善の話をすると言う手は一つあると思います。SWESTの方 でSWESTディスカスというメーリングリストがあるんで、引き続き議論をして いきたいと思います。 感想 開発プロセスの話など、現場で誤解されやすいだろう事を非常にわかりやすく お話されていたと感じました。時折笑いで会場が沸くなど、終始和やかな雰囲 気のセッションでした。