【ゴールデンウィーク営業のお知らせ】
2025年4月29日(火)～2025年5月6日（火）の期間を休業とさせていただきます。
※4月30日（水）、5月1日(木)、2日(金)は通常営業いたします。
※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。
システム開発を通じて社会貢献を実現したい
私は、システム開発を通じて社会貢献を実現したいと考えています。
なぜなら、今こうして何不自由なく生活できていることへの恩返しをしたいという気持ちがあるためです。
そのために、社会貢献が実現できるようなプロダクトの開発に携わりたいです。
具体的には、自分の強みである「Webアプリ開発」「チーム開発」といった領域の業務を行いたいです。
業務を通じてプロダクトに貢献するために、周りの方々との信頼関係を築くことを最優先で行います。
また、読書やハンズオンなどで技術的な成長を続けます。
（すでに習慣化しているので、継続し続けます）
上記のようなインプットだけでなく、アウトプットを行うことで組織全体に良い影響を与えたいです。
具体的には、勉強会の参加・開催、技術的な記事の執筆などを行い、社内外に発信していきます。
株主管理業務のWebアプリです。
https://sharemanager.jp/
煩雑な業務をWeb上で行うことで、株主管理の手間を省くことができるサービスです。
現在数十社に導入いただいています。
株式会社Qureテクノロジーズ
https://qure-technologies.co.jp/
開発体制は以下の3名体制です。
それぞれの役割は以下の通りです。
プロダクトマネージャーが、仕様変更や追加機能のアイデアを提示する。
私が、プロダクトマネージャーと対話を重ねて要件や仕様をまとめ、実装する。
テスターが、テストを行う。
以下の業務を経験しました。
プロダクトのアイデアを練り、開発してリリースし、商談して使っていただく、というところまで一通り経験しました。
顧客目線でプロダクトを見る力が身についたと感じています。
業務レベルでの開発経験者は私1人だけという状況だったので、開発環境の整備や技術的な知識の共有なども行いました。
最後まで責任を持ってやりきることの大変さと、達成感を学びました。
実際にどのように開発を行なってきたかを例示します。
プロダクトマネージャーに対しヒアリングを実施し、以下のように大まかに機能の概要を明文化します。
今回解決したい課題として「持株会管理業務の煩雑さ」がありました。
持株会管理業務は、「毎月の積立金の算出」「会員の登録・退会」「会員の情報変更」など、手間のかかる業務です。
多くの企業では、上記の業務をエクセルなどで行なっており、工数がかかっている上に人的ミスも発生しやすいという課題がありました。
そこで、持株会管理業務をスムーズに行うための機能として以下の機能を開発しました。
積立金の計算などはシステム化することで自動化でき、登録や情報変更などをCSVで一括登録できるようにするなど、とにかくユーザーの業務負担を減らすことを考えた機能にしました。
誰がどのような操作を行うかを考えながら、作るべき機能を洗い出しました。
この時点ではあまり詳細に踏み込まず、「要件は後から変わっていくもの」という前提で進めています。
要件を満たすために何が必要かを考え、リストアップします。
大まかにタスク化し、タスク管理ツールに登録します。
デザインツールでモックを作り、プロダクトマネージャーとモックを見ながら動きを確認します。
要件を変える必要がある場合は2. の要件定義の内容を更新します。
クラス名やテーブル名などを考えます。
ここからコードを書いていきます。
以下のような環境で実装を行なっています。
VS Codeには以下のような拡張機能を入れています。
https://qiita.com/Yajima_t/items/1bb71fe5dd112231cb62
実装時は以下の点に気をつけています。
ローカル環境で動作を確認し、問題なければテスト環境にデプロイします。
次にテストケースおよびテストプランを作成します。
テストケース管理アプリとして「Qase」を使用しています。
テスターにテストを依頼します。
テストがOKであれば6.に進みます。
テストがNGであれば4.に戻ります。
プロダクトマネージャーに機能をレビューしてもらい、フィードバックを得ます。
得たフィードバックをもとに、仕様の変更や設計見直しを行い、実装します。
フィードバックがなくなったら7.に進みます。
本番環境にリリースします。
今回は大型の機能リリースだったためユーザーへの通知を行いました。
実際の開発の流れの例は以上です。
同様に、以下のような機能を開発しリリースしました。
自身が達成した成果は以下の通りです。
特に、支払調書や全銀フォーマットデータなどを自動生成してダウンロードできる機能はユーザーの方から感謝のお声を多くいただいています。
主婦層向け求人媒体です。
https://part.shufu-job.jp/
開発体制は以下の通りです。
私はバックエンドチームに所属していました。
株式会社ビースタイルホールディングス
https://www.bstylegroup.co.jp/corporate/outline/
主婦層向け求人媒体のバックエンド開発およびプロジェクトリーダーを経験しました。
主に以下のプロジェクトを経験しました。
プロジェクト1. バグ改修
プロジェクト2. 求人データ連携プロジェクト
主にPHP(CakePHP, Laravel)を用いて、バグ改修などを行いました。
ローカル環境ではDockerコンテナを使ってプログラムを動かしました。
GitHubにプルリクエストを作成すると自動テストが起動し、自動テストが失敗した場合はマージできないよう設定してありました。
テスト環境はAWSと連動しており、GitHub上のプルリクエストをCodePipelineからデプロイすることでECSを用いたデプロイ環境が構築されていました。
コードのレビュアー・レビューイを経験しました。
フロントエンドのタスクとして、Vue.jsを用いた機能の改修も経験しました。
3名のチームのリーダーを経験しました。
課題として「自社求人媒体の求人データが不足している」というものがありました。
課題解決策として、外部会社と協力し、外部会社の求人データを我々の求人媒体に掲載するための仕組みづくりを行いました。
外部会社の求人データを取り込むバッチを実装するというプロジェクトでした。
プロジェクトを進める上で、以下の点に気をつけました。
成果として、スケジュール通りプロジェクト進行ができました。
外部協力会社の皆様とも良好な関係を築けました。
メンバーからも「一緒に開発ができて楽しかったです」とお声をいただきました。
多くのユーザーが日々利用しているプロダクトだったので、システム全体の品質に気を使いました。
具体的には、以下の点を徹底しました。
この現場ではじめて自動テスト・自動デプロイ（CI/CD）を経験しました。
毎週勉強会を行うなど、周りのメンバーと交流を深め、お互いに刺激し合いながら業務を行いました。
用語集や各種手順書などのドキュメントを書いて社内に公開したところ、「とてもわかりやすいです。次に参加するメンバーにも共有できるので助かります」といった声をあちこちからいただきました。
個人的に、以下の点を課題に感じました。
開発チームは基本的にフルリモートでの勤務だったこともあり、組織内のコミュニケーション量が不足していると感じました。
1日に1度、「朝会」という形でWeb会議があったのですが、雑談などはあまりなく、それぞれが淡々とその日やることを発表しあって終わりというものでした。
コミュニケーション量の不足がどのような課題となるかというと、一番は「ドメイン知識の暗黙知化」だと感じています。
ドメイン知識が暗黙知化してしまうと、「何か障害などが起こった際に特定のメンバーしか対応できない」という状況が生まれてしまいます。
当時のチームも上記のような状況に陥っていたため、私はなんとかしてドメイン知識を形式知へと昇華させたいと考えていました。
社内の勉強会を主催しました。
勉強会を主催することで、勉強会の中でドメイン知識を形式知へと昇華（ドキュメント化）したいと考えました。
実際に勉強会の中で作成したドキュメントは開発組織全体に公開され、手順に沿って作業することで障害に対応することができるようになりました。
勉強会の詳細については以下の記事をご参照ください。
要約すると以下の通りです。
結果的に、以下の成果を挙げられました。
成果1. 各種ドキュメントの整備
成果2. コミュニケーション量の増加によるチームの連帯感の向上
成果3. チーム全体の技術力の底上げ
歴史の長い会社だったこともあってか、社内でのみ通用する用語が多く、その意味があいまいになっているという現状がありました。
例えば部署名・組織名の通称、ユーザーの属性に応じた呼称、プラン名などです。
私自身、入社後に会議などでわからない用語があるとメモしておいて誰かに意味を聞く、という作業を重ねていた現状があり、「この知見を社内に共有しないと、毎回新入社員がキャッチアップに苦労するのではないか」と危惧を抱いておりました。
オンラインドキュメントツールで用語集を作成し、社内全体に公開しました。
誰でも編集できるようにしておくことで、認識齟齬がある場合には修正してもらえる環境を整えました。
成果として、私の後に入社したメンバーから「情報量が多くて助かりました」「あの用語集のおかげでスムーズに業務内容が理解できました」というお声をいただきました。
入社後のキャッチアップにかかる時間を短縮でき、生産性の向上に寄与できたと感じました。
組織全体に良い影響を与えられた実績として、「書籍購入制度の導入」があります。
詳細は以下の記事をご参照ください。
書籍購入制度を導入してもらった話 - Qiita
https://qiita.com/Yajima_t/items/43e78ddd8b182506555e
要点をまとめると以下の通りです。
成果として、書籍購入制度を導入したおかげで勉強会で輪読ができるようになり、チームのコミュニケーションの促進と技術力向上という2点が実現できました。
チームメンバーからは「絶対に無理だと思ったのに、実現して嬉しいです」「チームの生産性が上がったと感じます」というお声をいただきました。
BtoBの収納代行サービスです。
https://smartbilling.co.jp/service/receipt_agency/
開発体制は以下の通りです。
私が参画した際は6名でしたが、最終的には2名体制になりました。
株式会社アイ・ディ・エイチ
https://idh-net.co.jp/
（SESとして収納代行プロジェクトに参画していました）
収納代行サービスの開発・保守運用です。
収納代行とは、商品・サービスの料金を企業に変わってエンドユーザーに請求し、まとめて企業に収納するというサービスです。
私の担当業務は以下の通りです。
以下のような作業を行いました。
お金を扱うシステムなので、処理の正確性に気をつけながら業務を行いました。
現場の課題として以下の2点がありました。
私が参画した時点で、1つのシステムに運用要員として5名が稼働していました。
ほぼ全てのユーザーがグループ会社、というクローズドなサービスだったのですが、データ加工や出力などを手作業で行う場面が多く、工数がかかっていました。
具体的な運用作業は以下の通りです。
解決策として、「可能な限り自動化」しました。
例えば「全請求データのCSV書き出し」であれば、以下のように自動化しました。
【自動化前】
以下の手順で作業を行っていました。
【自動化後】
手作業は完全になくなりました。
シェルスクリプトとWindowsのタスクスケジューラーで、CSVファイルを共有できる環境を整えました。
また、「そもそもこの作業は必要なのか？」という点について現場責任者と話し合い、業務の棚卸しを行いました。
結果として手作業が減り、運用要員を5名→2名にまで削減できました。
現場責任者から「業務を効率化してくれて助かる」といったお声をいただきました。
以下のような手作業が行われていました。
手作業なので、毎月のように作業ミスが発生していました。
課題1同様、「可能な限り自動化」しました。
以下の作業を例に説明します。
【自動化前】
以下の手順で作業を行っていました。
【自動化後】
運用時の手作業は完全になくなりました。
IPアドレス許可設定を行うために、ユーザーに以下の操作を行ってもらいます。
「IPアドレス許可設定」画面を開く
許可したいIPアドレスを入力
「保存」ボタンクリック
の後、システム内部では以下の処理を行います。
入力されたIPアドレスをDBに保存
入力されたIPアドレスを.htaccessに追記（シェルスクリプト）
こうすることで手作業を排除できました。
現場責任者から「作業ミスを減らしてくれたので業務効率が上がりました。ありがとう」といったお声をいただきました。
成果は以下の通りです。
圧着はがき送付機能（Share Manager開発）
2024年5月中にリリース
まずはPdMと対話し、「いつまでに何が必要か」を明確にしました。
今回は期日が決まっていたため、「最低限必要な機能をまず作る」という方向性で議論を重ねました。
「開発日数」と「機能」はトレードオフの関係にあるということをまず理解してもらい、いわゆるMVPを作ることを意識しました。
開発手法は、アジャイル開発を意識しました。
具体的には以下のように進めました。
スプリントは1週間としていましたが、実際はそこにとらわれず細かく時間をとってフィードバックをもらうよう工夫していました。
結果的に、リリース期日までに無事リリースを行うことができました。
スプリントで動くものを見てもらうことで、「欲しい機能が明確になった」とPdMから声をかけてもらったことが印象的でした。
「圧着はがき送付機能」のリリースノートはこちらです。
以下の言語を身につけたいです。
また、アジャイル開発を体系的に学びたいと考えています。
独学で得た知識をもとにチーム開発をスクラムで行った経験はあるのですが、途中でなあなあになってしまい、あまりうまくいかなかった過去があります。
アジャイル開発の経験者に教えを受け、実践してみたいです。
組織を横断するような開発を行う環境が一番パフォーマンスを発揮できます。
「組織間の調整が上手い」とよくお声をいただきます。
「今何が必要か？」「障害となっている箇所はどこか？」「誰に助けを求めるべきか？」などを意識しています。