【プロマネ 銀の弾丸●チェックリスト】 

15.手抜き問題のチェックリストCheck List #68~72 2016.10.15

 

1. ソフトウェア開発リスクの全体像

Point : 複雑な問題の解決にはチェックリストを

□ チェックリストは、開発問題の解消に有効であることを知る。

□ チェックリストは、その事前のチェックタイミングに用いることでのみ有効となる。

□ チェックリストは、失敗リスク回避の強力なツールである。

 ソフトウェアの開発は多くの複雑な手順が必要とされますが、すべての手順を記憶しておくことは不可能であるし、また一々細かな手順書に従って行動することも実際的ではありません。 これから示すチェックリストは、重要な行動項目の抜けや見落としを防ぎ問題の発生を予防するという観点で構成されています。

 それぞれのチェックリストの確認は、ある行動に着手する直前に行うことで効果が発揮されます。この確認のタイミング(Check Timing)は一時停止点(Pause Point)とも呼ばれており、物事を開始する前のリスク排除の重要な働きを持っています。

 どのような行動においても、それを無事に遂行するためには、事前にその行動の重要なポイントを一度立ち止まって冷静に見るという「静」の時間が理性や合理性を働かせる重要な働きをします。この「静」と実際の行動における「動」が相まって、人間行動の過ちを防ぐ働きをしています。

 次に示した「Check List #1 開発プロジェクト安全チェックリスト」は、ソフトウェア開発の全体を包括的に俯瞰したもので、プロジェクト開始の前にチェックすることでプロジェクト開始にあたっての全体的なリスクの発見に有効に働くことになります。

Check List #1 開発プロジェクト安全チェックリスト ▶Check Timing:開発準備時 

 

【見積り回答前】 ◀ Check Timing

□ 要求仕様の骨子が決定され明確に書面にて提示されていること。

□ 見積り回答書の内容は、要求仕様骨子の実現に見合った開発期間および開発費になっていること。

□ 見積り回答書には、明確な要求仕様骨子に対してのみ見積られ、不明なものについては見積りに含まれていないことを明記すること。

□ 見積り回答書に、開発に必要な実行条件がある場合、その条件を明記すること。

【設計着手前】 ◀ Check Timing

□ すべての要求仕様が決定され、明確に書面にて提示されていること。

□ 全ての要求仕様に関して、全ての不明点および疑問点が払拭されていること。

【製造着手前】 ◀ Check Timing

□ 基本設計が完了され、基本設計書として明確に書面にて提示されていること。

□ 詳細設計が完了され、詳細設計書として明確に書面にて提示されていること。

□ 全ての設計書に関して、全ての不明点および疑問点が払拭されていること。

【単体テスト前】 ◀ Check Timing

□ 単体テスト試験書が作成済であること。

□ テスト対象機能のコーディングが全て完了していること。

【結合テスト前】 ◀ Check Timing

□ 結合テスト試験書が作成済であること。

□ テスト対象機能の単体テストが全て完了していること。

【総合テスト前】 ◀ Check Timing

□ 総合テスト試験書ないしは運用(シナリオ)テスト試験書が作成済であること。

□ 総合テスト対象機能の単体・結合テストが全て完了していること。

【成果物リーリース前】 ◀ Check Timing

□ 全ての機能が要求仕様通り、システムとして実運用を満たしていることが確認されたか。

□ 発見済で未修正の不具合が残存していないか。

 Check List 2 プロジェクトを成功させるための基本条件 Check Timing:開発準備時

統合管理

□ ベンダーを中心とした統合的プロジェクト管理を行うこと。

□ 適切なプロジェクト・マネジメント能力を発揮すること。

 

コミュニケーション

□ プロジェクト傘下の全組織および全会社間の密接なコミュニケーションを行うこと。

□ 日次情報共有会議によるチーム内での情報共有を行うこと。

 

要求仕様

□ 主要な仕様を適切な時期までに凍結させること。

 

リソースの確保

□ 見積り交渉において、開発内容に見合った工期・予算を確保すること。

□ 顧客システムおよびその運用業務に精通していること。

□ 開発規模および難易度に応じた開発体制を構築すること。

 

開発

□ 顧客価値の重要度順の仕様凍結ならびに開発を行うこと。

□ ドキュメントに基づいた開発を行うこと。

□ データに基づく開発を行うこと。

□ 開発効率化・失敗の再発防止のために普段の改善活動を行うこと。

2. 不条理な顧客/ベンダー要求のチェックリスト

【不条理な顧客要求

Check List #3 不条理な顧客要求への対抗策       Check Timing:見積り回答前

□ 開発責任者と要求側責任者の密接かつ直接的な話し合いを実行すること。

□ 完全な要求仕様書の早期提示時期の確約をとること。

□ 開発仕様はすでに凍結合意されたものに限定すること。

 

*困難な要求に対しては、困難な条件の提示を行うこと。

□ 要求元からのPM、有識技術者等の投入

□ 要求元からの評価テスト支援メンバーの投入

□ 開発要員増強のためのプレミアムコストの要求

□ 暫定版または優先度順のリリース、分割リリース等の条件提示を行うこと。

□ 「暫定版の不具合発生責任は要求者に負っていただく」と言う条件提示を行うこと。

