社内の管理業務・ルーチン業務を
シンプルにシステム化します

こんなことで悩んでいませんか？

• 社内の情報が、紙や電話で飛びかっており、記録が大変だ
• 過去の契約資料、管理資料が紙なので見つけるのが大変だ
• 単純作業の付加価値が低い業務に多くの時間が掛かっている
• 自社の業務は特殊なので簡単なカスタムIT化が望まれる

• PC、タブレット、スマホで使える業務アプリ
• いつでも、どこでも確認できるクラウド情報管理
• 業務を再定義し、普段使いできるシステム

Value UP

自社に最適なシステムをゼロから作る。
昔では大企業しかできなかったことが、最新のテクノロジーで
リーズナブルな価格でできるようになりました。

目指すゴール

• ペーパーレス・報告書自動作成
• 現場直行直帰の実現
• 業務のスピード向上
• 圧倒的売上アップ

超高速開発・ラピッド開発

モックアップアプリ作成まで最短１週間

カットオーバーまで最短２ヶ月

ラピッド開発とは

「ラピッド開発」をご存じでしょうか？これまでフル新規の業務用アプリケーションシステムを作るには最低でも半年、長くなれば２年以上もの時間が必要でした。しかし社会の環境変化は速くなり、また、デジタル・ソフトウェアで解決すべき課題は年々増えています。

これからは新しいアプリケーションシステムは、素早く構築し、素早く運用を始め、素早く改善していくというサイクルが求められます。
そのためには、まず、動くものを作り、アプリケーションを使うメンバーからのフィードバックを得ながら高速で開発サイクルを回して行かなければないません。

このように短期間でフルスクラッチのアプリケーションシステムを創ることを、ラピッド開発といいます。

なぜジェイネクストは、ラピッド開発ができるのか

Point1
プログラマが、仕様を決めてすぐにコードを書きます。
無駄なやりとりが一切ありません。

Point2
フルスタックエンジニアが、構想、設計、コーディング、バグだし、サーバー実装、修正までを全て行います。
分業しないので、言語化したり文章化する時間が圧倒的に短いです。

Point3
全ての作業が驚くほど早く終わります。
●データベースの設計４時間
●基盤構築１時間
●１画面の構築に３０分ほどです。
●２０画面程度のモックアップであれば、実働３日ほどで作ることが出来ます。

仕事のプロセスの違い

既存のアプリケーション構築フロー

古いアプリケーション開発の手順はは以下のような手順です。

①クライアント側が社内の業務部門にヒアリングをして要望をとりまとめします。

②次に要求仕様書（ＲＦＰ）を作成して、委託するベンダーに見積検討依頼を出します

③ベンダー側は、ＲＦＰに基づき大まかな構想を決めて社内用の仕様書・設計概要書を作成します。

④社内のみならず、外注も使う場合には、ここで再度見積のための作業依頼書が作成されます。

⑤外注先ではコーディングするための詳細指示書が作成されます。

つまり一つのアプリケーションのプログラムを作り始める前に、何枚もの書類が再生産されます。この時間こそが無駄な工期の原因です。

また、図の末端にいるコーダーと呼ばれる「手を動かしてプログラムを作る人」は、顧客と会うことも無ければ、実利用者の意見を聞くこともありません。
そのため、顧客の期待する事やシステムの目的を知らずにコードを書くことがあるのです。

受託ベンダーと外注には利害関係もありますから、途中の仕様変更や、追加機能などについてはその都度このプロセスが繰り返されることとなります。

また、コーディングの現場で起きる、「意外と実装負荷の掛かる機能が見つかったので、機能の代替案に現場が妥協できるか」などについては、この真逆のルートで情報がクライアントに上がっていき判断を仰ぐことになってきます。途中に何層もの人物や関係者、はたまた企業間のやりとりが発生するため、とんでもない時間のロスが起きるのです。

