担当者しか分からないシステムから、チームで育てられる開発資産へ

業務システム、Webサービス、社内ツールの開発では、コードを書くことだけが仕事ではありません。既存コードや設計書を調べ、要件を整理し、テストやレビューの準備を行い、変更内容をチームへ共有する作業も日々発生します。

特に、長く運用されているシステムでは、設計の背景や保守時の注意点が担当者の経験に閉じてしまいがちです。担当者が変わるたびに同じ調査をやり直していては、開発のスピードだけでなく、品質や引き継ぎにも影響します。

Jiteraは、許可されたソースコード、設計書、要件、テスト結果、運用情報などをコンテキストとして整理し、調査、設計書の初稿作成、テスト観点の整理、引き継ぎ資料の作成を支援します。本記事では、開発担当者が定型的な調査や資料作成の負荷を減らし、設計と判断に集中するための活用方法を紹介します。

開発担当者の1日と、繰り返し発生する定型作業

開発担当者の一日は、状況確認から始まり、要件確認、調査、設計、実装、レビュー、テスト、記録の更新へと進みます。障害や緊急の問い合わせが入ると、予定していた作業を中断して保守対応を行うこともあります。

朝：状況確認と優先順位付け

• チャット、メール、チケット、障害通知を確認する
• 前日の進捗、未完了タスク、レビュー待ちの変更を確認する
• 当日の開発、レビュー、打ち合わせの予定を整理する
• 緊急度や影響範囲を踏まえて作業の優先順位を決める
• チームメンバーからの質問や相談に回答する

午前：要件確認、既存調査、設計、実装

• 依頼内容や要件定義書を確認する
• 既存コード、設計書、データベース、API、画面構成を調査する
• 変更による影響範囲を確認する
• 実装方針や設計案を整理する
• コード、画面、API、データ処理を実装する
• 不明点を業務部門、顧客、プロジェクト管理者へ確認する

午後：レビュー、テスト、追加修正

• ソースコードや設計内容をレビューする
• 単体テスト、結合テスト、画面テストを実施する
• テスト結果やエラー内容を整理する
• 指摘事項や不具合を修正する
• 仕様変更が発生した場合は、設計や実装への影響を再確認する

夕方：進捗共有とドキュメント更新

• チケットや案件管理表を更新する
• 作業結果、未解決事項、リスクをチームへ共有する
• 議事録、変更履歴、設計書、操作手順書を更新する
• テスト結果やレビュー結果を記録する
• 翌日の作業と追加確認事項を整理する

終業前または夜：保守・緊急対応

• 本番障害や問い合わせへの対応を行う
• ログ、ジョブ、データベース、外部連携を調査する
• 一時対応、原因調査、恒久対応の方針を整理する
• 必要に応じて障害報告や関係者向け説明資料を作成する

繰り返し発生する定型作業

「設計と判断」より「調査と資料作成」に時間が奪われる構造

既存コード調査の負荷

既存システムの改修では、変更したい画面や機能だけを見ればよいとは限りません。関連するAPI、データベース、バッチ、外部連携、帳票、権限設定などを確認しなければ、影響範囲を判断できないことがあります。

設計書が古い場合や、資料が複数の場所に分散している場合は、コードと資料を突き合わせる作業がさらに増えます。担当者は、どこに何が書かれているかを探し、処理の流れを頭の中で組み立て、調査結果を別の資料へ書き直すことになります。

属人化した仕様や保守知識

次のような情報は、正式な設計書やソースコードだけでは把握しにくく、経験者に依存しやすい領域です。

• なぜ現在の設計方式を採用したのか
• どの機能やデータが他の処理に影響するのか
• 障害発生時に最初に確認するログやジョブは何か
• 再実行してよい処理と、再実行してはいけない処理は何か
• 特定の顧客や業務だけに適用される例外条件
• 仕様書に記載されていない運用上の注意点
• 過去の障害や仕様変更で残された特殊な処理

担当者の異動や退職が発生すると、後任者はコード、設計書、過去のチケット、議事録、口頭説明を突き合わせながら、知識を再構築しなければなりません。

チームで共有できていない設計判断

設計では、採用した方式だけでなく、比較した案と採用しなかった理由も重要です。しかし、最終成果物には結論だけが残り、判断の背景が共有されないことがあります。

その結果、似た案件で同じ調査や議論が繰り返されます。開発、運用、業務、プロジェクト管理の情報が分断されると、同じ質問への回答や影響調査も担当者ごとに行うことになります。

Jiteraで変わる4つの開発業務

1. 既存システム調査・リバースエンジニアリング

既存ソースコード、データベース定義、設計資料、運用情報を許可された範囲でコンテキストとして整理します。Jiteraは、プログラムの目的、入力と出力、処理の流れ、呼び出し関係、データの依存関係、例外処理、改修時の影響範囲をまとめる草案作成を支援します。

コードから確認できない事項は推測で補わず、「要確認」として分けて出力させます。開発担当者は、調査結果を起点に実際のコード、設計書、運用実態を照合し、改修対象と確認すべき範囲を判断します。

2. 要件整理・設計書初稿作成

会議記録、依頼内容、既存システムの仕様、業務ルール、制約条件を入力し、機能要件、非機能要件、未確定事項、追加質問、処理フロー、画面仕様、データ項目などの初稿を作成します。

既存の設計標準やコーディング規約も参照できる状態にしておくと、案件固有の要件と組織の標準を分けて整理しやすくなります。設計方式の妥当性、セキュリティ、性能、運用への影響は、開発担当者が判断します。

3. テスト観点の整理

