たった5人日の改修がプロダクトを壊す。技術的負債を生まないための「軽量・要求開発」

はじめに

株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2025』の24日目の記事になります。

放課後等デイサービスや就労移行支援の事業所を300以上運営している会社です。
障害者福祉・介護領域・学校教育領域でSaaSプロダクトを自社で開発し提供している会社でもあります。

プロダクトやソフトウェア開発を遂行していくために、「どのように」作るのかの前に「なにを」作るのか、「なぜ」作るのかを明らかにする必要があります。そのためにプロダクトへの要求を定める必要があります。その技術が要求工学です。ソフトウェア工学での前半に記述されている事で、抽象度の高い事が書いてあるので忘れちゃってる人もいるかもしれません。

本記事は、グロース活動中によくある5人日ぐらいで終わるチケットでも要求開発を忘れないで行えるように3つの方法を紹介してます。

グロース活動中の「なぜ？」に答える事ができ、ビジネス価値や、ユーザの価値を体感してプロダクト開発が楽しいと思ってもらえるエンジニアが増えますよに書いています。

対象読者

• システムをつくるお仕事に携わっている
• 設計力をあげていきたいエンジニア
• AI時代に上流工程で何をしていいか不安なエンジニア

要求は聞くものではなく開発・発見するもの

よくあるプロダクト開発のワンシーンです。

　
業務担当者: 「ユーザー情報登録画面に住所の入力欄を追加してください。」

エンジニア（思考）: （この画面だと、APIのパラメータ追加とテーブルのカラム追加が必要だな… 5人日くらいか）

エンジニア: 「がってんしょうち！」

　

※ LITALICOだと事業運営しているので、業務担当者から直接言われる場合もありますし、SaaS事業だとPdMがいたりするのでビジネスの共有も明確になっていたり様々です。

エンジニアの専門性は要求開発で活かす

従来の要求定義は、ユーザーからの要望を「ヒアリング」し、それを整理するプロセスでした。しかし、このアプローチには大きな問題があります。それは、「ユーザーが提案する手段は、必ずしも彼らが本当に求めている目的ではない」という点です。 アジャイルやウォータフォールでもよく使われる文章だと思います。

[tips] LITALICOは自社で300以上事業所を運営している会社です。エンジニアではない社員の方が多い会社です。より、丁寧に要求開発を行いわないとこのような課題が顕著になってしまいます。


ユーザーからの「カラムを追加してほしい」といった具体的な要望は、あくまで彼らが考えた手段であり、その根底にあるビジネス上の真の目的<なぜ？>を深掘りせずに実装を進めると、誤った課題に対する解決方式を作ってしまう最も非効率的な開発になってしまいます。 業務担当者やPdM、UXデザイナ、誰であっても業務全体や、ましてやシステム全体を知っているとは限りません。 影響範囲や背景にある課題を特定せず、言われた通りに機能を追加し続けることは、誰も使わない機能を増やし、結果としてプロダクトの価値を損なう大きなリスクを伴います。

要求開発は、「それを作って本当に課題が解決するか？」と「それは正しく動いたと証明できるか？」という問いを立てながら、要求そのものをエンジニアリング（設計・構築）していく姿勢を指します。

AIを使った開発では、開発速度が上がっていくと思います。正しいのもを早くつくるには、真の課題解決につながる要求をユーザーと共に作り上げることが、現代のエンジニアに求められる姿なのです。
※ ユーザーをステークホルダー・ドメインエキスパートと置き換えても可

家づくりに学ぶエンジニアの心得

エンジニアが持つべき専門性とマインドを、家づくりを例に表してみます。

「重要な壁」を無意識に抜いていないか

プロの建築家は、壁を撤去する際、それが単なる間仕切りなのか、それとも建物を支える重要な構造体なのかを、必ず事前に確認します。

• 非技術者の要望：「開放感が欲しいから、この壁を抜いて窓にしてほしい」
• 初心者エンジニア：「分かりました。5日で終わります」＝＞ 数年後、建物の歪みが発生し、家が壊れました
• プロのエンジニア：「その壁は家全体を支える重要な壁です。代わりに、こちら側に補強を入れて別の場所を窓にしませんか？」

　ソフトウェア開発において「ドメインモデル」は、システムの健全性を守る「重要な壁」です。たとえ5人日程度の小規模な改修であっても、不適切なデータベーステーブルのカラム追加やロジックの分散は、このドメインモデルという構造を徐々に侵食します。このような実装を放置することは、将来的に「機能の階層を増やしたい」といった重要な拡張を不可能にし、システムの寿命を縮める「時限爆弾」となり得ます。

小規模開発こそが技術的負債の温床になる

たった5人日の案件なんて、さっさと開発しちゃえばいいじゃない？と感じるかもしれません。なぜ、小規模開発の要求開発が重要なのか？ そこにはシステムの未来を脅かす3つの罠が潜んでいるからです。

