はじめに

皆さんは合気道を知っていますか？

合気道は、合理的な体の使い方（体捌き）や呼吸法、剣の理合いを活かした崩しで、体格差に関係なく小さい力で相手を制することができる日本発祥の現代武道の一つです。

筆者は社会人になってから合気道を始めたばかりでまだ有段者でもないですし、合気道について偉そうに語れるような実力や知識はまだありません。が、数年前にとある道場で合気道を体験した時に完全に惹き込まれ、現在は気づけば合気道のことを考えて体が動いてしまうほど没頭しています🔥

＜合気道ってなに？もっと知りたい！という方向けの追加説明はこちら＞

合気会という開祖・植芝盛平の血筋を継ぐ道主たちにより設立・運営されている、最も主流で大きい合気道組織による説明は以下の通りです。

合気道は、開祖・植芝盛平翁(1883～1969)が日本伝統武術の奥義を究め、さらに厳しい精神的修養を経て創始した現代武道です。合気道は相手といたずらに強弱を競いません。入身と転換の体捌きと呼吸力から生まれる技によって、お互いに切磋琢磨し合って稽古を積み重ね、心身の錬成を図るのを目的としています。また、合気道は他人と優劣を競うことをしないため、試合や競技を行いません。

引用元：公益財団法人合気会 > 合気道とは

開祖である植芝盛平の思想の変遷や弟子・指導者による独自の解釈によって、数多くの流派に分かれてそれぞれが発展しているため、「多様性」も合気道の大きな特徴の一つです（呼吸力や氣で相手に触れることなく投げ飛ばすといった合気道もあれば、体のつくりや構造から合理的に関節を極める/投げるといった合気道もある）

私が現在通っている道場では、合気道以外にも剣道、居合道、杖道、空手など多くの武道を探求・修得し、剣術や杖術の理合を組み込むことでより実戦的な合気道を確立した西尾昭二先生の教えを継承しつつ稽古に励んでいます。西尾先生は日本国内のみならず、北欧諸国やアメリカ、メキシコ、フランス、ドイツなど各国で合気道発展のために尽力された後、2005年に77歳で惜しまれつつご逝去されました。

↓剣の理合を重視する西尾流の合気道

元々合気道は対武器を想定しており、武器を持っている手を抑えるために手を取る動作から始まる技が多いのですが、そういった技もボクシングのジャブ/ストレートや空手の突きにも応用できるように入り身や当て身を用いて独自に発展させているのが西尾先生の合気道です。（自分から相手に一切攻撃をしないイメージを持っていたので、初めて西尾流合気道を目の当たりにしたときは衝撃を受けました！）

▲ 合気道の追加説明はここまで ▲

本記事の趣旨に沿わないので合気道の説明はこれくらいにしておきますが、今回そんな私が合気道をテーマに個人開発を始めることにしたので、本記事では題材選定〜要件定義でやったことや意識したことを書き残しておこうと思います！

対象読者

個人開発をこれから始める、もしくは既に個人開発をやっている人
要件定義の進め方がイマイチわからないなぁ...という人
合気道、もしくは合気道に関する当個人開発について少しでも興味をもってくれた人

前提

本記事は要件定義編なので、技術的な話はほぼゼロです
競合サービスの調査やターゲット層のニーズ分析等も本記事のスコープ外とします

あくまで「自分はこんな感じで個人開発進めたよ〜」を記録したものです。
「このやり方が絶対的に正しい！」とか「みんなも真似するべき！」という意図で書いた記事ではありませんので、参考になる部分だけ参考にしていただければと思います。

作りたいサービスの概要（３行サマリ）

日々の合気道の稽古で学んだことや感想を自由に記録し、検索・閲覧ができるデジタル稽古日誌アプリ
個人の稽古記録の用途に特化した世代を問わず使いやすいUIやデザインを目指す
異なる流派や他道場生と合気道の技の考察や意見交換を通して交流できる機能も追加リリース予定

成果物

当記事で扱う内容も含め、個人開発の関連情報をNotionでまとめたWikiページを貼っておきます（題材選定〜要件定義の進め方だけ知りたい方はとばして続きを読み進めていただいてOKです！）

どうやって進めていったか

