ジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと家族と共に流れ着き、ベルリンのスタートアップで働くソフトウェアエンジニアの日記

React Router v4: react-router-domを使って動かす超シンプルな例

React Router はv3からv4になると大きな変更が入っている。v3のコードのままReact Router をv4にするとまったく動かなくなって結構ハマりがちなので超シンプルなデモを作ってみた。

【デモ】
Rails 5 の上にReactを乗せてreact-router-domを使っている例
https://react-router-dom.herokuapp.com/

リンク押したらヘッダーはそのままで下部のページが切り替わる。ただそれだけのデモ
f:id:tango_ruby:20170622034159p:plain

バージョン

    "react-router-dom": "^4.1.1",
    "react": "^15.6.1",


まず大前提としてReact Routerはv4 で3つに別れた。その3つとはreact-router、 react-router-dom、 react-router-native。
react-routerは残りの2つのコアになる機能をまとめたもの。webの場合はreact-router-domから、nativeはreact-router-nativeからインポートする。

今回はウェブなのでreact-router-domとした。
インストールの方法

npm install --save react-router-dom

インポートのコード事例

import React from 'react';
import ReactDOM from 'react-dom';
import {
  BrowserRouter,
  Route,
  Switch,
  Link
} from 'react-router-dom';

<BrowserRouter>

まずはルーターの設定をする。ルーターは2種類あって<BrowserRouter>と<HashRouter>。
<BrowserRouter>はダイナミックなリクエストを制御するサーバーがある場合。<HashRouter>は静的なファイルのみを扱う場合。
今回は特に意味もなくRailsをバックエンドに使っているので<BrowserRouter>とした。

ReactDOM.render((
  <BrowserRouter>
    <App />
  </BrowserRouter>
), document.getElementById('app'))

<App>

メインの画面構成を<Header>があって、その下に<Main>とした。

const App = () => (
  <div>
    <Header />
    <Main />
  </div>
)

<Link>

<Link>はリンクをクリックした際にページをリロードせずにレンダーするコンテンツ表示を変更させる仕組みを提供する。なので<Header>はこのようになる。

const Header = () => (
  <header>
    <nav>
      <ul>
        <li><Link to='/'>Home</Link></li>
        <li><Link to='/page_a'>Page A</Link></li>
        <li><Link to='/page_b'>Page B</Link></li>
      </ul>
    </nav>
  </header>
)

<Switch>

<Switch>で<Main>内の表示を切り替える。

const Main = () => (
  <main>
    <Switch>
      <Route exact path='/' component={Home} />
      <Route path='/page_a' component={PageA} />
      <Route path='/page_b' component={PageB} />
    </Switch>
  </main>
)

後はPageAとBを作ればできあがり。まー書き方を少し変える必要がありますよ、というのが結論になる。

こんな記事書かなくてもここ見たら全部書いてる訳であんまり意味ないかな、と思ったがせっかく書いたので公開することにした。

全てのコード

import React from 'react';
import ReactDOM from 'react-dom';
import {
  BrowserRouter,
  Route,
  Switch,
  Link
} from 'react-router-dom';

const App = () => (
  <div>
    <Header />
    <Main />
  </div>
)

const Header = () => (
  <header>
    <nav>
      <ul>
        <li><Link to='/'>Home</Link></li>
        <li><Link to='/page_a'>Page A</Link></li>
        <li><Link to='/page_b'>Page B</Link></li>
      </ul>
    </nav>
  </header>
)

const Main = () => (
  <main>
    <Switch>
      <Route exact path='/' component={Home} />
      <Route path='/page_a' component={PageA} />
      <Route path='/page_b' component={PageB} />
    </Switch>
  </main>
)

const Home = () => (
  <div>
    <h1> Home!!!!! </h1>
  </div>
)

const PageA = () => (
  <div>
    <h1> Page A!!!!! </h1>
  </div>
)

const PageB = () => (
  <div>
    <h1> Page B!!!!! </h1>
  </div>
)

ReactDOM.render((
  <BrowserRouter>
    <App />
  </BrowserRouter>
), document.getElementById('app'))

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

「テメー偉そうに」と言われても身の丈レベルでブログ発信する意義が海外在住中のエンジニアはある

