• ベストアンサー

品質マインドについて

プログラマーをやっています。 最近現場で品質マインドの向上を向上させろと言われています。 品質マインド=つまりは品質に対する意識を向上させるということだと考えています。 設計書の書き方ひとつとっても、「これをわかりやすく書くことによって、実際にプログラミングするときのミスを減らすんだ」なんて、意識しています。 ここで疑問に思ったのは、この「品質マインドの向上」を目的とする場合、それが達成できたかの評価が必要になると思います。 その際に、この目に見えないもの、数値化できないものをどのように評価すればいいのでしょうか。 取組例とあわせて回答をお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • 0909union
  • ベストアンサー率39% (325/818)
回答No.1

投稿者の意図を測りかねますね。まあ、どんな意図としても、まず http://search.yahoo.co.jp/search?p=JSTQB&aq=-1&oq=&ei=UTF-8&fr=ie8sc&n=10&x=wrt の事を知っておられるのでしょうか? その関連の関係者の投稿でしょうか? >品質マインドの向上 これは、そのことだけでなく、他のことでも同じなので、さして特別な指標があるわけではない。 よく出てくるのが経済指標ですよね。景気が向上しているか、100社とか1000社とかの社長に聞いて、政府が経済動向を発表していますね。 あれも、「マインド」であって、実際に物が、どれだけ売れたとか、お金がどれだけ動いたとかの統計上の指標ではない。 社長が「上向いている」と回答すれば、上向きに一票として集計される。単なる感じた事を社長が回答しているだけ。 なにせ、「上向いている」なんて思う根拠は、人それぞれで、それらを指定して、それについて上下しているのか聞いているわけではない。 これらを例にして、サンプルすると、 ・まず「JSTCB」の参考書を読んだ。 ・「JSTCB」の資格を取得した。 ・「JSTCB」の参考書にあるような事を実行した。 ・QCD? 改善行動とフィードバックをした。 など、実際の取り組みを行動を実施させ、この項目も当事者にリストさせる。 これらの行動によって、実行前と、実行後の意識をアンケート調査。その総計の違いが、 つまりマインドの数値化になる。 これは一例で、不具合に対処する時間(解析、修正、それらに関係する時間)の総計の上下でも、推し量る事もできる。 品質マインド = 不具合に対処する時間の削減 = 残業時間の削減(コスト減) = 顧客満足度の向上 を会社は目指すわけだ。それらの時間や金額を具体的に下げるのが(又はあげる)の最終目標。 その最終目標を踏まえれば、おのずと、数値化しなければならないものが見えてくると思うが、 ひんとになったかな

