JayGatsby

# 「トルー」の開発 ## プロダクト概要 採用CMSアプリ「[トルー](https://toroo.jp/)」の開発・運用をした。 一言で言うと、**企業の採用活動を効率化**するWebアプリケーション。 直接的な競合サービスは、採用係長やジョブカンATSなど。 具体的には、以下の機能が強み。 - 求人情報と応募者情報を一元管理 - 自社専用の採用サイトをノーコードで構築 - IndeedやGoogle For Jobs、Facebook Jobsなどの求人サイトとAPI連携 ## プロジェクトの規模 - **開発メンバー:** 2021年4月時点で4人（私とオフショア3人）。多い時で7人（私を含めた日本人4人、オフショア3人） - **開発期間:** 2018年8月〜2022年4月（3年9ヶ月） - **プロダクトの売り上げ:** 2020年度の売上は1.2億円 ## 技術スタック | | 技術スタック | |----------------------|-----------------------------| | フロントエンド | Slim, jQuery, Vue.js | | バックエンド | Rails, Python | | DB | MySQL, Redis | | インフラストラクチャ | AWS, Docker, CircleCI | | 開発支援ツール | GitHub, Slack, Chatwork | ## 担当役割 プレイングマネージャー（`PjM`、および`フルスタックエンジニア`）として**企画以外を全て担当**していた。 プロダクトフェーズとしては`1→10`を経験。 プロダクトロードマップや新規機能発案などの大きな"企画"と言われる部分は`PdM`が担当し、それ以降の要件定義・設計・コーディング・テスト・運用保守・データ分析を全て担当した。 - 要件定義 - アプリ・インフラの実装・運用保守 - オフショアメンバーの育成・マネジメント ## アプリ・インフラの実装・保守運用 ### セキュリティ強化 1. `SQLインジェクション`や`XSS`、`CSRF`などの修正 - **課題 :** `SQLインジェクション`の脆弱性があるコードが散見されていたが、誰も修正せずに放置されていた。 - **工夫点 :** `brakeman`というGemを提案・導入して、**脆弱性のあるコードを修正・再発防止に成功** した。 2. BIツール導入により、DB直接参照を回避 - **課題 :** トルーの現状把握・データ分析のために、**エンジニア以外の社員も`DB`を直接参照していた**。 - **工夫点 :** Googleデータスタジオ（現 Looker Studio）を提案・導入することで、DBに直接接続することなく必要な情報のみ閲覧できる様にした。 3. `Trustred Advisor`を用いてセキュリティ強化 - **課題 :** AWSを使っているが、インフラセキュリティに知見がないメンバーしか居なかったので網羅的セキュリティを評価できない状態だった。 - **工夫点 :** `Trusted Advisor`の提案・導入することで、セキュリティ堅牢度の向上に貢献した。 具体的には、`WAF`の導入、`S3`のバージョニング、`ALB`のログ保存、`CloudWatch`で`CPU/Memory`の監視を設定した。 4. `WAF`を導入し、DDoS攻撃を防いだ - **課題 :** トルーの採用サイトに対して`DDoS攻撃`が多発していた。 - **解決策 :** `WAF`を導入することで、`DDoS攻撃`を防ぐことに成功した。 ### コスト削減 1. `ALB` と `ACM`の使い方を見直して、**年間50万円（層インフラ費用の5％）のコスト削減** に成功。 詳細は以下URLを参照。 [https://qiita.com/Gatsby/items/933c5a93e5900865b7d2](https://qiita.com/Gatsby/items/933c5a93e5900865b7d2) 2. 未使用ドメインを解約して、**年間20万前後のコスト削減** に成功。 - **課題 :** 企業毎に独自ドメインを発行しているが、解約済み企業のドメインを解約せずに毎年自動継続更新をしていた。誰もドメインの管理をしていない状態だった。 - **工夫点 :** - 解約してもすぐ再契約する企業もチラホラ存在した為、トルー解約から1年経つ企業のドメインを解約するようにBizサイドを合意を得てから実装した。 - ドメインが悪用された場合のクレームや損害賠償に備えて、利用規約にドメインの解約に関する記述の提案・修正もした。 ### リファクタリング 1. コーディング規約の導入により、**1000行あったFat Modelを400行に縮小** - **課題 :** コーディング規約が無かったため、コードの属人化、可読性・メンテナンス性の低下が顕在化していた。具体的には以下のような課題があった。 - コアドメインに当たる`Company`や`Recruitment`などの`MVC`全てが`Fat`だった。 - `before_action`の多用でコントローラのブラックボックス化 - コールバック関数やアソシエーションなど記述位置がバラバラ - ハードコーディングの多用 - メソッドレベル・クラスレベルでコードの書き方がバラバラで、コードレビュー・メンテナンス共にが大変だった。 - **解決方法 :** - `View`でしか利用しないロジックを`ViewModel`（Railsでいう`Decorator`）に切り出し - `Controller`でしか利用しないロジックを`Service`クラスと`Form Object`に切り出し - `Model`や`View`, `Controller`など広範囲に使うメソッドは`Utility`モジュールに切り出し - 変数・定数・`enum`を用いてハードコーディングの撲滅 - コールバック関数の制限 - **工夫点 :** - **上司それぞれがこだわりを持っていたので、辞めた後に導入する事で穏便にコードの書き方を統一した。** - リファクタリング前に、テストを実装 - `before_action`などのコールバック関数は使いすぎると処理がブラックボックス化するので、意図的に使わない様にした。 - `Rubocop`を導入して、書き方を統一した。 2. `Trailblazer`のドキュメント化により、**各メンバーのキャッチアップ時間を約2週間短縮** - **課題 :** `Trailblazer`はカオスなRailsコードに秩序をもたらすので超優秀なGemだが、DDDの様に学習コストが高すぎる。にも関わらず導入した人が辞めてドキュメントもなくキャッチアップが大変で属人化していた。 また、オフショアメンバーも毎月コロコロ入れ替わりが激しく、`Trailblazer`がボトルネックで開発スピードが遅かった。 - **解決方法 :** `Trailblazer`の使い方をドキュメント化して、全メンバーが使い方を把握できる様にした。 <!-- 1. モデルに`schema`情報を記載 - **課題 :** Railsではモデルとテーブルが密結合にも関わらず、テーブルの`Schema`情報がモデルファイルに記載されていない。「モデルにどんなカラムあったっけ？」となった際はDBか`Schema`ファイルを確認するしかなく少し面倒な状態だった。 - **解決・工夫点 :** `annotate`というGemを提案・導入することで、漏れなく全てのモデルファイルに`Schema`情報を記述した。 --> ### パフォーマンス改善 1. **`DB`の`CPU使用率`を90%から60%に改善** - **課題 :** `N+1問題`が散見されていたが誰も修正せずに放置されていた。 様々な負債と相まって、`DB`の`CPU使用率`が90%に達してパフォーマンスが著しく低下していた。 - **工夫点 :** `bullet`というgemを提案・導入して、**N+1問題を解決・再発防止に成功**した。 2. 処理時間9時間 && メモリ使用率100%のバッチ処理を、**処理時間20分 && メモリ使用率30%に改善** - **課題 :** - 初期トルーでは求人データの登録手段は手作業のみだったが、CSVを用いた一括登録機能を実装したことにより、**従来の約100倍のペース**で登録される様になった。具体的には、初年度数千件程度だった求人データが、1年で100万件を超えた。 - トルーはIndeed, 求人BOXなど求人媒体に求人情報を連携しているが、求人データを1回のSQLで全て取得していたことにより、**メモリ使用率が100%に達しXMLファイルを作成できなくなった**。 - **解決方法 :** - スロークエリログから根本原因がインデックスの貼り忘れであることを特定し、インデックスを貼ることで処理時間を20分に改善した。 - データ取得処理・ファイル書き込み処理を小分けに処理することでメモリ使用率を30%に改善した。 - **工夫点 :** - `lol_dba`というgemを提案・導入して、**DB全体のインデックス貼り忘れを修正・再発防止に成功**した。 - `find_each`, `in_batches`メソッドを用いてループ処理・SQLを小分けにするだけでなく、**ファイル書き込み処理も小分け**にすることでメモリパンクを半永久的に再発防止した。 - `CloudWatch`を用いて**CPU・メモリ使用率の監視・通知を実装することで早期発見・再発防止に貢献した**。 - `pluck`を用いて、無駄なデータを取得しないようにデータ取得サイズを軽減させた。 3. `BULK INSERT`を実装して、**処理時間を20分から7分に改善**した。 - **課題 :** 従来のバッチ処理では大量のデータを1行ずつINSERTしていたので処理速度が遅かった。 - **解決方法 :** `activerecord-import`を用いて`BULK INSERT`を実装することで、処理速度を半分以下に改善した。 - **工夫点 :** `BULK INSERT`の際は`ActiveRecord`を経由せず直接`SQL`を実行するので、バリデーションやコールバックが発火されない。 なので、`BULK INSERT`のバッチ処理からも`ActiveRecord`からもバリデーションロジックを切り離し、独自のバリデーションクラスを実装することでデータの不整合が起こらないように一元管理した。 また、プルリクエストのテンプレートにチェックリスト作成を提案・導入することで、今後実装されるバッチ処理の再発防止に貢献した。 4. リードレプリカの導入で閲覧ページの**レスポンス速度が12秒から3秒に改善** - **課題 :** 求人数の急増とCSVインポート機能により常にWrite処理が走っていたことにより、上記課題1〜3を改善してもMasterDBの`CPU使用率`が80%を超えていた。 - **解決策 :** リードレプリカを導入することで閲覧ページの**レスポンスを12秒から3秒に改善**した。 5. 毎日の**CSVインポート件数を20分の1に削減** && 論理削除された求人データを物理削除することで**DB容量を120GBから100GBに削減** - **課題 :** CSVインポート機能を実装したことで求人データが1年で100倍になった。1番の原因は、顧客が増加したことではなかった。本質的な原因は、Indeed SEOの仕様を逆手に取った人材紹介企業の増加にあった。 Indeed SEOの仕様上、新規求人は上位に表示されやすい。新規求人かどうかの判定はIDを用いて行われる。なので、CSVインポートを用いて求人情報を全部論理削除・新規作成を繰り返し行う企業が増えていた。これが本質的原因だった。 - **工夫点 :** - 全部論理削除・新規作成をしなくても済むようにIndeed専用のIDを導入することで、求人データ爆増を防いだ。 - 同時に、論理削除された全く使われていないデータを物理削除することで、DB容量の節約にも成功した。 <!-- 4. 求人データが約1万件を超えるとトルーで作成した採用サイトが一切見れなくなる不具合の修正 - **原因 :** MySQLの`order`で使用できるメモリの上限を超えて並び替えができなくなていた。 - **解決方法 :** `order`するときに使えるメモリの最大容量を増やすことで解決しました。 - **工夫点 :** AWS RDSに設定しているパラメータグループがデフォルトパラメータグループだったので、カスタムパラメータグループに変更する必要がある。しかし、パラメータグループを変更するにはDBを再起動する必要があるので、トルーをメンテナンスモードにすることで、ユーザー対策を行なった。 --> ## オフショアメンバーの育成・マネジメント 1. オフショア開発と密にコミュニケーションを取ることで、**タスクの遅延率を80%から20%に削減**。 - **課題 :** 以下のような地獄の状況だったので、「タスク完了日」が「納期」としての役割を果たしていなかった。 - **私が担当する以前は、オフショアメンバーとのMTGは週1回の15分だけだった。** - 依頼するタスクの仕様が雑で、**ほぼ全てのタスクで手戻り・闇の工数が多発**していた - オフショア側も一切質問してこない - **解決方法 :** 毎日30分MTGと毎週1時間MTGを行い、認識に齟齬がないか・仕様の理解度・進捗のチェックを行い徐々に改善していった。現在では20%に削減することができた。 - **工夫点 :** 以下の取り組みをすることで、オフショアメンバーに自発性・主体性を芽生えさせた。 - 依頼したタスクがそもそもなぜ必要なのか、背景と理由を説明 - 1度犯したミスを逐一チェックリストに追加し、再発防止をした（品質マネジメントの徹底） - タスクの進捗確認と技術的フォローをする事で納期の意識付けをした（スケジュールマネジメントの徹底） - 依頼するタスクのゴールを明記（スコープマネジメントの徹底） - 雑談をする、相手に敬意を払い、発言・質問・提案を褒め、感謝をする（コミュニケーションマネジメントの徹底） 2. エンジニア以外のステークホルダーから要望のヒアリング・要件定義を遂行 - **課題 :** 営業・CSが、クライアントの要望をそのまま企画に出すことが多く、企画に上がる要望と達成したいゴールが異なる問題が発生していた。 また、MTGや口頭でのやり取りをチャットやドキュメントに残さないので、認識の齟齬が発生していた。 - **工夫点 :** 以下の取り組みをすることで上記問題の再発防止を心がけていた。 - 「そもそもその機能は本当に必要なのか？」と前提を疑う ここをしっかり議論することで無駄な機能を作ったり、仕様変更をしたりといった手戻りを発生させない様にしていた。 - その機能が必要となった背景・目的を明確に理解 「目的を達成する為にはこの企画がベストなのか？」を常に意識・議論することで無駄な手戻りを防いでいた。 - 建設的議論ができる雰囲気・信頼の構築 相手を頭ごなしに否定・きつい口調で話すなどの愚行をしない様にした（上司はこれしてた）。幸い、社内では年下ということもあり、雰囲気・信頼の構築は容易にできていた。また、曖昧な表現は避けるなど、意思疎通には細心の注意を払っていた。 - ログ記録 「言った・言ってない」の水掛け論を防ぐために、チャットやドキュメントなどにログを残し、必ず確認を取り、認識の齟齬を最小限にしていた。 - **成果:** 具体的には以下機能は自信を持って、要件精査をできたと感じている。理由は、手戻りや認識齟齬なくユーザーから良いFBを頂けたから。 - 画像一括アップロードの実装 - OEM機能の実装 <!-- ## その他 --> <!-- 他にも頑張って実装したこと・結果を出したこと - 契約・請求周りの実装、運用保守 - 画像一括アップロードの実装 - ATS - Facebook API連携 - facebook, google, indeed, job boxをXML化 - ライン応募、Pythonサーバー、MessagingAPIで急にNgrokが使えなくなった。 - 営業日 - OEM - クソコードって言われた - 価格改定、コアドメインの仕様変更 - MySQLをバージョンアップ - リードレプリカ、マルチAZ、 - RSpecでGETメソッド - 採用 - 教育 - タスクマネジメント - リスクマネジメント - スコープマネジメント - スケジュールマネジメント - 品質マネジメント - コミュニケーションマネジメント - チームマネジメント - リーダーシップ - プロジェクトマネジメント - プロダクトマネジメント - ビジネスマネジメント - マネジメントスキル - マネジメントスタイル - マネジメント手法 - マネジメント理論 - マネジメントツール - マネジメント思想 - マネジメント戦略 - -->

