AIで開発を速くする前に、作らなくていいものを決める – Arkanos Insights 

生成AIの普及によって、システム開発のあり方は大きく変わりつつあります。

コードの生成やレビュー、テストコードの作成など、これまで人が時間をかけて行っていた作業をAIが支援することで、開発の生産性を高めることができるようになりました。

「AIを活用して、いかに速く開発するか」。

これは今後のシステム開発において、重要なテーマのひとつだと思います。

一方で、開発コストを下げるという観点では、もっと単純で、場合によってはAIによる効率化以上に効果の大きな方法があります。

そもそも、作らなくていいものを作らないことです。

10%速く作るより、ひとつ作らない

仮に、あるシステムに10個の機能を実装するとします。

AIの活用によって開発を10%効率化できれば、当然ながら開発コストの削減につながります。

しかし、その10個の機能の中に「実はなくても困らない機能」が含まれていたらどうでしょうか。

その機能をひとつ作らないと判断できれば、設計、実装、テストに必要な工数そのものがなくなります。さらに、リリース後の保守や改修の対象もひとつ減ります。

もちろん、単純に機能数だけで比較できるものではありません。それでも、すでに作ると決めたものを効率よく開発することと、そもそも何を作るべきかを判断することは、別の問題です。

AIによって前者の効率化が進んでいる今だからこそ、後者についても改めて考える必要があるのではないでしょうか。

自社用のWorkLogを作ってみた

Arkanosでは、自社の業務記録を管理するための「WorkLog」という小さな仕組みを内製し、2026年1月から実際の業務で利用しています。

それ以前はExcelで日々の作業内容や工数を管理していました。

Excelでも記録自体はできます。しかし、毎日の入力を忘れてしまったり、月末になってから記憶をたどりながら入力したり、請求時に必要な情報を集計したりと、運用してみると意外に手間がかかります。

そこでWorkLogを作ることにしました。

ただし、最初から高機能な業務システムを作ろうとは考えませんでした。

日々の業務で自分たちが必要としている機能を洗い出し、必要なものに絞って実装しました。そのため、システムとしての開発規模はそれほど大きなものではありません。

「小さく作る」ことと、「適当に作る」ことは違います。

機能を少なくすること自体が目的なのではなく、目的を達成するために必要な機能を見極めることが重要です。

WorkLogも、日々の作業内容と工数を記録し、月単位で集計し、請求の根拠となる作業実績を確認するという、実際の業務に必要なところはきちんと実装しています。

それだけでも、Excelで行っていた管理から脱却し、現在では日々の業務に十分役立つツールになっています。

Arkanosで実際に利用しているWorkLogの入力画面。日々の作業内容と工数を記録し、集計や請求時の確認に利用しています。PCだけでなくスマートフォンからも入力できるため、移動中などのちょっとした時間にも記録できます。

この経験から改めて感じたのは、システムの価値は機能の数で決まるわけではないということです。

多くの機能を持っていても、ほとんど使われなければ、その開発コストは十分な価値を生みません。

反対に、機能が少なくても、日常的に発生している不便を確実に解消できれば、そのシステムには十分な価値があります。

RFPはどうしても「全部盛り」になりやすい

一方、さまざまなシステム開発のRFPを見ると、非常に多くの要求が盛り込まれていることがあります。

もちろん、これには理由があります。

RFPを作る立場では、必要な要求が抜けていることは避けたいものです。複数の部門から要望を集めれば、それぞれの立場から必要な機能が挙がります。

「将来使うかもしれない」

「せっかく新しくするなら対応しておきたい」

「今のシステムにあるから、次にも必要だろう」

そうした要求を積み上げていけば、RFPが「全部盛り」になっていくのは、ある意味では自然なことです。

プロジェクトを推進する立場としても、後から「なぜこの機能を入れなかったのか」と言われるより、要求として盛り込んでおいた方が説明しやすいという事情もあります。

ただ、その中には一度立ち止まって、

「これは本当に、初期稼働の時点から必要でしょうか？」

と考えてもよいものが含まれていることがあります。

要求として挙がったことと、初期開発で実装しなければならないことは、必ずしも同じではありません。

「作る／作らない」の二択にしない

ここで重要なのは、コストを下げるために必要な機能まで削ることではありません。

システムを成立させるために必要な機能や、利用者にとって明確な価値を持つ機能には、きちんと投資する必要があります。

一方で、要求をすべて「作る／作らない」の二択で考える必要もありません。

例えば、要求を次の3つに分けて考えることができます。

最初から作る

業務やサービスを成立させるために必要で、初期稼働の時点から利用するものです。

利用状況を見て、後から作る

あると便利そうではあるものの、本当にどの程度利用されるのか分からないものです。まずはシステムを運用し、実際の利用状況を見てから追加しても遅くない場合があります。

作らない

利用頻度や得られる効果に対して、開発や保守に必要なコストが見合わないものです。既存のツールや運用で十分に代替できる場合もあります。

特に判断が難しいのが、「たまに誰かが使うかもしれない」という要求です。

実際に必要になる可能性はあります。

しかし、必要になるかもしれないという理由だけで初期開発に含めるのではなく、必要性が確認された時点で追加するという選択肢もあります。

半年後、本当に必要になったのであれば、その時に作ればよい。

反対に、半年経っても誰も必要としなかったのであれば、最初に作らなかった判断は結果的に正しかったことになります。

要求を減らすことも、開発効率化

システム開発の効率化というと、実装工程に目が向きがちです。

AIによるコーディング支援、自動テスト、CI/CDなど、開発工程を効率化するための技術は数多くあります。

しかし、開発する機能そのものを適切に絞り込むことも、大きな効率化です。

ひとつの機能を作るためには、コードを書くだけではなく、要件を決め、設計し、実装し、テストし、リリースする必要があります。

そして一度作れば、その後は保守対象になります。

仕様変更があれば影響を確認し、OSやブラウザ、外部サービスなどの環境が変われば対応が必要になることもあります。

つまり、作らないと判断した機能については、初期開発費だけではなく、その後に発生するコストも抑えることができます。

だからこそ、開発工程に入る前の要求整理には大きな意味があります。

必要な機能まで落とす必要はありません。

むしろ、限られた予算や期間を、本当に必要な機能へ振り向けるために要求を整理する、と考えた方がよいでしょう。

「作らない」という判断も、システム設計の一部

システム企画では、「何を実現するか」を考えることに多くの時間を使います。

しかし、それと同じくらい、

何を最初には作らないのか。

を考えてもよいのではないでしょうか。

「作らない」は、要求を諦めることではありません。

「今は作らない」という選択肢を持つことです。

必要性が明確になったものは後から追加できますし、実際の利用状況を見てから判断した方が、より適切な仕様を決められることもあります。

以前、Arkanos Insightsで「仕事道具は『最良』ではなく『最適』で選ぶ」という記事を書きました。

高価で高性能なものを選ぶことが正解なのではなく、自分の用途に合ったものを選ぶことが重要だ、という内容です。

システムも同じだと思います。

最も多機能なシステムを作ることではなく、その業務やサービスにとって最適なシステムを作ること。

そのためには、「何を作るか」だけでなく、「何を作らないか」を考えることも必要です。

AIによって開発を速くする前に、まず作るものそのものを見直してみる。

それが結果として、開発コストや期間を抑えながら、本当に必要なところへ投資するための近道になるかもしれません。

Arkanosでは、こうした考え方をもとに、システム企画・RFP策定における「要求の棚卸しと最適化」を支援していきたいと考えています。