IT プロジェクトを成功に導くための計画方法

情報技術プロジェクト計画、または、IT プロジェクト計画とは、プロジェクトの開始時点でチームが作業を順調に進めるための取り組みのことです。 これらのステップは、プロジェクトが期限と全体的な目標を達成することにも役立ちます。

計画は IT プロジェクトの第 2 段階であり、プロジェクトの開始後とプロジェクトの実行前に行います。 開始および実行段階とIT プロジェクト管理の詳細情報をご覧ください。 これらのプロジェクトの優先順位付けに関する詳細は、「包括的な IT プロジェクトの優先順位付けガイド」をご覧ください。

IT プロジェクトを計画するには、主要な早期ステップを踏む必要があります。 そのステップには、チーム メンバーや関係者がプロジェクトの全体的な目的を理解できるように支援することが含まれます。 さらに、チームがどのように作業を定義し、監視するかを明確にします。

専門家は、IT プロジェクトを効果的に計画するためのステップをいくつか推奨しています。 まずは、プロジェクト チーム メンバーと関係者によるキックオフ ミーティングを開き、プロジェクトの大まかな概要と目的について話し合うことから始めます。 

IT プロジェクトを計画する上で重要な 13 のステップを以下にご紹介します。

ウォーターフォール手法の使用など、従来のプロジェクト管理計画には、いくつかのステップとドキュメントが含まれます。 IT プロジェクトでアジャイル手法を使用する場合、これらの取り組みはあまり一般的ではないか、または適用される方法が異なります。

たとえば、従来のプロジェクト管理では、チームは多くの場合、作業分解構成図 (WBS) を使用します。 詳細な図は、プロジェクトを完了するためにチームがチェック済みの印を入れる必要があるすべてのタスクを示しています。 作業分解構成図の始め方について詳しくは、こちらをご覧ください。  

アジャイル プロジェクトでは作業分解構成図は使用しません。 しかし、アジャイル プロダクト バックログやプロダクト ロードマップは、多くの場合、同様の目的を果たします。

従来のプロジェクト管理には、以下のステップやドキュメントも含まれます。 

• リスク管理計画の採用
• チーム メンバー、クライアント、関係者のコミュニケーション計画の処理
• 変更管理計画の実装
• 予算計画の実行
• 必要なリソースと人員配置の計画
• すべてのプロジェクト アクティビティのスケジュール

チームがアジャイルを使用して IT プロジェクトを計画、実行する場合、上記と同じステップを多く取りますが、形式が異なり、規則も少なくなります。 代わりに、これらのステップはスプリントやイテレーションの一部である場合があります。

ここでは、アジャイルの仕組みを理解する方法、そしてチームがアジャイルを適切に使用しているのか、それともアジャイルを使用していると言っているだけなのかについて詳しく説明します。

IT アジャイル プロジェクト計画の例をダウンロード — Microsoft Excel

このアジャイル プロジェクト計画テンプレート例は、IT プロジェクトの計画方法を理解する際に役立つ完成形です。 このテンプレート例には、特定のアジャイル スプリントのエントリと、それらのスプリント内の機能が含まれています。 また、各項目を担当するチーム メンバーのセクション、予定されている開始日と終了日、現在のステータスも記載されています。

アジャイル プロジェクト 計画テンプレートをダウンロード — Microsoft Excel

このアジャイル プロジェクト計画テンプレートをカスタマイズすると、アジャイル IT プロジェクトをあなたの目的に合わせて計画し、監視することができます。 テンプレートには、タスク、タスクの責任、開始日と終了日、ステータスを追加できるセクションがあります。 各タスクの期間 (日数) は、自動的に計算されるようになっています。 また、テンプレートの左側の表に入力したデータに基づいて、ガント チャートが右側に作成されるようになっています。

IT プロジェクトは、プロジェクトの開始から終了まで、多くの調整や変更が行われること知られています。 多くの IT 以外のプロジェクトでは、変更がはるかに少なくなります。 したがって、多くの IT プロジェクトを計画するには、異なるアプローチが必要です。