かつてアプリケーション構築フローは処理する情報量が大きく、営業、設計、コーディングという仕事を分業してチームで実現する必要がありました。しかし今では、各プロセスの業務設計は効率化され、少ない人数で（１人でも）システムを構築することも出来ます。分業による情報交換コストのデメリットの方が大きくなってきたのです。

また、仕様書など文書が先にできると、画面構成や使い勝手はおざなりになります。なぜなら、「レスポンスは●秒以内」「使いやすいこと」などといった文言は、仕様書に文章として書きにくいからです。

残念ながらこのようなプロセスで作られたシステムは、出来上がったときに「なんか思っていたのと違う」「新しいシステム、使いにくいよね」ということになるのです。
そして、それに気づいた時には後戻りできないくらいシステムの構築は進んでいるでしょう。

ジェイネクストのアプリケーション構築フロー

当社のアプリケーション構築フローは至ってシンプルです。

プログラマー（まぁ社長である私がプログラマーなわけですがw）が現場に赴き、現場で実際に新しいアプリケーションシステムを使う人に、何を求めているかをヒアリングします。
画面の具体的な動きを想定しながらプログラムの仕様を作っていきます。

あとは、プログラマー（私）の構想に基づいて、仮仕様を決めて「実際に動く画面」を提供します。

この間、仕様書は、メモ書き程度のものしか作りません。

近年要望されるアプリケーションシステムは、「製造現場」「建設現場」「店頭」など現場スタッフが働く場所で使われるものが多くなりました。
スマートフォン、iPadなどの安価で使えるモバイル端末が増えたためです。これらはデスクトップパソコン＋フルキーボードという環境では無く、小さい画面でタッチによる操作が基本です。
そのため、画面構成の使いやすさや、タッチでの目的へのたどり着きやすさ、また、オフィスワークとの親和性などが求められます。

このような使い勝手が優先される時代こそ、「実際に動く画面を見ながら開発する」ということが求められています。

ジェイネクストでは、フルスタックエンジニア（私）が、直接お客様の声を聞き、動く画面をみせながら設計を進めます。
出来上がったときには、自分達の要求する、使いやすいシステムが展開され導入もスムーズになります。

会社独自のウェブアプリケーション・業務アプリ開発を請け負います

対象業種

製造業、建設業、医療・介護、サービス業

アウトプット

現在の業務における課題を解決するための業務用アプリケーションの開発・納品・保守

活用シーン

• 点検、検査、記録などの業務
  • 飲食店舗の衛生検査、清掃記録システム
  • オフィス、公共機関の設備点検記録、清掃やメンテナンス記録システム
  • 帳票の自動作成システム、自動送信システム
  • 写真の記録システム
  • 工事現場、作業現場での記録点検フォーマットの電子化
• フィールドサポート業務
  • 営業・サポート現場での商品や部品在庫把握システム、
  • 製造現場での梱包検査サポートシステム
  • 製造、卸売、小売現場での在庫棚卸しシステム
  • サービス現場での予約や日程管理、状況管理システム

できること

サーバーやインストール不要

クラウドを利用するため、社内にサーバー等の設備機器を設置導入する必要はありません。

パソコンにインストールするソフトは要りません。ブラウザーがあれば全ての操作ができます。

特定のパソコンではなく、全てのネットに繋がるパソコンやタブレット、スマートフォンで、ログインさえすれば利用できます。

市販のデバイスを使えます

市販のパソコンのみならず、iPad等のタブレット、iPhone/Androidのスマートフォンなどでご利用いただけます。

特別な端末を用意する必要はありません。

データはクラウドに保存・バックアップ

アプリ内のデータはクラウドに自動保存されます。

バックアップは毎日行われますので、バックアップや保管のために何かをする必要はありません。

BCPにも対応しています。

帳票・印刷も可能

そうは言っても、印刷しておきたい、紙で見たい、保管したいというニーズも有ると思います。

必要なシーンでは、帳票をA4サイズにきっちり収めて帳票出力したりPDFで保存することもできます。

こんなアプリ開発にはご注意下さい

サーバーの購入・導入費用が請求される

