【実践ローコードDX】APPFLOW・SALDで業績アップを実現する（4/5)

なぜ今、システム内製なのか

さて、ここまで述べてきたIT業界のメガトレンドともいえる「ローコード・ノーコード」ですが、こうした「ローコード・ノーコード」の普及により近年特に進んでいるのが「システムの内製」です。

そもそも、日本がデジタルで出遅れた要因の1つとして、「システムの外注志向」を挙げることができます。

例えば、米国ではITエンジニアの約7割がユーザー企業に所属しているといわれますが、日本の場合はITエンジニアの約7割がITベンダー企業に属し、約3割しかユーザー企業に所属していません（総務省『平成30年版 情報通信白書』より）。

つまり、デジタル先進国である米国と、デジタルで出遅れている日本は、ITエンジニアの所属先において全く逆の構造になっているのです。

ところが、今まで述べてきた「ローコード・ノーコード」を活用すれば、比較的容易に「システム内製」を進めることができます。

システムを内製するメリットは次の4つです。

メリット① 自社の仕事の進め方に合ったシステム開発ができる

例えば近年のコロナや、テクノロジーの進化によるデジタル化等によって、自社の仕事の進め方が変わることが想定されます。また、新たな事業の誕生働き方の多様化などによって、ビジネスプロセスの変化が早く、 大きくなっています。

このように、「仕事の進め方（ビジネスプロセス）」が変わった時に、システムを内製していれば、システムの変更も素早く対応することができます。

メリット② システム開発のスピードが大幅に上がる

当然のことながら、システム内製ができれば、システム開発のスピードが大幅に上がります。

例えば、現状の営業プロセスの中に、「インサイドセールス」という非対面の営業プロセスを追加することになったとします。その時、外部のシステム会社に追加で開発してもらうとなると、発注から納品まで、軽く1ヶ月程度はかかってしまうでしょう。ところが内製であれば、場合によっては即日テスト環境を作れてしまいます。

このように、システム開発のスピードが大幅に上がることが、システム内製の大きなメリットであるといえます。

メリット③ システム開発のコストが大幅に下がる

前述 のシステムの変更を外部のシステム会社に頼むと、作業が発生する度にコストがかかってしまいます。その点、ローコード・ノーコードでシステム内製ができていれば、システムの変更が生じてもコストがかかることはありません。

仮に、外注するような大がかりな内容だったとしても、メリット②で述べた通りシステム開発に要する工数が大幅に短くなり、システム開発全体のコストも大幅に下がっていくのです。

メリット④ 社内に開発ノウハウが蓄積される

システムを内製すれば、システムの開発ノウハウは全て社内に蓄積されていきます。

あるいは社内だけでシステムを完全内製できないにしても、社外の専門家から支援を受けながらシステム内製を行うことで、開発の進め方や開発するシステムのスペックなど、開発ノウハウは社内に蓄積されていくことになります。

つまり、自社のデジタル人材のスキルがどんどん高まっていくことになります。さらに、外部の会社とのやり取りを通して、プロジェクト推進スキルや社内調整スキルなども高まっていくことになるでしょう。

このようにシステム内製は、ただ工数・コストを削減するという効果だけでなく、デジタル・ノウハウそのものが社内に蓄積され、会社そのものの競争力が上がるという大きな効果を見込むことができるのです。

中堅・中小企業がDXに成功するための「5つのポイント」

システムを完全に外部に発注するにせよ、本書で述べている通りに内製を行うにせよ、その実施そのものがデジタル変革であることには、何ら変わりがありません。

私たちは、これまで400社を超える中堅・中小企業へのDXコンサルティングを手がけてきていますが、その経験から中堅・中小企業がDXに成功するためには次の5つのポイントを押さえる必要があると考えています。

①社長が覚悟を決め、自らも関与すると同時に、社内のエース級の人材をDXの中核人材として投入している。

②人海戦術や、少々の頑張りでは達成できないような、ストレッチした高い目標設定をし、また挑戦しようとしている。

③現場が成果を体感できて営業が楽になるなど、当初の段階で明らかに成果の上がる絵を描いた状態で臨んでいる。

④短期間で成果を上げ、 まずは小さな成功事例をつくり、現場の意見を聞きながら次々と新たな挑戦目標に挑む スタンスで取り組んでいる。

