プロジェクトが計画通りに進まないときに見直したい3つのポイント

やり方そのものを見直すPDCAを！ システム導入プロジェクトの基本設計トラブル対応

私がある社内システム刷新のため、某ベンダー開発によるシステム導入プロジェクトのプロジェクトマネージャーを担当していた頃の話です。

プロジェクトが遅延状態だったため、前任からのプロジェクトマネージャーを引き継ぎ、新しくマスタスケジュールを作成し、社内メンバーと共にベンダーが提出する基本設計書のレビューをしていました。

しかしながら、ベンダーとの要件の認識齟齬が多く、基本設計書の作成し直しといった差し戻しが頻発し、納期遅延のリスクが出てきていました。
なんとか改善しようと、ベンダーが基本設計書を修正が完了次第、すぐに社内メンバーがレビューすることで間に合わせようと努力しましたが、遅延状況は改善されませんでした。

そこで、新たな改善案が必要と考えていたときに、ふと「この基本設計レビューは何のためにやっているのか？」と疑問に思いました。結果、「要件通りにシステム開発がされていることをチェックするため」と非常にシンプルな答えに。このような大前提が変わると計画や運用方法も変わってきます。

メンバーと認識を新たにし相談した結果、基本設計書のドキュメントの品質にこだわるよりもまずはプロトタイプを作り、同時ににレビューをするほうが生産性が高いという結論になりました。そのため、ベンダーとも協議を行い、やり方を大きく変更することにしました。

また、前任から引き継いだこのシステム開発は、「ウォーターフォール型の開発をする」というバイアスがありましたが、これは「アジャイル型に変えてはいけない」、ということではありません。

結果、予想通りプロトタイプを見ながらの基本設計書のレビューの方が生産性が高く、基本設計書レビューの遅延をリカバリーできました。

本実例から学んだことは、計画だけではなく「やり方そのものを疑う思考のクセ」をつけるべきだ、ということです。

これは、「このタスクは何のためにやっているのだろう？」と目的を常に問い続けることがポイントとなります。よく考えると、きっと目的達成の手段は複数あるはずです。手段が目的とならないよう心がけましょう。

チームタスクの優先順位には拡散性も考慮する！システム開発プロジェクトにおけるリリース後の問い合わせ対応

システム開発のプロジェクトに従事し製品をリリースした後、不具合が頻発したため立て直しを任された際の話です。

ユーザから上がってくる問い合わせや不具合について、量的にチームメンバーが対処しきれない、という問題が発生していました。

単純にタスクの量が多い、という問題だと考えたため、定期的にチームタスクの優先度と重要度の整理を繰り返して対応していましたが、状況はあまり改善されませんでした。

改めて見直しをする必要があると感じ、私のマネジメントについて原因分析を実施。見落としていたのが対処する問題に「拡散性」があるかどうかでした。

例えば、問い合わせの調査の結果、システムAに不正データがあるが、動かないわけではない、となると、緊急度は低く見積もりがちで、より喫緊のタスクから先に完了させようとしてしまいます。しかしこのシステムAを放置しておくと、システムB、Cにも影響を与え別の大きな不具合も誘発してしまう、というような場合です。このように、そのタスク単体の緊急度だけではなく、他のタスクに影響を与えるかどうか、という部分が「拡散性」です。

トラブル対応でチームタスクをマネジメントする場合、タスクはつい重要度と緊急度だけで優先順位を決めがちです。しかし、この拡散性ということもきちんと認知して優先順位を決める必要があります。

拡散性も念頭に置いてチームタスクの整理をし直した結果、問い合わせ対応が量的に対処しきれない、という状況は徐々に減っていきました。

今、思えばこの気づきは当たり前だと感じます。しかし、当時、自分では優先順位を的確に判断しているつもりでした。俯瞰的に問題を見ることの重要性について学ぶことができた事例です。

トラブル対応についての計画を立てる際には、あらためて「緊急度」「重要度」だけではなく「拡散性」もふくめた3つを軸にして、対応する優先順位整理してみてください。

やることも決めたらやならいことも決める！業務改善プロジェクトにおけるメンバータスク管理

ある会社全般の業務改善プロジェクトマネージャーにアサインされた頃の話です。各業務運用見直しの方針案が決定し、業務マニュアル作成といった最終成果物を各チームリーダー、およびメンバーに依頼していたときのことです。

一部メンバーの成果物タスク進捗が思ったより進んでいませんでした。そのため、最初は私が策定した計画の工期見積もりが短すぎたのか、または成果物の定義が伝えきれていないと感じました。

そこで工期を少し増やして、成果物作成までのフローを改めて各メンバーに説明して回るということを実施しましたが、それでも成果物の進み具合は改善されませんでした。

改めて、計画の見直しを迫られ、メンバーのタスクを見直すことに。各メンバーのタスクは本プロジェクト以外にもあるため、それを考慮して割当を行い計画したつもりでした。

しかし、原因を探るべく改めて各メンバーにヒアリングをしてみると、本プロジェクト以外のタスクで優先順位が低いものを、優先して対応してしまっていることがわかりました。

つまり、本プロジェクトに関するタスクの優先順位は理解はし、成果物も着手できる状態にもかかわらず、本プロジェクト以外のタスクに工期を奪われていたのです。

私はこのことから、関係部署マネージャー陣に一定期間以外は改めて本プロジェクト以外のタスクはしないよう依頼をしました。また、どうしても業務上必要な場合は本プロジェクトのタスクを調整するため教えて欲しい旨を伝えました。

結果、一定期間ではあったものの各メンバーのタスクが計画通り進み出し遅れを十分に取り返すことができました。

ポイントは、「やることを決めた際には、やらないことも決める」ということです。チームマネジメントにおいて、やるべきタスクを整理するのはもちろん重要です。しかし、同時にやらないことも整理すべきなのではないでしょうか。