□ 「暫定版の市場投入は、限定数にて実験店舗のみ」と言うような条件提示を行うこと。

□ 「全店稼働は正式版のみで行うこと」と言うような条件提示を行うこと。

 【仕様凍結】

Check List #4 早期仕様凍結                Check Timing:仕様凍結準備時

□ 早期仕様凍結のために顧客および関連各社の参加・協力の要請を行うこと。

□ 仕様凍結の期限を切り、元請側と下請側で合意をしておくこと。

□ 顧客・元請・下請間の直接コミュニケーションによる要求仕様の期限内凍結を行うこと。

□ 集中検討会ないしは合宿等にて短期集中的に仕様決定を行うこと。

□ 受注者側においても提案型仕様凍結を行うこと。

□ 顧客価値の優先度順に仕様凍結を行うこと。

□ 顧客価値の高い仕様順に開発着手すること。

□ 開発仕様の目的・背景・範囲・内容を文書にて明確化すること。

□ 仕様未凍結状態ないしは疑問点・不明点を残したままで先行開発着手は行わないこと。

 

Check List #5 仕様理解                      Check Timing:仕様調査時

 

□ 仕様検討の段階で要求者と徹底的な仕様検討を行うこと。

□ 要求仕様の背景や意味を必ず理解しておくこと。

□ まずは仕様の全体像の把握から始めること。

□ 疑問・不明点の発掘を行い、その解消に向けて要求者に対し積極的な行動を取ること。

□ 仕様決定のQ&Aは直接対話による確認を行うこと。

□ 不明なことは直ちに分かっている人・部署に聞くこと。

□ 習得した内容を、ドキュメントによって他のメンバーに伝えること。

□ 早期の仕様凍結を行うこと。

□ 基幹仕様未決定で開発に着手してはいけない。

 

Check List #6 仕様調査およびQ&A運用          Check Timing:仕様調査時

 

□ 仕様内容の骨子の事前の把握と整理を済ませておくこと。

□ 仕様調査は、顧客価値の重要度順および基幹的仕様から始めること。

□ 仕様追加・変更の影響度の事前調査を済ませておくこと。

□ 全ての問題点・疑問点を掘り起こすこと。

□ 重要な仕様・基幹仕様に関するQ&Aは直接対面コミュニケーションで確認すること。

□ 仕様内容および変更内容はチーム内(含む評価チーム)で即時的な情報共有を行うこと。

□ 仕様調査のQ&A情報や変更内容は要求仕様書や設計書も同時に更新すること。

□ 仕様決定事項や変更事項は集中的かつ情報共有可能なシステムで管理すること。

Check List #7 影響度表作成のポイント               ▶Check Timing:設計時

□ 正確な構造設計書・テーブル関連図・プロセスフローから影響度表を作成すること。

□ 事前の実装調査にて判明した他機能への影響情報を記録すること。

□ 設計作業時において知りえた影響情報を記録しておくこと。

□ 製造時において知りえた影響情報を記録しておくこと。

□ デバッグ時に判明した他機能への影響情報を記録すること。

□ 単体・結合・総合の各テストにおいて判明した他機能への影響情報を記録すること。

□ 市場障害対応にて判明した他機能への影響情報を記録すること。

 

要求仕様書の検証

Check List #8 要求仕様書のチェックポイント Check Timing:要求仕様書発行・受領時

1. 妥当であること

□ 顧客やユーザーのニーズと一致していること。

□ 上位のシステム要求仕様書などの関連する他のドキュメントとの矛盾がないこと。

□ 未確定項目がある場合は、どのように合意するか、依頼者と合意形成方法を決めておく。

 

2. あいまいでないこと

 

□ 要求仕様書に記述されている要求が、ただ一通りに解釈できること。

□ 要求仕様書の“良し悪し”を判断する手段や基準をもつこと。

□ 「範囲」を読み取れるように要求を表現すること。

□ 仕様は「仕様である」ことを明示し、説明は「説明である」ことを明示して記述すること。

□ 要求仕様書では、記述内容が“特定”できる表現になっているものを“仕様”とすること。

□ 要求仕様書の構成や内容は、後工程の読者に分かるように書くこと。

□ 「等」や「etc」の文言は使用しないこと。使用する場合は、○月○日までに決めるとコメントをつけること。

 

3. 完全であること

 

□ 顧客やユーザーの、情報システムに対するニーズが漏れなく要求仕様書に記述されており、かつ図表の参照や用語の定義などの、要求仕様書の形式が整っていること。

□ 「境界」は早い段階で決めること。

□ 「要求」のモレを防ぐために、カテゴリの分類や要求の分割・階層化に漏れがない、隙間がないことを確認できるようにすること。

□ 要求仕様書には、「操作性」「保守性」「交換性」などの「品質要求」を記載すること。

□ 階層化の基準として、以下を(状況によっては組み合わせて)使い、「隙間」なく分割すること。  時系列分割(時間軸分割)/構成分割/状態分割/共通分割

□ モレなく書くこと。

□ 要求仕様の番号をテストケースの番号とひもづけし、テストケースにモレがないことを確認すること。

□ 仕様をグループに分け、さらに集合を小さくし、混じり気のない仕様のグループを作る。