⑤5~10年後の経営体制をイメージし、 デジタル人材が経営トップと営業部門をサポートする組織体制を組み上げている。

ここからは、 その詳細を述べていきます。

成功するポイント①

”覚悟を決める”というのは、絶対に成功するまでやりきる、という強い意志を持つことです。そうした姿勢を社内外にも見せていくためには、社長自らの関与は必須になりますし、また社内のエース級の人材をDXの中核人材として投入する必要があります。

ここで、どのような人材を投入するべきなのかというと、一言でいえば所属部門のマネージャーが出し渋るほどのエース級社員を、システム内製のプロジェクトリーダーに据える、ということです。

一般にデジタル変革を行うとなると、何より「デジタルスキル」の有無に目がいきがちですが、 DXを進める上で大事なのは「変革スキル」の方です。

デジタル変革のことを、文字通り「デジタル・トランスフォーメーション(=変革)」といいますが、DXという言葉を構成する「デジタル」と「変革」のうち、必須のスキルが後 者である、ということなのです。

ここで言う変革スキルとは、「物事の本質を見抜き、成果を出すための最短最速の道筋を見つけ、周りを巻き込んで推進していく能力」です。そして、そうしたスキルを持っているのは結局のところ、現場のエース級社員なのです。

成功 するポイント②

DX(システム内製)を進めていくプロセスの中で、システム開発の目的・目標を設定するのは重要なプロセスになります。

ここで、成功事例で示された様々な成果の数値は、従来のビジネスプロセスの延長線上では到底不可能な成果ばかりです。必要があれば外部の専門家とも相談して、適切なチャレンジ目標を設定する必要があります。

成功するポイント③

SoE（システム・オブ・エンゲージメント:フロントオフィス・顧客まわり）といった、明らかに業績が上がる領域から手をつけていくこと。明らかに大きくコストダウンが可能な領域から手をつけていくなど、明らかに成果が上がるように取り組む、ということです。

その結果、実際に現場がDXの成果あるいは恩恵を肌で感じることができれば、会社の取り組みそのものに共感が得られ、次の展開 もより進めやすくなるといえます。

成功するポイント④

ローコード・ノーコードプラットフォームであるChatOps SALDの場合、例えばチャットボットやMA(マーケティングオートメーション)のような、限られたビジネスプロセス領域からDXを手がけ、その後にもっと広いビジネス領域をカバーしていくといった、「小さく始めて大きく育てる」というデジタル変革が可能になります。

その結果、短期間で成果を上げることができ、かつ現場の意見を取り入れながらよりブラッシュアップしていくことができます。 現場の意見を取り入れることで、デジタル変革そのものに対して、現場からより共感を得ることができます。

同時にこうした一連の取り組みを通して、現場のデジタルスキルも間違いなく上がることでしょう。

成功するポイント⑤

今、このデジタル変革に関わる中核メンバーというのは、間違いなく自社の5~10年後 の経営幹部となっているはずです。

また逆に、将来の経営幹部候補にこうしたデジタル変革に関与してもらった結果、前述のデジタルスキルに加え、より一層の変革スキルも身につけてもらう必要があります。

そうした観点で、5~10年後の自社の組織体制をイメージしながら、自社のデジタル変革を進めていく必要があるのです。

DX人材を育成する「教育プログラム活用のポイント」

社員の教育と聞くと集合型研修を想像しがちですが、デジタルスキル習得のための講座は、動画を個人ごとに視聴するeラーニング形式が適しています。これは個人ごとにデジタルリテラシーが異なるために、わからなくなるポイントが人によって違うからです。集合型研修であれば、個人ごとに合わせたスピードの調整が難しいですが、eラーニ ング形式であれば、受講者自身でわからない部分を繰り返し見て学習することもできす。 また、より効果的なトレーニングは、実際に自分で手を動かしながら体験するような「ハンズオン形式」と呼ばれるトレーニングです。 eラーニングを見てわかったつもりになるだけでなく、実際に手を動かして実践することで、自分で使えるところまで完遂させるのです。

実際に、船井総研グループの新入社員コンサルタントは、第2章で述べたChatOps SALD教育プログラム (Digital Enabler Training with ChatOps SALD) のeラーニングを視聴した後に、ハンズオントレーニングを行っています。ハンズオントレーニングはChatOps SALDを使ったチャットボットやMA、SFAやCRMの構築方法を習得し、部門配属しているのです。