# 「Icey」の開発 ## プロダクト概要 会員制動画配信サービス「[Icey](https://icey.jp/)」の新規開発・運用をしていた。 一言で言うと、**自身の動画コンテンツを限定公開・売買する**Webアプリケーション。 イメージとしては以下の様な感じである。 - Udemyの様に、自身の動画コンテンツを販売できる。 - CMSの様に、自分専用のサイトを簡単に構築できる。 ## プロジェクトの規模 - **開発メンバー:** 4人（全員日本人、全員業務委託） - **開発期間:** 2021年5月〜2021年11月（7ヶ月） ## 技術スタック | | 技術スタック | |--------------------|--------------------------| | フロントエンド | Haml, jQuery | | バックエンド | Rails | | DB | MySQL, Redis | | インフラ | AWS, Docker, CircleCI | | 開発支援ツール | GitHub, Slack | ## 担当役割 フェーズとしては、`0→1`と`1→10`を経験。 フルスタックエンジニア 兼 Tech Lead 兼 EM 兼 PjM（PdM未経験）として、以下の重要な役割を担当: - インフラの設計・実装・運用 - バックエンドの底上げとチームビルディング - CircleCIを利用したCI/CDパイプラインの構築 - メンバーのタスクマネジメント ## インフラの設計・実装・運用 ### 前提 - **私以外のメンバーがインフラ未経験だった**ので、全てのインフラ業務を一人で担当した。 ### 成果 <!-- 具体的には、以下のサービスを利用 - IAM - VPC, Route53, ACM - ALB, TargetGroup, Athena, AWS WAF, Kinesis FireHorse - CloudWatch, SNS, Chatbot - S3, CloudFront - RDS, Redis - EC2, ECS/ECR, CloudFormation, AutoScaling - Lambda, MediaConvert --> 1. ゼロから一人でインフラ構築 **私以外のメンバーがインフラ未経験だった**ので、全てのインフラ業務を一人で担当した。 2. `CloudWatch`, `Performance Insight`, `Athena`を用いたパフォーマンスの可視化とログ解析 - **課題** 新規開発サービスなのでリリース時のアクセス数に予測がつかない状態だった。 - **解決策と工夫点** そこで、`CloudWatch`を用いて`CPU/Memory使用率` や `ALBのレスポンスタイム`, `StatusCode`などが一定の閾値を超えると`Slack`に通知することで、**チーム全員が即座にパフォーマンス悪化を確認できる様にした**。 また、`Performance Insight`, `Athena`を導入し、ログ解析・原因の早期発見・改善を実現した。 3. `AutoScaling`と`マルチAZ`構成用いたスケーラビリティを実現し、高負荷時でもダウンタイムをゼロに成功 - **課題** サービスの特性上、アクセス数が急増することが予想された。 - **解決策と工夫点** `マルチAZ`, `AutoScaling`を用いてアクセス数に応じて`EC2`を自動で増減させることで、アクセスのダウンタイムをゼロにした。 4. コストとセキュリティを加味したAWSアーキテクチャの採用でコストを`50％削減`に成功 - **課題** 予算が限られていたので、コスト削減が求められた。 - **解決策と工夫点** - `ECS`を`Fargate`ではなく`EC2`を使い、コスト削減を実現 - `WAF`を用いて、`SQLインジェクション`や`DDoS攻撃`からプロダクトを保護（実際、めっちゃDDoS攻撃きててヤバかった）。<!-- （海外からのリクエストをブロックしたらStripe死んだ） --> - 敢えて`Public Subnet`のみを使うことでコスト削減を実現（`EC2`や`RDS`は`SG`を用いてリクエスト元を制限）。 `Private Subnet`では`NATゲートウェイ`が必要になり、使用時間とデータ転送量でお金がかかる。 動画配信サービスなのでデータ転送量が多いとコストに跳ねそうだったので、敢えてパブリックサブネットのみを使うことでコスト削減を実現した。 5. `Route53`の`CLI`を活用し、CSの業務時間を`月30時間削減`に成功 - **課題** サービスの仕様として、動画コンテンツを配信するユーザーは各々`test.icey.jp`のようにサブドメインを発行して専用サイトを作る。 初期仕様ではユーザーがサブドメインをリクエストし、CSが都度サブドメインを登録するフローになっていた。 しかしそれではスケールしない && ヒューマンエラーの温床になる状態だった。 - **解決策と工夫点** サブドメイン自動登録バッチを実装したことで、**ドメイン発行処理を自動化し月30時間削減に成功**した。 6. `Lambda`, `MediaConvert`, `CloudFront`を用いて動画再生のUX向上に成功 - **課題** ユーザーがアップロードした動画の解像度が大きいと再生が遅くなる懸念があった。 - **解決策と工夫点** 動画アップロードを契機に`MediaConvert`を起動し、`HLS`形式に変換・解像度変換処理を実装し、`CloudFront`を用いて動画のキャッシュすることでUX向上に貢献した。 ## バックエンドの底上げとチームビルディング ### 前提 - **私以外のメンバーがプログラミングスクール卒業したばかりの実務未経験エンジニアだったので、可読性やパフォーマンス、セキュリティ的に良くないコードが散見されていた**。 `Cost`は良いが、`Quality`, `Delivery`が最低だったので、以下取り組みを通じで、バックエンドの底上げを行った。 ### 成果 1. 技術力の底上げ・属人化の排除に貢献① - **課題** - そのコードを書いた人しか読めないコードが多発していた。 - 自分以外のメンバーは全員エンジニア歴が浅く、単純に実力不足だった。 - **何が分からないかを分からない**状態だったので、課題の吸い上げやエスカレーションが無い状態だった。 - **解決策と工夫点** ペアプロ・モブプロを通じてメンバーとのコミュニケーション・教育を徹底することで技術力の底上げ・属人化の排除に貢献した。 2. 技術力の底上げ・属人化の排除に貢献② - **課題** `PRレビュー`やペアプロ・モブプロでは時間的限界があった。 - **解決策と工夫点** `Brakeman`や`Bullet`, `lol_dba`, `Rubocop`を導入し、セキュリティ脆弱性やパフォーマンス問題、コードの可読性などをシステマティックに特定・修正させることで、漏れなくコードの品質向上に成功した。 3. 技術力の底上げ③ - **課題** メンバー全員やる気はあるものの、自分以外はエンジニア歴が浅く知識や経験が不足していた。 - **解決策と工夫点** 週1回1時間の社内勉強会を実施することで、技術力の底上げ・コミュニケーション促進化にも貢献した。 4. プロダクト品質の向上 - **課題** `Quality`より`Delivery`優先で、**テストが一切実装されておらず、プロダクトの品質を保証する根拠が全くない状態**だった。 - **解決策と工夫点** 全くテストを実装せずに開発を続けるのは危険ではあるものの`Delivery`最優先だったので、 プロダクトのコアドメイン（動画やユーザーのCRUD）に限定して、単体テスト（RSpec）を実装した。 これにより、**最低限の品質を担保しつつ開発スピードを維持できるように貢献**した。 これらを通じてメンバーの技術力の底上げに成功し、コードの品質向上や属人化を排除に貢献した。 ## CircleCIを利用したCI/CDパイプラインの構築 ### 前提・課題 - **私以外メンバーはインフラ・デプロイ周りの知見が全く無いので、デプロイの時間帯は私の作業時間に依存していた**。 - デプロイスクリプトを実装したが、他メンバーが`M1 Mac(Apple Silicon)`を使っていてCPUアーキテクチャが異なり、結局`Docker`イメージが動かないという問題が発生した。 (`EC2`の`CPU`が`Intel`製の`x86`アーキテクチャにも関わらず、`M1 Mac`でビルドされたイメージは`arm`アーキテクチャだから。) ### 成果 - 開発スピードが属人化しないように、**`CircleCI`を提案・導入し、開発スピードの向上に貢献**した。 ## メンバーのタスクマネジメント ### 前提 **私以外のメンバーがプログラミングスクール卒業したばかりの実務未経験エンジニアだったので、シンプルにタスクマネジメントができていなかった**。 ### 成果 1. スケジュール遅延の改善 - **課題** - **PjMがいなかった。** - スケジュール遅延が常態化していた。 - 自分以外のメンバーはエンジニア歴が浅く、タスク・スケジュール・スコープマネジメントが全く出来ていなかった。 - **解決策** なんちゃってスクラム（スクラムの`型`のみ導入し、`思想`は導入しない）の導入。 - **工夫点** スクラムの`思想`までちゃんと導入するには自分もメンバーも知識不足で失敗する可能性が高かったので、**プロジェクト管理の手段としてスクラムを導入**した。 具体的にはプランニング・スプリントレビュー・レトロスペクティブのみ導入し、スプリントごとにタスクの細分化・割り振り・締切設定をすることで、スケジュール遅延を大幅に改善できた。 また、スプリントごとに簡易的なレトロスペクティブをを行い、メンバーの成長・自主性の向上に貢献した。 <!-- ## 反省（メモ） - ポジションの兼務は利害相反になりやすいので、長期的には良くない。でも、他に任せれる人がいなかったのでしゃーないかも。 - メンバーのタスク管理については、マイクロマネジメントだったかも。でもレベルが低すぎたから、それしか手段がなかったかも。 マネジメントはコマンドアンドコントロール型とサーバントリーダーシップ型がある。 ジュニアメンバーは自分でタスクを進めることもエスカレーションもまともにできないので、コマンドアンドコントロール型が適している。 対して、ミドル・シニアになると、マネジメントが二度手間になるので、サーバントリーダーシップ型が適している。 - 技術的な正しさを追い求めていたかも -->

