矢島

## プロジェクト概要 株主管理業務のWebアプリです。 https://sharemanager.jp/ 煩雑な業務をWeb上で行うことで、株主管理の手間を省くことができるサービスです。 現在数十社に導入いただいています。 ## 所属会社 株式会社Qureテクノロジーズ https://qure-technologies.co.jp/ ## 開発体制 開発体制は以下の3名体制です。 - プロダクトマネージャー（社長） - 開発者（私） - テスター それぞれの役割は以下の通りです。 プロダクトマネージャーが、仕様変更や追加機能のアイデアを提示する。 私が、プロダクトマネージャーと対話を重ねて要件や仕様をまとめ、実装する。 テスターが、テストを行う。 ## 業務内容 以下の業務を経験しました。 - 起業（発起人の1人） - 開発 - リリース - 運用 - テスト - 顧客対応 - 商談 プロダクトのアイデアを練り、開発してリリースし、商談して使っていただく、というところまで一通り経験しました。 顧客目線でプロダクトを見る力が身についたと感じています。 業務レベルでの開発経験者は私1人だけという状況だったので、開発環境の整備や技術的な知識の共有なども行いました。 最後まで責任を持ってやりきることの大変さと、達成感を学びました。 ### 実際の開発の流れ 実際にどのように開発を行なってきたかを例示します。 #### 1. 作りたい機能の概要をまとめる プロダクトマネージャーに対しヒアリングを実施し、以下のように大まかに機能の概要を明文化します。 今回解決したい課題として「持株会管理業務の煩雑さ」がありました。 持株会管理業務は、「毎月の積立金の算出」「会員の登録・退会」「会員の情報変更」など、手間のかかる業務です。 多くの企業では、上記の業務をエクセルなどで行なっており、工数がかかっている上に人的ミスも発生しやすいという課題がありました。 そこで、持株会管理業務をスムーズに行うための機能として以下の機能を開発しました。 - 機能名称 - 持株会オプション機能 - 機能概要 - 持株会運営の業務を支援するための機能です - （詳細はこちらをご参照ください） - https://sharemanager.jp/news/update_20240227 - 機能詳細 - 持株会会員登録 - 積立金の拠出機能 - 株主名簿との連携機能 - など 積立金の計算などはシステム化することで自動化でき、登録や情報変更などをCSVで一括登録できるようにするなど、とにかくユーザーの業務負担を減らすことを考えた機能にしました。 #### 2. 要件定義 誰がどのような操作を行うかを考えながら、作るべき機能を洗い出しました。 この時点ではあまり詳細に踏み込まず、「要件は後から変わっていくもの」という前提で進めています。 #### 3. 設計 要件を満たすために何が必要かを考え、リストアップします。 大まかにタスク化し、タスク管理ツールに登録します。 デザインツールでモックを作り、プロダクトマネージャーとモックを見ながら動きを確認します。 要件を変える必要がある場合は2. の要件定義の内容を更新します。 クラス名やテーブル名などを考えます。 #### 4. 実装 ここからコードを書いていきます。 以下のような環境で実装を行なっています。 - プログラム動作環境 - Docker - 言語など - PHP, JavaScript, CSS, HTML, SQL - エディタ - Visual Studio Code(VS Code) VS Codeには以下のような拡張機能を入れています。 https://qiita.com/Yajima_t/items/1bb71fe5dd112231cb62 実装時は以下の点に気をつけています。 - 処理は細かくメソッド化する（処理が3行以上になったらメソッド化を検討） - 処理は宣言的な記述を心がける（極力、副作用がないようにする） - 変数名、メソッド名はわかりやすく（書籍「リーダブルコード」の内容を意識する） - MVCの責任境界を意識する - ロジックは極力モデルに閉じ込める - ビューにロジックは入れない - コントローラーにロジックは入れない - できるだけ処理を共通化し、使いまわす - マジックナンバーを入れない。定数化する。 - 極力SQLは使わず、ORMを活用する（セキュリティ強化、RDBMSのバージョンアップ時の対応箇所を減らすため） #### 5. テスト ローカル環境で動作を確認し、問題なければテスト環境にデプロイします。 次にテストケースおよびテストプランを作成します。 テストケース管理アプリとして「Qase」を使用しています。 テスターにテストを依頼します。 テストがOKであれば6.に進みます。 テストがNGであれば4.に戻ります。 #### 6. 機能レビュー プロダクトマネージャーに機能をレビューしてもらい、フィードバックを得ます。 得たフィードバックをもとに、仕様の変更や設計見直しを行い、実装します。 フィードバックがなくなったら7.に進みます。 #### 7. リリース 本番環境にリリースします。 今回は大型の機能リリースだったためユーザーへの通知を行いました。 --------- 実際の開発の流れの例は以上です。 同様に、以下のような機能を開発しリリースしました。 - 自己株式機能 - 自社が保有する株式（自己株式）について、会社法の要件を適用する機能 - 支払調書出力機能 - 配当実施時に税務署に提出する帳票のPDF出力機能 - セキュリティオプション機能 - システム内の特定アクションを検知し、ログを保存してユーザーに表示する機能 - 例えば、誰がいつどのIPアドレスでログインしたか、など ## 成果 自身が達成した成果は以下の通りです。 - プロダクトを作ってリリースした - 顧客から直接フィードバックを得てプロダクトをブラッシュアップした - 頻繁に機能を追加し続けたことで、プロダクトの価値を高めた 特に、支払調書や全銀フォーマットデータなどを自動生成してダウンロードできる機能はユーザーの方から感謝のお声を多くいただいています。