新規アプリ開発をする際に「サーバーの導入が必要です。100万円です。」という業者にはご注意下さい。そもそもクラウド化に対応していない時点で技術が遅れています。5年後に「サーバーの更新」ということで同じような金額を請求される可能性が高いです。

開発言語が「JAVA」である

「JAVA」が悪いわけではありませんが、JAVAは厳密な言語なので、大企業の業務用システムを長い時間を掛けて作り上げるのに適した言語です。中小企業の作るシステムには合致しないことが多いです。制作に時間がかかるので、素早い開発や素早い改善サイクルは実現しにくく、価格も高くなりがちです。

保守費用が高すぎる・安すぎる

年間の保守費用は一般的に制作初期費用の2割程度が妥当です。高すぎる場合は、イニシャル価格を安く見せるための方便の可能性もあります。逆に安すぎるとリリース後の充分なサポートを受けられない場合もあります。

利用テクノロジー

当社が対応しているプログラミング言語である「Python」は「Java」や「C言語」などと比べれば日本では耳慣れない言語ですが、世界では最新技術の開発に使われる高級言語です。

PythonはGoogleやFacebook、Instagramといった世界的WEBサービスで標準開発言語として使われており、最近ではクラウドストレージの「DropBox」、Softbankが開発した人間型ロボット「Pepper」、IoT用の小型コンピュータ「RaspberryPi」、そしてビッグデータ解析、AI開発、ディープラーニングプロジェクトなどでも使われる言語です。

Pythonは膨大なライブラリ（プログラムの部品セット）と秀逸なフレームワーク（アプリケーションの枠組み）を持っており、通常のプログラミング言語の30〜50%の時間とコーディング労力でプロジェクトを作ることができます。

当社のメリット

超高速開発

業務の状況をヒアリングしてから、概ね3営業日程度でモックアップを10画面程度作成出来ます。

内製より速い改善サイクル

制作時には、2週間単位で改善のサイクルを作り、「動く画面」「意見」「反映」というトライアルを繰り返します。これにより、思い通りのアプリケーションが作れます。

運用後も、電話で問題点を連絡をいただければすぐに直します。遅くとも2営業日以内には修正します。いちいち見積とか仕様の確認などは致しません。速く直して、速く使ってもらいます。それでも問題があればまたすぐ直します。通常新しいシステムでは1年で50回程度の修正要望に対応します。

当社のサポートポリシーは「内製より速い改善」です

長い試用期間＝失敗しないシステム作り

モックアップから動作確認、要望の取り入れまで、最大で3ヶ月程度の無料期間を設けております。「導入する前に使える」「作りながら意見を言える」「使い心地を体験できる」このような手順を踏んでから正式契約ですので「失敗しないシステム作り」ができます。

買い物で失敗する最大の要因は「事前に試せないこと」ではないでしょうか？
もしこんなことが出来たらどうでしょう？

• 車を買う前に実家まで長距離ドライブしてみる。
• 家を買う前に1ヶ月住んでみる。
• 靴を買う前に1日歩いてみる。
• パソコンを買う前に1週間仕事で使ってみる。
• 服を買う前に自宅に持って帰って、いま有る服でコーディネートしてみる。
• メガネを買う前に完成したレンズで1週間過ごしてみる。

これなら買い物は絶対に失敗しません。でも使ってから、作ってから、消耗してから「やっぱり買いません」というのが普通の商売では許されないですよね？

しかし当社のシステムではこのようなお試しができます。たっぷり使って、3ヶ月後に「やっぱり導入しません」でもOKです。遠慮無く高速開発でお試し下さい。

制作事例

制作事例の一部をご紹介します。

ビル清掃報告書システム

