システムインテグレータ（SIer）でのAI活用術

システムインテグレータ（SIer）に、そもそもAIは必要なのか

AIを入れて元が取れるかは、二つの物差しで判断できます。案件をまたいで同じ種類の判断が何度も戻ってくるか。そして、それを外したときに、費用と納期のどちらが動くか。

SIerのAI活用でいえば、年に一度しか来ない判断に仕組みを組んでも報われません。毎週発生し、外すと案件が赤字になる判断こそ、手を入れる価値があります。

当てはめると、線ははっきり見えます。 提案時の工数の見立て は、機能の数え方も難易度の区分も毎回同じ手順で、外せば開発の途中で人が足りなくなります。

コードレビューでの見落としの洗い出しも、規約と過去の障害という基準が社内にあります。提案書と見積書の下書きも、書く項目の並びは案件が替わっても動きません。

一方で、入れないほうがよい業務もあります。要件定義の場で、顧客が口にしなかった前提を引き出すやりとりです。顧客自身がまだ言葉にできていないものを、表情や現場の様子から拾う仕事で、記録に残っていないものは参照できません。

遅れが出たときに、追加費用と納期を顧客と決め直す交渉も同じです。 どこまでを自社の責任として引き受けるか を決める話で、社印を押す側の人間が席に着いていなければ進みません。

線引きは業務ごとに変わります。同じ案件の中でも、設計書どうしの突き合わせは任せられ、移行当日の切替判定は任せられません。次の章では、提案から保守までを工程に分けて並べます。

提案・受注から運用・保守まで、負荷が大きいのはどの工程か

SIerの仕事は、一件のシステムが提案から保守まで一方向に流れていきます。工程ごとに切って並べると、同じ判断を繰り返している箇所と、その場の状況を見て判断するしかない箇所が、別々の場所に固まっているのが見えます。

負荷が集中するのは結合・総合テストです。単体までは自社の中で完結しますが、結合から先は顧客側の環境設定と、組み込んだ他社製品の仕様が同時に絡みます。

日に何十件と上がる不具合票を前に、テストリーダーが最初に決めるのは これは誰が直すのか です。自社の作り込みなのか、顧客側のデータ設定なのか、組み込んだ製品の仕様なのか。 この切り分けが済むまで、誰も手を動かせません 。

しかも切り分けを外すと、他社に投げた不具合が数日後にそのまま戻ってきて、その日数が納期から消えます。テストリーダーは現象の再現と証跡の収集に時間を取られ、本来の進捗の把握が後回しになります。

ここに手が入り、不具合票が起票された時点で発生箇所と過去の類似事例から一次分類が付くようになれば、前の設計工程の不備も、後の移行判定も、同じ記録を見ながら話せるようになります。

本番移行を極小としたのは、切替の可否が当日の状況だけで決まるからです。リハーサルで残った項目を見て、この状態で顧客の業務を止めてよいかを判断する場面は、案件ごとに一度しかありません。

システムインテグレータ（SIer）で最初に取り組むべきAI活用、3つ

三つの並びは、こちらで決めたものではありません。第1章の二つの物差しに当てると、この順に落ち着きます。いずれも毎週動いていて、外すと採算か納期のどちらかに響く業務です。

要件が固まった時点で、提案時の工数を当て直す

要件定義書が確定し、案件管理の一覧で状態が設計着手に変わった時点で動きます。AIは、提案時に出した見積の内訳、過去案件の機能あたりの実績工数、難易度の区分表を基準に、要件定義書の機能一覧を画面・帳票・外部連携に数え分け、区分ごとの工数を積み上げます。

結果は積算の表計算ソフトに、案件ごとの行として増えます。いまは提案時の数字を抱えたまま設計に入り、人が足りないと分かるのは製造の途中です。仕組みが入れば、 設計に着手する前に 、提案時との食い違いが機能の単位で表に出ます。

前提条件の置き方が妥当かは、案件のプロジェクトマネージャが点検します。顧客に追加費用を切り出すかどうかは、契約に署名した責任者が引き受ける判断です。

本番で落ちる書き方に、レビューの前に印を付ける

変更がソース管理の仕組みに登録された時点が起点です。判断の基準になるのは、自社のコーディング規約と、過去の障害報告書の原因欄から拾い上げた「本番で落ちた書き方」の一覧で、AIは変更箇所をこの二つと照らし、当てはまる行に指摘の案を添えます。

