実行すれば宝の山 実行しなければ負債の山

カイゼン活動カタログ ←印刷はこちらから

目次

はじめに p1

改善 癸院ヽ発プロセスの改善 p2

改善 癸押ヽ発準備レビュー・チェックシートの運用 p4

改善 癸魁〕弖鐵蟲曾顱瞥弋畛斗予顱砲寮催抔上 p5

改善 癸粥〕弋畛斗佑諒儿拘浜 p7

改善 癸機〇斗擁儿恒洞租拮修瞭各 p8

改善 癸供〕弋畛斗優譽咼紂次Ε船Д奪シートの運用 p9

改善 癸掘仝積りリスクの回避 p10

改善 癸検仝積りヒット率の向上 p11

改善 癸后仝積り作業生産性の向上 p12

改善 癸隠亜.廛蹈献Дト・リスクの低減 p13

改善 癸隠院.廛蹈献Дト目標値の設定 p15

改善 癸隠押.灰潺絅縫院璽轡腑鵑粒萓化 p16

改善 癸隠魁ー衄瓦問題の撲滅 p17

改善 癸隠粥〔蟻未稜喀 p19

改善 癸隠機ゝ’愁皀献紂璽訖閉輯浜表の導入 p20

改善 癸隠供―だ技跳鏨浜表の導入 p21

改善 癸隠掘.愁侫隼饂困領用 p22

改善 癸隠検―藉設計レビュー・チェックシートの運用 p23

改善 癸隠后‐楮拈澤廛譽咼紂次Ε船Д奪シートの運用 p24

改善 癸横亜.魁璽疋譽咼紂次Ε船Д奪シートの運用 p25

改善 癸横院.謄好噺率の向上 p27

改善 癸横押|餌痢Ψ觜腑謄好肇譽咼紂次Ε船Д奪シートの運用 p28

改善 癸横魁〜躪腑謄好判猗レビュー・チェックシートの運用 p29

改善 癸横粥〜躪腑謄好肇譽咼紂次Ε船Д奪シートの運用 p30

改善 癸横機々柔管理作業チェックシートの運用 p31

改善 癸横供.螢蝓璽好譽咼紂次Ε船Д奪シートの運用 p32

改善 癸横掘.薀奪廛▲奪廚亮孫圈。陦械

改革コンセプト

改革コンセプト#1 時間の確保 p35

改革コンセプト#2 自律型開発 p37

改革コンセプト#3 変化即応型開発 p38

改革コンセプト#4 フォーカス活動 p39


はじめに

 日々の仕事に忙殺されているソフトウェア開発に携わるみなさんにおいては、いま以上の仕事はとてもじゃないがもう背負いきれないというのが実感でしょう。しかし一方では、問題山積の現状を少しでも改善し、世間の人並みに休日くらいは休みたいとお考えのことでしょう。

 もしそのように少しでも改善活動に取り組みたいとお考えの方々のために本資料をまとめました。

 カイゼンという言葉は今や世界共通語として知られていますが、本家本元の日本において果たしてどれ位の人々が改善活動に取り組んでいるのかは、昨今のジリ貧状態の日本においては余り期待できません。日本における構造改革が進んでいないと言われていますが、それはカイゼン活動が進んでいないことを意味しています。

 本資料は「カイゼン活動カタログ」という名称をつけた通り、ソフトウェア開発の上流工程から下流工程に至るまでの全工程において筆者が経験したカイゼン活動を元に、カイゼンを志している方々に具体的にどのようなカイゼンのテーマがあり、それらはどの様な問題をどの様にしてカイゼンし所定の成果を獲得したのかをカタログ的に示したものです。

 それぞれのカタログの記述構成は、テーマ名、改善すべき問題点、改善策および改善の期待成果となっています。改善の期待成果の欄には、その改善を実現するにあたって重要な役割を果たしたドキュメントのサンプルをエビデンスとして記載しました。

 なおカタログの次に記載した「改革コンセプト」はカイゼン活動を進めるにあたっての基本的な方針を著したものです。

 それぞれのカイゼン項目は一過性の改善活動では単発的な成果しか得られず、永続的な組織力の維持向上のためには継続的な活動が必要であることに強く留意していただきたいと思います。一旦これらのカイゼン活動を中止してしまった開発組織は品質の悪化、生産性の低下、赤字および人心の荒廃を招き、必ず衰退していくことでしょう。

 記載の順は基本的に上流工程から下流工程に至る流れとなっていますが、読者のみなさんの興味のあるところから読んでいただいても構いません。いずれにしろ、このカタログの中から何らかのヒントを得てみなさんのカイゼン活動が活性化するならば喜ばしいことです。


改善 癸院.董璽沺Аヽ発プロセスの改善

改善すべき問題点

 ・各工程の実行手順忘れ

 ・各工程の手抜きの防止

 ・人依存・経験依存のバラバラな開発手順

 ・視覚化されていない開発手順

改善策

 ・標準プロセス管理表の作成(開発業務手順のビジュアル化)

 ・標準プロセス管理表に基づく開発手順の実行(開発業務品質の確保)

 ・標準プロセス管理表実行のレビュー

 ・プロセス管理表にISO・CMMI項目を絡めたチェック機能の強化

改善の期待成果 ◎標準化されたプロセス管理表による全工程の手順および成果物の管理

【プロセス管理表】

Ref.『プロジェクト レスキューマニュアル 第7章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf


改善 癸押.董璽沺Аヽ発準備レビュー・チェックシートの運用

改善すべき問題点

 開発開始を阻害する問題として次のようなものがある。

 ・開発内容の概要および背景が把握されていないこと。

 ・公式の開発指示書が発行されていないこと。

 ・妥当な開発体制が構築されていないこと。

 ・リスク管理表、課題管理表、プロジェクト計画書、管理表、スケジュール表などのドキュメントの準備ができていないこと。

改善策

 開発開始に必要不可欠な人・モノ・資金・情報等についての準備が完了しているか否かをフォローするための「開発準備レビュー・チェックシート」を作成し開発準備工程においてレビューを行う。

改善の期待効果

◎開発開始の前に準備しておかなければならないものについての欠落を防止することにより、後に続く開発工程のリスクを予防しQCDおよび生産性の向上を図る。「開発準備レビュー・チェックシート」はそれぞれの開発組織の文化や実力に応じて最適化を図る必要がある。

Ref.『要件定義リスク クイックリファレンス 第2章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/requirement_risk.pdf

 


改善 癸魁.董璽沺А〕弖鐵蟲曾顱瞥弋畛斗予顱砲寮催抔上

改善すべき問題点

