予定どおりにITプロジェクトを終わらせるための9つの基本ステップ

タスクを予定どおりに終わらせるための9つの基本ステップは以下のとおりでした。

タスクは大きく見ても小さく見ても構いません。

タスクという言葉のイメージからすると大げさになりますが、一定規模のIT導入・システム開発プロジェクト全体を一つのタスクとして捉えたときにはどうなりますでしょうか。

その際も基本ステップは同じになります。具体的に見ていきましょう。

一定規模のプロジェクト全体タスクで最初にやるべきこと

ITシステム開発のプロジェクト全体をタスクと捉えた場合、最初にやるべきことは何でしょうか。
背景・目的は何かを確認してください。

特に目的は手段が目的となっていないか確認してください。

本当の目的がわからない場合は、一旦発散させて意見収集し、その後意見集約してみます。

一定規模のプロジェクトですからかなり大きい範囲による要求である可能性があります。

ここで知ろうとしている背景や目的は、実際やろうとしていることよりレイヤが上ということを意識してみることがコツです。

レイヤを２つほど上げると、見えてくるものが違ってくるでしょう。

顧客管理システムを導入して、顧客登録処理の効率化やセキュリティ的な管理ができていることを目指す案件があったとします。

目的が2つは出てきていますが、本当にそれだけの目的なのか、それはただの手段ではないのか等を一旦考えてみます。

レイヤを上げてみると、過去からの経緯で現状顧客の流出が進んでいるのが問題で、対策が必要だったことがわかっています。その対策として顧客の動向をきちんと把握して対策を打つということの一環で出てきた案件でした。

さらにレイヤを上げてみると、既存顧客を維持し新規顧客を増やすためにも、顧客動向を共有すべき、という要求がありました。

このように考えていくと、顧客登録の効率化やセキュリティ対策もやりたいことではありますが、本当の目的ではなさそうです。

結果として、背景・目的・方向性を検討していくことで、IT構想・企画を実施していくことになります。

一定規模のプロジェクト全体タスクでやるべきことを洗い出す

やるべきことを網羅的に定義する

プロジェクト全体として目的や方向性が決まっているとすればそれは構想や企画が完了していることになります。次にやるべきことは要件定義やプロジェクト計画です。

要件定義は、やや抽象的であった目的として実行すべきことを、さらに具体的に定義していきます。

具体的になっていく時点で、必要なITとしての機能や移行の方法など、決めていくうちに選択肢が出てくる可能性があります。目的の実現方法は複数考えられるからです。

選択においては、手段としての効果が大きいがコストも大きいものとその逆のものを比較する場面が多いのではないでしょうか。

この時点ではコストを算出するにも一苦労の場合が多いです。よって概算金額にて比較することなるでしょうが、大きな判断が必要な場合は、別にタスクとして起こして実行していくことになるでしょう。

顧客流出の防止にあたり、顧客動向を分析するという目的に対して、どのようなIT機能が必要かを定義します。分析するや管理するというのは具体的ではありませんので、どのようなデータをどのタイミングで、というように具体的にしていきます。

やるべきことを計画する

さらには、計画という段階まで進めます。計画とはどのように作っていくかということになりますので、どういったチーム体制で、誰がいつまで、ということを決めていくことになります。

大工程、中工程、直近工程といったようにレベルに分けて進め方とスケジュールを決めていきます。

一定規模のプロジェクト全体タスクで期間を確保する

一定規模のプロジェクトにおいては、前段階での工程では不完全さは取り払えないのが事実です。

特に既存システムがあり、改造を加えつつ業務を大きく変えるなどの対応は、見えていない部分がどうしても残ってしまう傾向にあります。

大規模な改修対応や大規模な機能追加等の対応は、特に期間の考え方が重要となります。そこで対応したいのは、全体の確認を行うテスト期間を半分の期間分確保するということです。

本来であれば要件定義時に決めて設計して作り込んでいくのが正しいですが、どうしても漏れが発生し、しかも見つけるのが困難であればテストして見つけるしかありません。

また必要な機能すべてを提供できるとも限らず、その場合どのような業務オペレーションとするかを決めるというタスクも発生します。

その対応についても、一つひとつ潰していくため期間が必要となります。

システムテストや総合テストと呼ばれる全体を繋げたテストや受入テスト、運用テストといった仕上げ・受け入れの仕事を半分の期間で実施することで、半分の期間で作成された不完全な状態を完全な状態へと持っていける可能性が高くなってきます。

一定規模のプロジェクト全体タスクで割り振りをする

プロジェクトでのタスクの割り振り

一定規模のプロジェクトという場面においては、関わる人も多くなってきます。数十人から百人以上ということもありますし、金融機関などではさらに大きな規模になることも少なくありません。

