ID:49529さん

# 概要 workhubのtoB向け管理画面の新規機能開発や、運用、保守を担当。 workhubとは、企業における人・モノ・空間を管理するwebアプリ（workhubにおける「人」は、従業員や、面接などで訪れる来訪者など、「モノ」は自社製品のスマートロックやIoTデバイスなど、「空間」はビルや自社オフィスの会議室などを示す）。 人・モノ・空間を管理することで、誰がいつどの鍵を用いて入れるか、などの権限管理をweb上でできるようになって物理鍵をなくしたり鍵の譲渡という業務をなくしたり、出退勤ログをモノ経由で自動で保存することによって、ISMS認証にも使用できる入退室ログを手軽に管理できる、などの価値を提供している。 # 主な実績 ## 開発 ### 1. [Workplace from Meta](https://developers.facebook.com/docs/workplace/?locale=ja_JP) との連携 - やったこと Workplace from Metaと自社サービスのAPI連携を用い、自社サービスの無人受付システムと連動した受付通知機能を実装した（連携設定画面と通知ロジック） - 意識した点 自社サービスとWorkplace from MetaのAPI連携は初めてだったため、素早く検証できるよう、強い権限をもらうよう働いた。また、実装上何ができて何ができないかが分からなかったため、検証結果をドキュメントに残し、ある程度検証が終わった後、実装案をプロダクトオーナーへ提案する形で機能実装を進めた。実装期間は3日と短い納期であったため、実装案提案後の開発では、絶対に壊れて欲しくない処理に限定して単体テストを書き、結合テストは行わずに進めた。 成果物の機能は、バグはひとつもなく、要件の齟齬もなく、納期に間に合った。 ### 2. 受付設定編集機能開発 - やったこと 無人受付システムの受付端末設定の編集機能を実装した - 意識した点 この機能が実装されるまでは、無人受付システムをインストールしている受付端末毎に設定変更をおこなっていた。100台導入する顧客もいたため端末ごとに設定するのでは設置箇所まで訪れなければいけないため時間がかかり、端末の管理も大変だったため、管理画面で受付端末の設定（画面の色や背景画像など多岐にわたる）を変更できるようにする必要があった。 DBに受付設定が保存してあったため、管理画面から変更するのは容易だったが、導入箇所で複数の端末を扱うという無人受付システムの性質上、同様の設定を一括編集できるようにした方が、ユーザーの体験が良くなると感じ、受付設定テンプレートを保存するようにした。 - お客様の声 https://www.okamura.co.jp/office/design_tips/230701/ ### 3. canvasを用いた画面の機能改修および追加 - やったこと canvasを用いた画面の機能改修および追加を行なった - 意識した点 canvasを用いた画面の改修が初だったため、まずcanvasの概念理解に努めた。 また、機能改修した箇所以外にもcanvasが使用されていたが、処理が共通化されており、既存の内部構造では対照画面の機能追加が不可能だったため、デグレーションを起こさないよう内部構造を変更し、機能追加を実現した。 コンポーネント設計は、レンダリングされるタイミングをReact Developer Toolsで確認しつつ、責務を考えつつ、行なった。 ### 4. dangerを使用したPR行数制限 - やったこと 差分が500行を超えたPRで警告を出すよう、dangerで実装した - 意識した点 PRの行数が多いと、レビュー負荷が高くなるという課題を感じ、実装した。ただし、開発速度も落とさないよう、エラー起こしてマージできないようにするのではなく、警告のコメントだけPRに自動で出すようにしてチームの意識づけから行なった。 他にもルールを加えたくなった時のために、内部構造も疎結合になるよう実装した。 その他、細かなUI修正や、Storybookでのアイコンカタログ作成、違和感のある文言の修正提案など、行なっている。 ## 保守 お客様からバグ報告を受けた際、機能の仕様把握に時間がかかってしまっていたため、事象把握と並行して仕様書を書くようにした。お客様からバグ報告を受ける機能は、たいてい複雑な処理をおこなっていたり、複数のCloud Functionが絡み合っていたりと、仕様把握に多くの時間を割いていた課題からこのような取り組みをおこなった。 また、仕様書を書くことに時間を費やしてしまっては、お客様のトラブル解消に時間がかかってしまうため、それほど考えずに仕様書を書けるようフォーマットとそのドキュメントを書く場所（Notionのデータベース）を用意した。