指摘の案はレビュー依頼の一覧に並び、担当者の手元には業務チャットで通知が届きます。いまはレビュー担当が全行を目で追い、規約違反の指摘だけで時間が尽きて、設計意図の議論まで届きません。印が付いていれば、 機械的な指摘が片付いた状態 から始められます。

印を採るか外すかは、レビュー担当がその場で決めます。顧客に出す品質記録に何を残すかは、開発リーダーが責任を負う判断です。

提案依頼書の要求一覧に、一つずつ答えを当てる

提案依頼書が指定の保管場所に保存されると、仕組みが動き出します。AIは要求項目を一行ずつに割り、自社の標準構成の一覧、過去に提出した提案書、実現方式ごとの前提条件のまとめと突き合わせ、項目ごとに標準構成で満たすのか、作り込みが要るのか、条件付きなのかを当てます。

出力は文書作成ソフトに提案書のドラフトとして保存され、営業担当に通知が飛びます。いまは要求項目を表計算ソフトに転記するところから始まり、白紙に向かう時間が案件のたびに発生します。ドラフトがあれば、埋まっていない欄の検討から入れます。

作り込みが要ると付いた項目を本当に受けるかは、提案責任者が見極めます。見積の最終の金額と、提案書に書く前提条件の範囲は、営業部門の長が背負います。

業務に組み込むまでの4ステップ

二つ目のコードレビューの例で、手順を最後まで追います。新しいシステムを組む話ではなく、ソース管理の仕組みと規約の文書をつなぎ直す作業です。

1. 使う情報がどこにあるかを決める

レビューの基準になる情報は、四つの場所に分かれています。

• ソース管理の仕組みに残る変更履歴
• 部署ごとのコーディング規約の文書
• 過去のレビューで出た指摘の記録
• 障害報告書の原因欄

新しく書き起こすものはありません。規約が枝分かれしているなら、どれを正とするかを決めて一つにまとめます。

2. 何をきっかけに動かすかを決める

人が思い出して依頼する形にすると、締め切り間際の変更ほど素通りします。きっかけは 業務上の出来事に寄せます 。

変更がソース管理の仕組みに登録された時点が自然です。夜間の自動処理で当日分をまとめる形でも構いません。人の操作に戻すと、忙しい週から順に使われなくなります。

3. 判断の基準を設定しておく

いちばん時間のかかる工程がここです。ベテランが頭の中で無意識に見分けていることを、外に出して文章にします。

書き留めるのは、たとえば次のような内容です。

• 顧客の本番環境では通らない書き方はどれか（接続の張りっぱなしなど）
• どの処理に記録を必ず残させるのか、その境目はどこか
• 本番で落ちた過去の原因のうち、レビューで止められたはずのものは何か

一度まとめれば、案件が替わっても使い回せます 。

4. 結果の戻り先と、確認する人を決める

戻り先はレビュー依頼の一覧です。変更ごとに行が増え、指摘の案が並びます。担当者には業務チャットで通知が届きます。

見るのはレビュー担当で、取りかかる前です。印を採るか外すかを決め、外した理由を一行書き足します。

先に知っておきたい、つまずきやすい3か所

• 自動で生成されたコードや、顧客から支給されたライブラリまで点検の対象に入ると、 指摘の案が際限なく付いて、誰も一覧を開かなくなります 。対象から外す範囲を、仕組みを動かす前に線引きしてください。
• パッケージ製品の設定作業や、顧客側の担当者との日程調整だけで進む機能は、画面の数にも帳票の数にも現れません。 機能一覧から数えた工数だけを信じる と、この分が丸ごと抜け落ちます。数え方の外にある作業は、別枠で積む決まりにしてください。
• 提案依頼書には、顧客の未公表の計画や取引先の名前が書かれていることがあります。秘密保持の契約で読ませられる範囲が決まっている案件もあるので、保管場所を分け、仕組みに流す案件とそうでない案件を先に区別してください。

システムインテグレータ（SIer）のAI活用は、どこから考えればいいか

この記事で引いた線は、判断の基準を文章にできる業務と、顧客の前に座って決めるしかない業務の間にありました。最初に挙げた三つは、どれも 判断の手順が社内の記録として残っている側 にあります。だから基準を書き出せば、同じ判断を仕組みに寄せられます。

三つを並べて始める必要はありません。 どれか一つを動かしてみれば十分です 。過去案件の実績工数、コーディング規約の文書、これまでに出した提案書。新しく買い足すものはなく、どれもいま社内のどこかに保管されています。