記事

要件定義の問題点

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

AIで何ができるのか 前の記事 開発費用値下げの危険性 次の記事

関連記事

記事

生成AIは使えない？

思い通りにならない理由

生成AIを導入したのに思ったような結果が得られない――そんな経験をしたことがある人も多いだろう。AIは進化を続けているが、それを使いこなす側にも試行錯誤が求められている。特に企業においては、社内情報を整理すればするほど目的の答えに辿り着けなくなる「RAGの沼」にハマることがある。多くの企業が生成AIを武器にしようとしているが、その真価を引き出すには、正しい導入と運用が欠かせない。

RAGとは何か

RAG（Retrieval-Augmented Generation）は、「検索」「拡張」「生成」の頭文字を取った技術であり、生成AIに独自情報を与えることで回答の精度を上げる手法である。インターネット上の情報だけでなく、社内マニュアルや業務データなどを取り込むことで、より業務に即した回答が可能になる。ただし、期待する結果が得られない場合、その原因は提供リソースの質や構造にある可能性が高い。

ChatGPT以外の選択肢

現在、生成AIとして多くの大規模言語モデル（LLM）が存在する。OpenAIのChatGPTをはじめ、AnthropicのClaude、GoogleのGemini、MetaのLLaMA、Mistral、Cohere、さらにAlibabaやBaiduといった中国系ベンダーもある。それぞれに強みがあり、RAGに適したモデルも存在する。たとえばCohereのCommand R+やMistralのMixtralなどが代表的だ。目的に応じてLLMを選び、最適な環境を整えることが重要である。

社内AIを成功させるには

セキュリティ上の理由から、社内情報をインターネットに出せない企業も少なくない。その場合、オンプレミス環境（社内ローカル）に生成AIを構築する選択肢がある。たとえばTinyLLaMAやPhi-2のような軽量モデルから、Nous HermesやMixtralなどの対話・RAG対応モデルまで選択肢は豊富だ。これらを活用すれば、外部にデータを出さずともAIの恩恵を享受できる。必要なのは、自社の目的と環境に適した判断力である。

まとめ

生成AIはあくまで「道具」にすぎない。導入しただけで目的が自動的に達成されるわけではない。課題を定義し、適切な情報を整備し、それを使いこなす力が必要だ。RAGがうまくいかないと感じたら、その原因はリソースや設計のミスマッチにあるかもしれない。

続きを見る >
記事

Excel業務をアプリ化する理由

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のデータを活かしながら安心して運用できる仕組みに変えられる。まずは繰り返しの多い業務から、小さく始めてみてほしい。

続きを見る >
記事

Excel業務のDX化は本当に必要か

DX化の現状

多くの企業でExcel業務のDX化が話題になっている。「Excelは古い」「すぐにシステム化すべき」という声も聞かれるが、本当にすべてのExcel業務をDX化すべきなのだろうか。実は、やみくもなDX化は逆効果になることも少なくない。Excel業務のDX化には正しい順序と判断基準が必要である。本記事では、DX化の利点を理解しながら、適切なアプローチについて考えていく。

DX化の利点

Excel業務をDX化することで得られる利点は確かに多数ある。まず、データの一元管理により情報の正確性が向上し、複数人での同時編集や更新作業がスムーズになる。次に、自動化による作業時間の大幅な削減が可能である。手作業で行っていた集計や転記作業から解放されることで、より付加価値の高い業務に時間を使えるようになる。さらに、データ分析の高度化により、経営判断のスピードと精度が向上する。これらの利点は、企業の競争力強化に直結する重要な要素である。

DX化の落とし穴

しかし、DX化を急ぐあまり失敗するケースも多く見られる。業務フローが整理されていない状態でシステムを導入すると、非効率な業務がそのままシステム化されてしまう。また、現場の声を聞かずにツールを選定すると、使いにくいシステムが現場に定着せず、結局Excelに戻ってしまうこともある。さらに、すべてを一度に変えようとすると、従業員の負担が大きくなり、業務が混乱する。投資したコストに見合う効果が得られず、DX化自体が目的化してしまう危険性もある。適切な準備なしのDX化は、かえって生産性を下げる結果を招くのである。

正しい進め方

Excel業務のDX化を成功させるには、段階的なアプローチが不可欠である。まず、現状の業務フローを可視化し、本当に必要な作業とムダな作業を明確に区別する。次に、Excelで十分な業務と、システム化すべき業務を見極めることが重要である。すべてをシステム化する必要はない。その上で、優先順位をつけて小さく始め、効果を確認しながら展開していく。従業員のITリテラシーに応じた教育も並行して行うことで、スムーズな移行が実現する。DX化は手段であり目的ではない。自社の状況に合わせた最適な方法を選ぶことが、真の業務改善につながるのである。

まとめ

Excel業務のDX化は、正しく進めれば大きな効果をもたらすが、順序を誤ると逆効果になる。利点を理解しつつ、自社の状況を冷静に分析し、段階的に進めることが成功の鍵である。やみくもなシステム化ではなく、業務改善を第一に考えた戦略的なアプローチを取るべきである。

続きを見る >