# 概要 2022年10月に新設されたQA / QE / SETに参画し、品質向上のための施策を行った # 背景 プロダクトが成長するにつれ、バグが発生し顧客に迷惑をかけるようになったため、アプリケーション開発の観点から品質を向上するためのチームが新設されることになった # 主な実績 ## 1. CI環境の整備 ### やったこと - [Jest coverage report](https://github.com/marketplace/actions/jest-coverage-report)の導入 - Jestの設定見直し - ESLintの設定見直し - [reviewdog](https://github.com/reviewdog/action-eslint)の導入 - GitHub Appの導入 ### 意識した点 開発メンバーに品質に対する意識付けを主な目的とした。ESLintでは[complexity](https://eslint.org/docs/latest/rules/complexity)を設定し、循環的複雑度の高い関数があったらPRにコメントするようにした。また、テストカバレッジを定期的に見てもらうために、PR毎に出力するようGitHub Actionsのワークフローを見直した。 GitHub Appは、reviewdog導入時にデフォルトのGitHub Tokenを使用してもPRへコメントする権限がない、という問題の解消のために導入した。特定の開発者が辞めても正しく動作し続ける、というメリットもあり、GitHub Appの導入を決めた（Qiita公開済みの手順記事は[こちら](https://qiita.com/mball/items/3f35ebb28ecf773b6623)）。 ## 2. テストの書き方ガイド作成 ### やったこと ReactやExpressなどバックエンドとフロントエンド問わず、テストの書き方ガイドを作成した ### 意識した点 テストを書くことに慣れていないメンバーが多数いたため、トラブルガイドやテストの書きやすいコードにするための手順などを誰が見ても手を動かせるくらいの粒度でまとめることを意識した。 ## 3. ペアプロ ### やったこと 実装方法の相談に乗ったり、テスト容易性の高いコードにするためのコーディングをペアプロで進めた ### 意識した点 QA / QE / SETとしては、テストを書いてほしいので、いつでも相談しやすいようコミュニケーションの頻度を高めるようにした。また、他の処理をコーディングするときにも応用してもらう狙いで、テストコードの意図を同時に伝えるよう努めた。 経験していく中で、責務のはっきりしているコードに対してテストが書きやすいと理解したので、必ず「その処理の役割はなんですか？」と問いかけを行い、答えられなかったら一緒にリファクタリング、答えられたら一緒にテストコードの実装をするなど、その人のスキルレベルや状況に応じて、対応を変えるよう意識した。

# 概要 個人で図書館への新刊入荷通知アプリを開発した # 背景 以下の問題を解決するために開発した。 - 図書館で新刊をいち早く読もうとしても、人気で他の人の予約で埋まってしまっている - 図書館のシステムでは、書名など検索に引っかかってほしいのに引っかからない時がある # アプリ開発前とアプリ開発後 ### Before - 手間がかかる - 読みたい新刊あったら、逐一図書館ホームページにアクセスしていた - 時間がかかる - いち早く読むためには毎日状況を逐一みなければいけなかった - なかなか引っかからないと、当然検索という行為の優先順位は落ちて、次第に忘れてしまう - 検索に引っかからない - 検索システムの問題かはわからないが、なんか読みたい本のタイトルを入力しても、そもそも検索に引っかからない ### After - 待つだけ - 読みたい新刊あったら、自作のLIFFアプリに登録して、最寄りの図書館システムに入荷したかどうかを待つだけ - それなりに確率高く新刊を早いタイミングで読める - 自分しかステータス変わったタイミングがわからないので、高確率で上の順位で予約ができる - 検索に引っかかる - 世の中に公開されているAPIを使えば、なんでか検索に引っかからない、と言う事象自体は回避 # 意識した点 **Clean Architectureの構成で内部品質を担保する** 完全にClean Architectureの構成できたわけではないが、以下のメリットを享受できた。 - テストが書きやすい - Storybookが書きやすい LIFFに依存してしまうと、アプリが作成しづらいため、構成を意識することで回避した。 **型の制約で表現できない部分をテストで表現する** 型定義ファイルを読んでいくと、ところどころで型で表現できていない制約がある。例えば ```ts export declare type TemplateCarousel = { type: "carousel"; /** * Array of columns (Max: 10) */ columns: TemplateColumn[]; ``` は、カルーセルメッセージを送るときは、一回の送信で10個まで、という制約になっている。（カルーセルメッセージについては [こちら](https://developers.line.biz/ja/docs/messaging-api/message-types/#carousel-template) ） こういった型では表現できていない部分に対してテストを書くことで、結合テストを行わなくとも、LINE側で起きるエラーを回避することができた。 **機能ごとに要件を最初に固める** 『はじめよう！ 要件定義～ビギナーからベテランまで』を読んで、要件定義からシステム開発を始めた。 アプリ開発後の理想の状態を言語化してドキュメントに残し、そこから機能に落とし込んでチケット化するなど、と普段行わない工程もこなした。 上述したLINE Messaging APIのような制約はカーリルAPIに関してもあったが、要件定義から始めたおかげでそういった制約を開発着手前に潰しきることができた。 # 参考リンク [いち早く図書館で新刊を借りたいので、入荷と同時にLINEで猫に通知させてみた](https://qiita.com/mball/items/3f9c2831c58655835437)

