AIに開発を任せる時代、SIの設計書はどう変わるのか

　PowerPointで業務フローを定義し、Wordで基本設計をまとめ、Excelで詳細設計を書く。現在のSIの現場では、こうした進め方が一般的でしょう。ITコンサルティング企業で働き、複数のSIプロジェクトや開発現場に接する私にとっても、見慣れた光景です。

　ただ、2023年以降に生成AIの活用が広がり、いまではAIがコーディングの中心を担う開発も出てきました。人が書いたコードをAIに補完してもらうところから、仕様を渡して実装やテストを任せ、人が結果を確かめるところへ。そんな進め方になると、設計書にも変化がありそうです。私が見ている現場でも、開発用の情報をMarkdownに整理しつつ、顧客とのレビューにはOfficeを使うなど、その組み合わせを試しています。一方で、「協力会社に頼んでいた作業をAIに頼むだけなら、これまでのやり方でよいのでは」という声を聞くこともあります。

　この記事は、SIやITコンサルティングの現場で、AIとの付き合い方に悩んでいる方に読んでもらえたらと思って書いています。私もまだ悩んでいる一人です。開発をAIに任せると、設計書の何を変え、何を残したほうがよいのか。一緒に考えてみませんか。

「依頼先が人からAIに変わっただけ」なのか

　良くも悪くも、日本のSIでは多重下請け構造が長く定着してきました。特に一次受けの事業者が要件定義や品質管理に軸足を置く案件では、コードに直接触れず、協力会社に開発やテストを依頼してプロジェクトを進めることもあります。「何を作るかを決め、依頼し、できたものを確かめる」という仕事は、AIが登場する前からやってきたわけです。

　そう考えると、「人がAIに置き換わっただけでは」という意見には、私も一定うなずけます。顧客の要望を具体的な要件に落とし込み、作業を任せられる単位に分け、成果物の品質を確かめる。その経験は、AIに開発を任せるときにも生きそうです。AIに開発を任せる流れを日本のSIに重ねると、世界の開発者が、SIでおなじみの「自分で全部作るより、任せて確かめる」仕事へ近づいているようにも見えます。これは私見ではありますが、AI時代の開発を考えるうえで、SIの経験には意外とヒントがあるのかもしれません。

　ただ、仕事の役割に共通点があるからといって、これまでの設計書をそのまま渡せば十分とは限りません。人に任せていたとき、文書に書かずに済んでいたことはなかったでしょうか。設計書の形式はこれまで通りで良いのでしょうか。ここから、設計書の中身と形式を考え直したいと思います。

設計書には、何を任せ、どう確かめるかを残す

　長く同じ案件に関わっている人なら、「この画面は前の機能と同じ感じで」と伝えても、過去の経緯や業務ルールを思い出してくれるかもしれません。AIに同じように任せるなら、どの機能を参考にし、何を引き継ぎ、どこを変えるのかを設計書に書き、それをAIに読ませたいところです。たとえば「注文を取り消せるようにする」という依頼なら、設計書に次のようなことを残します。

• 目的：担当者が誤って登録した注文を取り消せるようにする。
• 条件：出荷前だけ取り消せる。出荷済みの場合は理由を表示する。
• 影響：在庫の引き当てを戻し、誰が取り消したかの記録を残す。
• 確認：取消前後の注文・在庫・操作記録を確かめる。権限がない場合や、出荷処理と重なった場合も試す。

　これは説明用の例ですが、作ってほしいものと、できたと言える条件をそろえるということです。AIが仕様を読んで実装し、別のAIがテストを書いたとしても、同じ思い違いをしていれば、テストが通るだけでは気付けません。（これは、人が開発していても同じことが起きていますよね。）何を確かめるべきかまで、人が顧客の要件に照らして考える必要があります。

　NTTデータのあるチームのAI開発の経験談^[1]では、AIが必要な情報を見つけやすく、成果物同士の整合性も取りやすいように、設計書の体系をほぼ一から組み直したと紹介されています。ファイルを小さく分け、必要なものだけを参照させる工夫もしています。私が参考にしたいのは、ファイル形式だけでなく、設計書の分け方と、そこに何を書くかまで見直している点です。顧客に確認してもらうこと、AIに実装を任せるために伝えること、後から変更する人に残すこと。それぞれに必要な情報を考えると、これまでの設計書をそのまま引き継ぐ以外の形も見えてきそうです。

Officeは、顧客と一緒に確認しやすい

　開発をAIに任せても、顧客と「これを作りましょう」と確認する仕事は残ります。設計書は、実装の依頼に使うと同時に、業務を知る人と開発する側の理解をそろえるためのものでもあります。IPAの「機能要件の合意形成ガイド」でも、聞き取った内容を図表にし、漏れや矛盾がないかを発注者と開発者が一緒にレビューする流れが示されています。^[2]

