ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

ソフトウェアプロセス改善だねっコミュのSPI活動計画の成果って(ご意見募集)

  • mixiチェック
  • このエントリーをはてなブックマークに追加
こんにちは。くま吉と申します。

現在、SEPGで活動中なのですが、ちょっとばかり相談にのっていただけないかと。

うちの会社の体制は、社員400名のところに、SEPGとして2名、各現場部門(70名くらい)に兼務SPI担当者が1名×3部門の計5名でSPI活動を行なおうとしています。

まずは、各部門の持っているノウハウの情報共有からと思ってスタートしたのですが、なかなかうまくいきません。
で、上司から、「ゴールを決めてWBSまで落として活動するように」との要請がありまして。
確かにおっしゃる通りなのですが、どうやってゴールを設定すればよいか途方にくれています。
ここで、きちんと成果を出せれば、すこしずつ規模を増やすことができると思っているのですが。

もしよろしければSEPG活動の具体的な目標やWBSの立て方など、アドバイスいただけましたらうれしいのですが。

(不適切なトピでしたら削除くださいませ>管理人様)

コメント(20)

ゴールですか。
改善だろうがなんだろうが、ビジネスの目的・目標から落とし込むのが正しいかと。

例えば製品のコンセプトに、改善はどう貢献しますか?
改善を実施することで、どんないいものが作れるようになるのだろう?

