IT戦略策定の実際

# はじめに
　昨今、DXという言葉が氾濫し、多くの事業会社の経営幹部も流行に遅れまいとして、あるいはその期待される生産性向上の機会を自社だけ逃してしまわないようにという思いから、何を道具に、何を目標にしてDXを進めていこうか真剣に検討していることと思う。
　そして、とりあえずDXはシステム部門にお願いしてみようと言うことで、「DX検討しておいてね」と依頼されている読者の方もかなりいるのではないかと思う。
　本来DXとは、紙や言葉などで行われていたコミュニケーション（申込みとか承諾とかのビジネスの手続きも含む）をデータに置き換えようということであり、それをデータにすることにより、手続きの効率化、顧客エクスペリエンスの向上やマーケティング等の販売促進を実現するものである。またデータ化することにより、コミュニケーション手段の多様化をもたらし、新たなビジネスの展開を可能にするものでもある。
　この定義と、単なるシステム導入や開発とどう違うのかという議論はさておき、伝達手段がデジタルになることによりどう変化するだろうかという意識で考えるのは、システム化をどうしようかと単純に考えるより発展性があり、新しいビジネスモデルにもつながる可能性がありそうなのは確かである。
　つまり、IT戦略を考えるとき、以前よりもより視野を広げて考えなければならなくなっていることは確かである。そこで私が実際にIT戦略を策定した経験を基に、そのときに考えた方法や成果物について以下に記述したいと思う。もちろん完全ではないし、別の次元の考え方もあるだろうが、皆さんがIT戦略を考える立場になったときのヒントにしてもらえれば幸いです。
# 1.IT戦略の視点
### 1-1.少し前の時代のIT戦略
　IT戦略といわれるものは、メインフレームの時代からいわゆるオープン系と呼ばれるPCサーバーが活躍を始めた頃から耳にするようになったと思う。この時代も、パンチしたデータをホストコンピューターで主にバッチ形式で処理するしかなかった時代から、PCやPCサーバー、またはunix系のサーバーの上で動く様々な製品を組み合わせてシステムを動かせるようになってきた、まさに変革期であった。
　この時代には、アーキテクチャーやハードウェアの選択肢が増えたため、どのようにシステムを構築するのがよいのか、TCOと呼ばれるシステム関連の調達費や構築・維持・運用も含めた総費用の観点、開発のスピードの観点などからIT戦略を考える必要が出てきた。それに加えていろいろな製品を組み合わせて、主に社内ユーザーの生産性を上げようという視点も加えられるようになったと思う。
　ただ、ここでの視点は、ほぼシステムを構築する側からの視点であって、システム部門が主体となって考えるIT戦略であったと思う。
### 1-2.現在のIT戦略
　現在はというと、さらに変革が進み、お客さまがスマホでコンピュータを携帯し、誰とでも即時に、音声のみならず、画像やデータを利用してコミュニケーションができる時代になった。かつ、ニューラルネットワークの出現により画像処理や言語処理分野、またはマーケティング分野などでAIがかなりの精度でかつ簡単に利用できるようになった。また、システム自体においても、クラウドの普及により、持たざるシステムも可能になり、一時代前の変革を凌駕する変革が起きているのである。
　ここでIT戦略を語るとき、システムが直接お客さまと関わるようになり、システムの扱うデータも、会社の製品やお客さまから頂戴したデータだけでなく、見込み客のデータやその他一般の人の行動のデータなどに範囲が広がり、かつ音声や手書き、さらには顔などもデータに変換しシステムで扱えるようになっている。また、工場などの現場ではIoT機器が稼働し、これらからも様々なデータが送られてくるようになっている。これらのデータを利用して経営に役立つシステムを作ろうと考えたとき、システムが主体となって考えられる部分は限られ、経営戦略をシステムがどのようにサポートできるか、またシステムの技術で経営戦略の一部を構築できないかという課題を、経営または企画部門等の多くのステークホルダーの参加により検討することが重要になってくるのである。そこで、次に、どのような視点からIT戦略をまとめていくかを考えてみる。
### 1-3.経営課題の視点
　ひとつの視点は、経営課題、すなわち会社は何を解決しなければならないのか、また何を目標にどのような施策を行おうとしているのかをシステムがどのように解決・支援できるかという視点である。
　それは事務の生産性を向上しなければならないとか、多くの種類の商品を短期間で出荷したい等のような従来型の課題もあるであろう。しかし現代のデジタル社会にあっては、データやコミュニケーションツールを利用して、顧客との接点の改善、商品の開発や生産・売り方のプロセスを変える等、いわゆるデジタルによるビジネスモデルの変革というチャレンジ的な経営課題が加わってきたのである。
　そしてこれらの経営課題を解決するために中長期的にどのようなシステムを作っていくか、または利用していくかの視点も非常に重要になってくるのである。
### 1-4.新技術の視点
　上記のように経営課題からの視点のみでIT戦略を考えたときの欠点は、新しい技術や、巷で利用されている技術を応用して新たな課題（チャレンジ）を提起する視点が弱い点である。
　すなわち、新たな技術や一般に普及しつつある技術を利用して、新しいビジネスモデルを構築できないかという視点を強化しておくことが、他社との差別化が図れる経営戦略につながることになる。
　もちろんそういう情報に明るい経営幹部を抱える若い会社は例外かもしれない。ただ、皆さんの周りの企業を見てもおそらく感じることであろうと思うが、これを意識するとしないとでは会社の成長戦略に大きな違いが出てくる。このような、新技術により経営課題を解決できないかという考えをIT戦略を立案する立場の部門は常に持たなければならない。
　このような技術からの視点をカバーするため、コンサルタントに任せたり、ビジネスアイデアのコンテストを開催したりなどの手段を講じているところもあるが、これらの技術の可能性と経営の課題をすりあわせ、自分の会社で戦略を立て自身で実施することは、会社としてのアイデンティティーを確立し、モチベーションを維持し、変革のDNAを引き継いでいくのに重要ではないであろうか。
　この技術側からの視点は、どんな技術がどんなところに応用されているかをウォッチしておくこと、および企画部門等と情報共有しておくことが大切で、そのような共有する仕組みを作っておくことも戦略の一つかもしれない。私の場合はIT戦略の成果物には常に技術マップ表をつけ、営業支援、マーケティング、バックオフィス支援、商品開発などの分野別に、応用できる技術と、どのように世間では応用されているかを図表にしていつでも共有できるようにしていた。
### 1-5.IT基盤や組織の視点
　これは従来型のIT戦略の視点と言ってもよいであろう。すなわち、どのようなシステム基盤でシステムを動かすのか、それにどのような開発体制や保守体制を目指すのかといったものである。しかしシステム基盤のありかたも、集中型、分散型、メインフレーム中心、オープン系などの旧来のカテゴリーでは分類できないほどに複雑化している。今やそのような分類に加え、Webサービスなどによるインターフェイスの改善、仮想化、またクラウドなどの要素が増え、かつクラウドに関してはIaaSからSaaSに至るまでの選択肢やアプリケーションの開発・デプロイの方法の選択肢も様々あり、どのような基盤が最適なのかを判断するのは非常に難易度の高いものになっている。しかしながらこれらを上記で述べた２つの視点から派生した戦略的な目標と整合する形でまとめていかなければならい。
　さらにはITのセキュリティー対策は予算のかなりの割合を占めるようになり、無視できないものとなっている。
　アプリケーション開発についてもしかりである。開発言語やフレームワークなどの選択肢も増え、かつパッケージ製品やルールエンジンなどの開発支援ツールも次から次へと出現してきている。そして、開発方法論も、ウォーターフォールやプロトタイプからアジャイルと進化してきている。またRPAなどのエンドユーザーツールもあれば、AIインターフェイスをクラウドで接続するなど材料は豊富すぎるほどに存在するのである。
　これらの新しい基盤を導入する場合には、システム部門の組織もどうあるべきか、つまり、開発や基盤構築、運用保守という枠組みを維持することが必ずしも効率的でないケースもありえる。その場合組織体制を変える要も出てくるかもしれない。
　IT戦略において、現行踏襲でない新しい基盤を導入すると決断するのは、非常に勇気のいる仕事となってきている。基盤がもたらす効率性や開発スピード、保守容易性に加え、外部との接続の容易性などを吟味し、持続可能な基盤にする予見性がさらに重要になる。
### 1-6. 各部門の開発ニーズの視点
　IT戦略のような大きな視点からの指針がなかった時代においては、企画部門が各部門のシステム化の要望を集めて、コストを見積もり、優先順位を決めるという手順で年度単位のシステム開発計画を立てているところが多かったのではなかろうか。IT戦略においても、各部門のニーズを組みとることは重要なことに変わりはない。
　ただし、IT戦略においては、先に述べた経営戦略の視点と新技術の視点から考えられた大きな枠組みの中で、どのような開発案件を優先するか、またどの程度の投資をするかを考えることが求められる。逆に言えば、個々の開発案件が会社をどのようにしていきたいかというビジョンにどれだけ貢献するのかを考えることである。
　一点注意しなければならないのは、最近各部門がIT開発、またはITのサービスを直接委託することが多くなってる。これは、技術が専門化し、得意な分野を持つ会社がそのサービスを各社に提供するようになったことが要因としてあげられる。AIを用いたサービスや、スマホのアプリといったものがその例であろう。これらを各部門が各部門の利益のために独自の予算で推進することを認めるのか、ITの戦略として投資の優先順位に含めるのかは、IT戦略の中で明確にしておかなければならない。理想としてはIT戦略に含めて、会社全体のIT関連投資に一貫性を持たせた方がよいと考える。