□ <グループ名>に要求の性質を持たせるためには、範囲をあらわしていることを意識してグループ名を選ぶこと。

□ 「・・・・は、・・・・しない」という「否定表現」を避け、thenとelseの両方を明らかにすること。

 

4. 矛盾がないこと

 

□ 要求仕様書内部で矛盾や衝突がないこと。

□ ほかの機能の仕様と衝突していることに気づくためにも、仕様は早期に展開すること。

□ 早い段階で全体の仕様化を行うこと。

 

5. 重要度と安定度のランク付けがされていること

 

□ 各要求について、重要度と安定度を示す指標を明確につけておくこと。

□ 確認中の仕様をそのまま記述し、変わる可能性があることを明記すること。

6. 検証可能であること

□ 開発されたソフトウェアが、要求仕様書に記述された要求を満たしているかどうかを確認  

   可能であること。

□ 検査部門の人に、「検査可能」という側面から要求仕様書のレビューを実施してもらう。

□ 品質要求(「操作性」「保守性」「交換性」など)はテストでも確認すること。

7. 変更が容易であること

□ 要求仕様書に対する変更が、容易に、完全に、一貫して行えるようになっていること。

 a)目次や索引、明確な相互参照が整備され、使いやすい構造になっていること。

 b)冗長でない、つまり、同じ要求が要求仕様書内で複数個所に記述されていないこと。

 c)他の要求と混ざらず、各要求を独立・分離して表現している。つまり、要求が互いに依存

   していないこと。

□ 重複なく書くこと。

□ 仕様書全体を「均一」に記述することにこだわらないこと。関係者間で共有できている認定

仕様まで、詳細に記載しなくてもよい。

□ 仕様番号の確定作業は、仕様化の最初の段階では行わないこと。グループ分け確定後

   に行うこと。

□ 似た記述が続く場合に、何が違うかをすぐに読み取れるようにすること。

8. 追跡可能であること

 

□ 要求仕様書に記述された個々の要求に関し、その起源が明確であり、開発が進行するに

  伴って作成された文書等との対応付けがとれること。

 a)後方追跡可能性

 b)前方追跡可能性

□ 設計や実装の工程で明らかになった「仕様」は、要求仕様書に書き戻すこと。

□ 「要求」と「理由」をセットで表現すること。

□ 要求仕様には固有の記番号を付けること。

 

(参考資料: IEEE830品質特性、USDM)

 

3. 見積り問題のチェックリスト

Check List #9 見積り回答リスク回避            ▶Check Timing:見積り回答前

□ 適切な開発費と開発期間の確保ができているか。

□ リスク物件における分割見積り・分割開発・分割リリース等の交渉を行っているか。

□ 複数社体制プロジェクトにおいて、自社責任範囲を見積り回答書に明記しているか。

□ 過去の類似開発の見積り/実績データを参考にした見積りを行っているか。

□ 見積りの使用目的を確認すること。

 例;顧客要求のため、受注に直結しない参考値のため、など。

□ 口頭での依頼に対しては口頭で返し、口頭レベルの依頼・回答は一切正式なものとしては扱わず、責任も持たない旨を通告しておくこと。

□ 顧客の正式要求のものならば、要求日および妥当な回答希望日を記入した見積り依頼書を両社の正式なルートを通して、要求仕様書と共に提出していただくよう伝えること。

□ 正式要求書の場合、回答期限に間に合いそうもないと判断された場合は、その理由を明確にし、時間を置かず直ちに要求者と期限の交渉を行うこと。

 

Check List #10 見積精度向上                ▶Check Timing:見積り回答前

□ 見積り対象の仕様知識に習熟しているか。

□ 見積り対象システムのプログラム構造を理解しているか。

□ 見積り前に要求仕様の事前調査を済ませているか。

□ 既存の設計書等が不備な場合、影響範囲に絞ったソースコードの調査を行ったか。

□ 事前調査の結果をドキュメントに残したか。

□ 見積り対象仕様開発における過去の失敗リスクを把握しているか。

□ 見積り対象仕様開発に必要な技術を保有しているか。

 

Check List #11 見積り回答書                 Check Timing:見積り回答前

 

□ 見積り回答期限の事前確認は行ったか。

□ 見積り対象の仕様は明確になっているか。

□ 見積りにインプット条件は全て網羅したか。

□ 見積りにアウトプット条件は全て網羅したか。

□ 仕様の疑問点・不明点は全て顧客に確認したか。

□ 仕様変更が及ぼす影響範囲は特定したか。

□ 特別な見積り条件の要求があった場合、その考慮は行ったか。

□ 見積り範囲やリスクに関する条件を見積り回答書に記述したか。

Check List #12 概算見積り                  Check Timing:見積り回答前

□ 要求仕様の全体像を、その目的・意味・背景を含めて把握すること。

□ 自分で見積り可能なものとそうでないものを分けること。

□ 未経験項目および重要リスク項目をリストアップすること。

□ それぞれに対して、必要工数を大雑把に3段階(大・中・小)程度に分けて記入する。各段階に要する工数は、例えば、大=1ヶ月、中=2週間、小=1週間等に決めておく。重要リスクについても、もしそれが起きた場合についても同様に工数の大・小を記入しておく。自分で決められないものについては経験者や上長の意見を聞く。