要件定義書、設計書、ソースコード、既存テストケース、業務ルールをもとに、正常系、異常系、境界値、権限、入力制御、外部連携、回帰テストの観点を整理します。

過去の障害記録やレビューで指摘された項目をコンテキストに加えることで、同じ見落としを防ぐための確認項目を作りやすくなります。生成されたテスト観点は、実際の環境、データ、業務手順に合わせて修正し、必要なテストを実施します。

4. 引き継ぎ・チームナレッジの整備

既存の設計書、ソースコード、議事録、チケット、障害対応記録、運用手順、経験者へのヒアリング結果を整理し、システム概要、依存関係、注意点、判断理由、障害時の確認手順をまとめます。

自動的に整理された内容と、担当者が確認した内容を分けて記録すると、どこまで検証済みかを把握しやすくなります。確認者、確認日、対象環境、参照した資料、未解決事項も残すことで、チームで更新できる開発資産になります。

業務ごとの入力コンテキストと生成されるアウトプットの例

入力コンテキストには、対象システム、環境、版、更新日、機密区分、参照してよい範囲を付けます。現行版と旧版を区別し、個人情報や認証情報などは社内規程に従って扱います。

生成された設計書、コード、テスト、障害報告、引き継ぎ資料は、開発担当者が確認・編集するための草案です。根拠が確認できない内容は、正式な仕様や事実として扱わず、要確認事項として管理します。

AIの出力を開発・レビュー・テストで確認する運用

Jiteraを開発業務へ組み込む際は、AIに任せる作業と、人が判断する作業を分けます。AIには、情報の整理、初稿作成、類似する知識の提示、確認事項の抽出を任せます。人は、要件の確定、設計方式の選択、実現可能性、品質、セキュリティ、本番適用の可否を判断します。

開発担当者が確認すること

• 要件と設計内容が一致しているか
• コード、設計書、データベース定義の関係に誤りがないか
• 正常系だけでなく、例外処理や異常終了時の処理が含まれているか
• 影響範囲に画面、API、バッチ、帳票、外部連携が含まれているか
• AIが参照した資料の版と対象環境が正しいか
• 「推定」「要確認」とされた事項に確認担当者が割り当てられているか

チームで行うレビューとテスト

• 開発担当者が設計、コード、テスト観点を確認する
• 業務担当者が業務ルール、例外条件、運用手順を確認する
• 運用担当者が監視、障害対応、リカバリ手順を確認する
• セキュリティ担当者が権限、データ管理、外部連携を確認する
• 必要なテストを実施し、結果と未解決事項を記録する
• 承認者がリリースや本番変更の可否を判断する

AIの出力は最終判断ではありません。文章や図が整っていても、内容の正確性、網羅性、実現可能性を保証するものではありません。設計書、コード、テスト計画、リリース、障害対応を正式な成果物や判断の根拠として利用する場合は、必ず担当者が参照元と照合し、レビュー、テスト、承認を行ってください。

製造業・金融・SIerでの展開例

製造業：MESや基幹DBの依存関係を可視化する

製造業では、MES、生産管理、品質管理、在庫管理、販売管理、設備などのシステムが連携しています。テーブル、画面、API、バッチ、外部連携の関係を整理し、改修前の影響範囲調査や、担当者交代時の引き継ぎに活用できます。

工場ごとの設備、工程、運用ルールに差がある場合は、対象工場や環境を明確にして整理します。現場、情シス、開発、設備、品質の担当者が、抽出された関係を実際の運用と照合することが重要です。

金融：レガシーコードとバッチ処理を段階的に整理する

金融機関では、長年稼働しているプログラム、データベース、SQLバッチ、ジョブ定義が業務を支えています。ソースコード、DB定義、ジョブ定義、設計資料を業務単位で整理し、処理概要、データの流れ、依存関係、改修時の確認項目、テスト観点の草案を作成できます。

機密性の高い情報を扱うため、配置場所、通信経路、権限、ログ、保存期間、参照範囲を事前に確認します。移行、改修、リリース、業務判断は、AIの整理結果だけで確定せず、開発、運用、業務、セキュリティの担当者がレビューします。

SIer：顧客案件の経験を次の開発へつなぐ

SIerでは、要件定義書、設計書、ソースコード、テスト仕様書、運用手順書、チケット、障害記録などが案件ごとに蓄積されます。これらを許可された範囲で整理し、類似する設計、過去の判断理由、障害時の注意点、レビュー観点を次の案件へ活かせます。

案件固有の情報と、組織で再利用できる標準知識を分けて管理すると、顧客情報を適切に扱いながら、チームの開発資産を育てやすくなります。引き継ぎや新人の立ち上がりだけでなく、保守や追加開発での調査にも役立ちます。

まとめ

開発担当者が設計と判断に集中するには、コードを書く時間だけでなく、コードを調査し、資料へ整理し、チームへ共有する時間にも目を向ける必要があります。

Jiteraは、許可されたコンテキストをもとに、既存システムの調査、リバースエンジニアリング、要件整理、設計書の初稿作成、テスト観点の整理、引き継ぎ資料の作成を支援します。目的は担当者の判断を置き換えることではなく、調査や定型的な資料作成の負荷を減らし、設計、品質、運用、チーム連携に使える時間を増やすことです。

まずは、対象範囲と出力形式を定めやすい業務から始めるとよいでしょう。たとえば、特定プログラムの処理概要、改修前の影響範囲、テスト観点、引き継ぎ資料などです。AIが整理した内容と、人が確認した内容を分け、確認者、確認日、参照資料、未解決事項を記録することで、担当者の記憶に依存しない開発資産へ育てていけます。