◎仕様変更の基本的要件の記述モレによる開発生産性および品質の低下

 ・要求仕様の目的の記述モレ

 ・要求仕様の背景の記述モレ

 ・要求仕様の概要の記述モレ

 ・要求仕様の運用説明モレ

 ・要求仕様の正確な記述

改善策

 ・開発要件を過不足なく網羅した要求仕様書ひな形の作成

 ・要求仕様書ひな形の運用

 ・要求仕様書の採点評価

改善の期待成果

◎要件定義書の精度向上による見積り精度向上、設計書等の精度向上

【要件定義書記述項目表】

【要件定義書採点表】

 Ref.『要件定義リスク クイックリファレンス 第3章・第4章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/requirement_risk.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第3章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロジェクト レスキューマニュアル 第6章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf


改善 癸粥.董璽沺А〕弋畛斗佑諒儿拘浜

改善すべき問題点

 ・要件定義ベースラインの確立および変更管理がなされないまま開発に着手し、度重なる仕様変更および想定仕様に基づく開発による手戻り、品質劣化、コスト高、生産性低下、必要時間の喪失を招いている。

 ・発注社および受注社ともに要件定義のベースラインの早期凍結意識が不足している。

 ・発注社および受注社ともに要求仕様は全て書面化し、契約ベースにて管理する意識が不足している。

改善策

◎仕様変更管理表の作成および運用による要求仕様ベースラインの確立

 ・ 要件定義工程のプロセス化

 ・ 仕様凍結期日の明確化

 ・ 放縦・無定見な仕様変更の防止

 ・ 仕様変更の質、量および費用の管理

改善の期待成果

◎要求仕様の早期凍結、開発QCDの向上

 

Ref.『要件定義リスク クイックリファレンス 第3章・第4章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/requirement_risk.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第3章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロジェクト レスキューマニュアル 第6章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改善 癸機.董璽沺А〇斗擁儿恒洞租拮修瞭各

改善すべき問題点

 仕様変更が他のソフトウェア領域のどこにどの程度の影響を及ぼすのかが把握できないことによりQCD全体および生産性を悪化させる以下の問題が発生している。

 ・正確な開発費の見積りができない。

 ・正確な開発期間の見積りができない。

 ・正確な設計ができない。

 ・正確なコード製造ができない。

 ・効果的・効率的なテストができない。

改善策

 「仕様変更影響度表」の作成・運用により上記の問題の低減化を図る。

◎「仕様変更影響度表」の作成にあたっては、前もって構造化された業務機能の一覧と処理一覧(ソフトウェア部材とのリンクを含む)が必要になり、これらの二つを組み合わせたマトリクス図が仕様変更影響度表となる。

◎「仕様変更影響度表」への書き込みは開発の全工程で実行される必要があり、要求仕様調査時、設計時、製造時、デバッグ時、単体テスト時、結合テスト時、総合テスト時において知り得た影響度情報を記入していく必要がある。これらの作業はシステム化が望まれる。またこれらの作業はソフトウェアのバージョン開発が続く限り継続される必要があり、一旦中断してしまうと影響度表の信頼性は著しく低下してしまう。

改善の期待効果

◎「仕様変更影響度表」の運用は、妥当な開発費・開発期間の見積り、正確な設計・製造、効率的・効率的なテストの実現に大きく寄与し、プロジェクト全体のQCDおよび生産性の向上に貢献する。


改善 癸供.董璽沺А〕弋畛斗優譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 ・見積り範囲からの逸脱仕様    ・未確定仕様

 ・不明・疑問仕様            ・不明確な仕様の優先順位

 ・不明確な制限事項・条件        ・不明確な仕様の背景・意味

 ・不明確な異常処理・エラー処理    ・不明確な性能要件

 ・不明確な非機能要件

等。

改善策

 要件定義工程において確定すべき要求仕様からの抜け、誤り、疑問、不明点、制限、条件などの未確定要素を排除するために「要求仕様チェックシート」を作成し要件定義工程においてレビューを行う。

改善の期待効果

◎要求仕様の品質を向上させ、その後に続く設計・製造・評価工程のQCDおよび生産性を向上させる。

Ref.『要件定義リスク クイックリファレンス 第3章・第4章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/requirement_risk.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第3章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

 


改善 癸 テーマ: 見積りリスクの回避

 

改善すべき問題点

 ・非現実的な超短納期・低開発費の要求。

 ・開発着手後の納期短縮要求や開発費減額の要求。

 ・正しくない要求内容またはお粗末な要求仕様による見積り回答。

 ・顧客案件が数週間前に発生しているにも関わらず見積依頼が今日の明日。

 ・システム全体を見ない見積依頼、回答。

 ・見積リスクを開発費の大小でしか判断できていない。

 ・開発途中での仕様変更管理ができていない。

改善策 【見積りリスクの回避】

◎見積依頼・回答基準の策定および運用

◎見積り方法・見積回答シートの改善

 ・開発範囲の明示 ;仕様の骨子決定ずみのシステム範囲・機能範囲についてのみ見積る。

 ・未決定仕様に関しては見積り回答に含まれないことを明示すること。

 ・開発着手時期および開発期間を明示すること。

 ・表現、必要項目の再検討を行うこと。

 ・自動計算、ツール化できる部分の検討(FP計算等)による見積者毎のバラツキの低減

および記載漏れの防止

 ・見積時点の要求仕様精度レベル(採点)による開発リスク係数の考慮を行うこと。

 ・見積り有効期限を明示すること。

改善の成果 ◎適正な開発期間・開発予算の確保

 【見積りプロセスガイドライン】

Ref.『ソフトウェア開発のメソッド クイックリファレンス 第3章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロプロマネ銀の弾丸・チェックリスト 3.』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf


改善 癸検.董璽沺А仝積りヒット率の向上

改善すべき問題点

 受注につながらない見積りによって失われた開発者の時間および工数金額は、少なくない時間および費用のネガティブインパクトを開発組織に与えている。

改善策

 見積り依頼を受けた開発部門別および見積り依頼を出した部門別の2種類の「見積り時間&ヒット率集計一覧表」を作成し、無駄になった時間および金額を把握すると同時に受注ヒット率が低い見積り依頼部門および担当者を特定し、該当する部署および担当者に対して無駄な見積りは結局コスト増として相手に跳ね返る旨の警告を発し無駄な見積り依頼要求を抑制する。

改善の期待効果

◎平均ヒット率よりかなり低い見積り依頼を頻発する部署ないしは担当者に対して確率の低い無駄な見積り要求を抑制させることにより、開発者の貴重な時間の浪費を防ぐと同時に開発部門のコスト負担を軽減する。

 


