「同じことが安くできます」ではなく「今できないことができます」——無償ソフトの使いどころ

結論を先に書く。

**無償ソフトへの置き換えを「経費削減」として提案すると、たいてい途中で止まる。**止まる理由ははっきりしていて、削減額と、慣れたものを捨てる面倒くささが釣り合わないからだ。数万円のために全員の手を止めるのは、普通に考えて割に合わない。

だから私は、別の言い方をしている。「今のソフトではできないことが、できるようになります」。

これは値段の話ではない。できることの範囲が広がるという話で、成立すれば経費削減よりずっと強い理由になる。ただし成立する条件がはっきり決まっていて、そこを外すと何も起きない。

この記事はその条件と、代わりに増えるリスクを書く。順序は次のとおり。（1）「上位提案」の定義、（2）これで解決しないこと、（3）成立する要求・しない要求、（4）例外、（5）実務でどうだったか、（6）今日15分で試せること。

何を「上位提案」と呼んでいるか

定義する。ここで言う上位提案とは、いま使っているソフトの標準機能には無く、今後も入る見込みが薄い要求を、外側から満たすことを指す。

具体的には、こういう要求のことだ。

図面や帳票の中身と、別に管理している台帳を突き合わせて、食い違いを出したい
標準機能には無い切り口で集計したい
自社の決まりごとに沿ったチェックを、提出前に自動でかけたい
出来上がったものを、決まった形に整えて別のシステムへ渡したい

**どれも「ソフトの機能が足りない」という話ではない。**むしろ商用ソフトは高機能だ。問題は、その高機能が、そのソフトの中でしか使えないことにある。

なぜ使えないかというと、データを独自の形式で内側に抱えているからだ。外から開けない。だから「この一点だけ欲しい」と思っても、要望を出して次のバージョンを待つしかない。**そして多くの場合、待っても入らない。**自社だけの要求だからだ。

**データ形式が開いていれば、待つ必要がなくなる。**外側から読んで、必要な処理を書ける。これが上位提案の中身で、たいていは数十行のスクリプトで足りる。

この方向で解決しないこと

デメリットから書く。上位提案が成立しても、次の5つは解決しない。むしろ4番目と5番目は新しく発生する。

1. 単体の完成度は埋まらない。 繰り返すが、無償ソフトが商用ソフトと同等になることはない。細部の作法、動作の安定、サポート体制。**機能表を並べれば負ける。**上位提案は「別の方向へ伸ばす」話であって、「追いつく」話ではない。

2. データ形式が閉じていたら、何も成立しない。 この記事の全部が、形式が開いていることを前提にしている。中身がバイナリで外から読めないなら、上位提案そのものが存在しない。成立条件の一番目がここで、例外はない。

3. 「作れる」と「安心して任せられる」の間には距離がある。 外から足したツールが正しく動いているかを、誰がどう確かめるのか。この問題は残る。私自身、チェックをAIで支援する検証を進めている最中で、**どこまで任せられるかの精度はまだ言えない。**言えない以上、言わない。

4. 作ったツールの面倒を見る人が要る（新しく発生する）。 数十行のスクリプトでも、作れば保守の対象になる。元のソフトが更新されれば動かなくなることもある。**「作って終わり」にすると、半年後に誰も直せない置き土産になる。**ここは正直に見積もっておく必要がある。

5. 属人化しやすい（新しく発生する）。 小さく作れるということは、一人で作れるということだ。裏を返せば、**その人がいなくなると誰も触れない。**何をするツールなのか、なぜ作ったのかを、動くものと一緒に残しておかないと後で困る。

4番と5番は、上位提案の代償だと考えている。これを言わずに提案するのは不誠実だと思うので、私は最初に言うことにしている。

どういう要求なら成立するか

線引きを表にする。

要求のかたち	成立するか	理由
標準機能に無い切り口で集計したい	○	データさえ読めれば外で計算できる
別に持っている台帳と突き合わせたい	○	両方がテキスト形式なら素直に書ける
提出前に自社ルールでチェックしたい	○	ルールが言葉にできるなら形にできる
決まった形に整えて別システムへ渡したい	○	変換は最も向いている用途
画面の操作性を良くしたい	×	ソフト本体の作りの話。外からは触れない
動作を速くしたい	×	同上
商用ソフトと同じ見た目の帳票を出したい	△	近づけられるが、完全一致は目指さないほうがいい
取引先指定の形式で出したい	△	形式の仕様が公開されているかによる

3行にまとめる。