## プロダクト概要 主婦層向け求人媒体です。 https://part.shufu-job.jp/ 開発体制は以下の通りです。 - フロントエンドチーム - 2名 - バックエンドチーム - 8名 - インフラチーム - 3名 - テストチーム - 3名 私はバックエンドチームに所属していました。 ## 所属会社 株式会社ビースタイルホールディングス https://www.bstylegroup.co.jp/corporate/outline/ ## 業務内容 主婦層向け求人媒体のバックエンド開発およびプロジェクトリーダーを経験しました。 主に以下のプロジェクトを経験しました。 プロジェクト1. バグ改修 プロジェクト2. 求人データ連携プロジェクト ### プロジェクト1. バグ改修 主にPHP(CakePHP, Laravel)を用いて、バグ改修などを行いました。 ローカル環境ではDockerコンテナを使ってプログラムを動かしました。 GitHubにプルリクエストを作成すると自動テストが起動し、自動テストが失敗した場合はマージできないよう設定してありました。 テスト環境はAWSと連動しており、GitHub上のプルリクエストをCodePipelineからデプロイすることでECSを用いたデプロイ環境が構築されていました。 コードのレビュアー・レビューイを経験しました。 フロントエンドのタスクとして、Vue.jsを用いた機能の改修も経験しました。 ### プロジェクト2. 求人データ連携プロジェクト 3名のチームのリーダーを経験しました。 課題として「自社求人媒体の求人データが不足している」というものがありました。 課題解決策として、外部会社と協力し、外部会社の求人データを我々の求人媒体に掲載するための仕組みづくりを行いました。 外部会社の求人データを取り込むバッチを実装するというプロジェクトでした。 プロジェクトを進める上で、以下の点に気をつけました。 - メンバーが業務に集中できる環境を作る - 部門間の調整が必要な箇所は早めに調整を行う - 自分たちだけで悩まず、助けを求める - 定期的に1on1を行い、メンバーの状況を把握する - アジャイルを意識し、とにかくフィードバックループを回すことを心がける 成果として、スケジュール通りプロジェクト進行ができました。 外部協力会社の皆様とも良好な関係を築けました。 メンバーからも「一緒に開発ができて楽しかったです」とお声をいただきました。 ## プロダクトについて気をつけたこと 多くのユーザーが日々利用しているプロダクトだったので、システム全体の品質に気を使いました。 具体的には、以下の点を徹底しました。 - ユニットテスト、統合テストを書く - 手動でテストを行う際はテストケース管理ツールを使い、テストケースと結果をチーム内でレビューし合う - コードは複数人にレビューしてもらう この現場ではじめて自動テスト・自動デプロイ（CI/CD）を経験しました。 毎週勉強会を行うなど、周りのメンバーと交流を深め、お互いに刺激し合いながら業務を行いました。 用語集や各種手順書などのドキュメントを書いて社内に公開したところ、「とてもわかりやすいです。次に参加するメンバーにも共有できるので助かります」といった声をあちこちからいただきました。 ## 課題 個人的に、以下の点を課題に感じました。 ### 課題1. 組織内のコミュニケーション量が不足している 開発チームは基本的にフルリモートでの勤務だったこともあり、組織内のコミュニケーション量が不足していると感じました。 1日に1度、「朝会」という形でWeb会議があったのですが、雑談などはあまりなく、それぞれが淡々とその日やることを発表しあって終わりというものでした。 コミュニケーション量の不足がどのような課題となるかというと、一番は「ドメイン知識の暗黙知化」だと感じています。 ドメイン知識が暗黙知化してしまうと、「何か障害などが起こった際に特定のメンバーしか対応できない」という状況が生まれてしまいます。 当時のチームも上記のような状況に陥っていたため、私はなんとかしてドメイン知識を形式知へと昇華させたいと考えていました。 ### 課題1. の解決策 社内の勉強会を主催しました。 勉強会を主催することで、勉強会の中でドメイン知識を形式知へと昇華（ドキュメント化）したいと考えました。 実際に勉強会の中で作成したドキュメントは開発組織全体に公開され、手順に沿って作業することで障害に対応することができるようになりました。 勉強会の詳細については以下の記事をご参照ください。 - １年間続けた勉強会の成果と失敗 - https://qiita.com/Yajima_t/items/6034d20ea20b9484c903 要約すると以下の通りです。 - 時間 - 毎週金曜の1時間 - 場所 - オンライン（Discord） - 基本は自由参加 - ラジオ的に聞くだけでもOK - 参加人数は、4〜8人程度 - 議事録を作成し、後日上長へ共有 - 議事録はオンラインドキュメントツール（DocBase）でリアルタイム編集 結果的に、以下の成果を挙げられました。 成果1. 各種ドキュメントの整備 成果2. コミュニケーション量の増加によるチームの連帯感の向上 成果3. チーム全体の技術力の底上げ ### 課題2. 社内でのみ通用する用語が多く、新たに入社したメンバーがキャッチアップに苦労する 歴史の長い会社だったこともあってか、社内でのみ通用する用語が多く、その意味があいまいになっているという現状がありました。 例えば部署名・組織名の通称、ユーザーの属性に応じた呼称、プラン名などです。 私自身、入社後に会議などでわからない用語があるとメモしておいて誰かに意味を聞く、という作業を重ねていた現状があり、「この知見を社内に共有しないと、毎回新入社員がキャッチアップに苦労するのではないか」と危惧を抱いておりました。 ## 課題2. の解決策 オンラインドキュメントツールで用語集を作成し、社内全体に公開しました。 誰でも編集できるようにしておくことで、認識齟齬がある場合には修正してもらえる環境を整えました。 成果として、私の後に入社したメンバーから「情報量が多くて助かりました」「あの用語集のおかげでスムーズに業務内容が理解できました」というお声をいただきました。 入社後のキャッチアップにかかる時間を短縮でき、生産性の向上に寄与できたと感じました。 ## その他 組織全体に良い影響を与えられた実績として、「書籍購入制度の導入」があります。 詳細は以下の記事をご参照ください。 書籍購入制度を導入してもらった話 - Qiita https://qiita.com/Yajima_t/items/43e78ddd8b182506555e 要点をまとめると以下の通りです。 - 技術書を購入するための補助がほしかった - 直属の上司だけでなく、さらに上の上司にも働きかけた - ただ「予算ください」と訴えるのではなく、ストーリーを意識した - 「技術力が低いという課題を解決するため」に「技術書が必要」だから「制度化して予算をください」 成果として、書籍購入制度を導入したおかげで勉強会で輪読ができるようになり、チームのコミュニケーションの促進と技術力向上という2点が実現できました。 チームメンバーからは「絶対に無理だと思ったのに、実現して嬉しいです」「チームの生産性が上がったと感じます」というお声をいただきました。

