QCDの死角

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

デジタル化は効率化を保証しない

デジタル化と聞くと、多くの人が効率化を期待する。しかし、たとえばFAXで受け取った紙の受注をOCR（文字認識）でデジタルデータ化し、データベースに保存しても、それは単なるデジタル化に過ぎない。デジタル化を行うだけでは本質的な効率向上は望めず、業務フローの見直しがなければ効果は限定的だ。

非効率なフローをそのままデジタル化するリスク

最も大きな問題は、業務フローを見直さずにデジタル化を行うことだ。従来の手作業のフローをそのままデジタル化すれば、かえって作業が煩雑化し、時間がかかることもある。特にITに疎い権限者が意思決定を行う場合、このような失敗はよく見られる。「デジタル化＝効率化」と誤解し、実際には逆効果となるケースも少なくない。

俯瞰できないシステム担当者の問題

システム担当者やシステム会社が、俯瞰的な視点を持たない場合も問題だ。業務フローを把握せず、指示通りにデジタル化を進めれば、非効率なシステムが出来上がる。ユーザー部門は「IT化で逆に効率が悪くなった」と感じ、最悪の場合、システムが欠陥品だと誤解されることもある。業務の流れを把握し、適切にデジタル化を進めることが必要だ。

生成AI導入の失敗例

生成AIの導入に関する相談も増えているが、その多くは「期待通りに動かない」という内容だ。その原因は、多くの場合、AIが本来必要ない箇所に導入されていることだ。たとえば、ただのデータ管理であれば、生成AIではなくRDB（リレーショナルデータベース）のほうが合理的だ。効率を上げるには、AIの利用が本当に適切かを見極める判断力が必要だ。

まとめ

「ITが分からないから任せる」という姿勢はリスクが高い。ITを知らない人がIT化を進めるのは、決算書を読めないのに経営をするのと同じだ。業務フローを理解し、技術を正しく活用するには横断的な視点と経験が不可欠だ。

誤解されるコスト削減

実はローコード・ノーコードツールを使えば、開発が必要なくなるので安くなるというのは正しくない。たしかに、ノーコードツールを社内メンバーでCMSを使ってソフトを作るという場面は開発費用はかからない。

CMSとはコンテンツ・マネジメント・システムの略で、たとえばWebサイトのコンテンツを構成するテキストや画像、デザインなどを非エンジニアがプログラミングをせずに作成や管理できる仕組みのことである。ローコードツールはそれに加えて少しのプログラミング知識でシステムやツールを作成できることである。

開発手法の選択基準

断じてローコード開発だからといって安いわけではない。開発手法の特性による得手不得手を上手に使い分けるからトータルとして価格が安くなるということである。非エンジニア営業の金額調整という意味での判断でローコード開発を選択する場合は失敗することがある。

システム導入の本質理解

ローコード開発でも、システム導入の目的や条件が本質的にわかっていなければ、仕様要件のブレによって結果としてトータルが安くなることはない。これはローコード開発ということが問題なのではなく、フルスクラッチ開発であっても、SaaSと利用する場合であっても同じことが言える。

負債の危険

本来ローコード開発が適さない場合にも関わらず無理やりに合わせることで、プログラム部分の複雑性が増し、技術的負債となって大きな問題になっていく。結果として安くはならず、ローコード開発のメリットであるメンテナンス性までも損なうため、トータルで考えると高くなる。

まとめ

お客様の予算内で考えないといけないので、といった口癖があれば注意が必要である。クライアントの言いなり状態であれば、無理な要求は開発における仕様だけではないだろう。金額を含めた総合的な判断ができる人が、結果としてローコード開発を選択するわけである。