思考と決断のPM力

PMの真価

スキルシート上にあるPMというのは、どういった開発言語や開発環境などを使ってきたかという内容であることが多く、SEの延長という意味合いが強く残っている。もし、期待するポジションが発想力や提案力にあるとすれば、姿勢をみることが大切となる。

従順の呪縛

就職氷河期と呼ばれる世代より上の年齢層では、常に従うことを幼少期から叩き込まれていると考えられる。日本では「禁止」か「許可」かを常に意識しながら仕事をしており、「許可されるまでは禁止されている」と考えているのではないかと推察される。

失敗からの成長

正しいか、間違っているか、の判断基準しか持ち合わせていない場合、何か問題が発生したときに時間を遡ってどこで判断を間違えたのかを追求する。それは大切なことであるが、実際のプロジェクトでは誤ったことを反省しつつ修正しながら進むことが大切である。

判断力の真髄

エンジニア出身のPM(開発プロジェクトのPM)だと、禁止か許可かというデジタルのような見方をしている人もいる。特に今日のシステムに関するプロジェクトでは、ゼロかイチだけでは判断できないような、ウエットでアナログな状況判断が必要となる。

まとめ

たとえ能力の高いPMだったとしても、仕事になると発想することや作ることの楽しみより、ミスによる懲罰を恐れたりするために、無難で当たり障りのない判断をしがちである。システムに関するプロジェクトがなかなか前へ進まない理由でもある。

関連記事

DX疲れの実態と対策

DX疲れとは何か

DXを推進しなければならないというプレッシャーの中で、現場の担当者が静かに疲弊しているケースが増えている。新しいツールの導入、業務フローの見直し、社内への説明と調整。やるべきことが次々と降りかかり、通常業務との両立に限界を感じている方も少なくない。実はこの「DX疲れ」は個人の能力不足が原因ではなく、組織全体の進め方に根本的な問題が潜んでいることが多いのである。まずはその実態を正しく理解することが、改善への第一歩となる。

疲弊する現場の共通点

DX疲れが広がる現場には、いくつかの共通した特徴がある。まず、DX推進の担当者が少人数、あるいは一人に集中しているケースである。経営層からの期待は大きい一方で、具体的なサポート体制が整っておらず、担当者が孤立してしまう。さらに、短期間で成果を求められることも大きな負担である。DXは本来、段階的に進めるべき取り組みだが、「早く結果を出せ」という圧力が現場を追い詰める。加えて、現場の社員からの抵抗や非協力的な態度も、担当者の精神的な消耗を加速させる要因である。こうした環境では、どれほど優秀な人材でも疲弊するのは当然のことなのだ。

ペース配分という処方箋

では、DX疲れを防ぎながら着実に成果を出すにはどうすればよいのか。最も重要なのは「ペース配分」の見直しである。すべてを一度に変えようとするのではなく、優先順位をつけて段階的に進めることが欠かせない。たとえば、まずは一つの業務プロセスに絞ってデジタル化を試み、小さな成功体験を積み重ねていく方法が効果的だ。また、DX推進を特定の個人に依存させず、チームとして取り組む体制を構築することも大切である。定期的な振り返りの場を設け、進捗と課題を共有することで担当者の孤立を防げる。経営層も「すぐに成果が出るもの」という認識を改め、中長期的な視点でDXを支援する姿勢が求められる。焦らず、しかし確実に前進する意識こそが、組織全体の持続的なDX推進を可能にするのである。

持続可能なDXの実現

DX疲れは、放置すれば担当者の離職やプロジェクトの頓挫といった深刻な結果を招く。しかし、正しいペース配分と組織的なサポート体制があれば、無理なくDXを前進させることは十分に可能だ。大切なのは、DXを「特別なプロジェクト」として切り離すのではなく、日常業務の延長線上に位置づけることである。現場の声に耳を傾け、小さな改善を積み重ねることで、社員一人ひとりがDXの意義を実感できるようになる。また、外部の専門家の力を借りることで、社内だけでは見えなかった課題が明確になり、効率的な推進が可能になるケースも少なくない。DXは短距離走ではなくマラソンである。走り続けられる環境をつくることこそが、真のデジタル変革への近道なのだ。