□ これらの仕事を何人で実行するかを想定しておく。

□ 算出した開発期間の合計を想定人数で割ったものが想定されるスケジュール期間となる。

 

4. 相互義務不履行問題のチェックリスト

 

Check List #13 仕事の丸投げ状況           Check Timing:見積り回答前・後

□ 見積り回答内容以外の仕事を強要してはいないか。/されてはいないか。

□ 責任範疇外の仕事を強要してはいないか。/されてはいないか。

□ 過不足のない要求仕様書を提示しているか。/提示されているか。

□ 合理性・妥当性に反した開発期間・内容を強要してはいないか。/されてはいないか。

□ 合理性・妥当性に反した開発コストを強要してはいないか。/されてはいないか。

□ 仕事に関する疑問・質問に誠意をもって回答しているか。/回答を受け取っているか。

□ 相互の約束がお互いに履行されているか。

□ 優位な立場を悪用した不条理な責任転嫁が行われていないか。

 

Check List #14 仕事の丸投げに対抗するポイント    ▶Check Timing:事前準備工程

□ 顧客側の役割および職務責任を契約書等にて明確にすること。

□ ベンダー側の役割および職務責任を契約書等にて明確にすること。

□ 下請け側の役割および職務責任を契約書等にて明確にすること。

□ 統合的プロジェクト管理により全ての関係組織・会社間の役割・責任を明確にすること。

□ 上司および部下の役割および職務責任を社内規定等にて明確にすること。

□ 自分における役割および職務責任を明確に意識すること。

□ 当事者同士で解決できない場合は、さらに一段上のマネジメントに相談すること。

□ 事前準備・改善活動等による効率化を行い、時間切迫が理由の丸投げをなくすこと。

□ 改善活動等によるスキルアップを行い、能力不足が理由の丸投げをなくすとこ。

□ 丸投げ行為は職務放棄とみなし厳罰をもって臨むこと。

□ 丸投げに泣き寝入りすることなく組織的な対抗措置をとること。

 

Check List #15 チームプレーにおける相互義務の履行  ▶Check Timing:開発全工程

□ 顧客チームとベンダーチーム間の相互義務の履行および連携はできているか。

□ 同一プロジェクトに参加している他社間の相互義務の履行および連携はできているか。

□ ベンダー・顧客側においては何を開発するのかを要求仕様書等にて明示すること。

□ 請ける側においては要求に対しての実現方法を見積り回答・設計書等で明示すること。

□ 要件定義チームと開発チーム間の相互義務の履行および連携はできているか。

□ 開発チームと評価テストチーム間の相互義務の履行および連携はできているか。

□ 上司と部下の間の相互義務の履行および連携はできているか。

5. リスク回避失敗のチェックリスト

Check List #16 基本的なベンダーリスク     Check Timing:見積り時、要件定義時

□ 実現不可能な納期・開発費を強制されていないか。

□ 複数社・複数工程間の統合的なプロジェクト管理、問題情報共有が行われているか。

□ 適正な要求仕様書が妥当な時期までに提示されているか。

□ 仕様等の不明点・疑問点についての回答時期・内容は適正か。

□ ベンダー側担当者の仕様知識、技術能力、管理能力は妥当か。

□ オフショア開発に対する進捗・品質管理に問題はないか。

Check List #17 ベンダーリスクへの対応のポイント ▶Check Timing:見積り・要件定義時

□ 不条理な要求に対してデータに基づく交渉等により妥当な納期・コストの獲得を行うこと。

□ 仕様の提案や集中検討会などを通して早期の仕様凍結に全力を尽くすこと。

□ 要求仕様には必ず抜けや誤りがあるという前提を持つこと。

□ 密接なコミュニケーションを維持し、疑問点・不明点を払拭すること。

□ 契約外の要求に対しては追加期間・コストの要求を行うこと。

□ 評価時間が確保できないようなリリース直前の仕様変更要求を請けないこと。

□ 工程のスキップや中断などの不正な指示には従わないこと。

□ 開発や評価に必要な情報・機材・開発環境が適正な時期に提供されること。

□ 問題の解決にあたっては、一方的な丸投げを行うことなく、両者が協力して臨むこと。

□ ベンダー側にて不足している役割を新たな仕事として取り込む提案ができるか。

 

Check List #18 開発工程の3時点でのリスク回避

1.開発の入り口で押さえるリスク            Check Timing:見積り・要件定義時

□ 適正な見積りにて妥当な開発期間と費用を獲得すること。

□ あいまいな要求仕様の明確化および早期の仕様凍結に全力を注ぐこと。

□ 要求仕様書を常時メンテナンスし”使えるドキュメント”として残すこと。

□ QCDの数値目標の設定を行うこと。

2.開発中に押さえるリスク                         Check Timing:開発中

□ あらゆる無駄の排除とリスク項目の解消を実行すること。

□ 設計書をリアルタイムでメンテナンスし、常にプログラム内容との同一性を保持しておくこと。

□ 失敗の真因・再発防止策をドキュメントとして残すこと。

□ 創意工夫の内容を設計書やガイドラインなどのドキュメントに残すこと。