慣れた道具で、見ながら話せる

　Officeが使いやすいのは、顧客もSI側も使い慣れていることが大きいと思います。Wordで文章を読み、Excelで項目を並べ、PowerPointで図を見せる。見やすく整えやすいうえに、変更履歴、計算、図の作成など、説明や読み合わせに必要な機能もそろっています。

　OneDriveやSharePointに保存した対応形式の文書なら、対応アプリと権限のある人で同時編集でき、以前の版も確認できます。大企業や官公庁の案件でも、Officeのライセンスと利用環境がすでにそろっていれば、資料を確認するために新しいツールを導入する必要がありません。会議で決まったことを、AIへ渡す仕様にも戻す。そこまでつなげておけば、顧客との確認に使い慣れたOfficeを選ぶのは、自然なことだと思います。

Officeの中でも、AIに文書づくりを手伝ってもらえる

　Office側にもAIによる作成・編集の支援があります。Microsoft 365 Copilotでは、Wordの下書きや書き換え、Excelの分析や数式・表の作成、PowerPointのスライド作成・修正などの機能を利用できます。顧客と話す場ではOfficeを使い、AIにも文書づくりを手伝ってもらう。そのうえで、日々のコード変更と仕様をどう結び付けるかを考えると、MarkdownとGitの出番が見えてきます。

Markdownは、コードと設計書を一緒に直しやすい

仕様・コード・テストを、一つの変更として確認する

　Markdownは、記号で見出しやリンクなどを表すプレーンテキストです。コードと同じリポジトリに置き、Gitで変更履歴を管理できます。OfficeファイルもGitに保存できますが、そのままでは文章やセルの変更を通常のテキスト差分として読めません。Markdownなら、行ごとの変更をそのまま確認できます。

　たとえばAPIに項目を追加するとき、実装コード、テスト、Markdownの仕様書を一つのPull Requestに入れます。Pull Requestは、変更案をまとめて確認するための仕組みなので、仕様・コード・テストを一つの変更のまとまりとして確認できます。仕様とコードが同じ場所にあり、差分もテキストで追えると、AIにも関連する情報を読ませ、食い違いを確認させやすくなります。「項目は実装されたけれど、必須か任意かが仕様に書かれていない」といった点を、変更したコードと仕様書を見比べて確かめさせるイメージです。

　ここで、先ほどのNTTデータの経験談^[1]が参考になります。このチームでは、処理の流れを細かく書く従来型の詳細設計書を省き、入出力を示して実装をAIに任せているとのこと。この事例を読むと、設計書の形式だけでなく、どこまで詳しく書くかも見直したくなります。処理の一手一手をコードに沿って書くよりも、必要な入出力や守るべき条件を設計書に残し、実装がその条件を満たすかをAIにも確認させる。細かな処理手順を省く場合も、それまでの設計書が担っていた確認事項をどこに残すかは、あわせて考えておきたいところです。MarkdownとGitは、こうした進め方に使いやすい組み合わせだと思います。

AIが必要な情報にたどり着けるようにする

　ここで参考になるのが、OpenAIの「ハーネスエンジニアリング」^[3]です。AIを開発する側のOpenAI自身が、エージェントを使った開発環境づくりの経験をまとめています。その中では、AGENTS.md^[4]に、あらゆる情報を詰め込む方法ではうまくいかなかったと説明しています。代わりに、詳しい知識はdocs/以下に整理し、AGENTS.mdは必要な文書へ案内する短い目次として使っています。

　この考え方は、SIの設計書にも取り入れられそうです。たとえば、AGENTS.mdには開発時の基本ルールと文書の案内を置き、APIの仕様はAPI設計書へ、業務上の制約は要件定義書へ、技術を選んだ理由はその記録へとたどれるようにします。顧客と合意した内容を、AIが開発中に参照するところまでつなぐイメージです。

　リポジトリを直接読むコーディングエージェントを使うなら、Officeの文書をテキストへ変換して渡す場合に比べ、Markdownは本文をそのまま読ませられ、Gitでも変更を追いやすくなります。実装などAIに任せる作業に近いドキュメントほど、Markdownにしておくと扱いやすそうです。設計書を置いておくだけでなく、必要な場面で必要な箇所へたどり着けるようにする。文書の中身に加えて、文書同士のつながりも設計することが大事になりそうです。

どの設計書を、どのフォーマットにするか

　開発中にこまめに直す文書と、顧客への説明や提出に使う資料では、使いやすい形が違うことがあります。たとえば、次のような選び方です。

• 顧客と文章を読み合わせる要件定義書や基本設計書はWord。
• 詳細設計の項目定義や、絞り込み・集計をする一覧はExcel。
• 業務フローや、方式を説明する資料はPowerPoint。
• コードと頻繁に一緒に直す仕様、開発手順、技術を選んだ理由の記録はMarkdown。