• 画面数：約５５画面
• バックエンド　Python + Flask + PostgresSQL
• フロントエンド　HTML + CSS + JQuery +Jinja2テンプレート
• プラットフォーム　Heroku
• データ取扱件数　現場数15000件/年、写真数450,000件/年
• 主な機能：ビル清掃の清掃状況や清掃結果をスマートフォンで記録し即時報告書を作成するシステム
• 主な機能：ビル内の清掃個所を事前登録し、清掃予定や清掃開始時に箇所を読み込む
• 主な機能：清掃報告書をオンラインで管理会社に公開するシステム
• 主な機能：スマートフォンで撮影した写真を４Ｇ環境でも３秒程度でサーバーに送る技術
• 制作期間4ヶ月
• 構築価格目安250万円
• 月額保守費用目安30,000円

課題と解決

＜以前の業務状態＞
B社は横浜市内にあるビルメンテナンス会社です。主な業務であるビル清掃の業界では現場の清掃作業をビルオーナーや依頼主に報告するのが一般的です。B社が顧客向けに作成提出する報告書には清掃作業の前・中・後を写真に撮影して規定のフォーマットに貼り付けて帳票として印刷するものです。
清掃シーンの撮影はデジタルカメラを利用しており、報告書はエクセルやワードのフォーマットでした。
＜主な課題＞
現場での清掃作業が終わってから毎日の報告書作成に多くの時間を使っていました。作業後に事務所に戻り、デジタルカメラ写真をパソコンに取り込みます。続いて報告書ファイルが重くならないように画像を縮小処理してから貼り付けます。
エクセル上の作業は写真の整理、貼り付け、コメントの記入となっており、1つの報告書を作成するには1時間ほど掛かります。現場での撮影漏れがあると、もう一度翌日に撮影するために現地を訪問するということもありました。
現場が終わって疲労が溜まっている状態で社員がこのような作業を行うのはハードですし、残業代のみならず昨今の働き方改革にはほど遠い状態にありました。
また作成した報告書はファイルがどんどん貯まっていきます。月間で200件、年間で2400件もの報告書が作成され、そのデータもどんどん重くなっていきます。お客様への送付はメールで行っており、双方で情報のやりとりにも不満がある状態でした。
＜システム構築のポイント＞
当社がこのような状態をヒアリングしてから提案したテーマは以下の４点です。
①報告書を瞬時に作成して、ペーパーレスのままお客様に送付できるシステム
②いざというときは今までと同じ帳票でA4サイズに印刷できるシステム
③現場での撮影をスマートフォンで実現出来るシステム
④オンラインで現場の状況を管理者が確認出来るシステム

オンラインで顧客に送付する機能などがこれまでの業務プロセスとは全く違ったために一部開発に時間が掛かりましたが、以下のスケジュールで進捗しました。
１）モックアップ提供まで１週間
２）使い方を見ながら改善することに１ヶ月
３）初回打ち合せから３ヶ月目には基本機能のリリースを実施
４）顧客への報告書送付機能に追加で１ヶ月
このようにトータルで４ヶ月でのリリースを行いました。
＜導入後の業務変化＞
B社はシステムを導入後に以下のメリットを感じられました。
①現場での撮影箇所が事前にスマートフォンに表示されるため、業務の手順がわかりやすい上に撮影漏れが無い
②現地での撮影が終わると瞬時に報告書が作成出来るので、事務所に戻らず直行直帰ができる。作業者は非常に楽。
③紙の出力がなくなったのでバインダー整理など紙に関するコストと手間がなくなった
④現場での撮影状況がリアルタイムに分かるので管理する側としては安心できる

食品衛生検査　情報管理システム

• 画面数：約３５画面
• バックエンド　Python + Flask + PostgresSQL
• フロントエンド　HTML + CSS + JQuery +Jinja2テンプレート
• プラットフォーム　Heroku
• データ取扱件数　1000件/年
• 主な機能：データエクセルアップロード、データ検索、PDF送信機能など
• 制作期間4ヶ月
• 構築価格目安200万円
• 月額保守費用目安20,000円

課題と解決

