休み明け用メモ

レビュー指摘が多くてリリースが遅れることを「プランニングで決めなかったから」と言われて、そうはならんやろと思ったので考えをまとめておく

じゃないと休みの間中考えてしまいそう

まず、プランニングで決めなかったからと言って明らかに負債になるコードをマージするのはよくない（特に緊急な課題でもないし）

なぜプランニングで漏れたのか
→このくらいなら理解してると思ったから？

そもそもレビュー指摘されないようなコードを最初から書いてレビューに出せばいいのでは？
→このくらいは自分で考えて到達してほしいと思うが、それを各自の努力に委ねることはできない（博打と一緒だから。趣味ならともかく仕事である以上、品質・納期は守れるように努力するべき）*1
→まずこのレベルから予め周知しておく必要があるレベルであることを認識する

アクション？
→プランニングで逐一何をどこに書くか決める？
→どのようなことをどこに書くのかの方針を先に共有する？

お気持ち
→苛立ちが発生するということはそこに問題がありそうということなのでそれはいいけど苛立ちをそのままぶつけるのは勘弁してほしい
→ぶつけられる側もしんどいし、ぶつけたからといって問題は何も解決しないので

*1:個々人だけのやり方だと効率が良かったり良くなかったり本人の資質みたいなところもある。だから少なくとも仕事で使う部分は仕事中に担保したいというお気持ち

フロントエンドとバックエンドをチーム分けするのは合理的なのか

11月からプロジェクトが変わって、引き続きReactNativeでアプリ開発する仕事をしてるわけですが、今回のプロジェクトもアプリ側（フロントエンド）チームとサーバーサイド（バックエンド）を分けるチーム構成で進めている。

一つ前のプロジェクトもそうやってチームを分けていたけど、イマイチしっくりこないというか無駄が多かったなと感じたので書き残しておく。
フロント/バックの分け方としてはこんな感じ。

• フロント/バックでリポジトリは別
• それぞれのチームのみレビュー（承認）権限がある
• それぞれのチームのタスクのみを担当する

個人的にはフロントとバックが分かれていることで余計な作業が発生しているように感じている。少なくとも（アプリの大部分を占める）単純な機能についてはそう思う。

例えばバックエンドからユーザー情報を取得してその内容を画面に表示するようなユーザー詳細画面を作るとする。
フロント側は画面のレイアウトを、バックエンド側はユーザー情報を返すAPIをそれぞれ作ることになると思う。（既にフロント↔バック間の通信の仕組みは出来ているとする）

フロント側はAPIができていないのでまずはモックあるいはダミーデータで画面を作ることになる。
これらは最終的に消されることになるのでまずコレが無駄。

次にいざ結合してみると様々な問題が発生する。
例えば、

• 表示に必要なデータが取得されていない
• データの型が決まっていない（stringなのかnumberなのか）
• データがないときはnullなのか空文字なのか

ひとつひとつはもちろん大したことじゃないしすぐ直せる。

…と思うだろうけどフロント/バックが分かれている時の修正の流れはこう。

1. 修正してもらう
2. バックエンドチーム内でレビュー（指摘したフロントエンドの人はレビュー権限なし）
3. マージ・デプロイ
4. フロントとの結合再確認

フロントエンドの人にレビュー権限ないからバックエンドチーム内で更に別の人にレビューしてもらう時間を取る必要があるし、もしも修正方針のコミュニケーションがうまくいってなかったらもう一度このやり取りをする羽目になる。

そこはしっかりコミュニケーション取って決めておくところだろとかというのはごもっともだけど、経験則になってしまうけどそれでもやっぱり漏れや認識のズレは発生するしほとんどの人は「ちょっと言って直してもらえばいいことでしょ」と思っていると思う（実際は待ちの時間がかなり発生するわけだが）

とはいえ、たとえチーム分けをしない形にしたとしてもフロント/バックそれぞれのアーキテクチャとかについてはそれぞれの分野で得意な人・できる人がやる感じになっていくだろうし、ある時点ではスキル・知識的にフロント/バックどっちかのタスクをやることが多くなることもあると思うけどそれは別に構わないと思う。価値を届けられないよりはずっといい。

実際、今のプロジェクトはバックエンドが遅れ気味になった*1ためフロントチームの自分とかもバックエンドの機能実装をするようになっている。

1機能がフロント、バックエンドそれぞれの結合で完成するものならそれを分割するのはそれだけコストがかかることだなと感じた。

世の中ではこうやってチーム分け事例がたくさん紹介されているので、こういう問題をどう対処しているのかとても気になるところ。

*1:アーキテクチャ周りの調査が多かったとか、稼働の問題とかもあるけど

炎上プロジェクトに放り込まれて感じたこと

前回からの続きです。

何回も書き直してぐしゃぐしゃになってしまったけどとりあえず公開する。
振り返り的なことは別記事で書く。

まとめようと思ったけどうまくいかなかったので、あくまで自分視点で感じたことを書いていこうと思います。

