Ver. 1.0 提供：（株）システムクリエイツ
これは、ソフトウェアの開発組織が、どのような問題を抱えているかを判断するためのチェック・リストです。それぞれの質問項目に“該当”する場合は、チェック・ボックス「□」を塗りつぶしてください。判定しにくい状況もあるかと思いますが、はっきりと“該当する”ことを判定の規準にして下さい。
□ 達成すべき“要求”を明確にしたドキュメントが存在しない
（あったとしても、“・・・したい”という実現の裏付けのない「要求」のリストだけ）
□ 「要求」について、顧客（発注者）と入念に打ちあわせることをしていない
□ 仕様が決まらないまま、“暫定仕様”で作業が進められ、あとで手直しとなることが多い
□ 「要求仕様書」に対して、承認の為のレビュー（インスペクション）が実施されたことはない
□ いわゆる「製品仕様書」と呼ばれるものから直ぐに設計作業にとりかかる
□ 要求（あるいは“仕様”）は、途中でしばしば変更されたり、追加される
□ 個々の“要求”にユニークな番号が割り付けられていない
□ 依頼者からの要求の変更は、特に協議する「場」がなく、何時でも受け付けられる
□ テスト段階に入って「要求」に対する食い違いがしばしば発見される
□ 期日（納期）を延長するとき、新しい機能の追加を伴うことが多い
該当項目数・・・・（ ）／１０ ・・（ ）％
□ プロジェクトの計画書と呼べるものは存在しない
□ ドキュメントなどの成果物の「量」の見積もりが行なわれていない
□ 適切な単位で、作業量の見積もりが行なわれていない
□ “約束するための”作業の詳細なスケジュールが存在しない
（あるのは、実態を反映しない大雑把なスケジュールだけである）
□ スケジュールは、一度決められたら、実際と大きく食い違っても、書き直されることはない
□ 実行不可能なスケジュールが強要される
（結果として、“建て前”としてのスケジュールとなる）
□ 担当範囲の「量」や「難易度」が、担当者によってばらつきが大きい
□ 期日（納期）は、間近になって二回以上延長される
該当項目数・・・・（ ）／８ ・・（ ）％
□今の 開発組織の数年後の「姿」が描かれていない
□ 組織として、今現在、要員に対して技術的な教育・訓練が行なわれていない
□ 要員に対する教育・訓練の計画や見通しが立てられていない
□ 技術の習得は個人任せで、組織として「方向」が打出されていない
□ 開発要員の所有する“文献”の数は、平均して１冊以下である
（“文献”には、言語等の“実用書”は含まない）
□ 構造化手法という、分析・設計手法を習得している人はいない
□ オブジェクト指向という、分析・設計手法を習得している人はいない
□ 休憩時間などで、新しい技法などが話題にならない
□ “ソフトウェア・エンジニアリング”という言葉の意味を知らない
□ 「凝集度」、「結合度」という言葉の意味を知らない
□ 「McCabe の複雑さの尺度」を知らない
□ “品質特性”を５個以上言えない
該当項目数・・・・（ ）／１２ ・・（ ）％
□ マネージャー（管理者）が、“以前と同じ”開発業務を分担している
（プレーイング・マネージャーを除く）
□ 明確に「チーム」という行動単位は存在しない
□ 「チーム」という呼び名はあっても、作業の連携を意識することはなく分担に専念する
□ 「チーム」の中で作業の遅れがちな人に対して、皆でカバーすることはない
□ 仕事の依頼（または要請）は、経験に基づいて直接“個人”に対して出される
□ プロジェクトの最後に、まとめの報告書が要求されない
□ プログラムのバグ等の不具合の本当の原因を追及したことがない
□ お互いの成果物を見せあって、技術を向上させようという意識がない
□ 難しい問題（バグなど）が解決されたときに、その方法などがメンバーに公表されない
□ 組織の全員が開発作業に専念していて、“プロセス”などを考える人もグループもいない
□ １日の全ての時間が目の前（当面）の開発業務に投入されている
□ 残業時簡が月１００Ｈ（以上）の状態が３ヶ月以上続いている
該当項目数・・・・（ ）／１２ ・・（ ）％
□ 開発作業の「標準作業手順（フロー）」と呼べるものが存在しない
□ 要求仕様書の「書式標準」と呼べるものが存在しない
□ 設計書の「書式標準」と呼べるものが存在しない
□ 設計書と呼ばれているものは、実は関数のＩ／Ｆを定義した「関数仕様書」である
□ 「要求」から「ソース・コード」に導くための「設計書」が存在しない
□ 設計段階において、「レビュー」と呼べるものは殆ど行なわれていない
□ 設計レビューが、１時間で終わることはない。
□ ソースコードを対象にしたレビュー（コード・インスペクション）が行なわれたことがない
□ 現在ある設計書とソースとは内容は一致しない
□ 担当者への作業の分割は、よく検討されないまま早い段階で行なわれる
□ 途中で仕様が変更されたとき、その影響範囲を特定する方法がなく、担当者に任されている
□ コーディングとテストに開発期間の半分以上の時間が投入されている
□ 事前に十分な単体テストが行なわれないまま、全体を結合してテストを開始する
□ 問題が最後まで隠れていて最後にまとめて噴き出す
□ 問題が常に先送りされ、抜き差しならない状態で作業が着手される
□ 過去の過ちから学ばないために同じ種類の問題（バグ）が何度も繰り返される
□ テスト専任者がいないため、納品前ののテストも開発者自身で行なわれている
□ 要求に対して適切なテスト項目が確立していない
□ テストが殆ど自動化されていない
□ 「プロセス」の改善について、相談する人がいない
該当項目数・・・・（ ）／２０ ・・（ ）％
□ 潜在していたバグが発見されたとき、既成のモデルの影響範囲を特定するのが難しい
□ プログラムのバグの修正個所の特定や修正方法は、担当者に任されていて公表されることはない
□ プログラムのバグの修正によって新たなバグを作ることが多い
□ ソースプログラムは、何時の時点も制作者（担当者）の手元にあり自由に変更できる
□ 開発期間中に、制作途中の文書やプログラムを定期的にバックアップしていない
□ リソースのバックアップ、および、非常時の再開方法が確立していない
□ 要求仕様書や設計書などの公式ドキュメントを“承認”する手続きがない
□ ドキュメント類は、最初に書かれたままで、途中で仕様が変わっても変更されることはない
□ 途中で仕様を変更した“理由”が、後になって思い出せなくて困ったことがある。
□個々の バグや仕様変更に対して、プログラムの何処を修正したかを追跡することが出来ない
□ 開発環境のディレクトリにある古いソースを消してよいかどうか判断できない
□ 間違えて、古いオブジェクトをリンクしてしまうことがある
該当項目数・・・・（ ）／１２ ・・（ ）％
□ システムの中に、アセンブラ言語に依存する部分が３割以上ある
□ ソース・プログラムを生成・翻訳する以外に、ツールと呼べるものは使われていない
□ 「Ｃ」言語以上の言語であっても、「フラグ」と呼ばれるデータが非常に多く使われている
□ システムが適切なリアルタイム・モニターの下で作動していない
□ リアルタイム・モニターを導入しているが、それを使うノウハウを特に意識したことはない
□ 届けられた電子メールに対応するのが後回しになりがちである
□ 電子メールの応対が煩わしく感じる
□ 届けられた電子メールに対して意見（異見）があるときだけリプライする
該当項目数・・・・（ ）／８ ・・（ ）％
結果は如何だったでしょうか？ それぞれのカテゴリで該当項目数が過半数を越えるようでは、“要注意”ですし、ほとんど（８割以上）該当するようでは、２１世紀に向けて、製品やソフトウェアの開発を通して、社会に貢献するためのプランを根底から練り直していただかないと、今のままでは開発組織の存続は難しいと考えられます。
そのような中期的に明確なビジョンも無い状態のままで、その場凌ぎで「外注」を使ったとしても、一時的な延命行為に過ぎず、組織の改善には繋がらないでしょう。逆に“あるべき姿”からますます遠ざかってしまう危険があります。
“今日までやってきた”という「事実」だけでは、“明日もやっていける”保証にはならない時代であることを認識していただく必要があります。
このような私の心配が「取り越し苦労」となるほど、現実は甘くないと思って下さい。