日本で活躍中のエンジニアで「海外転職をしたい」とか「海外移住したい」と考える方がいれば、その参考になればと思ってブログを綴っている。すると時々コメント欄なんかで「ちょっと海外に出たからってなに?本当にすげーもん作ってから偉そーに言えよ」みたいなのも来る。
そんな辛辣なコメントを多少受けたとしても「身の丈レベルでブログ発信する意義が海外在住中のエンジニアはあるはず」という話。

身の丈レベルとはこんなの。

  • 一瞬で仕様を理解してコードを完成させてしまう頭のキレるスーパーエンジニアではない
  • ネイティブと遜色なく互角に英語で渡り合えるだけの完璧な語学力がある訳ではない
  • 腐るほど金がある訳ではない

例えば私はイーロン・マスクのインタビュー記事やなにげないツイッターのつぶやきまで全てフォローしている。世界最高峰の頭脳から繰り出される発想を少しでも理解したいからだ。しかしとてもじゃないが「イーロン・マスクの活動に自分も感化されました」なんて気持ちは一切沸かない。

スポーツの中で唯一好きなのはサッカーだけだが、メッシやクリスティアーノ・ロナウドのプレーを見て「今度自分もアレやってみよう」とは思えない。何も分かってないガキじゃないので自分とメッシとがどれぐらい違うのか、の分別ぐらいはある。

どんな世界でもスーパースターの活躍は素晴らしいが、自分に置き換えることはできない。

で、前述の身の丈レベルのブログ発信の話に戻る。私はかつて日本で社畜エンジニアをしながら、海外転職に挑戦するもののことごとくお断りメールをいただいていたことがある。そんな時にスーパーエンジニアのブログはあまり参考にならなかった。どれだけイーロン・マスクをフォローしても「あの天才とオレとは違う感」がどんどん出てきて余計にヘコむ。

あの時期に本当に役に立ったのは自分とそんなにレベルの変わらない日本人オッサンが「なんとか海外の会社に転職しまして、もがきながらやってます」みたいなブログ記事だった。

そういうのは「この人でもできるんならオレだって」と思わせてくれる。失礼を承知で言えばそのブログ主がショボければショボいほど勇気が出る。

だからと言ってブログでわざと自分のショボさをアピールしても情報が歪むだけで有用ではない。どんなにレベルを落としたところでエンジニアとして海外の大都市圏に移住するにはそれなりの英語力と技術力は必須になる。

この辺りを「それなりのレベルは必要。ただし天才でなくてもOk」を発信できるのは私のような身の丈レベルで生き残っている海外在住エンジニアだけだと思っている。それはイーロン・マスクやイチローがどんなに偉大であっても偉大すぎて彼らにはできないことなんだよ、と。

海外に出ようと考えていてそれを阻害するもっとも大きな要因はその人の精神にある。今の時代の海外移住なんて雲を掴むような話な訳が無いし、ちゃんと計画すればほぼ誰でも可能だ。それでもその人自身が「オレきっとイケるわ」と思わなければ、とたんにその海外移住を阻む壁が高くなり、不可能になってくる。せっかく「海外移住かー。やってみたいなー」と思っていて、それを可能にするだけの素養があるのに、そんな根拠の無い精神でチャンスを逃す人がいるのは本当にもったいない。

このブログのように身の丈で「海外でなんとかやってます」というブログがたくさん量産されれば、諦めてしまいがちな人達にとっての海外移住が当たり前になっていくと思っている。

ベルリンのような国際都市で多国籍なエンジニアと共に仕事をしていると世界の国々で「稼げそうなプロジェクト」「おもしろそうなプロジェクト」を目指して国境を越えて人が押し寄せているのが分かる。しかし日本はその流れから取り残されているようだ。実際、私はベルリンのスタートアップでまだ日本人エンジニアに出会ったことが無い。
日本にとどまる選択をする人が大多数であることは百も承知だ。ただ少数派であっても日本を出ようと考えるエンジニアは必ず居るはず。そんな方達が根拠の無い理由で諦めることなく、実行に移して日本がITエンジニアのグローバル化の流れから取り残されないようになって欲しい。

