リモートワークに移行してからの僕たちのチーム: 3ヶ月目

前回の記事からまた一ヶ月がたった、あれからあった事をまとめておく

poketo7878-dev.hatenablog.com

さすがに、3ヶ月目ともなるとリモートにともなう変化というのも段々と落ちついてきますね。

会社としての変化

オフィスを捨てた

リモートワークに移行した事もあり、ほとんど人が出入りする事のない大きなオフィスにたいして固定費が出つづけるのも良くないだろういという事で、ミーティングの時などに臨時利用できるタイプのコワーキングオフィスを借りてオフィスをひきはらった。

直接あって話したほうが早いよねというタイミングでは行く事もあるが、基本的にはリモートツールでビデオミーティングやslackといった方法でコミュニケーションを取るのはかわらない。

チームとしての変化

プロダクトにかかわる人をまきこんでの週あたまのミーティング

PO,PM,エンジニアチーム,デザイナーといったアプリ開発メンバーを中心にやっていたスタンドアップだけでなく、 PO, PM, テックリード, デザイナー, 管理部, マーケティング等 (ベンチャーなので明確な部門分けがある訳ではないが) プロダクトの入口からユーザーや顧客への接点まで広くプロダクトにかかわる人が参加する定例を週あたまのスプリント計画の前に実施するようになりました。

これによって、開発しているチームだけでなく他の部門の人とプロダクトにかかわる様々な側面での合意形成やディスカッション等もできるようになりました。

プロダクトを通じてユーザーに価値を届けるためには、お金の管理であったりアプリ以外の面でユーザーに価値を提供するための準備の渉外など様々な人の協力が不可欠なので、そういった人たちとも一緒に話せる良い機会になっています。

Githubに仕様書をまとめるようになった

今までは議事録はDocbaseに記録していて、仕様等はIssueに書かれている事が多かったですが、 これだと長期的には仕様をIssueを寄せあつめて理解する必要がでてしまいます。 そこで、一旦Githubにドキュメントとして確定した仕様があったらまとめていくようになりました。

仕様と開発の問題として感じるのは、仕様としては「システムの全体がこうなっていてほしい」という記述が必要なのに対して 個別の機能開発の観点では差分が何であるかがハッキリしないと工数のみつもりや開発タスクの分割もむずかしくなってしまいます。 そのため、手前の機能追加をいそぐ時期にはこの差分の部分が開発のタスクとして作られていくという事になってしまいます。

インフラ領域ではTerraformのようなInfrastructure as Codeのツールが発展しているので、差分はツールが導出して解決してくれますが、 まだ人間が自然言語で曖昧に伝達しているような仕様では差分をシステムが導出するというのは難しいかとおもいます。 (仕様を形式言語でちゃんと記述すればあるいは...とは個人的には少し考えますが、仕様記述のコストがまだ高いですね)

僕の変化

HTML/CSS/JS系のフロントエンドをやりはじめた

今回のプロダクトでは、Web系の管理画面も顧客にとって重要な側面になるので力をいれていきたいです。 そこで私もHTML/CSS/JS等のフロントエンドの開発をしはじめました。

CSSの勉強をした

個人的に、CSSに対して苦手意識がありつつもきちんと向きあう機会がなくWeb上でいわゆるやりかたを見て場あたり的に対処しながらなんとなくやってしまう事が多かったのですが、体系的に理解しておきたいとおもい 以下の本を購入してCSSの様々な側面について勉強しました。

CSS: The Definitive Guide: Visual Presentation for the Web (English Edition)

なかなか厚くて読むのに時間がかかる本ですが、CSSの様々な側面を詳細に説明してくれているので今までなんとなくで対応してきていた物について、どうしてそうなるのか理解して進められるようになりました。

React/Redux/Recoilをやりはじめた

こちらも、フロントエンドをプロダクトとしてちゃんとやる機会がなかったのですが、 今回はリッチなフロントエンドの挙動が必要になる場面も多かったので、RailsでHTMLを出すだけではなくReactを採用しました。 段階的に機能を付けていく中で、状態管理が必要になってきたので、ReduxやRecoilを導入しました。 副作用も必要になってきたので、redux-sageとかも導入して使っています。

React Railsを利用して作っているのですが、rspecやjest等もふくめてどうやってReactまわりのテストを書きながらすすめるのか勉強中です。

ビジネス系の本を読んだ

新規プロダクトの開発となるとビジネスの戦略も気になってきます。そこでいくつかビジネス書も読んでみました。

ジョブ理論　イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第２位！　ハーパーコリンズ・ノンフィクション)

〔エッセンシャル版〕マイケル・ポーターの競争戦略

ビジネスとして成長していくための山の登り方として、 小さなベンチャーでどんな戦略が取れるのか、その戦略とる時にどんな事に気をつけなければいけないのか、 リーンで進めていく勉強をチームで協力しながら進めていく一方でプロダクトの戦略としてコストダウンで勝負するのかそれとも機能で勝負するのか、 その時に気をつけなければいけない事は何かとかが上手く掴めると良いなとおもっています。