Logo

    ©ゆとりちゃれんじ

    GitHubXInstagram
    Product開発100週の軌跡

    Product開発100週の軌跡

    はじめに

    ゆとり世代の中野です。

    さっそくチャレンジについて書いていきます。

    チャレンジする背景

    • Product開発はじめて100週になるので色々整理しておきたい

    チャレンジ内容

    • 100週どんなことをやってたのかを残す

    やったこと

    ‣
    解決したい課題の調査
    • 具体的な話は長くなるので飲みでも誘ってください
    ‣
    ユーザインタビュー
    • ユーザが抱えているpainが仮設として一致しているか確認した
    • 自分が見えてない課題が他にもあるのか確認した
    ‣
    PRDの作成
    • プロダクトのあれこれをここに全部書きました
      • マルチプロダクトなのでプロダクト毎に書いたのと横断的に書いたものを用意しています
    • これを見れば何を作ろうとしているのかがわかるようになっています
    ‣
    技術検証
    • 元々はPWAで完結させたかったのですが検証した結果Native一択に
    • その後も大きいものから小さいもの検証をたくさん繰り返しています
    ‣
    技術選定
    ‣
    そもそもコアな技術何にする問題
    ‣
    Native(iOS & Android)かReactNativeかFlutterかetc…
    • Native(iOS & Android)を選ばかなかった理由
      • PMFするまでは自分一人のリソースしか勘定していないためSwiftとKotlinキャッチアップしてドライブさせてる未来が見えなかった
      • 将来エンジニアを探すコストも踏まえて難易度が高かった
    • Flutterを選ばかなかった理由
      • 当時はFlutter人気がすごくてめっちゃ迷った
      • 言語がDartであり今後横展開させずらかった
        • 特定の技術にロックインされてしまうため
    • etc…
      • 色々見ましたがどれも役不足でした
    ‣
    ReactNaitveを選択した理由
    • 決め手はExpoとEAS
      • 正直ExpoとEASがなかったらFlutterを選んでたかもしれない
      • ExpoとEASがあるおかげで難しいアレコレは全部任せたができる
      • やるべきことはドメインにフォーカスすることであり雑務ではない
    • その他の理由
      • webの技術を使っているところが強かった(バックエンドしかわからんがwebなら…)
      • ReactもTSもここで覚えてしまえば当分は食い扶持困らんやろう思考
      • ExpoGoも便利で使い勝手よかった
      • あとはReactとTSであれば将来的にエンジニア探す時の母数で困ることはなさそう
      • その後Reactの思想にハマり気づいたらフロントエンドに転身するのはまた別の話
    ‣
    コアな技術が決まったので周辺技術を選定する
    ‣
    言語
    • Javascript
      • 右も左もわからない状態で始めた頃のコードはjsで書いてました
      • 現在は新規でjsファイルを作ることはなく順次tsに置き換えていってます
    • Typescript
      • 言わずもがな
    ‣
    CI/CD
    • 今後のDeveloperExperience考えたら一択だった
    Actions

    GitHub Actionsを使用することで、高機能のCI / CDですべてのソフトウェアワークフローを簡単に自動化できます。 GitHubから直接コードをビルド、テスト、デプロイします。コードレビュー、ブランチ管理、問題のトリアージを希望どおりに機能させます。

    github.co.jp

    ‣
    Build
    • EAS
      • BuildはEASに丸投げにしてます(全部よしなにしてくれて助かってます)
        • Expo Application Services (EAS)

        Deeply integrated cloud services for Expo and React Native apps, from the team behind Expo.

        expo.dev

        Expo Application Services (EAS)
    ‣
    ホスティング
    • Vercel
      • 元々Next.jsとExpoを悪魔合体させてたのでVercelでホスティングしていました
        • 問題が起きた時にこれはExpoなのかNext.jsなのかという地獄に出会い分離しました(そのタイミングでFirebaseへ)
        • 将来的に戻ってくる可能性はぜんぜんある
        Vercel: Develop. Preview. Ship. For the best frontend teams

        Vercel is the platform for frontend developers, providing the speed and reliability innovators need to create at the moment of inspiration.

        vercel.com

        Vercel: Develop. Preview. Ship. For the best frontend teams
    • Firebase
      • Actionの提供があったり日々アップデートがあり非常に使い勝手のいいホスティング先
      • 現在進行形でお世話になっていますありがとうございます
        • Firebase

        Firebase は、高品質のアプリを迅速に開発できる Google のモバイル プラットフォームで、ビジネスの成長に役立ちます。

        firebase.google.com

        Firebase
    ‣
    BaaS
    • Firebase
      • 元々Firebaseにおんぶにだっこだった
        • firebaseには色々泣かされた思い出で目頭が熱くなる
        Firebase

        Firebase は、高品質のアプリを迅速に開発できる Google のモバイル プラットフォームで、ビジネスの成長に役立ちます。

        firebase.google.com

        Firebase
    • Supabase
      • 最近はSupabaseに現在鞍替え中
        • supabaseいいぞぉ
        The Open Source Firebase Alternative | Supabase

        The Open Source Alternative to Firebase.

        supabase.com

        The Open Source Firebase Alternative | Supabase
    ‣
    テスト
    • Jest
      • 元々はJestで簡単なテストを気持ち程度書いて自動化する仕組みを作ってました
        • Jest

        jestjs.io

        Jest
    • 最近はReact Testing Libraryも使いはじめました
      • 最近UIとLogicをしっかり切り離すようにしているのでテスト書くために
        • Testing Library | Testing Library

        Simple and complete testing utilities that encourage good testing practices

        testing-library.com

        Testing Library | Testing Library
    • E2E
      • こちらはまだ未導入
        • 一応いくつか絞り込みは終わっている状態
    • Codecovを使ってカバレッジの計測するために開発初期から導入済み
      • https://about.codecov.io/

      about.codecov.io

    ‣
    UI
    • React Native Paper
      • ReactNativeで唯一マテリアルデザインが使えるUIフレームワーク
      • デザイナーとUIについて色々話し合いPMFまでは以下で進める
        • 独自のUIは実装しない
        • デザインシステムは作らない
        • 誰でも使えるマテリアルデザインを使う
        React Native Paper

        React Native Paper is a high-quality, standard-compliant Material Design library that has you covered in all major use-cases.

        reactnativepaper.com

        React Native Paper
    • Storybook
      • 色々な用途があり採用
        • 基本的には全てのComponentはStorybookに登録されている状態
        • 何かUIを作りたければStorybook上で実際に動かしながら議論できる
        Storybook: Frontend workshop for UI development

        Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It’s open source and free.

        storybook.js.org

        Storybook: Frontend workshop for UI development
    • chromatic
      • リグレッションテストやUI及びデザインの差分を確認用
      • 主にデザイナーがデザインレビューする時のコストを削減するために採用
        • Automatically review, test, and document Storybook

        We make tools for frontend developers that automate the Storybook workflow. Chromatic helps you gather UI feedback, test across browsers, and generate usage docs, all in one shared cloud workspace.

        www.chromatic.com

        Automatically review, test, and document Storybook
    ‣
    CSS
    • Tailwind CSS
      • クラス名を考えたり運用するのはコスト高く共通認識が作りにくいため共通言語のために採用
      • 正確にいうのであればNativeで使えるようにしてくれているライブラリがあるのでそちらを利用する
        • Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.

        Documentation for the Tailwind CSS framework.

        tailwindcss.com

        Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.
    ‣
    GlobalState
    • jotai
      • 元々recoilを考えていたのですが開発が滞っている話を聞きjotaiに変更しました
        • Jotai, primitive and flexible state management for React

        Jotai takes a bottom-up approach to global React state management with an atomic model inspired by Recoil. One can build state by combining atoms and renders are optimized based on atom dependency. This solves the extra re-render issue of React context and eliminates the need for memoization.

        jotai.org

        Jotai, primitive and flexible state management for React
    ‣
    設計思想
    • 明日これを捨てれる
      • 疎結合に作り負債になった時や良いものが出てきた時にすぐに捨てれるようにして高速で経験値を積めるようにしています
    ‣
    利用ツール
    • Slack
      • あらゆる作業はSlackからできるようにする(まだ道半ば)
    • Notion
      • チームの全てのナレッジをここに集約してる
    • Jira
      • スクラムチームの要
    • Confluence
      • Notionに移行済み
    • Trello
      • 振り返り用に使ってる(惰性)
      • そのうちNotionに移行するかも
    • Figma
      • デザインとプロトタイプ用
      • エピックなどの実際に作るものの疑似体験はここでできるようにしてる
    ‣
    チーム作り
    ‣
    前提
    • チームメンバーは全員非同期のフルリモート
    • スクラムを組んで1週間に1回2時間だけ同期的にイベントを実施する
    • HRTをチームのコアの価値観としお互いの人間性を否定しない
    ‣
    やったこと
    • @nakano yuta が前提の違反がないか常に警察をする
    • 違反があった場合は対話をするを繰り返した
    • どういう風にしたいのかとなぜそうするべきかのかを繰り返し共有した
    • チームメンバーを孤独に戦わせないために自分の専門領域も幅広くキャッチアップし壁打ち相手になれるぐらいの状態にアップデートした
    ‣
    なぜチーム作ったのか
    「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」

    （If you want to go fast, go alone. If you want to go far, go together.）

    https://twitter.com/algore/status/344175392724234241?ref_src=twsrc^tfw|twcamp^tweetembed|twterm^344175392724234241|twgr^a0c1402ea89113707031498e6770d37f25b03532|twcon^s1_c10&ref_url=https%3A%2F%2Fblog.tinect.jp%2F%3Fp%3D43121

    • 見たい世界はとても遠く自分一人で早く行っても見れるかわからないので最初にチームを作りました
    ‣
    どんなチームなのか
    • 相互理解で心理的安全性は担保され全員言いたいことが言える
    • 冗談も愚痴もいい合えるし他のメンバーからフォローしてもらえる
    • DeveloperExperienceがたぶんみんな好き
    • 基本的に全員自律自走しています
    • 以下を強く憎んでいます
      • クソコード
      • 属人化
      • 暗黙知
      • 暫定対応
      • 繰り返し作業
      • 手動作業
      • 悪い開発者体験
    ‣
    仕組み作り
    ‣
    個人的な思想
    • DeveloperExperienceが低い状態ではUserFirstは実現しない
    • 1発だけのUserFirstは可能(多大な犠牲と負債を作って)
    • 高いDeveloperExperienceがある状態ではじめてUserFirstが実現できる
    • つまりDeveloperExperience以上のValueをUserにデリバリーできない
    • 必要なのは継続的な価値のデリバリーができる仕組み
    ‣
    開発の仕組み
    • 基本的にスクラムの思想に則ってチームで開発しています
    • ChatOpsを目指しているため外部サービスの操作もSlackでできるようにしています
    • コードを書く以外にやらないといけないことはほぼ自動化しています
    • 今後も自動化できるところは全て自動化しコアドメインにコミットする以外何も考えなくても良い状態を作っていこうと思っています
    ‣
    Issue制度
    • コミットしていた感じた辛い点やもっとこうしたほうがいいかもの改善案などチケットとして対応できないものをチームのIssueとして定義し全員が自由に切れるようにしています
    • 議論はIssue上で行うようにしており、スクラムイベントの時に動きがあったものを取り上げたり対応するかなどをチームで話し合い決めています
    ‣
    開発に関して
    ‣
    チームの動き
    ‣
    概要
    • スクラムチームを組んでいます
    • 1週間を1スプリントのタイムボックスとして切っています
    • イベント自体は同期的にハドルで行っています
    ‣
    Issue
    • スプリントの開始時にIssueについて議論や意見交換をしています
      • バックログに存在しない改善案やこれって課題じゃない？などの議論をしています
        • チームが高いパフォーマンスを出すための弊害になっていること
        • 既存の仕組みはもっとよくできるこうすればどう？など
    ‣
    デイリースクラム
    • 非同期でコミットしている採用していません
    • 困ったら都度slackで相談でき必要に応じてハドルで同期的にサポートする体制にしています
    ‣
    レトロスペクティブ
    • Trelloを使い事前に非同期に書き出すようにしています
    • 全てのProblemは全員で頭をひねり本質的なトライに繋げるようにしています
    • 時間がかかるものは継続的なProblemで定期的にWatchするなどしています
    • KeepはGoodも含めてありメンバーのいいところはお互いに称賛しあっています
    ‣
    スプリントレビュー
    • 基本的に相互レビューをしており2ndレビューアにPOの自分を入れているので省略しています
    ‣
    プランニング
    • 全てのチケットは具体的に何をやるのか何故やるのかどうやるのかを共有しています
    • 完了の定義を定義し曖昧さを駆逐しています
    • プラポを使いプランニングポーカーを実施し認識をあわせていっています
    Plapo | プランニングポーカーをもっとなめらかに

    plapo.net

    Plapo | プランニングポーカーをもっとなめらかに
    • 雑談
      • イベント完了後はゆるい雑談してます(自由に抜けてもらって大丈夫なやつ)
    ‣
    環境構築
    • git cloneして起動コマンドを叩くだけです
    ‣
    開発時のルール
    • 開発者が気にすることは色々ありますが多くのものは自動化されており完了の定義を満たすアウトプットを作るだけで満たされるようになっています

    100週意識してること

    ‣
    良いものを作るではなく良いものを作れるチームを作るにフォーカスする
    • 良いものから良いものは生まれない
    • 良いものを作れるチームから良いものが生まれる
    • モノはあとから作り直す戦略をたてればいい
    • 一度出来上がった文化を再構築するのは恐ろしくしんどい
    ‣
    属人化は許さない
    • 属人化をしてしまうと一時的に速度があがるのはそう
    • 長期的にみたらデメリットが目立つので属人化はさせない
    • もちろん属人化の走りになる暗黙知も許さない
    ‣
    技術的な妥協は許さない
    • 今持てる全てを出し尽くして実装する
    • 逃げて妥協して楽した負債の返済を誰にもさせるな
    • 知見を得た時は最優先でリファクタをしろ
    ‣
    人間を信じない
    • 人は失敗する生き物である前提で全てを考える
    • 人は感情の生き物でロジックではない全てを許せ
    ‣
    チームを管理しない
    • チームは子供じゃない
    • 全員意思を持って行動できる
    • できることは信じることだけ

    100週を振り返ってみて

    ‣
    成功体験
    • 100週以上続けてることがすごい
    • 実は1回リプレイスしていて旧Repositoryのコードを新Repositoryに持ってきてもそのまま動くぐらい疎結合に作れていた
    • チームで成長し前に進んでる実感がある
    • チームで誰も孤立させない一人で戦わせないを地でやりつづけてる
    • 正しく作る正しくあるの理想を掲げ説き続けている
    • 全員の壁打ちになれるぐらいのキャッチアップを常に続けてる
    • ルールは意識させたら負けActionで自然発火するものを作るべきことに気づけた
    • やはりDXと自動化と仕組み化こそ正義と確信を得た
    ‣
    失敗体験
    • 何もわからない技術領域にNoPlunで凸したこと
    • コスト書けて勉強したにも関わらず捨てていく技術たちがあるので効率的に学んでいけないと人生溶ける
    • 平日も休日もずっとinputしてプロダクト開発してるだけだったので他に何して過ごせばいいかわからない時がちょくちょくある
    • 慢性的な睡眠不足で明らかに不健康な生活してた
    ‣
    現状の課題
    • 自分がPOとPdMとSMとDevの帽子をかぶり分けるというアンチパターン(時々脳がバグる)をしている
    • Spikeがあるとコミット量が減ってしまう
    • やりたいことが無限にあって整理するのが大変
    • テストが不足しているので厚くしていきたい
    • 次々に出てくるサービスの使い方覚えたり調査したりする時間が足りてない
    • ユーザインタビューの頻度が少ないので頻度を増やし解像度をあげていきたい

    結論

    • プロダクト作りめっちゃしんどいけどめっちゃ楽しい
    • いっぱい得るものあったのでそれもどんどんチームに還元していきたい

    さいごに

    • いつもコミットしてくれてるチームメンバーありがとうございます！
    • 早くリリースできるように引き続きがんばります！

    yutanakano

    WEBエンジニア

    大阪生まれのゆとり世代です

    趣味はバイクでツーリングに行くこと

    愛車は Ninja ZX-25R SE KRT EDITION

    Expoでプロダクトを作っています

    image