関連するQ&A

  • 品質保証部と品質ISOの関係

    私の勤務先の品質保証部では、新製品や設計変更時のQA評価は、原則として設計部門が計画から実施までを行うことと考えており、設計者が作成したレポートにハンコを押すだけです。 ハンコを押した責任も特に負うという意識はなく、市場不具合が起こり、顧客に事情を説明しなければならないような場面でも、平気な顔で「評価は設計者が行っているので、私は詳しいことはわかりません。だから、顧客への訪問は設計が行ってください」というスタンスで、市場不具合の責任の一部が自分たちにあるという意識もないようです。 社長の前で行われる会議でも、市場不具合の原因についての説明で、品質保証部長が、平気な顔で「設計部門が、こんないい加減な評価をしていました!」と社長に言いつけたりしています。それに対する全社的なムードも、「設計、ちゃんとやれよ」という雰囲気です。 専門家ではないので、逐一条文を読んだことはありませんが、品質ISOでは、私の理解では設計部門が自分で評価してOKしていたのでは、意図的な不正や、意図的でなくてもバイアスのかかった評価になってしまうので、わざわざ別部門として品質保証部をつくって中立的な評価が実施されるような体制を求めていると思っています。 一応、品質ISOの監査は、毎回通っていますが、こんな姿勢でOKなのでしょうか? こんど、品質保証部門の人と話す機会があるので、このあたりを話題にしてみたいのですが、品質ISO上、QA評価の実施方法についてはどのように規定されているのか知りたいです。(特に、品質保証部門が果たさなければならない役割について)

  • 目標管理シートの書き方について

    現在駆け出しのプログラマですが、このたび会社で半年毎に目標管理シートを記載し、下記についてどういう目標を立て実現をめざすかということを記述する事になりました。 1. 利益率の向上 2. 納期の厳守 3. 不良の再発防止 4. 品質の向上 5. 会社業務の生産性の向上 6. 個人の技術力の向上 そして私が思うに下記のような制約があるのですが、この状況下で適切な目標とはどういうものかというのが分からなかった為、アドバイスいただける方がいらっしゃいましたら、ご教示の程よろしくお願いします。 1. 半年毎に数値で評価する事が可能な目標にする必要があると思います(例え数年かかる目標でも、半年毎にその進捗状況が数値で評価できる目標にする必要があると思います)。 2. 一応業務のメインはプログラミングですが、設計などを行なう可能性もあり、半年の間にどのような業務を行なうかは目標設定時には分かりません (大まかに絞れば、ソフトウェア開発ということになりますが、例えばプログラミング色の強い目標を設定した所、実は業務でプログラムをやることがほとんどなかったという可能性もあり、あまり狭い範囲に絞った目標の場合、自分でコントロールできない所で目標が達成できなくなる可能性があります)。 3. プログラミング言語はその時々で適切と思われる言語が決定された状態で指示される為、半年の間にどのような言語を使用するかは目標設定時には分かりません。 なお、アドバイスについては、具体的な目標、及びその目標の達成基準をご教示いただいてももちろん大丈夫ですし、こういうサイトがあるですとか、こういう考え方があるですとかというような情報でも大丈夫です。 アドバイス等によっては、特定の会社では使えるものの、特定の会社では使えないことなどもあると思いますが、できるだけ多くの意見をいただけると参考になり助かります。 また、情報不足等があり、補足が必要でしたら、その旨ご指摘いただければと思います。 以上、よろしくお願いします。

  • MBO(目標管理シート)の書き方 SE

    上司からMBO(目標管理シート)を書くように依頼されたのですが、何を書けばいいのかわからず困っています。 私はソフトウェア開発の会社に入社して2年目になります。主な仕事は設計書の作成とプログラマの進捗管理になります。 ひとまずMBOに ・納期の厳守 ・品質の向上 の2項目とそれを達成する為の方法を記載して提出したのですが、 上司に 「出来て当たり前の事は書かないで欲しい」 と言われ再度考えることになりました・・・・ いったいMBOとは何を書いたらいいのか分からなくなってきたのですが どういった目標を書けばいいのかご教示いただけないでしょうか?

  • プログラマってかなり凄いのでは?

    私はソフトウェアエンジニアをしています。基本設計からシステムテストまでを担当することが多いです。 個人的に、設計〜テストの中で一番難しいのは、設計ではなくプログラミングだと思っています。 何をするにも沼にハマるのが普通で、非常に多くの情報を頭の中で捌いて解決するのを延々と行う工程です。 しかし、設計とテストをしないプログラマをIT土方と定義するなら、彼らは過小評価されていると思います。 たまに「設計したらあとはプログラマに放り投げるだけや。簡単や。」みたいな声もききます。さもプログラミングが簡単であるかのように。 私の体感と大きく違いますし、こういうことを言う人に実際プログラミングをやらせたら多くの人が挫折すると思っています。まず環境構築で絶望し、チュートリアルに毛が生えた程度の実装で悶え苦しむと思います。 プログラミング工程の難易度について皆様のご意見をお聞きしたいです。

  • 高校生の規範意識の低下に対して

    現在、高校生の規範意識が低下しており大きな問題になっています。私は学校現場で、この問題解決に取り組むために様々な施策を考えています。ボランティア活動や、社会奉仕活動など。 しかし、どれもピンときません。 何か高校生の規範意識の向上に繋がるような取り組みはないでしょうか?? できれば具体的にお願いします。

  • 皆さんはどうされてますか?

    はじめまして。私、某加工処理業の営業をしてます。 この不況のさなか、品質の向上による他社との差別化を図ることこそ、生き残る道と思い営業してますが、現場作業員達にはなかなか理解されず、あまり強く言うと現場にそっぽを向かれてしまいます。 彼らは彼らなりに努力はしてるのですが、肉体的努力であって、私の望むものではありません。 どうしたら、現場作業員の意識を変えることが出来るでしょうか?

  • QMS部門計画

    (1)6.2(b)で、品質目標は「測定可能である」ことが求められると思いますが、「目標10件達成」に対して、9件実施できていれば、表記方法としてそれでOKでしょうか?。達成率として90%といった『%表示』をする必要があるということでもないですか? (2)部門計画に、「技術習得」として、具体例を数件挙げるということは、問題ないものでしょうか?それは力量評価であって、スキルマップ、教育訓練表で管理すべきであり、部門計画に掲載するのはありでしょうか?掲載した以上は、「測定可能である」ことが必要になるので、数値による達成度の記載が必要になりますよね?

    • ベストアンサー
    • ISO
  • SEの将来性について

    SEの将来性について 現在、入社3年目でSEというよりはプログラマをしております。 大学はプログラミングとは全く関係ない普通の大学を出ました。 入ってみてわかったことなのですが、まわりに40、50代のプログラマがいません。 (「プログラマ35歳定年説」も働くようになってから知りました。) 私の周りでは40、50代に近づくにつれ営業や、プロジェクトマネージャ、上流の設計に 移っていっているようです。 しかし私はプログラミングは好きな方ですが、営業や上流設計等に あまり興味がもてません。 しかしこのままプログラミングのみで進むのも(技術面、給料面でも)厳しいかと思っています。 一度、キャリアアドバイザーの方にも相談したのですが どこの世界でも40、50代になったら1線で活躍するのは難しい もし転職するとしても同じSE業界でないと厳しい とのことでした。アドバイザーの方には感謝しているのですが 「1線から退くこと」と自分の周りに「全くいない」という状況を 一緒にすることにやはり違和感を感じます。 そこで参考までにSEの方に2点お聞きしたいのですが ・皆様の周りの40,50代の方は何をしていらっしゃるでしょうか。(極端な例ではなく傾向をお願いします) ・これからのSE業界はどうなるとお考えでしょうか。 よろしくお願いします。

  • 世界一、品質に厳しい日本市場で戦えない糞製品

    製品のクォリティーをアップさせるには、日本市場で磨け! 何て言葉を何かの雑誌で、どこかのブランドの社長の 言葉として、紹介されていたのを想い出す。 確かに、日本製品の高品質は、神経質な日本人に 揉まれ、より良い物、より優れた物を平均して作る、 造れる事に特化していると思う。 また、自動車でもそうだが、欧州の自動車メーカーと 違い、モデルチェンジのサイクルが早かった事も拍車を 掛けていたのか!? いつの間にやらメルセデスやワーゲンをトヨタ・ホンダが チギっている・・・ 携帯電話(スマホ)のバッテリーがメタボに成っただけでも バッテリーを無料交換してくれる日本メーカー 不具合が、全体の1%に満たなくとも、設計上のミス及び 製造上の不備が無いか調べ、リコール判断を真摯に発表 する日本のメーカー 中国では、リコール件数が余りのも多い日本製品は 信用性に欠けるとかで、国産品や韓国製品が急速に 売り上げを伸ばしているとか・・・ 三菱のトラックのように人を殺さなければいいのだが,,, 中国製品は、韓国製品の失敗を踏まえて、 品質を向上させて日本市場を席巻出来るのか? 世界を席巻出来るのか?

  • プログラミングを行う上での注意点は?

    こんにちは。私は昨年4月からSEとして採用された22歳(♀)です。 現在は下積みとして、ひたすらプログラミングをする毎日です。 プログラミング自体は嫌いではなく、 自分の作ったものが思い通りに動いたときは"、やっててよかった"、と達成感で満たされます。 ただ、まだまだ経験が浅いこともあり、 設計書をもらっても何から手をつけてよいかわからず、 (1)とりあえず書いてみる (2)バグだらけ (3)先輩の手を煩わせてしまう という悪循環に陥りかけています。 "もっと全体像を見ないとダメ""書けても動かないと意味がない"と 先輩からご指導いただいているのですが、 いったん作業に入ると、目先のことにとらわれうまくいきません。 そもそもアルゴリズムが苦手で、 効率のよいプログラムが組めない、という問題もあるのですが…。 そこで、皆さんがプログラミングを行う前、 あるいは最中に必ずされていること、心がけていることはなんでしょうか? 4月からは2年目に突入しますし、 7月から後輩が入ってくることも確定しています。 正直、先輩に頼れるのも今のうち、と焦っています。 現役プログラマーのかた、 あるは趣味でプログラミングをされているかた、どなたでもかまいません。 どうかご教授ください。

専門家に質問してみよう