3.開発の出口で振返ること(ラップアップミーティング)     Check Timing:開発終了時

□ QCDの目標値と実績値を比較・分析し、問題の原因を数値データと共に明確にし、対策した結果をまとめておき、プロジェクト完了報告書にて他チームとも情報共有を行うこと。

□ 失敗に学ぶ。失敗あるいは創意工夫の記録を振返り、次の開発・開発者に申し送る。

 

Check List #19 プロジェクトリスク回避       ▶Check Timing:見積り・要件定義時

プロジェクトのリスクを認識し事前の対策を講じているか。

□ 見積り交渉における妥当な開発費および期間を獲得すること。

□ 要求仕様の早期凍結を行うこと。

□ 開発業務品質向上のための改善活動を実行すること。

□ リーダーによる開発仕様の全体像の把握を行うこと。

□ 開発メンバーによる開発仕様の十分な理解を行うこと。

□ 開発メンバーに対する適切な仕事の配分を行うこと。

 

Check List #20 スケジュール遅延リスク回避   Check Timing:見積り・要件定義時

□ 実行すべき内容が明確になっているか。

□ 開発に必要な期間・工数の見積りに間違いはないか。

□ 無理なスケジュールが組まれていないか。

□ 仕様凍結遅延ないしは仕様変更が多発していないか。

□ 予定目標と実績進捗は日々管理されているか。

□ リーダーにおける開発内容の全体像の把握が十分か。

□ 担当者が仕様を十分に理解しているか。

□ 担当者ごとの生産性・能力・性格を考慮した仕事の配分が行われているか。

 

6. コミュニケーション不良問題のチェックリスト

Check List #21 コミュニケーション(基礎編)   Check Timing:会議・会話の前・中・後

□ 顧客との会議に、予想される想定問答など十分な事前準備をして臨んでいるか。

□ 他人の評判だけに従って自分の行動を決めてはいないか。

□ 発言すべきか否かを、必要性によらず感情によって決めてはいないか。

□ 先に相手の話を聞くなど、丁寧なコミュニケーションを行っているか。

□ 相手の話の途中に割り込むようなことをしてはいないか。

□ 毎日、短時間でもコミュニケーションを継続することで良好な人間関係を維持しているか。

 

Check List #22 コミュニケーション(中級編)   Check Timing:会議・会話の前・中・後

□ 話をする前に、自分の中で伝えたい内容を整理しているか。

□ 伝えるべきこと、伝えてはいけないことをわきまえているか。

□ 重要な取り決めは相互の合意を文書にて残しているか。

□ 相手の話を良く聞かずに、自分の意見ばかりを話していないか。

□ 事実を伝えるよりも良く見せることに注意が傾いてはいないか。

□ 恥や外聞を恐れ、不明点・疑問点をその場で確認することを避けてはいないか。

□ 合理的かつ妥当な結論を導き出すことよりも、議論の勝ち負けにこだわってはいないか。

□ 客観的なドキュメントや数値データに基づいてコミュニケーションを行っているか。

 

Check List #23 コミュニケーション(上級編)   Check Timing:会議・会話の前・中・後

□ 相手が最も聞きたいと思われることを最初に伝えているか。

□ 相手の能力レベルに合わせた話し方をしているか。

□ 仕事の指示や依頼において、相手の理解度を確認しているか。

□ 会話を深めるに、相手との共有体験を持つことや教養の幅を広げているか。

□ 会社間の重要事項に関するコミュニケーションはリーダー対リーダーで行っているか。

 

Check List #24 顧客との会議のポイント           Check Timing:顧客会議前

□ 開発仕様の全体像の把握、仕様の目的・意味・背景を理解しておくこと。

□ 事前準備・事前検討を行い、顧客からの想定質問への答えを用意しておくこと。

□ 顧客からの宿題事項は、状況を聞かれる前に答えること。

□ 自分の言いたいことよりも顧客の話を良く聞くこと。

□ 疑問点・不明点については臆することなく、その場で確認を取ること。

□ リーダークラスにおいては、発表力やプレゼンテーション力を強化するために、普段の開発業務の中で発表やプレゼンの機会を自ら求めること。

□ リーダークラスにおいては、議事進行や調整能力を磨くために、社内会議等にて議長役や書記役を自ら買って出ること。

 

Check List #25 会議運営のポイント                 Check Timing:会議前

□ 会議の目的・背景・討議内容を事前に出席者に伝えているか。

□ 何を討議するのか事前に決めているか。

□ 何を決めるのか事前に明確にしているか。

□ 誰が・何を・いつまでに実行するのかを決めるようにしているか。

□ 不必要な人を招集してはいないか。

□ ダラダラ雑談に終了宣言を行うことができるか。

 

Check List #26 日次情報共有会議のポイント     Check Timing:情報共有会議前

□ 昨日(or今日)何を実行したかの報告を行うこと。 

□ 今日(or明日)何を実行するのかの予定報告を行うこと。 

□ 今抱えている問題や困っていることを報告すること。

□ メンバーは、事前に報告事項を日報に記入する習慣を持つこと。

□ リーダーは、各報告に対して適時のアドバイスを行うこと。

□ リーダーは、全員に共有すべき情報を伝えること。