ということでこんな身の丈レベルのブログを参考にしてください。

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法

今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。

プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。

だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。絶対にズレる。

エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな?誰だっけ、それ言ったの?オレじゃねーよ。お前だよ。おめーのその口が『今週中』って言ったんだよ。もう金曜の夜だぜ。どーすんの?どーすんだよ!」とツメてもプロジェクトは1歩も進まない。
逆に「エンジニア様、いつもコード書いていただいてありがとうございます!」と持ち上げても一緒。
ムチでしばいてもアメをぶら下げても、論理的根拠が無い限り工数見積なんてうまくいく訳がない。

こういうことを書くと「だからウォーターフォールはダメ。時代はアジャイルだよ」と言う人が居るけど、私が関わったプロジェクトは全てアジャイルだった。2週間ぐらいの小さな開発プロセスをぐるぐる回していくアレ。アジャイルであっても工数見積は必要だし、PMチームと開発チームの間の認識違いによる言い争いと、大幅な見積もり誤差は絶えなかった。

そこでフィボナッチ工数見積である。

フィボナッチ工数見積の方法

大前提として見積もりミーティングは開発者とPMチーム全員参加。ダラダラするとすごい時間の無駄なのでルーチン化してチャッチャと終わらせる。何度かやると「いつもやってることだし」となって20分から30分ぐらいで終わる。

【1】 実装したい機能をできるだけ細かい単位に切り出して、タスクチケットとして発行する
例:Twitter認証によるユーザー登録機能

【2】バックエンドもしくはフロントエンドなどのタグを付ける。バックエンドとフロントエンドの両方に実装が必要な場合はチケットを2つ用意して、それぞれのタグを付ける。
例:Twitter認証によるユーザー登録機能ーバックエンド、 Twitter認証によるユーザー登録機能ーフロントエンド

【3】全員でそれぞれのチケットに対しての必要工数をフィボナッチ数列でポイントを付ける
2、3、5、8、13、21の数列を使って、最も工数のかかりそうなチケットに21ポイントを、最も少ない工数のチケットに2ポイントをつける。

【4】チケットを優先順位順に並べる。手順3で付けたポイント数とは別に「どれが先に実装されるべき機能か」を基準とした優先順位。

【5】優先順位の上位から最初の開発スプリント(2週間)で完了しそうな分量だけを取り出す。
チーム人数にもよるがだいたい10から20チケットとか。

【6】取り出したチケットを各担当者に割り振る。その後ひたすら開発する。

【7】バグフィックスが出るたびにチケットを発行し、そこにフィボナッチ数のポイントを見積もって付ける。

【8】2週間のスプリントが終わったら、終了したチケットの合計ポイントを数える。
そこで終わってないチケットとその担当者を批判しない。ただ数える。

【9】1に戻って同じ手順を繰り返す。2週間のスプリントが終わったら、また終了したチケットの合計ポイントを数える。

これを何度も繰り返すとそのチームが2週間で処理できる平均速度がポイント数で出る。これがまーまー正確な値になっている。どんなに気合いれて開発してもいきなり速度が2倍になったりしない。
またここで言う平均速度のポイント数とは100ポイントとかの単位であり、決して100人月という意味ではない。そのポイント数はチーム全員で上記の手順を踏んだ上での数値となる。「わがチームが見積もるわがチームの開発スピードポイントです」としか言いようがなく、これが驚くほど正確なのだ。

最初はこれがどれぐらい画期的なアイデアかは気づかなかったが、何度も実践するうちに分かってきたことがいくつかある。

工数を日数で表現しないからこそ出せる正確性

もしチケットに対して「1日でできる仕事だ」とか「3日はかかる仕事」というように日数で表すと、余計な邪念が入って不正確な見積もりになってしまう。見積もりのミーティングは正確性が最も重要なのにどうしてもエゴが入ってしまう。

エンジニアA「これは重いタスクですから4日はかかりますね」
エンジニアB「なに?4日?こんなの1日で十分だろ(オレならできるぜアピール)」
エンジニアA「いえいえ、このタスクの実装に**も含んでいることを考慮に入れてますか?前回Bさんが似たような箇所を実装された時に4日以上かかってましたよ」
エンジニアB「は?テメー喧嘩売ってんのか?」
PM「まーまーそこはAさんもBさんも優秀なので1日でいいじゃないですか」
エンジニアA、B「はい。。。」

