見えない品質を設計する──AI時代の業務システム開発論
仕様どおりに動くことと、業務で使えることは同じではありません。
そして、業務で使えることと、業務に耐えることもまた違います。
AIによって、動くものを作る速度は大きく上がりました。
しかし、その速さは、画面に現れない品質まで自動的に保証してくれるわけではありません。
業務システムにおける「見えない品質」と、それを設計するために人間が立てるべき問いについて考えます。
新しいシステムが使われ始めた。
システムは、仕様どおりに動いている。
画面も表示される。
登録もできる。
帳票も出力される。
しかし、モニタの片隅には、二枚のテープラベルが貼られている。
「確定したら、帳票を印刷しておくこと」
「表計算アプリへの入力も忘れずに」
そういう場面があります。
これは、特定の案件の話ではありません。
業務システムでは、抽象化したつもりでも、関係者が読めば状況を推定できてしまうことがあります。だから本稿では、個別の出来事ではなく、長く業務システムに関わる中で何度も見てきた構造として書きます。
問題は、画面がなかったことではありません。
処理が動かなかったことでもありません。
本当に確認したかったこと。
判断に必要だったこと。
あとから説明しなければならないこと。
それらが、システムの中で十分に扱われていなかった。
業務システムの品質は、こういうところに現れます。
こうした光景は、AIが登場する前からありました。
しかし、AIによって動くものを作る速度が上がるほど、この問題はむしろ見えにくくなるかもしれません。
だからこそ、見えない品質を設計する力が、いっそう重要になる。
私は、そんなことを考えています。
動く試作品と、業務で使えるシステムは違う
最近では、AIと対話しながら、まず動くものを作っていく開発のあり方が注目されています。いわゆるバイブコーディングと呼ばれるものです。
これは、とても強力です。
頭の中にある曖昧なイメージを、すぐに画面にできる。
利用者に見せながら、「ここは違う」「こうしたい」と会話できる。
動くものを見ることで、初めて気づくこともあります。
AIを使った試作やバイブコーディングを否定したいわけではありません。
むしろ、使うべきだと思います。
ただし、ここで一つ、間違えてはいけないことがあります。
試作品が動くことと、業務システムとして使えることは違う、ということです。
試作品は、多くの場合、きれいな道を通ります。
必要な値が入力される。
想定した順番で操作される。
データは正しい。
ネットワークは切れない。
同時利用者は少ない。
処理は途中で止まらない。
このような、いちばん幸せな経路を、ハッピーパスと言ったりします。
ハッピーパスが通ることは大切です。
まず、それが動かなければ話になりません。
しかし、業務はハッピーパスだけではありません。
入力が途中で止まる。
必須項目が欠ける。
古いデータが残っている。
同じ処理を二重に実行してしまう。
権限のない人が操作しようとする。
処理中に通信が切れる。
外部サービスが応答しない。
夜間バッチが途中で落ちる。
月末だけ件数が膨らむ。
休日明けに利用が集中する。
業務システムとは、こうした揺らぎを含んだ場所で使われるものです。
つまり、本当に設計しなければならないのは、ハッピーパスの外側です。
サッドパス。
負荷。
復旧。
ログ。
監視。
権限。
例外処理。
保守性。
変更への耐性。
これらは、試作品の画面を見ただけでは、あまり目立ちません。
デモでは拍手されにくい。
会議でも話題になりにくい。
「そこまで必要ですか」と言われることすらあります。
しかし、業務システムが業務システムであるためには、ここが必要です。
見えている機能だけを見ていると、こうした条件は見落とされます。
だから、問わなければならない。
その画面は、うまくいくときだけを前提にしていないか。
その処理は、途中で止まったときにも業務を壊さないか。
その仕組みは、あとから何が起きたかを説明できるか。
こうした問いは、画面の華やかさとは別の場所にあります。
AIは、言えばコードを書いてくれます。
しかし、聞かれなかったことまですべて勝手に心配してくれるとは限りません。
「この条件で一覧を作って」と言えば、一覧を作ってくれる。
「登録画面を作って」と言えば、登録画面を作ってくれる。
でも、その画面が業務上どの程度の負荷に耐えるべきか。
どのエラーを利用者に見せ、どのエラーを運用に回すべきか。
障害時に何分以内に復旧すべきか。
ログは誰が何のために見るのか。
権限設計はどこまで細かくするのか。
こうしたことは、プロンプトの外側に落ちやすい。
だから、AI時代のシステム開発では、コードを書く力が不要になるというよりも、何をAIに問うべきかを設計する力が重要になるのだと思います。
見えない品質は、自然には出てきません。
誰かが、それを品質として認識しなければならない。
誰かが、それを設計対象として扱わなければならない。
誰かが、それを「なくても動くが、なければ業務に耐えないもの」として言葉にしなければならない。
そのために必要なのは、見えていない条件に問いを立てることです。
その役割は、AIが速くなればなるほど、人間の側に残るのではないでしょうか。
「つまり、こういう機能ですね」と言う前に
もう一つ、AI時代に気をつけたいことがあります。
それは、答えにたどり着く速度が上がるほど、問題を見誤る危険も大きくなる、ということです。
システム開発の現場では、利用者からいろいろな言葉が出てきます。
「情報を共有したい」
「検索しやすくしたい」
「手戻りを減らしたい」
「属人化をなくしたい」
「入力を簡単にしたい」
「判断を早くしたい」
こうした言葉を聞くと、私たちはすぐに機能へ変換したくなります。
情報共有なら、掲示板。
検索しやすくするなら、全文検索。
手戻りを減らすなら、承認フロー。
属人化をなくすなら、ナレッジベース。
入力を簡単にするなら、選択式の画面。
判断を早くするなら、ダッシュボード。
もちろん、それが正しい場合もあります。
しかし、いつもそうとは限りません。
「情報を共有したい」と言っている人が、本当に求めているのは、情報を置く場所ではないかもしれない。
実は、誰が何を決めたのかがわからないことに困っているのかもしれない。
あるいは、情報はすでにあるが、信頼できる最新版がどれか分からないのかもしれない。
または、共有されていないのではなく、読まれないことが問題なのかもしれない。
それなのに、こちらがすぐに、
「つまり、こういう機能ですね」
と言ってしまう。
この瞬間、問題は機能に変換されます。
曖昧だったものが、急に具体的になります。
具体的になると、話は前に進んでいるように見えます。
画面案が出る。
項目が決まる。
スケジュールが引かれる。
見積もりが作られる。
いかにも仕事が進んでいる感じがします。
しかし、ここには危うさがあります。
本当に解くべき問題に触れる前に、解けそうな形に変えてしまっているかもしれないからです。
私は以前、「1＋1」と「2」について考えたことがあります。
1＋1の答えは2です。
それは間違いではありません。
でも、システム開発の現場で大切なのは、「1＋1は？」と聞かれたときに、条件反射で「2」と答えることではないように思います。
そもそも、その1は何なのか。
もう一つの1は、同じ種類のものなのか。
足してよいものなのか。
足すことが目的なのか。
本当は、引くべきなのか、分けるべきなのか、並べるべきなのか。
そうした問いを飛ばして、すぐに「2」と答えてしまう。
これは、一見正解しているようで、実は解くべき問題そのものを間違えているのかもしれない。
AIは、この「2」を出すのがとても速い。
こちらが少し曖昧なことを言っても、AIは整った答えを返してくれます。
それらしい構成にしてくれる。
画面案にしてくれる。
コードにしてくれる。
説明資料にしてくれる。
これは便利です。
しかし、便利であるがゆえに、私たちは「問いがまだ熟していない状態」に耐える力を失いやすくなります。
何かを聞けば、すぐに答えが返ってくる。
その答えが整っている。
だから、問題も整理された気になる。
でも、業務の問題は、最初からきれいな形をしているとは限りません。
むしろ、本当に重要な問題ほど、最初は言葉になっていないことがあります。
「なんとなく使いにくい」
「いつもここで止まる」
「結局、最後は電話している」
「システムには入れているけれど、別の表も残っている」
「承認はされているが、現場では信用されていない」
こういう言葉の中に、業務の本質が隠れていることがあります。
ここで必要なのは、すぐに機能へ変換することではありません。
少し立ち止まることです。
なぜ使いにくいのか。
どこで止まっているのか。
電話では何を確認しているのか。
別の表には何が残っているのか。
承認されたものが、なぜ信用されないのか。
こうした問いを持ちこたえること。
それは、開発の速度とは逆方向に見えるかもしれません。
しかし、ここを急ぎすぎると、速く作ったものが、速く間違えることになります。
AI時代には、仕様を分解する速度も、実装する速度も上がります。
だからこそ、最初に置いた問いがずれていると、そのずれも高速に増幅されます。
間違った問題設定に対して、愚直にシステムを作ってしまう。
これは、かなり危ういことです。
業務システムにおいて、本当に怖いのは、動かないシステムだけではありません。
動くけれど、問題を解いていないシステム。
使えるように見えるけれど、業務の肝心なところを外しているシステム。
現場の手間を減らすはずが、別の場所に手間を移しているだけのシステム。
こうしたものは、表面上は成功に見えることがあります。
だから、かえって気づきにくい。
「つまり、こういう機能ですね」と言いたくなる前に、少しだけ立ち止まる。
その曖昧な言葉は、何を訴えているのか。
その要望は、どんな業務上の痛み（ペイン）から出ているのか。
その機能を作ることで、本当に何が変わるのか。
AI時代の業務システム開発において、人間が果たすべき役割の一つは、ここにあると思います。
答えを速く出すことではなく、問いを早く閉じすぎないこと。
要望の奥にある痛みに問いを立てること。
それもまた、見えない品質の一部ではないでしょうか。
検証とは、価値を保存することである
システム開発には、さまざまな進め方があります。
要件を固め、設計し、実装し、テストへと段階的に進めていく。ウォーターフォール型の開発と呼ばれる進め方は、その代表的なものです。
その設計と検証の関係を整理する図として、V字モデルというものがあります。
V字モデルを考えるとき、いつも少し気になることがあります。
この図は、左側に要件定義や設計があり、右側にテストや検証があります。
上から下へ設計が詳細化され、下から上へテストで確認していく。
この図を見ると、つい時間軸のように読んでしまいます。
しかし、V字モデルの本質は、単なる時間軸ではありません。
左側で決めたことが、右側で何によって確認されるのか、という対応関係です。
要件で語られた価値は、受入テストで確認される。
基本設計で決めた構造は、総合テストで確認される。
詳細設計で決めた振る舞いは、結合テストや単体テストで確認される。
そこに線が引けているかどうかが重要です。
ただし、ここにもう一つ、見落とされやすいことがあります。
線が引けていても、価値は痩せることがあります。
要件で語られた言葉は、設計で形を変えます。
設計は、仕様でさらに形を変えます。
仕様は、実装でコードに変わります。
変換のたびに、最初に大切だったものが、少しずつ落ちていくことがあります。
たとえば、こういうことが起きます。
「滞留を減らしたい」という価値が、「一覧を表示する」という機能に変換される。
「判断に必要な根拠を揃えたい」という価値が、「検索条件を追加する」という仕様に変換される。
「あとから説明できるようにしたい」という価値が、「承認履歴を保存する」という実装に変換される。
変換そのものは、必要なことです。
価値は、何らかの形に変換されなければ、システムの中に置くことができません。
しかし、変換されたものだけを確認すると、最初の価値が届いているかどうかを見失います。
一覧は表示された。
検索条件も動いた。
承認履歴も保存された。
でも、滞留は見えるようになっていない。
判断に必要な根拠は揃っていない。
あとから説明できる状態になっていない。
現場の電話確認も減っていない。
テストは通っている。
仕様は満たしている。
それでも、「使えない」と言われる。
こういうことが起きます。
AI時代には、テストの自動化が進みます。
仕様からテストケースを作ることも、コードから単体テストを書くことも、以前より容易になります。
しかし、テストをたくさん作れることと、価値を確認できていることは同じではありません。
AIは、与えられた仕様に基づいてテストを作ることができます。
しかし、その仕様が本来の価値を正しく表しているかどうかは、別の問題です。
だから、V字モデルの図を見るときに大切なのは、右側のテスト項目だけを見つめることではありません。
常に、左上を見ることです。
左上にあった目的。
最初に守りたかった価値。
なぜ、それを作ろうとしたのか。
変換を重ねるほど、左上は遠くなります。
だからこそ、意識して戻らなければならない。
検証とは、単に不具合を見つけることではありません。
仕様どおりに動くかを見ることだけでもありません。
検証とは、最初に求めていた価値が、形を変えながらも失われていないかを確かめることです。
言い換えれば、検証とは、価値を保存することなのだと思います。
見えない品質を設計するための問い
では、見えない品質を設計するために、何を問えばよいのでしょうか。
見えない品質を設計するとは、画面に現れる機能の外側で、業務が本当に支えられる条件をあらかじめ考えることです。
例外が起きても崩れないこと。
判断に必要なものが失われないこと。
価値が、要件から設計、仕様、実装へ移る途中で痩せていかないこと。
大げさな方法論にする必要はないと思います。
特別な儀式を増やすことでもありません。
見えない品質を設計するとは、開発の節目に、問いを置いておくことです。
試作品を作るときには、こう問う。
この試作品では、何に集中し、何をいったん脇に置いているのか。
いちばんうまくいく経路だけを作っているのか。
入力が欠けたとき、処理が途中で止まったとき、想定より多くの人が使ったときの振る舞いは、あとで扱う問いとして残っているのか。
異常が起きたとき、利用者と運用者がそれぞれ何を知る必要があるかは、後回しにした問いとして残っているのか。
機能に変換する前には、こう問う。
その要望は、どんな業務上の痛みから出てきたのか。
その機能ができることで、現場の何が本当に変わるのか。
逆に、その機能を作っても残る手作業や電話確認は何か。
検証するときには、こう問う。
仕様書に書かれた機能を確認しているのか。
それとも、最初に守りたかった価値を確認しているのか。
「動いた」と言える条件と、「業務に耐える」と言える条件を、同じものとして扱っていないか。
これらの問いは、AIに対する問いでもあります。
そして同時に、私たち自身に対する問いでもあります。
AIに何を作らせるかの前に、私たちは何を品質として扱うのか。
そこを決めないままでは、見えない品質は設計できません。
AI時代に人間が設計するもの
私は、AI時代の業務システム開発において、人間に残る役割は、単に「最終判断をすること」ではないと思います。
もっと前から、人間の役割はあります。
何を作るべきかを問うこと。
どこまで作れば業務に耐えるのかを定義すること。
何を確認すれば価値が守られたと言えるのかを決めること。
見えない品質を、言葉にすること。
これは、コードを書くことより地味です。
デモで目立つものでもありません。
生成速度を比較するベンチマークにも出にくい。
けれども、業務システムの成否は、しばしばここで決まります。
そして、これは開発者だけの仕事ではありません。
発注する側。
受け入れる側。
業務を預かる側。
運用を引き受ける側。
それぞれが、何を品質として求めるのかを言葉にしなければならない。
どの問いを閉じてよくて、どの問いをまだ閉じてはいけないのかを見極めなければならない。
そのためには、個人の勘だけでは足りません。
良い問いを立てるためのナレッジがいる。
良い問いを立てるための訓練がいる。
そして、問いを急いで閉じさせない環境がいる。
AIによって、開発の速度は上がります。
しかし、速度が上がるほど、見落としたものも速く遠ざかります。
本当は考えるべきだった例外。
本当は聞くべきだった違和感。
本当は確認すべきだった価値。
それらを置き去りにしないために必要なのが、見えない品質を設計する力なのだと思います。
動くことと、使えることは違う。
使えることと、業務に耐えることも違う。
そして、仕様どおりに動くことは、価値が守られていることを必ずしも意味しない。
その違いを見失わないために、問いがいる。
見えない品質は、良い問いから立ち上がるのだと思います。
※執筆にあたり生成AIとの対話を活用しています。
※本稿は、過去に投稿した以下の記事をもとに、創作大賞2026「ビジネス部門」応募作として再構成・加筆したものです。