改善 癸后.董璽沺А仝積り作業の生産性向上

改善すべき問題点

 不適切な見積り依頼方法や内容のために調査・検討に余分な時間がかかり見積り作業の生産性を低下させると同時に見積り精度の低下を招き、ひいてはプロジェクトのQCDの低下を招いている。不適切な依頼方法や内容の例としては次のようなものがある。

 ・要件定義書なしの見積り依頼(口頭・電話のみによる依頼など)。

 ・要件定義書内容の不備(必要事項の記述なし、記述ミスなど)。

 ・短時間の見積り回答要求。

 ・バラバラに出される仕様内容、二転三転する仕様内容など。

 ・最初から仕切り値で開発費や納期を要求してくる。

改善策

 「見積り依頼内容調査票」を作成し、不適切な見積り依頼を頻発する要求部署および要求者を特定し、改善要求を行う。見積り不可能な事例に対しては、その理由を明示し、適切な見積り依頼書の再発行を促す。

改善の期待効果

◎見積り依頼方法および内容の適正化により不要な調査・検討・コミュニケーション時間を削減し、見積り作業の生産性を上げると同時に見積り精度の向上を図り、プロジェクトのQCDを向上させる。


改善 癸隠亜.董璽沺А.廛蹈献Дト・リスクの低減

改善すべき問題点

 ・見積り精度が悪く赤字を招いている。

 ・要求仕様の精度が悪く開発の生産性低下や品質悪化を招いている。

 ・類似不具合がなくならない

 ・不具合による仕損費が減らない

改善策

 ・過去に経験した主要なリスク問題の収集とカテゴリ―分類。

 ・類似不具合情報の収集とカテゴリ―分類。

 ・開発チームにおけるリスク管理表の作成および運用。

 ・マネジメントによるリスク監査の組織的・継続的な実行。

改善の期待効果

◎リスク排除による目標QCDの達成

Ref.『要件定義リスク クイックリファレンス』

http://www.geocities.jp/pmfactory_ambitious/pmnote/requirement_risk.pdf

『プロマネ 銀の弾丸・チェックリスト』

http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

 

『プロジェクト レスキューマニュアル』

http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改善 癸隠院.董璽沺А.廛蹈献Дト目標値の設定

改善すべき問題点

 目先の仕事に追われプロジェクトの目標も立てずに開発を行っているチームが多く、いつまでたっても優れたQCDの成果を残せず、人材の成長も達成できない。

 目標値のない開発とは、地図のない旅あるいはゴールの見えない競技のようなものであり、出たとこ勝負の人的資源消耗型のプロジェクトに等しい。

改善策

 開発着手前にプロジェクトのQCDに関する達成目標値を設定することにより、その目標を達成するためのあらゆる活動によってプロジェクトを遂行すること。QCDの目標値を設定するためには過去のプロジェクトのQCDデータが収集されている必要がある。現時点での開発チームのQCDに関する実力値が分からなければ目標値を設定することは不可能である。

【目標値設定の条件と設定方法】

 ・現時点における自チームのQCD実力値が把握されていること。

 ・現実的で達成可能であること。     ・測定可能な数値で表されること。

 ・現状の問題点を洗い出し、その数値化を行うこと。

 ・問題点の真因を明確にし、具体的な改善策を立案すること。

 ・改善策の期待効果に見合った目標値を設定すること。

 ・目標値は、その変更も含めて、常時、チーム内の全員で共有されていること。

【目標値の例】

◎品質指標

 ・テスト工程発生不具合のレベル・件数・発生率(/kstep)

 ・市場発生不具合のレベル・件数・発生率(/kstep)

 ・仕様ミス率(発生件数/kstep)     ・設計ミス率(発生件数/kstep)

 ・製造ミス率(発生件数/kstep)     ・評価ミス率(評価ミス発生件数/kstep)

 ・プロセス品質;レビュー漏れ率(レビュー漏れ不具合件数/kstep)

◎コスト指標

 ・目標利益率または利益額

◎生産性指標

 ・見積りヒット率/要求仕様書精度達成率/ソフトウェア流用率(モジュール化率、リピート率)/プログラム製造ステップ単価

改善の期待効果

◎目標値の設定はデータ・ドリブンなプロジェクトの第一歩と言え、ソフトウェア開発を科学的・工学的に遂行する唯一の手段である。数値に基づく開発は、プロジェクトの代表的な問題であるあいまいさや情緒的な判断を一掃する。

【目標値設定による効果】

 ・現状の開発力が明確になる。

 ・到達すべきゴールが見え、モチベーションの維持につながる。

 ・改善すべき問題を明確にする。

 ・あいまいさや情緒性を排し、合理的ないしは妥当性のあるチームを育成する。


改善 癸隠押.董璽沺А.灰潺絅縫院璽轡腑鵑粒萓化

改善すべき問題点

 開発チームにおけるQCDおよび生産性に致命的なインパクトを与えているコミュニケーション問題には以下のようなものがあります。

 ・人の話を最後まで聞くことができない。

 ・部下の意見を十分に聞けない。

 ・質問がしづらくて失敗を招いている。

 ・自分の主張の根拠について適切に説明できない。

 ・臆病な性格がコミュニケーションを阻害している。

 ・忙しい時、一方的な自分の意見の押し付けになってしまう。

 ・伝わったと思った内容が伝わっていなかった。

 ・要求内容を勝手に深読みして仕様を膨らませてしまった

 ・まともな業務文書が書けない。

 ・何が書いてあるのか分からない仕様書・設計書。

 ・表面的な言葉の理解では本質が見抜けない。

改善策

◎「日次情報共有会議」の実行

 毎日の短時間ミーティングをチーム内で実行すること。メンバー全員から「〆鯑何を実行したか ¬斉何を実行する予定か 今抱えている問題は何か」の3点について報告を受け、リーダーはそれぞれに的確なアドバイスを行う。

 数十人以上での課や部における一方的な通達に偏りがちな朝礼・昼礼は何の効果もないと思った方がいい。最大10人以下のメンバーにおいて「日次情報共有会議」を実行することによって、全員の進捗・問題点および全体的な情報共有は間違いなく実現され、多くのメンバーが持っているコミュニケーションの苦手意識も改善されていく。

改善の期待効果

◎下記課題の改善によりコミュニケーション不良に起因する間違いや失敗は激減する。

 ・チーム内の情報共有。

 ・毎日の行動結果・行動予定の確認。

 ・毎日の課題/リスクの掘り起こしと対応状況の確認。

 ・開発目的・範囲・情報の徹底。 

 ・開発仕様の情報共有。

 ・開発仕様の優先度順位情報の共有。