＜以前の業務状態＞
M社は東京都文京区にある食品衛生検査事業会社です。主な業務である飲食店の衛生検査業務では、テナントオーナー・フランチャイズオーナー・本部等へ衛生検査内容を定期的に報告しています。
B社が顧客向けに作成提出する報告書には約５０項目の衛生検査チェック、NG箇所のデジカメ撮影画像、NG箇所の記録・改善コメントを規定のフォーマットに貼り付けて帳票として印刷するものです。
NG箇所の撮影はデジタルカメラを利用しており、報告書はエクセルのフォーマットでした。
＜主な課題＞
大手チェーン店や、飲食店の現場では年4回程度の衛生検査が求められています（法定ではありません）。
衛生検査の基準は各社によって違いますが、一般的に目視検査を50項目程度、NG箇所の撮影とコメント、手指や取手、食品から検出する細菌微生物の培養検査といった組合わせになります。
現場での検査は紙の帳票を手に持ち、素早く各ポイントをチェックした後、NG箇所について手書きでコメントをしていきます。現場ではデジカメを使用して撮影を行い、
微生物培養検査のサンプルも採取します。
また飲食店は昼、夜といった来客のピークにあたると検査が十分に出来ませんので、空いている時間の午後２時～５時くらいに集中して検査をしなければいけません。
手書きメモもとデジカメの撮影で現場はかなり煩雑となり検査員は多くの労力を使っていました。
また検査が終わってから毎日の報告書作成に多くの時間を使っていました。作業後に事務所に戻り、デジタルカメラ写真をパソコンに取り込みます。続いて報告書ファイルが重くならないように画像を縮小処理してから貼り付けます。
エクセル上の作業は写真の整理、貼り付け、コメントの記入となっており、1つの報告書を作成するには１～２時間ほど掛かります。
現場が終わって疲労が溜まっている状態で社員がこのような作業を行うのはハードですし、残業代のみならず昨今の働き方改革にはほど遠い状態にありました。
また作成した報告書はファイルがどんどん貯まっていきます。約２００店舗につき年間４回で800件もの報告書が作成され、そのデータもどんどん重くなっていきます。お客様への送付はメールで行っており、双方で情報のやりとりにも不満がある状態でした。
検査員は１０名ほどいて、ファイルの共有だけでも大きな手間になっており、また、店舗ごとの時系列でのデータ比較もできていませんでした。
＜システム構築のポイント＞
当社がこのような状態をヒアリングしてから提案したテーマは以下の４点です。
①報告書を瞬時に作成、今までと同じ帳票でA4サイズに印刷できるシステム
②５０箇所のチェックをタブレットでタッチ式に操作できるシステム
③NG箇所の撮影をタブレットのカメラ機能で行い、そのまま報告書に貼り付けできるシステム
④オンラインで報告書の承認チェックができるシステム

検査員の要求するスムーズなのUI（ユーザーインターフェース）の実現に時間がかかりましたが、以下のスケジュールで進捗しました。
１）モックアップ提供まで３週間
２）使い方を見ながら改善することに１ヶ月
３）初回打ち合せから４ヶ月目には基本機能のリリースを実施
４）その後約半年間、使い勝手を改善ながら運用を開始
このようにトータルで４ヶ月でのリリースを行いました。
＜導入後の業務変化＞
M社はシステムを導入後に以下のメリットを感じられました。
①現場でのチェック作業がタブレットでスムーズに実現出来る
②NG箇所の撮影をそのままタブレットで行い、報告書に自動的に貼り付く
③微生物培養検査の入力が画面上でスムーズに行える
④検査員は事務所に戻らず直行直帰ができる。作業者は非常に楽。
⑤お客様にも電子データで見ていただけるので整理など紙に関するコストと手間がなくなった
⑥検査を実施した直後にお客様に状況を見ていただけるので、現場の問題点共有や改善が早くなった
⑦複数ある現場での進捗状況がリアルタイムに分かるので管理する側としては安心できる

契約書　タブレット電子署名システム

• 画面数：約20画面
• バックエンド　Python + Flask + PostgresSQL
• フロントエンド　HTML + CSS + JQuery +Jinja2テンプレート
• プラットフォーム　Heroku
• データ件数　年間500件程度
• 主な機能：iPadでのスタイラスを使った署名システム、契約書PDFファイルの登録、ユーザーと契約データの紐付け、自動メール送信システム
• 制作期間：1.5ヶ月
• 構築価格目安70万円
• 月額保守費用目安10,000円