そういうイメージが大切だと思います。
ほんださん>
 そうですね。現場部門が自発的な改善を回せ始めればSEPGはゴールを達成して解散してもいい。
 (というようなことを以前にくっしーさんも言っていたような。ウインク
 でも、今のところの現実はそうではない。どうやって"現場を煽るか"といったことも考えないといけないですね。

くっしーさん>
 製品などだと改善のイメージが明確ですね。"取っ手"の形が変わるとか、位置を変わるとか。
 ソフトウェア開発の場合の改善の貢献をどのように測るか、と。
 ROIで測るという話も聞きますが、プロジェクトのリーダーがたまたま優秀だったので成功したかも
 しれないし、メンバーが優秀だったのかもしれない。プロジェクトは一つ一つ違いますから、比較する
 わけにもいかない。
 そのあたりをどのように測っていくのか、と。ボケーっとした顔

むー、わけがわからなくなってきた。あせあせ(飛び散る汗)
なるほど。
「ビジネスの目的・目標」にどれだけ寄与するか、というところを、すべて「定量的」に見ようとすると、難しいと思います。それこそ、のぼるちゃんさんが言う「スキルアップや従業員満足度」など「定性的」な項目も、ビジネスゴールの1つと捉えることはできると思います。

そこを「数値的に測定」するのは大変ですが、「ふりかえり」を使って、チームメンバー全員がお互いにそれぞれの成長や成功要因(もしくは失敗)を評価して、次回の改善ポイントを抽出するということも、立派な「測定」の活動だと思います。

改善の場合は「定量的」なものと「定性的」なものを、バランスよく評価しながら進めるのが、わたしは理想的だと思っています。
> くっしーさん
 ご意見、ありがとうございます。
 なるほど、振り返りの機会を利用して、まずは定性的な評価をしましょう、ということですね。
 これは良い方法のような気がします。ありがとうございます。るんるん
CMM(CMMI)でもTPSでも最終目標は、例えばトヨタのように、すべての従業員“カイゼン中毒にかかっている”状態とか、“そうと意識せずにカイゼンが行われている”状態にすることだと思っています。CMMのレベル5で言う、“継続的なプロセスの改善ができている”状態とは、正にそういうことですよね(と、僕は理解しています)。そしてそれが、今いる人たちだけでなく、新たに組織に入ってくる人たちにも自然に伝染するような組織文化であることでしょうね。
つまり、CMMなりTPSなりの改善活動というのは、プロセス改善活動ではなく、組織改善活動もしくは意識改善活動なのです。プロセスの改善は、その結果、自然に出てくるようになるものだと思っています。

そうだとすると、数値目標を作って計測することは難しいでしょう。どうしてもくっしーさんの言うように定性的な目標にならざるを得ないと思います。しいて数値目標とするなら、一人一人の改善提案件数を計測するようなことですかね。でも、それが“ノルマ”のように捉えられてしまっは意味ないですね。

こういう目標はなかなか理解してもらえないかもしれませんね、なにしろ2〜3年で結果が出る目標ではないですから。組織文化を作り変えることになるので、それこそ5年、10年かかっても仕方ないと思います。だからこそ、CMMではレベルの目標を設定するんでしょうね。最終目標に到達するためのステップというか、途中のレベルはあくまでも中間目標でしかない。だから、どんなに不況であろうと、会社の業績が悪くなろうと途中のレベルでやめたり、当分の間活動休止なんてことはありえない。それこそ、明日倒産するというその日まで改善は続けなければならない。というか、当たり前のように続ける。

すいません、僕が日ごろ感じていることを書かせていただきましたが、なんかまとまりの無い文章になってしまって。
yachtman004さん>
 くま吉です。しろくまですよ。
 ご意見ありがとうございますexclamation ×2
 そうですね、組織に「カイゼンが当たり前になる文化」を定着させることがSPI活動の目的だ、
 というのは、まったくもって同感です。
 SPI活動って、実は、企業全体の業務改善活動なのかなあ、などとも思います。

基本的な理念はわかりました。

しかし、その一方で、現実はそうなっていないし、そのような理解ある経営トップはなかなかいない。もうやだ〜(悲しい顔)
改善をしようとすれば、その改善が企業にとって、どのくらいのメリットがあるのかを求められるのが
現実なのではないでしょうか。
そして、そうした現実の経営活動のなかで、「実際の」SPI活動として
 1SPI活動の計画をどのように立てているか、
 2実績をどのように測定しているか、
 3評価の基準を(誰が)どのように定めているか、
など具体的な、現実的なところを差し支えない範囲でお教えいただければ幸いなのですが。ウッシッシ
わが社の実際の活動(CMMに基づいた業務改善活動、略してCMM活動と呼んでいます)では、
 専任のCMM推進課を設ける。CMM推進課は、課長以下数名の組織。
 開発部門の各部に、SEPG(開発業務と兼任)を1〜2名任命する
という体制で進めています。

まず、CMM推進課が中心となって、セルフチェックシートを作成しました。内容は、PAごとに各種のプラクティスが充分に実施されているかどうかを、自己評価するためのものです。例えば、必要なドキュメントが作られているか、具体的な作業が行われているか、決められた計測が行われているか、等々です。
各プロジェクトでは、このチェックシートに基づいて開発作業を評価し、CMM推進課に報告します。頻度は月に1回です。また、自己評価だけではなく、SQAによる監査も実施します。こちらは半年に1回程度の頻度です。

1SPI活動の計画をどのように立てているか
→○○年○○月にCMMIレベル○のアセスメントを受ける、というような目標を立てます。各プロジェクトでは、その目標に到達できるように(つまりそのレベルになるように)、そのために必要なプラクティスを実践します。そう言ったからといってすぐに実施できるわけも無く、プロセスの整備や、計画の立案、トレーニングの実施などを徐々に実施していきます。

2実績をどのように測定しているか
→先ほど書いたセルフチェックシートによる自己評価です。評価の方法は、各種プラクティスの実施度合いを「十分」、「一部不足」「不十分」「適用外」「未着手」などで評価します。各プラクティスごとに、「十分」と評価するための基準が設けてあります。最終的には、「十分」と評価したプラクティスの割合(遵守率と呼んでいます)を算出しています。遵守率=「十分」の数/(設問数−除外数)×100[%]

3評価の基準を(誰が)どのように定めているか
→先ほど書いたように、社内に専任のCMM推進課があり、彼らが作成します。各プロジェクトでの評価時には、セルフチェックシートの各項目そのままではなく、プロジェクトごとにテーラリングしたプロセスに合わせて読み替えをしています。

まさに、CMMまっしぐら、直球勝負、って感じです。ですが、個人的にはとてもまずいやり方だと感じています。このような型にはめられた活動では、CMMのレベル4までは良いかもしれませんが、レベル5の「継続的な改善」を行うことはできないのではないかと思います。前のコメントに書いたような、組織文化を変えるような活動になっていないと思うので。
↑は個人的な感想なので、あまり気にしないでください。
>yachtman004さん
 くま吉です。
 ご丁寧な書き込み、ありがとうございます。わーい(嬉しい顔)
 なるほど、おっしゃるとおり「CMMまっしぐら」のようですね。
 でも、組織としてしっかりやられているようにお見受けしました。すばらしいです!

 参考になりました。ありがとうございました!
ふたたび、くま吉です。シロクマですよ。るんるん

年度も変わり(ってちょっと遅いですが)、より現場に密着したSPI計画の検討してみました。

うちの会社は、現場にプロセス改善の意識がまだまだ根付いていないので、
徐々に広めていこうと思いまして、SEPGで「EVM分析サービス」なるものを考えました。
プロジェクトから計画と実績を出してもらって、SEPGでトレンドグラフ、ブルズアイチャートなどを作成、傾向などをプロジェクトにリコメンドすることで、少しずつ現場にカイゼン意識を広めていこうとしたわけです。

でも、上司より「それはQCのミッションではないのか」との指摘がありました。
現場の品質を管理するのはQCの作業であろう、と。SEPGは、そのようなスキルをQCに与えるのがミッションなのだ、と。
むー、それはちょっとちゃうなー、と思っていたところに、別の部署の偉い人からも同様の意見をお聞きしてしまって(品質を確保・向上させるための技法・ツールをQCに与えるのがSEPGの役目)。

SEPG,QA,QCって、三権分立のようにお互いが独立していて、というのが、私の漠たる考えだったのですが、もしかしたら違うのかも、とちょっと弱気になったりして。

皆様の、SEPG、QA、QCの関係について、教えていただけると幸いです。
はじめまして。

私はフリーのコンサルティング(まだ仕事なし)ですが、
守備範囲を決める必要はないのではと思います。

現場が困っているのであれば即刻火消しに走る。
その結果、反省会とかで改善点をアクションアイテムにする。

SEPG、QA、QCは、1塁か2塁か3塁のどこを守るかみたいな
感覚で、大事なのは現場の最適化だと考えています。


プロジェクトが火を噴いたら、それこそレスキューのように
火消しに回る。それがSEPGの一番の役割では?

片付いたら、反省を活かしプロセスに落とし込む。
プロセスを固めた後はそれを実践する。私の考えです。


クローバー上さん、ご意見ありがとうございます。
 「現場の最適化」とは、どのような事をイメージされておられますでしょうか?
 生産性、品質の向上や効率化というイメージでしたら、品質保証からのアプローチ(QA的)と、エンジニアリングプロセスのカイゼンからのアプローチ(EPG的)では、なんとなくやりかたが違うような気がしますが...。
くま吉さん

現場の最適化とは、現場で困ってること中心に活動
することと考えてます。
それが、品質的なこともあれば、プロセスを定義すること
でもあれば、純粋なエンジニアリング的なこともあります。

それは、現場、現場で違うものであり、またミックスした
ものでもあるかもしれません。

私は現場が困ってること、ここにメスを入れたら大きく
改善されるのに ということをヒアリングを通じて
把握できればと考えてます。

とにかく目線は現場の困り具合です。
くま吉さん、はじめまして。

今は顧客常駐で SPI 活動を行っているモモタロスです。

うちの場合、品質改善チーム(SEPG)3 名が、PMO, QC, QA(SQA) を
兼ねているため、ソフトウェア開発改善から構成管理、PM 改善、
顧客(エンド)改善といったところまで同じメンバーが実施します。

従い、くま吉さんの上司様のような助言(?)はいただいたことは
ないのですが、かなり古い記憶をたどると SEPG の建前としては
上司様のおっしゃるような内容だったと記憶しています。
#そののちに監査する。

まあ上記の内容はむかぁしに SW-CMM をテーラリングしながら
勉強していた時期なので、QC を監査?現場を監査?と、
うろ覚えなので、はっきりいって自信はありません;;
#ただ、結果はどちらも同じゴールに着くとは思います。

SEPG, QC, QA が明確に分離しているような環境なのであれば、
作業領域は区分けした方がよいかもしれません。

うちは一緒なので、逆にやりやすいのかなぁ。。。

クローバー上さん
 ありがとございます。
 そうですね、「目線は現場の困り具合」というところは、ぶれてはいけないですね。

クローバーモモタロスさん(「オレ、参上exclamation & question」?)
 なるほど、もしかしたらSW-CMMあたりから来ているのかなぁ。

うちの組織は、まずQAが誕生し、QMS(というかISO9001)を構築したあと、
QCが派生、で、SEPGがそこから分離、みたいな感じで始まったので、
SEPGという"組織"のミッションが曖昧な気がしています。
「いっそ同じ組織だったら楽なのにexclamation ×2」なんて思うこともしばしば。
どうなんだろーもうやだ〜(悲しい顔)
こんにちは、yachtman004です。

SEPGの職分は、たしかに上司の方の言われる通り、考え方や技法、ツールなどを現場やQC(品質管理担当者)に伝達することだと思います。CMM/CMMIの考え方では、そのような品質やプロセスに関する計測を現場の作業(=開発プロセス)に組み込んで、その開発プロセス通りに作業を実施すれば、計測結果が得られる。その計測/分析結果に基づいて業務プロセスを改善できる、、、ということだと理解しています。

なので、SEPGがわざわざ計測したり、分析したりするのは、改善がまだ現場に定着していないということになるのかもしれません。

ただ現実問題として、業務改善に慣れていない職場で、何をどうやって改善すれば良いのかわからない、どこから手をつければ良いのかわからない、ということであれば、現場に対して「こんな分析をすれば、こんな結果がわかりますよ。だからこの部分に問題がありそうですよね」って示してあげることもできますよね。そして「次からは自分たちで計測して、分析して、業務改善に役立ててくださいね」ってのは、大いにありだと思います。そうやって現場に業務改善が根付いてくれれば、結果オーライなんじゃないでしょうか。
新人教育、技術者教育では、毎日、わかったこと、わからなかったこと、改善するとよいことの3つを報告してもらうようにしています。

20年近く続けています。

業務でそれを続けてくださっている組織もあるようにお聞きしています。
逆に、毎日の報告は無理で、折れてしまったという報告もお聞きしています。

昨年、当方で、ある方に、KPTのセミナを開催していただきました。
こういう講師の方にお願いすれば、毎日の報告も、豊富になることが理解できました。
#名古屋アジャイル勉強会でやってもらったので、その再演になります。

伝える人のSKILLの課題があることを再認識しました。

ps 今日のBestPractice & 教訓

自分でうまくできないことは、できる人を探してくる。

常に人だのみだと、自分が腐敗していくので、何回かに1回は自分でもがんばってみる。

成熟した先は、腐敗である。

腐敗とは、次の生命の元なので、Life Cycle Processの一つ。

腐敗直前が一番おいしい。

おいしい状況を持続するのは無理。

時間をかけて、次のおいしい状況まではその準備。

ps2
製品のLife Cycleに合わせるかどうかは判断です。

組織のlife cycleも考えた再編成は10年に1度はするとよい。

2−3年に1度する組織もあるが、TOPが変わるたびということで、本当にそれがいいかどうかは疑問。
クローバーyachtman004さん
 ありがとうございます。まずは、現場やQCの方と一緒にSEPGも自分たちで分析しながらやっていってみようと思います。
クローバーkaizen_nagoyaさん
 内容としては、プロジェクトファシリテーションに近いようですが、それが定着すると素敵ですね。

私の会社では、CMMIをベースにした、独自のプロセス標準があり、
先日、社内アセスメントがあったのですが、そのなかで、「EPGの作業として、
組織のQCDを分析し、組織の改善に役立てる必要がある」と指摘されたんですが、
それもEPGのミッションなんでしょうか?

いままで、QCDの収集・分析はQAに任せてしまっていたので、そんなもの、と
思っていたのですが、確かにQCDを把握する、ということは大事かも...。

みなさんの組織ではいかがですか?

ログインすると、残り3件のコメントが見れるよ

mixiユーザー
ログインしてコメントしよう!

ソフトウェアプロセス改善だねっ 更新情報

ソフトウェアプロセス改善だねっのメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。