まとめ

DX疲れは、現場の担当者だけの問題ではなく、組織全体で向き合うべき課題である。無理のないペース配分、チーム体制の構築、そして経営層の理解と支援があれば、持続可能なDX推進は実現できる。まずは自社の現状を見つめ直し、できることから一歩ずつ進めていくべきだ。DXの進め方に悩んだら、こちらの書籍もぜひ参考にしてほしい。

続きを見る >

補助金活用DX入門

中小企業のDX課題

DX推進は中小企業にとって避けて通れない経営課題だが、最大のネックは初期投資コストの高さである。システム導入、クラウドサービス、セキュリティ対策、人材育成と、多岐にわたる投資が必要となり、約65%の企業が費用面での不安を抱えている。しかし、国や自治体が提供する補助金・助成金を戦略的に活用すれば、実質的な費用負担を大幅に抑えることが可能だ。2026年度も多くの支援制度が継続・拡充されており、今こそDXに踏み出す好機といえる。

2026年度の主要補助金

2026年度に中小企業が活用できるDX関連の補助金は多数ある。代表的なのは「IT導入補助金」で、最大450万円まで補助を受けられ、補助率は通常1/2、条件によっては2/3まで拡大される。「ものづくり補助金」は従来のDX枠が廃止され、製品サービス高付加価値化枠に統合された。また「人材開発支援助成金」の事業展開等リスキリング支援コースでは、AI・DX研修の費用を最大75%補助してもらえる。東京都の「DX推進助成金」は最大3,000万円と手厚く、地方自治体独自の支援制度も充実している。なお、事業再構築補助金は2026年3月で終了予定のため、検討中の企業は早急な対応が必要である。

申請成功のコツ

補助金申請で採択率を上げるには、いくつかの重要なポイントがある。まず「自社の経営課題」と「DX導入による具体的な解決策」の関連付けを明確にすることが必須だ。審査では生産性指標の改善や賃上げ・雇用創出への寄与が重視される傾向にあり、数値目標を含む具体的な事業計画が求められる。助成金は着手前に計画書を提出しなければ対象外となるため、事前準備を怠ってはならない。また、認定経営革新等支援機関や金融機関との連携も採択率向上につながる。IT導入補助金の場合は、IT導入支援事業者のサポートを受けることで申請書類の不備を防げる。複数の補助金に並行申請する戦略も有効だが、同一経費への重複利用はできない点に注意が必要である。

注意点と成功事例

補助金・助成金を活用する際は、いくつかの注意点を押さえておくべきだ。まず、どちらも後払い(精算払い)が原則のため、一時的に自己資金で事業を実施する必要があり、資金繰り計画が不可欠である。また、助成金は「人に関する制度」であるため、給与・勤怠・雇用契約などの労務書類が整っていない企業は利用が難しくなる。制度は毎年変更があり、最新情報を常に確認することが重要だ。成功事例として、飲食店がIT導入補助金を活用してPOSシステムとモバイルオーダーを導入し、回転率20%向上と人件費削減を同時に達成した例がある。補助金は単なる費用削減ではなく、企業変革のきっかけとして捉え、戦略的に活用することが成功への近道である。

まとめ

2026年度もDX推進を支援する補助金・助成金制度は充実している。IT導入補助金やものづくり補助金、人材開発支援助成金など、自社の課題に合った制度を選び、事前準備と明確な事業計画を徹底することが採択への鍵となる。制度変更も多いため、最新情報の確認を怠らず、補助金を「成長のエンジン」として戦略的に活用すべきである。

続きを見る >

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

素人仕様と開発遅延

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

潜む技術的負債

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

「できます」の罠

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

持続可能な開発へ

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

まとめ

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

続きを見る >