いてづきブログスマートフォン用の表示で見るいてづきブログ情シスでやってみたことの備忘録2020-01-15フロントエンドとバックエンドをチーム分けするのは合理的なのか雑記11月からプロジェクトが変わって、引き続きReactNativeでアプリ開発する仕事をしてるわけですが、今回のプロジェクトもアプリ側(フロントエンド)チームとサーバーサイド(バックエンド)を分けるチーム構成で進めている。一つ前のプロジェクトもそうやってチームを分けていたけど、イマイチしっくりこないというか無駄が多かったなと感じたので書き残しておく。フロント/バックの分け方としてはこんな感じ。フロント/バックでリポジトリは別それぞれのチームのみレビュー(承認)権限があるそれぞれのチームのタスクのみを担当する個人的にはフロントとバックが分かれていることで余計な作業が発生しているように感じている。少なくとも(アプリの大部分を占める)単純な機能についてはそう思う。バックエンドからユーザー情報を取得してその内容を画面に表示するようなユーザー詳細画面を作るとする。フロント側は画面のレイアウトを、バックエンド側はユーザー情報を返すAPIをそれぞれ作ることになると思う。(既にフロント↔バック間の通信の仕組みは出来ているとする)フロント側はAPIができていないのでまずはモックあるいはダミーデータで画面を作ることになる。これらは最終的に消されることになるのでまずコレが無駄。次にいざ結合してみると様々な問題が発生する。表示に必要なデータが取得されていないデータの型が決まっていない(stringなのかnumberなのか)データがないときはnullなのか空文字なのかひとつひとつはもちろん大したことじゃないしすぐ直せる。...と思うだろうけどフロント/バックが分かれている時の修正の流れはこう。修正してもらうバックエンドチーム内でレビュー(指摘したフロントエンドの人はレビュー権限なし)マージ・デプロイフロントとの結合再確認フロントエンドの人にレビュー権限ないからバックエンドチーム内で更に別の人にレビューしてもらう時間を取る必要があるし、もしも修正方針のコミュニケーションがうまくいってなかったらもう一度このやり取りをする羽目になる。そこはしっかりコミュニケーション取って決めておくところだろとかというのはごもっともだけど、経験則になってしまうけどそれでもやっぱり漏れや認識のズレは発生するしほとんどの人は「ちょっと言って直してもらえばいいことでしょ」と思っていると思う(実際は待ちの時間がかなり発生するわけだが)とはいえ、たとえチーム分けをしない形にしたとしてもフロント/バックそれぞれのアーキテクチャとかについてはそれぞれの分野で得意な人・できる人がやる感じになっていくだろうし、ある時点ではスキル・知識的にフロント/バックどっちかのタスクをやることが多くなることもあると思うけどそれは別に構わないと思う。価値を届けられないよりはずっといい。実際、今のプロジェクトはバックエンドが遅れ気味になった*1ためフロントチームの自分とかもバックエンドの機能実装をするようになっている。1機能がフロント、バックエンドそれぞれの結合で完成するものならそれを分割するのはそれだけコストがかかることだなと感じた。世の中ではこうやってチーム分け事例がたくさん紹介されているので、こういう問題をどう対処しているのかとても気になるところ。何回も書き直してぐしゃぐしゃになってしまったけどとりあえず公開する。振り返り的なことは別記事で書く。まとめようと思ったけどうまくいかなかったので、あくまで自分視点で感じたことを書いていこうと思います。中には自分がうまく理解できていないだけだったり単に能力不足だったりというのもあるかも知れません。React経緯ポートフォリオはクライアントサイドだけで作ったのでサーバサイドと連携したものも試してみたいなと思った。以前サイゼリヤ1000円作ったときにSinatraが手軽でいいなと思ったので、SinatraでAPI作ってReact(というよりはaxios)で叩くことを試してみた。}.to_jsonendたったこれだけ!超短い。CORS設定しないとネットワークエラーになってしまう。Appクライアント側。ボタンをクリックしたらaxiosでSinatraからJSONを取得して、結果をstateに入れて表示する。""}stateの中身について上記のコードかconstructorかで宣言してあげないとkey1なんてないよと怒られてビルドできない。所感CORSのところと上記のstate周りでちょっとハマったけど、予想通りとても簡単にできた。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だと実行したときにタイポに気づくとか日常なので。Material-UIでポートフォリオサイト作ったTweet広告を非表示にするもっと読むコメントを書く2019-07-07炎上プロジェクトに放り込まれて1ヶ月でやったこと日記6月の頭、これまで携わっていた仕事が唐突になくなってしまいメンバーがそのまま別のプロジェクトに放り込まれることになった。1ヶ月経ってようやくプロジェクトがなんとか進み始めた(ように見える)のでやったことを書いておく。無事に着地できるといいな...。意識合わせまず自分たちが入った時点でプロジェクトの仕様を把握できている人が誰もいなかった(恐ろしいことに...)既存メンバー同士でも理解がズレていることが散見されたので、1週間かけて全員が仕様をきちんと理解+意識合わせするということを行った。実行環境づくり認識があっていなかった中にはインフラ環境も含まれていて、それもあって開発者が実行できる環境がなかったのでまずはこれを作ってもらうことにした。これを決めるとき、ヘルプで投入されたCTOからかなり的確なアドバイスをもらえてCTOすごいって思った(小並感)。経験が物を言う部分ってあるよね。チーム分け自分たちがやるべき部分を明確にするためにアプリ、インフラ、サーバチームに分けた。早さを優先するためでもある。これまでは全員がそれぞれの部分に対してレビューとかしていたけど、その負担で本来やらなければならない部分が遅くなるということが起こってしまっていたので。意識付け最初の目標は「実行環境作って1機能がちゃんと作れることを確認するということ」とした。いざスタートしてみるも、いきなりうまくいくはずもなく。チーム分けたにもかかわらず別チームのプルリクレビューにバンバン入ってきてたりしたので、それは明示的に「こっちにはかかわらず本来のチームの仕事に集中してほしい」と伝え、それぞれがやることとやらないことを明確にした。本人は良かれと思ってやってくれていることだけど、結局そこが遅れると全体として遅れる結果になってしまうので...。コミュニケーションの場作りチームを分けたことでチーム間での意思疎通ができていない(お互いに向こうから聞いてくるだろうと思っている)ことも発覚する。リーダー間の話し合いでコミュニケーションを取る必要があるだろうということになって週3で全員での進捗確認の場を設けることにした。表向きは進捗確認だけど、真の目的は顔つき合わせて進捗を話させることでコミュニケーションを強制的に発生させることである。スクラムでいう朝会みたいな。これまでの様子を見ていると、決めごとは誰かが決めてくれていたっていう人が多く*1こうやって強制的にでも話す機会を作らないといつまで経っても話が進まないという感じだったので。このタイミングで別チームに確認したいことを出させたり、各自が思い込みで進めて認識がズレていた部分を合わせられるようになった。朝会(14時)上記の進捗確認とは別に、自分のチームは毎日朝会をすることにした。みんなちょくちょく寝坊するので14時から。先述の意識付けの一環として、まず昨日やったことに対してどうしてそれをやったのかを確認することにした。最初の1週間、見ていると作業をするためにタスクを切るという本末転倒なことをしていたので、作業はタスクを完了するためにするものということを意識してもらうようにした。これは前のスクラムマスターに教えてもらったことだけど、改善すべきことはそれぞれの人が無意識にやっていることにあるのでそこを明らかにしなければならない。問題を改善するにはまず問題を認識するところから。無意識にやっているということは再現性も高い。その無意識にやっている理由を明確にすることが必要になる。メンバーがこれを意識できるようになったかはわからないけど、勝手に作業をせずやる前に確認したり聞きに来てくれるようになった。次に不要不急のリファクタリングを禁止にした。単純に時間がないのと、リファクタ案が出ても上記の通りいつまで経っても決められず*2放置されるプルリクが散見されたので。プルリクもこの時間で一通り見ることにした。これはどっちかというとまだ技術部分をキャッチアップできてない自分のためにという側面もある。全員の前で説明してもらって、動かしてみて、問題なさそうと全員が納得したならマージしていくというスタイル。正解がわからないところで悩んで時間を使うよりは試してみてうまくいかなかったときに対応したほうが良さそうという判断。自分の課題として上記の通りまだ技術部分のキャッチアップができてないこと。既存メンバーは進捗は出てなかったとはいえ技術検証や学習はきっちりやってたみたいで、決めたタスクに対する作業はとても早い。自分がチームリーダー的ポジションとして開発以外の雑用(割と差込み仕事多い)を引き受けてる間に朝会で自分がやるって言ってた分まで片付けてくれてる。自分の知識がつかないことやこの先のことに対して結構恐怖があるけど、ひとまず今は炎上プロジェクトに対して自分ができることで貢献できればいいか...と思って自分を納得させている状態。19:00炎上プロジェクトに放り込まれて1ヶ月でやったことTweet広告を非表示にするもっと読むコメントを書く2019-05-17サイゼリヤ1000円をRubyでざっくり作ってみたRubyqiita.comサイゼリヤ1000円ガチャがバズっていたので自分でも練習として作ってみた。github.comフレームワークはSinatraにしてみた。使ったけど爆速でWebアプリが動いてすごい。ときどき、Railsはオーバースペックみたいに言われるのがちょっとわかった気がした。sqliteをActiveRecordで使う方法とかいろいろ調べながらやったけどそれでもここまで2時間かかってないと思う。最小限のファイルしかいらないので見通しもいいし、ちょっとしたものなら本当にこれで良さそう。あとはデザインか...(絶望)デザインは1時間くらい悩んだ後とりあえず本家と全く同じにしました(何デザインできる人ほんとすごい。書いたコードと本家コードを見比べてみてかなり簡潔にコードを書けた気がする。本家コードはプログラミング初学者(当時)が書いたものだし、フレームワークも言語も違うんだからそこでマウント取ろうとかそういう気持ちはまったくないんだけど、自分もガチ初心者だった頃より少しはマシになれたのかもなぁと思った。19:30サイゼリヤ1000円をRubyでざっくり作ってみたTweet広告を非表示にするもっと読むコメントを書く2019-05-09ターミナルでよく使うショートカット備忘録ツールGWが明けたらiTerm2のショートカットを完全に忘れていたので備忘録を兼ねて書く。Tab)iTermを使い始めた理由は最後の複数タブ同時入力のため。普段はVSCode内のターミナルで作業しているのでリリースなどでサーバーにsshするときしか使っていない。kカーソルより前/後を全削除あとは、普段fishを使っているので以前に入力したコマンドは→で補完入力されたりする。fishもとりあえず入れただけで使いこなせてないのでもう少し調べて使いこなしたい。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。