「データをこう使いたい」という要求は、だいたい成立する。
**「ソフトをこう動かしたい」という要求は、成立しない。**外側からは本体を作り替えられない。
**判断は要求ごとに変わる。**ソフト単位で「できる・できない」を決められる話ではない。

例外——形式が開いていても踏み込まない場合

3つ挙げる。

**要求が年に数回しか発生しない場合。**手でやったほうが早い。作ったツールの面倒を見る手間のほうが上回る。

要求が固まっていない場合。「なんとなく便利にしたい」の段階で作り始めると、作り直しになる。言葉にできるまで待つ。

**間違えたときの影響が大きい場合。**金額の計算や、外部への提出物そのものを自動生成する用途は、チェックの仕組みが先に要る。順序を逆にしない。

実務でどうだったか

私は現在、別の業務領域で、商用ソフトから無償ソフトへの置き換えを実務で進めている（属する組織や製品の名前は書かない）。当初これは「置き換え」のつもりだったが、途中から性質が変わった。

置き換え前のソフトは、実質的に図を描くためだけに使われていた。図が本来持つべき部品の情報は、中に入っていない。だから移行しても失うものが無く、それが踏み切れた理由だった——ここまでは前の記事に書いた。

**変わったのはその先だ。**移行先の形式がテキストだったので、**元のソフトには最初から無かった情報を、この機会に持たせられることに気づいた。**標準となる図面を1枚だけ丁寧に作り、そこに部品の情報を入れる。派生する図面は、そこから複製できる。

つまり**「同じものを安く作り直す」ではなく「前より良いものにする」作業になった。**置き換えのついでに資産ができた、という言い方が近い。

もうひとつ。移行先には部品の定義ライブラリが揃っていなかった。以前ならこれは「だから移行できません」の典型的な理由で、実際そうやって諦められてきた。**形式がテキストなので、この整備をAIに任せられた。**壁が無くなったというより、壁だと思っていたものが壁でなくなったという感覚に近い。

正直に付け加える。**この置き換えは進行中で、完了していない。**派生図面の複製がどの程度の精度と速度で回るか、部品情報の整備に実際どれだけかかったかは、記録として残せる形にできていない。うまくいっていると言えるが、数字では言えない。

なぜ値段の話から始めないのか

最後に、この記事でいちばん言いたいことを書く。

**値段で入ると、値段で比べられる。**安いことを理由に選ばれたものは、もっと安いものが出たときに置き換えられる。それに、経費削減の提案は社内で承認を取るのが意外と難しい。削減額が小さいと、稟議を通す手間のほうが高くつくからだ。

**「今できないことができる」で入ると、比較の相手がいなくなる。**その現場の、その要求に合わせて作ったものだからだ。私が個別に設計する形をとっているのは、これが理由でもある。

もちろん、そのぶん作る側の負担は大きい。既製品を並べて売るのとは違う。**だから最初に、できることとできないことを全部並べる。**上に書いた5つのデメリット——特に「作ったツールの面倒を見る人が要る」と「属人化しやすい」——を最初に説明して、それでも要るかを一緒に確認する。

**要らないと判断されたら、それでいい。**そこで無理に進めたものは、たいてい半年後に使われなくなっている。

今日試せること（費用なし・15分）

自分の現場に上位提案の余地があるかは、15分で分かる。ソフトも要らない。

紙かメモ帳を開き、いま使っているソフトに対して「これができたらいいのに」と思ったことを3つ書き出す。過去に要望を出して「標準機能では対応できません」と言われたものがあれば、それを優先する。
3つそれぞれに、「データをこう使いたい」なのか「ソフトをこう動かしたい」なのかを書き添える。前者なら成立する見込みがあり、後者なら無い。
前者が1つでもあれば、そのデータが入っているファイルの形式を確認する。テキスト形式かどうかの調べ方は別の記事「無料ソフトを選ぶとき、機能表より先に見る1点」に書いた。

**前者が1つもなければ、いまのソフトで足りているということだ。**その場合は置き換えを考える必要がない。これも立派な結論で、確認して何も出てこないことに意味がある。

この記事で書かなかったこと

具体的なツールの作り方・コード（要求ごとに違うため。一般化して書くと役に立たない）
AIによる生成・チェックの精度と速度の実測値（検証の途中で、出せる数字が無い。不明）
作ったツールの保守にかかる費用の相場（実案件で実測して積んでいる途中）
商用ソフトのライセンス費を削減した金額（現場ごとに違うため。自社の請求書で確認してほしい）
既存の保守契約をどう見直すか（別の話題として大きいので、別記事で扱う）