多くても少なくても同じではありますが、タスクは適切な人に割り当たっていないと、プロジェクトは停滞します。

ITユーザは必ずしもプロジェクト体制を十分に取れるわけではありません。むしろ日常業務のほうがあるので、一部の時間しかプロジェクトに割けないということのほうが多いのではないでしょうか。

そのような稼働時間も踏まえて、タスクを割り振らないといけません。多くのタスクの現状認知や仕上げに寄与できる人が、作業タスクを一生懸命やっていたら、限られた時間がもったいないということになります。

階層チーム体制

大きなプロジェクトとなった場合は、チーム体制が階層的になることもあります。

プロジェクトマネージャを中心として、階層化したチームを編成することは、意思決定やマネジメントの上では、有効となります。

プロジェクトマネージャから見たら、マネジメント対象の人が４か５人で、またその先に４，５人のチームがある、というチーム体制が情報の流れの円滑化からいうと理想的となるでしょう。

ただし、これは完全化モデルです。マネージャやノードとなるチームリーダが適切に完璧に揃っていることがありますでしょうか。

あるという組織もあるでしょうが、多くはそんな完璧な体制は組めないのではないでしょうか。さらに完全化モデルにおいてはプロジェクトマネージャは神です。ある程度神に近い人はひょっとしたらいるかもしれませんが、その存在を期待するのは現実的でしょうか？

知恵が出せるチームとは

すべてのタスクがきれいにツリー構造で表せれば、チーム体制もそれに近いものができるでしょうが、そうなるとは限りません。ただ、やるべきことがタスクとして認識されていれば、誰かがやったり、数人で知恵を出しあうなりして、何とか進めることはできるはずです。

ITのプロジェクトで作業量をマネジメントする部分は少なくありませんが、ユーザにとっては知恵をマネジメントするほうがウェイトが大きくなります。

一定規模のプロジェクト全体タスクでスタートのスイッチを入れる

スイッチとしてのキックオフミーティングとは

多くの人数が関わるプロジェクトでは立ち上げが重要となります。計画をしてタスクを人に割り当てたとしてもやはりスムーズに進むとは限りません。

そこでよく行われるのはキックオフミーティングです。

目的を理解してもらい、計画を説明し、実行に移してもらいます。これまでのタスクの前段にあった成果を見せればいいのですが、やはりここで重要となってくのは、スイッチを入れるという行事です。

カリスマの一言は有効か？

もし組織がカリスマ社長のもとに軍隊のように動くようになっているのであれば、カリスマ社長から一言あれば動き出すかもしれません。

ただ、大人数になっている場合はカリスマ力も行き届かない可能性があります。

なので一言もスイッチのきっかけにはなりますが、タスクとしてまず何からやろうというものもスイッチとして用意したほうがよいでしょう。

一定規模のプロジェクト全体タスクでの行動フェーズ

IT導入プロジェクトにおいては、システム開発していたり、システム設定を行っている場面です。あるいは移行データを作成している場面などもあります。

一定規模のプロジェクトであれば、作業ボリュームがあり、作業順序性や品質確保もかなり苦労する場面ではあります。しかし、重要なのは、個々に至るまでの過程でやるべき姿が定義され、やることが計画されていれば、それほど大きな問題はなく開始できているはずです。

ITについては技術的な問題が発生する可能性を秘めています。あるいは、関わる人が増えてくれば、それだけITマネジメントを阻害する原因行動も出てきます。認識限界、自己偏重、現在偏重、環境順応といった傾向から課題・問題が発生してきます。

課題・問題が発生した際は、適時確認することと対策を打つことです。これは次ステップでの説明となります。

一定規模のプロジェクト全体タスクでの途中計測

工程の区切りでの判断は正しいのか？

一定規模のプロジェクトにおいては、大きなマスタスケジュールを元に動いていることが多いでしょう。

システム設計、システム開発、データ移行、ユーザ教育などのタスクが大きな工程で分かれているのではないでしょうか。

その工程の区切りでうまくいっているのかいないのかを計測して判断するというは一般的でしょう。
ところが、工程の区切りというのは、様々なタスクが並行で動いている中で、きれいに収束するというのは難しいです。ましてやすべてがうまくいっていなかければ、先に進まないと決めていたら、本当にプロジェクトがストップしてしまいます。

プロジェクトにおける適切な定点計測とは

工程という大きな単位ではなく、もっと細かいタスク単位で見ると、まさに今見てきているタスクの進め方のとおり、適切な計測を定点で行っていれば、その総数がプロジェクトの断面ということになります。

