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

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

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

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

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

背景知識）弊社と弊社チームの紹介

弊社の概要 株式会社NoSchool オンライン家庭教師サービス「マナリン ク」を開発・運営 2020 年サービス提供開始のスタートアップ 現在全社員10 名超、エンジニアは4 名 現状のメンバーは特定技術領域に特化しつ つフルスタックに開発もできるT 字型なスキ ルセット 重要なIssue ：「少人数でサービスのすべて を支えつつ事業を成長させるにあたって、 どういった制度や文化をもって開発体験を 高めていくか」

調査手法

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

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

良いところ部門：第 5 位

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

仕組化タスク 株式会社NoSchool の行動指針として「仕組み化/ 自動化を推し進める」がある 月あたり3 営業日を使って、仕組み化/ 自動化案を社員自ら発案して実践する「仕組化タスク」制度がある ※ エンジニア以外のメンバーもZapier やSlack ワークフローなどを使った自動化に取り組んでいます 例 PHPStan を導入しLevel1 から6 まで徐々に上げることで、コードの最低品質を揃える仕組み ローカル環境で全テストを並列化しつつ高速に実行するmake test コマンドの作成 Scaffdog を使った定型コンポーネントの自動生成 Sentry for Laravel の導入 今後こんなことやりたい ベーシックなインフラ構成のCDK 化 テストカバレッジのCI での監視

良いところ部門：第 4 位

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

工数的に許容できる範囲で品質維持 マナリンクでの開発フローにおける品質維持のための最低限のルール ソースレビューだけでなく開発中の各段階で相談できる枠組み（相談という行為に名前をつけて人に 頼みやすくしている） 調査報告 API 設計レビュー 細分化レビュー 設計レビュー デイリースクラム※ 後述 ソースレビュー ※ 全部必須ではなく、開発者の判断または施策開始時に必要なレビューを擦り合わせ テスティング 自動テスト：API 単位テストを必須、それ以下の粒度は任意 手動テスト：第3 者による探索的テストと、企画者によるユーザー体験チェックを実施

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

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

良いところ部門：第 3 位

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

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

良いところ部門：第 2 位

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

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

良いところ部門：第 1 位

成果を出していれば、細かくゴチャゴチャ言われな い ※ 言い方… 笑

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

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

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

ちなみに悪いところ

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

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

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

古くから存在するドメインモデルの改善がおいついて いない。 僕の理解では、特に決済周りがドメインモデルというよりトランザクションスクリプトっぽくなりがち 外部アクセスの都合が混ざってくる実装において、ドメイン層の実装にだけ注力できるだけの余裕が欲し い DB アクセスは呼吸をするようにRepository に逃がせる割に、決済系サービスへのアクセスが混ざって くるとその原則が守れないあたり、まだまだです。 一緒にオンライン指導関連の契約や支払い周りの処理の適切な設計を追い求める方、大募集です！

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