@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
クオリティーコントロール
1|2|3|4
次のページへ»
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-04-05 09:20
私は以前工場にいました。
そこでは品質改善、クオリティーコントロール、あるいは工程管理ということで 少しでも早く、簡単に、正確に基準範囲内でつくるよう要求されました。 ソフトウェアの作成においてこれらの要素はどのように考えているのでしょうか | ||||
|
投稿日時: 2004-04-05 10:21
はにまるです。
現実レベルでの話を投稿します。 私は、4社渡り歩いていますが、製造業で行われているTQC活動レベルと比べ IT業界は、品質の意識と管理レベルが必要水準に対し低い位置にあると思います。 (私も以前、工場で働いていました。) この違いは、管理者や経営者の言葉で違いを感じる事が出来ます。 工場での時は、TQCの話をする時、B級品(品質規格外の製品)の数値を金額として表し、 損失額を提示して話をされていました。 なぜ、品質を求めるのかの定義が確りしており、作業員として理解し易かったです。 一方、IT業界では「品質」という一括りのキーワードで、あれも、これも語る為、意味不明です。 しかもその状態で、結果論として「テスト」という単一キーワードに持っていきます。 簡素に考えて、「品質」と言うキーワードを取り外して考えた場合、 多くの要求を「テスト」のみで解決する考えは可笑しいはずですが、 実際には「テストだ!テストだ!」と九官鳥の様に連呼する管理者が多いと思います。 # 以前に比べ最近は減りましたが... 正直、システム開発における品質向上の機構は、 管理レベルでは無く、現場にレベルに埋め込まれていると言うのが、実状と感じます。 つまり、管理が必要レベルの役割を担っていない。と言う事です。 今は、品質管理まで手が回らないと言うのが、私の周囲での大半の意見かと感じますが、 一方で、議題に上げたら、皆「最重要事項だ!」と言う姿を容易に想像出来る所が面白いですね。 一体、何のジレンマなのでしょうか? 「品質管理の仕方」が解らないのかな?「品質管理=自分で自分の首を絞める」の図式かな? # 編集-追記 今、どの様に取組んでいるのか?の記述を忘れていました。 1.表向きは、管理者の要求通り「テスト」でのみ品質向上を維持しています。 2.裏では、仕事に基本手順である「依頼」→「確認」→「作業」→「検証」→「実施(公開)」→「報告」 を自分の直接管理配下で行っています。 2つ目の作業で、規定以上の品質は出せる為、今はここで停止です。 # 編集-修正 「品質企画外」→「品質規格外」に訂正。流石は誤字脱字王! [ メッセージ編集済み 編集者: はにまる 編集日時 2004-04-05 12:41 ] | ||||
|
投稿日時: 2004-04-05 12:46
ソフトウェア工学でいえば... あれは、宇宙/軍事分野の「絶対に失敗してはならないところ」で 使われるソフトウェアについてのものですから、本来、「早く」 とか「簡単に」という考え方が無いですよね。 で、それをムリヤリあてはめようとすると、「何も管理を していないも同然」ということになるわけで。 では、そういうソフトウェア工学に代わるものがあるかというと... [ メッセージ編集済み 編集者: ぽんす 編集日時 2004-04-05 12:47 ] | ||||
|
投稿日時: 2004-04-05 13:11
まぁこのあたりが品質管理を取り違えているところだと思いますね。 テストは品質向上の最終的な歯止めの部分で、TQCなり品質管理の根本はもっと 前のところで行われなければ意味無いのですけどね。 ただ、ソフトウェアの品質管理のうちボトムアップとしてのQCにはSWQCとかいう QC活動を行っているところもあります。(効果がどうかは別として) 逆に、トップダウンとしてのQCというのが確立されていないのですね、これが。 せいぜい、設計書の様式、コーディング規約、テスト方法等にとどまっているところで す。要因特性図を書けばすぐわかるとおり、主となる要因のほとんどが「人」にかか わるものなのでなかなか難しいわけです。 もうひとつ言えば、工場等製造業で行われる品質管理の基本は、「良品」を作ることを 目的にすることではなく、「ばらつき」をすくなくすることにあるので、そのままの形 ではソフトウェアに置き換えられないでしょうね。多分、製造業での品質管理とは別に 新しいジャンルでも作らないと難しいのかもしれませんね。 [ メッセージ編集済み 編集者: Beatle 編集日時 2004-04-05 15:51 ] | ||||
|
投稿日時: 2004-04-05 13:31
みなさんありがとうございます。
やはり品質管理の方法なり手法が確立されてない、あるいはやりにくい ところに問題があるのでしょうか? あまりソフトの世界では品質管理という言葉はきかないですよね。 俺だけかもしれないけど? | ||||
|
投稿日時: 2004-04-05 14:30
以下、あくまで個人的な意見です。
絶対正しいなどと言うつもりはありませんので、そのつもりでご覧下さい。 よく、プログラミング工程のことを「製造工程」とはいいますが、 プログラミング工程と製造業での生産現場の工程は全然違うと思っています。 ソフトウェアの製造で、工場での生産に相当するのは、CDのプレスとか パッケージングとかだと思います。 つまり、個別システム構築では存在しない工程かと。 普通の、量産工程を含むような製造業に敢えて例えれば、詳細設計〜試作あたりの 工程に一番近いと思います。で、この部分での品質確保にはどのメーカーも苦労 しているというのが私の認識です。 まぁ、このあたりの工程と比較したとしても、まだ製造業の方がソフトウェア産業 よりは品質管理に関して進んでいるとは思いますが それでも日本の生産現場の非常に高い品質管理と比べるのはちょっと無理が あるかなと思います。 # もしくは、単品受注生産で、受注ごとに図面から引きなおしているような # 業務形態の製造業なら、生産現場に近いかも。(ほとんど職人の世界?) # こういうところって、どうやって品質管理してるんでしょうね? で、肝心の「どうすればいいのか?」については、私にもさっぱり分かりません
そんなことはないですよ。 大手ベンダーだと、ISO9001の認証を取ってるところもありますし。 # ちゃんと機能しているかは別として | ||||
|
投稿日時: 2004-04-05 14:45
はにまるです。
皆様の意見を聞くと、私自身も品質管理に偏った考えがありそうです。 特に、製造業の品質管理であるTQCが私の基本になっている為、 Beatleさんの御指摘は、身に染みます。 また、ぽんすさんの >「絶対に失敗してはならないところ」で 使われるソフトウェアについてのものですから は確かに、業務アプリと一色単に考えるのはマズイな...と感じました。 私は派遣者なので現状は、派遣先の品質基準より、ちょっと上のレベルで仕事をすれば 済んでいますが、管理者になった時の事を考えると...まずいっすね。 考える必要がありますね。(それほど深く考えていない自分に気付いた。)
私の場合、用語は聞く、残骸のみ見た事が有る程度です。 1.「プリクラのフレーム」と価値の違いが解らない、装飾性を目的としたのであろう 「設計書のテンプレート」 2.「仕事の基本概念」から考慮されていない事がありありと解る、 規定者自身も守る事が出来ない程、応用性の無い「作業手順書」 3.分析なんか過去一度もされず 管理者達の情報工作道具に目的が変わり果てた「障害報告書」 って所です。 無論、「管理」とはほど遠い概念から発生している作業ですが。 | ||||
|
投稿日時: 2004-04-05 15:02
製造業とソフトウェア開発の対比というテーマですと、マス・プロダクションな製造業ではいかに規格外品による損失を下げて歩留まりを良くするかという基準があるのに対し、ソフトウェア開発では、大量にライセンス販売されるものであってもソフトウェアとしては一つですから、マニュファクチャー的な側面が強いように思います。
製造業になぞらえて言うと、大工場ではなくてオーダーメイド品を専門とする町工場のイメージが近いかもしれません。 (私は製造業に従事したバックグラウンドがないので、外していたらごめんなさい(_ _)) そこでソフトウェア開発とオーダーメイドで精密なパーツを作る町工場の対比に勝手に話を持って行きますが、例えば板金加工を挙げても、設計図面という確立されたドキュメント形式があり、寸法や許容誤差が仕様として与えられます。 この仕様はソフトウェア側では詳細設計仕様の粒度を持っていると私は考えます。 けれどもソフトウェア開発の受発注に目を向けると、そこでやりとりされる仕様は機能仕様や性能仕様であり(外注の場合は、誤差にあたるものとして、期間ごとの障害発生件数と対応工数、障害収束曲線等の予測と実績が求められますが)、製造業での図面と比較すると非常に粒度の荒い情報しか扱えていないというのが私の感覚です。 場合によっては機能仕様の網羅性が低かったり、性能仕様として現実的には無理な数値を挙げられたりしますが、前者はまさに「人」に由来する要因です。 これについては、豆蔵の萩本さんをはじめとする方々が「要求開発」というキーワードで精力的に講演や執筆をされていますね。 「人」が主因となる受発注ギャップを埋める方法として、私も勉強中です。 あと、私も一応ソフトウェア・アーキテクトと名の付く仕事をしておりますが、いくつか担当した案件では、発注する側はビジネス文化の用語で話をするし、受注する側はテクノロジー文化の用語で話をする傾向が強いと感じています。 (主に受注側の立場ですが、受発注の間に立って双方の文化を「通訳」するという案件もありました) 完全に同じ文化で話ができないという点が製造業と比較したソフトウェア開発の現状の問題点だと思いますし、受発注の双方がお互いの文化を理解できるようにならないといけないと強く感じている次第です。 共通の記述言語として UML が登場したのがギャップを埋める端緒であり、二つの文化が同じ言語で書かれることによりシームレスにつながっていく次のステップが MDA といったところでしょうか。 品質管理からかけ離れた散漫な内容になってしまいましたが平にご容赦を(_ _) |
1|2|3|4
次のページへ»