はじめに
　フレデリック・ブルックスの、「銀の弾丸などはない」と言う言葉はあまりにも有名です。これはソフトウェア開発にともなう様々な問題の解決には、特効薬などはなく科学的な根拠に裏打ちされた持続的で根気強い改善努力が必要であるという警句です。
　ソフトウェア開発の現場で発生している問題は多種多様にわたっており、一個人、一組織の知力で対抗するにはあまりにも巨大すぎ、これら全ての問題を一挙に解決してくれる特効薬はありません。
　銀の弾丸がないかと言えば、ないとも言えません。それは我々の身近な日々の開発生活の中にころがっている我々の経験則に求めることができます。多くの経験則は一般的には明文化されず、個人の記憶の中に内在している暗黙知として存在しています。これらが明文化され組織的に運用されれば、銀の弾丸となり、狼男や悪魔的なバグなどを激減させることが可能になるのかも知れません。
　経験則を明文化するためには、現場で発生している多種多様な問題のパターン化および構造化が必要であり、それらは最終的にはチェックリストという形で提示される必要があります。

▶チェックリストの有効性について
　ソフトウェア開発のリスク回避手段の代表的なものとしてリスク管理表がありますが、その作成・運用の実態は非常に貧弱なものでしょう。リスク管理表へのリスク項目の登録にあたって行われていることは、プロマネ自身の経験における記憶から抽出されたリスクやチームメンバーから出された意見などに基づいたものがほとんどでしょう。リスク管理表なるものがあればまだよい方で、リスク管理表そのものが存在しないプロジェクトも少なくありません。
　リスク管理表の最大の問題点は、膨大なリスクの中でとりあげるべきリスク項目を何にして良いのか分からないという点にあります。一般的には、人・もの・金・ＱＣＤ・情報などを切り口にしてリスク項目の抽出を行うことになりますが、プロマネ個人の能力や経験に依存する限り効果的なリスク管理表を作成することはできないでしょう。
　組織的活動におけるリスクの「基準点」は、個人に求めるのではなく、組織に求めるべきであり、組織におけるリスクの「基準点」とは、組織が蓄積した「過去の失敗事例」に他なりません。　過去の失敗事例は、その原因ごとにパターン化することが可能で、パターン化できるということはチェックリスト化できるということです。さらにこれらのチェックリストは、その因果関係を分析することで構造化が可能となります。構造が明確になれば、何が基本的なリスクか、すなわちキーリスクは何かが明白になります。これらの構造化されたチェックリスト群は、リスクの網羅性を高め、さらに短時間でのリスク抽出を可能にし、リスクのモレを防止するでしょう。
　経験則によればキーリスクは、要求仕様問題、見積り問題およびコミュニケーション問題の三点にあることが明らかです。　これらの問題は開発の時系列の流れに沿って階層構造を形成しており、初期階層での不手際は、次の階層問題を引き起こし、初期階層から最終階層に向けて問題は拡大していき、まさに失敗パターンのトリクルダウンが起きてしまいます。
 
▶問題の１７パターンおよびその原因
　ソフトウェア開発における問題のパターンおよびそれぞれのリスク原因を以下にしまします。

問題のパターン／リスク原因
①不条理な顧客要求⇒ □決まらない要求仕様 □短納期・低コスト要求
②見積り問題 ⇒□不十分な仕様調査・仕様理解 □見積り交渉力の弱さ
③相互義務の不履行⇒ □プロジェクト統合管理の不在　□説明責任の欠如（丸投げ） □情報共有の不足
④リスク回避の失敗⇒ □仕様決定遅れ □短納期
⑤コミュニケーション不良⇒ □顧客・開発チーム間の意思疎通・情報共有の不良　□チーム内の意思疎通・情報共有の不良
⑥情緒的開発姿勢⇒ □感情的・情緒的な思考・行動 □数値目標の不在
⑦モチベーション問題⇒ □モチベーションの低下
⑧本質の把握ミス⇒  □自分の頭で考えない自律性の未熟さ
⑨優先順位問題⇒  □割り込み作業等の優先度判断の誤り
　□必須業務に優先順位はないという認識の欠如
　□納期第一優先という誤り。
⑩ドキュメントベース開発の欠如
　□開発行為の科学的根拠（ベースライン）の喪失
　□低品質なドキュメントが招くＱＣＤの失敗
　□文書化能力の低下
⑪実務能力問題 ⇒□業務知識不足（技術、仕様、システム構造、評価テスト）　□仕様決定能力の低さ □設計・製造能力の低さ
⑫リーダーシップ問題⇒ □マネジメントなきプロジェクト管理
⑬チームプレー問題 ⇒□相互義務の不履行 □相互扶助の不在
⑭手抜き問題⇒  □必要工程の中断ないしはスキップ
⑮時間認識問題⇒  □仕様凍結期限意識の欠如
　□期限・タイミング意識の欠如
　□許容時間・必要時間認識の欠如
⑯ノウハウ継承／人材育成問題
　□個人のスキル向上の疎外 □　組織能力向上の疎外
　□プロジェクトＱＣＤ達成能力の低下
⑰学習能力の欠如問題⇒ □失敗に学ばない
　□振り返り（ラップアップ）の未実行 □改善活動の未実行
 
