SIerの経験を、次の提案と開発を生む組織の力に変える
SIerの現場には、設計書やソースコードだけでは表しきれない知識があります。
この顧客には、どの順番で論点を提示すると合意形成が進みやすいのか。過去の移行案件では、どの調査を先に行うと見積もりの精度が上がるのか。障害が起きたとき、ログに現れる前にどの兆候を疑うべきなのか。長年の経験を持つエンジニアやプロジェクトマネージャーは、こうした判断を日々積み重ねています。
しかし、その知識は一つのプロジェクト、一人の担当者、あるいは特定の顧客との関係の中に閉じがちです。担当者が異動すれば、同じ確認や調査を別の人が最初からやり直す。過去に似た案件があっても、提案書や議事録を探し出せず、経験者に聞くしかない。設計・開発・保守の各工程に情報が分かれ、プロジェクトを越えた学習が起こりにくい。
SIerにとって重要なのは、経験を単に記録することでも、AIに無条件で覚えさせることでもありません。どのような状況で、何を確認し、どの選択肢を比較し、なぜその判断に至ったのかを整理し、次の提案や開発で再利用できる組織の知識へ変えていくことです。
製造業の現場で語られる「デジタル・ラストワンマイル」は、SIerにも存在します。RFP、要件定義書、ソースコード、チケット、障害ログなどのデジタル情報と、顧客との合意形成や設計上の勘所、障害対応の優先順位といった実務判断の間にある距離です。私たちJiteraは、この距離を埋めることが、SIerのAI活用を個人の生産性向上から組織の競争力へ広げる鍵だと考えています。
SIerの資産は、成果物だけではない
SIerには、要件定義書、基本設計書、詳細設計書、ソースコード、テスト仕様書、運用手順書、RFP、見積書、議事録、問い合わせ履歴など、多くの成果物が蓄積されています。これらは提案や開発を支える重要な資産です。
ただし、成果物が残っていることと、次の案件で経験を再利用できることは同じではありません。過去の見積もりがあっても、前提となる体制、顧客の制約、移行対象の複雑さ、リスクの見立てが分からなければ、その数字だけを使うことはできません。設計書があっても、なぜその方式を選んだのか、どの案を見送ったのかが分からなければ、類似案件への応用は難しくなります。
障害対応の記録も同じです。原因と対処だけではなく、どの情報を手がかりに仮説を立てたのか、どの確認を省略できたのか、顧客への報告と復旧作業をどう切り分けたのかが、次の対応に活きる知識になります。
資料を増やすだけでは、組織の知識は増えません。成果物の背景、適用条件、判断の理由、結果として何が分かったのかを、後からたどれる状態にすることが必要です。
提案と開発の間にある知識をつなぐ
SIerの業務では、提案、要件定義、設計、実装、テスト、運用保守が別々の工程として管理されがちです。しかし、各工程には本来つながりがあります。
提案段階で顧客が重視していた条件は、要件定義で確認すべき論点になります。要件定義で決まった前提は、設計やテストの判断に影響します。運用中に判明した制約や障害の傾向は、次の提案や標準設計に反映できるはずです。
このつながりが切れていると、同じ組織の中で何度も同じ質問が繰り返されます。営業は開発担当者に過去事例を聞き、開発担当者は運用担当者に障害の経緯を聞く。担当者が変わるたびに、知識の再構築が必要になります。
目指したいのは、次のような関係をたどれる状態です。
- RFPや顧客要件から、過去の類似案件、提案方針、見積もりの前提を確認できる
- 要件や設計上の判断から、関連するソースコード、テスト、変更履歴をたどれる
- 障害の兆候から、監視ログ、過去の対応、顧客報告、再発防止策をつなげて確認できる
- 個別案件で得た知見を、標準テンプレートや次の提案・設計に反映できる
AIが単にファイルを検索するだけでなく、工程と判断のつながりを踏まえて情報を整理できれば、提案から運用・保守までの知識の流れをつくりやすくなります。
ベテランの経験を、質問から引き出す
経験を持つ人に、最初から完璧なナレッジを書いてもらうのは簡単ではありません。忙しいプロジェクトマネージャーやエンジニアに、過去の判断を白紙から文章化してもらうには、大きな負担がかかります。
そこで、実際の案件や問い合わせを起点に、AIが不足している情報を質問する方法があります。過去のRFP、提案書、設計書、チケット、障害履歴などを参照しながら、AIが「この見積もりでは、移行対象のどの条件をリスクとして見ていましたか」「この障害では、なぜこのログを最初に確認したのですか」と尋ねる。経験者は、日常の業務に近い形で答えることができます。
その回答には、成果物だけではなく、外部連携の多さ、仕様書の欠落、業務部門との確認体制によって、調査の進め方や見積もりの前提が変わるかもしれません。こうした条件が整理されて初めて、経験は別の案件にも応用できる知識になります。
ただし、経験者の回答をそのまま標準解として扱ってはいけません。顧客との契約、セキュリティ要件、現在の製品仕様、社内標準、法令・規制などと照合し、適用範囲と確認者を明確にする必要があります。知識を引き出すことと、業務で利用できる状態に承認することは、別のプロセスです。
開発AIエージェントと業務AIエージェントをつなぐ
SIerにおけるAI活用では、システム開発そのものを支援する開発AIエージェントと、提案・営業・運用・保守・社内ナレッジを支援する業務AIエージェントを分けて考えるだけでは不十分です。両者が扱う知識を、業務の流れの中でつなぐことに価値があります。
開発AIエージェントは、要件定義書や設計情報をもとに、ディレクトリ構造、コード、API、UI、データベース、テストなどの生成を支援できます。既存のレガシーコードを解析し（リバースエンジニアリング）、現行仕様や依存関係を整理することも、モダナイゼーションの重要な起点になります。
一方、業務AIエージェントは、RFP分析、提案書や見積書の初稿作成、過去案件のナレッジ共有、顧客からの技術問い合わせの一次切り分け、障害報告書のドラフト作成などを支援できます。
大切なのは、コード生成だけを速くすることではありません。提案時の前提が開発に伝わり、開発で得られた知見が保守と次の提案に戻ってくることです。開発成果物、プロジェクトの判断、顧客との合意、保守上の知見が分断されなければ、AIは個別作業の補助から、プロジェクト全体の学習を支える存在へ近づきます。
AIに任せることと、人が判断すること
SIerの成果物は、顧客の業務やシステムに直接影響します。AIが作成した設計書、コード、テスト、見積もり、障害報告を、そのまま顧客に提出したり本番環境へ適用したりすることはできません。
AIに任せられるのは、情報の整理、類似事例の提示、初稿の作成、依存関係の可視化、確認すべき論点の抽出などです。人は、顧客要件との適合性、顧客との要件整理、設計の妥当性、セキュリティ、品質、契約上の責任、リリース可否を判断します。
この役割分担を明確にしないままAIを導入すると、作業は速くなっても、レビューの責任が曖昧になります。誰が確認したのか、どの資料を根拠にしたのか、どの変更を承認したのかを追跡できることが、AIを組み込んだ開発プロセスには欠かせません。
AI活用の評価も、生成量や応答速度だけでは足りません。根拠をたどれるか、レビューしやすい形で出力されるか、誤りを修正して次回に活かせるか、プロジェクト間で再利用できるか。こうした観点で、開発品質と組織学習の両方を見ていく必要があります。
経営層が向き合うべき、属人化の構造
SIerの属人化は、単に「詳しい人がいる」という問題ではありません。提案の受注確度、見積もりの精度、開発品質、障害対応の速さ、顧客との関係性が、特定の人の経験に依存している状態です。
経営層や事業責任者がまず確認すべきなのは、次の問いではないでしょうか。
- 重要な提案や見積もりが、特定の担当者に依存していないか
- 過去案件の判断や失敗から、次の案件が学べる状態か
- 顧客ごとの前提や合意事項を、担当者が変わっても追跡できるか
- レガシーシステムや複雑な保守の知識を、次の世代へ移せる状態か
- AIが生成した成果物について、レビューと承認の責任者が決まっているか
知識を組織の資産にするには、何を残すかだけでなく、誰が所有し、誰がレビューし、どの範囲で利用し、いつ更新するのかを決める必要があります。これはツール導入後の保守課題ではなく、事業継続と収益性に関わる経営課題です。
AIコンテキストプラットフォームという考え方
SIerの経験を継続的に活用するには、ファイル置き場や一時的なFAQだけでは不十分です。RFP、顧客要件、設計書、コード、チケット、ログ、見積もり、議事録、過去の判断、担当者による確認を、業務の文脈に沿って扱う基盤が必要になります。
AIコンテキストプラットフォームは、組織固有の知識をAIが参照できる状態に整え、人の確認とレビューを通じて継続的に更新していくための考え方です。SIerにおいては、提案、開発、保守、顧客対応を別々の情報として管理するのではなく、判断と成果物のつながりとして捉えることに意味があります。
Jiteraには、システム開発を支援する「開発AIエージェント」と、提案・保守・社内ナレッジなどを支援する「業務AIエージェント」があります。Jiteraは、既存の成果物や業務情報をもとに、SIerが自らの経験を次の提案・開発・保守へつなげていくための基盤づくりを支援します。
ただし、経験を組織の資産にすることは、Jiteraを導入すれば完了するものではありません。対象業務の選定、知識の所有者、レビュー方法、顧客情報やソースコードへのアクセス範囲、更新責任、現場での受け入れ方を定め、実際の案件で確かめながら育てていく取り組みです。
まとめ
SIerにとってのAI活用は、コードを速く書くことだけではありません。提案の経験、顧客との合意形成、設計上の判断、障害対応の勘所を、次の人と次のプロジェクトが再利用できる組織の知識へ変えることです。
そのためには、成果物だけでなく、判断の背景、適用条件、確認の順番、結果をつなげて扱う必要があります。AIは、情報を整理し、類似事例を示し、不足している知識を質問し、人がレビューしやすい状態をつくることができます。一方で、顧客に対する責任、品質、セキュリティ、最終判断は人が担います。
問うべきなのは、「AIで開発者一人ひとりの作業をどれだけ速くできるか」だけではありません。「一つの案件で得た経験を、次の提案、次の開発、次の顧客、次の世代へどうつなぐか」です。
個人やプロジェクトに閉じていた経験を、組織の判断力に変える。そこまで実現できたとき、AIは単なる開発ツールではなく、SIerの競争力を継続的に育てるデジタルな同伴者になるのではないでしょうか。
※本稿はSIer・システム開発業界におけるAI活用と知識継承の考え方を示すものであり、特定の開発成果、品質、セキュリティ、法令・規制への適合性、契約上の義務、個別のシステム要件を保証するものではありません。実際の導入にあたっては、各組織の規程、顧客との契約、情報管理方針、開発・運用保守プロセス、権限、承認手続きを確認してください。