食品衛生検査　情報登録アプリケーション

• 画面数：１画面（シングルページアプリケーション）
• フロントエンド：HTML + CSS + JQuery
• バックエンド：PHP
• 主な機能：HTML上の食品衛生に関する条件において、テーブルデータの動的な組み替え、検査数値を判断した動的な判定可否システム、AJAXによる非同期でのサーバー保存
• 構築価格目安40万円
• 月額保守費用目安なし

訪問看護・訪問介護　スケジュール作成支援システム

• 画面数：約5画面
• バックエンド　Python + Flask + PostgresSQL
• フロントエンド　HTML + CSS + JQuery +Jinja2テンプレート
• プラットフォーム　Heroku
• 主な機能：既存のクラウド型スケジュール管理システムに自動ログインし、スクレイピングで各従業員の稼働時間をチェックする。訪問業務でより効率的なスケジュール構築を支援するシステム
• 構築価格目安20万円
• 月額保守費用目安なし

タイヤ交換作業所　社内システム

• 画面数：60画面
• バックエンド　Python + Flask + PostgreSQL + mongoDB
• フロントエンド　HTML + CSS + JQuery +Jinja2テンプレート
• プラットフォーム　Heroku
• 主な機能：価格比較サイトから特定条件にてスクレイピング技術を使いタイヤ価格を自動取得する。
• 主な機能：取得した価格情報は毎晩自動更新され、ドキュメントデータベースに格納される。
• 主な機能：ランティングページからはタイヤサイズに応じてAjaxにて検索出来注文できる。
• タイヤ交換ピットの予約をユーザーが行える時間管理
• タイヤ予約情報を管理側で確認しデータを更新するシステム
• タイヤ販売後のタイヤ調達・決済・ピット予約までを一貫管理するシステム
• 構築価格目安350万円
• 月額保守費用目安20,000円
• 製作期間６か月

コンサルティングソリューションのユーザー閲覧システム

• 画面数：30画面
• バックエンド　Python + Flask + PostgreSQL + mongoDB + AWS S3
• フロントエンド　HTML + CSS + JQuery + Jinja2テンプレート
• プラットフォーム　Heroku
• 主な機能：コンサルティングのソリューション資料を有料閲覧会員に公開するシステム
• 主な機能：ＰＤＦをダウンロードできないよう内部レンダリングする仕組
• 主な機能：会員のステータスに応じて表示コンテンツを切り替える技術
• 構築価格目安250万円
• 月額保守費用目安30,000円
• 製作期間２か月

制作料金

制作料金は都度見積となります

主要技術

クラウド型WEBアプリケーションシステムの開発において主に以下の技術を利用します。

使用プログラミング言語（フロントエンド）

HTML / CSS / JavaScript / jQuery / Bootstrap / Bulma.io

使用プログラミング言語（バックエンド）

Python / Flask / PHP

データベース・ストレージ

PostgreSQL / MySQL / MongoDB / AWS-S3 / AWS-DynamoDB

サーバー環境

Heroku / AWS

対応デバイス

デスクトップPC / スマートフォン / タブレット / モバイルレスポンシブ対応

技術水準目安

対応レベルを　最大★５つで表現しています

Python	★★★★★
Flask	★★★★★
HTML+CSS	★★★★★
Bootstrap / Bulma	★★★
JS/jQuery	★★★★★
PHP	★★
MySQL / PostgreSQL	★★★★
MongoDB	★★★★
Excel VBA Macro	★★★★★

タイムカードに頼らない勤務時間管理をしませんか？

クラウドウォッチドッグはPCのログ管理、ITインベントリ管理を行います。
●労基署対応のエビデンスアップに
●ソフトウェアのライセンス数管理に
●私用ソフト、ウイルス対策ソフトのインストールの管理に

「勘違いDX」をしないように

