お問い合わせ
kashimoto 
初めまして、DXBootを運営する（株）クリエイティブユニバース代表の樫本です。
この記事では、弊社のコンサルティングの知見を元に中小企業のDX推進担当になった方にお役に立てればと思い書いています。
特に、小規模なスタートアップから従業員10人未満の経営者などこれからという方には非常に大事なことをお話しています。
もともと私はwebデザイナーのフリーランスだったのですが、webを中心に取引先の会社のITサポートをしていく延長で外部CTO、外部情報システム部的な仕事など手掛け、ITの専門家として仕事をする機会が増えました。
スタートアップのサービス設計・開発に関わる機会も多く、発注側と設計者の両方の経験してきた立場で現在では「サイボウズ社kintone」を使った伴走DX支援、webサイトやメディアを活用した集客からCRM連携など手掛けています。
DXについては言葉が独り歩きしていて実態を伴っていないと感じることが多く、この記事を通じて少しでも多くの人が本当の意味でDXに繋がれば嬉しいと考えています。
そもそもDXの定義とは？
まず大前提として認識合わせのために「DXとは？」をおさらいします。
DXの本来の意味は「デジタル・トランスフォーメーション」と言われ、デジタルを通じて働き方や経営に変革をもたらすものです。
しかし、実際のところ経済産業省の情報処理推進機構（IPA）が公開している「DX白書」などを見たり、弊社も実際に大阪府や堺市、神戸市など行政のヒアリングをさせて頂いた限りではITにこれまで投資をしておらず、IT負債を解決しなければならないという現場がまだまだ非常に多いのが現状です。
つまり、DXは本来の意味である「DXして変革を起こそう！」というデジタライゼーションの側面と、「ちゃんとITを活用したい」という企業のIT化促進の２つの側面があります。
DXを失敗するパターンをまずは知ろう
まずプロジェクト成功のコツは成功する方法を探すのではなく、失敗する方法を知ることです。成功要因というのは表に見えない様々な要因があります。とても優秀なリーダーがいた。良い開発会社パートナーがいた。予算が潤沢だった。表向きの事例だけでは見えないものがたくさんあります。
ここではいくつかの失敗パターンを紹介します。
1.知識がなくてハンドリングできず、使えないシステムが出来上がり予算を失ってしまった
DX推進担当になって計画を立てていくとおそらく大半の場合は何かしらシステム設計・開発に手を出すことになります。
弊社でも良く遭遇したお話で言うと発注者と開発者の2社間で進んでいるケースが多いのですが、
発注者側：開発の専門家がおっしゃってるからそうなんだろうな・・・
開発者側：発注者の要望でそうしたいなら違和感あるけど現場ではそういうもんなんだろう・・・
とお互い相手を配慮した結果、後から「ちょっと待てよ・・・」とトラブルや意見の相違が発生する状態になることが非常に多いです。
高いお金を払ったけどひどかったという話の大半はこのような話が多いのです。
実際に弊社でも依頼を受けてコンサルティングする際は、経営者が話すサービスのプレゼンテーションを自分でも語れるぐらい理解し、現場がどういうことを大事に活動しているかも視察させてもらったりして「顧客視点：サービス運営している視点」をちゃんと手に入れてから設計・開発を考える必要があります。
2.絵に描いた餅状態で先行して作り込んでしまった
こういうことがやりたい！というのが明確にあるのは素晴らしいことです。
しかし、超ベテランのシステム開発、経営者でも「自社にフィットするサービス・業務システムを作る」の経験値がなく初めての場合はほぼ100%で想定外、予想外のことがおきます。
だからこそ段階的に開発を進めたり、試験運用・検証ができるようなバッファを持たせたりしながら進行させることが失敗を防ぐ上で大切です。
弊社でもUIデザインを担当することがしばしばありますが、やりたいことを全部踏襲していくと本当に大事な機能じゃない今は不要な機能にリソースを割いてしまうことがあります。
どれだけ高性能なパソコンでも「コピー＆ペースト」ができないパソコンは誰も欲しくありません。同じように本当に大事なコアな機能に注力せず、あれやりたい、これやりたいを開発してしまうと後から「こんなはずじゃなかった・・・」となりがちです。
この話は後述の「MVPを作ろう」にてより詳しく解説します。
3.いざ現場で運用したら追加改修が大量に発生した
上述したように、開発者は運用のプロではありません。試験運用せず、現場に導入したら当然多数の問題がでてきます。
弊社で良く遭遇するのは
- 現場のIT活用レベルが低すぎてExcel管理などから脱却できない
- 広告や成果確認のための外部連携ツールとシステムが連携できない
- 社内の情報管理とシステムの情報管理のフォーマットが違うため変換作業が必要になる
- 行政などの委託業務で、とあるシステムの利用が契約に入っていて移行できない
などです。これらは防げないのでしょうか？
これを防ぐにはすべてを熟知した人が全体を見て設計する必要がありますがあまり現実的ではありません。
だからこそ、ある程度バッファを持ち、設計に柔軟さを持たせる必要があります。
弊社の経験上、現場の人間3-5人ぐらいにテストしてもらうとおおよそ大きな問題は把握できるので、ぜひ現場の導入運用テストをしましょう。
まずは「アイデア」を募る環境を整えるよう
DXを推進していくためにはどうしても業務の変革が必要となります。多くの場合、新しいシステム・やり方への抵抗感があり、反発もあるでしょう。
システムというのはITのリテラシー不足から「余計なことをしてはいけない」と考えている方が非常に多いです。しかし、DXを目指すためには今の業務はどのように変化すると自分たちの働き方が豊かになるかイメージできる必要があります。
これまでの経験から仕事の打ち合わせとして議題を決めて打ち合わせをしても、本当に必要最低限のことしか分かりません。ちょっとした雑談のような余白でポロッと話したことが、実は大事なことというのも珍しくありませんので、実は雑談もかなり大事だったりします。そのためなるべく会社のことはもちろん、業界のこと、小さな悩みなどヒアリングしていく必要があります。
その上でディスカッションを通じて素材が集まってくると「アイデア」のイメージが湧いてきます。
「もしかしたら今使っているチャットツールに通知が来たら嬉しいかも？」
「もしかしたら、あのデータ、ここにあると自動でグラフにできたりします？」
「もしかしたら、この業務無くても困らないです？」
このようなアイデアが生まれる余白がDXを進めていくには重要です。そして組織がこういうアイデアを出すことになるで自然と「うちの会社、こんな風にDXしたらいいかも？」とイメージが湧くようになれば一つのDX文化ができたと言えるでしょう。
雑談が大事というお話はあべのハルカスで開催した「DXサムライ Vol.01」で「中小企業DX事例から見るスモールステップDX」というタイトルでお話させていただきました。詳しくは下記レポートをご覧ください。
MVPを作ろう。本当に大事なことなのでもう一度いいます。MVPを作ろう！
MVPは「実用最小限の製品：Minimum Viable Product」という意味です。本当に必要な最低限の機能のことを言います。
何度もこの例を口酸っぱく言わせていただきますが、どんなに高性能なパソコンでもコピー＆ペーストできない、書類作成や表計算ができないパソコンは買いたくありません。このようにそのシステム運用において本当に絞って大事な機能を作ることがプロジェクトを上手く達成するためにとても重要なのです。
弊社も以前はお客さんはより便利な機能がたくさんあったほうが嬉しいと考えていたのですが、逆に移行コストや習得コストが発生したり、運用開始してからより必要な機能のアイデアがでたりと良いことはあまりありませんでした。
そのためシステムを開発する上でDXBootでは顧客に説明するときは「検証が可能な最小限のプロダクト」を作りましょう！とお伝えしています。
知識ないまま投資するのは、将来設計無いままマイホームを買うようなもの
弊社ではDXの伴走支援をしていく上でとても重要視してるのが「担当者の知識」です。当然多くの場合の発注者はその知識を持ち合わせていません。
DXBootでは大きな開発に入る際は必ずシステム設計ワークショップを開催します。これにより互いに認識を合わせることはもちろんのこと、お客さんのメンバー間でも認識のすり合わせや自分たちが今から挑戦する全貌がどのようなものなのか把握することで正しい設計や運用計画を立てることができます。
DXはITツール導入ではなく、経営・組織改革である
ここまで説明させて頂いてかなり視野が広がったのではないかと思います。DX支援・推進において本当に大事なの「システムを作ること」ではなく「システムを通じて経営改革・組織改革を実現していく文化作り」なのです。
この本質を外したままプロジェクトが進んでしまうと発注者もシステム開発会社もお互いに不幸になってしまうことでしょう。
互いに本当にその会社の未来が良くなっていくのか？日々お客様からの利益を積立てて投資して作るシステムは本当に必要なのか？本当にこの機能でいいのか？を考え抜いて考え抜いて考え抜く必要があります。
ふわっとした知識やツールの使い方ではなく、会社の未来を変えるコンサルティングをツールを通じて実現していくのが弊社が考える本当のDX支援だと考えています。
そしてコレを実現していくためには一緒に会話ができるように発注側の担当者にも知識を手に入れて貰う必要があります。だからこそ弊社は伴走型支援を重視しています。
そして、どれだけ大手か、実績が豊富かよりも担当者と開発担当が互いに理解し合い、一緒に本気で未来を考えることができ、その仮説検証をしていけるリソース確保や周りの人の協力など必要なのです。だからこそDXやシステム発注というのはとても難しいのです。
先人の事前知識をしっかり学ぼう〜DX白書2023〜
実はDXに関してはIPA（情報処理推進機構）が「DX白書」というものを発刊しています。無料でPDFも見れますのでこちらコンテンツを学ぶことで今の日本のDX事業がかなり見えてきます。
読む時間がない方は、雰囲気を掴むのに感想ブログを読むと参考になるでしょう。いくつかピックアップしますのでご参考までに。
事業と一緒にシステムを育てていこう
以上お読みいただきありがとうございました。
この記事を通じて一社でも関西を始めとする中小企業が無駄に使えないシステムに多額の投資することが減ることを祈っています。
あなたが会社の未来や自社の事業について熱く語っているのに「そんなことよりも作るシステムの要件を決めましょう」と進めようとする会社は要注意です。
この世界、そんなに甘くはありませんので参考にしてください。
システム開発は難しく、作った当初はそれでよかったけど1年運用したら話が変わってきたなど珍しくありません。いきなり多額の投資をするのではなく、スモールステップで始めて状況に応じてじわじわ一緒に育てていく方式をオススメしています。
DXBootではkintoneを使った伴走支援や、ミニマムでWebサイトにシステムを乗せて事業のスモールスタート支援など提供しています。従業員10人以下の規模感でも大歓迎なのでご興味ある経営者、ご担当者様はぜひお問い合わせください。
▼kintoneについて詳しい記事をご用意しました。クラウド型の業務改善プラットフォームにご興味ある方はぜひご覧ください。
▼2023/09/04 DX支援事例を追加しました。
DXにおいて大事なことはたくさんあると思います。ですが、シンプルなゴールとして「本当に大事なことのために時間を増やせるか？」が命題だと思っています。