Ref.『コミュニケーション自習講座』

http://www.geocities.jp/pmfactory_ambitious/pmnote/communication1.pdf

 


改善 癸隠魁.董璽沺Аー衄瓦問題の撲滅

改善すべき問題点

 時間不足やあせりによって必要な工程の中断や工程自体のスキップが行われた場合、間違いなく品質問題に直結してしまいます。本来ならばプロジェクトのQCDはみな必須条件のはずですが、時間不足に陥ったプロジェクトでは形だけでも納期優先となり必要な作業の希薄化ないしはスキップという愚行に手を染める結果を招きます。 その結果、市場で大トラブルを発生させることになります。

改善策

◎基本的な対策は見積りおよび要件定義工程において妥当な開発期間を獲得することや改善活動によって生産性を向上することにありますが、ここでは具体的な手抜き行為を列挙した「手抜き防止のチェックリスト」の導入による対策を示します。

【設計・製造工程における手抜き防止のチェックリスト】 

□ 仕様の事前調査・検討をスキップしていないか。

□ ドキュメントに基づく設計・製造・評価が行われているか。

□ 基本設計工程をスキップしていないか(基本設計書未作成)。

□ 詳細設計工程をスキップしていないか(詳細設計書未作成)。

□ 仕様実現に必要なメモリー容量、ハードウェア諸元を確認したか。

□ パフォーマンス性能、レスポンス性能の考慮が抜けていないか。

□ 異常系処理の考慮が抜けていないか。

□ 各工程における自己チェックをスキップしていないか。

□ 各工程の内部/外部レビューをスキップしていないか。

□ ソースコードやドキュメントの無節操なコピー&ペーストが行われていないか。

□ プロジェクト完了時の振り返りやラップアップをスキップしていないか。

【テスト工程における手抜き防止のチェックリスト】 

□ インターフェースにおける最終的な出力確認をスキップしていないか。

□ テスト項目未消化のまま次工程に進んでいないか。

□ 単体テストをスキップしていないか。

□ 結合テストをスキップしていないか。

□ 総合テスト項目未消化のまま客先にリリースしていないか。

□ 発見済み未修正バグを含んだままリリースしていないか。

【全般的な手抜き防止のチェックリスト】 

□ 仕事の意味を考えて作業を行っているか。

□ 時間がないことを手抜きの言い訳にしていないか。

□ 予算不足を理由に手抜き仕事が行われてはいないか。

□ 合理的なプロセス管理表に基づいて開発を実行しているか。

□ 重要な手順抜けを防ぐためのチェックリストを運用しているか。

□ 手順慣れで必要なチェックを飛ばしてはいないか。

□ コーディングやドキュメント作成において安易なコピー&ペーストを行ってはいないか。

□ ソフトウェアやドキュメント等の成果物の出荷前の現物確認や動作確認を行っているか。

□ 深刻な疲労に陥ってはいないか。

□ 手抜きで発生した実例を本人に示しているか。

□ 日次情報共有会議等で問題の共有を毎日実行しているか。

□ 前記問題点の改善活動をリーダー主導で行っているか。

改善の期待効果

◎「手抜き防止のチェックリスト」は「レビュー・チェックシート」と合わせて使用することで意図的な手抜きと意図しないミスの両方の防止に効果を発揮し、QCDの改善に寄与する。

Ref.『プロプロマネ銀の弾丸・チェックリスト 15.』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

 


改善 癸隠粥.董璽沺А〔蟻未稜喀

改善すべき問題点

◎開発の全ての工程の中で見られる代表的な無駄としては次のようなものが挙げられる。

 ・繰り返される同じ失敗        ・受注につながらない見積り

 ・意味不明な報告書        ・結論の出ない会議

 ・長時間の井戸端会議        ・タイミングが遅いレビュー

 ・保険かけのCCメール        ・長時間にわたる世間話的な電話

 ・遅刻により相手を待たせる時間     ・優先順位を考えない場当たり的な仕事のやり方

 ・責任の押し付け合い、ケンカ、派閥争い、勢力争いによって失われる時間とエネルギー

 ・多重請負構造・多層組織構造によるコミュニケーション不良

改善策

 上記に列挙されたさまざまな無駄は特段の注意を向けなければ無駄だとは認識されにくい人間行動の不適切さに起因するものが多い。これらの問題に対する個人的ないしは個別的な対応はほとんど効果を期待できない。これらの問題は組織文化の問題であるため組織的な躾、すなわち組織的な運動が必要であり、例えばそれは伝統的なアプローチである5S運動が有効である。

【ソフトウェア開発における5S】

 ・整理: 開発に必要なものは残し、不要なものは廃棄すること。

 ・整頓: 開発に必要なものは常時使用可能な状態にしておくこと。

 ・清掃: 開発に必要なものの欠陥は常時修正しておくこと。

 ・清潔: 開発に必要なものは最新の状態にメンテナンスしておくこと。

 ・しつけ: 上記の4Sを実行する習慣を身につけること。

 これらの運動は、まさにさまざまな改善活動の中において組織員全員の活発なコミュニケーションの実行のもとに、組織的にかつ継続的に実行する必要がある。

改善の期待効果

◎優れた開発活動を支えるものは、言うまでもなく、個人および組織における健全なヒューマンスキルに他ならず、これらの人間能力は、その自律性を基本的な土台とし、妥当性と合理性の双方の力によって、柔軟な思考・行動を生み出し、個人ないしは組織間における相互義務および相互扶助の行動を促進するでしょう。最後に、これらの魅力的かつ人間的な思考・行動によって獲得された有形・無形の心的・物的な資産を、将来の自他に譲る行為によって、その個人ないしは組織に永続的な繁栄をもたらすことができると思われます。


改善 癸隠機.董璽沺Аゝ’愁皀献紂璽訖閉輯浜表の導入

改善すべき問題点

 一般的な仕様別ないしは機能別の進捗管理表は大まかな進捗を表すのには適しているが、詳細の進捗は不明で信頼性に乏しく、昨日まではオンスケジュールだったものが今日になって突然1週間遅れとか1ヶ月遅れとかの報告を受けることがある。

改善策

 従来の仕様別・機能別進捗表に加えて開発進捗の正確性を担保するために仕様や機能の裏付けとなるソフトウェア・モジュールおよび部品レベルの進捗を表すことが可能な「機能モジュール進捗管理表」を作成し運用する。部品レベルまでに落とし込まれた進捗管理によって、開発の進捗管理の精度は格段に向上し、遅延部分の特定が容易になり、柔軟かつ迅速な対応が可能となる。

 この部品レベルの管理法はコンビニエンス・ストア業界における単品管理に学んだ手法である。

