Checklist For Successful Software Projects Japanese

Successful Software Projects Checklist
ソフトウェア・プロジェクト成功のためのチェックリスト
Confidentiality Statement
機密性に関する声明
This Successful Software Projects Checklists along with all attachments hereto shall be considered
<company>’s Proprietary/Confidential Information
この「ソフトウェア・プロジェクト成功のためのチェックリスト」とすべての付属資料は、○○社の所有情報および機
密情報である。
ProjectManagement.com Successful Software Projects Checklist
この資料の利用にあたって－ビジネス上の利益
"If you fail to plan, you plan to fail."

「計画無くして、成功なし」
ソフトウェア・プロジェクトを管理することは、最も状況が良いときですら難しい。不幸なことに、多くの新任プ
ロジェクト・マネジャーは実質的に何のトレーニングも受けない。諸々の準備が整い、かつソフトウェア開発
の成功につながるチェックリストで周到な計画を立てたとき、プロジェクトはほとんど成功したも同然だ。
ソフトウェア・プロジェクトの成功に向けた簡易ガイドラインとして（一般的なソフトウェア開発で気にすべき
こと、プロジェクト計画、プロジェクトの開始、プロジェクトのキックオフからプロジェクトの終結までカバーし
ている）、以下のチェックリストを活用しよう。プロジェクトマネジメントの問題における「特効薬」ではないこ
と認識しつつ、次のプロジェクトにおいてはこれらの提言を心に留めておこう。適切だと思ったものはリスト
に加えても良い。
一般項目
ソフトウェア開発計画を作成し、その計画を守っているか
ソフトウェア開発計画ではプロジェクト構想が示され、チーム構成と開発手法が定義される。計画に
は見積もり、主要なマイルストーン、進捗を管理するためのその他の手法が含まれていなければな
らない。ソフトウェア開発計画は「生きている（随時更新される）」資料であるべきであり、すなわち主
要な各フェーズや段階の終了のタイミングで更新される。
必須となるプロジェクトマネジメント活動を適用しているか
トラブルに陥る多くのプロジェクトは、コスト見積もり、プロジェクト・スケジューリング、資源計画、コ
ンフィギュレーション・マネジメント、そして先を見越したリスク・マネジメントといった実績のあるプロ
ジェクトマネジメントの領域を適用していない。そうしてその後、なぜそれらのプロジェクトが常に混
乱の中にあるのか、と悩むのである。それは当然の結果だ。
すべての人たち（プロジェクト・マネジャーおよび上位マネジメント層）は現実的か、そしてプロジェク
トに対する合理的な期待を持っているか
何人かのマネジャーは自分のプロジェクトにおいて、問題が起こりうる領域でのマイナスの影響の可
能性を認識している。しかしながら彼らは、問題はうまく解決するだろう、という彼らが見たい見方で
ものごとを見ることを選択する。たとえ入手したすべての兆候がそうでないことを示していてもだ。
要求事項のベースラインを定義し、その変更に対する管理をしているか
要求事項をできるだけ早く固定化しよう。変更の可能性のある要求事項や不明確な要求事項の詳
細リストを管理し、見積もりコストやスケジュールへの影響度によって優先度をつけよう。それらの項
目をアーキテクチャーか、少なくとも詳細設計の期間内に解決するように心掛けよう。
効果的なソフトウェア・プロセスを実施したか
多くのプロジェクトでは効果的なソフトウェア・プロセスを実施していない。それはプロセス適用のア
プローチにおいてバランスが取れていないためである。最低限のプロセスだけを適用し、後はスタッ
フの経験に頼る場合や、グローバル・プロセスへの厳格な適合を強要する場合もある。
©2017 ProjectManagement.com 2
十分なプロジェクトマネジメント・リーダーシップを持っているか
ソフトウェア・プロジェクトの管理には、将来の大惨事を回避するために目の前にある困難に立ち向
かう意思のある情熱的な人材が必要である。問題のある次の 2 つのタイプのマネジャーに気を付け
よう。ソフトウェア開発の経験はあるがマネジメント経験のない人、そしてマネジメント経験はあるが
ソフトウェア開発経験のない人である。両タイプともに、技術的、そしてマネジメント的ノウハウについ
て、必要な調和が欠けている。
適切なタイミングで判断を行っているか
マネジャーの中には、急を要する判断を手遅れになるまで避ける人がいる。差し迫った問題に関し
て、非常に危険な兆候を目の前にしても、である。
先を見越したリスク・マネジメントをしているか
多くのプロジェクトにおいてリスク・マネジメントを実施するように求められるが、効果的に導入して
いる例は殆どない。どの程度うまく失敗を食い止めることができているだろうか。
プロジェクト成功のために必要な文書の量を決めたか
プロジェクトによって異なる種類の文書が要求される。プロジェクトの規模、スケジュール、そしてシ
ステムの予想耐用期間に応じて、必要となる文書の量と種類を決めよう。
コスト削減やスケジュール縮小のために標準が緩和されていないか確認したか
標準を緩和することは、プロジェクトにおける間違いを発生させやすくする。そして最適なプロジェク
ト・コストとスケジュールはともに間違いを取り除けるかによって決まる。さらに、基準を緩めること
は、意欲を削ぐ効果を発生させる可能性がある。ほとんどの開発者は品質志向であるため、基準の
緩和は顧客や上位マネジメント層が品質を気にしていない、というメッセージを送ることになる。
フェーズ途中でのスケジュール遅延を、あとで取り戻せると思わないようにしたか
プロジェクトにおけるフェーズが始めから終わりに進むにつれて生産性が向上する、という思い込み
は、一般的な間違いの 1 つである。生産性はわずかに向上するかもしれないが、どのフェーズにおい
ても時間を取り戻すだけの十分な余裕はない。
非合理的なゴールを設定しないようにしたか
非合理的なゴールを設定することは、まったくゴールを設定しないことよりも悪い。チームがその
ゴールを信じられなければ、彼らはただ時間を費やし、タイム・レコーダーに記録し、家に帰るだろう。
もし彼らが急かされれば初めの段階でミスを犯し、それが後になって修正のための莫大な費用を発
生させるだろう。合理的で適度に困難なゴールを設定しよう。そうすることで、チームはプロジェクト
の効率を損なうことなく、ゴールを達成するために能力を働かせることだろう。
変更を実施するときにその影響を査定し、変更管理委員会の承認を得たか
各変更の影響を見積もろう。それはスケジュールの見直しなくプロジェクト内で吸収できる小さな変
更のときでさえ重要である。プロジェクトでは大規模、小規模問わず、どのように変更が実施されて
きたか、過去からの記録が必要だ。個別の変更が大きな影響を与えないとしても、もし管理していな
ければ小さな変更が徐々に積み重なり、最終的にはコストとスケジュールの超過をもたらす。
成功を祝うのが早すぎないか
納期通りに製品を納品しなければならないというプレッシャーは、しばしばマネジャーの早まった完
了宣言を引き起こす。製品が契約上の品質と信頼性を兼ね備えた状態で完成するまで、成功宣言
はありえない。
要求事項管理
要求事項は十分で、完全で、一意的に識別可能で、明瞭で、適切に優先付けされているか。
要求事項の間で内部的な矛盾はないか。
一連の要求事項は、すべての妥当な例外と境界条件に対して、きちんと対処しているか。
要求事項は実現可能か。すなわち、一連の要求事項に対する解決方法が存在するか。
要求事項は既知の制約内で実行可能か。
他の要求事項とのすべての相互参照は正しいか。
すべての機能要求事項と非機能要求事項について考慮したか。
すべての要求事項はテスト可能で、検証可能で、そして追跡可能か。
プロジェクト計画のコンテンツ
概要
プロジェクトの背景とコンテキストが記載されているか。
プロジェクト・サマリーが準備されているか。
前提条件や定数、依存関係は特定されているか。
プロジェクトへのアプローチの概要は記載されているか。
（該当する場合のみ）外部インターフェースは定義されているか。
成果物
プロジェクトにおける成果物は記載されているか。
各成果物に関する関連情報が含まれているか。例えば、日付、方法、場所など。
リスク・マネジメントと資産マネジメント
最も高いプロジェクト・リスクは列挙されているか。
最も大きなプロジェクト資産は列挙されているか。
コミュニケーション
コミュニケーション・チャネルとインターフェースは定義されているか。
プロジェクト組織
プロジェクトの組織は記載されているか。
関連する役割と責任について定義されているか。
プロジェクト・ライフサイクル
プロジェクト・ライフサイクルの選定について記載され、説明されているか。
ライフサイクルに対して行われたテーラーリングについて記載され、説明されているか。
追跡調査と管理
プロジェクトを追跡調査するための仕組みの概要が記載されているか。
技術プロセス
プロジェクトで利用されるハイレベルな技術プロセスが記載されているか。例えば、設計ツールやプ
ログラミング言語など。
見積もり
プロジェクトのための 1 つ以上の見積もり概要が記載されているか。
見積もり技法と信頼水準が記載されているか。
資源マネジメント
必要となる資源は特定されているか。
必要な資源と利用可能な資源とのずれは特定されているか。
制約のもとにおいて、プロジェクト・ゴールに達するために必要な資源割当てについて、記載されて
いるか。
プロジェクト計画の利用方法
開発チームがインプットを持つ
開発チームの主要メンバーが見積もりプロセスのすべての局面、特にシステム開発にどのくらい時
間がかかるのかについて、関与していたか。プロジェクト・マネジャーとしてのあなたの仕事は、起こ
るかもしれないリスクに対応するための時間を加えた上で、開発の見積もりが合理的であることを
確かにすることである。
各項目の責任者が見積もりを承認する
システムの各パートを実装するメンバーが、見積もられた時間内でそれを実施することに責任を持
つことに同意したか。通常、正式な承認ではないが、取り組もうとしている作業の見積もりについて、
開発者が自信を持っていることは重要である。
プロジェクト・マネジャーが各見積もりを承認する
プロジェクト・マネジャーは各項目が現実に即して見積もられていることに同意したか。PM は計画
上定められた期間内にプロジェクトを完成に導く責任がある。よって、PM が計画の各項目について
ある程度の自信を持つことが重要である。
高いリスクや高い価値を持つ項目を前に持ってくる
計画において高いリスクや高い価値のタスクが特定され、それらをできるだけ前に持ってきている
か。うまくいかないときに対処するための時間をより確保できるので、リスクの高い項目に初めに取
りかかることには意味がある。同様に、顧客の要望を満たしていることをより早く見せられるようにな
るため、ビジネス価値を多く生む項目に初めに取りかかることにも意味がある。
標準タスクに時間を割り振る
計画では要求事項、設計、開発、テストそして展開に対する妥当な時間を割り振っているか。余計な
混乱やパニックを避けるために、それらすべてのための時間が確保されているか、プロジェクト計画
を確認しよう。
引渡しを 2～3 週間単位で予定する
プロジェクトでは、定期的（2～3 週間ごと）にクライアントへ引渡しをする計画か。定期的な引渡しの
数が多いプロジェクトは、最後の最後まで何も作られないプロジェクトよりも本質的にコントロール
しやすい。各引渡しは適合する、しないを明白にした、具体的なマイルストーンになる。定期的な引渡
しをすることで、ユーザーは予定していたタイミングよりも早く建設的なフィードバックをすることがで
きるようになる。
前提条件と依存関係を文書化する
計画において置かれた前提条件と特定された外部の依存関係はきちんと文書化されているか。計
画はプロジェクト・ライフサイクルにおいて早い段階で立てられるため、未知のことが多い。そして前
提条件はスケジュールを作成する上で必要である。そのため前提条件が間違っていることが分かっ
たときには、適切なタイミングで計画を見直すことができる。
開発アクティビティが要求事項まで遡れる
すべての開発アクティビティは、おそらく設計を通じて、ビジネス要求事項まで遡ることができるか。
本来、どんなに要求事項が「素晴らしい」としても、プロジェクトのスコープ内における明白なビジネ
ス・ベネフィットがなければ、それが行われてはならない。
リスクが対処済み
計画においてリスクは包括的に対処されているか。あらゆるプロジェクトにおいて注意しなければな
らないことは、スケジュール通り、予算通りの引渡しに対する最も大きなリスクと、そのリスクがプロ
ジェクトに与える影響を特定する努力をすること、イベントが起こったときに各リスクが発生する可能
性がどの程度あるのか見積もること、そして各リスクに対する適切な軽減策である。
計画が簡単に理解できる
計画は利用する人全員にとって理解できる方法で表現されているか。効果的に伝えられた計画はプ
ロジェクト・マネジャーにとって大きな助けになる。なぜなら、チームの各メンバーがスケジュールを
遵守する責任をより取れるようになるからである。
計画を追う
プロジェクトの進捗を計画に照らし合わせているか。週次のプロジェクト・レポートに正確な進捗状
況を含められるように、週次でプロジェクトを追うのは良いアイデアである。
状況に応じた計画変更
プロジェクト予算と時間枠を満たすため、必要に応じてプロジェクト計画を見直しているか。良いプ
ロジェクト・マネジャーは計画上の小さなずれは許容するが、何かしら大きなこと、例えばクリティカ
ルなタスクの完了日を守れないなど、が起こった場合には、それらを織り込むために計画を変更し
なければならない。
プロジェクト開始時
ビジネス・ケースの承認
ビジネス・ケースとプロジェクト・スコープは上位マネジメント層が承認したか。ビジネス・ケースがサ
インされ承認されることで、上位マネジメント層が少なくともそのプロジェクトを認識し、また何が達
成されるかを認識していることが確実になる。
プロジェクト監督（例えば、運営委員会）の実施
プロジェクトの進捗をレビューするための、上位マネジメント層向けの正式な体制が整っているか。
各マイルストーンにおいて、運営委員会はプロジェクトを継続すべきかどうかを判断する。
要求事項の詳細が入手可能
プロジェクト要求事項が入手可能で、かつそれらは期待するアウトプット（製品）について、詳細に記
載しているか。かなりの頻度で、要求事項を作成することがプロジェクトの初めのステップである。プ
ロジェクトにはこれらの要求事項を決定する手段があるか確かめよう。
開発環境チェックリストの完成
ソフトウェア開発環境チェックリストは完成させたか。このリストはコンパイラー、エディター、デバッ
ガー、ビルド・システムそしてコンフィギュレーション・マネジメント・システムを含め、適切なソフトウェ
ア開発環境がプロジェクトで利用可能かどうかを確かめる。
テスト・プロセスの定義
プロジェクトで要求されるテスト・プロセスが定義され、すべてのステークホルダーとの合意が取れ
たか。すべてのステークホルダーが、プロジェクト製品のテストにおいて何が行われるか、テスト・プ
ロセス（特にクライアントやユーザー部門がテスト実施のために人手を準備する必要がある部分）に
おける各ステークホルダーの責任、プロジェクト製品を受け入れるための基準、について理解し同意
したか確かめよう。
プロジェクト・キックオフ：チーム・メンバーの任命
すべての必要なチーム・メンバーがプロジェクトに任命されたか。マネジメントが、誰がプロジェクト
に参画していて、どの程度の時間を割いているか、を正確に認識することは重要である。
チーム・メンバーによるプロジェクトでの役割の認識
各チーム・メンバーがプロジェクトにおける自分の役割、および権限と責任の範囲について認識して
いるか。より厳格な体制が望まれるような大きなプロジェクトでは、役割を明確化するために体制図
が役に立つ。
プロジェクトのキックオフ時
プロジェクト・キックオフ会議の開催
プロジェクトのキックオフのために会議を開催したか。これはチームを呼び集め、プロジェクトのス
コープを示し、プロジェクトにおいてそれぞれの役割を担当する各個人を紹介することを含む。すべ
てのこれらの会議において、進め方は同じである。プロジェクトの紹介をし、現在の状況と同じ部屋
にいる各個人がどのようにプロジェクト・ゴールに向けて貢献していくかについて話し合う。
週次チェックリスト：計画に対する進捗の確認
スケジュールに対してプロジェクトがどのように進んでいるか分かっているか。プロジェクトをスケ
ジュール通りに、予算通りに、そして全員がハッピーに完了させるために、プロジェクトの進捗がどう
なっているか、何が原因で遅延が発生しているか、を常に把握しなければならない。これら情報を集
めるための最良の手段は、実際に顔を合わせて質問することである。タスクがどのように進んでいる
か、本当の状況を得られる可能性がより高い。
チーム・メンバーによる翌週のタスクの認識
チーム・メンバーが、自分たちがどのタスクを割り当てられ、いつまでにそのタスクを完了し、それら
のタスクの、またはそれらのタスクに向けた依存関係は何か、について知っているか。プロジェクトの
チーム・メンバーは、彼らにして欲しいことやその期限が分からないと完全にいら立ってしまう。また、
出来ないと分かっていることをやるように言われたり、自分の意見を言う場を与えられたりしないと
いら立つ。このもっともないら立ちを回避しよう。
既知の停止を織り込む
プロジェクト計画において、チーム・メンバーがプロジェクトから離れる時間を生むイベントを許容し
ているか。例えば、休暇、トレーニング、部署の月次会議、そしてサーバー・アップグレードなど、計画
可能な「停止」がプロジェクトでは時々存在する。プロジェクト計画中に分かるものもあれば、その後
突然現れ、計画に含める必要が出てくる場合もある。
要求事項変更手続きの遵守
新しい要求事項は、開発を開始する前にレビューされ、承認され、計画されているか。多くのプロジェ
クトにおいて、ユーザー、ビジネス・アナリスト、そしてプロジェクトにとって「良いアイデア」を加えよう
とする開発者などの技術アーキテクトからさえも、悩まされることになる。よかれと思ってやることで
はあるが、スケジュールに影響を及ぼすため管理されなければならない。
高いチーム・モラル
プロジェクト・ゴールの達成に向けて、チーム一丸となって取り組んでいるか。プロジェクトに対して
「好感」を持っているか。生活の質に関する考慮は別として、楽しいチームは生産性の高いチームの
基礎である。「楽しい」ということは、いつも冗談を飛ばしているということではなく、各個人がチーム
の中で働くことに満足しており、プロジェクト・ゴール達成に向けたやる気を持っているということで
ある。そのようなチームはプロジェクトに対して「好感」を持つ。
適切なスキル
チーム・メンバーは、割り当てられたタスクに対する適切なスキルを持っているか。いつでも可能なわ
けではないが、チーム・メンバーはプロらしくタスクを完了させるためのスキルを持つべきである。も
しそうでない場合、トレーニング・コースの受講、メンターの任命、もしくはタスクに対して追加の時間
を与える、などの救済措置を取る必要がある。
知識とスキルの共有
チームでは知識とスキルが自由に共有されているか。チーム・メンバーが自分の殻に閉じこもってし
まう特殊なタスクを持っているか。これはある部分、良いチーム動態の効果である。もしチームでお互
いに尊敬し合い、プロジェクトの完成に向けて一緒に作業することを心地よく感じていれば、お互い
にスキルや知識を自然と共有するようになるだろう。
合意形成
すべてのタスクの手順や標準について、チーム内の合意が取れたか。良いチーム・ワークのその先
の成果は、共通のタスクを遂行するための標準の手順が分かってくることである。これは標準で繰り
返し使えるプロセスにつながるため、良いことである。
「正規」時間の労働
長期間、長時間労働になっている者がいないか。すべてのプロジェクトにおいて、締め切りが近いと
きなど、追加の作業が必要になることはある。しかしながら、仕事がチーム・メンバーの生活を破壊し
ないようにすることが大切である。過剰な労働は人々の健康に害を及ぼすだけでなく、最終的には
病気になり、燃え尽きてしまうか辞めてしまうことになる。
問題を抱えた関係の特定
チーム・メンバー間における対人関係の問題に気付き、プロジェクトに悪影響を与えないよう前向き
な対応を行ったか。「性格の不一致」、意地の悪さ、全般的な不調和は大きく時間を無駄にする。そ
れらは元をたどれば、大抵チーム・メンバー間でお互いに尊敬の心を欠いている。
プロジェクト終了時
展開計画の完成
展開のための文書化された詳細な計画があるか。計画には、最終の受入テストと本番ハードウェア
への展開を含む、展開に向けたすべての要素の日付と時間が含まれるべきである。
ユーザーの十分なトレーニング
新しいまたは改良されたシステムのユーザーは、利用に向けた準備ができているか。トレーニングは
しばしば完全に手遅れになってしまうまで忘れ去られる。システムのユーザーが新しいシステムを効
果的に利用できるように、すべてのトレーニングと必要なサポートを受けられるようにすることが重要
である。
ポスト・プロジェクト・レビュー（PPR）
ポスト・プロジェクト・レビューでは、今後のプロジェクトにおいて組織がパフォーマンスを改善できる
領域を特定したか。PPR のタイミングは難しいことがあり、特に長期間にわたって「段階的縮小」を
する必要がある大きなプロジェクトでは難しいかも知れない。必要であれば、マネジメント、ビジネ
ス・アナリスト、開発者、テスト担当など、チーム内でグループに分けてレビューしよう。
PPR による問題点のカバー
ポスト・プロジェクト・レビューの議事は、既に不足していたとプロジェクトで特定していたすべての
領域を扱っているか。PPR の議事を準備するときには、不足していたことに関してプロジェクトを通
して挙げられたすべてのコメントについて考慮し、レビューに盛りこもう。
PPR フォロー・アップ
ポスト・プロジェクト・レビューでのアクション・アイテムは、組織によってフォロー・アップされている
か。PPR の結果を広く伝えることにより、PPR が無駄にならないようにしよう。そうすることで他のプ
ロジェクトに取り組んでいる人々が、彼ら自身のプロジェクトの準備をするときに、PPR でまとめられ
た経験を利用することができる。
ソース・コードと文書は永続的な形態で保管したか
プロジェクトのソース・コードと要求事項、設計、テストなどの文書は通常、顧客から求められる成果
物である。内部プロジェクトでも、将来参照するためにプロジェクトのチーム・メンバーが行ったすべ
てのハード・ワークについて永続的なバックアップを作成することは、良いアイデアである。プロジェク
トのソース・コードのコピーを複数作成するために、特別なバックアップ・テープを準備しよう。さらに
良いのは、3 つないし 4 つの CD-ROM に分けることだ。
プロジェクト再開のための十分な情報が準備できているか
プロジェクト製品の拡張機能を開発する新しいプロジェクト・チームが最小の休止時間で着手でき
るよう、十分な情報が準備できているか確かめよう。この項目の重要性はとても多様である。もしこ
のプロジェクトの製品が同じチームによって継続開発される場合、追加の文書は一切必要ないかも
知れない。知識はそのチームによって新しいプロジェクトに持ち越されるだろう。
クロスチェック
自分に下記の質問を問いかけてみよう。
 手元のプロジェクトに対して、適切な開発ライフサイクル・プロセスを選択したか
 開発チームはどのような要求事項（機能要求事項そして非機能要求事項）が満たされるべきである
