AI愛子設計ログ12　3歩進んで2歩下がるソフト開発

続きです。全てのシリーズはこちら
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。

■製造業をソフト開発業の同時運営の難しさ

製造業の現場にいると、「ものを作ってこそ価値がある」という実感が染みついています。材料をセットして、プレスして、1個打ち抜けば確実に10円なりの売上になる。極めてシンプルで、確実性がある。
では、ソフトウエア開発はどうか。

「出来上がれば売れるでしょ？」
「とりあえず作ってみてよ」
「詳しい人に聞けばすぐにできるでしょ？」

このような言葉が飛んできたとき、ソフトウエア開発者は言葉を失います。

なぜなら、ソフトウエア開発は“作ること”それ自体が、極めて不確実で、繊細なプロセスだからです。とくに開発途中のシステムでは、「完成」という概念すらあいまいです。LINE愛子Botのような実験的かつ発展途上のシステムではなおさらで、この違いを根っからの製造業の現場職人にはなかなか理解できません。

■デグレ：開発者を蝕む“見えない後退”

ソフト開発において、最大の敵の一つが「デグレ（デグレード）」です。ある機能を改善したつもりが、別の場所で動作が壊れる。昨日まで動いていた機能が、今日のリリースで動かなくなる。
プレス機で一つ改良したら横の別のプレス機がおかしくなる、なんて普通ありませんからね。

「前に戻すだけじゃん」と思われるかもしれませんが、現実はそう簡単ではありません。

単に“戻す”だけではなく、原因調査・再テスト・依存コードの洗い出しが必要だからです。

しかも、時間が経つほどコードは複雑化します。1つの変更が、意図しない20か所に影響を及ぼすこともある。
改良を加えれば加えるほど、壊れる可能性は高まります。これは物理的な「金型」や「部品」を扱うハードウエアの世界ではありえない話です。

■コードは「読めばわかる」ではない

「詳しい人に聞けば？」という言葉に、多くのソフトウエア開発者は失望します。

コードはレシピや設計図のような“完成品”ではありません。書いた本人ですら、1ヶ月後には読み解くのに苦労する。
それが、ソフトウエアの現実です。

もし、他人のコードを読み解くなら、最低でも以下の工程が必要になります：

– 全体の構造を俯瞰する
– 変数名や関数名の命名ルールを理解する
– 変更履歴とその意図を追う
– 外部連携や環境依存を確認する
– そして、実際に何が動いているかをログやテストで追いかける

それも、こうした何十時間というコードレビューの中でようやく「こういう意図で作ったのか」が見えてくるのです。

つまり、コードは「知識」ではなく「経験」と「文脈」です。

■「三歩進んで二歩下がる」開発の本質

製造業では、「手戻り」はあっても、1度作った型や部品は明確に残ります。しかし、ソフトウエアでは進んだと思ったその一歩が、見えない地雷を踏んでいて全部壊れていたことに後から気づきます。

だから、LINE愛子Botの開発も、「三歩進んで二歩下がる」どころか、「四歩進んで五歩下がって一歩半だけ横に進む」ような日もあります。

それでも、全体としては必ず前に進んでいる。見える形ではなく、内部構造や柔軟性、拡張性といった“基礎体力”が少しずつ育っているのです。

■ソフトは完成してからがスタート

「まだ完成してないんですか？」
「そろそろ納品できるでしょ？」

そう言われた時点で、ソフト開発における“完成”の定義を改めて伝える必要があります。

ソフトウエアは、完成してからも“使われながら成長する”存在です。

LINE愛子Botも、「使われることで現場の声を吸い上げ、より現場に寄り添った形に育っていく」。そのためには、一見“無駄”に見える小さな修正やバグ対応の積み重ねが不可欠なのです。

■製造業とソフトウエアの違いを尊重する

ものづくりの現場では、「作れば売れる」感覚が強く根づいていますが、ソフトウエアは「作っても、それが正しく動き続ける保証はない」ため、作るだけではなく、育てて、保守して、変化に耐えるようにするまでが製造になります。

製造業が「1つ1つ丁寧に形にする」世界だとしたら、ソフトウエアは「見えない論理を設計し、巨大なシステム破綻せずに動かし続ける」世界です。
どちらも、プロフェッショナルの矜持がかかった技術の結晶。
互いをリスペクトしながら、次の時代を一緒に創っていけたらと願います。

コメント