2021年頃から猫も杓子もDXと言うようになりました。しかし多くの企業、経営者、ビジネスパーソンが「DX」の定義を誤っています。DXとはデジタルトランスフォーメーションとのことですが、殆どの企業では「IT化」をDXと言っています。ペーパーレスやデジタルツール活用をDXと呼んでいるのです。

DXが何の意味であるかは他にも記事が山ほど有りますので皆さんも食傷気味だと思います。ここではそのデジタル化が「DXかどうか」を見定める方法を簡単にご紹介します。

（1）売上が増えたらDX

DXは簡単にいえば、売上が増えるデジタル活用です。売上増加には「顧客・売価」いずれかのアップが必要です。顧客が満足度を高めたり、新たな顧客を誘引できればDX成功です。これまでより新しい商品が売れたり、売価が上がればそれもDX成功でしょう。このシンプルな理屈が必要です。

経理のDX、人事のDXという意味不明の用語が溢れています。殆どの場合、経理のデジタル活用、人事のデジタル活用、という意味でしょう。経理をデジタル化しても顧客満足度は上がりません。人事にデジタル活用をしても売価は上がりません。

（2）顧客満足度が上がったらDX

1番のテーマと似ていますが、顧客満足度は重要な視点です。「DXは本来社会を豊かにする取り組み」です。社員の残業が減ったとか、紙が減ったというのは顧客満足に直接的に繋がりません。新しい付加価値ができることで顧客満足度が上がればDXです。

（3）新しい顧客層を獲得できたらDX

これも前述のテーマと繋がる話ですが、DXでは顧客層が増えます。これまでアプローチできていなかった顧客層と成約できればそれはDXです。

（4）商品サービス提供スピードが半分になればDX

DXは「顧客視点での業務プロセスの抜本的な見直し」が提唱されています。DXをしたけれと顧客が注文してから納品するまでにかかる時間が変わらなければDXとは言えません。一方で、顧客の購買や注文プロセスから、商品サービスの提供時間・リードタイムが半分になったとしたらそれはDXと言えるでしょう。

（5）大幅に人員が削減出来たらDX

顧客視点で業務プロセスを抜本的に見直せば、通常2割くらい事業に関わる要員は不要になります。その部門から2割くらい従来業務の人が減ってスリムになれば間違い無くDXができたと言えるでしょう。

人件費は企業原価の3～4割を占めますので、要員がスリムになれば大幅な利益増になります。もし要員が減ってないとしたら業務プロセスを抜本的に見直しできていないと思います。

（6）同業他社の悲鳴が聞こえてくればDX

最後はハードルが高いですが、同業他社の観点です。

業務を抜本的に見直して新しい価値を提供することで新規顧客層を誘引したり、売価が上がれば他社からは悲鳴が聞こえてくるはずです。DXは「デジタル・ディスラプション」とも言われてます。ディスラプションとは「破壊的イノベーション」ということです。同業他社が追従できないくらいのビジネスモデルになっていればそれはDXでしょう。

いかがでしょうか？いままでの延長線上のIT活用ではDXはできないと思います。ひとまずDXかどうかの見極めはこういう視点があるということを覚えておきましょう。

ＤＸ：デジタルトランスフォーメーションがうまくいかない理由

日本では「ＤＸがうまくいかない」と言われていますが、なぜだと思いますか？
いや、ＤＸ以前に「ＩＴ化」も遅れていると言われています。まず始めは「ＤＸ」と「ＩＴ化」をひとまず同じものとしてとらえて日本企業になじまない理由をご紹介しましょう。

ＩＴ化とは本質的に「時間と空間をゼロにすること」と言い換えると分かりやすいと思います。これまで人手でやっていた事がコンピューターに代われば一瞬で業務が終わります。

身近な例であればオンラインショップですね。オンラインショップは実店舗に比べて２４時間３６５日動きますし、店舗に行く必要も無ければ店舗の従業員も要りません。もちろん物理的な店舗も不要です。銀座に行かなくても、遠方から買うことも出来ますし、銀座に従業員が通勤することも、銀座に店舗を建てること（借りること）も不要です。このように時間と空間をゼロにすることがＩＴ化のイメージと思うとよいでしょう。