□ 長時間を要する問題は当事者とリーダーで別途打ち合わせをすること。

 

Check List #27 レビューの基本                 Check Timing:レビュー前

□ 重要機能順(顧客価値の順)にレビューを行っているか。

□ 仕様および機能の目的・意味・背景を正しく理解しているか。

□ 必要な仕様書や設計書および資料を用意してレビューを行っているか。

□ 入力条件は正しいか、処理ロジックは正しいか、出力は正しいか。

□ パフォーマンス・レスポンスの考慮は適切か。

□ メモリーやCPU速度等のハードウェア条件の考慮は適切か。

□ 想定仕様によって開発をしている部分はないか。

□ 過去の類似の失敗例を参考にしてレビューを行っているか。

 

Check List #28 効果的なレビューのポイント          Check Timing:レビュー前

□ レビューの時間を計画的に確保しておくこと。

□ レビューは対象物の全件チェックではなく基本部のチェックに絞り込むこと。

□ レビュー対象物の一覧表を作成すること。

□ 過去のミス・不具合の傾向に基づいてレビューの重点を絞っておくこと。

□ 基幹機能に関する基本的な理解が正しいか。

□ 基幹機能の実現方法は適切か。

□ 中間レビューを行うこと。

□ 共通的なレビュー項目のひな型(チェックリスト)を作成しておくこと。

□ 仕様変更の影響部分のレビューも行うこと。

□ 担当者は、事前に自己チェックを済ませておくこと。

□ レビュワーは、担当者が見落としがちな異常系、過去の評価モレ等の広い視点を持つこ

と。

 

7. 情緒的開発姿勢のチェックリスト

Check List #29 感情本位から目的本位へ    Check Timing:モチベーション低下時

□ 自分の関心を自分自身から仕事そのものに移すこと。

□ 顧客の要求するものは何かということを良く理解し、その実現に向けて情熱を注ぐこと。

□ たとえ嫌いな相手であっても仕事に必要なことは必ず実行すること。

□ 人の好き嫌いで自分の行動を変えず、誰に対しても一貫した姿勢と行動を保つこと。

□ 過度な自己中心性を捨て、顧客要求の実現のためにチーム/メンバーに貢献すること。

 自分を害するものを減らしたければ、これらのことを実行する必要がある。

 

Check List #30 感情的・情緒的思考行動の解消      Check Timing:問題対応時

□ バグ発生に対して怒ることよりも冷静に原因追及および修復作業に努めているか。

□ 計画通りに物事が進まないことを自分やメンバーの性格のせいにしてはいないか。

□ 問題に直面した場合に合理的な判断ができているか。

□ 今までの計画に想定違いや欠陥がなかったか。

□ 計画を阻害するどのような新たな要因が発生したのか。

□ 目の前のデータや事実から原因・理由を見つけて新たな対策を打つこと。

 

Check List #31 目標設定                     Check Timing:開発着手前

□ 仕事をこなすだけで、目標の設定は不要だと思っていないか。

□ 現実的で達成可能なQCDの目標値を設定しているか。

□ 目標は測定可能な数値で表されているか。

□ 目標は過去の実績を基準に設定されているか。

□ 目標達成のための具体的な手段を持っているか。

□ 目標値は実行手段に見合った数値になっているか。

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

 

Check List #32 モチベーション           Check Timing:モチベーション低下時

□ 仕事の意味を理解せずに形式的にこなすだけになってはいないか。

□ 単純作業にも創意工夫を働かせているか。

□ 意味や背景を考えて仕事をしているか。

□ 言われたから仕方なくやると言うような、やらされ感的な仕事になってはいないか。

□ QCDの数値目標を持って、惰性に流されない仕事を行っているか。

□ 仕事の量や質の全体を把握することで出口(完了時期)が見えるようにしているか。

□ 業務中に頻繁にまたは長時間にわたって私的行為をしている者に警告しているか。

□ 失敗やミスの原因を明確にし、歯止め対策を講じているか。

□ やる気のない者と同じ行動をしてはいないか。

□ 自分自身や他人を過剰にあるいは過少に評価してはいないか。

□ 個人に対して卑下あるいは侮辱などの行為をしてはいないか。

□ 他人より多いあるいは少ないという比較だけにこだわってはいないか。

 

Check List #33 仕事への取組み姿勢       Check Timing:モチベーション低下時

□ 好き嫌いという情緒的な姿勢で仕事をしてはいないか。

□ 義務感を超えた誠実さをもって仕事に取り組んでいるか。

□ 仕事内容の意味や背景を知るために、“なぜ。”の問いかけを行っているか。

□ 事前準備・事前調査を行っているか。

□ 放置している案件がないか。

□ 複数の仕事を並列的に進める工夫をしているか。

□ 優先度を判断して仕事を進めているか。

□ データやドキュメントに拠る合理性に基づいた仕事を行っているか。

□ 人々の納得が得られるような妥当性のある仕事を行っているか。

□ 残務を先送りにしてはいないか。

□ 顧客からの電話に居留守を使うことはないか。

Check List #34 困難な仕事への対応       Check Timing:モチベーション低下時

□ 自分で対策を考えずに、他人に解決策を頼ってはいないか。