# 2.  IT戦略のスパンと改訂
### 2-1. 戦略のスパン
　IT戦略はどのぐらいのスパンで計画するのがよいであろうか。経営戦略または経営計画というものがあれば、それに期間を合わせるのがベストである。なぜなら経営戦略とIT戦略はともに会社の目標および投資の優先順位を決める基準になるものだからである。ITだけ考えれば３年から５年が適切な期間であろう。すぐに要件を詰めて開始できるものもあれば、PoCのような実験やフィージビリティースタディーを経て実施するものもあるだろうし、そもそも長期間かけて目的を達成させるような計画もあるだろう。ただし、５年以上先を見据えるのは逆に計画の実現性を疑うものになる恐れがある。
### 2-2. 戦略のレビューと改定
　IT戦略を策定し、取締役会などで承認を得た後は、経営戦略や計画と同様に毎年、計画の進捗のレビューと、会社を取り巻く環境の変化による見直しが必要かどうかを検討し、必要に応じて改訂を行うべきである。特に戦略の前提となる方向性や、後に述べるカテゴリー別の投資枠の見直しを行うといったインパクトの大きい見直しに関しては、取締役会の承認事項とするなど予め決定しておくことが望ましい。また、年度単位のレビューのタイミングで、もう１年計画をスライドさせて、常に５年先までを見据える計画とすることもできる。このやり方の方が、常に途中の年度から発生する案件が戦略期間内に終わらないものが出てきたときの処理が簡単であり、計画の見直しが容易になるので望ましいと思うが、経営戦略等との整合性もあると思うので、状況によってやりやすい方を選択すればよい。