そうなると様々なＩＴ化で起きることは、「そのために働いていた人が不要」になり「そのための物理的スペースが不要」になります。
とはいえ、「ネットショップを運営する人が必要になるのだから、ＩＴ化後も従業員が必要なのは変わりない」「運営作業をするスペースは必要だ」という意見もあるかと思います。しかし店舗で販売員をやっていた人がネットショップの運営ができるでしょうか。お客様の好みを考えて企画を立案する人は必要かも知れませんが、それはごく僅かです。そして運営に必要なスタッフの数は激減するでしょう。運営スペースも確かに必要ですが、一等地にある必要はありません。ネットにつながるＰＣがあればどこからでも仕事ができます。

仕事はネットショップの在庫管理や、オペレーションとなり、求められるスキルが販売員とは全く異なります。また多くの場合、運営に関する仕事の多くを外注に委託するでしょう。

つまり本気でＩＴ化をするなら、従業員には大幅に辞めていただき、残った人（残りたい人）には大きなスキル転換が必須になる。さらに実店舗が不要になるということです。日本では正社員の従業員を簡単に解雇することはできませんし、既存の店舗の撤退なども考えにくいでしょう。なかなか既存の組織の抵抗に遭って実現できないのではないでしょうか。

そして、「ＤＸ」では、これまでのような一部の業務（例：販売業務→ネットショップ）だけをＩＴ化するのにとどまりません。一つの事業に携わるあらゆる工程・業務をもＩＴ化していき、事業のインプットからアウトプットを一気通貫してＩＴ化するというものです。例えば経理、給与計算、交通費精算などバックオフィスの業務はこの１０年で一貫してＩＴ化の道をたどってきました。同じく対顧客もオンラインショップ、キャッシュレス決済等、人手を介さないツールへの移行が進んできました。

しかし製造業でいえば、開発、調達、生産、といったコア業務がありますが、そのようなコア業務にも「ＩＴ化による時間と空間の削減」を持ち込むというものです。中核業務を担う従業員は多くの場合正社員を雇っています。これまでＩＴ化してきた分野（バックオフィスやフロント業務）では有期雇用社員（アルバイトや派遣社員等）を使っていたので長期的な人材の増減には対応できましたが、中核の正社員（無期雇用社員）を簡単に辞めさせたり配置転換できるわけではありません。

このようにＤＸするには会社をスリム化したり、大幅な従業員スキルの入れ替えが必要になります。部門毎不要になるということもあるでしょう。既存の会社における人間関係に縛られた経営者ではＤＸはできないのです。やったとしても既存の組織に影響のないオマケ的な位置づけでいつまで経っても会社全体のＤＸはできないのです。ましてや大企業の順送り人事で就任したサラリーマン経営者には決してできなことです。順当に任期を満了することが彼らのインセンティブですから。

さて、こうして書いていると否定的な側面ばかりに思われますが、これらは一般的に大企業に当てはまることです。大企業は既存の自社事業が大きく、社内制度や仕組みはすべて既存事業に合わせて作られています。つまり巨人が部分的にダイエットすることを目指しているにすぎないのです。しかし中小企業は違います。既存の自社事業は小さいですから、もっと大きい市場にＤＸされたビジネスモデルで挑めばいいのです。大企業が時間と空間を使って行っていることを横目に、時間と空間を一切省いたプロセスで勝負することができるのです。

もちろん新しくＤＸのための投資が必要でしょう。人材も必要でしょう。しかし大きな市場を取りに行くためにゼロベースで事業を創造できれば既存の大企業の市場を侵食することもできます。仮にそのＤＸされたビジネスモデルを大企業がまねしようにも既存の枠組みと雇用慣行に縛られた状態では手も足も出ないのです。

大切なのは、大企業が一見強みと見える、守って離さないものを、離せないように市場を創造することです。

お問合せ