まず、今回の個人開発の大まかな作業フローは以下の通りです。
あくまで筆者が行った手順を書き出しただけであり、個人開発のやり方に正解はないのでそっくりそのまま真似をせずに本人がやりやすいよう進めるでいいと思います。（デザインが一部できた時点で実装し始めてみたり、進め方を個人の裁量で自由に決められるのが個人開発の醍醐味なので）

★ ＝本記事のスコープ

★題材選定
★要求の整理
★要件定義
デザイン作成
DB設計
技術選定・アーキテクチャ設計
実装〜テスト
デプロイ・リリース周りの諸作業

本記事では、1〜3の前準備〜要件定義を具体的にどう進めていったのか改めて整理し、書き残していきます。

題材選定

個人開発において「何を作るか」を決めるのは、最も重要度が高い かつ 判断材料となる基準・観点も各人各様なので、皆さん自身でご自分に合う決め方を模索していくのがよいと思います。

あくまで参考程度にですが、私は以下の観点で題材選定を行いました。

個人開発をする目的が達成できるか？
リリース後に誰1人使ってくれないとしても、自分だけは使い続けたいと思えるサービスか？

個人開発をする目的が達成できるか？

個人開発を始めるときの目的は人それぞれで、同じ人でもタイミングによって目的は変化すると思います。「収益化してお金を稼ぎたい」とか「転職に向けてポートフォリオを用意したい」とか色々ありますよね。

今回の私が個人開発をする目的は、「普段仕事で使っているNext.jsやTypeScriptを使ったコーディングに費やす時間を定量的に増やし、理解度・習熟度の向上を図る」でした。

よって、この目的を達成するために以下のようなものは選択肢から外しました。

機能数が少なくて難易度の低い（Try & Error の質や量が落ちる）もの¹
- 例）Todo管理アプリ、ブログなど
機能の実装よりもUX設計やデザイン重視のもの
- 例）LP、コーポレートサイトなど

AikiNoteは、技術スタックとしてNext.jsやTypeScriptなどの自分が理解度・習熟度を高めたいものを採用しており、かつ継続的に機能追加していくことを想定しているサービスのため、私の個人開発の目的を十分に達成しうると考えています。

リリース後に誰1人使ってくれないとしても、自分だけは使い続けたいと思えるサービスか？

こちらの観点もかなり重要だと思っていて、要はペルソナを自分自身に設定したうえで作ったサービスを利用→使いにくいところや改善点を反映→また使ってみるの繰り返しで、サービスの継続的な改善や開発モチベーションの維持ができるかという内容です。

もし本当の意味で自身が使い続けたいと思えるサービスではなく、「こんなサービスあったら誰かが使ってくれるだろう」という期待の元で長い期間個人開発をしてリリースしたとします。

しかし、もしそのサービスを継続的に使ってくれる人が1人もいなかった場合、なんのフィードバックを得ることもできないのでサービスの改善もしにくいですし、開発のモチベーションも消失してしまいますよね。

よって私は、自分が大好きな合気道を続けている限り、ユーザーが自分1人だとしても修正を重ねながらずっと使い続けたいと思えるようなアプリ（合気道に特化した稽古記録アプリ）を開発することを決めました。

もし作りたいものが決まったうえで「本当にこれ作るべきかなぁ...？」と不安を感じる場合は、さらに誰のどういった課題を解決するのか・なぜそれを解決したいのか・どうやって解決するのかの3点を詳細に書き出してみると、イメージしている成果物の解像度が上がって判断しやすくなるかもしれません！

要求の整理

作りたいものが明確になったら、次はその目的（Why）を深堀りすることで要求を整理します。ここでいきなり仕様寄りの要求（How）ではなく、システムの変化によって変わることのない本質的な要求をしっかり洗い出すことが大切です。

❌ 悪い例

稽古内容を記録するフォームはTOP画面からワンタップでアクセス可能にしたい
技や受けの攻撃方法など、定型的な情報はいちいち入力せずにタグで管理したい
他の人が投稿した稽古記録にコメントしたり返信したりできるようにしたい

⭕ 良い例

稽古が終わったあとの着替え直後や帰り道にサッと起動し、学んだことや感想をスムーズに記録したい
他の流派の合気道家もしくは同じ流派（道場）内の他メンバーと稽古記録を共有し合ったり、考え方や技についての考察を共有・議論できる場がほしい

