SHIOPON LABO

知見や備忘録、レビューなど。しおぽん(shiopon01)のブログ

React/Reduxビギナーのための、練習用スターターキットを公開している

公開しています

React/Reduxビギナーのための、練習用スターターキットを公開しているという記事。
最小限の機能で、機能追加が煩わしくない1ページのReduxアプリを作成するためのスターターキットを目指した。

github.com

中身としては、react-create-appコマンドで作成したReactアプリに、Reduxのみを組み込んだ形。package.jsonを見ると、追加したパッケージは基本的なRedux関連のパッケージのみだということが分かる。多くの部分はreact-scriptsに依存している。
(学習コストを下げるためredux-routerなどは組み込まなかった。ルーティングをしっかり作りたい場合や他のパッケージを利用したい場合は自分で追加してもらいたい)

"dependencies": {
  "react": "^16.2.0",
  "react-dom": "^16.2.0",
  "react-redux": "^5.0.6",
  "react-scripts": "1.1.1",
  "redux": "^3.7.2"
},

サンプルで最初から置いてるTodoアプリは、Redux公式のexampleをこのプロジェクトのディレクトリ構造 (modular) に合わせて移植した。react-create-appで生成された画面の下にそのままTodoアプリを突っ込んでいる形のため、ここは今後、見栄えを良くしていきたい…。

Example: Todo List - Redux

f:id:shiopon01:20180320161504p:plain

ディレクトリ構造

ActionやReducerは専用のディレクトリやファイルに分けるのではなく、依存し合うそれぞれを1つのモジュール単位として、1つのファイルで管理する手法を採用している (Ducks proposalと呼ばれてる?) 。これを採用するため、ducks-modular-reduxを参考にした。

.
├── public                           # 静的ファイル
├── src                              # アプリのソースコード
│   ├── index.js                     # id="root"へのRender、StoreのProvide
│   ├── components                   # コンポーネント
│   ├── containers                   # コンテナ
│   ├── modules                      # モジュール (Action, Reducer, Action Creatorを含む)
│   │   ├── reducers.js              # それぞれのモジュールのReducerをまとめたもの
│   │   ├── todos.js                 # Todoモジュール
│   │   ├── todos.spec.js            # TodoモジュールのTest
│   │   └── visibilityFilter.js      # VisibilityFilterモジュール
│   └── unit                         # 小さな機能
│       ├── injectStyle.js           # CSS`@keyframes` を扱うための関数
│       └── registerServiceWorker.js # https://goo.gl/KwvDNy
└── LICENSE                          # MIT

ducks-modular-reduxでは、依存するそれぞれのAction, Reducer, Action Creatorを1つのモジュールとして1つのファイルにまとめる手法を提案している。
よくある、ActionやReducerをそれぞれ専用のディレクトリやファイルとして/reducer/index.js/action.jsで管理されるパターンは、機能 (Action, Reducer) の追加が非常に煩わしい。たしかにうまく管理はできるのだが、実際にプログラミングしてアプリを作る場合、この面倒くささは未経験の想像する面倒くささを凌駕する。

このプロジェクトで採用しているプロジェクト構造は、全ての機能はモジュール単位で分けているため幾分マシだ。機能を追加したい場合、必要な分モジュールを追加するだけで良い。機能が大きくなると1ファイルが大きくなってしまうデメリットはあるが、可読性が失われることはほとんどないし、ファイル移動が必要ないというメリットがある。

// Actions
const LOAD   = 'my-app/widgets/LOAD';

// Reducer
export default function reducer(state = {}, action = {}) {
  switch (action.type) {
    default: return state;
  }
}

// Action Creators
export function loadWidgets() {
  return { type: LOAD };
}

github.com

コンポーネント構造

新しい機能を実装したいならば、とりあえずサンプルで用意しているTodoを参考にすれば良い。(もとはReduxのexampleだが…)
現在のコンポーネントとコンテナコンポーネントの関係を図にしてみる。[ ]で囲まれているものがコンテナコンポーネントで、囲まれていないものがコンポーネントだ。