ここでもう1つ、教育のポイントを挙げるとすれば「教えすぎない」ということです。 教育に熱心な会社ほど、多くのことを学習させようとしてしまいます。しかし、多くのことを教えすぎると消化不良になり、業務で実践することができないことで、かえってスキル習得が遅くなってしまうのです。

たくさん覚えてほしいのであれば、小さく分けて学習と実践のサイクルを繰り返すことで、一段ずつレベルアップしていく、そんな学習ステップを設計することが必要です。

システム内製はどこまでを社内で行い、 どこからを外部に依頼すべきか

システム内製といっても、必ずしも全てを自社で内製することにこだわる必要はありません。むしろ、質の高いシステムを完成させるためには、社外のプロ（外部パートナー）の力を利用することが賢明です。

ただしシステム内製を進める上での前提として、

①自社で主導すべきこと

②外部パートナーと共同で行うべきこと

③外部パートナーに任せるべきこと

の3つに作業を分けることができます。それを以下に述べます。

①自社で主導すべきもの

①–1デジタル化の戦略企画策定

会社として何を目指してデジタル化を進めていくのか、 その投資対効果をどう設計するのか、といったデジタル化の戦略企画の策定は、必ず自社でやるべき部分です。

もちろん、これまでやったことのないデジタル化を進めていく中で、 コンサルタントやシステムベンダーなど、様々な人にアドバイスをもらい知恵を借りることは悪いことではなく、むしろ積極的に情報収集すべきです。

ただし、自社の経営戦略の責任は、自社に帰されます。 経営戦略の根幹となるデジタル化の意思決定も、他人任せにせず、納得できるまで自社で検討し、 判断する必要があります。

①–2デジタル化の戦略企画策定

要件定義とは、「どのようなシステムをつくるのか」を決めることです。具体的には、システムにどのような機能を持たせて、どのように業務オペレーションを回すのか、を決めることを指します。

よく「つくってもらったシステムが使いものにならない」というトラブルを聞くこともありますが、そうしたケースの大半は要件定義の詰めの甘さが原因です。 どのようなシステムにするのかが、正確に外部のシステム会社に伝わっていないことが原因なのです。分析は、 外部のシステム会社に行ってもらうにしても、要件定義は自社で丁寧に検討して進めるべきなのです。

①-3 セキュリティ・インフラ管理

内製するシステムを載せるインフラ管理や、セキュリティ管理を行う責任者を社内で決めて、安全に使えるように するための対策は、自社で行う必要があります。

システム内ができるローコード・ノーコード開発プラットフォームは、社員でどんどん機能の追加や改修ができて便利な一方で、誤って本番環境のシステムを壊す。 情報を削除してしまうといったリスクもあります。

また、安定した通信環境の確保や、退職者のアクセス権限の削除、社員のパスワードが適切な強度になっているかの確認など、セキュリティ対策をしっかり行わなければ、悪意のある人から攻撃を受けて顧客情報が漏洩する恐れもあります。

こうしたリスクは大企業だけに限ったものでなく、中小企業に対してもIPA（独立行政法人情報処理推進機構）が「中小企業の情報セキュリティ対策ガイドライン」を公表しています。これらを確認し、適切な情報セキュリティ対策を行う必要があります。

②外部パートナーと共同で行うべきこと

②–1システムの基本設計

システムの要件定義に基づいて具体的なイメージを設計し、内容にズレがないかを確認する設計作業までが基本設計になります。

初めて導入するツールの場合、 どのような画面になるのかが十分にわかっていないため、外部パートナーの力も借りて、基本設計を行ってもらうことも多くなると思われます。例えば、そうした画面イメージを実際に使う現場メンバーにも確認してもらうなど、導入後の利用シーンでも違和感がないかを確認してもらいながら、基本設計を固めていくことが必要です。

②-2 プログラミングを伴わない開発（ツール設定）

外部パートナーは、基本設計に基づいてシステムの開発を行っていきます。

その中で、ローコード ・ノーコードツールで開発する場合は、プログラミングを伴わない開発があります。 こうした工程は完全に外部に委託するのではなく、 いくつか社内で 行ってみた方が良いでしょう。