## プロジェクト概要 BtoBの収納代行サービスです。 https://smartbilling.co.jp/service/receipt_agency/ 開発体制は以下の通りです。 - 開発チーム - 6名（PM1名、開発5名） 私が参画した際は6名でしたが、最終的には2名体制になりました。 ## 所属会社 株式会社アイ・ディ・エイチ https://idh-net.co.jp/ （SESとして収納代行プロジェクトに参画していました） ## 業務内容 収納代行サービスの開発・保守運用です。 収納代行とは、商品・サービスの料金を企業に変わってエンドユーザーに請求し、まとめて企業に収納するというサービスです。 私の担当業務は以下の通りです。 - 運用作業 - 運用作業の自動化 - 開発 以下のような作業を行いました。 - AWSのEC2インスタンスのメトリクス監視 - CPU使用率など - RDSのスロークエリを改修 - 適切にインデックスを張る - 正規化を行う - など - バグ改修 - データの不整合を生んでいる処理を改修する - 想定外のデータも扱えるようにする - 小数点の端数処理が想定と異なる箇所を改修する - など - パフォーマンス改善 - ページの表示速度が遅い箇所の速度改善（クエリの最適化） お金を扱うシステムなので、処理の正確性に気をつけながら業務を行いました。 ## 課題 現場の課題として以下の2点がありました。 - 課題1. 運用工数が高い - 課題2. 手作業による人的ミスが多い ### 課題1. 運用工数が高い 私が参画した時点で、1つのシステムに運用要員として5名が稼働していました。 ほぼ全てのユーザーがグループ会社、というクローズドなサービスだったのですが、データ加工や出力などを手作業で行う場面が多く、工数がかかっていました。 具体的な運用作業は以下の通りです。 - 全請求データのCSV書き出し（毎日2時間程度） - 口座情報の最新化（毎月3時間程度） - エンドユーザーの名寄せ作業（毎月4時間程度） - 月次請求データのエクスポート＆他部署への共有（毎月 2時間程度） - IPアドレスのホワイトリスト追加（都度発生 30分程度） - 整合していないデータに対する調査（都度発生 30分〜数日） - バグ改修（都度発生 2時間〜数日） ### 課題1. の解決策 解決策として、「可能な限り自動化」しました。 例えば「全請求データのCSV書き出し」であれば、以下のように自動化しました。 【自動化前】 以下の手順で作業を行っていました。 1. ブラウザからCSVエクスポート画面を表示し、「CSVエクスポート」ボタンクリック 2. 他の作業をしながら1時間程度待つ 3. FTPクライアントで本番サーバーに接続する 4. 特定のディレクトリに移動し、CSVファイルを自分の端末にダウンロードする 5. 社内ファイルサーバーの特定のフォルダに、CSVファイルをアップする 【自動化後】 手作業は完全になくなりました。 シェルスクリプトとWindowsのタスクスケジューラーで、CSVファイルを共有できる環境を整えました。 また、「そもそもこの作業は必要なのか？」という点について現場責任者と話し合い、業務の棚卸しを行いました。 結果として手作業が減り、運用要員を5名→2名にまで削減できました。 現場責任者から「業務を効率化してくれて助かる」といったお声をいただきました。 ### 課題2. 手作業による人的ミスが多い 以下のような手作業が行われていました。 - エクセルを利用してCSVファイルを加工し共有する - 手でSQLを書き、本番DBに対して実行する - CSVファイルからSQLを生成し、本番DBに対して実行する 手作業なので、毎月のように作業ミスが発生していました。 ### 課題2. の解決策 課題1同様、「可能な限り自動化」しました。 以下の作業を例に説明します。 - IPアドレスのホワイトリスト追加（都度発生 30分程度） 【自動化前】 以下の手順で作業を行っていました。 1. 「このIPアドレスを許可設定したい」とメールを受ける 2. SQLクライアントソフトを立ち上げ、本番DBに接続 3. IPアドレス許可リストテーブルに、レコード挿入 4. httpd.confにIPアドレスを追記 5. Webサーバー（Apache）の再起動 6. 「許可設定の作業が終わりました」とメールを送信する 【自動化後】 運用時の手作業は完全になくなりました。 IPアドレス許可設定を行うために、ユーザーに以下の操作を行ってもらいます。 1. 「IPアドレス許可設定」画面を開く 2. 許可したいIPアドレスを入力 3. 「保存」ボタンクリック 3. の後、システム内部では以下の処理を行います。 4. 入力されたIPアドレスをDBに保存 5. 入力されたIPアドレスを.htaccessに追記（シェルスクリプト） こうすることで手作業を排除できました。 現場責任者から「作業ミスを減らしてくれたので業務効率が上がりました。ありがとう」といったお声をいただきました。 ## 成果 成果は以下の通りです。 - 運用コスト削減（6人月→2人月） - 運用の精度向上（手作業→スクリプト化）