□ 消極的ないしは逃避的姿勢になっていないか。

□ 何が困難で不安なのかを具体的にリストアップしてみたか。

□ 事前の学習をしているか。

□ 事前準備をしているか。

□ 仲間との連携を検討しているか。

□ 条件付行動を選択しているか。

□ オール・オア・ナッシング思考をやめ、合理的かつ妥当性のある行動を選択しているか。

□ チームでリスク解消に取り組んでいるか。

□ チーム内で責任分散を行っているか。

 

9. 本質把握ミスのチェックリスト

 

Check List #35 本質を見抜く                  Check Timing:問題検討時

□ 自分の目で観察したか。

□ 自分の頭で考え、判断したか。

□ 複数の情報にあたってみたか。

□ 見聞を深める行動をしているか。

 

Check List #36 思い込み解消                  Check Timing:問題検討時

□ 湧いた疑問に対して、何故。の問いかけをしているか。

□ 根拠となる事実や定義に従って、原典を確認した開発行動を実行しているか。

□ 変更の影響度を確認した上で仕様変更を行っているか。

□ 常識に照らし合わせた理解や判断を行っているか。

□ 仕様変更、日程変更等の重要情報は、原本配布/直接対話で伝えているか。

□ 複雑な問題に対して、複数の解決策を比較検討しているか。

 

Check List #37 誤解を避ける                  Check Timing:問題検討時

□ 文書によらず口頭のみの情報で仕事をしている場合がないか。

□ 数値や論理記号に乏しいあいまいな日本語記述の文書を使っていないか。

□ 勝手な想定ではなく、定義されたドキュメントに基づいた開発を行っているか。

□ 仕様の目的・意味・背景を知った上で開発を行っているか。

□ 全体的視野、顧客の視点で問題を考えているか。

□ 他者の視点で考えてみたか。

 

Check List #38 不明な問題を解く                Check Timing:問題検討時

(数学の考え方17か条、秋山仁)

□ 分類や整理をしてみたか。

□ 図や表にしてみたか。

□ 簡単な模型を作ってみたか。

□ 基準をそろえたか。

□ 数学やロジックの言葉で表してみたか。

□ 小さな例で試してみたか。

□ 難しい問題は分割して考えてみたか。

□ 必要条件で絞り込んでみたか。

□ 特定の要素に注目してみたか。

□ 視点を変えてみたか。

□ 逆に考えてみたか。

□ 操作は1つずつ片付けてみたか。

□ 知っている事実を活用してみたか。

□ 規則性を探してみたか。

□ 対応をつけて考えてみたか。

□ 自然からヒントを得てみたか。

□ 部分から全体を把握してみたか。

 

10. 優先順位問題のチェックリスト

 

Check List #39 優先順位の設定                Check Timing:作業着手前 

□ 仕事の意味・意図・背景を最初の時点で正確に把握すること。

□ 仕事内容をブレークダウンすること。

□ ブレークダウンした仕事内容に優先順位を設定すること。

□ タイムリミットが直近に迫っているものから処理をすること。

□ 時間的余裕があるものは重要機能の順に処理すること。

□ 優先順位が判断できない場合は早めに上長に相談すること。

□ この仕事に許される自分の残り時間を毎日意識すること。

 

Check List #40 仕事の優先順位認識             Check Timing:作業着手前

□ QCD(品質、コスト、納期)の優先順位は同一であることを理解しているか。

□ 標準的なプロセスで定義されている作業は全て必須であることを理解しているか。

  *仕様の不明点・疑問点の事前調査や各工程のレビュー等は必須業務である。

□ 顧客や上司からの要求が常に第一優先とは限らないという認識を持っているか。

□ 自分の責任範囲を超える優先順位の変更は上司の承認を得ているか。

□ 要求内容の優先順位を顧客に確認しているか。

□ タイムリミットが迫っているものを第一優先にしているか。

□ 顧客価値の重要度順で仕事を進めているか。

□ 緊急度・優先度の決定にあたって、要求者あるいは指示者との調整ができているか。

□ 中断された仕事について、再開に必要な事項のメモを残しているか。

□ 割り込み作業は必ず発生するという認識で、作業の前倒しを行っているか。

 

Check List #41 割り込み作業対応               Check Timing:作業着手前

□ 全ての工程において、割り込み作業や不測の問題は必ず発生するという認識を持つこと。

□ 顧客との会話を絶やさず、早い時点での割り込み要求情報をキャッチすること。

□ 全ての工程のスケジューリングは必ずバッファを持たせること。

□ バッファを確保するために、常に業務の改善や効率化を行うこと。

□ その場で内容を聞く余裕がまったくない場合は後刻の時間を指定して後で聞くこと。

□ 現状の仕事と割り込みの仕事についてチーム全体としての優先順位を考え、緊急度・重要度の高いものを優先させること。

□ 割り込みにて中断された作業については、中断情報を記録しておき再開に備えること。

□ 自分の担当業務に割り込ませることが不可能と判断した場合は、他の人に割り振ることや他の代替案を示すこと。

□ 割り込み対応が全く不可能な場合や開発工程の後半での仕様の追加および変更は、次回リリースにしていただくように交渉すること。

 

11. ドキュメント・ベース開発欠如のチェックリスト

 