改善の期待効果

◎開発進捗の究極的な可視化によって全ての開発部材単位の進捗が正確に把握され、それによって進捗のロードブロックを早期発見することで早期対応や柔軟な対応が可能となり、スケージュールの遅延を防止することができる。


改善 癸隠供.董璽沺А―だ技跳鏨浜表の導入

改善すべき問題点

 全てのテスト工程および市場稼働時に発生した不具合および仕様変更に関する修正作業は一般的に不具合票や要求仕様変更管理表などで管理されているが、それぞれの修正作業の進捗や作業内容などについての集中的かつ視覚的な管理はおろそかになりがちであり、その作業の正確な内容および進捗度合いの有効な管理がなされておらず、開発効率の低下や品質の低下を招いている。

改善策

 不具合残件および中途仕様変更の進捗をその内容と共に視覚的に表現した「不具合残件管理表」を作成・運用する。


改善 癸隠掘.董璽沺А.愁侫隼饂困領用

 

改善すべき問題点

 同一業種業態の各社顧客から要求されるアプリケーション仕様・機能には非常に類似性が高いものが多いのにもかかわらず個別に開発されている場合が多く、開発および顧客に対してQCDに大きなネガティブなインパクトを与えている。

改善策

 アプリケーション層におけるソフト資産の流用・共用化を促進させるための施策としては次のようなものがある。

 ・モジュール化のための設計ガイドラインの作成。

 ・類似仕様・機能のモジュール化。

 ・モジュール化済みの部材のDB等による開発内公開および周知を図る。

 ・再利用率(リピート率)をモニタリングし、再利用を促すこと。

【モジュール設計ガイドの概要】

 ・初期設計段階でのモジュール設計ガイドライン

 ・詳細設計段階でのモジュール設計ガイドライン

 ・プログラム作成段階でのモジュール設計ガイドライン

 ・ドキュメント作成のガイドライン

【アプリケーション設計ガイドの概要】

◎初期設計/詳細設計段階での各階層構造のモジュール設計方法を記述

 ・GUI部:入力制御、表示制御に関するパターン化の明示

 ・業務処理部:業務クラス追加・変更に関するパターン化の明示

 ・機能モジュール:機能モジュールに関するパターン化の明示

◎プログラム作成段階でのモジュール作成ガイドライン

◎ドキュメント作成のガイドライン

改善の期待効果

◎多くの知恵と工夫を要するが、「ソフト開発のQCDを向上させるにはソフトを作らないこと」という言葉を最も良く現す成果が得られる。


改善 癸隠検.董璽沺А―藉設計レビュー・チェックシートの運用

改善すべき問題点

 ・システムの全体像が表されていない。    ・要求仕様が完全に網羅されていない。

 ・設計のコンセプトが不明。        ・理解が困難ないしは不可能な内容。

 ・要求機能を構造化した設計になっていない。・実運用との整合性が分からない。

 ・仕様の変更および仕様の間違いが反映されていない。

 ・機能を実現するための情報の欠落や誤りが多い。

 ・柔軟性に乏しい構造設計になっている。

 ・詳細設計書作成のベースドキュメントとして使用可能な設計品質ではない。

 ・結合テスト仕様書のベースドキュメントとして使用可能な設計品質ではない。

改善策

 要件定義書における誤りや抜けを発見すると同時に初期設計書としての基本要件を満たすための諸条件を網羅した「初期設計チェックシート」を作成し、初期設計工程においてレビューを行う。

改善の期待効果

◎要件定義書の欠陥を早期に発見すると同時にシステムの基本設計書である初期設計書の品質を確保することで、その後に続く詳細設計・製造・評価工程のQCDおよび生産性を向上させる。

Ref.『プロジェクト レスキューマニュアル 第5章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

『設計製造評価リスク クイックリファレンス 2.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/sekkei_riskreference.pdf

 


改善 癸隠后.董璽沺А‐楮拈澤廛譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 ・各機能の起動条件が不明確

 ・各機能の入力条件および出力結果(データ、表示、印字等)が不明確

 ・各機能の処理フローが不明確

 ・各機能のデータフローが不明確

 ・使用されるテーブル・ファイルが不明確

 ・排他処理・異常処理が不明確

 ・記録されるべきログが不明確

 ・プログラム作成のベースドキュメントとして使用可能な設計品質ではない。

 ・単体テスト仕様書のベースドキュメントとして使用可能な設計品質ではない。

改善策

 初期設計における誤りや抜けを発見すると同時に詳細設計書としての基本要件を満たすための諸条件を網羅した「詳細設計チェックシート」を作成し、詳細設計工程においてレビューを行う。

改善の期待効果

◎初期設計書の欠陥を早期に発見すると同時にプログラム作成の基本設計書である詳細設計書の品質を確保することで、その後に続くプログラム製造・評価工程のQCDおよび生産性を向上させる。

Ref.『プロジェクト レスキューマニュアル 第5章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

『設計製造評価リスク クイックリファレンス 2.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/sekkei_riskreference.pdf

 


改善 癸横亜.董璽沺А.魁璽疋譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 ・詳細設計書が未完了のまま製造工程に進むこと。

 ・製造担当者のコーディングミス。

 ・製造時のデバッグの質が悪いこと。

 ・レスポンス・パフォーマンスを考慮した設計や製造がなされないこと。

改善策

 詳細設計における誤りや抜けを発見すると同時にコーディングの基本要件を満たすための諸条件を網羅した「コーディングチェックシート」を作成し、コード製造工程においてレビューを行う。

 ・プロセス管理の遵守

 ・コーディング・ガイドラインの作成(過去のコーディングミスに学ぶこと)

 ・デバッグの励行

 ・性能要件を考慮したコーディングの実行。

改善の期待効果

◎詳細設計書の欠陥を早期に発見すると同時にコーディングの品質を確保することで、その後に続く評価工程のQCDおよび生産性を向上させる。

 

Check List プログラマーがやってはいけない手抜きの12ヶ条            

 ?Check Timing:プログラミング着手前

□ ソースコードの”コピペ”を無節操に行なっていないか。

□ ベースのプログラム構造を理解しないままソースコード変更に着手していないか。

□ データ処理の仕掛けを理解しないままソースコード変更に着手していないか。

□ 変更対象の機能の呼び出され方、関連機能との連携の仕方を理解せずソースコード変