これを5とか13という単位の無い数字にすることで余計な邪念を挟む余地が無くなる。単なるポイントであって単位が無いので他との相関で決めるしかなくなる。「あのタスクを5って言ったんなら、これはもうちょっと軽い目だから3かな?」という具合だ。しかもこの時点で誰が担当するかは割り振られてないので、前述のAとBのように「オレだったら1日でできるぜ」などと無駄なアピールをさせなくて住む。

フィボナッチで重いタスクの差を明確に

ポイント数にする場合に1、2、3、..8、9、10と連続した数字ではなくフィボナッチ数列にしているのには理由がある。まず実務においてタスクの重さは指数関数的に伸びていくこと。軽量なタスクはそれほど差はないが重量なタスクにはモノによって大きな差が出ることはエンジニアなら経験則でご理解いただけるはず。
また重くなるにしたがって差を大きくすることでその差をより意識するように仕向けるため。軽いタスクの場合、2や3の差は小さく多少の誤差が出ても大きな影響は無い。見積もりの重要性は重いタスクほどにある。そこで「重いタスクを9かな?それとも10かな?」とじっくり考えても9と10の差は1でしかでなく、9と10の差を意識するのが難しくなる。
ここをフィボナッチにすることで13と21の差はとても大きく、「あれが21だったらこれは13にすべきだろ」と、より明確に区別することが可能になる。

「完成させます!(徹夜で)」が無くなる

全員参加の見積もりミーティングから出された正確な開発スピードポイントは無茶苦茶な開発計画を制御してくれる。誰かがアレもコレも2週間以内にやれー!とやったとしても「いやいやこのポイント数を見てみ。平均速度の3倍だぜ。それ無理だから」と論理的に諭すことができる。「どうしてもその機能を今のスプリントに盛り込みたいんなら、他のコレとコレを削って」と言って、現実的な計画に修正できる。
また逆にエンジニアが「こんなにたくさんのタスクが2週間以内に完了できる訳ねーよ。無理無理!」と言ってきたとしても「いやいやこのポイント数を見てみ。いつもの平均速度と同じだし。なんで今回だけできねーってなるんだよ。雰囲気だけでモノ言ってんじゃねーよ」とこれまた論理的に諭すことができる。
論理が成り立つ手法は感覚的にしかモノを言わない奴をしっかり排除してくれるのだ。
こうして「完成させます!(徹夜で)」という無理ゲーが無くなり、より健康的な開発が可能になっていく。要はチームの開発スピードを全員が(論理的に!)把握しておくことの効果が絶大なのだ。

個人が処理したポイント数を人事評価に結び付けない。

これは重要。工数見積は全てプロジェクトの推進のためであって、人事評価のためにやっている訳ではない。ここに人事評価を結びつけると、ポイント稼ぎのためにやたら軽いタスクに重いポイント数を乗せて、またそのチケットを取り合ったりとロクなことが無い。

以上がフィボナッチ工数見積の概要。

なんか偉そうに紹介してしまったが、特にPM手法に詳しい訳でも専門知識がある訳でもない。全ては同僚のスペイン人プロジェクトマネージャーRの言ってることの受け売り。
Rのバイブルというか超おすすめの本としてAgile Estimating and Planningをいつも紹介されている。
私の意見としては「エンジニアがそんな本を読まなくてもいいように会社は君を雇ってるんじゃないの?」なのだが。とにかくおすすめらしい。

Agile Estimating and Planning (Robert C. Martin Series)

Agile Estimating and Planning (Robert C. Martin Series)

アマゾン.comのレビューでもやたら高評価なのできっといい本なのだろう。
日本語版ならこちら。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

  • 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
  • 出版社/メーカー: 毎日コミュニケーションズ
  • 発売日: 2009/01/29
  • メディア: 単行本(ソフトカバー)
  • 購入: 74人 クリック: 764回
  • この商品を含むブログ (226件) を見る

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com