大規模な新規プロジェクトであれば、設計会議が行われ、ドメインモデルやDFD、システム影響、テーブル設計の議論もなされると思います。しかし、5人日ぐらいの小規模の改修ではそうしたプロセスは省略されがちになったりしませんでしょうか？ このとき、エンジニアが行う「一つだけのカラム追加」という安易な意思決定が、将来的なメンテナンス性を決定的に損なうことがあります。

脅威要因	小規模案件でのありがち	長期的な影響
思考停止	「言われた通りにカラムを作るだけだから簡単」と考える。	ドメインモデルがスパゲティになり、変更に弱いシステムになる。
ドキュメントの欠如	「小規模だからWikiやチケットの記載は不要」と判断する。	数ヶ月後にそのカラムが何のためにあるか誰も分からなくなる。
個別最適化	特定の画面のためだけにデータを追加し、他との整合性を無視する。	データの重複や不整合が発生し、バッチ処理等でエラーが頻発する。

3つの罠

”とりあえず”リリース

小規模な改修では設計レビューが簡略化されることで、「とりあえずの項目追加」といった安易な意思決定が頻発します。レビューしたとしても、リリースすぐしたいから等の理由で安易な意思決定のままプロダクトコードが増えていく事があります。この蓄積が、後の大規模な機能追加を困難にし、最終的にシステムの寿命を大幅に縮めます。

要件は見えるものだけ

安易な意思決定は、考える事も少なくさせます。5人日の仕事に非機能要件を考える余裕はありません。なぜなら、気持ち的にはもう終わっているのです。API追加すればいいんでしょ？で設計は過小評価されます。小さなカラム追加や安易な関連付けは、リリース当初は問題にならなくとも、将来的にパフォーマンス問題を引き起こす要因となります。不適切なデータベースの巨大な集約や、非効率なジョインを誘発し、クエリパフォーマンスを徐々に、しかし確実に劣化させます。プロダクト全体がもっさりするなんてパフォーマンス問題の多くは、こうした小規模開発の小さな設計ミスに起因します。

眼の前の価値を優先

小規模案件の多くは、工数が少ないと誰もが想像するので業務担当者が直接、要望を伝えてくる場合が多くなります。そうすると、エンジニアも早く開発して改善してあげたいと思うものです。という理由で「なぜその機能が必要か」というビジネス上の価値を問わずに実装を進めると、Aさん（もしくは特定の会社等）にとっては、価値があるが、全体的にみると価値が不明確な機能ばかりがシステムに溜まっていきます。
これは保守コストだけを増大させ、コアドメインにとって重要度の高い機能開発へのリソースを圧迫する結果につながります。

小規模開発こそ実施する「軽量・要求開発」3つのフレームワーク

小規模開発であっても、チケットやwikiに以下の3点を数分で書き出すだけで、開発の質は飛躍的に向上します。そもそも小規模開発なので影響も小さい見込みなのだと思います。設計にかける時間を過小評価しているだけで、多くの時間は使わないはずです。 自分がよく知らない機能を改修することもあると思います。解像度を高め品質を作っていくコストは必ず確保するようにしたいものです。そこで、軽量にできる要求開発の手法を提案します。

数分と書きましたが、60分使って、この3つを使って解像度をあげていってください。
そんなに大きいコストではないと思います。

3つのフレームワーク

要求開発とはユーザーやドメインエキスパートと共に行いあるべきシステムの姿を導き出す行為です。なので、このフレームワークはエンジニアだけがわかるものではなく、ユーザーとコミュニケーションをするシーンにおいて一緒に使ってほしいのです。エンジニアだけのモデリング手法である必要はありません。

☺️ ユーザーストーリー分析

曖昧な「なぜ？」を排し、真の提供価値を自然言語化します。

よくあるフォーマットは以下です。
「私は<ペルソナ>として、<機能>が必要です。なぜなら、<価値/メリット>が得られるからです」

特に「なぜなら」の部分が、ユーザーが本当に欲しいものを見極めるリトマス試験紙となります。ここが記述できない、もしくは表層的な理由しか出てこない場合、注意が必要です。その要望は解像度が低く、本当の要望が隠れている場合はがあります。
　
　
前述した業務担当者から「ユーザー情報登録画面に住所の入力欄を追加してください。」という要望をもらったケースでサンプルを記述します。

良いユーザーストーリー

「購入者として、一度登録した住所を保存したい。なぜなら、次回の注文時に再入力する手間を省き、スムーズに決済を完了させたいからだ」

• 目的が「再入力の省略」であれば、単に項目を増やすだけでなく「前回使用した住所を選択する機能」が必要だと分かります