更に着手していないか。

□作られたデータはどの機能がどのタイミングでアクセスしているのか理解しないままソー

スコード変更に着手していないか。

□ 他人の書いたソースコード理解するためにそれを読むことだけしかしていないのでは。

□ 一つの変更要件に対して複数の担当者が関係している場合、早い段階でお互いに検討

内容等の相互確認・レビューをしているか。また、みなバラバラにソース修正にとりかか

り、寄せ集めたソースで一気にテストをしているのではないか。

□ お互いにどこを変更したのか誰も知らないのではないか。

□ 一つの機能に関する多数の関数において同一巨大パラメータ構造体(256バイト等)を

共通に使用してはいないか。

□ 開発中に発見された、以前から含まれていた潜在バグについていきなりソースコードの

修正を行なっているのではないか。

□ 「プロジェクト計画書」を書いていないのではないか。

□ 「データ」をとっていないのではないか。

(出典;清水吉男著「派生開発を成功させるプロセス改善の技術と極意」および「要求を仕様化する技術 表現する技術」)

Ref.『プロジェクト レスキューマニュアル 第4章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第9章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロプロマネ銀の弾丸・チェックリスト 15.』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

『設計製造評価リスク クイックリファレンス 3.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/sekkei_riskreference.pdf

 


改善 癸横院.董璽沺А.謄好噺率の向上

改善すべき問題点

 従来のチェックリストではテストパターンの確認が困難でテスト漏れが発生する。

改善策

 運用をからめたマトリクス型のテスト仕様書を使用することによりテスト漏れを防止する。

改善の期待効果

◎テスト漏れは確実に減少するが運用のケースを明確に把握しておく必要がある。またこのマトリクス表にあるべき入力データおよび出力データの定義を付加することでさらに有効なテスト仕様書となる。


改善 癸横押.董璽沺А|餌痢Ψ觜腑謄好肇譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 ・テスト用チェックリスト(テスト仕様書)の精度が悪い。

 ・時間不足を理由にした単体テスト・結合テストの手抜きないしはスキップ。

 ・初期設計書および詳細設計書とテスト仕様書の各項目の対応ひも付けが不十分。

 ・重要機能順のテストが行われないこと。

 ・テストの自動化が不十分なこと。

 ・テスト結果のレビューが行われず不具合の傾向が把握されないこと。

改善策

 単体テストおよび結合テストの内容が設計書通りに動作することを確認する項目を網羅した「単体・結合テストレビュー用チェックシート」を作成し、テストの前にレビューを行うことで、作成された単体テスト仕様書および結合テスト仕様書における誤りや抜けを発見する。

改善の期待効果

◎テスト仕様書の欠陥を早期に発見することで単体テストおよび結合テストの品質を確保し、その後に続く総合テストのQCDおよび生産性を向上させる。

 

Ref.『ソフトウェア開発のメソッド クイックリファレンス 第11章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロプロマネ銀の弾丸・チェックリスト #54、#71』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

『プロジェクト レスキューマニュアル 第3章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改善 癸横魁.董璽沺А〜躪腑謄好判猗レビュー・チェックシートの運用

改善すべき問題点

 下記の総合テスト環境が揃っていないために有効な総合テストが行えない場合がある。

 ・総合テストに必要な全てのソフトウェア環境および成果物が揃っていない場合がある。

 ・顧客実運用テストに必要な顧客設定データが揃っていない場合がある。

 ・総合テストに必要な全てのハードウェア環境が揃っていない場合がある。

 ・総合テストに必要な総合テスト仕様書が揃っていない場合がある。

 ・総合テストに必要な人員体制が整っていない場合がある。

改善策

 総合テストに必要な上記のソフトウェアおよびハードウェアの環境および部材が揃っていることを事前に確認するための「総合テスト準備チェックシート」を作成し、総合テスト開始前にレビューを行う。

改善の期待効果

◎総合テストに必要な全ての環境および部材が揃っていることを事前に確認することで総合テストをスムーズに開始させ、総合テストのQCDおよび生産性を向上させる。

Ref.『設計製造評価リスク クイックリファレンス 4.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/sekkei_riskreference.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第13章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロプロマネ銀の弾丸・チェックリスト #55、#71』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

『プロジェクト レスキューマニュアル 第3章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改善 癸横粥.董璽沺А〜躪腑謄好肇譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 総合テスト仕様書(テスト・チェックリスト)の欠陥が多い。

 ・総合テスト仕様書(チェックリスト)そのものが揃っていない。

 ・抜け・誤記が多く精度が悪い。        ・異常系のチェックが抜けている。

 ・実運用テストのチェックが抜けている。    ・性能評価のチェックが抜けている。

 ・非機能要件のチェックが抜けている。    ・外部 I/O系のチェックが抜けている。

改善策

 総合テストの内容が要求仕様通りに動作することを確認する項目を網羅した「総合テストチェックシート」を作成し、テストの前にレビューを行うことで、作成された総合テスト仕様書における誤りや抜けを発見する。

改善の期待効果

◎総合テスト仕様書の欠陥を早期に発見することで総合テストの品質および生産性を向上させ、最終的には、顧客の要求通りの品質および機能を確認する。

 

Ref.『設計製造評価リスク クイックリファレンス 4.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/sekkei_riskreference.pdf

『ソフトウェア開発のメソッド クイックリファレンス 第13章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロプロマネ銀の弾丸・チェックリスト #55、#71』http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

『プロジェクト レスキューマニュアル 第3章』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改善 癸横機.董璽沺А々柔管理作業チェックシートの運用

 

改善すべき問題点

 ソフトウェアの適正な管理がなされなかったことにより以下のような問題が発生している。

 ・出荷ソフトウェアにおけるモジュール抜け。

 ・出荷ソフトウェアにおける誤ったモジュールの混入。

 ・出荷ソフトウェアにおけるバージョンの取り違え。

 ・改修時または不具合修正時のデグレ―ション。

 ・度重なる仕様変更による混乱。

改善策

 効果的な構成管理ツールを使用すると同時に人間系に由来するエラーを防ぐために「構成管理作業チェック・シート」を使用する。

改善の期待効果

◎構成管理ツールとともに構成管理作業チェック・シートを組織的に運用すれば人的ミスによるソフトウェアの構成不具合を防止できスムーズな市場投入が可能となる。


改善 癸横供.董璽沺А.螢蝓璽好譽咼紂次Ε船Д奪シートの運用