中には自分がうまく理解できていないだけだったり単に能力不足だったりというのもあるかも知れません。

React + Sinatraを試してみた

経緯

ポートフォリオはクライアントサイドだけで作ったのでサーバサイドと連携したものも試してみたいなと思った。

以前サイゼリヤ1000円作ったときにSinatraが手軽でいいなと思ったので、SinatraでAPI作ってReact（というよりはaxios）で叩くことを試してみた。

SinatraでJSONを返すAPI作成

require 'sinatra'

before do
  response.headers['Access-Control-Allow-Origin'] = '*'
end

get '/' do
  content_type :json
  { key1: 'value1', key2: 'value2' }.to_json
end

たったこれだけ！超短い。
CORS設定しないとネットワークエラーになってしまう。CORSについては別の機会にちゃんと勉強する（勉強するとは言ってない）

axiosで叩いて表示

import React from "react"
import "./App.css"
import axios from "axios"

class App extends React.Component {
  state = {
    key1: "",
    key2: ""
  }

  handleClick = async () => {
    try {
      const response = await axios.get("http://localhost:4567/")
      const data = response.data
      this.setState({ key1: data.key1, key2: data.key2 })
    } catch (e) {
      alert(e)
    }
  }

  render() {
    return (
      <div className="App">
        <button style={{ width: 200, height: 35 }} onClick={this.handleClick}>
          Sinatra呼び出し
        </button>
        <p>{this.state.key1}</p>
        <p>{this.state.key2}</p>
      </div>
    )
  }
}

export default App

クライアント側。ボタンをクリックしたらaxiosでSinatraからJSONを取得して、結果をstateに入れて表示する。それだけ。

state = {
  key1: "",
  key2: ""
}

stateの中身について上記のコードかconstructorかで宣言してあげないとkey1なんてないよと怒られてビルドできない。

所感

CORSのところと上記のstate周りでちょっとハマったけど、予想通りとても簡単にできた。素晴らしい。

ソース

github.com

React + Material-UIでポートフォリオサイト作った

仕事でReact（正確にはReact Native）を使っているのでお勉強がてらポートフォリオサイトを作った。

iteduki.github.io

案外さっくり作れたつもりだったけどコミット履歴を見ると10日はかかった模様。
平日1日1時間程度+休日なのでだいたい15時間程度くらいだろうか。

まずはいろんなポートフォリオサイト見て回ってコンテンツをひねり出し、さらに最初の1,2日はTypescriptわからん、Material-UIわからんという感じで格闘していた気がする。
Material-UIを選んだのはcssフレームワークの中で、前職辞める直前に一瞬React触ったときに使ってたような気がするなというだけで選んだ（本当に使っていたかは定かではない）

実際に作ってみて、cssの知識全然足りないなって思った。
やろうとしたレイアウトがうまくできなくて諦めて変えるみたいなことをしていた。仕事では許されないやつ。css勉強せねば…。

まだデザインとかほぼ素のままなのでもう少しいじってみるつもり。
それとgh-pagesだと毎回deployめんどいのでCIにしたい（明らかに先にやっとくべき事案）

ただ、なんだかんだ言って慣れてしまえば結構書きやすいなと思った。redux使ってないとかはあるけどｗ

あと、Typescriptはコンパイル時点でエラーがあると教えてくれるのは便利だなと思った。JSだと実行したときにタイポに気づくとか日常なので。

それにしても、2019年にもなってなんで自分のWebサイト作ってるんだろうなぁなんて思ったのでしたｗ

Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門

炎上プロジェクトに放り込まれて1ヶ月でやったこと

6月の頭、これまで携わっていた仕事が唐突になくなってしまいメンバーがそのまま別のプロジェクトに放り込まれることになった。

1ヶ月経ってようやくプロジェクトがなんとか進み始めた（ように見える）のでやったことを書いておく。無事に着地できるといいな…。

意識合わせ

まず自分たちが入った時点でプロジェクトの仕様を把握できている人が誰もいなかった（恐ろしいことに…）

既存メンバー同士でも理解がズレていることが散見されたので、1週間かけて全員が仕様をきちんと理解+意識合わせするということを行った。

実行環境づくり

認識があっていなかった中にはインフラ環境も含まれていて、それもあって開発者が実行できる環境がなかったのでまずはこれを作ってもらうことにした。
これを決めるとき、ヘルプで投入されたCTOからかなり的確なアドバイスをもらえてCTOすごいって思った（小並感）。やっぱ経験が物を言う部分ってあるよね。

チーム分け

自分たちがやるべき部分を明確にするためにアプリ、インフラ、サーバチームに分けた。早さを優先するためでもある。
これまでは全員がそれぞれの部分に対してレビューとかしていたけど、その負担で本来やらなければならない部分が遅くなるということが起こってしまっていたので。

意識付け

最初の目標は「実行環境作って1機能がちゃんと作れることを確認するということ」とした。
いざスタートしてみるも、いきなりうまくいくはずもなく。