ここでは 2 つの主な違いがあります。

• IT プロジェクトでは、従来のプロジェクト管理方法を使用する可能性が非常に低くなります: ウォーターフォールなどの従来のプロジェクト手法は、建設プロジェクトには確かな選択肢です。 このようなプロジェクトでは、計画の大幅な変更の可能性は低くなります。 しかし、ソフトウェア開発やその他の情報技術プロジェクトでは、全体を通して大きな変更が発生し、アジャイルまたは修正版のアジャイル手法を使用する可能性が高くなります。
• 予算は変更される可能性が高くなります: IT プロジェクトの予算は、不測の障害や問題に調整が必要な場合、変更されます。 しかし、プロジェクトの成功に際しても予算は変更される可能性があります。 これは、(プロジェクトの実施期間間に開発された) 新しい IT 製品がヒットし、顧客に愛されるようになったときに起こります。
  
  「IT 以外のプロジェクトと IT プロジェクトの違いは、IT プロジェクトの終了時点が、実際には何かの始まりであるという点です」と Shandil 氏は言います。 「他のプロジェクトを終えたら、それは何かの終わりです」
  
  建設スタッフが建物を完成すれば、建設予算も完了します。 しかし、ソフトウェア開発者がソフトウェアを完成させ、顧客から愛用されると、その顧客はそのソフトウェアを改善するための変更を継続的に提案します。 つまり、ソフトウェアと IT の予算は、それが成功すれば大きくなります。
  
  「ソフトウェアに 200 万ドルを費やした場合、サービス停止までに 800 万ドル費やされるでしょう」と Shandil 氏は説明します。

専門家は、プロジェクト チームの形成と維持を推奨しています。 また、計画に必要なドキュメントとそうでないドキュメント、作業と進捗を示す方法も決定する必要があります。

IT プロジェクト計画の専門家による最も役立つヒントを以下にご紹介します。

• 進行中のプロジェクト チームを維持する: 組織によっては、特定のプロジェクトごとに専任チームを作成する場合があります。 しかし、Zucker 氏は、ほとんど同じメンバーから成る進行中のチーム (プロジェクトに次々と取り組む、いわば永続的なチーム) を維持することにはメリットがあると言います。 チーム メンバーは全員がお互いに適材適所を知り尽くしており、プロジェクトの作業をより効率的に進めることができます。
  
  「永続的なチームは、 アジャイル環境でも従来の環境でも、どちらでも機能します」と、Zucker 氏は言います。
• 目標が正しい目標であることを確認する: 会社やプロジェクトのリーダーがプロジェクトの目標を発表し、すぐにその目標を達成するための計画を立て始めることがよくあります。 しかし、その目標が正しい目標なのか、それを達成すれば組織の望みを達成できるのかを常に分析するとは限りません。
  
  「全体が何度も役にたっているのを見てきました」と、Zucker 氏は言います。 「彼らは自分が達成したいことに 15 秒を費やし、その実装方法の詳細をすぐに掘り下げていくのです。 成し遂げたいことを明確にしましょう」
• 適切な方法で最終的な成功を定義する: IT プロジェクトでの成功は、ソフトウェアやデジタル システムに追加した機能の数ではないと Shandil 氏は忠告しています。 それは、顧客満足度です。
  
  「最高の結果は顧客満足度に表れるため、通常は次のように考えます。 今月はいくつの機能をリリースしたか？ ではなく、: 満足してくださっている顧客は何人いるか？ お客様は私たちが今月リリースした機能に満足してくださったのか？」と尋ねることを提案しています。
• 詳細な書面ドキュメントに集中しすぎない: アジャイル手法は、従来の手法よりも、正式な書面によるドキュメントの要求に重点を置いていません。 しかし、アジャイルでも、基本的なプロジェクト管理計画とスコープに関するいくつかのドキュメントは重要です。 しかし、ドキュメントの作成に時間を無駄に費やすことは避けたいものです。それらは、すぐに廃止され、プロジェクトの進捗を妨げます。
  
  「これらのドキュメントの作成に時間がかかるため、トレードオフを行うと思考の回転が遅くなります。. 多くの場合、将来に向けてプロジェクトを計画しています。 製品が何であるかさえ、はっきり分からない場合もあります。 本当に必要なドキュメントを決定し、編集します。 また、絶対に必要なものと不要なものを決めるスキルでもあります」と Sims 氏は助言します。