改善すべき問題点

 ソフトウェアおよび要求仕様書・設計書・評価仕様書等の最終正式版が揃っていない。

 ・リリース成果物が揃っていない場合がある。

 ・リリース成果物が最終正式版になっていない場合がある。

 ・開発途中で発生した変更内容が更新されていない場合がある。

 ・リリースされるソフトウェアが書き込まれたマスターメディアを使用した最終確認テストが

行われていない場合がある。

改善策

 顧客にリリースされる全ての成果物項目を網羅した「リリース・チェックシート」を作成し、リリース前に確認することで間違いのない製品であることを確認する。

改善の期待効果

◎リリースされる成果物が正しい最終成果物であることを確認することで、顧客に間違いのない製品をリリースすることができる。


改善 癸横掘.董璽沺 Д薀奪廛▲奪廚亮孫

改善すべき問題点

 プロジェクト終了時に行う振り返り会議(ラップアップ・ミーティング)を実行しない場合に起こる問題は次の通りです。

 ・失敗に学ばないために同様の問題を再発させる。

 ・成功要因を他のチームへ横展開できない。

 ・目標と実績の対比を行わないために、失敗/成功のレベルを数値で把握できない。

 ・失敗/成功の要因を全メンバーで共有できない、学習できない。

 ・次なる目標値の設定ができなくなる。

改善策

必ず「ラップアップ・ミーティング」を実行し、下記項目の目標値と実績値の差異の分析を行い、その原因を特定し、対策案の作成を行うこと。

◎品質問題の振り返り

 ・発生不具合(総合テスト)のレベル、件数および発生率(/Kstep)

 ・発生不具合(市場リリース後)のレベル、件数および発生率(/Kstep)

 ・仕様品質;仕様ミス率(仕様ミス発生件数/Kstep)

 ・設計品質;設計ミス率(設計ミス発生件数/Kstep)

 ・製造品質;製造ミス率(製造ミス発生件数/Kstep)

 ・評価品質;評価ミス率(評価ミス発生件数/Kstep)

 ・プロセス品質;レビュー漏れ率(レビュー漏れ不具合件数/Kstep)

◎コスト・利益問題の振り返り

適正な利益確保の振り返りのポイント

1.見積りと実績の差異の分析を行うこと。

2.適正利益率が確保されなかった場合、見積り自体の問題と開発の問題に分けて問題は何か、問題のレベルはどうだったのか、何故その問題が発生したのかの原因および真因の分析と対策案の作成を行うこと。

 ◎生産性問題の振り返り

 見積りヒット率/要求仕様書精度達成率/ソフトウェア流用率(モジュール化率、リピート率)/プログラム製造ステップ単価などの目標値と実績値の差異の分析を行い、その原因を特定し、対策案の作成を行うこと。

改善の期待効果

◎「ラップアップ」は「目標値の設定」とセットになって機能し、開発チームをデータ・ドリブンな組織に変身させ、次なるプロジェクトの目標設定を可能とし、チームメンバーの確実な成長を約束する。

 ・失敗に学び同様な失敗を防止する。

 ・成功要因を他のチームへ横展開可能とする。

 ・目標と実績の対比を行うことで、失敗/成功のレベルを数値で把握できる。

 ・失敗/成功の要因を全メンバーで共有でき、大きな学習効果を与える。

 ・次なる目標値の設定が可能となる。


改革コンセプト#1 キーワード: 時間の確保

改革のコンセプト : ものごとを遂行するにおいて時間の確保は究極の必要条件である。

 ヒト・モノ・カネ・情報などのリソースはなんとかなる可能性があるが、失われた時間を取り戻すことはできない。プロジェクトの究極の成功要件は、必要時間の確保にあることを深く認識し、必要時間の確保および無駄な時間の削減に必要なあらゆる対策を講じること。

必要なアクション

(1) 先行調査によりリスクを排除し、後工程で発生する不始末による膨大な時間ロスを防ぐこと。

(2) 要件定義工程において顧客とのコミュニケーションを緊密にすることで要求仕様の誤解やモレをなくし後工程で発生する膨大な時間ロスを防ぐこと。

(3) リスクを考慮した妥当かつ正確な見積りを行うことで開発に必要な絶対時間の確保をすること。

(4) 開発プロジェクト内のコミュニケーションを緊密にすることで指示の誤解やモレをなくし後工程で発生する膨大な時間ロスを防ぐこと。

(5) 重要な機能から先に開発を行い、完成の都度顧客と現物にて動作確認を行うことで、やり直し・修正などの膨大な時間ロスを防ぐこと。

(6) 上記をより可能にするために顧客および開発チームは場所および情報の共有を行い開発を共同して遂行すること。

アクションの具体例 

◎先行調査

 要求仕様の疑問点・不明点の払拭、未経験の仕様・機能の調査・理解、プロトタイプ作成による未知の新技術領域のリスクの排除など。

◎顧客との密接直接コミュニケーション

 要件定義に関して顧客との集中合宿検討会を含む密接かつ頻繁な仕様検討会の実行。

◎妥当かつ正確な見積り

 要求仕様および開発全体に関するリスクを把握し、開発に必要な時間と予算の確保を行

うこと。

◎開発内部のコミュニケーション

 毎日ベースの定例日次情報共有会議の実行、週次のまとめ振り返りおよび次週予定検討会の実行、月次のまとめ振り返りおよび次月予定検討会の実行など。

◎顧客に対して7日〜10日ごとの重要仕様順のリリースを繰り返し顧客および開発チーム

による共同検証を行い、不具合修正・仕様変更等は顧客との直接対話による即断・即決に

よる対応を行うこと。

期待効果 

◎プロトタイプ作成による未知の新技術領域特有の不具合のあぶり出しによる、本番開発における致命的な不具合の予防。

◎顧客との密接直接コミュニケーションにより要件定義における相互の理解を促進するだけではなく相互の信頼関係を醸成する。

◎要求仕様の早期明確化をベースにした妥当かつ正確な見積りは、プロジェクトの絶対的な成功要因である必要時間の確保と必要予算の確保を確かなものにする。

◎開発チーム内の日次・週次・月次の頻繁なコミュニケーションはメンバー全員による問題の共有および情報の整理整頓を促進し、開発者における仕様の誤解・設計ミス・段取りミス等を大幅に削減すると同時に大勢の開発者における開発完遂の強いモチベーションを最後まで維持させる。

◎短期間開発ごとに逐次リリースされた動作する現物のソフトウェアにての顧客との直接的

検証・対話は開発における後戻りや不要な修正等の無駄な作業を大幅に削減する結果とな

り、同時に顧客における安心感・満足感の醸成に大きく寄与する。

Ref.『ソフトウェア開発のメソッド クイックリファレンス 第5章』

