※画像はイメージです
はじめに
「Excelの転記をなくしたいけれど、何をどう頼めばいいか分からない」
「開発会社に要件をまとめてくださいと言われて、話が止まった」
「やっと完成したものを見たら、思っていたのと違った」
業務システムの相談で、よく聞く話です。
弊社の取締役CTOで、開発会社の代表を務める新井です。クラウドインフラとスクラム開発を専門に、10bookの開発にも携わっています。
先に結論を書きます。要件は、最初にまとまっていなくて構いません。動くものを早く出して、使いながら決めれば大丈夫です。今回はこの進め方と、そこに経理がわかる人が入ると何が変わるのかをお話しします。
要件は、使ってみて初めて分かる
開発を頼むと、最初に要件を聞かれます。しかし、毎日の業務は当たり前になっているので、言葉にするのは簡単ではありません。
私自身の経験です。社内の進捗管理システムに、請求の源泉徴収の欄を足したことがあります。最初は「あり・なし」の2択で作りました。動くものを見た代表の上田から、「一部だけあり」も要ると指摘があり、その日のうちに3択へ直しました。文章だけで確認していたら、気づくのはもっと後だったはずです。
言葉の確認では、認識はずれます。同じ「請求」でも、頭に浮かべているものが人によって違うからです。動くものがあれば、ずれはその場で分かります。
要件なしで始められる、3つの理由
もちろん、どの開発会社でも要件なしで始められるわけではありません。私たちができるのは、次の3つがあるからです。
- 開発の経験：買取サービス、鉄鋼業の見積、獣医療、会計など、業種の違う業務システムを作ってきました。話を聞けば、必要なものの見当がつきます。
- バックオフィスの知識：請求、支払、給与、決算の流れを深く知っているので、言葉にならない部分をこちらから聞き出せます。
- 確立した開発手法：スクラムと生成AIを使う進め方が決まっています。要件が固まらなくても、開発を止めません。
スクラムで、短い区切りごとに動くものを出す
スクラムは、短い区切りを繰り返して開発を進める方法です。区切りの長さは決めていません。内容に合わせて、できるだけ短くします。その中で次の4つを回します。
- 決める：いちばん困っていることを1つ選ぶ
- 作る：その部分を、動くものにする
- 使う：実際の業務で触ってみる
- 直す：使って分かったことを、次の区切りに反映する
PDCAを、短い間隔で回すということです。途中で優先順位を変えられますし、できた部分から先に業務で使い始められます。
買取サービスを運営する会社の、会員向けの買取システムも、この進め方で作っています。Appleギフトカードや新品のiPhoneを買い取るサービスで、申込から本人確認、査定、お客様への振込、在庫の管理までをつなぐシステムです。2026年に開発を始めて、短い区切りごとに動く画面をお見せしながら進めています。申込の画面の分かりやすさや、本人確認で書類が足りないときの戻し方のように、実際に触って初めて出てくる要望を、次の区切りに入れていきます。
生成AIを開発に使うことで、動くものを用意する時間は大きく縮まりました。打ち合わせで出た案を、その日のうちに動く形にして見せることもあります。
経理がわかる人が入ると、何が変わるか
早く作るだけでは足りません。スクラムの弱点は、目の前の画面に目が向いて、数字の出口が後回しになりやすいことです。入力した取引は仕訳になり、月次レポートや決算書につながります。ここが抜けると、次のようなことが起きます。
- 値引きや返金、前受金の扱いを決めておらず、月末に経理が手で直している
- 税率ごとの金額が取れず、インボイスや消費税の集計で作り直しになる
- 士業や個人の外注への報酬で必要になる源泉徴収の項目がなく、請求の画面を後から直す
バックオフィスアドバイザーは、動くものを見ながら「この取引はどんな仕訳になるか」「月次でどの単位の数字を見たいか」を確認します。
ミスや不正を防ぐ仕組みも同じです。会計事務所の視点で、早い段階から確認したいのは次の4つです。
- 権限：誰がどの情報を見られて、どこまで操作できるか
- 承認：作る人と承認する人が分かれているか（振込データなど）
- 履歴：誰がいつ何を変えたか、過去の数字が後から変わらないか
- 証憑：請求書や領収書が取引と結びつき、すぐ取り出せるか
先ほどの進捗管理システムでも、源泉徴収の設定を共通の設定表から読む作りにしたところ、設定を消すと過去の請求の欄が空になると分かり、請求ごとに値を残す作りへ直しました。こうした仕組みは、後になるほど直す範囲が広がります。
証憑の設計は、法律への対応も兼ねています。メールなどで受け取った請求書のデータは、原則として電子のまま保存し、取引日・金額・取引先で探せるようにしておく必要があります。
※画像はイメージです
業務システムからインフラ、セキュリティまで、ひとつのチームで
システムは、動かす土台があって初めて使えます。画面の開発とサーバーの構築を別の会社に頼むと、不具合が起きたときに原因の切り分けから始めることになります。
私の開発会社は、もともとクラウドインフラを得意としています。業務システムの開発に加えて、AWS・Azure・GCPのクラウド基盤や、自社でサーバーを持つオンプレミス環境の構築、監視や保守までを一貫して担当します。サーバーの構成をコードで残し、リリースを自動化しています。動くものを短い間隔で出し続けられるのは、この土台があるからです。
開発はLaravel、Java、Go、Next.js、Reactなど、お客さまの環境に合わせて選びます。
経理のデータは、会社の機密そのものです。公開前のセキュリティチェックや、攻撃者の視点で実際に侵入を試みるペネトレーションテストにも対応します。いま動いているシステムの確認からでも、ご相談いただけます。
10bookを使い続けてわかったこと
10bookの土台は、公認会計士である代表の上田が、簿記の知識がなくても決算書を作成できる仕組みとして開発を始めたシステムです。いまは見積から請求、入金、給与、月次レポートまでをひとつのシステムで扱い、弊社の会計サービスの実務でも使っています。
使う人が増えると、作ること以上に、使い方を伝えることが大切になります。10bookでは機能ごとの操作マニュアルに加えて、はじめての設定のチュートリアルや説明動画も用意しました。チュートリアルは、代表から依頼を受けたその日に公開しました。お客さまの開発でも、マニュアルや説明動画の作成を範囲に含められます。費用はお見積もりでお知らせします。
相談の前に分かっていると話が早いこと
要件定義書は要りません。次のことが分かれば、話を始められます。分からなければ、それも一緒に整理します。
- いま、いちばん時間がかかっている作業は何か
- その作業で使っているExcelや帳票はどれか
- 新しいシステムを誰が使い、誰が数字を確認するか
まとめ
要件がまとまらないのは、頼む側の準備不足ではありません。動くものを見ないと決められないことがあるだけです。短い区切りで動くものを見せて、使って、直す。その中で、数字が合うかを経理の目で確かめる。これが私たちの進め方です。
開発は私を含む3名のチームが担当し、ご契約は私が代表を務める開発会社と直接結んでいただきます。経理や会計の確認には、公認会計士・税理士である代表の上田をはじめ、弊社のスタッフがバックオフィスアドバイザーとして加わります。私は弊社の取締役CTOとして10bookにも携わっているので、請求や仕訳の話が経理の言葉のまま通じます。
「うまくまとめられないけれど、なんとかしたい」という段階で構いません。10bookや会計サービスをご利用中の方は担当者へ、はじめての方はお問合せフォームからご相談ください。ご相談の内容は、開発の検討のため、私が代表を務める開発会社と共有します。サービスの詳しい内容は以下からご覧いただけます。