開発の段階でツール設定に慣れておくことが、システム稼働後の細かい修正を社内でス ピーディーに行うことにつながります。

③外部パートナーに任せるべきこと

③–1 ChatOps SALD分析

システムでやりたいことが、 どれくらい実現できるかを確認するのがChatOps SALD分析です。

仮にローコード・ノーコードツールが社内に導入されており、新たな業務に当てはめてシステム内製する場合は、社内で実行できるでしょう。

しかし、新たなローコード・ノーコードツールでシステム内製を行う場合は、ツールの活用や設定、開発のノウハウが社内には十分にないため、実際にした経験やノウハウを持つ外部パートナーに任せるべきでしょう。

③–2 プログラミングを伴う開発

チェックポイント② 全体最適の提案：全体最適の視点で提案してくれるか

システムには、それを使って業を行うオペレーションも必ずセットになっています。システムでカバーできない部分はオペレーションで補うことになりますが、システムでできることが少ないとオペレーションの負荷がかかります。

反対に、事業の変化が早い場合、システムをつくり込んでしまうと、事業の変化についていけなくなり、システム改修コストが高くかさんでしまいます。

また、特定の部門やビジネスプロセスから始める場合に、全社への展開を構想しているか否かで、横展開できるようにテンプレート化を行うかどうかも変わってきます。

このような全体最適の視点を持ち、サポートを提案してくれる会社を選びましょう。

チェックポイント③ 成果へのコミット姿勢：成果にコミットする姿勢があるか

開発を請け負ってくれる会社はありますが、 システム開発を通じて実現したいビジネスの目的で理解し、一緒にコミットしてくれる会社はあまり多くありません。

システム開発でやりたいことは、エクセレントなシステムをつくるのではなく、ビジネスを成功させることのはずです。そのためには、単なる開発に留まらない会社を選ぶようにしましょう。

会社の規模によって、システムを利用する人数が変わってくるため、システムにかけるべき予算ももちろん変わっていきます。 また、業界ごとに商慣習があるので、自社の業界の習慣を理解してくれるかどうか、というのも大事な視点です。

自社と同規模・同業種での開発実績が多くある会社を選ぶことが重要なポイントの1つになります。

チェックポイント⑤ 投資対効果の算出：投資対効果の算出に協力してくれるか

システム開発を始める要件定義の際に、投資対効果を算出してから投資額を決めて、開発をスタートすることが一般的です。

この際に、同業他社での業績アップ事例や業務効率化事例など、 どれくらいの成果が出ているかの情報収集に協力してくれる会社を選びましょう。

なお、この成果を想定できない、もしくは知らない会社は、前述の③に記した「成果」あまりコミットしていない会社かもしれません。

チェックポイント⑥ 不要な開発の提案：必要と思えない開発提案をしてこないか

システム開発会社は、開発の仕事を受けてエンジニアを稼働させることで収益を得ています。したがって、ローコード・ノーコードツールであったとしても、追加 機能の開発や、他ツールとの連携機能の開発の仕事が取れると収益が上がります。

もちろん、追加機能を開発することでシステムの利便性は上がりますが、その分コストもかかっていきます。必要と思えない開発の提案が含まれていないかをチェックしましょう。

また、そのような提案を行ってくる会社は、顧客貢献よりも自社収益を優先している可能性があるので、注意が必要です。

チェックポイント⑦ 業績の推移：ベンダー自身の業績は伸びているか

ここまでご紹介したチェックポイントを満たすシステムベンダーは、実はそれほど多くありません。そのため、めぐり合うまでに時間がかかるかもしれませんが、シンプルでわかりやすい1つの指標が、ベンダー自身の業績が伸びているかどうかです。

なぜなら、この要素を満たす会社は重宝されるため、仕事が増え続け業績が伸びているはずだからです。

なお、営業担当者が非常に良いのに会社の業績があまり伸びていない場合、組織力が低く特定のハイパフォーマーな社員によって成り立っており、その後の開発工程では思うような人員を充ててもらえない恐れもあるので、注意が必要でしょう。

PMO 支援とは何か

システム内製とともに広がっているのが「PMO支援」です。この章の締めくくりに、PMO支援を活用したシステム内装について触れておきます。