• 前もって計画を立てすぎないようにする: このヒントは、限られたドキュメントに関連しています。 作業を開始する前に、詳細な計画に時間をかけすぎないようにしてください。 もちろん、いくつかの基本的な目標と構造を設定し、 その後、仕事に取り掛かるとよいでしょう。
  
  「今すぐ計画して、後に備えましょう」と Shandil 氏は言います。 「そして、その間に、もう少し学びましょう」
  
  つまり、アジャイルで 1 週間など、限られたスプリントで、チームは製品やプロジェクトに取り組むことができるのです。 「チーム メンバーは、その週の作業でさらに多くのことを学び、次の週の作業に向けて簡単な計画を立てるかもしれません.。 そして、あなたはそれを反復するだけです」と Shandil 氏は言います。 「私たちにとって重要な違いは、何かを実行しなければ、何も学ぶことができないということです」
• 実行可能な最小限の製品の概念を理解し、使用する: 実行可能な最小限の製品 とは、開発者が新しい製品の基本バージョンをできるだけ早くユーザーの手に届けるように促す概念です。 つまり、最終製品ではありませんが、基本的なレベルで機能し、ユーザーにコンセプトのアイデアを与えることができます。 その早期のユーザー フィードバックは、他の機能を追加し、製品を開発を一層すすめるのに役立ちます。
  
  「最良のフィードバックは、実際のユーザーからのフィードバックです」と Sim 氏は述べています。
• 労働文化に関する労働契約を締結する: プロジェクトの開始時に、Shandil 氏はクライアントに対し、人々の協働方法に関する基本的なルールと原則を定める労働契約の合意を促しています。
  
  「これにより、人々は、チームのような行動を取り、個々の協力者の集まりのような行動は取らなくなります」と彼は言います。 「そこで、私たちはチームのルールブックを考案しました」
  
  ルールには、「沈黙は合意」などが含まれています。 「そうすれば、人々は自分が議論に参加すべきであることを理解し、議論に参加しなければ、合意しなかったと後で言えなくなるのです」と Shandil 氏は説明します。
  
     
• プロジェクトの進捗を全員が簡単に確認、監視、追跡できるようにする: チーム メンバー、クライアント、関係者は全員、プロジェクトのステータスと進捗を簡単に確認できる必要があります。 チーム メンバーは、作業がどれだけ残っているかを確認でき、チーム メンバー以外の人々は進行中の作業を把握できます。 これは、このプロジェクトや将来のプロジェクトに対する政治、財務、その他の支援を構築するのに役立ちます。
  
  Shandil 氏は、買収されたオーストラリアの医療組織での事例を覚えています。 買収会社の CEO はオフィスを訪れ、IT 部門にプロジェクトが書かれた大きなホワイトボードが置かれているのを見ました。
  
  「彼女はこのボードを見て、『あなたたちはたくさんの仕事をしていますね。 シドニーにいる私の部下は、これほど仕事をしているとは思えません」 私たちは、それが真実ではないことを知っていました。 ただ、可視化できていなかっただけなのです。 彼女が知識労働者がいる場所を通り過ぎ、頭の中でたくさんのことが起こっているため、そのアイデアは私たちにとって本当に重要です。 彼女には見当がついていないのでしょう。 それをテーブルに持ち込み、必ずしも技術的な経歴を持っていない人にそのプロセスに実際に参加してもらうことは、非常に大きなメリットがあります」
