先日、ITエンジニア向けに開発の話をした時の内容を記事化しました。
AIで誰でも簡単にアプリを作れる時代になりました。動くものが数時間でできてしまう。素晴らしいことです。ただ、その分だけ「作って終わり」のシステムも量産されやすくなっています。この記事では、情シス（情報システム部門）の視点を借りて、作ったものが運用でつまずかないための設計チェックを整理します。
開発の「完成」は、誰かの「出発点」
まず前提の整理から。開発の目的は「システムを完成させる」ことです。しかし会社にとって、完成したシステムは手段であり、目的は「事業を前に進める」こと。つまり、開発の「完成（目的）」は、次の誰かの「出発点（手段）」になります。手段と目的はこうして連鎖していく。だから、作って終わりにはできないのです。
この連鎖が一番よく見える場所が情シスです。情シスは会社のIT全体を作り・守り・回す仕事で、構築から運用までこの流れ全体に伴走します。目的はただひとつ、「何も起こさせない（事業を止めない）」ことです。
開発視点と情シス視点は、見ているものが違う
開発視点は「そのシステム単体」を見ています。要件を詰め、事業を進める機能を作り込む。一方、情シス視点は「会社全体の仕組みに、それが収まるか」を見ています。止まらないか（運用・可用性）、会社のインフラに乗るか、ガバナンスやセキュリティ規程に合うか、資産として管理できるか。
開発の目がシステム単体に閉じると、会社全体の要件が抜けます。だから運用の段になって「あれもない、これもダメ」が起きる。逆に言えば、情シスが見ている「会社全体」の視点を、開発の最初から借りること。それが、運用でつまずかない＝作って終わりにしない設計です。
シャドーAIは、こうして生まれる
この視点の違いは、AI利用の現場ですれ違いを起こします。使う側の目線は「便利なのに、なぜ使えないの?」。情シスの目線は「漏れないか・直せるか・回り続けるか」。目的が安全と継続性なので、便利さだけでは判断できないのです。すれ違いの結果生まれるのが、情シスを通さずにツールを使うシャドーAIです。
ここで大事なのは、問題は「質問したこと」ではなく、リスクを相手任せにして丸投げしていることだという点です。情シスは上司でも教育係でもないので、「便利なのに」だけで相談しても聞いてもらえません。逆に、相手の視点——何が漏れると困るのか、止まったら誰が対応するのか——も考慮した考えを持って相談すれば、情シスは味方になってくれます。エージェント時代のセキュリティが環境設計の話になってきているのも同じ文脈です（こちらのイベント視聴メモ参照）。
AIは「コードを書く」。それだけ。
「AIでコードを書く時代に、保守性の高いコードをどう書けばいいか」という質問をよくいただきます。私の答えはこうです。AIがコードを書けるようになっても、システムが動く仕組みは変わっていません。自分で書いても、AIに書かせても、最後に問われるのは同じ。誰が使うのか。止まったらどうするか。どう直し、どう続けるのか。
「便利だから」と、この目的を見ずに作る。それが、直せない・続かない技術的負債になります。コードを書くのが楽になった今こそ、目的を見る力の価値が上がっているわけです。
作って終わりにしないための、7つの問い
では、設計の段階で何を考えておけばいいか。私が使っている7つの問いを表にしておきます。
| 観点 | 問い |
|---|---|
| 使う人 | 誰が、毎日使うのか |
| 止まった時 | 止まったら、誰が困るのか |
| 直す人 | 数年後、誰が直せるのか |
| データ | どこに残り、誰が守るのか |
| 引き継ぎ | 自分がいなくても、分かるか |
| 変わるもの | 業務や人数が増えたら、どうなるか |
| 廃止 | いつかやめる時、困らないか |
全部に完璧に答える必要はありません。ポイントは、答えに詰まったところが「作って終わり」になりかけている場所だということです。相手を想像する、相手の立場を自分のこととして考える——チェックリストというより、そういう視点の道具として使ってください。
まとめ
ツールの話と、そのツールで何を達成するかの話は、別の問いです。手段と目的を分けて見る。相手には相手の目的があると知る。「作って終わり」ではなく育てるまでを見る。この3つが揃うと、長く使われるものが生まれます。AIの「自律に任せる範囲」と「コードで縛る範囲」の線引きは、ChatGPTを分解したら、エージェントの正体が見えてきたという独り言でも、別の角度から書いています。あわせてどうぞ。
