FutureVulsって何?
@sadayuki-matsuno さんが、ほぼ一人でアドベントカレンダー書いてます。サービス概要については、このアドベントカレンダーを読めば理解できることでしょう。
セキュリティの面倒な部分はVulsに任せよう。サーバの脆弱性をスマートに一元管理するFutureVulsが正式リリース！
さて、この記事では、FutureVulsのフロントエンドを作り直した話をします。そしてここから文語調です。
Before/After
どのように変わったかについては、クラスメソッドの方がちょうどバージョンアップ前後の記事を書いているので、分かりやすい。さっそく見てみる。
Before
FutureVulsで脆弱性診断してみた ｜ DevelopersIO
After
大規模バージョンアップ！新しくなったFutureVulsを触ってみた ｜ DevelopersIO
何を意図して、何が変わったのか
主に実施したことは、以下のとおり。
上司に紹介しやすいサービスに
- メインカラーを白に変更
- 表形式にして、オフィスツールだとわかるようにする
大量のデータを操作しやすくする
- 表形式でデータを表示し、全ページで操作方法を統一する
使えば使うほど、効率が上がるツールに
- 重要な情報の条件をユーザがカスタマイズできる
- キーボードショートカット
- カラム/ペインの表示方法をカスタマイズできる
最初に覚えることを減らす
- メインのアクションの操作方法を統一 (同じコンポーネントを利用)
- メインアクション以外で、当時利用されていなかった機能を削除
- ダッシュボードの削除
- カレンダー機能の削除
自分の立ち位置
今年の4月から、外注のエンジニアとして週2~3日ほど稼働中。
なお、FutureVulsチームは基本全員リモートで稼働している。
紹介記事を書いた松野さんが、バックエンドとフロントエンドをほぼ一人で担当する時期があり、松野さんが得意なバックエンドに専念させようという目論見だった。
ジョインからリリースまでのスケジュール
4月 : チームにジョイン、旧フロントエンドシステムのサポート、ビジネスの理解、UI改善案の提出
5月 : モック作成、インタビュー
6~7月 : 新プロジェクトのベース作成、基幹処理作成
8月 : 開発ラストスパート + Vuls祭り で新UIリリース
コミット履歴を見ると、実際に開発をスタートしたのが6月上旬だったので、3ヶ月で作ったことになる。 8月リリースは決まっていたのに、5月くらいの自分、ぜんぜん危機感なかったのだろうか。
各段階で気をつけたこと
以下は、各段階の進め方でよかったと感じたものを記していく。
4月
ジョインして早々、サービスについての戦略を話し合う場があり、結果としてUIを改善しようという話になった。
この時期は、主にミーティングをしていた記憶がある。そのミーティングの中で、改善後のUIをホワイトボードにイメージを書いた。
なお、新UIを作るにあたり、ターゲットとメインアクションを可能な限り明確に定義してもらった。
- メインターゲットの決定
- どういう人達が使うのか
- B2Bの場合は、具体的にどの会社が契約してくれそうか
- メインアクションの特定
- メインターゲットに近い人達にヒアリング
- 日々の運用でやってることを理解する
5月
4月に話したことをもとに、ウェブで動作するモックを作成。
モック作成には Moqups と yEd を利用した。
以下のように、yEdで画像1枚のページを作って、そこに他のページに遷移するアクションをつくるだけだったので、1日掛けてモックを作った。
1日で画面遷移のイメージと操作イメージが共有できるので、安い投資だろう。
●がある箇所は、メンバーからのコメント。積極的にフィードバックがもらえたので、その意見をさらに反映して、みんなの頭の中にあるイメージを統一していった。また、そのモックをもとに既存顧客や、潜在顧客にインタビューを行い、自分の中で完成図が見えるまでモックでの挙動を考えた。
6-7月
旧プロジェクトをそのまま利用するか、新しく作るかの判断を行い、プロジェクトの雛形から、メインUIのベース部分を作った。
Frameworkや構造などを考え、結果的に React+Reduxのducksパターンを採用した。
また、そのときの判断で、一部の通信で利用していたGraphQLを廃止してもらったり、TypeScriptを廃止したりと、モダンとは逆の選択もした。
当時、GraphQLがMutateに対応していなかったため、Apolloと API+Reduxの2つの処理を制御する手間や、TypeScriptを導入することにより、短期的にコードをガンガン変更しづらくなることなどが理由。 代わりにflowtypeを導入して、必要な箇所だけ型定義すればいい、という形にした。
フロントエンド側(僕を覗いて1.5人)のタスク管理も軽く行っていたが、それぞれ担当範囲を決めて、めちゃくちゃざっくり決めたら、めちゃくちゃ頑張ってくれた。
1)新UIメインページ担当、 2)デザイン担当、 3)既存システムからの移行担当 と役割が明確だったので、こちらでざっくりタスクを依頼していた記憶。
8月
基幹部分の作成に1.5ヶ月くらいかけてしまったので、8月はほぼ5日/週のペースで稼働。(土日含む)
周囲の協力もあり、ちゃんとVuls祭りには間に合った。
リリース後について
最近はフロントエンドを他の優秀な方にお任せしていて、自分はGolangを利用して、OSS Vulsにも貢献しはじめた。
これまでも、バックエンド/フロントエンドともに自分でやるのが普通だったし、そのほうがコミュニケーションコストは減るし、自由に働けるので、このままの方向で仕事したい。
振り返り
良かった点
- 期限内(8月まで)に作り切れた
- メインのアクションまでの画面遷移数が減った
- 脆弱性検知 → リスクの仕分け → タスク化
- メインアクションの基礎ロジックをまとめることができた
- メインページは全て同じ親コンポーネントを利用している
- メンバーごとに担当領域を作ることで、細かなマネジメントをする必要もなく作業ができた
- 全員リモートワークにもかかわらず、大きな問題は発生していない
- 全員の強みが違っていたことも幸いした
悪かった点
- ビジネスロジック部分のテストしかなく、手動デバッグの要素が大きい
- 現在、Cypressを利用してE2Eテストを導入中
- ベースロジックをつくるのに時間を掛けすぎた
- 自分の実装待ちのタイミングがあり、結果全体の作業が遅延
- 週3だったので、もっと手離れよく進めることはできたと思う
気づき
- 遊び心で作った機能が、割と営業受けすることがわかった
今後について
FutureVuls自体がまだ成長初期のサービスなので、市場が大きくなることを信じて改善を続ける。入ったばかりの状態の自分の言うことを信じて任せてくれたので、任せてよかったと考えてもらえると嬉しい。
FutureVulsに興味のある方は、紹介記事にもあるとおり、LPからチャット
すると爆速で神戸さんから返事が届くので、ぜひご連絡ください。