# 概要 ビルへの共連れを防ぐ「アンチパスバック」の開発 # 背景 ビルセキュリティを強化するために「アンチパスバック」をworkhubで提供することになった。人の出入りや鍵の解施錠に関わる体験のため特に品質に気を使いつつ提供する必要があったが、開発期間は1ヶ月と短納期だった。「アンチパスバック」を提供する前の大型リリースではバグの多発や残業続きによる開発・QAが疲弊しており、「アンチパスバック」の開発に不安を感じていた。そのため、プロダクト開発チームをSETという立ち位置で支援した。 # 実績 - バグ発見時期の早期化 - テストケース数における発見バグ数の現象 - 遅延のないリリース # やったこと ## リリース戦略策定 高品質・短納期でのリリースを実現するために進め方を変える必要があった。その上で具体的には以下に取り組んだ。 - イベントと参加者の定義 - 検証体制 - チケットの分割 - 実装順序の調整 **イベントと参加者の定義** 「アンチパスバック」以前の機能開発では開発とQAがコミュニケーションを取る回数が少なかった。そのためQAとしてはBを先に開発してほしいが開発チームはそれを知らないためチケットの上にあるAを開発する、といったコミュニケーションが少ないことによる工程の無駄が発生していた。そのような認識齟齬をなくすために、それぞれの作業工数を逼迫しないようにしつつ、必要なイベントを定義した。 **検証体制** どのタイミングで誰がどの環境で検証するか、を決めることでバグ発見時期の早期化に繋げた。以前は全ての機能開発が一通り完了するまで検証が開始されなかったが、QAにとってのクリティカルパスを開発も認識し、実装順序を変更することで出来上がったものから検証できるよう調整した。 ## 設計レビュー APIのインターフェース設計において、シーケンス図を実装者と描きながら決めることで、ドキュメント化とレビューを同時に進めた。 ## ペアプロ 短納期なので自動テストを書くことによる遅延は許容できなかったが自動テストを書くことに慣れていない実装者だったため、時間と特に定めずにペアプロを行った。ペアプロでスキルトランスファーを行いつつ進めたため最後は実装者一人で自動テストを書けるようになっていた。 # 参考リンク https://prtimes.jp/main/html/rd/p/000000138.000040203.html

## 概要 Reactを使ったプロダクトの依存パッケージ更新 ## 背景 一時期支援していたプロダクトは `--legacy-peer-deps` オプションをつけなければnpmパッケージのインストールができなかった。その時点ではなんとかなっているが、依存パッケージが古いことは、いずれ新しい技術を試したいとなった時の障壁になったり、継続的に顧客へ価値提供し続けることを止めてしまう可能性もあると感じたため、取り組んだ。 ## 実績 `--legacy-peer-deps` オプションをつけなくても `npm install` ができるようになった ### やったこと 以下パッケージの更新および代替パッケージへの移行 - typescript - eslint - prettier - webpack - react-pose ### 意識した点 破壊的な変更が入っているものはマイグレーションガイドを読みながら進め、代替パッケージの移行をするときは作業を楽にするためにGitHub Copilotを活用して進めた。 また、今後はこういったパッケージの更新をどうしていくかの運用をチームメンバーと話し合った。renovateでの随時更新を提案しつつ、当時のチーム状況を踏まえセキュリティアップデートに限定して継続的に更新する運用に決定した。 ## 参考リンク https://moroball14.github.io/moroball14-website/blog/nodejs-update