ローコード・ノーコードによるシステム内製のポイントと、8つのステップ
では、こうしたローコード・ノーコードを活用して、いかにシステム内製を進めていけば良いでしょうか。本章では、ローコード・ノーコードによるシステム内製を、8つのステップに分けて解説していきます。
この8つのステップは、デジタル変革プロジェクトを進めていく一般的な流れでもあります。
従来のシステム開発のプロジェクトはSOR（システム・オブ・レコード: 基幹系）領域が中心であり、いわゆる「ITの知識」主体で進めていくことができる世界でした。
それに対して、ローコード・ノーコードによるシステム内製の場合は、SoE（システム・オブ・エンゲージメント: 顧客まわり）領域が主体になることから、従来の「ITの 知識」だけでなく「ビジネスの知識」も必要となり、ビジネス現場の関係者も巻き込みながら、良い意味での試行錯誤（改善）を繰り返しつつシステム構築を行っていくことになります。
また、SOR領域をローコード・ノーコードでシステム内製を行う場合は、既存システムからの置き換えや、既存システムとの連携といったケースが多いといえます。従来のシステム開発の場合は、あらかじめ立てられた計画（要求・要件）通りに開発することが前提でした。しかし、ローコード・ノーコードによる開発の場合は、いちはやく試作品を完成させて、テストを繰り返すことでシステム全体を完成させることが前提です。
こうした観点で、従来のシステム開発のステップと、ローコード・ノーコードによるシステム内製のステップはニュアンスが若干異なるところがあります。
各ステップについて、まずは概要から述べていきます。
ステップ1 システム開発の目的・目標の設定
システム開発が内製の場合であっても、あらゆるプロジェクトは目的・目標の設定が必須です。
SoRの領域であればコストダウン、あるいは工数削減が目的であり、数值（KPI）での目標設定が想定されます。また、SoEの領域であれば集客数・商談数・受注件数の増加が目的であり、同様に数値 (KPI) での目標設定が想定されます。
ステップ2 既存システムのビジネスプロセス・機能の洗い出し
既存システムだけでなく、人手による入力作業や確認作業も含めて、ビジネスプロセス・機能を洗い出します。洗い出したビジネスプロセス・機能は、業務フローや相関図、各種フレームワークなどを活用することで全体を可視化し、課題や問題点を整理していきます。
ステップ3 フィット&ギャップ分析
ビジネスプロセス・機能を洗い出したものに対して、導入を検討している製品やサービスがフィットしているのか、それともギャップがあるのか判定し、適合率やコストなどから比較・検討していきます。Appflow・SALDは、全てのビジネスプロセスを網羅していることから、他のプロダクトと比較して適合度は高く、またコストパフォーマンスも非常に優れています。
ステップ4 要件定義
要件定義では、どのようなシステムをつくるのかを決定し、システム全体の内容を要件定義書として取りまとめます。要件定義書に記載する内容としては、次のようになります。
・システム概要
・システム化業務フロー
・業務全体図、システム構成図
・機能要件、非機能要件
ステップ5 プロトタイプの開発
プロトタイプの開発では、要件定義した内容に沿った試作品をつくることで、早い段階で画面イメージを確認することができるため、認識の齟齬を減らすことができます。Appflow・SALDでは、GUI（グラフィカルユーザインターフェース）の操作で画面やレポートを簡単に生成できるので、プロトタイプ開発に向いています。
ステップ6 既存システムとの並行活用とトラブルシューティング
既存システムから新システムへの切り替えには、リスクが伴います。例えば、移行したデータに不備があったり、システムの操作に不慣れで誤操作したりすることが想定されま す。そのようなトラブルを回避するため、新システムを並行活用することでリスク軽減を図ります。
ステップ7 リプレイスの実施
ITでのリプレイスとは、既存システムから新システムへ置き換えることを意味しています。既存システムを利用していない場合、そのまま新システムを利用できますが、既存システムを利用している場合、先のステップで述べたとおり、並行活用で検証した上で、リプレイスを実施することになります。
ステップ8 運用
リプレイスの実施後は、システムを運用していくことになります。運用にあたっては、システムの操作説明書や運用手順書などの準備、利用部門への操作説明会の実施、問合わせ窓口の設置や運用保守体制の確立が必要となります。
以上の8ステップを経て、システムの内製化によってDXの実現ができるようになります。ここからは、各ステップについて細かな点までご説明していきます。
ステップ1 システム開発の目的・目標の設定
あらゆるプロジェクトの推進には目的・目標の設定が必要です。
特に、システム開発の場合は、それがローコード・ノーコードによるシステム内製の場合であっても、会社のトップあるいは組織のトップが、今回のシステム開発で何を実現するかといった目的を明確に示す必要があります。
各機能の目的については、トップではなく、各機能の主担当に検討してもらうようにしましょう。責任や権限に応じたメンバーが各機能でそれぞれの目的を策定することで、各社員にオーナーシップが生まれ、デジタル変革を推進する上でモチベーションが高まり、プロジェクトがスムーズに進むようになります。
また、重ねて強調すると、こうしたデジタル変革のプロジェクトというのは、得てしてプロジェクトが進むにつれ、「デジタルツールを導入することそのもの」が目的化されてしまい、そもそもの目的・目標が忘れ去られがちになります。
デジタル化はあくまで手段ですが、それが目的になってしまうと、本来果たすべき目的・目標が果たせなくなることになってしまいます。
この「目的」を立てる際、よく「目的」と「目標」が混同されがちですが、システム開発でいう「目的」とは、なぜその開発費用を投資する必要があるのかを、課題に対して一言で説明できるものを指します。
例えば、「顧客からの問合せ数の増加に伴い、エクセルによる問合せ管理が煩雑化、連絡漏れが発生している」という課題に対して、「問合せ対応を適切に行うことによる、問合せ管理、営業管理の効率化」といった内容は目的といえるでしょう。
これに対して「目標」とは、目的を達成するための具体的な目印になります。
前述のケースでいうと、例えば「入力事務の時間を○割削減する」といったことが目標になります。ただし目標設定の根拠が乏しい場合、逆に現場のモチベーションを下げてしまうことがあるため要注意です。きちんとしたシミュレーションを行うなど、適切な目標設定が重要なポイントになります。
繰り返しにはなりますが、目的と目標を設定する際、注意しなければならないことは「新たなシステムを導入する」ことが目的ではないということです。
「そんなこと当たり前だ」と思われるかもしれませんが、現実問題としてシステム導入の現場では、システムを導入することが担当者の中で先行してしまい、とにかくシステムをスケジュール通りに稼働させるために実装するシステムの一部を削減したり、使用者の理解を得られていない機能を実装したりしてしまうケースが発生します。
また、「入力事務の時間を○割削減する」という目標に集中するあまり、そもそもその入力業務自体をなくしてしまうといった、抜本的な見直しが見過ごされてしまうこともあります。
こうしたことを防ぐためには、システム内製においても「担当者の目線」だけではなく、「社長の目線」あるいは「組織TOPの目線」が必要です。
既存の業務ありきで発想し、その時間短縮だけを目指すのではなく、不要な業務プロセスそのものを廃止したり、統廃合したりすれば、本来の「目的」である「問合せ対応の効率化」をより劇的に進められる可能性があります。
Appflow・SALDの導入も含め、システム内製は目的を達成するための手段に過ぎないというこ とを忘れず、常に「目的」や「目標」に立ち返ることが必要です。
ステップ2 既存システムのビジネスプロセス・機能の洗い出し
目的と目標の設定が完了し、続いては既存システムのビジネスプロセス・機能を明確化します。これらを明確化させることで、目的を達成する上での業務上のテーマ、使用者（ユーザー）のニーズ、改善点といった「課題・問題点」を明らかにできます。
洗い出したビジネスプロセスや機能は、業務フローや相関図といったフレームワークを活用しながら整理を行い、課題・問題点を検証していきます。そして最終的には、その課題・問題点を解決する具体的な施策や、理想的な業務フローを定義していきます。
そのためには、まず自社の業務全体を1つの図で見渡せる「業務全体図」を作成することが望ましいといえます。現在の業務状況を把握するために、「As Is (現状の姿)」の業務全体図を作成することが重要です。この図を作成することで、業務における課題を特定できるだけでなく、関係者間で業務全体像を共有することができます。
業務全体図の作成方法については、業務の担当者や関係者、部署を縦軸に配置し、それぞれが担当する業務をマッピングしていきます。マッピングする業務は、ヒト・モノ・カネ・情報を「関係者」や「システム」の間でやり取りしている業務になります。
業務全体図の作成が完了した後は、各業務の詳細を説明する「業務一覧」を作成します。業務を大きく分類し、分類ごとに詳細な処理を具体化し、一覧表に整理します。
この際、大分類、中分類、小分類といった階層を意識して整理を行うことで、抜け漏れがなく業務を洗い出すことができます。例えば、発注管理といった大分類から、発注データの登録、発注書の作成・印刷などの詳細な業務を中分類、小分類として洗い出していくような形です。
また、洗い出しの際は、どの部署や役割の人がその業務を行っているかもチェックしておきましょう。改めて業務の分担を明確にすることで、自分が普段行っている仕事以外のところについて全社として共通認識を持つことができます。
洗い出しのポイントとしては、現在利用している営業帳票や管理帳票などのドキュメン ト（エクセル・スプレッドシート・手書きの書類など）を収集したり、既存システムの機能を棚卸ししたりするといいでしょう。業務の仕組みを正確に理解するのに役立ち、全体像を把握しやすくなります。
一通り業務の洗い出しが完了した後は、「業務フロー」を作成します。
これは先ほどの「業務全体図」とは異なり、「業務一覧」の小分類に記載した業務の流れや関係者を可視化するために使用するものです。業務全体図同様、業務フローを作成することで、関係者間での認識のずれや誤解を回避することができ、コミュニケーションを円滑に進めることができます。
ここで大事なことは、ITシステムのみならず、使用者(ユーザー)が手作業で行う作業もフローに記載することです。また、各フローについては、関係者が一目で概要を捉えられるシンプルな作図を心がけることがポイントです。
業務フローの作成に厳密な決まりはありませんが、複数人で作成を行うと記述がバラバラで理解できないフローになってしまうため、アイコンやイラストを使用する際のルールを設けておくと良いでしょう。
このステップ2の最後に、「業務一覧」や「業務フロー」によって明らかになった既存の業務に対し、ステップ1で立てた「目的・ 目標」の達成に向けてどのような課題・問題点があるか、どのような「業務フロー」であれば「目的・目標」を達成できるのかといった、”あるべき（理想の）業務像を整理・検討していきます。
ここで抽出された課題・問題点は、これからどのようなシステムを構築していくかの検討で活用されます。
また抽出された課題・問題点の中にも「最優先で取り組むべきもの」「急ぎではないが戦略的に解決すべきもの」といった形で、緊急度や重要度が異なるものが混在しているはずです。システム開発では、予算や期間が定められているケースがほとんどのため、まずは「課題」と「要望」といった切り口で問題点を分類し、その中でも、緊急度・重要度によるマトリクスを作成して、解決すべき課題の優先度を付けていくことが必要です。
ステップ3 フィット&ギャップ分析
DX化する領域が明確になったら、次に導入を検討しているシステムのフィット&ギャップ分析を行いましょう。
フィット&ギャップ分析とは、文字通りシステム化したい要件が、導入検討しているプロダクトで実現できる（フィット）のか、または乖離 (ギャップ)があるのかを確認するものになります。
システムの開発をゼロベースから行うフルスクラッチ開発と比較し、パッケージやSaaSなど、いわゆる「既製品」を活用したローコード・ノーコードでの開発の場合は、各製品・各サービスで提供している機能や画面が異なってくるため、ステップ2で整理した業務上の課題とシステム化の要件をその製品が実現できるのか、1つひとつ確認する作業が必要となります。
まず、フィット&ギャップ分析を行う際は、自社の要件を縦軸に置き、検討している製品を横軸に並べた比較表を作成していきます。
次に、自社で定義した要件に対して製品が対応している場合は○、また対応していない場合は×といった要領で、要件にマッチする機能を保有している製品がどれになるかの整理を行います。製品によっては自社の要件をほぼ網羅しているケースや、一方で自社の要 件に全く対応できない製品も存在するでしょう。
また、標準機能で対応していない場合でも、Appflow・SALDのようなノーコードだけでなくローコードの機能を含むツールであれば、製品が提供する環境を利用して独自の業務ロジックをつくることで回避する、「カスタマイズ」が可能なケースもあります。
例えば、商談管理を行いたいという要件がある場合、Appflow・SALD CRMには商談の進捗管理やその進捗記録を残すことができる商談管理機能があるため、その要件に対しては「標準機能」で対応可能になります。
しかし、商談データをもとに、見積りや請求データを自動的に作成したいという要件がある場合は、Appflow・SALDの標準機能では対応できないため、そのような自動化処理を、Appflow・SALD独自のスクリプト言語を活用して「カスタマイズ」することで対応可能になる場合があります。
スクリプト言語はAppflow・SALDがノンプログラマーのために用意したプログラミング言語のため、複雑な言語ではなく、少ないコード行数で実行できるよう調整されているため、一般的なプログラミングよりも短い時間で構築できます。
また、Appflow・SALD内のカスタマイズだけでは対応できない要件がある場合は、その機能を補うことができる別のパッケージやツールをAppflow・SALDと紐づける「連携」で対応可能なケースもあります。
クラウドSaaS プラットフォームを活用するポイントとして、既存システム全てをAppflow・SALDに無理にでも置き換える、ということは必ずしも考えない方が良いといえます。
また、Appflow・SALDには他システムとの連携を可能にするAPI連携が用意されており、やはり業界ごとにデファクトスタンダードなシステムもあるため、そうしたシステムとAppflow・SALDをつなぐ』という考え方の方がDX全体としては、成功しやすくなるでしょう。
さらに、予算や費用対効果を考え、他プロダクトの代用も難しいとなった場合は、その業務のみ手作業で行うといった「運用回避」を検討することも必要です。
ステップ4 要件定義
システムの選定が完了すれば、次は「要件定義」を行っていきます。
要件定義では、どのようなシステムをつくるのか決定し、システム全体の内容を要件定義書として取りまとめます。そして要件定義書とは、システムを導入した際の新業務プロセスを、関係者間で共有しやすいよう図や一覧に示したものです。要件定義を行うことで、新業務で必要となるツールの整理を行うことが可能になります。
要件定義書の作成を始めるにあたり、まずはシステムを活用した新業務プロセスの「業務全体図」を作成します。ステップ2で検討した要望を実現するために、新システムを導入することでどのような業務に変化するのかといった「To Be (あるべき姿)」の業務全体図を作成することが重要になります。
次に、作成した新業務の「業務全体図」をベースに、「システム化業務フロー」を作成し ます。
既存業務の可視化やその業務上の課題を洗い出すために、ステップ2で作成した「業務フロー」とは異なり、「システム化業務フロー」は、その課題解決のために新業務の中で、システムをどのように活用するのかを表したドキュメントになります。システム化業務フローを作成することにより、業務全体において、システム化する範囲を明確化でき、システム化部分のおおよその処理を関係者間で共有することができます。
Appflow・SALDの場合、レーンを業務フローに追加するのがよいですが、業務内容によっては複数のアプリにまたがって業務を行うケースもあるため、次の図表のように、アプリ別でレーンを追加するのもよいでしょう。また、業務フローと同様、アイコンやイラストを使用する際のルールを設けておいてください。
そして、作成したシステム化業務フローから、「機能要件一覧」を作成します。
機能要件一覧は、ステップ2で作成した業務一覧と同様、業務フローから機能を抜き出し、一覧表としてまとめたもので、これを作成することで機能に抜け漏れがないかの確認を行うことができます。
また、機能要件一覧は既存システムのビジネスプロセスを洗い出した際と同じように、大分類、中分類、小分類の階層に分類し、一覧表に記載していきます。
記入する内容は、システムの機能に加え、画面構成や帳票、外部接続など今回のシステム化に関わるものも記載してください。
もし画面や帳票の要件が多く、煩雑になってしまう場合は、「画面一覧」「帳票一覧」といった形で分類別に一覧表を作成するのもよいでしょう。しかし、手作業で行う業務がある場合は、システムの機能には該当しないため、今回の機能要件に加える必要はありません。
また、文字だけでは伝わりづらい機能や帳票に関しては、機能概要やデータの入出力、例外処理を記載した「仕様書」を作成するのがいいでしょう。一覧表にある全ての機能に仕様書を作成する必要はありませんが、関係者間でイメージの共有が難しいものに特化して、機能の概要やデータの扱いをまとめ、また図を用いて説明するのが最適です。
システム化の要件をどのくらいの詳細度で洗い出しを行うかは、関係者間で協議しながら決めることになります。要件定義書を確認する承認者や、システムの開発を担う開発者が正しく理解できるかが重要なので、そのことを念頭に置いた上で、要件定義を進めていくのがよいでしょう。
また、作成した要件定義書は共有するだけでなく、関係者を招集し、この要件で問題ないかの読み合わせを実施するのがよいでしょう。読み合わせを実施することで、担当者間の業務知識、理解の溝を埋めることができ、要件定義書の中の不備を見つけることもできるので、作成後はぜひ実施するようにしてください。
ステップ5 プロトタイプの開発
要件定義が完了した後は、いよいよ開発フェーズへと移っていきます。
開発フェーズでは、いきなり完成品を作成するのではなく、まずは試作品となるプロトタイプの開発を行いましょう。
システムの導入によくある失敗ケースとして、要件定義や仕様書にある通りの機能、システムを構築したにもかかわらず、システムの評価の段階でユーザー側の同意が全く得られず、修正が多発し、納期や予算を大幅にオーバーする結果になるといったことがあります。
「1枚の絵は1000の言葉に値する」という言葉があります。システム開発の世界でも、言葉や文章だけで、システムの要件を伝えきるのは困難なことです。
そのためにも、まずはプロトタイプを作成することで早い段階で画面イメージを確認しましょう。プロトタイプを通して、認識の齟齬を減らし、プロジェクトのリスクと開発にかかるコストの低減ができるでしょう。
特に、ローコード・ノーコードツールはプログラミングをほとんど伴わずに開発が行えるため、気軽にプロトタイプの開発に取り組めます。また、Appflow・SALDの場合は、GUIの操作で画面やレポートを簡単に生成できるので、確認・評価が行いやすく、プロトタイプ開発に向いています。
プロトタイプの開発には、要件定義後の「開発」と、そのプロトタイプの「評価」の2つのフェーズがあります。
開発フェーズでは、要件をもとに、外観や操作感が実際のシステムと同じようになる試作品を作成します。評価フェーズでは、プロトタイプを開発チームと運用チームで検証し、完成イメージと齟齬がないかを確認します。場合によっては評価フェーズでのフィードバックを受けて、プロトタイプの修正を行います。
こうして、プロトタイプの開発と評価を繰り返し、完成イメージが固まったところで本番の設計・開発に着手します。
では、具体的な工程に入っていきます。プロトタイプの開発は、以下の手順で進めていきます。
①プロトタイプの作成
設計で実装を決めた機能のみを搭載した試作品を開発していく工程です。システムの核となる機能、何度も検証が必要な機能を優先的に試作品に搭載します。
Appflow・SALD CRM の場合、構築は次の手順で進めるのがよいでしょう。
ステップ1: 各タブの項目を追加する
ステップ2: パイプラインやレイアウトルールを設定する
ステップ3: 自動化処理を作成する
ステップ4: 外部連携の設定を行う
②プロトタイプのテスト
作成したプロトタイプをテストし、不具合やエラーが見つかった際は修正していきます。
テストでは、要件でまとめた各項目の抜け漏れがないか、ワークフローが正常に動作しているか、自動化による各種通知やタスクが正常に動作しているか、外部連携が正常に動作しているか、といった項目に対してチェックを行っていきます。
テストのためには、個人情報や商談データを実際に入力する必要がありますが、実在する個人名や商談ではなく、サンプルデータを使用することが一般的です。Appflow・SALD CRM にはサンプルデータが用意されていますが、各タブの構成がサンプル通りでないことやデータが少ないこともあります。そのため、ダミーの個人情報を生成できるツールを活用するのも手でしょう。
③ユーザーによる評価と改善
ユーザー評価の結果をもとに、プロトタイプの改善を行います。
ユーザーからのフィードバックを受け、操作性や使い勝手の改善点を洗い出します。そして、それらの改善点をもとに、プロトタイプを改良していきます。
改善作業が必要な場合は、再度、プロトタイプのテストを行い、問題点を特定し、修正します。これらの工程を繰り返し、改善を重ねながら、最終的に完成版のシステムを開発します。
以上のように、プロトタイプの開発は、試作品を作成し、テストやユーザー評価を行い、改善作業を行いながら、最終的に完成版のシステムを開発する工程です。このプロセスを通じて、利用者のニーズに応える高品質なシステムの開発ができるようになります。
ステップ6 既存システムとの並行活用とトラブルシューティング
プロトタイプの開発を経て、新システムが完成すると、既存システムから新システムへ切り替える移行が必要になります。移行方式では、主に3つの方法があります。
①一括移行方式
既存システムを休止し、新システムへ一斉に切り替える方式です。一斉に切り替えますので、移行時間やコストを抑えられる一方で、移行後にトラブルが発覚すると影響範囲が大きくなるリスクがあります。
②段階的移行方式
業務や機能単位などで既存システムを休止し、段階的に新システムに切り替える方式です。段階的に移行することで、一括移行方式よりリスクを抑えられます。一方、移行が複数回となることによるコスト増や、分割した単立で既存システムと新システムが混在することになるため、相互間でのデータの同期・連携を考慮する必要があります。
③並行運用方式
既存システムと新システムを同時並行で稼働させ、結果を比較検証し、新システムに問題がないと判断した時点で既存システムを休止する方式です。並行運用しているため、安全に移行できる一方で、既存システムと新システムで二重入力の負担が大きい点に注意が必要です。
システムの内製化においては、スキルやノウハウがあるITベンダーなどの事業者が移行を行うわけではないため、リスクがもっとも低い既存システムとの並行活用を検討します。運用負担は大きくなるものの、利用者のシステムの習熟度を上げつつ、比較的安全にシステムへ移行できます。
次に、トラブルシューティングについて述べていきます。
システムを利用していると、不具合や異常といったトラブルがつきものです。対応を誤れば、原因究明に時間を要したり、2次災害を引き起こしたりすることで障害が長期化するリスクがあります。
ITベンダーなどの事業者は、トラブル対応のスキルやノウハウを持っていますが、システムを内製化する場合、スキルやノウハウが不足しがちです。そのため、あらかじめ想定されるトラブルの対処法を体系化し、マニュアルとして標準化しておくことが重要となってきます。そうすることで、トラブルが発生しても、誰でも円滑に対処することが可能となり、早期復旧を図ることができるようになります。
トラブルシューティングのマニュアルを作成する際のポイントは、次の通りです。
・トラブルシューティングの基本的な考え方、運用ルールを記載する。
・問い合わせやクレームと、その原因と解決策を収集する。
・収集した原因と解決策が適切であるか、わかりやすい表現かを検討する。
・問題、原因、解決策をトラブルの内容ごとに分類する。
トラブルシューティングに関して、ITツールを活用して環境整備していくことも必要となります。トラブルシューティングマニュアルは、エクセルやGoogle スプレッドシート等で作成できますが、Appflow・SALDにはFAQや問題解決のナレッジを簡単に作成・参照することができます。これにより、ナレッジベースで自己解決率アップや対応工数削減が図ることができます。
続いて、トラブルシューティングの方法についてご紹介します。システムによっては細かな違いはありますが、基本的なステップは以下の通りとなります。
①「いつ・どこで・どうなったか」を明確にし、状況を把握する。
②原因を切り分けし、問題箇所を特定する。
③問題の発生条件や問題が再現できるかを確認する。
④対処では、暫定措置と恒久措置を検討する。
システム稼働後もトラブルがゼロになることはないため、トラブルシューティングは、継続して取り組んでいく必要があります。
ステップ7 リプレイスの実施
既存システムとの並行活用を経て、いよいよリプレイスの実施となります。リプレイスでは、準備が不足していると、失敗するケースが多くみられますので、注意が必要となります。
リプレイス前に準備すべきものとして、移行データの準備が挙げられます。これまでシステムを利用していない場合は、今後、新たにデータを登録していくことになるので、特に考慮する必要はありませんが、既存システムから切り替える場合には、これまで登録したデータを移行する必要があります。
移行データの準備ができた後は、実際にデータが移行できるか、リハーサルを行います。サンプルデータで移行テストを行うだけではなく、問題を早期に発見するためにも、早い段階で既存システムの全件データにてリハーサルを行うことが重要となります。既存システムでは、サンプルデータに含まれていないイレギュラーなデータが存在している可能性もあるため、リハーサルを行うことで問題点を洗い出し、既存システムでのデータ修正や移行データの加工といった解決策を準備し、万全の備えをしてリプレイスに臨む必要があります。
次に、リプレイスを行う上での注意点についてお伝えします。
ITベンダーなどの事業者に依頼する場合は、リプレイスを全て任せるのではなく、発注する側が主体的に関わっていく必要があります。視点で確認し意味については、事業者も完全に把握しているわけではないため、利用者の視点で確認して行くことが実用です。
一方で、システムを内製化する場合は、社員が担当することになります。そのため、システムの運用方法やデータの意味を把握していても、システム導入する推進担当者と利用者が異なる場合は、認識を擦り合わせて進めていくことが必要となります。
ローコード・ノーコードでは、変更対応が容易ではあるものの、システムを内製化する場合は社内の限られたリソースで対応していくことになるので、手戻りのリスクを軽減するよう社内調整していくことも重要となってきます。
なお、Appflow・SALD CRMでは、データをインポートする機能が用意されています。この機能を使えば、Salesforce Microsoft Dynamics CRM といった、これまで利用していたCRMからデータを簡単にインポートすることができます。
また、既存システムから出力した項目をAppflow・SALD CRM の項目にGUIで紐づけることができます。インポートした結果も履歴画面から確認することができ、インポートして30日以内であれば、インポートを取り消しすることもできます。これらの機能によって、既存システムのデータを移行することが容易に行えます。
Appflow・SALD においては、メルマガ配信リストをAppflow・SALD CRM の顧客データと連携することができますが、Appflow・SALD CRM を導入しない場合であっても、メルマガ配信リストを既存システムのデータから移行することができます。
Appflow・SALD CRMと同様に既存システムから出力した項目をGUIで紐づけることができます。また、既存システムだけに存在する項目であってもノーコードで容易に項目追加することができます。
このように、Appflow・SALDの各プロダクトでは、既存システムからデータを移行するために、多くの機能が用意されています。
ステップ8 運用
リプレイスの実施が完了した後は、システムを運用していくことになります。
新しいシステムを用意しただけでは、運用していくことはできませんので、入念な準備やサポートが必要不可欠です。準備不足で、その場しのぎの対応になってしまうと、業務は混乱をきたすことになります。運用の準備及びサポートについては、おおよそ次の通りとなります。
①システムの操作マニュアルや運用マニュアルの準備
システムを操作したり、運用したりするには、マニュアルを準備しておく必要があります。
ただし、システムの操作を全てマニュアル化するのは、どうしても時間や労力がかかってきます。特にシステムを内製化しているのであれば、社内のリソースにも限りがあるので、業務上、重要なポイントに絞って用意するなど工夫が必要です。
また、Appflow・SALDを導入する場合、「はじめてガイド」に基本的な操作方法がわかりやすくまとめられています。こういった製品情報を有効に活用できる環境も準備していきましょう。
②利用部門への操作説明会の実施
システムを利用するには、用意した操作マニュアルを活用して、操作説明会を実施します。操作説明会では、なるべく実際のデータを使用し、システムの操作だけに終始しない よう、現在の業務の流れをシステムに置き換えて説明することで、新システムを理解しやすくなります。
また、説明を聞いただけでは、システムの習熟度は上がらないので、実機で操作してもらう方がよいでしょう。1回の説明会で習得できないようであれば、複数回実施することも必要となってきます。
③問合わせ窓口の設置や運用保守体制の確立
システムのことについて問合わせしたい場合、混乱をきたさないよう、どこに問合わせしたらよいのかをあらかじめ決めておく必要があります。
また、改善要望や質問事項に対応する体制も準備しておかなければいけません。システムを内製している場合、構築に携わった担当者がそのまま運用保守も担当するケースが多い傾向ですが、運用保守対応が属人化するリスクがあります。そうなってくると、異動や退職時に引継ぎが不十分になる恐れもあるので、ドキュメントに残しておいたり、1人に依存しないよう副担当者を体制に含めたりといった対応も必要になります。
④改善要望や質問事項の対応
操作説明会やシステムの運用においては、改善要望や質問事項が上がってきます。
改善要望の対応にあたっては、リスト化を行うとともに優先度をつけて、特に業務上で支障をきたすものについては、最優先で対応する必要があります。
なお、Appflow・SALD CRM には、「サンドボックス機能」という本番環境と完全に切り離したテスト環境があります。本番環境で改善対応や不具合修正を行った場合、何か問題が発生すると、通常業務にも影響することになります。こちらの機能を利用することで、本番環境に影響を与えずに検証することができるため、安心してシステムを変更することができます。
質問事項の対応にあたっては、改善要望と同様にナレッジとしてリスト化するとともに、よくある質問事項はFAQにまとめていきます。作成したFAQは、社内に共有することや個別の説明会を実施するなど、利用者自らが解決できるようにすれば、類似の質問を減らすことに寄与します。
システム内製は短期間のアジャイル型開発で進めよう
システムを開発する手法として、様々な種類がありますが、代表的な手法として、第1章でも少し触れた「ウォーターフォール型開発」と「アジャイル型開発」があります。まず初めに、それぞれの開発手法について、もう少し説明します。
ウォーターフォール型開発
最初に全体計画を立て、その計画に従って開発を進めていく手法です。
従来型のシステム開発でよく見られる手法で、滝 (waterfall) の水が流れ落ち、逆戻りしない意味合いで、このように名付けられました。計画通りに進められ、品質を確保しやすい一方で、当初の仕様から変更が生じたときに対応しづらいという面があります。
アジャイル型開発
アジャイル型開発では、事前に全てを計画するのではなく、必要な機能から短期間で開発する手法です。
アジャイルは、直訳すると素早い、機敏な、という意味合いで、さらに頭のよいといったニュアンスも含まれています。小さい単位で開発を繰り返して進めていくため、利用開始までが短縮でき、仕様変更にも柔軟に対応できる一方で、スケジュール管理が難しく、柔軟性があるあまりに開発の方向性がブレやすくなる点にも注意が必要です。
これまでのシステム開発といえば、「ウォーターフォール型開発」で行われるケースが多い傾向にありました。その理由の1つとしては、ITベンダーなどの事業者にシステム開発を請負契約で発注する場合、発注内容（開発範囲や開発期間など）が決まっているため、契約後の仕様変更には対応しづらいことから、「アジャイル型開発」は採用されにくかったのです。
一方、システムの内製化においては、ローコード・ノーコードのデジタルツールを活用すれば、必要な機能から短期間での開発ができることから、「アジャイル型開発」で進めることが適しているといえます。
次に、「アジャイル型開発」の進め方を見ていきます。「アジャイル型開発」では、いくつかの進め方がありますが、その中でも代表的なのが「スクラム」になります。スクラムとは、ラグビーのスクラムのように、チームががっちりと連携しあって開発していく手法になります。ここでは、スクラムの基本的な流れをご紹介します。
ステップ1 プロダクトバックログの作成
開発対象の要望や優先度をプロダクトバックログとしてまとめます。
ステップ2 スプリントプランニングを実施
スプリントとは、チームで一定量の作業が完了する際の短く区切った期間（主に1~4 週間程度）のことで、ここではプロダクトバックログからスプリントの計画を立てていきます。
ステップ3 デイリースクラムの開催
スプリントの間、状況報告や問題の共有、進め方の確認などを行うことを目的として、毎日決まった場所・時間でミーティング（デイリースクラム）を開催します。1回あたり15分程度行うことが一般的で、作業計画に絞って会話します。作業内容の詳細にまで言及すると、メンバー全員の開発作業が止まる点には注意が必要です。
ステップ4 スプリントレビューの実施
スプリントの終了時に、スプリントレビューミーティングを開催し、開発したソフトウェアが要求を満たしているかを評価します。
ステップ5 スプリントレトロスペクティブ（振り返り）の実施
スプリントレビューミーティング後に、そのスプリントの振り返りを行い、次回のスプリントの改善策を検討します。ポイントとしては、①よかった点・継続したい点、②問題点・改善点、③次回のスプリントで取り組む対策、といった点で振り返りましょう。
本章では、ローコード・ノーコードのデジタルツールを活用して、システムを内製化するステップを見てきました。
おわりに
本稿では、現在のIT業界のメガトレンドである「ローコード・ノーコード」について説明し、特にローコード・ノーコードプラットフォームAppflow・SALDを活用した、中堅・中小企業におけるデジタル変革 (DX) について述べてきました。
冒頭にも述べましたが、デジタル変革は「小さく始めて大きく育てる」という発想が重要です。つまり、導入する会社の全社員が、デジタル変革による”業績向上”という成功体験を実感するためにも、目に見える成功体験が必要なのです。
こうした小さな成功体験の積み重ねによって、最初は限定的であったデジタル変革の取り組みを、最後は全社的・全体的な取り組みに拡大していく、という手法が、特にリソースが限られている中堅・中小企業には有効な方法といえます。
実際、私たちは最初はAppflow・SALDによるSFAの導入からスタートし、今後はHR(人事・組織開発)の領域や、AIの活用といった領域に広げていこうとしています。
そういった意味でも、様々プロダクトから構成されており、企業活動のほとんどの領域を網羅するローコード・ノーコードプラットフォームであるAppflow・SALDは、まさにデジタル変革を成功に結び付けるための、うってつけのデジタルツールなのです。
そして最後に強調しておきたいことは、改めてこうしたデジタル変革に会社を挙げて取り組んでいる会社と、そうでない会社との間では、10年後には逆転不可能なレベルで大きな差がついてしまっている、ということです。
本稿でも述べてきた通り、例えば最初は「チャットボット」「MA(マーケティング・オートメーション)」といった部分的な領域で、短期間の間に目で見える成果を上げることはできるかもしれません。
しかし、そこから人材面も含めて会社全体のデジタルリテラシーを底上げし、本当の意味での会社全体のデジタル変革に取り組み、成果を上げるためには相応の時間が必要だといえます。
具体的に、「中堅・中小企業におけるDX進展度のレベル」の図表で示します。
ここで自社がレベル0~2だ、という会社におきましては、特に本稿で数多く述べてきた成功事例を参考にしながら、ぜひ、すぐにローコード・ノーコードプラットフォームAppflow・SALDを活用した、「小さく始めて大きく育てる」 デジタル変革への取り組みを検討していただきたいと思います。今の決断が、10年後の会社の未来を決める、といっても過言ではないのですから。
【実践ローコードDX】APPFLOW・SALDで業績アップを実現する連載シリーズをすべて読んでくださった皆様に心より感謝と御礼を申し上げて、筆を擱きます。