# 3. 投資枠の設定
### 3-1.カテゴリー別開発投資枠
　IT戦略の方針を具現化するためには、どのような分野にそしてどのようなシステムにどれだけ投資するかを明示しなければならない。カテゴリーの例としては、営業支援、顧客接点、マーケティング、バックオフィス支援、商品開発、サプライチェーンなどがあると思うが業種によって異なると思うので、これは自身で考えて欲しい。
　これらのカテゴリーの優先順位は、経営課題の視点と新技術の視点を癒合した経営戦略に基づいて決定することになる。ここがIT戦略においてステークホルダーが一番関心を持つところであり、日本においては根回しが必要なところである。その優先順位ごとに投資の上限を割り当てていくことになる。そこに計画時点で主にチェレンジしようとする戦略的な案件の概算費用を入れ込み戦略をより明確にする。その他の開発案件は、その投資予算枠内にて後日検討調整することでよいと思う。なぜなら、IT戦略はあくまでどのようなことに重点的に取り組むかの方針であり、この方針の承認を経て全体の開発計画を立てるのが適切であるからである。
### 3-2. IT全体の投資枠
　カテゴリー別の投資枠とは別に、ITの投資枠全体を設定するのがIT予算の肥大化を防止するために必要であろう。ここには新規投資でない基盤の保守、アプリケーションの保守、情報セキュリティーの関連費用などを含める。アプリケーションの保守の定義であるが、不具合や制度の変更による変更など、それが会社の利益に直接つながらない経費処理されるような対象を指す。
　やはり日本においては保守の比率が高いため、この費用の大きさと、ここを改善してより生産性の高い分野に費用を振り向ける施策の重要性を経営にも認識させるためにもこれらを含むのが望ましいと考える。
### 3-3. IT基盤の新規投資
　この全体の投資枠にはその他、IT基盤の新規投資や更改費用を含める。IT基盤の新規投資については、カテゴリー別投資枠に入れてもよいが、経営戦略とは別の要素（中長期的なIT自体のの効率化や開発サポートの充実、情報セキュリティーなど）があるため、ほかの優先順位とは違う観点からその必要性を判断してもらいたいと考える。そのため、投資枠とともに、別途今後のIT基盤のあり方を説明するのがよいであろう。
### 3-4. 研究開発費
　最近、PoCという考え方が浸透し、新しい技術を本格利用する前に小さいスケールで実施して効果の検証を行うケースが多くあり、これを予算化する必要がある。ただし、PoCといえどもその必要性は会社の方針に合致するかという吟味は必要なので、研究開発という位置づけでその予算枠と目的を説明し承認を得るべきである。この費用を全体枠に含めるか、カテゴリー別投資枠に含めるかは、それぞれの判断でよいと考える。
### 3-4 予備費
　IT戦略を５年程度のスパンと考えると、当然環境の変化により新たな投資を行わざるを得ないことがある。このため、予備費的なものをある程度は組み込むのがよいかと思う。それを超えてIT全体の投資枠を超える場合には、取締役会の承認を必要とするなどにしておくと、ある程度の予算的な余裕ができる。
# 4.　IT戦略のまとめかた
### 4-1. 成果物の構成例
　　　成果物の構成(目次）の一例を示す。
　　　１．方針
　　　　　1-1. IT戦略の考え方とIT投資の方針
　　　　　1-2. IT戦略の期間
　　　　　1-3. レビューと改訂の承認手続
　　　２．開発カテゴリーと優先順位の考え方
　　　３．各開発カテゴリーと投資計画
　　　　　3-1.各カテゴリー別の主な開発計画
　　　　　3-2.投資枠（今後の案件の枠を含む）
　　　４．全体投資枠
　　　　　4-1. システム保守費用
　　　　　4-2. IT基盤案件
　　　　　4-3. 研究開発費
　　　　　4-4. 予備費　　　
　　　５．システム基盤案件
　　　　　5-1. システムアーキテクチャー
　　　　　5-2. 組織体制
　　　　　5-3. 投資額
　　　参考　分野別技術応用マップ
### 4-2. 構成例の説明
##### 4-2-1.　「１，方針」について
 ここでは、IT戦略がどのような背景と考え方によって、どこに重きを置いて投資するかを俯瞰的に述べる。会社の置かれた社会的状況や競合他社の状況、そして会社の経営戦略はどのようなもので、それにITがどのように関わり、どこをサポートするのが重要になってくるのか。また、なにかしらのIT技術を応用して課題解決に向けた取り組みを行おうとしていることなど、まさしく方針または指針と言うものを述べる。
　この方針にそって、カテゴリー別に投資する優先順位を決めているということになるので、一番重要であり承認手続き前にステークホルダーとも合意を得ておくことが望ましい。
　さらに、IT戦略の期間と、毎年の進捗のレビュー、およびレビュー等によって改訂が必要になった場合の手続き等を記述する。
##### 4-2-2. 　「２，開発カテゴリーと優先順位の考え方」について
 ここでは、上記の方針に沿って、どの分野にどのような投資を行い、そのために投資がどの程度になるかという大雑把な説明を行う。その期待される効果が具体的にわかれば、それを記載するのが望ましい。
##### 4-2-3. 　「３, 各開発カテゴリーと投資計画」について
 ここでは、カテゴリー別に主な開発と概算費用を記載する。それに加え、今後とりまとめる開発案件を含めて投資枠としてどの程度とするかを記載する。以下の要領でで記載する。
　●費用と投資枠は年度単位に記載する。また当該IT戦略期間中に修了しない場合、全体の投資金額を説明する。
　●金額は案件ごとに開発全体を通しての概算金額を示すとともに、キャッシュベースで、年度ごとに記載する。
　●カテゴリー別の投資額は、IT戦略の期間全体で考え（例えば５年間）、カテゴリー別の総投資額を決める。この額がカテゴリーの優先順位になる。
　●ただし年度単位の予算枠も、主な開発と、後にまとめる開発案件を合わせて上限を決めておくと年度単位にその他の開発案件を取捨選択するため、また投資の妥当性などをレビューするために便利である。
　●また償却額は全体の会社計画との整合性を見るために必要であるので別途用意するなどしたほうがよい。

　このあたりのまとめ方は、この方法にこだわる必要はない。何を優先しているかがわかればよいのである。できるだけ表で表すのが望ましい。
##### 4-2-4. 　「４，全体投資枠」について
　ここでは、IT関連の総投資枠を説明する。システム保守費用、IT基盤への投資、研究開発費用、予備費をここで加える。各カテゴリー別同様、IT戦略の期間全体と、年度単位のものがあるといいだろう。例外的に、IT戦略の期間内に開発が終わらないものが出てくると思われるのが、それは５年間の必要な費用で予算枠内に収まるかどうかを判定し、その後の費用の説明を加えることで了解を得るようにすればよいと考える。その後に発生する費用が極端に大きくならなければ、決めた優先順位内の開発の継続であると割り切れると思う。
##### 4-2-5.   「システム基盤案件」について
　ここでは、どのようなシステム基盤を会社で推進していくかについて説明する。その一つはシステムのアーキテクチャーであろう。今やアーキテクチャーも自社内のみで完結する時代ではなくなっているので、開発手法や外部のサービス利用や接続を考えた上でのアーキテクチャーになると考える。そして、そのような開発手法やアーキテクチャーを推進するのに最適な組織体制を記述すべきと考える。そしてそれらの推進や体制維持に関する費用に加え、システム保守や更改の費用、セキュリティー対策の費用などを含め全体投資額へ追加する。
##### 参考資料　分野別技術応用マップ
　これは、1-4.で述べたが、経営戦略やそれが目指すビジネスモデルの参考にするために、現在世間で応用されているITの技術を、営業支援、マーケティング、バックオフィス支援、商品開発などの分野別に分け、その応用されている技術と、どのように世間では応用されているかを図表にして、経営や企画部門と共有するためにIT戦略でも参考資料として添付する。
# 5. その他システム案件の整理について 
　IT戦略では、戦略的な主な案件について記載するが、ユーザー部門が抱えるその他のシステム開発案件については投資枠内で後日整理することとした。これは年度ごとに、IT戦略の投資優先順位を踏まえ、その案件のカテゴリーの投資枠内で取捨選択して別途開発計画を策定することになる。もし投資枠を超えるような計画になった場合には、その承認を得る手続きを決めておくことが望ましい。

# おわりに
　文章のみになり、読みにくい資料になってしまいました。書きたいことはもっとあるのですが、どんどん冗長になるような気がして少し抑えました。ただ、IT戦略関連の本を読んでもしっくりこなかった私が、IT戦略を取締役会に諮るに当っていろいろ考えた成果を少しでも皆さんに知っていただきたく一生懸命まとめてみました。いろいろご批判はあるでしょうが読んでいただいた皆様に感謝申し上げます。