理由は大きく2つあって、「要求の実現方法を柔軟に検討するため」と「必要最低限の要件のみを抽出するため」です。

要求の実現方法を柔軟に検討するため

実現するためのHowに近い要求（ほぼ要件）をベースに要件定義を固めてしまうと、その裏に隠れている目的を実現可能な他の手段・可能性を十分に考慮できなくなってしまいます。

例えば、読者の皆さんも普段使っているであろうスマートフォンの製品開発において「バッテリーの容量を大きくしたい（最低でも4,000mAh以上）²」のような要求が出てきたとします。しかし、これは本質的な要求ではなく実現するためのHowに近い要求（ほぼ要件）であるため、バッテリー容量を大きくする以外の実現方法がありません。

それに対して、「外出先で長時間使用してもバッテリーが切れず、安心してスマートフォンを使いたい」という本質的な要求（HowではなくWhy寄り）を定義すれば、以下のように実現方法をいくつか挙げることができ、後続の要件定義でより多角的なアイデアを要件として検討することができます。

大容量のバッテリーを搭載する
省電力モード
充電速度を改善する
ソフトウェアの最適化で消費電力を抑える

そもそも「要求」と「要件」の違いって何だっけ？と思った方は、以下の記事を読んでみてください。とてもわかりやすかったので、オススメです。
非エンジニアだからこそ要求定義と要件定義は極める > 2. 要求定義と要件定義の違い

必要最低限の要件のみを抽出するため

言うまでもなく、個人開発はたった一人で開発タスクをこなしていく必要があるため、開発工数を最小限に抑えることが重要です。

最近は生成AIの急速な発展によりコーディング補助やUIの自動生成は充実していますが、それでも仕様変更や手戻りが頻発すると無駄な工数がかかってしまいますし、その分リリースが遅くなってしまいます。

本質的な要求から最低限の要件のみを抽出することで、以下のメリットを得ることができます。

手戻りを減らすことができる
- 必要最小限の要件に絞ることで、開発途中の仕様変更や大きな設計の見直しを減らすことができる
リリース時期を早めることができる
- まずは MVP として必要最小限の機能のみでリリースし、ユーザーのフィードバックを受けながら追加開発を行うことで、より実用的なアプリに育てていくことが可能になる

MVP = Minimum Viable Product
顧客のニーズを満たす最小限のプロダクトを指す概念

要件定義

要求の整理によって本当に実現したいこと・真の目的が明らかになったら、Figma等のデザインツールや手書きで用意したワイヤーフレームを使って実際のユースケースを想像しながら、要求を満たせる必要最小限の要件から書き出していきます。

私の場合、以下の流れで要件定義を進めました。

ユースケースの整理
機能要件の洗い出しとリリース優先度付け
非機能要件やその他に考慮しておきたいことを検討・追記していく

ユースケースの整理

まずは「このサービスを使ってユーザーがどんな行動を取るか（どんな場面でどう使うか）」を具体的にイメージしながら、ユースケースをFigmaでワイヤーフレームを作成しつつ洗い出していきます。

例として、今回私は以下のようなユースケースを想定しました。

稽古後にスマホでサッと記録を残す
過去の稽古記録を検索・参照する
特定の技や攻撃方法ごとの記録を一覧で確認する
他の道場生や異なる流派の人の稽古記録・考察を読む
稽古日数や稽古記録ページ数など、自身の稽古歴を定量的に振り返る
etc...

当時のワイヤーフレームは残していないのですが、上記のイメージが湧きやすいよう作りかけの一部デザインを代わりに貼っておきますmm

機能要件の洗い出しとリリース優先度付け

次に、洗い出したユースケースそれぞれに対して、必要な機能や画面を具体的に書き出していきます。

例えば、「稽古後にスマホでサッと記録を残す」では以下のような要件が出てきます。

ファーストビュー画面からワンタップ操作でページ作成できる
立ち技/坐技や受けの攻撃法（取り方）や技名をタグで選択できる
デフォルトでその日の日付がタイトルに入力されていて、タグ選択→フォーム入力→保存でスムーズに稽古記録をつけられる
etc...

それらを一覧化したら、以下3つのリリース優先度で機能要件を分類分けしました。

初回リリースで必須な機能（MVP）
後追いで追加が確定している機能（Phase 2）
将来的に追加するかもしれない機能（Phase 3）