# 「HAKU」の開発 ## プロダクト概要 無人のセルフ医療ホワイトニングサービス「[HAKU](https://whitening-haku.com/)」の開発・運用をしている。 一言で言うと、`HotPepper`のホワイトニング版のような予約管理Webアプリケーション。 直接的な競合サービスは、`hacomono`や`STORES`など。 具体的には、以下の機能が強み。 - ホワイトニングに特化した無人店舗の予約管理 - フランチャイズ展開による『HAKU』のSEO優位性 ## プロジェクトの規模 - **開発メンバー:** 2024年3月時点で6人（全員日本人） - **開発期間:** 2022年10月〜2024年3月（1年6ヶ月） ## 技術スタック | | 技術スタック | |----------------------|-----------------------------------------------------------| | フロントエンド | Haml, jQuery, React, TypeScript | | バックエンド | Rails, Go | | DB | MySQL, Redis | | インフラストラクチャ | AWS, Docker, Github Actions, Terraform | | 開発支援ツール | GitHub, Slack, Notion, CodeRabbit, GitHub Copilot | ## 担当役割 フェーズとしては、`0→1`と`1→10`を経験。 フルスタックエンジニア 兼 Tech Lead 兼 EM 兼 PjM（PdM未経験）として、以下を担当: - エンジニア採用・育成・開発効率化 - PjM - インフラの実装・コスト削減 - マッチングアルゴリズム実装 ## エンジニア採用・育成・開発効率化 1. エンジニア2名の離職防止と2名の新規採用に成功 - **課題:** 以下が原因でエンジニア採用が苦戦 && 離職者が出そうになっていた。 - 技術レベルの低さ - 給与の低さ - 会社の知名度 - 求人の見栄えの悪さ - エンジニア採用戦略の無さ - **解決策:** 技術のモダン化（`TypeScript`, `React`, `Go`, `Terraform`を導入）することで、2名の離職防止と2名の新規採用に成功した。 - **工夫点:** 全ての課題は解決できない。選択と集中が必要。既存メンバー離職が一番影響が大きいので、何が解決すれば残るかヒアリングを行い、それに向けて改善を行った。結論、『`Rails`, `jQuery`, `AWS`だけやっていてもエンジニアの成長を感じない』という技術的な成長・長期的なキャリア形成が課題ということが分かった。また、リファラル採用できそうな2名も同じ理由で内定承諾を渋っていた。よって、`TypeScript`, `React`, `Go`, `Terraform`を導入し、技術レベルを向上させたことで2名の離職防止と2名の新規採用にも成功した。（もちろん開発スピードが低下しないように、ドキュメント化とオンボーディングを徹底し、新規採用者がすぐに開発に参加できる環境を整えている）。 経営層へは、技術力向上には短期的にはコストがかかるが、それ以上に長期的なリターン（プロダクトのQuality向上・Delivery改善・採用改善を通じたCost改善が目に見えていた）があると説明し、理解を得た。 2. `CodeRabbit`を導入し、プルリクレビューからマージまでのリードタイムを50％軽減に成功 - **課題:** 技術レベルの低さ、プルリクレビューの大変さ - **解決策:** `CodeRabbit`を導入することで、プルリクレビューの大変さを解消し、技術レベルの向上に貢献した。 3. コーディング規約の導入 - **課題:** - コードの属人化によるバグの多発、可読性の低下が顕在化していた。 - 既存機能のメンテや他機能との連携が困難になり、`著しくDelivery速度が低下`していた。 - **解決策:** - レイヤー分けに関しては`DDD`の概念を導入し、MVCより適切にレイヤー分けできるようにした。 具体的には、`Value Object`、`Repository`、`Service`層とRailsの`Form Object`層を導入し、それぞれの責務を明確にすることで、コードの可読性を向上させた。 - **工夫点:** - 個人的には、未熟なエンジニア組織に`DDD`を導入することは**アンチパターン**だと考えている。よって、`DDD`の中でも比較的簡単で且つ、現状のカオスなコードにコスパ良く導入でき且つ、`DDD`以外の文脈でも登場するレイヤーのみを導入した。 - コーディング規約に関する勉強会の実施とドキュメント化を行い、全メンバーが理解できるようにしている。 - `Rubocop`による記法の強制統一 - よくあるアンチパターンやPRレビューで指摘された内容をドキュメント化することで、再発防止を図っている。 ## PjM 1. なんちゃってスクラム導入によるマネジメント不在の解消 - **課題:** **マネージャー不在**だったので、まともな進捗管理ができていなかった。 - **解決策:** スクラムの`型`を導入することにより、マネジメント属人化を解消し、チーム全体での進捗管理を行った。 - **工夫点:** スクラムの思想まで持ち込むとオーバーヘッドで且つキャッチアップが大変（メンバー全員未経験）なので、**進捗管理の手段としてスクラムを導入す**ることで、スケジュール・スコープマネジメントに成功した。 2. ステークホルダーとのコミュニケーション強化による業務理解の向上 - **課題:** エンジニア全員業務委託だったので、**Bizサイドとのコミュニケーションが一切無かった**。 - **解決策:** スプリントレビュー・プランニングにBizサイドを呼び、他部署が何をやっているか、エンジニアが何をやっているかをお互いに共有することで、コミュニケーションの活性化と業務理解を向上させた。 ## インフラの実装・コスト削減 1. AWSコストを`30％削減` - **課題:** 前任者が雑に作ったAWS環境が原因で、無駄なコストが発生していた。 - **解決策:** 作りかけの中途半端な`staging`環境や未使用のAWSリソースを削除・作り直しを行い、約30％のコスト削減に成功した。 - **工夫点:** `Billing and Cost Management`を用いてリソース利用料金を分析することで網羅的なコスト削減とリソース整備を行った。また、`production`と`staging`でAWSアカウントを分けることでコスト管理・セキュリティ・インフラ運用の向上を行った。 2. `staging`環境構築とデプロイの安定化 - **課題:** - **メンテナンスモードが無く、アクティブユーザーお構い無しで各々の独断でデプロイしていた**。 - `staging`環境がないので**ぶっつけ本番での動作確認**になっていた。 - サーバーが2個しかないのに`Rolling Deployment`だったのでデプロイが不安定だった。 - **解決策:** - これまでメンテナンス時間がなかったので、Bizサイドに了承を得てメンテナンス時間を作ることで、デプロイの安定化を図った。 - `staging`環境を構築 - `Rolling Deployment`でも耐えうるコードを設計し、サーバー数も増やすことで一時的な高負荷にも耐えられる設計を実装した。 ## マッチングアルゴリズム実装 1. マッチングアルゴリズムを実装し、CSの手作業を`月100時間削減` - **課題:** - 空き枠とカウンセラーと歯科医師と顧客のスケジュールマッチングを、CSがExcel表を用いて手動でマッチングをしていた。 この作業にCSの工数が月100時間も発生していて、もちろんヒューマンエラーも多発していた。 - にも関わらず、自分以外のメンバーがマッチングアルゴリズムの実装に自信がなかったことも原因で実装されない状態が続いていた。 - **解決策:** CSと密に連携することで既存マッチング要件を擦り合わせながらアルゴリズムを構築した。 これにより、ヒューマンエラーはゼロになり、CSの手作業を`月100時間削減`に成功した。 - **工夫点:** CSだけでなくPO・社長とも密に連携し、今後のプロダクトロードマップを加味してマッチングアルゴリズムを実装した。 <!-- 例えば現在は1時間区切りだが、15分区切りにしたり、 -->

