Upgrade to Pro — share decks privately, control downloads, hide ads and more …

弊社の開発体験の良いところは?メンバーに訊いてみた!

meijin
November 14, 2023

 弊社の開発体験の良いところは?メンバーに訊いてみた!

meijin

November 14, 2023
Tweet

More Decks by meijin

Other Decks in Programming

Transcript

  1. 弊社の開発体験の良いところ
    は?メンバーに訊いてみた!
    株式会社NoSchool CTO / meijin

    View full-size slide

  2. 良い開発体験とはこんなものだ!
    といった理論より

    View full-size slide

  3. 実際にメンバーがここが良い!
    と言うことを聞きたいですよね!

    View full-size slide

  4. ということで、
    訊いてみた内容を発表します!
    ちなみに、悪いと言われたところも発表します!

    View full-size slide

  5. 自己紹介
    名人
    Twitter(X):
    名人|マナリンクCTO
    Zenn: https://zenn.dev/meijin
    株式会社NoSchool CTO
    オンライン家庭教師マナリンク(https://manalink.jp/)
    個人開発
    テストメーカー(https://test-maker.app/)
    好きな言語はTypeScript
    、好きなLighthouse
    のメトリクスはCLS
    趣味
    将棋☗、カメラ📸、ラム酒🥃、個人開発💻、筋トレ💪、高校野球観戦⚾

    View full-size slide

  6. 背景知識)弊社と弊社チームの紹介

    View full-size slide

  7. 弊社の概要
    株式会社NoSchool
    オンライン家庭教師サービス「マナリン
    ク」を開発・運営
    2020
    年サービス提供開始のスタートアップ
    現在全社員10
    名超、エンジニアは4

    現状のメンバーは特定技術領域に特化しつ
    つフルスタックに開発もできるT
    字型なスキ
    ルセット
    重要なIssue
    :「少人数でサービスのすべて
    を支えつつ事業を成長させるにあたって、
    どういった制度や文化をもって開発体験を
    高めていくか」

    View full-size slide

  8. 調査手法

    View full-size slide

  9. こんな感じにFigma
    で意見収集・投票

    View full-size slide

  10. それではさっそくランキングを発表します!

    View full-size slide

  11. 良いところ部門:第
    5

    View full-size slide

  12. 仕組化タスクで、
    PHPStan
    など品質維持するツール
    やテスト並列化など仕組みを導入

    View full-size slide

  13. 仕組化タスク
    株式会社NoSchool
    の行動指針として「仕組み化/
    自動化を推し進める」がある
    月あたり3
    営業日を使って、仕組み化/
    自動化案を社員自ら発案して実践する「仕組化タスク」制度がある

    エンジニア以外のメンバーもZapier
    やSlack
    ワークフローなどを使った自動化に取り組んでいます

    PHPStan
    を導入しLevel1
    から6
    まで徐々に上げることで、コードの最低品質を揃える仕組み
    ローカル環境で全テストを並列化しつつ高速に実行するmake test
    コマンドの作成
    Scaffdog
    を使った定型コンポーネントの自動生成
    Sentry for Laravel
    の導入
    今後こんなことやりたい
    ベーシックなインフラ構成のCDK

    テストカバレッジのCI
    での監視

    View full-size slide

  14. 良いところ部門:第
    4

    View full-size slide

  15. ソースレビューは必ずやる、探索的テストを必ずや
    る、
    API
    単位の結合テストは必ずやるなど、工数的に
    許容できる範囲で品質維持のためのルールを決めて
    いる

    View full-size slide

  16. 工数的に許容できる範囲で品質維持
    マナリンクでの開発フローにおける品質維持のための最低限のルール
    ソースレビューだけでなく開発中の各段階で相談できる枠組み(相談という行為に名前をつけて人に
    頼みやすくしている)
    調査報告
    API
    設計レビュー
    細分化レビュー
    設計レビュー
    デイリースクラム※
    後述
    ソースレビュー

    全部必須ではなく、開発者の判断または施策開始時に必要なレビューを擦り合わせ
    テスティング
    自動テスト:API
    単位テストを必須、それ以下の粒度は任意
    手動テスト:第3
    者による探索的テストと、企画者によるユーザー体験チェックを実施

    View full-size slide

  17. 相談の定型化の例①
    相談するときに適切な項目をSlack Workflow
    化しており、相談の質が人によって差が出ない
    ようにしています。
    画像はAPI
    設計レビューのときのWorkflow

    す。

    View full-size slide

  18. 相談の定型化の例②
    ちょっと違う論点ですが、GitHub Issue
    を起
    票するときに、提案用のテンプレートを用意
    しており、ライブラリ導入とかリファクタリン
    グの提案も決められた項目に回答することで
    起票できるようにしています。懸念点などを事
    前に明示することで、スキマ時間に予め調べて
    みたり、詳しい開発者から助言をもらえます。

    View full-size slide

  19. 良いところ部門:第
    3

    View full-size slide

  20. 週に
    1
    回仕様定例を実施して、開発が始まってからも
    こまめに要件を調整していく

    View full-size slide

  21. 週に1
    回仕様定例を実施
    週に1
    回固定で、開発チームとCEO
    で定例MTG
    を実施しています
    内容は着手中の開発施策の仕様に対して、疑問や改善点の提案です
    原則、最初に決めた仕様を何があっても変えませんといったことはなく、開発を進めていく途中である
    程度柔軟に変えていくこともあります
    納期がN
    月N
    日と固定で決まっていることも多くないので、大抵の施策は要件の調整とリリース日の調
    整も同時にやります
    開発に着手してから見えてくるものも多いですが、いちいちMTG
    のセットをしているとキリがないしま
    あ良いや、となりがち
    固定で週1
    入れることで、日程調整が面倒といった不満を減らします(もちろん急ぎの相談などは社内で
    捕まえて相談することもあります)

    View full-size slide

  22. 良いところ部門:第
    2

    View full-size slide

  23. 朝会で雑談したり、悩んでいることをシェアする

    View full-size slide

  24. 朝会で雑談したり、悩
    んでいることをシェア
    する
    俗に言うデイリースクラムをやっています
    毎朝Geekbot
    というサービスを使って、各
    メンバーがSlack
    で質問に回答
    機嫌はどう?で「昨日人生初麻雀してき
    た」みたいな雑談をします
    「悩んでいることはある?」で悩んでいる
    ことをシェアして、実装上の問題の場合は
    朝会終了後議論に入って解決したりします

    View full-size slide

  25. 良いところ部門:第
    1

    View full-size slide

  26. 成果を出していれば、細かくゴチャゴチャ言われな


    言い方…

    View full-size slide

  27. 成果を出していれば、細かくゴチャゴチャ言われな

    真意を投稿者本人に訊いてみました
    たとえば開発の進め方について、「段階リリースにしてここまで一旦出したい」「まず徹底的に調査
    してから着手したい」といった細かいやり方について、自分が発案してもゴチャゴチャ言われない
    うちのやり方はこうだからといった押し付けや、無駄に細かい進捗報告を要求されることがない
    世の中には「目的ありきのゴチャゴチャ」と「お気持ちゴチャゴチャ」がある
    結合テストを書かなければならないとか、設計レビューをやるとかも「ゴチャゴチャ」だが、明確
    な目的がある「目的ありきのゴチャゴチャ」。これはよき
    不必要に完璧を目指すとか、受け売りで制度を増やす「お気持ちゴチャゴチャ」。これはよくない
    うちの開発チームは「目的ありきのゴチャゴチャ」が主だし、そのうえで今はリソース等の都合でで
    きない”
    理想”
    についても、コードレビューや勉強会で議論する文化がある
    らしいです。あんたが一番ゴチャゴチャ言っとるがな!

    View full-size slide

  28. こういった体験を作るために日々考えていること

    View full-size slide

  29. 以下のようなサイクルを脳内で描いています

    View full-size slide

  30. ちなみに悪いところ

    View full-size slide

  31. 悪いところ部門TOP3
    フロントエンドのコンポーネント設計が固まっていないので我流になりがち
    Nuxt
    が移行しきれずに残っている画面の開発が大変
    古くから存在するドメインモデルの改善がおいついていない。

    View full-size slide

  32. フロントエンドのコンポーネント設計が固まってい
    ないので我流になりがち
    やっていること
    Global State
    を使わず、Context
    で乗り切れるところは乗り切る
    無駄なuseState
    やuseEffect
    警察
    feature
    ベースのディレクトリ構成
    課題
    フロントエンドがバックエンドほど綺麗にレイヤー分けできていない
    結局Form
    コンポーネントはでかい
    1
    ファイルだけではないがとはいえ数ファイルでしか使われない共通モジュールの置き場所難しい問題
    どの粒度を1feature
    とみなすか(DDD
    でいう境界づけられたコンテキスト)の策定基準が曖昧
    一緒に取り組んでいただける方、大募集です!

    View full-size slide

  33. Nuxt
    が移行しきれずに残っている画面の開発が大変
    創業期はNuxt
    で開発していたが、あとからReact Native
    アプリをリリースした関係で、Web
    フロントを
    Vue
    で書くのが辛くなった
    2023
    年11
    月現在
    Next
    製ページ:60
    ページ
    Nuxt
    製ページ:110
    ページ
    高頻度でメンテナンスするページはだいたい施策の実装のついでに移行しているが、逆に言えば低頻度で
    メンテするページはNuxt
    のままであることが多い
    また、パッと思い浮かぶ範囲で数画面ほど、ラスボスみたいな画面があってなかなか移行できていない
    チャット機能がある、WYSIWYG
    エディタがある、UI
    の種類が妙に多いフォームがある、外部サービ
    スのスクリプトを埋めている、など
    高速で移行を進めるための基底コンポーネントの整備や、ラスボス画面の移行に挑みたい方、大募集です!

    View full-size slide

  34. 古くから存在するドメインモデルの改善がおいついて
    いない。
    僕の理解では、特に決済周りがドメインモデルというよりトランザクションスクリプトっぽくなりがち
    外部アクセスの都合が混ざってくる実装において、ドメイン層の実装にだけ注力できるだけの余裕が欲し

    DB
    アクセスは呼吸をするようにRepository
    に逃がせる割に、決済系サービスへのアクセスが混ざって
    くるとその原則が守れないあたり、まだまだです。
    一緒にオンライン指導関連の契約や支払い周りの処理の適切な設計を追い求める方、大募集です!

    View full-size slide

  35. ご清聴ありがとうございました
    このあとの懇親会でお話しましょう!
    またはTwitter
    のDM or Pitta(
    旧Meety)
    まで連絡ください!

    View full-size slide