チーム分けたにもかかわらず別チームのプルリクレビューにバンバン入ってきてたりしたので、それは明示的に「こっちにはかかわらず本来のチームの仕事に集中してほしい」と伝え、それぞれがやることとやらないことを明確にした。

本人は良かれと思ってやってくれていることだけど、結局そこが遅れると全体として遅れる結果になってしまうので…。

コミュニケーションの場作り

チームを分けたことでチーム間での意思疎通ができていない（お互いに向こうから聞いてくるだろうと思っている）ことも発覚する。

リーダー間の話し合いでコミュニケーションを取る必要があるだろうということになって週3で全員での進捗確認の場を設けることにした。
表向きは進捗確認だけど、真の目的は顔つき合わせて進捗を話させることでコミュニケーションを強制的に発生させることである。スクラムでいう朝会みたいな。

これまでの様子を見ていると、決めごとは誰かが決めてくれていたっていう人が多く*1こうやって強制的にでも話す機会を作らないといつまで経っても話が進まないという感じだったので。

このタイミングで別チームに確認したいことを出させたり、各自が思い込みで進めて認識がズレていた部分を合わせられるようになった。

朝会（14時）

上記の進捗確認とは別に、自分のチームは毎日朝会をすることにした。
ただしみんなちょくちょく寝坊するので14時から。「朝」とは。

先述の意識付けの一環として、まず昨日やったことに対してどうしてそれをやったのかを確認することにした。
最初の1週間、見ていると作業をするためにタスクを切るという本末転倒なことをしていたので、作業はタスクを完了するためにするものということを意識してもらうようにした。

これは前のスクラムマスターに教えてもらったことだけど、改善すべきことはそれぞれの人が無意識にやっていることにあるのでそこを明らかにしなければならない。
問題を改善するにはまず問題を認識するところから。そして無意識にやっているということは再現性も高い。だからその無意識にやっている理由を明確にすることが必要になる。

メンバーがこれを意識できるようになったかはわからないけど、勝手に作業をせずやる前に確認したり聞きに来てくれるようになった。

次に不要不急のリファクタリングを禁止にした。
単純に時間がないのと、リファクタ案が出ても上記の通りいつまで経っても決められず*2放置されるプルリクが散見されたので。

プルリクもこの時間で一通り見ることにした。
これはどっちかというとまだ技術部分をキャッチアップできてない自分のためにという側面もある。
全員の前で説明してもらって、動かしてみて、問題なさそうと全員が納得したならマージしていくというスタイル。

正解がわからないところで悩んで時間を使うよりは試してみてうまくいかなかったときに対応したほうが良さそうという判断。

今後の課題

自分の課題として上記の通りまだ技術部分のキャッチアップができてないこと。
既存メンバーは進捗は出てなかったとはいえ技術検証や学習はきっちりやってたみたいで、決めたタスクに対する作業はとても早い。
自分がチームリーダー的ポジションとして開発以外の雑用（割と差込み仕事多い）を引き受けてる間に朝会で自分がやるって言ってた分まで片付けてくれてる。

自分の知識がつかないことやこの先のことに対して結構恐怖があるけど、ひとまず今は炎上プロジェクトに対して自分ができることで貢献できればいいか…と思って自分を納得させている状態。

無事に着地できるといいな…（2回目）

SCRUM BOOT CAMP THE BOOK

*1:割と経験浅めなメンバーで構成されていたため

*2:今回使ってるReactNativeの経験者がプロジェクト内にいないので誰も作法の正解を知らない

サイゼリヤ1000円をRubyでざっくり作ってみた

qiita.com

サイゼリヤ1000円ガチャがバズっていたので自分でも練習として作ってみた。
github.com

フレームワークはSinatraにしてみた。 初めて使ったけど爆速でWebアプリが動いてすごい。
ときどき、Railsはオーバースペックみたいに言われるのがちょっとわかった気がした。

sqliteをActiveRecordで使う方法とかいろいろ調べながらやったけどそれでもここまで2時間かかってないと思う。
最小限のファイルしかいらないので見通しもいいし、ちょっとしたものなら本当にこれで良さそう。


あとはデザインか…（絶望）
デザインは1時間くらい悩んだ後とりあえず本家と全く同じにしました（何
デザインできる人ほんとすごい。

書いたコードと本家コードを見比べてみてかなり簡潔にコードを書けた気がする。
もちろん本家コードはプログラミング初学者（当時）が書いたものだし、フレームワークも言語も違うんだからそこでマウント取ろうとかそういう気持ちはまったくないんだけど、自分もガチ初心者だった頃より少しはマシになれたのかもなぁと思った。

参考にしたサイト
Sinatra＋ActiveRecord＋SQLite3で，軽量なWeb-DB連携例tamosblog.wordpress.com

はじめてのRuby Sinatra入門: 軽量RubyフレームワークSinatraとPaizaCloudを使って10分でWebサービスを作る