POLプロダクト部 Advent Calendar 2020 1日目の記事です。
こんにちは、株式会社POLプロダクト部のミズノと申します。研究 x テック = LabTechという新しい領域にチャレンジしている会社に所属しています。
今年のアドベントカレンダーではエンジニア、デザイナ、プロダクトマネージャーが日々の取り組み、ノウハウ、ナレッジを投稿しますのでご期待ください！
1日目の記事ということで何を書こうかなと思ったのですが、先日社内で行ったフロントエンド設計MTGからの学びをシェアしたいと思います。
事の始まり
我々のフロントエンド開発においてはいくつかの課題を皆感じていました。
例えば、
- Reactを採用しているがRedux、Hooksをどのように共存させるか
- 複数のプロダクトで同じようなコンポーネント作ってる
- 新しく入ったメンバーのキャッチアップに時間がかかる
これ以外もたくさんあり、共通していたのは、
何を作るのかより、どのように作るかというところに頭を悩ませてる
自由がありすぎるとベストを探し始めてしまいます。これ自体は悪いことではないのですが終わりのがないので困りますよね。そこでフロントエンド開発における社内ルールを設けることにしました。
ルール作り
具体的なルールは以下のようなものです。
- コンポーネントはAtomic Designで別リポジトリ管理する
- グローバルstateはReduxで管理するが、基本はhooksを使う。
- コンポーネントとデータの連携は必ずコンテナ経由で行う
- propsで値を渡すのはatomsのみに制限する
- それ以外はcontext経由で値を取得する。
- presentation、services、dataの３層構造でコードの置き場所を明確にする
ディレクトリ構造は以下をベースにしています。
app
┝ component
│ ├ atoms
│ ├ molecules
│ ├ organisms
│ ├ templates
│ └ pages
┝ containers
│ └ routing
┝ context
┝ redux
│ ├ middleware
│ └ modules
┝ services
└ data
こんな感じで、皆でワイワイ話しながら、お互いの考えを話し合いました。自分が考えてもいないこともありとても良い学びの場となりました。これからも定期的に開催していく予定です。
設計とはルール作り
実は上のルール自体はそこまで重要ではないです。これを読んでいる皆さんの会社にそのまま当てはめてもうまくいかないこともあるでしょう。重要なことは
- ルールがあるとプロダクト作りやすく、集中できる。
- 制限されることでより良い設計を見つけることができた
という2点でした。RoRの設定より規約も同じですよね
身近なところでは、何かを考えるときに、まず叩き台を作ったりするとたくさんの意見が出ると思います。これも叩き台がある種のルールとして機能しているからだと思います。
僕は設計の役割は、ルールを作ることだと考えています。これはコードの設計、デザイナによるデザインも同じだと考えています。ルールがあることで窮屈になるのではなく、それがある事で考えやすく、作りやすく、創造性が発揮しやすいと建築家の隈研吾さんも仰っていました。
スタートアップにおけるエンジニアの役割は色々あるとおもいますが、POLではマーケットにフィットするプロダクトを素早く作ることを重視しています。ルールがあることで、クオリティ高く、素早くプロダクトが作れると考えています。すらすら書けてると気分も良いですよね。
最後に
この記事が皆さんの参考になり、より良い設計が発見されることを期待しています。その時はぜひシェアしていただけると嬉しいです。
POLではこんな感じで、より良いプロダクトを開発するために試行錯誤しています。
研究領域に興味があり面白そうだなと思っていただけたら、ぜひカジュアル面談してみませんか？ 会社の良いところ悪いところ包み隠さずお伝えします１
エンジニアは積極採用中ですし、エンジニア以外のポジションもたくさんあります！
明日はフロントエンドの鬼こと@ultrasevenstarさんが記事を書きます。ご期待ください！