いてづきブログ

情シスでやってみたことの備忘録

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

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

 

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

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

 

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

 

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

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

 

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

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

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

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

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

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

 

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

 

 

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

 

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

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

 

 

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

 

 

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

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

前回からの続きです。

 

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


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

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

 

  • 散逸する情報
  • 知らない仕事が降ってくる
  • 技術以外興味がないメンバー
  • 上司に怒られる(のではないか)ということへの恐怖
  • デザイナーとの意思疎通が辛い
  • 協力会社のマネージメント

 

続きを読む

React + Sinatraを試してみた

経緯

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

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

SinatraJSONを返す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使ってないとかはあるけどw

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

 

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

 

 

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

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

 

 

 

 

 

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

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

 

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

意識合わせ

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

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

 

実行環境づくり

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

 

チーム分け

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

 

意識付け

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

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

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

 

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

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

 

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

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

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

 

朝会(14時)

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

 

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

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

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

 

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

 

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

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

 

今後の課題

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

 

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

 

無事に着地できるといいな…(2回目)

 

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

 

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

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

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

qiita.com

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

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

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


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

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

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

ターミナルでよく使うショートカット備忘録

GWが明けたらiTerm2のショートカットを完全に忘れていたので備忘録を兼ねて書く。

iTermのショートカット

  • Cmd + d
    • 横分割
  • Cmd + shift + d
    • 縦分割
  • Cmd + ],Cmd + [
    • 前後のパネルに移動
  • Cmd + opt(alt) + i
    • 現在のタブのすべてのパネルに同時入力(Broadcast Input to All Panes in Current Tab)

iTermを使い始めた理由は最後の複数タブ同時入力のため。
普段はVSCode内のターミナルで作業しているのでリリースなどでサーバーにsshするときしか使っていない。

ターミナルのショートカット

  • ctrl + w
    • 単語一個分消去
  • ctrl + l
    • 現在のカーソル行を一番上に(clearと同じ)
    • Cmd + kでも同じようなことができるがiTermで同時入力してるときはCurrent Paneしか消えない
  • ctrl + u, ctrl + k
    • カーソルより前/後を全削除

あとは、普段fishを使っているので以前に入力したコマンドはで補完入力されたりする。
fishもとりあえず入れただけで使いこなせてないのでもう少し調べて使いこなしたい。