Check List #42 ドキュメント・ベース開発の遂行     Check Timing:各工程開始前

□ 基本部の要求仕様書は、見積り時に提示されること。

□ 詳細要求仕様書は妥当な時期までに凍結されること。

□ 要求仕様書に基づいて基本設計書が作成されること。

□ 基本設計書に基づいて詳細設計書が作成されること。

□ 詳細設計書に基づいてプログラム作成が行われること。

□ 詳細設計書に基づいて単体テストチェックリストが作成されること。

□ 単体テストチェックリストに基づいて単体テストが行われること。

□ 基本設計書に基づいて結合テストチェックリストが作成されること。

□ 結合テストチェックリストに基づいて結合テストが行われること。

□ 要求仕様書・実運用シナリオ資料に基づいて総合テストが行われること。

Check List #43 ドキュメント更新             Check Timing:変更・修正発生時

□ 仕様調査時のQ&A資料の内容は都度、設計書等に反映すること。

□ 仕様書・設計書等は、テスト等での不具合修正の都度、更新すること。

□ 仕様書・設計書等は、欠陥が発見された都度、更新すること。

□ 仕様書・設計書等は、派生開発の都度、更新すること。

□ ソフトウェア構造設計書は、派生開発の都度、明確になった部分を更新すること。

□ 仕様変更影響度表は、仕様調査情報および評価テスト情報に基づき更新すること。

 

Check List #44 ドキュメント・ベース業務の遂行    Check Timing:決定事項発生時

□ 顧客会議/連絡における依頼・指示・決定内容は議事録にて管理されているか。

□ 関係各社との会議/連絡における依頼・決定内容は議事録等にて管理されているか。

□ 社内会議/連絡における依頼・決定内容は議事録等にて管理されているか。

□ 顧客・ベンダーからの仕様変更は、仕様変更管理表にて管理されているか。

□ 依頼・指示・決定内容等は、「誰が、何を、いつまでに、どのように」が明記されているか。

Check List #45 ドキュメントの見える化のポイント  Check Timing:ドキュメント作成時

□ 書類の品質の均一性保持のために、統一的にフォーマット化すること。

□ 仕様や機能の目的・背景・意味を記述すること。

□ 論理記号、数学的表記、図・表・フローチャート等を使用し、論理的な記述をすること。

□ 複雑な事象表現にマトリクス図や共通パターン表などを使用すること。

□ 異常系処理を記述すること。

□ 重複を避け、シンプルな記述にすること。

□ パフォーマンス・レスポンス条件を記述すること。

□ 仕様変更による修正影響度表を作成すること。

□ 誤記、抜けおよび変更は発見・発生と同時に更新すること。

□ 開発ドキュメント内容とプログラムコードは、常時一対一で整合性を保つこと。

□ 複数の仕様書間、設計書間の矛盾した記述をなくすこと。

Check List #46 業務文書作成のポイント        Check Timing:業務文書作成前

【準備】

□ 書く前に、相手に伝えたいことを重要なもの順にメモに書き出しておくこと。

【受け取る側の利益・心情を優先】

□ 最初に結論の記述から始めること。相手の要望や疑問にまず答えること。

□ 自分の言いたいことを優先しないこと。特に不始末の詫び状などでは言い訳から記述を始めるのは禁物。

【分かりやすさ】

□ 報告書は基本的に最初の1ページで全貌が分かるように書くこと。

□ 文章の主題・件名と本文の内容を合致させること。

□ 結論に始まり、続いてその経緯について簡略にまとめること。

  どんなに長い内容でも本文は1~2ページにまとめ、詳細内容は添付資料とすること。

□ 文章は重要なものの順に書くこと。

□ 一つの文章はできるだけ短くすること。複雑な内容は複数の文章に区切って書くこと。

□ 箇条書き等によって簡潔な表現に努めること。

□ 同じ内容を、形を変えて何度も繰り返さないこと。

□ 重要な事とそうでないことを峻別すること。

【正確性の確保】

□ 「誰が、何を、いつまでに、どのように、どれくらい」等が明確に記述されているか。

□ 数値やデータによって質や量を表現することで、文書の客観性が保たれているか。

□ あいまい表現はしない。例えば、”非常に”とか”おおよそ”などの表現は厳禁。

□ 文章だけで説明が難しいものは、マトリクス・図・表などを使用すること。

□ 技術用語は、顧客・プロジェクト・社内で統一用語を使用すること。

 

12. 実務能力問題のチェックリスト

 

Check List #47 ソフトウェア開発チームに必要な能力   Check Timing:開発着手前

□ チームにおける日常的で密な直接コミュニケーション力

□ ドキュメントの常備はもとよりちゃんと動作するソフトウェアの素早い開発力

□ 顧客との日々の直接コミュニケーションによる協調

□ 変更要求に対する俊敏な対応力

□ 顧客価値優先度の把握力

□ 意欲ある人材で構成されたプロジェクト構築力

□ 短期開発力

□ 一定のペースを持続できる開発力

□ 技術的な優位性の保持、良好な設計力の保持

□ 無駄・不要な仕事の削減力

□ 自律的チーム力

□ 定期的・効果的振り返りによる行動の変更・調節力