非機能要件やその他に考慮しておきたいことを検討・追記

非機能要件やその他項目については、個人開発ということもあり、すべてを厳密に漏れなく定義するというよりも、自分自身が気にしたい観点だけをピックアップして書き出すという方針で進めました。

AikiNote開発では以下のようなものを検討・記載しています。

マルチプラットフォーム対応
- 工数を最小限に抑えるためにも、想定されるユーザー層やユースケースごとのデバイス使用率に応じてなるべく絞って対応する
- 例えば合気道の稽古記録アプリであれば：
  - 利用者は？合気道を習っている社会人 or 学生
  - 使うタイミングは？稽古直後、帰宅途中、道場での休憩中 etc
  - 使うデバイスは？ → 圧倒的に「スマホ」が多いと予想できる
- → スマホ（iOS/Android）のモバイルブラウザもしくはネイティヴアプリに対応すれば十分そう
セキュリティ
- ユーザー認証・認可
  - OAuth 2.0 + PKCE を利用し、安全な認証フローを設計する（特にSPAやモバイルアプリで有効）
  - JWT（JSON Web Token）によるセッション管理を行い、有効期限や署名検証を徹底する
- XSS、CSRF、SQLインジェクションなどの一般的な脆弱性の対策は最低限行う
etc...

また、IPA（独立行政法人情報処理推進機構）が定義している非機能要求グレードをベースにして、「自分の開発規模だとこれは考慮しなくてOK」「ここだけは押さえておきたい」といった形で取捨選択しながら書いてみるのもよさそうです。

上記の手順で実際に書き上げた成果物は以下リンクからご覧ください。

要件定義時の方針として、初期リリース時はMVP（必要最小限の機能のみ）で早期リリースを目指し、追加リリースでユーザーが増えた場合に使用してもらいたいSNS的な要素を随時実装・発信していくことにしました。

理由は、最初から多機能にしすぎると開発期間が長くなり、途中でモチベーションが低下して挫折しやすくなるからです。

まずは最低限の機能でリリースし、実際に自分で使いながら必要な改善点を見つけて修正を繰り返すのが、個人開発においては持続可能で現実的な進め方だと考えています。

その他・Tips

個人開発系の情報をたくさん拾えるように常にアンテナを張る
- solomaker.dev等の個人開発者向けプラットフォームやその他SNSでどういったアイデアが実際に個人開発でリリースされているのか、どういった要件でどの技術が採用されているのか等を学ぶ
- よく観てるYoutubeチャンネル
生成AIをなるべく活用して工数や考慮漏れを減らす
- Notion AI に「個人開発したいから要件定義やサイトマップ等の必要な情報を一箇所に集約できるページの雛形を作って」と雑に投げたらイイ感じのテンプレートをサクッと作ってもらえた
- 要求をインプットさせたうえで、要件定義に漏れがないか・他に追加すべき機能があるかをChatGPTに聞きまくった

おわりに

いざ個人開発をやろうと思ったときに、題材選定〜要件定義について細かく書いている記事が少ないと感じたので自分なりに手順や意識したことをまとめてみました。

個人開発は自由度が高い分、途中で方向性を見失ったり、やることが多すぎて手が止まったり挫折してしまう人が多いと思います。（自分は何回もありますw）

しかし、しっかりと目的やそのために必要なタスクを整理し、最小限の要件でのすることで、開発の負担を減らしつつ継続しやすくなるんじゃないでしょうか。

まだスタートしたばかりの私の個人開発について書いた当記事および個人開発Wikiが、同じように個人開発を始めようとしている人の一助となれば幸いです。（Notion AI に作ってもらったテンプレートですが、もし必要あれば複製してご活用くださいmm）

参考文献

当記事執筆時点で参考にした記事・サイトのURLは以下に記載されています。

もし普段使っていないような馴染みのない言語・フレームワークの学習が目的であれば、シンプルなTodo管理アプリ等は個人開発の実装対象としてちょうどよいと思います。 ↩
「mAh」は「ミリ・アンペア・アワー」と読みます。バッテリーの容量を示す単位で、mAhは「1時間に流せる電流」を表します。たとえば100mAhは、100mAの電流を1時間流せる容量であることを示しています。 ↩