まず、自社のシステム内においてキーパーソンとなるのが、プロジェクトマネージャー (PM) です。 プロジェクトマネージャーとは、担当するプロジェクトを成功に導くための計画立案から、進捗・品質・コストの管理までを担う責任者のことを指します。要は、幹事のような存在です。

例えば、社員懇親会の幹事に任命された社員は、企画や予算管理から、当日の運営までを行っていきます。具体的には、限られた中でどんなお店でどんな料理にするのか、当日はどんなイベントを行って楽しませるのか、イベントは出し物にするのか全員参加のゲームにするのか、サプライズゲストを呼ぶのか等を決め、会場の下見から関係者の打合せまでのスケジュールを決め、進捗の管理を行い、様々な調整を行いながら、社員に楽しんでもらうというゴールに向けて奔走していきます。

これが「社員懇親会を成功させる」というプロジェクトマネジメントであり、幹事は立派なプロジェクトマネージャーです（ちなみにプロジェクトマネジメントの適性がある若手社員を発見するために、宴会幹事を任せる会社もあります。 イベントの段取り力と、ブロジェクトマネジメント力はリンクしています）。

そして、こうしたプロジェクトマネージャーの意思決定や、決定事項のスムーズな進行をサポートするのが、プロジェクトマネジメントオフィス (PMO)という組織です。

先ほどの懇親会を例に挙げると、会場となるお店の候補を探したり、他の懇親会で盛り上がったイベントの事例集を行ったりすることで、幹事の意思決定をサポートする役割です。 また、開催日程を決めた後の出欠確認を行う、参加者からの集金を取りまとめるといった、スムーズに進行させるためのサポートを行うような役割もあります。

こうしたPMOの機能を代行する、あるいは支援するサービスのことを「PMO支援」といいます。近年はシステム内製がブームとなっていることもあり、この「PMO支援」サービスを提供するコンサルティング会社も増えています。

同時に、「PMO支援」サービスを利用するユーザー企業も増えています。

システム内製で「PMO支援」を受けるパターンは、主に次に記す5つとなります。

もちろん活用目的は1つだけでなく、複数のこともありますので、自社が必要とするものを想定しながら「PMO支援」の検討を行うのが良いでしょう。

①システム開発の進行支援

システム内製に慣れていない場合、失敗してしまわないように、システム開発の進め方そのものをアドバイスしてもらいながら進める必要があります。

この場合のPMO支援は、何をどの順番で進めるのかをレクチャーしてもらう形です。

②システム開発の技術支援

初めて使うローコード・ノーコードツールであれば、その設定・構築・開発方法について、技術的なノウハウを教えてもらいながら進める必要があります。

この場合のPMO支援は、他社での構築・開発のベストプラクティスを教えてもらい、利便性とメンテナンス性の高いシステムの内製をサポートしてもらう形です。

③アジャイル開発の推進支援

システム内製をアジャイルで行っていく場合、アジャイル開発の専門家に入ってもらい、開発計画の策定と進行管理を教えてもらいながら進める必要があります。

「アジャイルコーチ」や、アジャイル開発のフレームワークの1つである「スクラム」をレクチャーする「スクラムマスター」という専門職があり、スキルを認定する認定資格もあります。

この場合のPMO支援は、社内でアジャイル開発ができるように、進め方をサポートしてもらう形です。

④システムベンダーのコントロール支援

内装するシステムの一部を外注する場合、外部のシステムベンダーに明確に指示を出して、開発してもらう必要があります。

ただし、システム開発に慣れていない状況だと、上手に指示が出せないため、PMO支援の中で、指示出しをサポートしてもらい、開発してもらった機能の検収を行ってもらう形です。

⑤複数部門横断の進行支援

複数部門でシステム内製を進める場合、相互に連携しながら、同じシステムを二重に開発してしまわないように調整する必要があります。

この場合のPMO支援は、各開発プロジェクトのマネージャーと連携し、社内の複数部門の進行状況を管理し、ムリ・ムラ・ムダのないように社内調整を行っていきます。

現在NALでは、ローコード・ノーコードでシステム内製をChatOps SALDにも適用して、お客様に最高のサービス エクスペリエンスを提供しています。それらについて知りたい場合は、遠慮なく下のリンクをクリックして、NALへお問い合わせください！。

ローコード・ノーコードでシステム内製のChatOps SALD