index.js
└── App.js
    ├── [AddTodo.js]
    ├── [VisibleTodoList.js]
    │   └── TodoList.js
    │       └── Todo.js
    └── Footer.js
        └── [FilterLink.js]
            └── Link.js

コンテナコンポーネントではreact-reduxconnect関数を使ってstateの値をpropsとして受け取ることが出来る。コンテナコンポーネントを使うことで、好きなコンポーネントでstateの値を受け取ることが出来るもの、と思えば良い。

このプロジェクトの詳しい使い方は後日。

補足

  • CSSはファイルをインポートするのではなく、コンポーネント内で<div style={style.app}>などして指定している。(App.js参照)

組織が裁量労働制を導入するためには何をしなければならないか

3行でまとめると

裁量労働制の導入には時間がかかるというポエム

TL;DR

9時18時のフルタイムが働き方が定着した組織で本気で裁量労働制を導入したいならば、段階的に導入する他無い。
今までフルタイムだった組織が突然裁量労働制を採用したところで、必要な文化が培われておらず容量のつかめていない雇用者や労働者は困惑し、結局いつも通りの働き方をし続けることは間違い無しだ。
これはウォーターフォールに慣れたチームが上司の命令でアジャイルを導入しても、結局ウォーターフォールで開発してしまうことと同じだ。さらにこの、誰も裁量労働できていないが形式的には裁量労働制の環境が続くと、雇用者も味をしめて定額働かせ放題の環境を作り上げる。これは上司が「アジャイルだから納期短く出来るよね」と言ってくるのと同じだ。

多くの組織にとって自由な働き方を可能としない原因として、リモートで働く環境が整っていない点が挙げられる。これは例えば、書類での承認手続き、face to faceしか認めない文化、VPNでアクセスできない社内サーバーなど。裁量労働制を導入するためには、まずはこの障壁となる文化を破壊していかなければならない。

もし組織が裁量労働制を導入したいと考えているなら、まずは先にコアタイム付きのフレックスタイム制を導入するべきだ。これは裁量労働制より自由ではないが、労働者にはある程度の自由と裁量が与えられる。なにより、きちんと残業代が支払われるのもフレックスタイム制の良いところだ。この制度で働きながら、前述した、障壁となる文化を破壊していく。

ある程度フレックスタイム制が定着し、雇用者が労働者の裁量を認められるようになり、いくつかの文化を破壊できたならば、次はフレックスタイム制のまま、新たな環境を整えるフェーズに入る。それにはまず、リモートワークを導入できる環境を目指すことが良い。リモートワークを可能にするには、遠隔でも情報共有できるツールの導入、遠隔でもコミュニケーションを取るためのツールの導入が必要不可欠になる。

この段階で終了しても良いが、最終的に裁量労働制を考えているのなら、このままフレックスタイム制の中でリモートワークを導入するべきだ。この時点でもほとんど裁量労働ではあるが、前述したように、残業代はきちんと支払われる。そして、同じ時間に働くという一体感はまだ多少残っている。
この段階では、ツールの導入やコミュニケーションの練習と共に、お互いの休憩と成果を認める文化を培っていきたい。給与は時間ではなく、成果に支払われるべきだ。ここで言う成果とは、コードの行数ではなく、利益貢献度である。

そして、全ての業務がリモートワークで可能になり、雇用者だけでなく労働者同士でお互いの裁量を認め合える文化を培った上で、初めて裁量労働制を取り入れることができる。9時18時のフルタイムで働かせている組織でこの工程を踏まずに裁量労働制へ切り替えると、間違いなく失敗する。裁量労働制とは、気軽に導入できる制度ではないのだ。

終わりに

裁量労働制を導入するために、前提としてリモートワークで働ける環境が存在しなければならない。その環境を整えるために、まずはフレックスタイム制で出社しつつリモートワークで利用できるツールや制度を決めたり、作るべきだ。これには多大な時間を要するだろうが、いきなり裁量労働制を採用するのは絶対にやめよう。

結局結局、はてなブログに帰ってきた。

沢山のブログを作っては爆破し、作っては爆破してきましたが、もう2度とブログを爆破せず、今後はこのはてなブログを利用し続けることを誓います。