こんにちは！

SEプラス採用担当の鶴田です！

今回は、「【開発エピソード】勤怠管理システムを全面リニューアルしました！ ～要件定義からリリースまで、現場と走り切った刷新～」と題しまして、当社の勤怠管理システム「TENKO」の全面リニューアルの開発を担ったMedia Teamの堀さんと楠本さんに、今回のプロジェクトついてお伺いします！

SEプラスのエンジニア職にご興味をお持ちの方はぜひご覧ください！

普段のエンジニアの職務内容については、こちらの記事でご紹介していますので、まだ見ていない方はぜひこちらもご覧ください。

1.TENKOのリニューアルとは

ーー堀さんに聞いてみました

堀さん：

TENKOは当社内で自社開発した勤怠管理システムです。TENKOの今回のリニューアルは、新機能導入が目的というよりも、使用している言語とフレームワークのバージョン更新が主な契機です。社内で進めている他サービスの改修計画に沿って、サポート終了や運用上のリスクを順次解消する一環としてTENKOも対象となりました。

さらに、人事部門の体制強化に伴い、勤怠管理を管理部で一元化する方針が決まり、イントラ機能への要望が具体化したこともリニューアルを後押ししました。こうした事情を踏まえ、安定性と現場ニーズの両立を目指して刷新を進めることとなりました。

2.開発の進め方について

ーー楠本さんに聞いてみました

楠本さん：

プロジェクトは現場の要望を丁寧にかみ砕くことから始めました。イントラユーザーである管理部に対し、イントラ機能として「まずこれが欲しい」という優先項目を洗い出し、1件ずつヒアリングを行って「なぜそれが必要か」を確認していきました。

そこからは、要望をできるだけ反映させる方針のもと、要望の洗い出し→精査→要求の深掘りを行い、運用フローとのすり合わせを重ねながら仕様を固めていきました。設計段階では言語や実装フローも確認し、実際に組み込んだ際の挙動を管理部と確認。仕様確定後は設計→実装→テスト→リリース準備→リリースという工程で進行しました。

開発は、属人化を避けるため二人体制で進めていきました。私がメイン開発を担当し、堀さんにサポート役としてミーティング同席、設計・要件定義・テストの調整などを担っていただきました。テストはエンジニア全員と管理部で協力して実施し、複数名でチェックする体制を取ることで認識のズレや見落としを防ぎ、相談しやすい環境を整えました。

また設計は全サービス共通の前提としてセキュリティを最優先としつつ、データ構造の見直しも行いました。具体的には「One Fact in One Place（1つの事実は1箇所に集約する）」というデータベース設計における考え方を徹底し、前バージョンの反省を生かして、さらに操作性が高まるよう見直しを行いました。

3.苦労したこと

堀さん：

開発メンバーはTENKO以外にも複数プロジェクトを担当しており、同時期には当社の教育サービスの受講サイト改修も進行していました。TENKOでの試行錯誤で得た知見を受講サイト側に反映しようと試みがありましたが、途中でそちらの方針が変わったため、期待した相互適用が難しくなった場面がありました。その影響で、TENKO側でどのような方向で試行錯誤を進めるか決めづらくなることもありました。

また、従来の「まず着手してから改善していく」やり方を改め、今回は要件をきちんと固めてから実装に入る方式を採りました。品質面では効果があったのですが、想定していたとはいえ、必要な機能の整理や要件定義に想定以上に時間がかかってしまいました。今後は要件定義の工程をさらに効率化する必要があると感じましたね。

楠本さん：

TENKOは比較的シンプルな業務システムですが、その分「これで業務上正しいか」「法令に適合しているか」といった確認作業が重要でした。技術的な実装よりも、管理部と密に連携して法律や労務面の要件を精査する作業に時間と手間がかかりました。未経験の分野も多かったため、早い段階から関係部門の知見を取り入れて逐次確認しながら進めていくのは、やりがいがありつつも苦労した点でしたね。

また、実装前に固めた要件がテスト段階で大きく変更されるケースがあり、その都度手戻りが発生したため、工程の見直しも必要になったので、大きな反省点ですね。

4.学びと今後の改善

堀さん：

管理部と密に連携し、プロジェクトを最後までやり切れたことは大きな成果です。スケジュールの大幅な遅延なくリリースを実現でき、場合によっては早期リリースも視野に入れられる余力を確保できました。開発担当に一定の裁量が与えられたことで、現場の要望に合った実装手法を柔軟に選択できた点も成功要因の一つです。

また、普段はサービス企画チームとやり取りすることが多いのですが、今回は内製システムということで、実際のユーザーであるSEプラス社員と直接コミュニケーションを取る機会がメインでした。その中で分かったのは、「単にシステム要件を満たしておけば良いというわけではない」ということです。

当社の教育サービスは、営業がクライアント企業の教育担当者に提案し、教育担当者が自社の社員に受講を促すという階層的な構造を持っています。だからこそ、今後はサービス企画チームと話す際に「システムで何を作るか」だけでなく、企画チームが日々どんな視点で価値を定義しているか、営業がどう顧客に提案しているか、教育担当者がどんな効果を求めているか、受講者はどんな受講体験を期待しているか──といった背景まで一緒に考え、深く理解する必要があると実感しました。要望の“なぜ”を踏まえた設計を心がけることで、より現場に刺さるサービスを作っていきます。

楠本さん：

リリース後、ユーザーから大きな問い合わせはほとんど寄せられず、適切なユーザーに適切なシステムを届けられたという手応えを得られました。紆余曲折はありましたが、当初の目的は概ね達成できたと感じています。

一方で、エンジニア側から見ると、企画の意図や運用全体のイメージを十分に把握できていなかった場面がありました。特に画面を実際に見せながらの確認や、現場の運用フローを一緒に検証するといった視覚的・実務的なすり合わせが不足していた点は反省点です。要件や運用イメージの齟齬を減らすため、画面モックやプロトタイプを早期に用意して企画側や現場に触ってもらうプロセスを、積極的に導入していきたいと思っています。

5. 最後に

TENKOの刷新は決して派手な機能追加ではなく、地道な改善と現場との対話の積み重ねで成り立ちました。チーム全員で課題を見つけ、手を動かしてきたからこそ出せた手応えがあります。エンジニアとして挑戦したい方や、わたしたちと一緒にものづくりをしたい方、ご応募をお待ちしております。

ぜひ次回のストーリーも楽しみにしてください！