ID:36983さん

# 現行機能の洗い出し まず、現行の電話機が何ができるかをすべて洗い出し、現場で使っている営業リーダーとすり合わせを行いました。抜け漏れを発見次第、要件に追記が行いました。 # 要件実現可能性の調査 その後、要件を Twilio で実現できるかを確認しました。確認したところ、すべて Twilio で再現できることを確認したので、実装に着手。 # 実装 実装は自分ひとりで行い、自力でわからないところは多数ありましたが、 Twilio や電話、 WebRTC について社内に知見を持つ人がいなかったため、社外の詳しい人にヒアリングしたり、 StackOverflow で英語で質問したりなどして、不明点をすべて明確にし、実装をしました。 ## 技術構成 構成としてはサーバサイドは Laravel 5.4 を利用しました。フロントエンドは内製のデザインシステムを利用し、画面の動作は jQuery2.1.4 で実現し、 Chrome Extension を作成しました。 Chrome Extension はこのプロジェクトではじめて本格的にさわりましたが、キャッチアップを行い、半年ほどでα版の提供を行い、 1 年かからずにプロダクト版リリースにこぎつけました。 Chrome Extension にした理由は、自動アップデートが可能になり、特定のサイトを開いていなくても電話を受けられるようユーザビリティも考慮したためです。一般的な電話をブラウザで受けられるシステムは特定のページを開いていないと電話を受けられないのですが、 Chrome Extension にすることでブラウザを開きさえすれば、電話の利用が可能になる点が特長です。 # リリース前テスト リリース前に影響範囲が少ない部署でα版の提供を行い、大きな問題も起きずに完了しています。リリース直前には数十名の現場の営業にも協力してもらい、システム負荷テストや要件が満たされているかを確認しました。 # 運用保守 リリース後、見つけたバグは自力で解決し、最終的にはほぼバグがでなくなりました。 安定運用に切り替わったタイミングでリリース後対応するとして、スコープ外にした機能の開発を行いました。 この際には、一緒に協力してくれるエンジニアが 1 名と、現場の営業とエンジニアをつないでくれる総務 2 名を巻き込み、テストやユーザヒアリングなども協力して行い、速度を上げて改修をし、現場の営業にも好評だったと感じています。 # リリース後分析 Twilio はすべての通話ログが API で取得できるため、取得したログを元に R 言語で分析を行い、通話までにお客様が待っている時間帯を調査し、営業の稼働時間について交渉を行いました。 # 退職前引き継ぎ 退職前にかんたんに解決できるトラブルは総務の人に情報共有を行い、ほとんどが現場で解決できるようにし、情報共有を行った総務の人がいなくなった後も情報が漏れないようにドキュメントを整備しました。そのため、退職後に引き継いだエンジニアに聞いたところ、大きな障害もなく、ほとんど困ることなく引き継ぎができていたという評判を受けています。 この業務に伴い、一般的な開発業務以外に、稟議や社外折衝、データドリブンな施策提案など幅広い経験をすることができ、事例としても取り上げられています。

