会計ソフトを「個人開発」するときに考えてきたこと
先日、ここ一年半ほどかけて開発してきた「個人事業主向けクラウド会計ソフト Shiwake」をリリースしました。
会計ソフトという大きな何かを個人開発するというのはなかなか大変だったのですが、そんな会計ソフトの開発を行う中で考えてきたことを書いていきたいと思います。
[こんな人に向けて書いています]
- プロダクト作りにおける「コンセプト」や「進め方」に興味がある人
- ソフトウェア開発における「プロジェクトマネジメント」に興味がある人
最初の課題感をブラさない
プロダクトをつくるにあたっては、なにかひとつ「軸」となる考え方があることが望ましいです。多くの場合、それは「プロダクトにおける課題感」となります。
Shiwake の場合、下記のような課題感を最初に定義し、機能を考える際は常に頭の片隅に置きながら開発を行っていました。
今回のサービスの一番の課題感は、「個人事業主には関係ない機能追加ばかりなのに値上げをし続ける会計ソフトが辛い」という、至極個人的な課題感です。そのため、超特別な機能を作るだとか、会計の仕組みを変えるだとか、そのようなことはスコープ外でした。
[チーム開発の場合の余談]
個人開発の場合、自身がその課題感を理解しているだけでよく、自分の中の課題感が明確な場合は文章に落とさなくとも開発は進められます。（私の場合は、文章に落とすことで課題感をブラッシュアップしたいため、文章に落とすことが多いです。が、上記は他人が読むことを前提としていなかったため、文章としてあまり整っていないのはご愛嬌）
とはいえチーム開発の場合は、自身の課題感を「誰か」に伝える必要があります。そのため、文章として課題感を書き留めることは必須であり、また、誰かに伝えるための文章として書いていく必要があります。
最初から完璧に作らない
Shiwakeを作り出すまで、中の人は会計のことをほとんど知りませんでした。仕訳というものがあるだとか、確定申告をしないといけないといったレベル感でしか理解しておらず、そもそも会計ソフトを作ることは無謀のようにも思えていました。
そのため、「わからないことを前提」に、「作り変えていく前提」で機能開発を進めていました。
実際の開発でも、「プロトを作る→有識者含め何人かに触ってもらう→再設計→再度触ってもらう」ということを繰り返し、データベースやAPIの設計を固めていきました。記憶にある限り、3-4回ほど大きな見直し（数千行〜1万行程度の実装の修正）を行っています。
[チーム開発の場合の余談]
関わる人が増えるにつれ、関連範囲の多い大きな修正が行いづらくなります。そのため、ラフに作ったものを力技で修正するというのは「個人開発」ならではの技法に思えています。
チーム開発においてはこのような無理やりの修正は最小限に留め、「設計による品質の作り込み」に力を入れる方が効率的だとは思っています。
ドキュメントをきちんと作る
個人開発の場合はドキュメントを作らない人が多い印象ですが、それには明確に意を唱えたいです。
というのも、三日前の自分はもはや別人だからです。
三日前の自分が考えたことの多くは忘れてしまっており、ドキュメントがないと思い出すことすらできません。ドキュメントではなくコードを読めばわかるという人もいますが、コードに落としきれない細かな設計思想などはドキュメントがないと忘れてしまいます。
さらに、個人開発の場合は「自分の記憶がなくなった場合に助けてくれる他人」が誰もいません。そのため、ドキュメントが唯一の頼み綱です。
使い捨てのコードや記憶のあるうちに終わる開発以外、心と記憶の拠り所として、きちんとドキュメンテーションを行いましょう。
[チーム開発の場合の余談]
チーム開発の場合、ドキュメンテーションには「チームの認識をそろえる」という目的が追加されます。そのため、ドキュメンテーション自体の価値が個人開発よりも必然的に高くなります。
[AIを利用した開発における余談]
AIコーディングツール等を利用する場合、仕様が明確であるほど出力結果の質が高くなる傾向にあります。そのため、明確な仕様をドキュメントに落としておくことの価値はより高まったように思えます。
課題を適切に管理する
個人開発だとしても「課題管理」は適切に行った方が良いと考えています。上記のドキュメンテーションの話ともつながるのですが、考えないといけない問題があったとしても、課題として適切に管理されていないと忘れてしまいます。
※ ここでの課題は「時間をとって考える必要があるもの」くらいで捉えてください
規模の小さなツールやシステムの場合は問題ないのですが、ある程度規模が大きくなってくると適切に課題管理をしないと開発が前に進まなくなります。
[チーム開発の場合の余談]
チーム開発の場合、これらの課題を解消しないことで「他のメンバー」の生産性が下がってしまいます。そのため、課題を適切に管理することの重要度は個人開発よりも高いです。上記の課題管理表は「ひとり」で使う前提なので項目も適当ですが、本来は「担当者」や「期日」などが必須です。
タスクを適切に管理する
個人開発だとしても、最低限のタスク管理を行った方が良いです。というのも、管理されていないタスクは忘れてしまうからです。
とはいえ重厚なタスク管理を行う必要はなく、自分がわかる粒度で書かれたチェック表程度のものがあれば十分だとは思います。
[チーム開発の場合の余談]
チーム開発の場合「他の人もわかる状態」でタスク管理を行う必要があります。つまりは、チェック表のようなものだけでは足りず、タスク単体を見た時に「誰でもそのタスクができる状態」が求められています。
そのような状態を実現することで、タスクが他の人でも代替可能となり、リソースの適切な割り振りが可能となります。
テストを書き、リファクタリングをし、綺麗なコードベースを保つ
開発においてテストを書くのは当然と思われる方も多くなってきたとは思いますが、個人開発でちゃんとテストを書く人はまだまだ少数派かと思います。単純に、面倒ですからね。
とはいえ、一定規模・一定期間以上の開発の場合、過去に書いたコードの内容など当然のように忘れてしまいます。そのため、テストをきちんと書くことは長期的な開発効率化に繋がりますし、綺麗なコードベースを保つことで思い出すコスト（＝過去の自分が書いたコードを新しく読んで理解するコスト）を最小化することができます。
[チーム開発の場合の余談]
個人的な感覚として、チーム開発の方が「綺麗なコードベースを保つ」ことの難易度が高いです。コーディングの腕は人それぞれですし、各々好きな書き方もあるため、レビューをある程度行なっていたとしても、そのチームの一番レベルの低い人に合わせる形で徐々に質が落ちていくのが常です。
また、チーム開発では大規模なリファクタリングが行いづらいため、この観点からもコードベースが汚くなりがちです。それゆえ、コードが汚くなりづらいアーキテクチャの重要性が高いと感じています。
まとめ：人はいろいろなことを忘れてしまう
一定規模以上のソフトウェア開発の敵は、間違いなく忘却です。個人開発にせよ、チーム開発にせよ、「忘れてしまう」という問題が全ての根っこにあります。
ドキュメント作成や課題・タスク管理を行う本質的な理由は忘却ですし、コードベースを綺麗に保つことの本質的な理由も忘却にあります。
つまり、「忘却とどう戦うか」というのが、一定規模以上のソフトウェア開発における最重要課題なのです。
個人開発をされる方、チーム開発をされる方（その中でも特に、PM・PdMの方）は、その観点を持ちつつ開発を行っていくと、より良いプロダクト開発につながっていくと思います。
余談：リリースがめんどくさいので半年経った
必要な機能自体は昨年12月にはできていて、いつリリースしても良い状態でした。とはいえ、自身の確定申告や人柱になってくれた知人の確定申告を見届けないと怖いなという気持ちや、リリースすると対応が面倒だなとか、他の仕事等で時間が取られているうちに、半年くらい経ってしまいました。が、まあ連休だし良いかなと思って7月の連休にリリースしたのでした。
宣伝コーナー
個人事業主に特化したクラウド会計ソフト Shiwake は、価格も機能も「個人事業主にちょうど良い」仕上がりになっています。
個人開発を行っているみなさん、是非是非使ってみてください！
P.S. そのうちモバイルアプリも出します。こちらも、リリースしたくない面倒、、、、と思っているので、背中を押してくれる誰か、お酒を飲みにいきましょう！
リリースしたくないしてるうちにモバイルアプリが出来上がってしまったなにこれ
— きゅーい🥳 (@library_fit) June 20, 2025
いいなと思ったら応援しよう！
まいにちのご飯代として、よろしくお願いします。
コメント
1私は横領の手口、不正経理の手口を教え込まないことを考えました。
教え込ませたら、これほど手強い相手もいません。