React/Reduxのスターターキットを公開している
React/Reduxビギナーのための、React/Reduxスターターキットを公開しているという記事。当初は最小限の機能で1ページのReduxアプリを作成するためのスターターキットを目指していたのだが、現在のSPA需用もありルーティングなどを追加した。
中身としては単純に、 react-create-app コマンドで作成したReactアプリにReduxを組み込んだ形。 package.json を見ると、追加したパッケージは基本的なReact/Redux関連のパッケージとコード整形系。webpackなど多くの部分は react-scripts に依存している。
- react
- react-dom
- react-redux
- react-router-dom
- react-scripts
- redux
- redux-logger
- redux-thunk
- eslint
- eslint-config-prettier
- eslint-plugin-import
- eslint-plugin-prettier
- eslint-plugin-react
- eslint-plugin-react-redux
- prettier
ディレクトリ構造
ActionやReducerは専用のディレクトリやファイルに分けるのではなく、依存し合うそれぞれを1つのモジュール単位として、1つのファイルで管理する手法を採用している (Ducks proposalと呼ばれてる?) 。これを採用するため、ducks-modular-reduxを参考にした。
. ├── public # 静的ファイル ├── src # アプリのソースコード │ ├── index.js # main render │ ├── reducers.js # combine Reducers │ ├── registerServiceWorker.js # Offline cache https://goo.gl/KwvDNy │ ├── shareComponents # share Components │ │ └── Header.js # page header │ ├── utils # convenient things │ │ ├── logo.svg # React icon │ │ ├── consts.js # your ENV │ │ └── injectStyle.js # you can use `@keyframes` │ └── app # application main sources │ ├── App.js # application routing │ ├── home # [home] `localhost:3000/` │ │ ├── index.js # [home] main Container │ │ └── Home.js # [home] main Component │ └── todo # [todo] `localhost:3000/todo` │ ├── index.js # [todo] main Container │ ├── Home.js # [todo] main Component │ ├── components # [todo] Components │ ├── containers # [todo] Container Components │ └── modules # [todo] main action logic files (include in `Action`, `Reducer`, `Action Creator`) │ ├── reducers.js # [todo] combine Reducers │ ├── todos.js # [todo] todo module │ └── todos.spec.js # [todo] todo module unit test └── LICENSE # License is 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 };
}
組織が1から裁量労働制を導入するためにしなければならないこと
裁量労働制の導入にはそれなりの時間を要するというポエム。
TL;DR
9時18時フルタイムの働き方が定着した組織で、本気で裁量労働制を導入しようと考えるなら段階的に導入していく他無い。
今までフルタイムだった組織が突然裁量労働制を採用したところで、必要な文化が培われておらず容量のつかめていない雇用者や労働者は困惑し、結局いつも通りの働き方をし続けることは間違い無しだ。
これはウォーターフォールに慣れたチームが上司の命令でアジャイルを導入しても、結局ウォーターフォールで開発してしまうことと同じだ。さらにこの、誰も裁量労働できていないが形式的には裁量労働制の環境が続くと、雇用者も味をしめて定額働かせ放題の環境を作り上げる。これは上司が「アジャイルだから納期短く出来るよね」と言ってくるのと同じだ。
多くの組織にとって自由な働き方を可能としない原因として、リモートで働く環境が整っていない点が挙げられる。これは例えば、書類での承認手続き、face to faceしか認めない文化、VPNでアクセスできない社内サーバーなど。裁量労働制を導入するためには、まずはこの障壁となる文化を破壊していかなければならない。
もし組織が裁量労働制を導入したいと考えているなら、まずは先にコアタイム付きのフレックスタイム制を導入するべきだ。これは裁量労働制より自由ではないが、労働者にはある程度の自由と裁量が与えられる。なにより、きちんと残業代が支払われるのもフレックスタイム制の良いところだ。この制度で働きながら、前述した、障壁となる文化を破壊していく。
ある程度フレックスタイム制が定着し、雇用者が労働者の裁量を認められるようになり、いくつかの文化を破壊できたならば、次はフレックスタイム制のまま、新たな環境を整えるフェーズに入る。それにはまず、リモートワークを導入できる環境を目指すことが良い。リモートワークを可能にするには、遠隔でも情報共有できるツールの導入、遠隔でもコミュニケーションを取るためのツールの導入が必要不可欠になる。
この段階で終了しても良いが、最終的に裁量労働制を考えているのなら、このままフレックスタイム制の中でリモートワークを導入するべきだ。この時点でもほとんど裁量労働ではあるが、前述したように、残業代はきちんと支払われる。そして、同じ時間に働くという一体感はまだ多少残っている。
この段階では、ツールの導入やコミュニケーションの練習と共に、お互いの休憩と成果を認める文化を培っていきたい。給与は時間ではなく、成果に支払われるべきだ。ここで言う成果とは、コードの行数ではなく、利益貢献度である。
そして、全ての業務がリモートワークで可能になり、雇用者だけでなく労働者同士でお互いの裁量を認め合える文化を培った上で、初めて裁量労働制を取り入れることができる。9時18時のフルタイムで働かせている組織でこの工程を踏まずに裁量労働制へ切り替えると、間違いなく失敗する。裁量労働制とは、気軽に導入できる制度ではないのだ。
終わりに
裁量労働制を導入するために、前提としてリモートワークで働ける環境が存在しなければならない。その環境を整えるために、まずはフレックスタイム制で出社しつつリモートワークで利用できるツールや制度を決めたり、作るべきだ。これには多大な時間を要するだろうが、いきなり裁量労働制を採用するのは絶対にやめよう。
結局結局、はてなブログに帰ってきた。
ブログを作っては爆破、作っては爆破してきましたが、もう2度とブログを爆破せず、今後はこのはてなブログを利用し続けることを誓います。