▶本書の構成と有効な使い方
　第１章においては、ソフトウェア開発の全てを網羅した包括的なチェックリストを、そのチェックタイミングとともに示しました。　第２章以降においては、冒頭にて、「First Point」としてその章の全体像および要旨を示し、続いて、パターン化された問題の因果関係の時系列順に、それらの問題を予防するための個別のチェックリストを記載し、章末には、「Last Point」としてその章のまとめを示しました。また各章におけるチェックリストの理解を助ける目的で適時「コラム」欄において若干の解説を加えました。
　本書において提示されたチェックリストは致命的な手順抜けの予防を目的としたもので、いわゆる業務マニュアルや手順書を意図したものではありません。　これらのチェックリストは、読者の所属組織やプロジェクトの実情に応じて追加・改変して使用されることが望まれます。

本書の有効な使い方
□はじめに一通り全体を通して読む。
□目次の中で自分が抱えている問題から先に読む。
□チェックリストに○×△印をつけ、現状のレベルおよび課題を知る。
□各章の冒頭のFirst Pointおよび末尾のLast Pointに注目して読む。
□巻末に記載したチェックタイミング時系列順Check List一覧に沿って読む。
□気づいたことや自分の意見などをメモとして書き残し実践につなげる。

　以降、本文においては、問題の１７のパターンの順に、それぞれのキーリスクで構成されたチェックリストを示すことにします。

 
１．ソフトウェア開発リスクの全体像

Point：複雑な問題の解決にはチェックリストを
□　チェックリストは、開発問題の解消に有効である。
□　チェックリストは、その行動前のタイミングに用いることでのみ有効となる。
□　チェックリストは、失敗リスク回避の強力なツールである。

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

　それぞれのチェックリストの確認は、ある行動に着手する直前に行うことで効果が発揮されます。この確認のタイミング（Check Timing）は一時停止点（Pause Point）とも呼ばれており、物事を開始する前のリスク排除の重要な働きを持っています。
　どのような行動においても、それを無事に遂行するためには、事前にその行動の重要なポイントを一度立ち止まって冷静に見るという「静」の時間が理性や合理性を働かせる重要な働きをします。この「静」と実際の行動における「動」が相まって、人間行動の過ちを防ぐ働きをしています。

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

【見積り回答前】　◀　Check Timing
□　要求仕様の骨子が決定され明確に書面にて提示されていること。
□　見積り回答書の内容は、要求仕様骨子の実現に見合った開発期間・開発費になっていること。
□　見積り回答書には、明確な要求仕様に対してのみ見積られ、不明なものは見積りに含まれていないことを明記すること。
□　見積り回答書に、開発に必要な実行条件がある場合、その条件を明記すること。

【設計着手前】　◀　Check Timing
□　すべての要求仕様が決定され、明確に書面にて提示されていること。
□　全ての要求仕様に関して、全ての不明点および疑問点が払拭されていること。

【製造着手前】　◀　Check Timing
□　基本設計が完了され、基本設計書として明確に書面にて提示されていること。
□　詳細設計が完了され、詳細設計書として明確に書面にて提示されていること。
□　全ての設計書に関して、全ての不明点および疑問点が払拭されていること。

【単体テスト前】　◀　Check Timing
□　単体テスト試験書が作成済であること。
□　テスト対象機能のコーディングが全て完了していること。

【結合テスト前】　◀　Check Timing
□　結合テスト試験書が作成済であること。
□　テスト対象機能の単体テストが全て完了していること。

【総合テスト前】　◀　Check Timing
□　総合テスト試験書ないしは運用（シナリオ）テスト試験書が作成済であること。
□　総合テスト対象機能の単体・結合テストが全て完了していること。

【成果物リーリース前】　◀　Check Timing
□　全ての機能が要求仕様通り、システムとして実運用を満たしていることが確認されていること。
□　発見済で未修正の不具合が残存していないこと。
 
Check List ＃２　プロジェクトを成功させるための基本条件▶Check Timing：開発準備時
【統合管理】
□　元請けベンダーないしはコアとなる組織を中心とした統合的プロジェクト管理を行うこと。
□　適切なプロジェクト・マネジメント能力を発揮すること。

【コミュニケーション】
□　プロジェクト傘下の全組織および全会社間の密接なコミュニケーションを行うこと。
□　日次情報共有会議によるチーム内での情報共有を行うこと。

【要求仕様】
□　主要な基本的仕様を適切な時期までに凍結させること。

【リソースの確保】
□　見積り交渉において、開発内容に見合った工期・予算を確保すること。
□　顧客システムおよびその運用業務に精通していること。
□　開発規模および難易度に応じた開発体制を構築すること。

【開発】
□　顧客価値の重要度順の仕様凍結ならびに開発を行うこと。
□　ドキュメントに基づいた開発を行うこと。
□　データに基づく開発を行うこと。
□　開発効率化・失敗の再発防止のために普段の改善活動を行うこと。

全ページをご覧になりたいかたは有料マガジンからどうぞ。