# リプレイスのリプレイス 旧システムをリプレイスしたと言われた管理機能の保守を任されましたが、新システムと旧システムで機能の差分があったため、新旧管理機能を並行して、現場の人が使っていると言われました。そのため、旧システムの機能を全て新システムに移す実装を行いました。 PM が不足している機能一覧は洗い出しくれましたが、それをどのように実現するのかといった詳細については決められていませんでした。そこで、 PM と交渉を行い、機能をどのように実現するかは僕が旧システムのコードリーディングと現場の人と話し合い、仕様の洗い出しと提案を行い、合意の上で仕様策定していくということで決定しました。 自分で洗い出した仕様を元に、現場の人と随時ヒアリングを行い、実装を進めました。また、仕様をすべて GitHub Issues に残すことで、後から入った人がどうしてこのような実装になっているかがわかるように心がけています。 他のメンバーの協力もあり、無事に旧システムの機能を新システムに全て移植完了し、旧システムは削除されました。業務効率があがったと現場の人からは好評です。 # 新リプレイス 入社前の 2 年ほど前から始まっていたリプレイスはすでに当時選んだシステム構成も古くなってしまったため、再度見直し、リプレイスを開始しました。その際にはマイクロサービスの思想を導入し、機能を分割、システム構成も変更しました。 ## 技術構成 新システムの技術選定は同じチームのメンバーと行い、下記構成になりました。 * TypeScript * KoaJS(backend) * Next.js(frontend) * PostgreSQL 上記を選定した理由は、下記です。 ### TypeScript マイクロサービスの設計を取り入れるため、 RPC と相性がいい Go か TypeScript が残りました。現行システムは CakePHP + jQuery のため、現行システム保守メンバーが異動する際、 Go は学習コストが高すぎると判断しました。また、 TypeScript をフロントエンドとバックエンドにどちらも共通で利用することで、型の共通化やバリデーションの流用などをメリットに考えました。 ### KoaJS npm のインストール数が多く、薄いレイヤー構造で学習コストが低い点が採用の決め手になりました。また、Node で一番多く利用されている Express.js の作者が KoaJS を作成したため、思想が近いと考え、採用などでも有利になると考えています。 ### Next.js * 素の React を一から組むのは学習コストが重い * 実質的な提供方法が静的ホスティングのみのため、リリース直前に場当たり的な対応(HTMLタグ直埋めなど)ができないため、保守性の低いコードが入り込んでしまうことを防げる * Next.js はオールインワンなので、 webpack の最適化、 TypeScript の型定義やルーティングをファイルパスベースでできて全体的に楽 * Next.js はすでにあるレールに従って書くことで、初期設計でミスることがない すべて、メリットデメリットがあり、 React であれば Next.js よりも楽な点もあるが、すばやくリプレイスを開始し、完了させることを重視しているため、 Next.js の採用に踏み切った。 Vue.js は 2.0 は型定義ができず、パフォーマンスがよくない。 3.0 は現時点で安定版が存在しないため、採用ができないという理由から除外した。 ### PostgreSQL あえて MySQL を採用するメリットがないが最大の理由。 かつ細々とした知らないと踏んでしまう下記のような設定ミスなどが MySQL には存在するため、避けたいと考えた。 * 文字コードが独特で uft8 にしても、一部漢字や絵文字が入らない(utf8mb4 にすれば避けられるが、分かりづらい) * boolean がtinyint(1) で表現されるが、 -1 など入ってしまう * 高速に動くことを重視しているが、今後のエンタープライズ戦略を考えると、 PostgreSQL の堅牢性のほうが魅力的なため * 文字列の暗黙的なキャストが存在し、バグの温床になりうる 機能的に差分はあるが、現状のシステムで論理削除を考慮する事が多いため、部分インデックスを使える PostgreSQL に軍配が上がった。 ## 業務 新リプレイスからは僕はリーダーとして、チームを支援するスクラムマスターとして業務を行うことにしました。理由は Backend, Frontend 共にスペシャリストがおり、僕はエンジニア以外とのコミュニケーションが得意で、空いている領域だったためです。 スクラムマスターとして、スクラム開発を支援するため、下記のようなことをしています。 * 各種スクラムセレモニーのファシリテート * 現場の不満を吸い上げ、改善できるように上司に交渉 現状の業務環境はいろいろと定まっていないことが少ないため、問題点が現場から上がってくることが多いです。それらの問題点をすばやく察知し、言語化をして、上長に提案するという業務を行っていました。これをすることで、現場の開発のフローを止めないようにして、中長期的に開発効率が高まるようにしました。 ### 採用活動 また、この頃から採用活動に携わることにしました。理由は、不足している人員の拡充と採用活動に手一杯でマネジメントまで手が回っていなかった上司を支援するためです。 採用活動ははじめてでしたが、構造化面接を取り入れ、手法を一次面接をともにするエンジニアに共有し、面接の標準化と採用ミスを防ぐ仕組み作りを行いました。また、構造化面接に伴い、会社の求職票の不備や現状との不一致を洗い出し、人事部と連携して、求職票の改善も行っています。求職票の改善により、不一致の候補者にかかってしまっていた工数を大幅に削減できています。採用活動に手一杯だった上司もマネジメントに手が回せるようになり、感謝されています。