　もちろん、Wordを日々更新することも、Markdownの設計書をそのまま顧客とレビューすることもあります。「基本設計書だからWord」「AIに読ませるから全部Markdown」と先に決めず、誰が何に使うのか、どのくらい変更するのかに合わせて選びたいところです。

　併用するときに決めたいのが、「内容を直すときは、どの文書を更新するか」です。その基準になる文書が「正本」です。正本を変換したり、一部を抜き出したりして作る説明資料は、正本から作った「派生物」として扱います。（AIがない開発でも、正本が何で、どの文書を更新すべきかが整理できておらず、大変なことに……というのはよくありますが……。）

　形式が増えるほど、どこに何があり、どれが今使う版なのかを見失いやすくなります。AIがあっても、文書管理台帳^[5]のような役割のドキュメントは大事ですね。人もAIも必要な設計書を見つけられ、顧客との確認で決まったことが関連する設計書に反映される。そこまで含めて、現場で使える組み合わせを考えるべきでしょう。

SIでAIを使うなら、顧客の情報と設計書の分け方も考える

　大手SI事業者が手掛ける案件では、コンプライアンスや情報の取り扱いに厳しいルールを持つ顧客と仕事をすることが多いと思います。AIにどこまで情報を渡し、どの環境で扱うかは、顧客との合意が必要です。当たり前の話ではありますが、この「渡せる情報と、渡せない情報」の区分も、設計書の作り方に影響しそうです。

　たとえば、顧客固有の業務情報を含む設計書を丸ごとAIに読ませられないなら、AIに渡せる仕様と、参照を制限する情報を分けることになります。顧客向けの説明には必要でも、AIへの実装依頼には不要な情報もあるでしょう。設計書をどの単位で分けるか、どこに保存するか、両者をどう対応付けるかまで考える必要が出てきます。

　ただ、顧客名を伏せたり、データ例を架空の値に変えたりすれば、何でも渡せるわけではありません。何を残し、何を除けばよいかも、顧客と合意した範囲で判断します。必要な業務条件まで削ってしまうなら、その設計書でAIにどこまで作業を任せられるかを見直すことも必要でしょう。

　学習への利用や履歴の保存、アクセス権の確認も、もちろん大事です。^[6]その確認を設計書の運用につなげると、「この環境のAIには、ここにある設計書まで読ませる」という具体的な整理になります。フォーマットを変えただけで、情報管理の条件が変わるわけではありません。顧客と確認しやすいか、AIが扱いやすいかに加え、どの情報をどこで扱えるかも、設計書の方式を選ぶときに考えておきたいところです。

まずは一つの文書で試してみる

　既存プロジェクトで始めるなら、開発チームがよく使う文書から試すと、よかった点や困った点が見えやすいと思います。開発手順、コーディング規約、手順書、テストシナリオ、詳細設計書などが候補になりやすそうです。その中で、顧客と合意したAIの利用範囲や提出物の条件を踏まえ、試しやすいものを選ぶ。実際に使ってみると、AIに伝わりにくい記述や、人がレビューしづらい箇所も見えてくるはずです。

　Gitでのレビューが楽になっても、顧客向けの資料を作り直す手間が増えれば、全体では楽になっていないかもしれません。開発チームの中だけでなく、顧客との確認や提出まで含めて、続けられそうかを判断することが大事ですね。

AIに合わせて見直しながら、現場で探っていく

　何を作るかを決め、開発を任せ、品質を確かめる。SIで続けてきたこの仕事は、AIに開発を任せるときにも通じます。顧客の業務を理解し、要件をそろえ、できたものに責任を持つ経験は、これからも生きるはずです。

　そのうえで、AIに伝えるべき内容を設計書に残し、必要なときに読ませられるようにする。顧客と確認するのか、開発中に使うのか、AIにどこまで情報を渡せるのかに応じて、設計書の中身や分け方、フォーマットを選び直す。こうして設計書のあり方をAIを使う開発に合わせて見直すことは、大切だと思います。

　ただ、私も含め、ITコンサルやSIの現場はまだ手探りです。どこまでAIに任せ、何を設計書に残し、顧客とどう確認していくか。すぐに一つの正解が決まる話でもないでしょう。試してみて、困ったことやうまくいったことを持ち寄りながら、設計書や業界のあり方は、これからも模索され続けていくのだと思います。この記事が、同じように悩んでいるみなさんの役に立てると嬉しいです。

　（まあ、個人開発では、私は要件から設計・開発・テストまで、全部AI最優先の作りにしているんですけどね。）

　関連ツール：Markdown表・CSV・TSV変換 — AIが作った表をExcelで確認したり、Excelの一覧をMarkdownの設計書へ移したりするときに使える、tojihub Toolsの変換ツールです。