要件定義のアプローチ

Excelの限界

Excelは多くの中小企業で業務の中心を担っているが、運用を続ける中で限界を感じる場面が増えていないだろうか。「ファイルが重くて開けない」「誰かが数式を壊してしまった」「最新版がどれかわからない」――こうした問題は、Excelでの管理が業務の規模に合わなくなっているサインである。使い慣れたツールだからこそ、課題に気づきにくいのが厄介な点だ。

3つの課題

Excel業務の課題は、大きく3つに整理できる。1つ目は「属人化」である。作成者にしかわからない複雑な数式やマクロが組まれ、その人がいないと修正も更新もできなくなる。2つ目は「保守性の低さ」である。ファイルが壊れたり、バージョン管理ができなかったりするリスクが常につきまとう。3つ目は「共有の不便さ」である。同時編集の制限やメール添付でのやり取りは、情報の行き違いやミスの原因になる。これらは個人の注意力では解決できない、構造的な問題である。

アプリ化で変わること

これらの課題を解消する方法の一つが、Excel業務のアプリ化である。Power Appsを使えば、Excelのデータをそのまま活用しながら、入力画面や承認フローを備えたアプリを作成できる。アプリ化のメリットは、まずデータの一元管理が可能になることだ。誰がいつ更新したかが記録され、属人化のリスクが下がる。また、スマートフォンからも操作できるため、現場での入力作業が格段に楽になる。さらに、入力規則を設定することでミスを未然に防ぐ仕組みも組み込める。Excelの「便利だけど不安」を、「安心して使える」に変えることができるのだ。

着手する業務の選び方

アプリ化を始めるなら、まずは効果を実感しやすい業務から着手するのがポイントである。たとえば、見積もりの計算、在庫の集計、日次の報告書など、Excelで繰り返し行っている作業が最初の候補になる。ある企業では、Excelの計算シートをPower Appsでアプリ化した結果、入力ミスが大幅に減り、作業時間も短縮された。大規模なシステム導入ではなく、身近な業務の改善から始めることで、現場の納得感を得ながらDXを進められる。「Excelをやめる」のではなく、「Excelの良さを活かしながら進化させる」という発想が大切だ。

まとめ

Excel業務の「属人化・保守性・共有の不便さ」は、アプリ化で解消できる。Power Appsを使えば、Excelのデータを活かしながら安心して運用できる仕組みに変えられる。まずは繰り返しの多い業務から、小さく始めてみてほしい。

IoT導入の落とし穴

製造業や物流業を中心に、IoTセンサーやデバイスの導入が加速している。設備の稼働状況、温度・湿度、位置情報など、あらゆるデータがリアルタイムで収集できる時代になった。しかし、IoTを導入したものの「期待した業務改善効果が得られない」という声が多く聞かれる。データは確かに取得できているのに、なぜ業務改善に結びつかないのか。この問題は多くの企業が直面している共通の課題である。

データの墓場化

IoTデバイスから送られてくるデータは、サーバーやクラウドに蓄積されていく。しかし、その膨大なデータを見ても「何をすればいいのか分からない」という状況に陥る企業が少なくない。ダッシュボードには数値やグラフが表示されているものの、それを見て具体的なアクションを起こせる人材がいない。結果として、高額な投資をしたIoTシステムが「データ収集マシン」で終わってしまい、経営層からは「費用対効果が見えない」と指摘される悪循環に陥る。

失敗の典型パターン

活用が進まない企業には明確な共通点がある。第一に「導入目的が曖昧」なケースだ。「とりあえずIoTを入れてみよう」という姿勢では、取得すべきデータの種類も不明確になる。第二に「データ分析のスキル不足」である。統計知識やデータ分析ツールの使い方を理解している人材がいなければ、データから意味のある洞察は得られない。第三に「業務プロセスとの連携不足」だ。データ分析の結果を実際の業務改善アクションに落とし込む仕組みがなければ、分析は絵に描いた餅で終わる。これらの問題は技術以前の、組織体制や戦略の問題なのである。

正しい活用ステップ

IoTを真に業務改善につなげるには、段階的なアプローチが必要だ。まず「解決したい課題」を明確にし、その課題解決に必要なデータだけを取得する設計から始める。次に、データを見える化するだけでなく、「どの数値がどうなったら、誰が何をするか」というアクションルールを事前に設定する。さらに、現場担当者がデータを日常的に確認し、判断できるよう、シンプルなダッシュボードと教育体制を整えることが重要だ。IoT活用は技術導入ではなく、業務プロセス改革として捉え、全社的な取り組みとして推進することで初めて成果が生まれる。

まとめ

IoTで業務改善が進まない企業の共通点は、データ収集が目的化し、活用のための戦略・スキル・体制が不足している点である。導入前の課題設定、データ分析人材の育成、業務プロセスへの組み込みという3つの要素を整えることで、IoTは真の業務改善ツールになる。技術導入だけでなく、組織全体での活用文化の醸成が成功の鍵である。

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。