フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月(人工)単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

関連記事

開発の遅延「技術的にはできます」の罠

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか?
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか?
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。

続きを見る >

上司を動かすDX推進術

上司が首を縦に振らない現実

「DXを進めたいのに、上司がまったく理解してくれない」。これはDX推進を任された担当者が最も多く抱える悩みのひとつである。現場では業務効率化やデジタル活用の必要性を日々感じているのに、いざ上司に提案すると「今のままで十分回っている」「よくわからないから後にしてくれ」と一蹴されてしまう。この認識のズレは単なる世代間ギャップではなく、DXの本質が正しく共有されていないことに根本的な原因がある。

上司世代が抵抗する3つの理由

上司世代がDXに消極的な理由は主に3つある。第一に、成功体験への執着である。従来のやり方で結果を出してきた上司にとって、業務プロセスの変更はリスクにしか映らない。第二に、デジタル技術への不慣れである。ITツールに日常的に触れてこなかった世代ほど、新しいシステムの導入に対する心理的ハードルは高くなる。第三に、評価制度との不一致である。短期的な売上や数値目標が評価軸になっている場合、すぐに効果が数字に表れにくいDX投資は優先順位が下がる。こうした構造的な背景を理解せずに「DXは必要です」と正論をぶつけても、上司の心には響かないのが現実だ。

上司を動かす3つの巻き込み術

では、どうすれば上司をDX推進の味方にできるのか。効果的なアプローチを3つ紹介する。まず、「DX」という言葉を使わないことだ。上司にとってDXはカタカナ用語の塊であり、抽象的で自分ごとに感じにくい概念である。代わりに「月次レポートの作成時間を半分にできます」「入力ミスによるクレームを8割減らせます」といった具体的な業務課題に紐づけて提案すべきである。次に、小さな成功事例をつくることだ。Excelマクロの自動化やクラウドストレージの導入など、低コストかつ効果が実感しやすい施策から着手し、目に見える成果を上司に報告する。最後に、競合他社の事例を活用することである。「同業のあの会社はもう取り組んでいる」という情報は、上司の危機感を最も強く刺激する説得材料になる。

上司は敵ではなく最大の味方

上司を巻き込めないままDXが停滞すると、競合との差は開く一方だ。しかし悲観する必要はない。上司が理解してくれないのは、提案内容が間違っているのではなく、伝え方と巻き込み方にもう一工夫が必要なだけである。大切なのは、上司を「抵抗勢力」ではなく「味方にすべき最重要キーパーソン」として捉え直すことだ。上司が何を重視し、どんな成果を求められているのかを把握した上で、相手の立場にメリットが伝わる提案に再構築すべきである。DXは担当者一人で進めるものではない。上司の理解と後押しがあってこそ、組織全体を巻き込んだ本当の変革が実現する。焦らず戦略的に、一歩ずつ認識のギャップを埋めていくことが重要だ。

まとめ

上司がDXに消極的な原因は世代差ではなく、伝え方と評価構造のズレにある。「DX」という言葉を避けて具体的な業務改善として提案し、小さな成功体験を積み重ねて見せることで、上司の認識は確実に変わる。上司を味方につける戦略的アプローチこそ、DX推進を成功に導く最大のカギである。

続きを見る >

小さく始めるDX

そのDX、止まっていないか

「DXを進めたい」と思いながら、何から手をつければいいか分からず止まっている。そんな中小企業はとても多い。全社改革・大規模システム・多額の投資——そんなイメージが先行し、最初の一歩が重くなってしまう。結果として計画ばかりが膨らみ、現場は何も変わらないまま時間だけが過ぎていく。実はこの「大きく考えすぎる」ことこそ、DXが進まない最大の原因である。

小さく始める

そこで有効なのが「スモールスタート」という考え方だ。経済産業省のDXレポートでも、失敗企業の典型として「最初から大規模プロジェクトを立ち上げ、要件定義に1年以上かける」ケースが挙げられている。逆に言えば、最小単位の業務から手をつければ、リスクも投資も最小限に抑えられるということだ。たとえば紙の日報をアプリに置き換える、Excel管理をクラウド化する。たったそれだけでも、現場は「変わった」という手応えを確かに得られる。

1ヶ月でアプリは作れる

私たちADXには、実際に「1ヶ月でアプリが完成した」という実績がある。ポイントは、すべてを一度に変えようとしないことだ。まず一つの業務、一つの困りごとに絞り込み、Power Appsなどのローコードツールで素早く形にしていく。最初から完璧を目指さず、現場が実際に使いながら少しずつ改善していく。この進め方なら、専任のIT人材がいない中小企業でも無理なく続けられる。そして小さな成功体験が一つ生まれると、社員自身が「次はこの業務も変えたい」と前向きに動き出す。外から押しつけるDXではなく、現場の内側から育つDX——これこそが、本当に根付く変革の入り口になる。

小さな一歩を育てる

大切なのは、小さく始めたあとに「育てる」視点を持つことだ。一つの業務で成果が出たら、その効果を社内で共有し、隣の部署、別の業務へと少しずつ広げていく。最初から完成形を描く必要はない。現場の声を拾いながら、必要な機能を一つずつ足していけばいい。この「小さく始めて、大きく育てる」サイクルが回り出せば、DXはもはや特別なプロジェクトではなくなる。日々の業務改善の延長線上に、自然とデジタル活用が組み込まれていく。背伸びをした投資ではなく、等身大の一歩を積み重ねること。それが、中小企業にとって最も現実的で、最も確実なDXの進め方である。

まとめ

DXは「大きく考える」ほど止まり、「小さく始める」ほど前に進む。最小単位の業務をアプリ化して成功体験を積み、それを少しずつ周囲へ広げていく。この進め方なら、人材も予算も限られる中小企業でも、今日から確実に動き出すことができる。必要なのは完璧な計画ではなく、まず一歩を踏み出す勇気だ。その小さな一歩こそが、やがて会社全体を変える確かな変革の始まりになる。止まっていたDXを、今こそ動かしてみないか。

続きを見る >