ニーズの理解と課題の定義について
— 新しい機能が解決する目標を明確にできませんか？それとも、問題はタスク自体が明確にされていないことにありますか？FSDは、問題の定義や目標を引き出す手助けをすることも目的にしています。
— プロジェクトは静的に存在するわけではなく、要件や機能は常に変化しています。プロジェクトは最初の要望のスナップショットのみに基づいて設計されているため、時間が経つにつれて、コードは混沌としてしまいます。良いアーキテクチャの課題の一つは、変化する開発条件に対応できるようにすることです。
なぜ？
エンティティの明確な名前を選び、その構成要素を理解するためには、コードが解決する課題を明確に理解する必要があります。
@sergeysova: 開発中、私たちは各エンティティや機能に、その意図や意味を明確に反映する名前を付けようとしている。
課題を理解しなければ、重要なケースをカバーする正しいテストを書くことも、ユーザーに適切な場所でエラーを表示することもできず、単純にユーザーのフローを中断することにもなってしまいます。
どのような課題についての話？
フロントエンドは、エ ンドユーザーのためのアプリケーションやインターフェースを開発しているため、私たち開発者はその消費者の課題を解決しています。
私たちのもとに誰かが来るとき、その人は自分の悩みを解決したり、ニーズを満たしたりしてほしいのです。
マネージャーとアナリストの仕事はこのニーズを定義することです。開発者の仕事はウェブ開発の特性（接続の喪失、バックエンドのエラー、タイプミス、カーソルや指の操作ミス）を考慮して、そのニーズを実現することです。
ユーザーが持ってきた目的こそが、開発者の課題です。
小さな解決された課題が、Feature-Sliced Designの設計方法論におけるfeatureではあります。プロジェクト課題のスコープを小さな目標に分割する必要があります。
これが開発にどのように影響するのか？
課題（タスク）の分解
開発者がタスクを実装し始めるとき、理解の簡素化とコードメンテナンスのために、タスクを段階に分けます。
- まずは、上位レベルのエンティティに分けて、それを実装する
- 次に、これらのエンティティをより小さく分ける
- そしてさらに続ける
エンティティを分解する過程 で、開発者はそれに明確に意図を反映した名前を付ける必要があり、エンティティの一覧表を読む際にそのコードが解決する課題を理解するのに役立ちます。
この際、ユーザーの悩みを軽減したり、ニーズを実現したりするユーザーへの手助けをすることを忘れないように心がけましょう。
課題の本質を理解する
エンティティに明確な名前を付けるためには、開発者はその目的について十分に理解する必要があります。
- エンティティをどのように使用するつもりなのか
- エンティティがユーザーの課題のどの部分を実現するのか、他にどこでこのエンティティを使用できるのか
- などなど
結論を出すのは難しくありません。開発者がFSD枠内でのエンティティの名前を考えているとき、コードを書く前に不十分に定義された課題を見つけることができます。
どのようにエンティティに名前を付けるのか、もしそのエンティティが解決できる課題をよく理解していない場合、そもそもどうやって課題をエンティティに分解できるのか？
どのように定義するのか？
機能によって解決される課題を定義するためには、その課題自体を理解する必要があります。これはプロジェクトマネージャーやアナリストの責任範囲です。
FSD設計方法論は、開発者に対して、プロダクトマネージャーが注目すべき課題を示唆することしかできません。
@sergeysova: フロントエンドは、まず情報を表示するものである。どのコンポーネントも、まず何かを表示する。したがって、「ユーザーに何かを見せる」というタスクには実用的な価値がない。
基本的なニーズや悩みを見つけたら、あなたのプロダクトやサービスがどのようにユーザーの目標をサポートすることができるのかを考えます。
タスクトラッカーの新しいタスクは、ビジネスの課題を解決することを目的としており、ビジネスは同時にユーザーの課題を解決し、利益を上げようとしています。したがって、説明文に明記されていなくても、各タスクには特定の目標が含まれています。
開発者は、特定のタスクが追求する目的をはっきりと把握しておくべきです。しかし、すべての会社がプロセスを完璧に構築できるわけではありません。
その利益は何か？
では、プロセス全体を最初から最後まで見てみましょう。
1. ユーザーの課題を理解する
開発者は、ユーザーの悩みとビジネ スがその悩みをどのように解決するかを理解すると、ウェブ開発の特性によりビジネスには提供できない解決策を提案することができます。
しかしもちろん、これは開発者が自分の行動や目的に無関心でない限り機能します。さもなければ、そもそもなぜFSDやアプローチが必要なのか？という疑問になってしまいます。
2. 構造化と整理
課題を理解することで、頭とコードの中で明確な構造が得られます。
3. 機能とその構成要素を理解する
1つの機能は、ユーザーにとって1つの有用な機能性です。
- 1つの機能に複数の機能性が実装されている場合、それは境界の侵害である。
- 機能は分割不可能で成長可能になる場合があるが、それは悪くない。
- 悪いのは、機能が「ユーザーにとってのビジネス価値は何か？」という質問に答えられないことである。
- 「オフィスの地図」という機能は存在できない。
- しかし、「地図上の会議室の予約」、「従業員の検索」、「作業場所の変更」は存在可能である。
@sergeysova: 機能には、直接的にその機能を実現 するコードだけが含まれるべきであり、余計な詳細や内部の解決策は含まれないべきである（理想的には）。
機能のコードを開くと、そのタスクに関連するものだけが見える。それ以上は必要ない。
4. Profit
ビジネスはその方針を極めて稀にしか根本的に変えないため、ビジネスのタスクをフロントエンドアプリケーションのコードに反映することは非常に大きな利点になれます。
そうすれば、チームの新しいメンバーにそのコードが何をするのか、なぜ追加されたのかを説明する必要がなくなります。すべては、すでにコードに反映されているビジネスのタスクを通じて説明されているからです。
現実に戻りましょう
ビジネスプロセスが明確な意味を持ち、設計段階で良い名前が付けられている場合、その理解と論理をコードに移すことはそれほど問題ではありません。
しかし実際には、タスクや機能性は通常「過度に」反復的に進化し、（または）デザインを考える時間がありません。
その結 果、今日、機能は意味を持っていますが、1か月後にその機能を拡張する際には、プロジェクト全体を再構築する必要があるかもしれません。
開発者は未来の要望を考慮しながら2〜3ステップ先を考えようとしますが、自分の経験に行き詰まってしまいます。
経験豊富なエンジニアは通常、すぐに10ステップ先を見て、どの機能を分割するか、どの機能を他の機能と統合するかを理解しています。
しかし、経験上遭遇したことのないタスクが来ることもあり、その場合、どのように機能を適切に分解し、将来的に悲惨な結果を最小限に抑えるかを理解する手段がありません。
FSDの役割
FSDは、開発者の問題を解決する手助けをし、ユーザーの問題を解決するのを容易にしています。
開発者のためだけに課題を解決することはありません。
しかし、開発者が自分の課題を解決するためには、ユーザーの課題を理解する必要があります。逆は成り立ちません。
FSDに対する要件
明らかになるのは、Feature-Sliced Designのために少なくとも2つの要件を定義する必要があるということです。
- FSD方法論はフィーチャー、プロセス、エンティティを作成する方法を説明する必要がある。
- つまり、それらの間でコードをどのように分割するかを明確に説明する必要がある。これによりこれらのエンティティの命名も仕様に組み込まれるべきである。
- FSD方法論は、アーキテクチャがプロジェクトの変わりゆく要件にスムーズに対応できるようにするべきである。