インストラクショナル・デザインⅡ

3ブロックのゴールは「開発計画書」を作成することです。では「開発計画書」って何でしょう？　少し考えてみましょう。

まず、ウォーミングアップに今書こうとしている「開発計画書」を、この科目で学んだXYZ公式で自分なりに表してみてください。答えはひとつに絞る必要はありません。思いつくままいくつか書いてみましょう。

次にロジックチェックをしてみましょう。

講師（北村）は企業に勤務しているころから、eラーニング関係の業務に携わっていました。具体的な仕事としては、eラーニングの調査・提案・導入・展開・開発・営業・・・つまりほぼ全部を一人でやっていました。この頃は導入や開発に関する稟議書こそ書いていたものの、計画書は不要でした。なぜならば、自分が実質的な責任者で、実働までやっていたため、上司のOKがとれれば、もっと端的に言えば予算さえ通ればあとは自分一人でやることができたからです。計画は自分の頭の中にありさえすれば（実は明確では無かったにせよ・・・・）、とにかく納期までに頑張り、臨機応変かつ柔軟に行っていけば（といえば聞こえは良いですが、要は「いきあたりばったり」でした）それでOKだったのです。当初は試行として小規模なものしかできなかったこともあります。この時点では「開発計画書」は不要でした。

しかし、eラーニングの展開が進み、開発規模が大きくなり、自分一人ではこなせなくなるとそうもいきません。まずは要員の確保をしたり、場合によっては外注もしなくてはならなくなりましたが、そのためにはどのような作業がどのようなタイミングで発生するかを上司に稟議したり、部署全体に示し調整をする必要が出てきました。

また、確保できた要員や外注先に、作ろうとするもののコンセプトや仕様、業務の流れといったことを説明し、どの作業をいつまでにしてもらうかを指示し、進捗状況を管理する必要も出てきました。そして、そのためにも、今までであれば自分の頭の中にあった与件や事情、「こういうものにしたい」という願意やアイディアを整理し、可視化することが不可欠となりました。

かくして、一人でやっている間には不要だった開発計画書が、eラーニングの仕事がうまく回り始めると同時に必要不可欠なものになってきたというわけです。

さて、こういったことから、開発計画書は何かを考えてみましょう。

「何のため」は言うまでもなく、開発や導入を成功に導くためです。（何が成功かは、案件毎に定義する必要がありますが・・・）

「何をする」についても様々なことが考えられますが、おおむね次の2つに整理できると思われます。

第一には「したいこと」「すべきこと」を整理・吟味することです。与件（条件）の明確化・アイディアの整理などがこれにあたります。

第二には「したい」「すべき」を関係者に伝え、検討・開発を進めることです。決定権者から開発許可や予算・要員を得る、関係者に開発するプロダクツのイメージを示す、プロジェクトを進行する（分業・協業する）といったことがこれにあたります。

このための「どのように」つまり、示すべき内容や構成要素としては

• だいたいどのようなものか、目指すものは何か→概要
• 制約などは何か→仕様
• どのようなプロダクツか→画面構成・遷移図
• どのように進めるか→プロジェクト管理（工程・スケジュール・WBS）

といったものになるかと思われます。もちろん、これ以外のものがあっても構いません。

 

なお、概要については「後付け」にされがちですが、実はこれが非常に重要だと講師は考えています。なぜなら関係者や学習者は「概要」からそのコースを知り、しかも「概要」だけが伝わっていくことが多いからです。実際、いろいろな書類の冒頭に「概要」が書いてあれば、そこだけを読むことは少なくないと思われます。

また、概要は「自分自身の思考の中心」としても活用できます。概要に自分なりのコンセプトがしっかり書いてあれば、様々な項目と概要（コンセプト）が整合しているかどうかをチェックしながら考えることで計画・企画に筋が通りますし、逆に項目を検討する中で概要（コンセプト）に修正・改訂が必要、つまり根本的な問題、例えば与件となっている開発条件や学習環境、あるいは定めた出口・入口との不整合があることに気づく機会も得られるからです。

そして、稟議書・提案書としての説得力を増すには理論的な裏付け、提案したり協業する相手の共感を得られる望ましさ、実現可能性を示す実績なども示すと良いでしょう。

 

開発計画書や企画書を書く際に、次のような点にも留意しましょう。

あるプロジェクトの専門家が「プロジェクトが100あれば、成功するものが10、失敗したものが10。残りの80は成功したか・失敗したかすら分からない。それはプロジェクトの基準や目標が不明確だからで、それこそが何より問題だ」と述べていました。

そうならないように、そのプロジェクトで、具体的に何を成果とするのか（どうなったら成功と言えるのか）、それをどのように評価するのかを述べておきましょう。これにより、プロジェクトの目指す方向を提案先とより明確に共有でき、プロジェクト終結時に提案先からプロジェクトに対する正当な評価を得ることができます。また万が一「失敗」したときにも、そこから次への教訓を得ることができます。

提案する上で、皆さんは「一押し」の解決策をお持ちだと思いますが、その「一押し」の解決策の良さをアピールするために、解決策は複数提示するようにしましょう。「自分としてはこの案をお勧めしますが、他にこういった別の案も考えられます」といった形で提示し、それぞれの長所・短所を比較することで顧客側の意思決定が支援でき、結果的に「一押し」案をよりアピールすることができるはずです。

その提案に伴うリスク、例えば人員・予算の不足、納期遅れ、予定通り修了しない受講者の大量発生といったことについて、それらを防止・軽減するための策、発生してしまった場合の対応策についても述べておきましょう。これにより、提案の実現可能性を読む側に判断してもらいやすくなります。

提案や企画の内容が適切であることを証明する行為つまり「正当化」（決して「こじつけ」ではありません）をするには、それらが適切である理由を示す必要があります。その強い味方のひとつが理論です。「この提案には理論的な背景がある」といったことを述べることができれば、楽に、そして強い「正当化」をすることができます。

せっかく勉強しているIDなどの理論です。ぜひ、提案にも活用しましょう。