• サイバーセキュリティに対処する方法について考える: サイバーセキュリティはすべての IT プロジェクトにとって重要です。 一部の IT プロジェクトにとっては、プロセスの初期段階で考慮すべき最も重要な要素かもしれません。
  
  つまり、サイバーセキュリティは、チームが評価し、計画する初期のリスクの 1 つでなければなりません。 Sim 氏は、製品に必要なサイバー セキュリティを確保するために必要なものをチーム リーダーが評価したプロジェクトを目撃したことがあると言います。 そして、そのサイバーセキュリティ予算は、最終的にプロジェクト全体の想定予算の 5 倍にもなってしまいました。
  
  「そのプロジェクトはもう意味がないということですね」と彼は言います。 「作業後期ではなく、超初期段階でその事実を見つける方が良いでしょう」

IT プロジェクトの失敗率はかなり高い。 1994 年以来、Standish Group は IT プロジェクトの成功に関する CHAOS レポートを発表してきました。 2015 年のレポートによると、2015 年には IT プロジェクトの 36% が成功裏に完了していました。 また、46% のプロジェクトが、プロジェクトは完了し運用可能だが予算をオーバーした、期限を過ぎて完了した、当初の計画よりも提供した機能が少なかったなど、「課題を抱えた」状態でした。. さらには、19% のプロジェクトが完全に失敗し、取り消されました。

プロジェクト マネジメント協会の「Pulse of the Profession」2021 のレポートでは、過去数年間の事例から IT プロジェクトの成功に対する改善がいくつか報告されました。 それでも、この数字はより多くの改善の余地を示しました。 このレポートによると、IT プロジェクトの 64% が予算内で完了し、59% が期限内に完了していることがわかりました。 また、IT プロジェクトの 33% が失敗し、予算を失ったことがわかりました。

専門家は、IT プロジェクトはさまざまな理由で失敗すると言います。 その理由は、目的が不明確であったり、プロジェクト チームのリーダーや関係者間のコミュニケーションが乏しかったり、プロセスの初期段階でユーザーからのフィードバックが不十分であったりしたことが挙げられます。

問題の原因となっている特定の問題の詳細を以下に示します。

• プロジェクト リーダーとチーム メンバーがお互いに、また関係者と同期していない: 失敗したプロジェクトでは、プロジェクト リーダーやチーム メンバーは、クライアントや関係者と十分な頻度でコミュニケーションを取っていません。 コミュニケーションを取っても、そのコミュニケーションは乏しく、プロジェクトの目標は、それぞれの側によって考え方が異なります。
• 説明責任の混乱: また、チーム リーダーとチーム メンバーは、プロジェクトのタスクや全体的な役割を誰が担当しているのかも混同する場合があります。
• 不明確な要件: 失敗した IT プロジェクトの大きな要因は、開始時にプロジェクトの中心にある製品要件を明確にしないことです。
• 作業の過剰セグメント化と不十分な引き継ぎ: 優れたプロジェクト チームには、会社のさまざまな部門のメンバーが含まれており、一緒に仕事をし、自分たちのチームより規模の大きなチームの業務がサイロ化しないようにします。 サイロ化することにより、部門間でプロジェクトを移動させる際に、タスクに関連する大きな問題が発生する可能性があります。
  
  「昔のやり方は、冷戦時代の情報受渡地点のようなものです」と Shandil 氏は言います。 「誰かが公園のベンチに行き、その下に何かを置いてから、歩き去ります。 すると誰かが来て、それを持ち去ります。 私たちはそれが機能しないことを知っています」
  
  さまざまな部門のチーム メンバーは、機能横断型チームで協力する必要があると Shandil 氏は助言します。 「部門横断型チームを持つという考え方では、引き継ぎを行う必要はありません」
• 製品の予備計画と作業の実行に時間をかけすぎる: 企業の多くは、中核となる製品の計画と準備作業の実行に時間をかけすぎます。 いくつかの予備計画と作業を実施する必要がありますが、できるだけ早くユーザーの手に製品を届けなければなりません。
  
  長期の計画と開発には、別の危険が伴います。 それは、市場の方が彼らが開発を計画していた製品よりも勝ってしまうという危険です。 「何か売り出すのに 1 年かける場合、それ自体が長すぎるのです」と Sim 氏は述べています。 「テクノロジーは、やろうとすることは何でも可能にしてくれるかもしれません」

ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。