# 「Resily」の開発 ## プロダクト概要 OKR管理ツール「[Resily](https://resily.com/)」の開発・運用をしていた。 ## プロジェクトの規模 - **開発メンバー:** 8人（全員日本人） - **開発期間:** 2022年4月〜現在 ## 技術スタック | | 技術スタック | |----------------------|-----------------------------------------------------------| | フロントエンド(SPA) | React, TypeScript | | バックエンド | Go | | DB | PostgresQL, Redis | | インフラストラクチャ | GCP, Docker, Github Actions, Terraform, Kubernetes | | 開発支援ツール | GitHub, Slack, Notion, CodeRabbit, GitHub Copilot | | API | REST, GraphQL, gRPC | ## 担当役割 開発メンバーとして、フロントエンド、バックエンド、インフラ全ての分野で幅広く開発に携わっていた。 また、Resilyがアドバンテッジリスクマネジメント（ARM）に買収された後は、『[アドバンテッジタフネスカウンセリング](https://www.armg.jp/mhlw/toughness-counseling/)』の開発リーダーとして上流工程を行なっている。 ## 担当業務 1. CS部門と密に連携しながら`SRE`を導入することで効率的な監視体制を構築した - **課題:** 文字コードが`SJIS`のCSVインポートができない不具合が発生し、ユーザーの一括登録ができず、新規契約顧客がサービスを使えなくなっていた。 - **解決策:** `SJIS`のCSVインポートができるように修正を行うと同時に、`SRE`の設定も行った。 - **工夫点:** 開発リソース不足だったので、`SRE`を導入することで効率良くプロダクトの品質向上に注力できるようにした。 セッションリプレイやヒートマップ等のユーザー行動分析ツールを駆使し、CS部門と密に連携しながら以下を定義した。 - **CUJ:** CSVファイルのアップロード、バリデーション、データベースへの登録、招待メールの送信ができること。 <!-- 新規契約したユーザーの約9割が1日以内にCSVインポートを行っていたが、文字コードが`SJIS`のCSVインポートができなくなっていた。 CSVインポートでユーザーを一括登録できなければサービスが使えないと同義なので、`CUJ`を『CSVインポートができること』と定義した。 --> - **SLI:** - CSVファイルアップロードからユーザー登録完了までの平均時間 - CSVファイルアップロードから招待メール送付までの平均時間 - サービスの月間アップタイム率 - **SLO:** - CSVアップロード後、95%のケースで5分以内にユーザー登録と招待メール送信が完了する。 - 月間アップタイム99.9%を保証する。 - **SLA:** SLOを割った場合は、最優先でバグ対応を行い、顧客に対して謝罪を行う。 2. 500番エラーの画面実装 - **課題:** 500番エラーの画面が存在せず、エラー時に画面がただ真白になる状態だった。 問題は、**自分以外のエンジニアメンバーがそのことに何の違和感も感じていない**事であった。 - **解決策:** 500番ページを実装した。 - **工夫点:** 自分は違和感があったので、顧客とのMTGに参加させてもらい、`VoC`を聞き続けることで、エンジニア視点ではなく**ユーザー視点を身につけることに尽力**した。 他のエンジニアメンバー全員が気づかなかったUIUX改善を行なった。 3. `Ruby`用の`gRPC`のOSSのバグを修正して `Mailer`サービスを実装した。 - **課題:** Resilyはマイクロサービスアーキテクチャで構築されていて、`Mailer`が独立している。 `gRPC`経由で`Mailer`サービスを呼び出しているが、`Ruby`用の`gRPC`のOSSのバグが原因で実装が滞っていた。 - **解決策:** `Ruby`用の`gRPC`のOSSのバグを修正して、メーラーを実装した。 <https://github.com/grpc/grpc/pull/31783> - **工夫点:** `Issue`が無かったので、自分で`Issue`を立てて、PRを出した。 4. `CloudSQL`から`AlloyDB`へ移行し、DBの読み書き速度を30％改善 - **課題:** 本来`View`はデータ分析など単純な用途でしか使うべきではないが、複雑な`View`に更に複雑なクエリをかけていた。 もちろんインデックスが貼れないので、読み込み時間が10秒以上かかっていた。 - **解決策:** `AlloyDB`への移行を行い、DBの読み込み速度を30％改善した。 - **工夫点:** 本来であれば`Materialized View`やテーブル化で対応すべきだが、テーブル化するには開発リソースが足りず、また、リアルタイム性を求められるデータなので`Materialized View`も適していなかった。 一筋縄では行かない状況だったので、暫定的処置として`AlloyDB`への移行を行い、DBのRead速度改善によりUX改善に成功した。 5. `Go`のデバッグ環境を整備し、開発スピードを向上させた（計測はできていないが体感2倍以上） - **課題:** `REPL`系のデバッグ環境が無く、デバッグが大変だった。 - **解決策:** `Delve`を導入して、デバッグ環境を整備した。 - **工夫点:** 素の`Delve`は使いにくいので、UIが分かりやすい`VSCODE`経由で`Delve`を使えるようにした。 また、`Docker`コンテナ内外両方からでもデバッグできるようにした。 6. `DDD`でバックエンドの実装を行い、ドキュメント整備を行いメンバーのキャッチアップをサポートした。 - **課題:** バックエンドが`DDD`で記述されていたがメンバー全員`DDD`未経験で、コードが属人化していた。 - **解決策:** 自分自身も`DDD`未経験だった為、キャッチアップを行いながらでバックエンドの実装を行い、`DDD`についてドキュメント整備を行うことでメンバーのキャッチアップをサポートした。 7. `React`のコンポーネントレンダリングに20秒弱かかっていた処理を3秒に改善 - **課題:** レンダリングに20秒弱かかっていた処理があり、ユーザーが待ちきれずに離脱していた。 - **解決策:** `React.memo`, `useCallback`, `useMemo`を用いて、コンポーネント・関数・変数のメモ化を行い、パフォーマンスを改善した。 - **工夫点:** `why-did-you-render`を導入して、レンダリングの原因を特定し、パフォーマンスを改善・再発防止した。 8. リッチテキストエディタのレンダリング速度を10分の1に改善 && 文字記入数を20倍に改善 - **課題:** リッチテキストエディタの記入内容を自動保存する仕様だったが、`onChange`で`POST`していてパフォーマンスが最悪だったので、ユーザーの文字記入数が激減していた。 - **解決策:** `debounce`で実装することにより、レンダリング速度を10分の1に改善 && 文字記入数を20倍に改善に成功 9. PRの粒度を細分化することで、PRレビューのコメント数を約3倍に増やした。 - **課題:** PRの差分が数千行になることが頻発し、まともにPRレビューできていない && レビューコストが嵩む状況だった。 - **解決策:** PRの差分を`400行`以下にすることで、PRレビューの効率化を行った。 - **工夫点:** スプリントレトロスペクティブでPRの細分化を提案し、スクラムチーム全員で『差分は400行以下にする』という合意をとった。 10. 社内スクリプトの修正を行い、テスト実行時間を15分から1分に改善 - **課題:** - 社内スクリプトで使用するライブラリのバージョンが古く - マイグレーションを実行せずにテスト実行していて - テスト失敗時のログ出力が不十分で - 特定箇所のみのテストが実行できず、全テストが実行されるようになっていた - **解決策:** - 使用ライブラリのバージョンアップ - テスト実行前にマイグレーションを実行するように修正 - テスト失敗時のログにユーザーID・企業IDを出力するように修正 - 特定箇所のみテストを実行できるように修正 - **工夫点:** 社内スクリプトは滅多にメンテされないので、丁寧にコメントを記述した。 11. セルフサーブ機能の実装 - **課題:** 営業活動だけでは売り上げが伸び悩んでいたので、セルフサービス機能を実装することで、売り上げを伸ばすことが求められていた。 - **解決策:** セルフサービス機能を一人で実装。CSにヒアリングを行いながら、ユーザーのリテラシーに合わせたデザインや機能を実装した。 - **工夫点:** セルフサーブのターゲットとなる顧客や既存顧客のニーズをCSやマーケからヒアリングを行いながらUIUXの実装を行なった。セルフサービス機能を一人で実装。CSにヒアリングを行いながら、ユーザーのリテラシーに合わせたデザインや機能を実装した。

