QCDの死角

営業依存の弊害

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

役割の細分化

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

開発の本質

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

相互理解

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

まとめ

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

素人仕様と開発遅延

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

潜む技術的負債

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

「できます」の罠

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

持続可能な開発へ

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

まとめ

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

思い通りにならない理由

生成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がうまくいかないと感じたら、その原因はリソースや設計のミスマッチにあるかもしれない。