Reorganized the structure of tailwind.config.js

[nagineko]

Issue #, if available:
#677

Description of changes:

• Organized color code names managed in tailwind.config.js.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[nagineko]

ワークフローの実行ありがとうございます。
深夜作業でtailwindのデフォルトカラーコード＆スケール値（gray-300）と空目してwarningになっていたので、カラーコード名を修正しました。

[wadabee]

PRありがとうございます！

Issueにて共有できていなかったのですが、従前からの課題として、アプリのUIデザインポリシーを明文化できていないため、どのカラーをどこで使うべきなのか分かりづらいという状況になっているというものがありました。
Atomicデザインのようなポリシーで細かくコンポーネントを分けて管理すれば、デザインの統一性を計りやすくなりますが、歴史的な経緯もあってそれはできていません。

という課題を踏まえての私の意見です。

フォントへのみ使用することが適切な色やホバー時のみ使用することが適切な色など、管理が複雑化しやすくなっているように見受けられます。

現行のconfigは体系的に管理できていなかったため、config自体の階層構造化については賛成です。
しかし、現行のフォントのみに使用する、ホバーの時に使用するなどの機能指向の色の管理方法は、このconfig自体がデザインポリシーを兼ねるのではないかと考えております（カラーテーマを眺めればどこで使うべきかわかるという意味で）。
つまり、font, hover, actionableなど、機能指向で整理した方が整理した方がわかりやすかったりしないでしょうか？

色の拡張性を持たせられるような構造に整理したいです。

色の拡張性を持たせられるというメリットも承知しているのですが、秩序を作りたい（作るべき）という思いも強いです。
明文化されているデザインポリシーがない状態で、拡張性だけを追加しても、実装時のカラー選択に迷う、秩序を保ちづらい、レビュー基準が曖昧になるなどのデメリットも出てくるかと思います。
明文化されたデザインポリシーを用意すべきと言われればその通りなんですが、現状作業リソースの関係でできておりません。

こちらの方針で修正してくださいというお願いというわけではなく、より開発、メンテしやすいコードになるようにご意見を聞きたいという意図になります！
ご確認の程よろしくお願いいたします！

[nagineko]

@wadabee
コメントありがとうございます！
2点意見をまとめたのでご確認お願いしますmm

①
デザイン周りは言語化が難しいのですが、
ご認識の通り、デザインポリシーは策定すべきだと思います。
いわゆるコーディング規約に当たるポリシーだと認識しているので、それがないことにはは混沌としますし、また第三者からのコミットも期待できなくなってしまうと思います。
（個人的には後者が大問題で、他ツールとの相対的なシステム価値の衰退を表します）

ですのでまずはデザインポリシーを用意すべきだと思いますが、リソースの都合で作成いただくのが難しいならば、私の方で作成するのはどうでしょうかと考えています。

ただし現状ですと鶏が先か卵が先かになっていて、先にデザインポリシーを作っても今後のデザインアップデートに耐えうるポリシーを作成することが難しいという小問題もあると思います。

そこで、以下の順番でissue立てて進めていく方針はどうでしょうか？
tailwindの色管理健全化（今）→既存デザインを整えるPR（デザインポリシーも込）→新規デザインを追加したり既存デザインを削除する→Ladleとコンポーネントの表示完全一致化
（ladleとコンポーネントの表示完全一致の件はYukinobu-Mineさんにふわっとお伝えしてはいます）

②
折角tailwindを利用されているので、色管理の状態部分はコンポーネントの責務で、色自体の管理はtailwindの責務として分割した方が良いと思いました。

今はデザインポリシーまで兼ねているので、認知まではしやすいけど、どういう時にその色を使うのか？用意されてない状態に対する色はどうするのか？（事前に将来使ってもらう色と状態を用意するのも大変だと思います）を毎回確認する必要があるので、複雑だと感じます。

そういった問題を解消するために、①を別途実施しデザインポリシーとtailwindを分離できたらなと思います。

長文になってしまい申し訳ないのと、必ずこうしたいという訳ではないので検討いただけますと幸いです。

[wadabee]

@nagineko
レスが遅くなってすみません。
コメントのご確認ありがとうございます！

naginekoさんのおっしゃる通りで、デザインやUI周り（コード管理も含めて）で原則に反しているところも多数あり、課題として認識はしています。ただ、そちらは歴史的経緯があってのことで、コードベースも大きくなっていることからある程度は仕方ないという判断をしています。
もちろんどうでもいいということではなく、より良い構成に変えていくべきだとは考えているのですが、Amazonの文化としてユーザーのニーズをもとに発明を行うべき（意訳）というものがあり、このアセットもその思想をもとに開発しています。現在は、ユーザーからのニーズが多いボット機能の強化に取り組んでいる最中であり、リソースが足りない状況です。
デザイン周りをベスプラに沿って改善していくこともこのアセットの価値につながっていくことだとは思いますが、ユーザーからの要望があまり上がっていない機能のため、相対的に優先度を落とさざるを得ない状況です。
上述のボット機能の強化に取り組んでいる最中とのこともあるので、大変申し訳ございませんが一旦本件はPendingとさせてください。またの機会に改めて検討させていただければと思います。
今後ともよろしくお願いいたしますmm

[statefb]

@nagineko さん
PRありがとうございます！またダークテーマ対応もありがとうございました！上記 wadabee への補足ですが、次回もしご要望がある場合、Contributionに記載のある通り、一度Issueでdiscussionさせていただき、方針が決定してからお願いしたいです（せっかく実装したものが無駄になってしまうことを防ぐため）。

今回はご期待に添えず申し訳ないですが（おっしゃる内容はよく理解できますが、我々も有志でメンテナンスしていることもありリソースが足りていない状況です）、Contribution自体は非常にありがたいですし、嬉しく思いますので、今後とも何卒よろしくお願いいたしますmm

[nagineko]

@wadabee @statefb
お二人ともご返信ありがとうございます。
文化や歴史について認識いたしました、レビューいただきありがとうございました。

1点補足いたしますと、デザインをべスプラにしたい意志はなくニーズ（ユーザビリティの向上）を満たしたいだけでしたので、その内容をissueにまとめました。以降issueの方でやり取りさせていただけますと幸いです。
#706

重ねて、本件レビューいただきありがとうございましたｍｍ
お忙しい中日々メンテナンスいただき大変感謝しております。

@statefb
誤解を与えてしまったようで申し訳ありませんが、本PRはこちらにてissueを作成した後、PRを作成させていただいておりました。
他の方が作成したissueも参考にし、ラベルが貼り替えられていた上で特に議論等ございませんでしたのでPRを作成いたしましたが、今後のPR作成手順として参考にしたく、他にPR作成手順などございましたらご教授いただけますと幸いですmm
こちらこそ、今後とも何卒よろしくお願いいたします。