か、理解しているか
 アプリケーションのための適切なアーキテクチャーを選択したか
 アプリケーションの機能の過不足について確かめたか
 コード生成において標準のベストプラクティス、例えば継続的な統合や日次のビルドとテスト、を準備
したか
 計画、要求事項、アーキテクチャー、設計、コード、そしてテスト・ケースを含む開発プロセスでの文書
類について、レビューの仕組みを確立したか。
 テストはあなたのソフトウェア開発でなくてはならない部分で、積極的に行われるか。つまり、テスト・
ケースがコーディング開始前に計画され、アプリケーションの設計中もしくはコーディング中に作成さ
れるか。
 システムまたはプロジェクトを構成するすべての文書類の状態を把握し、それら文書類の状態を管理
し、そしてシステムがはっきりとわかる説明（構造）でリリースしているか
 計画がソフトウェアの品質をチームで達成する助けになるようにするために、プロジェクトにおける品
質の優先度とリリースの基準を確立したか
 展開の計画を立て、展開チェックリストを利用したか
 システム運用、および起こりうるユーザーの問題に答え、そして解決するためのサポート体制を構築し
たか
 以前のプロジェクトの教訓を生かしたか
 自分の開発プロセスを、会社によって選択された業界標準と比べてみたか

Checklist For Successful Software Projects Japanese

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Checklist For Successful Software Projects Japanese

Uploaded by

Copyright:

Available Formats

Successful Software Projects Checklist

"If you fail to plan, you plan to fail."

引渡しを 2～3 週間単位で予定する

You might also like