# 「ARM」の開発 ## プロダクト概要 メンタルカウンセリング・コーチングのWebアプリケーション「[アドバンテッジタフネスカウンセリング](https://www.armg.jp/mhlw/toughness-counseling/)」の刷新をしている。 ## プロジェクトの規模 - **プロジェクトメンバー:** 20人（全員日本人） - **開発期間:** 2023年8月〜現在 - **開発規模:** 3億円 - **開発スタイル:** ウォーターフォール ## 担当役割 開発リーダーとして、RFPや要件定義書の作成、カウンセラーのマネジメントなど、上流工程を担当している。 具体的には以下を担当: - スコープマネジメント - コミュニケーションマネジメント - ステークホルダーマネジメント - スケジュールマネジメント - リソースマネジメント - 品質マネジメント <!-- - リスクマネジメント --> <!-- - コストマネジメント --> <!-- - 調達マネジメント --> <!-- - 統合マネジメント --> ## 前提 このプロジェクトは私がアサインされる前からかなり炎上していた。 具体的には以下。 - 3年がかりの大プロジェクトにも関わらず、1年半経ってようやくRFPを作成し始めた段階。理由は、前任者が何も決めなかったから（これにより前任者は取締役を降格になった）。 - 要件定義やRFPの作成は本来エンジニアが行うべきだが、自分がアサインされた当時は上司（PjM）がそれら全てをカウンセラーに任せていた。理由は、この炎上案件の責任を取らされたくないから。 現在もその影響を強く受け、プロジェクトの進行が遅れに遅れているがリリース日は絶対にズラせないので、試行錯誤しながらなんとか前に進む様に奮闘している状況である。 <!-- - **RFP作成に1年半かかった** - 3年がかりの大プロジェクトにも関わらず、1年半経ってようやくRFPを作成し始めた段階。 - 前任のPMが何も決めずに時間とコストを浪費。 - 役職主義（何を言ったかではなく誰が言ったかが重視される世界）にも関わらず、権限委譲が下手な企業文化なので、何も進まなかったらしい。 - 前任PMが定年まで逃げ切れるからサボっていたと考えられている。実際。前任PMは今回の失態で執行役員から本部長に降格したが、2024年5月に定年退職した。 - 上司（PL）の圧倒的**他責**思考と**受け身**の姿勢 - 自分の歓迎会の時に『この案件は絶対に炎上するから、自分達に責任が飛んでこないように立ち回るのが大切』と発言。 - 上司はエンジニアという立場でありながら、RFPやシステム要件定義書、ER図などの作業を全てシステム未経験のカウンセラーに押し付けて、上司は開発受託会社との日程調整やメールのやり取りだけを行っている。 - 自分が上司に『カウンセラーさん達がシステム未経験で要件定義の進め方に苦戦しているから手伝っても良いか？』と確認すると『良いけど責任がこちらに降りかからない様に、最終的な決定はカウンセラーにさせて。』と発言してくる。 - 『コード書いたのが17年前。AWSのコンソール触ったことない』と発言。 - ストレスチェックやカウンセリングサービスなどの認証・認可を共通化するプロジェクト（共通認証基盤プロジェクト）側からシステム的な質問が来ても『それは要件次第ですね。』の一点張りで、『IDはメアドでいいですか？』『PKやFKはどれにしますか？』『どのカラムをカウンセリング側で持って、どのカラムを共通認証基盤に渡しますか？』などエンジニアしか分からない質問をカウンセラーに丸投げしている。カウンセラーから質問されたらフォローしているが、そもそもカウンセラーに決めさせるべきではないのに、責任逃れできるようにしている。 - 憶測だが、なぜこうなっているかというと、上司はこれまで下請け開発会社で働いていたため、発注会社との揉め事を嫌というほど経験してきたから、自分が責任を取らないようにしていると思われる。 - 協業T社との契約漏れによる**要件爆発** - 今回のシステム刷新は協業T社のシステムも兼ねている。しかし、ここで認識に齟齬が発生している。ARM側としてはあくまでカウンセリングシステムをSaaS売りしたいので、汎用的に作る方針でこれまで検討してきている。 - しかし、協業T社はT社専用にカスタマイズされたシステムを作ってもらうと認識していた。 - 本来であれば前任PMが、認識を合致させて契約を結ぶはずが、それをしていなかった。汎用的ではないT社専用のシステム要件が大量発生し、**要件爆発**が起きている。 - ではなぜ協業T社と関係を立たないかというと、『投資委員会（社内稟議）でシステム開発費をT社が半分出す』という前提で承認をもらっているので、引くに引けない状況にある。 - また、T社はARMより株価は10倍以上あり、知名度と協業の実績は会社の信頼に繋がるという側面もあり、引くに引けない状況にある。 ## 組織的問題 - セクショナリズムとサイロ化の常態化 - ストレスチェックとカウンセリングサービスは同時契約した場合、解約率が4分の1になるというデータがあるのに、それを営業部署に伝えても『部署が違うから』という理由で無視されている。 - データが一元管理されていない && 神Excelで属人化しているので、そもそもデータドリブンな判断ができない。 - データの一元管理に課題感を持っていない && ITリテラシーが低い高齢者組織と化している。 - 過度な役職主義。何を言ったかではなく誰が言ったかが重視されるので、内部政治が跋扈している。 - NEC営業からの天下りCTO - NECからの天下り営業がCTOになっている。 - CTOはDockerが属人化すると言い出す。 - CTOはウォーターフォール至上主義。 - ウォーターフォールとそれを取り巻くレガシー環境についての危機感がない。 - Excel神業 - なんでもかんでもExcelで管理しようとする。 - QAもチャットやメールではなくExcelで管理している。例えば『RFP_質疑応答_20240211.xlsx』『RFP_質疑応答_20240213.xlsx』など - 間違った社内用語。クロスセルをアップセルと言っていたり、メールをチャットと言っていたり、社内用語が統一されていない。 - 過度な会議と承認プロセス - 会議への参加人数も無駄に多い - 発言者は数人なのに、毎回十人前後参加している - 形式主義で、意思決定・承認プロセスが無駄に多い。 - 権限委譲が下手くそで、自分が決定権を持っていないのに、自分に決定責任を押し付けてくる。 - 人材不足・採用失敗 - Resilyエンジニア全員の退職 - 3年間採用が失敗続き。採用した人は全員退職済み。 - 新参CTOと既存エンジニアの軋轢 - PowerBIがあるのに4000万かけてデータ分析機能を作る。 - PKSHAで事業部長やってた人が、ARMで事業統括部長になっていたが、取締役が何も決めず進まなかったから1年で辞めた。 - DX部も30代がいない。40代以上ばかりと新卒。コードをかける人が全員辞めていってる。コード書けない上流工程やってる人だけが残ってる。 --> ## 担当業務 ## スコープマネジメント 1. **要件爆発**の解決 - **課題:** - カウンセラー達はシステム開発未経験なので案の定『**あれもやりたいこれもやりたい**』と要件が複雑になっていった。 - **機能の必要・不要はゼロイチではなくグラデーションであるが、カウンセラー達はそれを言語化できていなくて、人によって必要・不要がブレブレだった。** - **解決策・工夫点:** - MoSCoW分析を導入し、必要・不必要のグラデーションを以下のように言語化した。 - ないと業務が回らないもの（Must） - なくても業務は回るが、あると業務効率が格段に上がるもの（Should） - なくても業務は回るが、あると業務効率がちょっと上がるもの（Could） - **現時点では**なくても困らないもの（Won't） - **リリースが2025年4月Must**だったので、他にも以下の様にしつこく確認することで要件の取捨選択を行った。 - 『25年4月（リリース日）時点でその機能が無いと業務が回らないのか？』 - 『Mustなのはわかるが、**手作業ではダメなのか？**』 - 『**その機能は本当に必要か？現在の機能がそうなってるだけで、本当はもっと別の機能にした方が良いいのでは？**』 - 『**その機能が必要と言ってるのは誰か？特定のカウンセラーだけなのか、全カウンセラーなのか？**』 - 『**その機能が必要な理由・背景は何？本当に本質的な課題を解決している？手段が目的化していないか？**』 - 『その機能を実装することの費用対効果（ROI）はどうか？』 - 『その機能はMust, Should, Could, Won'tどれに当たるのか？』 - 何度も確認 & 言質を取る。 2. 三現主義を徹底したドメインを理解 - **課題:** 自分はシステム開発の知見はあるが、カウンセリング業務の知見がなかった。 対して、カウンセラーはドメインエキスパートだが、システム開発の知見もITリテラシーも全く無かった。 - **解決策:** - カウンセリング業務のヒアリングとロープレ - 使用しているツール群の把握 - 現行カウンセリングシステムの仕様把握 - 今後欲しい機能とその背景・根拠の理解 - 普段のケアレスミスやZDに抵触するような項目の把握 - **工夫点:** 三現主義の徹底。 カウンセラーとの認識齟齬の主な原因が、自分にドメイン知識が無いこととカウンセラーにITリテラシーが全くないことだった。なので、カウンセラーの要望や本質的課題を正確に汲み取るためには、カウンセラーの立場に立ち、カウンセリング業務のドメインを理解する必要があった。 それを解決するべく三現主義を徹底し、カウンセラーの視点を身につけるように奮闘した。 <!-- たとえば気づいたこと。 - 営業日がARMとTMSで異なる。ARMは年中無休。TMSは土日祝日休み。 - シンクライアント的なワークスペース使ってる。コピペできない。画像も保存できない。VPNが厳しい。だから、Gmailとかarm.jpのメアドではなく、システム内チャットでやり取りしなければならない。 - 検索と言った時に、カウンセラーの検索・ユーザーの検索などそれぞれの検索機能だと僕は思っていたが、カウンセラーは全てを含んだグローバル検索を指していた。 - 『カレンダーから予約する機能が欲しい』と言った時に、『カレンダーだけから予約できる機能』と僕は思ったが、カウンセラーは全員『カレンダーからもイシュータイプからもカウンセラーからも予約できる』 - 『自動お知らせ』と言えばNotificationをイメ＝辞するが、T社ではお知らせもメールも全てシステム内チャットでやり取りしているので、『自動お知らせ』と言えば『システム内チャットでの自動お知らせ』を指していた。なので、お知らせに対して返信ができるようになっていた。 - 『手動お知らせ』も同じ。 - 16回ではカメラONにできない。 - --> ## コミュニケーション・ステークホルダーマネジメント 1. 社内用語ドキュメントを作成し、開発受託会社との認識齟齬を減らした。 - **課題:** 一般的な言葉を使わず社内用語を多用していて、誤解を生みやすい && ハイコンテキストな状態だった。 例えば『**メール**』**と言う言葉が**『**チャット**』**の意味で使われていたり、**『**クロスセル**』**のことをARM社内では**『**アップセル**』**と呼んだり、**『**カウンセリング**』**を人によって**『**CNG**』『**CLG**』**と略したりとカオスな状態**だった。 自分だけならまだしも、今後アサインされるメンバーや外部ステークホルダー（開発受託会社やOEM売りを考慮した際の顧客など）との意思疎通に支障が出る状態だった。 - **解決策:** 社内用語をドキュメントにまとめることで、認識齟齬を減らすことに成功した。 - **工夫点:** カウンセラー達に用語の説明文を書いてもらい自分がレビューすることで、チームで社内用語ドキュメントを運用できる仕組みを作った。 <!-- - **失敗:** 協業T社の社内用語はまとめられなかった。理由は、優先度。向こうの対応をそこまで丁寧にやることでそこまでメリットがあるように思えなかったから。でも実際はやるべきだった。『自動お知らせ』とかマジで意味が分からなかった。 --> 2. 無駄な仲介役の廃止 - **課題:** - 協業T社とのコミュニケーションを仲介するARM社内メンバーが無駄に二人も居た。これにより、伝書鳩のようなコミュニケーション構造になり、認識齟齬や単純なコミュニケーションコストが爆増していた。 - 協業T社とのコミュニケーションを、チャットではなく`Excel`ファイルを用いて行なっていた。しかもその`Excel`を個人フォルダに置くなど情報管理が属人化していた。 - **解決策:** 仲介役と`Excel`を廃止し、`Backlog`を用いて協業T社と直接コミュニケーションできるようにした。 - **工夫点:** **仲介役は自分より年齢も役職も上だったので権限のない自分では廃止できなかった**。 よって、コミュニケーションを阻害している客観的証拠をPMに提示・説得することで廃止してもらった。 ## リソース・品質・スケジュールマネジメント 1. 上流工程の巻取り - **課題:** RFP・要件定義書の作成は本来エンジニアが担当するべきタスクであるにもかかわらず、上司（PjM）はそれをカウンセラーにやらせていた。理由は上司が炎上案件の責任から逃れるためだった。 なので、当たり前だが成果物の質・量ともに最低だった。実際、開発ベンダーから『何を言いたいのかよく分からない』『そもそも日本語として体を成していない』と言われた。。 - **解決策と工夫点:** - 一人で全ては巻き取れないのでシステムのコアドメイン機能に当たる部分は自分が担当し、それ以外の部分はカウンセラー達に任せることで少しはマシになった（もちろんリソース不足の中やっているので、まだまだ質は低い）。 - 要望を要件として記述するための簡易的な文章テンプレートを用意したり、考え方の指針を示したり、内容レビューをしたりすることで属人化の排除を徹底させた。 2. カウンセラーをマネジメント - **課題:** カウンセラー達がそもそもタスク・スケジュールマネジメントが一切できていなかった。 理由は2つ。1つ目は人手不足。 2つ目はカウンセラーの中で役職（部長や副部長、課長など）が、カウンセリング業務の成績だけで決まっているので、マネジメントスキルがない人が役職に就いていた。 よって、マネジメントが破綻していて上流工程が進まない状況だった。 - **解決策:** - カウンセラーがスケジュールを全く意識してなかったので、`Backlog`を使い進捗管理を徹底させた。 - 業務フロー図やER図なども`Excel`で管理していたが、重すぎて開かなくなったりメンテが大変だったので、`Miro`を導入したことで劇的に業務効率が上がった。 - **工夫点:** カウンセラー達とは15歳以上歳が離れているので、年齢差によるハレーションを防ぐ為に、信頼関係の構築に細心の注意を払った。 具体的には、以下のような工夫をした。 - 雑談を交えたり - お土産を送ったり - 年齢は若くても技術力は一人前であることを示す為に、自分のITに関する知見を披露したり - 三現主義に基づいてカウンセラー業務を理解したり - 一緒に飲みに行ったりなどした。 3. カウンセラーのリソース配分の調整 - **課題:** **カウンセラー達は通常業務の合間にシステム開発の作業を行っていた為、コンテキストのキャッチアップやスイッチングコストが高く、作業効率が悪化していた。具体的には、リソースの1、2割を割くカウンセラーが5名もいたが、そんなちょっとの時間ではMTGにも参加できず、全体の決定事項などをキャッチアップすることが困難だった。そのため、タスクを振られても何をやって良いのか・何の為にやるのかを把握できず言われた事すらできない状況に陥り、ハレーションが発生していた。** - **解決策:** 各カウンセラーにリソース配分を最低でも5割以上割く様に強く要請した。クオーターごとにリソース配分が決まっているので、次のクオーターからは5割以上のカウンセラーのみ残るようになり、作業効率が劇的に上がった。 ## 調達マネジメント 1. 協業T社との契約漏れによる要件爆発。 - **課題:** ARMと協業T社の認識齟齬が大きく、要件爆発が起きていた。ARM側は『カウンセリングシステムをSaaS売りする為に汎用的に作る。協業T社はあくまで1顧客』という方針でこれまで検討してきた。しかし、協業T社から『ARMはT社専用にカスタマイズされたシステムを作ってもらうための請負会社だと認識しています』とストレートに言われた。本来であれば前任PMが、認識を合致させて契約を結ぶはずが、それをしていなかった。これにより、汎用的ではないT社専用のシステム要件が大量発生し、要件爆発が起きている。 ではなぜ協業T社と関係を立たないかというと、『投資委員会（社内稟議）でシステム開発費をT社が半分出す』という前提で今回のプロジェクトの承認が降りているので、引くに引けない状況にあるから。 - **解決策:** **正直、うまく解決できたとは微塵も思っていないし、まだ解決できていない。** 自分一人でエスカレーションしても解決しないと判断し、上司（PjM）とカウンセラー全員でPMにエスカレーションすることを依頼した。 これにより、T社の要望をできるだけ断る嫌われ役を別の部署からPMが連れてきた。その人がT社との交渉を行い、ARM側の要望を概ね通すことができた。しかし結局いまだに契約は結んでいないので、後々手のひら返しされるか不安だが、とりあえず要件爆発は一件落着？した。 <!-- 7. プロダクトロードマップの理解と反映 - **課題:** カウンセラー達はシステム開発未経験なので、RFPや業務フロー図を作ることで手一杯で、プロダクトロードマップまで気が回っていなかった。 - 例えば、ベンダー売りを考えた『サービスと契約』 - 人材教育とセッションと満足度アンケート - セッションレポートの入力項目の動的生成 - **解決策:** ER図やテーブル定義書などの機能要件に、将来のプロダクトロードマップを反映させた柔軟性・拡張性を持たせた。 - **工夫点:** カウンセラー達はシステム開発未経験である。よって、柔軟性がないとどうなるかを理解させるために、具体的な動くものやデモ、デザインサンプルを駆使して、どういう機能があれば良いかを理解させた。 --> <!-- ## できなかったこと - PowerBIがあるのに4000万かけてデータ分析機能を作る。 - PowerBIがあるのにデータ分析機能を作ろうとしていた。なぜなら社内の情報セキュリティ方針に違反するからBIツールの使用は禁止されていたから。 - 社内の情報セキュリティ方針について情シスに詳しく聞くと『お客さんがBIツールで直接DBを閲覧するのが良くない』という理由だった。 - しかし、PowerBIはDBを直接閲覧するのではなく、DBからデータを抽出してExcelのように扱うので、その理由は成り立たない。 - もしこの理論が罷り通るなら『フロントエンドだって、バックエンドがDBから抽出したデータ見てるから、フロントエンドも禁止になるからおかしい』という理論を展開したが、理解されず。 - それをCTOに報告しても、CTOは『ルールだから仕方ない』の一点張りだった。 - なので、PowerBIの導入はできず、4000万かけてデータ分析機能を作ることになった。 - しかも、結局予算オーバーで2800万円分まで機能を削る事になった。Mustで必要な機能まで削る事になり、ユーザーへ提供できる価値が著しく損なわれる事になった。 --> <!-- # その他頑張ったこと ## TMS要件の整理とFitに向けた調整 徹底した無駄の排除 - 機能をシンプルにする - パスワード変更ができる『セキュリティリスクマネジメント』 - 個人情報をCSVダウンロードできる機能の排除 ## PM時に気をつけること - 三現主義 - PMBOKで言うところの『10の知識エリア』の徹底 - MosCowの法則の徹底 - 実際に動くものを見せてイメージを掴ませる　＆＆　義重的な信頼を勝ち取る - 話が二転三転する。（内村、池田） - 言われたことをそのまま送信する。ただの仲介役・伝言ゲームになってる（池田、吾郷、タフネス、その他部署） - 営業が言ってることなのか、お客さんが言ってることなのか？ - お客さんが言ってるとは、一部のお客さんだけなのか、多数のお客さんが言ってるのか？ - -->