企画者は、意思決定者から求められる前に、主導的に提案する

　企画者は、意思決定者から求められる前に、主導的に企画し、提案すべきだ。そのために準備するのが企画提案仮説だ。企画提案仮説は、次の項目から成るフレームワークだ。



　企画提案仮説は、企画者がその提案テーマを担当すると決まった直後から構築を開始する。そう聞くと、「現状を調査する前から考えても分からない項目ばかりだ」と反応する人がほとんどだ。しかし「分からない」と思うことの多くは「何種類も想定できて決められない」ということだ。それならばすべての場合を想定すればよい。企画提案仮説の構築は、上記フレームワークの問いに、シンプルに答える短い言葉を準備することだ。だからすべてのオプションを考えることに時間がかかる訳ではない。要は、自分の脳みそに蹴りを入れて、徹底的に考えるか否かの問題なのだ。

企画提案仮説の骨格を成す項目

　企画提案仮説の骨格を成す項目について、以下に解説する。

提案の落としどころ：Ⓐ
　特に初期仮説の構築段階では、分からなくてもまず考える。この項目を設定することで、以降の①～⑮の項目の検討にリアリティーがでる。落としどころは、①～⑮の項目の検討後に見直し、想定できる落としどころが何種類かあれば、①～⑮の項目もそのバリエーションの分だけ検討する。

キー・イシュー（KI：意思決定者の悩み）：①～③
　前回（第4回）で解説した、意思決定者が抱く業務改革推進上の悩みだ。キー・イシューを検討するフレームワークは、②社内外の重要事実、③意思決定者の意思、ILやKIの知識・外部の先行事例から、全体発想で創造する。

イノベーション・ロジック（IL）：④、⑤
　第3回で解説した、リターンを生み出し、投資効果を高める業務改革のロジックだ。我々でも、提案の初期仮説で考えるイノベーション・ロジックの半分はウソだと考えるので、20前後のイノベーション・ロジックを準備する。イノベーション・ロジックはいくら腕を組んでうなっても出てくるものではない。日頃から事例の知識の蓄積を怠ってはならない。また、美辞麗句は通用しない。シンプルにリターンの出るところまで突き詰めることが重要だ。初期仮説の段階では、⑤効果を実証するファクトは準備できないこともあるが、まず不確かな仮説であっても手を抜かず、④イノベーション・ロジックを「他にないか」と自分に言い聞かせて検討する。

システムビジョン（イノベーション・ロジック実現のためにシステムと業務をどのように革新するか）：⑥
　システムビジョンとは、イノベーション・ロジックを実現することで業務とITがどのようになるのか、目指す姿の仮説だ。ここでシステムとは、コンピュータシステムに限定したものではない。人が遂行する業務で道具であるITを使って、システマティックにリターンを上げ続ける仕組み全体のことだ。システムビジョンは、求められる提案によって検討すべき中身は異なるが、汎用的なサブフレームワークは存在する。

表1　システムビジョンのサブフレームワーク
項目	説明
組織	新設すべき組織や変更すべき組織構造
制度	報告・意志決定ルール、評価制度など
資源配分	組織、業務間の工数や人員数の配分、連携する業務機能間の時間配分など
主要情報と業務プロセス	キーとなる情報要求と業務の流れ
主なIT機能	業務プロセスを支援するIT
人材レベル	業務遂行に必要な人材の能力
リーダーシップ	トップや現場リーダーのリーダーシップ

　例えば、開発購買の質と量を拡大するイノベーション・ロジックのシステムビジョンを考えてみる。専任組織や会議体の設置、基準類の見直し、開発プロセス、部材、調達先、調達方法などに精通したスキルセットの定義、開発購買を織り込んだ開発プロセスの標準化、グローバルな開発購買に関するDBなどが、このイノベーション・ロジックの目指す姿として想定される。

　システムビジョンの検討において、システム部門の若手に見られる傾向は、組織や資源配分、人材レベルなどの項目を、無意識に考える対象から外すことだ。自分たちが口を出すべき対象ではないという思いが背景にあると考えられる。しかし資源配分の変更が求められるイノベーション・ロジックは多く存在する。また求められるIT機能は、一定水準のスキルを前提にした場合とそうでない場合で、ITの投資額が大きく開くことも珍しくない。無意識のタブーを置かず、意思決定者のつもりで最適を考えるべきだ。

ビジョン達成課題（意思決定者はどのような課題指摘（反論）をするか）：⑥～⑧