予算ブレの原因

開発の変動要因

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

目標変化と予算

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

計画型開発法

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

柔軟な開発手法

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

まとめ

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

関連記事

フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月(人工)単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

続きを見る >

システム開発の混迷

営業依存の弊害

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

役割の細分化

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

開発の本質

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

相互理解

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

まとめ

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

続きを見る >

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

続きを見る >