「残業しないほうが評価される」エンジニア組織へ。ジェイ・ラインの開発フロー再設計ストーリー

なぜ「残業しない組織」を目指したのか

ジェイ・ラインは、MARUTTOや受託制作で常に複数案件を並行しながら、品質とスピードの両立に課題を抱えていました。
・案件増加に伴う属人化と、エンジニアへのタスク集中
・「遅くまで頑張る人」が暗黙に評価される空気
・本質設計よりも「目先の火消し」に追われる状況
これらはミスや品質低下だけでなく、採用・定着にも悪影響を及ぼします。そこで、「作業時間」ではなく「価値を生む時間」で評価する組織への転換を掲げ、開発フローの再設計に着手しました。

要件定義の“前工程”を営業・ディレクターが担う

初期の課題は、「要件定義の粗さ」をエンジニアが残業で補っていたことでした。そこで、要件定義のさらに手前となる“前工程”を明確化し、営業・ディレクター側で次を徹底しました。
・クライアントのビジネスゴールと言語化されたKPI
・優先度付きの要望リストと、外せない制約条件
・既存システム・運用ルールの把握メモ
この状態まで整理してからエンジニアに渡すことで、「要件の解釈」ではなく「設計の工夫」に時間を使えるようにしました。

Redmineのチケット粒度をそろえるルール設計

以前は、Redmineのチケット粒度がメンバーごとにバラバラで、進行状況や工数の見通しが立てづらい状況でした。そこで、粒度をそろえるために次のルールを設定しました。
・1チケットは「半日〜1日」で完結する分量が目安
・「調査」「設計」「実装」「テスト」を分けて登録
・受け身の依頼ではなく、担当者が分割提案できる仕組み
これにより、進捗の見える化が進み、残業が発生しそうな箇所を早期に検知し、前倒しでヘルプを出せる体制が整いました。

レビュー会の設計を「指摘の場」から「学習の場」へ

以前のレビュー会は、仕様抜けや不具合の「チェック」が中心で、心理的ハードルも高くなりがちでした。再設計では、目的とアジェンダを見直しました。
・「バグを探す場」から「設計意図を共有する場」へ転換
・レビュー観点（セキュリティ、保守性、運用影響）を事前共有
・指摘だけでなく、良い設計・コーディングの共有も必須化
この変更により、レビュー時間は延びずに質が向上し、「直し前提」の残業が減少。エンジニア同士が知見を還元し合う文化が生まれました。

評価指標を「時間」から「価値」にシフトする

フローを整えても、評価が「どれだけ遅くまでやったか」のままでは行動は変わりません。ジェイ・ラインではエンジニア評価を次のように再定義しました。
・仕様の不確実性をどれだけ前倒しで潰したか
・再利用しやすい設計・コードで、次回工数をどれだけ削減したか
・関係者との情報共有で、チーム全体のリスクをどれだけ下げたか
これらを1on1や案件ふりかえりで具体的に振り返り、「定時で成果を出すこと」がはっきりと評価されるようにしています。

「安心して腕を振るえる」組織文化へ

開発フローの再設計は、単なるツール運用の見直しではなく、エンジニアが安心して専門性を発揮できる環境づくりそのものでした。
・前工程を担う営業・ディレクターとの対話が増えたこと
・Redmineやレビュー会を通じて、属人化が減ったこと
・「残業して当然」というプレッシャーが薄れたこと
結果として、「無理をして支える」から「仕組みで支え合う」組織へ。ジェイ・ラインはこれからも、WEBソリューションを支えるエンジニアが、健全なワークスタイルで最大の価値を発揮できる体制づくりを続けていきます。