【ゴールデンウィーク営業のお知らせ】
2025年4月29日(火)～2025年5月6日（火）の期間を休業とさせていただきます。
※4月30日（水）、5月1日(木)、2日(金)は通常営業いたします。
※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。
関わるプロダクトやチームをより良い方向に持っていきたい
チームの空気感が、その働きに大いに影響を受けることを知ったので。関わるチームは、心理的安全性の高い、良いチームにしていきたい。
サービスの裏側から、プロダクトを良くしていくことが出来るので、そのお手伝いをしたい。
同一データベーステーブルを使っている人材紹介サイト群の処理分割
当社に複数有る、全ての人材紹介サイトをリファクタリングするにあたり、
今まで1つだったデータベーススキーマを、サイト毎に分割しようという話になりました。
自分の担当している人材紹介サイトと、ケアマネを担当している人材紹介サイトは、昔「横展開しやすい」という理由で同一テーブルを使っている部分が多く、
データ投入処理や、WEB側の変更を業務システムへ反映する処理など、様々な処理が一緒になっていました。
WEBサイトのあるべき姿に向けて、それを分割しました。
2つの人材紹介サイト
仕様調査、要件定義、設計、コーディング、テスト、運用/保守
それぞれのサイトが、お互いのサイトの工数を消費させずに、開発を進められる、健全な状態に近づきました。
Optimize Nextの導入による、簡易的なA/Bテストの導入、またその運用方法の指示
元々、登録フォームとCRM活動用のランディングページにはA/Bテストの仕組みが有ったのですが、
求人一覧や求人詳細ページには、A/Bテストの仕組みが有りませんでした。
そこで、今は無きGoogle Optimizeと同等の機能を有するという触れ込みのOptimize Nextを導入し、各ページでA/Bテスト出来るようにしようということになりました。
要件定義、設計、コーディング、テスト、運用保守
CRM活動用ランディングページのリファクタリングと、個別最適化
元々有った、CRM活動用のランディングページは、同じソースコード上に様々な機能が載っており、ソースコードから動きを判別するのが難しく、ソース変更時に何が起こるかも分かりづらいものでした。
なので、自分からの働きかけで、運用者や開発者が変わっても、触りやすいCRM活動用の画面（及びA/Bテストの管理画面）を作ることになりました。
企画、要件定義、設計、コーディング、テスト、運用/保守
CRM活動用LINEの友だち情報と、WEBサイト会員情報との連携
当社の人材紹介サイトでは、電話営業とユーザとを繋ぐLINEアカウントは有ったのだが、CRM活動用のLINEアカウントが存在しなかった。
なので、企画部保有のLINEアカウントを新設し、その友だち情報をWEBの会員情報と連携させることにより、LINEからも、ユーザの求める求人情報の定期配信を可能としたい。
要件定義、設計、コーディング、テスト、運用保守
人材紹介サイトに路線・駅検索を導入するための調査を行った
理学療法士、作業療法士、言語聴覚士の人材紹介サイトにおいて、路線・駅検索の機能が無かったので、実装に向けてどんなデータを使うか？などの調査を行う必要が生じた
要件定義、設計
1名
Aurora MySQL(MySQL 5.7)
路線・駅検索より優先順位の高い施策が来てしまったため、実際の開発にはまだ着手出来ていないのだが、
別軸で発生した、サイト横断での駅・路線検索実装のときに、このときの調査結果がほぼ100%活かされ、次期の開発予定に入った。
理学療法士、作業療法士、言語聴覚士向けの人材紹介サイトにおいて、履歴書と職務経歴書を作成し、PDFでダウンロードする機能を実装
当社の人材紹介サイトには、履歴書や職務経歴書を作成する機能が存在せず、外部の作成サイトで作ったものをPDF形式で受け渡しする業務フローになっていました。
外部の作成サイトから、別のサイトにユーザが流出してしまう危険性が有ることと、履歴書情報の共有が内部でスムーズに出来たほうが内定率が高まるという予測から、サイト内で履歴書と職務経歴書を作成する機能の制作が依頼されました。
要件定義、設計、テスト、運用保守
いきなり全機能の入った状態でリリースする流れにしてしまったため、工数が延び、何度もテストを行うようになってしまったり、
プロダクトマネージャの思いつきで機能が入れ替わったり、難しい開発環境になってしまいました。
リリース当初は細かいエラーの対応に追われました。
最初のリリースは最小限に。その後運用しながら細かく新機能をリリースするようにすれば、
都度改善とテストが出来る上、手戻りも少なくなるので、大きめの機能の開発時はスモールスタートにするよう心がけることになりました。
理学療法士、作業療法士、言語聴覚士向け人材紹介サイトのリニューアル
見た目の古いサイトだったので、新しい見た目にすると共に、
表示される求人情報をリッチ化し、SEOを伸ばそうということになった
要件定義、設計、コーディング、テスト、運用/保守
チームリーダー・インフラ：1名（当方）
バックエンドエンジニア：2名
デザイナー：1名
サイト共通の事業所画像管理画面を用意し、全人材紹介サイトで事業所画像を出せるようにした
事業所画像を載せる機能の無い、人材紹介サイトが多かったので、全ての人材紹介サイトで事業所画像を出す必要が有った
要件定義、設計、コーディング、テスト、運用/保守
全人材紹介サイトで、事業所の画像（ダミーデータ含む）を表示出来るようになった
人材紹介サイトの記事コンテンツのWordpressへの移行
理学療法士、作業療法士、言語聴覚士向け人材紹介サイトにて。
SEOに注力するにあたり、サイト内の記事コンテンツをWordpressに移行することになった。
要件定義、設計、コーディング、テスト、運用/保守
インフラ・フロントエンド・バックエンドエンジニア：1名
子会社となった会社の持つ、治療家向け求人サイトの引受けと開発サイトの作成
自社が、治療家向けの求人サイトを持つ会社を子会社化しました。
それに伴い、治療家向けの求人サイトを受け取ったのですが、最小限度の作りであり、クラウドではないレンタルサーバに置かれていたので、
よりリッチな作りに変更しようという決定になりました。
要件定義、設計、コーディング、テスト、運用/保守
AWS
人材紹介WEBサイト内に表示させても良いが、広告媒体では表示させない事業所への対応
事業所情報は、人材紹介サイトの集客の要ですが、事業所側の要望は様々あります。
人材紹介WEBサイト内に表示させても良いが、広告媒体では表示させない事業所への対応が急務となり、それに対応しました。
当時存在した人材紹介サイト6サイトに対して、同様の処理を入れました
要件定義、設計、コーディング、テスト
バックエンドエンジニア：2名
Salesforce上に「広告集客停止フラグ」を入れてもらい、その対応を各所で行いました。
具体的には、フラグが立っている場合は
メールアドレスとパスワードで、ログイン会員登録させる人材紹介サイトに、メールアドレス無しユーザの登録導線を追加する
メールアドレスとパスワードで、ログイン会員登録人材紹介サイトが有った。
ユーザの会員登録率は、登録に必要な項目が少なければ少ないほど良く、
個人情報にあたる、メールアドレスの記入が無ければ、それがより高まるとされていた。
要件定義、設計、コーディング、テスト、運用保守
フロントエンド・バックエンドエンジニア：4名
人材紹介サイト4サイトを、オンプレミス環境からAWS環境へと移行した
インフラの一元管理を止め、各開発チームで適切にスケール出来る仕組みにするため、オンプレミスから各チームのAWSアカウントで分けた構成にするようにした
要件定義、設計、開発、テスト、リリース、運用保守
1名
インフラ構築と、Lambda関数の作成が中心で、ソースコード移行は開発チームに依頼する
AWS
同人誌販売サイトの新規構築
大手の同人誌販売サイトが2つ有り、そこにもう一石投じようという企画の基、新規サービスが計画されました。
暗号化されたPDFを出力する部分が売りで、そこを軸にユーザ数を増やしていく計画でした。
設計、コーディング、テスト、運用保守
jQuery, OpenSearch, S3
ガラケーサイトの終焉に合わせ、スマートフォン用に人気の出る新規サービスをひたすら作る部署で働きました。
既に存在した、ネタ投稿サイト「ボケて」に、コミュニティサイトの機能を付加したものを構築しました。
AWS EC2, RDSの基本的な構成。
流行りませんでした。
iOS, Android用に、cocos2d-xを使った2Dバトル中心のロールプレイングゲームを作りました。
開発は僕一人。デザイナーさんは1名。音楽はフリー音源から拝借。流行りませんでした。
iOS, Android用。これもcocos2d-xで作りました。
社内に、ツムツムのようなゲームを提出した方がおり、その方からソースを拝借。
細かいパラメータの調整やゲームメニュー。計測ツールの導入などを行いました。
流行りませんでした。
Web, iOS, Andorid用。
Wordpressを改造したものを作り、そのユーザアカウントをアイドルに渡し、更新して貰います。
アイドルの記事に、アプリからおひねりのようなポイントを入れることによって、ランクを上げさせ、リアルなイベントへの参加権を取得してもらうサービスでした。
このサービスはマネタイズ出来たのですが、会社都合で、運用に人手を掛けられなくなり、低評価になりました。
2006年から数年、iモードなどのガラケー公式サイトの新規開発と運用を担当しました。
企画との折衝、要件定義から、実装、運用フェーズまで担当しています。
この頃は、データセンタに有るインフラを使っていたので、インフラやミドルウェアまでの調整はインフラエンジニアに委託していました。
運用開発を行いました。
複数有る音楽ジャンルのサイトを、Docomo, au, softbankの3キャリアで運用しました。
新規構築から運用まで行いました。
携帯キャリア別に運用すると、3~4倍の運用工数が掛かるので、携帯キャリア別のパラメータを意識せず運用出来る仕組みにしました。
某出版社案件を中心に、ガラケー用の公式サイトと公式アプリの開発と運用を行いました。
PHP, Apache, PostgreSQL
既に有る、公式サイトの運用開発を行っていました。
PHP, Apache, PostgreSQL, i-modeアプリ（Android）
会員制の、小説閲覧・投稿サイトの新規開発と運用開発を行いました。
当時、i-modeアプリからは文章を横読みでしか出来なかったのですが、縦書きフォントの入った、強引に縦書きで読ませるツールを開発。作品を分割してダウンロードさせるなど、imodeに対応したアプリを独自開発しました。
このアプリの開発も、一人でやっています。
PHP, Apache, PostgreSQL
会員制のグラビアサイトを複数構築しました。
WEBサイト運用開発チームのマネジメントをしています
週1回開発チケットの優先度決めミーティングを行い、来週までに開発するチケットなどの優先順を決めていました。
簡単なものは、チケット管理ツール（Backlog）の中で仕様の確認を行いますが、ロジックの難しいものや大きいプロダクトについては、別に会議を開き、仕様をすり合わせました。
業務委託を中心に構成されたチームなので、「長いスパンでどうする？」というのは考えづらかったのですが、それぞれの開発者の発言のしやすさや、発言した内容を実現しやすくするよう動いています。
また、四半期に一回振り返りの時間を設け、それぞれが中長期的にやりたいことの洗い出しを行い、実現に向けてやるべきことをまとめています。
毎日の朝会で、各自の進捗だけでは無く、リリース日の決まったチケットを確認し、無理の無いスケジュールで進められるよう適宜調整していました。
週に1度の優先度決めミーティングでも、今週の成果物と来週受け持てる工数感を共有し、お互いスケジュールが狂わないように調整しました。