top of page
Project plan
Execution plan
Run
control
Looking back
プロジェクトの落とし穴
その１ Project Plan(業務改善計画)とExecution Plan(実行計画)は違う。
システム化計画の目的（Goal）は、新しい価値の創造であったり、業務のスリム化・高度化など、求める内容や質は様々ですが、この段階でシステムに過度な期待は禁物です。
あるべき姿（Goal）と、現状のギャップを正しく認識しないことには、一足飛び、二足飛びの壮大な計画を立てても失敗します。
そうならないためには、Ploject Plan と Execution Planの違いを理解し、Goalに対し、いま自分のいる場所を常に確認する必要があります。プロジェクト管理の入り口は、このGoalの設定と、Execution Plan、つまり現実の差を明らかにするところから始まります。
その2 Run control(開発の進捗またはその管理)は急がせない。
仕事をする上で、納期通りに完結させることはビジネスの常識です。にもかかわらず、Run control（予定通りの開発スケジュールにするための牽制）では、予期せぬことや、突発的な問題が発生することも多々あります。
ここで、納期を優先してしまうと、後で必ず痛い目にあいます。
本来、Execution Plan（実行計画）を立てる段階で、納期までのバッファ（余力）を見ておくものですが、特に
Ploject Plan ＝ Execution Planの場合は、本当に余裕のないスケジュールを引いてしまうものです。
どうしても納期を優先する場合、トレード・オフとして、何かを諦める決断が必要です。無理に納期に合わせた結果、バグだらけの成果物では、使い手のお客さまはもちろん、作り手も信用を失い、誰も幸せにはなれません。Laughteyは、皆がWIN-WINになれるための努力を惜しみませんが、中途半端な成果物しかお渡しできないようなスケジュールなら、最初からご依頼をお断りをするケースもありました。
その3 Looking Back(振り返り)のないプロジェクトは次も失敗する。
これはシステム開発系のプロジェクトに関わらずですが、成功事例ほど伝わりやすく、失敗事例ほど伝わりにくいものです。Execution Planが失敗したことでPloject Planとの差が大きすぎた事に、そこで気づいたなんてこと、ありませんか？
失敗を認める事はとても体力も気力も使いますが、この作業無くしてお客さま、弊社ともに成長はありません。
アンカー 1
成功事例
弊社にプロジェクト管理をお任せいただいた事例の一部をご紹介します。
超高速PDCA! セミナー予約サイトの構築
■お客さまの課題
ある特定分野で、専門的な業務やセミナーを主催されているお客さまからのご依頼。
「いま使っているこのシステム、もう担当者が異動でいなくなって、使い方がよくわからないんだよ」
「ウェブサイトから受講の受付をするんだけど、なんかエラーが出てるみたいなの！」
「受講者の集計は全部、手作業なんだよ」
「このウェブサイトに、新しい機能を付けてほしい」
「私はよく使い方が分からないから、Aさんに聞いて！」
つまり
ご利用になられている「各種セミナーのウェブ受付画面」に不具合が出ており、急いで直したいけど、どこに頼めばいいのか分からない。加えて、もっと業務を効率化するための機能が欲しい！というご依頼でした。
■解決のアプローチ
こちらのケースの場合、すべてはProject Plan（業務改善計画）を設定する際のインタビューで決まりました。お客さまのニーズは上記の通りですが、本質的な課題は「業務の属人化」にありました。システム担当者さまが人事異動でご不在となった途端に、システムが稼働しなくなっている状況でした。
そこで
Project plan（業務改善計画）は、「セミナー受付サイト運営の標準化」となり
Execution Plan（実行計画）は、「セミナー新規作成から受付集計作業までの効率化」となりました。
ご覧の通り、IT改善が目的ではなく、運用の問題解決がゴールです。
ここに、少しだけIT要素を入れてRun（開発）に入りました。
■納期
上記の通り、システムに求められているポイントはごくわずかで
・誰でも同じ作業ができること。
・集計作業を楽にすること。
この2点だけでしたので、業務の分析から新しいシステムの導入（プロジェクト完了）まで、わずか1.5ヶ月で完了しました。
■プロジェクト管理のポイント（成功への分岐点）
いま目に見えている問題点（たとえばウェブサイトの入力フォームが壊れている など）や、お客さまのご要望だけでなく、本質的な問題点にまで入り込めた事が非常に大きかったです。
特にIT管理業務は属人化しやすく中身が見えにくいものですが、「そもそも見る必要がない」が究極だと思います。このお客さまの場合、システム保守や運用にコストをかけず、どんどんセミナーを開催し、受講者さまとの接点を強化し、セミナー自体の質向上に時間を費やすべきと考え、salesforce.comのクラウドサービスで業務改善を図りました。
■費用・効果
非公開
※当初お客想定の開発予算比50％,納期比30％短縮で完了しました。
■使用した環境
salesforce.com Platforlm,sites.com
即効性重視! お客さまホームページの開発
■お客さまの課題
特定の分野で、ウェブ取引を行うシステム。そのウェブ取引システムに、対象のユーザーさまを誘致する導線が弱く、ウェブ取引システム自体の活性化が課題
「ユーザーさんは特定されているけど、なかなかうまく取引システムを活用してくれなくてね」
「この取引システムさえ活用してくれれば、次のビジネスに確実に繋がるのに」
「担当者間で取引の商談をされると取引合意のエビデンス（証跡）が残らなくて困るんだよ」
「このシステムの活用度を上げるアイデアない？」
「いっそのこと、このシステムを使わないと取引してはならない というルールを徹底させるか・・・」
つまり
お客さまでご利用の「ウェブ取引システム」の活用度が思うように上がらないことでビジネスチャンスを逃したり、取引の合意形成が形として残らないために、「強制使用ルール」をご検討中のご相談でした。
■解決のアプローチ
この「ウェブ取引システム」を使用した業務を分析していく上で、いかに「ウェブ取引システムが重要か」を学ばせて頂いたとともに、「ウェブ取引システム」自体の多機能が、実際にご利用いただくユーザー様に理解されていない、という重要なポイントを見つけました。
そこで
Project plan（業務改善計画）は、「ウェブ取引システム活用度の向上」となり
Execution Plan（実行計画）は、「機能紹介ページと、入力権限照会ページの作成」となりました。
「ウェブ取引システム」自体は多様な機能を持っており、有効活用できればたしかにビジネスチャンスは広ると思いました。しかしながら、お客さま「特定の人」と称されている入力ユーザーさまは、さらにカテゴライズ（見れる・見れない,できる・できない など）が、詳細に設定されており、その制限範囲や制限ルールが実入力ユーザーさまに理解されていない事が本質的な問題点でした。
このまま「強制使用ルール」を周知したところで、ネガティブイメージをつけてしまうだけだと考え、「ウェブ取引システムとは？」といった機能の「紹介」と、「あなたが実行できる機能は？」といった制限の「照会」、「紹介」と「照会」を行うサイトページのRun(開発)に入りました。
■納期
このケースの場合、仮説だらけでスタートした「現状把握」に非常に時間を要しました。
Project plan（業務改善計画）が出来上がってからのExecution Plan（実行計画）「機能紹介ページと、入力権限照会ページの作成」は、複数のシステム開発ベンダーさまにご協力いただく形で、弊社が全体コントロールを行い、納期は当初のお約束通り3.5ヶ月で完了しました。
■プロジェクト管理のポイント（成功への分岐点）
お客さまのプライバシー上、詳細はご説明できませんが、仮にシステム的な「強制使用ルール」を採用した場合、開発費用も開発納期も、ぐっと安く・早く完了していたことは間違いありません。しかし、本質的な課題にまでメスを入れる英断をしたくださったお客さま、そしてプロジェクトの主旨をご理解頂き、ご尽力くださいました複数のIT開発ベンダーさまとの「チーム」を作れたことが成功の要因でした。
■費用・効果
非公開
※当初お客想定の開発予算比96％,納期比100％で完了しました。
※当初設定の「ウェブ取引システム」の利用率KPI 初月度で122％達成しました。
■使用した環境
お客さまご利用中の仮想基盤に対し、HTML形式のウェブサイトを構築
bottom of page