成果物を完成させるという区切りは確かにあると思いますが、完成を目的に急いで作られたものよりも、一つひとつのタスクをきちんと計測するよう習慣づいていれば、状況や成果は確認できるということです。

少なくとも、ある断面が終了したということであっても、残っているタスクがあれば明確にしておくことは必要です。

一定規模のプロジェクト全体タスクでのテコ入れ方法

プロジェクト後半で積みあがってくるもの

プロジェクトにおいては、特に後半は不具合検出のタスクが多くなります。テストを進めるタスクに、都度発生した課題一件一件が加わった状態がやるべきタスク群です。

課題は都度発生するため、一定範囲はやるべき人が決まっているでしょうが、一定範囲を超えた場合は、タスクが宙に浮きます。

そうなってくると、プロジェクトの進捗は停滞してきますので、テコ入れが必要です。

たった1件の課題に対するテコ入れ

ITのプロジェクトにおいては課題がほんの1件だったとしても、それを対応する目的を今一度考えざるをえなかったり、設計はもちろんのこと、要求が必要なのか、別な方法とどちらがいいのか、といった遡っての検討が増えてしまうこともあります。

テコ入れの場合の手順は、元々のタスクの進め方と同様で、背景・目的・方向性から検討していくことになります。

テコ入れでプロジェクトが前進するコツ

後半では、内容はわからないが、何らかの多くの課題を潰していくことがタスクとなりますので、1件ごとにタスクの進め方の手順を繰り返すことを想定したマネジメントを準備しておきます。

その前提であれば習慣化され、ゴールまで続けられるモチベーションを保つことができます。何も起きないことを前提と考えてしまっていては、いちいち課題発生都度がっかりしてしまいます。

一定規模のプロジェクト全体タスクでの記録方法

プロジェクト過程で生産性を上げて記録する

一定規模のプロジェクトにおいては、チーム体制も組まれ、多くの人が関わってきますので、阿吽の呼吸はほぼ通じないと思っていたほうがいいです。

そこで記録というものが重要となります。

一人で仕事していても前にやったことは忘れています。なので適切に記録していないと、後の仕事が進められません。

特に多くの人数が関わっていると、詳細化したタスク単位で柔軟に担当を変えることもあります。よって、タスクが途中でも後を誰もが進められるように記録しておくということです。

記録においても、できる限りタスクの基本ステップに沿って、何をやるべきか、誰がどうやっているのか、計測時点での状況などが記録されているとわかりやすいです。

ただし、すべてを記録するとなると工数がいくらあっても足りないところはあります。できるだけ、関わる人がわかるようにしますが、生産性を上げることも考える必要があります。

生産性を上げる方法は、常に記録することを習慣化することです。
会議が終わったらその時点で記録がされており、すぐに共有されることが望ましいです。
なぜなら、1日経ってしまったら既に半分は忘れてしまっているからです。
もちろん、手分けしてできればそのようにできるでしょうが、できないこともあるので、できる限り早さを重視することを心掛け、習慣化されるよう仕向けたいです。

記録における最重要ポイント

プロジェクトとして最初から一貫して行わないといけないことは、完全性の欠落への対処です。

最初に決めたことが完全に実現され、何もなく完了するということはほぼありません。特に一定規模のITプロジェクトということであれば、間違いなく完全はあり得ません。

記録は、完全でないものへの対処の時に特に役に立ちます。

何か仕様を決定した時の記録は、あとからやっぱりおかしいとなった時に見直せます。それだけであれば、仕様は成果物に反映しているのですから、当たり前のことなのですが、問題は決めたことがおかしいかもしれない、つまり別な観点が抜けていて、やはり不完全であったということなります。

遡って検討するには、どうしてそうしたかが情報として欲しくなります。よって記録の際には、決めた理由も明らかにすべきです。

まとめ

一定規模のITシステム導入・開発プロジェクト全体を一つのタスクと見たときのステップ

一定規模のITシステム導入・開発プロジェクト全体を一つのタスクとして見たときも、一つタスクを進めることも基本は同じです。

途中にうまくいっていないとなればテコ入れが必要となりますが、テコ入れ時は発生した課題のタスクに対し、タスクの手順を追って対応していきます。

タスクを全体と個別に見る方法

タスクを大きく捉えたときも、その一部をタスクとみて小さく捉えたときも、一定規模のプロジェクトにおいては、目線をいったりきたりして、結果的に全体としてタスクの完全度合いはどうなっているかを判断することなります。

その際に、形式化のレイヤ、段階化のレイヤがそれぞれ3レベルくらいでマネジメントされていれば、プロジェクトマネージャやオーナーなどの関係者の判断に大いに役に立ちます。

基本は9つのステップです。