AIが実装を終えた。けれど、顧客はまだその機能を使えない。
仕様の確認が残り、テスト環境が空くのを待ち、詳しい担当者のレビューを待つ。こんな案件を想像すると、コードを書く速度と、顧客に変更が届く速度の間にある距離が見えてくる。
Factoryの「Software Factory」に関する記事を読んで、私はSIerの強みの置き場所を考えた。一つのシステムを作る能力に加えて、そのシステムを変更するたびに、仕事が少しずつ楽になる仕組みを持てるか。 そこに、AI時代の競争力が蓄積するのではないか。
この記事では、元記事の考え方を紹介したうえで、SIerの案件運営と商売に引き寄せて考える。業務例と事業案は筆者の考察であり、Factoryの導入実績を再現したものではない。
Software Factoryが扱うのは、ソフトウェアを届ける工程全体
FactoryはSoftware Factoryを、入力や道具を標準化し、成果を測り、変更の経緯をたどれるようにするソフトウェア生産の仕組みとして説明している。同名の企業・製品と、一般的な概念は区別される。Factoryの元記事
同社の「Factory 2.0」では、要望や不具合報告から、計画、実装、検証、リリース、監視へ進み、運用で分かったことを次の仕事へ戻す構想が示されている。工程をつなぎ、継続して改善することが中心にある。Factory 2.0の発表
私には、この見方がSIerにとって重要に思える。開発者が便利な道具を持つだけなら、効果は個人の作業にとどまりやすい。顧客から依頼を受け、利用開始まで責任を持つSIerには、工程のつなぎ目まで改善する余地があるからだ。
ただし、「工場」という言葉から、どんな依頼でも投入すれば完成品が出てくる姿を想像すると、議論を誤る。顧客が決めるべき業務上の判断と、開発側で繰り返し処理できる仕事を、まず分ける必要がある。
標準化したいのは、顧客の業務よりも「変更の確かめ方」
たとえば、受注システムに返品機能を追加する案件を考える。以下は説明のための仮想例だ。
返品時に在庫を戻す処理は、短時間で書けるかもしれない。しかし、売上をいつ取り消すか、請求締め後の返品をどう扱うか、倉庫への連絡が失敗したら誰が対応するかは、コードだけでは決まらない。
AIへの指示を詳しくすれば済む部分と、顧客と合意しなければ進めない部分がある。ここを混ぜたまま実装だけを速めると、未決定の仕様が、動くコードの形で先に固まってしまう。
私なら、この案件で次の三つを残す。
- 合意した条件：返品できる期間、締め処理との関係、例外時の担当を記録する。
- 条件を確かめる手段：通常の返品だけでなく、締め後や連携失敗時も試せるテストを用意する。
- 本番での確認方法：在庫と請求の不整合をどう見つけ、誰が対応するかを決める。
次に値引きや交換機能を追加するとき、この条件とテストを使えるなら、前の案件の仕事が次の案件の費用を下げる。
反対に、担当者が過去の議事録を探し、同じ説明を聞き直し、同じ失敗をレビューで指摘するなら、経験は積まれていても、仕事の進め方はあまり変わっていない。
業務知識を持っていることと、その知識を次の変更で使えることには、差がある。 SIerが標準化すべきなのは、顧客ごとの業務を無理にそろえることより、条件を明らかにし、確かめ、更新する手順だと思う。
「学習する工場」には、知識を捨てる仕事も要る
過去の指摘をすべて保存すれば、開発は賢くなるのだろうか。
私は、保存だけでは足りないと考える。以前は正しかった仕様が、制度変更や業務変更で古くなるからだ。古い指示を忠実に守るAIは、現在の要求から見れば間違った仕事をする。
返品の例なら、「締め後は返品を受け付けない」という条件が、後から変更されるかもしれない。そのとき説明文だけ直しても、古いテストが残れば新しい実装を不正と判定する。逆に、テストだけ消して判断理由を残さなければ、次の担当者が以前の制約を復活させる可能性がある。
必要なのは、条件、テスト、判断の理由を一緒に更新する責任者である。どの顧客・どの版に適用するのか、何が変わったら見直すのかも分かるようにしたい。
ここには、SIerの継続的な仕事がある。開発時に資料を納めて終えるのでなく、変更のたびに、資料と実装と検証の対応を保つ仕事だ。
一方で、すべてを共通部品にする必要はない。再利用の見込みが小さい機能まで汎用化すれば、そのための開発と保守が増える。顧客固有の条件はその顧客の中に残し、共通化する範囲を選ぶ方がよい。
SIerが売れるのは、変更し続けられる状態
この考え方を事業にするなら、何に対して料金を受け取るのか。
私なら、最初の整備と、日々の変更対応を分けて提案する。最初に既存仕様やテスト、リリース手順を整える。そのうえで、合意した範囲の改修と、検証の仕組みを保つ仕事を継続して引き受ける。
ただし、「月額で何でも開発します」では採算を管理しにくい。依頼の大きさも影響範囲も違うからだ。小さな画面変更と、データ移行を伴う業務変更を同じ一件として扱うべきではない。
| 提供する仕事 | 顧客が得るもの | 採算を確かめる観点 |
|---|---|---|
| 初期の仕様・検証整備 | 変更時に確認できる土台 | 整備費を後続の改修で回収できるか |
| 範囲を定めた継続改修 | 小さな要望を継続して反映できる状態 | 確認・修正・運用まで含む総費用 |
| 大きな業務変更や移行 | 新しい条件に対応する仕組み | 個別の不確実性と追加作業の範囲 |
これは料金設計の案であり、市場で確立した契約形式だと主張するものではない。
固定価格で引き受ける仕事では、再利用によって総原価が下がれば利益を残せる余地がある。ただし、減らせた実装工数以上に確認や保守が増えれば、利益は出ない。工数に応じて請求する仕事なら、短縮した能力を次の仕事へ向ける仕組みも必要になる。
顧客の側にも条件がある。要件の優先順位を決める人が不在なら、開発基盤だけ整えても依頼は進まない。顧客が担う判断と、SIerが担う実行を、契約だけでなく日々の運用でも明確にする必要がある。
この商売の強みは、顧客が変更を依頼するたびに、毎回同じ調査費を払わなくてよくなることだと思う。SIerには、その改善分を顧客への価値と自社の利益に分ける設計が求められる。
成果は、コード量より「待ち時間と手戻り」に表れる
仕組みの効果を測るとき、AIが生成したコード量だけでは判断できない。大量の変更がレビュー待ちになっているだけかもしれないからだ。
DORAは、変更のリードタイムやデプロイ頻度とともに、変更失敗率などの不安定さも見る指標を示している。変更のリードタイムは、コードのコミットから本番展開までを指す。DORAのソフトウェア提供指標
SIerの案件では、それに加えて依頼受付から着手までの時間も見たい。顧客が感じる待ち時間は、コードを書き始める前から発生するからだ。これはDORA指標の定義を広げるのではなく、別の区間として測る提案である。
私は、同じ種類の改修について、次の点を一緒に確かめるところから始めたい。
- 顧客の判断や開発環境、レビューを待っている時間は減ったか。
- 引き渡すまでに、人が説明し直したり修正したりする負担は減ったか。
- 本番に出た後の不具合や、予定外の再作業は増えていないか。
これにAI利用料と基盤の維持費を合わせれば、速くなったことにいくら払っているかも見える。難易度が違う案件同士を単純比較せず、同じサービスの変化を追う方が判断しやすい。
最初の一歩は、いつも説明し直している改修を一つ選ぶこと
Software Factoryという名前の大きな基盤を、最初から丸ごと作る必要はないと私は考える。
まず、繰り返し発生し、同じ確認や手戻りがある改修を一つ選ぶ。その仕事で、どこを人が判断し、何をテストで確認できるかを明らかにする。次に同じ種類の依頼が来たとき、前回残したものが役に立ったかを確かめる。
既存の開発環境を使う案なら、導入範囲を絞れるが、工程間の連携は自分たちで整える必要がある。製品を採用する案なら、用意された機能を使える一方、既存業務との適合や運用費の確認が要る。独自基盤なら細かく合わせられるが、その保守も自社の仕事になる。ここでは製品比較やFactoryの導入試験はしていないため、特定製品の採用までは結論づけない。
最初に確かめたいのは、立派な管理画面ができたかではない。次の依頼を受けたとき、同じ説明と同じ失敗を一つ減らせたか。 その改善が続くなら、開発の経験が、次の仕事を支える資産になり始めている。
SIerの競争力は、案件のたびに優秀な人を集められることに加え、前の案件が次の案件を強くすることに宿る。AIで増えた実装能力を、顧客が安心して使える変更へつなぐ。その仕組みを育て続けられる会社に、継続して任せる理由が生まれると思う。
開発能力と収益の関係は、AnthropicのGit刷新が映す、SIerの次の稼ぎ方で考察した。案件をまたぐ仕組みへの投資は、Accentureの「Claude月29ドル」が問う、SIerのAI投資でも取り上げている。
公開資料の確認日：2026年10月19日。Factoryの概念説明とDORAの指標を参照。業務例、料金設計、SIerへの示唆は筆者の考察。
WRITTEN BY
コメント