運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

関連記事

DX抵抗の本質

「現状維持」の本音

DX推進の現場で最もよく聞かれる言葉が「今のままで十分回っている」という声である。しかし、この言葉の裏には単なる保守的な姿勢だけではない、切実な事情が隠れている。現場担当者にとって、新しいシステムの導入は「業務負担の増加」と「習熟までの不安」を意味する。日々の業務をこなしながら新しいツールを覚える余裕がない、というのが本音なのだ。この心理を理解せずにDXを押し進めても、形だけの導入に終わってしまう。

抵抗の3要因

現場のDX抵抗には、大きく3つの要因がある。1つ目は「自分の仕事がなくなるのでは」という雇用への不安である。効率化によって人員削減されるのではという恐れが、無意識の抵抗を生む。2つ目は「これまでのやり方を否定された」という感情的な反発である。長年培ってきた業務ノウハウを軽視されたように感じ、心理的な壁が生まれる。3つ目は「導入後のサポート体制への不信感」である。過去にシステム導入で混乱した経験があると、また同じことが起きるのではと警戒心が強まる。これらは論理ではなく感情の問題であり、丁寧な対話なしには解消できない。

現場を味方にする方法

現場の抵抗を協力に変えるには、戦略的なアプローチが必要である。まず「スモールスタート」で成功体験を積むことが重要だ。全社一斉導入ではなく、協力的な部署や担当者から小さく始め、目に見える成果を出すことで周囲の関心を引く。次に「現場キーマンの巻き込み」が効果的である。影響力のあるベテラン社員をプロジェクトメンバーに加え、当事者意識を持ってもらうことで、自然と周囲への波及効果が生まれる。そして最も大切なのが「目的の共有」である。DXは手段であり、目的は現場の負担軽減や働きやすさの向上であることを繰り返し伝える必要がある。「あなたの仕事を楽にするため」というメッセージが、抵抗感を和らげる鍵となる。

DX定着の共通点

DXに成功している企業には共通点がある。それは導入後も現場との対話を継続していることだ。システムを入れて終わりではなく、定期的なフィードバック収集と改善を繰り返すことで、現場の声がツールに反映される実感が生まれる。この「聞いてもらえている」という感覚が、次の変化への受容性を高めるのである。また、成功企業は小さな改善成果を積極的に社内共有している。「このツールで月5時間の作業が削減できた」といった具体的な数字は、懐疑的だった社員の心を動かす。DXは一度きりのプロジェクトではなく、現場と伴走し続ける長期的な取り組みであると理解することが、真の定着への第一歩である。

まとめ

現場のDX抵抗は、単なる保守性ではなく、不安や過去の経験に基づく合理的な反応である。この心理を理解し、スモールスタート、キーマンの巻き込み、目的の共有という3つのアプローチで丁寧に進めることが成功の鍵となる。DXは現場を敵に回すものではなく、現場を味方につけてこそ真の効果を発揮する。

続きを見る >

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

続きを見る >

Power Appsで簡単に業務改善

システム開発の高コストと複雑化

多くの企業では、情報システム部門や外部システム会社にシステム開発を依頼すると、仕様確認が繰り返される。「この機能はどうするか?」「ステータスはこれで全てか?」など、質問が多く、時間とコストが増大。結果、システムは複雑化し、現場のニーズに即したシンプルな解決策から遠ざかる。

野良プログラムのリスク

システム開発の手間を避けるため、各部署でExcelマクロによる「野良プログラム」が横行する。これらは各人のPCに保存され、最新版の確認が困難になり、メンテナンスも不透明。担当者がいなくなるとブラックボックス化し、セキュリティリスクも増加。放置すれば、企業全体の業務効率が低下し、情報漏洩の危険もある。

Power Appsで迅速なシステム構築

こうした問題を解決するのが、MicrosoftのPower Appsだ。従来の複雑な開発プロセスを排除し、現場担当者が自らアプリを構築できる。ドラッグ&ドロップで簡単に操作でき、セキュリティもMicrosoft標準に準拠。野良プログラムの乱立を防ぎ、システム管理とメンテナンスも容易になる。さらに、ユーザー自身がアプリを修正できるため、柔軟性も確保できる。

定量化困難な業務もデジタル化

業務のデジタル化は、数値で説明可能なタスクは簡単だが、現場には「説明しにくい」業務も多い。こうした業務は経験に依存しがちで、担当者に頼ることが多い。Power Appsは、このような曖昧な業務も迅速にアプリ化し、標準化と効率化を同時に実現する。

まとめ

Power Appsは、現場主導でアプリを作成・管理できる柔軟性を提供し、野良プログラムのリスクも解消する。複雑な開発プロセスを省き、数値化しにくい業務も効率的にデジタル化することができる。

続きを見る >