プロジェクトマネジメント（品質編） ～ソフトウエア開発における品質確保のポイント～ ２００７年１２月１７日 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 1 インデックス ●はじめに Ｐ３ ●プロジェクトの失敗要因について Ｐ４ ●製品品質構成の二大要素 Ｐ５ □マネジメントの品質 Ｐ６～Ｐ１０ ●上流工程におけるマネジメントの問題 Ｐ６ ●プロジェクトの状況を把握できていますか Ｐ７ ●開発プロセスにおけるマネジメントの問題 Ｐ８ ●ミサイル理論 Ｐ９ ●プロマネのポイント Ｐ１０ □開発の品質 Ｐ１１～Ｐ３１ ●障害事例に学ぶ Ｐ１１ ●障害報告事例 Ｐ１２ ●再発防止あるいは不具合対策の横展開につい て Ｐ１３ ●障害に学ぶと言う事 Ｐ１４ ●『だから何？』について Ｐ１５ ●やってはいけない実例集 Ｐ１６～Ｐ１７ ●こうなっちゃいました症候群 Ｐ１８ ●本当に見ているのか、見えているのか Ｐ１９～Ｐ２１ ◇デザインレビュー会議の形骸化 Ｐ１９ ◇見える管理について Ｐ２０ ◇“基本の基”の実行について Ｐ２１ ●当たり前のことが何故”できないのか” Ｐ２２～Ｐ２３ ●問題解決の効果的ポイント Ｐ２４～Ｐ２６ ●品質はお金で買えるか Ｐ２７～Ｐ２８ ●品質に対する役割 Ｐ２９ ●受入検査について Ｐ２９ ●評価テストについて Ｐ２９ □リスクについて Ｐ３０～Ｐ３２ ●リスクについて Ｐ３０～Ｐ３１ ●リスクヘッジについて Ｐ３２ □商品とは何？ Ｐ３３ □責任について Ｐ３４ □毎日やろう Ｐ３５ Copyright (C) 2007 Hiroshi Sano All Rights Reserved 2 はじめに 品質問題でお悩みの皆様へ。あなただけが最悪なのではありません。 現時点で世界中で進行中のプロジェクトはおそらく何十万件もあり、恐らくその中 で失敗するだろうプロジェクトは統計的数値では６０～７０％にも上るのではと思 われます。日経ＢＰ社の調査（０３年１１月１７日）によるとプロジェクト成功率 は驚くことに２６．７％ときわめて低く、その原因の筆頭に品質問題が上げられて います。（成功率；品質：４６．４％、コスト：７６．２％、納期：５４．９％） しかしながらできることなら自分のプロジェクトだけでも品質問題をクリアして成 功プロジェクトの仲間入りをしたいものです。 これからご説明する内容は品質管理に関しての教科書的な内容ではなく生身の人間 として実際の品質問題解決における経験則から抽出した”ものの考え方”を中心に 皆様に解決のヒントを提供できれば幸いです。 Ｑの達成なくしてはＣ・Ｄの本 当の達成はあり得ない。 顧客の満足を得られる条件下で はじめてＱＣＤの成立の意味が ある。 ＱＣＤ； ＱｕａｌＩｔｙ：品質 Ｃｏｓｔ：利益・コスト Ｄｅｌｉｖｅｒｙ：時間・納期 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 3 プロジェクトの失敗要因について 失敗プロジェクトの原因の９０％以上がマネジメントの問題であると思われ ます。特にプロジェクトマネジャーの役割はきわめて重要で下記米国における プロジェクトの成功要因分析データも同様の結果を示しています。 ほとんどの要因はプロジェクトマネジャーの責任下にある項目ばかりで、 上位５項目を合計すると７０％にもなります。 ＊下記データは成功要因としてのランキングですが、もしこれらがなかりせば 失敗したであろうという意味で失敗要因のランキングとして読み替えていただ いても差しつかえないでしょう。 米国におけるプロジェクト成功要因調査データ； 1位 幹部のサポート：18% 2位 ユーザの貢献度：16% 3位 経験のあるPM(プロマネ）：14% 4位 明確な目的：12% 5位 単純なスコープ：10% 6位 標準ソフト・インフラ：8% 7位 要件のシンプルさ：6% 8位 プロジェクト・プロセスの有無：6% 9位 見積もりの信頼性：5% 10位 その他：5% （2003/3/25、Latest Standish Group CHAOS Report） Copyright (C) 2007 Hiroshi Sano All Rights Reserved 4 製品品質構成の二大要素；マネジメント品質と開発品質 製品品質構成の二大要素 ●マネジメント品質 ；主にプロジェクトマネジャー自身のマネジメントに関する品質。 ●開発品質 ；プロジェクトの構成メンバーによる開発実行行為に関する品質。 品質とは”人の質”に他なりません。以降の解説は”人の品質”に着目 して、プロジェクトマネジメント上、陥りがちな考え方の間違いを掘り 起こし真の原因に到達できるように視点の転換を促したものとしました 。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 5 マネジメントの品質 ■ 上流工程におけるマネジメントの問題 注文書（契約書）がないまま開発を実行している プロジェクトを見かける事がありませんか。 マネジャーに何故と聞いたら「納期に間に合わないからとり あえず開始しています。」と言うのがおおかたの答えです。 このような状況のプロジェクトは大体要件定義も完了しておらず、 開発体制も未整備なままでお金や時間が管理できない状況下にあります。 もう少したてば何とか改善されるとの甘い判断のもと大きく焦げ付いたプロジ ェクトを経験されたことはありませんか。 着手すべき条件が整っていないのに外部の圧力に負けて開発着手してしまうの ではマネジャーとしての仕事をしているとはとうてい言えません。 ビジネスライクに言うと仕事を受けていない段階において納期の心配をするこ とはないはずです。 それでも失注したらどうしようと言うのは、また別の次元の問題です。 マネジャーとしては早く条件・契約が成立するように阻害要因の解決に向けて 利害関係者間の戦い・調整にちゅうちょしてはいけません。 ある意味において戦えるマネジャーである必要があります。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 6 マネジメントの品質 ■ プロジェクトの状況を把握できていますか 分かっているようで実はわかっていない開発状況。 例えば下記質問に即答できるプロマネが何人いるでしょうか。 ・このプロジェクトの責任者は本当にあなたですか？ ・開発範囲・内容は明確ですか？ ・リスクは何ですか？ ・このプロジェクトのメンバー全員が現在、本当に何をやっているのか 知っていますか？ ・このプロジェクトの予算消化割合と開発進捗状況の整合性が取れている 証拠がありますか？ ・この物件のプログラムサイズは？ ・プロジェクト計画書はありますか？ Copyright (C) 2007 Hiroshi Sano All Rights Reserved 7 マネジメントの品質 ■ 開発プロセスにおけるマネジメントの問題 分かっているようで実はわかっていないプロセスマネジメント。 プロセスマネジメントを簡単に言うと、段取りの作成（プロセス管理表）とそれに 従った実行行為の事です。 料理に例えると具体的なイメージがわきます。 １．要件定義；何を作るかを決める（Ｗｈａｔ）：カレーライスを作る ２．設計；どういう風に作るかを決める（Ｈｏｗ）；インド風カレーを作る ３．プロジェクト計画書の作成 ・スケジュール決定；Ｘ月Ｘ日時の夕御飯に提供する。 ・プロセス管理表作成；作成の手順・段取りを決める ４．開発体制整備、開発環境準備；必要な材料、道具をそろえる ５．開発実行 プロセス管理表に従い開発工程を順次実行する；レシピ表に従い各 材料の適切な調理順に従って料理する。 ６．成果物の評価・検証実施；味見をする。 ７．客先へリリース・導入・稼働；食卓に提供する。 以上を見ていただければプロセス的には両者ともに全く同様な段取りです。 多くのプロジェクトを見てきましたが、最初のＷｈａｔとＨｏｗをおろそかにしたため 最初はカレーライスを作るつもりだったのに完成したのはハヤシライスだったり最悪完 成に至らなかったりしたものが散見されました。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 8 マネジメントの品質 ■ ミサイル理論；目標は動的に動いているという認識 ターゲットは動くものであるという認識。 ターゲットは時間の経過による環境・条件の変化に伴い動くものです。 アクションはターゲットの変化に沿うべく次から次ぎへと継続的に実行されなけれ ばターゲットには当りません。当たり前のことが当たり前に出来ない本当の背景に はターゲットは常に動いているという認識の欠如があります。 最終目標 強 化 初期計画 仕様検討 強 化 設計 初期目標 ＰＧ・ＤＢ 単体評価・ＳＣ接続 共同総合評価 ●到達目標は初期に想定した位置から時間の経過・環境・条件の変化に伴い必ず 変化する。 ●目標は動的にダイナミックに動くものであるという認識を持つこと。 ●動的に動く目標をヒットするためには変化を見逃さずタイミングの良い強化施策 を連続して実施すること。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 9 マネジメントの品質 ■ プロマネのポイント プロジェクトマネジメント自体は基本的に難しいものでは有りません。 ●はじめに計画書ありきで行こう。 ●Ｗｈａｔを決めよう。 ●Ｗｈａｔが決まらないうちにＨｏｗには進まないこと。 ●だれかの指示を待つのは止めよう。指示するのはプロマネ自身です。 ひとつ上のマネジメントの役割も目指そう。 ●ミサイル理論を実施しよう。 ●品質の根幹は上流工程にあり 前工程にはお金が落ちているが、後工程にはトラブルしか落ちていない。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 10 開発の品質 ■ 障害事例に学ぶ（一般的な障害報告書のダメさ加減） 何がダメなのか？ 具体的にどのようなひどいことが起きているのでしょうか。代表的な障害事例を 紹介します。 添付の障害報告書の例は一般的にほとんど何の疑問もなく公式の報告書としてよ く見受けられるものです。よく考えて見ましょう。 これら障害の原因とされるものは全て表面的なもので本当の真因によってもたら された結果に過ぎません。 真因はこのような結果をまねいた”人・組織”自身の考え方および行動そのもの にある様に思います。 悪いのはコードを作った、インストール作業を実施した、パッケージを作成した 、プロジェクト組織およびその構成員である”人の考え方・行動”ではないので しょうか。 ”人”といっても特定の個人だけのことを指しているわけではなく、その プロジェクトを構成している関係者全てを指しています。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 11 開発の品質 障害報告事例①（ロジックミス） ○○年○月○日 ○○○御中 △△株式会社 xxxxx障害の件 調査対応御報告 拝啓、貴社ますますご清栄のことと、お喜び申し上げます。 この度は、弊社システムにおいてご迷惑をお掛けしました旨、深くお詫び申上げます。 以下に、今回の障害に対する調査結果並びに対策についてご報告申上げます。 敬具 【 記 】 客先にては重大障害にて不愉快な 思いをされている中において ”貴社益々ご清栄のこととお慶び 申し上げます。”等の文言は不適 当です。 １．障害発生の経緯 １）○月○日 ＸＸサーバにて、ＸＸ時～ＸＸ時に於いてＸＸＸＸ件の取引が発生し、うちＸＸＸ件 がローカル取引となりました。 ２）ＸＸサーバへ接続している○○にて、ＸＸ時～ＸＸ時1の間、一部の取引（ＸＸ店舗、ＸＸ取引) にxxxx応答の「受信タイムアウト」が発生しました。 ２．障害の原因 ＸＸサーバと通信を行うプログラムの不具合である事が判明致しました。 同一のＸＸサーバに接続されている複数の○○から同時に問合せが発生した場合に、それら問合い 合わせに対する複数の応答を同一ＸＸサーバに返信する際の排他制御に不備があり、複数のプロセ スから同一の応答伝文を同一ＸＸサーバに返信しようとしエラーとなりました。 又、その影響を受け、受信カウンタと応答済みカウンタの整合性が合わなくなり、センターからの 応答伝文に相違有りと判断され、取消指令が出されて○○に応答が返らない状態となりました。 プログラムミスとの記述のみで、 何故間違ったのか、設計図はどう なってたのか、レビューはどうし たのか、評価テストはどうしたの か一切記述なし。真因はロジック ミスそのものでは無い。 さらに、この状態が続いた事で問合せ応答の通信経路を管理しているトランスファ管理ファイルが 全て使用中となり、ローカル金額未満のものが ローカル成立となってしまいました。 詳細は別紙にてご説明致します。 ３．対 策 ＸＸサーバと通信を行うプログラムの修正を行い、Ｘ月Ｘ日プログラム入替えを実施させていただ きました。 【プログラム修正内容】 １）ＸＸ管理テーブル（ＸＸサーバ単位で保持する内部メモリ）に対する排他制御を行い、同一Ｘ Ｘサーバに接続される複数の○○から同時問合せが発生しても、必ず１件ずつ確実に処理が行われ るように修正致しました。 ２）今後xxxx問合せに関する障害が発生した場合、原因調査を迅速に進める為に、ログの強化を行い ました。 真因の追求をしていないので結果 として本当の対策、今後の歯止め が書けていない。これでは事例の 横展開も不可能。同様障害が必ず 再発する。 現行のログにＸＸ、ＸＸ等を受け渡し情報として追記するように致しておりますが、性能等には影 響ありません。 － 以上 － Copyright (C) 2007 Hiroshi Sano All Rights Reserved 12 開発の品質 ■ 再発防止あるいは不具合対策の横展開について 何回も何回も同じような過ちを何故繰り返すのだろうか？ 多くの組織の共通の悩みです。 ある障害に対する是正措置計画書の例； 『障害原因：Ａ業務の計算ロジックの作成ミス。 障害対応策：不具合部のロジック修正 再発防止作：同様のロジック作成ミスをしないよう各部に横展開する。』 笑えない実例です。残念ながら実際多くの障害報告書はこのレベルどまりなのです。 有効な再発防止策は １．真因をつきとめること；問題の核心に迫るために、”何故”を最低でも ３回以上繰り返し真因を突き止める事。 真因分析の切り口はＱ、Ｃ、Ｄ、プロセス、 人間系（行動・心理）等多方面から行うこと。 ２．その結果を文書・現物等にて証拠として残すこと。 何故？なぜ？ナゼ？ ３．適切な仕組みを通して証拠に基づいてリアルタイムに 横展開を実施すること。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 13 開発の品質 ■ 障害に学ぶと言う事 ●障害が進歩の原点です。障害に学ぶ事より他に進歩への道はありません。 ●障害報告書からの出発 障害報告書に何を書くか、障害をどう役に立てるか。 一つの障害には隠れた不具合が山ほどあります。 正しく失敗の本質を総括したエビデンス（証拠）を残さなければ実質的な 横展開は不可能です。気持ちだけの横展開で終わってしまいます。 ●横展開の仕組み 障害が起きた時、リアルタイムに横展開できないと有効性はありません。 毎日起きているものは毎日横展開できるようにしましょう。 障害登録機能・検索機能に優れた重要障害ＤＢ等のシステム整備が 必要です。 障害に対する正しい対応およびエビデンスによる確実な横展開は不具合の解 消のみならず将来の技術力向上の基礎となる極めて重要な活動です。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 14 開発の品質 ■『だから何？』について（Ｓｏ Ｗｈａｔ？） 報告書、プレゼン資料、障害報告書等の資料において 何を言いたいのか分からないもの、意味不明なもの、 言い訳だけのものが多すぎないでしょうか？ 何故こんな資料しか書けないのでしょうか。 →たぶん仕事の意味が分かっていないのでしょう。 『何故なぜ問いかけ実行』のすすめ（トヨタ改善に学ぶ） 真因にたどりつくには５回の『何故』が必要。３回程度では良くやったね レベル。 ５回の疑問と改善案が出せるようになったら立派。ノルマ的なやり方では なく、それくらいの疑問と改善案が出るような環境が大切です。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 15 開発の品質 ■ やってはいけない実例集 ●夜中の無断レジストリ配信（＝背信行為そのもの）による 客先システムロック発生。 ●組織承認を経ない個人同士のマスターソフトの受け渡しの 結果、客先導入で障害発生。 ●赤字プロジェクト予算の他プロジェクトへの未承認先送り ・付け替えによる利益の先食い行為をしたマネジャー。 ●受注済み物件にてプロジェクトマネジャーのアサインも ないまま担当者レベルに丸投げ放置されていたプロジェクト。 ●テスト未了のまま何のアラームも報告もなく不具合多数のソフトを 客先検証に出したプロジェクト。 ●業界常識の５倍の見積りを出したプロマネ。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 16 開発の品質 ■ やってはいけない実例集 ●見積スキルのない開発者が業者に見積り自体を丸投げすること。 結果、発注金額は業者のいいなりになってしまいプロジェクトの損益を 悪化させてしまう。 ”業者にいくらかかるかと聞いてはいけません。” ●見積り回答書に「依頼元担当者が信頼置けないためリスク分３０％乗せた」 旨の文章を添付のまま発信してしまったプロマネ。 ●正規の注文書がない仕事にて成果物を出荷したプロマネ。 ●緊急性・重要性もない２０ページにもわたるチェーンメールを上位マネジメン トを含む４８名もの関係者に発信したプロマネ。 ●「人手不足のためクレーム回答できないと」発信を指示したマネジャー。 ●受注決済伺い書の「本見積りは確定した金額ではありません」の文言にて 見積り金額の決済伺い書を出したプロマネ。 『現実；本当のことは闇から闇へと消されていきます。意識的にも無意識的にも いわゆるマズイことは“ソレハナカッタ”ことにしておきたいとの個人的・ 集団的心理傾向がはたらきます。』 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 17 開発の品質 ■ こうなっちゃいました症候群 ●大きな問題が発生しているにもかかわらず、「こうなっちゃいました」の報告 だけを受けたことがありませんか。危機感が無さすぎることにあ然としたこと がありませんか。 真の原因は何々だから、本来どうあるべきだからこれから対応をどうするかが 問題なのです。 問題発生時の「何故？」の発信を心がけましょう。 エンジニアリングの基本の基です。 ●「ほうれんそう」の励行 言い古された言葉ですが、状況が悪ければ悪いほど早め早めの 報告・連絡・相談（ほうれんそう）が必要です。しかしながら 現実はすでに当事者においては完全にリカバリー不能の最悪の 状態に陥りながらもまだ何とかしようとしており、ついに外部 からの指摘により問題が発覚する場合が非常に多いのです。 何故早く相談しないのでしょうか？ 心理的障壁として“他人・上司に悪い状況を報告したくない”“いつも良い子 でいたい症候群”“悪くなったのは自分のせいではない”等々がありプロマネ 自身がこの穴に落ち込むことは絶対に避けなければいけません。また開発プロ ジェクト内の日々のフェイス・トゥ・フェイスの会話を絶やさない様にして風 通しを良くしましょう。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 18 開発の品質 ■ 本当に見ているのか、見えているのか ◇デザインレビュー会議の形骸化（レビューの健全化について） 公式の規定にて実行されなければならないデザインレビューが ほとんどレビューとしての機能を果たしていないことがまま有る のではないでしょうか。 開発プロセスの節目ふしめで設定されているレビュー開催時期を 守らない・守れない。 何故まもらないのだろうか。 承認を通す事が第一番の目標になっており、例えば製造に入る前の ポイントとしての設計レビュー実施時期になっても設計書不備のために レビュー会議が開催できず、意識的にレビュー時期を遅延させてしまう。 製造があらかた終了する時期にやっと揃えた設計資料にてレビューを実施した りする。 これでは何のためのレビュー会議なのでしょうか。 参加者の貴重な時間を浪費させただけなのではないでしょうか。 レビューは問題を顕在化させるための行為で、問題が発見される事はレビュー が成功したと考えるべきです。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 19 開発の品質 ■ 本当に見ているのか、見えているのか ◇見える管理について ◇リスク、Ｑ、Ｃ、Ｄ、プロセス、人が見える。 どのように見えるかが問題です。 ポイント；人手をかけないで見える様になること。 ●リスク；リスクの明示がなされているか、適切な処置 同じインプットをさせないこと。 が行われているか否かが見えること リアルタイム性があること。 ●Ｑ；各工程の品質が適切か否かが見えること。 ●Ｃ；コストの投入・消費状況が適時・適切額か否かが見えること。 ●Ｄ；進捗の状況が適切か否かが見えること。 ●プロセス；プロセスの実行が適切か否かが見えること。 ●人；役割別・工程別体制に従って適切な行動をおこなっているか 否かが見えること。 ポイント； ・人手をかけないで見える様になること。 ・管理表に何度も同じインプットをさせないこと。 ・リアルタイム性があること。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 20 開発の品質 ■ 本当に見ているのか、見えているのか ◇『基本の基』の実行について 開発における２つの超基本資料； １．役割別・工程別体制表 プロジェクトを構成する複数の組織・人の工程別・役割別体制を関係者全員 の合意・コミットメントの上明示すること。 ２．基本９種設計資料 作るものの徹底的な”見える化”には単なる機能仕様書だけでは不十分です。 文書記述式の機能仕様書では表せない業務ノウハウ・専門的常識を見える様 にするために下記９種類の設計書が必要です。 １）運用フロー；業務の流れ、日次、週次、月次のタイムチャート等 ２）データフロー；データの発生、経由、蓄積、削除を記載した資料 ３）システム論理構成図 ４）プロセスフロー；機能単位の処理（手続き）の流れ ５）ソフト構造図 ６）影響度表；変更部分がどの業務に影響を及ぼすかを記載した資料 ７）インターフェース仕様書；外部接続時の伝送及びデータ仕様 ８）機能仕様書；システム仕様書、ターミナル仕様書 ９）構成管理手順；モジュール単位にライフサイクルを管理する手順 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 21 開発の品質 ■ 当たり前のことが何故”できないのか”（複雑系・単純系についての認識） ほとんどの問題はその問題単独ならば簡単に解決できるでしょう。 しかしながら複数の問題が複数のプロジェクトに渡ったり、複数の組織・人間に 関係している場合は問題の組み合わせは比例級数的になり単純には解決できなく なります。 一般的な開発組織においては多くのプロジェクトが同時に進行しており、一つの プロジェクトの中においても複数の組織・人間が関係しているのがごく普通の状 況です。 しかしながら我々が普通なこと、当たり前なこととして認識していることがイク オール簡単な事ではないのです。 単独ならば簡単な単純系事象も複数・同時発生した場合は非常に困難な複雑系問 題となってしまうのです。 われわれが『当たり前のことが何故”できないのか”』の言葉を発するほとんど の場合が”当たり前のことだけれども単純には解決できない”と言う認識に立っ た 解決策の立案・実行が必要となります。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 22 開発の品質 ■ 当たり前のことが何故”できないのか”（複雑系・単純系についての認識） 複雑系に対する対応策 ●ミサイル理論の実施；「目標は動的に動いている」という認識を持とう。 ターゲットは動くものであるという認識が必要です。ターゲットは時間の経過による 環境・条件の変化に伴い動くものです。アクションはターゲットの変化に沿うべく次 から次ぎへと継続的に実行されなければターゲットには当たりません。 当たり前のことが当たり前に出来ない本当の背景にターゲットは常に動いているという 認識の欠如があります。 ●一石三鳥アクションの実施 前述の継続的アクションの実施において、全行程に同時並行的に種々の改善アクション を関連を持たせて実行すること。 一つひとつのアクションをシリーズに順次実行するのではありません。一つずつ実行し ている間に環境・条件が変化してしまい有効な結果は得られにくいものとなってしまい ます。一石三鳥は”「おいしい”アクション」ではありません 「そうしなければならない」アクションなのです。 原因・真因の究明方法について ●原因は一つではない 問題の原因は複数である場合が普通であると思ったほうが良い。一つの問題であっても 複数の工程それぞれに違った観点・局面からの切り込み・対策を講じなければ有効でな い場合がしばしばです。 ●原因のポイントを絞ること； 複雑な問題であれば有るほどその問題の最大原因にまずポイントを絞ることが重要です。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 23 開発の品質 ■ 問題解決の効果的ポイント（モグラタタキ状態からの脱出） 品質問題の渦に巻き込まれた時の効果的ポイントの抑え方の方法について ●いつまでも効果の出にくい施策にこだわって時間を浪費しないこと。 ●仮説と検証のによるアクションの方向性の転換・ 多重性アクションの実行等、時系列的に厚みのある 連続したアクションが有効です。 戦争と一緒です。全てを対策していても戦力ダウンです。 弱い箇所をピンポイントにて戦力を集中し対策することです。 何処にフォーカスさせるのか？ これが重要です。 「だから何」を考えれば「何処にフォーカスすべきか？」が見えてきます。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 24 開発の品質 ■ 問題解決の効果的ポイント（モグラタタキ状態からの脱出） 仮説と検証の実行例； 多くの不具合を修正してきたにもかかわらず、いつまでたっても品質が安定しない のは何故か？ ●仮説１：未修正の不具合がまだ残っている。 原因１：全ユーザにて不具合修正の最新Ｖｅｒ／Ｒｅｖにソフトを統一して いない。 原因２：未再現・不明による調査打ち切り項目は本当は不具合 （バグ、設定ミス、運用ミス等）であると考えられる。 不明打切り項目数が多すぎる。未再現クレームのソフト原因に 関するものとしてソフト基本構造の脆弱さが想定される。 対策１：修正版ソフトの市場投入の継続・定期的実施 対策２：不具合多発業務を中心に基本設計書の整備およびソース解析を行い 下記弱点箇所の強化を行う （排他処理不正、非同期制御不正、タイミングずれ、リトライ処理抜け 、Min／Max制御不正＜ﾒﾓﾘﾘｿｰｽ、ﾃﾞｰﾀ長、伝文長、ｶｳﾝﾀ、ﾎﾟｲﾝﾀ＞、 タイマー値不正、ﾚｼﾞｽﾄﾘ不正、設定間矛盾） Copyright (C) 2007 Hiroshi Sano All Rights Reserved 25 開発の品質 ■ 問題解決の効果的ポイント（モグラタタキ状態からの脱出） 仮説と検証の実行例； ●仮説２：不具合修正時および新規開発にて不具合を作りこんでいる 原因：基本設計書の不備・内容レベルの貧弱さの中でのソフト修正・追加を 行っており、地図のない旅をしている状態と同じである。 対策：不具合多発業務を中心に基本設計書の整備・レベルアップを行い 不具合修正時・新規開発時における修正ミス・設計ミス・製造ミスを 撲滅する。 下記基本設計書の整備・内容レベルの向上を行う （運用フロー、データフロー、システム論理構成図、プロセスフロー、 ソフト構造図、影響度表、ｲﾝﾀｰﾌｪｰｽ仕様書、機能仕様書、 構成管理手順書） Copyright (C) 2007 Hiroshi Sano All Rights Reserved 26 開発の品質 ■ 品質はお金で買えるか ●金の切れ目が縁の切れ目； 古くからの諺にあるように、プロジェクトを 生かすも殺すも適切な時期に適切なだけの資金投入 があるか否かによります。 プロジェクト発足に当たって言われる常套句に ”早く体制を確立しよう”と言うことばがあります。 資金投入は体制が整備された後に考えれば良いと 言うような風潮が蔓延していないでしょうか。 順番が逆なのです。まずお金ありきでなければいけません。 お金は経済活動における血液であると例えられるように、いくら頭脳ばかり 揃えても血液が流れなければプロジェクトは動きません。 お金のないところに人材は集まりません。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 27 開発の品質 ■ 品質はお金で買えるか □品質とコストのバランスについて ●高品質・高コストは当たり前。 ●低品質・高コストは論外。 ●低品質・低コストは使えない。 ●高品質・低コストは理想的だが実現が困難。 ●目指すべきは高品質・リーズナブルコスト （＝お客様に納得いただけるコスト）です。 高いと言うクレームに対しては相手と開発内容およびそのリスクの大きさにつ いて戦わなければならないでしょう。プロマネの重要な仕事の一つです。 ”悪い／遅い／高い”と良く耳にしますが、”悪い”をまず何とかしなければ いけません。 ”遅い”はスケジュール調整の段取りを高い視点で対応すれば何とかなります 。 トラブルが出なければ”高い”はおとなしくなります。 品質（悪い）はマネージメントの最重要課題です。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 28 開発の品質 ■品質に対する役割； 品質の作り込みは開発チームの役割であり、品質の管理・保証行政は品質保 証チームの役割です。 ■受入検査について； 発注者側にてちゃんとした受入検収を行わなければ、発注者・受注者双方に とって不利益を招く事を肝に銘じておくべきです。 ”受入れ”ではなく”受取り”になっている場合が少なくありません。 ■評価テストについて； 不具合発見が少ないテストは失敗だ！ 発見不具合数が異常に少ない評価テストはあきらかに評価の失敗と考えるべ きです。評価チェックリストが適切ではなかったか、あるいは評価者がチェ ックリスト通りに評価しなかったかの再検証が必要です。 評価テストはある種の破壊的行為と考えたほうが分かりやすいのではないで しょうか。 もちろんシステムの正常運用にて問題がないか否かのテストが基本となりま すが、例外条件テスト、異常操作テスト、最大・最小テスト等システムの弱 点をつくイジワルテストの実施がポイントとなります。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 29 リスクについて できない事をやろうとしていませんか。 できないことをやろうとしないで下さい。やらせないで下さい。 一人で判断が困難な場合はチーム・組織で判断して下さい。 ●リスクは基本的に”人”により発生させられるものである と言う認識が必要です。 例えば”低開発費”自体がリスクではなく、 ”低開発費を招きそうな人”がリスクなのです。 ●リスクと課題の違いが分かりますか？ 未だ発生するか／しないか分からないが発生しそうな問題について 「リスク」と言い、実際に顕在化した問題を「課題」と言います。 ゆえにリスク管理表と課題管理表は別に作成管理しなければいけません。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 30 リスクについて ●取ってはいけないリスクと取るべきリスクについて 判断が難しいのですが自組織の実力にて何とかこなせる レベルを越えるものは”チャレンジ”の域を超えて”無謀” な領域に入ります。 反対にチャレンジ可能なリスクは積極的に取らなければ ビジネスの拡大はありません。 ●リスクの可視化 いずれにしろ何がリスクなのかを明示したリスク管理表の作成は必須です。 リスク管理表内容例； 物件名、ユーザ名、依頼元名、現進捗工程、開発番号、開発費、 開発スケジュール概要、責任プロマネ名、担当メンバー氏名、 リスク記述欄（品質、開発費、納期、対外部署間問題、工数問題、人材問題 、その他問題） Copyright (C) 2007 Hiroshi Sano All Rights Reserved 31 リスクヘッジについて ●上流工程におけるリスク回避がもっとも効果的。 最上流工程におけるリスク回避に必要な３つの重要成果物 １．要求仕様書（ＲＦＰ）；何（Ｗｈａｔ）を作るのかの定義書。 ２．基本設計書 ；どう（Ｈｏｗ）作るのかの定義書。 ３．見積り書（開発費、開発期間、見積条件・範囲） ；いくらでいつまでに作るのかの契約書 この３つの成果物の精度でプロジェクトの成否の大半が決定します。 ●リスクリスクヘッジコスト（リスク予備費）・メンテ費 プロジェクトが失敗した場合のリスクヘッジ原資については巨大プロジェ クトの場合に関しては保険会社との契約を結ぶ傾向も一部には見受けられ ます。通常は用意されない場合が多く経営を脅かす危険性があります。 システムソフトウエアの健全性・性能維持費については独立系 ソフトハウスにおいては平均的に販売パッケージ額の５～７％を ソフト保守・メンテ費としてユーザと契約している場合が多い様です。 一般的なカスタムソフト開発におけるソフト保守・メンテ費については 特別な場合を除いてはお客様から頂けていないのが現状であると想像され ます。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 32 商品とは何？ ●障害率が高すぎる製品は商品ではない。 ●お客様の声；『うちはハードを買っているのではない。データを買っている のだ。』 ●システム全体が一つの商品である。サーバだけ、ＰＯＳだけ、端末だけでは 商品とは言えません。お客様は個々の機器を買っているのではなくシステムお よび、それで処理されるデータを買っているのです。 ●機器単体における現状の設計をとってみてもまだまだ商品としての考え方が 不十分です。オペレータの操作系についてはＧＵＩの採用にて大幅に改善され ましたが、サービスマン用の機能である設置・設定方法が難しくてミスを誘発 しやすいものがまだまだ多いのではないでしょうか。 ●単に会社組織の論理のみに頭が支配されている人々にとっては自分の狭い 領域の担当部分のみが商品であると思いこんでしまっている場合がまま見 受けられます。 『それは私の担当ではありません』からの脱却が必要です。 （参考文献『それは私の担当ではありません、ダイヤモンド社刊、ピーター・ グレン著、川勝・門田共訳』）。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 33 責任について ●『誰が』の記述がない、あっても今度は期限の明示されていない 報告書・会議がごく当たり前の様に行われていることがありませんか。 ただ口頭で話すばかりでいっさい議事録が取られない会議が行われては いませんか。 『誰が』の記述がないと言うことは責任者が不明と言うことです。 期限の明示されないアクションは実行されないのと同義語かも知れません。 会議の主催者が白板に議事録もとらず、参加者がただ話をするだけの会議が 行われていないでしょうか。 ●だれもが当事者・責任者になりたがらない組織・チームになってはいない でしょうか。 責任と言うことについて重苦しく考える必要はないと思います。 単純に考えると”この仕事は誰の担当ですか”と言うことだと思います。 下記に朝日新聞に記載された記事をご参照下さい。 ＜責任について＞ 自由と義務を均衡させる手段の第１歩として人間の責任に関しもう一度自分の頭 で何をすべきか個々人で考えなければならない。日本人全体を覆う無責任主義下 における思考停止傾向から脱却し「考える日本人」にならなければならない。 （朝日新聞1998/1/18） Copyright (C) 2007 Hiroshi Sano All Rights Reserved 34 毎日やろう（プロジェクトマネジメント） 今すぐできることです！！ 毎日やろう 課題バラシ／対応策 担当者の巡回フォロー 対応策の指示 毎日聞こう 担当者のグチ・不平・ 不満を聞こう 関連部署の状況を 聞こう お客様の話を良く 聞こう 毎日見よう リスク・課題管理表 進捗管理表 担当者の健康状態 （自分のも） 毎日まとめよう アクション 課題 マネジャーは心理的にも地理的にもいつも 担当者の側に居よう 開発ルームに 引っ越そう いつでも相談に乗ろう ＶＯＣ／ＣＳ お客様を早い時点で仲間として巻き込もう 早くしよう 自部署の仕事ではないと判断したものは即刻担当部署に渡してしまおう。 ＰＪリーダはサブリーダの、サブリーダは担当者／外注の 仕事の範囲を明確にしよう 仕様書はまず手書きでも白版のコピーでも良いからとにかく見える様にしよう 見える様にしよう 実行スケジュール表を古いままにせず実態に合わせた線引きをして見よう ；どれくらい遅延しているか見えてくる 管理表は毎日更新しよう 日曜日は休もう。交代ででも。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 35 ご静聴ありがとうございました。 Copyright (C) 2007 Hiroshi Sano All Rights Reserved 36
© Copyright 2024 ExpyDoc