http://www.geocities.jp/pmfactory_ambitious/pmnote/method.pdf

『プロマネ 銀の弾丸・チェックリスト 16.』

http://www.geocities.jp/pmfactory_ambitious/pmnote/silverbullets_20161015.pdf

『プロジェクト レスキューマニュアル 第7章4.』http://www.geocities.jp/pmfactory_ambitious/pmnote/projectrescue2016.pdf

 


改革コンセプト#2 キーワード: 自律型開発

改革のコンセプト

 マンネリ化したウォーターフォール型開発組織を自律性のある組織へ転換させる。

必要なアクション

 1. 毎日やろう        2. 毎日聞こう    

 3. 毎日見よう        4. 毎日まとめよう

 5. マネジャーは心理的・地理的にいつも開発担当者のそばに居よう。

 6. 顧客の声を聞こう    7. 早くしよう    

 8. 見えるようにしよう

 これらの行動は開発者における自律性・協調性を促し、顧客との密な連携を促し、日々

刻々の変化に即応するための基本的な行動のポイントとなる。

アクションの具体例 

1. 毎日やろう

 ・課題バラシおよびその対策を毎日実行しよう。

 ・開発担当者を毎日巡回しフォローしよう。

 ・対策の指示を毎日行なおう。

2. 毎日聞こう

 ・お客様の話を良く聞こう。

 ・開発担当者の不平・不満・グチを聞こう。

 ・関連部署の状況を聞こう。

3.毎日見よう

 ・毎日、リスク管理表・課題管理表を見よう。

 ・毎日、開発担当者たちの進捗状況を見よう。

 ・毎日、開発担当者たちの健康状況を見よう。自分の健康状況も。

4. 毎日まとめよう

 ・変化する課題・問題を毎日、整理更新しまとめよう。

 ・明日以降の必要なアクションをまとめよう。

5. マネジャーは心理的・地理的にいつも開発担当者のそばに居よう。

 ・マネジャーはいつでも担当者の相談にのろう。

 ・マネジャーは事務所から開発ルームに引っ越そう。

6. 顧客の声を聞こう

 ・お客様を早い時点で開発パートナーとして巻き込もう。

7. 早くしよう

 ・自部署の担当ではないと判断した仕事は即刻担当部署に渡そう。

8. 見えるようにしよう

 ・リーダはサブリーダの、サブリーダは担当者・外注の仕事の範囲を明確にしよう。

 ・必要な情報は口頭だけに頼らずまず手書きでも白板のコピーでも良いから書面として見えるようにしておこう。

 ・スケジュール進捗表・管理表は毎日更新しておこう。


改革コンセプト#3 キーワード: 変化即応型開発

改革のコンセプト

 1. 顧客要求に対して俊敏な対応をすること。

 2. 開発チーム全員による意識・価値観の共有による目標の達成。

必要なアクション

 (1)顧客とのデイリー&ダイレクトなコミュニケーションの実施。

 (2)インクリメントな成果物を基にした顧客と開発チームによる共同評価・検証の実施。

 (3)開発チーム内のデイリー&ダイレクトなコミュニケーションの実施。

アクションの具体例 

◎顧客と開発チーム間あるいは開発チーム内において発生する課題・問題を、成果物である現物に基づいて直接的なコミュニケーションによって毎日ベースに俊敏に解決しようとする

こと。 プロジェクトの主要な問題は人と人の間に発生するものであり、それらの問題をすばやく解決することからしかプロジェクトの成功は導き出せない。

 フォーカス活動(カイゼン活動)における顧客とフォーカスチーム(カイゼン主導チーム)間およびフォーカスチーム内の相互作用関係は下図のように表せる。

 フォーカスチームと顧客間における相互作用関係を実現するための基本コンセプトは「顧客要求に対する俊敏な対応」であり、これを支える行動指針は「顧客とのデイリー&ダイレクトなコミュニケーションの実施」および「インクリメントな成果物を基にした顧客と開発チームによる共同評価・検証の実施」である。

 またフォーカスチーム内におけるメンバー間の相互作用関係を実現するための基本コンセプトは「開発チーム全員による意識・価値観の共有による目標の達成」であり、これを支える行動指針は「開発チーム内のデイリー&ダイレクトなコミュニケーションの実施」である。


改革コンセプト#4 キーワード: フォーカス活動

改革のコンセプト

 フォーカス活動(カイゼン活動)は、顧客に対してスピーディな協調的相互作用関係の中で、顧客要求の変化に対応すべく密接なコミュニケーションを実行し、正しく機能するソフトウ

ェアを提供し、さらにこれらを実現すべくフォーカスチーム内においては自律的なメンバー間においてフェイス・トゥ・フェイスの会話を実行し、一定の開発ペースを維持すべく顧客要求の

価値の高い順にインクリメンタルな開発を継続し、有効な技術の採用に注意を払い、定期的な振り返りによるフィードバックにより無理・無駄・失敗の予防を行なおうとするものである。

必要なアクション

◎コンセプト1.顧客要求に対する俊敏な対応

 行動指針1.顧客とのデイリー&ダイレクトなコミュニケーションの実施

 行動指針2.インクリメントな成果物を基にした顧客と開発チームによる共同評価・検証の実施

◎コンセプト2.開発チーム全員による意識・価値観の共有による目標の達成

 行動指針3.開発チーム内のデイリー&ダイレクトなコミュニケーションの実施

期待効果 

◎フォーカス活動(カイゼン活動)はウォーターフォール開発における3つの問題点の解消に大きな効果があるものと考えられる。

 々程間のコミュニケーション・ギャップによる問題

 開発能力による問題

 GЪ映塾呂砲茲詭簑

 フォーカス活動は顧客とのあるいは開発チーム内における密接なコミュニケーション、顧客要求順位の高いものから行われるインクリメントな開発等により下記のような効果を生む。

 ・分割リリースごとに動作確認・顧客検証を終了して進むため、開発完了に向けて見通しが良く、予測可能である。

 ・低リスクである。失敗に対するリカバリー期間確保が容易である。顧客および開発者における安心感が確保される。

 ・要件の変更・追加に対する柔軟性・融通性がある。

 ・品質確保の効果がある。

 ・顧客満足度の獲得がしやすい。

 ・開発者の自主性・自律性・モチベーションの向上が期待できる。

 ・チームワークの強化が行われる。

 ・コミュニケーション能力の育成・定着化が行われる。

 上記はいわゆるウォーターフォール開発にアジャイル的な要素を組み込んだ開発方式であり、筆者がリードした大規模な開発においてもその効果は実証済である。