「サービス管理者として、ユーザーの正確な居住地を知りたい。なぜなら、自治体からの助成金対象者であるかを正しく判定し、不正な受給を防ぐ必要があるからだ」

• 目的が「厳密な判定」であれば、自由入力ではなく「郵便番号からの自動入力」や「公的な住所マスターとの照合」といった、より堅牢な実装が必要になります。

悪いユーザーストーリー

「ユーザーとして、住所入力欄が欲しい。なぜなら、住所を入力したいからだ」
「開発者として、usersテーブルにaddressカラムを追加したい。なぜなら、場所のデータを保持するためだ」

• 「何を作るか」に終始しており、背景にある価値や目的が不明確なため、エンジニアの思考を停止させてしまうため、記述する意味が薄れます

良いユーザーストーリーの場合は、足りない機能や価値が見えてきました。

😩 共通言語の更新（ユビキタス言語）

対象項目が事業領域（ドメイン）においてどのような意味を持つのかを定義し、チーム共通の「言語・振る舞い」として定義します。これはデータベース設計書ではなく、チーム内で共有される共通認識です。言葉が定まることで、認識のズレによるミスコミュニケーションがなくなり、将来のメンバーも理解しやすい「変更に強い設計」が実現します。

小規模な改修（5人日）であれば、立派なツールを導入する必要はありません。

• チケットの冒頭に数行書く
  「今回の『住所』は、配送ラベル用なので部屋番号まで必須です。コード上のクラス名は ShippingAddress にしましょう」と一言記述するとかです。

• コードの命名を辞書に合わせる
  辞書で決めた用語を、そのままクラス名やメソッド名に反映させます。

用語	クラス名	定義・ビジネスルール（制約）
住所	Address	ユーザーへの郵送物送付や、サービス提供エリアの判定に使用する情報の集合体。値オブジェクトとして扱い、全ての属性が一致すれば同一のものとみなす。
郵便番号	PostalCode	日本国内の7桁の数字。ハイフンあり・なしの両方を受け付けるが、正規化して保存する。存在しない郵便番号はエラーとする。
都道府県	Prefecture	日本の47都道府県。選択式（Enum）で管理し、文字列の揺らぎ（例：東京、東京都）を許容しない。
市区町村・番地	StreetAddress	市区町村から番地までの情報。配送ラベルの印字に耐えうる形式であること。
建物名・部屋番号	BuildingInfo	任意入力。集合住宅の場合に必須。配送トラブルを防ぐため、100文字以内とする。
配送先住所	ShippingAddress	注文時に指定される、実際に荷物を届けるための住所。ユーザー情報に登録された「住所」とは別に管理される可能性がある。

ドメイン駆動開発をしてる場合は値オブジェクトで表現される振る舞い・ビジネスルールを書いておくといいでしょう。クラス名にしてますが、これだと非エンジニアでも理解してもらえるでしょう。計算のルールなどは必ず書くようにしてミスコミュニケーションが起きないようにします。

😉 インパクト・コンテキストマップ

チケット影響範囲の特定と可視化を行います。その変更がシステムのどの境界を跨ぎ、どのような副作用を及ぼすかを可視化します。

画面上の変更であっても、バックエンドの外部システム（配送システムなど）やデータの流れに影響がないかを事前に検討します。これにより、パフォーマンスの問題やデータの整合性欠如といった技術的な落とし穴を未然に防ぐことができます。

本記事では「住所を追加したい」という要望が、実は配送先システムまで副作用がありました。

チケットの影響があるコンテキストのみの最小限で問題ありません。
コンテキストマップはmermaid形式でも記述できます。
データフローダイアグラムやリッチモデル自由形式で構いません。重要なのはメンタルモデルを使って影響を把握するのが目的です。

※手書きでもOKです。

専門家としての規律がシステムの未来を救う

5人日の小規模な改修であっても要求開発が不可欠なのは、「システムのあるべき姿」を維持し、その寿命を延ばすための最小限の防衛線だからです。中規模開発以上での設計ミスだけでなく、日常の「これくらいなら許容範囲だろう」という小さな妥協が積み重なり、技術的負債は生まれます。

今日から、作成する全てのチケットに、ユーザーストーリー、共通言語、コンテキストマップという「3つのフレームワーク」を添付しましょう！この60分間の思考こそが、1年後の開発チーム、ひいてはプロダクトの未来を決定づけると考えています。

おわりに

ちゃんと要求開発をすると、要求抽出、要求分析、要求仕様化、要求検証の要求工学に基づいたプロセスをまわすのですが、5人日で行うとヘビーだと感じ最小限にしています。グロース開発中心に考えると要求変化分析などは入れていきたいお気持ちは残ります。

AIを使った開発が進んでいくと上流工程での能力やスキルが多く求められていくと思います。
2025年の年末はちょっとモデリングを試してみてもいいのではないでしょうか？